Tuesday, April 14, 2015

MobiSec 2.0 Awesomeness Unleashed!

MobiSec has undergone a major reconstruction and version 2.0 (actually 2.0.1) is now available for download on SourceForge.  The popular mobile testing VM platform has been rebuilt on the latest Ubuntu 64-bit LTS.  The tools have been modernized through updates and by replacing deprecated tools with better-supported equivalents.  The environment has also been trimmed down in size by removing some heavy-weight tools that are typically not used during mobile-specific testing.

If you are getting into Mobile Pen Testing, keep an eye out for our upcoming classes.  The next one is   at BlackHat (details and registration here)!  This class will walk you through the MobiSec environment, tools and testing methodology.  The other really cool things we have in store for this class are Android in a VM, which is much faster than using the Android (AVD) emulator; and we have a rockin' scavenger-hunt style CTF to test your new skills!

For those who still need to perform mobile testing of older platforms we recommend using the latest 1.x release of MobiSec as it is a 32-bit environment and some of the legacy tools built exclusively on 32-bit architecture have not been successfully ported to the new 64-bit VM.

Jason Gillam is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jgillam@secureideas.com, on Twitter @JGillam, or visit the Secure Ideas - ProfessionallyEvil site for services provided.

Thursday, March 26, 2015

Don't Forget the Little Things!

On January 31st, Deusen disclosed what was described as a Same Origin Policy Bypass flaw called "Universal XSS (U-XSS)" in IE 9 through 11 on Full Disclosure.  This zero-day is another reminder of why a "Defense in Depth" strategy is so important, even within web applications.  That's because this particular flaw has to do with the way Internet Explorer handles the Same Origin Policy within IFrames.  Even though this is called a "Universal XSS" flaw, the simple step of consistently returning a properly configured X-FRAME-OPTIONS header effectively inoculates any website by preventing its content from working in an IFrame.

An IFrame (or Inline Frame) is an element of HTML that allows content from one website to be displayed "inline" within the content of another website.  The browser's Same Origin Policy (SOP) is responsible for essentially sandboxing the framed content from any scripts running on the parent page.  This should make it impossible for a script on the main page to interact with content inside the framed page unless both pages come from the same "origin".  Origin is defined as having the same scheme, host, and port.

Having "frameable pages" on a web application is one of those little security details that in many cases gets completely forgotten.  Sometimes the excuse is that not all browsers have the same fix (i.e. X-FRAME-OPTIONS is not supported on all versions of all browsers), so it may require additional effort to protect a website across all browsers (e.g. frame-busting code).  It's also not one of the first things (or even one of the second or third things) a web penetration tester is going to look at because it isn't nearly as compelling as a SQL Injection, XSS, authentication, or authorization flaw.  Depending on the tester it might even be completely overlooked in the report.

I spent some time playing around with Deusen's proof of concept to get a better understanding of what is really going on.  It's somewhat complicated as it requires a specific sequence of requests and thread blocking, but it amounts to a sort of "Time of Check - Time of Use" (TOCTOU) behavior (bug) in the IFrame code in Internet Explorer.  Under the right conditions it is possible to initialize the IFrame with content from one origin (i.e. one the attacker fully controls)  and then switch that content to any website that can be framed without an additional origin check.

The results?  Full JavaScript interaction with the content on the target site, just as if that site had its own XSS flaw.  If a user happens to already have an active session on the target site, the attacker will gain full visibility and control of the content on the website, including the ability to steal the session cookie as long as the HttpOnly flag is not set (another "little thing" that is frequently overlooked).

Deusen's U-XSS disclosure is a great example of why these "little things" should not be overlooked. And it isn't the first example of the emergence of a flaw specific to IFrames.  This reminds me of Paul Stone's whitepaper on Pixel-Perfect Timing Attacks in HTML5, in which he describes another flaw for which simply configuring the X-FRAME-OPTIONS response header will provide a good defensive measure.

We live in a world of wonderful and rapidly changing technology, but it is also a world of vulnerabilities and zero-days that criminals are leveraging for a variety of unsavory purposes.  We cannot anticipate where we will see the next zero-day, but we can prepare for it.  One of the best ways to prepare is to employ a "Defense in Depth" strategy, and this means we have to fix all the "little things".  Make use of X-FRAME-OPTIONS - it's usually very easy to implement.  Make sure all sensitive content is encrypted over SSL.  Properly protect session cookies with the Secure and HttpOnly flags.  Enforce strong passwords.  Sometimes, like with Deusen's U-XSS, it's these little things that make the difference between being exposed or being protected.

Note: Deusen's U-XSS on Internet Explorer was patched in March, 2015.

Jason Gillam is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jgillam@secureideas.com, on Twitter @JGillam, or visit the Secure Ideas - ProfessionallyEvil site for services provided.

Saturday, March 21, 2015

CarolinaCon 11 Slides for Anatomy of Web Client Attack

For those who have asked - my slide deck for Anatomy of Web Client Attacks can be downloaded here.

Jason Gillam is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jgillam@secureideas.com, on Twitter @JGillam, or visit the Secure Ideas - ProfessionallyEvil site for services provided.

Wednesday, February 25, 2015

Adventures in LDAP Injection: Exploiting and Fixing

Every pen tester looks forward to that next encounter that includes one of those uncommon vulnerabilities that ultimately result in an exciting session of exploration and learning.  During a recent web penetration test I ran across one of these rare gems when I started seeing some odd behavior on a forgot password form.  In this case I was fortunate to be working virtually across the table from a development team member who could verify our hypotheses by reading through the code.

We had just determined that this form had a username harvesting flaw, where the email address was the username.  What was really odd is that this username harvesting flaw honored wildcards (i.e. '*').  That by itself made for a really cool twist on a harvesting flaw because we no longer needed a dictionary of email addresses.  After looking into the code, my developer counterpart determined that wildcards were being honored because the email input was being concatenated to a LDAP search filter expression.

After a bit more experimentation we determined that we could not only use wildcards, but also append additional logical expressions (e.g. "And", "Or") to the filter.  Unfortunately since this form does not return the results of the expression we weren't able to pull additional record details.  Then it occurred to me: SQL Injection is much like LDAP Injection, only much more common and better understood.  One form of SQL Injection is known as "Blind SQL Injection", which occurs in situations where a series of yes/no queries can be used to pull information from a database.  It is like a game of 20 questions, e.g.: is there a table that starts with the letter 'a'?  is there a table that starts with the letter 'b'? etc....

So if SQL has its "Blind SQL Injection", doesn't LDAP have its "Blind LDAP Injection"?  It certainly does!  Within seconds we had worked out the syntax to get a yes/no response based on a guess for the first character of the phone number  LDAP attribute for the user account.  Run this through Burp Intruder and we were quickly able to discern the first, second, third character of the phone number.

This was cool, but we were really curious about whether or not we could retrieve a password hash.  We attempted a few different strategies to pull the password and in the end resorted to online research where we discovered that this particular LDAP implementation didn't treat the password as a normal attribute and simply wouldn't return it at all (hashed or otherwise).  Alas... no password.  But we were able to pull several other attributes, the most interesting of which is probably the user's role (i.e are they an admin?).

So we found and exploited a Blind LDAP Injection flaw... but as a pen tester the job is not over yet.  We also have to provide an appropriate recommendation to address the flaw.  Since LDAP Injection is similar to SQL Injection I decided to start there.  First... can we do parameterized queries with LDAP?  In this case it turns out the answer is "no".  The implementation was a JNDI search filter, which is actually just a String.  Unless you pull in third party library that does this for you, there really is no alternative to String concatenation.  That's not very good news for the defensive side, and it only seems to go downhill from there...

What do us security professionals chant when we see injection flaws?  "Input Validation!"  So let's take a look at that with respect to an LDAP injection flaw on a email address.  According to the OWASP Validation Regex Repository, a valid email address follows this pattern:


        ^[a-zA-Z0-9+&*-]+(?:\.[a-zA-Z0-9_+&*-]+)*@(?:[a-zA-Z0-9-]+\.)+[a-zA-Z]{2,7}$

For those who don't understand regular expressions, don't worry about it.  The important thing to note is that the valid email characters include '*'.  This means even with regex-based validation we still have working wildcards!   To address these we need to use output encoding with LDAP's escape syntax, which is to substitute '\2a' for '*', telling the LDAP expression to treat it as a literal '*' instead of a wildcard.  There are actually several more characters that should also be escaped but I have yet to find an up-to-date reference.  OWASP has a Preventing LDAP Injection in Java page that appears to be accurate as of 2008.

So the take-away is: if during a web pen test you at all suspect LDAP on the back end, try wild cards (e.g. *, %) and some LDAP injection payload lists.  LDAP may not provide some of the cool command execution functionality you can get out of SQL Injection flaws but it can still be at least used to gather sensitive data so it is well worth the time and effort.

Jason Gillam is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jgillam@secureideas.com, on Twitter @JGillam, or visit the Secure Ideas - ProfessionallyEvil site for services provided.

Tuesday, February 03, 2015

Professionally Evil Training Event: Multiple classes being offered in Orlando FL April 6-9 2015

Secure Ideas is very excited to announce their training event for April.  We have worked with the Core Group and TrustedSec to create an event that covers a wide variety of training needs.

The event is April 6-9th 2015 and will be held at the Palms International Resort.

We are in the process of getting all of the courses online for registration, but we have three of them available now.  Currently you can register for the 4 day web penetration testing course, taught by Kevin Johnson and James Jardine.  Or you can sign up for Tactical Sec Ops, a 2 day class with Jason Wood.  After that class is finished, Jason Gillam will be teaching Mobile App PenTesting with OWASP Mobisec.  This is a two day class running after the Tactical Sec Ops class finishes.

If you would like more information, or want to register, visit https://www.secureideas.com/classes/

We look forward to hanging out in Orlando and learning some fun and useful techniques.


Kevin Johnson is the CEO of Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at kevin@secureideas.com or visit the Secure Ideas - Professionally Evil site for services provided.

Wednesday, December 10, 2014

Web Penetration Testing with Burp and CO2

Start 2015 right with a free web session to learn all about the Burp CO2 plugin!  This training is scheduled for Thursday, January 8th, 2015 at 2pm EST.

Portswigger’s Burp Suite is a very popular and flexible intercepting proxy tool among web application penetration testers. During this training session I will provide an overview of Burp Suite and how it can be extended to perform functions that are not directly available in the tool. The session will continue with a detailed explanation and demonstration of my Burp CO2 extension suite, using targets in the Samurai Web Testing Framework (Samurai WTF) distribution. Attendees may choose to follow along in their own Samurai WTF VM or just sit back and watch the show. Most CO2 modules will run in both the Free and Professional editions of Burp Suite.

Sign up for training here: https://attendee.gototraining.com/r/2091721179351153665



Jason Gillam is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jgillam@secureideas.com, on Twitter @JGillam, or visit the Secure Ideas - ProfessionallyEvil site for services provided.

Saturday, November 29, 2014

SamuraiWTF 3.0 and into the future!

We are really excited to announce that SamuraiWTF 3.0 is now available publicly.  (We did a previous release but found some issues and so that was pulled back.)  This release is available at http://sourceforge.net/projects/samurai/ immediately and we hope you enjoy it.

In this release we have updated the base operating system to Ubuntu 14.04 (hence the major version number change.)  We have also updated a number of tools and improved the target environments to better suit a training environment.

The project team also wants to explain our new release process which is set up to ensure a regular release cycle, instead of the arbitrary and way to long process we have been following.  For the first 5 years of the project, Justin and I have basically built releases when we had time.  And many of those never actually got released publicly except in classes.  Our plan is to fix that.

As of today, we have set up a release schedule and are assigning responsibilities to ensure that it happens.  We will continue the process that ties major releases to Ubuntu LTS versions.  (Like how 3.0 is tied to 14.04, 4.0 will be based on Ubuntu 16.04)  This allows for people to maintain patches and support for the underlying system for up to 5 years.  Major Releases will occur during the quarter release following the major Ubuntu LTS version release.

We will also be doing quarterly .x releases.  This means that 3.1 will be released around January 31st 2015.  3.2 will then follow around April 30th. (The around is based on upload speeds of what ever location I am at.<grin>)

We will also be performing .x.x releases as things need to be updated which require a full release.  For example, if we find things that need to be fixed in 3.0 (which is VERY likely) we would release a 3.0.1 as needed.

To ensure a release cycle, Justin and I will be responsible for the timing.  We will work together to make sure that what needs to be updated is and will have a code freeze about a week before the release.  So if you want something in the release, you must let us know before that time.   (Obviously .x.x releases will typically have a shorter code freeze due to their sudden nature.)

We look forward to working on future releases with the entire community and if you have any questions or comments, please feel free to post them below or email me at kevin@secureideas.com

Kevin Johnson is the CEO of Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at kevin@secureideas.com or visit the Secure Ideas - Professionally Evil site for services provided.