Realtek SDK SIP ALG Vulnerability: A Big Deal, but not much you can do about it. CVE 2022-27255, (Sun, Aug 14th)

Realtek logotype
Realtek logotype

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.

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:[email protected] SIP/2.0
To: 9810972595144330
From: 30;tag=bb9c670d
Via: SIP/2.0/UDP 10.6.0.4:5076;branch=z9hG4bK-fd0aa04ce6b4b1c2ddfbe740e2bf453e;rport
Call-ID: fd0aa04ce6b4b1c2ddfbe740e2bf453e
CSeq: 1 INVITE
Contact:
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.

I have not seen any decent IDS rules yet. Keep in mind: The Snort SIP preprocessor, by default, only watches a few standard SIP-related ports. Attackers may launch the exploit over any port. The exploit does not depend on you using SIP or responding to anything in your network. It just requires that the vulnerable ALG code parses the SIP packet.


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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Alex Post