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.
The problem is, there is almost always some "trivial" system (public web site, severely outdated wordpress blog, or worse) that some poor fool in marketing/product "HAD TO HAVE YESTERDAY". The admins knew it wasn't mission critical, and would only be "temporary". So they spent minimal effort to set it up, skipped over all of the process and security hardening they would do for a proper release, and left it.
Of course, we know what happens: some hacker finds the exploits, then pivots to explore the internal network.
You will find most big enterprise-y shops build networks with hard exteriors, and soft interiors. Very few of their security plans are capable of a threat from inside the network.
If it had been done for more nefarious purposes, wouldn't "they" have been more discreet, carefully wiping traces of their activity from the logs? Not doing something that immediately throws red flags like sending thousands of email messages?
In all honesty, I certainly don't have the skills to detect an NSA-level attack that doesn't involve brute-force attempts on accounts. I can erase or alter logs, but then there are logs logged of me vi'ing logs, so I erase the shell history, but then that gets logged when I log out. It's a weird loop I don't know how to defeat, but some people do.
The heart of our problem was a misconfigured sshd that permitted remote logins (not root logins) on all user accounts. A disaster in the making. We got lucky that it was a spammer who compromised the system and not a competitor.
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.
Same with XSS, although not as serious it's staggeringly common.
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.
There is no reason not to have these tools if you have so many easy to use ones available for intrusion.
I happen to have known a local startup that was working on such a service: intrusion/security testing SaaS. Their model was something like giving a simple dashboard/report that the management could easily understand and act on if needed. They also thought about having a badge that the verified sites could display, as a proof towards their users that they are secure. Unfortunately they, and their VC, screwed it up big time.
Also, while basic SQL injection issues are "fixed" if you are an experienced dev, CVEs about SQI in libraries meant to protect you from SQI are common. No doubt there are lots of zero day SQI exploits for every SQL library out there.
Cheap developers with no senior oversight and code review? No [automated] security testing to catch the basics?
You're getting what you deserve if this is the only level of talent and organization you want to put on task.
And when that happens? You can't help but notice that nobody provides you with a simple "EscapeSql" function you can use, so I always have to roll my own (or do horrible things with dynamically constructing the parametrized query and the parameter array in parralel).
I wouldn't be surprised if many developers just throw up their hands and skip sanitizing.
Not a good idea considering Bitcoin isn't anonymous and a sufficiently motivated state can back track to an electronic purchase of bitcoin tied to your identity.
purchase it using stolen bitcoin. :P
http://www.reddit.com/r/blackhat/comments/2d9qba/hackback_a_...
"OP" here is just mirroring (presumably for increased traffic) instead of linking to the true OP on pastebin.
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).
Pilots have checklists, web developers have Application Security Verification Standard (2014)! https://www.owasp.org/images/5/58/OWASP_ASVS_Version_2.pdf
Also, there's the distinction between security software (an app that accomplishes a security-related goal) and software security (an app that is resistant to malicious tampering). Coders for security software can often suck at software security (openssl, e.g.).
