Unless you’ve been living under a rock or have a life, you’ve heard more about Log4j2 than you might care to have. You’ve probably heard talk of Log4Shell, Log4j, exploits, vulnerabilities, CVE-2021-44228, and countless Christmas songs this month. Why did I write exploits and vulnerabilities in bold and underline them? Don’t recall, I have a memory leak. Oh yeah, it’s because people tend to use the terms interchangeably, and they’re not. And so, in the interest of precise communications I’m going to take a few paragraphs to explain the differences by telling you of a windows vulnerability I discovered many years ago.
One evening my wife and I went out to dinner and, unfortunately, we both forgot to bring our keys with us. Upon returning home we realized that we were either going to have to call a locksmith, break down a door, break a window, or hack our way into the house. Hacking sounded like the best, or at least most desirable option, even though we didn’t have a smart home. No, this was a physical hack.
We had sliding glass windows which we secured with wood dowels so that they couldn’t be opened from the outside. Yeah, the house was locked down pretty well… except for the window I never got around to putting a dowel into. But could the window be opened from the outside? Afterall there was a clasp holding it closed. As it turns out I was able to press the window inward enough to clear the clasp while not breaking the window. At the same time, I slid the window sideways enough to open it.
The vulnerability was that the clasp could be bypassed. An unauthorized threat actor (AKA burglar) could have exploited the vulnerability to break into the house if they knew the vulnerability existed. Yep, regardless of the fact that the vulnerable window clasp was never known to have been exploited (bypassed), the window, and hence the entire house was vulnerable due to the bug in the window clasp.
Now let’s move on to the exploit. The act of bypassing the clasp was how the Clasp Bypass vulnerability was exploited. The means of exploiting the vulnerability was pressing the window in enough to gain access to the house. I capitalized “Clasp Bypass” because it is the name of the vulnerability. I could have called it the Clasp vulnerability, the Whatchamacallit vulnerability, or anything I chose to. Clasp Bypass is a suitably descriptive name, so that’s I’m calling it.
When we talk about exploits, we often hear “proof of concept.” In this case, the concept was that the clasp could be bypassed, and actually doing so proved that the Clasp Bypass vulnerability actually could be exploited. Most security professionals will agree that using a harmful payload against someone is an attack, not a proof-of-concept. Older security professionals will argue otherwise because, with age comes ornery. Also of importance, was that this vulnerability was easily exploited. If the window was on the second floor, then exploiting the vulnerable clasp would have required a more complex exploit requiring a ladder, cherry picker, stilts, or superpowers. When evaluating software vulnerabilities, the ease or difficulty of exploiting the vulnerability is important information.
Trick question. If I had put a steel plate in front of the window so that the clasp and window were inaccessible, would the vulnerability exist? Yes, it would. Even though I eliminated the ability to exploit the vulnerability in my house, the clasp itself still is vulnerable to exploitation, and if you put it in another location, it may be an exploitable vulnerability that may be of concern.
Now we move on to the payload. If a burglar had entered the house, he or she could have stolen things of value. In this scenario, stealing content would be the payload. An attacker also could have stolen my wedding pictures and demanded money if I wanted them back. Sounds a bit like ransomware, doesn’t it? Fortunately, I was the one who exploited the vulnerability. You might call it an insider attack.
The payload I decided upon was to drink a beer and then let my wife in the door. It was a two-stage payload. In retrospect I probably should have let my wife in the door first, but none of my injuries were not life threatening. As strange as it may seem to say that opening the door for my wife, was the payload, it was. Payload does not mean bad or good, it’s just an action that can be performed post-exploitation. If you remember the Code Blue worm, you may recall that its payload was to patch systems that had been infected with Code Red. The access to the systems was unauthorized, but the payload, patching a vulnerable system, was frequently beneficial and typically not destructive. Still, unauthorized access is a computer crime!
Let’s not forget about patching! You can bet that I quickly patched the vulnerable window. The wood dowels were the patch.
Now let’s apply this to log4j2
Log4j2 (and log4j) are not exploits, they are vulnerable applications. The vulnerability is commonly known as
Log4j2 (and log4j) are not exploits, they are vulnerable applications. The vulnerability is commonly known as Log4jShell. Log4j2 and log4j are the vulnerable applications and Log4jShell is the name of the vulnerability. I have seen Log4jShell incorrectly referred to as an exploit. It’s not. If you hear someone call Lof4jShell and exploit, tell them they are wrong and refer them to this blog.Log4jShell is a name of a vulnerability. Exploitation is accomplished by executing arbitrary code loaded from LDAP servers when message lookup substitution is enabled. Not all exploits are even given names. In part that is why people mistakenly call a vulnerability an exploit. The payload is what the threat actor does once they have remote access. According to security vendor BitDefender, they have seen payloads that use victim computers for crypto mining These are the lucky victims. Undoubtably there is sensitive information that is being stolen from the unlucky victims. You can bet that a variety of other payloads are being, or will be, deployed.
OK, that’s enough for log4j2. If you wish to know more about log4j, log4j2, or Log4jShell, I have provided Google with an extensive list of resources. Just google any of those terms 😊
And so, this concludes my story of CVE-2005-WTF, a windows vulnerability that was exploited in the wild and patched with a machined piece of wood.
Randy Abrams
Senior Security Analyst
SecureIQLab
https://secureiqlab.com
*No windows were shattered in the creation of this blog
