SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere Nutzervereinbarung und die Datenschutzrichtlinie.
SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere unsere Datenschutzrichtlinie und die Nutzervereinbarung.
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.
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.
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.
The impact of mistakes and holes can be very real.
One thing that I want to say very quickly while I have everyone's attention - use TLS, and use it right. Please.
I'm a big proponent of the encrypt-everything mindset, and this is one of the most important areas to do that.
Now that we've talked a little about bigger picture issues, let's look at threats impacting people here.
Who here knows what XSS is?
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.
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.
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. :)
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.
As time goes on, and more focus is put on these features, new attack techniques will be found.
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.
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.
A Brief Introduction to Fear
JS: Good & Evil
● Critical for the
● Provides rich
● User tracking &
● Browser exploits