Exploiting by information disclosure, part 1

Information disclosure is considered to be a serious threat, wherein an application reveals too much sensitive information, such as mechanical details of the environment, web application, or user-specific data. Subtle data may be used by an attacker to exploit the target hosting network, web application, or its users. Therefore, leakage of sensitive data should be limited or prevented whenever possible. This paper is intended to unfold the information disclosure bugs in software or websites which can be utilized by attackers to unveil sensitive data or even exploit other applications of the machine, and it is dedicated to newbies, developers, and experienced professionals to get them to understand how to shield from this attack, because they are limited to coding and functionality implementation for the software. In fact, a software developer doesn't have knowledge or awareness about information security framework. Hence they usually don't think like a hacker and will leave such bugs inadvertently, which are exploited by intruders later.

Abstract

Information disclosure is all about giving too much information to those who are not believed to be able to access that information. This is one of the most copious software threats which is often disregarded or typically isn't handled properly by developers. It is obvious that software used to launch with some inherent bugs, which were exploited by intruders later. Some bugs can be manipulated to disclose significant information to breach the system.

Sensitive information disclosure bugs often are marginalized because the software developers do not understand how an attacker could manipulate the information obtained to help break the application. It is mandatory to comprehend how disclosing certain a portion of data can be a security problem, because if hackers can obtain some data, they will try to use it against your service or software to exploit other vulnerabilities. For instance, some application discloses a user name when a certain error occurs during authentication. The hacker can utilize that user name to guess the e-mail address, and could perform a social engineering attack to trick the user into taking an action that gives the attacker an advantage.

Reconnaissance threat

Reconnaissance or fingerprinting is the leading phase of attacking a target, in which the attacker gains as much information as possible about the victim to exploit it. By gathering such information, the hacker may develop an accurate attack scenario, which will effectively exploit a vulnerability in the website, which is running on a particular web server. Reconnaissance assists to create a precise profile of the target's platform, configurations, web application, database version, and possibly even their network topology.

Although there are bundles of web penetration testing tools available to enumerate the information about a website, such as NMAP, NESSUS, etc., we are employing here NetCat.exe, which is considered to be one the most efficient tools for getting information about a target. Here is the following output shown by NetCat applied to a victim:

[html]

D:> nc www.xyz.com 80

GET / HTTP/1.0

HTTP/1.1 302 Found

Cache-Control: private

Content-Type: text/html; charset=utf-8

Location: /en/us/default.aspx

Server: Microsoft-IIS/7.0

X-AspNet-Version: 4.0.30319

P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo C

NT COM INT NAV ONL PHY PRE PUR UNI"

X-Powered-By: ASP.NET

Date: Sat, 14 Jul 2007 15:22:26 GMT

Connection: keep-alive

Content-Length: 136

[/html]

Accurately identifying the web technology architecture information eases the undertaking of choosing an appropriate exploit, which reduces the overall effectiveness of a website. The reconnaissance typically categorizes the banner-grabbing in the following tactics:

• Recognize Web Server and Version: the website is hosted on a Web server such as IIS, Apache, and Tomcat. Here, we can identify that the target machine is deployed on the Internet via IIS web server.
• Recognize Web Technology: There are multiple Web technologies used to build a Website such as ASP.NET, JSP, SERVLET, and CGI. As per the aforesaid output, the website xyz.com is developed by using ASP.NET version 4.0.
• Recognize Web Services Technologies: Web services reconnaissance begins with inspecting the target Web Services WSDL file, which contains critical information like methods, input and output parameters. We typically could check it through with www.xyz.com/cust.asmx?wsdl.

HTML page comments threat

It is very common that developers include detailed metadata and comments on their source code. However, such information included into the HTML source code might expose to a potential hacker internal intelligence that should not be accessible to them. HTML pages usually contain too much subsidiary-sensitive information in the form of comments and metadata such as usernames, passwords, SQL code, internal IP addresses, debugging information, improper server configurations or page responses for valid versus invalid data, and failure to clean out such HTML comments containing sensitive information could pose a serious vulnerability to a Web application.

This inherent threat could easily lead to leak of contextual or profound information such as SQL query structure, server directory structure, and internal network information. Sometimes developers forget about the comments and they leave them on in production. Attackers usually look for HTML comments which start with "<!--" and end with "-->" to review or determine if any information is being leaked and to gain more insight about the application.

The following HTML code snippet is for retrieving and storing registered users along with their image information over a web page. At the time of development, the programmers would have mention some extra information which are entirely irrelevant to this page functionality, and unfortunately, they forget to scrub them out at the production site. Here, if an attacker views the source code of this HTML page, he can easily determine the server IP address as 192.168.20.120 where the images are storing and retrieving, as well as this aforesaid HTML also revealing the SQL server password as scott@123 along with the table name as tblusers, along with the column name where the registered user's information is storing as the following.

[html]

<!—Insert Images into SQL database by admin password for testing: "scott@123" -->

<!--Restart 192.168.20.120, If the images fail to load-->

<!-- Query: SELECT ID,FName FROM tblusers WHERE active='1' -->

<div><span>ID</span>

<span>First Name</span>

<span>><img src="~/file/xyz.jpg" alt="testing"/> </span>

</div>

[/html]

Moreover, the attacker can easily determine the HTML version information for valid version numbers and Data Type Definition (DTD) URLs. Here, the following code shows "strict.dtd" which is used for default strict data type definition as:

[html]

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

[/html]

So, it is always recommended to wipe out all the extra information contained in the HTML comments or metadata at the time production, even if such information is included at the coding site. Otherwise, your web application could be exploited easily.

Website Error Message Threat

Many web applications return informative error messages when unexpected events occur. These messages may be useful for attackers. Most web applications are written in languages that are more complex than simple scripts like Java, C#, and Visual Basic .NET. When an unhandled error occurs, it is common to see full stack traces being returned to the browser in those languages. The following login page is showing an example of a real web site for authenticating users. It is obvious that the programmer would have implemented some validation mechanism in order to validate the correct user name and password. Here is the hack, and if the programmer had not handled it properly, lots of interesting information could be disclosed.

Here, the user types the username and password, but the following error message is immediately reflected the moment he hits the login button. So, one can easily assume that "ajay" in user name box is a valid value and password value is invalid. Hackers can conclude that the user name is ajay and half of the battle is over, because the password value is the only unknown to him.

Here in a second scenario, one can easily conclude that he has entered the correct password value and only the user name value is incorrect.

So, in a perfect paradigm of poor programming practice, a hacker can easily assume either user name or password values through error messages. Rather, such crucial authentication mechanism should be handled properly. Error messages must be displayed like in the following figure. Here, a hacker never anticipates either values through an error message.

Sometimes, users might be frustrated because the website does not appear to be working properly due to some technical mistakes such database connectivity lost, network error, or runtime errors. If such a problem has not been anticipated or handled prior to development time, the Web page shows the source of error or other information related to particular problem in form of trace. However, a malicious hacker can uncover a lot of interesting information from an such error message as the following:

In the aforesaid figure, the page is showing a server related issue, but the developer doesn't handle this problem at the time of coding, and a hacker can get much sensitive information from this error message, such as:

• Database Server IP Address= 192.168.10.120
• Database Name= Northwind
• Login User Table Name with columns = UserDetails, UName, UPass
• Page storing location to web server

It is a professional and secure programming practice to always show a custom error page status with occurrence of any internal or external error at your websites in ASP.NET, rather than to allow the .NET framework to show the actual error on the page. You should follow the below steps to enable <customErrors> and map all errors to a single error page:

1) Edit your ASP.NET Application's root Web.Config file. If the file doesn't exist, then add it in the root directory of your solution.

2) Create or modify the <customErrors> section of the web.config file to have the settings in the below image.

3) Finally, add a CustError.Html page which contains some custom message.

[xml]

<configuration>

<system.web>

<customErrors mode="On" defaultRedirect="~/CustError.html" />

</system.web>

</configuration>

[/xml]

Once the custom error page CustError.html has been configured properly, the web page now loads this page in case of any unexpected error occurrence. The hacker has no idea about the actual technical error or internal coding details at this time. He is even unable to grab any kind of sensitive information like earlier, because the Web server loads this page, no matter what the actual error is at server side.

View-state threat

The Web forms data or changes lost while round tripping to the server due to the stateless nature of HTTP. Hence, the ASP.NET uses View-State as a client side state management mechanism for storing values of a web page during round tripping from the server. Once your web page code has finished running, the ASP.NET examines all the controls on your page. If any of these properties has been changed from its initial state, ASP.NET makes a note of this information in a Name/ Value collection. Finally, ASP.NET takes all the information it has combined and then serializes it as a Base64 string. The View-State is typically accumulated in a hidden field with an ID __VIEWSTATE.

The following example is just storing serial key values into page View-State for further reference. If an attacker inspects the HTML page source, he can find the following View-State information in the hidden field like so:

As per the aforesaid figure, the value of the serial key stored in View-State is showing in Base64 hash format, which is indeed not a big deal to crack. Another mechanism is showcasing below, to decipher the Base64 hash format of View-State values. Just, copy the view state value in the hidden field from the earlier image and paste into following text box as;

Bingo! We have successfully cracked the Base64 hash value. The hash value has computed to the serial key as 123-567-890 which is contained in the page view stated in encrypted form. So, hashing with Base64 or storing sensitive information in the View-State is quite dangerous, anyone could circumvent the web page data through their own custom deciphering mechanism.

In order to protect the View-State data that contains highly sensitive data such as session value, password or serial key, it is recommended to use the ViewStateEncryptionMode attributed in the HTML page, which encrypts the View-State data, which makes the undertaking of the attacker more difficult.

[html]

<%@ Page Title="Home Page" Language="C#" AutoEventWireup="true" ViewStateEncryptionMode="Always" CodeBehind="Default.aspx.cs" inherits="WebApplication1._Default" %>

[/html]

Again, get the View-State data from the Web page source after making the option ViewStateEncryptionMode to Always as:

Finally, try to decode the View-State data once again through your own custom mechanism like earlier. This time, it fails to compute the exact serial key values like earlier, because View-State values are encrypted and more secure now.

Hence, weak or improper handling of View-State data could pose various threats to your website in the form of Spoofing, Cross-site scripting, Information leakage, and SQL Injection attacks.

Obfuscated Data

It is important to identify interesting data, but sometimes information is absolutely outside of the interest to a malicious hacker because the data are not understandable or not readable. In fact, data might be obfuscated, and so the information disclosure bug might not be easily discovered. Vendors usually implement obfuscation over sensitive code segments, hence the process of modifying data is not an easy task but not impossible. Still, such data can be interpreted. Actually, an obfuscation scheme protects clear text data by encoding them, it in fact, making it harder for testers to interpret the code or find the bug, but easy for the attacker to break once the encoding scheme is figure out. Here are some common data encoding methods developers might use to protect sensitive data:

• Base64
• XOR
• Hexadecimal
• Mime
• Rot-13

Note, the aforesaid encoding scheme just hinders the path of an attacker, but they are not fool-proof to protect sensitive data. For instance, some data sent across the network located in a URL might look like http://www.xyz.com?%75%73%72=%61%6a%61%79&&%70%77%64=%70%68%61%6e%74%6f%6d. Not too readable.

An attacker can easily circumvent the URL sensitive values which are passed in hashed format. They can employee numerous conversion tools for UTF formats as follows:

However, the sensitive data was encoded in UTF-8 format. In fact, this URL sent user name and password across the network, and if you manage to figure the encoding sachem somehow, then it would reveal the user name as ajay and password as phantom. So encoding of obfuscation tactics makes harder to recognize, but is not the ultimate solution to protect data. A developer might also use their own custom scheme to try to protect the data. The important point is that we should aware what the data is and how it is being consumed.

Final word

There are many types of information disclosure utilized by applications in some form. Hence, it is difficult for the attacker to determine which information is useful. It is mandatory to handle information disclosure related issues meticulously, because if your application reveals so much information, an attacker has an advantage to use against the application, system or even another program. In this paper, we have been able to get an understanding of various types of vulnerability in an ASP.NET pages in the form of Comments, View-state, and Error messages. In the forthcoming articles of this series, we shall resume our voyage by covering another interesting vulnerability in an ASP.NET page, through which sensitive information could be disclosed.