Nitesh Dhanjani

I’ve been spending a considerable amount of time auditing web applications, and I’ve come to realize that a large amount of developers do not understand the root cause of Cross Site Scripting (XSS) vulnerabilities. The most common mistake committed by developers (and many security experts, I might add) is to treat XSS as an input validation problem. Therefore, I frequently come across situations where developers fix XSS problems by attempting to filter out meta-characters (<, >, /, ", ', etc). At times, if an exhaustive list of meta-characters is used, it does solve the problem, but it makes the application less friendly to the end user – a large set of characters are deemed forbidden. The correct approach to solving XSS problems is to ensure that every user supplied parameter is HTML Output Encoded (Example: < is replaced with &lt;). Most frameworks (.NET for example) provide API’s that help with HTML encoding, but I have come across instances where such APIs don’t encode certain characters that can lead to XSS when more complicated variants of input are attempted. Therefore, I frequently and highly recommend RSnake’s XSS cheat-sheet to test web based applications and services for XSS vulnerabilities. If you are a web developer or tester, I do recommend that you test your application with the inputs suggested by RSnake to test for XSS issues.

I just came across twill, a Python based tool for web application testing. It can be used interactively (command-line) or via a Python script. Below is a quick example on how to use twill so submit a form (HTTP POST). I’ve used Google for demonstration purposes. Note that all user input is represented in bold.

Startup twill:
$ ./twil-sh
-= Welcome to twill! =-

current page: *empty page*

Goto http://google.com/ and show form details:
>> go http://google.com/
==> at http://www.google.com/
current page: http://www.google.com/
>> showforms
Form name=f
## __Name______ __Type___ __ID________ __Value__________________
hl hidden (None) en
ie hidden (None) ISO-8859-1
q text (None)
1 btnG submit (None) Google Search
2 btnI submit (None) I'm Feeling Lucky
current page: http://www.google.com/

Use “oreilly” for the query (q) paramter, and submit using “I’m Feeling Lucky”:
>> fv 1 q oreilly
current page: http://www.google.com/
>> submit btnI
Note: submit is using submit button: name="btnI", value="I'm Feeling Lucky"
current page: http://www.oreilly.com/

Our search succeeded, and we are now at http://www.oreilly.com/ (redirected by Google because we submitted using the "I'm Feeling Lucky" option). Next, lets list forms on http://www.oreilly.com/:
>> showforms
Form #1
## __Name______ __Type___ __ID________ __Value__________________
sp-a hidden (None) sp1000a5a9
sp-f hidden (None) ISO-8859-1
sp-t hidden (None) search
sp-x-1 hidden (None) cat
sp-x-2 hidden (None) cat2
sp-q-1 hidden (None)
sp-q-2 hidden (None)
sp-c hidden (None) 25
sp-k hidden (None) Articles|Books|Conferences|Other|Weblogs
sp-q text (None)
1 search submit (None) Go
current page: http://www.oreilly.com/


Show cookies acquired so far:
>> show_cookies

current page: http://www.oreilly.com/

I see how twill can be very useful in performing security assessments against web applications. twill makes it easy to submit forms for input validation testing (XSS, SQL Injection, etc), look at hidden HTML tags, cookie details, etc. The twill website has more details on how to use twill in a Python script. This can be useful when you need to automate twill actions. Also, see “Web app testing with Python 3: twill” for more examples.

A few days ago, I noted Tenable’s announcement stating that Nessus3 will not be released under the GPL. As expected, this announcement has caused 3 new Nessus forks to be announced: GNessUS, Sussen, and Porz-Wahn.

GNessUS seems to be most active of the three (as of now). According to the announcements section of the project website, GNessUS will soon change its name:

Date: Sat, 15 Oct 2005 11:11:16 +0100 (BST)
From: Tim Brown
To: gnessus-announce@gnessus.org, gnessus-news@gnessus.org
Subject: News from the Tenable talks

What does this mean for the project? Well, I have no intention of shelving it and to this end, I have set up gnessus-discuss@gnessus.org where we can debate a new name for the project. Subscription to this can be achieved by sending a mail to majordomo@nth-dimension.org.uk with a body of "subscribe gnessus-discuss" and I would welcome you joining.
[more]

This is great news. I will continue to watch all three of these projects, and contribute where I can.

Eric Chavez, a good friend of mine, alerted me to a new tool called tcpxtract. The purpose of this tool is to extract files from network dump files. I have been looking at ways to capture files from HTTP streams, so I thought I’d give it a try. It wouldn’t compile right away (misplaced #endif), but I found the solution on the Bugs section of the project website. I tried running it on OS-X, but it didn’t seem to capture any images. When I get a chance, I will probably look at the source code for tcpxtract.c to see where the problem is.

This reminded me of driftnet, a similar tool, but limited to extracting images (and now MPEG audio streams) from the network. Always a fun tool to try when at a coffee shop or airport. Here is a screenshot of driftnet successfully capturing images on my network (while I was visiting oreilly.com):

One useful option in driftnet is –a, which causes drifnet to save the images into a temporary location instead of displaying it on-the-fly.

On a related note, I came across another interesting tool: Foremost – this tool can recover files from a given stream of data. I tried it with network dump files that I created with Ettercap, and it worked surprisingly well.

The latest Nessus roadmap states that Nesssus 3 will NOT be released under the GPL. Before I talk about why this is not a big issue for me, let me first state that I have been a big supporter of the Nessus project. I have written two articles about it, as well as a chapter on NASL in my latest book, Network Security Tools: Writing, Hacking, and Modifying Security Tools. I always make it a point to talk about Nessus when I speak at conferences on information security topics.

Here is why this announcement doesn’t bother me at all: because the Nessus plugins will continue to be open source. NASL is a scripting language, and therefore all the plugins will continue to be in clear text. In my opinion, the power of Nessus lies in the ability of the user to open up a particular Nessus plugin to determine how it works, and to confirm false positives. As long as Nessus continues to give me this ability, I will continue to use and support it.

For those wondering, here is another thread where Renaud Deraison describes why Nessus 3 won’t be released under the GPL:

Virtually nobody has ever contributed anything to improve the scanning _engine_ over the last 6 years. I'm not talking about shoe- horning DB support in nessusd, but really to contribute things which make the scans faster, or Nessus more powerful.

A number of companies are _using_ the source code against us, by selling or renting appliances, thus exploiting a loophole in the GPL. So in that regard, we have been fueling our own competition and we want to put an end to that. Nessus3 contains an improved engine, and we don't want our competition to claim to have improved "their" scanner.

Understood. And more power to them. Nessus is a great tool, and I look forward to using version 3.

I just came across the TrueCrypt project: free and open source disk encryption software for Windows XP, 2003, and 2000. After installing it, I tried to create an encrypted volume and noticed an option to create a ‘hidden’ volume.

According to TrueCrypt, here is an explanation of what a hidden volume is:

All well and good, but while reading this, I couldn’t help but think of a situation where the (violent) adversary is someone familiar with this feature of TrueCrypt! In such a situation, it would be impossible for the adversary to be convinced that all data is being revealed to him or her (this is a known drawback in the concept of Plausible Deniability).

That said, I am impressed with the features TrueCrypt has to offer, and I will continue to test it for a while. However, given that the project is barely a year old, I'm not ready to risk using it to protect my primary data just yet.

During the last few minutes of episode 25 of this Week in TECH, an audience member asks the panel for ideas on how to capture .torrent files on a network. The solution given during the podcast is to use a network analyzer such as Ethereal to capture the .torrent files that are being downloaded by users on a network. However, assuming that users are requesting .torrent files from a public tracker, I believe that a simpler solution is to use urlsnarf to sniff the HTTP requests for .torrent files. Here is an example:


[root]# urlsnarf -i en1 | grep "\.torrent HTTP/"
10.0.0.2 - - [ 3/Oct/2005:23:50:59 -0500] "GET http://downloads.revision3.com/torrents/systm/0004/systm
--0004--podcasting--large.h264.mov.torrent HTTP/1.1" - - "http://revision3.com/systm/podcasting/media" "Mozilla/5.0
(Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12)
Gecko/20050915 Firefox/1.0.7"

This technique will work just fine on a wireless network or a hub-based network segment. Ettercap’s ARP poisoning techniques can be used to sniff on switched network segments.