Check out our Monthly Survey Page to see what our users are running.

Libretro / RetroArch were hacked, wiping some repositories

By - | Views: 18,656

In an announcement, the Libretro / RetroArch mentioned how the Libretro / RetroArch organization on GitHub was attacked by hackers and they managed to do quite a bit of damage.

While restoration is ongoing, some of it is going to be more difficult. In the announcement, they mentioned the scale of the damage that was done comes down to:

  • He accessed our buildbot server and crippled the nightly/stable buildbot services, and the netplay lobby service. Right now, the Core Updater won’t work. The websites for these have also been rendered inaccessible for the moment
  • He gained access to our Libretro organization on Github impersonating a very trusted member of the team and force-pushed a blank initial commit to a fair percentage of our repositories, effectively wiping them. He managed to do damage to 3 out of 9 pages of repositories. RetroArch and everything preceding it on page 3 has been left intact before his access got curtailed.

GitHub themselves have replied (source) to mentioned they can't help, so they're now relying on local backups and Git history from their developers to get it back to where it was online.

Some good news though: for users they said no Cores or RetroArch installs should be considered compromised, as the attacker was too busy with wiping things and being a nuisance. However, thanks to it the Core installer is offline as are the 'Update Assets', 'Update Overlays', 'Update Shaders' functions.

Also mentioned is how they didn't have automated backups of their buildbot, a service which helps to automate building the application and testing. Something that's generally vital for larger projects. They said it's due to funding, as they don't have enough for it with a note about supporting them on Patreon to help.

This is another reminder of: backups, backups—backups! More than that though, it's also an example of why two factor authentication is also vitally important. This little detail was left out of their announcement, but they didn't force 2FA which appears to be how the attacker actually got in. Speaking on Twitter, they mentioned how some developers felt it was "too much of a pain" and they didn't want to lose those contributors. Well, was it worth it? Let's hope proper security will be implemented now.

Article taken from GamingOnLinux.com.
20 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
18 comments
Page: 1/2»
  Go to:

TheSHEEEP 17 Aug
View PC info
  • Supporter Plus
What an odd choice of target practice for a hacker.


Last edited by TheSHEEEP on 17 August 2020 at 10:02 am UTC
But why tho?
Eike 17 Aug
Git should be optimal for those cases, right?
With every developer having the history on their discs?
mirv 17 Aug
View PC info
  • Supporter Plus
Done just because they could, no doubt. Be a nuisance, get some perverse pleasure out of it, and ultimately be unremembered and in a few days nobody will care.

At least git lends itself to having local commit histories, so everything can be restored, even if it takes a little mucking about. Distributed source control has many benefits.

Sadly, this won't be the last time such behaviour will occur. No matter how much it's repeated, there are some who won't take basic precautions. Secure your systems as much as you can, and be paranoid about backing up anything important - at least to the level of being able to get up & running again with a minimal of fuss should the primary resource go down.
Arehandoro 17 Aug
Quoting: TheSHEEEPWhat an odd choice of target practice for a hacker.

Not a fan of conspiracy theories, but maybe some companies that don't like the idea of having their older titles being emulated...

QuoteHe accessed our buildbot server and crippled the nightly/stable buildbot services, and the netplay lobby service. Right now, the Core Updater won’t work. The websites for these have also been rendered inaccessible for the moment

He gained access to our Libretro organization on Github impersonating a very trusted member of the team and force-pushed a blank initial commit to a fair percentage of our repositories, effectively wiping them. He managed to do damage to 3 out of 9 pages of repositories. RetroArch and everything preceding it on page 3 has been left intact before his access got curtailed.

Do they already know it was a he?

QuoteThis little detail was left out of their announcement, but they didn't force 2FA which appears to be how the attacker actually got in. Speaking on Twitter, they mentioned how some developers felt it was "too much of a pain" and they didn't want to lose those contributors.

I face this constantly at work. And to be honest, it's bullshit. With setups like MFA from Azure AD, with the Authenticator app, where not even a code is needed to use the 2nd factor. Or with tools like Yubikey that can be used for the same, but also as main way to authentication in websites, any developer complaining about the nuisance of 2FA goes into the "Suspicious list" right away.

And I'm a "quick to pull the trigger" kind of admin when it comes to revoking access to systems xD
Linas 17 Aug
View PC info
  • Supporter Plus
Quoting: ArehandoroDo they already know it was a he?
No, and they never will. They probably just didn't want to write "the asshole" and went with "he" instead.
Dedale 17 Aug
That sounds infuriating and stupid. Interesting article, thanks.
Creak 17 Aug
Quoting: ArehandoroI face this constantly at work. And to be honest, it's bullshit. With setups like MFA from Azure AD, with the Authenticator app, where not even a code is needed to use the 2nd factor. Or with tools like Yubikey that can be used for the same, but also as main way to authentication in websites, any developer complaining about the nuisance of 2FA goes into the "Suspicious list" right away.
And there's also Bitwarden which simplifies it even more with storing the TOTP url. You don't need a second device (which is a security risk), but it is still way harder to hack your account since the hacker should have direct access to your machine in order to get both your password and the TOTP address (which are protected by a main password in Bitwarden).

Here's a very interesting blog post from Bitwarden explaining 2FA in general, and their system:
https://bitwarden.com/blog/post/basics-of-two-factor-authentication-with-bitwarden/

Also, they answer the question "some may ask what is the point of having your username, email, and your two-step login code all stored within the same application [...]? Doesn’t that negate the value of two-step login?"
Quoting: BitwardenThe answer depends. Let’s break it down.
  • Your Bitwarden Vault hopefully already has two-step login using some other method. (ie. do not use the Bitwarden Authenticator to protect your Bitwarden account.) Therefore it is currently protected with a high level of security and, in fact, two-step login.

  • Having two-step login enabled for websites and applications is always better than not having it enabled. A tighter bundling of two-step login makes it easier to use more frequently, which promotes better security hygiene as a practice.

  • If you need to share an item, you can share it with two-step login enabled, which, again, is better security practice. This is a collaboration and two-step login power move.

  • You do not need to remember which authentication app you used, since it is built in.

  • You can always choose, on an individual basis, which login you want to authenticate internally within the Bitwarden app, or externally using a separate Authenticator app.


Bitwarden users find that the integrated Authenticator functionality provides faster workflows with better security and dexterity for collaboration. Users also note that they apply different policies to different types of accounts. Primary financial institutions may be authenticated externally using a separate Authenticator app, while all of their ecommerce logins are authenticated internally within Bitwarden.

Also.. Bitwarden is open source ;)


Last edited by Creak on 17 August 2020 at 2:47 pm UTC
Arehandoro 17 Aug
Quoting: Creak
Quoting: ArehandoroI face this constantly at work. And to be honest, it's bullshit. With setups like MFA from Azure AD, with the Authenticator app, where not even a code is needed to use the 2nd factor. Or with tools like Yubikey that can be used for the same, but also as main way to authentication in websites, any developer complaining about the nuisance of 2FA goes into the "Suspicious list" right away.
And there's also Bitwarden which simplifies it even more with storing the TOTP url. You don't need a second device (which is a security risk), but it is still way harder to hack your account since the hacker should have direct access to your machine in order to get both your password and the TOTP address (which are protected by a main password in Bitwarden).

Here's a very interesting blog post from Bitwarden explaining 2FA in general, and their system:
https://bitwarden.com/blog/post/basics-of-two-factor-authentication-with-bitwarden/

Also, they answer the question "some may ask what is the point of having your username, email, and your two-step login code all stored within the same application [...]? Doesn’t that negate the value of two-step login?"
Quoting: BitwardenThe answer depends. Let’s break it down.
  • Your Bitwarden Vault hopefully already has two-step login using some other method. (ie. do not use the Bitwarden Authenticator to protect your Bitwarden account.) Therefore it is currently protected with a high level of security and, in fact, two-step login.

  • Having two-step login enabled for websites and applications is always better than not having it enabled. A tighter bundling of two-step login makes it easier to use more frequently, which promotes better security hygiene as a practice.

  • If you need to share an item, you can share it with two-step login enabled, which, again, is better security practice. This is a collaboration and two-step login power move.

  • You do not need to remember which authentication app you used, since it is built in.

  • You can always choose, on an individual basis, which login you want to authenticate internally within the Bitwarden app, or externally using a separate Authenticator app.


Bitwarden users find that the integrated Authenticator functionality provides faster workflows with better security and dexterity for collaboration. Users also note that they apply different policies to different types of accounts. Primary financial institutions may be authenticated externally using a separate Authenticator app, while all of their ecommerce logins are authenticated internally within Bitwarden.

Also.. Bitwarden is open source ;)

I use bitwarden personally with a yubikey as hardware 2FA plus OTP within the app :)

At work we use 1password. Plus AWS Secrets Manager. I still need to battle with people as of why is good for them haha.


Last edited by Arehandoro on 17 August 2020 at 3:06 pm UTC
dpanter 17 Aug
Quoting: ArehandoroI still need to battle with people as of why is good for them haha.
Bless your patient soul, you have my sympathy. Dealing with users can be a frustrating experience.
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.