Dropbox on smart phone screen showing security breach compromised GitHub repositories

Dropbox Security Breach Leads to Compromise of 130 GitHub Repositories

A phishing campaign aimed at Dropbox employees has led to compromise of 130 of the company’s GitHub repositories, as the attacker peppered staff with emails leading to fake login pages and eventually managed to get one to bite. The security breach is not an immediate threat to user Dropbox accounts, but did reportedly provide the attackers with developer tools including API keys.

Dropbox security breach leaks code, developer tools

Dropbox says that the security breach did not involve the contents of any customer accounts, nor any contact or payment information. However, it did include some names and email addresses of company employees and business contacts.

The attackers were instead focused on company GitHub repositories, raiding 130 of them for code and tools. Dropbox says that this did include internal credentials, naming developer API keys as an example.

The security breach appears to have begun on October 13; suspicious activity was flagged in the company’s GitHub repositories and Dropbox was notified on October 14, leading to the discovery that an employee had been compromised by a phishing email.

The attackers sent phishing emails to a number of Dropbox employees, all impersonating the widely used CircleCI DevOps integration platform (which allows for use of GitHub credentials as a login). The attacker captured their login information and prompted employees to use their hardware authentication key to send a one-time password to the attack site, opening the door for them to raid the GitHub repositories.

The amount of personal information lost in this security breach is relatively minimal; a “few thousand” names and email addresses belonging to current and former Dropbox employees, sales leads, vendors and customers (out of the platform’s estimated 700 million users). Dropbox says that customers have nothing to worry about in terms of the contents of their storage or their payment information, and that it brought in outside forensic experts to verify the extent of the security breach.

While customers are not at immediate risk, a security breach that involves internal developer materials is always a cause for ongoing concern. It is not clear exactly what was taken from the GitHub repositories beyond some API keys, but these are the sorts of materials that can be analyzed to find exploitable vulnerabilities and may also provide other types of keys or tokens that will allow attackers to expand their range of access.

Dr. Eric Cole, Advisory Board Member at Theon Technology, thinks that more bad news is yet to come as the complete impact on the GitHub repositories is mapped out: “If this is like other breaches over the next several weeks the 130 repositories will increase to 1300 or 13,000.  In addition, a repository can be very large, contain a lot of subdirectories and a lot of files, so saying 130 repositories is very vague and it can be a large amount of information.  Since repositories contain a lot of data, it also raises a flag when the company says no sensitive data was compromised.  A better answer would have been sensitive data should not be in these repositories but anyone who has worked with Dropbox or GitHub know that data is often copied or stored in directories in which it is not suppose to be stored.

Phishing grows to encompass secondary authentication methods as use of MFA expands

Dropbox issued a statement indicating that it is adopting more phishing-resistant forms of MFA for its employees, beginning with WebAuthn (which is also an option offered to Dropbox customers). The FIDO system that underpins WebAuthn offers some anti-phishing features that other systems do not, such as advanced browser-based verification of connecting site authenticity and keypairs that have more specific and limited uses.

Just as many companies are just beginning to come around to the need for MFA in their networks, the ones that have already onboarded it are finding that they need even more secure systems to keep pace with modern attacks. The breach of the GitHub repositories demonstrates that a well-crafted email phishing attack is still enough to defeat some MFA measures, even the local authentication key methods that are touted as being more secure. But attackers are adding even more complex layers to phishing schemes to account for increased 2FA and MFA use, with a resurgence in the use of SMS phishing and social engineering phone calls as security breach components.

Mika Aalto, Co-Founder and CEO at Hoxhunt, describes one of these recent approaches: “On the automated side, hackers are using bots, such as SMSRanger and BloodOTPbot, that will automatically follow up a credential harvesting attack with a phone call using a carefully crafted social engineering script that ends with obtaining the victim’s authentication code. These bots will only get smarter and more dangerous with advances in technology like AI.”

There is not yet any known connection to the recent campaign that targeted companies that use the Okta access management services, but there are numerous similarities. The Okta attackers sent SMS messages out to employees of companies known to subscribe to the service, linking to a phishing page that ended up capturing credentials of about 130 organizations. Cloudflare was heavily targeted during this campaign, but attributed its ability to prevent a security breach to its more advanced system of hardware key verification. The company’s report on the incident says that three of its employees did in fact follow the phishing links and enter credentials, but the “origin binding” feature of their FIDO2 hardware keys ultimately stopped the verification from going through. The company also expressed confidence that its system of endpoint security measures would have kept the attack from progressing even if an employee account had been compromised.

Nick Rago, Field CTO at Salt Security, sees the breach of the GitHub repositories as another call for organizations to adopt zero trust architecture: “As social engineering attack techniques become more and more sophisticated, organizations must adopt a zero trust mentality with code artifacts as much as possible to stay ahead of threats that can arise when an outsider gains access to GitHub repositories. In this case, Dropbox confirmed that the code accessed by the threat actor contained API keys used by Dropbox developers. It is unclear from the incident notification what those API keys were used for, what systems they connected to (internal or external), and the extent of the data and functional access the threat actor would have with those API keys. Static API keys and other important credentials used by app developers should be secured in some manner and not stored in plain text as part of any “at rest” application source code. Data encryption or leveraging a secure data vault provide two common and more secure alternatives. The Dropbox breach serves as a good reminder for organizations to scan their source code repositories to look for any credentials stored in plain text (API keys, passwords, etc.) that a threat actor could potentially use if they were to gain access to the repository. Additionally, this type of threat illustrates why organizations require runtime API security, which can detect and prevent API abuse if an API key was compromised and used in an API attack.”

Attacker captured employee credentials via #phishing and prompted employees to use their hardware authentication key to send a one-time password, opening the door for them to raid the GitHub repositories. #securitybreach #cybersecurity #respectdataClick to Tweet

William Glazier, Director of Threat Research at Cequence Security, additionally notes this incident as a reminder that API keys must be carefully tracked and monitored at all times to prevent security breaches: “API Keys are a valuable target for attackers. This incident demonstrates why maintaining strong API Key hygiene is so important. This includes never checking API Keys into source control repositories, adhering to least-privileged access role principles for API keys, and rotating them regularly. While in the case of Dropbox the initial compromise took place via phishing, it’s important to have visibility into your run-time API inventory and schema. It is also essential that organizations ensure no sensitive data, such as API Keys, are exposed via any unknown or undocumented API endpoints, and that organizations are able to invalidate the exposed keys and reestablish new ones.”