xolxo
(xolxo)
July 16, 2020, 11:55am
1
Hi,
recently Microsoft revealed very critical DNS vulnerability (CVSS base score of 10.0). Perhaps some one has already created a rule for it and could share it or maybe could help with creating one.
Based on analysis of CVE-2020-1350 I came to the following steps of attack:
DNS request is sent
DNS reply with truncation flag is received
TCP connection via DNS 53 is setup
DNS request sent via TCP
DNS reply with max size 65535 and with manipulated DNS Pointer Compression 0xC0 received
Manipulation of DNS Pointer Compression causes heap based buffer overwrite because DNS response contains a large (bigger than 64KB) SIG record
Could anyone share an idea how better to implement this rule. My current idea based on my introduction level with Suricata is the following:
alert tcp $EXTERNAL_NET 53 -> $HOME_NET any (msg:”SIGRed (CVE-2020-1350) possible exploit”; dsize:>65534")
Thank you in advance.
Hi!
The ET OPEN set has two rules for this currently, sid 2030532 and 2030533. Feel free to take a look and see if those will work for you.
JT
1 Like
xolxo
(xolxo)
July 16, 2020, 1:04pm
3
Thank you. I have found them. Just in case here is the two entries you have mentioned.
alert tcp any 53 -> any any (msg:“ET EXPLOIT Possible Windows DNS Integer Overflow Attempt M1 (CVE-2020-1350)”; flow:established,from_server; content:"|ff|"; depth:1; byte_test:1,>=,0xec,0,relative; content:"|00 00 18|"; distance:12; within:64; fast_pattern; content:"|c0|"; distance:2; within:1; content:"|00 18|"; distance:1; within:2; metadata: former_category EXPLOIT; reference:cve,2020-1350; reference:url,research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/; classtype:attempted-admin; sid:2030533; rev:3; metadata:affected_product Windows_DNS_server, signature_severity Critical, created_at 2020_07_14, performance_impact Significant, updated_at 2020_07_16;)
alert tcp any any -> any 53 (msg:“ET EXPLOIT Possible Windows DNS Integer Overflow Attempt M2 (CVE-2020-1350)”; flow:established,to_server; content:"|ff|"; depth:1; byte_test:1,>=,0xec,0,relative; content:"|00 00 18|"; distance:12; within:64; fast_pattern; content:"|c0|"; distance:2; within:1; content:"|00 18|"; distance:1; within:2; metadata: former_category EXPLOIT; reference:cve,2020-1350; reference:url,research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/; classtype:attempted-admin; sid:2030532; rev:4; metadata:affected_product Windows_DNS_server, signature_severity Critical, created_at 2020_07_14, performance_impact Significant, updated_at 2020_07_16;)
konstantin
(Konstantin Klinger)
July 16, 2020, 4:15pm
4
1 Like
felmoltor
(Felipe Molina)
July 17, 2020, 8:46am
5
Hi, I have created a couple of rules too. Let me know if you have available PoC and if these rules work for you:
sigred.rules
# Author: Felipe Molina de la Torre (@felmoltor)
# If not already defined, define in your suricata.yaml document the variable $DNS_SERVERS pointing to your Windows DNS servers array
# e.g. DNS_SERVERS = [10.20.30.1,10.20.30.2,10.20.30.3]
# A TCP dns answer (0x80 in the offset 4) with a payload greater than 65280 (0xFF00) and containing the malformed compression bytes "0xc00d"
# Why 0XFF00? I saw PoC sending tcp palyoads smaller than I initially thought (0xFFF0). To have an overflow I would need con consider that ASCII characters of the domain name can take values from 0 to 255. The first character of the domain name is going to be used to overflow the buffer, so, assuming the limit case (65535-255 = 65280 = 0xFF00)
# The 00 00 18 00 01 payload means "termination of the domain name string" (0x00) with a following SIG (0x0018) IN (0x0001) answer within the first 120 bytes of the TCP payload
alert tcp $EXTERNAL_NET 53 -> $DNS_SERVERS any (msg:"Windows DNS Exploit (Compressed SIG record)";flow:established,to_client;classtype:denial-of-service;byte_test:2,>,0xFF00,0;byte_test:2,&,0x80,4;content: "|00 00 18 00 01|";within: 120;content:"|c0 0d|";reference:cve,2020-1350;sid:666662;rev:2;)
This file has been truncated. show original
I would like to have some feedback about them