Never Give Your Information To 10 Minute Old Startups

Handing over sensitive information to startups that are only a few minutes old can lead to bad, bad things.

The Startup

The startup under fire today is a web service by the name of Ice Box Pro posted on Hacker News today proved that point. The service was designed as a way to back up filed to Amazon Glacier that you put in a special Dropbox folder. I was curious to see how well it performed, so I decided to sign up and give it a test run. What follows is a perfect example on how not to handle security.

Clicking on the Account tab brings you to your account page, visible below.

The Your Account page of an Ice Box Pro account

The Your Account page of an Ice Box Pro account

Visible are your name, email, AWS ID and Key, and the AWS Glacier vault created by Ice Box Pro. Upon setting your AWS ID and Key, only the last few characters are actually visible. What’s even more interesting, however, is the /users/87 part of the URL. As it turns out, your User ID is baked into the URL. In this example, I was the 87th user to sign up for Ice Box Pro. My original account was somewhere between 5 and 15, although I entered in random text for the email address so I couldn’t log back in.

So what’s the problem? I’ll give you one guess as to what happens when you change that 87 to another number.

Viewing other users information

That’s right, you could change that 87 to any number you could think of and it would spit back the information for that user. You would see exactly the same information you could see for yourself. This quickly reminded me of the Stripe CTF a few months ago. Since you can only see the Name, Email, and the last few characters of the users ID and Key, the information isn’t too dangerous with the exception of it being a spammers gold mine. But wait, it gets worse…

Compromising accounts

See that Edit link at the bottom of the account page? Click it and you’ll see the account edit view!

Edit your account page for IceBox

In the Edit your profile view, you can change your name, email, password, and AWS info

The important part here is to note that if I had filled out an AWS access key ID and AWS secret access key previously, the entire key would be visible on this screen. So while only the last few characters are visible from the account view, the entire key is visible from the edit view. It’s worth noting that the edit option is available for any user account and can be accessed by anyone.

This means that by going to /users/1/edit and /users/2/edit, you could edit the details of the two founders of Ice Box Pro. From here you can reset their password, login as them, and get access to any file they backed up. Even worse it gives you access to their AWS keys.

If you setup your access correctly, then only your AWS glacier service can be accessed. Some users, however, I found used their master AWS keys which give access to every area of Amazon Web Services (EC2, S3, etc).

Conclusion

Never give any kind of information to a startup that came into existence just 10 minutes ago. At least give it a few days for them to work out the security vulnerabilities such as this. The one I saw today was one of the worst imaginable. Full control over any users account, password, and AWS keys. Users that used their master AWS keys opened themselves up to a major headache if the keys were accessed by the wrong people and not revoked in time.

  • http://twitter.com/saturnflyer Jim Gay

    Wow. That is awful

  • http://www.saturnflyer.com/ saturnflyer

    Wow. That is awful

  • http://twitter.com/standaloneSA Matt Simmons

    /me slaps forehead.

  • http://twitter.com/artur_sapek Artur Sapek

    This is hilarious. Nice find.

  • http://twitter.com/timanema Tim Anema

    Did no one test this? Did no one have any imagination at Ice Box to imagine the use cases of their urls? This is some amateur stuff here

  • http://twitter.com/zachinglis Zach Inglis

    Their reaction was even worse when they handed out your email.

    I suspected they’d be humble, apologise and try to move on the thread.

  • http://twitter.com/zachinglis Zach Inglis

    Their reaction was even worse when they handed out your email.

    I suspected they’d be humble, apologise and try to move on the thread.

  • http://twitter.com/merijn481 Merijn Terheggen

    Ryan, your post is NOT an example of responsible disclosure. In fact, you seem to weigh the importance of your post getting on HackerNews above the security of the people who tried Ice Box Pro. The creators of Ice Box Pro had good intentions and messed up security (as almost any startup does to some extend). You are either ignorant to what security actually means or unethical, which at best is as bad as what the creators of Ice Box Pro did and maybe worse. Will you take responsibility if any of the users that tried Ice Box Pro get hacked as a consequence of your post?

    • http://www.ryankearney.com/ Ryan Kearney

      Will I take responsibility? No, because it was posted AFTER it was fixed. I posted no details of any exploit until the security hole was closed.

      • http://twitter.com/merijn481 Merijn Terheggen

        Ah, I see you did let them know and the vulnerability was fixed before you posted. Good. I recommend saying such a thing in your post because it helps people like me understand that you are in fact responsible about the disclosure.

        • Marco

          you are responsible for acting by responding on information you don’t understand, and for being presumptuous and accusatory. slow down man.

        • J Random

          Yes, it’s really important that self-elected security disclosure police understand that you are measuring up to their expectations.

        • http://www.facebook.com/chris.laffra Chris Laffra

          limos.com had the same vulnerability for a long time. By changing the 6 character confirmation number in the URLs they sent to their users, you could view back all reservations for anyone in the last years, and future reservations as well. All possible details were available, such as names, phone numbers, time, pick up address, reason for trip, number in the party. Etc. I tried to notify them through various channels, and never received any reaction. Their CTO and CFO did not understand their problem, and their IT team tried to shuffle it under the carpet, perhaps. I simply gave up. Of course, I could have scraped their DB and sold the data of Bieber’s upcoming reservations to US Weekly and retire, yet I didn’t. So… don’t trust 10 minute old startups, but neither trust 5 year old ones either.

    • http://nicksergeant.com/ Nick Sergeant

      I don’t know. Normally I would agree with you, but if you’re building a web app and can’t get “user’s private information should only be available to that user” correct, then you have no business in building web apps.

    • anon

      Like it takes a genius to discover this exploit. Give me a break.

    • Guest

      lol you sir are funny. Do you normally post stuff that is completely wrong? Or is it my special day?

  • http://twitter.com/merijn481 Merijn Terheggen

    Ryan, your post is NOT an example of responsible disclosure. In fact, you seem to weigh the importance of your post getting on HackerNews above the security of the people who tried Ice Box Pro. The creators of Ice Box Pro had good intentions and messed up security (as almost any startup does to some extend). You are either ignorant to what security actually means or unethical, which at best is as bad as what the creators of Ice Box Pro did and maybe worse. Will you take responsibility if any of the users that tried Ice Box Pro get hacked as a consequence of your post?

    • http://www.ryankearney.com/ Ryan Kearney

      Will I take responsibility? No, because it was posted AFTER it was fixed. I posted no details of any exploit until the security hole was closed.

      • http://twitter.com/merijn481 Merijn Terheggen

        Ah, I see you did let them know and the vulnerability was fixed before you posted. Good. I recommend saying such a thing in your post because it helps people like me understand that you are in fact responsible about the disclosure.

    • http://nicksergeant.com/ Nick Sergeant

      I don’t know. Normally I would agree with you, but if you’re building a web app and can’t get “user’s private information should only be available to that user” correct, then you have no business in building web apps.

    • anon

      Like it takes a genius to discover this exploit. Give me a break.

    • Guest

      lol you sir are funny. Do you normally post stuff that is completely wrong? Or is it my special day?

  • http://twitter.com/eranation Eran Medan

    Someone was RESTing too much in the security class…

    • http://www.facebook.com/aashu.dwivedi Ashu Dwivedi

      haha :)

    • http://www.facebook.com/gadgettrak Ken Westin

      Oh, I $GET_ it now.

  • http://twitter.com/eranation Eran Medan

    Someone was RESTing too much in the security class…

    • kw_45

      Oh, I $GET_ it now.

      • Dr. McKay

        Uhm… do you $_GET it?

        • bluelightzero

          $_POST is cleaner

  • darel peters

    Actually there is still a very easy hole. Create 2 accounts. take alook at cookie in fiddler, compare. and tamper it – enjoy.

  • darel peters

    Actually there is still a very easy hole. Create 2 accounts. take alook at cookie in fiddler, compare. and tamper it – enjoy.

  • http://stepanp.com Stepan Parunashvili

    Someone should have read Michael Hartl’s tutorial on Rails :P

  • http://stepanp.com Stepan Parunashvili

    Someone should have read Michael Hartl’s tutorial on Rails :P

  • http://twitter.com/dubcanada Steven Verbeek

    I broke my account by setting my AWS key to 0. I now can’t even access my account to fix it… Oh well :)

  • http://twitter.com/dubcanada Steven Verbeek

    I broke my account by setting my AWS key to 0. I now can’t even access my account to fix it… Oh well :)

  • eagspoo

    cancan + 10min + a clue = problem solved

    • http://optiss.si/ Tomaz

      devise + 10 min of reading + no clue = problem solved :)

  • eagspoo

    cancan + 10min + a clue = problem solved

  • http://twitter.com/mauriciojr Maurício Linhares

    Not sure what makes me sadder, the fact that a company just didn’t care about security when it holds your freaking service keys (and most people would use their full set of AWS keys instead of creating a pair of keys just for this service) or a developer or team of developers that is so clueless about their job that can’t see this is a huge security hole.

    Not sure if I’d be surprised if these guys got attacked and all keys just happened to be stored unencrypted in their database.

  • http://twitter.com/mauriciojr Maurício Linhares

    Not sure what makes me sadder, the fact that a company just didn’t care about security when it holds your freaking service keys (and most people would use their full set of AWS keys instead of creating a pair of keys just for this service) or a developer or team of developers that is so clueless about their job that can’t see this is a huge security hole.

    Not sure if I’d be surprised if these guys got attacked and all keys just happened to be stored unencrypted in their database.

  • Guest

    wtf kind of engineering is this! I just taught my grandpa how to hack this site and he’s happily hacking and enjoying people’s information. This site is a great learning tool for beginning hackers (even those who don’t know how to code), the sad part is that this is actually real account data.

  • Guest

    wtf kind of engineering is this! I just taught my grandpa how to hack this site and he’s happily hacking and enjoying people’s information. This site is a great learning tool for beginning hackers (even those who don’t know how to code), the sad part is that this is actually real account data.

  • eagspoo

    Well I do hope no one was dumb enough to give their root AWS credentials instead of credentials for a harmless IAM user. So the real risk in that case is the data, not the credentials.

  • eagspoo

    Well I do hope no one was dumb enough to give their root AWS credentials instead of credentials for a harmless IAM user. So the real risk in that case is the data, not the credentials.

  • SSL Dude

    Is that using HTTP, without SSL?

    The bug you found is obviously the worst case scenario, but sending sensitive information over the internet in plaintext is a close second.

    • Rick

      Remember kids, ruby on rails is not gonna magically secure your website.

  • SSL Dude

    Is that using HTTP, without SSL?

    The bug you found is obviously the worst case scenario, but sending sensitive information over the internet in plaintext is a close second.

  • Rick

    Remember kids, ruby on rails is not gonna magically secure your website.

  • vicmiclovich

    I’m pretty sure that they’ll either start protecting access to actions like the edit or delete actions once they realize this. Most folks, new to ruby, are yet to experience the awesome of tools like “friendly_id” or “nested_resources” to create friendly URLs. This is just an honest mistake and over time they’ll revolve. This doesn’t make their service a bad one. Of course we have to probably “help them out” :p Now they know :p

  • vicmiclovich

    I’m pretty sure that they’ll either start protecting access to actions like the edit or delete actions once they realize this. Most folks, new to ruby, are yet to experience the awesome of tools like “friendly_id” or “nested_resources” to create friendly URLs. This is just an honest mistake and over time they’ll revolve. This doesn’t make their service a bad one. Of course we have to probably “help them out” :p Now they know :p

  • http://abhishek.dilliwal.com Abhishek Dilliwal

    even a college guy wont do such blunders!

  • http://abhishek.dilliwal.com Abhishek Dilliwal

    even a college guy wont do such blunders!

  • Jose Ramon Varela

    Would you really say this is a common trend among prototypes/new startups? This seems like an outlier in carelessness since it wouldn’t take much to fix this issue using gems like devise and cancan. A gaffe like this one could have been avoided by watching tutorials.

  • Jose Ramon Varela

    Would you really say this is a common trend among prototypes/new startups? This seems like an outlier in carelessness since it wouldn’t take much to fix this issue using gems like devise and cancan. A gaffe like this one could have been avoided by watching tutorials.

  • hhimanshu

    wooo, man what was the developer thinking while designing the application?

  • hhimanshu

    wooo, man what was the developer thinking while designing the application?

  • http://manavgoel.net/ Manav Goel

    Lack of proper testing(in this case no testing at all) results in this.

  • http://manavgoel.net/ Manav Goel

    Lack of proper testing(in this case no testing at all) results in this.

  • http://twitter.com/ndbroadbent Nathan Broadbent

    The story is that this service wasn’t even meant to be launched yet. It was supposed to be a private site for a few friends to test out, but someone submitted it to hacker news prematurely. I think the lesson here is that they shouldn’t have deployed a live application until they had done all their testing on a private network.

  • nathan_f77

    The story is that this service wasn’t even meant to be launched yet. It was supposed to be a private site for a few friends to test out, but someone submitted it to hacker news prematurely. I think the lesson here is that they shouldn’t have deployed a live application until they had done all their testing on a private network.

  • http://www.facebook.com/lalacucubautzi Andreea Agarlita

    Shit happens…but to make such a big mistake in managing users data and personal accounts, it’s more than unprofessional and the companies should be fined. If they can’t manage safely these data,which is essential, what services do they offer??

  • http://www.facebook.com/lalacucubautzi Andreea Agarlita

    Shit happens…but to make such a big mistake in managing users data and personal accounts, it’s more than unprofessional and the companies should be fined. If they can’t manage safely these data,which is essential, what services do they offer??

  • http://needforair.com/ Louis Chatriot

    I don’t think it has anything to do with being 10 minutes old. They should take security 101.

  • http://needforair.com/ Louis Chatriot

    I don’t think it has anything to do with being 10 minutes old. They should take security 101.

  • http://bluesmoon.info Philip Tellis

    I agree with everything except the “10 minute startups” part. There have been enough compromises in the last year alone to show that it isn’t just 10 minute startups, but even 5-10 year old companies that make these mistakes. A large part of security is just common programming sense, ie, validate all input, and too many programmers ignore that.

  • Guillermo

    You will surprise how many sites have this security problem.

  • Patrick

    I don’t believe that there are still people (I don’t want to call developers!) that made these mistakes!! :-(

  • Andrew Cunningham

    Really, the age of the startup is irrelevant here. You can run for years with bad security. It’s more about making sure you spend a minute to note the environment and security certificate you’re using. Telling people not to sign up for a startup because they’re new doesn’t help them grow.

  • Sajin M Prasad

    They launched this without testing. That was very novice.

  • Test McTest

    I find this HIGHLY offensive.

  • not stupid

    i dont even give this to the bank internet database, you MUST BE STUPID TO AGREE TO BE IDENTIFIED BY THIS QUESTIONS.

  • http://online24.nl Michiel Prins

    Sadly, as a penetration tester I come across issues like these very often. ID enumeration is a classic.

  • http://twitter.com/amolkher Amol Kher

    I also recommend serving account pages over SSL so that passwords are not passed in cleartext.

    • http://twitter.com/AlanHogan Alan Hogan

      This* was a ticket at IFTTT a while back, because yes, it’s the responsible thing to do. We decided to take it a step further and serve *all* pages over SSL. Now our pages have security be default instead of security by opt-in, if that makes sense.

      I mean, really, it’s 2012, and there is little excuse to serve anything remotely important over HTTP.

      *To clarify, we never, ever sent passwords or keys over plaintext. However, for a time, there were pages that contained personally-identifiable or otherwise secret information that didn’t always use HTTPS. No more!

    • http://twitter.com/AlanHogan Alan Hogan

      This* was a ticket at IFTTT a while back, because yes, it’s the responsible thing to do. We decided to take it a step further and serve *all* pages over SSL. Now our pages have security be default instead of security by opt-in, if that makes sense.

      I mean, really, it’s 2012, and there is little excuse to serve anything remotely important over HTTP.

      *To clarify, we never, ever sent passwords or keys over plaintext. However, for a time, there were pages that contained personally-identifiable or otherwise secret information that didn’t always use HTTPS. No more!

  • fred55

    Did you inform the company and give them time to correct this security hole? If not, you you are helping criminals to victimize their customers.

    • http://www.ryankearney.com/ Ryan Kearney

      If you spent 5 minutes researching you would have figured out that it was fixed before anything was disclosed.

      Than you for your concern.

  • http://twitter.com/icodeforlove Chad Scira

    its products like this that make it harder for the rest of us security concious developers trying to start stuff. :(

  • http://twitter.com/rodvdka rodvdka

    This looks like Django to me. A simple: if request.user() == id(passed in) would solve this problem. There really is no excuse for not checking for this, it’s basic.