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.
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.).
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.
Usually there are PCs and mobile platforms on it, handled by more or less naive users... many of them could be / are turned into unsuspecting adversary to attacks.
One should always treat internal devices as potentially compromised.
That just was the right words at the right time :-)
Cheers
All the logs over the years simply show spam from bots idly probing for pirated SIP lines/extensions on our VoIP box, attempts to send mail through our mail server, and open PHP MyAdmin/Django/Wordpress login pages--none of which are present because none of that software's in use.
This is trivial, but you need to be familiar with the environment variables used by bash. unset HISTFILE
$ vi /var/log/*.log
$ kill -9 $BASHPIDIn short, the Medeco lock basically has every deterrent you can put into a lock that the industry knows about. Medeco to Kwikset is like a major payment processor's portal to a Wordpress site with a shopping cart plugin for seeing specialty cat themed oven mitts. You get what you pay for if you high someone that knows what they're doing.
From http://en.wikipedia.org/wiki/Medeco :
> As of 2008, several new methods of cracking Medeco locks has been developed by Mark Tobais and Tobias Bluzmanis and were presented at the DEF CON 2008 and HOPE 2008. A simultaneous public release of a book detailing many of the exploits, called "Open in Thirty Seconds" detailed many of the attacks discovered.
> They further detailed the ability to bump current generation Medeco M3 locks.
> Many Medeco dealers continue to make claims about the Bump and Pick proof nature of their locks, however Medeco has retracted virtually all of its own press indicating such claims.
Furthermore, this particular piece of rhetoric:
> An expert lock smith might be able to pick it in his career, once.
makes no sense. Picking a style of lock once makes the next time easier, not harder.
Easy getting down off your high horse. It might blow your socks off, but I've read that Wikipedia article before. I've actually gone through the whole DEFCON presentation and paper too, where you'll see which locks have the bump mod since 2008. ;) Yet, given that I'm not concerned about the CIA or NSA sneaking in to spike my cookie jar with LSD, I'll stick with my Medeco lock, including the bump mod, to make it a little more difficult to waltz into my warehouse. If you want in, you'll have to take the door or wall down, which is the point of a quality lock.