Practical Clickjacking with BeEF

Transcription

1 Practical Clickjacking with BeEF Brigette Lundeen Center for Secure and Dependable Systems University of Idaho Dr. Jim Alves-Foss Center for Secure and Dependable Systems University of Idaho Abstract - A lot of effort has been put into researching client-side attacks, including vulnerabilities like cross-site scripting, cross-site request forgery, and more recently, clickjacking. Similar to other client-side attacks, a clickjacking vulnerability can use the browser to exploit weaknesses in cross domain isolation and the same origin policy. It does this by tricking the user to click on something that is actually not what the user perceives they are clicking on. In the most extreme cases, this vulnerability can cause an unsuspecting user to have their account compromised with a single click. Although there are protections available for clickjacking, the web applications implementing these mitigations are far and in between. Additionally, although the possibility for an attacker to frame a page is easy to detect, it is much more difficult to demonstrate or assess the impact of a clickjacking vulnerability than more traditional client-side vectors. Tools do not currently exist to reliably demonstrate clickjacking exploitation, and the rare demonstrations that are done typically use custom JavaScript and HTML for each individual vulnerability. Worse, many times this esoteric code is never made public, leaving everyone to rewrite their own from scratch. BeEF, known as the Browser Exploitation Framework, is a tool designed to help professional penetration testers easily demonstrate the impact of client-side security vulnerabilities. In this paper, we present a plugin module for BeEF which provides a way for penetration testers to easily demonstrate the impact of clickjacking vulnerabilities. Keywords-component; formatting; style; styling; insert (key words) I. INTRODUCTION A. Clickjacking Clickjacking happens when a user intends to click on something, but through an invisible or opaque iframe the user actually clicks on something else. A clickjacked page is a visible webpage that includes a reference to another, invisible iframed webpage. The user clicks on a link on the invisible iframed webpage that performs some unintended action while the user thinks they just clicked on the visible page. An attacker only needs some of the basic features of HTML, CSS, and possibly JavaScript to craft an attack. Figure 1 is based on a figure from a famous clickjacking paper [1] and accurately shows how a clickjacking attack occurs. The user visits an online lottery sweepstakes website to play the lottery and try to win the grand prize. The user thinks they are clicking on the link to play the lottery sweepstakes, but in fact they are clicking on the invisible amazon iframed page. Figure 1. Clickjacking example. B. Clickjacking protections Currently, the accepted mitigation to a clickjacking vulnerability is to not allow your webpage to be framed. There are 2 primary ways to disallow framing a webpage. The first and most widely implemented is done with JavaScript and is known as frame-busting. if(top!= self) { top.location = self.location; (1) The JavaScript from (1) tells the browser to check and see if this webpage is the top-level page. If not, the browser will make the framed page the top-level page. This is just one example of frame-busting JavaScript. There are many different implementations, but they usually all have the same idea. First, do a conditional check to see if the page is the top-level page. If not, some action is performed, such as redirecting the request or displaying an error page. However, JavaScript was never intended as a method of preventing framing, and all implementations are inherently hacked together. In Internet Explorer 8, Microsoft included a new approach to prevent unintended framing. Microsoft s latest Software Development Lifecycle documentation says to include the HTTP response header named X-FRAME- OPTIONS in each authenticated page. [2] By adding the X- FRAME-OPTIONS header you can prevent your page from being framed or just allow it to be framed by other pages with the same origin. All of the latest browsers have included /12/$ IEEE 614

2 varying levels of support for X-FRAME-OPTIONS, including all latest versions of Chrome, Safari, and Firefox. C. Protections don t always work Frame-busting scripts rely on JavaScript executing on the framed page. This is a function scripts were never intended to perform. If an attacker disables or modifies the JavaScript then the resulting code may have unintended consequences and it may be possible to frame a page. Two examples that attackers can use to disable script are the security and sandbox attributes. Microsoft created a security attribute to restrict what framed webpages could do. The security=restricted iframe attribute signals to the browser to use the restricted internet zone security settings for the framed content. By default in Internet Explorer, the restricted zone does not allow scripts to run, sometimes breaking the logic of a frame buster script. HTML5 has proposed a better implementation for creating a restricted iframe environment, but with respect to frame busting scripts the results are similar. The intent of the sandbox iframe attribute is to provide added security by enabling a set of restrictions on the contents of an iframe. Simply sandbox attribute prevents any frame-busting scripts or any other scripts of the framed webpage from running. The sandbox attribute allows iframe restriction granularity. For example, the sandbox attribute by itself blocks any form submission. However, if you want the framed webpage to allow forms to post while still restricting the execution of scripts, the appropriate attribute is sandbox=allowforms. The attribute is still part of a working draft [3] and currently only supported in Chrome and Safari. Between security=restricted and sandbox attributes, it is trivial to prevent frame-busting code from executing in most common browsers, which is frequently all that is needed to bypass a frame busting script. X-FRAME-OPTIONS header is the most reliable way to prevent unwanted framing as long as it is supported by the client browser. While it is supported across all the latest browsers, it isn t supported in several browsers that are still popular at the time of this writing, such as Internet Explorer 7 and Firefox 3.6. There still exist a staggering number of people using older Internet Explorer browsers. As of March 2012, IE6/7 has a combined user count of 4.7% [4]. The X-FRAME-OPTIONS header has three options, Deny Same Origin, or Allow-From. Allow-From tells the browser to block if the origin of the top-level origin is different than the origin specified. The other hurdle with X-FRAME-OPTIONS is that it is just now getting support in many of the popular programming languages. Lastly, it is important to note that there are legitimate reasons a webpage would need the ability to be framed. For example, the Facebook Like button is added to a webpage by including an iframe. If Facebook didn t allow framing on their pages, then the Like button as an iframe wouldn t work. This design logic has been used countless time for clickjacking attacks. It has become so popular it has its own name, likejacking. As long as scenarios exist that require the ability to allow framing webpages, clickjacking attacks will exist. II. EXISTING TOOLS Since Clickjacking was first popularized in 2008, there have been other code snippets and tools that were built for the purpose of helping security professionals perform simulated clickjacking attacks. While some of these tools have had some great components, each has failed to provide a full-scale approach for developing a real-life clickjacking attack. A. CJTool In 2010, Paul Stone created a promising tool to help craft clickjacking attacks [5]. Simply opening a local webpage in your browser and following the steps, someone was visually able to craft a clickjacking attack with simple drag-and-drop and point-and-click techniques. The tool has a slick UI to help even the most novice security professionals craft an attack. The tool supports some more advanced features of clickjacking including support for text extraction and injection. Stone s tool has not gone through any serious updates or revisions to keep the code base up-to-date. Cjtool is a standalone tool and therefore doesn t get the same use and support as other security tools. Its sole purpose is clickjacking and because of this it doesn t receive the same kind of attention as many other more generic security tools that aid in multiple attack vectors. Since the code is not actively maintained, many of the features and general functionality does not work in current browsers. The only major browser that is currently still functional without modifying code at the time of this writing is Firefox. Even with browsers where cjtool is supported, it is difficult to show realistic proof of concepts. Cjtool was not built for easy extensibility. For example, assume you want to chain two attack vectors by using clickjacking to perform an XSS attack. To do this, you will need to modify the current logic of the tool (which is no easy task). Since cjtool isn t actively maintained, isn t supported by many browsers, and difficult to extend, someone trying to craft a clickjacking proof of concept will most likely find themselves writing their own JavaScript from scratch. Cjtool performs the attack in a frame on the same page. There is a left frame and top frame to the page that always remains visible, even when you set the attack to be invisible. This user-interface flaw greatly limits the use of the tool. A professional wanting to simulate a real-life attack must go into the code and manually edit the CSS to remove the top and left frames from view and reposition the attack frame. This requires the security professional to possess some advanced CSS knowledge. Stone created a promising tool that has a nice design and components. However, due to lack of support the tool is becoming increasing irrelevant. To have a successful tool that the security community can utilize time-and-time again the tool must be easily configurable, maintained and updated regularly, and easily extendable for chaining multiple attacks and preparing for future innovations. 615

3 containing div around the iframe and an input element to detect when a click occurrs. The difficult part was the CSS to get the attack to work. The input element used to detect the click is hidden from view. It is simply there to get and lose focus. There is no way to determine if the iframe is clicked from the parent page. So the way to detect a click is to give the hidden button focus. When the button loses focus, an assumption is made that the iframe was clicked. Simply setting the button style to display:none or giving it width=0;height=0 doesn t work because the element was unable to have focus. The styles to allow the button to perform its intended purpose and also to not appear on the page are the following: Figure 2. Cjtool contains a top and left frame for configuring the attack. The blue-shaded frame is where the attack actually happens. B. BeEF One-off tools just don t work in the real world. The problem is they are developed for one purpose. They may perform that one task well, but each time a new situation arises the code will need to be repurposed and implemented to serve the next new one-off. This is why generic tools have gained popularity and have more long-term success than standalone tools. For example, consider Metasploit and the popularity it has gained due to the fact that it is open-source and it can be extended with new modules. There is also a community that maintains Metasploit and ensures the continued integrity of the modules it accepts into its code base. The Browser Exploitation Framework, or BeEF, is a penetration testing tool that focuses on the web browser [6]. BeEF was built to demonstrate cross-site scripting issues in the browser, and has evolved to include practical implementations of many client side attack vectors. BeEF has an active community supporting it the developers release updates and new features monthly. BeEF is free, open-source, and a popular tool in the web security world. Integrating the clickjacking tool into BeEF is a good way to distribute the tool to a lot of security professionals who would find it most useful. Contributing to BeEF is a relatively easy process since it is a modular framework. The underlying framework is flexible, so adding my code as a module makes a lot of the pre-existing features of BeEF available; therefore, decreasing some of the development time. By having a solid framework with a variety of modules, this will also make it easier to chain attacks. For example, you could use cross-site scripting and clickjacking to perform an advanced attack. III. INTRODUCING AN EXTENSIBLE CLICKJACKING MODULE FOR BEEF Before beginning any integration with the BeEF framework, a standalone tool was first built to handle a specific clickjacking vulnerability. The number of HTML elements used for the attack was kept to a minimum, because in the BeEF framework all these elements would need to be injected into the attack page. To perform the attack, there are really only three basic HTML elements you need, the iframe, the #persistentbtn{ width:1px; height:1px; opacity:0; filter:alpha(opacity=0) The iframe element needs to be really big to include the entire page. The user defined values for the top and left pixels of the desired clickable element are added to CSS as negative values to shift the iframed element to the top, left corner of the containing div. The containing div has to be small, really small to allow the JavaScript that performs the following the mouse event to work properly. It is just meant to show the element of the iframed page and just enough of the element to allow the user to click it. The opacity is assigned dynamically depending on if the user wants the attack to be visible or not. The CSS for the iframe and container div look like the following: div{ position:absolute; z-index:100000; overflow:hidden; width:16px; height:16px; opacity:0; filter:alpha(opacity:0) iframe{ border:none; position:absolute; width:2000px; height:10000px; top:-10px; left:-120px; 616

4 A BeEF configurations Figure 3. BeEF clickjacking module configuration page. Above is a screenshot of the BeEF clickjacking module configuration page. This page shows all the configuration options available with the tool. The first four options are all about setting up the iframe element. The iframe Src field is for the URL of the page you want iframed on the clickjacked page. The next two checkbox fields can allow the attack to bypass JavaScript frame-busting scripts of the iframed page. Refer to 1.3 for a detailed explanation of the security=restricted and sandbox fields. By default, there is a sandbox attribute set to allow form submission. The above configurations will produce an iframe element (minus some style configurations) that looks like the following: page, some of the custom JavaScript a user may want to execute is to force a click event on the element on the clickjacked page the user believes they are interacting with. This might be necessary so that the user does not get suspicious or irritated and leave the clickjacked page. There can be an unlimited amount of custom JavaScript. The last thing of importance to realize is that all the clickjacking elements, including the iframe, are removed from the page when the attack is complete. So after the second click, all traces of the attack will be gone from the document object model of the clickjacked page. Therefore, the user is free to interact with the page like normal. The best way to explain how the tool works is to show it in action. B. The Victim Assume a user finds a webpage that has some funny quotes, but to get to the page the user must click on a disclaimer. Internet users see this all the time. Many websites have redirect pages, splash pages, and ad pop-ups the user must click on to either close the webpage or just to continue interacting on the webpage. This is not a phenomenon that only occurs on questionable websites. There are plenty of legitimate websites that have this same functionality, such as forbes.com, theonion.com, and whitehouse.gov. Most internet users will click the button to continue using the website without much thought. How much harm can one click cause?! In this scenario, the user clicks the link Okay to read the funny quotes. <iframe src=" security= "restricted" sandbox= "allow-forms"></iframe> The remaining pieces of the configuration page are all related to the clicks. The iframed page needs to know where on the iframed page the user needs to click. The way to do this is by specifying an X-pos and Y-pos on the configuration page to indicate where on the iframed the element is located. These values can be specified for each sequential click. If left as the default 0 for the subsequent clicks, the iframe position will remain the same. There are two ways to setup a clickjacking attack. 1) If you know exactly where a user will click on the page, then you can simply maneuver the iframed page so that part of the page is directly over the place the user thinks they are clicking. 2) Via JavaScript, make the iframed page follow the mouse as the user moves it around the page. Therefore, when the user clicks regardless of where on the page they will always click on the hidden iframe. This tool uses option 2, because it will work 100% of the time. Any specific JavaScript an attacker wants to execute when the user performs a click event must be specified on the module configuration page. This can be different for each click. Since the user is unknowingly interacting with the invisible iframed Figure 4. Attack page s first screen The user continues to use the webpage clicking through the random quotes and guessing who said it. 617

5 the Chrome browser; however, it can also be done with other browsers. If the attack was being performed on an Internet Explorer browser, the security zone iframe attribute would need to be unchecked. Figure 5. Attack page after the click-thru screen. The webpage seems pretty harmless the user visited, clicked, and had a few good laughs. What they don t realize is that while interacting with a seemingly harmless webpage using BeEF and the clickjacking module, the user actually Liked a completely different webpage on their Facebook account. C. The Attack To see the attack unfold on the page, the iframe will need to be visible. This time the attack is made visible by checking the Show Attack checkbox on the BeEF clickjacking module s configuration page. Figure 7. Attack page with visible Facebook Like button iframe. Since the attack is visible, it is obvious to see that clicking on the Okay link actually is clicking on the Facebook Like button of some other page. This particular Like button is present on an onion.com page. Since the click will actually cause the logged in user to Like the Onion news page, custom JavaScript needed to be added to the configuration page to manually close the overlay. So the first click actually does 2 things: 1) The user performs a Like of the Onion page and 2) through custom JavaScript from the BeEF configuration page the click-thru overlay is closed. Figure 6. Configuration for attack with a visible iframe. For this particular attack, the sandbox iframe attribute must be unchecked. Remember that Facebook doesn t have frame-busting code for their Like button. The design logic allows the Facebook Like button to be iframed. In fact, including the sandbox attribute will prevent this attack from working because Facebook is using JavaScript to perform the Like action. This particular attack is being propagated through Figure 8. Attack page with visible Facebook Like button iframe that has already been clicked. 618

6 The BeEF configuration page is setup for two clicks. This attack only requires one click. After the second click, all the HTML elements on the page that were added for the clickjacking attack are removed. The user will interact with the page like normal and will likely not realize anything happened, unless they notice the new Like on their Facebook profile page. to chain attacks. Using BeEF, an attacker can setup an attack using an XSS module and then use the clickjacking module. The ability to use any module in conjunction with another is invaluable. However, as outlined above, there are a few limitations that need to be improved upon to reap the full benefits. IV. FUTURE WORK Clickjacking is such a different type of attack that it might be best served as its own page within BeEF. All BeEF modules follow a strict standard and have certain functionality restrictions. Clickjacking works as a module, but due to the nature of a clickjacking attack having it as a separate page within BeEF may allow more extensibility. The entire attack could be setup on its own page, similar to Stone s cjtool, and other modules could be used within the Clickjacking context. However, this is something we will leave up to the discretion of the BeEF moderators. At the time of writing this, this module has not been included in the BeEF project. However, a pull request has been made and to the BeEF project [8]. Figure 9. Facebook Timeline with the Liked Onion page showing. D. Limitations Performing a clickjacking attack requires the attacker to know the exact location of what they want clicked. This can be difficult to calculate with some webpages depending on how the page is setup. However, in most cases this is easy enough to do. There are plugins and external tools that will aid in measuring the pixels on a webpage. For example, in Firefox there is a free plugin called MeasureIt [7] that allows you to easily measure the pixels from the top and left of the window to the element of interest. This clickjacking module allows you to view the attack by making the iframe visible. Making it visible shows in real-time what is happening, however, the viewable area is small. It needs to be small for the JavaScript to work properly when following the mouse around. The visible feature shows the iframed element the user will click on, but it isn t a large enough area to see the surrounding elements of the iframed page during the attack. Making it so the entire iframed page is visible during the visible attack would require a lot more fancy CSS, JS and many more HTML elements. This would create bloat to the page. There are lots of benefits of using BeEF for this clickjacking module, but one of the nicest features is the ability V. ACKNOWLEDGEMENTS We want to extend a special thanks to, Richard Lundeen. His security expertise is what inspired this tool and his geekiness inspires every day. We also want to thank the entire BeEF team for developing and supporting an invaluable piece of security software. Also for writing it in a way that we could delve into the unknown world of Ruby and somehow come out unscathed. VI. REFERENCES [1] G. Rydstedt, E. Bursztein, D. Boneh, C. Jackson, Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites, June 17, [2] SDL Process Guidance Version 5.1, Microsoft, April 14, [3] W3C Working Draft, section 4.8.2, March 29, 2012, [4] StatCounter Global Stats: Top 12 Browser Versions on Feb 2012, [5] P. Stone, Clickjacking Tool, Blackhat [6] BeEF: The Browser Exploitation Framework Project, [7] K. Freitas, MeasureIt, US/firefox/addon/measureit/. [8] 619