The heat is on for web application firewalls now days. But what is making it so popular at this time than ever before? The only thing coming to my mind is PCI DSS requirement 6.6. According to this requirement, all web facing applications need to be protected against known attacks either by having the application source code reviewed for common vulnerabilities by an organization specializing in application security or by installing an application layer firewall in front of the web facing application. The deadline for meeting this requirement is 30th June 2008.
Even though you need to meet one of these requirements to become PCI compliant, wouldn't it make more sense for a security conscious organization to adopt both these measures, one during development and the other in production?
That said this may only be feasible for all those applications which are still in development or near completion. But what happens to all those applications which are already in production for a long time now, having complex mulit-tier architectures along with all those legacy systems in place. Is it really feasible to get the source code reviewed for all these applications, and if its done, is it really possible to remediate all those vulnerabilities found during source code review to meet PCI deadline. Probably not, for such a short period of time. Does that mean the only option left for these applications is the web application firewalls? If that's the case, can we assume that once put in place, web application firewalls are going to act as silver bullets for all these applications. I hope not! There are several open source and commercial web application firewalls available in the market and each one comes with its own benefits and shortcomings. I don't think that any one of these firewalls would be able to protect all these applications against all sorts of current and future attacks. WASC has developed a set of WAF evaluation criteria to assess the quality of various WAF solutions available in the market.
So what would be the best approach? I would say that web application firewalls may be used as first line of defense for all those applications which are already in production to meet PCI requrements. This way these applications will have enough time to get the source code reviewed and the developers would have enough time on their hands to resolve the issues discovered during the source code review. On the other hand, applications which are still in development or near completion may go through source code review to identify and eliminate as many vulnerabilities as possible at this early stage, and then a web application firewall may be put in place to protect these applications further in production environments.
Don’t you think its defense in depth for web application security? I think it is….
Tuesday, 29 January 2008
PCI Compliance: Web Application Firewall (WAF) vs. Source Code Review
Thursday, 10 January 2008
Cross Site Printing: Now Printer Spamming
Aaron Weaver has found a way to spam printers on a local network. The vulnerability is called Cross Site Printing. Now just be careful while visiting web sites, because whenever you visit a malicious web site, it may try to connect to a printer on your local network without your knowledge and start sending data, meaning you've been spammed on your printer in a similar way you get spam on your fax. An excerpt from Aaron' paper:
By using only JavaScript, an Internet web site can remotely print to an internal network based printer by doing an HTTP Post. The web site initiating the print request can print full text, enter PostScript commands allowing the page to be formatted, and in some cases send faxes. For the attack to succeed the user needs to visit a web site that contains this JavaScript.We have yet to see how much damage can be done with this vulnerability. So, get ready for even more spam in 2008!
Many network printers listen on port 9100 for a print job (RAW Printing or Direct IP printing). You can telnet directly to the printer port and enter text. Once you disconnect from the printer it will print out the text that you send it. Network printers also accept PostScript, and Printer Control language. The security around this is usually minimal – connect to the port, send the print job, disconnect and the printer prints the page.
Tuesday, 8 January 2008
User Enumeration - Part 2
In my previous post, I had discussed how an attacker may enumerate valid usernames on a vulnerable web site. The details of my previous post can be found here. In this post, I will describe what measures can developers take to prevent these types of attacks.
Safeguarding New User Registration Process
This is the most effective way of enumerating usernames without alerting system administrators or end users, but can also be the most difficult to prevent. It is not really possible to make user registration 100% secure against these attacks but the impact can be reduced considerably by taking appropriate measures.
One approach may be to log the IP address from where the request is coming. If a web site is receiving a lot of user registration requests from the same IP address in a very short period of time, it may indicate that an automated attack is taking place. This type of attack can be prevented by limiting the number of requests from that IP address. The main problem with this approach would be that the users may be behind a proxy server and thus the IP address of the proxy would be logged instead of the actual machine from where the request is coming. So the best approach would be to put a time limitation for the number of requests coming from a particular IP address.
The second approach may be to introduce the use of CAPTCHA to prevent automated tools to send registration requests to the server.
Safeguarding User Authentication Process
The main approach to safeguard user authentication would be to generate a generic error message like this: "Username or Password is wrong". This would not reveal if the username is wrong or the password is wrong. Sometimes developers try to make the authentication process more secure by using a two step authentication. The web site may still be vulnerable if this functionality is not implemented properly e.g. an error message is generated just after the first step if the user details on the first page are wrong, or the user is directed to the second page if the details on the first page are correct. The proper way of implementing two step authentication would be to generate a generic error message only at the end of the authentication process and not revealing the actual cause of failure.
Safeguarding Password Reminder Functionality
One thing to consider to prevent password reminder functionality from user enumeration is to return a generic message such as this "An e-mail has been sent to the registered e-mail address" every time a password reminder request is made. There is no way for an attacker to find out if the request failed or succeeded. But at the same time, an e-mail is sent to the registered e-mail address if that address existed, or nothing will happen otherwise.
One more thing to consider here is that separate user details may be used for authentication and password reminder functionality e.g. a username instead of an e-mail address may be used for user authentication, while an e-mail address may be used for password reminder functionality. The benefit of doing this would be that even if an attacker is able to enumerate an e-mail address, he would still have no clue about the username, making the knowledge of e-mail address useless to him.
Safeguarding User Enumeration through Directory Enumeration
Some web applications would allocate a separate directory to the registered users where the name of the directory is same as the username. This type of web site functionality is very rare in high profile web sites, but still can be seen at some places. Because of the nature of error messages coming back from the web site for existing (HTTP Error code: 403 Forbidden) and non-existing (HTTP Error code: 404 Not Found) directories, this type of functionality is best avoided.
By implementing the above steps, developers can reduce the risk of user enumeration considerably on their web sites.
I have tried to list the user enumeration prevention techniques above to the best of my knowledge. If anyone reading this post knows better ways of preventing these attacks, please leave a comment and I will try to add them here.
Safeguarding New User Registration Process
This is the most effective way of enumerating usernames without alerting system administrators or end users, but can also be the most difficult to prevent. It is not really possible to make user registration 100% secure against these attacks but the impact can be reduced considerably by taking appropriate measures.
One approach may be to log the IP address from where the request is coming. If a web site is receiving a lot of user registration requests from the same IP address in a very short period of time, it may indicate that an automated attack is taking place. This type of attack can be prevented by limiting the number of requests from that IP address. The main problem with this approach would be that the users may be behind a proxy server and thus the IP address of the proxy would be logged instead of the actual machine from where the request is coming. So the best approach would be to put a time limitation for the number of requests coming from a particular IP address.
The second approach may be to introduce the use of CAPTCHA to prevent automated tools to send registration requests to the server.
Safeguarding User Authentication Process
The main approach to safeguard user authentication would be to generate a generic error message like this: "Username or Password is wrong". This would not reveal if the username is wrong or the password is wrong. Sometimes developers try to make the authentication process more secure by using a two step authentication. The web site may still be vulnerable if this functionality is not implemented properly e.g. an error message is generated just after the first step if the user details on the first page are wrong, or the user is directed to the second page if the details on the first page are correct. The proper way of implementing two step authentication would be to generate a generic error message only at the end of the authentication process and not revealing the actual cause of failure.
Safeguarding Password Reminder Functionality
One thing to consider to prevent password reminder functionality from user enumeration is to return a generic message such as this "An e-mail has been sent to the registered e-mail address" every time a password reminder request is made. There is no way for an attacker to find out if the request failed or succeeded. But at the same time, an e-mail is sent to the registered e-mail address if that address existed, or nothing will happen otherwise.
One more thing to consider here is that separate user details may be used for authentication and password reminder functionality e.g. a username instead of an e-mail address may be used for user authentication, while an e-mail address may be used for password reminder functionality. The benefit of doing this would be that even if an attacker is able to enumerate an e-mail address, he would still have no clue about the username, making the knowledge of e-mail address useless to him.
Safeguarding User Enumeration through Directory Enumeration
Some web applications would allocate a separate directory to the registered users where the name of the directory is same as the username. This type of web site functionality is very rare in high profile web sites, but still can be seen at some places. Because of the nature of error messages coming back from the web site for existing (HTTP Error code: 403 Forbidden) and non-existing (HTTP Error code: 404 Not Found) directories, this type of functionality is best avoided.
By implementing the above steps, developers can reduce the risk of user enumeration considerably on their web sites.
I have tried to list the user enumeration prevention techniques above to the best of my knowledge. If anyone reading this post knows better ways of preventing these attacks, please leave a comment and I will try to add them here.
Friday, 4 January 2008
User Enumeration - Part 1
So you wish to enumerate user accounts within web applications. OK, move forward, follow the steps below and who knows if you can strike the gold ;-)
Finding existing user accounts on a vulnerable web application is a trivial task. You just need some helpful error messages that reveal useful information about users. There are a number of way to enumerate valid user accounts on a vulnerable web site.
Exploiting User Registration Functionality
If you wish to register on a web site as a new user, you need to enter your details on the user registration page including a unique username. This username is used by the web site to identify you for future interactions. If you select a username that already exists, the web application will generate an error message like this: "This username already exists, please choose another".
The main benefit of using this technique for user enumeration is that this is non-intrusive i.e. this would not alert a system administrator or the end user of the web site because you may be the genuine user who wish to register to the web site. Since the web site requires you to have a unique username, it needs to inform you if you choose a username that already exists. As no data is sent to the end users or you are not altering the state of the user account, the users also wouldn't know that this attack has taken place.
Exploiting User Authentication
If you wish to use a web site's privileged functionality, you need to authenticate yourself to the web site. This is normally done by entering a username and a password on the authentication page. Sometimes developers may be over helpful in an effort to provide useful error messages to end users. But these error messages may be more useful to an attacker than to a normal user. The following error messages may help an attacker to enumerate valid user accounts on a target web site:
If a user enters a username that does not exist on the web site, an error message like this may be returned "This username does not exist, please try again by entering a correct username". But if the username exists and the password is wrong, an error message like this may be returned "Incorrect password". This error message indicates that the username exists but the password entered does not match with the one stored in the database for this user.
Exploiting Password Reminder Functionality
Another method of enumerating valid user accounts is the password reminder functionality. If a user forgets the password, the web site provides a functionality to enter the username or the email id where the password would be sent. Even worse, sometimes the web application will generate a new password and send it to the user's email id.
Now if you enter a username that does not exist, an error message "This username does not exist" would be generated, otherwise a message something like this "The password has been sent to the registered email id" would be generated, revealing that the username exists on the target web site. This is not considered a very good method for user enumeration as this will alert the end users that some malicious activity has happened to their account.
Enumerating User Accounts through Directory Enumeration
Some web applications would allocate a separate directory to the registered users where the name of the directory is same as the username. When a user accesses the web site, this directory is simply appended to the URI. This may look something like this:
www.example.com/username
You can append different usernames at the end of the URI in an effort to find valid user names. This is possible because different error messages can be returned for existing and non-existing directories. Also an error message may be returned for a non-existing directory while some valid information may be returned for the existing directory if no authentication is required to access the contents of that directory.
Once a valid user account is found, the next step would be to brute force the account in an effort to gain unauthorized access to the target web site. Mission Accomplished!
I have divided this post in two parts. This part describes how an attacker can enumerate users on a vulnerable web site. Part 2 will explain what measures web application developers can take to avoid user enumeration on their web sites.
Finding existing user accounts on a vulnerable web application is a trivial task. You just need some helpful error messages that reveal useful information about users. There are a number of way to enumerate valid user accounts on a vulnerable web site.
Exploiting User Registration Functionality
If you wish to register on a web site as a new user, you need to enter your details on the user registration page including a unique username. This username is used by the web site to identify you for future interactions. If you select a username that already exists, the web application will generate an error message like this: "This username already exists, please choose another".
The main benefit of using this technique for user enumeration is that this is non-intrusive i.e. this would not alert a system administrator or the end user of the web site because you may be the genuine user who wish to register to the web site. Since the web site requires you to have a unique username, it needs to inform you if you choose a username that already exists. As no data is sent to the end users or you are not altering the state of the user account, the users also wouldn't know that this attack has taken place.
Exploiting User Authentication
If you wish to use a web site's privileged functionality, you need to authenticate yourself to the web site. This is normally done by entering a username and a password on the authentication page. Sometimes developers may be over helpful in an effort to provide useful error messages to end users. But these error messages may be more useful to an attacker than to a normal user. The following error messages may help an attacker to enumerate valid user accounts on a target web site:
If a user enters a username that does not exist on the web site, an error message like this may be returned "This username does not exist, please try again by entering a correct username". But if the username exists and the password is wrong, an error message like this may be returned "Incorrect password". This error message indicates that the username exists but the password entered does not match with the one stored in the database for this user.
Exploiting Password Reminder Functionality
Another method of enumerating valid user accounts is the password reminder functionality. If a user forgets the password, the web site provides a functionality to enter the username or the email id where the password would be sent. Even worse, sometimes the web application will generate a new password and send it to the user's email id.
Now if you enter a username that does not exist, an error message "This username does not exist" would be generated, otherwise a message something like this "The password has been sent to the registered email id" would be generated, revealing that the username exists on the target web site. This is not considered a very good method for user enumeration as this will alert the end users that some malicious activity has happened to their account.
Enumerating User Accounts through Directory Enumeration
Some web applications would allocate a separate directory to the registered users where the name of the directory is same as the username. When a user accesses the web site, this directory is simply appended to the URI. This may look something like this:
www.example.com/username
You can append different usernames at the end of the URI in an effort to find valid user names. This is possible because different error messages can be returned for existing and non-existing directories. Also an error message may be returned for a non-existing directory while some valid information may be returned for the existing directory if no authentication is required to access the contents of that directory.
Once a valid user account is found, the next step would be to brute force the account in an effort to gain unauthorized access to the target web site. Mission Accomplished!
I have divided this post in two parts. This part describes how an attacker can enumerate users on a vulnerable web site. Part 2 will explain what measures web application developers can take to avoid user enumeration on their web sites.
Subscribe to:
Posts (Atom)
Posts
