Let's talk malware!
There’s been a lot of talk about malware in the security news of the last few weeks and whether it is Windows oriented (like LockBit 3.0/Black featured in CISA’s alert) or Linux oriented (like the new variant of BPFDoor), all malware is just one thing: software running on a system which shouldn’t be there.
I say that because I often see people ask “Is [system] vulnerable to [malware]?” and I see that question put people in an awkward position – let’s use possibly the most well-known Linux malware as an example and that question could become “Is the BIG-IP vulnerable to Mirai?”, but remember you can substitute any malware where “Mirai” is; LockBit, LockBit Linux-ESXi, Xor DDoS, BPFDoor, XMRig etc, and the answer will be the same:
The BIG-IP isn’t vulnerable to Mirai, because Mirai isn’t a vulnerability.
That answer is disingenuous, though, because the full answer would be:
In and of itself, Mirai is not a vulnerability, however if an attacker is able to place the Mirai binary onto a BIG-IP and execute it, Mirai will run on the BIG-IP as it would on any other Linux based system.
The same is true of any system, of course; if you asked “Is Windows vulnerable to LockBit Black” the answer would be that LockBit Black isn’t a vulnerability, but if an attacker is able to place the LockBit binary on a target Windows system and execute it, that system will succumb to LockBit.
Why the semantics?
You might ask why I am being really picky about the word “Vulnerability” here – the answer amounts to the same thing, after all and you could just say “The BIG-IP is vulnerable to Mirai”, but the word “vulnerable”, in computing, has a very specific meaning:
A vulnerability is a flaw in a computer system which weakens the overall security of the system.
Put in these terms you can see that Mirai is not a vulnerability – Mirai itself isn’t a flaw in a computer system, it is simply software which runs on said system in the same way that any other legitimate software might run. It is undesirable malicious software, hence malware (literally a portmanteau of malicious software), but software, nonetheless.
A vulnerability, meanwhile, is likely to be how the attacker gets the malware onto the system; for example, an unpatched CVE allowing remote code execution. But there are many other ways to deliver malware which don’t require the exploitation of a vulnerability - like a phishing attack against an administrator or an administrative interface exposed to the internet with default credentials.
Enough semantics, what should we do to protect ourselves?
First, educate your users; it is harder (in my opinion) to prevent successful phishing attacks through technological means than it is to train your users to be vigilant and to spot phishing attempts. But don’t stop there;
- Regularly train your administrators and operations teams on how to deploy new systems securely and to audit the security of existing systems.
- Ensure you have robust playbooks for new deployments with security checkpoints baked in.
- Put systems in place to limit the opportunity for ‘off the books’ development/deployments, especially in public cloud environments.
- Have systems in place to ensure patching of known vulnerabilities in a timely manner, especially remote code execution vulnerabilities.
When it comes to the systems themselves:
- Don’t expose server management interfaces to the Internet (e.g., a BIG-IPs Configuration Utility on port 443 or SSH on port 22).
- Ensure any internet accessible IP addresses have appropriate packet filtering and only expose required services (e.g., ensure Port Lockdown is in use on BIG-IP Self IPs).
- Use strong passwords for all administrative accounts.
- Have centralized logging and monitoring in place for security events (like logins, especially from unexpected sources).
See K13092
F5 products can help you with this, of course:
- Ensuring that your assets can only be accessed via the BIG-IP on ports you control immediately ensures you aren’t accidentally exposing SSH on your webserver, ruling out the possibility of an attacker simply brute-forcing credentials and uploading malware directly.
- The BIG-IP is (usually!) a full proxy right down to Layer 4, so any exploits or C2 channels that rely on quirks of TCP or utilise unusual header fields to transfer data will fail when the BIG-IP proxies and applies its own optimisations to the server-side flows.
- Placing Advanced WAF in front of your internet-facing web services, configured with an appropriate policy, significantly reduces the possibility of an attacker exploiting a weakness in your web applications to upload a malicious payload (such as SQL Injection or shell command injection).
- The AFM IPS (in AFM 13.1.0 and later with an IPS subscription license) allows you to scan non-HTTP traffic for potentially malicious activity and take action.
- BIG-IP APM allows you to secure access to potentially vulnerable protocols like RDP, better still, APM layered with Advanced WAF allows you to protect your VPN and secure endpoints against brute force attacks.
Of course, F5 products are not best placed to stop a user from clicking on a malicious link in an email, but the points above at least help close some of the vectors that malware can enter your network.
Not only that, but if you are inspecting your outbound traffic (with BIG-IP AFM or SSLO) then it’s a snap to add rules to those products that will alert you and/or block outbound C2 communication attempts from compromised clients!
Summary
BIG-IPs (and any other systems) aren't vulnerable to malware in the computing sense of the word vulnerability, or to put it another way, malware isn't a vulnerability; but malware - malicious software - can run on its target system if an attacker can place it there.
The key to stopping malware, then, is rigidly following security best practices. Secure systems and patch known vulnerabilities in them through which an attacker might deliver malware (typically remote code execution vulnerabilities).
Published May 24, 2023
Version 1.0