Quantcast

Drive-by downloads: exploiting cross-site scripting vulnerabilities

Engineering manager at Twitter (co-founder of Dasient) Neil Daswani and CTO at Cenzic Lars Ewe have a discussion of today’s Internet safety challenges at RSA 2011 Conference – ‘Drive-by downloads: How
To Avoid Getting a Cap Popped in Your App’. Their focus areas in this part of the talk are drive-by downloads1 exploiting cross-site scripting2 vulnerabilities on websites, as well as vectors of cyber attacks in the historical context.

Neil Daswani Neil Daswani (web application security expert, engineering manager at Twitter): Hi, my name is Neil Daswani and I am here today with Lars Ewe. We will be talking about drive-by downloads and how to avoid getting a cap popped in your app.

There has been quite a bit of buzz around this talk in a number of publications, and part of that is because one of the things that we’re gonna be doing in this talk is showing how an actual website can get infected by taking advantage of a web application vulnerability, and infecting users when somebody simply loads and visits the web page.

Now, before I kind of get into a detailed demo of the particular vulnerability and the drive-by download that occurs, one of the things that I want to mention is that this particular vulnerability was identified by Gerry Eisenhaur – one of the key researchers at Dasient. He discovered this drive-by on a number of real websites.

What he had found is that the vulnerability was a cross-site scripting vulnerability, a persistent cross-site scripting vulnerability that had existed on multiple websites due to the fact that they were using a third party web application to run part of the site.

Now, we had seen that there were a couple of things going on, so the websites were infected, the third party web application had a vulnerability, it was affecting multiple types of websites, across multiple verticals, including security vendors. And we worked together with multiple parties to lock down the vulnerability but it still exists on some sites.

So as per being responsible software companies and following Responsible Vulnerability Disclosure protocols, we are not gonna be showing the issue on the exact sites on which it was found. And we’re gonna and show a slightly different vulnerability on a mock site that we have made up so that you can see exactly what happens.

But basically it just shows the dangers of web application vulnerabilities. You can have a persistent cross-site scripting vulnerability, and you can use it to inject a drive-by download into a site.

The way that this particular demo is going to work is a ‘benign’ drive-by has been injected into a site via such a vulnerability. And when one visits the web page, we’ve written this so it basically pops up the Windows calculator as an example of what could happen. We could have popped up any application, send any malware binary to the users just when they load the page, but we are just popping up the Windows calculator. And then, there is a bunch of details how the attack occurs, but let me go ahead and switch to the video and show exactly how it occurs.

Sample drive-by download occurrence video

So we have a website at a domain that we put up, called ‘willinglydumb’. And when we enter the URL into the web browser, we will see that the page will load, and it will load its login page but there is a malicious iFrame3 on this page and it basically invokes a vulnerability in the Acrobat Reader process, so you will see in the left side the Internet Explorer window launch Acrobat Reader, and that launched this drive-by download ‘e.exe’, which is the Windows calculator, and that happened very quickly (see video).

So just visiting a web page these days can be very dangerous. And it’s kind of interesting as to how bad things have gotten on the Web. These attacks very often impact legitimate websites. And so on this slide, while we say ‘drive-by via XSS on XXX website’, we are not talking about an X-rated website, we’ve just x’ed out the name.

But one question you might have is: “How did we get here? How did we get to a state of the Web where someone can just load a webpage and have an arbitrary application started on their machine without their permission?” Lars is going to provide us with a bit of historical context and tell us about how we got here.

Lars Ewe Lars Ewe (technology executive in web application development, CTO and VP of Engineering at Cenzic): Let’s do a quick overview of sort of the history behind all of this because, as Neil said, it is actually quite concerning when you see where we are and what the state of affairs is. These days you go to any website, and if you are not savvy enough you might actually get affected without ever knowing that it hit you.

So when you look at the history though – and obviously this is gonna be a very high-level overview here of how we got to where we are – there have been phases here, and we’ve gone through these phases that have changed over time.

And you will see that in the early days, let’s say in the 80’s roughly, we were talking about basic viruses. When they first came out they often would go and attack BIOS level (BIOS level based attacks), they would sit on your drive and the boot sector and often be dormant. Like, you know, Michelangelo – one of the famous ones that people can refer to. Those of you who are old enough to still remember that should know that basically what happened there was it would sit there dormant and then get live at a certain time, which happened to be the birthday of Michelangelo, so that’s where the name came from. And it would wipe out the disk, wipe out sectors of the disk – things of that nature. But when you think about it, the distribution was very limited, it usually happened through floppy disks – a sort of the ‘sneaker network’4 approach, if you will.

Evolution of security

Evolution of security

Then over time, as network became more prevalent, and you had the Internet take over the way we do business, so you had different attack levels. So that happened at the network layer level, and they would distribute them more easily. So we started seeing IDS’s5 and then IPS’s6 to try to protect against that, and Firewalls these days are very common practices, and in the fact it’s pretty hard to find many institutions that don’t run Firewalls or IDS’s and IPS’s of some sorts.

But then after that, in the 90’s and early 2000’s we saw a new attack vector emerge, and that one was really at the application layer. So as we kind of moved down from the infrastructure layer and BIOS layer up to the network layer, we worked ourselves all the way up to the application layer.

Fundamental change in malware distribution

Fundamental change in malware distribution

And the application layer is different. One of the challenges that lies within that is it allows for different distribution. So if you look at how malware has historically been distributed over time, you will notice that, as I said, it started early on with floppy disks and that’s how people got infected. I remember, and you might remember we were cautious of a floppy disk, if you had a concept of being cautious in the first place.

Then over time, we moved more and more to network layer attack, often through email. People got to the point where they realized they don’t want just to open any email, they are cautious of the attachments in emails.

As of late, you now will notice that all of a sudden all it takes is visit a website, and you might never know what hit you until it hits you. So that’s a different layer of sophistication that we are seeing. And also, the way things get exploited has changed. It used to be more of an attack that happened at the client side and often at the OS level, nowadays the root cause happens at the server that you are visiting, so the website itself gets affected, and then consequently that spreads down to yourself. So it’s a different distribution mechanism, different attack level, different sophistication.

Last but not least, I think what Neil stressed before, it’s really important to take away here that now we are talking about legitimate websites. So before, it used to be shady floppy disks. If someone had free software for you, well, you might wanna go double check on that. We did have cases where professional floppy disk companies got affected, but not so often. These days, most of these attacks happen on legitimate websites. So although you might not think at all that going to a certain website might affect you, be cautious of that. And it starts affecting reputations of companies, so it is also a totally different ball game these days.

Ways to infect a site

Ways to infect a site

So with that being said, I am gonna hand that over to Neil again, and Neil is going to walk us a little bit more through the anatomy of malware distribution. The one thing I will quickly cover here is software vulnerabilities (see upper right-hand corner of the image) which often are root cause of where it starts. Most of you might have heard of cross-site scripting, SQL injection7, cross-site request forgery8 – these are all pretty well known, or at least for most people better known than web application vulnerabilities. Especially ones that have to do with injection, have to do very much with being the root cause of what we are talking about here, because they actually open the door for the attacker to then plant the malware on the site that you then later go and drive-by, and that’s where the bad things happen. Well, that’s not the only vector, that’s one of the more prevalent vectors. There are widgets and other things that can affect you as well.

Read next: Drive-by downloads 2: malware code implementation and preventive measures
 

1Drive-by download is a download that happens without a person’s knowledge or authorization. In the context of this article, a drive-by denotes a download which occurs on websites through a web application vulnerability.

2Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications that enables attackers to inject client-side script into web pages viewed by other users.

3IFrame (Inline Frame) is an HTML document embedded inside another HTML document on a website. The IFrame HTML element is often used to insert content from another source, such as an advertisement, into a web page.

4Sneaker network (Sneakernet) is a term describing the transfer of electronic information, especially computer files, by physically couriering removable media such as magnetic tape, floppy disks, compact discs, USB flash drives, or external hard drives from one computer to another.

5IDS (intrusion detection system) is a device or software application that monitors network and/or system activities for malicious activities or policy violations and produces reports to a Management Station.

6IPS (Intrusion prevention system) is a network security appliance that monitors network and/or system activities for malicious activity. The main functions of intrusion prevention systems are to identify malicious activity, log information about said activity, attempt to block/stop activity, and report such activity.

7SQL injection is a frequently used technique to attack databases through a website. This is done by including portions of SQL statements in a web form entry field in an attempt to get the website to pass a newly formed rogue SQL command to the database (e.g. dump the database contents to the attacker).

8Cross-site request forgery (CSRF), also known as a one-click attack or session riding, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user’s browser.

Like This Article? Let Others Know!
Related Articles:

Comments are closed.

Comment via Facebook: