Tuesday, May 19, 2015

SamuraiWTF 3.2 RELEASED!

We are really excited to announce that SamuraiWTF 3.2 is now available publicly.  This release is available at http://sourceforge.net/projects/samurai/ immediately and we hope you enjoy it.

In this release we have updated a number of tools, addressed bug issues, and improved the target environments to better suit a training environment. We have also updated the Zed Attack Proxy(ZAProxy) to version 2.4.0. This particular version introduces new feature sets such as advanced fuzzing, attack mode,and advanced scanning options that increases the ease of use for common feature sets. To get a more complete list of ZAProxy’s updated and newly released features, please view the documentation. In addition,we have added the SQuirreL Database Client for further exploration and training with this project.

If you are just getting into Web App Penetration Testing, keep a look out for our upcoming classes. The next one is in Austin, TX(details and registration here)! This class will walk you through the SamuraiWTF environment, tools and testing methodology. This is a unique opportunity to sit down and learn from some of the best around; and we have a rockin' scavenger-hunt style CTF to test your new skills and get invaluable hands on training!

In future releases, we planning to expand our list of vulnerable apps to provide a more robust training environment. As always, we look forward to working with the entire community so
if there is something that you would like to see added to Samurai WTF, feel free to reach out and let us know.

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

Monday, May 04, 2015

And Now... Introducing: Burp BS!

Burp BS... where the "BS" stands for BeanShell.  "What on earth is BeanShell?" you may ask?  BeanShell is a very old Java library that was designed to build scripts in Java (full details on www.beanshell.org).  It never really caught on for general use because the Java language is designed from the ground up to be a strongly typed OO language, which is counter to the 'norm' for a scripting language.  Still, BeanShell is mature, solid, and has been used in a number of places where scripting inside of an existing Java container makes sense.

If you see where this is going and just want to find the download link, it's hereburpco2.com/burp-bs.html.  Otherwise, please read on:

With the Burp BS extension, Burp is now one of those places!  You might be thinking: "scripting is cool but when will you really need it?  Can't Burp already handle just about every scenario?".  Burp is pretty good at handling just about everything but sometimes you get into some tricky corner-case where the standard tools just don't cut it.  I never write a Burp extension that I don't use at some point need in a Web Penetration test.

In this particular case I was faced with a clever sort of MAC (Message Auth Code) check, where the MAC was a parameter derived from other POST parameters, one of which was an incrementing value.  Furthermore, the server actually kept track of these and would not process requests with a MAC that was used previously (so now the MAC is only functioning as a sort of Nonce).  I could not figure out any way in Burp to have it gather values, increment one, generate the MAC and set it.... that's just too many things to juggle.  Sure I could have messed around with Intruder and maybe gotten parts of this to work, but that doesn't help me with other tools such as Repeater.  But if I could write a little script to process each request...

I know some of you are thinking "Python?".  I'm a fan of Python so I absolutely did consider just writing the logic in a Python script or extension (or using an existing Python extension) but then I remembered BeanShell.  Some of the advantages of BeanShell include:

  • I could build a little interface for running and testing scripts directly inside of Burp.  No need to keep redeploying an extension to see if the script works.
  • Completely reusable for future tests.
  • BeanShell actually runs inside the existing Burp Java environment so it has full access to the usual Java APIs as well as all the Burp APIs.
  • Although it is running in the Java environment and using Java code, BeanShell code designed to be script-friendly so it doesn't have some of the constraints of the Java language.
  • I could easily write a wrapper around Burp's APIs to expose intuitive objects.

In the end I decided to move forward with BeanShell.  So what does this scripting language look like, you may ask?  Let's say you need to grab parameters foo and bar, concatenate them, generate the MD5 hash and place it in the cookie foobar:
values = request.getParam("foo") + request.getParam("bar");
request.setCookie("foobar", utils.md5(values));
Or let's say you need to conditionally add the header "X-Foo" whenever a parameter "bar" is set to "true", and only on GET requests... but you need to switch them to POST requests.
if (request.getMethod().equals("GET") && request.getParameter("bar").equals("true"))
    request.setHeader("X-Foo", "Burp BS Awesomeness");
If you are familiar with Java syntax already these probably seem very easy to understand.  Note that I didn't have to set a type for new variables (that's a script-friendly feature of BeanShell) and I have access to some useful pre-set objects (request and utils).

If you are interested in reading more about this project please visit burpco2.com/burp-bs.html.  Please send me feedback if you find this extension useful or if you have ideas to improve on it.

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.

Monday, April 27, 2015

Reading (Slogging) Through the 2015 Verizon DBIR

When the first data breach investigations report was released by Verizon in 2008, I remember thinking how awesome it was to get some actual data about security incidents and to see someone sharing this type of information.  At the time I was a systems administrator who had also become “the security guy” at my employer.  Because of this, I was hunting for information that I could use to explain what the attacker landscape was looking like and what risks we may be facing.  I did not want to depend on anecdotal information from stories that I would have a hard time backing up when talking to various directors and vice presidents.

The 2015 DBIR report continues to provide a large amount of information from Verizon’s case load and those of a number of contributors.  The report itself is 40 pages longer than the inaugural 2008 issue and has substantial improvements in the graphs used to communicate information.  The authors have worked hard on using data analysis to pull information out of all the data that they’ve gathered.  The only real fault I can find in this is that I a bit like a VP of Sales felt when I used to talk to him using technical jargon.  I don’t have a background in data science or statistics, so that made reading the report more difficult than I would have liked.  Still, it was informative and supported some things that I had suspected from pen tests we’ve done.

Cost of Breaches
One of the sections that I found to be personally interesting dealt with the financial impact of data breaches.  About 5 years ago I sat in an internal meeting and listened as the cost of a data breach was about $110 - $125 per record breached.  There are some obvious issues with these numbers.  The main problem is that it is too rigid for the varying sizes of data breaches.  Verizon also recognized that and in this year’s report tries to break down that cost based on the scale of the incident.  One quote from the report states:

“The forecasted average loss for a breach of 1,000 records is between $52,000 and $87,000.”

This would be a pretty small breach (when compared to those that make the headlines), but gives us a pretty good starting place to use when we get asked how much a breach could cost.  Verizon went further to provide a table of estimated costs of breaches up to 100,000,000 records compromised.

* Table from the 2015 Verizon DBIR

There’s a huge range between the best case and the worst case scenarios.  However, when looking at the columns for the upper and lower bounds of “average” costs, it narrows down quite a bit.  I’d be a bit cautious in how I used this information, but the middle three columns give us something that sounds reasonable to use.  It’s interesting to see how the costs break down in based on what Verizon and its contributors have found in their experience.  Of course, your mileage may vary.

The section on the results of phishing campaigns in larger breaches was not surprising to me at all.  Phishing has been a common theme in a number of reports on security incidents for several years.  These attacks are really annoying in my own inbox and are alarmingly effective when we perform them during a penetration test.  Verizon states that a small phishing campaign of 10 emails has a “90% chance that at least one person will become the criminal’s prey…” by acting on the email message.  I wish I could say that this was an exaggeration, but it’s absolutely in line with my experience when doing phishing during an assessment.

The news gets worse when you look at how little time you have to respond before someone clicks the link or opens that attachment.  Verizon’s report says that 50% of the users will click on that link during the first hour.  If anything, that seems a little long to me.  Secure Ideas consistently finds that users will start responding immediately to these emails.  It’s also grimly amusing to see how determined some individuals are to get to whatever is promised in the email.  It seems like there’s always someone who will try that link a half dozen times before they give up.  It’s not unusual to send a campaign with a 25% success rate in users clicking on the target link.  A clever and well timed message can do much, much better.  In fact, we performed one assessment during the holidays that linked to a survey about locations for the company Christmas party.  In this case, we had more responses than emails actually sent.  I can only guess that it was forwarded around to others in the organization.

With that bit of grim news, what’s the recommendation?  First, pay attention to your email filtering and work to make improvements on its ability to detect this messages while they are still inbound.  It might be worth performing some internal phishing tests or having a third party (like Secure Ideas’ User Scout ;-) perform them with the goal of testing and improving the ability of your filtering software’s effectiveness.  Don’t just use these tests as a way to see how employees respond.  Just how good is that spam app that we bought in the first place?  Using these campaigns as part of an interesting and actually useful user awareness program can really help as well.  Word gets around fast and lingers for a while when folks find out how their company actually did during a test.  Don’t use this as a witch hunt to embarrass or humiliate by listing who messed up, but let folks know that the attack was all too successful without naming names.  Verizon also states these assessments and training can actually improve our ability to detect phishing attacks as employees become aware of what phish look like and who to tell about them.

Wrapping Up
There’s quite a bit more in the report than what I’ve mentioned here.  The report is absolutely worth checking out and finding out more for yourself.  If nothing else, reading these types of reports should be part of our overall security programs.  Even if we disagree with some of the conclusions, it gives us information about what responders are seeing and what may apply to our organization.  Just a warning though.  Don’t open it up and expect it to be a bit of light reading.  Be prepared to read, think, verify and re-read it over time.

You can download the report from Verizon’s web site here.

Jason Wood 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 jason@secureideas.com or visit the Secure Ideas - Professionally Evil site for services provided.

Thursday, April 23, 2015

Installing Splunk: First stop on the road to log analysis

First thing’s first: What is Splunk and why do I want or need it? The short is answer is Splunk is a data analytics tool that indexes system logs across different machines and appliances so that they’re searchable. Data analysis, event monitoring, compliance, and overall management oversight can be gleaned from this tool.

Splunk takes data that is spread out far and wide in your organization’s IT infrastructure and puts it all in one place. It allows you to search through the data, create alerts to notify personnel when certain conditions are made, and generate reports that are not only easy on the eyes but specific to what you want to display conveniently from a web interface. Easy right?


Before going any further, ensure your system meets the minimum hardware/software requirements prior to installation. To view those requirements, please check the Splunk documentation.

Also, make sure that you have a system that already has its basic configuration and hardening completed. For example, static ip address, updates/patches, time, sudo privileges etc.  

Lastly, make sure the package you download is appropriate for the system you are using. Do not attempt to install the 64 Bit version of Splunk on a 32 Bit version of Ubuntu Server.

Installing Splunk on an Ubuntu Server(14.04 +)

For this demonstration, we will install Splunk using an installer package downloaded from the internet. As there is not a desktop environment present in our Ubuntu server instance, we will utilize the CLI to accomplish this goal.

To prepare for downloading the installer, switch to your home directory:

    cd /home/[user]   or cd ~
Downloading our package to this location does not require the use of elevated privileges and makes it easier to clean up the installation once it is completed.

Download Installer

In case the picture is a bit fuzzy, here is a copy/paste of the command used. Please note the single quotes or apostrophes that are present in the command. They are absolutely necessary in order for this installation to be a success. Also note that the version used for this demonstration is current at the time of this writing.

    wget -O splunk-6.2.1-245427-Linux-x86_64.tgz 'http://www.splunk.com/page/download_track?file=6.2.1/splunk/linux/splunk-6.2.1-245427-Linux-x86_64.tgz&ac=&wget=true&name=wget&platform=Linux&architecture=x86_64&version=6.2.1&product=splunk&typed=release'

11th try copy.jpg

As an aside, wget is a pretty handy utility used to fetch files or download entire websites from the internet. The “-O” argument outputs the content of the URL path to a single “file” where that content will be written. For more information about the wget utility, view the Wget manual at gnu.org.

Once the download is complete:

Expand the archive file and move its contents to the /opt directory
    sudo tar -xvzf splunk-6.2.1-245427-Linux-x86_64.tgz -C /opt
***wait for the terminal window to stop scrolling.

Why extract the archive to the /opt directory?
The answer is a simple one: /opt is where programs that are not installed by default with the operating system are stored. We downloaded to our home directory first since that is where we have write access.

Change directories to /opt and list its contents:
    cd /opt

You should see the directory splunk that was extracted from our archive file.

From the /opt directory, change directories to splunk/bin
    cd splunk/bin
Start the Splunk service and accept the terms and conditions.
    sudo ./splunk start
You will then be prompted to accept the EULA    
press y to accept the End User License Agreement.

This gives you the socket to access your Splunk web interface.
You can access this using the hostname or IP address of your Splunk instance and the default port of 8000. In this case it will be http://SecureIdeas:8000

Once the portal loads, you can login to it by using the default username of admin and password of changeme

And then you will be presented with the dashboard as seen below:

    splunk web.jpg

In future posts, I will go over how to add data to your Splunk web interface as well as configure alerts and rule sets that will allow the admin to have the most visibility in his/her environment all while allowing Splunk to do all of the heavy lifting.

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

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.