Mitigating log4j (CVE-2021-44228) with AFM Protocol Inspection Custom Signatures
The Log4j vulnerability has drawn a great deal of attention and I won't recap anything that other people have said better than I can. See https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability and https://support.f5.com/csp/article/K59329043 for background. UPDATE: I recommend using these three signatures based on Regular Expressions/PCRE to detect attacks using padding and different character encoding schemes to disguise the attack. The first signature is redundant and limited in its application, but very low in resource use. The second will catch exploit attempts that use a bewildering variety of alternate character encoding schemes, but is resource intensive. The third is a specialty signature that deems any payload with "Base64" together with " $ " and " { " (however encoded) to be suspect. This third signature is cheap to use. Simple, low-impact signature that handles padding between significant characters but not character encoding. Limited capability compared with the next two signatures, but if it matches it saves the effort of attempting to match other signatures. create log4j-pcre sig "content: \"$\"; content: \"{\"; distance: 1; pcre:\"/(\?i)\\$'\?\\{.*\?j.*\?n.*\?d.*\?i.*\?\\:/s\";" description "Apache Log4j attempt" service http documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability" direction to-server references "CVE-2021-44228" See the related article "Using Perl Compatible Regular Expressions (PCR) in Protocol Inspection Custom Signatures" for a detailed breakdown. Complex signature that checks for a variety of encoding types for each of the significant characters. WARNING: may cause a performance hit because we can't use a content check as a pre-filter. create log4j2-encoded sig "pcre:\"/(\\$|(0\?44|([u0]00|x|(%|%25|[u0]00)78|%|[u0]0025|%25)24))/\"; pcre:\"/\\{|(0\?173|([u0]00|x|170|(%|045|%25|[u0]00)78|%|[u0]0025|%25)7b)/i\";distance: 1;pcre:\"/j|b|1[5140]2|([u0]00|x|170|([u0]00|%|045|%25|x)78)|%|045|(([u0]00|%|%25|x)25)[64][a2]/i\";distance: 1; pcre:\"/n|1[15]6|([u0]00|x|170|([u0]00|%|045|%25|x)78)|%|045|(([u0]00|%|%25|x)25)[46]e/i\";distance: 1; pcre:\"/d|1[04]4|([u0]00|x|170|([u0]00|%|045|%25|x)78)|%|045|(([u0]00|%|%25|x)25)[46]4/i\";distance: 1; pcre:\"/i|1[15]1|([u0]00|x|170|([u0]00|%|045|%25|x)78)|%|045|(([u0]00|%|%25|x)25)[46]9/i\";distance: 1;" description "Apache Log4j2 exploitation attempt encoded" service http attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability" direction to-server references "CVE-2021-44228" Simple and low-impact signature to check for attempts using Base64 encoding create log4j2-base64 sig "content:\"Base64\";nocase; pcre:\"/(\\$|(0\?44|([u0]00|x|(%|%25|[u0]00)78|%|[u0]0025|%25)24))/\"; pcre:\"/\\{|(0\?173|([u0]00|x|170|(%|045|%25|[u0]00)78|%|[u0]0025|%25)7b)/i\";distance: 1;" description "Apache Log4j2 exploitation attempt encoded in Base64" service http attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability" direction to-server references "CVE-2021-44228" End of Update. The following signatures are obsolete due to the use of static content patterns. I took some Snort signatures provided by the RSA SOC Prime team, and ported them (with permission) to AFM Protocol Inspection custom signatures. This is similar to an exercise I performed about a year ago in the wake of the Fireeye breach (see https://devcentral.f5.com/s/articles/Converting-a-Snort-Rule-to-an-AFM-Protocol-Inspection-Custom-Signature). Without belaboring the point, here are the signatures. IMPORTANT: these signatures make no attempt to defeat obfuscation attempts. They are simple string matches. To enable them, start a tmsh session and switch to the security > protocol-inspection > signature context. Then paste these 3-4 at a time, depending on the size of your paste buffer: create ET_EXPLOIT_Apache_log4j_RCE_Attempt-http_ldap description "ET EXPLOIT Apache log4j RCE Attempt (http ldap)" sig "content:\"|24 7b|jndi|3a|ldap|3a 2f 2f|\";nocase;" id 2034647 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-http_rmi description "ET EXPLOIT Apache log4j RCE Attempt (http rmi)" sig "content:\"|24 7b|jndi|3a|rmi|3a 2f 2f|\"; nocase;" id 2034648 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-tcp_ldap description "ET EXPLOIT Apache log4j RCE Attempt (tcp ldap)" sig "content:\"|24 7b|jndi|3a|ldap|3a 2f 2f|\"; nocase;" id 2034649 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-tcp_rmi description "ET EXPLOIT Apache log4j RCE Attempt (tcp rmi)" sig "content:\"|24 7b|jndi|3a|rmi|3a 2f 2f|\"; nocase;" id 2034650 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-udp_ldap description "ET EXPLOIT Apache log4j RCE Attempt (udp ldap)" sig "content:\"|24 7b|jndi|3a|ldap|3a 2f 2f|\"; nocase;" id 2034651 protocol {udp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-udp_rmi description "ET EXPLOIT Apache log4j RCE Attempt (udp rmi)" sig "content:\"|24 7b|jndi|3a|rmi|3a 2f 2f|\"; nocase;" id 2034652 protocol {udp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-udp_dns description "ET EXPLOIT Apache log4j RCE Attempt (udp dns)" sig "content:\"|24 7b|jndi|3a|dns|3a 2f 2f|\"; nocase;" id 2034662 protocol {udp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-tcp_dns description "ET EXPLOIT Apache log4j RCE Attempt (tcp dns)" sig "content:\"|24 7b|jndi|3a|dns|3a 2f 2f|\"; nocase;" id 2034660 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-http_dns description "ET EXPLOIT Apache log4j RCE Attempt (http dns)" sig "content:\"|24 7b|jndi|3a|dns|3a 2f 2f|\"; nocase;" id 2034657 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-udp_ldaps description "ET EXPLOIT Apache log4j RCE Attempt (udp ldaps)" sig "content:\"|24 7b|jndi|3a|ldaps|3a 2f 2f|\"; nocase;" id 2034672 protocol {udp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-tcp_ldaps description "ET EXPLOIT Apache log4j RCE Attempt (tcp ldaps)" sig "content:\"|24 7b|jndi|3a|ldaps|3a 2f 2f|\"; nocase;" id 2034670 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " create ET_EXPLOIT_Apache_log4j_RCE_Attempt-http_ldaps description "ET EXPLOIT Apache log4j RCE Attempt (http ldaps)" sig "content:\"|24 7b|jndi|3a|ldaps|3a 2f 2f|\"; nocase;" id 2034667 protocol {tcp} reference-links "https://community.rsa.com/t5/netwitness-blog/apache-log4j-log4shell-background-and-detection-rules/ba-p/660546?attachment-id=32926" references "RSA SOC Prime Team authored these signatures. CVE-2021-44228" service http direction to-server attack-type attempted-admin documentation "https://www.f5.com/company/blog/protection-against-apache-log4j2-vulnerability https://lunasec.io/docs/blog/log4j-zero-day/ " My thanks to RSA for providing these signatures.Converting a Snort Rule to an AFM Protocol Inspection Custom Signature
We recently had the opportunity to demonstrate what I consider the most interesting use case for Protocol Inspection custom signatures: adapting existing Snort rules for use in AFM Protocol Inspection. Security company FireEye announced a breach in which the tools used by their red teams to test network and application defenses were stolen. FireEye released Snort rules to identify traffic associated with the command and control of these tools. We ported these Snort rules to AFM Protocol Inspection custom signatures and published them in F5's Guidance. https://devcentral.f5.com/s/articles/F5-SIRT-FireEye-Breach-Guidance The reason I find this such a compelling use case is that most of our customers have day jobs. They are not full-time security researchers who model application protocols and swap inside information with other security researchers as a profession. However, we can leverage the work of those who do have those jobs and adapt the Snort rules they write for use with AFM Protocol Inspection. That's exactly what we've done here and I'll show you the process we used to do it. General Observations First, I want to describe the relationship between a Snort rule and a Protocol Inspection custom signature. Basically, the detection syntax is the same, but everything else is different. Both provide tons of useful meta-data, but how that is provided by the two systems is different. Another thing to think about is preservation of information. I don't want my custom signature to lose any information present in the Snort rule. At a minimum, you will want to record where the custom signature came from. I recommend recording the source of the Snort rule in your custom signature in the references or reference-links fields, and retain anything that might provide a breadcrumb to your incident response, such as the Snort rule's msg , reference , and metadata field contents. If you can preserve the Snort rule's sid by the use of prefixes or suffixes in the custom signature's id , that might help an incident responder track down the original Snort rule. I'll show one approach to doing this in my conversion below. The Snort Signature - what we're adapting We'll adapt the following signature, provided by FireEye under a BSD license (see below): alert tcp any $HTTP_PORTS -> any any (msg:"Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]"; flow:from_server,established; content:"{\"meta\":{},\"status\":\"OK\",\"saved\":\"1\",\"starttime\":17656184060,\"id\":\"\",\"vims\":{\"dtc\":\""; sid:25888; rev:1;) Signature Creation walk-through Here's how I built out one Snort rule conversion into a custom signature. We'll go field by field, building out the command and editing as we go. The added or changed sections at each step will be in bold. I put a comparison of Snort rule elements and custom signature fields after the walk-thru if you want details on each step. I have a tmsh session open on the BIG-IP, in the security.protocol-inspection.signature context, and a Snort rule I can cut from to paste into my tmsh session. The first field I need is the custom signature name . I will use the msg field from the Snort rule as the basis for the name . This follows the convention for importing signatures from a file. I copy the Snort rule msg field, Backdoor.HTTP.BEACON.[CSBundle MSOffice Server], omitting the starting and ending quotation marks. I need to remove the brackets and remove or replace the spaces to use in the name . My convention is to remove prohibited characters and swap underscore characters for spaces. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server I can use the Snort rule msg unchanged for the description so long as I enclose it in quotes, and since it's in the copy buffer I'll add that field to my command next. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" Now the protocol field. This has to take the form of a list enclosed in curly braces. I take it from the protocol specified in the Snort rule's header. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} Now the references and reference-links . I took these from the web page announcing the issue the Snort rules address. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" Now the service , which is a mandatory field. I infer this is http from the Snort rule header section $HTTP_PORTS and the "HTTP" string in the msg. If you do not specify a service, the "other" service is selected for you. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http I derive the id from the Snort rule sid 25888. I'll prepend a 1 to bring it into the 100000+ range used for custom signatures. Because we have the references filled out, this is not critical. In fact, you could preserve the original Snort rule sid in the documentation section and just let the system assign the next available id number. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http id 125888 Specifying the direction can reduce log spam and misleading stats. For example, if you are interested in requests for http://mysite.example.com/../../etc/passwd but don't care about 404 errors in response, specify the direction to-server. That way only traffic to the server will match. In this case, our Snort rule's direction is to-client, which I infer from the Snort header source port being $HTTP_PORTS. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http id 125888 direction to-client Now we get to the good stuff: the sig field. I add sig " to my signature. sig is a container for pcre and content checks, and the container is delimited by UNESCAPED quotation marks. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http id 125888 direction to-client sig " I copy the payload detection elements from the Snort rule - all the content and pcre checks - and paste that in. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http id 125888 direction to-client sig "content:"{\"meta\":{},\"status\":\"OK\",\"saved\":\"1\",\"starttime\":17656184060,\"id\":\"\",\"vims\":{\"dtc\":\""; I add a double-quote character to the end, to identify the end of the sig field. This should NOT be escaped. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http id 125888 direction to-client sig "content:"{\"meta\":{},\"status\":\"OK\",\"saved\":\"1\",\"starttime\":17656184060,\"id\":\"\",\"vims\":{\"dtc\":\"";" I then go through and escape the quotation marks at the beginning and end of every content and pcre check with a backslash. Note I can ignore quotation marks already escaped inside these content and pcre checks. These added backslashes are in red for slightly easier identification. create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server4 description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http id 125888 direction to-client sig "content:\"{\"meta\":{},\"status\":\"OK\",\"saved\":\"1\",\"starttime\":17656184060,\"id\":\"\",\"vims\":{\"dtc\":\"\";" Now I can hit the 'Enter' key and my custom signature will be added. I can then select and enable it in Protocol Inspection policies. One note: the validation for custom signatures is letting me get away with a lot because I'm using BIG-IP v16.0.0. 14.x will not tolerate a signature definition that includes characters that are used in Snort syntax. It's a good practice to use the hexadecimal representation even in 16x. Here's what that would look like: create Backdoor.HTTP.BEACON.CSBundle_MSOffice_Server4 description "Backdoor.HTTP.BEACON.[CSBundle MSOffice Server]" protocol {tcp} references "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" reference-links "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html" service http id 125888 direction to-client sig "content:\"{|22|meta|22 3a|{},|22|status|22 3a 22|OK|22|,|22|saved|22 3a 22|1|22|,|22|starttime|22 3a|17656184060,|22|id|22 3a 22 22|,|22|vims|22 3a|{|22|dtc|22 3a 22|\";" Copyright 2020 by FireEye, Inc. The 2-Clause BSD License Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. For more information on Protocol Inspection Custom Signatures, see K00322533 Overview of Protocol Inspection Custom Signatures