DoS 101: The Ping of Death

You are probably familiar with DoS attacks (Denial of Service). They're all over the news. They may have even affected popular services you've used. DDoS and DoS attacks are very disruptive and typically serve no other purpose other than bringing sites and services off the network. They've been known to bring entire corporations to their knees in a PR sense (for a short time), like Sony and Paypal. They cost these larger corporations millions of dollars in lost revenue and damages. The average cost of a DDoS or DoS attack is $40,000 per hour. In some of the biggest corporations I've worked in, we've estimated the cost in the 6 digits per minute range, depending on what network were to be hit. If you hit a billing or charging platform for an $80 billion a year company, that will cause some serious financial damage. The best strategy to mitigating DoS and DDoS attacks is to understand them (and to call Prolexic/Level3 or whatever other upstream you're using, heh).

DoS vs. DDoS:

I see this one mixed up a lot on everywhere from news articles to forums. A Denial of Service (DoS) is typically run from a single source to attack a specific target. A Distributed Denial of Service (DDoS) is run from many systems to attack a specific target. It can be explained by throwing those foldable steel chairs:

Figure 1: Santa experiencing a DoS attack.

Figure 2: A Wrestler experiencing a DDoS attack. 

Ping of Death; The Old School Cool.

The Ping of Death is hardly a new attack. In fact, it's probably the oldest trick in the book: You ping the crap out of someone with an over-sized IPv4 packet until their interface or the system itself crashes and is no longer reachable. Back in the days of limited bandwidth and large botnets, ping of death and smurfs were serious attacks. The Ping of Death would not flood a victim with so much traffic it couldn't cope, like the smurf attack. The crash condition is mitigated now, but ping floods by sending large amounts of over-sized pings can still be a threat to an unwary victim - like someone hosting a small ventrilo or web server. Understanding this Denial of Service attack will help you understand the core concepts behind them when we move onto more modern attacks.   

PING...PONG...

Below is our PoD.py code:

Running this from one VM to another is a ton of fun to watch your wireshark go berserk with the sheer raw amount of seemingly random traffic you'll get hit with. 

***Note, to run this (at least on Ubuntu) you need be root (sudo su), then run python PoD.py.***

Let's take a look at a sample attack from my Ubuntu VM at 10.0.2.5 to my Kali VM at 10.0.2.15:

Figure 3: En garde! We start flooding 10.0.2.15 with a bunch of traffic

Figure 4: Our server at 10.0.2.15 starts eating a ton of ICMP traffic. Oh noes! It's a DDoS... Or is it?

It appears we are receiving a DDoS attack. But if you look closely at the Ethernet II headers... the originating MAC address is the same. So this isn't a DDoS at all! It appears only a single host is attacking us but spoofing their address. That is because we are on the same subnet. ICMP works like this: 

Figure 5: Anatomy of a PING.

When you send an ICMP echo request, you first send an ARP request. When a host first tries to connect to another host on the same subnet, it will send an ARP request, and cache that response. If you have wireshark running before you launch your ping of death attack, you will see this request. Once that is cached, all the ICMP Echo Replies will be sent back to that MAC - Even if we aren't actually at that IP.  

You can verify this by looking at the Rx/Tx on the attacking machine and comparing it to our server:

Figure 6: Our server at 10.0.2.15 is under attack. We can see a nearly equal amount of incoming and outgoing traffic.

Figure 7: After 39 seconds of attack our server was hit with about 56 mb of traffic. 

Figure 8: Our client at 10.0.2.5 is recieving ICMP echo replies because we are on the same subnet.

Figure 9: Our client both sent and received about an equal amount of data. Not good to DoS ourself too.

So how could this be avoided? Well generally you don't attack things on the same subnet. But a simple fix would be to create a mac_spoofer() function in our code, and build the Ethernet header too, with random MACs. However, over a WAN this is not needed. When we send the traffic over a WAN the replies won't go to us... They'd go to the address you spoofed.

Figure 10: You can see we are only sending traffic, not receiving. I slowed down my interface so I'd send a small amount of traffic. 

This brings up an important topic now: amplification. It wouldn't do us any good to attack ourselves with a flood of traffic now, would it? We also don't want to send the same amount of traffic as our target receives. If we sent out 700kbps of traffic, about what the PoD.py script can send out on my VMs, we also don't want to waste our precious bandwidth and the target to recieve just 700kbps of traffic. We would just be arm wrestling their connection, and whoever had more bandwidth would win. Chances are, most websites have a bigger connection that what is cheaply available commercially. We also want the target to eat more bandwidth than we are sending, so we need a way to amplify our traffic. We could try sending from multiple machines, but that would be similar to just multi-threading the problem. We need ways to send large traffic by using small traffic. 

Pings and Amplification: The SMURF Attack

Notice how in our first example, our server was readily sending ICMP echo replies back to what it thought it was the sender? We can leverage this to achieve our amplification in the smurf attack. Our attacking machine just hast to send a ping packet with a spoofed source address to that of the victim. Our receiving machine gets this request and sends the reply to another remote machine. When dealing with Denial of Service attacks, you have to consider more than just download speeds, you also have to consider upload speeds. Usually your pipe only has so much bandwidth. Back in 1995~1997 when these attacks were serious business, your typical pipe for a server was measured in kbps. Additionally, trying to parse a massive (for the time) 60,000 byte packet would sometimes cause a buffer overflow condition and the server to crash. Yikes! These days the PoD and Smurf attacks are just a comically cute attack on most corporate infrastructure thanks to advances in network speeds and security controls. 

That being said, it's still possible to take down low powered hardware (RaspPI) or low bandwidth systems trivially with a flood of large ping packets.  

To amplify our target, we can either spoof our address, and let them just receive and relay large 60,000 byte IPv4 packets back to another target (which only amplifies by a really lame amount), or we can leverage the broadcast address. Thus we are brought to the smurf attack. In the timeline of Denial of Service attacks, we are around 1998/1999.  

Figure 11: A SMURF Attack

You send an ICMP Echo Request (1), with the source address spoofed to that of your target, to the broadcast address of several routers (2). The systems behind those routers all send their ICMP Echo Replies to that of your target (3), since you spoofed the address in step 1. 

We tweak our PoD.py code just a bit and we can perform a Smurf attack.

Figure 12: Pinging the broadcast address causes the Echo request to hit everything on the subnet (both our Kali and Ubuntu VM)

Figure 13: Running our smurf attack from our Virtual Lab Network.

Notice how we received the ICMP Echo requests but never sent any replies? This is because the virtual interface for Virtual Box has ip-directed broadcast disabled. As a matter of fact, nearly every router has this disabled by default now. The smurf attack was such a problem in the late 1990s, the industry all but eradicated it. If ip-directed broadcast were enabled, we'd be sending echo replies straight back to our target.  

What to take away

Denial of Service attacks are one of the most feared type of cyberattacks by businesses today - even though there are far worse attacks. They cost tons of money, you often have no idea who is performing one, and often the attackers want no demands or results other than to see you go down. They don't want your customer data, intellectual property or your money. Business tends to fear that kind of logic, and that's exactly why DDoS is the weapon-of-choice for hacktivist groups.  

Moving forward I will like to demonstrate some more modern Denial of Service attacks that achieve HUGE amplification: The now antiquated DNS Amplification and the newer NTP Reflection. Stay tuned!  

TCP 103: Port Scanning with Scapy

In TCP 101 and TCP 102, we learned how to manipulate TCP with a RAW_SOCKET. Welp, doing it that way all the time would suck. Thankfully, there's a module for that: scapy! We used pure socket before because I wanted you to understand what's under the hood when dealing with TCP/IP, or else the Scapy module would be kind of hard to wrap your head around.

Scapy is not a default module on Ubuntu or the like. You may need to install it on your distribution:

sudo apt-get install python-scapy

The Scapy Overview

Scapy is a great module for manipulating interface traffic. I recommend grabbing the PDF documentation for it here and here for reference. It can be used from everything to building sniffers to crafting your own custom packets. If you're getting into security, scapy is a must-know module. Take a look through the documentation at the link provided to get a glimpse at what's under Scapy's skirt. 

In this post we will be testing scapy on some port scanning concepts to familiarize you with the module.

The Half-Open Scan (Stealth Scan)

A half-open scan, as the name suggests is a type of SYN scan where we don't complete a full TCP handshake. It is also called a stealth scan (option -Ss in NMAP). You might be wondering why exactly it is called a stealth scan. Remember our little client and server application from TCP 101? You may have noticed our server did not actually record the IPv4 address until the TCP handshake was completed. That is exactly why a half-open scan is called a stealth scan. Let's see the code in action.

tcp_half.py

server.py (from TCP 101)

Fire up 2 VMs again like in TCP 101. Take our server.py code and launch it on our server and fire off a half-open TCP connection.

Figure 1: We fire off our half_open scan.

Figure 2: Not a peep from our server.py script.

Figure 3: We can clearly see a SYN, RST packet from our Ubuntu VM at 10.0.2.5 - indicators of a stealth scan.

In figure 1, we can see we receive back a SYN-ACK from our server (flags = SA). This indicates that port 12345 is open. If we had received back a RST-ACK from the server (flags = RA), it would indicate the port is closed.

So what is happening here?

When we fire off tcp_half.py it sends a single SYN packet. Our server replies with the SYN-ACK to try to finish it's TCP handshake in order to establish a complete connection. Instead we stop the connection and send a RST. The server will then drop the connection, hence why this is a half-open scan. We only connect half way and stop the connection. Our server never records our IP and just assumes we failed to connect because of network gremlins.  

Let's do a walkthrough of the tcp_half.py script, since it's new to you:

Line 1: We import scapy. You may have gotten an error if you tried to run this: "there ain't no damn scapy module bro." Or something like that. If that's the case:

sudo apt-get install python-scapy

Line 4: IP(args): We craft our IPv4 header. We set the source and destination address. In the link provided, it lists out the available arguments, data type, and default values for the IP() object. Much easier than dealing with struct and packing all the damn data up for the built in socket module. 

Line 5: TCP(args): Here is where we craft the TCP header. We set the source port to 1024, our destination port to 12345, and our flags value to "S" for "SYN". Lastly we set the sequence id to 12345, which is important to make sure our packets send and receive in order. A list of arguments for TCP: 

Figure 4: To find a list of arguments you can open a python console and import scapy. run ls(arg) to print out a list of commands.

Scapy documentation can be a bit daunting to trove through, but it's still pretty intuitive. How do you think you'd set "flags" for a FIN? flags="F" What about a FIN-ACK? flags="FA"

Line 7: Here we create our packet. We add in an IPv4 header then a TCP header. We do not need to craft an ethernet header since we are not manipulating any information at the data link layer. 

Line 9: sr1(args) [page35 & 36]: We set p to the returned object of sr1(). SR1 sends our packet "packet" and will only capture and return the first answer it receives. It is best used for single packet probes like we are doing for port scanning. We only care to know what the server's response is, which will come as a reply to our packet. The inter=1 command is the time in seconds to wait in between each packet.

Line 10: p.show(): Print out the parsed data from our packets so we can view it. In this case it will be the single packet captured from sr1 in line 9. 

Lines 12 thru 15: Same difference as crafting our SYN. The difference is we fire off our RST right away after the SYN waits 1 second. 

The FIN Scan:

Modern day security equipment like various firewalls and IDS/IPS systems can easily detect SYN scans. A FIN scan is a good way to do a port scan around most firewalls and IDS systems. We send the remote host a FIN packet. If there is no response from the remote host, there is a good probability the port is actually open. If we receive a RST-ACK, the port is closed.

Figure 5: We fire off our FIN and get no response. Yay! The port is open.

Figure 6: Our server is as oblivious as always.

Figure 7: We can see the FIN reached our server. Our server does nothing when it receives it.

To play around with it, firewall off your servers listening port with an IP tables rule. You'll receive a RST-ACK when you send the FIN to port 12345.

The ACK Flag Scan:

An ACK flag scan is best suited to probe if firewalls, IPS or other related network security controls are between you and your target host. With this method we send an ACK packet with a random sequence number. No response means the port is either filtered or open. On the contrary, if we receive a RST-ACK, the port is closed.  

For this example I will probe telnet, which is pretty much firewalled off most of the internet.

Figure 8: We send an ACK and get back a RST. The port is closed by a firewall.

Figure 9: We receive the RST-ACK by our application. 

XMAS Scan:

This involves sending basically a bunch of flags all at once (FPU) and seeing what bounces back. You could say the packet was 'lit up like a christmas tree.' Typically if the port is closed, you'll get an RST. If the port is filtered you will get nothing back.

Figure 10: We Send our FIN-PSH-URG and receive back a RST-ACK. Telnet is closed on the remote host.

Figure 11: Packet capture of a successful XMAS Scan.

Reinforcing the Concepts:

If you need something to do to reinforce these concepts, build yourself a little port scanner with scapy. You could pretty much wrap all the code here into some functions, that way you'll have them for later on. Play around with scapy, a VM, IPTables and Wireshark. It's a very powerful tool for packet manipulation! Merry XMAS scanning!

Where to Begin as an InfoSec Noob

The number one question I get or see across many security forums is often repeated several times a day: Where do I start for a career in IT or Information Security? Hopefully I will be able to answer a majority of your questions here:

Intro
Just note that the path of an Information Security professional isn't an easy one, or more people would be doing it. As a matter of fact the amount of people going into it is decreasing as technology gets more complicated.

“The demand for the (cybersecurity) workforce is expected to rise to 6 million (globally) by 2019, with a projected shortfall of 1.5 million,” stated Michael Brown, CEO at Symantec

The US government even relaxed their visa requirements, issuing H1-Bs to foreign security contractors under the Specialty Occupation Program. They recognize the need to boost America's cyberdefense, and that there are millions of open job reqs that aren't getting filled.

The learning curve for a lot of people seems too steep, so they don't attempt it until later on in their career when they get more confident with their abilities. There's nothing wrong with that though! That's how many ended up in security in the first place! Most people in InfoSec are in their 30s to 50s. At 25 now I'm still the youngest person in every team I've ever worked with by at least 5 to 6 years - and I've worked at some big companies with large and mature security organizations. I started young and was crazy enough to choose this as a career. Just know this: It won't happen overnight so don't get impatient. I'm going to give it to you straight: This is probably a 5-7 year timeline at least. But the payout is worth it. Top salaries are in the $200k+ range. 

• Learn and understand a programming language. And I mean truly understand it. You won't be a good hacker if you can't look at code without really understanding what it's doing. Python is typically recommended. Most tools are written in it or similar language (like Ruby). Plus it's easier to automate web application pentesting using Python because the library support is really strong for such tools in Python 2.7.
• Learn and understand the industry by gaining experience in a professional role. It's very unusual to end up in a security role without any prior experience. Get a job as a systems administrator or network administrator. School and degrees are not required (and often are a waste of time, more on that in the certifications portion). If you have true knowledge and certifications, it won't be difficult to find a position once you understand the rest of what I'll mention. Start small. Without professional experience you likely won't land a $60k/year sysadmin role. Your first role might even be making $13 an hour as a helpdesk operator. Additionally, understanding how the IT world works will make you that much better of a pentester. Just by seeing a few things on social media or scanning the resumes of your target you'll immediately know where to hit or what to look for when you're attempting to intrude in an authorized penetration test.
• Know and understand network protocol. Obviously, you need to know very low level information on how computer systems and networks interact with each other. Full knowledge of TCP/IP, UDP, DNS, etc. is absolutely required. I wrote a guide here that explores TCP/IP 101 and manipulation with Python.
• Network in the industry. Learning from others is the best way to learn. You gain different perspectives and can build off of not only your own experience, but others as well. Your peers will have all had exposure to a very wide variety of networks, vendors, tools and platforms. Learn from them. This obviously comes in line with building professional experience.
• Metasploit, Burp, and other tools are only the tip of the iceberg. Using MSF console or another tool without really understanding what you're doing is script kiddie shit. Yes, it is totally possible for any monkey to figure it out - they are designed to be easy to use. There's a discernible difference between a professional who knows what they're doing with the tool and one who only has a limited scope of what to do with a tool because they've cracked a few metasploitable VMs. It isn't uncommon to have to tweak things. It doesn't always work right out of the box.
• Social engineering is debatable security. If you handed a client a penetration test that had social engineering in it, and that's the only way you broke through the perimeter, they'd probably be mad and never return to your agency. Pentests ain't cheap. If they didn't ask for it, DON'T give it to them. You'll work out social engineering aspects when defining the scope. When clients are paying for an ethical hacker, they're paying someone to find things that they couldn't. Their security staff probably already knows the risk of phishing. You can save hardening against phishing for another service agreement with them. Give them the good stuff.
• Certifications, not Degrees! Getting the right certifications gets you past the robo-resume crunchers and gets you in front of a potential client. Plus, in the process of getting them you'll actually learn useful and relevant information. Time to harsh up your mellow and lay down the reality: Your GPA and your transcripts are worthless to industry leaders. When I worked at Intel they ultimately want to know "is this person smarter than you?" Depending on how well you ranked to that question determined how badass you were going to be in the job. They didn't care if there was or was not a degree, just whether or not you were damn good at what you do. If you know what you're doing, companies and nation-states will come to you for your weaponized exploits.
  
  Degree's aren't necessarily a complete waste of time. If your end game is to land a job in IT Security or a related field, you don't need to fetch a degree right away (if at all). My issue with them is a lot of young students think that just by earning a degree they will automagically learn how to hack or how to get marketable skills. Degree courses only teach you the concepts. They won't teach you how to write secure code. They won't teach you how to spin up a honeypot to catch that APT that's been hammering your network. The same concepts that certs like the CISSP or Security+ teach. Certification organizations recognize this. For example, ISC^2 removes 1 year off the 5 year requirement if you have a Security+ OR a Degree. One can be studied for in 4 weeks, the other takes thousands of dollars and years off the clock. I'm not alone in this regard. ISC released a study that found members with a CISSP earn, on average, $30k more per year than those without. The difference in salary is negligible with a masters. You want to get a degree for the right reason - for your academic growth and personal development.
  
  Trying to earn a degree in computer science or information systems/security for the purpose of hoping to land an IT job is not the right way to do it. I'd only recommend that route if you want to go into a career as a Software Developer/Engineer - or an actual computer scientist (Quantum computing and robotics, that's what I'd go back to school for). Many schools have programs where you'll work before you even graduate. Take advantage of them if you go that route, because fuck it, you're giving them $40,000 anyways.
• Watch your background. Obviously, don't go hacking away and getting arrested for BS when you're starting out. It may be too tempting because it really is too easy. Having a record of any kind makes it difficult to break into certain markets, like the government or organizations that are governed by federal or state regulations (finance, gov orgs like NASA, public utilities, medical, etc.). Conducting any kind of illegal activity and getting caught for it could very well end your career or halve the potential employers you could work for depending on charges. Really cliche, and I don't judge by any means, but don't steal shit and stay out of drugs and it's pretty much a non-issue at that point. A lot of advice seems to glaze over or completely neglect to bring up this point. Yeah, I'm 90% sure 90% of us have done SOMETHING illegal or at least really in the gray area. But that doesn't make it ok for you 'just because others did it too.'
  
  
  Love to learn and live to do it. There's an ancient Greek legend that can apply here: Milo of Croton, an ancient Greek Olympic athlete. I suggest you read it, because starting will be similar to that. The story goes like this: Milo carries a baby Ox every day. As the oxen grew and matured, so did he and his strength. Eventually he was able to carry a full sized Ox like the average guy carried a sack of flour. I know the feeling all to well of staring at the mountain of information and wondering where the hell you even start to scale it. Remember Milo and start small. I constantly learn new things from electrical engineering to new computer science concepts. The truly successful in our industry are the self-start self-study nerds. The more information you want to vacuum up every day the stronger you'll get - just like Milo. Just don't do it all at once. You can't go lift an full sized Ox right from the beginning.

So what now? Where to start

Generally speaking there is a lot of information and there is not any best place to start. Take my information and use it to work out the best path for you.

• Don't underestimate books. If you were involved in a public school system, you're familiar with textbooks. The majority of what you know now was learned through textbooks. Think about it. All the teacher did for the most part was assign work for you to do in your textbooks. Now you're your own teacher. Build yourself a curriculum and force yourself to adhere to it. Environment is everything. If you're in a distracting environment (that includes being alone at your house) it makes it almost impossible to learn. It's so easy to click that damn Reddit bookmark and just lose 3 hours of your life. However, that's 3 hours of time you just robbed from yourself. If you're a student, your school's library is a great place. A public library as well. Anywhere public with a solid learning environment is best. This includes downtime at work too, believe it or not. If I ever have a free moment, I usually spend it wisely and knock another chapter out of book if I can, or maybe rebuild or add a new feature to a tool I built.
• What is the general certification path? Again, there isn't any solid answer for this question. Generally recommended is: Net+, CCNA, Sec+, CISSP, Master something like Python, C|EH, OSCP, Use your employers $$$ to get some GIAC/SANS shit like the GPEN because its super-ultra-mega expensive. Don't buy the SANS stuff with your own money. If you're going to do that just buy yourself a motorcycle and ride to Alaska instead. Money better spent at this point in my opinion. When you're old and crusty with 10-15 years experience, invest in a masters degree. By then you may have plateaued pay wise and NOW the timing is right for a degree, but it isn't totally necessary. A degree doesn't really increase your pay in InfoSec like it does in other fields, but it does help you get into a non-technical and sometimes a technical management role which will probably pay better with overall total compensation (pension, etc.). By now, stuff that was around when you were a kid is being called 'vintage' by young technology addicted people with ridiculous hairstyles, so that pension and 401k stuff you didn't give a shit about on your offer letters 15 years ago matters more than it did when you were 20.
• The CompTIA Network+. This is for those of you who have no idea what the hell a value of 06 means in the protocol information of a packet dump. It will teach you the basics. It's like pouring the cement foundation for what you're going to build next. You can't build up without a foundation, it just doesn't work that way.
  The thing is with certifications is they have different versions. So get the right book for the current version of the test. At the moment the current version is the N10-006 exam. (People from the future, be sure to check CompTIAs site for the current version). Try this material to study for it ISBN-10: 0071848223.
  • CompTIA Network+ Reference:
    Book: ISBN-10: 0071848223
    Exam Code: N10-006
    Voucher URL: Link
• Cisco Certified Network Associate (CCNA). Once you have a solid foundation in networking it's time to build that up with actual skills. It is impossible to pass the CCNA without knowing your way around the terminal in Cisco's IOS. This will teach you how to work with the most common networking equipment vendor: Cisco. It also goes more in depth with networking concepts and how they apply to the IT world. Knowing networking isn't enough. You also need to be able to answer questions a business might ask like "How do we achieve network segmentation between these applications?" Experience will be able to answer that best but you can start with the CCNA. The current exam at the time of this post is the 200-120 CCNA. I recommend ISBN-10: 1587143879. Seeing as how this directly involves in working within a terminal on an actual switch through the console port, Ihighly recommend picking up a used Catalyst 3500 series switch so you can get intimately familiar with the remote terminal.
  • CCNA; Routing and Switching Reference:
    Book: ISBN-10: 1587143879
    Exam Code: 200-120 CCNA
    Voucher URL: Link
    Recommended Training Hardware: Cisco Catalyst 3500 series (Typically $75~$200 used depending on model)
• Get to work! By the time you have a solid understanding of network and routing and have achieved a few certificates, you should be working somewhere in IT. You absolutely need that experience. Also, most employers will pay for training so you don't need to fork the money over for the increasingly more expensive exam vouchers from this point on. If you're having trouble finding work with the CCNA and Net+ under your belt, you need to look smaller. Remember the Ox analogy? You might have to take a helpdesk role or expand you experience to include Microsoft and Linux systems administration. There are certificates for those, but they're not totally necessary. Don't look at big companies. Look at small local companies. You also may need to expand your job hunt to nationwide or at least statewide. Don't be afraid to move. This is your career after all. Passing up a nice opportunity because you're afraid to take the plunge and move to another state isn't a wise decision. Because of my line of work I've had the opportunity to live, work and travel all over the US! Just keep in mind you'll never break into any real info sec role without prior experience - degree or not. Once you have your foundation built don't pour your time anywhere else but resume building. One of my first ever contracts was as a network administrator at a start up. Sometimes it's not all about the money. What I learned at that role landed me a Systems Engineering role at a larger company making more serious money a couple years later, and they loved how technical I was. I couldn't have done it without my lowly net admin role where I got exposure to all kinds of amazing tools and equipment.
• CompTIA Security+. The Security+ had a bad rep with the older version. It wasn't technical enough with older versions. Well now, that has changed. It's actually challenging, and a really good solid foundation to launch into the CISSP with. The current exam you want to take is the SY0-401. The SY0-301 is the older one that's about to be depreciated. Don't bother with that one, it sucked in my opinion. This exam will go into networking concepts, as well as security concepts like business continuity, CIA, and other things you'd expect to find on the CISSP. If you're fresh into security, it's a good way to start. The exam vouchers are cheap and like with all CompTIA certs, coupon codes or programs for vouchers are widespread. It's a low-cost low-risk intro into the CISSP. Additionally, it knocks an entire year off the experience requirement for the CISSP! Very useful for getting a headstart. It has it's place so don't bash it.
  • CompTIA Security+ Reference:
    Book: ISBN-10: 1118875079
    Exam Code: SY0-401
    Voucher URL: Link
• ISC² CISSP: Certified Information Systems Security Professional: This has become the defacto security certificate in the industry and is practically mandatory... for HR purposes. Yes, that's right. It's a common misconception this actually teaches anything about hacking. It does not. It is NOT a technical certificate.What it DOES do is expand more on the business concepts you learned about in the Security+. It will teach you everything from what fire extinguisher to use in the event of an electrical fire (I'm not kidding) to a brief overview of firewalls and architecture design. It covers a very wide and broad overview of Information Security and IT in general. There is not a lot of depth in the program as far as raw technical knowledge goes. I'll describe it like this: It's like a lake that's 10 miles wide and 2 inches deep. Lots of coverage, not much depth. That being said you absolutely should get it, just don't misunderstand what this certificate is. You won't be a 1337 h@x0rz just by getting your CISSP. I've seen plenty of people who passed the exam but don't even know what a reverse shell is. But it will help you land that SOC Analyst role at UltraMega Corp, Inc., ltd LLC. That's when you'll start picking up real skills.
  • ISC² CISSP Reference:
    Book: ISBN-10: 1119042712
    Exam Code: CISSP
    Voucher URL: Link
    Vendor Reference URL: Link
• Learn a Programming Language! Now, if you haven't been working on this slowly over time, now is the time. You're going to need to write your own tools or tweak existing tools at some point by this point. Python is THE language to learn first. Not only is it easier to learn than any other language, it is what probably 90% of the tools are written in and has amazeballs library support for info sec tools. There's lots of ways to learn but the best way I found was the Learn Python the Hard Way book. I've recommended it to a few people and they all ended up launching into other books and landed roles in web dev after about a year of self study. LPTHW won't work unless you do EVERYTHING. Answer and understand every extra question the textbook asks. Buddy up with some programmers at your work place and ask them to mentor you when you get stuck. Having someone explain it to you like you're 5 is an awesome thing. One thing to be wary of when asking experienced programmers is they may look at your code and recommend 5 other random libraries you've never heard of. Take it with a grain of salt. Programming is like handwriting, we all write it differently. You won't totally know everything about code after a book like LPTHW, but you'll be able to launch into other books. 4 or 5 books later you'll be awesome. One thing I'd like to mention that worked better for me is to get the actual physical book. Soft copies like PDFs have never cut it for me. I carry around the books I'm working on with me every day and set them on my desk. It's a good physical reminder that I need to finish them every day and having a physical copy makes it much easier to just flip it open to the book mark and pick up where I left off. Plus you look like some bad ass wizard with a giant bookshelf of programming manuals.
  • Python Security Reference:
    Learn Python the Hard Way: ISBN-10: 0321884914
    Learn Ruby the Hard Way: ISBN-10: 032188499X
    Violent Python: ISBN-10: 1597499579
    Black Hat Python: ISBN-10: 1593275900
    Metasploit: The Penetration Tester's Guide: ISBN-10: 159327288X
    Learning Penetration Testing with Python: ISBN-10: 1785282328
• EC Council Certified Ethical Hacker; C|EH: Like the Security+ and Network+, this is a foundation into penetration testing. This is like the "introduction to tools." It goes over the tools and tactics for basic network security penetration testing, like using Metasploit. It's a great resume builder and learning experience to take your next step away from an Information Analyst role and into a more technical role. Those tools are designed to be easy to use, so believe it or not, you don't actually need to know shit about security or hacking to take and pass this exam if you study hard enough. To be fair, the same can be said for any of these certifications. It just seems to happen a lot more than usual with this one, maybe because of the way it's marketed. DO NOT do that. Don't be that guy. You devalue the certificate and the people who have worked hard to achieve this certificate AND know what they're doing. You'll get crushed in an infosec interview if you up and get this cert without a good foundation and expect it to teach you what you need to know to get a specialist role. You'll waste the employers time and your own. Plus you'll look like an idiot and pretty much ban yourself from working at that company (those managers stick around for long times at larger companies, and yeah we will remember you if you apply again 2 years later as 'that one guy'). Version 9 is the latest at this time, it recently replaced version 8.
  • C|EH version 9 Reference:
    Book VERSION 8: ISBN-10: 111864767X
    The v9 exam is really new, so books may not be released yet. Check the vendor reference link for any version 9 material.
    Exam Code (v9): 312-50
    Voucher URL: Link
    Vendor Reference: Link
• Offensive Security Certified Professional; OSCP: Try harder! This exam is tough. I'll put it this way: The exam is 24 hours long, and you have to actually hack into systems. There's no questions. There's no multiple choice. Just an objective. Most people use almost that entire time to do the exam and write the pentest report. If you're ready to put your skills to the test and prove you can faceroll systems with Metasploit, this is the exam to take. It's like a shining beacon of awesomeness on your resume too. If you have this certificate there is often little doubt that you know your shit if it's backed up with some solid experience and industry reputation. That being said, it specifically covers several tools widely used in the penetration testing biz. It won't teach you how to hack into satellites to broadcast traffic in order to hide your botnet or any fancy shit like that. But you'll be able to break systems that have common vulnerabilities no problem. This test takes MONTHS to prep for. You absolutely need a really solid background with everything previously mentioned in order to successfully complete the lab. Even as tough as this cert is, it's still considered entry level. That's right. After everything you've learned and even with an OSCP you're only starting to crawl. Writing your first 0day and publishing your first CVEs are a still a few paces ahead at this point. I told you it would take a while. Your Ox is essentially a juvenile now. You're pretty strong but it isn't fully matured yet and neither are you :)
  • OSCP Reference: Book: Due to the nature of this test there isn't really any book, but there are several that will help. ISBN-10: 1494861275 
    Exam Code: Exam is handled by them and not a third party like Vue. Check the reference site for more information.
    Vendor Reference: Link
    Vendor Lab Reference: Link

MITM 101: ARPSpoofing

In TCP 102, we went over how to capture the IPv4 header and TCP headers on our local interface. But how do we capture them from a remote host? We have to become... the man in the middle (MITM).

Figure 1: Totally inconspicuous eavesdropping 

The Address Resolution Protocol (ARP):

ARP is as old as the internet itself (1982). It's a core technology like TCP/IP and is very important for packet switched networks, like the ones we use today. Without it our interfaces will have no idea what router to hop to next. You may be familiar with DNS (Domain Name System) that resolves an IP address to a domain name (like google.com).   

ARP works kind of the same way, in concept at least: It resolves a MAC address to an IP address.

On your local machine, the ARP cache is stored in a table. You can view it with arp:

The ARP Request:

On your local network, a machine might want to send a message to another machine. The host machine might only know the IP address, but the MAC address is required to actually send the message at the data link layer. In this case, the host machine will broadcast an ARP request. Everything on that subnet will receive this message. If you remember from TCP 102, I said to note what type of packet this was. If we go back to this screenshot, you can see its 0x0806:

Figure 2: Address Resolution packet; 0x0806

The ARP Reply:

The intended recipient will send a reply back across the network with their MAC address via Unicast.

Figure 3: "Hey who the $@#! is at 192.168.1.120?"

The ARP Cache:

Obviously, it would suck down our precious 1980s bandwidth if we sent an ARP request every single time we wanted to contact a host on our network. Because of this, the machines on the local network will cache the ARP replies for a short amount of time. When any device wants to send some data to another device, it must first determine the MAC address, even if it knows it's IP address. You can see the problem here. What if we just... told everyone we're someone we're not? After all, who's going to stop us? I got reported by sudo once. Nothing bad happened, so why can't I say I'm Jim for a day.

Figure 4: I guess I don't get 21:9 aspect ratio this year.

The ARP Header:

Well, just like TCP and IP, ARP has a header too.

Figure 5: Note the addresses wrap around to another offset.

We'll use this information to craft our very own evil ARP reply. We've gone in detail over TCP and IP headers in TCP 102, so this one shouldn't need much explaining.

Anatomy of the MITM:

Here's our new fancy arpspoofer code:

We'll also need the sniffer code from TCP 102:

Here's how my virtual lab is setup:

Figure 6: The lab setup.

If we just launched are ARP poisoning attack and our sniffer with default configuration of our interfaces, we would intercept the traffic from the victim and drop it. We don't want to do that! They wouldn't be able to get anywhere and we wouldn't be able to harvest useful information. We need to set our interfaces into IPv4 forwarding mode. This can be done by pasting the following line into the terminal:

echo 1 > /proc/sys/net/ipv4/ip_forward

That will allow us to forward traffic on our interface to the gateway.

Now that we have our interface configured and our code ready, let's analyze what will happen when we launch it:

Figure 7: An ARP poisoning attack.

We simply tell the gateway we're the victim and we tell the victim we're the gateway. That's it! With the ipv4 forwarding rule enabled, it will allow us to send and receive traffic on behalf of someone else. 

Launching the MITM:

First, fire up our sniffer.py script. It will begin sniffing traffic on the interface of our Kali VM.

Next, launch the arpspoof.py and paste in the MAC for your listening interface, victim and gateway.

Now, on your target VM, browse to a site, like Reddit:

Figure 8: All your internets are belong to me.

If we capture the traffic in wireshark you can see that I'm now the victim and the gateway according to who you ask:

Figure 9: The IPs and MACs of my lab network

Figure 10: We tell the Victim that we are the Gateway.

At this point, we have full control over the victim's traffic. Although we are just passively listening, we can modify and manipulate any part of their traffic if we want. There is little to no validation on plain-text traffic. We could say, modify the DNS requests to point them to another IP and redirect them to our evil Reddit site, or if they are using a plaintext http:// login site we could sniff their credentials. This type of attack is fairly dated but there are many tools and tactics we can deploy that allow us to intercept TLS or SSL encrypted streams. The sslstrip attack is still extremely effective. All it does is change an https:// link to http://. With a bit of work you could take the code I've provided you and do exactly that. On most sites they will fail to login but they'll still have POSTed their login credentials to you. What I do is have them post their credentials once. If they fail I reset the connection and let them login over https://. They'll get to login and just think they fat fingered their password, none the wiser I just harvested them.  

Also, using a self signed certificate and presenting it to the victim instead of the remote servers certificate still works wonders. Many people are stupid, to put it bluntly, and click-through the giant red "omg this cert is broken" page that Chrome and Firefox will display. It's because of this reason that the browsers started removing click-through options.

Now you know why Public Key cryptography is so damn important. DNS requests, HTTP traffic, etc. all get signed. If you modify any part of it, the signature is invalidated and our victim will know they are being eavesdropped upon. But you can still leave all the encrypted data in-tact and listen to where they are going.  

Figure 11: Obviously, tweezers are the best tool for grabbing passwords and ruining monitors.

Analyzing the Code:

So what went on here? Most of this information isn't new by this point. What is new is the concept of crafting our own packet, though.

s.bind(args)

This is technically new. We pass in our interface (eth0 in this case) and htons(0x0800). Remember that 0x0800 is IPv4. The args are accepted like this: (interfaceName, protocolNumber).

On line 9 we define a new method, pack_addr, that address to networks (aton) an IP address passed in as an argument, then returns the packed result.

On line 14 we define another method, pack_mac, that takes a MAC address passed in as a string and converts it to it's packed Hex form. It will replace any ":" characters with '', or nothing.

Lines 22 thru 26 just pack the input you supply into their network form using the previously described methods. Take care to input it correctly. I'd just grab your HW addresses directly from ifconfig or arp.

On lines 29 thru 31 we are constructing the Ethernet headers. These are a header type that rests above IPv4. We haven't dealt with them yet but they work just like the TCP and IPv4 headers, except they have a fixed preamble that we do not modify. We can ignore the preamble and don't need to supply it when crafting the packet. Here is how they are constructed:

Figure 12: An Ethernet Header

We construct this by supplying the Source address + Dest Address + Protocol code into a variable. Remember from TCP 102, that the arp_code 0x0806 is a type of protocol code:

 Figure 13: You can see the 0x0806 entry for ARP, from TCP 102.

LInes 34 thru 38 specify options for our ARP header. Refer back up to figure 5 to help map the ARP header to these variables:

• htype: Hardware Type
• protype: Protocol Type
• hsize: Hardware Address Length
• psize: Protocol Address Length (IP)
• opcode: Operation Code

On lines 41 and 42 we actually craft the packet. We first add our ethernet header, and then we add all the information in order needed to complete the ARP header. Refer back to Figure 5 if you need help mapping each variable we are adding together. Essentially they are the same, but we flip flop our dest and source addresses/MACs.

On lines 46 and 47 we send these in an infinite loop to keep the gateway and victims ARP cache flooded with our MAC address instead of the correct ones.  

A Word of Warning:

Don't go sniffing all willy-nilly and violating someone's privacy. I obviously can't stop you if you do but I'm also not responsible for any damage you may cause, or any legal consequences. Only use these for learning purposes and on a virtual network you own. I ran this within my own virtual environment where I would not cause any harm to any other machines.   

Figure 14: You're 1337 now, so grab your balaclava and crowbar.