How hackers steal two-factor authentication codes from users in some exchanges...

Almost every month we read from news that hackers managed to steal funds from exchanges even though the exchange has all the common security measures implemented.

There is two known vulnerabilities that can be used to get the 2FA seeds.

OpenSSH vulnerability in Ubuntu

During install Ubuntu disables password-checking on local terminals. After install, the authentication module is not uninstalled or removed from PAM (Pluggable Authentication Module) configuration.

To get access to the server, the hacker tries list of usernames used by system daemons. Because normal shell login is not allowed with empty password, the hacker tries to upload public key to .ssh subdirectory of the home directory. Because each daemon has own PAM configuration, it is possible that one of them allows file transfers, or creating files with specific names, without invoking the shell specified in user database (/etc/password).

After the public key is uploaded, the hacker logs in to the server using matching private key and gains access to the file system. Because daemons must have access to most of the system critical files, and because some low-security daemons only restrict access to processes running on same host, it is only matter of time until the hacker can open the database containing 2FA seeds.

Using malicious browser extension

This method requires capturing all the traffic sent from forms created by the exchange... Hacker must have account on the exchange itself to know names of the form fields.

First step is to capture the password for the victim account. After that, the hacker waits for the user to attempt any action on the exchange that asks for the 2FA code for the second time... When this happens, the browser extension reads the DOM (document object model) of the page and intercepts the library that verifies the 2FA code... Because that verification needs the seed, the extension can grab it by injecting code right before the function sends the request to the server.

Most exchanges don't use client-side verification because it is safer to do the verification on server-side and send just the 2FA code using XMLHttpRequest (method for dynamically alter the page contents using data received from server).

When the 2FA code is verified on the exchange server, the clocks of all three devices (device running 2FA authenticator, device running the browser and device running the verification) must be within 30 second tolerance. Most devices are not that accurate if kept running for a long time, so resyncing clocks periodically is required for successful 2FA verification.

2FA verification in the browser only requires two devices to have clocks synchronized so there is less chance of failure.