Researchers reported Friday that TeamTNT is using compromised AWS credentials to attack AWS cloud environments via the cloud platform’s application programming interface. The threat actors are now also targeting the credentials of 16 additional applications, including the AWS apps as well as Google Cloud credentials.

The researchers said the threat actors can now identify all identity and access management (IAM) permissions, elastic computer cloud instances, S3 buckets, CloudTrail configurations, and CloudFormation operations granted to the compromised AWS credentials.

This attack was significant because in hitting Google Cloud it represents the first time attackers have targeted IAM credentials on compromised cloud instances outside of AWS. Although it’s still possible that TeamTNT could target the IAM credentials of Microsoft Azure, Alibaba Cloud, Oracle Cloud, or IBM Cloud using similar methods, Unit 42 researchers have yet to find evidence that there has been an attack on the other cloud providers. TeamTNT first started collecting AWS credentials on cloud instances they had compromised as early as August 2020.

In a blog post, Palo Alto’s Unit 42 researchers said these latest discoveries followed the threat group having targeted Kubernetes clusters and creating a new malware called Black-T that integrates open source cloud-native tools to advance its cryptojacking operations.

Yaniv Bar-Dayan, co-founder and CEO at Vulcan Cyber said any enterprise using cloud services needs to understand that offloading compute and storage infrastructure to a cloud provider doesn’t mean offloading cloud security. Companies still need to apply a comprehensive vulnerability management and mitigation plan to all cyber resources utilized by a company, including cloud apps.

“Cloud vulnerabilities are not the same as application vulnerabilities and both require different remediation and mitigation actions to protect from organizations like TeamTNT,” Bar-Dayan said. “We agree with Unit 42 researchers and reiterate the immediate need to protect cloud infrastructure using the appropriate remediation steps common to cloud environments such as configuration changes, compensating controls, and workarounds.”

TeamTNT starts by infiltrating a public cloud environment – with AWS by far the most prevalent target, though Google Cloud was hit this time around – and builds a map of the environment which includes scraped credentials, workloads, and storage, said Oliver Tavakoli, CTO at Vectra.

“All this represents the equivalent of establishing a base camp prior to climbing a high summit,” Tavakoli said. “Then the insertion of cryptomining software begins with TeamTNT counting on the fact that target organizations won’t notice the uptick in usage charges for a while.”

GitHub announced on Friday their updated community guidelines that explain how the company will deal with exploits and malware samples hosted on their service.

To give some background behind the new policy changes, security researcher Nguyen Jang uploaded a proof-of-concept exploit (PoC) to GitHub in March for the Microsoft Exchange Proxy Logon vulnerability.

Soon after uploading the exploit, Jang received an email from Microsoft-owned GitHub stating that PoC exploit was removed as it violated the Acceptable Use Policies.
In a statement to Bleeping Computer, GitHub said they took down the PoC to protect Microsoft Exchange servers that were being heavily exploited at the time using the vulnerability.
However, GitHub faced immediate backlash from security researchers who felt that GitHub was policing the disclosure of legitimate security research simply because it was affecting a Microsoft product.

GitHub releases updated guidelines
In April, GitHub issued a ‘call for feedback’ to the cybersecurity community regarding their policies for malware and exploits hosted on GitHub.

After a month of input, GitHub officially announced yesterday that repositories created to host malware for malicious campaigns, act as a command and control server, or are used to distribute malicious scripts, are prohibited.

However, the uploading of PoC exploits and malware are permitted as long as they have a dual-user purpose.

In the context of malware and exploits, dual-use means content that can be used for the positive sharing of new information and research while at the same time can also be used for malicious purposes.

The key changes added to the GitHub guidelines are summarized below:

We explicitly permit dual-use security technologies and content related to research into vulnerabilities, malware, and exploits. We understand that many security research projects on GitHub are dual-use and broadly beneficial to the security community. We assume positive intention and use of these projects to promote and drive improvements across the ecosystem. This change modifies previously broad language that could be misinterpreted as hostile toward projects with dual-use, clarifying that such projects are welcome.
We have clarified how and when we may disrupt ongoing attacks that are leveraging the GitHub platform as an exploit or malware content delivery network (CDN). We do not allow use of GitHub in direct support of unlawful attacks that cause technical harm, which we’ve further defined as overconsumption of resources, physical damage, downtime, denial of service, or data loss.
We made clear that we have an appeals and reinstatement process directly in this policy. We allow our users to appeal decisions to restrict their content or account access. This is especially important in the security research context, so we’ve very clearly and directly called out the ability for affected users to appeal action taken against their content.
We’ve suggested a means by which parties may resolve disputes prior to escalating and reporting abuse to GitHub. This appears in the form of a recommendation to leverage an optional SECURITY.md file for the project to provide contact information to resolve abuse reports. This encourages members of our community to resolve conflicts directly with project maintainers without requiring formal GitHub abuse reports.
While dual-use content is allowed, the new GitHub guidelines around PoCs and malware states that they retain the right to remove dual-use content, such as exploits or malware, to disrupt active attacks or malware campaigns utilizing GitHub.

GitHub states that they continue to support community feedback regarding their policies to continue improving their policies.

Most vulnerabilities are from mistakes, not malicious attacks
Security vulnerabilities can often go undetected for over four years before they are disclosed, according to the latest 2020 Security report by GitHub.

As per the report, vulnerabilities can often not be detected for more than for years. Once they are disclosed, developers may take over four weeks to fix these vulnerabilities.

Once they are identified, the package maintainer and security community typically create and release a fix in just over four weeks. This highlights the opportunities to improve vulnerability detection in the security community,” the report said.

However, the majority of vulnerabilities arise from mistakes and not malicious attacks.

“Most vulnerabilities are from mistakes, not malicious attacks: While malicious attacks are more likely to get attention in security circles, 83 per cent of the CVEs that GitHub sends alerts for are due to mistakes rather than malicious intent,” as per the report.

Active repositories with a supported package ecosystem have a 59 per cent higher chance of getting a security alert in the next 12 months.

Software packages based on Ruby (81 per cent) and JavaScript (73 per cent) are most likely to receive an alert in the last 12 months.

Apart from this, the report also states that 94 per cent of projects rely on open source components. These have approximately 700 dependencies. This makes the projects more vulnerable in terms of security.

“Most projects on GitHub rely on open-source software. We see the most frequent use of open source dependencies in JavaScript (94 per cent), Ruby (90 per cent), and .NET (90 per cent). A repository can have hundreds of dependencies, so when there’s a problem with security in the supply chain, you see a massive ripple effect,” the report added.

Automation can help improve security and provide a security patch for vulnerabilities faster, as per the report.

A design flaw in Actions, GitHub’s workflow management platform, can give hackers write access to repositories and reveal encrypted secrets, Google Project Zero researcher Felix Wilhelm has reported.

An attacker can exploit set-env, one of the commands supported by GitHub Actions, to dump NodeJS commands to the shell output, which are then processed and run by Actions’ runner process.

“As the runner process parses every line printed to STDOUT looking for workflow commands, every GitHub action that prints untrusted content as part of its execution is vulnerable,” Wilhelm writes. Projects that have complex GitHub workflows comprised of multiple steps are especially at risk.

For instance, in the case of Microsoft’s Visual Studio Code GitHub repo, Wilhelm was able to exploit the bug by injecting code in an issue title passed to the project’s new issue workflow.

Another example is Stale, one of GitHub Actions’ own modules for closing stale issues and pull requests. In projects such as RocketChat, which use stale as part of a multi-step workflow, attackers can use the set-env command to stage code injection attacks.

In his research, Wilhelm found similar issues in actions that operate on pull requests. “An external contributor can just create a pull request between two existing branches in the target repo to trigger a privileged workflow run,” Wilhelm writes.

Following Wilhelm’s report, GitHub issued an advisory, confirming the vulnerability and declaring it will disable set-env and another command, add-path, in the future.

“To allow us to address this issue and maintain the ability for you to dynamically set environment variables we have introduced a new set of files to manage environment and path updates in workflows,” GitHub wrote in a blog post following the advisory.

“If you need to log untrusted information such as issue titles, bodies, or commit messages to STDOUT we recommend that you disable command processing prior to doing that.”

Wilhelm could not be reached for comment.

Mitigation
In written comments to The Daily Swig, a spokesperson for GitHub said: “Each submission to our bug bounty program is a chance to make GitHub, our products, and our customers more secure.

“We are continuing to migrate customers off of the set-env and add-path workflow commands feature and deprecate it as quickly as possible with minimal disruption to our users in the Actions ecosystem.

“We plan to fully deprecate set-env and add-path workflow commands in the next month, and have included guidance on how to move off of this feature as well as options for patching prior to the deprecation in our disclosure.”