GitHub vulnerability leaks sensitive security reports

A newly discovered vulnerability on GitHub could expose security reports, giving attackers the opportunity to exploit code flaws before users have a chance to apply patches.

Justin Cappos, a professor in the Department of Computer Science and Engineering at New York University, discovered the vulnerability by applying a patch to another account’s repository. He explains that he noticed that his security reports were shared with the account owner… Justin Cappos discovered the vulnerability on March 13 and reported it to GitHub on March 20 through his bug bounty program with HackerOne, but no CVEs have been assigned since then .

Justin Cappos told us that the attack vector involves .github repositories containing security.md files in which users store instructions on how to report a vulnerability found in their repositories. Therefore, Security.md files must be publicly accessible. The vulnerability is triggered when a user attempts to implement a fix for an issue they discovered in another repository.

Accessing the Security.md file could reveal security weaknesses in another user’s .github repository, but attackers would still have to exploit those weaknesses to launch attacks, Kappos said. Thus, the risk is real with the second intention.

“What happens is that the security.md file contains a link to where vulnerabilities are reported, so the vulnerabilities reported in my software will be transmitted to the attacker,” he said. “So a competent person can understand that anyone who uses my reporting software runs the risk of informing more people due to an error. When they tell me about the problem, that information gets to the hacker. The latter can then compromise all my users if he knows how to quickly exploit the discovered problem.”

In fact, when GitHub users discover a bug, they are prompted to fork the repository containing the issue, and that repository is then marked as .github. They then submit a pull request to the new .github repository to notify the user of the fix. If a forked .github repository contains security.md files, security vulnerability reports for all user projects that do not have a .github repository will be sent to the notifier.

The vulnerability could work whether users merge the pull request or not, warns Justin Cappos. He called on GitHub to make it more difficult to launch an attack.

“When you fork someone else’s .github, whatever they said to do for security reporting ends up automatically being applied to all your repositories. There is no warning about this. There are no notifications,” warns Justin Cappos. “Essentially, you, as a user who is just trying to do something good, like fix a typo or bug, suddenly find yourself handing over all your security reports to a third party, including those that have malicious intentions. »

Justin Cappos raises many sensitive issues related to this vulnerability. Security.md files in .github repositories may contain a range of sensitive information. When a user takes over another user’s repository to make changes, the Security.md file is applied to all of that user’s .github repositories. The GitHub user will subsequently not be able to change the file after the fork; the fork contains all the contents of the files at that time.

Another concern: the vulnerability could affect extremely secure repositories in ways that users might not expect. However, Justin Cappos emphasizes that the attacks will only affect legitimate users seeking to fix bugs in code or projects published on GitHub.

Justin Cappos explains that he has not yet seen any evidence that such attacks took place. But they analyzed GitHub repositories and found that thousands of users had accidentally leaked their security.md files. He notes that the security information of some popular projects has been changed, but it is unknown whether these changes are intentional, accidental or malicious. He adds that most of the affected repositories are not considered critical.

According to Justin Cappos, the vulnerability is easy to exploit, but targeting is difficult. However, attackers can lure users by deliberately including errors in their code, but there is no guarantee that they will respond.

During the vulnerability disclosure process with HackerOne on March 20, Justin Kappos confirmed that they have documentation of the issue. GitHub is taking the vulnerability seriously, but at the same time it is not sure that this is a real vulnerability that needs to be fixed.

“I somewhat agree with GitHub’s assessment that this is not very serious. Although their issue tracker has rated this as critical (the highest category) – mainly because you have access to very sensitive information and it affects a wide range of repositories – the fact is that someone has to be a good Samaritan in the first place and forking your repository to send a pull request makes it harder to attack a specific part,” admits Justin Cappos. “However, for an attacker who simply wants to compromise projects as a whole, this is a significant problem.”

To date, no CVE or patch has been assigned for this vulnerability, and Justin Cappos encourages users to protect themselves by creating an empty .github repository.

“If you created your own .github repository, this will not affect you, since you will not be able to overwrite yours when you fork someone else’s. But if you haven’t created it, which most users don’t because they’re not very popular, then you’re vulnerable,” he explains.

Contacted by TechTarget (MagIT’s parent company), GitHub is committed to investigating the security issues found and explains: “We have taken note of this report, submitted as part of the GitHub bug bounty program, and have confirmed that it represents a low level of security. risk and low likelihood of exploitation. We continue to invest in improving the security of GitHub and our products, and are exploring ways to make this behavior clearer when editing security policy files. »

However, recent attacks on GitHub users have highlighted the popularity of the development platform among attackers, as well as the risks to the open source software supply chain. Earlier this month, Checkmarx discovered that attackers were manipulating GitHub shares and the star watch feature to trick developers into uploading malicious code. In March, Checkmarx reported another attack campaign in which attackers poisoned several popular GitHub code repositories, including Top.gg, which is used for search and discovery on the Discord platform.