AFM Protocol Inspection rules for CVE-2022-3602 (aka SpookySSL)
AFM Protocol Inspection rules offer a flexible, performant way to inspect, log, alert and optionally block any network traffic passing through the BIG-IP which matches the configured ruleset.
I noticed that a couple of projects had delivered Snort-style rules for CVE-2022-3602 and so I wanted to build on the previous work by James Affeld and the F5 SIRT to see if those signatures could be adapted for use in AFM Protocol Inspection.
The good news is that they can - but there are some gotchas, and so I thought I'd document those here.
Emerging Threats rules
The Emerging Threats (ET) Open Ruleset for Suricata contains two rules for CVE-2022-3602, one for inbound traffic and one for outbound:
alert tls $EXTERNAL_NET any -> $HOME_NET any (msg:"ET EXPLOIT Possible OpenSSL Punycode Email Address Buffer Overflow Attempt Inbound (CVE-2022-3602)"; \
flow:established,to_client; \
tls.certs; \
content:"|06 03 55 1d 1e|"; \
content:"xn--"; fast_pattern; within:30; byte_test:2,>,513,-6,relative; \
reference:url,www.openssl.org/news/secadv/20221101.txt; \
reference:cve,2022-3602; \
classtype:attempted-admin; \
sid:2039618; rev:1; metadata:attack_target Server, created_at 2022_11_01, cve CVE_2022_3602, deployment Perimeter, former_category EXPLOIT, performance_impact Significant, signature_severity Major, updated_at 2022_11_02;)
alert tls $HOME_NET any -> any any (msg:"ET EXPLOIT Possible OpenSSL Punycode Email Address Buffer Overflow Attempt Outbound (CVE-2022-3602)"; \
flow:established,to_server; \
content:"|06 03 55 1d 1e|"; \
content:"xn--"; fast_pattern; within:30; byte_test:2,>,513,-6,relative; \
reference:url,www.openssl.org/news/secadv/20221101.txt; \
reference:cve,2022-3602; \
classtype:attempted-admin; \
sid:2039619; rev:1; metadata:attack_target Server, created_at 2022_11_02, cve CVE_2022_3602, deployment Perimeter, former_category EXPLOIT, performance_impact Significant, signature_severity Major, updated_at 2022_11_02;)Fox-IT rules
Fox-IT also have a Suricata rule available (https://github.com/fox-it/spookyssl-pcaps) along with pcaps which demonstrate the problem; it is worth noting that their rule is slightly more specific than the ET rules and discards certificates with very short punycoded names, where the resulting string would be too short to trigger the overflow.
alert tls any any -> any any (msg:"FOX-SRT - Exploit - Possible SpookySSL Certificate Observed (CVE-2022-3602)"; \
flow:established; \
content:"|2b 06 01 05 05 07 08 09|"; fast_pattern; \
content:"|06 03 55 1d 1e|"; content:"xn--"; \
content:!"|81|"; distance:-6; within:1; byte_test:2,>=,500,-6,relative; \
classtype:attempted-user; threshold:type limit,track by_src,count 1,seconds 3600; \
reference:url,www.openssl.org/news/secadv/20221101.txt; \
reference:url,https://github.com/fox-it/spookyssl-pcaps; \
metadata:ids suricata; \
metadata:created_at 2022-11-02; sid:21004268; rev:3;)AFM Protocol Inspection
My colleague Arvin and I started out trying to convert the Fox-IT rule into an AFM Protocol Inspection rule and we hit on a couple of strange issues caused by the negative 'distance' constraint on the negated match for 0x81 ('content:!"|81|"; distance: -6;') which appears to cause AFM to fail to match in the test cases. At this point I am not sure if that is due to our test scenario or due to the way AFM handles the negative distance and we are still looking into that, but I didn't want to hold off on writing this article; let me explain why.
I believe the best course of action for anyone running OpenSSL 3.x is to upgrade to the fixed release (3.0.7) as soon as possible, but given that even in the interim period it seems extremely unlikely that an attacker is going to be able to achieve more than simply crashing the thread handling their request in the vast majority of deployments, the value of these rules (in my opinion, at least) is simply in visibility into whether or not you are seeing punycoded values in SSL certificates. For example:
- In a client certificate authentication deployment - are clients sending potentially maliciously crafted certificates?
- In an inspection gateway deployment - are public websites sending potentially maliciously crafted certificates to your clients?
Both of these are interesting data points you can use to enrich your SIEM data and give visibility into the kind of threat actors who might be targeting you - assuming, of course, that your general use cases don't involve punycode domain names in SSL certificates!
The AFM rule
user@(host1)(pid-30952)(cfg-sync Standalone)(Active)(/Common)(tmos)# list security protocol-inspection signature openssl-sig-CVE-2022-3602
security protocol-inspection signature openssl-sig-CVE-2022-3602 {
attack-type protocol-other
description SpookySSL
documentation "Possible OpenSSL Punycode Email Address Buffer Overflow Attempt Outbound (CVE-2022-3602)"
id 100001
last-updated 2022-11-04:09:29:48
protocol "tcp"
reference-links https://github.com/fox-it/spookyssl-pcaps
revision 1
service ssl
sig "content: \"|06 03 55 1d 1e|\"; content:\"xn--\"; fast_pattern; within:30; byte_test:2,>,513,-6,relative;"
subscription no
user-defined yes
}
You can create the above signature by opening a tmsh session as an Administrative user and changing to the Signature context of Protocol Security, e.g.:
[user@host1:Active:Standalone] config # tmsh
user@(host1)(pid-31262)(cfg-sync Standalone)(Active)(/Common)(tmos)# security protocol-inspection signature
user@(host1)(pid-31262)(cfg-sync Standalone)(Active)(/Common)(tmos.security.protocol-inspection.signature)#
Once in the correct context (and partition, if applicable) the rules below can simply be copied & pasted, ensuring you maintain quotes and escaping exactly as-is (taking care to ensure any quote marks remain ASCII quotes and are not converted into “smart quotes”):
create openssl-sig-CVE-2022-3602 description SpookySSL attack-type protocol-other reference-links https://github.com/fox-it/spookyssl-pcaps service ssl protocol { tcp } sig "content: \"|06 03 55 1d 1e|\"; content:\"xn--\"; fast_pattern; within:30; byte_test:2,>,513,-6,relative; " documentation "Possible SpookySSL Certificate Observed (CVE-2022-3602) (Based on ET Open Ruleset)"You'll then want to ensure you have that signature associated with whatever Protocol Inspection profiles you have associated and that you're applying the correct action, of course.
The big "gotcha"
There's a huge gotcha in all this and it comes in the form of TLS 1.3. In TLS 1.3, certificates are no longer sent in the clear - they are sent in encrypted form (Fox-IT call that out in the readme on their github page, too). Of course that means that any signatures, whether deployed in AFM or any other engine, are no longer able to inspect the signature for potentially malicious punycoded strings.
If you are inspecting inbound traffic and you control the servers then you have at least a measure of choice here - disable TLS 1.3 and continue to have visibility into client certificates at the expense of some security, or enable TLS 1.3 and lose that visibility but gain security; of course, you've already upgraded to OpenSSL 3.0.7 so the risk here is minimal.. right?
If you're trying to inspect outbound traffic to servers you do not control (where you wish to inspect the incoming server certificate) then of course you have very little control over what the client and server negotiate. That's probably a topic for another blog!
Licenses
The ET Open Ruleset is distributed under the BSD License and Fox-IT rules are licensed under the MIT License, included here for compliance:
#*************************************************************
# Copyright (c) 2003-2021, Emerging Threats
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without modification, are permitted provided that the
# following conditions are met:
#
# * Redistributions of source code must retain the above copyright notice, this list of conditions and the following
# disclaimer.
# * 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.
# * Neither the name of the nor the names of its contributors may be used to endorse or promote products derived
# from this software without specific prior written permission.
#
# 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 OWNER 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.
#
#*************************************************************
MIT License
Copyright (c) 2022 Fox-IT
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
Updated Dec 06, 2022
Version 2.0
No CommentsBe the first to comment