Web Application Hacking — Analyzing the Application

Welcome back guys, this is continuation of the previous blog on Mapping the Application. Lets continue our analysis to further gain more information about the application

Lets get this started.

These are the key things that are to be looked after, when analysing the application.
• Core functionality
• Periperal behaviour
• Core Security mechanisms
• User-Input Processing
• Client-side technologies
• Server-side technologies
• Any details about internal structure

Entry points for User-Input

The key areas to look at,
• URL File paths
• Query string parameters
• Parameters in POST request
• Cookies
• Headers processed by Server

URL File Paths

Normally, less looked after, because it would contain only directory and sub-directory paths. But, in REST style URLs, data itself is transmitted as URL file path.

           www.app.com/browse/clothes/jeans

this is equivalent to,

            www.app.com/browse?clothes=jeans

So treat these as data points rather than, just files.

Query string parameters

All application may or may not use the same param=value form, it depends on the developer.
Some examples

/dir/file/foo%3dbar%26foo2%3dbar2
/dir/file?param=foo:bar
/dir/file?foo=bar$foo2=bar2

This may seem unrealistic, but may happen. If you consider it simply as foo=bar, you will miss critical vulnerabilities like SQLi and Path Traversal.
If you see it URL encoded, just decode it and understand what is happening.

HTTP Headers

Referer Header

Referer header is used by the application to know where the request originated. For example, if a request originated from the admin section, we may access certain things unaccessible by the normal users. It can also be used for SEO, so try crafting different Referer headers.

User-Agent Header

It says what device is being used to access the application. It may be that the application may serve different content to a different device. It is good to probe to reach all code paths in the application.
Brute force the User-Agent Header with various User-agents and see if there are any changes in the behaviour, if there is some deviation, there may be vulnerabilities in it.

Adding Headers

You may gather a list of Headers that the application would process and try sending it to the application.
Like if an application is behind load balancer, the X-Forwarded-For can be used to do malicious tasks.

Out-Of-Band Channels

The application may take input from other sources, like e-mail, from FTP, etc. These mostly provide a large space for user-input. So they must be identified and they are an ideal place for bugs.

Server-Side Technologies

We can identify server-side technology in several ways. These are already a part of your initial recon.

Banner Grabbing

Sometimes some servers disclose large amount of information. We can identify these by banner grabbing.
The Server: header is a key place to look at. Some other places are Templates used in building HTML files. URL paths like WP-Login in URL shows it as a Wordpress installation. Though the banner can be changed or spoofed.

HTTP Fingerprinting

As said, the banners can be spoofed. Through HTTP Fingerprinting, analysing the behaviour using packets we could identify the server. Httprecon is a handy tool to do it.

Other Revealing things

File extensions could reveal information about programming languages in use. Presenting some uncommon things I see,

d2w — WebSphere
cfm — Cold Fusion
dll — Usually compiled native code (C or C++)
nsf or ntf — Lotus Domino
pl — The Perl language

You would be already familiar with php, asp, aspx, jsp etc.,

Next are the session tokens, they could also be customized

JSESSIONID — The Java Platform
ASPSESSIONID — Microsoft IIS server
ASP.NET_SessionId — Microsoft ASP.NET
PHPSESSID — PHP
CFID / CFTOKEN — Cold Fusion

If you find anything new about the session token, just copy and paste it in a google search.

Third party code, may be commercial or open source. If opensourced, you could download it and test locally. If it is commercial, search for other places where the code might be used, (USE DORKS). Then analyze the behaviour in both the applications.

Server-side Functionality

This is the key area for identifying vulnerabilities. If you know what the server is built for, how it is built, you could easily prioritize your attacks and make your way in.

View the complete URL

First take a look at some long URLs,

       http://www.target-site.com/pub/picture/117/view

This is a REST-Style URL, which is equivalent to,

http://www.target-site.com/?schema=pub&type=picture&id=117&action=view

Understand these kinds of URLs completely. From the above you could infer that you are going to view an image with an id 117. An ideal attack would be to change the action parameter to see if we could add/write/edit a file. By just modifying view to add won’t do the work because 117 is already present. Try possibilities like,

        http://www.target-site.com/pub/picture/100001/add

The 100001 may not be present in the server. There might be a possibility to write an arbitrary file to the server.

Extrapolate the Behaviour

Here I present situations, where you can take the application behaviour to your advantage.

Input Validation

For sure all applications’ must have. Mostly the code is shared to all parts of the application. If you have found a DB interaction and your query gets sanitized. Look for places where input is reflected back. You can use that to craft DB queries that would be successful. Since the same validation code is used all over.

Obfuscation

Applications need to use some sort of obfuscation to avoid easy access. Look at other places like, error messages which may display deciphered text from some obfuscated string. You have to craft a specific input to get deobfuscated text. Sample those, so you could even obtain the algorithm for obfuscation.

Error Handling

Some places may handle errors gracefully, some may crash and log the reason. Alter inputs and carefully monitor the errors, they may have a great deal of information. We may even determine the internals of the code.

Isolate Application Behaviour

We may have a bad time finding vulnerabilities. Now its the time to look into more details. Look through the whole application, identify places where the functionalities seems to be “added on” or “bolted on”. These may be developed later, by different developer which may not be correctly tied to authentication, session management, access controls etc.,
These may be identified using changes in GUI appearance, naming conventions and sometimes in comments.

Mapping the attack surface

Now we may prioritize the attacks to be carried out, starting from the low hanging fruit and go deeper as we move on.

For those who are in a hurry or donot like reading long text,

1. User-Input
   •Inspect all URLs, modify it to see for any changes.
   • Inspect all submitted query string parameters and modify it to find any anomalies.
   • Inspect HTTP Headers, most important, modify Referer and User-Agent Headers.
   • Try adding Headers like X-Forwarded-For, the application is likely to process
   • Identify the out-of-band channels where the input is recieved from.
2. Server-side technologies
   • Make use of the Server header, look at URL paths, directory names and Template pages.
   • Run Httprecon or other HTTP Server Fingerprinting tools.
   • Look for other revealing items like file extensions, session token names
3. Server-side functionality
   • Dissect the URL and understand what each word means and think of what it might do on the server.
   • Check what are all the characters or markup sanitized by the code, if you find any places where input is reflected back.
   • Check all the error messages or any messages from the server to see if it has any input submitted by the user.
   • Cause the application to generate errors and infer from them.
   • Identify parts of the application where there is added on functionality or those deviate from main application.
4. Prioritize the attacks to get the low hanging fruits and move deeper.

I would have explained each topics in a long way, but that would take even longer blogs. Please comment on how you liked the blog. Please mention if you need tutorials on how to perform things, else we shall continue the same as now.

Lets look at the client side, in my next blog.

Thanks for reading and I hope you learned something new.