The IT Nerd

GitHub has announced that it has expanded its secret scanning “validity check” feature to include Amazon Web Services (AWS), Microsoft, Google, and Slack. The feature was introduced last December and was limited to scanning public repositories on the GitHub platform. “Secret scanning alerts notify you directly about leaked secrets in your code,” the company said at the time.

Validity checks will alert users if exposed tokens found by secret scanning are active. The company said it intends to support more tokens in the future.

GitHub also offers push protection to help developers secure code by scanning for secrets before they are pushed into the code base.

George McGregor, VP, Approov Mobile Security had that to say:

   “This is a great extension to an important service provided by GitHub. Knowing when your secrets have leaked is important, but equally important is what you do about it.

   “It is important to have a plan and have the tools in place to act immediately. In other words, to be able to rotate compromised secrets and keys in real-time without having to update code or upgrade apps.

   “That way GitHub provides the “early warning” about leaked secrets and a cloud based secret-management solution provides the ability to act quickly.”

I agree. This is a great way to avoid an “oops” moment that can have devastating consequences. I applaud GitHub for taking this step as this is one of those things that will make things better for all of us in the long term.

GitHub has announced the rollout of passkeys which allow developers to use them in place of both their passwords and 2FA authentication methods. This also enables logging in to applications and online platforms using personal identification numbers (PINs) or biometric authentication methods, such as facial recognition or fingerprints:

Passkeys build on the work of traditional security keys by adding easier configuration and enhanced recoverability, giving you a secure, privacy-preserving, and easy-to-use method to protect your accounts while minimizing the risk of account lockouts. Unlike SMS and email , passkeys are unique per website, so they cannot be used to track a user’s activities across different sites. The best part is that passkeys bring us closer to realizing the vision of passwordless authentication—helping to eradicate password-based breaches altogether.

Eduardo Azanza, CEO, Veridas:    

“It’s crucial to see organizations move towards a passwordless future. As we see the convergence of the digital and physical world, biometric verification is the only way to secure and protect users.

Passwords are now outdated. They can be stolen and leaked onto the dark web to commit other crimes such as fraud and identity theft. Earlier this year, Google made a similar announcement – warning about the dangers of passwords and recognizing the benefits of using biometrics.

Biometrics are linked to a user’s physical identity, which means they are much harder to steal compared to passwords. Therefore, security teams are able to quickly detect fraud, phishing and spoofing techniques, as they can more accurately identify and verify users.

As well as the security benefits for GitHub users, biometrics drastically improve the user experience. With biometric verification, users don’t have to remember dozens of passwords, reset them when they are forgotten, or go through double authentication steps. Biometrics will verify and authenticate users within seconds, not leaving the user frustrated, which would be the case if a password was involved.

Whilst passkeys are a positive step forward, in order to make users even more secure, GitHub and other organizations should look towards more secure forms of biometrics such as voice verification and full-facial scans, which can combat threats such as deepfakes.”

This is a good move by GitHub and I hope to see other companies make the move towards the availability of passwordless authentication solutions. And ultimately, towards requiring their use as that would make the digital universe a safer place.

GitHub’s beta push protection program is now open to the public, auto scanning for a list of 230 token types. The service will proactively prevent leaks by scanning for secrets before a ‘git push’ operation is accepted. “If you are pushing a commit containing a secret, a push protection prompt will appear with information on the secret type, location, and how to remediate the exposure,” GitHub said today.

Excerpts:

To help developers and maintainers across open source proactively secure their code, GitHub is making push protection free for all public repositories.

Push protection prevents secret leaks without compromising the developer experience by scanning for highly identifiable secrets before they are committed.

In certain instances, you may need to push code that has a secret in it–for example, fixing an outage with speed and addressing the secrets after. You can bypass push protection by providing a reason, for example, it’s used for testing, is a false positive, or is an acceptable risk that will be fixed later. Repository and organization administrators and security managers will receive an email alert on all bypasses and can audit any bypasses via their enterprise and organization audit logs, alert view UI, REST API, or webhook events.

Ted Miracco, CEO, Approov Mobile Security had this to say:

“Overall, the push protection program by GitHub is a step in the right direction, and could be especially impactful in improving mobile app security, for critical fintech and healthcare apps that leak secrets in over 90% of the apps tested. This an excellent tool for developers to use in securing their code, however it is only effective if CISOs are committed to enforcing the use of the capabilities. 

   “Making push protection free for all public repositories is another positive that can lower the barriers to use of this technology. However, it’s worth noting that the push protection feature can slow down the development process, and this may lead developers to bypass the testing in certain instances. It will be very important for administrators to keep track of any exceptions and to audit regularly to ensure compliance with the security of the system.”

This is a good move as it protects users from their own mistakes. Which in today’s environment could have far reaching consequences. Good on you GitHub!

Well this is embarrassing.

GitHub has had to update its SSH keys after they accidentally published the private part of the key to the entire planet.

A post on Github’s security blog reveals that the company has changed its RSA SSH host keys. That will cause connection errors, and some frightening warning messages. But don’t worry developers, GitHub hasn’t been pwned. They just screwed up. But everything will be fine.

#Sarcasm

Kevin Bocek, VP Ecosystem and Community at Venafi had this comment:

“GitHub needs to take a closer look at how it manages its SSH keys as an exposure of this kind – no matter how brief – could have serious ramifications given the high level of privilege these machine identities are afforded. These critical machine identities are incredibly powerful and are used everywhere, but they’re also poorly understood and managed, making them a prime target for attackers. Unlike other machine identities, like TLS, SSH keys don’t expire. This means that a compromised identity could be abused for a long time – months or even years – without an organization knowing.

Fortunately, GitHub responded quickly to rotate the impacted machine identities once it noticed that the private SSH key was accidentally published in a public repository. And luckily, it doesn’t appear that they’ve been abused. But if an attacker had seized this opportunity, then it would have given them a very powerful weapon – potentially allowing them to spread across GitHub’s customer networks, eavesdropping on user’s connections, and accessing GitHub’s infrastructure too, while appearing completely trustworthy. In a machine-driven world, having a control plane to manage the lifecycle of machine identities is essential. As this incident shows, you can find yourself exposed very quickly and if not handled quickly, serious repercussions will follow.”

Hopefully GitHub learns from this and as a result has better practises in terms of their SSH keys so that they not only avoid the possibility of getting pwned, but being the punchline in a joke.

Remember when I posted a story about GitHub releasing a security alert for an attack campaign using stolen OAuth user tokens issued by two third-party OAuth integrators? Well there was an update to that post that shares some additional details:

GitHub’s analysis of the attacker’s behavior reveals the following activities carried out on GitHub.com using stolen OAuth app tokens:

1. The attacker authenticated to the GitHub API using the stolen OAuth tokens issued to Heroku and Travis CI.
2. For most people who had the affected Heroku or Travis CI OAuth apps authorized in their GitHub accounts, the attacker listed all the user’s organizations.
3. The attacker then selectively chose targets based on the listed organizations.
4. The attacker listed the private repositories for user accounts of interest.
5. The attacker then proceeded to clone some of those private repositories.

This pattern of behavior suggests the attacker was only listing organizations in order to identify accounts to selectively target for listing and downloading private repositories. GitHub believes these attacks were highly targeted based on the available information and our analysis of the attacker behavior using the compromised OAuth tokens issued to Travis CI and Heroku.

Following this series of notifications, GitHub will have completed directly notifying each affected user for whom we were able to detect abuse using the stolen OAuth tokens.

In short, these were targeted attacks using OAuth tokens that effectively gives the attacker to ability to do a complete account takeover. Which is of course bad.

Yariv Shivek, VP of Product, Neosec had this comment on this news from GitHub:

“OAuth tokens and API keys are often stolen, leading to complete account takeover. When account takeover is for an admin account, the problems inside a business are exacerbated. But having your customers or business partners compromised and their identities assumed is a problem that is hard to detect. How can you know who’s using a token they present to your API? In this OAuth world, do you really know who’s connecting to which API on behalf of whom? Understanding the context of use of these APIs is fast becoming an essential requirement for protecting your business.”

GitHub has posted this blog post on the Best practices to keep your projects secure. But companies or individuals should do more to ensure that their GitHub repositories are actually secure. Because if they don’t, they could be the next target of a threat actor.

On April 18^th, GitHub issued this Security alert: Attack campaign involving stolen OAuth user tokens issued to two third-party integrators. The alert warns that private repository contents were accessed via third-party OAuth user tokens maintained by Heroku and Travis CI. Which of course is very, very bad.

David Stewart, CEO, Approov had this comment:

“API keys and OAuth tokens are prime targets for attackers because they are relatively long lifetime identifiers which can be exploited at scale via scripts, similar to credential stuffing techniques using traditional usernames and passwords.

Organizations must consider worst case scenarios where API keys and OAuth tokens become available to bad actors and ensure that these assets can’t be weaponized against their business. A typical way to mitigate such situations is to implement and additional authentication requirement to ensure that these credentials can only be used from genuine remote client instances, eg web apps or mobile apps.”

Chances are if you were affected by this, you will know about it. But it wouldn’t hurt to check your GitHub repositories to make sure.