What we learned from teaching Web Hacking at Infiltrate 2013

So this year myself (@alexm_py), Miguel, Matias (@gunler) and a guest appearance by Nico (@nicowaisman) were the teachers for the Web Hacking class at Infiltrate. This is our third time teaching the course and we learned a lot along the way, I've tried to only focus on things that are applicable outside our organization.

1) We write a ton of custom software for our classes and that investment is seen in higher rate of students actually learning the content. Case in point, Matias wrote an amazing web application for our web crypto class explaining how ECB, CBC and Padding Oracle worked (here's a look). They key seemed to be that the students could tinker around and add different values to see what effects were had on the algorithm. Students walked out of our class understanding the crypto concepts better than any other time we've taught this content.

2) Putting in the extra effort to make your applications look good is worth it. We decided to teach command injection (CMDi) as a proper module this year rather than just including it in our reference material so I had to write up new slides and new exercises. I was pretty happy with how it turned out. The student response to this exercise vs. one of the XSS exercises was pretty evident. My initial thought with XSS was that by keeping things as very simple HTML we could focus on the vulnerability but instead it detracted from the quality of the experience. That's going to get fixed.

3) Students in our classes are happiest with their fingers on keyboards. The first two modules we teach are open source information gathering (OSIG) and versioning. In OSIG we spend a lot of time talking about methods to find vhosts, Google dorks, and other methods to find out information about the sites being assessed. Versioning is exclusively about determining the version of installed CMS's and webservers. We taught these in a more lecture heavy style and it was our #1 complaint amongst students. I think the information is important and spot on but we need to re-do how we teach it.

4) Consider having a separate day to go over introductory material. Because we get students from all different ability levels we cover some basic information: how HTTP traffic works, intro to the Linux CLI, intro to Python, intro to JavaScript, intro to SQL (mostly MySQL). A number of students commented on how they thought this slowed down the pace of the class too much. We had explored the idea of having an optional day at the beginning where students who were unfamiliar or uncertain about this information could have a day of focused instruction. Ultimately we didn't do it but it is an idea we'll have to revisit.

5) Test your exercises in the environment you're presenting them in! I made the mistake of testing from a development laptop rather than from a student's laptop and the minor differences became embarrassing. Also make sure to fully test each of your exercises and their solutions, just because something worked last time doesn't mean it will work this time in this environment. Since we did a scoring system our new rule is that before the class we will beat each exercise and challenge until our demo student receives a perfect score.

6) Students tend to appreciate the little things. Our classes are typically catered, at Infiltrate we did breakfast, lunch and an afternoon snack. Asking the students how the food was and if there was any dietary restrictions we should meet went a long way, I had a few students go out of their way to thank us for doing this.

7) Lastly is general collection

Things will go wrong with your connection to the hotel network, have someone from your team who's main responsibility is to get the class network and the hotel network talking (if applicable) If you're moving a lot of gear invest in hand trucks that turn into carts (example) and other items to secure your gear to the cart like sturdy cases and straps Always keep a minor first aid kit handy, I sliced my finger open while moving our overloaded and improperly secured hand truck :( Consult with the hotel and determine the best place to load in your gear rather than just showing up at the entrance Ask the hotel if they can print 8x11 signage or if you can do it yourself, some hotels are really picky about this And above all else keep your cool. Putting classes together is hard, teaching classes is hard, don't make it more difficult by blowing your top

Many thanks to the following hombres/hombrettes (alpha order): Alfred, Carissa, Dave, Linda, Ray, Vanessa and the conference staff at the Fontainebleau

Predicting your future from past reports

You, as a security consulting customer, have a relationship with your security vendor. However, your vendor could be providing you with more value then you may currently be receiving in your partnership. For example, one thing Immunity does with our repeat customers is that we review the entire years worth of assessments and find patterns that can say surprising things about the enterprise.

In order to do this I take every deliverable that Immunity created from that year and extract the details about all of the vulnerabilities found and create a master list of findings. Then using the information gathered from the master list, I prepare a presentation for each our clients which provides a years worth of results in a quick and easy to read format. A sample of the information you can expect to receive is:

A sample comment can be "You only had a few denial of service issues, but if you remember, those were all critical issues that could end a business line."

I then review the presentation with the client and answer questions such as:

•What kinds of engagements did Immunity work on over the course of the year (i.e web applications, custom software, third party assessments, etc.)?
• Are there repeats of the same type of vulnerabilities across different platforms/applications and if so where and how much does it appear and what is the threat level?

This is obviously a chart from a full year...if you have 39 critical findings from one engagement then you are splitting vulnerabilities up with too much granularity.

•What percentage of vulnerabilities found were critical, high, moderate and low. How does this compare to prior years?
•Do the majority of the vulnerabilities come from third party applications or from in-house developed applications?

An example conversation that I may have with a client when discussing the annual recap is that it appears that they got a hold of cross-site scripting vulnerabilities but SQL Injections still remains a problem when compared to the previous years. Or perhaps that every application that does high-frequency trading has huge amount of consequential vulnerabilities (a.k.a - this is a risky business line so do you accept the risk to gain the reward to do you search for another product?).

If your security vendor is not providing you with this value then you are missing out!