Category Archives: Penetration Testing

Teaching SANS SEC542: Web App Penetration Testing and Ethical Hacking in St. Louis July 8-13

Filed under Application Security, Penetration Testing
Tagged as ,

Just a quick update to let everyone know that I’ll be teaching SANS SEC542: Web App Penetration Testing and Ethical Hacking in St. Louis July 8-13th through the Community SANS program.  This is a fantastic 6 day class with lots of hands-on exercises, sharing of my real world web app testing experiences and a Capture the Flag event in which students will be able to use the methodology and techniques explored during class to find and exploit vulnerabilities within an intranet site.  I’m very excited to teach you the skills required to be a great web application penetration tester!

Check out the SANS class information page for more information about the class, agenda and location.

Save 10% on your registration using code: TomStLouis

See you in St. Louis!

Project Mayhem to be Unleashed at Black Hat Abu Dhabi

Filed under Penetration Testing
Tagged as , , , ,

For the last several months I’ve been performing research on techniques attackers could use for performing accounting fraud in popular accounting systems. This research coincides with a whitepaper that SecureState has developed entitled “Cash is King: Who’s Wearing Your Crown?” To perform this research I have collaborated with a coworker of mine, Brett Kimmell, who is the manager of SecureState’s Risk Management practice. Brett and I will be presenting the findings from our research at the Black Hat security conference in Abu Dhabi on December 6. This is by far the most unique topic I’ve researched in that we’ve combined penetration testing techniques with ways to commit fraud and more importantly, showing real world accounting fraud prevention. Brett Kimmell is a CPA and has many years of experience with accounting and fraud detection. He was also the CFO for a large non-profit organization. Combine this skill set with penetration testing and cutting edge malware development and you have research that truly demonstrates attacks that literally hit the “bottom line” of a company. As a penetration tester I find that gaining access to customer data, passwords, credit cards, PHI and other standard fare (ie: Trophies) are just the beginning of what can damage a company. In this research we take it to the next level and show the damage that can be done where it truly hurts a company: the financial system. It’s my hope is that this is just the start of showing organizations’ true business risk through advanced penetration testing.

In our work we’ve focused our research on Microsoft Dynamics Great Plains (GP). GP is the most popular accounting system used by small to midsized businesses across the world. In our research we show how attackers can commit undetectable fraud by manipulating accounting systems like GP. These attacks are quite different than finding and exposing a 0-day in software, as our research is centered on creating attacks (including custom created malware) that specifically targets a company’s accounting processes. The attacks we illustrate in our research show that technical controls cannot be solely relied on to prevent fraud. Non-technical accounting controls must be implemented and proper oversight maintained to be effective in combating modern fraud.

Next week we will be releasing our whitepaper as well as “Mayhem”, which is proof-of-concept code designed to hijack and manipulate the accounting processes within Microsoft Dynamics GP. Mayhem was created by the talented Spencer McIntyre of SecureState’s Research & Innovation Team. Mayhem is actively being developed but even in its current state (which we will demonstrate at Black Hat) will make you take a hard look at how a company needs to defend against this type of threat. Similar to how banking Trojans have targeted banking consumers in recent years, Mayhem is the first type of attack that we know of that targets the accounting systems of a company. While we focus on Microsoft Dynamics GP in our research, it can be easily ported to other types of accounting systems. Stay tuned next week as we reveal details about Mayhem and how our research puts a new focus on accounting controls.

Burp Suite Series: Efficient use of Payload Options when Attacking HTTP Basic Authentication

Filed under Application Security, Penetration Testing
Tagged as , ,

In this series of blog posts I’ll be discussing some handy Burp Suite techniques we often use on our penetration tests.  Burp Suite is our de facto tool of choice for assessing web applications and conducting web based brute force attacks.  First up are some techniques to use when conducting brute force attacks on websites that use HTTP Basic Authentication.  While simple brute force attacks are easy to set up in Burp Suite (think form based authentication) not a lot of tutorials exist out there for how to brute force HTTP Basic Authentication, especially if the password is not in clear text like you might usually find it.

How HTTP Basic Authentication Works

HTTP Basic Authentication works by Base64 encoding the username and password in the HTTP header.  It looks like this in a web request:

Authorization: Basic dmljdGltQHZpY3RpbS5jb206cGFzc3dvcmQ=

Running this through Burp Suite’s decoder function (Base64 decode) gives us the following:

As you can see, the username and password are in clear text.  Not a good option for authentication since this can be easily sniffed off the wire with a network sniffer like Wireshark, which is why these credentials should ideally always be going over SSL.  Besides the clear text security issue, using HTTP Basic Authentication provides the penetration tester with a convenient way to brute force the password for users of the system or application.  Typically you will find HTTP Basic Authentication used for web access to network management devices. Also, some websites use this for authentication to their application (and that’s a whole other blog post).  I’ve recently seen more web and mobile applications using this form of authentication.

What if the Password is Hashed?

Occasionally you might encounter a situation where the authentication header does not reveal a clear text password but a hashed representation of the password.  For example, you might see this after running the Base64 string through Burp Suite’s decoder:

In this example, the password is not clear text but is an SHA1 hash of the password.  If it is a guessable password, you can easily use any type of hash lookup table like this one online to lookup this hash.  This SHA1 hash is “password”.  Hopefully that’s not your password. 🙂

Attacking HTTP Basic Authentication with Hashed Password Values

One of the attacks on a system utilizing HTTP Basic Authentication is the lovely brute force attack.  First, get yourself a password list of easily guessable passwords.  I recommend any on Ron Bowe’s website SkullSecurity, especially “500 worst” and “Rockyou”.  Next, submit a request with dummy account information and intercept the request with Burp Suite’s proxy:

At this point you want to decode the Base64 string to see if the password is plain text.  Right click the request and then “Send to Decoder”. Then select Decode As Base64 to reveal the plaintext.

The password is hashed so next find out what type of hashing is used (use a look up utility like Hash Identifier in Backtrack 5).

Once you’ve determined the hash type you can configure Burp Intruder, which will be used to actually perform the brute force attack.  Go back to the proxied request and right click “Send to Intruder”.

Press “Clear” and highlight the Base64 string with your mouse.  Press “Add”. Keep the attack type to “Sniper”. Click on the “Payloads” tab.

Under “Payload Options [Simple list]” is where you want to load your password list. Next, you will need to set your “Payload Processing” rules.  The orders of these rules are very important.  First you want a rule to hash the password using SHA.  Next, you need to add the prefix, which is the username (email) of the account you want to brute force.  Don’t forget the “:” after the username!  Lastly, we want to Base64 encode the entire payload.

Important: Ensure you uncheck the “URL-encode these characters” in the Payload Encoding section.  This will ensure any “==” or “=” from the Base64 string are not encoded in the request.

Other Considerations for More Complex Brute Force Attacks

There are several other ways we can approach this type of brute force attack on HTTP Basic Authentication.  What if you wanted to attack multiple users with one password like “Password1”.  Simply change the payload list to usernames (emails in this case) and in the Payload Processing rules, create a rule to add a suffix.  In the suffix field, add the SHA hash of Password1.  Make sure you include the “:” before the hash value. Then keep your last rule to Base64 encode the payload.  Here are a few other ideas on advanced attacks:

  • Use Burp Extender and perform custom logic to create an attack using the “Pitchfork” or “Cluster Bomb” Intruder functionality.  For example, suppose I want to do a brute force attack using different user id’s and passwords such as:

You can also create a list yourself using a Python script, then replace the payload list with this one and keep the payload processing rules we’ve already defined.

Happy Brute Forcing!

Re-posted from the SecureState Blog