On Friday, Octavio Gianatiempo & Octavio Galland released details about a vulnerability in Realtek's eCos SDK. The release came as part of their talk at Defcon. Realtek patched the vulnerability they spoke about in March. But this patch may not do you much good. The vulnerability affects Realtek's SDK. Various vendors use this SDK as part of the equipment that uses Realtek's RTL819x SoCs. Affected vendors need to release patched firmware to mitigate this vulnerability. Many affected vendors have not yet released updates.

BLUF:

• Devices using firmware built around the Realtek eCOS SDK before March 2022 are vulnerable
• You are vulnerable even if you do not expose any admin interface functionality
• Attackers may use a single UDP packet to an arbitrary port to exploit the vulnerability
• This vulnerability will likely affect routers the most, but some IoT devices built around Realtek's SDK may also be affected.

You may check the complete slide deck from the talk here https://github.com/infobyte/cve-2022-27255/blob/main/DEFCON/slides.pdf.

We created a brief more "manager-focused" presentation here: https://isc.sans.edu/presentations/Realtek_SDK_SIP_Vulnerablity.pptx. Feel free to use and modify as needed.

The Realtek SDK implements an Application Layer Gateway (ALG) for SIP. Many routers do that to allow SIP to work past NAT. NAT alters a packet's IP addresses. But the SIP payload also includes the IP addresses, and the ALG ensures that the IP addresses in the payload match the routable IP address of the gateway.

Here is a quick sample SIP payload from one of our honeypots:

INVITE sip:9810972595144330@46.244.23.4 SIP/2.0
To: 9810972595144330<sip:9810972595144330@46.244.23.4>
From: 30<sip:30@46.244.23.4>;tag=bb9c670d
Via: SIP/2.0/UDP 10.6.0.4:5076;branch=z9hG4bK-fd0aa04ce6b4b1c2ddfbe740e2bf453e;rport
Call-ID: fd0aa04ce6b4b1c2ddfbe740e2bf453e
CSeq: 1 INVITE
Contact: <sip:30@10.6.0.4:5076>
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, BYE
User-Agent: sipcli/v1.8
Content-Type: application/sdp
Content-Length: 271

v=0
o=sipcli-Session 991233794 534482564 IN IP4 10.6.0.4
s=sipcli
c=IN IP4 10.6.0.4
t=0 0
m=audio 5077 RTP/AVP 18 0 8 101
a=fmtp:101 0-15
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=sendrecv

The critical part is highlighted in orange/red. An attacker can trigger a stack-based buffer overflow by sending an arbitrary string. The paper demonstrates how code execution is easily accomplished.

According to the presentation, POCexploit would look as simple as (abbreviated. Needs at least 256 "a"s):

INVITE sip:x SIP/2.0
Content-Length: 388

v=0
o=jdoe 2890844526 2890842807 IN IP4
10.47.16.5
c=IN IP4 24.2.17.12
t=2873397496 2873404696
a=recvonly
m=audio 49170 aaaaaaaaaa...aaaaaaaa 

Only the last line matters. This simple PoC should crash a vulnerable device. This and other exploits are available via the presentation author's GitHub repo (https://github.com/infobyte/cve-2022-27255)

You can find a PCAP I recorded from one of the exploits (the one starting a telnet server) here: exploit.pcap

So what can you do about this?

First of all, make sure your firmware is up to date. There is a chance that your vendor did release an update. Secondly, if you can block unsolicited UDP requests at your perimeter, this isn't easy, and you must be careful not to block anything critical. But remember, you only need to block "unsolicited inbound" traffic. Traffic like DNS responses is still ok. This may be an option depending on the capabilities of your firewall. Protocols like gaming and some VoIP systems may give you a more difficult time with rules like this. For VoIP, you may be able to allowlist your VoIP provider. 

Other than that: Be vigilant. Do not "trust" your router (which means moving to more host-based controls or, dare I say it: Zero trust. Nothing you are going to fully implement today.

Below I included my snort rule for this exploit. Let me know if it can be improved. It works for the PoC exploit. I decided against using the SIP preprocessor. At least in Snort 2.9, the SIP preprocessor only looks at specific ports, and the exploit may use any port. Asking the SIP preprocessor to look at any port is likely not efficient. Snort 3 may be different here with its better protocol detection. As this is a single UDP packet exploit, using the stream preprocessor doesn't make too much sense either. You may want to adjust the target IP from "any" to the IP address of the device that you are protecting. I kept the metadata light to not distract from the actual rule.

alert udp any any -> any any (sid:1000000; \
msg:"Realtek eCOS SDK SIP Traffic Exploit CVE-2022-27255"; \
content: "invite"; depth: 6; nocase; \
content: "m=audio "; \
isdataat: 128,relative;   content:!"|0d|"; within: 128;)

The rule looks for "INVITE" messages that contain the string "m=audio ". It triggers if there are more than 128 bytes following the string (128 bytes is the size of the buffer allocated by the Realtek SDK) and if none of those bytes is a carriage return. The rule may even work sufficiently well without the last content match. Let me know if you see any errors or improvements.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|