11 ms·
Never Give Your Information To 10 Minute Old Startups
- adgar2 14y agoIt might be time for pg and co. to reconsider the idea that engineering doesn't matter and that startups are just about people. This is pathetic.
- spamizbad 14y agoHonestly, this isn't even a matter of engineering. I don't know the rails solution, but a quick-and-dirty solution in other frameworks is to use a decorator on your controller/views that does something like: if request.session.userId == action.userId: pass else: return SecurityExceptionResult The example above is like 10 mins to code and put under test once you fill it in with the necessary stuff- You're probably going to want to log would-be security issues and gracefully handle the error. With that said, user-identity does not belong in a URL. If you just did /user/edit (we assume all operations are performed on the logged in user) and then moved your security validation down a level to verify that session.userId == model.record.userId you'd be much better off.
- adgar2 14y agoWhat do you call the role of the individual whose job it is to implement account management? Do you not call that person an engineer? If not - whose responsibility would you say it is to ensure shit like this doesn't happen?
- spamizbad 14y agoGood point, but I read "engineering doesn't matter" to mean you shouldn't spend a significant amount of time carefully designing a system that's likely to change. pg is absolutely correct in that sense. My point was the amount of time required to prevent security holes like the ones outlined in the link are minimal - preventing them isn't going to stand in the way of an engineer implementing other features.
- alyx 14y agoTo be fair, the guy who owns that site did mention that it wasn't meant to be picked up by HN and was still in the early stages of development.
- philwelch 14y agoIf it's accessible on the public internet and asks for something as secure as API keys, that is when you should worry about security, not when it's "meant to be picked up by HN".
- alyx 14y agoFair, but in any case, the ultimate responsibility still lies with the user's judgment. Maybe if there was a service promised but not rendered, could you place full blame on the developer(s).
- adgar2 14y agoExactly. When you go to provide your information to a website, you need to consider "what are all the possible outcomes of this?" We can't use the reputation of the providers of a service as a proxy and thus have zero information about what to expect. Since you almost never have the source code for the website you're giving your information to, using your logic, just never give your data out. Right?
- shardling 14y agoWhat exactly does "ultimate responsibility" even mean here?
- philwelch 14y agoIt's not a matter of assigning blame, it's a matter of not delivering a shitty service to your customers.
- kooshball 14y agoI have mixed feeling about this. On one hand we all want to move quickly, get users, add new features, etc etc. On the other, security issues like this are just so vital that nothing else really matter if your data is not secure. It's especially true for a BACKUP SERVICE that promises ridiculous stuff like "99.999999999%" uptime on the frontpage.
- paulsutter 14y agoI'd love to see some concrete suggestions on the right way to do security for a site like this. This would take far more than protecting a few web pages from unauthorized access. What else should they do? How should they store sensitive data like AWS keys? Should they include a feature to force the creation of a new temporary key to prevent users from naively storing their master key? Is there a better mechanism than storing the key?
- gfodor 14y agoOne appropriate way to do this is to not build this type of application as a web service, but instead as a standalone application. (Disclaimer: I haven't really tried this product, for obvious reasons.)
- rdl 14y agoI've been working on a similar kind of problem (linking to AWS); the right thing is to walk users through IAM credential creation (if you must have the keys), explaining exactly what rights are needed, why, and how to verify, and to not take anything more than you need. I'd also encapsulate use of any user-provided sensitive data in an API then called by your service, and put some logic within the API (because I don't want a random web UI screwup to dump everything for everyone) -- rate limits, etc.
- rdl 14y agoI've been working on a similar kind of problem (linking to AWS); the right thing is to walk users through IAM credential creation (if you must have the keys), explaining exactly what rights are needed, why, and how to verify, and to not take anything more than you need.
- amalag 14y agoWas wondering how it was "compromised", thanks for posting this.
- paulhauggis 14y agoI'm shocked at the security flaws in this system. It's so easy to prevent..
- citricsquid 14y agoSecurity stuff aside, I'm curious why a system would be designed this way. Surely (in most systems) all users have the same page for managing their account (eg: /account) or is this system designed so that the management portion (eg: what a support person would use) is the same as what the users use? I don't think I've encountered a site that had accounts edited this way before.
- adgar2 14y ago> I don't think I've encountered a site that had accounts edited this way before. Any site that employs the pattern of specifying user account routes using the user's primary key in the URL needs to implement authorization. This site clearly skipped that step. To me, this looks like the stereotypical bare-bones rails deployment by a newbie.
- natrius 14y agoThe last time I used Rails (2009), the way RESTful URLs are set up encouraged this pattern. It's simple enough to restrict access to the user in question, but it is (or was) easy to overlook.
- misiti3780 14y agoi agree - i cant think of a reason why the user id would ever be in the account url
- grey-area 14y agoIt's relatively common practice to have an url like this: /yourusername or /users/yourname or /users/32, which shows a public profile, and therefore to have a guessable url for it, and to have a link to edit your account on that page if you are that user. That in itself is not a security problem, but having no access control obviously is.
- ExpiredLink 14y agoIt's REST, it must be good.
- hellosmithy 14y agoWow. That's taking the idea of an MVP a little too far. Just goes to show worth doing a little research before handing over any real information to a new service like this.
- zacharyvoase 14y agoI took a look at the team. Is it considered apropos to state how surprised you are that developers who come across as relatively senior are capable of making an incredibly fundamental security mistake such as this? It looks like this was just the default Rails resource scaffolding.
- adgar2 14y ago> Is it considered apropos to state how surprised you are that developers who come across as relatively senior are capable of making an incredibly fundamental security mistake such as this? Only if you're concerned that you can't tell who is "relatively senior." In this case, your judgement was unfortunately wrong.
- zacharyvoase 14y ago'Relatively senior' here means 'ostensibly trusted with important tasks in the past'. Both of the creators of this application (I won't say 'founders of this startup' because that's silly) are ex-WePay.
- adgar2 14y agoI had to look up WePay on Google. The wikipedia page says they have 30 employees as of a year ago, did YC and 1 round of funding. I have to be honest - that doesn't demonstrate a high level of trust at all these days. It's sad, but true. Plus, if you say they're "ex-WePay," I assume they were just everyday developers for WePay, not critical resources.
- ricksta 14y agoI would recommend using CanCan for security if they haven't done so already so you can't just type in other users user_id in the url to view or edit. https://github.com/ryanb/cancan https://github.com/ryanb/cancan Cancan is great way to make sure that you can only read or edit your own records in the database with Rails.
- catch23 14y agoCancan probably wouldn't have prevented this. It's not because someone didn't use some library. The developer probably just did a User.find(params[:id]) instead of doing something like current_user from whatever authentication system they were using. He probably used the scaffolding generator to make everything and forgot to go back and ensure things are secure. It's also interesting that the aws key/secret are "masked" on the page, but you can just visit http://www.iceboxpro.com/users/12.json http://www.iceboxpro.com/users/12.json and get the formatted json representation with no masking.
- nathan_long 14y agoThis kind of thing can be handled with doing something like `current_user.accounts.find(params[:id)` instead of `accounts.find(params[:id])`. If it's not your resource, it's like it doesn't exist for you.
- jeromeparadis 14y agoI'm puzzled. For the kind of service they want to offer, to have such newbie security vulnerabilities makes you wonder if it even works. It's the kind of flaw that any moderately experienced developer never leaves opened.
- andrewcooke 14y agoif anyone else is having problems viewing this: it's a serious hole in icebox, the service featured here http://news.ycombinator.com/item?id=4619132 http://news.ycombinator.com/item?id=4619132 if you've used that service, the information you entered was publicly visible (key to access aws, etc) (the thread linked above says it has now been patched). [i don't understand why, but when i access the link for this thread i get the gzipped page as a download; linux + chrome 22; firefox displays what appears to be gzipped data; wget saves the gzipped data as index.html; same behaviour for chrome on opensuse and ubuntu; windows 7 + ie9 (in a vm) shows the gzipped data in notebook; is no-one else seeing this?!] [update: fixed now - it looks like it wasn't changing the content type]
- RKearney 14y agoWhat OS/Browser are you using?
- nostrademons 14y agoI'm getting the same. Chrome 22/Mac.
- RKearney 14y agoShould be resolved. Can you try once more?
- bmelton 14y agoI have the same problem as the GP, and I'm using Chrome on OSX. Hope it helps.
- josegonzalez 14y agoAm I the only one getting a download.gz file?
- deleted 14y ago[deleted]
- RKearney 14y agoWhat OS/Browser are you using? I turned on aggressive caching with CloudFlare to speed up page loads but it appears that it's only serving the gzipped version.
- deleted 14y ago[deleted]
- Silhouette 14y ago10 minutes? Never give your information to a business that made a mistake like this, ever. That wasn't merely a "security vulnerability". It was also a demonstration that the people running the business have absolutely no idea what they are doing when it comes to security, privacy, or testing and release processes. (Actually, there is an alternative explanation, which is even worse: they knew and didn't care. I prefer to assume naivety rather than malice.) Unfortunately, the only sensible action when faced with a business like this is to run away and not look back for a very long time, except perhaps to check who the people responsible were so you can avoid anything else they work on in the near future as well.
- larrys 14y ago"Never give your information to a business that made a mistake like this, ever." Fwiw back in 1996 or 97 the UPS website did the same thing. By altering the tracking number you could see somewhat complete information on someone else's shipment. Since the tracking numbers ran in sequence from the shippers log books giving one tracking number from a competitor you could see all their customers. (To get that all you had to do was place a single order so they shipped to you. Although I guess it wouldn't have been even easier to social engineer someone to simply give you any tracking number and save that step.)
- whalesalad 14y agoTotally not the same thing. Not even close. Knowing a tracking number is nothing compared to having access to someone's AWS account. That's like saying knowing where someone's car is parked is the same as having their keys and a full tank of gas. I agree with silhouette. These guys scaffolded a rails project and and then slapped bootstrap on it. You can't trust an MVP this extreme.
- mryan 14y agoThis is exactly the same thing - an obvious security oversight that resulted in private information being disclosed, simply by modifying the URL. The fact that the results are so different is irrelevant - the attack vector was essentially the same. Also, even with the complete lack of security on this site, it should still not be possible to take any action on the victim's AWS account. IAM has read-only roles for this exact reason - hopefully no-one was negligent enough to post their master AWS key/secret in to this or any other third-party site.
- ddellacosta 14y agoI'm curious, did you let them know that this vulnerability exists before you wrote an article and posted it to HN? If you let them know and they ignored you, then I understand that you'd want to write an article and spread it around. It's important that customers know when a company doesn't value their security. At that point, the proper way for them to handle it is to quietly fix it, and then let all their affected customers know so they have a chance to change their security settings. However, if you didn't give them a bit of time first, then you are doing more damage than good to them--and their customers.
- RKearney 14y agoThey already knew and it was fixed before I posted this.
- ddellacosta 14y agoAnd did you let them know privately before you posted this comment? http://news.ycombinator.com/item?id=4619411 http://news.ycombinator.com/item?id=4619411
- RKearney 14y agoDetails of the vulnerability were not posted until it was patched, which was no more than 60 seconds after that initial post.
- JoeCortopassi 14y agoGiven the severity of the hole, I am thankful that you posted what you did
- adgar2 14y agoSince you presented 2 possibilities here, neither of which are accurate, what is your response to the reality of the situation?
- patio11 14y agoMany folks in the security community might suggest a) An oblique warning publicly like "There exists a security problem with this; I have mailed the devs" b) actually mailing the devs c) waiting for confirmation of fix or a reasonable time and only then d) tar-and-feather. The term-of-art for this is "responsible disclosure." This incentivizes people to fix things quickly and preserves the reputational value of breaking into things without researcher-vendor relations getting adversarial when you announce something like "I harvested a couple dozen of your customers' API keys" or "Here's an exploitation roadmap you can follow in your browser" in a public forum.
- deleted 14y ago[deleted]
- Silhouette 14y agoSorry, but I think you're being far too kind. A policy of so-called responsible disclosure is a reasonable approach to take when dealing with an established product/service that contains a minor vulnerability, something potentially dangerous but unlikely to be exploited in the immediate future with serious negative effects. In this case, we appear to have a new project run by people who don't know what they're doing, with a glaring vulnerability that had presumably already compromised 80+ people's sensitive credentials and in turn who knows what other sensitive information. Bringing it down as fast as humanly possible and loudly so no-one else gets damaged in the meantime is entirely justified in a case like this.
- JoeCortopassi 14y agoCompletely agree. Look at his responses to the security issue being brought up in the original thread [1]. This is someone who is clearly playing fast and loose with some frameworks, and people's information, and does not deserve to be given that consideration. In his own responses, he says that he won't email the users! I can't imagine how upset I would be if this had my information. Access control for something like this is dead simple [1]http://news.ycombinator.com/item?id=4619424 http://news.ycombinator.com/item?id=4619424
- picardo 14y agoMirror? I can't read download.gz files.
- RKearney 14y agoSorry, try again. Misconfiguration on the server was sending out gzipped content without proper headers.
- JoeCortopassi 14y agoEveryone here that is thinking of giving this company the benefit of the doubt needs to go read their (smeagle) responses to RKearney from the original thread. Here are some samples of the careless attitude behind this: ---- "if anyone's concerned about your AWS key, just destroy your IAM user and create a new one. that's what it was designed for." ---- In response to advice saying they should notify users by email: "good idea. actually, we'll just wipe them and force new ones." ---- In response to RKearney warning people about just what exactly is exposed: "in case you have issues with your AWS keys. RKearny's email: ryan@ryankearney.com https://secure.gravatar.com/avatar/f7d7b021fb488fe6a67ddb286.. https://secure.gravatar.com/avatar/f7d7b021fb488fe6a67ddb286....
- ainsleyb 14y agoThis is a severe lack of customer service. The least that can be done is a quick shutdown of the site until there's a good fix, an email to all customers (since legally they have to disclose the breach: http://en.wikipedia.org/wiki/Security_breach_notification_laws http://en.wikipedia.org/wiki/Security_breach_notification_la...), and a thanks out to whomever reported the issue. If you make a mistake, own up to it. Honesty is the best key to building a business, and I'm sure they've at least lost the HN trust for any product in the future.
- enoch_r 14y agoI was slightly sympathetic to them right up until smeagle posted RKearney's email. While not noticing an incredibly obvious security hole is serious, it's somewhat understandable in the context of a site that unintentionally goes public before it's ready. What's far, far worse is the mindset in which someone who points out a security hole is the problem, and should be personally attacked. They should have thanked him, notified their users, done a thorough review of their own security, and warned new signups to only use IAM keys. Instead they got defensive, made excuses, and attacked the messenger.
- oelmekki 14y ago> it's somewhat understandable in the context of a site that unintentionally goes public before it's ready Sorry, but no. There is absolutely no good reason while creating an user controller - even when writing the very first lines - to not check against current user on sensible actions. Actually, I may argue that's the very first thing you do once the controller skeleton is set up.
- merijn481 14y agoRyan, your post is NOT an example of responsible disclosure. You could have written your post and posted it AFTER alerting the Ice Box Pro guys and waiting until they had the main issues fixed. Your post would still be a good post. 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?
- merijn481 14y agoAh, 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.
- adgar2 14y agoAccording to timestamps, it took ~5 minutes for you to realize your mistake. It may be worth waiting those five minutes before posting, in the future.
- markmm 14y agoI hope the people behind IceBoxPro have revealed their real names, because they have no business in the software industry any more, and rightfully so.
- sergiotapia 14y agoHoly shit! I consider myself a mediocre programmer at best and even I wouldn't make such a dumb mistake. This is literally something only a amateur would do. I'm just awe struck that this would even happen. How?
- zhodge 14y agoSame here haha. I'd be pretty upset if that was my personal information up and available for all to see, but thankfully that wasn't the case. How this happened is what I want to know too.
- mattdeboard 14y agoBeware the mistake you think you'll never make :)
- ainsleyb 14y agoWhat we've found is that there are 2 mindsets: building and breaking. When you're building a product it's super hard to switch to the breaking mindset of security, simply because mental context switching is expensive and mentally exhausting. The most important thing is to force yourself into that mode before posting anything publicly. If you don't have the security experience, have a friend or service (like ours) look it over. Data is one of the most important assets to your company (or project), and any sort of disclosure can shut you down permanently.
- thisone 14y agoit's something someone would do who's never worked with authentication and authorization before and doesn't have the fallback of a professional tester (aka breaker). As people have mentioned, rails doesn't have it built in. I've used gems to provide it since I don't trust myself to write good enough security algorithms (and really, why reinvent the wheel if I don't have to). In .net we can use the asp.net membership. But you've always got to have that authorization part, which I think can get forgotten about unless you've got a system under you belt or something/someone to crib from. Sometimes you just don't think, and sometimes it becomes very public.
- 14y ago
- deleted 14y ago[deleted]
- eranation 14y agoThis is an example of the overuse of the term MVC...
- clobber 14y agoAh I'm reminded of the Blippy credit card leak http://venturebeat.com/2010/04/23/blippy-credit-card-citibank/ http://venturebeat.com/2010/04/23/blippy-credit-card-citiban... What strange times we live in.
- tylermenezes 14y agoUgh. Seriously? How did you not notice that?
- metalruler 14y agoAnother hole that has been exploited in the past (speaking generally here, not about this specific startup) is a password reset function that confirms the email address it is sending the password/recovery link to. If the accounts are sequentially numbered, it's a trivial exercise to fetch a reset link for each member, and scrape the email address returned.
- eagsalazar 14y agoWell to be fair, people who gave their real AWS keys also acted as, if not more, foolishly than the devs. From amazon: "For your protection, you should never share your secret access keys with anyone. In addition, industry best practice recommends frequent key rotation. Learn more about Access Keys" USE IAM USERS
- chaseideas 14y agoMannnnnnn, this exploit is SO 4 hours ago... ;D
- chaseideas 14y agoThis comment was completely tongue in cheek; in all seriousness it was great to see them fix this so quickly. Tell me that blog post didn't read like a security exploit announcement... Anyways, as discussed, it never should've happened in the first place, but it sounds like from the comment threads that it was likely Framework related, so.... yeah, still prettty bad.
- seldo 14y agoThose who know me will laugh to see me continuing to beat this dead horse, but this is a really great example of why ORM+scaffolding is an anti-pattern, by which I mean it seems like a good idea at first, but the costs outweigh the benefits. It's absolutely true that you can use ORM and scaffolding patterns in a totally secure way. But the problem is that the defaults are insecure -- every table can be accessed, every record is available, every field can be edited, and the URLs for doing so are (deliberately) easily guessable. One of the simplest and most fundamental rules of effective security is to close everything down by default and only open things up as required, after careful consideration. Scaffolding breaks that rule.
- angryasian 14y agoI think it has less to do with ORM and more to do with laziness. Its really one line in the controller, if loggedin user is not the user trying to edit redirect.
- gambler 14y agoIt's not just laziness. 99% of all framework tutorials I've seen out there completely ignores even basic authentication/authorization issues, which are universal to all real websites. This lack of attention to details is cultivated.
- movingahead 14y agoI guess they are using Rails. If they had only taken a few hours to go through a free tutorial like the one at railstutorial.org , they could have avoided this blunder.
- Evbn 14y agoWell the original Rails book had it: http://pragprog.com/book/rails4/agile-web-development-with-rails http://pragprog.com/book/rails4/agile-web-development-with-r...
- grey-area 14y agoOne of the simplest and most fundamental rules of effective security is to close everything down by default and only open things up as required, after careful consideration. Scaffolding breaks that rule. This is really an argument for building authentication and authorization into every app, rather than against scaffolding/ORMs. As rails doesn't have auth (of both kinds) built in, it doesn't really matter if they offer scaffolding or not - any editing url you make is going to be completely without protection unless you add it. The only thing you'd be adding by not having guessable urls without authentication/authorization is security through obscurity. So IMHO the lack of auth is really the issue here (and the thing that breaks the rule in your final sentence), rather than the guessable urls.
- Andrex 14y agoAt first, I thought I was supposed to notice the complete lack of "HTTPS" in the URL bar. The data leakage obviously overshadows it, but I can't think of a site that wouldn't be a better "fit" for SSL encryption than an app like this, aside from banking/government sites. SSL might have been a "nice-to-have" back in the day when there were real arguments to be made against it (mostly performance-related), but even those don't really apply to a "pet project" made by "two nerds" (smeagol's words, not mine.) And for an app like this, I think it's critical. Just my two cents.
- cinbun8 14y agoI would rather say 'Never give your information to a startup that does not handle it responsibly'. Not every startup is irresponsible with data. In this case you have a strong point. Good work finding the security issue and reporting it.
- deleted 14y ago[deleted]
- mattrandle 14y agoIts got nothing to do with the age of the startup, and everything to do with the quality of the engineering. You see problems like this and worse in companies that have been around for years. It would have been more responsible to privately notify the owner of the site rather than karma whoring a blog post to top of HN.
- louischatriot 14y agoI really don't think it has anything to do with the startup being 10 minutes old. That's security 101 we're talking about ...
- stesch 14y agoThat's why I'm not a user of App.net. They only accept credit card.
- mintplant 14y agoWhat does that have to do with anything?
- stesch 14y agoWith the title of TFA.
- JeremyBanks 14y agoFortunately, you don't give App.net your credit card information directly. It's handled by Stripe, and they're past being "10 minutes old". (Even though this isn't easily verifiable in the checkout flow to a non-developer.)
- stesch 14y agoThey want my credit card info on the app.net page. With Paypal I'm on the Paypal page. (Or Google checkout, or whatever.)
- alinajaf 14y agoThe optimistic and humble side of me wants to believe that this is a rare occurrence. The truth is that I don't remember working on a single codebase that didn't have some eventually discovered vulnerability in auth(entication|orization). When I eventually do comb through controllers and find easily exploited access-control violations, I've often been met with responses similar to the behaviour of the developers at Icebox. Rails does and will continue to protect you from a lot of mistakes, but nothing is going to help long term unless you know what words like authentication, access control and session management mean. If you're a professional web developer and you care about your users then please buy and have a read through The Web Application Hackers Handbook[1]. Every page is dripping with easily exploitable attacks you didn't think of. That last app you built is almost definitely vulnerable to a handful of them. [1] http://www.amazon.com/gp/product/1118026470?ie=UTF8&tag=portswinet-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1118026470 http://www.amazon.com/gp/product/1118026470?ie=UTF8&tag=...
- driverdan 14y agoMajor data leaks / security issues like this are not confined to sites that are 10 minutes old. Yesterday I discovered a recently funded startup is exposing all personal user data and activity to the world via their public, unprotected APIs. I'm hoping they fix it quickly before someone interested in harvesting that data finds it.
- partymon 14y agoI'm sure there is a middle ground here. Security is not necessarily a function of age.
- markmm 14y agoThis is typical of the "Get it out the door ASAP" culture with many startups. Yes you can't spend years indulging in perfecting every area of your system but don't release a pile of junk written in a scripting language that you learnt in the last few months. Software is a product and it's worth spending extra time to make it well engineered.
- seanconaty 14y agoI'm not surprised about this. Caveat emptor.