CEH: Web Applications and Data Servers: Examine IIS Webserver Architecture

In this case, the uname and passwd fields are of interest. A dictionary file with pairs of words can be thrown at this form automatically. The file should include obvious words like “test,” “guest,” “practice,” and so on. With some dumpster diving or other means of collecting information, a company directory can be used to put together likely usernames. Then a dictionary list of common passwords can be used to audit the weak logins.

Abusing the Robots.txt File

All files on a site are organized into folders under its root directory. Robots (spiders) from search engines crawl the directories of a website looking for pages to catalog into the search engine.

Some files such as scripts should be stored in a directory that is inaccessible to the Web user login and instead is only accessible by the Web service that needs to call the library files from other active pages. Other directories might contain documentation or sample code that is not meant for public viewing.

The robots.txt file is supposed to tell a robot what it can and cannot index. It is placed at the root of the website. It also tells attackers where the good stuff is. Consider the following example robots.txt file:

The first line says this file applies to all forms of robots. The other lines tell them what they cannot index. The problem with this is clear—it is up to the robot to be courteous enough to obey the directives.

Offline Browsing

Sometimes it is more efficient to download as much of the website as possible first, and then search through it offline for information such as keywords, e-mail addresses, names, and so on.

Tools such as “wget” and “black widow” are ideal for this activity. Also do not forget about archive.org and “The Wayback Machine,” which archive old versions of sites.

Hidden Form Fields

Whether you are offline browsing or looking at the source code of a recent page, finding hidden form fields is sometimes great. They do not display in the browser window, but the value attribute can carry important data with the form submission back to the server.

In the early days, hidden form fields included prices! The attack simply modified the source code and submitted the page. Presently, hidden form elements might contain password hashes, retry counters, or other significant items. Consider the following example:

Capturing the token using a proxy such as “Paros” would allow attackers to substitute this token with one generated from their own browser, and take over the login session of the other user.

Directory Traversal

One of the other functions of a Web server is to keep the anonymous user account confined to the file system of the website itself. In other words, the root of the website files is the root of what the user can see on the system. In navigating directories, the “../” characters mean “navigate to the parent” directory. On some systems it is possible to navigate to several parents and then drill down into the file system. For example:

http://www.example.dom/scripts/../../../winnt/system32/cmd.exe?c+dir+c:

Starting in the root folder on example.dom, move into the scripts folder (to pick up execute permissions), then come up three parent levels (which might place the attacker at the root of the drive), then drill down to where the cmd.exe utility is and invoke it. The query string passes a command to that shell, and since the result is a character stream, HTTP will return it to the attacker’s browser. On a vulnerable host, a directory listing would be displayed.

This vulnerability potentially exists on both Windows and Linux systems. Filters are available to detect the “../” characters in the URL; however, there are two problems. First, if the programmer of the website decided to use relative links between pages, then the dot dot slashes will appear in the requests intentionally, and the filter will break the website. Second, there are many ways to hide the characters with encoding techniques. Consider the following examples:

%2E%2E%2F

%2E%2E/

%2E.%2F

%%32E%%32E%%32F

These are all equivalent strings once the URL encoding has been parsed, The final example is double encoded. The point is to see that there are thousands of ways to represent a directory traversal attempt. Scanners such as “n-stealth” have tens of thousands of traversal and xss attempts that can be sent to test a Web server for vulnerabilities.

URL Obfuscation

In addition to URL encoding techniques, there are different ways to represent the address of the Web server. This technique is commonly used in spam messages to convince the victim the link is safe. Consider the following examples:

http://eccouncil.org

http://superbank@eccouncil.org

http://64.147.96.106

http://0x40936606A

http://1083400298

http://superbank@1083400298

These are all equivalent addresses. For the CEHv6 exam, it is important that you can use a normal (not a scientific) calculator to perform the conversions. To convert a dotted quad IP address to its decimal form using the previous example, the formula would be worked out as follows:

SSL Attacks

Also referred to as a SSLMiTM attack, this attack begins as a social engineering exercise where a victim is convinced to accept a fake certificate. The website is often a spoofed site designed to masquerade as a common business, as an intranet page, or as a place the victim would be familiar with.

The browser will warn users that the certificate chain cannot be validated, but most users in this situation are not familiar with the idea. If the e-mail they were sent with the link was convincing enough, the victim will be focused on the urgency of visiting the site and will dismiss the warning as being a browse error. The padlock closes, the SSL connection is established, and users are certain they can trust the site with their passwords.

Once the attack is completed, users might be sent to the legitimate site in order to keep the appearance of the scenario intact.

Cookie Stealing

Cookies are small pieces of data stored on the client side (presentation layer) of a Web application. They can then be read back from subsequent pages loaded from the same domain. Netscape invented the cookie object in order to store authentication tokens, customization settings, and dates and times that would allow Webmasters to track usage patterns.

There are some constraints to using cookies. The original specification set out the following rules:

Only the domain that set the cookie could read it.

Browsers will only store cookies from 20 unique domains.

Browsers will only store 200 cookies total.

These constraints were meant to protect clients from having their entire hard drive consumed by cookies. The data are stored in different ways according to the browser design, and they are not always encrypted.

Cookie stealing can be accomplished in the following ways:

Physical access to a system might allow an attacker to simply copy cookies out to a file and walk away.

Using a sniffer or proxy server, unencrypted cookies can be eavesdropped on and then substituted on the next page request.

Companies can triangulate cookie tokens on the back end of an application.

Let’s examine the latter possibility. If “techsite.com” sets a cookie on a visitor’s system that contains a unique token, it can then share that token with an affiliate site such as an advertising partner. The advertisement itself will be downloaded from the domain of the advertisers, who then correlate the token they were given by “techsite.com” and write it into a cookie from their domain. From here, all activity can be tracked, and every link the visitor clicks builds up a database of preferences from which future ads can be targeted. This includes other websites that the ad agency partners with since they could always share the token with them as well.

There are many scripts and examples of using the document.cookie object in JavaScript. The aforementioned http://www.w3schools.com has some excellent tutorials on the topic.

Session ID Hijacking

Session IDs are strings of random characters that are associated with a visitor’s present visit to a website. They can be set and stored in a cookie, transferred in the HTTP header, or even placed in the URL.

Session sidejacking is another name for the process of sniffing this session ID string from a legitimate user. Attackers then start a session with the same website and replace their own ID token with the one captured from the victim’s session. Packet sniffers and proxy servers make this a fairly easy attack if measures are not taken to enhance the token with additional characteristics or to protect it within an encrypted tunnel.

XSS (Cross Site Scripting)

This attack was originally called a CSS attack, and on the CEHv6 exam that term might still be used. Since CSS stands for Cascading Style Sheets, the name of this attack was changed to XSS. Sometimes it is referred to as JavaScript injection.

Many actual XSS vulnerabilities are more complex than the following example, but the basic idea can illustrate the concept well enough. When an HTML form allows a visitor to submit special characters that are not “cleansed” or filtered, it is possible to interact with the code on the logic layer from the HTML form on the client side.

In the case of XSS attacks, the string of characters entered into the HTML form make it all the way through processing and back to the client side with no alteration at all. The client then executes it as presentation script.

Consider the following example: An HTML form is asking for a visitor’s first name. In the field she puts:

Then she submits the form only to find that on the resulting page an alert box indeed pops up and says “FUBAR!” She notices in the url that there is a name value pair that includes the string:

http://www.example.dom/page.xyz?first_name=

She then examines the source code and notices that the injected script looks like something the client would try to execute rather than treat as a simple string of characters. She enters a different parameter into the browser address bar such as:

Then she resubmits the page and is quite surprised by what she sees. The location property of the window object of the browser has changed, resulting in a redirect.

The final step would be to find a vulnerable site and inject a similar redirect attack. The URL can be obfuscated using encoding methods to hide the intent of the link. Send this link in a phishing e-mail and those who click on the link will have unfortunate results waiting for them. Other than not clicking, there is little the victim can do to stop this.

CEH: Web Applications and Data Servers: Learn SQL Injection Methodology

Start by entering disruptive characters like a single tick into a form or through parameter manipulation as is HTTP headers or changing cookies that are not encrypted. Other characters might work but the point is to first cause an error then utilize SQL skills from there. The attack is all about character injection into a request.

CEH: Web Applications and Data Servers: Understand Evasion Techniques for SQL Injection

Filters cannot look for every combination of blah’ or 1 = 1 -- and any other statement that returns true but application layer filters can look for SQL commands that are not appropriate on that segment of the network.

SQL injection works from similar principles as XSS attacks, but involves SQL (Structured Query Language) being passed to the database layer of the Web application rather than round tripping back to the client. Once an SQL injection vulnerability is found, the only limitation to attackers is their skill with SQL queries. Attackers can sit there at the browser and submit SQL statement after statement until the entire backend is mapped, altered, viewed, and controlled.

On an HTML form, the attack tries something along the lines of a single tick character (single quote). If a 500 series error results from the HTTP server, indicating the logic layer script could not do its job, then there is a possible vulnerability. Next attackers try a string such as:

Blah’ or 1 = 1 - -

The “blah” does not matter; it could be anything. The tick disrupts the code on the logic layer and the characters that follow are evaluated rather than simply passed through. The two hyphens cause the rest of the logic layer statement to be commented out and therefore ignored.

Consider the following line of code (it is all meant to be one line):

Set rst=Conn.Execute(“select * from userinfo where username = ‘” & Request.Form(“username”) & Request.Form(“password”) & “ ‘ “)

There are two languages present in this code. One is Active Server Pages and the other is SQL. They are separated by nested quotes (alternating between single and double) so the server side interpreter can make sense out of each statement starting at the innermost nested statements first.

Once the tick and the hyphens are injected into the code by the evaluation of the statement Request.Form (”username”), the characters that follow have a completely different nature to them.

Set rst=Conn.Execute(“select * from userinfo where username = ‘” & blah‘ or 1 = 1 –

The return of this command will be a “true.” The rest of the script is an if/else construct that says “If true then it is all good” else go to the failed login page. This exploit will result in a successful login. Once the vulnerability is discovered, nearly any SQL statement can be inserted instead.