Today I want to talk about this Log4j, this JAVA vulnerability that's taken the news cycle by storm. It's something that has garnered a lot of attention. I haven't decided rightfully so yet or not. I feel the jury's still out on how big this will be. I wanted to jump into this topic and explain what is happening with this Log4j vulnerability. Why is it garnering so much attention? Because what can happen here, pretty simply put, is that an attacker with seemingly a trivial line of one line of code can overtake a system with this vulnerability. This vulnerability was discovered on November 24th by Alibaba security researchers, and they brought this to the Java team's attention and started working on a patch. But between then and now, this has gone into the wild and run rampant.
I will explain a bit of what it is and who it affects. First off, it involves a lot of companies. Many different people use this Log4j logging software within their software applications. This affected software could be software that runs on your computers, runs from a server, runs in your corporate or enterprise environment, or runs on your hosted web server. There's a lot of Apache-type servers that are affected by this vulnerability. The good news is there's a fix. There's a way that you can fix this. You can update various devices in your environment. I know if you're a fan of Ubiquiti UniFi wireless controllers and devices, older versions of their software are affected by this, and they have an update out. So there's going to be many people dedicating a lot of effort to updating devices to get this fixed.
The more significant issue is that attackers are currently looking for web servers that have this vulnerability or have this exploit. It won't be long before bots are built and servers that are automatically doing this for cybercriminals, hitting websites, filling out web forms with the trivial line of code that I mentioned to make this exploit go down. But it's pretty simple as to what's going on. The sequence of code that all you need is simple, and we've seen it in many different ways, but you can use an LDAP server. We've seen other servers like DNS requests being sent through as well.
But basically, all you need to do is go to any website that's running. Go to any form that you can identify, or if you know what you're doing from a technical standpoint, you can force or you can trick the browser into sending different host headers or HTTP headers and things like that back to the server, so it thinks it's getting a form fill. Still, it's you just manipulating the data before it hits the server. All you have to do is write this line of code that points all of this back to a server you control. And once you do that, you know you have a machine that you can then take over and potentially deploy a payload.
Log4js is a problem and why this is a big deal to I.t. professionals is because, number one, what you might have to do to detect this in your organization, depending on how big it is, the larger companies will have a significant problem with even finding this. We're seeing that if it can be exploited, it's challenging for these large organizations to test all their applications to see if somewhere on some page or some application that they're using somewhere in their company is susceptible to this exploit. Eventually, automated tools will be built, but we're early in the game right now, and those tools are starting to come out, or they don't exist yet. So there's not a super simple, automated way to figure out if you are susceptible to this vulnerability or exploit.
Security researchers and tools and software are getting in tune with what to look for on the vulnerability side and what to look for post-exploitation in the event that you've already been compromised with this vulnerability and they've already started to do so things on your systems. We see the security vendors, the endpoint, the antivirus companies trying to put things in place to detect both the vulnerability as well as the post-exploit to see if maybe you've already been exploited. But quite frankly, we're not there yet. We're not there yet to detect this, so there's a very manual process involved.
The other concern that this brings up for everybody is if a server does get exploited and a payload is then loaded onto it, I am aware of a security researcher who did this with a Minecraft server, who could infect everyone who joined onto the Minecraft server with malware. They were able to put the exploit in place and then infect the people who entered that server with different types of malware. That's the big problem. The problem becomes worse when a server gets exploited because of Log4j. Then people who use that particular service, or use that site, or use that game log into that server, and because that server's now been compromised, they become a victim.
This type of attack becomes a supply chain on top of a supply chain type of attack, where one vulnerability leads to the exploitation of something that can then exploit many, many, many other users. Even if you don't have this Log4j on your system, you could potentially be somebody who is attacked through the supply chain of this attack. So what we need to do is we need to get this patched. We need to get this out of play. We need to get this vulnerable version of Log4j out of the mix, get systems patched, but it's a big undertaking. It's going to take security teams and IT professionals a while to make sure that this all happens over time, and quite frankly, just based on previous exploits like the Microsoft Exchange vulnerability that came out in the spring. We saw plenty of companies who did nothing around that. And then today, nine, ten months later, we're still seeing active exploitation of Microsoft Exchange vulnerabilities.
So at the end of the day, everybody can do their best to get this patched. But unfortunately, we're going to see many, many people fall victim to cybercriminals due to this exploit and companies not taking the proper precautions to get these things patched and to get these vulnerabilities out of existence. There's going to be lots of scanning of web servers going on to determine if you're running this version. Cybercriminals, threat actors are looking for this. There's very much a spray and pray type of operation going on. You're going to see an uptick in phishing attempts and getting your employees to click on things to try to get you to go to a vulnerable site or server that this exploit might have compromised.
This vulnerability has the potential to be ugly. A way that this can go down is not good, simply because there's going to be a lot of legitimate companies, legitimate, trusted things out there that are going to fall to this vulnerability and become an exploit point for other people that are unsuspecting to these types of things. I'm hoping it doesn't become a big deal like they're painting the picture out to be. It's pretty essential. If you are an IT professional, please make sure you're looking for this stuff. There are ways to look for this stuff, and if you need help with this, we can help.
Suppose you need help with either the detection of Log4j or its remediation in your company. In that case, you can reach out to our company, and we can help you detect this Log4j vulnerability in your environment. Not an easy thing to do if you have 50, 100, 200, 1,000 employees' systems out there that you need to check and make sure are not vulnerable. You can't just limit your checks to web servers. You have to check everything, and we can help you with that. We've developed a way to quickly scan networks and determine if these things are in place.
That's it for me for the Log4j Java library vulnerability. Unfortunately, there's a pretty trivial vulnerability out there in the wild. It needs to be patched, and that's where we're at today.
