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
How SolarWinds Busted Up Our Assumptions About Code Signing
Dr. Jethro Beekman, Technical Director,  3/3/2021
News
'ObliqueRAT' Now Hides Behind Images on Compromised Websites
Jai Vijayan, Contributing Writer,  3/2/2021
News
Attackers Turn Struggling Software Projects Into Trojan Horses
Robert Lemos, Contributing Writer,  2/26/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: George has not accepted that the technology age has come to an end.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
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-2009-20001
PUBLISHED: 2021-03-07
An issue was discovered in MantisBT before 2.24.5. It associates a unique cookie string with each user. This string is not reset upon logout (i.e., the user session is still considered valid and active), allowing an attacker who somehow gained access to a user's cookie to login as them.
CVE-2020-28466
PUBLISHED: 2021-03-07
This affects all versions of package github.com/nats-io/nats-server/server. Untrusted accounts are able to crash the server using configs that represent a service export/import cycles. Disclaimer from the maintainers: Running a NATS service which is exposed to untrusted users presents a heightened r...
CVE-2021-27364
PUBLISHED: 2021-03-07
An issue was discovered in the Linux kernel through 5.11.3. drivers/scsi/scsi_transport_iscsi.c is adversely affected by the ability of an unprivileged user to craft Netlink messages.
CVE-2021-27365
PUBLISHED: 2021-03-07
An issue was discovered in the Linux kernel through 5.11.3. Certain iSCSI data structures do not have appropriate length constraints or checks, and can exceed the PAGE_SIZE value. An unprivileged user can send a Netlink message that is associated with iSCSI, and has a length up to the maximum length...
CVE-2021-27363
PUBLISHED: 2021-03-07
An issue was discovered in the Linux kernel through 5.11.3. A kernel pointer leak can be used to determine the address of the iscsi_transport structure. When an iSCSI transport is registered with the iSCSI subsystem, the transport's handle is available to unprivileged users via the sysfs file system...