« SECURE 2012 – Call for Speakers: A reminder

An Anomaly in the μTorrent network

This article is based on observations in the ARAKIS system, which is built on top of a network of honeypots.

1. Introduction

In recent weeks we continued to observe significant increase of uTorrent (uTP based) network activity. Some parts of recorded traffic triggered high-level alerts in the ARAKIS system informing about possible nodes infection. What is more, according to traffic data, among other things, two of the ARAKIS honeypot sensors were involved in a conversation, which is very unlikely. This means that IP adresses that those packet contained were incorrect (or forged). In this report we summarize findings from our analysis of this activity.

OSSTMM 3 methodology gives the following definition of an anomaly:

Anomaly is any unidentifiable or unknown element which has not been controlled and cannot be accounted for in normal operations. [...] An anomaly may be an early sign of a security problem. Since unknowns are elements which cannot be controlled, a proper audit requires noting any and all anomalies.

[...]

In PHYSSEC, an anomaly can be dead birds discovered on the roof of a building around communications equipment.

[...]

In COMSEC telecommunications, an anomaly can be a modem response from a number that has no modem.

In SPECSEC, an anomaly can be a local signal that cannot be properly located nor does it do any known harm.

2. What is uTP exactly?

uTP protocol uses UDP protocol for transportation and complements it with connection-oriented features. It encapsulates standard BitTorrent packets. This means, that regular BitTorrent traffic takes place inside a communication channel created in the uTP layer. This channel has some features typical to TCP channels, including connection-orientation and congestion control. Standard BitTorrent packets rely on such TCP facilities as received data acknowledgements, regulation of window size, etc., in this case however these facilities are provided by uTP. Why do we need another protocol for that, when you can use TCP instead? UDP/uTP/BT stack is also responsible for bandwidth congestion control. When user is downloading data from HTTP or FTP server, the download speed is limited on the server side. Distributed BitTorrent network doesn’t have such limitations. That’s why it often happens that when a user downloads large amount of data, BitTorrent traffic consumes a large portion – or whole – of network bandwidth and effectively denies access to other networking applications. One possible solution is to apply built-in restrictions on the client side. These are not very sophisticated functions however and users often forget about them too. uTP on the other hand allows BitTorrent nodes to dynamically adjust bandwith congestion at the protocol level and also provides some additional functions, like support clients using low bandwidth or sharing ADSL line with a web browser.

Read more at cert.pl

To my surprise, this actually got a response. Someone monitoring the @awscloud account opened a trouble ticket to my email address asking for clarification. The exchange was friendly and hopefully, and I think it’s worth sharing here.

It’s a pretty compelling situation: cloud service offerings and web browser technology have advanced to the point where S3 and CloudFront should be all one needs to deliver an incredibly performant and cost-effective user experience, letting small startups compete in the time-to-first-render game on an even playing field with the likes of Google and Yahoo. Instead, developers are forced to settle for ugly workarounds and outright hacks due to a few crucial shortcomings.

My team at Boundless is has been working on a cutting edge single-page HTML5 app. We are hosting it on S3 and CloudFront, and its underlying API lives on EC2. Without getting into too much detail, the architecture is a lot like #newtwitter.

1. S3 Restricts Response Headers

Despite initial appearences, and without much justification from Amazon, the S3 API severely restricts which headers can be attached to an object.

• Cache-Control
• Expires
• Content-Disposition
• Content-Type
• Content-Language
• Content-Encoding

Users can apply their own metadata, but it will always be prefixed with x-amz-meta. CSS3 brings the ability to embed arbitrary fonts on the web. Fonts are the clothes words wear, and CSS3 is why the web is looking so sharp lately. The difficulty is that W3 puts fonts under a same-origin restriction. Thus, embedding these fonts requires these additional headers:

• Access-Control-Allow-Headers
• Access-Control-Allow-Origin

And the complete CORS specification has yet more headers to contend with:

• Access-Control-Max-Age
• Access-Control-Allow-Methods
• Access-Control-Allow-Credentials

This leaves CloudFront users who wish to embed fonts with a handful of undesirable options.

1. Serve the entire domain through CloudFront. This is fine unless there’s anything on your domain which shouldn’t be cached, and I’m sure things get even more complicated if you throw SSL into the mix.
2. Skip S3 and serve everything from EC2. S3 has eleven nines of durability. Go ahead, reproduce that with a couple of NginX boxes.
3. Insert some proxy servers to add the headers. I think what you mean is, add yet another hop in your network while increasing your attack footprint and your EC2 bill.
4. Mix fonts into stylesheets using data: URIs. Now every time you adjust a
   tag, your visitors have to download your fonts again. You could break your CSS into multiple files, but this is in direct opposition to one of the tenants of website optimization: minimize the number of HTTP requests. Also, 7-bit encoding means your fonts are now 37% fatter on the wire.