The lowdown and dirty along with the Good, the Bad and the Ugly of what you must know to be a successful Network Security Analyzer a.k.a. Pentester.
The link for this article can be found herein: www.infiltrated.net/pentesting101.html
Step One - Weeks One through Six
This is an introductory eye opener. For these next few weeks, I suggest going through and understanding the OSI layer. Learn how protocols interconnect and communicate. Learn why and how things are the way they currently are. Although many shun the OSI layer, some say it's antiquated, some point to the DoD model, the OSI model is still highly referenced and straight-foward.
You want to not only learn the names of the OSI layer, but you also want to understand how they all behave with one another. You must - and I repeat, MUST - understand every single part of the OSI layer, period. In doing so, the knowledge of it comes in handy across all technical certifications, so if you're planning on going the certification route, this will only benefit you in the long run.
Let's think about this for a second on a realistic level for a pentester. So you're in an interview and someone asks you - "At what layer of the OSI does an SQL injection occur" you will need to know this answer. Now remember, SQL operates on the Session Layer, but is an SQL Injection attack occurring at the Session Layer or at the Application Layer? What layers is it passing through? Understanding the core concepts of it all begins with the OSI model. Regardless if you're taking a test or sitting in an interview, the purpose of needing to know this is - it makes it easy for you to structure an attack, perform an investigation, or perform any kind of analysis.
Recommended reading:
http://tinyurl.com/cehOSIlayer
http://en.wikipedia.org/wiki/OSI_model
Rinse and repeat: The OSI layer is one of the core fundamentals you should know period. This includes studying A+ material. You may not want to take the A+ in fact most say it's worthless, personally I wouldn't bother with the certification however, if you need to know perhaps BIOS information, swapping out disks, analyzing disk information, you will need to understand many of the topics on the A+ level.
Step Two - Weeks Seven through 19
Immerse yourself in learning networking. Learn as much as you can on how networks interconnect, how they do so, what a MAC address is, what is ARP, RARP, how one network connects with another and why. From the LAN level all the way on through. I cannot tell you how many individuals swear they understand the differences between a private LAN and a WAN yet they'll ask "I'm at work (public address), why can't I ping my server at home from work?! The address is 192.168.x.x".
My suggestion would be to grab some of the Cisco books, my order or preference would be as follows with an explanation following:
Cisco Press:
Routing TCP/IP volume I and II
Network Security Architectures
Network Security Fundamentals
Designing for Cisco Internetwork Solutions (CCDA)
So why Cisco Press books, you're not studying for the Cisco exam! The listed books have a wealth of information with regards to the OSI layer (all levels) and explain common concepts and strategies in security. Not to overlook the fact they'll teach you an ample amount of information pertaining to routing and switching. You will need to understand networking heavily in the security arena as computers are (drum roll) networked.
Understanding routing, routing protocols, switching, VLAN's, etc. will definitely help you in the long run whether you realize it or not. You will need to know how a path is taken to get to a targeted machine, you will at some point find yourself wondering why you're solely seeing two servers on a network when you know there are dozens. You will want to understand portions of a packet when doing a sniffer/network analysis. You will need to understand why one protocol might be chosen over another. Overall without a network, there is little to be compromised. Even locally. What would be the purpose of say compromising a machine on a penetration test only to be isolated to that machine simply because you didn't understand what an ARP address was, how to change it, how to spoof it. How to subvert VLAN's.
Again, just because you're not taking a CCxx exam from Cisco, does not mean you shouldn't pick up their books. Plenty of professional engineers have started their careers reading Cisco material without being Cisco certified engineers.
Now the CCDA book will help you understand the concept in designing a network and while you may not care for it - you can learn plenty of information that you can use in the real world. My suggestion is to get the books, study them frequently and understand the core of it all. I suggest checking out a store I use on ebay called Best Bargain Books. I've purchased books for $1.00 (US) and paid about $3.50 on shipping. http://stores.ebay.com/Best-Bargain-Books Also check out the used section at Amazon. Or simply browse Cisco's website.
Do not - repeat - do not skimp on understanding the network. This includes reading RFC's. You should have a keen concept of say RFC1918 and why it's important to understand private and public networks. You should also have a thorough understanding of the different types of IP packets, their codes, errors and structures not to forget you will need a firm grasp on subnetting. The differences between a Class A, B and C network, and no a Class C is not a slash twenty four (/24). If that came as a surprise to you, then you seriously need to go back and read. Understanding subnetting is important as you will need to understand your boundaries when performing say, network assessments.
Step Three - Weeks 19 through 26
You've begun to understand networking and have an understanding of the OSI, now it's time to learn a thing or two about systems... Suggestion... Pick up any distro of Linux or BSD. Head over to distrowatch and select one you think would suit you. Remember, your goal is to understand an operating system and the best way is to do so hands on.
My suggestion would be a variant of Redhat, either Fedora or CentOS. "But Debian so rox0rs!@", "duod my Slackware pwned you!" Distribution zealotry aside, the majority of corporations stick with primarily Redhat followed by SuSE on the Linux end, Free followed by Open on the BSD end, and Fortune xxx corporations tend to go with a mixture of Solaris, HPUX, z/OS, Redhat, etc. based on my experience. No you probably won't be pentesting a Slackware box, nor Ubuntu machine. If you're doing a high level corporate test, you will be testing against those mentioned, I highly doubt you will see Slackware, Puppy Linux or any other of the thousand variants of Linux on the enterprise circuit.
Tinkering with different operating systems will give you hands experience on those operating systems however, this is not real world experience on the corporate side of things. Corporations each differ. Many different technologies are in place, all performing different functions. So why don't I recommend you learn say, JAVA or Assembly here? It's irrelevant for now. Right now, you will want to dive in to operating systems in general. Learn about them from an administrator level. Eventually you WILL also want to learn some form of programming language even at its basic level. Which poison you pick will be up to you. PERL, Python, Ruby, ASM, they all have their roles, pros and cons.
Programming will definitely help you in the pentester (Tiger Team) role and you may not always find an exploit made readily available for something particular. You may be familiar with a program running that you've perhaps seen crash before, act strange, but there is no guarantee you will be able to visit say milw0rm, PacketStorm or other sites and find an available exploit. You may want to whip out a dissassembler, gdb, IDA pro and debug what's going on with that program you have an eye on though. What made the program crash, does it have the potential to have commands written (buffer, stack, heap) via an overflow?
I wouldn't focus so much on tools or even programming right now. I wouldn't even make them a priority at this point as you won't always be in an environment to run certain tools anyway. You're merely familiarizing yourself with the operating system. My personal suggestion, learn the common tools for that system as well as Perl or Python period. If you're working on say a Solaris box, you shouldn't have to wonder what svcadm is. You shouldn't be puzzled at /var/adm and why you never saw it on say Ubuntu. Understand the differences in operating systems and their structures.
The purpose for me conveying to you the need to learn the common core of a system is because it gives you a lot of flexibility at the end of the day. For example:
ruby -pe 'next unless $_ =~ /something/' filename
grep something filename
awk '/something/' filename
perl -nle 'print if /something/' filename They all perform the same task, but which would you use on what system and at what time? I might use perl on a large file however what happens if I'm on a system without perl - those horrid legacy systems where one update or upgrade will break something, then I'd move on to awk or sed. It all boils down to versatility for me. Put me on any system and I'm good to go. If the system has a command line structure, I can get by. Can you perform the same functions as say nikto without PERL? I can using LWP or CURL and awk. Does this make sense? I hope it does.
Step Four - Weeks 27 through 38
During this time period, I suggest setting up lab based environments, meaning - creating an environment to compromise. Download VMWare or compile XEN and load up a couple of different operating systems with different programs/daemons under different configurations. E.g., Windows 2k running say IIS with no MS patches. Cleanly installed version of say CentOS, Solaris, etc.
Once you have your VMWare images installed, you can then head over to milw0rm, Bugtraq, etc., and find the vulnerabilities associated with your operating systems and configure the operating systems accordingly. Meaning - if you see that say Program X version Y is vulnerable to attack Z via an advisory, then configure program X version Y so you could actually compromise it.
This where the fun should begin. At this point you should be able to determine what programs are running as daemons and if you're wondering "what's a daemon" at this point, I suggest you go back through step 2. Your first tasks during this timeframe should be to try local exploits followed by remote exploits.
Download and compile some of the exploits associated with the system you're working on and try figuring out how these exploits work the way they do. Take a minute or two to look through someone's code, try to understand it. This still does not mean you should pick up Stevens' TCP/IP Illustrated. Just browse through the code, take a look at portions of the code and try to gain a sense of what it's doing. In doing so, you become a little more familiarized with certain structures of system calls, ports, connections, etc., without even knowing the programming language (if you didn't already know or learn a specific language). It's good to know the process an exploit goes through during an attack, it helps to develop strong skills in re-writing code whenever necessary that might suit your needs.
Try to gain enough understanding to perform say an lsof or netstat to see what is open on the port side of things. Remember you're starting off with local attacks, so with this information you can move on to say Now LAN level network compromises. Leave sniffers running to see the connections, try to analyze what you see. What DO YOU see? Can you leverage it? Are you familiar enough to know what are the first programs you would want to look for - if say port 445 was open? Are you familiar enough with the most vulnerable daemons and programs for most operating systems? Can you name the top exploits for the top rated open ports?
During the "learning networking" steps, you should have become familiar with the differences between UDP and TCP. Do you know what and how to look for opened ports effectively without using a scanner? How about writing your own scanner ;) It's actually a lot simpler than some may think.
This is a learning phase for you, so you should not be disheartened if you fail during your first attempts, no one is born "thirteen thirty seven" period (except TQBF and Shawn ;)). I'd suggest before you focus on becoming familiar with nmap, you familiar yourself with say telnet. Can you write a shell script to connect to a slash 24 for banner grabbing with nothing but bash and telnet? What happens if you just don't have access to a scanner? Do you call it a day? Think outside the box. Versatility.
"Why the hell would I do that?" you ask. The answer is simple, so you could take a look at the entire scope of things from different layers and angles to see and hopefully understand what occurs during the compromise phase. Familiarize yourself with as many processes involved on all layers and levels, don't strictly depend on tools, a monkey can be taught to run a tool. See what occurs at the network level, check what occurs at the server level - understand what is getting logged - if it is, where it is. Fiddle around, you may want to invest in the man pages of a system, certain available tools already on a system. tcpdump, snoop, lsof.
You can also load up Wireshark if you have it installed or your sniffer of choice, compile any known exploits for the vulnerable programs and servers you've installed, and attack then in parallel to your sniffer running. Understand what packets pulled off the compromise at what layer. If you're serious about doing say network analysis, I suggest taking a look at Laura Chappell's excellent Wireshark University offerings. Laura is a pretty cool and knowledgeable expert when it comes to the packet level. In fact, I'd seriously hate to become her enemy. Luckily she not only ultra smart when it comes to packets, she is an extremely wonderful person (INSERT brownie_points WHERE NICK LIKE sil) ;)
Now many peers will disagree with the approach I've written here or even take an altogether different approach than I have so far - many will choose to skimp on the networking portions of it and focus on say the application side of things or programming aspects. This is not an incorrect approach it's a matter of preference. Personally for the application attackers doing a pentest on my network, I'd modify things on the fly if I saw them since I can be anal like that. E.g., if I saw they were launching attacks on a Linux machine in my network, I might change the host's responses to that of an Irix machine for kicks and giggles, I might reverse proxy an IIS machine to POST to an Apache Server. That's just me though, but I'm sure the experienced individuals will be able to determine what I've done. How so? Perhaps packet signatures, server settings being returned, it all depends, it's all for you to discover.
Which brings me to a major rule of thumb, don't always rely on fingerprint when doing enumeration, it isn't always 100% - at least for me it isn't. This is why you'd want to understand some of the network portions, packet signatures, methods of delivery, etc., as checksums are more difficult to change then it is to change a daemon's listening port or a server's signature: mod_pimp anyone? Cross compare different results with different tests, then verify.
It's easier to gauge what something *really* is, on the network layer as opposed to relying on "banner grabbing". Besides, I still use modified portsentry on my honeypots along with a modified version of Fred Baker's Deception ToolKit. What can I say, I'm retro like that. During this timeframe, you should become familiar with certain methodologies and frameworks when it comes to penetration testing. For this I recommend heading over to ISECOM and picking up the " Open Source Security Testing Methodology Manual" (OSSTMM) and familiarize yourself with it.
Step Five - Weeks 39 through 52
This is going to be an odd guide/course/step to follow on this phase because there is no "one size fits all" model. It boils down to trial and error if you ask me. The tool stage. By now you should be seriously comfortable with understanding ports, systems, what to look for; "knock knock". During this phase you want to become more familiar with security tools, what tools do what, where, why, how and when is the best time to use them.
My suggestion, head over to Insecure.org and check out the top tools for each segment of security. Download them all, try them all and try to understand them all. What they do, how they do it, which might be better in which scenario and why. Which makes less noise on the network. Obscurity!
Now let's take a step back to reality. A tool is a tool is a tool ad-nauseaum. It's "what is the tool doing" that's important moreover, can you explain what a tool does if I was having a conversation with you about it. Or would you give me a generic answer. Do you know the difference between a webapp scanner and a network scanner? Can you interchange between the two? Are you sure?
Tools can be fun but understanding what they're used for as well as what they do, is more important than actually using them sometimes. Besides many tools are just streamlined commands already on a system. You might find it easier to make your own tools at one point, or you might find nifty shortcuts and dual uses for your tools. For example, I sometimes use nemesis as a replacement for nmap ;). I sometimes use LWP's POST instead of a browser. Sometimes I browse pages a-la wget -qO - thispage.com or links -dump thatpage.com imagine that for a second:
wget -qO - http://thispage.com|awk ./ssword/'
curl -e "http://live.search.com" -A "Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)" http://www.testdomainserver.com
A friend of mine I shall named Minga is perhaps one of the best pentesters I know period, his favorite tools to use ... None! He chooses to use his own stuff 99% of the time. While some (specifically me) think he's a glutton for punishment (particularly me) I think he's perhaps the most clever and dangerous pentester I know simply because of his versatility. You see, tools can leave a fingerprint . so with him, it's hard to detect his presence let alone defend against someone like him. Since he's my friend, I know I can just bribe him with beer and not worry about my network, you however, you won't get that in the real world. In order to think about offense you need to understand defense and vice versa. Hence me pointing out opening logfiles and understanding what you are seeing.
In understanding the layers, you'd understand when and where to use a sniffer, a packet injection tool, a "web application" scanner, a network scanner, etc. Make sense now? So when you began you probably thought you'd fired up nmap, Nessus, HP Webinspect, Core Impact or some other scanner, launch it against a network, call it a pentest, collect the money and call it a day.
If you have performed a pentest or are currently performing them in this method (using ranDumb tools), I created a title for it a long time ago for you - scriptkiddiot. I don't care if you're certified to the core. If that's the meat and bones of your arsenal and knowledge - point and click - to me you're still a scriptkiddiot. Sorry but it's the truth.
Hopefully you will understand why it doesn't always work as simple as just looking for and using SuperHackerTool X. What about the firewalls, the IDS/IPS devices that will almost always block you, how can you skate around that, can you even skate around that. Can you blind spoof and sniff the responses if any? Do you even understand what the purpose of blind spoofing is? Can you compromise a machine via blind spoofing and reverse a shell back to you? What about a covert channel say through http or ICMP. What about firewalking? There is a lot more than meets the eye. The more you know and understand, the more creative you can get, the better you will be.
Anyway, hopefully by now you will will see the importance of being that creative, that versatile, that flexible. Enough to think about how to avoid and perhaps even evade certain security devices and applications. "How can you muck around a little bit more stealthily." Can you change your packet settings to say Unicode? Can you do so with say libpcap without downloading someone else's tool? What about netsed? Do you even know what these tools are? Suggestion: Break your tools down into their respective categories, webscanners with webscanners, network scanners with network scanners and don't (repeat) don't skimp on investigating existing tools on a machine.
So you now have the experience with the layers, networks, operating system, now it's time to formulate a CTF (Capture The Flag) game plan. Configuring a network/system on a realistic level. Imagine that you needed to set up a SoHo environment. A mail server, webserver and a database for a 20 user network. Go create it - virtualized or not - this is your preference. Configure it as if you were starting your business. After it's done, analyze it. Find out what you would need to do in order to compromise that network. Are they running a webserver - if so which - what version, rinse and repeat. Re-do this network and now lock it down as if you're life depended on it, rinse and repeat the attack process. What do you observe?
This recon phase should give you a sense of how to seriously perform information gathering. There is a twist to it. At the same time you're gathering information, have those servers open to you as an administrator watching logs. Who is connecting to this server, where are they coming from, what are they trying to see. Is anything out of the ordinary? This dual purpose teaches you strong defense tactics ;) Understanding the administration of a server is priceless from a defensive posture. Understanding it is priceless from an offensive posture! ;) There are always two sides, offense and defense.
No comments:
Post a Comment