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.
Hack Back – A DIY guide to those without the patience to wait for whistleblowers
31–40 of 62 posts
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#32Earlier quoted context omitted.
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?
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#33How 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. Show…
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.
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#34This 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)
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.
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#35This 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.
"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."
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#36Earlier quoted context omitted.
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.
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#37"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.
He also mentions using a hacked WiFi, your pretty safe.
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#38If 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.
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#39Every 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.
Saying XSS is not serious is encouraging those bad behaviors; XSS are actually serious flaws when properly exploited (http://beefproject.com/).
Re: Hack Back – A DIY guide to those without the patience to wait for whistleblowers
#40"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.
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.