Security Experts:

Lessons From Yahoo Hack: Don't Let Hackers Party on Your 3rd Party Code

On the December 2012, an Egyptian hacker who calls himself ViruS_HimA claimed to have breached Yahoo!’s security systems and acquire full access to certain Yahoo! databases, leading to full access on the server for that domain. The attack method was analyzed and recognized to be a variant of the SQL injection attack and the specific victim Yahoo! web application was identified as a third party astrology application branded as a Yahoo! application.

Yahoo Breach SQL Injection

Figure 1 The hacker's hack evidence screenshot

This attack underscores the security problem posed by third party code. In this case, the vulnerable application was probably not coded by Yahoo! team, and not even hosted on Yahoo’s server farm, leaving Yahoo! with the full responsibility for securing the application on one hand, and a very limited capability to actually control the code, on the other hand.

This is not the first time Yahoo! has been struggling with security issues on third-party code. Last July, Yahoo! Voices was breached and 400K users’ credentials were exposed. According to the hackers, the breach was enabled by a SQL injection vulnerability (Union based SQLi). Yahoo! Voices is an online publishing application that was developed by Associated Content and later acquired by Yahoo!.

The problem of third-party code is not limited to Yahoo!, of course. Almost every web application includes some components that were not developed by the application programmers.

Protecting third party code and applications

The Payment card industry Data Security Standard (PCI DSS) Requirement 6.6 provides two options for web applications protection. The first is to conduct a vulnerability assessment and incorporate the assessments into the software development life cycle (SDLC). The other is to deploy a Web Application Firewall (WAF) if front of the web application.

Naturally, where all the options are available, the best protection is achieved by combining all of them together. However, with third party code, the ability to incorporate the assessments into the software development life cycle (SDLC), or simply put fixing the code, is virtually nonexistent.

Some of the issues can be discovered and fixed beforehand with an appropriate security due diligence. Therefore, from a business standpoint, executives should always assume third party code—coming from partners, vendors, mergers and acquisitions—is vulnerable, and take relevant precautions: Putting in place legal requirements in a contract for what you will and will not accept from a security perspective, incorporate security due diligence for any merger or acquisition activity and require a report specifying security issues and measures taken to address them.

However, when these precautionary measures fail to prevent a security vulnerability, the only practical way to protect third party code is by putting it behind a WAF. In this case of the hacked third party astrology application, Yahoo! could have directed user traffic to with a WAF, deployed on Yahoo!’s environment or on the cloud as a reverse proxy and shield the application. That way, the application would have been protected from the hacking and Yahoo! would have spared the bad PR and the possible abuse of its users’ privacy.

The Key Lessons

Whether you are outsourcing development, services or maintenance, the bottom line is that if you are allowing others to create code and run services that your customers will perceive as coming from you—meaning that you are responsible for any functional problems or security breaches. Guaranteeing that your programs and data will remain secure once you’ve allowed outside applications to run on your servers or integrated them into your Web presence is not an easy task. But there are practices you can adopt that will ensure—as much as possible—that you maintain control over the security of your company and customer information. When it comes to third-party code, protecting applications with a Web Application Firewall is essential.

view counter
Tal Be’ery is a Senior Security Research Manager in Microsoft, formerly the VP of Research at Aorato (acquired by Microsoft), developing Microsoft Advanced Threat Analytics (ATA). Previously, Tal managed various security project teams in several companies. Tal holds a B.Sc and an M.Sc degree in Electrical Engineering and Computer Science and is a Certified Information Systems Security Professional (CISSP). He is the lead author of the TIME attack against HTTPS, has been a speaker at security industry events including RSA, Blackhat and AusCERT and was included by Facebook in their whitehat security researchers list. (Twitter: @talbeerysec)