Every good filing system has a section called “M for miscellaneous”. So does this blog series.
It is possible for an attacker to provoke Norton Internet Security into blocking all access to Amazon S3 from your computer. So if a Tunesafe user visits a site that contains a specially designed page – or views a forum entry containing a specially designed image – his Tunesafe backups will cease to be accessible.
This does not simply affect Norton Internet Security and Amazon S3: it is potentially a problem for all Web services when used with any anti-Internet software. There is a detailed blog posting here and an executive summary here.
Slashdot is a site that offers “news for nerds”. To appear on its front page is to be read by hundreds of thousands of people. If the news story contains a link to your web site, very many of those readers will visit your site in a very short time, probably leading to the complete collapse of your server under the load. Your site has been “slashdotted”.
A malicious analogue of slashdotting is also possible. One of the more vicious Internet worms of the last few years aimed to recruit a network of millions of computers all of which would attack one site (such as a US government one) at the same moment. That particular attack failed because the worm was not well designed; but it is quite common to find high-profile sites such as Worldpay having to operate at reduced capacity for several days as a result of a denial-of-service attack.
One of the attractions of putting your publicly accessible data on Amazon S3 is that you are immune to slashdotting.
One of the dangers of putting your publicly accessible data on Amazon S3 is that you are immune to slashdotting.
Why is it a danger? Because a normal slashdotted site becomes slower and slower and eventually crashes or grinds to a halt. This limits the size of the attack. But if you have a 2MB photograph stored on Amazon S3, access to it will be as fast with a million visitors as it is with one; and at $0.0004 per visit, a million visitors will cost you $400. You are safe from a denial-of-service attack but open to a draining-of-bank-account attack.
I haven’t gone too far into this risk because Tunesafe is immune to it: nothing is publicly accessible at all, and each user’s backups are stored in his own private data space on S3. But if you are planning a public service, assess the risks carefully. Various S3 users are lobbying Amazon for automatic limits and cutouts so that access to their data is suspended in case of attack. Amazon are quite reasonably resisting their requests for now. For a start, it would imply real-time gathering of billing information across Amazon’s network, whereas at present they can get away with consolidating the data at relatively long intervals. This may end up as one of those risks that just have to be budgeted for.
Doshslatting is slashdotting backwards. Amazon charge for uploads as well as downloads: so an attacker could wreck your budget by uploading vast amounts of data. (Again, because it doesn’t have publicly accessible data spaces, Tunesafe is immune to this.)
Doshslatting can only be malicious, which makes it rather easier to deal with. Given the cheapness of S3 and the slowness of data transfer, an attacker would have to have access to a “botnet” of thousands of subverted PCs in order to cost you very much money. The motives for doshslatting could only be vandalism and extortion. Given that a botnet can be used for many lucrative purposes, vandalism isn’t worth the bother; and extortion is not only criminal but necessarily involves contact between the extortioner and his victim. There are easier ways to make money out of botnets.
Amazon S3 already contains partial protection against doshslatting. Rather than having a publicly writeable area of your storage space, you can make all of the space private and accessible only by signed requests from a client. You then make your web application work as follows:
- The web browser asks your own server for a signed write request.
- Your server considers the identity of the user, and if it thinks the user is legitimate it creates a signed request and sends it to the browser.
- The web browser sends the signed request to Amazon S3 along with the data it wants to upload.
This is good, rational protection, and it works. If Amazon allowed the signed request to include a size limit – “please write a data object, the object to be no more than 4MB in size” – things would be better still (technically, the modification would be very easy indeed). What is even better is that signed requests in S3 can have time limits, so your server can issue a request that will only work for 15 seconds after it was created. This will prevent most kinds of botnet attack.
- The anti-Internet problem
- This will become more and more of a problem as the use of web services grows. The problem will be stopped eventually, because the makers of anti-Internet software will have to make their products work rationally or people will stop buying them.
- There are technical impediments to Amazon providing precise rate-limiting mechanisms, but an imprecise one may eventually become available (eg. limiting starts when the traffic has reached somewhere between 1 and 5 times the chosen limit). Even so, this is a risk that has to be borne by the business that uses Amazon S3. Methods of monitoring and mitigation have to be considered and a budget set aside to pay Amazon’s fees if a surge in demand does occur. Not every risk can be prevented or pushed onto someone else’s shoulders!
- Methods exist to reduce the risk to the point where only a really dedicated attacker could have a measurable impact; and such attackers will have many more lucrative things to do with their time and resources.
Next time, this series is brought to a conclusion.