Sunday, March 28, 2010

Basic XSS AutoFill Script

Sometimes its nice to just browse through a site you are testing and quickly enumerate obvious XSS issues.  And by obvious, I mean cut and dry, no cleverness needed.  But then you encounter a large form and have to fill out the twenty fields with your test script. You hit submit and realize that 6 of them are vulnerable. Blah, now you have to go back and put in an individual alert message for each field to identify which of those 20 fields are the vulnerable ones.

I finally got tired of this and created a nice little grease monkey script.  You can download it here.

After you load it into grease monkey the script will automatically update all fields with the following basic xss test:

The following html elements are effected:
  • text boxes
  • text areas
  • drop down menus
  • hidden fields
I also added a few items the are skipped, mainly fields that are called 'action' or 'token'. You can change this as you see fit.

The script will modify the mentioned elements for every page you view. So make sure to turn it off after you are done testing.

-Michael Coates

Thursday, March 25, 2010

Fuzzing with OWASP's JBroFuzz

I decided to search out a good web fuzzer for some testing needs. I wanted a fuzzer that was capable, customizable and could support my testing.  The last thing I wanted was some sort of all-in-one application security scanner (since the false positives can just get ridiculous at times). Nope, all I needed was some automation assistance.

I came across OWASP's JBroFuzz and think I've found a good match.  The tool provides a variety of brute force options and includes some nice graphing and statistics to analyze the information. I was also happy to see some nice documentation so I could quickly get up and running. My only compliant at the moment is that the proxy setup is a little clunky and not-intuitive at first. But again, as long as you follow the guide, it shouldn't be an issue.

When do I plan to use this new found fuzzer?
1. Sites where I don't have source for some reason. This is actually a rarity. If you want someone to assess the security of your web app, you should really give them the source code. Quick aside: if the consultants you select for an assessment aren't asking for source code, an alarm should go off in your head. If they don't do source code analysis, then they aren't doing there job.

2. When a site relies heavily on complex regular expressions for input validation and has weak output encoding. Yes, we can make the argument straight away that this is an issue. But its very powerful to make your case with a working exploit. Otherwise, you are trying to justify a bug fix to an issue that may or may not be currently exploitable. This can be a tough sell if developers are heavily leveraged with feature enhancements, new functionality, upcoming releases, etc.

-Michael Coates

Wednesday, March 3, 2010

Man In The Middle Attack - Explained

"That’s vulnerable to a man in the middle attack!"

You've probably heard this before, but let’s dive into the details of this attack and understand exactly how it works.

First, a quick definition, a man in the middle (MitM) attack is an attack where the communication which is exchanged between two users is surreptitiously monitored and possibly modified by a third, unauthorized, party. In addition, this third party will be performing this attack in real time (i.e stealing logs or reviewing captured traffic at a later time would not qualify as a MitM)

While a MitM could be performed against any protocol or communication, we will discuss it in relation to HTTP traffic in just a bit.

Requirements for Attack
A MitM attack can be performed in two different ways:
1.       The attacker is in control of a router along the normal point of traffic communication between the victim and the server the victim is communicating with.
2.a.    The attacker is located on the same broadcast domain (e.g. subnet) as the victim.
2.b.    The attacker is located on the same broadcast domain (e.g. subnet) as any of the routing devices used by the victim to route traffic.

We will discuss 2a. This is a likely attack that can be used against your neighbors or the person sitting next to you at a coffee house.

The Attack
A MitM attack will take advantages of weaknesses in network communication protocols in order to convince a host that traffic should be routed through the attacker instead of through the normal router. In essence, the attacker is advertising that they are the router and the client should update their routing records appropriately.  This attack is called ARP spoofing.
The (greatly simplified) purpose of ARP (Address Resolution Protocol) is to enable IP address to MAC address translations for hosts. This is required so that the packet can reach their final destined host.  (see RFC 826)

By design, ARP does not contain authentication. Therefore, any host can reply to an ARP request or send an unsolicited ARP response to a specific host.  These ARP response messages are used by the attacker to instruct the victim’s machine that the appropriate MAC address for a given IP address is now the MAC address of the attacker’s machine.  More specifically, the attacker is instructing the victim to overwrite their ARP cache for the IP->MAC entry for the router. Now, the IP address for the router will correspond to the MAC address for the attacker’s machine.

What does this mean?  Now, all of the victim’s traffic will be routed through the attacker.  Of course, we don’t stop here. In order to allow the traffic to reach the Internet, the attacker must configure his system (or attack tool) to also forward this traffic to the original router. In addition, the attacker performs a similar ARP spoofing attack against the router. This way the router knows to send traffic, that was destined for the victim machine, to our attacker instead.  The attacker then forwards on the traffic to the victim. This completes the “chain” and places the attacker “in the middle” of the communication.

Impacts on HTTP

At this point, the attacker has the ability to view and modify any TCP traffic sent to or from the victim machine. HTTP traffic is unencrypted and contains no authentication. Therefore, all HTTP traffic can be trivially monitored/modified by the attacker.

What about HTTPS?

Everything we have talked about thus far is related to getting in the middle of the network communications. This enables the attacker to view most exchanged data, but does not enable the attacker to intercept data exchanged of protocols that implement their own authentication and encryption (e.g. SSH, SSL/TLS)
But, this is where the fun starts.  The purpose of HTTPS is to create a secure communication over top of HTTP by the use of SSL or TLS.  On its own SSL/TLS can be very effective and secure. However, there are significant problems in the implementation of SSL/TLS which effectively renders it useless.  In addition, the browsers handling of SSL/TLS can lead to issues when both HTTPS and HTTP sites are visited by the user.

More devious means are needed to perform a MitM against SSL/TLS.  At this point the attacker could attempt to intercept HTTPS traffic by using a custom certificate. This would present a certificate warning message in the user’s browser and likely alert the user to the attack.  Luckily for the attacker, most users would ignore the warning and continue – thus exposing all of their data.

Alternatively, the attacker could try and use tools such as SSLstrip to leverage poor application design with regards to SSL/TLS. This could also enable the attacker to obtain the victim’s password over clear text HTTP.

How concerned should you be?

The attack scenario described in 2a can be performed by any user on the same broadcast domain as your machine.  This means that anyone sitting in the same coffee house on the wireless network could be an attacker. Also, if you connect directly to your Comcast/RoadRunner/ATT/whatever home connection, then many of your neighbors could also perform this attack against you.  And if you use a home router instead of directly plugging the connection into your machine - well, then the attack is still possible via 2b (essentially the same attack).

Really the only reason this isn’t a bigger deal is because of the requirement to be on the same subnet.  Right now we have so many other issues, such as XSS, SQL injection, etc, which can all be exploited remotely by attackers. The attackers just sit in their remote locations and destroy web sites from a far.  However, the point is this, if an attacker wants to steal YOUR specific bank data then all they need to do is sit next to you at a coffee house or sign up for Internet service in your area.

If you find SSL/TLS attacks interesting, then check out an upcoming talk at Chicago's Thotcon Security Conference on Friday, April 23.

-Michael Coates