Hack Back – A DIY guide to those without the patience to wait for whistleblowers
data.langly.frThis 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.
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.
typically the infrastructure which is supposed to be "uber sekure" has been well vetted, and is relatively secure.
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.
I was always baffled by the notion of "internal network". Why do so many admins think that it is secure, that the device on it should be trusted more than some random PC on the Internet?
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.
"Small" meaning easy-to-mitigate. I was expecting something along the lines of, "I spent months probing buffer overflows to leak security credentials." Not, "I spent three seconds and nearly fell out of my chair when I realized they don't sanitize database queries."
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)
Once the servers been comped, you can't tell what's been accessed on that machine. You could possibly find out if it accesses other machines within your network (logging depending) - however if someone were to root a public facing server that had a bunch of files on it, you have to assume they've been seen/duplicated.
That was exactly my thought so there is no "lucky" after all. At least not for sure.
And, also, we operate in a low-tech service industry where simply having a database of customers is considered moderately cutting edge. We're not a software company producing hacking tools for evil governments and their puppets. There's nothing interesting on the server for anyone save our competitors. That leads me to logically deduce that the "hacking" attempts the internet-facing servers experience simply fall into the net of trolls searching for more machines to add to their botnets.
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.
Because they never gained root access. I trust the logs in this case because their actions were immediately made known: Access logs show failed login attempts from that ip for a range of usernames, a successful login on the compromised account, then nothing but reams of mail being churned out.
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.
> 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.
This is trivial, but you need to be familiar with the environment variables used by bash. unset HISTFILE
Or kill the shell from within, avoiding history write:
$ vi /var/log/*.log $ kill -9 $BASHPID
The solution for log issue can be a remote specialized machine that does append-only logs and nothing else - it should be possible to lock down such a service so that if you're compromised, then at least you have unaltered data from the initial part of the attack, before they disable all logging.
I 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.
Every 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.
4) Security testing becomes a norm and there will be easy to use tools/services. Regulation doesn't help here. Everyone makes mistakes, the better developers just make less.
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.
No, it will stop. I think the tools and general lack of awareness are a big factor - those will both undoubtedly change.
I have my doubts. Think about lock design - it's been known for a long time how to design decent locks, and yet in the US we still use these crappy cylinder locks.
As someone who doesn't know, how do we design decent locks? Which locks use the decent design?
Read up on Medeco. An expert lock smith might be able to pick it in his career, once. That's an $80 lock. Now look at Kwikset from HomeDepot for $11. An amateur can pick that lock in 2 seconds flat.
In 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.
You sound like a true believer in DRM. Just like with DRM, a lock doesn't provide all that much security because all of the information necessary to break it is encoded in the lock.
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.
>Furthermore, this particular piece of rhetoric: >> An expert lock smith might be able to pick it in his career, once.
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.
Web developers are making these errors because of the high demand for cheap web devs churned out of "learn to code!" bootcamps coupled with the fact that the people writing the checks don't understand security.
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.
>Web developers are making these errors because of the high demand for cheap web devs churned out of "learn to code!" bootcamps coupled with the fact that the people writing the checks don't understand security.
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.
Thank you - dunno why I just needed that said out loud - I shall stop worrying about how to compete for or educate such people - thank you.
That just was the right words at the right time :-)
Cheers
Honestly, I find it's bad tools. Every database lib I've worked with tried to bully you into using prepared/compiled queries or full ORM queries, but occasionally you still have to break out and smash strings together to build queries.
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.
Saying XSS is not serious is encouraging those bad behaviors; XSS are actually serious flaws when properly exploited (http://beefproject.com/).
Sure it's serious in its own way, but not on the same level as SQL injection.
As someone interested in getting into penetration testing, this is a fascinating look into how techniques that have been around forever can be used to get into anything. Disregarding the scale and target, this isn't anything groundbreaking. It's just the fact that a company like Gamma was vulnerable to simple things like this that is surprising.
"I recommend using servers you've hacked or a VPS paid with bitcoin to hack from."
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.
My understanding is that a sufficiently motivated state can find any computer criminal. It's just a matter of following them long enough until they slip and make an opsec mistake.
Usually the mistake is talking too much. Jeremy Hammond (Stratfor hack) had really good technical opsec but made the mistake of talking about his IRL exploits to Sabu which led the FBI to connect his online identity to his IRL political activism. Had he kept his mouth shut he probably would have never been caught.
haha, you're not thinking like a hacker :)
purchase it using stolen bitcoin. :P
If you use cryptocurrency you've mined yourself it will be anonymous, assuming you've proxied your miners through something to conceal their IPs.
I believe the correct approach is to share your tools and services freely in such a way as they can be configured and used from public computers (e.g. Apple Store, or a recently purchased craigslist laptop from an open wifi access point). The general idea is that you prepare your tools at your leisure, and then invoke and target in anonymity.
I think the implication is that you do mining via whonix/TOR and then use those funds. And then as you aquire more computers you use those to generate more bitcoins for more VPSs.
He also mentions using a hacked WiFi, your pretty safe.
There are a ton of opsec mistakes one can make that a nation state could track. How did you get to that hacked wifi location? Any cameras on the way? How many times did you use it? Shared radius from where you live / work / have ever used a credit card? The pervasiveness of tracking by camera of people / cars / etc makes this very hard to pull off (and I've given it a lot of thought as an infosec professional.)
Buy the bitcoins with cash?
How was this article found? You go up to the directory and there is a whole host of cruft. Not discounting the likelihood that this is how the attacker was successful -- none of it's bullshit anyways -- but seems odd that someone would just stumble upon this. Can't find out much about that site either other than the Datalove reference that makes it seem like some Telecomix thing. Anyways, interesting submission. Shows how quickly an attack can escalate and what easy tools are available for you to test your own sites for vulnerabilities.
It was posted within the last 24 hours on Reddit (/r/blackhat). Here's the thread...
http://www.reddit.com/r/blackhat/comments/2d9qba/hackback_a_...
I think the original paste-bin was posted on Reddit by the same account that posted the finfisher leaks. This is just a mirror.
Correct. Original link: http://pastebin.com/raw.php?i=cRYvK4jb
"OP" here is just mirroring (presumably for increased traffic) instead of linking to the true OP on pastebin.
Ah okay, that makes sense. Thank you.
It was also posted on the writers twitter https://twitter.com/gammagrouppr
I was looking into the peers seeding the torrent. There I found a host langley.fr seeding. That is how I got to the article.
Not OP, Ars Technica linked to it a couple of days ago.
Fyi the torrent can be found at https://netzpolitik.org/wp-upload/finfisher.torrent, and the encrypted archive which possibly contains the server software (which the author has asked volunteers to help crack. See section 7.) is at finfisher/www/FinFisher/Engineers7117/FinSpy/Images/FinSpy-PC+Mobile-2012-07-12-Final.zip. That file alone makes up 31.4gb of the 38.7gb total size.
Interesting 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).
If you are as curious as I am and decide to browse langly.fr for other interesting stuff: Don't click on links that say "...dont clik" and if you absolutely must, turn down the volume or put down your headphones and be prepared to restart your browser.
Or just don't have flash installed.
Very interesting read. Amazing to see where information gathering and simple hacking techniques can lead you...
Pilots have checklists, web developers have Application Security Verification Standard (2014)! https://www.owasp.org/images/5/58/OWASP_ASVS_Version_2.pdf
We still looking for the infamous password that would allow to reverse engineer the software and found the C&C!
How did he get the php shell started after uploading it attached to a ticket? I did not get this step.
The server-side upload code let him put it somewhere where PHP was enabled. So he "started" it by just going to its URL.
Wow, if a damn IT sec company can't get secuiity right, how am I supposed to?
I can incorporate tomorrow and call myself an IT security company.
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.).
This article has already been submitted 3 days ago under the pastebin link: http://pastebin.com/raw.php?i=cRYvK4jb (https://news.ycombinator.com/item?id=8155177)