Write-up: Session hijacking in the Skype client via Facebook integration

Archived article from 29 July 2011. Its content reflects the state of things at the time. Reconstructed from the web archive of secalert.net - view the original.

Summary. A Facebook integration added to the Skype Windows client rendered content pulled from Facebook wall posts and comments inside the client without sanitizing it. A crafted wall comment was parsed and executed in the context of the Skype client when a contact's feed was displayed, which made it a stored, persistent issue. Because the client's webview carried authenticated session state, script running in that context could read and exfiltrate it, hijacking the victim's Skype session with no interaction beyond viewing the feed.

Background

Skype released an update to its Windows client that integrated Facebook: users could now post comments, share links with Facebook friends, and see Facebook status updates directly inside the Skype client. Shortly after the feature shipped, I looked at how the integration handled data coming back from Facebook.

Root cause

The client did not sanitize content pulled from a Facebook wall post or comment before rendering it inside the Skype UI. A Facebook wall comment containing a crafted payload was parsed and executed in the context of the Skype client when a contact's feed was displayed, making it a stored, persistent issue. The victim did not need to be a Facebook friend or Skype contact of the attacker for the payload to reach them.

Impact

Because the Skype client sets session cookies for its own authenticated requests, a script running inside the client's context could read and exfiltrate that session data, effectively hijacking the victim's Skype session without any interaction beyond viewing the affected feed.

A broader pattern

A closely related pattern showed up independently a few days later in the ICQ 7.5 Windows client, found and published by Levent "Noptrix" Kayan: both clients ran their embedded web content with localhost as the effective origin, which meant script running in that context could also read local files such as /etc/passwd or /etc/hosts and reach other local services. It illustrated that the risk wasn't specific to Skype's Facebook feature, but to the general pattern of IM clients rendering untrusted, externally-sourced content inside a locally-privileged webview.

Remediation

Treat anything fetched from an external service as untrusted and encode or sanitize it for the exact context it is rendered in, rather than injecting it into the client's markup as-is. Embedded web content should never run with a locally-privileged origin such as localhost, so that a stored payload cannot reach local files or services even if sanitization fails.

Press coverage