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:

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, 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 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 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 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  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, 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 ( on 11/18/2014.  The video of that interview can be found at

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

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 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 or visit the Secure Ideas - Professionally Evil site for services provided.

Wednesday, October 01, 2014

Thumb Drives.. Can you tell the difference?

 During a physical penetration test, it is not uncommon for the tester (attacker) to drop usb thumb drives out in the parking lot or someplace within the building.  The hope is that an employee will pick it up and connect it to their computer.  The end goal: malware that makes a connection back to the attacker.

Business have some controls in place to try and help block this simple attack by blocking the ability for USB drives to connect to the device.  There are two problems that immediately come to mind.  First, how do you know that the device is really a thumb drive?  What if it was something else that attacks your system, like a human input device (hid)?  The second problem is just user awareness in understanding how attackers attempt to trick you into accessing the system.

Today, I want to talk about the device itself and the difference between a USB thumb drive and the HID.  As you can see from the picture, they look very similar.   Can you tell which is which?

The one on the left with the "Secure Ideas" label is in fact a 4GB USB thumb drive.   The one on the right is a HID, called a rubber ducky.  So what is the difference?  The USB device is just a storage device.  You can save and retrieve files from it.  You can even install bootable operating systems on it if you want.  This is what you normally buy when you want to transport files around with you on something small.

The HID device actually has a microsd card installed in it and is not meant for storage as this picture shows.

When plugged into a computer, the computer sees it as a Human Input Device (HID).  What does that mean?  Simply, it thinks it is a keyboard.  The devices is programmed by the attacker to run commands by sending a set of pre-configured commands to the system.  When it is plugged in, it runs the commands, even if USB thumb drives are blocked.  We can't really block HID devices since most people need a keyboard to work.

The HID device may install some malware or a back door that creates a connection out to the attacker to give him access to the system.  You may notice it doing this as it is not always very subtle (opening a command prompt and writing out a program to compile).

Just the other day, sitting in the office, Kevin asked for a thumb drive to put some files on.  He rustled around the desk and found one to use.  Unfortunately, the one he chose was actually the HID and not the Thumb Drive.  He was very surprised when he plugged it in and the keyboard popped up.  Fortunately it wasn't set up to manipulate a Mac, but it could have been.  These devices do exist and we need to be able to realize the potential that a device you receive may be malicious.  Sure, the Professionally Evil thumb drive could be malicious too, but it is easier to block those in a corporation.

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, @jardinesoftware or visit the Secure Ideas - Professionally Evil site for services provided.

Wednesday, September 10, 2014

CORS Global Policy

I recently noticed an uptake on Cross-Origin Resource Sharing (CORS) findings showing up in automated scanning tools, which would not have been a significant concern except for the fact that the tools were rating this as a relatively "high" severity and very few people I asked about it seemed to have any idea what it was. I love to find obscure quirky behaviors that can be turned into vulnerabilities... but first it we need to determine whether or not it is as bad as the scanning tools lead us to believe.

So what is CORS?

Simply put: it's a mechanism that creates a contract between a browser and a server permitting an exception to the Same Origin Policy. This is an extremely important aspect of today's application mashup dance party where all sorts of applications are intentionally interacting with each other in dynamic ways which must work around the Same Origin Policy. It is accomplished through request and response headers in such a way that the browser will identify all script-based requests with an Origin header, to which the server will respond with a set of cross-origin restrictions. The browser will only proceed with sending requests that adhere to the restrictions. The whole thing is slightly more complicated than this so if you want more details I recommend giving this a read:

Now the really interesting part of this from a penetration tester perspective is when we start involving cookies. It is possible to use CORS in what is known as a "with Credentials" mode, which will in fact send cookies during a cross-origin request. By this I mean that if you establish a session cookie with one origin, that cookie will be sent during any CORS requests (from other origins) to that origin. This allows a cross-origin request (e.g. an AJAX call) from one site to interact with another site as if the user was logged in.

So here is the line the scanning tools complain about:

        Access-Control-Allow-Origin: *

 ...and I see why. With a global wildcard policy like this (on any site containing sensitive data), wouldn't that mean a user browsing any attacker-controlled site is at risk of a cross-origin call pulling data off the target site? Researching this did not yield a satisfactory answer so I decided to write some test code and experiment with some scenarios on a few different browsers to see how they reacted. I tested Firefox 31.0, Chrome 37.0, and Safari 7.0.6 and all three of these yielded the same results.

What's the Risk?

In answer to the risk question: cross-origin requests using the "with Credentials" mode appear to fail if a global wildcard origin policy (i.e. Access-Control-Allow-Origin: *) is set. Such requests do not fail if specific origins are listed. So is there really a risk here or are the scanning tools overreacting?  As is often the case, the answer isn't as simple as "yes" or "no".  While experimenting with CORS and looking at some of the server configurations out there I realized that a typical server solution consists of simply adding CORS response headers.  They do not automatically perform filtering based on the values of these headers.  That is a job left up to applications and the browser.  In the case of the browsers I tested it seems like the browser is doing its job by not accepting the response body for requests against the server's CORS restrictions.  But the server is still sending the response body.  So if you examine CORS communication through a intercepting proxy (e.g. Burp), you will see that even though your Javascript can't read the CORS response, it is still sent over the wire unless the application is smart enough to respond based on Origin headers.

So what does this mean for penetration testers?  I feel we have not yet reached the end of the story.  So far my testing suggests that it is not common practice (yet) for servers to filter response based on Origin headers.  At a minimum this means the responses of an overly-permissive CORS policy can be easily captured by a proxy.  So an overly-permissive CORS policy combined with lack of Origin filtering and cleartext (HTTP) communication sounds to me like a solid recipe for data theft.

Next steps

I would like to see if a CORS request can be sent through a Javascript-based proxy within the same context.  In addition a lot more testing needs to be done on how different web servers handle Origin filtering.

Want to talk about it?

I will be teaching a Web Penetration Testing course at  AppSec USA next week and would be happy to discuss this research.

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, on Twitter @JGillam, or visit the Secure Ideas - ProfessionallyEvil site for services provided.