Stephen Northcutt of SANS Institute - "I think organizations should avoid Adobe if possible. Adobe security appears to be out of control".

Stephen Northcutt of SANS Institute - "I think organizations should avoid Adobe if possible. Adobe security appears to be out of control".
This is unfortunate news in my opinion. Bad publicity for Adobe and all of the good things and software that they provide and bad news for the developers out there creating slick applications using the Adobe Flex platform.

Northcutt is a bigwig tech guy from SANS. SANS Institute (http://www.sans.org/) is a highly respected organization and you can't take their statements lightly as say, a back page editorial on Inforworld. I believe alot of the flack comes from the slow and unresponsive update protocol that Adobe seems to be famous for. Microsoft usually releases updates monthly and I think I have read that Adobe recently announced a new updating strategy where they are planning to release updates quarterly. In my opinion, that is too infrequent.

Most of my experience in webappsec has been in the traditional browser based HTML based applications where you worry about vulnerabilities like improper input validation or not escaping output leaving yourself open to XSS. I have no idea how applications living inside of the flash player are exposed to attacks other than the reported problems with vulnerabilities within the Flash player itself. At a recent OWASP meeting, we had a guy from HP who demo'ed a slick, expensive offering from them that scans corporate software and reports leaks. I asked about if this software could flag Flex developed applications and I was told it could but I can't put a finger on why they were confident that it could. Maybe I don't remember or understood their explanation! Anyway, it involved something that was not of the traditional model.

It would seem logical that a Flex based application would take a little more skill to do a phishing style attack. The bogus site would have to be also developed in Flex, which I could see as doable. This is worth keeping on the radar especially as Flex is used in sensitive software such as online banking.

Hacking without going to jail.

I asked this question of the experts at the last OWASP group....if I want to get more familiar with tools such as Burp and Paros Proxy, how can I test against websites without getting myself into trouble?

The answer is here at hackers.org... this list is a list of sites that you can point your tools towards without going to prison.

Notes from Raleigh OWASP meeting held on August 2009.

Hey all,


I'll take a break from web application security tools assessments from a beginner's perspective and talk about what I observed from the Raleigh OWASP meeting held on August 06, 2009. I say take a break but what we discussed at that meeting is relevant to the recent blog posts on this very site.

We spent most of the time comparing web application security assessment tools - one that is commercial and has a decent price tag of $30,000 per seat - and a few that are freely downloadable and open source. Hans from HP presented WebInspect (click here, Hans mentioned that you can download a free to use 15 day trial). This one is the commercial offering and I must say, $30,000 is too cheap. Once you play around with the free ones, Paros (discussed in last post) and/or Burp , you realize what WebInspect can do. Hans did a great job presenting this tool and explaining all it can offer. It is totally customizable with respect to what it submits in form fields in tests - therefore better equipped to handle wizard style forms that are often found in login types of applications. The complex vulnerability scans can take hours or days and sometimes could go to the limits of what the target server can handle. It can create thousands of postings on forums, look for sql injection and XSS problems, browse for directory listings. The reporting that WebInspect offers is very extensive. The idea is that the security experts can run the scans, create the reports with the nice graphics and send them to the executives.

The other tools demonstrated by Steve were Paros, W3AF and Burp. What I found suprising was that the professional pen testers still use the free tools in their day to day duties. Steve mentioned that Paros's crawler (and I assume he means spidering) is very fast compared with WebInspect or Burp. It is a good thing to run a quick scan to find the most common problems quickly - a better-than nothing proposal.

Steve mentioned that development is dead on Paros with the last release in 2004 and he still likes it. I didn't take notes but I thought he said that he is part of the JRuby team that is writing a new edition in JRuby.

Try Googling: Paros Proxy, Burp or WebScarab (an OWASP project) to find links to download these free tools. Or download WebInspect from the link above to get a 15 day trial and let me know how it works.

Paros Proxy and Mapping a Web application

I mentioned in my last blog post that we will be looking at 3 common web application hacker tools but lets draw back that ambitious statement and start with one. I've already downloaded and installed Paros, so I'll start with that one. You can find this sweet tool at http://www.parosproxy.org/index.shtml. The version that I am using is version 3.2.0 released on November 2004.

For Windows installation it was easy, as I just let the Windows installer install itself but you must also download the latest Java JRE to get it to run correctly. Downloading and installing Java will be beyond the scope of this posting.

To set up Paros as an HTTP proxy you will use port 8080 for proxy connections and 8443 for SSL handling. Browse my last blog posting on HTTP proxies and how to set those up in your Internet Explorer, Firefox or Opera web browsers.

Once you have installed Paros, click on the launcher and you should see the Paros home page like this.

We will illustrate the value of a tool like Paros by practicing the first approach of a hacking session by what is called "mapping the target application." Mapping the application will give a hacker a better understanding of what the application is about and what the hacker is up against. According to the Web Applications Hacker's handbook, begin mapping by enumerating the applications' content and functionality in order to see what the application actually does. Some of the content will be easy to find and some will be hidden away and requires a little sleuthing to uncover. This is where the toolsets shine.

In the typical application, the majority of content can be discovered by manually browsing. The basic approach is to start at the home page and navigating through all the links and menu options until you have created a 'site map'. If the application already has a site map, that makes it easier - start there. As you can see, manually mapping and creating a rigorous inspection is a daunting task.

Web Spidering

Paros includes a tool called a web spider. This tool works by requesting a web page, parsing it for links and other content, then requesting those, continuously recursively until no new content is discovered.

Spiders attempt to acheive a high level of coverage by even submitting random and preset variables in parsed HTML forms. The spider can then analyze the response for even more valuable information. This allows spiders to walk through wizards and other mulit stage functionalities. Some other spiders can also parse Javascript to extract even more URLs and content.

To use Paros' Spider, you must first browse a site in a proxy session. Here is a screen shot once I've visited NFL.com:

To spider using Paros, you have to first browse the site and it will start adding the history to the left hand tree view. Notice all of the click thru URLs that it captures!

Select one of the sites in the tree view, I'll select NFL.com and choose Analyse -> Spider. Paros will bring up a dialog and start crawling...

You can tell Paros where to spider by directing the spider. The next steps that you can take is to manually and auto spider. See what the tool discovers and you don't. Then you can see if you can figure out why you couldn't discover some of the content that Paros does. Use Paros to discover valuable hidden content. Examine any error messages that are generated to see if you can figure out the technology behind the application. Hackers use this information to launch more sophisticated attacks.

That's it for this blog posting. The next posting will continue with Paros spidering and examine more advanced features and usefulness of application spidering. Now create those site maps and examine what you discover and what Paros discovers.

Hacking tools - HTTP Proxies

Finally, we get to the good stuff! This post is another in the series of how to use freely available tools to hack web applications. (White hat style!)

The most useful tool in your hacking or pen testing arsenal will be the HTTP proxy server. A proxy server is a server that mediates requests between your browser and the destination web server. When attacking web applications, the proxy server will allow you to intercept and modify all requests and responses. HTTPS? Even through https.

The intercepting proxy lies at the heart of your tool suite. To use it, you must configure your browser to use the proxy server to listen to a port on your machine. The proxy tool is configured to listen to that port and receive all incoming and outgoing requests. The coolest thing is that the proxy can 'stall' each message for review and modification by the user, along with other useful functions.

Configuring your browser to use a proxy server....

First, establish the port that your listening proxy will use for communications. This is usually 8080. Depending on which browser you use, the next steps will detail how you do this:

• Internet Explorer - go to Tools -> Internet options -> Connections -> Lan settings. UNCHECK: "Automatically detect settings" and "Use Automatic configuration Script" boxes. CHECK: "Use a Proxy Server for your LAN" box. In the "Address" field, type in localhost. In the Port field: enter the port number (usually 8080 as mentioned above). Click the advanced button. Make sure the applications you are targeting are not listed in the "Do not use proxy server for addresses beginning with...." box. Click OK and you are done with configuration of the browser.
• Firefox - go to Tools-> Options -> Connection settings. Check the "Manual proxy configuration" option. In the HTTP proxy field, enter localhost. Also, enter 8080 in the port field. Check "Use this proxy server for all protocols." box. Make sure the applications you are targeting are not listed in the "No proxy for..." box. Click OK and you are done with configuration of the browser.

In addition to the core functionality that proxy servers provide as listed above, the proxy tool suites contain a wealth of other features to assist you in attacks.

1. Configurable interception rules - In a typical application, many of the request and responses are of little interest. This funtion allows you to configure the proxy to show only messages that are of interest to you. You can configure such things as the target host, URL, method, resource type, and many more.
2. Web application spiders - This funtion will allow you to specify a target host and then the spider will recursively request links, then follow those links until all of the site's content has been discovered. Spiders are useful to map the target application. We will get into more of application mapping in a future post.
3. Application scanners - To be a great hacker, you must use automation to launch successful attacks. Scanners can be used to scan target hosts checking for common vulnerabilities by sending a set of attack strings and analyzing the responses to identify signatures.
4. Manual requests - sometimes it can be useful to send a single request and examine the response. Especially if you probing a specific vulnerability and want to issue the same request over and over again.
5. Many other features!

That's it for this post. My next post will examine the 3 top common tool suites that contain the features listed in this post. We will look at Paros, Burp and WebScarab.

A quick post about web application encoding schemes

Before we get into tools discussions, lets talk a little bit about character encoding schemes. You may remember from my last post that as far as input into a web application goes, assume that all input is malicious and a developer must solidify the defenses to reject known bad content. So, you, as a developer craft together a pretty good regex expression that you pass all of your input through. As long as it's human readable character data, you should be OK, right? Wrong. Attackers can manipulate a character encoding scheme used by an application to cause behavior that the developers did not intend.

Let's look at the common character encodings:

URL Encoding

According to the Web Hacker's Handbook, URLs are permitted to contain only the printable characters in the US-ASCII character set. Therefore, a encoding scheme for URLs was created in order to safely transmit any problematic characters within the extended ASCII character set. For example, the ? and & characters in a URL has a special meanings related to request parameters. If you wanted to inject these characters as data you will need to pass the encoding equivalent.

Here are some common characters in URL encoding:

%3d - =
%20 - space
%0a - new line

Unicode Encoding

This character encoding scheme is designed to support the writing systems all around the world. It can support unusual characters in web applications. 16 bit Unicode encoding and UTF-8 are common unicode encodings.

For example, in UTF-8 , each representation of a characters is a hexidecimal and preceded by a %.

%c2%a9 - copyright

When attacking web applications, unicode encoding can sometimes be used to bypass input validation mechanisms. If an input filter blocks certain expressions, but the component that immediately is invoked after bypassing the filters understand unicode, then it could be possible to launch an attack.

HTML Encoding

This scheme is used to display problematic characters in HTML pages. Some characters have special meanings that are used to define the structure of the document rather than content.

For example, to use these characters as part of the document content, you must HTML encode them:

" - "
' - '
& - &

On top of this, any character can be HTML encoding using its ASCII code in decimal form:

" - "
' - '

HTML encoding is used mainly in checking for XSS vulerabilities in web applications. If an application does not HTML encode its responses, then the application could be vulnerable to XSS attacks.

Base64 Encoding.

This encoding is used primarily for transferring binary information represented as printable ASCII characters.

Where do you start when hacking a web application?

Many of the web applications out there today explain that they are secure. According to the Web Hacker's Handbook, many sites tout their SSL as their claim to be secure. Of course, SSL is good - it prevents eavesdropping and keeps your content safe between browser and server over the Internet.

The fundamental security problem with most web applications is that the input is not under direct control of the application. Users all over the world can submit any arbitrary inputs to the application. The developers of the target application must therefore assume that each piece of input is malicious. The list of the Top 25 Most Dangerous Programming Errors compiled by the SANS institute and the MITRE organization in January 2009 describe the top 2 errors that revolve around malicious input and improper escaping of outputs.

The simple fact is that any user anywhere in the world can craft a special string to any publically accessible application that can wreak havoc for the organization. Couple that with the fact that the user doesn't have to use a web browser to interact with the application. There are numerous tools out there that are freely downloadable that can interact with web applications, even trapping the request from the client before it gets to the server and provides the attacker the ability to modify certain parameters that can totally bypass any validations.

Next post will get into the beginnings of how to use tools to completely map a target application.