Don’t
duck at the latest mention of Apache: Two critical bugs in its HTTP web
server – HTTPD – need to be patched pronto, lest they lead to attackers
triggering denial of service (DoS) or bypassing your security policies.
Apache, the open-source software foundation behind the Log4J logging library that’s been making for so many Log4Shell
headlines, on Monday put out an update to fix the two bugs in HTTPD,
which is a web server that’s right up there with Log4j in its ubiquity.
Both vulnerabilities are found in Apache HTTP Server 2.4.51 and earlier.
The first issue (CVE-2021-44790) is with the function “r:parsebody” of the component “mod_lua Multipart Parser.” As the VulDB
vulnerability database describes it, “manipulation with an unknown
input leads to a memory-corruption vulnerability” that “is going to have
an impact on confidentiality, integrity and availability.”
VulDB also noted that the issue is reportedly easy to exploit: It is
possible to launch the attack remotely. The exploitation doesn’t require
any form of authentication.”
Although technical details are known, there’s no available exploit –
at least, not yet. As of Monday, the vulnerability’s structure had
suggested that an exploit would fetch between $5,000 and $25,000, VulDB
estimated.
In a Tuesday writeup
of the two CVEs, Sophos principal security researcher Paul Ducklin said
that the two bugs could leave servers at risk of some serious hurt.
“These bugs might not be exposed in your configuration, because they
are part of optional run-time modules that you might not actually be
using,” Ducklin noted. “But if you are using these modules, whether you
realize it or not, you could be at risk of server crashes, data leakage
or even remote code execution.”
On Monday, Apache published these details for the two CVEs in its changelog:
- CVE-2021-44790:
Possible buffer overflow when parsing a carefully crafted request in
the mod_lua multipart parser of Apache HTTP Server 2.4.51 and earlier.
Apache said that its HTTPD team hasn’t seen an exploit, but “it might be
possible to craft one.”
- CVE-2021-44224:
Possible NULL dereference or Server Side Request Forgery (SSRF) in
forward proxy configurations, likewise in Apache HTTP Server 2.4.51 and
earlier.
On Tuesday, CERT-FR sent out an alert about the issue.
CERTFR-2021-AVI-972 : Multiples vulnérabilités dans Apache httpd (21 décembre 2021)https://t.co/SB0gpBJcd4
— CERT-FR (@CERT_FR) December 21, 2021
HTTPD: It’s Here, It’s There, It’s Every-Bleeping-Where
Ducklin noted that Apache’s brawny server has “more than 3,000 files
totaling close to a million [lines] of source code,” making it not only
“a large and capable server,” but one with “myriad combinations of
modules and options, making it both powerful and dangerous at the [same]
time.”
These bugs shouldn’t get lost amidst the Log4J brouhaha, Ducklin
said, given that “you almost certainly have Apache HTTPD in your network
somewhere. Just like Log4j, HTTPD has a habit of getting itself quietly
included into software projects, for example as part of an internal
service that works so well that it rarely draws attention to itself, or
as a component built unobtrusively into a product or service you sell
that isn’t predominantly thought of as ‘containing a web server.’”
Sean Nikkel, senior cyber-threat intel analyst at Digital Shadows,
noted that a quick peek at the Shodan search engine reveals that there
more than 3 million public devices running some version of HTTPD as of
this writing, meaning there’s a chance that HTTPD is running on some
internal or otherwise non-public instances.
That could mean that this vulnerability “may also be just as far-reaching as log4j,” Nikkel said.
The silver lining: “Apache dissuades people from using the mod_lua
functionality in several circumstances due to the amount of control it
potentially has,” he told Threatpost on Wednesday. In fact, Apache has
this cautionary note on its mod_lua site:
This module holds a great deal of power over httpd, which is both a
strength and a potential security risk. It is not recommended that you
use this module on a server that is shared with users you do not trust,
as it can be abused to change the internal workings of httpd.
However, Nikkel said, that doesn’t rule out the human factor: “There’s always the chance a server was misconfigured,” he noted.
Kudos to Patchy Apache
Used to be, the name “Apache” was presumed to be a pun for building
“patchy” software, given how the open-source software was built on
existing code and a bunch of software patches (but that’s not really how
it got its name, according to the project’s official documentation).
Still, kudos to Apache for being extremely patchy of late, security experts said.
“It should be noted that Apache has done an exceptional job
addressing the vulnerabilities that have been discovered in their
products this year,” Hank Schless, senior manager of security solutions
at Lookout, commented to Threatpost via email. “They’re pushing updates
as soon as possible, and making it widely known that patches are
available for teams. It’s important to keep in mind that software
vulnerabilities are inevitable – especially these days when applications
are so complex and users expect constant updates from the developers.”
OK, gratitude aside, could we just catch up with all these issues,
already? That’s what Yaniv Bar-Dayan, CEO and co-founder at Vulcan
Cyber, wants to know. “The integrated IT security industry is not very
good at effectively mitigating known vulnerabilities, and Apache
vulnerabilities are no exception,” he told Threatpost via email. “Our
cyber-debt specific to Apache software was substantial prior to
Log4Shell or these new HTTPD web server vulns.”
He pointed to CVE-2020-1938, the so-called “Ghostcat” security bug in
the popular Apache Tomcat web server that cropped up in 2020, as an
example. The bug led to a working exploit leaking on GitHub that made it a snap to exploit.
That same bug, in the Apache JServ Protocol (AJP), “has been getting a
lot of interest on Remedy Cloud almost a full two years after it was
disclosed,” Bar-Dayan said.
If Apache were the only software the industry had to worry about
securing when vulnerabilities are found, that would be manageable, he
said. But no: According to NIST, 2021 will be another record year for
new vulnerability disclosures, Bar-Dayan continued.
“We need to do much better as cybersecurity pros to identify the
vulnerabilities that matter to our businesses and organizations, by
assessing and prioritizing associated risk,” he said. “Then we need to
take control and orchestrate the mitigation effort while measuring our
ability to drive cyber-hygiene and attain acceptable levels of risk.”
This Is a Priority Patch
Schless urged IT teams to address the CVEs immediately, prioritizing
anything that’s publicly accessible or web-facing. “These assets are the
ones that attackers will scan for in order to find vulnerable systems
and exploit the vulnerability,” he said.
After that, security teams should then move on to assessing and
addressing internal servers and applications to which only employees
have access, he added.
“The scope of impact is likely more limited than what we’ve seen
recently, but that shouldn’t change the urgency with which the CVEs are
patched,” Schless recommended. “If attackers aren’t yet in a vulnerable
environment, they will be scanning the internet for vulnerable software
using HTTPD. However, if the attacker has already made their initial
entry and is performing reconnaissance on the environment, they will
likely try to locate vulnerable internal assets. This highlights the
importance of understanding how every user in your infrastructure
accesses and interacts with your apps and the data stored in them.”
Nikkel noted that support teams that might be stressing over yet
another patch might wring some solace out of the fact that there are
“some conditions and mitigations to this, so it may not apply to all
installations.”
Still, given that “these are typical web services deployed facing the
internet,” the “patch ASAP” rule yet again applies, he said.
_Image courtesy of Tom Thai. Licensing details. _
