What is an open relay?
An open relay comes from the good old days of Internet, when mail servers would simply receive requests to send out messages to other mail servers. It was built on a model of trust, and was conceived before anyone saw a benefit to sending out messages regarding cheap places to buy viagra to completely random strangers.
An open relay costs big money. Not only due to bandwidth used, but due to blacklisting of your server due to spam reports.
So how does this apply to cloud?
I saw a demo from Dan Orlando on how to integrate an Adobe Air application with S3. Very cool stuff, and definitely worth looking into.
In summary, he's providing an example on how you can access your S3 bucket.
The first second I saw this application, I thought to myself. Awesome! This could be used to collaborate with files, to be able to send information to an online repository so that multiple people can access it.
Then I came to the realisation that each person would need to have a public/private access key for the bucket. This is not reasonable to do in a large system. I've researched the topic a bit and discussed with a few people, and they have a range of ideas, each one more terrifying to me than the next.
Why is this terrifying? Because you are basically giving a third party user the keys to your cloud platform. Why is this a problem?
Show me the money!It is a problem. It doesn't take a genius to realise that giving a nefarious person access to a storage system to place files is just simply a bad idea. Why?
1. Phishing port
A place to store files on the internet, such as pictures etc. You take the heat, you pay for the bandwidth, they get to sell their Viagra/Tic Tacs.
2. Dark Side File store
From everything from WAREZ to undescribable images/movies that will get Interpol kicking down your door, your platform can be used for some pretty darn nasty stuff.
Let's not forget Trojans, virii etc.
3. Other access to Amazon
If they only gain access to your bucket, it isn't inconceivable that with your root key some black hat won't be able to spawn off a few EC2 servers to crack a few SSL key pairs or otherwise do numerous bits of distributed number crunching. After all, this is what Grid, er, I mean Cloud Computing was designed for!
Not to mention that you'll be getting quite a huge bill at the end of it all.
What should I NEVER do under any circumstances?
As Amazon quite clearly states. Give out, or embed your secret key in your Flex/AIR applications.
The problem is that to communicate directly from the client to S3, as far as I can tell you must have the private key included in the communication.
A RESTful state of unREST
In the good old days where programmers were programmers, and compilers were compilers, there was a level of automatic obfuscation present, as when you compiled your executable, it went to machine/byte code, and that was the end of it.
Unfortunately, with applications like Flex, all you need to do is to run the .SWF file through something like trillix, there is absolutely no way to keep your procedures secret. Including your authentication mechanism.
So let's say you run a login service in a Mid-Tier like JAVA, although it could be PHP, Ruby, whatever. Let's say that the user supplies their username/password to authenticate, and is then passed a private key to access a set of buckets. Problem solved, right?
Wrong.
There is no expiry on this key at this point in time, and it grants you complete and unabridged access to the bucket.
What are some possibilities for security?
Token Based Authenticated Security
If it would be possible to allow for a set of tokens, and a set of permissions to be placed to the files on S3, then that is ideal.
S3 is not about services that need to be allowed, but rather permission to read data. If you are blocked from reading the data, you have satisfied the security requirements. If you have access to the data where you should, and only where you should, you have met the user requirements.
I am unaware of a token based authentication service from AWS. If you could store your private key on your JAVA/PHP/whatever mid tier, securely held behind your standard security perimeter, you could then authenticate the username/password from the service. The service would call AWS, and register a token with a set expiry date, with a set of permissions.
The token would then be sent to the client, and the client could use the security priviliges which were previously authenticated.
Other
Ladies and Gentlemen of the Internet, please comment on any other ideas you might have on this topic. Also, watch this space, as I will be updating it as more information/AWS functionality comes to light.
there is apparently a token-based authorization scheme, although it's not implement in some of the libs so maybe it's new (?). http://docs.amazonwebservices.com/AmazonS3/latest/index.html?UsingAuthAccess.html
ReplyDelete@Jammer
ReplyDeleteExcellent to see people interested in cloud security.
Tokens tripped me up at first too, unfortunately:
"When granting access to a specific AWS user, the user must have an Amazon account and must be signed up for AWS and Amazon S3. This will enable the user to access any allowed buckets or objects using his AWS Access Key ID and Secret Access Key. When you grant access to all AWS users, any AWS user will be able to access allowed buckets or objects using an AWS Access Key ID and Secret Access Key. When you grant anonymous access, any user will be able to access allowed buckets or objects by omitting the AWS Access Key ID and Signature from a request. "
Note that you must have an AWS account, so you can't use it for your system.
The authentication I'm talking about is to provide you with a mechanism to authenticate based upon a token that you set up for your software, but a seperate token that acknowledges that a seperate username/password has been entered to authenticate the account.
The problem is that you can basically sign up for an account with a piece of software that uses a bucket in such a casual manner, install a packet sniffer like Charles and listen in on the communication. The key will be in there if stored on the server.
Otherwise, you can use Trillix or something similar to decompile the Flex/Flash app, have a peek inside, find the tokens, and away you go. Free storage on someone else's dime, as well as possibly free access to EC2, and other expensive services.
It really opens up a vector for malware et al.
I haven't had a look recently, but I still don't think anything exists to solve this conundrum. Should something avail itself, then AWS will definitely be another powerful tool in our arsenal.
bayani,
ReplyDeletei'm talking specifically about the thing they call "query string authentication" http://docs.amazonwebservices.com/AmazonS3/latest/RESTAuthentication.html#RESTAuthenticationQueryStringAuth
you create a signed query string (signed with your AWS key). the signed string includes both the specific query and an expiration timestamp. you can pass this signed query string to a 3rd party (who does NOT need to be an AWS user) after authenticating/authorizing them in your app via whatever criteria you want, without exposing your own keys. when the 3rd party presents the string to AWS, the signature is validated by AWS, and it thus serves as a "token" redeemable for a specific operation on a specific object for a limited time period.
While this is very nice for private usage and for sharing of public information, sadly none of this is useful for storing media in paid-content scenarios. Even the seemingly best solution - query-string auth - doesn't work. Your original user gets his content in a legitimate way, links the S3 URL on Twitter, and suddenly half the internet has free access to your content. Unless, of course, you set the expiry timer to something ridiculous, like 5 seconds. Any ideas, anyone?
ReplyDeletehello,
ReplyDeleteI'm addressing this issue in my blog post here
http://dimescu.com/2010/10/how-to-securely-call-amazon-webservices-from-a-client-application/
Hi ! I find out that you have a great article. Keep it up ! Thanks for sharing this.
ReplyDeletebuy real vine followers