Hacking Github with Webkit | Hacker News Reader

Hacking Github with Webkit

homakov.blogspot.com

301 pointshomakov78 comments

"I reported the fixation issue privately only because I'm a good guy and was in a good mood."

I for one am glad that Homakov decided to share and write about these security issues rather than just selling it to the highest bidder. I have learned quite a bit over the past year. And it's deplorable that Github isn't paying anything.

He was referring to companies which offer bounties (facebook, google etc) and not sites where you can sell your exploits

yeah. i don't sell exploits yet. Facebook, stripe, shopify, skrill - they treat a reporter nicely.

Any reason why you would even consider selling exploits? Do you not get compensated well from other ventures?

In negotiation theory your 'BATNA' or 'Best Alternative To Negotiated Agreement' is the second choice you'll go with if the current negotiation breaks down. Theoretically, neither party in a negotiation need accept less than their BATNA.

For example, when you negotiate your annual raise, your best alternative is the raise you could get by moving to another employer (adjusted for benefits, time spent commuting, how fun the job is etc). You don't have to explicitly say to your boss "give me a raise or I'll quit" - your boss just needs to know your options are open.

If homakov publicly says he'd never consider selling an exploit, he's saying his BATNA is $0 and some kudos on Hacker News. If he says he's undecided, his BATNA would be somewhere between a few thousand and a few hundred thousand dollars. Needless to say, the former statement closes off a lot of negotiation options while the latter leaves them open.

[0] http://www.forbes.com/sites/andygreenberg/2012/03/23/shoppin...

> Do you not get compensated well from other ventures?

He can likely get compensated much, much better for an original 0day on a big site.

I can only buy some beer and snacks for this compensation

JUST WONDER,

how much would someone pay for this vuln? We can discuss it... homakov@gmail.com

Just because a bounty policy isn't disclosed doesn't mean it doesn't exist.

I've reported several vulnerabilities to GitHub. There is no bounty policy.

yeah +1. @joernchen also did I remember. And lots of other people.

Hey, anyone, is github that super profitable company with 100mln investments ? They got no money or what?

I guess people disclose enough vulns voluntarily that they don't need to offer a bounty as an incentive.

= cheating

trust me, it doesn't exist.

I got a t-shirt some time back for reporting a serious XSS vulnerability.

they like you.

Oops, looks like my tweet (the "open-source GitHub") got a bit more famous than I thought. I feel I must write a big disclaimer here:

I was just joking and would never actually exploit someone that would do so much damage. I was merely commenting on the irony of leaking GitHub on GitHub. Don't fucking do this. It's not fun.

Another big disclaimer:

I didn't clone github/github, steps are theoretical

Wow Homakov, other great write up! I'm really interested in what resources you used to learn all this stuff! Would you mind doing a "recommended books and blogs" post anytime soon?

honestly, i didn't read a single book about web sec. I just learn things one by one and if something looks weird i investigate. This is why sometimes i publish "known" stuff.

You can sign up for Cryptography courses at Coursera.org. You learn about basic tenets of crypto like attacker games, cryptogaphic advantage, cracking some exploits (AES-CBC). If you do the problem sets and programming assignments and pass the course without help, you are off to a very good start I would say.

A very well-known and recommended book in this space is "The Web Application Hacker's Handbook."

Also, "The Tangled Web".

Another interesting post from homakov. Thanks so much for posting these as I learn a lot.

A few months back didn't your blog do something devious to people who read it? (Oh, yeah! It was signing people out of their Google accounts, I think?) Anyway, now I'm leery of clicking any links to homakov.blogspot.com.... :-p

I do think I'm safe from you, though. I browse with cookies off, NoScript enabled (except for small whitelist), and RequestPolicy blocking cross-site requests. Homakov, can you think of any sort of exploits I'd be vulnerable to when browsing the web?

RequestPolicy is OK, cookies off is better.. but how can you use the web !

Ha, well in some ways the web is better: I generally don't get ads or annoying pop-ups or social sharing widgets, etc. CSS is often on a separate domain so most pages are unstyled and ugly, but pretty easy to read (usually just black text on white background).

But the downside is I had to open this page in a different browser to reply to you just now. And things like Gmail, GitHub, etc, I use in my other browser, but I try to keep the sites I use "unprotected" to a minimum.

On the whole, a fair trade-off I think.

fair enough

I am not an expert in security but when I started using github pages a week ago. When I realized I could put any Javascript on the github.com domain I thought: good luck with making this secure.

there is no way to make it secure, lol :D

What about only letting users customise CSS and HTML? Can that be secure?

JS CSS HTML are very mixed in each other. It is very hard to allow only CSS/HTML.

May I recommend https://js-quasis-libraries-and-repl.googlecode.com/svn/trun... as a good read. It examines a system that can safely escape content based on its context, and forms the basis of one of the template packages of Go.

btw <meta http-equiv=Set-Cookie> may behave same way!

Thanks for the rec, this looks really good! Reminds me a lot of XHP.

best xss protection - http://homakov.blogspot.com/2013/02/pagebox-website-gatekeep...

Alright... what if they could only change the CSS, and not the HTML and JS? (Obviously not a solution for Github pages, but workable in some scenarios)

Still sounds dangerous to me. It's possible to execute code from CSS! https://code.google.com/p/browsersec/wiki/Part1#Cascading_st...

Does this mean all domains which allow arbitrary JS on subdomains are vulnerable? Is this why heroku app domains are x.herokuapp.com and not x.heroku.com?

Cedar stack apps are herokuapp.com, but their older Bamboo stack is heroku.com. But I don't think you can create any new ones with Bamboo, thankfully!

yes it does. yeah, *.heroku.com was a bad idea too.

I believe that * .heroku.com points to * .herokuapp.com

https://www.google.com/search?q=site%3Aheroku.com&aq=f&#...

About 598,000 results (0.23 seconds)

Some do redirect to * .herokuapp.com, though. For instance: http://blacklistapp.heroku.com redirects to http://blacklistapp.herokuapp.com. I wonder if they switched it over for newer instances?

1) find or buy at least one heroku.com subdomain

2) PROFIT

3) MOAR PROFIT

4) EVEN MOAR PROFIT

Nice one again. @homakov thanks for sharing. Shame on github for their bounty policy.

This is not new[1], but interesting that github didn't think about this when they set-up gh-pages.

It's hard to blame them though. Security is easy to miss. Myself and many other people who use github, and who understand those issues, don't really think about it until someone points this out...

[1] http://security.stackexchange.com/q/12412/7306 - just an example of a discussion about this very same issue from about a year ago (and it wasn't new even then)

EDIT: layout

did I say cookie tossing is something new?

If I would consider it as a new attack I would call it Homakov Cookie Tossing Attack. Now it's just cookie tossing.

Saying that it's not new wasn't meant as a criticism for your discovery of this happening on github. Quite the opposite.

It's more of an observation on how even well-known security vulnerabilities can go overlooked. Even by companies with as big exposure and as many resources as github.

As always really well written article and an interesting investigation. I learn a lot from your stuff. Thanks!!!

> Custom JS on your subdomains is a bad idea

What is the difference between allowing users to put custom JS on a subdomain, vs. someone just opening up the developer console and running whatever JS they like? Does JS loaded from the server have different privileges to JS entered at the console?

The difference is, I can put custom JS on my Github page and send you a link, when you open it you run code I authored. Developer console is just me running code, and is also on any arbitrary domain on any site.

My understanding of this article was that he pulled off the hack entirely by himself, without having to get someone to visit his page. Maybe I misunderstood.

no difference. but running XSS in console is shooting your leg

What you're referring to is a self-XSS. They were a lot more common back when you could run JavaScript from the address bar.

These days if you try and paste JavaScript to your address bar (try it with: javascript:alert(1);) then the browsers try and stop you. Firefox just won't execute any JavaScript, even if you've manually typed it. IE and Chrome strip the "javascript:" prefix (but Chrome is vunerable if you type "j" and paste the remainder).

More info here: https://www.facebook.com/photo.php?v=956977232793

Wouldn't a solution be for the server to set its session cookie for every subdomain, as HTTP-only? For example, set "_gh_sess" for every requesting domain, whether www.github.com, github.com, something.github.com; and ".github.com" as well. If you hit them all, you prevent js from shadowing them.

no, it's already httponly. There is NO WAY to secure your subdomains from such vuln.

Github only sets their cookie for "github.com". What I'm suggesting is that they set multiple http-only cookies: one for "github.com", one for ".github.com", another for every subdomain you access -- "pages.github.com", etc. If there's already an http-only _gh_sess cookie for every subdomain I can put scripts on, I won't be able to shadow it with my own _gh_sess cookie.

You can shadow other httponly cookies too. Any cookies.

Got it, thanks. More detail at [1] mentioned by gingerline above: "the secure flag does not prevent a cookie from being overwritten. In fact, a HTTP site can overwrite a cookie with a secure flag, as long as the domain names are related appropriately. The secure flag provides confidentiality protection but not integrity protection."

[1] http://security.stackexchange.com/questions/12412/what-cooki...

I wonder why GitHub is so popular and TFS services are not. It's so much better than GitHub IMO, can someone explain?

Supports TFS and Git vestion-control

Free collaborative projects for up to 5 people

Can have closed-source projects

Bitbucket supports private repos aswell and works with mercury and Git afaik. The main reason GitHub is popular is because it is popular; it just happened.

Moral of the story: having "www." in your canonical site URL is back in fashion?

this won't help. .site.com will be sent anyway

Not if you don't set it right?

.site.com are sent for any subdomain on site.com, www is not protection

* and even not by httpOnly (they should go first obviously).*

Why is it obvious that httpOnly cookies should go first?

because they can only be set on server side, thus they have more priority

test

What a load of crap. The chances that github doesn't call reset_session are zero which means this doesn't work.

Given the first vulnerability, which stemmed from poor defaults in Rails and Github using said defaults, I wouldn't be surprised if it were affected by this.

Not using attr_accessible is a lot different than not using reset_session after authenticating a log in. It's very easy to forget or not notice a model missing some whitelisting but to roll your own authentication code with zero security investment is just stupid and I would be extremely surprised if GitHub doesn't do it.

> different than not using reset_session after authenticating a log in

if it's obvious for you — you are good at security. But it is NOT a common sense to use reset session

why should it call reset_session, my little sweet troll?

i say more: this vuln worked fine. wait. github is STILL vulnerable. and i have an exploit

You offered no proof that this actually works and being defeated by a reset_session makes it way more likely it doesn't work.

i tried it on me and on friends, it works

want a personal proof? $3000.

ты охуенен.

your posts are so entertaining, keep it up

Окай

Reply on news.ycombinator.com