So there has been a lot of buzz around a topic that has been around for a short time.
Frame Sniffing
Now I want to quote the article that seem to start the phones and emails flowing across many companies. It was posted on the TechWeez website on Tuesday, and needless to say the 3,176 people Linking it via Facebook, and the 5,047 twitter views says, HOT TOPIC.
Now this was advertised by Context Information Security and thanks guys for taking the time to create the video, and discussing how it is done.
“Using Framesniffing, it’s possible for a malicious webpage to run search queries for potentially sensitive terms on a SharePoint server and determine how many results are found for each query,” said Paul Stone
What is Frame sniffing?
A Frame sniffing attack or exploit, requires a user from within your domain to access a malicious webpage. This is a critical point…it requires not only the person to access the site, but stay on the site, and leave the site open on there computer during the attack. If they navigate away or close the browser the attack/exploit is over.
When the person is sitting on the page…looking at the kitty, girl, car, boat….whatever you used to get them to the site. They leverage a hidden HTML frame, on a backend page. It is used to load a target website inside the attacker’s malicious webpage to read information about the content and structure of the framed pages.
This then bypasses the browser security restrictions that are meant to prevent webpages directly reading the contents of third-party sites loaded in frames.
Now if you go watch the video by Context IS, you will see they use the URL of your organization’s Intranet SharePoint portal, I don’t know about you, but that is usually not known by many if any outside the organization. So I am not saying your Intranet is safe, if your URL is researchable, or guessable so be it. Also a good hacker can get it via Social Engineering, or many other tricks. Those pesky Black Hats. So don’t assume this is a protective measure, security thru obscurity is not security.
Why this is not just a SharePoint problem? (only)
This is a browser exploit…..not a SharePoint one. It just happens it can be used against SharePoint. So lets fix the issue so we don’t have to wait for the browser security patch. It leverages the x-frame functionality, so we can solve that.
This exploit/attack can be used on a variety of sites, LinkedIn for example, and many many others. It also is a potential risk for other Collaborative solutions (salesforce, druple, etc.) so they need to get on it.
Microsoft and was told: “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.”
So no fears fixed in the next version.
How to fix your SharePoint environment!
So you ask, how can we get this to stop. Three simple options:
ONE
Tell your users to stop visiting malicious sites….haha like that is going to happen.
TWO
OK, so you can either rely on a Browser fix, Firefox has already released an update to fix this…so go get it. If your users only use Firefox you are safe….seriously don’t trust that. This does effect ALL other browsers as of this post.
THREE
Or we can do a simple fix on your server and your SharePoint site is safe again…My approach, lets just fix it, and let our users do to us what they will.
DANGER…Read this before you start. Changing the setting will prevent SharePoint from being framed, it could potentially break SharePoint in some setups! Example: if another intranet application uses SharePoint via a frame. Be sure to test this change before putting it into production. This will effect your i-Framing, and Page View web part functionality. SO GO DO THIS IN TEST FIRST…if you apply this to Production without testing………..don’t call me or email complaining. I did not build your environment so I do not know what the result will be. If I did build it and you are a client…email me and I will do this for you.
This is all done in IIS, not SharePoint…stop blaming SharePoint.
Context have tested SharePoint 2007 and 2010 and found that in their default configuration, they are vulnerable to this attack.
The following steps describe how to add the custom header in IIS7. If you have IIS6 idea is transferable, but steps will be a little different.
The screenshots below use SharePoint as an example, but the instructions will work for any site:
Open IIS Manager
In the left pane navigate to the relevant web site
Select the Features View and double-click the HTTP Response Headers icon
Click the ‘Add…’ link in the right pane
Enter ‘X-Frame-Options’ in the name field and ‘SAMEORIGIN’ in the value field
If you are a visual person, Click the images to enlarge
Conclusion
So if you feel you are exposing data, or are worried about this now, do the above setting changes. You may or likely will have to make changes to some portals delivery via webparts and frames.
References
Now I did not go into all the deep dive of the issue, just how to stop the patient from bleeding to death. If you want to do more research, go to the Context IS blog or there many whitepapers and references. As for me I now have to call all my SharePoint buddies and tell them to go do this. Later.
Context IS Blog post about Framesniffing http://www.contextis.com/research/blog/framesniffing/