"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.

Tales from consulting, part I

Mark and I just returned from a long consulting engagement, at 3 weeks on site it was one of the longer (if not the longest) trips I've taken for Immunity. I'd like to share a few things that worked, didn't work and that I would change. There will probably be a number of these posts in the future from both Mark and I.

Physical Pen-testing:

1) Simple is better. One of our tasks was to try and get into some restricted areas by posing as someone else. We made a modest investment in clothing and equipment so that I could try and blend in. While this was successful to a certain degree what ended up working best was just being what I was, an IT guy. Throw in a Fluke network tester and a keyboard as a prop and you're set to go.

2) Badges? Our client was using badges which required mutual authentication and would have been difficult to clone with the equipment we had on hand. So we took some high resolution pictures of legitimate badges, used some photoshop wizardry (courtesy of Mark), printed it out on sticker paper and created a new "badge". Any time I had to get into some place I shouldn't have been simply asking someone near by to buzz me in because my badge was "bent" worked like a charm. If you do these kind of gigs regularly investing in a card printer may be worth your while if you expect a high level of scrutiny.

3) Physical keyloggers are ridiculously effective. I'd used USB keyloggers before but they always surprise me with just how useful they are. We planted ours in conference rooms and general computing facilities and wound up with almost 40 sets of credentials over a two week period from just 4 devices. A tool like the Power Pwn would've been very nice to have as well.

4) A quick and silent way to take photos. I learned that the camera clicking noise my phone makes can not be silenced. Dave suggested some sort of slim video recording device we could attach to ourselves but I wasn't impressed with the resolution of the devices I looked at. A small, high resolution, quick shooting camera would be ideal.

5) Have a story for why you're there. One ruse I used was that one of my coworkers from the IT department had misplaced a piece of equipment in this general area over the previous week. I would ask the secretary or anyone close to the entrance if I could poke around to see if I could spot it. This got me anywhere I wanted to go, including locked conference rooms. The pretense of repairing conference room keyboards (and showing my keyboard prop) also got me out of a number of surprise visits from people coming in to use the room.

6) Don't over think it. Unless you're getting into a datacenter or an IBM campus to most people technology is magic and you can use that to your advantage. I had a trojan I carried around on a USB key that I would pop into open workstations. We debated on what I should say if I was challenged. "I'm here to inventory this system for IT" was simple but the question was raised amongst ourselves: "are you doing an inventory of hardware or software and if you're an admin you could just do this over the network..." Most people don't care about these details, inventory is a thing that IT does, you look like a nerd, therefore your story probably checks out.

Things to note:

a) When placing keyloggers or doing hardware work always make sure you have a minimum set of tools with you: screw driver with flat/philips/torx bits, headlamp and maybe a lock pick and shim set for getting into cabinets.

b) Know the schedule for the area you're getting into. If it's a conference room, when do you need to be there? Work area, when is shift change? Be familiar with the names of the areas around you, what department is on a nearby floor, who is the admin in charge of scheduling this room, etc.

c) When getting a USB keylogger be mindful of the form factor, some PCs have tight USB clusters and if your keylogger is fat enough it may block other ports that you need. Having a short F->M USB cable handy is good for quick fixes.

d) Practice, practice, practice with your picks and your shims. Beating a lock on your bench in an air conditioned room is easy. Beating the same lock in a dark room where you shouldn't be with no AC and under time pressure is hard. On this gig I got 0 locks and 1 shim, ultimately I found other ways to solve my problem but I clearly need practice.

Conclusions:

Over the past 5 years doing consulting gigs for Immunity it's been my experience that when we're on the inside of a network and our scope is sufficiently open then there's always a way to win. The same is true for physical pen-testing, if we have access to your space (or sometimes just in range) then we're on your network and we'll almost certainly have credentials. One of the most surprising things we learned was that our USB key logging was approximately as effective as our phishing was at obtaining credentials. While credentials aren't shells, as I've mentioned it's not always about shells. If the data you need doesn't require code execution to get then this is a boon for your stealth.

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!