Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

5/17/2019
03:00 PM
100%
0%

DevOps Repository Firms Establish Shared Analysis Capability

Following an attack on their users, and their shared response, Atlassian, GitHub, and GitLab decide to make the sharing of attack information a permanent facet of their operations.

During the May 2 ransomware attack on their users, popular repository-service providers Atlassian, GitHub, and GitLab all rushed to analyze the origins of the incident and help their users recover. 

As part of the response, the security teams at the three companies began to share data on the attacks and how the attackers operated. The collaboration worked so well, in fact, that the companies plan to make it permanent, says Kathy Wang, senior director of security at GitLab. Among the ongoing collaboration, the companies will explicitly search for files stored in their users' repositories that may contain credentials to the other services, she says.

"We realized that it was so much better for us to work together for the common good of the Git user community than stay siloed," Wang says. "If we can work with them to report these types of things, we can do better security hygiene for our users."

Sharing information on threats between competitors has increasingly become the norm, rather than the exception. Other industries have created information sharing and analysis centers (ISACs), and several subsectors of technology companies regularly share information — especially among groups of security firms — but this is the first time a group of developer-focused companies have banded together.

This week, Atlassian, GitHub, and GitLab posted to each of their sites the results of a joint analysis created through collaboration among the companies security teams.

"The security and support teams of all three companies have taken and continue to take steps to notify, protect, and help affected users recover from these events," the joint blog post stated. "Further, the security teams of all three companies are also collaborating closely to further investigate these events in the interest of the greater Git community."

On May 2, Atlassian, GitHub, and GitLab had to scramble to figure out whether the ransomware attack on their users meant that attackers had somehow breached their services. The repositories of approximately 1,000 users had been wiped and replaced with a ransom note, stating:

"To recover your lost data and avoid leaking it: Send us 0.1 Bitcoin (BTC) to our Bitcoin address [deleted] and contact us by Email at [email protected] with your Git login and a Proof of Payment. If you are unsure if we have your data, contact us and we will send you a proof. Your code is downloaded and backed up on our servers. If we dont receive your payment in the next 10 Days, we will make your code public or use them otherwise."

The three companies confirmed independently that in every case, the attackers compromised accounts using a variety of legitimate credentials. In addition to usernames and passwords, the attackers used application passwords, API keys, and personal access tokens, they said. Rather than reused credentials stolen in other breaches, the collection of passwords and keys likely came from repositories that inadvertently published files containing the secrets.

"Subsequently, the bad actor performed command-line Git pushes to repositories accessible to these accounts at very high rates, indicating automated methods," the analysis stated.

Working together, the companies identified a file containing the collected credentials for about a third of the targeted developers. The so-called "credential dump" was hosted on the same online provider that was identified as the source of the attacks, the three companies discovered.  

As late as May 10, the attackers continued to systematically scan for credentials mistakenly stored in the configuration files for Git, the program that acts as the conduit between developers and the various repository services. The scan came from the same IP address as the account compromises, the analysis stated.

The attacks continue a trend among cybercriminals and nation-state actors in targeting developers. From compromising their systems, as in the case of the malware inserted into an update for Piriform's CCleaner, to a series of attempts to poison open source projects, attackers are attempting to insert their code into the software supply chain, says Danny Grander, co-founder and chief security officer of software-security service Snyk.

"This is just one of the many ways that developers are the target," he says. "There is a rise in open source packages that are malicious and the targeting of developers with simple spray-and-pray types of attacks."

Developers should take their defense more seriously, Grander says. He and the three repository firms all urged developers to turn on two-factor authentication for their repositories — a defensive measure that would have prevented the ransomware attack. 

Meanwhile, Atlassian, GitHub, and GitLab will continue to share information with each other on attacks targeting repositories. The benefits of the collaboration became apparent during the response to the attack.

"As that whole initial exercise dissolved, we decided to permanently have a threat-intelligence sharing initiative between us," GitLab's Wang says. 

Currently, the companies just have a shared Slack channel, and that is working well for now, she said.

Related Content

 

 

 

Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Commentary
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
Edge-DRsplash-11-edge-ask-the-experts
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
News
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Google's new See No Evil policy......
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-33347
PUBLISHED: 2021-06-18
An issue was discovered in JPress v3.3.0 and below. There are XSS vulnerabilities in the template module and tag management module. If you log in to the background by means of weak password, the storage XSS vulnerability can occur.
CVE-2021-33576
PUBLISHED: 2021-06-18
An issue was discovered in Cleo LexiCom 5.5.0.0. Within the AS2 message, the sender can specify a filename. This filename can include path-traversal characters, allowing the file to be written to an arbitrary location on disk.
CVE-2021-33577
PUBLISHED: 2021-06-18
An issue was discovered in Cleo LexiCom 5.5.0.0. The requirement for the sender of an AS2 message to identify themselves (via encryption and signing of the message) can be bypassed by changing the Content-Type of the message to text/plain.
CVE-2021-32536
PUBLISHED: 2021-06-18
The login page in the MCUsystem does not filter with special characters, which allows remote attackers can inject JavaScript without privilege and thus perform reflected XSS attacks.
CVE-2021-21669
PUBLISHED: 2021-06-18
Jenkins Generic Webhook Trigger Plugin 1.72 and earlier does not configure its XML parser to prevent XML external entity (XXE) attacks.