Additional Security Issues: Hacme Casino

Hacme Casino from Foundstone is a well known vulnerable web application from the Hacme series used as a learning platform for secure software development. It is accompanied with a solution guide that demonstrates security issues in the application.

During my own usage – for self-learning, developer group trainings and security group demonstrations I have discovered a few more vulnerabilities that I am sharing here for the benefit of those who wish to get more out of Hacme Casino.

1. Vulnerability Exploited: Insecure Direct Object Reference

For vulnerability description refer here.

As seen in the screenshot below, it is possible to download potentially any file from the web server's file system without authentication by guessing and directly referencing it's path. Here we have downloaded boot.ini which is arguably not sensitive. Nevertheless sensitive files can be potentially downloaded as well.



2. Vulnerability Exploited: Session Fixation

For information on Session Fixation refer here. Following steps confirm the vulnerability.

Step 1: Login with a fixed session ID as seen in the Paros proxy screenshot.

Step 2: Check the trapped response from Paros. As we see the session ID is same as what we fixed.


Step 3: This step is not really required but just for a double check. Let's access the OPTIONS link. The trapped session ID in Paros is definitely the one that we fixed as seen. The next screenshot confirms indeed it was possible to access OPTIONS with this session ID.



3. Vulnerability Exploited: Cross Site Request Forgery

For vulnerability description refer here. Below are additional functions that are vulnerable to CSRF. The exploitation method is same as described in Hacme Casino guide.

http://localhost:3000/account/cash_out
http://localhost:3000/account/update_options
http://localhost:3000/blackjack/bet
http://localhost:3000/video_poker/bet

CSRF Protection

As of this posting CSRF (Cross Site Request Forgery) stands as fifth top most threat for web applications. For information on what CSRF is, read on http://www.owasp.org/index.php/Top_10_2007-A5

1. A good protection against this attack is to re-authenticate (like transaction password) or better use two-factor authentication for critical transactions like fund transfer. Taking the CSRF vulnerability from Hacme Casino a good solution would be ask for transaction password as shown in the screenshot below -


2. Another solution is to implement one time nonces. For more information refer the link mentioned above.

3. ASP.Net
Myth: Having ViewState enabled in a .Net web app would prevent against CSRF attacks.

Fact: Having ViewStateUserKey set and set to something that is distinct to each user like "ViewStateUserKey = Session.SessionID" will save you against CSRF attacks.

Gmail Session Hijacking in 7steps

Session tokens are crown jewels of user identity on a web application. It's no hidden fact that attacks such as XSS (Cross Site Scripting) are on all time rise that steal these tokens leading to user identity theft.

Although adequate community emphasis has been laid on XSS & its countermeasures, there are other prevalent techniques and wide-spread issues that can steal session tokens perhaps more easily.

The one that I share here is network eavesdropping/sniffing.

A vast majority of the web applications that I have come across use HTTP, post authentication. Example: Gmail, Yahoo, Orkut or for that matter any popular public portal. The list includes several intranet/online financial and payroll apps we see day in and day out.

Below we see a step-by-step attack where we steal session ID of a Gmail user and hijack it in the process. (The credit for this exercise is shared with my colleague, Raj, rajaol@gmail.com):

1. The screenshot below simulates a victim (c00kytest@gmail.com) who is currently accessing his/her Gmail account over a corporate LAN, Cyber Cafe' or Wi-fi hotspot. As we see in the URL bar, the communication is happening over HTTP, i.e. plain text.



2. The second screenshot simulates an attacker sitting somewhere in the same LAN. Though the LAN is a switched environment, the attacker has used a tool called Cain & Abel to become man-in-the-middle (MITM) (there are many tools that can be used to set this up. Ettercap is a good example. We use Cain & Abel for our long time friendship with the tool. We have used it to sniff passwords travelling on SMTP and POP on numerous occasions).



The blue circle in the screenshot (IP: 192.168.0.1) highlights the Internet gateway address that we ARP spoof for victim (IP: 192.168.0.110), highlighted in red circle. The second red circle below confirms the success of first step of attack where all victim traffic is getting routed from attacker's machine. By now we should be able to see all traffic going from victim machine.

Let's fire up wireshark to read the victim data (again, you can use any sniffing tools for this) The above screenshot shows wireshark getting started.

3. As shown in the next screenshot we steal victim's gmail cookie details. This is highlighted in the red circle (IP: 192.168.0.110)



4. We copy the cookie details and paste it on a notepad as shown below



Gmail uses GX token from cookie to track users. It's highlighted in the screenshot above. We just need this value to hijack victim's account.

5. As shown in the screenshot below, we go back to attacker's login (rajaol@gmail.com) and use a firefox add-on called Cookie Editor to insert the stolen cookie.



6. We now paste the stolen GX value in the cookie editor as shown below. (We did some trial and error and removed many other cookies. We also changed token value for gmailchat=c00kytest@gmail.com)



7. Alright. We are done. Now change the URL in the attacker's browser to the one highlighted in the screenshot below (some other gmail links were logging us out directly. This one didn't. There might be others too that could give you the access similarly. It's all trial and error). Gmail shows you logged on as victim !!!
(highlighted in second red circle)



Now that we have seen how simple this attack can be (Wi-fi would be even easier. No ARP spoofing required. It's all broadcast. On top of that many still use WEP. WEP is trivial to crack) and the associated threats, let's look at the countermeasures.

Countermeasures:

1. Use HTTPS
CAVEAT: On a switched LAN, MITM is still possible but your browser will warn you. It will show a certificate error. Users need to take this error seriously and alert the support/security staff. Gmail provides optional email access over https://gmail.com but it is insufficient as it makes other requests over HTTP. Nevertheless you will get a browser warning as soon as the MITM happens (certificate error). You can act upon it accordingly. Yahoo & majority of the other public portals do not provide options HTTPS access.

2. If HTTPS is not possible for performance reasons, use multiple cookies & continuous (page-wise or request-wise) tracking mechanism that detects a sudden new connection & logs out the user automatically.
CAVEAT: This might still be breakable by an attacker if the MITM started before victim's first access to the site.

Building Highly Secure Applications

Building highly secure applications need much more than an after thought Penetration Test and a rare Secure Code Review. Over the past two years the need to integrate security into the SDLC has become larger than ever. There is a growing acceptance & place for security within the application development teams these days. Challenge however has been what, where & how. A key need is to not overdo since it might repel potential adopters.

Recently there have been several resources flooding the Internet on how to meet this challenge. I found several that were over-blown & several that were inadequate. Having said that there were fairly good ones. The one that I liked the most & thought met my perception was the Secure Development Lifecycle from Microsoft.

As seen above it highlights what security practices need to be incorporated and where in an SDLC. As you dig deeper it addresses the how part as well http://msdn.microsoft.com/en-us/security/cc420639.aspx. I personally like OWASP guides for the how part specifically following
- Secure Coding Guide http://www.owasp.org/index.php/Category:OWASP_Guide_Project
- Static Analysis/Code Review http://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents
- Dynamic Analysis/Penetration Test http://www.owasp.org/index.php/Category:OWASP_Testing_Project

J2EE / ASP.Net XSS Protection

J2EE

We again leverage Hacme Books for an example vulnerable code.

Here the victim requests feedbackitem that may potentially comprise malicious code.

We fix this using output encoding method. Here we use Struts bean:write tag that supports output filtering of dangerous characters in the HTTP Response by default.

As you might have noticed, we did not do any input validation and instead accepted the malicious code in first place. Depending on the use cases or the functional requirements, it might or it might not be required. If needed, Struts Validator class could be used. As a best practice it is always recommended to do input validation as well.

ASP.Net

Below is a vulnerable code Hacme Bank.

string messageSubject = txtSubject.Text;
string messageText = txtText.Text;

Here txtSubject.Text and txtText.Text could be injected with malicious code.

However if we use Microsoft Anti-Cross Site Scripting Library the malicious code would be encoded when displayed to a victim and hence rendered harmless.

string messageSubject = AntiXss.HtmlEncode(txtSubject.Text);
string messageText = AntiXss.HtmlEncode(txtText.Text);

Again we allowed the application to accept malicious input in first place. If threat profiling of use cases necessitate, ASP.Net in-built validation routine called RegularExpressionValidator could be leveraged to filter the unwanted input.

The example below enforces txtSubject.Text and txtText.Text to accept alphabets and numbers only.

J2EE / ASP.NET SQL Injection Protection

J2EE

Let's take a vulnerable code example from Hacme Books.

String query = "select * from products where " + “lower(title) like '%" + keyword.toLowerCase() + "%‘”;

As seen keyword is passed to the interpreter without validation or encoding.

For SQL Injection protection, the secure version with Prepared Statement as shown below can be used.

PreparedStatement query = con.prepareStatement( “select * from products where lower(title) like ?");
query.setString(1, keyword);
updateSales.executeUpdate():

ASP.Net

A vulnerable code example from Hacme Bank looks like this.

string sqlQuery = "select user_id from fsb_users where login_id = '" + loginID+ "' and password = '" + password + "'";

Here the loginID and password are passed to the MS SQL server without validation or encoding .

Using a secure replacement with SQLParameters as below this attack can be mitigated.

string sqlQuery = "select user_id from fsb_users where login_id = @loginID and password = @password";
//Assuming you have defined a command called 'cmd'
cmd.Parameters.Add(New SQLParameter("@loginID", loginID))
cmd.Parameters.Add(New SQLParameter("@password", password))