DevelopSec

You are here: Home / blog

blog

by Leave a Comment

Verizon Email API Insecure Direct Object Reference Thoughts and Takeaways

It was recently announced that there was a flaw identified (and since fixed) in the Verizon API that allowed access to Verizon customer email accounts. The way this worked was that there was an ID parameter with the email account’s user ID specified. If a user supplied a different user’s ID name, that user’s email account would be returned. This is known as an Insecure Direct Object Reference. It was also found that the attacker could not only read another user’s email, but also send email from that account. This could be very useful in spear phishing attacks because users are more trustful of emails from their contacts.

Take-Aways

  • Understand the parameters that are used in the application
  • Use a web proxy to see the raw requests and responses for better understanding
  • Create test cases for these parameters that check access to different objects to ensure authorization checks are working properly
  • Implement row-based authorization to ensure the authenticated user can only see his information

The issue that is presented is that the API is not checking if the authenticated user has permission to access the specified mailbox. It would appear that it is only checking that the user is authenticated. Remember that authentication is the process of identifying who the requesting party is. Authorization is the process of determining what the authenticated user has access to. In this situation, the API should first validate that the user is authenticated, and then when a request is made for a resource (email account in this example) verify that that user is authorized to access that account before allowing it.

Unfortunately, many API’s are vulnerable to this type of attack because there is an assumption that the user can’t change the parameter values due to a lack of user interface. It is imperative that developers and QA testers both use a proxy when testing applications to be able to manipulate these types of parameters. This allows testing for unauthorized access to different objects. This is a very simple test case that should be included for every application, and not just for APIs. If you see a parameter value, make sure it is being properly tested from a security standpoint. For example, and ID field that may be an integer may get tested to make sure that the value cannot be any other type of data, but must also be checked to see if different values give access to unauthorized data.

It was also mentioned that the API didn’t use HTTPS for its communication channel. Using HTTP allows other user’s along the communication line to intercept the request and response data, potentially opening up the user to a variety of vulnerabilities. Make sure you are using the proper communication channel to protect your users in your mobile applications as well as the web applications.

by Leave a Comment

OneStopParking Breach Thoughts and Takeaways

It was recently announced that OneStopParking.com suffered from a data breach exposing customer credit card data. According to the report, the breach occurred due to missing patches in the application’s Joomla install. Apparently the patches caused some problems with the application so they were pushed back. The patches in question were released in September of 2014.

Take-Aways

  • Implement a patch management program
  • Use a web application firewall (WAF) for extended coverage

It is common to come across systems that are not fully patched. Of course there are a multitude of reasons for these scenarios. In this case, the patch caused a problem with the application which means that the developer has to fix their application before the patch can be applied, or not apply the patch at all. All too often the issue with missing patches is that the company just doesn’t have a good patch management process. This is very common when a system uses tools like Joomla or other 3rd party frameworks because they don’t even know updates are available. We are seeing these types of frameworks getting better at alerting the system administrator to the availability of the updates, which is a step forward.

In the case of OneStopParking.com it is nice to hear that they were aware of the patch. That is half of the battle. Unfortunately for them it apparently didn’t play nice with their application so they were not able to install it, ultimately leading to a breach. This example shows that there are risks to any 3rd party frameworks that you use and sometimes you may be at their mercy when it comes to the patches. It can be a difficult decision to determine if the application should continue running unpatched, or be taken offline until everything is working properly.

It is difficult for outsiders to try and determine the risk vs reward in a situation like this. It is a gamble and unfortunately, in this case, one that didn’t pay off. This is a good lesson in patching and 3rd party frameworks. If you are using these frameworks, make sure that you have a way to track what frameworks are in use and what security risks may arise at any given time. Create a plan to test the patches and apply them when appropriate.

If applying a security patch causes an issue, think about alternative methods for protecting that application until the patch can be applied. One option is to install a web application firewall (WAF) in front of the application that can be configured to protect the feature that has the security flaw. While this may not be a permanent solution, it is often recommended for this type of situation.

by

MoonPig Take-Aways

It was recently released that there were some security concerns with how the Moonpig, an online greetings card company in the UK, utilizes their API for mobile applications.  From the public disclosure of a vulnerability found in their API it may be possible for a user to see other user’s personal information, including last 4 of their credit card number, expiration date and name.  This is a great opportunity to look at some of the security issues and how they can be avoided in your code.

Take-Aways

For Developers

  • Use strong authentication mechanisms
    • Tamper Protection
    • Anti-Replay
    • Secure Communication
    • Limited Access
  • Don’t use hard-coded passwords
  • Implement authorization checks at the row level for data records
  • Implement brute-force and anti-automation protections
  • Implement certificate-pinning if possible to limit the ability to intercept traffic

For QAs

  • Use a proxy for inspecting traffic to the API
    • This would help identify use of stored credentials
  • Verify authorization checks
    • This is especially important when you see numeric parameters.  Increment/decrement them to see if access is granted to other customers
  • Check for Brute Force protections

Authentication

One of the first things pointed out in how the MoonPig API works is the authentication.  The application was making use of Basic Authentication, which is commonly seen in mobile API’s.  The good news is that the basic authentication was being performed over a secure channel (HTTPS).  The secure channel helps protect the credentials in transit to the server for verification.  This protection is important because basic authentication only base64 encodes the username and password.  It takes minimal effort to decode base64, although there is a common misconception otherwise.  As an example, the username/password of “James:password” is encoded as “SmFtZXM6cGFzc3dvcmQ=”.  While the resulting output appears to be unreadable, it isn’t.   Basic authentication does have some drawbacks, such as no brute force or anti-replay protections.

It appears that the API in question had some detail about using OAuth2, but it was not implemented.  OAuth provides a great option for authentication for mobile applications.  In some implementations it will include a signature to help prevent tampering of the request, anti-replay functions and other controls that are very useful when authenticating a request.  For more information on OAuth please visit the main OAuth Community Site.

Authorization

The next issue is a lack of authorization when it comes to accessing functionality or data.  Authorization is the ability to determine what functionality or data an authenticated user has access to.  Authentication is required for authorization to work.  In this situation, the ability to view other user’s information is a perfect example.  The API accepted a customer id of some sort, which happened to be an incremental numeric value, which identified what data to display.  By incrementing that customer id, it could be possible to view a different customer’s data.   This is common in many applications and is referred to as a Direct Object Reference.  A properly designed application would only allow the authenticated user to have access to the customer records for which they control and not any others.

Anti-Automation

The final issue to discuss is the lack of brute force protections on the API.  In a situation where simply implementing a parameter value by 1 or other set value returns different data, automating that to scrape lots of data becomes a concern.  It would be one thing if an attacker could grab one record at a time manually and it takes a long time to get the entire database.  It is completely different when a script can run through the 3 million records in a few minutes or an hour.  Unfortunately, this can also be difficult to defend against when it is an API.  With a user interface, you can throw a CAPTCHA or some other method up there, but with a lack of interface that can be a bit more challenging.  This is something that should be thought about when designing your APIs.

Certificate Pinning

It is just an assumption that the application doesn’t use certificate pinning because the traffic was intercepted and modified.  While it is possible to bypass certificate pinning I didn’t get that impression.  The purpose of certificate pinning is to have the app only accept trusted certificates.  When this is configured it makes it more difficult to use a certificate that is generated by the proxy an attacker might use for their man-in-the-middle attempts.

While certificate pinning is a great control, it is not always the right choice.   If your users are within a corporate environment that sends all traffic through a proxy that may strip or modify the SSL then this might not be feasible.

Conclusion

We can learn something from all of the security incidents that we see.  Although the breach may not effect you directly, take the time to understand what happened so you can ensure the same things are not happening within your organization.

by

Welcome

Welcome to the brand new DevelopSec website.  The goal of this site is to provide useful information for IT professionals to help develop better security practices.  All too often, we see that there are professionals that are working very hard to create great products, but do not have the security information they need.  Breaches are happening every day and many wonder why it matters.  We hope to make an impact and show how we can learn from the breaches or other security incidents that occur so frequently.

The site is focused on helping the less security savvy professionals, the developers and testers and line of business.  The intent is to provide valuable information without a lot of extra fluff.  The site, while still under some construction, will consist of a few different resources.  Over the past year, the DevelopSec podcast has been alive and well received.  The podcast consists of 10-20 minutes of thoughts on different security topics.  Thank you to all of you that have listened so far.

In addition, there will be a news section that looks at some of the incidents/breaches we see showing up in the news.  There are a lot of places to get the news, and our goal is not to just share news stories.  We want to go the extra mile and provide thoughts on how the situation in the news could effect you.  Whether that means just some tips on how you might be able to reduce your risk of the same incident or a more detailed summary to provide a better understanding of the real risks.

Another section will be discussions on secure topics that will hopefully be beneficial to our target audience.  Here is looking at what might evolve out of this new year in 2015.