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?
Have you run Nmap.exe ever? If yes, you are a fully qualified security expert.
Seriously, nmap should let you find an unpatched internet facing system. Then you have a vulnerability to point at. Instant cred.
Enough for you to learn while being paid.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
At 30?
You're young.
Do whatever you want.
If you a sysadmin have to ask that question, and as you say lacking in network skill, are you the most appropriate for that role?
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.
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?
Learn to program, learn to hack. There are resources available for both. It will take years and it's hard work, but without that, you'll just be another consultant following a script.
If you're not willing to take time and work hard, then yes, you are beyond hope for reaching this goal. Your best option in that case is to continue your current career path and just enjoy what you can of life.
"First they came for the slanderers and i said nothing."
I think penetration testing requires pretty good programming skills, particularly low level type stuff.
Not really. Running Metasploit doesn't require any programming skills. Writing your own tools, on the other hand, would.
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.
If you do, take SANS 560. It's a good start, helps provide a framework, and fills in gaps in your knowledge.
If you don't have funding, why bother (for your company - since you'll be making them more money).
However, I'd recommend doing it on your own - learning is always good. But if your company won't fund your education, you shouldn't put in all that work to do it for them. If they will let you learn on company time, then, that's a different discussion (but that means part of your 40 hours will be dedicated to learning and breaking shit). And it will take months to get up to speed, since you won't have a mentor to help point things out to you.
Ethical Hacker and all those other cheap certs are worthless. Books can be useful, but again, sometimes you need someone to point out the pitfalls, etc.
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)
Ignore them people saying your lack of programming "freshness" is a barrier. You could be the best/most productive programmer around here and still have no clue where to start digging for useful, relevant exploits you could abuse in any particular system you seem to be an expert in.
With that said, what you want to do is get yourself involved in the latest articles about zero day exploits, trojan horses, patch fixes, heartbleed, so on a so forth. You can get started right here on slashdot: any single search of one of those keywords will point you to news about a known issue, then it probably links to specifics of such issue. Eventually they lead to techniques used, be them SQL/packet injections, memory exploits, privilege escalation. With this you get the basics on the WHY and the HOW things are happening. When you start reaching outside of /. and to the less known technologies fixing flaws constantly, and you get a very good idea of the WHEN of such events - every single day!
Now what you have to do is pick a system you want to test. Familiarize with its architectural patterns, integration with internal and external components, the system it resides in (including hardware/software), but specifically it's use of memory, it's use of the OS APIs, etc. Do this until you get a feel of something fragile. The smell of weakness is usually an exploit waiting to happen. Then you will probably hit a lot of walls.
Also, remember that most exploits come in the form of an actual feature. Change your mindset to something like "if this can be used for good, it can be used for something not that good". That also works your way when you want to have your way with a specific technology.
When it's not a feature that reeks of bad engineering, the only thing left are bugs. But you can't look at bugs in the closed source, black-box environment most technologies you would want to test come packaged in. So find integration bugs: IPC, external interfaces, dependencies can usually be abused with heavy load, injections and whatnot, to induce unexpected behavior.
SANS training is pretty good, if you have the money (or can get work to pay for it). They start at the very basics and go up to advanced pen testing, reversing, etc.
Offensive Security has some good free tutorials and paid training, including lab work, for their OSCP/OSCE series of certifications.
Skip the CEH. I don't know anyone who takes that seriously, even if they have one. It's basically just an expensive way to prove you know netcat.
It's already started, but you could try 'Software Security' from the University of Maryland: https://www.coursera.org/cours.... At least it gives a solid foundation.
Not really. Running Metasploit doesn't require any programming skills. Writing your own tools, on the other hand, would.
Yeah, pen testing, per se, can be scripted. It's what you do about it next that's usually part of the service.
The other day I found a security problem due to the way the linux and BSD kernels handle ARP in different circumstances, and the interaction there created an attack surface. If the guy doesn't know much about networks, he's going to have a hard time of getting into the nitty-gritty.
There are good reasons to invest the time into making a career switch. Being great at network security isn't just something that gets bolted on (though plenty of training outfits will throw you a cert if you pay them for a two week class).
His best option may well be to pass up the opportunity, if this isn't his passion.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
You have limitations. Bad. You're aware of them. Good. Better than good, top quartile.
When you put the scare quotes round "new department" is that meant to imply that you're expected to do it all yourself? Hoping that's not the case, then the question comes down to what kind of person to recruit. If you're a Rolls, find a Royce. You'll get some management experience if nothing else.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
That is false. I am a good programmer and have self studied operatings systems, mathematics, low and high level languagesl, algorithms and data structures. I started a few years back when I finally figured out that nobody is going to pay me because I'm smart and good looking... You absolutely can have a career in writing good software without ever having done it outside the context of studying save for money. It's a function of aptitude, knowledge and experience. Having it as a hobby may correlate well with those inputs but it sure is necessary (or necessarily sufficient). It's actually a trade-off in some cases. The way I see it that learning by doing gives a different type of knowledge than learning from a book. I could have hobbied my way into developing Django applications but that would have cost the books I read on networking. I could pick Django up more easily on the job than I could the low-level stuff. Same for learning C or C++ or Assembler -- I don't know if I will ever use them but I do know that it opened up doors of learning and perhaps doing that would be closed to me had I spent the time hobbying together some app, a better one of which I could just download, using some higher level tool. The Job required I learn Java and Swing and so I picked up a book and learned during a lunch hour (I was working support at the time). The more deep and broad your basic knowledge is, the more areas you can pinpoint on when the time comes.
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.
But seriously, this is one of the BEST ways to start learning pen testing, all the tools you need in one place.
Install it and start testing on your own home network first to learn the ins/outs and to see how secure YOUR network is. Then, maybe get permission to run it at work with your boss that suggested you get into this.
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
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.
That's right. Pen testers *could* have all those skills, and perhaps you want to hire that level of professional if you need solid gold security, but those people are usually researching new threats, not taking their time setting up testing for a stream of customers.
Most pen testers are there to fulfill pen test requirements in standards like PCI where something like Metasploit would be a sufficient "best effort", and actually pretty decent if you have someone who really knows how to use it. Companies aren't expecting to be 100% secure against the latest custom threat, they just don't want to be taken down by exploits that everyone already knows about where you could legitimately hold the company responsible for not doing due diligence.
Let's face it, we all know that if an intelligence agency, or some very, very good cracker is attacking you with custom code against stuff they discovered through long research or genius level skills, they're going to get in if there is any hole at all. And there almost always is. It's just that those sorts of people don't attack your run of the mill organization. The money in cracking systems is in volume, so unless you are a very, very special snowflake or very, very unlucky, you just accept the risk of the elite cracker and close the many, many vulnerabilities that we do know about. That keeps out the kiddies and the petty criminals, which is your pool of most likely attackers.
From TFA 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
Does not appear to be internal testing from internal IPs that is the question now does it?
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
You have no idea what you're talking about. And yes, I could say that more nicely, but that doesn't make your statement any less uninformed.
Yes, programming skills CAN be a bonus. A bonus. Not a requirement. Some of the best security people I know have a rather superficial knowledge of programming. Mostly, what you need is a way to automatize tasks. Python is the tool of choice today. And you hardly need any programming skills to use that.
Forget stuff like x86 assembler. Seriously. Forget it. Most of the stuff you'll be doing is analyzing web applications where you either don't get anything that could be analyzed or where you get the source code. Yes, that's the two extremes you're dealing with. The few fat clients you will analyze will be written in Java or C#, and for both there are FAR, FAR better ways for analysis than disassembling.
Networking, yes. Networking is your bread and butter and you should know a LOT about it. But writing networking yourself? Please. What you will be dealing with is the intimate details of the HTTP and SSH (and of course their combination). If you can deal with this, you have 99% of the bases covered. It can't hurt if you know a bit about the general working of TCP (you should know about the handshake, and I'm not talking about the secret handshake to get into the conferences).
SQL databases... while it can be a bonus to know how to set them up, what you really need is to know how to inject exploits into queries. That's a neat trick for a few quick wins where you can show off to prospective clients. But in general that topic is fading quickly. They caught on. They use stored procedures and prepared statements now. Injections, while still fun and profitable, are sinking on the Top 10 quickly.
Unix, forget it. Linux, yes, as a toolbox. You don't need to get intimate knowledge of the kernel's quirks (though it does not hurt), but what you really need to learn inside and out is the IP stack. You want to know how to route ANY kind of traffic through your box and force ANY kind of app to use your box as a proxy, preferably one that can even crack pinned certificates. Yes, that's useful. And for that, you will want Linux, and you will want a few assorted tools that make such things possible.
nmap, metasploit, nessus, nikto, sslyze, ... the list is near endless. Yes, you should know them. Yes, you should know how to use them. But they are tools. They are not the ends, they are the means. You don't really need any of them, but they make your life a LOT easier (and your analysis affordable, after all you will be under quite a bit of time constraint when doing your tests, customers rarely want to pay you a month just to take a look at their crappy webshop).
In conclusion, what you list there reminds me of the old "how to become a hacker" meme that was circulating the net a while ago. I don't want to claim it was a hoax, since I don't know what it was like a quarter of a century ago. But the time has moved on and the trade has evolved. Tools exist today that have not existed back then. Attack vectors exist today that nobody considered back then. And at the same time, attack vectors vanished that were very real back then. It's cute, it's funny, it's exciting to think that there's a "crib sheet" on "how to become a hacker". There isn't. There are a few core skills that are important. Are. Now. Today. Whether they are in 3 months, I have no idea. 10 years ago I would have agreed with the Assembler bit, but time moved on and nearly all commercial software today is written in C#, and you don't disassemble that. There are better tools to use here. And 20 years ago being a crack C coder was crucial because there were no good tools, and if there were, you would not get your hands onto them. You needed to be able to write your own. Not anymore.
So please. I know it's tempting to butt in whenever one thinks they know a little bit about a topic but sometimes ... sometimes it's just better to not claim that you do. Especially if there are people really asking for advice, advice that may well shape their future careers. And bluntly, if someone followed that "list to hackerdom", at the end he'd mostly be 15 months older.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
Am I beyond hope?
Yes.
But not because you lack technical skills, those can be learnt. You're seriously working for a boss who thinks that he can turn a sysadmin into the head of a pentesting department by telling him to make it happen?
There's a lot that goes into a good pentest, and a reason that there are entire companies staffed with people who do essentially just that. It's not something you learn with a book on a few weekends. If your boss doesn't understand that, the result will be a disaster. And we already have too many people out there selling the printout of a Nessus scan as a penetration test.
What other comments said is spot on. Your boss needs to hire an experienced pentester, period. If he doesn't want to do that, there's no chance you'll be heading a pentesting department anytime soon.
Assorted stuff I do sometimes: Lemuria.org
Have you considered offering PCI Compliance rather than pen testing? While there are guidelines its a lot easier of an industry to break into without prior experience. A good pentesting service can test a really wide variety of things - a company that I used to work for would not only do the standard scans/attacks with ~40 different commercial and free tools, but also social engineering tests, mailing people usb sticks with autorun exploits, and stuff like that. I didn't get the specifics, just kind of the vague outline. While it's def not impossible to get into that, its something you should def do professionally before offering it as a service. Either way, PCI Compliance testing is like a watered down pentest, in which you're not actually supposed to break into anything. It also has a really wide variety of much smaller customers that are required to have it performed for various payment industry related reasons. A PCI scan can be anything from a half-arsed SAINT scan with minor notations, to a fairly comprehensive set of manually verified tests for things like SQL injections and XSS vectors.
Well, speaking as a professional "information security consultant" (who, on occasion, uses nmap and even more-destructive tools against clients), I guarantee you that mutually acceptable employment terms which permit and even expect the use of such tools is what has been paying my very comfortable standard of living for the past few years. From tiny companies that have a mobile app to supplement their primary business, to "stealth mode" silicon valley startups, to healthcare-related companies that are paranoid about leaking info, to huge financial firms (ugh, avoid those), to colossi of the computer/software/cloud industry, I've worked all kinds of places.
Of course, it helps that I'm employed by a company with an excellent reputation. Very little of my work actually involves automated tools; I will run them (unless the client asks not to, which is uncommon) because there's no reason not to, but that's not what they pay me for. My job is to find the stuff that the tools won't, like XSS in an optional parameter that you'll never see used while spidering a site, or exploitable race conditions in a driver when you send the right pair of IOCTLs in close succession, or... you get the idea. Yes, it takes longer, and yes, it costs more that hiring some script kiddie (or telling your sysadmin to turn into one), but it's worth it in the end.
There's no place I could be, since I've found Serenity...
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...