Slashdot Mirror
Ask Slashdot - Breaking Into Penetration Testing At 30
An anonymous reader writes I currently work for a small IT MPS in the Southern USA. Recently, my boss approached me about offering security evaluation and penetration testing to customers in our area due to the increasing number of regulations companies area are having to meet. My role in the company is that of a proactive systems administrator. I have strong troubleshooting skills, a moderate knowledge of Linux, and a strong grasp on Windows systems. My working knowledge of networks is a bit rusty, but I've started working on my CCNA again, and skill/knowledge of any kind of programming language is extremely lacking as I have slacked off in that department. However, I've been working with Powershell scripting, and have picked up some resources on Python. Where would a guy like me start? What can I do, as far as personal development, to give me a shot at building this "new department" within my company? Am I beyond hope?
At 30?
You're young.
Do whatever you want.
If you don't know where to start, try something like Kali. Have a play around with Metasploit as well.
Get certified.
>> my boss approached me about offering security evaluation and penetration testing to customers in our area
Because it might at least mitigate the damage after your company get sued by customers who get hacked after you tried to learn on their dime. (Google "Target Trustwave"...)
Seriously, if there's a real business opportunity in your market, your management should either hire an experienced guy/gal and/or partner with an existing firm. Then, you'd have the opportunity to learn along them...while picking up the certs you'll need to be credible when talking to other companies. (And if your management is too cheap to buy your security certs, that's a BIG red flag!)
...sez Anonymous Cosby.
Momentarily, the need for the construction of new light will no longer exist.
One thing you need to keep in mind is that Penetration Testing isn't just about the technical aspects. You need to be up to speed on all the legal aspects, not just in terms of know what laws govern the particular industry/company you happen to be conducting a test for, but in terms of liability. You really don't want to wind up finding yourself accused of breaking the law, whether state or federal, in the course of your job - and without a degree of caution, that's certainly not an impossible thing.
Remember, most of what gets done in any penetration test worth a damn would otherwise be illegal on any number of levels if you were doing it without the express authorization of the owner of those systems. Make sure you know what you're doing, and that the lawyers sign off on it first so that your company is covering your butt if anything goes bad.
http://www.cybrary.it/course/advanced-penetration-testing/
Your employer is going to be held liable/accountable if you miss a glaring hole in their information security infrastructure. I'm not saying you can't train to do this but I don't necessarily know that it's the kind of thing you can pick-up on the side or over a few weekends. I've dabbled in security over the years, am very familiar with *nix, worked in infrastructure as a sysadmin, am a fulltime well paid programmer and I am familiar with the variety of tools out there and I wouldn't consider myself for a role like this one. Too much risk.
I think penetration testing requires pretty good programming skills, particularly low level type stuff.
The fact that you have not maintained any programming skills suggests that it is not something which interests you sufficiently to pursue it in your free time. I am skeptical that a person without an intense curiosity to understand how systems work at a low (i.e., code and assembly level) would find the motivation to develop the necessary programming skills and reverse engineering know-how to discover holes in systems.
But perhaps I am wrong and these skills are not required to be a successful penetration tester.
Why would it? Pen testers jobs are not to write vulnerabilities. True, someone who knows how to write vulns will make a pretty good pen tester, but you don't need to know how to refine petroleum to be good at pumping gas. A basic pen tester needs these skills (in this order): 1) knowledge of current vulns across a wide variety of platforms, and a channel to keep up to date on the latest new vulns that come out, 2) knowledge of how to find if a vuln is present across a variety of platforms, using methods that don't involve "just give me root so i can check your versions" and 3) knowledge of how to actually run some/all of the exploits when the customer looks at your report of 13 high risk issues in disbelief.
To be a great pen tester you need one of two skills: programming knowledge to put together unique exploits on the fly, or diverse systems knowledge to know how to multiply existing vulns (exploit, pivot, repeat) in order to move from system to system.
I would say look at a cert like Offensive Security Certified Professional (Penetration testing with Backtracks) It's been a while since I did the curriculum I think it was worth it and learned a lot.
Hi, I work in the general cyber security industry. I would advise against heading this type of project given your current lack of experience. Penetration testing largely involves running scripts and tools that are mostly automated, and then interpreting the results to determine how to proceed (running the scripts and tools again but against a more well defined target) and repeating until you are in. That is one part of it. A second part is analyzing a company's complete security posture, this involves more than the technical systems, it involves the people that run/maintain/protect the technical systems and analyzing how well they do (or dont) do that (how easy they fall victim to social engineering, who has a level of access that is unwarranted, where the weak points are in terms of people/policy/implementation, etc.
I would not go into this with little previous experience. I would definitely hire someone with experience to be a part of this before proceeding.
Now, on to learning. If you want to be competent in cyber security, you should know the following (this is my opinion, don't take this is gospel, compare my suggestions to others):
Networking. Be intimately familiary with layers 1-4 of the stack. Know all aspects of TCP/IP (V4, V6 is still not widespread and will not be too hard to learn if you master V4). All aspects, not the basics, this is a necessity. You will not be able to identify that one odd TCP packet with a weird flags set or the malformed DNS request if you don't know what a normal TCP packet looks like.
As a test, answer this question with an essay: "What happens when I open up a browser and type google.com and hit enter." (assume all caches are flushed on all devices, your own equipment and the network equipment you are traversing). If your answer is not very long, then you most likely are missing some of the interactions that took place)
Tools. You need to know tools for analyzing network traffric, and diving deep into network traffic. Wireshark is one of the most popular programs for inspecting pcaps, get very familiar with this tool. Learn how to do the same sort of searching and poking about you do in wireshark with command line tools. Learn what BPF's are. Most useful security tools are *nix based. You absolutely need to become at least comfortable with operating out of the *nix command line (no gui) and know basic *nix tools. There is no way around this.
Knowledge of python and shell scripting has been very helpful to me. You do not necessarily need to know how to program in python or in the shell script of your choice (though it helps bunches) but you do need at a minimum to be able to read and figure out what code is doing, and to make minor modifications to get programs to do what you need.
Hacking. You need to know how hacking takes place. Not at the script-kiddie level of "run this and the system is hacked" but closer to the hardware level. Know how different hack attacks work, know what features or lack of features of the hardware/OS (things like DEP, ASLR, protectected memory pages/ring 0-3, userspace vs kernelspace) make the hacks even possible (buffer overflow, stack smashing, heap sprays, unsanitized inputs, etc). This requires some understanding of computer architectures.
Become familiar with internet RFCs. Know what the popular options are for intrusion detection. Learn how to read snort signatures since there are many of them (when I say learn to read the snort sig, that means you can take a snort signature,understand what it is trying to detect, and then be able to write a rule or signature based off of that in whatever IDS system you are using, if you have something different/in addition to snort).
Read alot. Do whatever work in the field you can. Learn. Don't stop learning, because the adversaries are not, and your intimate knowledge of computer security Circa 2014 is not going to protect you or your organization from the new hacks happening now. (lots of hacks are recycled and reused long after they have been patched/mitigated (due to poor patch managment/security procedudes), so knowing what was happening in previous years does help alot, but still never stop learning)
What parent said. Infosec, despite pretending to be this invite only club for h4x0rr k1dz 0n1y is anything but. Just get your cert (OWASP+CISP) and you're good to go. Literally just script kiddy stuff, ./metasploit and ./nmap and shitton of standardised process/good practice stuff.
Most of actual h4x0rs are too much of primadonas to ever get employed and (somewhat rightfuly) despise certs as corporate snake oil. Still, having a sysadmin certed to have at least vague idea about keeping boxes patched/default passwords of appliances changed/not exposed open is a good thing.
And this is why there are a ton of shitty 'pentesters' out there who seem to mistake running nessus or nmap scripts as a penetration test. No, it's not 'secret' knowledge and can easily be learned if want to spend the time but running metasploit doesn't make you a pentester.
Like defenders, pentesters generally need to find all the vulnerabilities (sadly many customers accept the first one which ends up being a scoping issue) and understand how to mitigate anything that was discovered/exploited. That requires an understanding of protocols, networking, applications, web frameworks, etc.. I have found that the best tend to have the capacity to think maliciously. IMO, that is a critical skill. I have seen far too many people that just don't understand why anyone would want to abuse a protocol, which makes them substandard pentesters.
As for the original question, there are plenty of tools out there that can help you learn. Metasploitable, WebGoat, Kali, SamuraiWTF (disclosure, I am good friends with the lead for that), ZAP, Burp Suite (pro is great and super reasonable). If you have corporate funding, there are some decent trainings out there Offensive Security has their classes (and certs, I have heard mixed results). There is also SANS, which I have been increasing disappointed with but if you want a bunch of knowledge shoved in your head (at a pretty high dollar cost), they tend to do it. Also, some drift more towards network pentesting or application, personally, I think people should be versed in both (leveraging a remote code execution bug in a webserver is great unless you have no clue what to do within the OS).
For cheaper options there are bunch of books that can teach you a ton of 'tips and tricks' around pentesting (web Hackers Handbook 2nd Edition is particularly good). Having a solid background as a sysadmin makes it much easier IMO (my background is similar), since you are most likely familiar with troubleshooting, networking, multiple OS's and what not.
Probably the most important thing is to have the mindset for penetration testing.
You are no longer trying to keep things up and running, and making systems usable; you are looking for all of the ways to make things break in new and interesting ways. You have to think creatively - you have to think about what the system/network admin missed and/or how "best practices" fail in a given situation/on a specific system.
That's why a deep technical understanding in a lot of areas is very helpful - you learn how things interact, and how failures can occur in different areas. For example, does a software package add a user? Does it open a network port? How does it handle permissions? How is authentication done? How do systems rely on the network? How does the network rely on various systems (like a DNS server)? The more you know about all of the interactions between the system(s) and the network, the more attack vectors you can come up with.
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
> leveraging a remote code execution bug in a webserver is great unless you have no clue what to do within the OS
Time for a car analogy.... because otherwise you are like a carjacker who can't drive stick.
"I opened my eyes, and everything went dark again"
The software industry just isn't a place for changing direction or starting new things. I mean, come on - learning a new skill is disloyal to the older skills. If everyone just learned things willy-nilly, who would sort the punch cards anymore?
Just keep your head down - you probably only have 2 or 3 more good typing years left before you're too old to sit up or retain bowel control.
It's useless to learn pen testing... unless you also learn "pen fixing".
It's totally useless to know that there are problems there, but now how to fix them.
It's like going to a doctor, they tell you they have bad news and good news. The bad news is that you have cancer. The good news is that they scored 5 under par during their last round of golf. The second piece of information doesn't help resolve the first one. Unless you treat any disease you find, you haven't helped them, you've only made them feel like crap about something they can't do anything about on their own.
Typically, you want a "defense in depth" strategy, which means firewalls, DMZs, the whole nine yards. But learning how to use script kiddy tools to get in is not going to teach you the skills you are going to need if you want to keep someone else using those same script kiddy tools out.
It takes an almost entirely different mindset, and it does, in fact, take real skills -- almost the same skills you'd need to write those tools yourself, in order to write the code necessary to fix the problem so it can no longer happen. In other words, you not only have to know how the tool is getting in, to keep the tool from getting in. This can require substantial knowledge in systems and network architecture, and, if the way the tool happens to get in is via SQL injection, cross-site scripting, etc., etc., you will likely have to *minimally* know enough about the technology that's being exploited that you can fix it.
This is not the job for a single individual; it's a job for a team of at least several people (if they are incredibly good), or potentially a *lot* of people, if they are individually specialized to the point of being narrowly focussed in being able to go deep in only one or two areas.
The best advice I could give you is advice you are no longer able to take: learn this stuff while you are a minor, and unlikely to be put away for a felony, or learn this stuff prior to the electronic trespass laws going into effect in the mid to late 1980's. Both of these mean you've missed your window on getting a broad base of experience on a lot of disparate systems, of the type you'd be asked to pen test (or subsequently "pen fix").
Unless you are really wealthy - or your company is - and you are able to set up a lot of systems which, when you hack them, there's no risk that you'll end up in jail.
Other than that - there's some training available, but if you want to fix the problems you find, you have to think about systems as a gestalt, and you'll have to learn about networking and at least some types of programming, probably in considerable depth, to make up for your inability to legally acquire breadth, and then hire people to get breadth on your team.
Alternately, realize what I did the first day of kindergarten: I didn't want to go back after the first day "because they would not give me reading, writing, and arithmetic". In other words, this is not knowledge that someone can gift you with, it's knowledge that you'll have to fight to acquire, and it's not going to be easy for you.
I think these days the big security risk is layer 7. SQLi is still very common...especially 2nd order injection and injection into GET parameters. Admins know they need to sanitize POST/update/insert but they miss get/select.
Wordpress is generaly run without htaccess rewrites on WP-plugins..an attacker enumerates your plugins and finds an exploit.
Ive seen get parameters with filenames..oh yes thanks for letting me change that to web.config or ../../etc
Client side filtering is another, equally hilarious issue. As joe mccray says "youre putting the filtering in the hackers browser which he controls...does that pass the common sense test?"
The list goes on and on...its easy to patch everything else. Web apps on the other hand...are often written by the people in charge of the site.
Nikto, BURP as you said; and ZED are faar more useful than metasploit now. Novices just dont know what to do with the info.
And lets not forget sqlmap ;)
Pedantic, but... Writing a vuln is dead easy. Here's one (compile this into a world-executable program with setuid:root):
#include <stdio>
void vulnerable () {
char buf[8];
gets(buf);
}
int main () {
vulnerable();
}
Writing a functional exploit, on the other hand, is a lot trickier, especially with all the exploit mitigation stuff found in modern operating systems (and libraries; some of them won't let you call gets() anymore by default). Fortunately, in my professional experience (4+ years of pentesting, both as part of a company's internal security team and as a security consultant), this is rarely requested. The client may want a PoC on occasion, if they think their stuff can't possibly be vulnerable, but even then it needn't do anything special or be robust across system configurations or anything.
Getting back to the core question: if you're going to be pentesting native code, especially whitebox testing where you are expected to review source code as well, you need to know C/C++, maybe Objective-C, maybe pre-.NET Visual Basic or even things like FORTRAN or COBOL if your client's codebase is old enough. For web apps, you need to know your HTML and JS, but it's also important to know HTTP - yes, the protocol - and browser security features like same-origin policy. For the server side of web stuff, there's a hundred different languages and probably ten times as many frameworks that you might need to know, but for the most part knowing PHP, Java, Ruby, at least one .NET language, and maybe Python is good enough for the vast majority of sites (add perl if you want to go old-school).
Scripting languages like Powershell and Python are actually really useful to a pentester, because you can knock together little utilities to try things out that way. Want to send a carefully crafted sequence of UDP packets, or decrypt all that stuff the client has "protected" with a hardcoded AES key and find their secrets? A few minutes of work will get you a tool that will save you lots of time in the future.
There's no place I could be, since I've found Serenity...