
Never Give Your Information To 10 Minute Old Startups - RKearney
http://blog.ryankearney.com/2012/10/never-give-your-information-to-10-minute-old-startups/
======
JoeCortopassi
Everyone 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..).

~~~
enoch_r
I 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
> 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.

~~~
alinajaf
Agreed. You don't even need to add any gems or do any rails magic for this to
work. In your controller:

    
    
        def edit
          @aws_credentials = current_user.aws_credentials
        end
    
        def update
          current_user.aws_credentials.update_attributes(
            params[:aws_credentials].slice(:a, :b, :c)
          )
        end

~~~
bhousel
Don't forget `destroy`.

------
patio11
Many 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.

~~~
Silhouette
Sorry, 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
Completely 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>

~~~
Silhouette
> In his own responses, _he says that he won't email the users_!

If they're based almost anywhere in the US or EU, they might well have a legal
obligation to notify at this point.

(I am not your lawyer, etc.)

------
Silhouette
10 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
"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
Totally 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
This 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.

~~~
brianpan
The results absolutely do matter. If you're running a site, you should be
auditing the areas where the security risk is the greatest and taking extra
precautions, and those areas are hopefully few. If you're not first taking
care of the places where the results are disastrous, then you're doing it
wrong.

Obviously if there is a known attack vector, you would fix any similar issues
everywhere, but not all code is the same.

~~~
mryan
The point I was making is that this particular flaw is indeed the same as the
UPS flaw when considered at a high level - modifying a URL caused sensitive
data to be disclosed.

In practical terms, of course the nature of data that is disclosed is
relevant. AWS keys are incredibly valuable, and should be treated as such.

------
seldo
Those 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
I 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
It'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
I 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.

------
Andrex
At 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.

------
zacharyvoase
I 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
> 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
'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
I 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.

~~~
djcapelis
One would hope that even average developers for a payments company would have
a better understanding of security than to make mistakes like this...

~~~
adgar2
Except you're talking about a payments _startup_. In startups, engineering
talent isn't very important.

------
ddellacosta
I'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
They already knew and it was fixed before I posted this.

~~~
ddellacosta
And did you let them know privately before you posted this comment?
<http://news.ycombinator.com/item?id=4619411>

~~~
RKearney
Details of the vulnerability were not posted until it was patched, which was
no more than 60 seconds after that initial post.

~~~
JoeCortopassi
Given the severity of the hole, I am thankful that you posted what you did

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

~~~
thisone
it'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.

~~~
sergiotapia
In .NET you can protect controller action methods using `[Authorize]` data
attribute above each method.

You can even create your own custom filters.

<http://www.youtube.com/watch?v=BsxUsyMSGeA>

Just letting you know. :)

~~~
thisone
indeed, aren't specifics, wonderful.

However, I do think that authentication is where people may believe they can
stop, forgetting or maybe not understanding, that authentication really
doesn't do much, without an authorization system.

------
paulsutter
I'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
One 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.)

------
jeromeparadis
I'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.

------
citricsquid
Security 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.

~~~
natrius
The 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
i agree - i cant think of a reason why the user id would ever be in the
account url

~~~
grey-area
It'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.

------
alyx
To 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
If 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
Fair, 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).

~~~
shardling
What exactly does "ultimate responsibility" even mean here?

------
hellosmithy
Wow. 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.

------
ricksta
I 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>

Cancan is great way to make sure that you can only read or edit your own
records in the database with Rails.

~~~
catch23
Cancan 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> and get the
formatted json representation with no masking.

------
louischatriot
I really don't think it has anything to do with the startup being 10 minutes
old. That's security 101 we're talking about ...

------
alinajaf
The 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=...](http://www.amazon.com/gp/product/1118026470?ie=UTF8&tag=portswinet-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1118026470)

------
metalruler
Another 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.

------
driverdan
Major 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.

------
andrewcooke
if 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>

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
What OS/Browser are you using?

~~~
nostrademons
I'm getting the same. Chrome 22/Mac.

------
cinbun8
I 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.

------
stesch
That's why I'm not a user of App.net. They only accept credit card.

~~~
mintplant
What does that have to do with _anything_?

~~~
stesch
With the title of TFA.

~~~
JeremyBanks
Fortunately, 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
They want my credit card info on the app.net page. With Paypal I'm on the
Paypal page. (Or Google checkout, or whatever.)

------
amalag
Was wondering how it was "compromised", thanks for posting this.

------
josegonzalez
Am I the only one getting a download.gz file?

~~~
RKearney
What 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.

------
partymon
I'm sure there is a middle ground here. Security is not necessarily a function
of age.

------
mattrandle
Its 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.

------
eranation
This is an example of the overuse of the term MVC...

------
seanconaty
I'm not surprised about this. Caveat emptor.

------
picardo
Mirror? I can't read download.gz files.

~~~
RKearney
Sorry, try again. Misconfiguration on the server was sending out gzipped
content without proper headers.

------
tylermenezes
Ugh. Seriously?

How did you not notice that?

------
chaseideas
Mannnnnnn, this exploit is SO 4 hours ago... ;D

~~~
chaseideas
This 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.

------
adgar2
It 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
Honestly, 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
What 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
Good 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.

------
paulhauggis
I'm shocked at the security flaws in this system. It's so easy to prevent..

------
clobber
Ah I'm reminded of the Blippy credit card leak
[http://venturebeat.com/2010/04/23/blippy-credit-card-
citiban...](http://venturebeat.com/2010/04/23/blippy-credit-card-citibank/)

What strange times we live in.

------
merijn481
Ryan, 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
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.

~~~
adgar2
According 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.

