Six Ways a Russian Hacker Attacked My Website
Until today, the "russian hacker" seemed like a piece of news-hyped fantasy. It turns out, that just isn't the case. They're real. They've attacked me, and they can attack you.
I want to be very clear at the head of this, this article features REAL links to this russian hacker's files and everything I was able to trace back to him. I did not candy-coat anything at all. If you're uncomfortable clicking those links, don't. If you choose to click the links, use a VPN, avoid running his files on your computer, and be safe. I'm not responsible for anything that happens if you interact with his stuff.
As you may have guessed after seeing my intro image, the hacker attacked me with injections through an input on my webpage. Put simply, he typed code into a search bar to see if he could get my server to do what he wanted it to do instead of what I was telling it to do. Had I not been properly sanitizing the data I was collecting from this input, he would have been successful.
Now, I'm not going to dance around what happened or try to tell you anything in an abstract way. I think it's important to know what hackers are trying these days so we know how to best protect ourselves. So, I've decided to include an actual screenshot of the "searches" this hacker typed into my search bar here.
You can ignore the 0's at the end of each line and the "groupSites0" at the beginning of each line. Those are search filters that have nothing to do with the malicious aspect of each of these searches. Let's get to the meat of these attack methods.
Attack #1: "etc/group" file searching
"etc/group" files are something I just learned about, and that's part of the reason this article is listed as a "discussion" piece. I'll tell you what I know, and please let me know in the comments if you have more to offer. To my knowledge, this hacker was assuming I use a Linix/UNIX operating system for my server. With Linix/UNIX operating systems, etc/group files contain a list of all users that have permissions for the server, which would be a great thing to have if you were trying to pretend to be me and gain access to my backend. The "../" here just means that he's trying to access parent directories within my backend's filesystem. That's not hugely relevant to the attack method here.
Attack #2: FTP file injection
This is by far my favorite attack that the hacker used. He was trying to upload a file to my server from his own, but he wasn't counting on me recording his searches for database backup purposes. By trying to connect his FTP to my server, he gave me access to his files. You see that URL in line 671 above? That's his real FTP, and you can visit it at ftp://ref:ref@dahli.rosinter.ru:21, though I'll save you the trouble if you are understandably wary. I'm including a screenshot of his files available at that link here.
He has a lot of files about a company called Qlik, and his FTP's parent domain either is or is pretending to be a Russian food company. That test.txt file you see there is what he was trying to upload to my server. What's in it? Nothing actually harmful, just a bit ominous.
Attack #3: "phpinfo" probing
phpinfo basically tells you everything about my PHP settings. It'll tell you what version of PHP I'm operating on, how long I let scripts run for before automatically terminating them, what environment variables I'm trying to hide from prying eyes, and a ton of other juicy goodies. But really, what the hacker is looking for here is just to see whether he can get any info out of me at all. Before trying to figure out what my thousands of users' passwords are, it's easier to ask for phpinfo to see if I'm even vulnerable to an attack in the first place.
Attack #4: Base64 injection
This one's another phpinfo probe in disguise. Base64 strings are usually used as the text-formatted version of images, but this one is the text format of a PHP file. And when you decode data:;base64,PD9waHAgcGhwaW5mbygpOyA/Pg==, guess command you get? That's right, <?php phpinfo(); ?>. Feel free to try it yourself here.
Attack #5: Further "etc/group" file searching
The attacker had no luck with his first "etc/group" file search, so he figured it'd be worth one more go in a different directory. No luck there either, but nice try.
Attack #6: w;w;w
I actually don't get this one. It almost seems like he's trying to set write permissions for himself? I'd love if the community could chip in in the comment section to let me know what this could be.
The Scariest Part...
I timestamp every search that goes into my searchbar. Every single one of these six searches were executed within a timespan of 30 seconds (from 6:36:32 AM through 6:36:59 AM). That means this person has this whole process automated. He goes from site to site, poking around to find any holes that he can exploit, and when he finds one, he knows plenty of ways to take advantage and get what he wants. And he does it all through VPN connections that don't trace back to him. If you're interested, here are the IPs he used:
- 82.150.140.160 (not blacklisted, in Amsterdam, Netherlands)
- 79.170.40.224 (blacklisted, in London, UK)
- 79.170.40.225 (heavily blacklisted, in London, UK)
Please use this as an opportunity to learn and take caution with your development. Not everyone plays by the rules.
--
Oldest comments (30)
this content didn't make me to yell. thanks nastyox for some fresh piece of content.
Fortunately my security was tight, so they all failed- but it is very disquieting that people actually dedicate themselves to this type of thing. Thanks for the follow by the way :)
What do you recommend such as a web security steps or configurations that you recommend to keep my website safe? Is coded in php.
There are a lot of things you can do. Some basic ones are:
Super helpfull!! Thanks ❤😊
Btw I didn't know that sha512 exists 😂😂
<script>alert("haha");</script>
Hi @nastyox,
Do you use only PHP or do you have an API with TLS and your application has some SPA on the frontend?
it's not an SPA, but there's a frontend with an internal-facing API which we don't release to the public
Thanks for the quick reply @nastyox
This post is so nice, thank's for sharing the whole process, useful! And btw bravo for your monitoring.
1) the FTP might not be his. It was pretty easy and common in the past to search for anonymous writeable FTP servers, FTP servers with leaked credentials (accidentally left in source code on github or elsewhere) and to misuse them as an attack vector.
2) the w;w;w might be an attempt to call a "w" command on linux which displays list of active users. Like here:
user@host:~# w
20:19:41 up 218 days, 13:22, 1 user, load average: 0.09, 0.08, 0.02
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/1 111.222.333.444- 20:18 5.00s 0.04s 14.70s mosh-server new -c 256 -s -l LANG=en_US.UTF-8 -l LC_CTYPE=UTF-8 -l LC_ALL=en_US.UTF-8
It usually is a good idea to start with a simple payload like "hack_test". Proving you have remote file upload for a less malicious file is a good way to confirm the vulnerability exists before properly exploiting it and uploading say a reverse shell.
You should play with some Honeypots
This is exactly what I thought when I noticed the attacks.
ну да, с русскими надо осторожней)
Just Decoupling your website Front End from the api , can make it better . there will be fewer option for him to capture any secret data.
Awesome, really valuable inforamtion.
That was a very interesting reading! The part that actually made me laugh was 'By trying to connect his FTP to my server, he gave me access to his files.'. It seems a rookie hacker
Hey, thanks for sharing all the details of the attack, even though he didn't use any especially clever, still good to be reminded of what could go wrong.
Being Russian myself, I don't think his nationality has much to do with the contents of your post though ;-)
OMG! This is so scary and also, it seems basic. Even when I was not aware of some of the methods. I guess I will dig a little on cyber security... Thanks for sharing!
A very confident rookie