Framesniffing against SharePoint and LinkedIn

Paul Stone & Jacobo Ros - March 2012

In this blog post, I'll describe the Framesniffing technique and show how it can be used by a remote attacker to steal sensitive information from users through their web browser. I'll demonstrate how this attack can be used to mine information from documents stored in a corporate SharePoint installation. This blog post also contains a demo that shows how information can be extracted from a user’s LinkedIn account using the same technique. Finally, I’ll explain how to protect your site against this kind of attack.

The video below shows a fictional but realistic example of how this technique could be used to carry out corporate espionage:

blog-sharepoint-frameleak.mp4

The video shows an attacker extracting sensitive information (including client names) from a fictional corporate SharePoint installation. The attacker then searches the server to discover crucial information about upcoming acquisition. To achieve this, the attacker first lures a user with access to the SharePoint server to a malicious web page. While the user is viewing the page, the attacker uses Framesniffing to infer information from the SharePoint server through their web browser.

The Framesniffing Attack

The Framesniffing technique uses an HTML IFRAME to load a target website inside of an attacker's webpage. All web browsers have security restrictions that prevent a webpage from directly reading the contents of pages loaded in frames. However, this attack bypasses those measures, allowing a malicious webpage to read certain pieces of information about the structure of a framed page, by using anchor elements. Before I describe the attack itself, here's a quick explanation of how anchors work.

How a web browser scrolls to an anchor

Anchor elements are traditionally used to navigate within a webpage. They are often used on long pages to navigate from an item in a contents table to a section further down a page. You can see how anchors work by visiting this example page:

    www.wikipedia.org/wiki/Web_browser#History

In this link, the #History part at the end is the anchor. It is used by the web browser to scroll to a particular point on the page. The web browser will look for any HTML element with an ID attribute set to "History" (or an anchor element with name="History") and scroll to it. Modern web pages will often have dozens of elements with IDs set, even if they're not being used as anchors.

Most importantly, if the anchor in the URL isn't found then the browser won't scroll the page at all. It's this scrolling-or-not-scrolling behaviour that the Framesniffing attack uses in order to read information. A malicious webpage can load a URL into a hidden frame with a particular anchor on the end, and check whether an element matching that anchor exists on the target webpage. If the anchor is present, the frame will scroll; if it's not then the frame won't scroll [1].

So why is this actually useful? Imagine an attacker wants to check whether a user is logged onto a particular website, example.com. If the user is not logged into the site, the front page will contain a login form like this:

     <form id="login"> <input name="username">…

If the user is logged in, then the login form won't be present. To do the login check, the attacker's web page can then load the following URL in a hidden frame:

http://www.example.com/#login

If the frame scrolls down when the page loads, then the attacker knows that the user is logged into example.com. Since this check is quick to do, the attacker's page could check hundreds of sites to build up a profile of which sites the user is logged into. The technique isn’t limited to doing login checks; all sorts of information can be inferred from anchor IDs, as you’ll see in the rest of this post.

Mozilla updated their Firefox web browser last year to prevent Framesniffing attacks (https://bugzilla.mozilla.org/show_bug.cgi?id=583889), however the latest versions of Internet Explorer, Chrome and Safari are still vulnerable to these attacks. We also tested a number of mobile browsers and found the default web browsers on iOS 5, Android 2.3 and Blackberry OS 6 to be vulnerable.

SharePoint Data Mining

By default, SharePoint 2007 and 2010 do not send the X-Frame-Options header. This means that any website that knows the URL of your organisation's SharePoint installation can load it in a frame (even if SharePoint is only accessible on your internal network, since it's loading in your browser). This attack works by checking for anchors on search result pages.

The following URL will run a search for 'Acme' on a fictional SharePoint server:

    http://sp2010/searchcenter/Pages/Results.aspx?k=Acme

The results page shows the first 10 results and indicates that there are three more pages of results. How about searching for something that doesn't exist in the document repository?

    http://sp2010/searchcenter/Pages/Results.aspx?k=rAnD0m456

This time there's a message indicating that there are no results. See the below screenshots for examples of these results pages:

    

SharePoint 2010 results pages - click to enlarge

Now let's look at the element IDs found on these pages:

  

Anchors on SharePoint results pages - 4 pages of result on the left, no results on the right

Depending on how many pages of results are returned, the anchors SRP_P2, SRP_P3 and so on will be on the page. If no results are found, then the anchor CSR_NO_RESULTS will be present. If only one page of results is returned, none of these anchors will be on the page.

Using Framesniffing, it's possible for a malicious web page to run search queries on a SharePoint server and determine how many results are found for each hit. While it's not possible for a malicious page to directly read the search results using this attack, a lot of information can be gleaned by searching a SharePoint repository for sensitive terms and counting the number of results returned.

Imagine an attacker wants to discover whether GarCorp, FooCorp and RadCorp are clients of BigCorp. The attacker knows that the SharePoint server runs on BigCorp's internal intranet at http://sp2010/, but can't access it directly. There are various ways that someone could discover the URL of an organisation’s internal SharePoint server. For example, Microsoft Office will embed the server’s URL in a document when it is ‘checked out’ for editing. If the document is then emailed or published then the URL can be easily discovered by the recipients.

The attacker might carry out the following steps to find this information:

  1. The attacker sends an email to a BigCorp employee with a link to his malicious webpage.
  2. The employee visits the webpage from inside the BigCorp intranet. The page itself is promotional material for a fictional company invented by the attacker.
  3. The malicious page loads the following SharePoint URLs in hidden frames:
    http://sp2010/searchcenter/Pages/Results.aspx?k=GarCorp
    http://sp2010/searchcenter/Pages/Results.aspx?k=FooCorp
    http://sp2010/searchcenter/Pages/Results.aspx?k=RadCorp
  4. The malicious page uses the Framesniffing to check the loaded pages for the IDs mentioned above. The results are as follows:
  5. Anchor'GarCorp' Query'FooCorp' Query‘RadCorp’ Query
    CSR_NO_RESULTS
    SRP_P2
    SRP_P3
    SRP_P4
    SRP_P5
  6. After a few seconds, the BigCorp employee closes the webpage.

From the above results, the attacker can see that ‘GarCorp’ didn’t have any search results so likely doesn’t have a relationship with BigCorp. For the ‘FooCorp’ query none of the anchors were on the results page which tells us that there was a single page of results (10 or fewer results). This suggests that FooCorp might be mentioned a few times a handful of documents, but probably isn’t a client. Lastly, RadCorp has 5 pages of results (at least 50 hits) which suggests a strong relationship with BigCorp. In this example, only 3 searches were done. However, the attacker could have searched for dozens of company names in a matter of 2-3 seconds.

Using this knowledge as a starting point, the attacker could then go on to perform more complex searches around RadCorp. SharePoint 2010 supports search operators such as AND, OR and NEAR (http://msdn.microsoft.com/en-us/library/ee872310.aspx). NEAR is a particularly useful tool – it will match words that are in close proximity to each other without having to search for an exact phrase. So the attacker could search for terms like "RadCorp NEAR buyout", "acquisition NEAR RadCorp" or RadCorp NEAR litigation" in order to gain some knowledge about specific details within documents.

What if a keyword-based search doesn’t give an attacker any useful results? In that case, a blind search using wildcards is possible.

SharePoint supports wildcard searches in some fields, such as author, filename and document title. For example, a search for filename:a* will return a list of files beginning with ‘A’. A blind search would start by performing searches for a*, b*, c* and so on, to find if there are files that start with those letters. It would then go on to search for an*, at*, as*... until a set of complete words had been build up. Although this may take a few thousand queries, it can be done fully automatically in 5-10 minutes depending on the speed of the browser, network connection and the SharePoint server being queried. An attack like this could be used to discover things like client names or product codenames, even with no prior information about the contents of the server.

LinkedIn Information Leak

Many public websites don’t protect against framing and are therefore vulnerable to Framesniffing. One example is LinkedIn. We’ve created a small demo that shows how information can be extracted from your LinkedIn profile, if you're currently logged into the site.

Run the Demo

Anchors on LinkedIn

The contacts search page on LinkedIn (shown right) allows filtering contacts by location, industry, company and so on. Each filter tick box has an ID that can be used as an anchor. For example the industry tick boxes have IDs like ‘118-I-fps’. Each industry has a different ID – 118 in this case is ‘Computer & Network Security’.

Our demo works by first loading the contacts search page into a hidden frame. It then changes the anchor at the end of the frame’s URL to #1-I-fps, then #2-I-fps and so on – one for each industry ID. Each time the anchor is changed, our code checks to see if the frame has scrolled. If it has scrolled then the anchor is present on the page, which indicates that the user has contacts in the corresponding industry. All of these checks are very quick to do because the page is only loaded once. Since only the anchor part of the URL is changing, the browser will not reload the page from the server.

Our demo only extracts and displays information about the industries and countries that a user has contacts in. That information is never sent to Context or anywhere else, but an attacker could silently collect this data without the user’s knowledge. Furthermore, the LinkedIn search page contains other anchors that could allow specific companies, contacts, and even the identity of the user themselves to be found.

We informed LinkedIn about this issue (via their security@linkedin.com address) on 29th February. At the time of writing Context had still not received a response from LinkedIn.

Many other websites are vulnerable to this kind of attack. A malicious website could build up a profile of a user by piecing together small pieces of information leaked from various websites. For example, the product IDs of previously bought items from a shopping site could be combined with a person’s user ID from a social networking site.

Protecting against Framesniffing

Similarly to Clickjacking, Framesniffing won't work if the target website has framing protection. Websites can protect themselves against both attacks by sending the X-Frame-Options HTTP header.

Context have tested SharePoint 2007 and 2010 and found that in their default configuration, they are vulnerable to this attack. We contacted Microsoft about the vulnerability, and they gave us the following response:

   "We have concluded our investigation and determined that this is by-design in current versions of SharePoint. We are working to set the X-Frame options in the next version of SharePoint"

Fortunately, protecting a website from this attack is a simple matter of adding the X-Frame-Options header.

The following steps describe how to add the custom header in IIS7. The screenshots use SharePoint as an example, but the instructions will work for any site:

  1. Open IIS Manager
  2. In the left pane navigate to the relevant web site
  3. Select the Features View and double-click the HTTP Response Headers icon
  4. Click the ‘Add...’ link in the right pane
  5. Enter ‘X-Frame-Options’ in the name field and ‘SAMEORIGIN’ in the value field
    

Configuring IIS - Click to enlarge

Note that because this setting will prevent SharePoint from being framed, it could potentially break SharePoint in some setups – for example if another intranet application uses SharePoint via a frame. Be sure to test this change before putting it into production.

Browser Protection against Framesniffing Attacks

As previously mentioned, users of the Firefox browser are already protected against this attack. We would encourage other browser vendors to apply similar protection to their browsers. In the mean time, the onus is on individual websites to add framing protection via X-Frame-Options.

References

[1] - If you're interested in the gory details of how the scroll detection works, see pages 15-16 in my Clickjacking Whitepaper. Also see [Berszstein et al, p18], a great paper that has some interesting examples of the technique. Thanks also go to my colleague Chris ‘alertbox’ Wallis for coining the term ‘Framesniffing’.

http://www.contextis.com/research/white-papers/clickjacking-black-hat-2010/
http://media.blackhat.com/bh-us-10/whitepapers/Bursztein_Gourdin_Rydstedt/BlackHat-USA-2010-Bursztein-Bad-Memories-wp.pdf (page 18)
https://bugzilla.mozilla.org/show_bug.cgi?id=583889


© Copyright 2013 Context Information Security