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!



Deliverables and how they evolve

There's a lot about doing quality security services that is not, as we say, self evident. One of these things is that every gig is different. Today Mark and I and Shari and Bas worked quite a bit on a particular gig that requires an "expert opinion". Essentially you take someone else's deliverable, look at the same evidence, and then decide what they may have missed, or what questions to ask next. 

This kind of service is extremely valuable when you have multiple parties involved with multiple conflicting interests and you want a technical readout on the facts as they stand. A good security consulting company can come to the table both without an agenda, and with years of experience in the technology and ideally, in the specific customer vertical you are addressing.

Now, in security consulting, you never have all the information you want. You can always use more time, or more data, or the logs off some random machine, or the source code to some piece of the puzzle. But the deliverable has a due date.

Occasionally, however, you find halfway during your review process that things you (as a team) think about are made clear. For example, you may find that your understanding of the threat model becomes more focused as you write the deliverable. 

For example, today we were looking at something where hackers broke into a system using SQL Injection. We were initially curious why none of their tools were manually deleted, yet were still not available on the system, when we realized that they used a remote webdav file share to both store their tools and exfiltrate data. This then revised our understanding of the outbound firewall ruleset, which led us into other areas of analysis that needed to be re-addressed.

In other words, from the client's perspective, this is what the process looks like:

But what consulting looks like when you do it right is this:

That analysis phase is the hardest phase. I will bullet list some reasons below:

• It requires consultants with years of experience - the most senior members of your team. These people are often so valuable in other areas that you have to fight for their time.
• Consultants hate being told they are wrong (and especially hate rewriting documents they have already put time into). Being able to have frank discussions about rethinking conclusions and then making the painful decision to redo a document means you have solved the social aspects of the workplace to a high level.
• Your process has to have enough fluff time at the end for documentation that you can afford to go back and do major revisions. It is likely you are under price pressure, and have already strictly cut the time for your project down as far as it can go. Only a confident (or lucky) company can keep their scoping up high enough to allow this kind of process to occur.

Aside from better deliverables (let's face it, you may end up getting paid the same either way), there are other major benefits to implementing this expensive process, for example, knowledge transfer within your consulting team. 

But as a client, one good question when getting a deliverable from a consulting services company is simply: "How many people within your organization who did not work on the project have READ this deliverable?" If the answer is none, you got shortchanged.

This year's top complex web attack

My two year old is learning to count. As far as he's concerned, it's just a fun way to chant while in the car. However, I will say that one of the things we see over and over in our assessments of web applications is web developers thinking that we cannot count!

In other words, you will often see this in hand-written web applications:

https:///www.example.com/webapp/getfile.php?fileid=5121

This is obviously better than having file="\path\to\file.txt", but at least 90% of the time there is no access control on fileid, and every user can browse every other user's files by simply incrementing and decrementing 5121 to 5122, 5123, etc.

I have included an explanatory video of this amazingly complex hack below! :>