How I hacked Github again(homakov.blogspot.com) |
How I hacked Github again(homakov.blogspot.com) |
Friends don't let friends code in Fails frameworks.
On the flip side, you could go about doing what you're doing under the presumption nobody is maliciously targeting your user base. In this scenario, it's possible you have a couple bad actors that see a net benefit greater than your bug bounties and are silently stealing and selling supposedly secure code from your users. You could be supporting a hacker black market where they sell and trade codebases to popular online sites. Imagine how easy it would be for them to find vulnerabilities in these sites if given access to the source code.
That, my friends, would be a catastrophe.
That's the beauty of bounties, it allows people to decide whether they want to do the right thing or not, if there was no bug bounty more people are just tempted to exploit the bug.
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.
$4000 !? Wow, I'd love to be able to make $4000 on the side just doing what I love.
> Interestingly, it would be even cheaper for them to buy like 4-5 hours of my consulting services at $400/hr = $1600.
This sounds like a pretty clever strategy for marketing yourself as an effective security consultant.
EDIT: $4000!? wow. so money. such big.
Can anyone recommend some reading material or some first steps I can take to work towards moving to a more security-focus career?
Thanks.
http://www.matasano.com/matasano-square-microcontroller-ctf/
Is there an easy way to see what vulnerabilities other websites have had and fixed, and to check if your site has them as well?
Maybe it's just me, but asking for donations after saying you bill clients at $400/hr seems weird to me. I wish I could bill at that rate.
There were always people complaining "Add a donate address"
Now "why you added a donate address". Oh, Internet.
And that's before legal costs and possible restitution.
</jokeruiner>
(At least that's how I imagine it must work. I've never consulted.)
> Oh my, another OAuth anti-pattern! Clients should never reveal actual access_token to the user agent.
From what I understood by reading the OAuth RFC is that front-end intensive applications (a.k.a. public client) should have short lifespan access tokens (~ 2 hours) and the back-end takes care of reissuing a new access token when expired.
Can someone clarify on how to make a those calls from a front-end application without revealing the access token?
http://2.bp.blogspot.com/-xqPTMgxhYmY/UvUCrsc9C8I/AAAAAAAADk...
If it's something you're interested in, go for it. I just worry that people see this like the promise of gold in a faraway land and go rushing in, not thinking about the real distribution of success.
I see that your a sysadmin so if network hacking is more you speed I would download Metasploit[2] and start hacking old linux or windows distros.
[0]http://www.amazon.com/The-Web-Application-Hackers-Handbook/d... [1]http://itsecgames.blogspot.com/2013/07/bee-box-hack-and-defa... [2] http://www.metasploit.com/
https://github.com/github/rails
http://www.kalzumeus.com/2013/06/17/if-your-business-uses-ra...
> 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.
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?
What do you think makes Github that much better than all the rest?
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.
I think that might be the rationale...or it might just be that he's found himself in a position where he can collect bounties AND donations :).
Just a quote while we're at it..
>> We make expand and then defense it.
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.
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...
It's no guarantee, of course. :)
Personally, I think he'd make more money at $400-600/hr if he could also get some kind of manager to handle the interactions with clients; it doesn't seem to be what he enjoys, or is particularly good at.
(I've had drinks with him before, so probably the most effective way to accomplish my goal is to buy him drinks when I'm in town.)
But abcd_f's comment is right about one-off 4-hour projects vs. long-term contracting. Non-billable time overhead spent on finding clients, negotiating contracts, mentally switching projects, or just sitting idle can negate the benefits of a high hourly rate.
At any case, I hired him fairly recently for a security audit and he worked quickly, and was very effective (he found several important vulnerabilities and reported them in a crystal clear manner). He was also a pleasure to deal with (no bullshit stance, something I find enjoyable).
The 4000 USD for ~20 hours of work were definitely well spent!
Wouldn't it also be wise to keep people like him 'out of the loop', I imagine it's much harder to audit when they have access to internal code/architecture that would be difficult for an outsider to stumble-upon?
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]
[1]: "Ghost Wars" (Steve Coll) pg 505
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...
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.
until that's different it's harder to answer your actual question. my guess, it'll be better but inevitably still have some holes.
It seems to me that it would drastically reduce the surface areas of attack.
Verify.
Important storage can be done 'in the cloud', but you need to audit and verify the cloud vendor is providing the proper controls. Just like you need to do 'privately'.
Not to say that it couldn't be compromised, but your not a target like github might be. If you're working with an enterprise level project with more complex auth and access methods, more users, performance and scaling needs, you'd need a real security implementation.
Completely agree. I'm not doing security, but my hourly is similar, and it was a game changer for me to have someone in a manager-like role working with me. Client relations are a huge time suck, but are also absolutely necessary. If he can find someone (or maybe someone on HN should volunteer), it'd be more than worth it.
BTW My manager takes a flat 15%. I'm much happier, clients are way happier, and my total income has increased as a result—not to mention another person is gainfully employed at something they're good at and enjoy. A win-win all the way around.
I would make this your tagline in some way -
"I will find vulnerabilities. If I don't, I will become a vulnerability to my own body and attack myself until I do!"
You are giving people that you have helped an opportunity to pay you without having any kind of contract with them.
Nothing wrong with that at all.
There's a clearly huge market.
Point, set and match.
He also commented on his site that he "is poor", so it could be that he simply hasn't landed enough gigs @ $400/hr to be in good financial shape yet.
Given a reasonably competent development team, you can usually make a first pass and find quite a number of low-hanging fruit security issues. Everyone makes mistakes, especially when under pressure to get a product out. Once those are gone you can use fuzzing and/or static analysis type techniques to find another set, but after that you get to the point where the bugs start getting quite obscure and require a fairly deep knowledge of how the system works so you can start stringing multiple problems together to get to a real security issue.
Of course this can be offset somewhat by the fact that software is usually a moving target, so if you're security testing a live, active codebase the developers are likely introducing new issues all the time, though hopefully at a reduced rate as they learn from their previous errors.
Get on that before someone filches it!
http://en.wikipedia.org/wiki/Yakov_Smirnoff - referred to as a Russian Reversal
Ok, learned something completely wasn't aware of before.
But, no, no intent to make that kind of joke.