Browser Event Hijacking

November 14, 2012

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.

23 Comments | Information Security, Web Applications | Permalink
Posted by Ben Toews

HTTP Pass the Hash with Python

November 12, 2012

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.

2 Comments | Information Security, Security Testing, Security Tools, Windows | Permalink
Posted by Ben Toews

Installing BBQSQL

August 12, 2012

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.

Leave a Comment » | Information Security | Permalink
Posted by Ben Toews

Repurposing Data…or, “You’re Going To Do WHAT?”

August 9, 2012

By Patrick Madden

Boston.com published an AP story that Google is implementing an opt-in beta test to include users’ email in search results. In other words, when a user is logged in at Gmail, performing a plain old Google search will turn up emails in addition to web pages. Privacy concerns have been flagged and noted, and the existence of matching emails will be presented using a collapsed control off to the side of the main results. But will this really do the job? Google searches are shoulder-surfed all the time, so simply disclosing even the existence of a matching email can potentially put people in hot water depending on the search terms.

Google’s beta is another instance in a disturbing trend to repurpose user data in ways that weren’t intended or anticipated when the users provided their data. As the AP article reminds us, Google had previously ventured into this territory with Google Buzz before running into legal challenges. Facebook regularly and unashamedly repurposed ancient postings, many of them ephemeral “status” updates, as users’ timelines that could be easily browsed, though it could be debated that this makes it more clear that the old posts do still exist.

In my AppSec work I regularly find “Insufficient Authorization” in sites and products I assess. These findings are generally relative to the app owner’s perspective and answer the question, “Can my user perform activities or access data in ways I don’t want?” When I look at repurposed user data, though, I see an exactly analogous situation but in the opposite direction…from the user perspective, the question becomes, “Can my service provider use my data in ways I don’t want?”

[The answer, of course, is in the terms of service wherein the providers claim rights to use and disseminate data provided to them, even if they don’t claim ownership of the actual data. Apparently, then, there’s no basis to complain about any of this, and Google, Facebook, and others will simply do what they want. That’s slightly pessimistic, but it’s not that far from what we’ve seen so far.]

When a finding of “Insufficient Authorization” appears to be the result of intended functionality, application owners are asked to review their business requirements versus the vulnerability, identify alternative means of meeting the business requirements, or reconsider the functionality altogether. On the other hand, ordinary end users are terrible at doing all of these, if they even care in the first place. Who can state their personal “business requirements” for social media and other free services, who has gone to the trouble of identifying the risks inherent in sharing personal data with third parties (and quantifying the risks? Pfft!), and who’s willing to reconsider the use of a service they’ve invested themselves in substantially, even though no payment was involved?

Repurposing of user data happens because a provider thinks they’ve found a way to make more money, and because one-sided terms of service make few concessions allowing users to control how their own data gets used. At the same time, that repurposing should never increase user risk exposure by default, at least not in my own personal utopia. Maybe we should all be looking for and flagging “Insufficient Authorization” findings from the user’s perspective. And if the Gmail feature goes live in production with no option to disable it, perhaps I can use separate email and search providers to segregate functionality and mitigate risk.

Leave a Comment » | Application Security, Information Security, Privacy | Permalink
Posted by maddenpat

Can’t Run Nessus off of Backtrack Live…No Problem!

August 8, 2012

By Scott Behrens (arbit)

We have all been there.  You boot up into Backtrack live, pull down and install Nessus and try to run a scan after installing plugins.  Your scan runs way too quickly and your report is nowhere to be found.  Being the Tux penguin that you are, you realize you have run out of ‘memory’ aka virtual hard drive space.  Your / partition shows to be 100% full and you frantically start deleting forensic software by the megabyte, but still haven’t created enough free space.  Maybe you should have picked a host that had more than 2 gigs of memory or just installed it to the desktop.  But you are on a client deadline, and you don’t have the time to get a new host or overwrite the base OS.

I have a very quick and simple fix.  This is by no means the most effective or slick way to alleviate this problem, but takes 2 commands and is very easy.

Read the rest of this entry »

Leave a Comment » | Information Security | Permalink
Posted by Scott Behrens

Defcon Post-Mortem

August 3, 2012

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.

2 Comments | Information Security | Permalink
Posted by Ben Toews

DLP Circumvention: A Demonstration of Futility

July 20, 2012

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

Leave a Comment » | Exploitation, Information Security, Security Tools | Permalink
Posted by Ben Toews

« Previous Entries
Follow

Get every new post delivered to your Inbox.