A story about a breach using a backup archive!
Backup is the first rescue line a company uses to handle a breach. But what happens if the backup is on the attacked server? And even worse, what happens when the backup file is the entrance vector for the hacker? A Russian hacker shared a story on a dark web blog about how he breached a company using a backup file.
The entire attack chain is presented as: fuzzing → backup → code analyzing → admin login → upload
Why break down the door - when the key is under the mat?
The attack starts with reconnaissance. The hacker scans subdomains and collects a list of hosts. The next stage is to feed the list to an app that scans for known vulnerabilities and go for a walk—maybe something will be found! And oh, miracle!
While he read the logs, he saw that an interesting archive with the inscription api.tgz was found. When cyber security experts talk about the smell of website security, they are referring to a file that should not be there. That means either bad development practices or bad deployment habits.
Not so surprisingly, after downloading and unpacking the archive, it was the source code of the backend of the applications. The backup contained - passwords, access to the database, and all the good stuff.
A security researcher will probably stop here and report it, but as the famous phrase, “Anything that is not remote code execution (RCE) is not a bug.”
“Show me your code, and I’ll tell you how you were hacked!”
Digging through the source code, the hacker came across a file where the first user is registered—he is also the Admin—and there is also a login and password.
Using those credentials, he managed to access the admin panel as an admin!
Then, there was a process of studying the application. In fact, it is an administrative panel for editing articles, and there was also a photo gallery section—it will be possible to upload something anyway.
“Remember Neo! Pictures do not exist!”
The Admin can upload images in the images section. The hacker tried to upload a simple PHP oneliner to check for filtering. As expected, there are no file controls.
As a result, he managed to get an RCE. We can close the project! Why?
After examining the server, he realized that the entire infrastructure and all applications are held on this server. If he “put out” the server, everything would stop!
Any junior “pentester” will be shocked by that, to put it mildly, and a “black hat” will be delighted with such a find. All the source codes and all the databases were on this server.
Well, now that’s it: all applications are compromised, RCE is there, and there are no backups. -> Ransomware.
Conclusion!
The primary and most common mistake system administrators make is using the server as another computer in the company. This mindset leads to storing backup copies, adding control files, running commands as root, etc. Secondly, having the source code of one application application on the server can ultimately compromise the entire infrastructure without bothering with complicated attack vectors. And finally, DevSecOps will save this company a lot.
The ransomware amount was not reported.
#StaySafe