HipChat Breach Shows Dangers of Slacking on Security of Third-Party Components

This week, HipChat advised customers that one of its databases was breached by attackers who exploited a vulnerable third-party library used on HipChat.com. HipChat, owned by Atlassian, said that the compromised database stored customer usernames, email addresses, hashed passwords, and room metadata such as room name and topic.

HipChat’s fast action to force a reset of all HipChat passwords and its use of bcrypt and a random salt to store passwords securely appear to have limited the damage. But attackers may have compromised a small number of accounts (.05 percent) to access chatrooms, messages and content in rooms, according to HipChat Chief Security Officer Ganesh Krishnan’s blog post.

No other Atlassian products or services were affected, and financial data does not appear to have been accessed, Krishnan said.

However, the HipChat breach is concerning for a few big reasons: namely, the third-party library that was the source of the breach remains unpatched, according to a tweet from Atlassian CEO Scott Farquhar. That means other websites and applications are vulnerable.

The HipChat breach also puts an exclamation point on warnings – from application security companies like Veracode – that attackers continue to exploit vulnerabilities in third-party and open source components. Components are frequently not tracked by developers and organizations who use them in their applications. Therefore, vulnerabilities in components can remain unpatched for long periods of time. 

All of this adds up to make vulnerable components a big, easy target for cyberattackers. Just last month, a vulnerability in Apache Struts 2, a commonly used Java library, was exploited in attacks on the Canada Revenue Agency. Veracode scans found that vulnerable versions of Struts 2 were present in 68 percent of applications using the library.

Getting a handle on vulnerable components

To be clear, using third-party and open source components isn’t the problem. And open source isn’t inherently riskier than the code you develop in-house. The issue is failure to keep visibility into the threat landscape and update components when new vulnerabilities are disclosed.

Tim Jarrett, Veracode director of enterprise security strategy, said many organizations lack a systematic way to address vulnerable components in their development process. 

“It’s hard to get action on component vulnerabilities without a recognition at the business level that addressing component risk is a priority. A policy can help to establish handling component risk as a business priority and establish what to do with applications that don’t comply,” Tim said.

“As an added benefit, having a policy can also help ensure that there’s traceability between security requirements and any requirements of industry regulation,” Tim said. “Several industry regulations, including new financial regulations taking effect in New York, require organizations to manage risk from third-party components.”

Development and security teams also need to shift their mindset and recognize that “free” components actually come with a cost.

“Open source isn’t free like the air you breathe,” Tim said. “I find it helpful to think of open source as a balance sheet. The functionality it delivers can be an asset to a development team, but keep in mind that the asset is offset by technical debt that requires regular payments, in the form of applying regularly released updates to the open source library.”

Finally, as developers make changes to their applications, it’s important to keep an up-to-date inventory of the components they are using. Veracode makes this easy by collecting information about your application’s open source components at the same time that static analysis is conducted – including open source components used by compiled libraries for which you have no source code.

Visit veracode.com to learn more about strategies to reduce risk from open source components using software composition analysis.