Java script, security and you - Tri-Cities Javascript Developers Group

Editor's Notes

1. Hi, I'm Adam Caudill - I'm an independent security researcher and software developer. I'm going to talk a little bit about the security aspects of Javascript; this will be a fairly high level talk - due to limited time, I'm going to try to keep things brief, but I'll be happy to answer any questions.
2. Javascript is clearly one of the most important technologies in use today - the modern web wouldn't be possible without it. As it's become critical on the client side, it's also making inroads on the server side - it's one of the most ubiquitous languages in use, while presenting a low barrier to entry, and certainly lower than other languages that have achieved such wide-side deployments. But, as is true with most technologies, there's a darker side. It's not all rainbows and butterflies. Let's define client-side Javascript as it actually is - arbitrary remote code execution. You are running code, on your machine, supplied by somebody else - someone that could be malicious, and running it in a sandbox of varying quality. Because of this, Javascript can do as much evil to users as it does good. You all know how to use Javascript for good, so let's take a quick tour of its darker side.
3. If you look at this Javascript, you'll see the code of a new variant of the Blackhole Exploit Kit that I discovered some time back. To make it easier to read I removed about 700 lines from that mess in the middle. This is not only obfuscated, but intentionally convoluted to make it harder to understand. If you can, note line 21 - it executes something invalid so it'll thrown an exception; the malicious code is called from the catch statement. At the time I found this, not only did none of the scanning tools detect this - the tools developed to deal with obfuscated code would fail, some quite dramatically. This is just a sample of what attackers will do to make it hard to understand their code. In this case, there was code to exploit flaws in Internet Explorer, and then take over the system. The technology that enables the modern, rich, interactive web, is also critical to criminals.
4. In August of last year, the FBI raided a hosting company that was known to shelter illegal content. Most such raids are simple - go in, take the equipment back to the FBI offices, and analyze the data. This was a bit different. This hosting company offered hosting only over Tor, so hidden services as they are called - so there's no way to know who was connecting to these sites, or even who owned them. They were flying blind, even though they arrested the person running the hosting company, they had no insight into So the FBI modified the HTML pages on the server to add a new iframe, the page it pointed to contained an exploit targeting Firefox version 17, the version of Firefox that was being distributed with the Tor Browser Bundle at the time. The code above is the shell code, the code that executes as part of Firefox after the exploit code loads it into memory, and takes advantage of a flaw to execute it. The shell code in this case sent the user's IP and MAC address to a server controlled by the FBI, so they could identify potential targets for further action. It's worth noting that perfectly legal sites were hosted by this company as well, they weren't spared from this treatment.
5. Who here has heard of Quantum Insert? It's the NSA's highly automated hacking system - one of the features is that it can inject malicious code into websites, turning a site you trust into a delivery mechanism for government controlled malware. The UK's version of the NSA, GCHQ used this method to inject code into LinkedIn pages to target networking and security personnel at certain organizations - and by that I mean private companies, not terrorist organizations. The US isn't the only country doing this, we are probably doing it at a larger scale - but we aren't alone.
6. So we've seen that criminals, law enforcement, and spy agencies all use the same techniques to take advantage of the fact that you are letting every site you visit run code on your machine. But I don't point that out to cause fear, I'm not a fan of FUD - but to make sure that everybody is thinking about the big picture when it comes to Javascript. The impact of mistakes and holes can be very real.
7. One thing that I want to say very quickly while I have everyone's attention - use TLS, and use it right. Please. By using TLS for all of your traffic you are preventing man-in-the-middle attacks which could silently modify Javascript to insert malicious code; this is just what happened with LinkedIn. The costs of using TLS is nearly zero now when setup correctly. CloudFlare, is now offering it for free - they even handle the certificate, so there's no cost at all - as long as you're ok with systems that don't support SNI seeing errors. I'm a big proponent of the encrypt-everything mindset, and this is one of the most important areas to do that.
8. Now that we've talked a little about bigger picture issues, let's look at threats impacting people here.
9. Who here knows what XSS is? When I say Cross Site Scripting, or XSS, most people picture the classic alert dialog popping up. In reality, XSS can be transparent, and quite effective. Effectively what's happening is that the attacker is injecting their own javascript code to your page - so the attacker's code can do whatever yours can do. If your cookies aren't protected by the HttpOnly flag, then it can capture a user's cookie, and send it off to the attacker's server - then suddenly they can be that user. If the user happens to have elevated privileges, this can be a very bad thing. Imagine for a second a banking web site, a customer gets an email that claims to be from their bank - the check and the domain matches the real thing, so they feel safe clicking it. As soon as the page loads things start happening. Next thing they see is a confirmation that they just transferred their savings to a foreign bank account. In the right situation, and when crafted correctly XSS can be very damaging. XSS often gets played down as being a minor issue, but depending on the situation, it can be a real issue.
10. There are two basic types of XSS - stored and reflected. Stored means that it's permanent, and stored on the server. This is often caused from bad input sanitization, allowing an attacker to inject something into a page that will execute for anyone that visits it. Forums and systems that allow comments are the most common place you see this. Reflected on the other hand, passes the code in as part of the URL. This may seem that it would make it less effective - but it can actually be worse, as it can be targeted. Imagine that you run a site, and get an email from someone saying that one of the pages looks like it's been defaced - more often than not that'll get your attention. You click the link without realizing what's on the end, and you're done. Anybody hits the same page, it's performally normal. This allows it to be used in a targeted manner and minimize the risk of early detection.
11. If you noticed, this slide looks a lot like the XSS slide - and it is, because the effects are very similar, but how they are targeted is different. XSS is about embedding Javascript in your site, CSRF is about having malicious code on a different site, and your site accepting the commands that it sends. So, for example if an attacker sent you a link to their site, and you're logged into the site they are trying at attack - they could do fun things like change your email or password. This can be just as troubling as XSS. It's critical that all calls use a anti-CSRF token, also called a synchronizer token, to ensure that your app and the user are on the same page. :)
12. One of the most disappointing issues I've seen are applications that perform all of their validation and sanitization on the client - and the server accepts whatever the client sends assuming it's been handled. This opens the door to so many issues, and so simple to prevent. Never, never, trust the client. You don't know what it is, or if it's malicious. So, because of that, the assumption should be that the client is always malicious. Even though you think you wrote the code that's running, you can't verify that, so assume that it's not your code. Check everything. Always.
13. With HTML5, and related… stuff, the attack surface for Javascript has never been larger. As the industry moves ahead with expanding what can be done, all of these features also become targets. I'm not going to get into this right now - just be aware that the more functionality that gets added, the larger the attack surface becomes. As time goes on, and more focus is put on these features, new attack techniques will be found.
14. So, what is Javascript - it makes what would have seemed like magic a decade ago common, even expected. It powers progress, and it powers criminals and spying. It's an ally, and a threat; a tool and a weapon. As is so often the case, it's not one or the other, but both. As long as we remember that, understand both how it can work for us, and work against us - we can keep our users safe.
15. If you want to get into this more, and learn more about how to test your own sites, a friend of mine has an ebook available that walks you through many of the details, complete with exercises to test techniques out.