Estimated reading time: 4 minutes
Special thanks to Frank Eargle, Customer nominated QRadar Champion, for being a great support in the redaction of this blog.
On March 10th 2021, F5 announced several vulnerabilities and fixes for both Big-IP and Big-IQ (see the F5 Blog). The announcement covers four critical CVEs, two high and a medium one. The seven vulnerabilities can be found on their support website.
The good news is that fixes are already available, the problem is that it is not always possible to update such critical/core devices in a heartbeat.
So once again we decided to try to help you with simple detection mechanisms related to this announcement that hopefully will give you enough inspiration to improve the security of your infrastructure.
This time I will step away from the “easy to complex implementation” method and propose you to:
- Have a look at the vulnerabilities
- Adapt the F5 script to QRadar
- Get an overview on the patching status
- An have a look at a former CVE and best practices
Let's first have a look at the vulnerabilities
We’ll start right away !
Most of the vulnerabilities are mentioning: “This vulnerability allows for unauthenticated attackers with network access to the iControl REST interface, through the BIG-IP management interface and self IP addresses, to execute arbitrary system commands, create or delete files, and disable services.”, but file and service management are quite common tasks on a system… So we need to find a way to differentiate routines from human activities.
The first proposal here is to create rules tracking connections to the management interface followed by multiples files creation or deletion or services being turned off. The fact that we are tracking a connection to the management interface first will lower the risk of false positives due to the system functioning normally.
Here is what the rules could look like:
Apply BB:CategoryDefinition: Service Stopped on F5 on events which are detected by the Local system
and when the event(s) were detected by one or more of F5 Networks BIG-IP AFM, F5 Networks BIG-IP APM, F5 Networks BIG-IP ASM, F5 Networks BIG-IP LTM, F5 Networks FirePass
and when the event category for the event is one of the following System.Service Stopped |
Apply BB:BehaviorDefinition: Connection to F5 Management Interface on events which are detected by the Local system
and when the destination IP is one of the following 10.11.12.13
and when the destination port is one of the following 22, 443, 161, 1026, 4353 |
Apply Connection to F5 Management followed by Suspicious Activity on events which are detected by the Local system
and when BB:CategoryDefinition: Service Stopped on F5 match at least 1 times in 10 minutes after any of BB:BehaviorDefinition: Connection to F5 Management Interface match |
You'll notice that the Building Block BB:BehaviorDefinition: Connection to F5 Management Interface contains no log source, this rule can actually be a Common Rule and be applied to logs and flows.
Of course for any of the proposed rule you can add a filter to exclude any device that has been patched (Refer to the section “Overview on the patching status” for more information), or a unique trusted username/IP as an example. In practice:
Apply Connection to F5 Management followed by Suspicious Activity on events which are detected by the Local system
and NOT when the event(s) were detected by one or more of F5ASM @ f5networks.asm.test
and when BB:CategoryDefinition: Service Stopped on F5 match at least 1 times in 10 minutes after any of BB:BehaviorDefinition: Connection to F5 Management Interface match |
F5 Script adapted to QRadar
In their detection script, F5 is looking for account creation on the appliance. We can try to implement the same with the logs in real time
Apply F5 Account creation on events which are detected by the Local system
and when the event(s) were detected by one or more of F5 Networks BIG-IP AFM, F5 Networks BIG-IP APM, F5 Networks BIG-IP ASM, F5 Networks BIG-IP LTM, F5 Networks FirePass
and when the event QID is one of the following (14255806) Successful account registration |
Another thing the script is checking is presence of specific words considered as suspicious in the log files.
To be able to do something equivalent you need to follow 3 steps:
1 - Search for CLI events containing command execution. In BIG-IP APM as an example, it would be under the event name "F5 System Event" (QID 14254648)
2 - Extract the property "Command"
3 - Create a rule
Apply Suspicious command execution on F5 on events which are detected by the Local system
and when the event(s) were detected by one or more of F5 Networks BIG-IP AFM, F5 Networks BIG-IP APM, F5 Networks BIG-IP ASM, F5 Networks BIG-IP LTM, F5 Networks FirePass
and when the event QID is one of the following (14254648) F5 System Event
and when the event matches Username is not any of admin
and when the event matches Command (custom) is not N/A
and when the event matches "Command" IMATCHES '.*(\.php|\.jsp|fsockopen|bach -i|nc -e|use socket|socket.socket|curl|wget|base64|nmap|passthru|shell_exec|phpinfo|base64_decode|fopen|fclose|readfile |php_uname|eval).*' AQL filter query
|
Tune the rule by adding the trusted usernames/IPs in the filter "and when the event matches Username is not any of admin" as well as the list of commands you want to track.
The script contains many information, it is really worth a look. My advice it to take it as a guide to create your detection rules.
Overview on patching status
Check out for devices that have not been patched. It doesn’t hurt to check which appliances have been patched and which might have been forgotten.
The procedure is super simple ! Let’s take the example of AFM devices:
1 - Create a search to grab the events containing the appliance version
- Log source Type is F5 NetworkBIG-IP AFM
- Event Name is Traffic Flow Stats (QID = 76000090)
2 - Select any event and extract the version
3 - Edit your search to show the new column
Note on a former CVE
Related to a CVE released in 2020, I’d like to do a reminder on best practices provided by F5 on their support website. The first recommendation they provide is to ensure that no Internet access is open on the Management interface, so I’d like to propose a rule to monitor it !
Apply Internet access on F5 Management Interface on events which are detected by the Local system
and when the event context is Remote to Local
and when the destination IP is one of the following 10.11.12.13 |
Once again, no log source has been applied to this rule, you can make it common and take advantage of both your logs and flows.
Conclusion
The rules and searches above are only the beginning of what can be implemented, and of course the implementation will be different depending on the device and version you want to monitor. Once again, this guide may be not perfect, but I hope this will help to know where to start and do it step by step.
Please let me know if you know about other detections, have any comment or if we can be any more help to you.
If you are directly impacted and in need of expert assistance, you can contact the IBM Security X-Force Incident Response team, who is available to assist 24×7, at US hotline 1-888-241-9812 | Global hotline (+001) 312-212-8034.
If you are interested in reading more about QRadar Security Content, you can find the complete list of blog entries here.