Exploiting by Information Disclosure in ASP.Net

Information disclosure is considered to be a serious threat where an application reveals too much sensitive information, such as the 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 untangle the information disclosure bugs in software or a website that can be utilized by an attacker to unveil sensitive data or even exploit an other application of the machine and dedicated to newbie developers and experienced professionals and get them the understanding to shield from this attack because they are merely limited to coding and functionality implementation for the software. In fact, software developer don't have knowledge or awareness of the information security framework. Hence they usually don't think like a hacker and leave such bugs inadvertently that are exploited by intruders later.

Abstract

Information disclosure is all about to giving too much information to those who are not believed to be able to access that information. This is one of the most copious threats to software that is often disregarded or typically, isn't handled properly by developers. It is obvious that software used to launch with some inherent bugs are 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 portions 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, an application discloses a user name when certain error occurs during authentication. The hacker can utilize that user name to guess the e-mail address and could do a social engineering attack to trick the user into taking 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 enough information about the victim to exploit it. By gathering such information, the hacker may develop an accurate attack scenario, that will effectively exploit a vulnerability in the website that is running on a specific 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 websites such as NMAP, NESSUS and so on, we are employing here NetCat.exe, that is considered to be one the most efficient tools for getting information about a target. Here, the following output is shown by netcat applied over a victim:



Accurately identifying the web technology architecture information eases the undertaking of choosing an appropriate exploit that reduces the overall effectiveness of a website. 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 in the aforesaid output, the website xyz.com is developed using ASP.NET with version 4.0.
  
  
• Recognize Web Services Technologies: web services reconnaissance begins with inspecting the target Web Services WSDL file that contains critical information like methods, input and output parameters. We typically, could check it through like www.xyz.com/cust.asmx?wsdl this URL.

HTML Page Comments Threat

It is very common that developers include detailed metadata and comments on their source code. However, such information included in 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 a 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 that start with "<!--" and end with "-->" to review or determine if any information is being leaked and finally, 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 mentioned some extra information that 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 image is stored and retrieved as well, this HTML also reveals 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 stored as in the following.



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” that is used for the default strict data type definition:

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

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

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, mainly 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 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, if the programmer had not handled it properly, lots of interesting information could be disclosed.

Here, the user enters 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 whatever typed “ajay” in the user name box is a valid value and the password value is invalid. The hacker can conclude that the user name is Ajay and half of the battle is over because only the password value is unknown to him.



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



So, it is a perfect paradigm of poor programming practices, a hacker can easily assume either a user name or password value using error messages. Rather, such crucial authentication mechanism should be handled properly, error messages must be displayed as in the following figure, here the hacker never ever anticipates either values using an error message.



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



In the previous figure, the page throwing some connectivity to server related but the developer doesn't handle this problem in code and the hacker can get much sensitive information from this error message as in the following:

• 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 in an internal or external error at your websites in ASP.NET, rather than allow the .NET Framework to show the actual error on the page. You should use the following procedure 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 to the root directory of your solution.
   
   
2. Create or modify the <customErrors> section of the web.config file to have the settings in the following image.
   
   
3. Finally, add a CustError.Html page that contains some custom message.
   

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

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 of the actual technical error or internal coding details at this time. He is even unable to grab any kind of sensitive information such as earlier, because the web server load this page, no matter what the actual error is at the server side.



View-State Threat

The web forms data or changes are lost when round tripping to a 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, ASP.NET examines all the controls on your page. If any of these properties have 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, such as:



As in the previous figure, the value of the serial key stored in the view state is showing in Base64 hash format, that is indeed, not a big deal to crack. Another mechanism is shown 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 it into the following text box:



Bingo! We have successfully cracked the Base64 hash value. The hash value has been computed to the serial key as 123-567-890 that 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 using their own custom decipher 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 attribute in the HTML page that encrypts the view state data that makes the undertaking of the attacker harder.

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

Again get the view state data from the web page source after making the option ViewStateEncryptionMode to Always as in the following:



Finally, try to decode the view-state data once again using your own custom mechanism such as earlier. This time, it fails to compute the exact serial key values such as earlier, because the view state values are encrypted and more secure now.



Hence, weak or improper handling of view state data could poses a variety of threats on 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 out of interest to malicious hackers because the data is 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, obfuscation schemes protect clear text data by encoded them. In fact, it makes it harder for the tester to interpret the code or find the bug, but easy for the attacker to break once the encoding scheme is figures 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 the attacker but they are not fullproof to protect sensitive data. For instance, some data sent across the network located in 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 that are passed in hashed format. They can employee numerous conversion tools for UTF formats as in the following:



However, the sensitive data was encoded in UTF-8 format. In fact, this URL sent the user name and password across the network and if you manage to derermine the encoding sache somehow then it would reveal the user name is Ajay and the password is phantom. So encoding of obfuscation tactics makes it 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 be aware of what the data is and how it is being consumed.

Final Word

There are many types of information disclosure and utilized by applications in various forms. Hence, it is difficult to determine which information is useful by the attacker. It is mandatory to handle information disclosure related issues meticulously because if your application reveals enough 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 vulnerabilities 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 pages through which sensitive information could be disclosed.