• Social Zombies: Rise of the Mobile Dead w/Kevin Johnson - Monday, March 11th, 7:15pm – 8:15pm
• “Hall of Shame” Apps in the Apple App Store and Google Play - Wednesday, March 13th, 8:15pm – 9:15pm

This is a great opportunity to see Social Zombies again if you missed our talk at DerbyCon last year.  Registered attendees of SANS 2013 get into the talks for free!  If you see me at the conference next week say hi and feel free to harass Kevin if you’re taking his class!

Share and Enjoy

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.

Share and Enjoy

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:

victim@victim.com:password

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:

victim@victim.com:5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8

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:

  victim1@victim.com:password1
  victim1@victim.com:password2
  victim2@victim.com:password1
  victim2@victim.com:password2

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

Share and Enjoy

COURSE DETAILS:

Security 542: Web App Penetration Testing and Ethical Hacking
Start date: Thursday August 23, class will run over 10 weeks, 6:30-8:30pm
Details and tuition visit: http://www.sans.org/info/106395

Where: SecureState
23340 Miles Road
Cleveland, OH 44128

This local course will be offered in a multi-week format via the Mentor Program. Each week I will answer questions and assist you with hands on labs and exercises during the class. Mentor courses give you the opportunity to participate in SANS training without the expense and inconvenience of travel or being out of the office during the workday.

An outline of the class is as follows:

- Learn an attack methodology and how the pen-tester uses JavaScript within the test
- Study the art of reconnaissance, specifically targeted to Web applications.
- Start the discovery phase with a focus on application/server-side discovery.
- Flash objects and Java applets.
- Exploitation

The class wraps up with a Capture the Flag event where the students will be able to use the methodology and techniques explored during class to find and exploit the vulnerabilities within an intranet site.

I hope you can join me in August and earn your GWAPT Certification in 2012!

On the other hand because of Security BSides and other smaller conferences over the years more unknown speakers are getting out there. We’re also seeing more great talks and discussions then ever before because of these smaller conferences. This is a good thing for our industry. Many good talks still get rejected from the big conferences like Black Hat and this is where conferences like Security BSides really shine. However, we potentially run the risk of seeing the same speakers, same content and as Matt said we appear to have an “echo chamber problem” at all of these conferences including the big ones. Is anyone else seeing this trend? Does the overlap of multiple security conferences matter to you? Like any trend in technology are we about to bust the “Security Conference Bubble”? I often wonder what the security conference world will look like in a few years if this trend continues.

Share and Enjoy

I hope to do a review of this book soon. So far it looks to be a good technical read.

Share and Enjoy

1. The Mobile File System
How’s the application storing data and where is it being stored?  You’d be surprised how much information is being stored in files, SQLite databases, system logs and more.  If you’re lucky you will sometimes find private keys and hardcoded passwords.  As a great example, the mobile Facebook application suffers from a file system vulnerability as I write this.  The author likes to call this a “plist hijack attack”.  Simply move the plist file to another mobile device and you are logged in as that user.  As for tools to use when looking for file system vulnerabilities you should really check out the forensic approach that John Sawyer from InGuardians has developed.  It’s my preferred method for seeing how the app writes to the file system and saves lots of time over creating a dd image.

2. The Application Layer
How’s the application communicating over HTTP?  How are web services being used and how are they configured.  Important things such as authorization and authentication need to be reviewed as well as session handling, business logic, input validation and crypto functions.  Business logic needs to reviewed just like you would in a Web Application Assessment to find flaws in the way critical functions (like shopping cart checkout processes) were developed.  Remember to never under estimate the criticality of Web Services!  For reference and context, check out the presentation that Josh Abraham, Kevin Johnson and I gave at Black Hat USA last year.

Something else worth mentioning is that you can’t rely on traditional web proxies like Burp Suite to test the application layer on a mobile app.  I’ve encountered applications that are configured to bypass device proxy settings!  You need to use a tool like Mallory which is a fantastic TCP and UDP proxy.  Mallory sees all traffic and allows you to manipulate and fuzz it.  There are other ways to do this as well but regardless, you need to have a way to see all traffic the mobile app may generate.

The application layer is also where you need to look for issues specific to mobile applications like UDID usage in iOS.  UDID is currently being used by many applications for unique device identification.  However, the use of UDID is becoming an increasing concern from a privacy perspective.  Not to mention, Apple is cracking down on UDID usage by now denying applications in the Apple App Store.  Check out the presentation I did at OWASP AppSec DC this year about some of the privacy and security concerns regarding UDID.

3. The Transport Layer
How does the application communicate over TCP?  How are custom protocols and third-party APIs used?  Does the application use SSL?  At OWASP AppSec DC we talked about the LinkedIn mobile application that was vulnerable to “sidejacking” or better known as HTTP session hijacking.  This is where an attacker can pull out the session cookie in clear text and replay this so the attacker can login as the user.  The popular “Firesheep” tool released in 2010 demonstrated this nicely.  The good news is that the recent release of the LinkedIn app (version 5.0) fixes the sidejacking issue.  Unfortunately though, using SSL for just the login process and defaulting back to HTTP is an issue many mobile and web applications still have.

Mobile Application testing is something that will evolve as mobile apps get more complex and the business drives more towards mobile solutions.  If you’re deploying mobile apps for your business it’s more important than ever to have testing done on these three areas at a minimum. Lastly, keep up-to-date on the latest developments on Mobile security and testing methodologies by getting involved with the OWASP Mobile Security Project.

Cross-posted from the SecureState blog

Share and Enjoy

Share and Enjoy

Share and Enjoy

One update we forgot to mention in the talk is that you should use Mallory, which is a transparent TCP and UDP proxy for testing mobile applications.  This is an excellent tool created by the guys at Intrepidus Group.  We’ve found that some apps will bypass proxy settings and lots of apps are sending data over binary protocols and more.  Mallory is the tool you need for testing any mobile app fully!

Just a reminder that I’ll be presenting Smart Bombs: Mobile Vulnerability and Exploitation with John Sawyer and Kevin Johnson at OWASP AppSec DC on April 5th in Washington DC.  I’ll be focusing my research on iOS application testing and some of the vulnerabilities discovered in some of the top 25 iOS applications.

Share and Enjoy

Share and Enjoy

What I liked most about this event was that there were plenty of “real world” talks on how enterprises are deploying and managing mobile deployments.  Real in the “trenches” types of talks.  Here are some of the themes that I heard throughout all the talks:

• Jailbreaking/Rooting is BAD
• The OWASP Mobile Top 10 is going to be just as important as the traditional web application OWASP Top 10
• Mobile Threats are an evolving, moving target.  Security teams have to be quick to adapt to new mobile technology
• MDM (Mobile Device Management Solutions) are a requirement
• Apple iOS devices are preferred over Android in the enterprise (seriously, that was the consensus).  No one seems to care about BlackBerry or Windows Mobile devices.  I think only one speaker mentioned Windows Mobile…

Speaking to the last point I find this pretty interesting.  Especially given the fact that Android seems to be beating Apple in regards to market share of devices and app store apps.  I also enjoyed hearing about some of the challenges and pitfalls real IT and security departments are facing.  Many of the speakers talked about some best practices they’ve developed and problems they’ve had.  One of the highlights for me was a talk by Det. Cindy Murphy from the Madison WI Police Department Computer Forensics Unit.  She shared some of her experiences with mobile device forensics and how this evidence holds up in court.  I highly recommend you check out this summit next year, it’s one not to miss!

I should have my slides from the latest version of my talk that I gave at the summit (Attacking & Defending Apple iOS Devices in the Enterprise) in the next day or so.

Share and Enjoy

I did some research and found this blog post which says this is simply a configuration issue with the passcode settings.  Check your setting for “Require Passcode” (under the Passcode Lock screen) and make sure it’s set to “Immediately”.  If it’s set to 1 minute or more, you really haven’t locked your device.  You’ve just been shutting off the screen.  See the screen shot below for the passcode setting you should be using.

Share and Enjoy

Share and Enjoy

#1 – The Passcode
This is the most important security feature of your device. It’s also one of the least configured settings. While it may be a pain to “unlock” your device when you want to use it, it’s also your first line of defense if your device is ever lost or stolen. The key to the passcode is to ensure its complex and greater than 4 characters or digits. Never use simple passcodes like “1234” or your ATM PIN number. The two other settings that you need to set are to “Require Passcode Immediately” and set “Simple Passcode” to OFF. You can find these settings under the “Settings” icon then “Passcode Lock”.

#2 – Erase Data
The erase data functionality adds another layer of security to your device. This function will erase all data after 10 failed passcode attempts. What this means is that if someone steals your device and tries to brute force your passcode, if they enter it incorrectly, the device is erased and returned to the factory default settings. Turn “Erase Data” to ON in the Passcode Lock screen.

#3 – Find My iPhone/iPad
If you ever lose or misplace your iPhone or iPad, “Find My iPhone/iPad” is a very important feature to enable. Simply download the application on your device or access it through iCloud (icloud.com). If your device is iOS 4 or below you will need to use the “MobileMe” (me.com) feature instead of iCloud. Either way, you will need to login with your Apple ID to set it up. You can then send the device a message or alert, locate the device on Google Maps, remotely set a passcode, and remotely erase the device. This feature is invaluable if your device is lost or stolen.

#4 – Backup Encryption
One of the more obscure settings that many users don’t set is the “Encrypt Backup” setting, which is found in iTunes. This setting even applies to the new iCloud service in iOS 5. This setting ensures that the backup of your device is encrypted. It goes without saying, if you can access this backup, the data on your device can be accessed and harvested. For example, earlier last year there was a “feature” in which Geolocation data could be easily harvested from the backup file. This has since been remediated, but just think how much information could be harvested about you through an unencrypted backup file.

#5 – Keep iOS Updated
Making sure that you always have the latest version of Apple iOS on your device is important because Apple is always releasing security updates and implementing new security controls. Simply plug your device into iTunes and you will get prompted to update your phone to the latest version. As a side note, don’t Jailbreak your device! Jailbreaking makes many of the built in security features useless and allows your device to be an easy target for data theft.

Ensuring that you have enabled and configured these security settings on your Apple iOS device is more important than ever. Devices like these are lost or stolen all the time and without taking the proper precautions, your data could be vulnerable. Having conducted Apple iOS device penetration testing assessments at SecureState for our clients, I can tell you how easy it is to break into these devices. It’s easy because the proper basic precautions were not taken. Take five minutes now and enable these settings; you’ll be glad you did.

Cross-posted from the SecureState Blog

Share and Enjoy

Probably the easiest Jailbreak tool out there as well…

Share and Enjoy

Share and Enjoy

Share and Enjoy

Download the white paper.  Download Josh’s Metasploit modules.  Download Kevin’s vulnerable web services.

Share and Enjoy

See the full gallery on Posterous

Share and Enjoy

UPDATE (5/27): I found a very nice script by Patrick Toomey which can dump the contents of the keychain on Jailbroken iOS devices.  More details about how the script runs can be found in this blog post.  Note that the type of information you get back depends if the passcode is enabled or not.  You will get more keychain entries back if the passcode is not enabled.  I had mentioned in my presentation that I hadn’t found a script to do this yet…well here it is.

Share and Enjoy

Share and Enjoy