Yahoo Website Compromise

In one of my recent posts, I had talked about the importance of using two keywords to secure authentication cookies. These keywords are 'Secure' and 'HttpOnly'. The scenarios I had presented in the post describe how the authentication cookie can be stolen by a malicious hacker if it is not appropriately protected by using one or both of these keywords.

Although it is very easy to prevent attacks on cookies by using these keywords, but most of the web sites I test while conducting penetration tests are still vulnerable to attacks. Recently one of the Yahoo websites was compromised by attackers that did not make use of these keywords to protect authentication cookie.The details of the hack can be found here. The article states that it's not just Yahoo but there are many other big names that are also vulnerable to these attacks.

It is quite evident by now that using only an encrypted connection to transmit authentication cookie is not enough. It is also very important to consider the use of 'Secure' and 'HttpOnly' keywords to protect the authentication cookie. 'Secure' would prevent the authentication cookie from being transmitted in clear text while 'HttpOnly' would prevent the authentication cookie from being accessed by client side scripts.

MS WIndows Critical Wormable Vulnerability - MS08-067

A new critical risk vulnerability has been discovered in Microsoft Windows Server Service that could allow remote code execution. This has forced Microsoft to release an out of band patch (MS08-067) to fix this vulnerabilty. The vulnerabilty has been rated as Critical for Windows 2000, Windows XP and Windows Server 2003 as an attacker can run arbitrary code without authentication, while Windows Vista and and Windows Server 2008 require authentication by default and thus the vulnerability has been rated as Important for these platforms.

This remote code execution vulnerability has been found in netapi32.dll that affects even the fully patched Windows systems. This vulnerability may be exploited to create a worm by crafting a special RPC request. A successful exploitation of the vulnerability would result in complete control of the victim system.

Although an immediate patching of Windows system is recommended by Microsoft, proper firewall configuration that blocks TCP ports 139 and 445 can also provide a temporary work around to protect network resources from attacks that originate outside the enterprise perimeter. This work around may not work on a system where the firewall is enabled, but the file/printer sharing is also enabled.

The more detailed information about the vulnerability and the available patch can be found at Microsoft Security Belletin and Microsoft SVRD.

Lynis - Security & System Auditing Tool for UNIX

I just came across this little host based UNIX/Linux auditing tool that assists in performing automated Unix system audits. The description of the tool follows:

Lynis is an auditing tool for Unix. It scans the system and available software, to detect security issues. Beside security related information it will also scan for general system information, installed packages and configuration mistakes. This software aims in assisting automated auditing, software patch management, vulnerability and malware scanning of Unix based systems. It can be run without prior installation, so inclusion on read only storage is no problem (USB stick, cd/dvd).

What is Lynis NOT:
- Not a hardening tool: Lynis does not fix things automatically, it reports only (and makes suggestions).

Examples of audit tests:
- Available authentication methods
- Expired SSL certificates
- Outdated software
- User accounts without password
- Incorrect file permissions
- Firewall auditing

The tool can be downloaded from lynis-1.1.7.tar.gz.

Securing Cookies in Web Applications

It is very common practice for web applications to transmit sensitive user information such as session token through cookies. Each time the user's web browser returns a session cookie, there is some concern that intercepting a user's session cookie can compromise a user’s session information. If a web application contains such information, it's important to prevent access to the cookie information. You can prevent interception of session cookies by encrypting the communication link between your web server and the user's browser. But is it all it takes to secure a session cookie? I believe it may partially prevent accessing the cookie information through interception, but it may not prevent gaining access to cookie information through other means. Here I'll explain the attack scenario's that may still be used to gain unauthorised access to cookie information even if an SSL connection is used.

Scenario 1:

A user is browsing to an authenticated portion of a Banking web site (https://www.MyBank.com). The web site uses secure HTTPS connection to protect sensitive user information including the session cookie. The user is accessing his web mail account in another browser tab at the same time. He has just received a phishing email from an attacker that appears to have come from his Banking web site. The email requires the user to verify his account security by clicking on a link within the email (http://www.MyBank.com). Note that the link in the email uses a clear text HTTP connection instead of a secure HTTPS connection. Once the user clicks on the link, it transmits the session cookie along with everything else in the clear text. The session cookie for the MyBank web site is automatically sent in this case because the user is already authenticated to the web site at the time of clicking on the link in the email. This enables an attacker to capture session token by sniffing the network traffic and enabling him to compromise a victim's account by replaying this session token to the target web site while the session is still active.

The web application owners may think that they are using an SSL connection to protect sniffing of session cookie and thus it may not be possible for an attacker to capture the session token within the cookie. The above scenario shows that an attacker can capture session token by launching an attack even if the web server does not support HTTP connection at all. In this case, web server sends an error back to the end user, but the session token has already been compromised while the request was send by the browser to the web server.

Mitigation: This type of cookie hijacking attack could be prevented by using a 'Secure' flag while setting a new cookie. Any cookie that contains session token or any other sensitive user information should be marked as Secure. If a cookie is marked Secure, it will only be transmitted if the communications channel with the host is a secure one and thus would not reveal any sensitive information to an attacker via network interception.

Scenario 2:

The web application owners have taken all the steps to prevent cookie interception by making sure that the cookie can only be transmitted over a secure HTTPS connection and a Secure flag is also used to ensure this behaviour. But the application does not perform data validation properly and is thus vulnerable to Cross-site Scripting (XSS) attacks. It is possible for an attacker to hijack a session cookie of an authenticated user by exploiting an XSS bug within the vulnerable web application. In this case again, an attacker sends a phishing email that appears to have come from a victim's Banking web site. The email requires the user to verify the security of his account by clicking on a spoofed link within the email that exploits the XSS vulnerability within the Banking web site. As soon as a user clicks on the link, malicious client side script within the link hijacks the user session token and sends it to an attacker.

Mitigation: Microsoft had developed a 'HTTPOnly' cookie flag to prevent cookie hijacking via malicious client-side scripts. This flag was initially developed for IE6.0 but is now supported by FireFox as well. Using this flag ensures that sensitive cookies will not be accessed by any client-side side scripts, thus preventing session theft through cookie hijacking via client-side scripts. Please note that using HTTPOnly flag to prevent cookie hijacking should not be considered as an alternative to data validation to prevent XSS attack, rather it should be used in conjunction with any other measure taken to make the application secure.

By taking these two simple measures, you may be able to prevent most of the cookie hijacking attacks on your web applications.

Switching Between Web Proxies using FoxyProxy

I normally use one of the three most common intercepting web proxies while conducting web application penetration tests (viz. Paros, WebScarab or Burp). All these proxies come with their own benefits and shortcomings and thus any one of these may not be suitable for all situations. Therefore, at times, you may have to use more than one proxy to complete your task. But switching between proxies can be a real pain and time consuming and thus may divert your attention from the actual work you are doing.

I had found a little firefox extension some time ago called FoxyProxy. This is an open-source advanced proxy management tool. I find this tool very handy during pentests as it makes the task of switching between web proxies totally effortless. It comes with some cool features and allows you to configure various proxies at the same time within Firefox. Once this is done, you just have to fire your favourite proxy and select the proxy name from the FoxyProxy menu. If you want to switch to a different proxy, just change the name of the proxy within the FoxyProxy menu and you're done. It's that simple!

There is one more reason why I like this extension. You can set patterns for which you want the browser requests to be routed through this proxy, while all other requests would bypass the proxy completely. This is again very handy when you are conducting penetration tests as this helps you to maintain a clean audit trail of all the requests sent to the target server.

I hope you enjoy using this little tool as much as I do. More information for this FireFox extension can be found here.

Web Application Security and OWASP Top 10

Most of the people will start talking about OWASP Top 10 when it comes to web application security. Why does it matter so much to all those people who are trying to secure their applications against attacks or to all those penetration testers who are testing for vulnerabilities within these applications?

It just makes me think if it's sufficient to secure or to test web applications only for vulnerabilities that appear in this list? Also what about all those vulnerabilities that do not just appear in this list? The latest Top 10 list was produced in 2007, which is also called OWASP Top 10 2007. Now this list does not contain Buffer Overflow and Denial of Service attacks which were there in ealier versions of OWASP Top 10 list. Does that mean that these attacks have just disappeared and all our applications are now immune to these attacks or does that mean that other attacks have become more wide spread and have taken precedence over the attacks that do not appear in this list any more? If that's the case, does that make all those attacks that do not appear in the Top 10 list any less attractive or less severe than the ones that appear in this list. If that's not true, then wouldn't it make more sense to secure our applications against all those attacks that appear in the OWASP Top 10 list as well as against all those that do not?

So why do we care so much about OWASP Top 10?

OWASP Top 10 is an awareness document for web application security that has been created by industry thought leaders with mutual consensus and lists the Top 10 most serious web application vulnerabilities. Adopting this document can act as an effective first step towards security awareness program and changing the software development culture within the organization for creating secure software applications. Therefore, adopting this document should be treated as the beginning of your security awareness program and everyone should strive to mitigate against the vulnerabilities mentioned in this document as a minimum requirement towards producing secure software and should not treat it as an end to achieve. Only by doing this, we can be one step closer towards producing secure software applications.

Hacking CCTV Camera

This is not something new, but I just came across this and found it quite interesting and fun, so just thought of mentioning it here.

You can find a CCTV camera anywhere you go these days. Most of the companies install a CCTV camera to monitor their physical security and think that only the assigned personnel within the company can monitor it. If that's the case, you may want to think again, as it's not just the personnel within the company, but anyone on the Internet can see and monitor the activities of the camera.

If you don't believe that now, you will very shortly ;-) as once again Google is our best friend to make our job easier in doing so. If you know the search criteria to find an Internet connected CCTV camera, Google will list all these cameras in the search result. So just thinking that no one will be able to find your CCTV camera as you have not published this information anywhere is bit naive.

I have listed some of the search strings below to find these cameras. Different search criteria applies to different brands of the cameras and lists the online cameras of that brand.

inurl:"/view/view.shtml"
inurl:"ViewerFrame?Mode="
inurl:"view/index.shtml"
inurl:"MultiCameraFrame?Mode="
inurl:"/home/homeJ.html"

If you click on one of the search results, it will show you the live view for that camera and all the menu options where you can change the view, zoom in and out, hear sound or do whatever you want within those menu options. Now isn't it bit worrying if anyone on the Internet can do that. What about criminals trying to breach your physical security. They just fix the camera at one location while carrying their attack at another. How fascinating is that?

If that's not enough, the top right corner of the image provide a link for the setup. Clicking on the setup will prompt for user credentials where you can gain admin access to the camera. But who knows if you can brute force the credentials successfully or someone has just not changed the default credentials. If you can gain access to the camera setup this way, its game over!!! You can control the camera fully now and do whatever you want to do with it.


*** Disclaimer ***
I have published this information for educational purpose only and have not tried to gain an unauthorised access to any of the systems on the Internet while conducting my research. You are free to use this information in any way you want and I can't be held responsible for the consequences because of any of your actions. Good luck and have fun ;-P

Input Validation... Getting It Right the First Time?

Most of the attacks on web applications happen because of poor input validation. So can we say if input validation is done properly, these applications would be able to avoid these attacks? Maybe, but this is easier said than done.

With the complex nature of web applications having multi-tier architecures these days, it is really difficult to decide where and how the input validation should be done. While conducting penetration tests, I normally come across web applications where developers rely too much on client side validation controls and only a handful of them get it right in the first place.

Any user input that is processed by the application should be treated as malicious. This includes all the HTTP headers and hidden form fields that are processed by the application and not just the data entered by the user in the form fields. User input that is passed to the server should always be checked for type, length, format and range.

The application should only rely on server side validation controls and not on client side validation controls as it is very trivial to bypass client side controls by using a web proxy. Even on the server side, it may be a bit tricky to have proper validation controls in place. So a defence in depth mechanism should be applied and the data should be validated every time it crosses a trust boundary. This approach should be followed to prevent servers at different stages assuming a malicious data string as a legitimate data string. For example, it may be perfectly legitimate for a web server to treat a single quote (') as a valid character for a name field (as someone may have a name O'Neil), but the validation controls on the application server may be put in place to make sure that the single quote is treated as is, and not as part of an SQL query to the database server. Again we may employ some parameterised queries on the database so that all the input passed to the database is considered as a parameter and not the command to the database.

Also, there are two approaches for handling input validation on the server side. One is to create a white list of acceptable characters and restrict everything else, and the other is to create a black list of known malicious characters and restrict these characters from the input while accepting everything else. The best practise is to create a white list of all the acceptable characters for each input field and reject everything else. This approach would enable the web application to prevent any unknown and future attacks as well, while on the other hand, creating a black list may only prevent against currently recognised malicious chracters. Sometimes, it may also not be so evident to identify all the malicious characters in advance and thus may be easy to miss mitigation against some of the attack vectors by following the black listing approach.

So, if done correctly, input validation would prevent most of the injection attacks on your web application.

PCI Compliance: Web Application Firewall (WAF) vs. Source Code Review

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….

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.

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.

We have yet to see how much damage can be done with this vulnerability. So, get ready for even more spam in 2008!