Sunday, March 27, 2011

Course Review: SANS SEC542

Well it is that time again for another course review.  This time it is SANS SEC542: Web App Penetration Testing and Ethical Hacking.

I personally found this course super interesting.  I took it OnDemand via SANS (personally, the only way to do courses) and I greatly benefited from the insight provided by Kevin Johnson as well as extra time to do my own research into the tools and techniques mentioned in class.  The following is going to be a summary of the core concepts that I learned from this course.  If you have a chance to take it, I suggest you do.  The insight and lab environment provided by SANS proves to be an effective learning tool.

Day 1: Attackers view of the web
The real purpose of this day is the ensure that everyone taking the class has a similar baseline of knowledge.  This knowledge, of course, is what the rest of the course will build on.  What I particularly liked about this part of the course was not so much the overview of TCP and the different types of authentication (basic/digest...) but how all of this was summed up into how the attacker views the different mechanisms that are used in security today. 

The course goes into depth about the authentication techniques used today.  For example, in Today's web, session state is everything.  The course goes over the different ways that session state is persisted in a stateless protocol as HTTP is. 

The course also talks about the different types of "testing", and which types will accomplish what.  On a related note, I was recently asked a question about the difference between penetration testing and a security assessment.  At the time, I kind of flubed the answer, but after reviewing my notes I would have to take the following stance.  A penetration test is simply a matter of seeing "how far can you get".  You can only truly know the risk of a vulnerability if you have fully explored how far you can take it.  A security assessment, on the other hand, is more of a "try-and-find" type approach.  The goal is not to find out how far a certain vulnerability can go, but rather, to figure out where the holes are and plug them.

The most important part of day 1, in my opinion, was the discussion of the attack methodology used.  Since learning this methodology, I have learned that there are others than can be followed such as OSSTMM.  Really, the methodology here is quite simple.
1) Recon : Research the target
2) Mapping: understand the target and it's surroundings
3) Discovery: look for vulnerabilities
4) Exploitation: launch attacks!!!


Day 2: Recon and Mapping

Recon as defined by the course simply means to research the target.  In the day and age of things like Stackoverflow, recon has gotten more complex.  Kevin tells the story of one assessment that he was doing where he actually used google and message boards to determine vulnerabilities in code.  Coders like to post samples (especially when they have problems) on message boards looking for help.  Kevin repeatedly says that the only advantage a company has over a hacker is the fact that they have access to the code.  This really changed my mind on posting code samples on the internet.  Most of the techniques and tools involved in Recon are general stuff.  Just remember that you can use anything public facing to get an idea of what the company is using.  Take for example, job postings.

Once you have your targets to hit, you can begin the mapping phase.  Mapping generally goes in the following order:
1) Port Scan
2) OS Fingerprint & Version Scan
3) SSL analysis
4) Virtual hosting $ load balancer analysis
5) Software configuration Analysis
6) Spidering
7) Detailed Analysis.

Basically, you are trying to find out as much information about the target as possible.  All this information could be things you could use during the next phases.  For example, in (3) you could determine that the server allows for the NULL SSL key.  Which basically means data is sent in the clear.  You might be able to use this information during later phases.  Another interesting aspect of mapping is (5).  There are automated tools that you can use to help determine the configuration of applications running on the server.  There are many tools that one can use in this space.  They include
1) Nmap
2) P0F
3) HttpPrint
4) Nikto
5)WebScarab

One important step of mapping is to try and chart out the application itself.  What pages link to others, etc.

Day 3: Server-Side Vuln Discovery
Basically this step involves probing the server to try and determine weakness in the application.  The easiest way to accomplish this is by use of automated scanners.  One should never rely on automated scanners to do all the work, however. Most of the day talks about manual ways to do discovery.  Very very very interesting stuff.
1) w3af

Day 4: Client-Side Discovery
This day primarily focuses on the client side technologies used in modern day websites, and how one might be able to exploit them.  One example I can remember clearly was talking about an AJAX shopping cart.  General shopping carts have the following 4 steps.
1) Add an item
2) Subtotal
3) Charge credit card
4) Checkout.

Well what would happen if you ran all of these calls out of order?  Would it work?  You'd be surprised to know that not too long ago some major AJAX shopping carts had vulnerabilities like this. 
This day goes into depth about AJAX, Web services, XPATH Injection and more. 

Day 5: Exploitation
This day was by far the "fun" day out of the course.  Here they talk about bypassing authentication.  They talk about using your SQL Injection for bad.  They talk about making zombies of browsers on the internal networks, and then using them to continue your attack.  Really really neat stuff.  I'm not going to into detail here.

Overall this was a great course.  I think it has provided a solid foundation for me to build my skills on.  I recommend this course for all developers who want to know how attacks are really done.  Those people who say, so what ... sql injection... the database doesn't have anything useful on it, be warned... you are so wrong.

No comments:

Post a Comment