captain holly java blog

Evaluating WebScarab

Posted in security, spring, Uncategorized by mcgyver5 on July 29, 2009

I was asked to do a security assessment on a co-worker’s Cold Fusion application. It is protected on every page by a NOT findnocase(cgi.http_host,cgi.http_referer) check to ensure the request came from the same domain. This is a good way to prevent forced browsing and most url injection attacks because if you mess with the URL, this tag knows it and stops all the shenanigans.
This is where a proxy comes in. I’ve worked a bunch with Paros and some with Burp, but my employer does not allow me to download these without some extra paperwork. Webscarab, for some reason, is allowed. Webscarab is written entirely in Java, has a zippy UI and has widening adoption.

Webscarab allowed me to do forced browsing on the application and learn that the application relied solely on that domain check to make sure the user was authenticated (That is, they could only get to the site through the login form). Webscarab also allowed me to find many XSS bugs.

Webscarab is infinitely scriptable (with beanshell).

Webscarab has a tool that evaluates session identifiers for their strength. I would guess that most web frameworks these days have very strong session identifiers. In fact, I challenge anyone to find an example of a weak session identifier on any web app that shouldn’t be replaced anyway for one hundred other reasons.

Startup Options
Webscarab starts in Lite mode, which is just the web proxy, by default. To get the full meal, you have to start with java -DWebscarab.lite=false -jar webscarab.jar
Default memory is 64MB and this can get used up quickly. Online examples show webscarab having ~510 MB available. This is achieved by adding -Xms32m -Xmx510m to the java startup args. Just like with some other java desktop apps (Like IntelliJ Idea) you can click on the Green|Yellow|Red bar along the bottom of the window to force garbage collection and free up some memory.

Things That Could Be Improved:

  1. Inconsistency: Some features are available through a right click, some through a double click, some from a menu item and others from buttons or tabs somewhere on the screen. Some fields look editable but aren’t. Some are editable on one click, others on two. Some edit fields select the whole field when clicked, but typing appends to the end of the existing entry.
  2. Other screens have a delete button. Not the Proxy Listener Tab. To delete a listener you must stop it. If I a listener fails to start, it may not be stopped and so cannot be deleted. I have to stop any other service using the same port as my listener, THEN start my listener, and THEN stop my listener to delete it
  3. The interface for getting rid of conversations is difficult to use. Webscarab can fill up pretty fast with banal conversations and the only easy way to get rid of them all is a restart. There is a Tools –> remove conversations menu item, but no regex that I enter seems to get rid of conversations.
  4. There should be some way to construct the proxy filters based on existing requests. By this I mean when a request is trapped that you never want to see again, you can flag it in some way to add it to the ignore list.
  5. Judging from several posts to the mailing list, Webscarab only works with Sun’s brand of java.

To address user experience as well as other issues, Webscarab is undergoing a total rewrite. This is currently known as Webscarab NG. They will be using the Spring Rich Client Platform. The new product also has database integration. This is a work in progress and needs lots of testing. So, if you are looking for an open source project to help, this would be an excellent choice. According to the email list, the Webscarab NG project leader has been directing his work at the OWASP Proxy lately. Even though Webscarab NG is in development, development also continues on the current Webscarab.

Advertisements

Slowloris vs tomcat

Posted in security, tomcat, Uncategorized by mcgyver5 on June 19, 2009

RSnake has been thinking about a denial of service attack against web servers that involves sending partial http packets to use up number of allowed clients. Sending carefully crafted partial packet causes the server to take A LONG TIME to work on the response to your request, using up its resources and becoming temporarily unavailable to other visitors. Apache HTTPD is mentioned as a server that is vulnerable. IIS is mentioned as one that is not. RSnake, being a realist and not an anti-microsoft evangelist, often says things that make the open source advocates uncomfortable. (“PHP is the bane of my existence” and “Whenever I assess a dot net application I know right off the bat that I’m going to find half the number of vulnerabilities”).

A few notes about Slowloris: It can’t effectively dos a box from windows because it works by creating hundreds of Sockets and Windows only allows a max of 130. It doesn’t crash anything, so it is a gentle tool(haha) It just happens to make web applications unavailable for as long as the attacker wishes. It does, by the way, send out hundreds of packets so it is detectable by the administrator.

To use Slowloris, first establish a timeout for the web server you are attacking:
./slowloris.pl -dns http://localhost -port 8080 -test

this should return some numbers to use for a timeout.

They don’t mention tomcat, so I spent most of the afternoon setting up a machine to see if this tool can DOS tomcat.

drum roll please….

slowloris test

slowloris test

clear that we’ll be using a 5 second timeout for TCP and a 30000 millisecond timeout for http.
then,
./slowloris.pl -dns localhost -port 8080 -timeout 30000 -num 500 -tcpto 5

the above opens 500 sockets and uses a tcp timeout of 5 seconds and looks like this:

slowloris execution

slowloris execution

now, try and connect to the benighted tomcat server.
hmmm. works fine. What gives?  I suspect that as this number of connections (500), I am still able to get a connection.  The first visit takes a really long time, but once I get through, I can use the site normally.  This matches the statement in the documentation that ”    “.  If I raise the number of connections….  It still takes a very long time to load the first page, but thereafter is just as easy to access the application.

When I run slowloris on the same server, however, tomcat is completely DOS-ED.    I’m impressed with the absolute unavailablity of tomcat in relation to the low level of traffic that slowloris generates.

ooooh.   I thought I was supposed to convert 30 seconds into milliseconds.  wrong!  setting the timeout this high  (30,000 seconds) is clearly too high.  When I set it down to 30, slowloris CRUSHED tomcat.  remotely or locally.  As you can see below, setting the timeout correctly allowed many more packets to be sent.

slowloris success

slowloris success

Tagged with: ,