Issue: We have recently identified an issue encountered while utilizing the Unifi Route device. Randomly, our UDP connections were closed. According to the log, the closure of the UDP is triggered by the rule “ET SHELLCODE Possible Call with No Offset UDP Shellcode”; content:"|E8 00 00 00 00 0F 1A|,” which I located here suricata-rules/emerging-shellcode.rules at main · vncloudsco/suricata-rules · GitHub.
Upon further investigation, it is evident that this is unequivocally a false positive, as UDP data is easy to triggering this pattern |E8 00 00 00 00 0F 1A|, especially in our case it’s EndtoEnd Delay extension in RTP header, given that it is not encoded.
Ask:
Please explain the rule detail and is this good detect the RTP header(our case EndtoEnd Delay).
Please help to confirm if this false positive.
Please advise on the best strategies that our software could employ to avoid triggering these patterns.
Thanks for reaching out! This rule is really old (2010!) and pretty generic so it is very FP prone. Looking at the ruleset, there are 10 signatures that have similar logic which are also very generic.
One aspect that makes these rules especially generic that they only check for two conditions:
Traffic from $EXTERNAL_NET -> $HOME_NET
The single hex string |E8 00 00 00 00 0F 1A|
That being said the rule logic is based off of this Netwitness blog which is looking for various opcodes that could occur in malicious shellcode. 2012091 specifically detects a hex string with these instructions:
E8 00 00 00 00 (CALL RELATIVE)
0F 1A (Start of a NOP)
After doing some Googling it seems like these rules are causing a decent amount of false positives for people accross a wide range of deployments. I found examples ranging from webcams to World of Warcraft traffic.
Due to the age of the rule and the number of FP’s I am going to disable it (and the related signatures) in today’s release. You should see the change reflected later this afternoon. If you have any other questions or concerns please feel free to ask and I’m happy to help!
In rules file, there exists several shellcode rules, like:
|E8 00 00 00 00 58|
|E8 00 00 00 00 0F A9|
|E8 00 00 00 00 8F|
Whether could these rules also be disabled?
@Tyrion - The following signatures related to the same reference which all include variants of |E8 00 00 00 00 XX . . .| were removed:
Possible Call with No Offset TCP Shellcode - 2012086
Possible Call with No Offset TCP Shellcode - 2012088
Possible Call with No Offset TCP Shellcode - 2012090
Possible Call with No Offset TCP Shellcode - 2012092
Possible Call with No Offset UDP Shellcode - 2012087
Possible Call with No Offset UDP Shellcode - 2012089
Possible Call with No Offset UDP Shellcode - 2012091
Possible Call with No Offset UDP Shellcode - 2012093
There are two ETPRO rules which contain the a hex pattern but are not related or FP prone so no changes need to be made there. Yesterday I inadvertently included these in my count so there are only 8 signatures total that needed to be disabled.
@Witty - Typically we communicate our ruleset updates via our Daily Community Ruleset Posts and Twitter. Here is yesterday’s post which shows removed rules.
Assuming Unifi customers are pulling from our official daily ruleset no other changes will be need to be made. That being said if you are manually pulling rules you should use https://rules.emergingthreats.net/ as opposed to that github repo you shared which is 4+ years out of date.
If there is an active support thread on their support forum I’m more than happy to post an update there .
.