6 ms·

Hack Back – A DIY guide to those without the patience to wait for whistleblowers

293 points by anirudhrata 12y ago

bjpirt 12y ago
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.
Eiriksmal 12y ago
This 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.
- deleted 12y ago
  [deleted]
- KJasper 12y ago
  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)
  - abluecloud 12y ago
    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.
    - KJasper 12y ago
      That was exactly my thought so there is no "lucky" after all. At least not for sure.
      - Eiriksmal 12y ago
        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.
  - Eiriksmal 12y ago
    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.
    - zerohp 12y ago
      > 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
      - yourad_io 12y ago
        Or kill the shell from within, avoiding history write: $ vi /var/log/*.log $ kill -9 $BASHPID
    - PeterisP 12y ago
      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.
- ztnewman 12y ago
  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.
  - Eiriksmal 12y ago
    "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."
  - spydum 12y ago
    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.
    - annnnd 12y ago
      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.
deleted 12y ago
[deleted]
samcrawford 12y ago
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).
orf 12y ago
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.
- EliRivers 12y ago
  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.
  - orf 12y ago
    No, it will stop. I think the tools and general lack of awareness are a big factor - those will both undoubtedly change.
    - Kalium 12y ago
      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.
      - 12y ago
001spartan 12y ago
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.
hummel 12y ago
We still looking for the infamous password that would allow to reverse engineer the software and found the C&C!
kevin_thibedeau 12y ago
"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.
- maaarghk 12y ago
  haha, you're not thinking like a hacker :) purchase it using stolen bitcoin. :P
- enraged_camel 12y ago
  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.
  - onewaystreet 12y ago
    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.
- newaccountfool 12y ago
  He also mentions using a hacked WiFi, your pretty safe.
  - mentat 12y ago
    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.)
- 12y ago
piffey 12y ago
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.
- ZoF 12y ago
  I think the original paste-bin was posted on Reddit by the same account that posted the finfisher leaks. This is just a mirror.
  - piffey 12y ago
    Ah okay, that makes sense. Thank you.
    - tim333 12y ago
      It was also posted on the writers twitter https://twitter.com/gammagrouppr https://twitter.com/gammagrouppr
  - p00b 12y ago
    Correct. Original link: http://pastebin.com/raw.php?i=cRYvK4jb 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.
- dkyc 12y ago
  Not OP, Ars Technica linked to it a couple of days ago.
- 8ig8 12y ago
  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_diy_guide_for_those_without_the/ http://www.reddit.com/r/blackhat/comments/2d9qba/hackback_a_...
phazmatis 12y ago
Wow, if a damn IT sec company can't get secuiity right, how am I supposed to?
- ki11a11hippies 12y ago
  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.).
jvdh 12y ago
This article has already been submitted 3 days ago under the pastebin link: http://pastebin.com/raw.php?i=cRYvK4jb http://pastebin.com/raw.php?i=cRYvK4jb (https://news.ycombinator.com/item?id=8155177 https://news.ycombinator.com/item?id=8155177)
frede 12y ago
How did he get the php shell started after uploading it attached to a ticket? I did not get this step.
- curveship 12y ago
  The server-side upload code let him put it somewhere where PHP was enabled. So he "started" it by just going to its URL.
weinzierl 12y ago
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.
- idlewan 12y ago
  Or just don't have flash installed.
cellover 12y ago
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 https://www.owasp.org/images/5/58/OWASP_ASVS_Version_2.pdf
pvnick 12y ago
Fyi the torrent can be found at https://netzpolitik.org/wp-upload/finfisher.torrent 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.

293 points by anirudhrata 12y ago

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.

Eiriksmal 12y ago

This 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.

deleted 12y ago
[deleted]
KJasper 12y ago
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)
- abluecloud 12y ago
  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.
  - KJasper 12y ago
    That was exactly my thought so there is no "lucky" after all. At least not for sure.
    - Eiriksmal 12y ago
      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.
- Eiriksmal 12y ago
  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.
  - zerohp 12y ago
    > 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
    - yourad_io 12y ago
      Or kill the shell from within, avoiding history write: $ vi /var/log/*.log $ kill -9 $BASHPID
  - PeterisP 12y ago
    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.
ztnewman 12y ago
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.
- Eiriksmal 12y ago
  "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."
- spydum 12y ago
  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.
  - annnnd 12y ago
    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.

deleted 12y ago

[deleted]

samcrawford 12y ago

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).

orf 12y ago

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.

EliRivers 12y ago
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.
- orf 12y ago
  No, it will stop. I think the tools and general lack of awareness are a big factor - those will both undoubtedly change.
  - Kalium 12y ago
    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.
    - 12y ago

001spartan 12y ago

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.

hummel 12y ago

We still looking for the infamous password that would allow to reverse engineer the software and found the C&C!

kevin_thibedeau 12y ago

"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.

maaarghk 12y ago
haha, you're not thinking like a hacker :) purchase it using stolen bitcoin. :P
enraged_camel 12y ago
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.
- onewaystreet 12y ago
  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.
newaccountfool 12y ago
He also mentions using a hacked WiFi, your pretty safe.
- mentat 12y ago
  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.)
12y ago

piffey 12y ago

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.

ZoF 12y ago
I think the original paste-bin was posted on Reddit by the same account that posted the finfisher leaks. This is just a mirror.
- piffey 12y ago
  Ah okay, that makes sense. Thank you.
  - tim333 12y ago
    It was also posted on the writers twitter https://twitter.com/gammagrouppr https://twitter.com/gammagrouppr
- p00b 12y ago
  Correct. Original link: http://pastebin.com/raw.php?i=cRYvK4jb 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.
dkyc 12y ago
Not OP, Ars Technica linked to it a couple of days ago.
8ig8 12y ago
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_diy_guide_for_those_without_the/ http://www.reddit.com/r/blackhat/comments/2d9qba/hackback_a_...

phazmatis 12y ago

Wow, if a damn IT sec company can't get secuiity right, how am I supposed to?

ki11a11hippies 12y ago
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.).

jvdh 12y ago

This article has already been submitted 3 days ago under the pastebin link: http://pastebin.com/raw.php?i=cRYvK4jb http://pastebin.com/raw.php?i=cRYvK4jb (https://news.ycombinator.com/item?id=8155177 https://news.ycombinator.com/item?id=8155177)

frede 12y ago

How did he get the php shell started after uploading it attached to a ticket? I did not get this step.

curveship 12y ago
The server-side upload code let him put it somewhere where PHP was enabled. So he "started" it by just going to its URL.

weinzierl 12y ago

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.

idlewan 12y ago
Or just don't have flash installed.

cellover 12y ago

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 https://www.owasp.org/images/5/58/OWASP_ASVS_Version_2.pdf

pvnick 12y ago

Fyi the torrent can be found at https://netzpolitik.org/wp-upload/finfisher.torrent 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.