I am embarrassed at how late to the game I am on this. SSL has been a staple in web security for years, and I am sad to admit that I have just now finally gotten an SSL on my website. Okay so how easy was it? SUPER EASY! Check out Certbot, and get an SSL on your website for free, today!
I get asked this question a lot, sometimes by clients, sometimes by friends, but most often times by individuals who really have an interest in network penetration testing. The question is a simple one, but can often times take many forms…
How do I secure my network?
How do I break into a network?
How do I mitigate the risk to my company?
(and my personal favorite:)
How do I hack?
In this post, I am going to take dip into the shallows of network penetration testing, and try to elaborate on the not-so-secret-sauce that is network penetration testing, starting from the beginning, and drifting into the mid to late stages of a network penetration test. Unfortunately, there is no comprehensive checklist for fully completing a network engagement, because every network is a unique and precious snowflake, and until Darpa releases the blow torch they’ve been working on, we’ll have to use our smarts to break stuff. So this brings me to my first topic…
The first step in being a successful network penetration tester is knowing everything there is to know about everything ever. Sound good? No? Okay, well, then lets start a bit more focused. There are a few basic concepts you can start with in being a successful network penetration tester.
A good network pentester is more than the sum of their exploits. Though I don’t have exact numbers for the industry, I can say that a good 90% of my engagements are successful because I identify gaps in business logic or misconfigurations in the systems. For example, knowing that networking equipment should be managed from a different subnet than the user space is key. There may not be a direct exploit there, but taking over a network admin’s machine and accessing networking equipment is far more likely if the management consoles for the equipment are on the same subnet. This is also an indication that the organizations security posture is not nearly as high as it should be. I tend to check for a lot lower hanging fruit when I find this, such as password reuse in systems, lack of 2 factor authentication, and lack of key usage system authentication. This lack of network segmentation is a huge red flag to me, and is actually a great finding for your report. This is just one example, but there are many more out there.
TL;DR – Learn how to properly network.
But Also Exploit
Remember how I said you need to bring more than just sick ‘sploits to a network engagement to be successful? Okay great. But also bring sick ‘sploits. Privilege escalation is much easier with exploits (though finding a misconfigured SUID binary or Windows Scheduled Task is pretty common too). Gaining a foothold into a system using an exploit might not be very obvious or common these days, but you aren’t there to find the common or obvious stuff. Hell, a scanner can do that. The most successful exploits I’ve used have been those that have been identified and released more recently. You might find MS08-067, but its more likely you will find Shellshock. Keep up to date by signing up for the Full Disclosure mailing list, and just keeping up to date with security news in general. /r/netsec is a good place to do so as well.
TL;DR – Also use exploits.
Learn To App Pentest
There exists this strange line in the sand that exists between app pentesters and network pentesters. I dont get it. Maybe its because I was a developer for 5+ years as well as a network/system admin. In any case, you will remove approximately (my estimation, not industry standard) 50% of your attack surface if you disregard applications; especially home brew applications. Internal apps are fantastic resources that are often time custom tailored specifically to give an attacker as much control as necessary in a network. They are (often times) not hardened, not QA’d, thrown together in 5 minutes by some customer service agent who took his first intro to PHP class and wants to make his job easier, have little to no deployment standards, and are not maintained. They also are probably not scanned. You don’t need to be a pro at app pentesting to get good findings. You are not concerned if their cookies are insecurely scoped, or if they are vulnerable to DOM based XSS. You care about file upload points, exposed admin interfaces, services running as root.
TL;DR – Test the apps too, they are your friends!
Great Beginning Resources
So a few resources I’ve found to be absolutely fantabulous when it comes to pentesting…
- Georgia Wiedman’s Hands On Introduction to Penetration Testing
- I don’t think I can overstate how amazing this book is. It does an amazing job of breaking down vulnerability classes into easy to consume, hands on tutorials. I could try to rewrite this book inside this blog post, but I’d fail, because her book is fantastic.
- g0tmilk’s Basic Linux Privilege Escalation
- Not gonna lie, I keep this link handy for all engagements. It acts as a checklist of sorts to ensure that I have crossed all my T’s and dotted all my I’s when trying to escalate privileges.
- Fuzzy Security’s Windows Privilege Escalation
- Same as g0tmilk’s blog post, but for Windows. I keep it handy, and it has served me well in the past.
- Offensive Security Certified Professional Course (PWK)
- Not only is this the most fun I’ve had with a security course, but its incredibly important to get real hands on experience when training to do network pentests. The lab is a 50 server CTF game with multiple subnets and hundreds of different exploits. The final exam is also a blast.
- SANS Training
- I’m a big fan of SANS. I was fortunate enough to have an employer who not only footed the $6000 bill, but when I won 1st place at SANS Netwars (their CTF game), they flew me out to the Netwars Tournament of Champions to compete on behalf of the company (I took 5th). As of writing this post, I am currently GPPA, GPEN, and GPXN certified.
- DVWA – Damn Vulnerable Web App
- This is a web app aimed at teaching soon-to-be hackers about web application vulnerabilities. Throw it on a VM and go to town.
- So I point people to Vulnhub all the time, and I try to stress as much as I can that you need to download the VM, and then go through a walkthrough! It isnt cheating! These VM’s do not have ‘courses’, and if you are new to pentesting, you will be lost trying to crack one on your own. Take down the VM with the help of a walkthrough and learn some lessons from it; dont idly follow the commands in the walkthrough. If you don’t know something, Google it.
TL;DR – There are a lot of great resources out there for beginner pentesters.
The Engagement Itself
So now that you are brilliant and have mastered all things network pentest, you can finally start a real network engagement! To be completely honest, this section will be super short. Its going to be a list of ‘nice to haves’ to ask a client for prior to the engagement, followed by a few reminders for the engagement itself. The content above should inform you exactly how to start and work through the pentest, so I wont reiterate that.
Need To Have’s
These are the things you will absolutely need for every engagement. Some may be more obvious than others…
- You need to know what you are attacking. Usually a subnet will do fine for internals, or a set of IP’s for externals. Don’t accept domains, as these can resolve to IP’s that aren’t expected and cause weird issues.
- This sounds strange, but its very important. If you perform tests on something without permission, thats illegal. Its a federal crime. The permission has to come from the infrastructure owner, which may not always be the same as your client. If your client hosts systems in AWS, the owner is Amazon. I’ve done a good amount of work with AWS and they have a great system setup to confirm and allow pentests.
- Figure out what’s important to them, because it’s probably not the same as what’s important to you.
- Some clients will say “oh, you know, just tell us everything thats wrong.” This is bad. You might fine some sick zero day in McAfee’s HIPS application, and it will get you tons of hacker cred, a CVE with your name on it, and even a Defcon talk, but if the client only runs the HIPS on one system, it has little to no impact for them.
- Remember that you are on the client’s side. You want to help their organization increase their security posture.
- Don’t try to embarrass them.
- Help them accomplish their goals too.
- They may really need another body in security. Try to write up your findings in a way that helps the client go to their higher ups and say “Well, if we had another security engineer, we could address all of these”
- The best value you can add as a network pentester is to make the longest lasting change you can. Clients will remember who to call when get need to get shit done.
- Point of technical escalation. The last thing you need is to break something in production and cause long periods of outages. Remember how clients remember who to call when they need to get shit done? They also remember who breaks shit.
Nice To Have’s
Whenever I start a network engagement, I always ask for these things. Sometimes I get them, sometimes I don’t.
- Network diagrams. Some younger companies won’t have these. In fact, they may ask you to create them based on your host discovery. Its okay to offer some help here. After all, if you write up improper network segmentation, you’re basically going to be doing this anyways.
- Any known vulnerabilities. This isn’t cheating. This is simply an acknowledgement between yourself and the client that this test is a time limited engagement, and asking for information that an attacker could obtain if they had unlimited time within the network. Its a way to move things along, really.
- Accounts. Same as above, this is a way to help get around the fact that you have a limited amount of time and provide the most value you can in the engagement.
- Anything else you should know? When you are negotiating, sometimes the most impactful tool you can use is silence. Same with information gathering. I recently went onsite with a client and sat with their developers. The developers walked me through the applications and gave me the rundown of the code. Right before the meeting ended, I asked “Is there anything I should know about the app that you haven’t told me?”, then I sat there quietly. After a moment of silence, they broke down and spilled at least three vulnerabilities that they knew existed in the code, and told me exactly what code had been tested and what hadn’t. It was glorious and lead to an extremely successful engagement, including server compromise and the compromise of all user information.
When you’re on an engagement, you just need to keep a few things in mind.
- Keep things civil. Some clients will be apprehensive of a pentest. Remember, you basically got brought in to tell them their baby is ugly. Do it respectfully and constructively.
- You are the expert. Act like the expert. I’m not saying spout off whatever random trivia you have about security. I’m saying you need to present yourself in a manner which instills confidence. Your presence can have a large impact on an organization. A consulting firm I worked for once had a contract to perform a security assessment on a company who was being purchased by another company. The result of the security assessment alone stopped a multi-billion dollar merger from occurring. Remember, with great power comes great responsibility.
- One goal: Get rehired. Okay, so some people may disagree with this, but let me explain. If you go on an engagement, fully fulfill all of your goals, help your client fulfill their goals, gain the respect of the technical staff, and become a trusted advisor for all security needs, the client will rehire you when they need you. You need to do all of those things. So maybe the goal should be “leave in a position where the client will rehire you if they need you”, but thats just a bit wordy.
Thats A Wrap!
I really hope this helps new pentesters figure out where to begin and how to advance in their goals of becoming a full fledged expert in security. I wish you the best in your hacking adventures!
So as I continue growing in my security career, I feel like it is a milestone in every IT security professional when they begin to create and share their ideas, techniques and knowledge through the creation and maintenance of a blog that no one will ever read.
This is mine.
I hope to share my own personal experiences, opinions and insight, and who knows, maybe someone will stumble upon my blog in a google search for some strange, esoteric problem that I have struggled with myself, and found the answer to. In the illustrated words of the great XKCD comics: