Log4J Affecting Civilians

This vulnerability will affect many systems, including the ones you use at home. Here are some tips to protect your personal devices and home network (tell your friends). Apply updates. Especially this week and next week. If you’re computer, phone or any piece of software wants an update, say yes. Updates in general are great, they often contain security fixes, as well as new features.
At some point this week make time to call your internet provider and ask if your router or modem has any updates for log4j. A lot of *devices* are going to be vulnerable, and most of us forget about our modems.
If you have “smart” devices at home, check for updates on them too!

While we’re at it, here are a few tips for securing your digital self (again, tell your friends!):

• Turn on Multi-Factor Authentication (MFA) or two-factor authentication (2FA), on all your online accounts that are important to you. Your banking accounts, government services, shopping accounts that have a credit card saved, etc.
• Get a password manager. Then change and save your passwords into it, one by one, as you visit all your favourite sites. Let it auto-generate unique passwords for you.
• Think twice before you click on a link in an email if you were not expecting to receive that email. Verify who it’s from, that it’s a legitimate website, and that the link starts with a domain that you recognize. If you’re not sure, copy the link into google.com (not the address bar, go to the search engine website) then add “phishing” to your search and see what it says.
• Never give personal information, such as pictures of your ID, your social insurance number, your home address, date of birth, etc. to anyone on the internet.

Guidance on Log4J

Lots of people are talking about how Log4J affects servers, but if you subscribe to this newsletter, you probably want to know about your apps. Let’s talk about what the problem is, how to figure out if you have it, then what to do about it.

Problem: this java logging dependency has a vulnerability in it that allows an attacker to take over your web server and run commands from it. They can run this attack before a login screen (unauthenticated). This is the “most scary possible” from a security viewpoint. Do you have this problem? You can search for it in a bunch of ways, but I suggest just going to your code repo, searching for “*log4J*”. If you find nothing, ALSO search using any sort of dependency tool. This could be dependencyGraph in GitHub, Snyk, OWASP Dependency-Check, White source, etc. These are also often called “Software Composition Analysis” or SCA for short.

Versions 2.x (every single one except 2.15.x which is the patch for this) are vulnerable.

Versions 1.x are only vulnerable if you call the JMSAppender functionality. You can look in your code for “JMSAppender” to see if you are calling it. If you are, you are vulnerable. If not, you’re good.

If the code has not been deployed anywhere, mark it as “do not deploy” and move on. Anything that HAS been deployed: where? WHERE is it deployed/where does it live? Behind a WAF or CDN? If so, add the rules to block this attack. CloudFlare & CloudFront both do, turn it on!

If you have your own RASP or WAF, and there are no rules available yet from your vendor (ask them if you don’t see it, tell them you want one if not). So if not available from the vendor, make your own “virtual patch”. Work with InfoSec to write regex that blocks the attack or fish some off of the internet (you are not the only one with this problem).

​

To be clear, if you make a virtual patch, this is a temporary measure, and you need to 1) monitor it to make sure it’s working, plus 2) upgrade the versions of Log4J as soon as you can. Don’t forget please. 😀

Worst case scenario: You have log4J, nothing to help you block it, and it’s a vulnerable version.

Option 1: “accept the risk” and do nothing to block it. You will still monitor the situation, but that is all. You will instead spend your efforts on releasing the upgraded version of your software as soon as humanly possible. For some organizations, this is the only option. Don’t feel bad, use that energy of the update instead. Ensure you test thoroughly; you don’t want to release patches like our industry saw during Meltdown/Spector that broke the patched systems worse than the vulnerability would have.



Option 2: Shut off the vulnerable systems. Immediately. If your business can have a few systems down until you figure out how to do something better, this *might* present less risk. There are currently many systems all over the internet being turned off, in the short term. There is no shame in doing this if it’s your best option. I’d rather have egg on my face than an exploited server.



Option 3: Go through your code and remove this dependency from your project, then comment out the code that calls it. When you are ready to apply the upgrade/patch, you will add it and turn it back on. Stop logging, just for now. This is the only situation where I would ever recommend removing logging. Test it thoroughly before deploying and make sure you don’t have any sort of “backup logging” that could interfere or spoil your efforts.

​