The Bug Report – December 2021

Your Cybersecurity Comic Relief 

Why am I here? 

If you’re reading these words, CONGRATULATIONS! You’ve made it to 2022! And even better, you found your way to ATR’s monthly security digest where we discuss our favorite vulnerabilities of the last 30 days. Feel free to pat yourself on the back, get yourself a nice cup of coffee, tea, LaCroix (you fancy!) or if you’d rather choose violence, you can go straight for the energy drink. And now that we are comfortable and energized, let’s get rolling!  

CVE-2021-43798: Grafana path traversal

What is it? 

Per its Wikipedia entry, Grafana is a multi-platform open-source analytics and interactive visualization web application that is widely used in the industry, with paying customers such as Bloomberg, eBay, PayPal, etc. It was revealed in early December that a path traversal vulnerability allowed an attacker to access local files due to an improper sanitization of “../../../” in its plugin path.  

It also showcases one of the tightest disclosure timelines known to man:  

Who cares? 

Ok, we can hardly blame you for hearing about ANY vulnerabilities except for Log4Shell in the last 30 days.  However, if your organization is using this software, you probably should have followed the disclosure last month, lest your “/etc/passwd” files are now known to the whole internet. Beyond that, there are two interesting points you can ponder while swirling your eggnog in its glass (side-rant on the disgustingness of eggnog redacted). Given how easy it is to exploit, the mere fact of the vendor fixing the bug via their public GitHub seems to have been enough to bring attention to it and get public working POCs for this vulnerability in less than 3 days following the fix. If you’re curious about how more mature open-source code bases deal with this risk, projects like Chromium rely on a separate bug tracking infrastructure that can restrict who can access the bug reports (that will spell out the security risks and test cases) combined with public commit messages with simple phrasing meant to avoid attracting the attention on the security commits.  

Another interesting tidbit, the root cause of this bug is the misuse of a Go API to sanitize paths as discussed in this Twitter thread. It turns out the filepath.Clean function used to sanitize the input processed by the vulnerable code only removes excessive “../../” if the path is absolute. This is a common case of an API behaving as expected but leading to dangerous consequences. Do you know for sure the codebase of your organization is free of these problems? The impact of unpatched vulnerabilities here could be the accessing or leaking of extremely sensitive data.  *pondering becomes frantic*  

What can I do? 

Obviously update the software if you’re using it, and you can also use Sigma rules to detect attack attempts. In an ideal world, your analytics platform should not be exposed to the wide internet, unlike these 87k instances, among whose 16k are still vulnerable according to Shodan. At minimum make sure your Grafana instance is behind a .htaccess prompt or similar. From a development perspective, security testing and unit tests should be leveraged to ensure the filtering you are putting in place is working the way it is intended to. And in the grand scheme of things, if you are going to process untrusted user input, don’t wing the filtering and apply thoroughly audited code patterns rather than disabling the warnings of your security tool…  

The Gold standard 

“Does the walker choose the path, or the path the walker?” may have mused Garth Nix in his novel Sabriel. One thing is certain though, the path described above won’t be “walked” nor traversed by an attacker for the McAfee Network Security Platform (NSP) customers. These lucky fellows are already protected against path traversal attacks via a generic rule and can even be bestowed further protection with the creation of “custom attack” rules.  

CVE 2021-44228: Log4Shell 

What is it? 

Who could have known that parsing—and sometimes even executing—untrusted input was a bad idea™? Well it turns out that Apache’s log4j logging code does exactly that, and if the logged string contains the magic characters $(jdni:…) it may even fetch and execute untrusted Java code. Iterations on this attack have also highlighted the possibility to leak local secrets stored in environment variables—such as AWS keys—and given the recursiveness of the processing, it also offers many ways to evade pattern-matching detection. 

Who cares? 

Pretty much everyone. You write Java and are into logging things? Yep, you should be on top of this. You use Java based applications/servlets? Well, there’s probably some logging of untrusted user input in there. Your corporate employer uses Java based appliances or services? Pour one for your SOC and IT folks who are probably having a blast over their holiday “break”. You get it, this problem impacts the whole industry, and in all likelihood, its effects will probably keep rippling out for the years to come. To make things worse, the bug is really easy to exploit. From pen testers to SOC analysts, “script-kiddies” to nation state actors, nearly everyone has begun to explore this attack vector and we have observed massive on-going attacks with a wide gamut of payloads, ranging from cryptominers to “rm -rf /*” payloads and even a broken attempt to spread the Mirai worm. The worst is likely yet to come.  

What can I do? 

“Stranger Things” taught us that “You can’t spell America without Erica.” Similarly, you can’t spell Apache without Patch. Sort of.  Upgrade! Micro-patch. Monitor traffic. Hint: if you’re internal-only application suddenly makes LDAP requests towards a remote server in a country you have no operations in, maybe something fishy is going on…  

If you like chaos and and/or you are having a hard time convincing IT of the importance of this bug, get permission to demonstrate it for them! Then, set strings you can control (user-agent, twitter name, wifi SSID, …) to this $(jdni:ldap…) magic value and make it point to an IP:Port you control (or a third party service like Canarytoken if you trust them). If you detect hits on that address, you can start having a fun conversation about the necessity of upgrading their tech stack with the owners of the incoming addresses. This is where asking for permission first becomes extremely important, as if you indiscriminately put the magic string all over the places to see what happens (as you may have seen on various social media platforms), it’s likely that eventually someone will reach out to have a “fun” conversation with you and ask about that funky user-agent of yours. Obviously, before pulling a stunt like this consider that the last thing you want for Christmas is a CFAA (Computer Fraud and Abuse Act) complaint delivered right to your doorstep.  

The Gold standard 

McAfee Enterprise customers are protected from many different angles (for the specifics, please visit this Knowledge Base article):  

• Expert Rules on Endpoint Security (ENS) can pick-up dangerous patterns in memory as described in this blog.  

• Endpoint Security (ENS), VirusScan Enterprise (VSE), McAfee Web Gateway (MWG) can provide generic detection under the tile Exploit-CVE-2021-44228.C via a “Potentially Unwanted Software” detection. This detection is also augmented by a list of hashes of samples related to in-the-wild campaigns exploiting this vulnerability.   
• Network Security Platform (NSP) can also detect the attack via User-Defined signature (provided in the KB article linked previously) 
• MVISION Endpoint Detection and Response (EDR), McAfee Active Response (MAR) can also be used to look for vulnerable systems with Real-Time Search (RTS) queries 
• McAfee SIEM got an update (Exploit Content Pack version 4.1.0) that will raise an alarm on potential exploit attempts. MVISION Insights is also providing valuable information under the Threat Campaign “Log4Shell – A Log4j Vulnerability – CVE-2021-44228”. See Insight Preview. 

CVE-2021-43527: Big Sig 

What is it? 

Big Sig sounds like the nickname Freud’s mother gave him. This bug is no less compelling. Early this December, Google Project Zero blogged about a vulnerability they found in Mozilla’s Network Security Services (NSS) with a CVSS score of 9.8, according to NIST’s National vulnerability database page. There is a heap overflow in the processing of certain signatures (DER-encoded DSA and RSA-PSS signatures). To put it simply, the NSS is a collection of cryptographic libraries that enable developers to use safer/heavily tested implementations of cryptographic primitives and standards (for encryption of communication, verification of the authenticity of data, and so on). The feature where the bug was found is responsible for the verification of signatures that prove the authenticity of data using various public cryptography schemes. This type of function is typically used to sign emails or documents to confirm their actual authors. Something really interesting about this bug is its relative simplicity but also its long existence; according to Project Zero’s blog, this bug was exploitable going all the back to 2012. The vulnerable code path just happened to fall between the cracks where various fuzzers used by Mozilla overlap. 

Who cares? 

If you like your signatures to be verified, and rely on the NSS library to do so, you should definitely have a look at the advisory and use the latest version of the software (NSS version 3.73/3.681 ESR or later). Firefox seems unaffected, but other software that parses signatures might be impacted (Thunderbird, LibreOffice, Evolution, Evince and more).  

What can I do? 

As usual, you want to make sure any software you are using that might be vulnerable is updated to its latest version. The patch was released on December 1st so, for starters, you’d want to make sure potential vulnerable software received an update after this date. It would also help to know which software relies on this library; while there is no magic bullet, references to files such as nss3.dll on Windows or libnss3.so on Linux are a good starting point. Beyond that, the best call is to look at release notes and potential list of third-party libraries used in any given application you may use. If you use the vulnerable library in in your own product, update the code or backport the patch. 

The Gold standard 

Have you checked out our bulletins? They’re a great source of information for the critical vulnerabilities you may have missed! This may include applications that will be deploying fixes for CVE-2021-43527.