:::Innovative Security Insights:::

Using Malware to Nullifying the ‘2’ of 2FA (Google Accounts)

The purposed of a 2FA system is to protect the user’s account from being stolen/accessed when logging in from a computer which may have been compromised (It works because the the attacker doesn’t have the 2FA token to login).

The following article details a possibility of how a malware can make use of certain functions provided to give an attacker persistent access to a Google account without the use of the 2FA (even after the session has ended). Also included in the article are recommendations which would protect against such an attack.

Note: For this to be possible, it will require one login on a compromised computer.

Note: This vulnerability has not been patched (as of 29/06/11). No feedback has been received by Google.

As usual, the article will be broken down into 4 sections:

I. The Infection
II. The Vulnerability
III. Make it Malicious!
IV. Recommendations

I. The Infection

The scope here is a login on a compromised computer. Therefore, for a start, let us a look at the infection. In this case, the functions of a malware required would be:

  1. Keylogger – This will allow the malware to obtain the user’s password
  2. Man in the browser – The malware will use this to perform queries without the user’s knowledge

II. The Vulnerability

The 2FA solution that Google provides comes with an option to authenticate an external device or application. How this works is that Google provides a specific password for the application which can be used on a third party email or instant messaging application. This provides the convenience of logging in without the use of a token. Thus, the main goal is to request and obtain an application password, which will allow us to access the Google account without the possession or control of the 2FA token from another system.

Thankfully, Google has a security mechanism against that. They require the entering of the password in order to go to the application password request page. However, given the knowledge and capability of the malware (as detailed in Section I), this safeguard can easily be bypassed. Thereafter, the attacker can use the requested application password to login without the use of the 2FA token.

As highlighted, we can see that through obtaining this password, we can gain access to the account indefinitely, unless the user revokes the password. However, there are several considerations:

  1. A user will not frequent the application password request page once his applications are locked in
  2. Google does not send you an e-mail/text message when a new application has been authorized
  3. In the case of infection, man-in-the-browser can hide the evidence of a breach

III. Make it Malicious!

Weaponizing the exploit in a malware:

  1. Detect user login (Log user ID and password)
  2. After user logs in, use password retrieved to request password application)
  3. Send application user ID and password to the attacker
  4. The attacker is given access to the account without user knowledge

Although there is no weaponized exploit at the moment, there is a high possibility that such a function would be easily exploitable and integrated into exploit kits, especially with the leakage of Zeus source code.

IV. Recommendations

1. Use of token required for critical functions

The current implementation for critical functions (i.e. requesting application password) requires that the password to be re-entered. However, in the case of an infection, this password is regarded as known information to the attacker, giving access to important functions to the attacker. After all, it is the purpose of 2FA to offer protection against such malware attacks.

Therefore, in order to limit what an attacker can do with a session, it is necessary to require the token be used for such critical functions.

2. Inform the user when there is a new application added

Once a user approves his/her applications, it is highly unlikely that he/she will revisit the application password request page to check on the approved applications. Also, there is no indication to the user that an application password has been requested.

Therefore, through informing the user via Text Message (Phone), he/she would be aware if an unauthorized request has been made, and he/she can revoke the password immediately.


Do feel free to share and discuss your opinions and suggestions.


– Brandon


One response

  1. Pingback: Access Code « Jeinrev

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s