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.

Tuesday, November 25, 2014

Burp CO2 now sports some Laudanum Scripts!

There have been a number of updates to the Burp CO2 extension suite over the past couple of months but the most exciting one is the addition of Laudanum functionality.  The Laudanum Project consists of a set of exploit scripts that are useful during penetration tests when the tester encounters the ability to upload files somewhere in the web root of an application server.

Similar to the classic Laudanum scripts, the Burp CO2 version of all shell payloads incorporate IP restrictions and an authentication token to secure the deployed scripts from unauthorized use (because having a malicious attacker leverage your pen test artifacts to hack your client is really, really bad!).

The Burp CO2 version of Laudanum attempts to simplify the process by moving all configuration to a user interface and by handling all the client-side logic in a consistent manner.  In addition, Burp CO2's Laudanum scripts are all designed to handle GET or POST requests, increasing the flexibility of use during penetration tests.

Once the setup is complete, simply press the re/Connect button to get a prompt.


THIS IS IMPORTANT: Remember that just like with classic Laudanum or any other uploaded exploit shell, the console you see is just a pseudo-shell.  It is not fully functional in the sense that it can only reliably be used to run a single command at a time.  Do not attempt to use it to do complex things like open an interactive command such as vi, or to tail a log file.  These types of interactions simply won't work as expected because the exploit script just executes the given command and responds with whatever is sent to stdout.  This being said, it is still quite useful for many situations such as browsing the file system, exploring an internal network, introducing additional exploits, and possibly even setting up a full reverse shell.  Laudanum is a great fallback when you can't directly obtain a shell through MetaSploit.

The latest binary (.jar) for the Burp CO2 suite can be found at http://BurpCO2.com.  Updates will periodically be pushed to the BApp Store as they stabilize

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.