Chinese Hackers Bypassing Two-Factor Authentication

Interesting story of how a Chinese state-sponsored hacking group is bypassing the RSA SecurID two-factor authentication system.

How they did it remains unclear; although, the Fox-IT team has their theory. They said APT20 stole an RSA SecurID software token from a hacked system, which the Chinese actor then used on its computers to generate valid one-time codes and bypass 2FA at will.

Normally, this wouldn’t be possible. To use one of these software tokens, the user would need to connect a physical (hardware) device to their computer. The device and the software token would then generate a valid 2FA code. If the device was missing, the RSA SecureID software would generate an error.

The Fox-IT team explains how hackers might have gone around this issue:

The software token is generated for a specific system, but of course this system specific value could easily be retrieved by the actor when having access to the system of the victim.

As it turns out, the actor does not actually need to go through the trouble of obtaining the victim’s system specific value, because this specific value is only checked when importing the SecurID Token Seed, and has no relation to the seed used to generate actual 2-factor tokens. This means the actor can actually simply patch the check which verifies if the imported soft token was generated for this system, and does not need to bother with stealing the system specific value at all.

In short, all the actor has to do to make use of the 2 factor authentication codes is to steal an RSA SecurID Software Token and to patch 1 instruction, which results in the generation of valid tokens.

Tags: China, hacking, RSA, two-factor authentication

Posted on December 26, 2019 at 6:19 AM • 17 Comments

Comments

Prohias • December 26, 2019 9:34 AM

I read the quoted section twice and didn’t follow at all. Could someone kindly explain the theory of how FoxIT believe it was hacked?

Stephen Harris • December 26, 2019 9:44 AM

RSA Software tokens are not that strong. Software such as “stoken” re-implement it. I wrote up, earlier this year, how soft tokens can be abused and how they have different security characteristics to hardware tokens.

https://www.sweharris.org/post/2019-06-09-softtoken/

With this I could have my soft token on hundreds of machines, and they’re all perfectly valid.

Essentially, RSA Soft tokens aren’t much stronger than TOTP as performed by google authenticator and similar.

Allen • December 26, 2019 12:11 PM

“patch 1 instruction” seems to be the big assumption.

Impossibly Stupid • December 26, 2019 2:52 PM

@Allen

“patch 1 instruction” seems to be the big assumption.

Not really much of an “assumption”, since that’s the way the vast majority of secure systems work. It goes back to at least the 1980s, when the copy protection of most PC software was cracked by replacing calls to a validation subroutine with something that always returned success. Earlier than that, of course, if you count the ability to “access 1 account” (i.e., administrator) to control an entire mainframe. Anywhere that trust comes down to the flip of a single switch is vulnerable.

There are experiences I’ve had myself where we put code in the development and/or testing environment that bypasses authentication/authorization checks in order to make debugging easier. You can do your best to put processes in place to keep that kind of thing from compromising the production environment, but mistakes still happen. Security is hard. 2FA is no panacea.

SpaceLifeForm • December 26, 2019 3:06 PM

@ Allen

NOP (“patch 1 instruction”)

Got root? system?

“could easily be retrieved by the actor when having access to the system of the victim.”

If the APT has gotten root/system, then it is entirely possible that it only takes a simple patch to replace a branch/return instruction with a NOP.

Patch can happen on the fly.

No need for a code-signing check and integrity check on the binary once loaded into RAM. Right?

Right? 😉

Electron 007 • December 26, 2019 3:57 PM

A security dongle or token or smartcard, or anything security-related even slightly out of the ordinary is a sure sign that you Have Something To Hide.

Pickpockets and thieves are everywhere, and if law enforcement officers do not know exactly what it is and what you are doing with it in the context of your official employment, you’re probably — in their eyes — breaking the law yourself and it’s a felony anyway to possess the thing if you aren’t “one of the locals” with a good working relationship with law enforcement.

So.

The only way to hide anything is to have nothing to hide.

And whatcha gonna do about it anyway?

It’s a cat-and-mouse game, the cops don’t want you to have it, and you will be rubber-hosed and/or violently dispossessed of it, whatever it is that you’re not supposed to have or not supposed to be doing.

tds • December 26, 2019 5:57 PM

Anders, Thoth and I considered another article on this topic in this week’s squid. For example, you could start here and work backwards.
https://www.schneier.com/blog/archives/2019/12/friday_squid_bl_708.html#c6803262

Or start here and work forward.
https://www.schneier.com/blog/archives/2019/12/friday_squid_bl_708.html#c6803243

WilliamDeRieux • December 26, 2019 7:31 PM

“steal an RSA SecurID Software Token and, patch 1 instruction, results in the generation of valid tokens.”

If the verification code runs on the client (e.g. client-side token verification) then it isn’t much of a stretch that a skilled-individual could modify that code to do whatever was needed.

so, the only real issue here is whether someone could get a hold of a a valid RSA SecurID Software Token.

Moreover, any time something runs on the client-side there is the potential for modification. It would better to run the verification on the server-side (at least to reduce the risk associated with local modification).

Weather • December 27, 2019 1:35 AM

@WilliamDeRieux
Severside? What comlucates with the server, you are assuming they grab the key but not the algorithm, so you assume they got basic access or not much time on the server, like early we talked about analysis of indevale packets, which some things can’t do due to bandwidth.
A Nop instruction can also affect the traffic to the server, again the client used or lack of algorithm.

me • December 27, 2019 2:01 AM

@WilliamDeRieux
If you have a server side check i can just steal the url you visit to generate tokens, it doesn’t work too
(And steal also credentials)

I have a yubikey and 2FA on my email but…
Even if this can’t be cloned it can be abused:
Suppose a hacked system or phishing, in this case attacker get one and only one code.
What if they login with this code and use the same code to disable 2FA?
Cods are valid for 30 seconds and clicking disable 2FA can be automated so that it can be done in less than 30 seconds.
Are the codes one time use only?
If yes attacker gets onr free login, if not attacker can takeover the account forever.

Clive Robinson • December 27, 2019 2:28 AM

@ ALL,

There appears to be a little confusion between a “hardware token” and a “software token” in terms of generating the alleged “one-time codes”.

The algorithm is often exactly the same, thus takes exactly the same seed, user-ID, and reptesentation of time. The real difference is that the hardware token is alledgedly both “Tamper evident” and “Tamper proof”. Whilst the former might be approximately true, the latter is almost certainly not. As we know from drug abuse by Russian athletes, even high tech tamper evident seals can be got around.

In essence the algorithm can be seen as a stream cipher using a one way function clocked at a slow time interval. The “seed” acting as the “key” with the user-ID mixed in either as part of the key or in a degenerate case as would plaintext in a standard stream cipher to produce the ciphertext that is used as the “one-time code”.

Once the algorithm is known, which would be the same at both the client token end and the server authentication end it’s only the seed and user-ID that has to be found by an attacker. I suspect that in most cases the seed would be the same for all users on a given server, and the user-IDs issued in some sequential manner.

In fact to ensure that the codes were “one-time” in both value at a given time and in sequence you would have to know exactly what seeds and user-IDs had been issued, so they are not “re-issued” by mistake.

There are two basic ways you can do this,

1, Issue them in sequence.
2, Keep a database of all issued.

Whilst the first would appear to be very insecure, the database is not just insecure but a target as RSA found out a number of years ago.

Thus a simple way to do things is to have a counter, that you start at a random –but kept– value and simply increment it by a known value for each issue be it a new “seed” or a “user-ID” you then encrypt the value using a block cipher and secret key or a one-way function. The result gives an apparently random seed and user-ID.

If an attacker gets to know the secret counter initial value and if used the key, then the whole system for all users would be broken.

Whilst there are things that can be done to make such token systems more secure, there is a limit on what can be done with the likes of the very low power microcontrolers used in the hardware tokens.

Realistically the security of such tokens is not going to be high in respect to modern systems.

Electron 007 • December 27, 2019 2:43 PM

So are the Chinese cracking two-factor missile launch codes?

https://www.cnbc.com/2019/12/27/russia-claims-its-new-hypersonic-weapon-is-ready-for-war.html

What about the Russian “кинжал,” the new hypersonic intercontinental ballistic missile capable of carrying an atomic nuclear warhead at five times the speed of sound in air?

If they cracked the two-factor authentication for the missile launch sequence, the Chinese could start a new false-flag Cold War with Russia, and with so much government disinformation going back and forth, we would have no way of know who is fighting against whom.

In fact, “We’ve always been at war with Eastasia” in the words of George Orwell.

Electron 007 • December 28, 2019 4:28 PM

And speaking of Chinese hackers,

https://www.latimes.com/world-nation/story/2019-12-28/hong-kong-ex-cop?_amp=true

It does appear that even the sophisticated denizens of the great city of Hong Kong have become jaded, weary and cynical of the City’s left-wing labor cops and their outdated story of a friendly, approachable City Hall’s representation of the underdog against an oppressive national government.

Peter Nelsen • December 29, 2019 7:54 AM

The technique of the “hack” in the report is facilitated by means of exceedingly poor security procedures during provisioning and distribution. This requires that tokens are distributed using an XML file, no password is specified for the file, and the file is not removed/cleaned (making it available to the bad actor). The headline might have been “Burglar copied door key key under left mat and can enter house without a trace.” The other aspect not mentioned in the report is the token PIN.

The bad actors were able to bypass the “Device Binding”. This is intended to prevent the software token XML file from being imported into the wrong application instance, but is not a true security control. If the token data is not protected with a password (and therefore a derived key), it was not protected. This is akin to the burglar hopping over a gate to retrieve the key under the mat.

IMO, it is more likely some home-grown, new employee provisioning mechanism was compromised. Once the victim’s Windows domain was hacked, they simply added a new “employee” (which automatically provided them a token, allows the new user to set the PIN, etc.) Strong security around the employee provisioning process is paramount.

Jane Thomas • January 6, 2020 9:42 AM

A problem shared is a problem solved, their services team are here to solve all your hacking problem such contact : THEDARKCRACKER @ protonmail com

school Grade Changes hackHack University grades and TranscriptsErase criminal records hackDatabases hackSales of Dumps cards of all kindsIndividual computers hackWebsites hackControl devices remotely hackBurner Numbers hackVerified Paypal Accounts hackAny social media account hackAndroid & iPhone Hackincrease your credit scoreText message interception hackemail interception hackIncrease blog trafficSkype hackBank accounts hackemail accounts hackWebsite crashed hackserver crashed hackRetrieval of lost file or documents *Credit cards hacker For more information contact their service team atEmail: THEDARKCRACKER AT protonmail DOT com