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.

88 replies
  1. Merijn Terheggen
    Merijn Terheggen says:

    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?

    Reply
      • Merijn Terheggen
        Merijn Terheggen says:

        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.

        Reply
        • Marco
          Marco says:

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

          Reply
        • J Random
          J Random says:

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

          Reply
        • Chris Laffra
          Chris Laffra says:

          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.

          Reply
    • Nick Sergeant
      Nick Sergeant says:

      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.

      Reply
  2. Merijn Terheggen
    Merijn Terheggen says:

    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?

    Reply
  3. darel peters
    darel peters says:

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

    Reply
  4. darel peters
    darel peters says:

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

    Reply
  5. Maurício Linhares
    Maurício Linhares says:

    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.

    Reply
  6. Maurício Linhares
    Maurício Linhares says:

    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.

    Reply
    • eagspoo
      eagspoo says:

      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.

      Reply
  7. mauriciolinhares
    mauriciolinhares says:

    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.

    Reply
  8. Guest
    Guest says:

    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.

    Reply
  9. Guest
    Guest says:

    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.

    Reply
    • SSL Dude
      SSL Dude says:

      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.

      Reply
  10. Guest
    Guest says:

    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.

    Reply
  11. eagspoo
    eagspoo says:

    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.

    Reply
  12. eagspoo
    eagspoo says:

    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.

    Reply
  13. SSL Dude
    SSL Dude says:

    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.

    Reply
  14. SSL Dude
    SSL Dude says:

    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.

    Reply
  15. vicmiclovich
    vicmiclovich says:

    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

    Reply
  16. vicmiclovich
    vicmiclovich says:

    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

    Reply
  17. Jose Ramon Varela
    Jose Ramon Varela says:

    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.

    Reply
  18. Jose Ramon Varela
    Jose Ramon Varela says:

    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.

    Reply
  19. Nathan Broadbent
    Nathan Broadbent says:

    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.

    Reply
  20. nathan_f77
    nathan_f77 says:

    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.

    Reply
  21. Andreea Agarlita
    Andreea Agarlita says:

    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??

    Reply
  22. Andreea Agarlita
    Andreea Agarlita says:

    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??

    Reply
  23. Philip Tellis
    Philip Tellis says:

    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.

    Reply
  24. Andrew Cunningham
    Andrew Cunningham says:

    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.

    Reply
  25. not stupid
    not stupid says:

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

    Reply
    • Alan Hogan
      Alan Hogan says:

      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!

      Reply
    • Alan Hogan
      Alan Hogan says:

      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!

      Reply
  26. fred55
    fred55 says:

    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.

    Reply
  27. rodvdka
    rodvdka says:

    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.

    Reply
  28. GrumPOW!
    GrumPOW! says:

    Say, what became of these hooligans? I was dumb enough to sign on, but now it seems that iceboxpro.com is history. I guess one of these days I’ll have to figure out how to access Glacier the good, old-fashioned way.

    Reply
    • Ryan Kearney
      Ryan Kearney says:

      No clue. The guy started posting my name and email (On no!) on HN saying people should contact me if they have any problems. He then proceeded to get ridiculed by the rest of the HN community for the way he handled it.

      Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply