Hacker News new | ask | show | jobs
by enscr 4520 days ago
Github uses ruby on rails, which is a pretty mature framework, perhaps covering most of the common security pitfalls. Additionally, I assume github has excellent programmers because of the nature of their job.

Could someone explain in simple english, how did they overlook known & well documented bugs that got them hacked (e.g. Bug 3 about cross domain injection). I'm wondering if someone of Github's caliber can be hacked so easily, what about the rest of the masses developing web apps. Especially all those new crypto-currency exchanges popping up left & right.

I've been toying with Django. Reading through the docs makes me feel that as long as I follow the safety guidelines, my app should be safe. It feels as if they've got you covered. But this post rattles my confidence.

5 comments

///host.com bug is not well documented. It's "0day" for most of websites.
Got it! Just worried about the rest of us folks who can't pay you $400/hr :)

Cheers !

Read every single post on his blog.
How did you find out about it?
It's worth mentioning that Github has forked Rails and is working off their own private branch of Rails 2.3. Not saying that was relevant to this exploit, mind you.

https://github.com/github/rails

http://www.kalzumeus.com/2013/06/17/if-your-business-uses-ra...

It is relevant to this:

> I . . . decoded _gist_session cookie (which is regular Rails Base64 encoded cookie)

In Rails 4 the session cookie is encrypted with a server-side secret, so the end user can't decipher it.

Gist is indeed running Rails 4.
Isn't gist an entirely separate application from dotcom? My impression was gist is a Sinatra app, not Rails.
I'm wondering if someone of Github's caliber can be hacked so easily, what about the rest of the masses developing web apps.

They're all pretty bad. SQL injection was a boondoggle for years until people wised up, or more likely moved to the then-newly-popular ORMs, but it still got Bell Canada recently. Target is #36 on the Fortune 500. That wasn't a webapp based attack, but even companies of their considerable resources still get security that wrong. Sure, you can tell yourself a startup is more tech focused and better positioned to get security right. But do devops building for server stacks and platforms they don't fully understand while pushing code multiple times a day really have both the skills and time to focus on security?

I'm wondering if someone of Github's caliber can be hacked so easily, what about the rest of the masses developing web apps.

What do you think makes Github that much better than all the rest?

It's a dream job for developers, in some ways a lot more so than the big boys like Google and Facebook. They have a hiring pipeline any tech company would kill for. They probably don't have the deep security talent that say Google or Microsoft have, but they should have enough.
It's a dream job for developers

Really? I'm not so sure, AFAICT Github doesn't have any new or interesting problems to deal with. It's just a Rails app that's constantly developed on. You can do that, well, anywhere.

Their employees do some really interesting things. ReactiveCocoa is incredible. Seems like a great place to work to me (I'd love to get a job there!)
Having met several of them and spent a day in their offices (they gave Kiva engineering a tour day a couple years back), I can say they have an awesome company culture and space and great leadership and great brand recognition. Plus, people generally like them. I'd put it near the top of my list if I had one.
Working in ruby using git? Sounds horrible to me :)
As briefly as possible? Infosec is hard. Most companies have virtually no security policies. Nobody listens. Black hats are ahead in the arms race and anyone who has decent knowledge (doesn't even have to be anywhere near on a level like Homakov or Zalewski) can pull off all sorts of exploits. Even if they don't strike the application itself, they'll get you through infrastructure that your application relies on. Look at how script kiddies like the SEA can pull off high-profile hacks through social engineering, domain and DNS hijacking.

It's assured that a ton of Rails apps are vulnerable, it's just that no one has found them, or more likely, is not publicly releasing or actively exploiting them.

Also, Rails doesn't address for all security pitfalls. Some of its mechanisms are actually underdeveloped and require rolling lots of checks by yourself, such as for proper session termination, IIRC.

> Infosec is hard.

In computer security, you have to get it right every single time. The bad guys only need to get it right once.

This highlights to me that our infrastructure is horrendously overcomplicated. We have all these great abstractions, but you have to worry about bugs and exploits in every possible layer of every system. Even the simplest modern web-application has an enormous surface-area to secure, and that makes getting it "right every single time" damned near impossible.
This is a little myopic but understandable in the context of a discussion on HN. Infosec is hard, but it is just one example of a bigger truth:

Defense is hard.

This comes up time and time again in any defensive discipline:

  Over two decades the  CIA had learned again and again that it  could not hope to
  defend against  terrorists by relying solely  on its ability to  detect specific
  attacks in  advance. No matter how many  warnings they picked up,  no matter how
  many  terrorist cells  they disrupted,  at least  some attackers  were going  to
  get  through. Officers  in  the  CTC privately  compared  themselves  to  soccer
  goalies: They wanted to  be the best in  their league, they wanted  to record as
  many shutouts as  possible, but they knew  they were going to give  up scores to
  their  opponents. Ultimately, many  of them  believed,  the only  way to  defeat
  terrorists was to get out of the net and try to take the enemy off the field.[1]

The final sentence above highlights the one pecularity of InfoSec; you do not have any offensive capabilities.

[1]: "Ghost Wars" (Steve Coll) pg 505

This is why I think some more work into client (or active) honeypots may be beneficial. If we can get an easy to install, auto updating honeypot that fights back, we may have a better offensive capability.

This may just end, like nuclear warfare, in MAD... But it would be great fun to watch!

http://en.wikipedia.org/wiki/Client_honeypot

http://books.google.com.au/books?id=YQmWtsqlvfMC&dq=active+h...

http://en.wikipedia.org/wiki/Mutual_assured_destruction

No one gets it right every single time. No one. That's a completely unrealistic expectation. What you do is establish a bar, which you share with everyone who will use your software. Then you evaluate your efforts against that bar.

One of the keys to developing good software is hiring third-parties to conduct audits. A bug bounty program is one way to incentivize people who are already probing your software to take the next step and tell you about the bugs they find.

What opinions does infosec in general have of correctness? What about languages like Haskell which focus on separating IO and pure functions?
well it gives the advantage that (used to?) keep desktop-Linux clear of most viruses: it's too little a fish for blackhats to go after.

until that's different it's harder to answer your actual question. my guess, it'll be better but inevitably still have some holes.

I specifically what infosec (or anyone involved in the industry) thought of separating pure and impure functions which affect the outside world.

It seems to me that it would drastically reduce the surface areas of attack.

Good to know, thanks. Any recommendation for a good read on security best practices for a python/django app?
If you aren't yet familiar with OWASP, start there. https://www.owasp.org/index.php/Main_Page

Here is some OWASP material specific to Django.

If you like reading http://blog.mikeleone.com/2011/10/security-django-and-owasp-...

If you like watching http://www.youtube.com/watch?feature=player_embedded&v=sra9x...