As Facebook’s popularity continues to rise, it is becoming an increasingly attractive target for security researchers and vulnerability disclosures.
Today, security researcher Ronen Zilberman publicly disclosed a new Cross-Site Request Forgery (CSRF) attack vector that uses an HTML image tag to steal a Facebook user’s information. According to Zilberman’s disclosure, the user needs only to load an infected page to launch the attack.
Zilberman first posted his discovery on Aug. 6, but is only today making the full disclosure on how the vulnerability works since the flaw has now been patched by Facebook.
Zilberman did not respond to request for comment by press time, but Facebook spokesman Simon Axten told InternetNews.com that a fix was pushed out for this bug on Monday, shortly after it was reported and before the details were made public.
“The information exposed was very limited and included only the user’s name, Facebook User ID, profile picture and list of friends,” Axten said. “User privacy settings were also respected (that is, if you had hidden certain information from Platform applications, that information was still inaccessible). We have no evidence that the bug was ever used for malicious purposes.”
Nevertheless, that Facebook accounts were compromised in the wild is noteworthy because the attack used a legitimate HTML tag to violate users’ privacy.
According to Zilberman’s disclosure, the attack simply involved the malicious HTML image tag residing on any site, including any blog or forum that permits the use of image tags even in the comments section.
“The attack elegantly ends with a valid image so the page renders normally, and the attacked user does not notice that anything peculiar has happened,” Zilberman said.
In a detailed blog post about how to exploit the flaw in Facebook, he explained that Facebook’s Automatic Authentication mechanism for user credentials when running a Facebook application is partially at fault.
“It turns out that a simple redirect from one page to another in the same application fools Facebook because the second request originates from a Facebook URL (the first request),” Zilberman blogged. “Therefore, the second request activates Automatic Authentication and personal info is sent.”
CSRF attacks work by tricking users into making third-party requests without realizing they’re doing it. In Zilberman’s example, that request also prompts the transmission of the user’s information to the attacker.
Zilberman added that in his view the action of the actual HTML image tag is part of the normal behavior of browsers and servers, and isn’t the root cause of the vulnerability. It’s an assessment shared by Graham Cluley, senior technology consultant at security vendor Sophos.
“It’s a really interesting vulnerability isn’t it?,” Cluley wrote in an e-mail to InternetNews.com. “I think the browser isn’t really doing anything wrong — it’s doing what it’s told to do — in this attack.”
CSRF attacks have previously hit big-name sites like Netflix and Google’s Gmail. Microsoft Internet Explorer, Mozilla Firefox and the Apache HTTP Web server are among the popular applications that have experienced CSRF vulnerabilities in the past.
Cluley laid the blame for the current CSRF issue on Facebook’s system, rather with Facebook itself.
“The problem is surely with Facebook’s internal systems and application API for not correctly ascertaining whether it was an internal user request or coming from the outside world,” Cluley said.
Though Zilberman noted that Facebook has plugged the specific CSRF hole that he described in detail, he suggested that other, similar holes may yet exist on Facebook and other sites.
That concern sounds plausible to Cluley.
“It is certainly possible that Zilberman is right and that other sites suffer from similar flaws,” he said. “Facebook’s competitors would be wise not to be feeling too smug about this incident, but instead asking themselves if they too could be vulnerable to these kind of attacks.”