Hack Back – A DIY guide to those without the patience to wait for whistleblowers
1–10 of 62 posts
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#2I found this a frank and pretty fascinating inside view of how hackers operate in the wild.
Thanks to whoever it was for publishing it. It's a must-read for anyone running any kind of IT services. Well worth running through these steps on your own systems.
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#3This article was quite fascinating. It's impressive that a series of small security holes culminate with the release of sensitive software. It's equally interesting that all those security tips we roll our eyes at, as we've heard them one too many times, they really matter! Don't write crappy code: Don't trust user input. Don't do client-side only checks on any information being processed by the server. Etc. Etc.
The Linux root exploit tools mentioned will be of assistance to me in securing our own servers. We've been "hacked" once before (the server admin had created a user named `server` with the password `server` some time in ancient history and left open a setting in SMTP that permitted the bot to send massive amounts of spam masquerading as thailandinternet54@yahoo.com from our mail server. Classy.) and got lucky that the bot's sole purpose was to send spam and not take control of the server and dump its sensitive database materials to a hard drive somewhere in Asia.
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#4[deleted]
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#5Interesting stuff, a nice level of detail.
Phrases like this say a little about his/her personality: "At this point I can see the news stories that journalists will write to drum up views ..."
Also interesting to note just how much other stuff is exposed on data.langly.fr (mostly related to Snowden, security, and a bunch of pirated content).
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#6This article was quite fascinating. It's impressive that a series of small security holes culminate with the release of sensitive software. It's equally interesting that all those security tips we roll our eyes at, as we've heard them one too many times, they really matter! Don't write crappy code: Don't trust user input. Don't do client-side only checks on any information being processed by the server. Etc. Etc. The…
[deleted]
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#7Every time I find or see an SQL injection issue I get angry. It's 2014, why are web developers still making the same basic mistakes? SQL injection is a fixed issue. There is no excuse.
Same with XSS, although not as serious it's staggeringly common.
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#8This article was quite fascinating. It's impressive that a series of small security holes culminate with the release of sensitive software. It's equally interesting that all those security tips we roll our eyes at, as we've heard them one too many times, they really matter! Don't write crappy code: Don't trust user input. Don't do client-side only checks on any information being processed by the server. Etc. Etc. The…
How would you know for sure that it didn't dump the database to somewhere in Asia once "they" have your server under control? Serious question, because how can you trust the logs? (Mind you, I'm not that technical)
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#9Every time I find or see an SQL injection issue I get angry. It's 2014, why are web developers still making the same basic mistakes? SQL injection is a fixed issue. There is no excuse. Same with XSS, although not as serious it's staggeringly common.
I believe it is essentially a function of the skill distribution and price of developers.
There will always be a spectrum of skill level; there will always be very inexperienced, low-skilled developers just about able to knock together something that works, but is susceptible to SQL injection. These inexperienced developers will charge less, and will get work, so there will always be an endless supply of new developers making new sites that are susceptible.
I can think of three ways (and various combinations/subsets of them) it would ever stop:
1) The tools themselves to somehow fall out of favour and be replaced with tools that make it harder to make this kind of mistake
2) Developers become compelled to undergo regulation and trade guilds or related, such that their skill level just to do business exceeds the aforementioned minimum
3) Websites (or a subset thereof) become regulated such that they are inspected/audited for this kind of thing, which would compel businesses to pay more to hire competent developers.
I don't see any of this happening any time soon, so there will be a perpetual supply of new websites containing well-known vulnerabilities. Forever. This will never, ever stop.
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#10This article was quite fascinating. It's impressive that a series of small security holes culminate with the release of sensitive software. It's equally interesting that all those security tips we roll our eyes at, as we've heard them one too many times, they really matter! Don't write crappy code: Don't trust user input. Don't do client-side only checks on any information being processed by the server. Etc. Etc. The…
None of those were 'small security holes'. SQL injection on your website? Unnecessary ports open and known vulnerabilities on a public facing server? This is embarrassing for a company that apparently focuses on security.