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

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.

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.

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.

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.

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.

After pulling down the Nessus binary and installing, do not navigate to the webpage to start the process of updating plugins, instead run the following command:

mv /opt/nessus/var/nessus /dev

ln -s /dev/nessus /opt/nessus/var

Now log into the web interface, provide your registration information, and update the plugin set.  You should now have enough hard drive space to run the scans.  This creates a softlink to the /dev partition for the huge database files that Nessus uses.  /dev has much more free space than / does, hence the fix.

I haven’t looked into great detail on why the /dev filesystem is allocated the way it is (1.2G free before Nessus install), and there may be a way to change this on boot.  Recently I had a client who wasn’t very familiar with Linux operating systems boot into backtrack for me and I therefore did not have console access.   I know /dev/ should never be used to store user files, but in a crunch this can save you some time.

If you have an even easier solution, leave a comment!

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

In the last few years, security breaches of signed SSL certificates, as well as a number of certificate authorities (CA’s) themselves, have illustrated gaps in the foundations of online security.

• Diginotar
• Comodo
• Verisign
• others

It is no longer safe to assume that CA’s, large or small, have sufficient stake in their reputation to invest in security that is 100% effective.  In other words, it’s time to start assuming that CA’s can and will be breached again.

Fortunately for the white hats out there, NIST has just released a bulletin on responding to CA breaches.  Find it on NIST’s website at http://csrc.nist.gov/publications/nistbul/july-2012_itl-bulletin.pdf.

The NIST document has great recommendations for responding to CA breaches, including:

• Document what certificates and CA’s your organization uses.
• Document logistics and information required to respond to CA compromises.
• Review and understand CA’s in active use in your organization.
• Understand “trust anchors” in your organization.
• Develop policies for application development and procurement, and implement them.
• Understand and react appropriately to CA breaches.

Let’s dive into these:

1. Document the certificates and CA’s that your organization uses

Any compliance wonk will tell you that inventory is your first and best control.  Does your organization have an inventory?

Let’s count certificates.  There’s http://www.example.com, www2.example.com, admin.example.com, backend.example.com, and there’s mail.example.com.  There may also be VPN.example.com, ftps.example.com, ssh.example.com.  These are the obvious ones.

Practically every embedded device from the cheapest WIFI router to the lights-out management interface on your big iron systems these days comes with an SSL interface.  Count each of those.  Every router, switch, firewall, every blade server enclosure, every SAN array.  Take a closer look at your desktops.  Windows has a certificate database, Firefox carries its own, Java has its own, and multiple instances of Java on a single system can have multiple CA databases.  Now your servers—every major OS ships with SSL capabilities, Windows, Linux (OpenSSL), Unix.  Look at your applications – chances are every piece of J2EE and .NET middleware has a CA database associated with it.  Every application your organization bought or wrote that uses SSL probably has a CA database.  Every database, every load balancer, every IDS / IPS.  Every temperature sensor, scanner, printer, and badging system that supports SSL probably has a list of CA’s somewhere.

All your mobile devices.  All your cloud providers and all the services they backend to.

If your organization is like most, you probably have an excel spreadsheet with a list of AD servers, or maybe you query a domain controller when you need a list of systems.  Forget about software and component inventory.  Don’t even think about printers, switches, or cameras.

If you’re lucky enough to have a configuration management database (CMDB), what is its scope?  When was the last time you checked it for accuracy?  In-scope accuracy rates of 75% are “good”, if some of my clients are any measure.  And CMDB scope rarely exceeded production servers.

Each one of these devices may have several SSL certificates, and may trust hundreds of CA’s for no reason other than it shipped that way.

Using my laptop as an example, I’ve got several hundred “trusted” CA’s loaded by default into Java, Firefox, IE and OpenSSL.  Times five or so to account for the virtual machines I frequent.  Of those thousands of CA’s, my system probably uses a dozen or so per day.

2. Document logistics and information required to respond to CA breaches

How exactly do you manage the list of trusted CA’s on your iPad anyway?  Your load balancer?  Who is responsible for these devices, and who depends on them? If you found out that Thawte was compromised tomorrow, would you be able to marshal all the people who manage these systems in less than a day?  In a week?

What would it take to replace certificates, to tweak the list of CA’s across the enterprise?  It will definitely take longer if you’re trying to figure it out as you go.

3. Review and understand CA’s in active use in your organization

Of all the dozens of CA’s on my laptop, I actually use no more than a dozen or so each day.  In fact, it would be noteworthy if more than a handful got used at all.  I could disable hundreds of them and never notice.  After all, I don’t spend a lot of time on Romanian or Singaporean sites, and CA’s from those regions probably don’t see a lot of foreign use.

Most organizations are savvy enough to source their certificates from at most a handful of trusted CA’s.  A server might only need one trusted CA.  Ask your network and application administrators – which CA’s do we trust and which do we need to trust?  It might make sense to preemptively strike some or all the CA’s you’re not actually using, if only in the name of reducing attack surface.

4. Understand “trust anchors” within your organization.

Trust Anchors are the major agents in a PKI – the CA’s.  Trust anchors provide rules and services to govern the roles of others such as the intermediates, the registrars, and the users of certificates.  Go back through your inventory (you made one of those, right?) and document the configuration.  What do the trust anchors allow and disallow with your certificates?  Will revoked certificates get handled correctly?  How do you configure it?

Does your organization deploy internal CA’s?  Which parts of the organization control the internal CA’s, and what other parts of the business depend on them?  What internal SLA’s / SLO’s are afforded?  What metrics measure them?

5. Develop policies for application development and procurement.

How many RSA SecurID customers really understood that RSA was holding on to secret information that could contribute to attacks against RSA’s customers?  Did your organization ask RIM if trusted CA’s on your Blackberries could be replaced?  Do you use external CA’s for purely internal applications, knowing full well the potential implications of an external breach?

Does your purchase and service contract language oblige your vendor even to tell you if they do have a breach, or will you have to wait till it turns up on CNN?  Do they make claims about their security, and are their claims verifiable?  Do they coast on vague marketing language, or ride on the coattails of once-hip internet celebrities and gobbled-up startups?

6. Understand CA breaches and react appropriately.

Does your incident response program understand CA breaches?  Can you mobilize your organization to do what it needs to when the time comes, and within operational parameters?

CA breaches have happened before and will happen again.  NIST has again delivered a world-class roadmap for achieving enterprise security objectives.  Is your organization equipped?

Ben and I have been grinding away on slides and code in preparation of our talk at DefCon 20.  Without letting all of the cats out of the bag, I wanted to take a second to provide a little more context into our talk and research before we present our new tools at the conference.

BBQSQL is a SQL injection framework specifically designed to be hyper fast, database agnostic, easy to setup, and easy to modify.  The tool is extremely effective at exploiting a particular type of SQL injection flaw known as blind/semi-blind SQL injection.  When doing application security assessments we often uncover SQL vulnerabilities that are difficult to exploit. While current tools have an enormous amount of capability, when you can’t seem to get them to work you are out of luck.  We frequently end up writing custom scripts to help aid in the tricky data extraction, but a lot of time is invested in developing, testing and debugging these scripts.

BBQSQL helps automate the process of exploiting tricky blind SQL injection.  We developed a very easy UI to help you setup all the requirements for your particular vulnerability and provide real time configuration checking to make sure your data looks right.  On top of being easy to use, it was designed using the event driven concurrency provided by Python’s gevent.  This allows BBQSQL to run much faster than existing single/multithreaded applications.

We will be going into greater detail on the benefits of this kind of concurrency during the talk. We also will talk a bit about character frequency analysis and some ways BBQSQL uses it to extract data faster.  Will be doing a demo too to show you how to use the UI as well as import and export attack configs.  Here are a few screenshots to get you excited!

BBQSQL User Interface

BBQSQL Performing Blind SQL Injection

If you come see the talk, we would love to hear your thoughts!

I was recently on an application blackbox assessment on a pretty solid application.  One thing that might get glazed over when developing a web application is the security of third party plugins or frameworks.  During the process of the assessments I identified a plugin that seemed to be installed but not really enabled.   It seemed to be SQL injectable but had nothing in the database.  No problem!  I found a method that allowed me to enter data in the database and then used another function to do Boolean based SQL injection against it.  This issue was easy to identify because the plugin developer stated the code was vulnerable in a comment.  I just did a Google search for the plugin name, and read though the source code.  Although slightly redacted (to protect the plugin developer while we disclose the finding), the comment basically stated that “ request variables have not been escaped and may be vulnerable to SQL injection”.

What’s the takeaway (outside of a few asprin)?  Don’t tell an attacker how to attack your application, security review third party plugins which may not have ever been assessed (especially small Github projects like the one above), and use prepared statements!