Cybility Savvy
Cybility Savvy
Cybility Alert- What you need to know about the Log4shell vulnerability
📝Show notes:
Michala Liavaag dives into what executives, non-executive directors and trustees need to know about 'Log4shell', a new vulnerability that is rated at the maximum 10.
The main facts you need to know: What is it? Where is it? Why should we care? What can we do about it?
She also discusses misconceptions and shares some questions leaders should ask their IT, third party providers and other suppliers.
NOTES:
After the recording of this episode, Apache have released v2.16: https://logging.apache.org/log4j/2.x/
At 3m38s, RCE is mentioned and it stands for Remote Code Execution.
👉 Cited in this episode:
Apache Foundation https://logging.apache.org/log4j/2.x/security.html
NCSC UK https://www.ncsc.gov.uk/news/apache-log4j-vulnerability
NHS Digital Cyber Alerts https://digital.nhs.uk/cyber-alerts/2021/cc-3989
Affected software lists: MVN Repository https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/usages
NCSC-NL https://github.com/NCSC-NL/log4shell/tree/main/software
Manual testing (only to be used on sites you/your IT are authorised to test) https://log4shell.huntress.com/
-----
⭐Found this useful? Please rate and review, as it helps reaching more people
👍You can also subscribe and share on social media
💬 Contribute to future episodes with your cyber security concerns and questions
🤝Connect with Michala and Cybility Savvy:
✅ LinkedIn ✅ Twitter ✅ Youtube ✅ Instagram
---
✍🏾Written and produced by Michala Liavaag
🎦Co-produced and edited by Ana Garner video
🎵Music by CFO Garner
-----
⭐Found this useful? Please rate and review, as it helps reaching more people
👍You can also subscribe and share on social media
💬 Contribute to future episodes with your cyber security concerns and questions
🤝Connect with Michala and Cybility Savvy:
✅ LinkedIn ✅ Twitter ✅ Youtube ✅ Instagram
---
✍🏾Written and produced by Michala Liavaag
🎦Co-produced and edited by Ana Garner video
🎵Music by CFO Garner
Hello I’m your host Michala Liavaag, founder of Cibility Consulting.
Today we bring you a special episode in which I’m going to explain the Log4shell vulnerability and what it means for you and your organizations. So, what is log4j? Log4j is an open source java logging library that is maintained by the Apache foundation. Now, what's that mean in English? Its purpose is to log, which is another term for record or write down if you like, an activity that's occurring in an application. So, typically, this would be: who- perhaps a person's name or a device name; what action is being taken- so they might be viewing something, they might be editing something, or deleting something; what is the actual object that's being affected- so it could be a record in a HR system for example, in which case by this point we know who's accessing it, whether I’m editing it or not, which system it is, which record it is in the system, and then the next piece of key information is when- so the date and time stamp that that occurred. So, when we talk about logging in security, those are the main aspects. Ironically, logging is one of the security controls that we rely on to investigate incidents. Yet, here it's the logging mechanism itself in which we have a vulnerability. This particular library is used by many software developers across the world, and it can be found buried deep within other applications that might not actually be obvious on first look. So this is the challenge.
So, what is the vulnerability? Well, it lies in the way that the application will look up information and this is via something called the java naming and directory interface, JNDI for short, but then the way that it translates that information that is sent back to it. For those of you who've seen Star Trek you'll be familiar with the universal translator, where the crew will have people around them speaking many different languages, but because of the universal translator it takes that input in and translates it into something that the crew member understands. So, some very clever people have found that by entering a particular combination of characters into a system they can actually trigger that system to go off and get information from an external source. So, if I’m an attacker, I might want you to go and visit my server with my malicious software on it, so that when your system then actually acts on this code, what it will be doing is bringing my malicious code into your system and then running it there. So we call this a RCE- Remote Code Execution, and it's one of the really nasty vulnerabilities that we can have, but what's worse in this case is that the attacker doesn't even need to prove who they are as in authenticate: they don't need to provide any usernames or correct passwords. Just entering this clever string will actually trigger this vulnerability.
So where do we find this vulnerability? The answer I’m afraid, is any application that uses a vulnerable version of the log4j library, specifically it's the log4j version 2 that's affected, not the version 1, although the version 1 also has security vulnerabilities that should no longer be used either. Now, it doesn't matter if this is on a server or on an end user device like a pc, it can be vulnerable in so many different ways. So, for example, you might have a website that has a form for your visitors to fill in, a contact form perhaps, and by putting this string into one of those fields that might be vulnerable. You might have a web application that you're entering data into, a lot of systems nowadays are software- as-a service, and the interface you access through a web browser, so this is particularly common, and again you could be entering an information, it could be this string and if that application is using a vulnerable version of log4j library, then that again would execute that malicious code, and the attacker would be in the system. Now the other one just to call out because a lot of people are missing this I’m afraid, is that it could also be an application that's installed on someone's pc. So, this is java related and quite often especially some legacy apps will actually use a lot of java. So it's something that shouldn't be overlooked, that this library could still be in an application on someone's pc, not just web servers and web applications. I’ll provide a link for you in the information about the most reliable list to check for affected software, and I’d really encourage you to share that with your IT, if you have IT internally or if it's a third-party provider, check that they're aware of it.
Now, this vulnerability properly came tonight uh on Friday and so a lot of people have been very very busy working over the weekend to try and limit the damage, but already, it is only Monday, we have several misconceptions that are coming up and I just wanted to make sure you're aware of these, so that you can challenge people who might be giving you information that they themselves might not realize isn't quite right. So, the first one, the misconception is: it only affects Apache web servers. That's not true it affects all systems across all platforms, if they are using a vulnerable version of the log4j v2 library.
Misconception 2: none of our internet facing servers are vulnerable. And you may hear it refer to this as servers in the DMZ, the demilitarized zone which is between the trusted network and, if you like, the wild west of the internet. Now again, this is a misconception. Exploits are already showing that a string of characters can be entered into one system that is perhaps in the DMZ and then, as it's passed in to another system that uses the vulnerable software, it's then that the initiates that call back to the attacker. So, it can actually get in through that protected area of the DMZ, into the trusted network and so you also need to be concerned about applications that might be vulnerable on the internal network. A lot of people are thinking: oh no, it's just the external stuff. No, it's not!
Misconception 3: we're okay, they won't target us. Well, I’m afraid that because this is so easy to exploit, even people with very little skill can do this, it's been weaponized really quickly and so we're seeing attackers are basically taking a sort of spray approach and anyone who's vulnerable is potentially a target. So they're not actually looking at individual organizations, it's just who can we get and then later on, typically once they've installed what we call a backdoor on your system, so they can wait for everything to die down and then come back later and do what they want to do, they'll be then looking at which are the interesting targets out of the people that they've managed to compromise.
So why do we care? Well, in security we have a rating scale which is known as the CVSS, common vulnerability scoring system, and much like the Richter set scale for earthquakes, it takes into account different factors, and it goes from 0 to 10, with 10 being the highest. Now this vulnerability is a 10. Let me say that again: this vulnerability is a 10. And that's why everyone's so concerned: because it's so easy, it's widespread, it's easy to exploit with little skill, and most importantly, it can be triggered remotely over the internet without logging into the system. So I mentioned earlier it's not authenticated and this is one of the key reasons why it's 10 and deserves our attention.
Now, again, it's early days, but already we're seeing exploitation. The good news, if you can call it good news, is that threat intelligence reports are suggesting that the majority of attackers are using this vulnerability to install crypto mining software on your machines, so that they can obviously make some money through that in terms of the crypto coin currencies. That's not great, you don't really want that in your systems, but at least it's not hindering your organization necessarily, unless they're using absolutely all the performance of the machines you've got. I would say there are a couple of examples already where some have chosen to install ransomware disabling organizations completely, and that's obviously something that we all want to avoid. And I think, as I’ve already mentioned, the most concerning is that some of them will be installing those backdoors on your systems to gain what we call persistence, so they're still there, so that they can come back later when things have died down to perhaps look at what else you might have that they can sort of exploit and sell or other things.
Okay so what can we actually do about this? For those of you who have internal IT departments, I would refer you to the national cyber security centre alert, that details the steps that they can take. For those of you have external IT providers, I would challenge them and ask them what they're doing about it. I would also pay heed again to those misconceptions that I mentioned earlier because some of them may not understand fully and you can challenge that with the information that I’ve given you.
Some things you can ask are: Are you aware of the log4j aka log4shell vulnerability? If not, why not? And if they do say they're not, I would just suggest that you sort of direct them to the information for now, and then note that that reason is looking at later on, as to why aren't they getting that threat intelligence to actually proactively do something about these vulnerabilities.
Now, if they have become aware of the vulnerability, the question then is: What actions have you taken to establish if any of our systems in use are affected? And remember that's not just servers but it could be client pcs as well. There's a really excellent list that again I’ll put in the show notes below, that is keeping up to date with the affected pieces of software. There are a few lists out there, but this one's very reliable so I would go with that one.
Also, not to be forgotten asking: have we actually checked if we've got any in-house software development going on or perhaps we used to have in-house software development, we've got some legacy software that might potentially be using this library? So that's another thing that you can ask just sort of get their minds going and trying to identify all your sort of attack surface, you know which bits are affected with it.
You can ask them what mitigation have they taken already, or plan to take. And then also: have we engaged with our third parties to understand the supply chain risk? Because there could be this onward impact to us and potentially on to our customers as well? Have we engaged our PR team, if we've got one. And if we don't, has the support chair of the board of trustees perhaps got a statement prepped ready, should you be asked what you're doing about this and how you're affected? You want to be ahead of it rather than behind it.
So the other side of this. and this is true regardless of this vulnerability. You want to be asking a question: are we monitoring for suspicious behaviour and looking actively for any data that's leaving our systems? Data exfiltration is the term we use. And if they are, how are they doing that? Are they actually searching internally for what we call an LDAP connections? In this particular vulnerability this is one of the protocols or the methods, if you like languages that is being used to then dial back out to the attacker, and so by looking for those connections they can indicate which systems and devices might be affected and then also block that connection as well. In particular, they may not have seen these activities before the 10th of December, but not necessarily because the vulnerability was sort of known about by some people before, so I think just focus on current activity at the moment, but you might double if you find something, wants to go back in your logs if you've got them available.
And then also um a lot of organizations forget to check their DNS logs. Now this stands for domain name server and it's the translator if you like that turns a name like a web address like www.cybilityconsulting.com, into a string of numbers and an IP appear address so that the internet knows how to direct it. And those logs can provide really rich information, but they can also be used to actually steal data out of your systems, so do ensure that your organization is looking at those as well.
So the key messages for your IT whether that's in-house or external:
1) Patch it if you can. Version 2.15.0 of the log4j library has been released and it fixes the vulnerability. Note: it's not as simple as it sounds, because it might actually require the recompilation of the software code, and then subsequently, the redistribution of the software packages from suppliers to their clients. So sometimes you know you think patching can be done quite quickly, but the gut feeling I think for most of us in the profession at the moment, is that whilst we take mitigating actions right now, this is going to be that marathon not a sprint. And because of that, you will need to take action to mitigate it. There are some strings that can be changed. I’ll put those again in the show notes, if you want to pass those on to your IT. And I’ve already mentioned about looking at logs and detecting those attempts to exploit your systems. Now, it's always good practice to block outgoing traffic, if it's not needed anyway. You should always limit to the minimum that's needed, so for server to talk to this one then that's all you should allow and you should have your firewalls block everything else in relation to those. And then if you do have systems that will actually inspect your traffic then they could also be checking for these protocols, these languages that we've mentioned that the attackers are using.
And finally there are lots of stories out there in the press, lots of technical blogs and everything as well, so what I’ve done is I’ve created the reputable sources that I would recommend that you use to learn more about this, those again in the show notes below and we'll provide a bit of a sort of cheat sheet with all this information for you.
If you do have any questions or concerns, you can go to our website cybilitysavvy.co.uk and complete the question form there, and we will do our best to answer those questions for you as soon as possible. So I hope this has been useful for you and we'll be back with the part 2 of Laura's excellent interview shortly, thank you.
