Gunwant Singh

Securing Web.Config through Encryption

2010-06-19T09:08:00.000-07:00

This write-up is effectual for ASP.NET 2.0.

The Web.config is a .NET configuration file which contains sensitive configuration data like connection strings, SMTP information, user credentials, etc. If you try to access Web.config directly from the web browser, you will get the error message “This type of page is not served”. The ASP.NET Engine does not allow the end-user to access Web.config, which is a good security feature in the .NET Framework. However, if the attacker has already compromised the file system of the server, he can access Web.config with no trouble . Therefore, it is highly advocated to encrypt sensitive areas of Web.config. The idea is if the hacker possesses your application's Web.config file, he should not be able to de-scramble the encrypted sections and when an ASP.NET page on the web server requests information from the encrypted configuration file, the data must be decrypted to be used legitimately (and this happens without you needing to write any code in your application).

There are two ways to encrypt Web.config:

- Programmatically
- Manually using the aspnet_regiis.exe command-line utility

There are few things to keep in mind before you deal with encryption mechanisms for your Web.config file:

1. The portions in Web.config that should be encrypted include connections strings, appsettings, portions with SMTP server connection information, user credentials, etc.
2. Encrypting and decrypting configuration sections carry a performance cost. Therefore, only encrypt the configuration sections that contain sensitive information. There's likely no need to encrypt, say, the 'compilation' section or the 'authorization' configuration sections.
3. The programmatic encryption technique can not be used to encrypt the following configuration sections:

- process model
- runtime
- mscorlib
- startup
- system.runtime.remoting
- configProtectedData
- satelliteassemblies
- cryptographySettings
- cryptoNameMapping
- cryptoClasses

In order to encrypt these configuration sections you must encrypt the value and store it in the registry. There's an aspnet_setreg.exe command-line tool to help along with this process (for ASP.NET v1.0).

4. The .NET Framework 2.0 ships with two built-in providers for protecting configuration sections:

1) The Windows Data Protection API Provider (DataProtectionConfigurationProvider): This provider uses the built-in cryptography capabilities of Windows to encrypt and decrypt the configuration sections. By default this provider uses the machine's key. You can also use user keys, but that requires a bit more customization. Since the keys are machine- or userspecific, the DPAPI provider does not work in settings where you wan to deploy the same encrypted configuration file to multiple servers. For more info: http://msdn.microsoft.com/library/default.asp?url=/library/enus/
dnpag2/html/paght000005.asp.

2) RSA Protected Configuration Provider (RSAProtectedConfigurationProvider) : This provider uses RSA public key encryption to encrypt/decrypt the configuration sections. With this provider you need to create key containers that hold the public and private keys used for encrypting and decrypting the configuration information. You can use RSA in a multi-server scenario by creating exportable key containers. For more info: http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnpag2/html/paght000006.asp.

5. In this article we'll only explore using the DPAPI provider using machine-level keys. This is, by far, the simplest approach since it doesn't require creating any keys or key containers, or ensuring access and permission rights to user-level keys. Of course, it has the downside that an encrypted configuration file can only be used on the web server that performed the encryption in the first place. Furthermore, using the machine key would allow the encrypted text to be decrytable by any website on the web server.

Now, let us explore the 2 methods to encrypt Web.config elements:

I. Programmatic way of encryption

1: Create a file test.aspx (for example).
2: In the aspx file, create 2 buttons. One for encrypt and the other one for decrypt.
3: In the code-behind page, create 2 functions. One for encrypt and the other one for decrypt.
4: Create 2 more functions for each onClick event of the two buttons created earlier.
5: Now there will be four functions. See the screenshots below.

Web.config portion to encrypt:

Test.aspx (ASP.NET Page):

Test.aspx.cs (Code-behind Page):

6: Access test.aspx in the browser and click the 'Encrypt Web.config' button.
7: View Web.config section. The encrypted portion will look as shown below.

Encrypted Web.config portion:

Note:

1. Similarly if you want to encrypt another portion of Web.config like the 'appsettings' portion, mention the value 'appsettings' when calling functions Protectsection() and Unprotectsection() in the examples above.
2. After encryption, the file (test.aspx in this case) must not be accessible by the attacker. It is recommended to delete/move the file after use.
3. Test all the steps on a dummy application before doing it on production/development environment.

II. Manual way of Encryption (Using aspnet_regiis.exe)

The utility aspnet_regiis.exe is an IIS registration tool primarily used to register an ASP.NET 2.0 application with the IIS web server. Additionally it can also be used to encrypt/decrypt configuration sections in Web.config. The location of the file is:

C:\WINNT\Microsoft.NET\Framework\v2.0.50727\

Note: The location may exist in the WINDOWS directory of the server.

The general syntax to encrypt a configuration section is:
aspnet_regiis -pef

-prov

The general syntax to decrypt a configuration section:
aspnet_regiis -pdf

- The 'section' field refers to the configuration section like connectionStrings, appsettings, etc. that you want to encrypt.
- The 'physical directory' field refers to the full physical path on the system to the root directory of the web application.
-The 'provider' field refers to the name of the protected configuration provider to use such as DataProtectionConfigurationProvider or RSAProtectedConfigurationProvider.

Example:

C:\
C:\cd C:\WINNT\Microsoft.NET\Framework\v2.0.50727\
C:\WINNT\Microsoft.NET\Framework\v2.0.50727\

Encryption:
C:\WINNT\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -pef "connectionStrings" "C:\Websites\Myapp" -prov "DataProtectionConfigurationProvider"

Decryption:
C:\WINNT\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -pdf "connectionStrings" "C:\Websites\Myapp"

Note:

1. The encryption using the manual technique is server-specific. If you encrypt Web.config on your development server and then copy the file to the production server, the production server would not be able to decrypt it.

2. In the above examples, we have used the "DataProtectionConfigurationProvider" provider. That is why the encryption is server-specific. This is the limitation of this provider. The RSA provider discussed earlier does not have this limitation as it is possible to export the RSA keys to another machine.

The Prevailing Insecurity: Side Channel Attacks

2010-01-28T00:32:00.000-08:00

“The greatest enemy will hide in the last place you would ever look.”

~Julius Caesar 75 BC

We are well aware of the fact that the security systems protect different types of our raw data and processed information. In a world like todays, it is utmost critical to keep up with the latest software patches, properly configured network devices and the newest hardware infrastructure to ensure the protection of organizations’ assets. Whenever we talk about security, for most of that time we talk about digital security or the software perspective of security. In other words, we talk about anti-virus utilities, updating the desktop applications, patching the vulnerabilities of a system or a network, etc. I see no problem with such a viewpoint but what we do not realize is that by emphasizing on one or two perspectives it will not defend us completely from risks. We need to focus on all the viewpoints of a security posture. And, that gives me an opportunity to talk about the disregarded ‘Side Channel attacks’.

The research on Security (and Insecurity) has gone to a substantial depth and researchers have uncovered several serious threats to the involved resources. They have rightly justified the fact that the information we are dealing with on a daily basis is greatly vulnerable most of the time. Side channel attacks are the attacks that exploit the physical implementation of a system. For example: It is positive to use strong cryptographic algorithms, or implement stringent access controls for classified data but what if the attacker is concerned about monitoring the keystrokes of your keyboard rather than trying endlessly to break a 512-bit algorithm. In another scenario, the attacker may observe your monitor or keyboard from a distance with a telescope mounted with a recording device. Notwithstanding, it may sound ridiculous but he may also remotely monitor the LCD image of your screen that is reflected in the eye or the eyeglasses you wear or a tea pot, spoon, or a plastic bottle placed intentionally by the attacker right on your desk. These are just basic examples of Side channel attacks. Let us discuss some real attacks technically in a little bit more detail.

The timing side-channel attack analyzes the time taken by the system processor to execute operations. We know that the time taken to produce an output differs by varying inputs. Now, an attacker can calculate the time taken for different calculations and therefore gain sensitive information about the system. How? You may be wondering. As a practical example, UNIX Operating System used to use a software-function for converting an 8-character password into an 11-character string. UNIX executed this function only if the entered username was correct, irrespective of the password’s validity. So if the username was correct, it took more time to process than if it was incorrect. By exploiting the timing factor, an attacker could gather all valid usernames of a system. He could later use them to brute-force for the passwords. UNIX fixed the issue later by always executing the function to avoid revealing valid login names.

In another attack, an attacker analyzes the variations in the power lines of a hardware device while it is performing different operations. Such attacks are categorized as power monitoring attack. As an instance, the CPU of a system consumes different power-units for different calculations. An attacker sitting in a different room can easily use a standard digital oscilloscope to read power-traces of a system CPU. In an experiment, it was verified that the power profiles for operations like squaring, multiplication, etc can be clearly distinguished thereby allowing an attacker to compute the secret key of an algorithm.

Interestingly, acoustic side-channel attacks exploit the sound (audible or not) which is produced during an operation. In 2004, Dmitri Asonov and Rakesh Agrawal of the IBM Research Center proclaimed that computer keyboards and keypads used on telephones and ATMs are vulnerable to attacks based on different sounds produced by different keys. By analyzing recorded sounds, they were able to recover the text of data being entered. This was demonstrated by placing a high intensity recording device in a near-by location. Also in 2004, researchers demonstrated that it may be possible to conduct timing attacks by carefully examining different humming noises made by the processor for different operations.

By exploiting the aforementioned physical leakage from the power lines, attackers have also learnt to exploit the heat radiations generated by the electronic devices. The surface of the CPU chip can be monitored for infrared images that can provide information about the code being executed internally. Such an attack is known as thermal imaging attack.

Lastly but not at all the least one, some researchers have found that by intentionally exposing a security system to situations where it induces faults can reveal the internal state of its workings. As an instance, a smartcard’s processor might be subjected to high temperature, irregular voltage or current supply, excessively high overclocking, etc. so it may begin to output incorrect results which may help the bad guy to deduce the instructions that the processor is running, or what its internal data state is.

Countermeasures: Because side-channel attacks rely on emissions or physical leakage of information, so the trick is to limit such leakages. This is possible by adding noise to the emitting channels, using data-independent processing techniques, shielding devices with opaque material, etc. And above all, user awareness is required. Who knows if someone cracks these countermeasures in the near future? So stay in touch and keep discussing.

Thank you.

-Gunwant Singh

References:

[1]http://en.wikipedia.org/wiki/Side_channel_attack
[2]http://www.discretix.com/PDF/Introduction%20to%20Side%20Channel%20Attacks.pdf

Application Security Logging Mechanisms

2009-09-14T04:49:00.000-07:00

In this composition, we will discourse about the need and effective use of logging for web applications from a security standpoint. We know logging can be used on varying levels. For example: the logs are maintained on network level (on routers, firewalls, switches, etc.) and then the logs are also asserted on the host level (the windows logs or the web server logs on which the application is hosted). Besides all these different levels, the application must also maintain its own logs that contends against the repudiation attacks. As an instance, say an application user escalates his privileges in an unauthorized manner. None of the logs but application logs would be able to detect the assault or the misuse against a web application. Notwithstanding the web/application administrator must insure about what all information should be logged. [1] Logs are typically properly generated by web and other server software but it is not so common to find applications that properly log their actions to a log and, when they do, the main intention of the application logs is to produce debugging output that could be used by the programmer to analyze a particular error.

It is crucial to ascertain what security events and user information should be logged. Elucidating the fact of what information is to be logged, here is a compiled list of the same:

- All user account management activity
- Addition/deletion of user accounts
- Changes in security attributes (access-levels, login intervals, terminal login restrictions, connection interface)
- User account suspensions/reactivations
- Administrative password resets
- Every access control related event
- Successful and failed logon/logoff events
- Account lockout events (Invalid password, Inactive session, access from un-allowed interfaces, login attempts out of valid intervals, max. concurrent session limit violations)
- Password changes
- Changes to application configuration settings
- Change to critical functional settings (eg. interest rates, service charges, grace period)
- System parameters (e.g. max. no. of concurrent connections per user, Password length)
- Access attempts to application and underlying system resources
- Changes to cryptographic keys
- Startup/stops of application processes
- Abnormal application exits
- Failed database connection attempts
- Attempts to modify critical registry keys
- Login/logoff for Maintenance
- Failed integrity checks for application data, executables and audit log
- Abnormal application exits
- Failed database connection attempts
- Attempts to modify critical registry keys

In general logs have levels i.e. the level of the details about the information. For example: If the management decides to log the password-changes attempts, then the question is to what level the information should be logged, say the username, timestamp, IP address, etc. The logs should be captured with enough level of detail that is actually called for, for a later analysis while equilibrating the need to NOT adversely impact performance. For each event, the following are important to record:

- A Unique event ID and type
- Timestamp of the event
- Error message incurred
- Success or failure of event
- IP address of the client
- User ID instigating the event
- Resources accessed
- Application Interface used by user
- Co-relation with audit trail entries

A sensible security practice is NOT to log the users’ passwords. The question is "Why"? Besides the resources like configuration data, files, information, etc that get compromised, logs may also get compromised. In case users’ passwords were being logged in the first place it would levy serious threat to the organization.

Withal these considerations are assistive to the web administrators, this is not enough. The testing of the logging mechanism must also be performed. From a tester viewpoint, one must see to it that the logs themselves must not violate the security compliance procedures and practices. Here are a few recommendations.

- Design the application so to save the logs to a different system. This will provide a secure modular structure. Else, once the web/application server is compromised, the logs themselves will be exposed to the assaulter.
- Secure the system on which the logs are stored. I mean server hardening.
- Limit access to logs on a need-to-know basis.
- Do not log sensitive information like PIN, encryption keys, crucial hashes and of course passwords.
- Implementation of alert mechanisms to the authoritative person if logging system malfunctions or shuts down.
- The security logs should be archived periodically.
- The application should provide a log analysis console to view the logs and/or analyze them.
- Check if the usage of logging mechanisms can inflict a DoS situation? For example: providing wrong credentials a number of times (say a million times).
- How are they upheld? Are logs kept for the adequate time?
- How about the privileges of accessing/analyzing the logs and the methods used for the analysis?
- How the management of log backups is done? Securing the backup server!
- Is the data “validated” before being logged in the logs? Filtering the strings like %0d %0a etc to prevent the ‘Log spoofing’.

Let us hash out a few things that relate to the best security logging practices mentioned above.

Sensitive Information in Logs: In order to be compliant with the data protection laws, organizations do ascertain of NOT storing clear text sensitive information anywhere. With an objective to be amenable to such restrictions, they store hashes instead of clear text passwords in the back-end databases and also use one time tokens in some cases. In case of logging if the application stores clear text passwords (or even personal data); it violates the data protection act, thereby stimulating heavy penalties to an organization. Not to blank out, some applications use GET request for sending usernames and passwords (Ex: http://www.vulnerable.com/ authenticate.php?username=admin&pass=admin123) and such requests gets logged in the log files. So even if the logging mechanism does not store the user private data in the log files, it WILL – unintentionally.

Log location: Visualize a scenario wherein an attacker has compromised a web server that implements logging mechanisms on the same server. He is now able to manipulate the logs on the server. Imagine how an attacker can easily delete/edit the logs inciting repudiation attacks. So an administrator would never come to know who attacked/compromised the server. Wouldn’t it be sensible to store the logs on a different server? In that case, if the attacker compromised the web server, he has to put some extra effort that may or may not compromise the log server. Importantly, this also makes it easier to aggregate (and/or segregate) logs from different sources and it also makes it easier to do log analysis (which can be CPU intensive) without affecting the server itself.

Log Storage: Envision a scenario of an attack on a web server that has logging mechanism implemented on the same server and on the same partition as the system folder. The attacker repeats some malicious actions (like unsuccessful login attempts, password changes, instigating an error) that gets logged in the log files. Now by repeating such actions (say) a million times, it will fill up huge storage space on the server itself. If the log files reside on the same partition as the system files are, it may create a Denial-of-Service situation. Mitigation: Choose a different partition (preferably a different server and a different partition), monitor and monitor.

Log Rotation: This refers to the fact that servers compress and move the log files to a different location/server after they are administratively NOT required. This also helps in freeing up the space for new logs. A penetration tester needs to check a few things:

- Logs must be compressed before they are stored on a different server.
- The rotation must be done after a specific event like the log file reaches a certain size or after a fixed amount of time. No more, no less.
- He also needs to check if an attacker can forcibly cause the log rotation to hide the malicious actions.
- Nonetheless, the permissions of the compressed files must be stricter. The active log files need write permissions but the compressed ones do not.

Log Analysis: The analysis of logs is a necessity to detect an intrusion or compromise. The analysis should accentuate on the following errors:

- 40x (not found) error messages: a large no. of such error messages may be an evidence/indication of an attack.
- 50x (server error) messages: An indication of SQL injection queries or injection of invalid characters in the form fields.
- Constantly trying to retrieve a file that does not really exist
- Continuous unsuccessful login attempts
- SQL Injection queries/ XSS scripts/ Invalid strings or characters etc.
- Access of admin (sensitive) files/ application configuration files
- Upload/Download of rogue files [big files/malicious files like exe, aspx, asp, etc]

Log analysis/review must not be done on the same server – both from a security and functionality point of view.

Log Spoofing: Let us take an example. A malicious user tries to bypass the authentication module as cited below.

Username: admin
Password: admin123

Now if a user enters admin/admin123 (guessing the password), the log files will exhibit the following log entry:

Login failed for the username: admin

The hacker would manipulate or poison the log files using an out-of-the-box technique. How about entering the following username?

Username: admin%0d %0aLogin succeeded for the username: admin%0d%0a
Password: admin123

The log files would now say the following:

Login failed for the username: admin
Login succeeded for the username: admin

The %0d %0a strings are the line-feed and carriage-return functions that will modify the logs to what the attacker wants. By using the following technique, the attacker can not only modify the logs but s/he can use it to hide his/her malicious actions.

That is all from my side on ‘Logging’. Hope this composition proved helpful. I seek any feedback/suggestion on this if you have time. Have a ball!

Thank you.

References:

[1] Section 4.3.4 - Application Configuration Management Testing: Logging, OWASP Testing Guide v3.

[2] Palisade article: http://palisade.plynt.com/issues/2004Oct/security-logging/

[3] Hyperlink: http://www.infosecwriters.com/text_resources/pdf/top5-log-analysis-mistakes.pdf

[4] Article: Application logs – Security best practices By Dipesh Rawal

[5] http://www.owasp.org/index.php/How_to_add_a_security_log_level_in_log4j (I did not read this one thoroughly but is surely helpful for application developers, so I thought of mentioning it here)

OWASP Presentation: May 2009

2009-06-01T09:45:00.000-07:00

Scrutinizing Full Trust in .NET applications

2009-03-11T08:59:00.000-07:00

In this write-up, I will try to elucidate the so called ‘Full Trust’ configuration in the .NET applications. Now I must make it clear that the ‘Full Trust’ configuration is the default (insecure) configuration which is to a certain extent notorious amongst the web developers and administrators. Some who know about it have no idea on how to configure it appropriately.

Sometimes applications do require ‘Full Trust’ for the functioning of their applications so the trust level must be chosen carefully depending on the requirement and scope of the application. This is done only by a profound critique of your application. Let us first understand what ‘Full Trust’ means with respect to .NET applications. Take for example, a .NET application is hosted and can be accessed using the URL: http://www.test.com and legitimate users can download various reports from the server using the following URL: http://www.test.com/download.aspx?file=report.pdf. Now an adversary can exploit the application by manipulating the URL in the following way: http://www.test.com/download.aspx?file=../../../../../../../windows/repair/sam. Notably the ‘sam’ file contains highly sensitive information. The point is, the attacker has used the application script to access resources that are outside the scope of the application. In other words, it is exactly equivalent to having full trust in the local machine zone or trust outside the application root. The situation becomes highly risky wherein multiple applications are hosted on the same web server. In order to bring down the risk, appropriate trust level can be configured.

There are five levels of trust that can be used for a .NET application which can be configured via web.config in the following way.

You can see trust levels as permissions of your .NET code.

- Full trust: your code can do anything that the account running it can do.
- High trust: same as above except your code cannot call into unmanaged code. i.e. Win32 APIs, COM interop.
- Medium trust: same as above except your code cannot see any part of the file system except its application directory.
- Low trust: same as above except your code cannot make any out-of-process calls. i.e. calls to a database, network, etc.
- Minimal trust: code is restricted from anything but the most trivial processing (calculating algorithms).

The following example [SRC: MSDN] shows the mapping of trust levels to different policy files.

The policyFile parameters above point to the configuration files which are stored in the framework configuration directory (C:\WINDOWS\Microsoft.NET\Framework\version\CONFIG).

Does that seem interesting? Particularly just by configuring a restrictive level of trust will not solve the issue. Some of the application components may require a higher level of trust. I have seen a few cases akin to that, for example, there was this application which when configured from a ‘Full Trust’ to ‘Partial Trust’ stopped functioning because there were some associated dll’s which required ‘Full Trust’ to run. So the developer had to design a custom policy to keep minimal permissions for users. If one wants to restrict the access to the resources outside the scope of your ASP.NET application, he has to specify which permissions your application and the associated resources needs for functioning. Such bespoke policies take considerable effort.

Often developers configure the applications on a medium trust level. Running medium trust will have the following application permissions besides others:

. Access to Microsoft SQL Server databases
. No registry access,
. No event log access,
. No ability to use reflection.
. Web access is limited to the network address that you define in the <> element
. File system access is limited to the application's virtual directory hierarchy.

If medium trust policy is too restrictive, you can create and use a custom policy file. The different permissions of different trust levels are shown below.

High Trust:

Medium Trust:

Low Trust:

Minimal Trust:

This ends the basic discussion on the trust levels in the .NET applications for now. In my next write-up, I will re-consider the same topic but I will come up with a more detailed explanation on the configuration of ‘Partial Trust’ and how to build your own policies for a flawless hosting of your application. So keep up a correspondence.

Thank you.

OWASP Presentation Delhi Chapter - January

2009-02-05T09:54:00.000-08:00

Putting salted MD5 hashing into action

2008-12-18T23:00:00.000-08:00

In the preceding OWASP Delhi meet-up, I discussed the salted MD5 hashing technique. It is straight-forward to understand and identify the workings of the method; however it is not that easy to implement it in your web application. I will try to explain that how we can programmatically implement this technique in our applications.

As a reminder, the following slide shows the working of salted MD5 hashing.

There can be a number of ways by which the above shown system can be implemented but I identified the following execution flow to put it forward to your application so to successfully implement this system.

1. The file random.php generates a highly random number at the server side which can be used as a salt for a particular instance.

2. The random.php file is included in the login.php file and then it (login.php) is sent to the user. The login.php file is served to the user along with the salt, md5.js JavaScript file and the HTML code.

3. The user provides his username and password to the file and clicks the ‘Submit’ button. The password is first converted into an MD5 hash and is then concatenated with the salt. The ensuing string is again keyed in to the MD5 function.

4. The final result is presented to the authenticate.php which actually compares it with the string calculated at the server side.

5. This technique assumes that the passwords on the database server are already stored in the MD5 hashed form (which provides an extra layer of security for obvious reasons).

6. To compute the string at the server side, the authenticate.php file picks up the password from the database and concatenates the same salt (which was sent to the user in the first place) to it and then hashes into the MD5 form.

7. If the result sent from the client to the server is same as calculated at the server side, the user is granted access to the application resources.

The code follows:
- The <> tags have been changed to ()

[ random.php ]

(?php

session_start();

$nonce = md5( rand( 0, 65337 ) . time() ); //generates the salt

$_SESSION['nonce'] = $nonce; //stored in the session object

[ login.php ]

(?php
session_start();
include('random.php'); //salt is included in the login.php file
$salt=$_SESSION['nonce']; //stored in a variable
?)

(html)
(body)

(script language="javascript" src="scripts/md5.js")
(/script)

(script)
var nonce = ""; //php variable stored in a JS variable nonce
function hash() //function to calculate the salted hash
{
var temp=md5(document.a.password.value);
var temptwo=temp+nonce;
document.a.password.value=md5(temptwo);
document.a.submit();
}
(/script)
(form name="a" autocomplete="off" action="authenticate.php" method="POST")
Username: (input type="text" name="username" /)

Password: (input type="password" name="password"/)

(input type="button" value="Login" onclick="hash();"/)
(/form)

(/body)
(/html)

[ authenticate.php ]

(?php
session_start();
$user=$_POST['username'];
$pass=$_POST['password'];
$con = mysql_connect("localhost","root","password"); //insecure
$salt=$_SESSION['nonce'];
unset($_SESSION['nonce']); //unset the salt session variable
if (!$con)
{
die('Could not connect: Please retry. ');
}
else { }
mysql_select_db("gunwant", $con);
$result = mysql_query("SELECT * FROM users");
$bt=0;

while($row = mysql_fetch_array($result)) //fetch the credentials from the DB
{
$temp=($row['password'].$salt);
if (($user == $row['name']) && ($pass == md5($temp)))
{
$_SESSION['username'] = $row['name'];
$_SESSION['role'] = $row['role'];
if ($_SESSION['role']=='admin') {header('Location: admin/welcome.php');}
if ($_SESSION['role']=='power') {header('Location: power/welcome.php');}
if ($_SESSION['role']=='user') {header('Location: user/welcome.php');}
$bt=1;
}
} //while ends
if ($bt == 0)
{
echo "\nIncorrect username/password. Please try again.";
include('login.php');
}
mysql_close($con);
?)

(html)
(/html)

[ welcome.php ]

(? php
session_start();
header("Cache-Control: no-cache,no-store", true); //prevent caching
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");

if ($_SESSION['role']!= 'admin') {header('Location: ../logout.php');}
if((isset($_SESSION['username'])) && ($_SESSION['role']=='admin'))
{
echo "Welcome ".$_SESSION['username']." ! Your role is ".$_SESSION['role'];
}
else
{ }
?)
(html)
Click (a href="../logout.php")here(/a) to logout.
(/html)

Points to note:

1. The salt is generated at the server side.
2. The salt should be highly random.
3. The salt should not be involved in the transit from client to server.
4. Once the results are compared, the salt should be unset (disabled) for that instance.
5. The code shown above may not be the best code written so I seek your feedback on ways to improve it.
6. To be done:
- Implementation of SSL
- Setting the value of “form.password.value” to “ “ (NIL) so it does not get stored in the browser memory.
- CAPTCHA implementation on the login page to prevent brute force attacks.
- Something to be done to secure the hardcoded DB credentials
- DB hardening

Thank you.

‘HTTP Response Splitting’ in plain words...

2008-12-04T00:26:00.000-08:00

Although, there are many articles/documents/whitepapers on this topic, professionals do not have a firm understanding of the basics of this vulnerability. Many of my friends have asked me to shed some light on this topic. This write-up is an attempt to make this subject matter more comprehensible.

Some people say it’s a web-server level attack but actually it’s a pure application level attack. I will try to explain this attack in simple words - how it works and how to safeguard the applications against this. The explanation is based on the interception of the requests and replies via the Burp-proxy, a web proxy/interceptor available at http://portswigger.net/proxy.

To understand the underlying vulnerability, configure your web browser so the requests and replies get intercepted in Burp-Proxy. For example,

1. A user navigates to the URL http://testingHRS.com/somefile.php?someparam=123 and intercepts the first request as shown.

GET /somefile.php?someparam=123 HTTP/1.1
Host: www.testingHRS.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)Gecko/20050317 Firefox/1.0.2
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

2. When he forwards the request in the Burp-proxy, he sees the first reply that gets intercepted as shown below.

HTTP/1.1 302 Found
Date: Tue, 12 Apr 2005 21:00:28 GMT
Server: Apache/1.3.29 (Unix) mod_ssl/2.8.16 OpenSSL/0.9.7c
Location: http://www.testingHRS.com/somefile.php?someparam=123
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

Note the reply is 302-type which means it will redirect the browser to another location. That location (highlighted above) is the same as it is in the ‘Location’ header directive.

Importantly, in Step 1 whatever URL the user types in (requests), gets returned to the requesting user by being included in the 'Location' directive of the 302-reply. Here lies the vulnerability.

'What’s wrong', you ask. The answer is that the input from the user is not validated at the server-end and is directly included in the ‘Location’ header directive or some other directive. Therefore, to exploit this, an attacker would try to include some malicious data in the response header. Here is how it is done.

Exploitation:

Consider the same example again. Say an attacker crafts the URL (below in black and red) and sends it to the legitimate user. The attacker uses social-engineering against the user to persuade him to click on the URL link.

http://testingHRS.com/somefile.php?someparam=123%0d%0aContent-Type:%20text/html%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0a%0d%0a%3Chtml%3E%3Cfont%20 color=red%3EThis%20 is%20malicious%3C/font%3E%3C/html%3E

We know,

CR (carriage return) = \r = %0d
LF (Line Feed) = \n = %0a

1. So the request will now become:

GET /somefile.php?someparam=123%0d%0aContent-type:%20text/html %0d%0aHTTP/1.1 %20200%20OK%0d%0aContent-Type:%20text/html %0d%0a%0d%0a%3Chtml%3E%3Cfont%20color=red %3EThis%20is %20malicious %3C/font%3E%3C/html%3E HTTP/1.1
Host: www.testingHRS.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050317 Firefox/1.0.2
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/pla
in;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

2. And the 302-reply will now become:

HTTP/1.1 302 Found
Date: Tue, 12 Apr 2005 21:00:28 GMT
Server: Apache/1.3.29 (Unix) mod_ssl/2.8.16 OpenSSL/0.9.7c
Location: http://testingHRS.com/somefile.php?someparam=123
Content-Type: text/html
HTTP/1.1 200 OK
//Second New response created by attacker
Content-Type: text/html
This is malicious
…

So there will be two replies (Splitted response) – One will be the application generated response and the second one will be the attacker controlled response (HTML). The attacker generated code can be another HTML or it can be something that sets a cookie at the client side, etc.

It is up to the imagination and skill of an attacker what code he wants to incorporate into that HTML page. The initial crafted URL can be sent to the user via email/chat/etc. Some social engineering is definitely needed so he can convince the user to access that URL.

Some points to note:

1. It is definitely not essential that the application will include the user input in the ‘Location’ directive only. I have seen many applications that includes the user input in ‘Cookie’ directive or some other directive. The URL needs to be customized depending upon where the application includes the user input.

2. It is also not mandatory to have the user input included in the 302-type reply, but any type of reply (200,404, etc) is equally vulnerable if the user input is included without validation.

Attacks like XSS, CSRF, Cross-user defacement, web-cache poisoning, and all client-side attacks are possible. This is quite serious!

Obvious Mitigation: Validate the user-input before including it in the Response header. One type of validation that will alleviate most HTTP Response Splitting attacks is to not allow any CR and LF strings.

OWASP Delhi Chapter Meet-up: Nov 29 2008

2008-11-22T00:13:00.000-08:00

Hi all,

I feel very happy to host another session on the 29 of this month on 'DeMystifying Authentication attacks'. I discussed these issues with one of my ex-client some time back, however there are a lot more interesting facts that I collated some time ago. Issues like improper 'Forgot Password' implementation, improper 'Reset password' Implementation, CAPTCHA issues, advanced SQL Injection, Replay attacks, etc. will be discussed. I would appreciate if you want to take this discussion further so we can learn more.

See you there. For details, check it out here.

CAPTCHA issues !

2008-11-11T01:57:00.000-08:00

ok, CAPTCHAs! A way to tell computers and Humans apart. That's what CAPTCHA vendors think. However, there can be some serious weaknesses in the CAPTCHAs that can put these mechanisms to a place that involves critical threat to your applications. Its interesting to talk about these vulnerabilities not just about how they should be implemented but also how anyone can write a code that can crack some complex CAPTCHAs. I read some articles that described about what CAPTCHA types are safe to implement and how & why they should be implemented.

This write-up is an attempt to discuss CAPTCHA issues that were unexplored to a required extent uptil yet but also to egg on for further research in this area. I would like to share knowledge that I gained while auditing web applications involving CAPTCHAs. I will consider five scenarios to describe the CAPTCHA issues.

Firstly, consider an application wherein there is a page with a form and a CAPTCHA. The developer has some saved CAPTCHA images (say 10, 20, 30 ... whatever is countable) on the server and the application code is validating each displayed CAPTCHA image with the respective value of that specific image. How can an attacker exploit this scenario? An attacker can explore the application for all images stored on the server to get the corresponding values of all those images stored on the server just by visiting the page a number of times. And then, he can write a code to submit the form by throwing all the collected values one by one through the application. One of them obviously will be the correct value for a particular image. This way the attacker has automated the process of submitting forms, although a bit slow. An attacker can write a script that can run consistently comparing all values each time it submits the form to the server - thereby creating a DoS situation. Obvious mitigation: One should rely on a highly random CAPTCHA and not the fixed/stored ones.

Secondly, consider the same application with a random CAPTCHA each time the page is visited. An attacker checks the web page and submits the form in a legitimate manner. He sees that when he clicks the 'Back' button on the browser and hits 'submit' button again, the form values get submitted again with no problem. Now what if he writes a script to submit the same form values and same CAPTCHA value a no. of times..probably a million times or may be more? Thats another issue that needs to be addressed. Mitigation: What I think of is to generate random CAPTCHA with each visit of the page. Also, at the server side, application must not accept same value of CAPTCHAs more than once. Caching and history control mechanisms would be helpful. Any other thoughts..??

Thirdly, an application with sequential CAPTCHA values. Funny enough to discuss! Refresh the page and the CAPTCHA value will change sequentially. Easy to fool the application. Mitigation: Make the CAPTCHA implementation highly random.

Fourthly, it does not matter whatever the CAPTCHA value is - it is not validated at the server side. There was this application which I audited a long time back and there was high randomness of the CAPTCHA at the client side but what I found out was there was no validation at the server side or may be there was but improper. So I strongly recommend to have a proper validation of the CAPTCHA value at the server side.

Lastly, I read an article on http://ha.ckers.org that discussed about MITM (Man in the Middle) attacks. I totally agree with the idea described there and I think this is possible. What that article said was if an attacker hosts a high traffic website and he writes a code that picks the CAPTCHA image from the target website and displays it on his web site to ask the users to solve it and then post back the answer back to the target site. This way he can postback the form in an automated way against the target website using a script.

Moreover I have heard about some people sitting remotely can manually solve CAPTCHAs like solving a few thousands CAPTCHAs for a few dollars (Human solvers). This is crazy! Practically this can surely be done to launch a DoS/DDoS attack for some big amount of money. Nonetheless, we have 3D CAPTCHAs. Interesting! Another challenge for crackers to crack. Check out an article here: http://spamfizzle.com/CAPTCHA.aspx. Have you heard of PWNTCHA? PWNTCHA is an application that decodes different vendors' CAPTCHAs, to varying degrees of accuracy, producing evidence for the case that CAPTCHAs don't do a great job of keeping bad guys out nor of letting good guys in - LOL. PWNTCHA stands for "Pretend We're Not a Turing Computer but a Human Antagonist" ha ha. The goal of this project is to demonstrate the inefficiency of many CAPTCHA implementations. Good to know!

Hopefully this write-up made you understand of the issues that can be critical to even a complex CAPTCHA implementation. There can be more issues which must also be considered. These issues are the ones which I found while auditing applications myself - so don't rely just on the ones mentioned here. Please do let me know if you want to further discuss/talk about any CAPTCHA (or any Security) issue(s) at all. I would be happy to do that. Pleasure is always mine.

Some nice Windows shortcuts

2008-11-01T15:17:00.000-07:00

I got this nice info from windowsinternals.com. These are just some good windows shortcuts. Either run from the dos prompt or run prompt in windows (Start > Run).

Management console shortcuts:


Computer Management              compmgmt.msc
Disk Management                  diskmgmt.msc
Device Manager                   devmgmt.msc
Disk Defrag                      dfrg.msc
Event Viewer                     eventvwr.msc
Group Policies                   gpedit.msc
Shared Folders                   fsmgmt.msc
Local Users and Groups           lusrmgr.msc
Performance Monitor              perfmon.msc
Resultant Set of Policies        rsop.msc
Local Security Settings          secpol.msc
Services                         services.msc
Component Services               comexp.msc

Control Panel Shortcuts:

Security Center                   wscui.cpl
Display Properties                desk.cpl
Firewall Settings                 firewall.cpl
Internet Options                  inetcpl.cpl
Network Connections               ncpa.cpl
Sound and Audio                   mmsys.cpl
User Accounts                     nusrmgr.cpl
Power Options                     powercfg.cpl
System Properties                 sysdm.cpl
Add/Remove Programs               appwiz.cpl
Automatic Updates Configuration   wuaucpl.cpl

OWASP Delhi Chapter Meeting held today

2008-10-18T10:48:00.000-07:00

It was absolute fun.

Pics: http://picasaweb.google.com/pukhraj/OWASPDelhiConferenceOctober182008

Guys I am really thankful to all of you who've taken participation in the chapter meeting and have appreciated all of us presenters. I am also thankful to the organisers especially Dhruv and Puneet who've given me such an excellent oppurtunity to share my work with all of you. I really enjoyed the other two presentations and ofcourse the company of all you guys. I hope there will be more such knowledge sharing sessions in future that will help us in all ways and I hope you will support the same way in future as well.

You can download the presentations here:
http://www.owasp.org/index.php/OWASP_Delhi_Meeting_October_18th_2008#Event_Presentations

Any queries, buzz me at (gunwant dot s at gmail dot com). I will also try to add more research work here as I get time.

Thank you all.

OWASP Delhi Chapter meeting 2008

2008-10-14T22:10:00.000-07:00

Hey,

So there is another meeting in 2008 after the big OWASP AppSec Conference in Delhi. I will be speaking on XSS, CSRF , some infamous attacks (Cross site tracing, Cross site cooking) and a few XSS variants. There are guys who will be speaking on Client side attacks , Web services and things like that. Seems interesting! Hope to see you all there.

Cheers.

Information Security

2008-06-23T09:58:00.000-07:00

Hi,

Welcome to my blog spot. This is the first time I am on blog spot. I will add posts on application security, network security and other topics of information security. I am building this up as I get time. Please bear with me.

Thanks.

Gunwant.PublicKey

2008-01-27T09:00:00.000-08:00

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.14 (GNU/Linux)

mQENBE3p1goBCADpq/3FQFm9RoODYdZvA7ClLHKZbmYktXSa3OJdNQI9VxX44bgF
aQE9HgzteX7OlucVX6A1bD9/8pjg+erjjzNzi9ldtv9TYErjbri3XMNYOwSBlZA4
WF+xiZwtJ2ziJE21GfnQBhEBikFxp1Z30VUJBqVAia2v7gJd2LIqTJRuOgAJSzzB
/K3WUGwFQ62foXesgWuYCntXdG0YpVku8yrOpKhvilkAtj38byxAFZSjbp/3oz34
H0FTRJhRo+YiIhu4+e5SzJGB2QHJVOfOA5GtYqWtbizIpXfAD1jP8dQyowh/7H2z
OzuO1WPHZ5wq28Cpq2SmTIs1MUq0lOqRzgk9ABEBAAG0I0d1bndhbnQgU2luZ2gg
PGd1bndhbnQuc0BnbWFpbC5jb20+iQE4BBMBAgAiBQJN6dYKAhsDBgsJCAcDAgYV
CAIJCgsEFgIDAQIeAQIXgAAKCRBX8R76Z8PnZUKiCACvHb14v3XI7ieGWLSDC8+f
xiXjYw6G9sa2qacAJiYqeqJGDikr0oghMYC1FwsR5yChH0U6m/0RpgesFutsMUu+
ZbMD1vdzkX+RILG3ziR8LEErgUuNOf7gno0W3oS5hiAXWRYGxs49cDALhqm/wbkW
gqQtVY0MLORwBNn+NCgs40j0DvYWxmA+FAIBtZj38YzRDGFtWyhcZtXYDmN00Qw3
XcQqouTPrkPig2r8K0oIAuOPqoRGFZf6PUfStgpOvxmeGOil0i9iowUCgNrtULyM
Ks+FXcH2VUIMfVrunw2/a+XbulzHdNTo8bZuld/NHhRirk0hbSv0RLP72FdGwOjV
uQENBE3p1goBCADEtAPuvEGTl4ZW1vJKkjP4ShKz2q6IOTIbQ8Egco+XVs+XoAGp
hgnkdy6B7C7mv3kYDUoKc/IwkJu8gozee2FDBw42uFEgrUav4JNXlgjsp1ZcnG3i
TaM8zbthc0f/MPXv0d8e6kNTt6eSfAVzblJ4qKC1pCRlJKyTHttVCdeglXPT90WQ
i8NWDfNYSc7F/ep32QfWfWB+WzuoHtBefw7LDaPbW4umu+IHdAYqek72nKrD1ojc
er4B+v+NELdGybIc0it99F2TfAUNE+fa4TrPBFgOd4clxhRJRj23W+tTmnP4CEeL
rBq62fefDIpbuEUtBlhkr038FVpcW7SoRABJABEBAAGJAR8EGAECAAkFAk3p1goC
GwwACgkQV/Ee+mfD52UO1wf/XBQOocQC8iyZb4pJWdm16SNSXO7WZxdD4wuNmqgL
7L1FFREjIZr+qxsRhuhZwb+sxd1DYJpe6NreQVAIX+MKXWkZAfC4CiJnTEwdlome
cwdD7QBR3f09SXo8hG0GJLzm27353Co/vu/c052Ld3/Rql+13AH9Yrjh+uEdN+2L
+nemgCIj/xHlqtJ1AYq+RngSuzNGBuZ6mZtU+mzxffaRQxAT9iA7uV3HwrClaJag
4hPSJgPCCPBgwoOEwSJzMpkCWU6pVK+6zW/rWzMdr9ckI2H4pwVdlbdr2U0hwSNI
hzQ+5SdSzihbOyI2msiTMBAcOh52KCaTWbAOMSJVqa12cA==
=aFkC

-----END PGP PUBLIC KEY BLOCK-----