What’s going on?
I have to say this past week has been a real eye-opener for many industries, but I believe the biggest one is the technology industry. Formally named CVE-2021-44228, the Log4j vulnerability has sent security and dev teams scrambling for the past 5 days, and for good reason. This vulnerability essentially allows malicious actors to
execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled
Many individual’s, myself included, are calling this one of the largest and most dangerous vulnerabilities that have been found. The main reason behind this is the shere number of products that are being effected. The following is a short list of some of the companies that are effected:
When was it discovered?
Aparently Cisco’s Talos security team has been observing exploits related to this since December 2 although the earliest exploit found was 04:36:50 UTC on 12/1/2021. Aparently the primary use for this exploit as seen in the wild has been to install crypto-mining malware, and add to botnets.
Microsoft has published guidance for preventing, detecting, and hunting for the Log4j issue.
My thoughts
It’s safe to say that this discovery has sent a lot of people running and scrambling and working their tails off.I can only imagine the emails that have come down from the security teams. I must say that whenever I first found out about this issue a few days ago I myself went running. Running straight to our code base is.Thankfully. None of our products were affected. But although none of our products were affected, it still doesn’t take away from that sudden heart drop feeling. After confirming that.None of the software that I worked on was affected the very next step in the process was setting up automated scanning using Snyk. While I have and continue to use Snyk’s CLI tools I didn’t have an automated process to ensure that our products were protected.
During development, we often repeat the phrase DRY (don’t repeat yourself), and in doing so often forget what the dangers of this phrase could bring. I completely agree with it and by no means am I advocating against open-source software, but at the same time we as engineers must take steps to ensure that any potential risks that could be brought in by external software are mitigated.
Let’s face it. Many software products would be extremely cost prohibitive to build without the assistance of already existing libraries. But time and time and time again we are shown that the potential for issues that we didn’t create to creep into our projects is there. In my opinion as our tools, programs, and methodologies continue to grow and mature it is important to invest into the DevSecOps process. By building security into our everyday practices we may not be able to completely ensure that our systems are safe, but it can help by ensuring that no security vulnerabilities are introduced into our code and notifying us the moment an issue arises.
Some tools
For those of you that are in a position to do so, I highly recommend that you take a look at the following automated security tools and speak to your leadership about the importance of implementing a DevSecOps program within your organization. Now would be the perfect time to do so.