UI Redressing against Facebook

In this post, I'm going to discuss a possible attack scenario, targeting the Facebook web application, that could lead to the reset of account passwords in an automated fashion exploiting a UI Redressing issue with the use of a cross-domain extraction technique.

UI Redressing bug, again

 

During my research, I discovered a Facebook's web resource that is not protected by the X-Frame-Options and that includes the fb_dtsg token, which is adopted as an anti-CSRF token (Figure 1). The following is the affected URL:
  • http://www.facebook.com/ajax/intl/language_dialog.php
Figure 1 - Facebook's web resource vulnerable to UI Redressing attacks.
The iframe-to-iframe extraction method can be applied here to extract fb_dtsg's value and, consequently, perform a series of Cross-Site Request Forgery attacks against the integrity of the victim's profile data.


The theory behind the Facebook profiles takeover

 

Facebook allows users to add a mobile number that, once certified, can be adopted as username in order to login or reset the account's password. Users can insert their mobile numbers via the Account Settings → Mobile → Add a phone → add your phone number options (Figure 2 and Figure 3): a confirmation code is therefore sent by Facebook's system to the user's mobile phone and it must be inserted (Figure 4) to complete the activation process.
Figure 2 - Users can add their mobile number via the "add your phone number here" link.
Figure 3 - Facebook's form used to add a mobile number.
Figure 4 - A confirmation code is sent to the user's mobile and must be entered to complete the process.

The main issue here is that no password is required to associate the mobile number to the user's profile. Because of this, an attacker may abuse the described UI Redressing vulnerability to steal the fb_dtsg token and register an arbitrary phone number. Despite this, the attacker still needs to insert the confirmation code in order to associate his mobile number. A bit of black magic helps here: the attacker can abuse an SMS to mail mobile application to automatically forward the Facebook text-message (SMS) to an attacker-controlled mail box, thus allowing an hypothetical exploit to fetch the code and complete the insertion process.

The exploit

 

A working Proof of Concept exploit has been developed in order to demonstrate the described attack. We have also shared the code with the Facebook security team. During my experiments, the Android application SMS2Mail has been adopted to forward the Facebook SMS (Figure 5) to the mail box (Figure 6).

Figure 5 - SMS with the Facebook's confirmation code that has been forwarded to the attacker's mail box.

Figure 6 - Facebook confirmation code forwarded to the attacker's mailbox.

The following steps summarize the exploitation phases:
  1. The exploit frames the vulnerable resource and allows the victim to play a fake game while performing the cross-domain content extraction;
  2. The fb_dtsg anti-CSRF token and the victim's user id are extracted. An HTTP request is forwarded to the Facebook application in order to emulate the attacker-controlled mobile number registration;
  3. An text-message (SMS), containing the confirmation code, is sent to the attacker mobile device. An SMS2Mail mobile application is installed on attacker's device and automatically forwards the SMS to an attacker-controlled mail box;
  4. The exploit waits for the SMS to be forwarded to the mail box, then extracts the confirmation code and performs a second CSRF attack in order to submit the code itself and complete the mobile number registration.

The attacker's mobile number is now associated with the victim's profile and can be used to reset the account's password. As a matter of fact, Facebook allows users to enter a previously associated mobile number (Figure 7) which is then used to send a reset code (Figure 8).

Figure 7 - Reset password mechanism involving the user's mobile number .
Figure 8 - Facebook's form used to insert the resetting code.
A fully automated Proof of Concept exploit can be downloaded here, while the following video illustrates the described attack:

2 comments:

  steve

March 19, 2013 at 1:58 PM

Could you expand upon which browsers are vulnerable to this "iframe-to-iframe extraction" vulnerability, and have those vendors provided you with a timeline for a patch?

  Luca De Fulgentis

March 20, 2013 at 11:51 AM

Steve,

the iframe-to-iframe extraction method has been developed to perform cross-domain extraction on Mozilla Firefox browser. The vulnerability has been reported to Mozilla as detailed here: https://bugzilla.mozilla.org/show_bug.cgi?id=822215