Last week on Thursday, I read about the release of a fix for a new Apache 0-day vulnerability that was already exploited in the wild. At first I was a bit concerned, because I run quite a number of VMs with Apache on it. Fortunately, it turned out pretty quickly that my servers were not affected. However, after checking my web server logs, I noted that if my systems had been vulnerable, I would have been hacked long before I read the first article in my RSS stream. Hackers don’t sleep, the press is slow, and I’m even slower!
First a few words about not being affected: It turned out that the bug in question that allowed a directory traversal attack to get out of the web root directory was only introduced in the latest version of Apache. Fortunately, I’m running Ubuntu 18.04 and 20.04 on my servers and the latest version has not yet made it there. And even if it had, I would have still been safe, as the bug was only exploitable if an admin had changed the default configuration. I didn’t. Still, I’d say this was a close call.
I first noticed a report about the threat on Thursday afternoon last week in my RSS stream. Checking my RSS stream later-on for the first article on the topic, I saw that there were a number of earlier articles that I skipped, and that the first one was from Wednesday, mid day. When I looked into my server logs, I saw that first web crawlers started looking for vulnerable hosts long before then. The first I could find in my logs was from Wednesday morning, 5:15 am. In other words, if my systems had been vulnerable, the game would have been long over even if I had caught the first press report. Close call or not, that’s the alarming thing in the first place.
It’s also interesting to see what the crawlers were looking for: The vulnerability they were trying to exploit is a directory traversal attack to get out of the web root directory. And here are some interesting targets they were looking for:
GET /cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd GET /cgi-bin/.%2e/%2e%2e/%2e%2e/[...]/%2e%2e/etc/hosts POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh [...] inserted by me to shorten that path
The ‘passwd’ file is obviously interesting for attackers, as it contains the names of the user accounts on the server. The encrypted passwords, however, are in the ‘shadow’ file which is only readable by root. Reading that file to be able to brute force the passwords would have required yet another configuration blunder from the admin. The ‘hosts’ file is also interesting, as it would have told an attacker a bit about the local network. The HTTP POST for ‘sh’ is probably the most nefarious request, as the attacker tried to put a new shell executable in place to get a backdoor.
So let’s say I would have been affected by this 0-day, what would I have done? Since the logs clearly show that break-ins appeared already, I think the only way forward would have been to immediately take the VMs offline, create a backup for a post-mortem, and then to restore the system partition and user home directory from an earlier backup. Fortunately, I do keep backups of system partitions so I could have done that with relatively little effort. Still, data might have leaked, so that is only one part of the story. Fortunately, I was not affected, but it shows that there are no guarantees and we are all walking on thin ice here.