CitiGroup Breach - 3 SDLC Activities that Failed

CitiGroup recently admitted a security breach where hackers got details from lots of credit card customers. The attack itself seems to have been fairly simple. The attacker logged on normally to an account. They then ran a script which iterated through the account number in the browser address bar. According to the New York Times,  they "automatically repeated this exercise tens of thousands of times — allowing them to capture the confidential private data."   In OWASP Top 10 speak this was a insecure direct object reference vulnerability.

It looks like a fairly simple vulnerability, although the details are unclear. But it should not have happened.  Here are three Secure Development Life Cycle  (SDLC) activities which, if implemented properly, would have probably prevented this attack*:

1. Authorisation checks were not implemented properly to check that the logged on customer had permission to view the details for the requested account number. This is a failure in the analysis/design phase. Whenever a user initiates a request your application should check that the user has permission to execute this particular transaction. There are two basic levels. At a coarse level, check that the user has permission to access this page. At a finer level, the user may have access to a particular page. However, does the requested account (or resource) belong to this user?
   
   It may be that authorisation checks were designed correctly by CitiGroup, but not implemented by the development team. In this case the assurance/testing phase should have come to the rescue.
2. During the assurance phase, this vulnerability should have been picked up. A penetration test which probed for various account numbers would most likely have caught this. Similarly a code review  would have indicated that something was wrong. This is what the OWASP Application Security Verification Standard (ASVS) is aimed at.
   
3. Finally, Application Monitoring during operation did not recognise the suspicious behaviour that numerious requests were coming from a single account. If proper monitoring had been in place, Citi may been alerted much sooner (maybe in real-time) to the problem. The OWASP AppSensor project could help here.

So learn the lessons. Make sure that you have an SDLC in place for your development process.
Have a look at the SLDC Main Posts which shows the main SDLC related posts on this blog and what are the most important steps in a SDLC.

Links:

• SDLC Quick Reference 
• OWASP AppSensor Project
• OWASP ASVS
• OWASP Code Review
• OWASP Testing
• New York Times  
• The Register

 * Of course this is all speculation, since we don't know what really happened.

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Developing Securely for SmartPhones - A few Key Principles

At AppSecEU last week, I attended Dan Cornell's (Denim Group)  presentation  on Security Testing Mobile Applications. You can view the slide deck on the Denim Group blog.

Basically, Dan demonstrated how you can "root" the smartphone and then reverse engineer the application to do whatever you want. Slide 6 shows a "Generic Mobile Application Threat Model" for a SmartPhone app connecting to an enterprise application.  It shows the following threats:

1. Malicious User
2. Malicious User (bypassing Mobile Client)
3. Malicious Mobile Application
4. 3rd Party Services (Possibly Malicious)

Nr. 2 is where a malicious user bypasses the smartphone completely and attacks the enterprise web services which the smartphone uses.

Nr. 3 is a malicious application which is installed on the smartphone and can interfere with other installed applications.

Nr. 4 is where the smartphone connects to 3rd party services which have been compromised.

Key Principles

So what  are the lessons when developing enterprise type apps for smart phones? Here are a few thoughts. These are based in part on a short conversation I had with Dan after his talk*.

1. Treat the smartphone as an "untrusted device".
2. If possible, don't store confidential information on the phone. 
3. Develop your web services securely, as an attacker may discover the web services and attack them directly - bypassing the smartphone completely.
4. Your web services should validate any input data and perform the necessary authorisation, access control, business logic checks etc.. Any validation performed on the phone should be repeated by the web service
5. Use SSL to prevent man-in-the-middle type attacks.

* These may not be an accurate reflection of Dan's views!

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

My OWASP AppSec Europe 2011 Presentation

I gave my presentation today at OWASP App Sec Europe 2011 today.

Here is a link to the slide deck. 

Note! It's in PDF format.

The talk is aimed at the developerment team. At the start of a development project you should think a bit about security. In the presentation I go down through a simple structured list of security  tasks that you should address in order to gather the security requirements that the project should implement.

                   
                                          

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Your OWASP AppSec EU Homework

This is your homework if you are coming to my presentation at the OWASP App Sec EU talk  on Friday June 10th, in Dublin. I'm going to use this completely ficticous application - the Brochure Co (BCo) website. This post is to give a quick overview of the application and a number of use cases which it will implement.

The main goal of the talk is to specify the security requirements that the application development team should incorporate during the implementation of the BCo website. 

The presentation will describe a set of topics that should be covered during a security workshop which is held at the start of the project.

Description
Brochure Co (BCo) is a company that manages and distributes a range of printed brochures on behalf of its clients. These brochures are sent out via normal mail on a regular basis. The new online application will allow BCo  users to register online and choose the brochures that they want to receive through the normal mail.

Use Case 1 - Registration
BCo users register with the  Bco.demo website. They enter their name and postal address. They choose what brochures they want to receive.

Use Case 2- Edit
BCo users can logon to the site and modify their address details as well as change the range of brochures that they receive.

Use Case 3- Delete
BCo Users can delete their accounts when they no longer want to use the application

Use Case 4- WebSite Admin Downloads Addresses
On a regular basis, the BCo Website Admin logs on and downloads the list of BCo user names and addresses as well as the list of brochures that they want to receive. The list is downloaded as a CSV file to their laptop. The BCo Website Admin cleans up the list.

Use Case 5 - WebSite Admin Forwards List
The BCo website admin then sends the cleaned up list in a spreadsheet format to PrinterCo in an email. PrinterCo then prints the brochures and sends the brochures to the BCo users via normal mail.

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot