Weak Password used in Ransomware Attack

Recently, it’s been reported that there have been a number of ransomware attacks against Github and Bitbucket. The attacks have a similar attack pattern of using a brute force/dictionary attack to gain access to accounts with weak passwords. At least, that’s the theory at this time. (Updated 5/18/2019: Github has posted on their blog that credentials were gained through account leakage.)

We are currently in the process of thinking about moving a large amount of source control into Github and wanted to see what sort of mitigations we have in place for access to source control through a browser.

1. Secondary SSO System
   
   We are going to use a Github Enterprise account, which will be connected to an on-premise SSO solution.
   
   To log into our GitHub repositories you will need to log in through Github username/password system and then you will have to log in a second time through our on-premise SSO solution.
   
2. Strong Password Requirements in On-Premise SSO
   
   Logging in twice doesn’t prevent a weak password from being vulnerable. So, that needs to be a way to enforce strong password strength.
   
   I don’t know if it’s possible to enforce strong password policies within Github (ie. 15 characters, a variety of character types, etc.). But, I know that we do have strong password enforcement within our on-premise SSO. So, that should solve the “weak password” problem.
   
3. Required MFA in Organizational Github Enterprise Account
   
   Another quick thing that should alleviate weak passwords is MFA. Within Github Organizations you can require that 2FA be turned on for your organization. Github offers a number of options for 2FA, but the preferred option should be a TOTP compatible device (like Google Authenticator). Text messages have proven to be a bit insecure.
   
4. Require MFA on On-Premise SSO
   
   So, this ones a bit trickier to work out. I haven’t seen an option in Github which would allow it’s third-party integration system (the one that interacts with the On-Premise Authentication System) to support checking for a field within the returned attributes which states that the third-party/on-premise authentication system used MFA to authenticate the end user. If it was possible to do that, then it would be useful to require that the source control users setup MFA within the On-Premise SSO system as well.

MFA Tokens–AWS Hardware or Google Authenticator

As security goes, MFA One Time Passwords are surprisingly simple. I think that’s one of the great things about them. MFA OTP are all based around a shared a secret. In general it’s a generated string that’s not too terribly long; which makes it easy to store and not too bad to type out every once in a while. That generated string has some mathematical properties that allow it to be combined with a timestamp to create a six digit code that changes every X number of seconds (generally 30 seconds). That’s it. It’s just a shared secret.

So, to use an MFA TOTP all you really need to do is share the secret between the service provider and service consumer. And that’s the comparison I want to make: Is there a difference between how you share the secret when using a hardware token vs Google Authenticator. And, I want to use AWS as the service provider.

Here is AWS’ page on the variety of MFA scenarios that they support, complete with links to purchase suggested hardware devices. It’s a pretty great starting point for anyone.

And, here’s my quick comparison:

Hardware MFA Device

If you go with a Hardware MFA device (for example the gemalto Safenet Display Card), and you start to setup the card in AWS’ IAM user account configuration, you’ll eventually run into this screen:

With that card, the Serial Number printed on the back of the card is the Shared Secret. The security is that you lock the card away and keep it safe; because if you can look at the back of the card, you can get the shared secret.

And, the way the secret is shared is that you send the Shared Secret to AWS over an https connection.

Google Authenticator

If you go with the Virtual MFA device (ie. Google Authenticator), and you start to setup the virtual device in AWS’ IAM user account configuration, you’ll eventually run into this screen:

The QR Code is kind of the classic way of getting the info into your phone. (And, I would suggest screen shoting the QR Code and the “Show secret key” value and storing the image into a password safe. The QR code contains a little extra info that labels the TOTP code in Google Authenticator. Also, it’s kind of annoying to buy a new phone and hand enter all the codes again.)

So, with the virtual device, AWS is generating the Shared Secret. And they are providing the secret to you by sending it to your browser over https. You are then expected to setup a lock on your phone to keep your device safe and secure.

Comparing the two

So is there really a difference? The transmission of the Shared Secret is still over https in both cases. That’s the moment where there is most likely going to be something/someone that could intercept the information.

Once the secret is shared, the hardware device will probably be the more at risk device to reveal the secret. Both the card and the cell phone can be stolen from your pocket or purse. Except, once stolen, the burglar can just read the shared secret off the back of the hardware card; where unlocking an iPhone is kind of a nightmare.