Penetration Testing with Raspberry Pi
Description
Key Features
[*] Quickly turn your Raspberry Pi 3 into a low-cost hacking tool using Kali Linux 2
[*] Protect your confidential data by deftly preventing various network security attacks
[*] Use Raspberry Pi 3 as honeypots to warn you that hackers are on your wire
Book DescriptionThis book will show you how to utilize the latest credit card sized Raspberry Pi 3 and create a portable, low-cost hacking tool using Kali Linux 2. You'll begin by installing and tuning Kali Linux 2 on Raspberry Pi 3 and then get started with penetration testing. You will be exposed to various network security scenarios such as wireless security, scanning network packets in order to detect any issues in the network, and capturing sensitive data. You will also learn how to plan and perform various attacks such as man-in-the-middle, password cracking, bypassing SSL encryption, compromising systems using various toolkits, and many more. Finally, you'll see how to bypass security defenses and avoid detection, turn your Pi 3 into a honeypot, and develop a command and control system to manage a remotely-placed Raspberry Pi 3. By the end of this book you will be able to turn Raspberry Pi 3 into a hacking arsenal to leverage the most popular open source toolkit, Kali Linux 2.0. What you will learn
[*] Install and tune Kali Linux 2 on a Raspberry Pi 3 for hacking
[*] Learn how to store and offload pentest data from the Raspberry Pi 3
[*] Plan and perform man-in-the-middle attacks and bypass advanced encryption techniques
[*] Compromise systems using various exploits and tools using Kali Linux 2
[*] Bypass security defenses and remove data off a target network
[*] Develop a command and control system to manage remotely placed Raspberry Pis
[*] Turn a Raspberry Pi 3 into a honeypot to capture sensitive information
Who this book is forIf you are a computer enthusiast who wants to learn advanced hacking techniques using the Raspberry Pi 3 as your pentesting toolbox, then this book is for you. Prior knowledge of networking and Linux would be an advantage.
All prices
More details
Other editions
Additional editions
Persons
Jason Beltrame is a Systems Engineer for Cisco, living in the Eastern Pennsylvania Area. He has worked in the Network and Security field for 18 years, with the last 2 years as a Systems Engineer, and the prior 16 years on the operational side as a Network Engineer. During that time, Jason has achieved the following certifications: CISSP, CCNP, CCNP Security, CCDP, CCSP, CISA, ITILv2, and VCP5. He is a graduate from DeSales University with a BS in Computer Science. He has a passion for security and loves learning. In his current role at Cisco, Jason focuses on Security and Enterprise Networks, but as a generalist SE, he covers all aspects of technology. Jason works with commercial territory customers, helping them achieve their technology goals based on their individual business requirements. His 16 years of real-world experience allows him to relate with his customers and understand both their challenges and desired outcomes.McPhee Michael :
Michael McPhee is a systems engineer at Cisco in New York, where he has worked for the last 4 years and has focused on cyber security, switching, and routing. Mikes current role sees him consulting on security and network infrastructures, and he frequently runs clinics and delivers training to help get his customers up to speed. Suffering from a learning addiction, Mike has obtained the following certifications along the way: CEH, CCIE R&S, CCIE Security, CCIP, CCDP, ITILv3, and the Cisco Security White Belt. He is currently working on his VCP6-DV certification, following his kids to soccer games and tournaments, traveling with his wife and kids to as many places as possible, and scouting out his future all-grain beer home brewing rig. He also spends considerable time breaking his home network (for science!), much to the family's dismay. Prior to joining Cisco, Mike spent 6 years in the U.S. Navy and another 10 working on communications systems as a systems engineer and architect for defense contractors, where he helped propose, design, and develop secure command and control networks and electronic warfare systems for the US DoD and NATO allies. Prior publication: Penetration Testing with the Raspberry Pi Second Edition (with Jason Beltrame), Packt Publishing, November 2016.
Content
Choosing a Pen Test Platform
Preparing for Battle
Planning the Attack
Explore the Target
Taking Action
Finishing the Attack
Alternative Pi Projects
Mapping our tools to the Penetration test Kill Chain
When we conduct our penetration tests, we are trying to mimic the actions an actual intruder or attacker would use to gain illicit access or otherwise compromise target systems. In this chapter, we'll discuss how we plan our penetration test, mimicking the Cyber Kill Chain discussed earlier that is often used to break down how hackers compromise their targets. For our purposes, we took some liberty with the Kill Chain and crafted the penetration test version. In this version, we did our best to show how different tools we are discussing in this tome help to get our Raspberry Pi through the entire operation:
In light of the Penetration test Kill Chain, it is helpful for us to understand what types of penetration test we may be called upon to conduct, as they can all impact how much of each of the phases we actually are on the hook to do. White box testing refers to our being given all of the information we would normally gather in the Recon phase, and as such, moves quickly and typically with us in the open (no stealth required). We might see this type of test if we are doing one as an employee or consultant against a new project's deliverables, testing a new web server or guest tenant, for instance, but without intensive Recon and maybe even Weaponize phases. If Recon is done here, it may be through more open methods such as interviews and in-person inspections or audits. Black box testing is more cloak-and-dagger - we'll be attacking without prior knowledge and therefore the Recon and Weaponize phases will be essential, and subsequent phases will hinge on those findings. Black box testing may be part of a Red Team or adversarial penetration test, usually done without warning most operators, and hopefully helping to capture real-time responses and behavior from the target's users and equipment. Gray box testing, as may seem obvious, falls somewhere in the middle, and therefore we may have varying levels of information and disclosure to different portions of the target and the team operating it. In the case of a Gray box test, we may be able to narrow down our early phase efforts to merely fill out the picture.
The type of test and the requirements of the customer will dictate which tools we actually need. If we can apply our requirements to the Penetration test Kill Chain, it will assist us in staying focused and efficient. Unnecessary activities waste our time and the customer's money, but they can also generate noise that may give us away. If this is a black box test, getting caught would be bad for a couple of reasons. Some customers may allow it to continue, but in those where we are conducting Red Team operations (mock attacks, rather than focused project-based testing), our reputation may suffer and we won't be working in this field for long. The customers are the ones who miss out, however - they come away from the engagement without being truly tested, and as a result, they have wasted their funding and leave without a true understanding of their security posture and vulnerabilities. They may even mistake our failures for a false sense of security that prevents them from moving to improve their architecture and continually pursue a secure environment.
Addition of non-standard tools to arsenal
Even though Kali Linux comes with a ton of security tools that can be installed via the metapackages, there are some other useful tools outside of those packages we may need to install to perform the various phases covered in this book. Some of these tools may not be required for every task, and some of them may be similar to other security tools that we may already be using, but we wanted to list the tools that we used for a good starting point. All these tools were installed using apt-get or wget on the command line via a terminal.
Here is the list of the security/utility tools outside of the Kali distribution that we will be installing and discussing in this book as part of our Raspberry Pi arsenal. They are in no particular order:
- xRDP: A xRDP is an open source Remote Desktop Protocol (RDP) server that will accept RDP connections from any RDP client, such as Microsoft's Remote Desktop Client.
- tightVNC: A tightVNC is a Virtual Network Computing (VNC) application that allows us to connect to the Raspberry Pi using a VNC client to the VNC server and provides us with a remote desktop that we can manage.
- Responder: The Responder is a Link-Local Multicast Name Resolution (LLMNR), Netbios Name Service (NBT-NS), and MDNS poisoner, with a built-in rogue authentication server for a number of protocols.
- gparted: A gparted is a graphical utility for partitioning the local disk.
- openSSH: The openSSH allows us to connect to the Raspberry Pi securely using a SSH client.
- stunnel4: The stunnel is a proxy between and client and server utilizing TLS.
- squid: A squid is a caching proxy that we used to test our stunnel configuration.
- Driftnet: The Driftnet is a utility used to sniff various image types. The audio and MPEG4 images and display them on the terminal.
- sslstrip: A sslstrip is a tool that proxies HTTPS connections and sends them as HTTP to the client. This way, items such as credentials can be taken using tcpdump, since they will be in clear text.
- Easy-creds: This leverages other security tools to obtain credentials.
- gedit: The gedit is a GNU Network Object Model Environment (GNOME)-based text editor.
- proxychains: This is a tool that forces TCP connections through a proxy.
- imageMagick: This is a tool for displaying, converting, and editing images.
- shutter: A shutter is a screenshot tool.
- zip: This is an archiving tool for Linux.
- File roller: A file roller is an archive manager.
- snort: A snort is an open source network intrusion prevention and detection system (IPS/IDS).
Positioning the Pi
Where to position our Raspberry Pi for penetration testing also depends on what type of test we are trying to conduct. If we are an internal assessor or auditor testing our own corporate network in a white box penetration test, then we don't have to worry about someone finding our Raspberry Pi and blowing the whole operation. Black box testing is another story - we will want to carefully consider the risks versus the benefits of placing the Raspberry Pi inside the target.
Remember, our main goal here is to test portions of the target's network to see how effectivly their current security controls are working. We can provide or recommend a remediation plan based on those tests that helps the customer fix any vulnerabilities/security holes that may exist. This way, any issues that we find can then be fixed before someone we don't trust finds these same issues and exploits them. Our ultimate goal is to help our customers protect network availability and their precious information, whether it is Personally Identifying Information (PII), credit card information, or propriety company secrets. We want to position our Raspberry Pi in the portions of the network that best suits what our tests are trying to accomplish. Generally, those positions are as follows:
- Outside the network: If we are starting outside, we are normally testing as if we are an external threat trying to gain access from the outside of the target network in. Here, we are going to try and get through the edge security defenses (through a known exploit, weak Firewall ruleset, and so on) to gain access to the network. Alternatively, we may be trying to exploit a publicly available service or website to gain access to that treasured data. Sometimes this is a black hat exercise, but most of the major compliance entities, such as PCI, require external penetration tests to be done on the target environment to make sure these vulnerable services are not publicly facing, and these variants may be white hat in nature.
- Inside the network: The placement here may be required in part of a white hat test, but black hat testing may depend on sustained presence here, and the challenge of getting our Raspberry Pi into a good vantage point without being detected can be substantial. Sometimes there is no substitute for being there, and when it comes to some of the later phases in the Penetration test Kill Chain, it will be essential to have insiders (Raspberry Pi or converted target zombies) to launch those attacks. We'll also have to consider the communications with the insider boxes.
Tip
We should ensure we are documenting all steps throughout the test, including how we decided upon the placement of the devices and subsequent insertion. This will assist in developing our report, as well as...
