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.

Tuesday, November 18, 2014

Beware of Holiday Scams

 It is that time of year and we need to be ready for the fraudsters to be out in full effect.  The holidays are approaching and it is a time for joy for most.   Unfortunately, the Grinches are working just as hard as Santa to effect your holiday cheer.  Here are few things to keep an eye out for this holiday season.

This was discussed on channel 4 news (http://www.news4jax.com) on 11/18/2014.  The video of that interview can be found at http://youtu.be/O1tM6L4MJm0

Too Good to Be True Offers
We all want to get the best deal out there, however some offers are just too good to be true.  Saving 50% on an item might be possible, but if the deal is getting better than that, watch out.   It is recommended that you trust your gut on these deals.  If you feel as though it isn't legitimate then stay way from it.  If you are curious or want to find out more information do some online searches to see if anyone else is listing it as a scam.  In this day and age, you are not the only one being offered the deal and probably won't be the first to fall for it.

Open Packages
When shopping for electronics, beware of open packages.  With vulnerabilities like BadUSB, it is possible that the opened device has had malicious software added to it.  Look for unopened packages just to be safe.

Travel Scams
A lot of people will be traveling for the holidays.  With the cost of flights and hotels being higher during these special times it makes sense to sniff out the good deals.  We recommend that you use a trusted travel agent or the actual travel sites to book travel rather than some unknown company that just popped up in email.  The last thing you need is to give up your personal information to then get to the airport and find out the tickets are not valid.

Unsolicited Emails
You are getting unsolicited emails all year round.  During the rest of the year, they are pretty easy to distinguish and you can pick the scams.   During the holidays, many of the subjects become more relevant and more enticing.  Things like holiday e-cards are sent by friends, or are they?  If you didn't expect to get something, verify with the sender before opening it.  If you are planning on sending e-cards, maybe let your friends know it will be on its way.   Don't ever click on links or open attachments in emails you don't trust.  Secure Ideas' UserScout services help companies make their employees aware of phishing emails and how to respond to them.  If you would like more information, please contact me at james@secureideas.com.

Protect Your Mobile Device
We store everything on our mobile device.  We have email, 2-factor authentication applications, our social media apps, banking, home security, etc, all on our phone.  Use pass codes to protect the device from the amateurs that may steal your device.  If your device has remote wipe capabilities, make it available in the event the device does go missing.  When walking around, be conscious of where you device is and your surroundings to help protect it from getting stolen.

We have heard about a lot of breaches this year.  While we can't personally do anything about the retailer breaches, we can follow our own security plans to help protect us.  Monitor your credit card statements regularly.  Protect your devices.  Trust your gut.  If unsure, do research and if still unsure, don't trust it.

James Jardine is a Principal Security Consultant at Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at james@secureideas.com or visit the Secure Ideas - Professionally Evil site for services provided.

Tuesday, October 07, 2014

SQLite: the good, the bad, the embedded database

SQLite is an embedded, open-source, lightweight SQL database engine. The C based library is transactional, self-contained, and highly compact. It’s also fairly easy to implement. It doesn’t require any sort of installation or configuration, and all data is stored locally. This is very differently from a standard Oracle or MySQL database, so don’t make the mistake of thinking they are interchangeable.

The compact and efficient nature of SQLite has led it to become very common in mobile development. The library understands most standard SQL commands, with a few exceptions (such as missing right/full outer joins, limited alter commands, and the inability to write to views).  It also has bindings for a large array of popular programming languages and is included by default on most smartphones. SQLite has even expanded into on-disk file formats for desktop apps and low traffic web sites.

With a small footprint, server-less databases, readable source code, and cross-platform capability, there are plenty of advantages. But… we’re tech people; we know the other side of that coin. There’s always a price to pay.

So what are the disadvantages of SQLite? Well, to begin with, the database is stored as a single file (which can be located anywhere in the directory hierarchy). While this may seem convenient, any rogue process can open the database file and overwrite it. SQLite has no way to defend against this, so security must be performed at the file level. Set permissions carefully, keep files out of the web root, and/or use an .htaccess rule to prevent unauthorized viewing. You’ll also want to make sure to sanitize user input using sqlite_escape_string(), since SQL Injection is still an issue.

Another security concern is a feature called journaling. When changes are made, the SQLite database maintains separate “journal” or “WAL” files to facilitate roll backs. These files are generally temporary and get deleted when the transaction commits or rolls back. However, there are 3 conditions that can interfere with journal deletion.

1.    If a crash occurs mid-transaction, the -journal or -wal file is stored to disk until the next use.
2.    Developers have the option to set journaling mode to PERSIST (which prevents the journal from being deleted).
3.    Developers also have the option to put SQLite into exclusive locking mode (often done for performance). With this option, the rollback journal might be truncated or have it’s header zeroed (depending on which version you’re using) but the journal itself is not deleted until SQLite exits the exclusive lock mode.

These conditions could present serious security concerns for a database handling sensitive data (even if it is only being stored temporarily). So how do we protect it? Well, theoretically, it is possible to turn off journaling at the source level. However, this is not recommended. If journal files are missing when the application crashes, your database will likely be corrupted.

In the end, it seems like the best solution for storing sensitive data in SQLite is to encrypt it before storage. If you prefer not to encrypt the data yourself, SQLite has an extension called SQLCipher that will perform encryption. The commercial version does have a fee, but the community edition is open source.

Donna Fracarossi is a Security Analyst at Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact us at info@secureideas.com or visit the Secure Ideas - Professionally Evil site for services provided.