Web Hacking 2014, lessons learned

We've done Immunity's Web Hacking class five times now and each time we learn something different. This blog post is going to incorporate some lessons from both the public Infiltrate 2014 class as well as a private class we did for a client.

Create a minimum and maximum duration for topics -- Web hacking takes place over 3-4 days, with 7 hours per day of instruction. The maximum amount of time we want to spend on any one topic is therefore 7 hours. In my experience 90 minutes is the minimum amount of time it takes to introduce a topic and have students complete a few hands on exercises. As an example, we can introduce XXE and have students exploit a straight forward vulnerability in probably under 90 minutes. But getting the HTTP and FTP out-of-band techniques is a bit more complicated.

What is the minimum time needed for a topic? -- Some things can't really be meaningfully condensed, in our experience if you want to successfully exploit a padding oracle vulnerability under real world constraints we need 7 hours to get you there (assuming you have no prior experience). Likewise we can give a good introduction to XSS and have you practically exploit (i.e. more than just popping alert(1)) a few bugs in about 2 hours.

Topics must be modular -- Prior to the private class we'd basically always covered the same things in our web hacking course. This client wasn't interested in PHP or Open Source Information Gathering (OSIG) so we had to cut those from the course. By keeping each topic isolated we could add and subtract content pretty easily and shuffle the order in which we covered topics. This is to say that no part of XSS should depend on completing the Command Injection topic, intra topic dependencies are ok and unavoidable.

In order to be modular you need a lot of content -- The PHP and OSIG modules combined for around 6-7 hours worth of content, since those weren't being covered we had to dramatically expand the content of each module to make up the difference. We've got around 5-6 hours of XSS content available and now we can fit this topic into any length slot based on customer need.

Testing things at scale -- One of the big 'whoops' moments we had for the Infiltrate version of this class was the scoring server breaking. We'd tested it prior to the class but came to find out during the course that the sqlite3 backing DB was not up to this particular task with the number of students we had. So, Miguel had to convert to PostgreSQL during the lunch break.

Better score reporting -- When we started the class in 2012 we had a dedicated war games type portion of the class after we'd covered all the content. In each subsequent class we've cut down on the war games portion in favor of covering more content but kept the scoring, completing in class exercises awarded tokens of a certain value, the student with the highest score at the end would win something (this year, a plaque!). We're going to spend some development time getting better scoring reporting for the instructors so we can track who hasn't completed a particular exercise a bit easier. We will probably do away with the dedicated war games portion in favor of spending more time on certain topics.

After hours access -- For each iteration of this class we've run into the situation where students want to keep working but the class had ended for the day. Typically we stop teaching at 5:00PM and call a hard stop at 5:30 but many students want to continue working. We've considered hosting copies of the exercises on a private VPN that students can access from their rooms if they wish and we may put some engineering time into that before the next Infiltrate.

ircd and collaboration -- Esteban had the great idea to host an in class ircd that would allow for greater collaboration if students wanted it. Some people might say "create a Sharepoint site" or "start a wiki", communicating effectively over IRC is a skill your attackers have so you should learn it too.

Fit and finish matter -- Aesthetically this class is almost 100% powered by Bootstrap. Use design to make accessing information easier and more pleasing. This goes a long way towards streamlining the class. Especially when students don't have to ask you if an exercise is broken because all you have is a single input field and an unhelpful HTML title.

Be more than vulnerable -- Students tend to be more engaged when interacting with applications that serve some purpose outside of just being vulnerable. One of our XSS exercises allows students to make web comics, another is a front end for a network ACL complete with listening service you need to connect to. Sometimes when you have to teach a very specific concept, zeroing in on that functionality is unavoidable. But we try to make the page easy to hold a student's interest and that comes by adding a bit of functionality.

"The Brain Stealer", Heartbleeding partial keys, etc.

One thing about bugs like Heartbleed is that they give you random memory contents. And sometimes these memory contents include an entire private key, and sometimes they do not. What can you do with a partial RSA key? Well, often you can solve using an SMT solver for the rest of the key! How cool is that? 

I mention this because it is something I did not know until yesterday, when Ronald walked me through part of the Immunity Master Class, which is being taught at INFILTRATE here in Miami next month (May 19th-23rd). And it's one thing to know that this is possible, but it's a whole different thing to have code to actually do it. 

That's why I love the Master Class, because no matter how good you are there is still a lot to learn in our industry even at the most technical level, and it's often stuff you can put directly into your high level research efforts. 

I personally grew up on Unix hacking. There are dark corners of the Solaris operating system that I'll never forget, like my first girlfriend's foibles. But I didn't realize how poorly I really knew Unix until I saw how Ronald puts the entire Kernel and Userspace together in his head when writing an exploit. So I often sit in on the Master Class to learn Unix hacking from one of the few people who I know is empirically better at it.

And of course, when it comes to SMT solvers, the whole world is still learning where they can and cannot go. As part of that, Immunity did a DARPA project to work on something called ILLITHID, which finds vulnerabilities by doing symbolic execution.

And as of today, we're announcing that because we're going to be extensively using ILLITHID (click here to see it in action) in class, students will be eligible to receive a free student license (i.e. non-commercial) for ILLITHID to take home with them. This is currently the only way you can get ILLITHID, and frankly is worth the price of admission alone!

If you're interested, send an email to admin@immunityinc.com and sign up or ask us for more information! (A detailed description of the class and INFILTRATE itself is here.)

"Unethical Hacking" Training available at INFILTRATE 2014!

One thing about the Unethical Hacking training happening at INFILTRATE 2014 is the advantage technology investments have improved the way people learn buffer overflows. This class is pretty unique in that we've run hundreds of people through it who have only basic programming skills, and at the end of it they are doing assembly language, writing intermediate level Windows buffer overflows, and have an accurate picture of how the process of taking a vulnerability to an exploit works. 

Part of the secret is VisualSploit, and the 2.0 version is an amazing improvement. As you can see below, it runs within your browser, and you drag and drop the components into it to reflect your understanding of how the program stack is behaving. You're writing exploits, but naturally, without coding at all.

A simple example exploit from class - VisualSploit, Immunity Debugger and your brain are all the tools you need!

Some of the blocks wrap quite complex functionality and calculations such as a jump from one block to another one. This makes learning the whole process thousands of times easier for students who are not already assembly language experts by avoiding hard to find typos.

A much more complex version of VisualSploit - coming up with the building blocks of an exploit can take four hours, but it's an intensely educational four hours!

So in summary, by taking the requirement that you know how to code Python or some other language out of the class, it more effectively and reliably teaches people how to write exploits. You come in knowing just a little bit about programming, and you walk out a completely changed person. I've seen it hundreds of times which is why it's my favorite Immunity class to teach. It's less frustrating, and more fun, simply because we invested in the tools to make the learning process better.

So sign up or call us for more information!
infiltrate@immunityinc.com
(p) +1-786-220-0600

Web Hacking Language Review

In a lot of respects the rewards for web exploits are more immediately accessible than complex memory corruption exploits. Part of the reason is that web applications are designed to be more accessible than the musty insides of a kernel. The amount of knowledge you need to be efficient at web hacking and to really understand it can be daunting, especially if you don't come from a programming or systems engineering type background. We've observed a bit of a disparity in the skill sets of our students for Web Hacking, some come from a web application development background and the basics of the HTTP protocol are well known to them. Other students may not have a firm grasp on that subject matter so we're addressing that with the Web Hacking Language Review.The language review is a one day intensive designed to give you the basic fluency needed to be productive in the Web Hacking class itself.

The very first thing we do is a practical look at the HTTP protocol. You'll be interacting with simple web applications and viewing your traffic through various proxies and Wireshark to get a feeling for what's actually happening, we'll talk about useful information contained in the HTTP response headers and so forth.

Our next stop is Linux command line fundamentals. Many people are daunted by the power of the Linux CLI and try to stick with more GUI centered tools and operating systems. It's true that the Linux CLI is extremely powerful and therefore complex but understanding basic usage, file system layout and how to ask the OS for help will provide you with the confidence you need to start using Linux as your primary OS for penetration testing.

Python is the in house programming language at Immunity, all of our products rely on it and we write it every day. A key part of our educational philosophy is that you need to be able to implement an attack to really understand it. That means being able to write it up and for us (and you) that means Python. We'll be spending time giving you hands on experience setting up PIP the Python package manager and writing simple but effective scripts in Python.

JavaScript is everywhere and thanks to projects like Node.js is now doing everything. Having a firm understanding of JavaScript is essential for assessing Web 2.0 applications, Node.js applications and making your XSS do more than just shout alert('XSS!!!'); We'll be covering some of the language fundamentals and giving you some directed experience in writing JavaScript.

MySQL you can't really understand SQL Injection unless you understand SQL and MySQL is one of the most popular relational databases in use today. Virtually any PHP application will have a MySQL option for data store purposes and many applications depend on some type of SQL database (Microsoft SQL, PostgreSQL, Oracle, etc). During this class period we will provide you with a SQL database and help you extract data from it to understand what types of SQL queries you'll likely come into contact with in the wild.

This class review gives you the background you need to get the most out of our Web Hacking course. If you're not confident in any one of the above sections I would encourage you to come to the course and take the refresher because during the proper Web Hacking course we won't be covering these fundamentals.

For more information contact sales@immunityinc.com and get a quote for the language review!

Real World CANVAS

One of the things I really like about CANVAS is its adaptability. Often when we do a penetration test or application assessment for a customer we'll come up with an attack that isn't a straight forward “run this module, receive root” type of attack. That's where CANVAS' adaptability comes into play for us.

During the heady days of summer 2013 my trusty colleague @markwuergler and I were dispatched to the west coast on an extended consulting engagement. We undertook a Phishing attack from the position of an attacker with access to the internal network (come see more details about this at my PyCon lightning talk). We cloned their internal web based email login page but modified it such that when users posted their credentials it was logged by us, the users were then redirected to the legitimate page and presented with a password error. The logging gave us a key set of information: their internal IP, username and password.

Mark cooked up some magic with Python WMI where we reflected the credentials back at the originating IP, created a new share, uploaded a custom HTTP SSL Trojan to the host and executed it. This didn't give us a 100% success rate as not all users had sufficient permissions to use our upload and execute method but we still came up with a high percentage of compromised hosts.

Since we were going to have CANVAS code running on the remote hosts, we tweaked CANVAS's startup.py script which is run on every new node that connects to CANVAS. For this particular engagement all we did was check our privileges and take a screenshot of the compromised host for reporting purposes. However CANVAS allows us to make automated decisions about our privileges, choose to escalate if needed and then dump password hashes or start monitoring the host's network traffic. In our situation, because the folks checking their mail could be doing so from computers where downtime or lost data would be catastrophic, we had to limit ourselves to something safe. So extensive post exploitation actions including memory corruption based privilege escalation were out.

A lot of work went into this particular attack and CANVAS saved us a lot of trouble. Once we came up with the plan only about 1 day of prep was needed, if we had to implement all that CANVAS helped us automate it would've taken weeks.

This raises the question, if an attacker is in a position to carry out these types of shenanigans on your internal network how do you defend against it? Mark and I had already modified the Trojan to bypass detection by the anti-virus installed on the network, so AV would be of minimal help. One of the limitations of this attack was that we had to touch disk to infect the hosts. A defender can take advantage of this using another Immunity free product, El Jefe, which watches process execution across an entire enterprise. With a little bit of Python elbow grease you can code up an alert which would let you know when a new binary is executed on more than a set number of internal hosts within a certain time period.

As I've participated in consulting with Immunity over the past 5 years one of the questions I've learned to ask myself when writing reports is, what will the client do with this vulnerability information? This attack wasn't that surprising, an attacker with access to an enormous internal network has the ability to run some frightening attacks. What the client does with this is not apply a patch or modify an ACL but it is to start looking at data they hadn't considered before and then figuring out what else that data can tell them about how their enterprise REALLY works. Pen-testing is fundamentally about telling your client something they didn't already know and in this instance I think we did exactly that.