Swiming Upstream: Aufdeckung von Broadcom SDK-Schwachstellen anhand von Bugreports

TL; TROCKEN;

Bei der Entwicklung von Erkennungsregeln für Broadcom-Binärdateien haben wir mehrere Sicherheitslücken identifiziert, die sich auf die UPnP-Implementierung des Broadcom SDK auswirken.

Obwohl wir Hinweise darauf fanden, dass Broadcom diese Sicherheitslücken bereits 2011 gepatcht hat, stellten wir fest, dass sie immer noch Geräte betreffen, die Jahre später von großen Anbietern wie Cisco, DD-WRT oder Linksys veröffentlicht wurden.

Dies führte zur Offenlegung von Sicherheitslücken wie
Anfang 2021.

Dies zeigt einmal mehr, wie wichtig es ist, die Sicherheit der Lieferkette zu validieren, wie z. B. sichere Entwicklungslebenszyklen und Quellcodeüberprüfungen auf Seiten des Lieferanten sowie eine Überprüfung des Quellcodes durch Dritte auf Seiten des Geräteanbieters. Mithilfe von IoT Inspector können dieses und viele andere Probleme in der Lieferkette automatisch identifiziert werden. In dem Bemühen, IoT sicher zu machen, können Sie
, kostenlos.

Überblick

In dem kontinuierlichen Bestreben, unsere Analyse der Softwarezusammensetzung zu erweitern, haben wir Regeln für Broadcom-Binärdateien untersucht, die wir häufig in angeschlossenen Geräten verschiedener Hersteller finden. Die Dateinamen dieser Binärdateien beginnen normalerweise mit bcm (z. B. bcm_atmctl, bcmcastctl, bcm_flasher,...). Dabei haben wir auch eine Broadcom-Binärdatei untersucht, die einen UPnP-Dienst implementiert, den wir in einem 4G/LTE-Router eines chinesischen Anbieters gefunden haben. Diese Binärdatei wurde bcmupnp genannt, und beim Umkehrvorgang entdeckten wir zwei offensichtliche Fehler:

Broadcom SDK (
)

N/A
n/a — Broadcom hat uns keine genauen, korrigierten Versionen mitgeteilt (unsere Schätzungen finden Sie unten).

Einige Anbieter entschieden sich dafür, das Problem zu beheben (DD-WRT), andere schlossen es als Wontfix (Cisco)
- DD-WRT

CVE-2021-27137 - DD-WRT - UNBEKANNT
CVE-2021-34730 - Cisco - 9,8 (kritisch) -
Q. Kaiser, IoT-Inspektor, Forschungslabor
Selim Enes Karaduman, in Zusammenarbeit mit SSD Disclosure
Die einzigen Informationen zu Fix/Non Fix stammen aus den Quellcode-Leaks von Broadcom auf GitHub. Erstes Erscheinen des Fixes für den Stacküberlauf im Upstream mit einer Änderung zu
:
* $Id: upnp_ssdp.c 305062 2011-12-26 10:48:21 Z Kenlo $
Das letzte Auftreten eines Heap-Pufferüberlaufs im Upstream, es gab nie einen öffentlichen Fix. Ich bin mir nicht sicher, wann es behoben wurde (wenn überhaupt).
* $Id: InternetGatewayDevice.c 241192 17.02.2011 21:52:25 Z gmo $

Die Sicherheitslücken

Stapelpufferüberlauf über ssdp_msearch

Das UPnP-Discovery-Protokoll basiert auf dem Simple Service Discovery Protocol (SSDP), einem UDP-Protokoll, das das HTTP-Nachrichtenformat verwendet.

Zwei Arten von Nachrichten können über SSDP gesendet werden:

Die Behandlung von SSDP-Anfragen wird implementiert von
Reihe:
struct upnp_method ssdp_methods [] =
{
{"M-SEARCH „, sizeof („M-SEARCH „) -1, METHOD_MSEARCH, ssdp_msearch},
{0, 0, 0, 0}
};
Dieses Array entspricht dem HTTP-Verb aus der eingehenden SSDP-Nachricht (
).

In
):
/* Analysieren Sie die M-SEARCH-Nachricht */
int ssdp_msearch (UPNP_CONTEXT *Kontext)
{
Zeichenname [128];
Minztyp;
char *host;
Zeichen *man;
Zeichen *st;

/* überprüfe HOST:239.255.255. 250:1900 */
host = Kontext->Host;
wenn (! host || strcmp (host, „239.255.255. 250:1900 „)! = 0)
gib -1 zurück;

/* check MAN: "ssdp:discover“ */
man = Kontext->Mann;
wenn (! man || strcmp (man, „\" ssdp:discover\ "“)! = 0)
gib -1 zurück;

/* Suchziel verarbeiten*/
st = Kontext->st;
wenn (! st)
gib -1 zurück;

if (strcmp (st, „ssdp:all“) == 0) {
typ = MSEARCH_ALL;
}
sonst wenn (strcmp (st, „upnp:rootdevice“) == 0) {
Typ = MSEARCH_ROOTDEVICE;
}
sonst wenn (memcmp (st, „uuid:“, 5) == 0) {
/* uuid */
Typ = MSEARCH_UUID;
st += 5;
strcpy (Name, Satz);
}
}
M-SUCHE* HTTP/1.1
GASTGEBER: 239,255,255. 250:1900
st:uuid:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...
MAX.: 2
MAN: "ssdp: discover“
Dieser Fehler ist voll ausnutzbar, da wir den Programmzähler kontrollieren. Im folgenden Beispiel zeigen wir, dass wir Register kontrollieren
auf einem ARM-basierten Ziel.

Wir haben einen schnellen Machbarkeitsnachweis für diesen Bug entwickelt, wobei Metasploit auf Cisco RV130 abzielt, basierend auf unserem
. Sie können den Exploit unten in Aktion sehen.

Heap-Pufferüberlauf über upnp_portmap_add

Das UPnP-Protokoll ermöglicht es lokalen Geräten, automatisch Portweiterleitungsregeln für sich selbst festzulegen, sodass ein Port, den sie intern bereitstellen, von der WAN-Schnittstelle des Geräts aus erreicht werden kann, das einen UPnP-Dienst bereitstellt. Dies erfolgt in der Regel durch Senden einer SOAP-Anfrage an den UPnP-Kontrolldienst. Diese Anfrage sollte den internen Client, den internen Port, die Remote-IP, den Remote-Port, das Protokoll und die Dauer enthalten, für die diese Regel gültig ist.

So würde eine legitime Portzuordnungsanfrage aussehen:
POST /control? WANIP-Verbindung HTTP/1.1
Gastgeber: 192.168.100. 1:1780
SoapAction: „urn: schemas-upnp-org: Dienst: WANIP-Verbindung: 1 #AddPortMapping“
Sprache akzeptieren: en-us; q=1, en; q=0.5
Accept-Encoding: gzip
Inhaltstyp: text/xml; charset="utf-8"
Verbindung: Keep-Alive
Inhaltslänge: 1105

<? xml-Version = „1.0"? <NewInternalPort><NewProtocol><NewExternalPort><NewRemoteHost>> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewLeaseDuration>3600-Spielekonsole 0 192.168.100.100</NewLeaseDuration> <NewPortMappingDescription><NewEnabled>52942 TCP 52942</NewEnabled></NewPortMappingDescription> <NewInternalClient>192.168.1.42</NewInternalClient></u:AddPortMapping></NewRemoteHost></NewExternalPort></NewProtocol></NewInternalPort> <s:Body> </s:Body></s:Envelope>
Über die UPnP-Portzuordnungsfunktion gibt es einen Heap-Pufferüberlauf. Der Überlauf erfolgt in einer verknüpften Liste von Portmapping-Einträgen (
).

In Zeile 3 eine Zuordnung zwischen der SOAP-Aktion
):
UPNP_ACTION action_x_wanipconnection [] =
{
{"addPortMapping“, 8, arg_in_addPortMapping, 0, 0, &action_AddPortMapping},
{"DeletePortMapping“, 3, arg_in_deletePortMapping, 0, 0, &action_deletePortMapping},
{"ForceTermination“, 0, 0, 0, 0, &Action_ForceTermination},
{"getConnectionTypeInfo“, 0, 0, 2, arg_out_getConnectionTypeInfo, &action_getConnectionTypeInfo},
{"getExternalIpAddress“, 0, 0, 1, arg_out_getExternalIpAddress, &action_getExternalIpAddress},
{"GetGenericPortMappingEntry“, 1, arg_in_getGenericPortMappingEntry, 8, arg_out_getGenericPortMappingEntry, &action_getGenericPortMappingEntry},
{"getNatrSipStatus“, 0, 0, 2, arg_out_getNatrSipStatus, &action_getNatrSipStatus},
{"getSpecificPortMappingEntry“, 3, arg_in_getSpecificPortMappingEntry, 5, arg_out_getSpecificPortMappingEntry, &action_getSpecificPortMappingEntry},
{"getStatusInfo“, 0, 0, 3, arg_out_getStatusInfo, &action_getStatusInfo},
{"Verbindung anfragen“, 0, 0, 0, 0, &Action_RequestConnection},
{"setConnectionType“, 1, arg_in_setConnectionType, 0, 0, &action_setConnectionType},
{0, 0, 0, 0, 0, 0}
};
In der Linie 26,
wird mit Argumenten aufgerufen, die aus dem SOAP-Envelope analysiert wurden:
/* << AUTOMATISCH GENERIERTE FUNKTION: Action_AddPortMapping () */
statisches Int
ACTION_ADDPORTZUORDNUNG
(
UPNP_CONTEXT * Kontext,
UPNP_SERVICE *Dienst,
IN_ARGUMENT *im_Argument,
OUT_ARGUMENT *OUT_ARGUMENT
)
{
/* --snip-- */

< USER CODE START >/* <> */
IN_ARGUMENT *IN_NewRemoteHost = UPNP_IN_ARG („NeuerRemoteHost“);
IN_ARGUMENT *IN_NEWExternalPort = UPNP_IN_ARG („Neuer externer Port“);
IN_ARGUMENT *IN_NewProtocol = UPNP_IN_ARG („Neues Protokoll“);
IN_ARGUMENT *IN_NEWINTERNALPORT = UPNP_IN_ARG („Neuer interner Port“);
IN_ARGUMENT *IN_NewInternalClient = UPNP_IN_ARG („Neuer interner Client“);
IN_ARGUMENT *IN_NewEnabled = UPNP_IN_ARG („Neuaktiviert“);
IN_ARGUMENT *in_newPortMappingDescription = UPNP_IN_ARG („Neue PortmappingBeschreibung“);
IN_ARGUMENT *IN_NewLeaseDuration = UPNP_IN_ARG („NewLeaseDuration“);

UPNP_STATE_VAR *Statusvariable;
UPNP_VALUE-Wert = {UPNP_TYPE_UI2, 2};

int-Fehler = upnp_portmap_add (Kontext),
ARG_STR (in_NewRemoteHost),
ARG_UI2 (in_neuer externer Anschluss),
ARG_STR (IN_NEUEM PROTOKOLL),
ARG_UI2 (in_neuer interner Anschluss),
ARG_STR (in_neuer interner Client),
ARG_BOOL (IN_NEWaktiviert),
ARG_STR (IN_NewPortMappingDescription),
ARG_UI4 (in_newLeaseDuration));
wenn (Fehler)
{
Fehler zurückgeben;
}
/* --snip-- */
}
Controller und validiert das empfangene Protokoll von Zeile 23 bis 27.

Anschließend wird überprüft, ob diese Port-Map bereits in Zeile 30 festgelegt ist. Wenn die Portzuweisung noch nicht vorhanden ist, wird der Portzuordnungsliste des Portzuordnungscontrollers (Zeilen 45-75) eine neue Portzuordnungsstruktur zugewiesen. Auf den Leitungen 89 bis 92 gibt es vier unsichere Anrufe an
gemacht werden, was der Kern dieser Sicherheitslücke ist:
/* Fügt einen neuen Portzuordnungseintrag hinzu */
int
upnp_portmap_add
(
UPNP_CONTEXT *Kontext,
Zeichen *remote_host,
vorzeichenloser kurzer external_port,
char *protokoll,
vorzeichenloser kurzer internal_port,
char *interner_client,
unsigned int aktiviert,
char *Beschreibung,
unsigniert, lange Dauer
)
{
UPNP_PORTMAP_CTRL *portmap_ctrl;
UPNP_PORTMAP *map;

/* Kontrollinstanz abrufen*/
portmap_ctrl = (UPNP_PORTMAP_CTRL *) (kontext->focus_ifp->focus_devchain->devctrl);

/* Datenvalidierung */
if (strcasecmp (Protokoll, „TCP“)! = 0 &&
strcasecmp (Protokoll, „UDP“)! = 0) {
upnp_syslog (LOG_ERR, „add_portmap:: Ungültiges Protokoll“);
gibt SOAP_ARGUMENT_VALUE_INVALID zurück;
}

/* Duplikat prüfen*/
map = upnp_portmap_find (Kontext, remote_host, external_port, protokoll);
wenn (Karte) {
if (strcmp (internal_client, map->internal_client)! = 0)
gibt SOAP_CONFLICT_IN_MAPPING_ENTRY zurück;

/* Argus, lass es wie Shutdown aussehen */
wenn (aktivieren! = karte->aktivieren ||
interner_Anschluss! = karte->interner_port) {

if (map->enable) {
karte->aktivieren = 0;
upnp_osl_nat_config (Karte);
}
}
}
sonst {
if (portmap_ctrl->num == portmap_ctrl->limit) {

UPNP_PORTMAP_CTRL *neue_portmap_ctrl;

int old_limit = portmap_ctrl->limit;
int old_size = UPNP_PORTMAP_CTRL_SIZE + old_limit * sizeof (UPNP_PORTMAP);

int neue_limit = alte_limit * 2;
int new_size = UPNP_PORTMAP_CTRL_SIZE + new_limit * sizeof (UPNP_PORTMAP);

/*
* ein neues für die doppelte Größe auswählen,
* Der Grund, warum wir Realloc nicht verwenden, ist, wenn Realloc fehlgeschlagen ist,
* Die alte Erinnerung wird weg sein!
*/
new_portmap_ctrl = (UPNP_PORTMAP_CTRL *) malloc (neue_Größe);
wenn (new_portmap_ctrl == 0)
gibt SOAP_OUT_OF_MEMORY zurück;

/* Kopiere das alte auf das neue und befreie es */
memcpy (neue_portmap_ctrl, portmap_ctrl, alten_größe);

kostenlos (portmap_ctrl);

/* Ordne den neuen als portmap_ctrl zu */
portmap_ctrl = neue_portmap_ctrl;
kontext->focus_ifp->focus_devchain->devctrl = neue_portmap_ctrl;

portmap_ctrl->limit = neue_grenze;
}

/* Lokalisiere die Karte und vergrößere die Gesamtzahl */
map = portmap_ctrl->pmlist + portmap_ctrl->num;
portmap_ctrl->num++;
}

/* Datenbank aktualisieren*/
karte->external_port = externer_port;
karte->internal_port = interner_port;
map->enable = aktivieren;
karte->Dauer = Dauer;
karte->book_time = Zeit (0);

strcpy (karte->remote_host, remote_host);
strcpy (map->protocol, protocol);
strcpy (map->interner_client, interner_client);
strcpy (map->Beschreibung, Beschreibung);

/* Auf NAT-Kernel setzen */
if (map->enable)
upnp_osl_nat_config (Karte);

gib 0 zurück;
}

Auslöser:
POST /control? WANIP-Verbindung HTTP/1.1
Gastgeber: 192.168.100. 1:1780
SoapAction: „urn: schemas-upnp-org: Dienst: WANIP-Verbindung: 1 #AddPortMapping“
Sprache akzeptieren: en-us; q=1, en; q=0.5
Accept-Encoding: gzip
Inhaltstyp: text/xml; charset="utf-8"
Verbindung: Keep-Alive
Inhaltslänge: 1105

<? xml-Version"1.0"? <NewEnabled><NewInternalClient><NewInternalPort><NewProtocol><NewExternalPort><NewRemoteHost>> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewLeaseDuration>0 AAAAAAAAA 0</NewLeaseDuration> <NewPortMappingDescription>192.168.100.100 8000 TCP 8000 192.168.1.42</NewPortMappingDescription></u:AddPortMapping></s:Body></NewRemoteHost></NewExternalPort></NewProtocol></NewInternalPort></NewInternalClient></NewEnabled> </s:Envelope>
Interessanterweise kann dieser Heap-Overflow unter bestimmten Bedingungen in einen Stack-Pufferüberlauf umgewandelt werden. Dieser Fehler ist daher direkt ausnutzbar, da wir den Programmzähler kontrollieren. Im folgenden Beispiel zeigen wir, dass wir Register kontrollieren
auf einem ARM-basierten Ziel.

Einstellung
Validierung (Überprüfung, ob sie der WAN-IP entspricht), indem ein Zeichenfolgenwert anstelle eines punktierten dezimalen IP-Werts festgelegt wird.

Frühere Entdeckungen

Als wir nach Zeichenketten in der Binärdatei googelten, stießen wir auf den Quellcode von Broadcom, der im Subversion-Repository von DD-WRT gehostet wird. Zu diesem Zeitpunkt wurde es interessant.

Wir haben den Stack-Pufferüberlauf im Code unter identifiziert
.

Wir haben den Heap-Pufferüberlauf im Code unter identifiziert
.

Die Sicherheitslücke war in einer älteren Version vorhanden, aber die
, was uns fasziniert hat.

Wir haben überprüft, wann diese Änderung vorgenommen wurde:
svn blame ssdp.c | grep strlcpy
45724 Brainslayer strlcpy (Name, Set, Größe von (Name));
Habe mir das Commit selbst angesehen:
svn diff -c 45724
Stichwortverzeichnis: ssdp.c
===================================================================
--- ssdp.c (Version 45723)
+++ ssdp.c (Version 45724)
@@ -382,7 +382,7 @@
/* uuid */
Typ = MSEARCH_UUID;
st += 5;
- strcpy (Name, Satz);
+ strlcpy (name, st, sizeof (name));
}
sonst {
/* überprüfe advertise_table auf den angegebenen Namen. */
Und die Commit-Nachricht:
svn log -r 45724
--------------------------------------------------------
r45724 | brainslayer | 09.02.2021 09:48:07 +0100 (Di, 09. Februar 2021) | 1 Zeile
Behebung eines potenziellen Stack-Überlaufs mit modifizierter UPNP-Anfrage
--------------------------------------------------------
Als wir dann nach „DD-WRT Stack Overflow“ googelten, fanden wir schließlich diesen Hinweis von SSD Disclosure:
. Es erwähnt nur DD-WRT und nicht den Heap-Pufferüberlauf.

Obwohl es im Advisory nicht erwähnt wird, haben auch die DD-WRT-Betreuer den potenziellen Heap-Overflow erkannt und ihn in ihrem Branch behoben:
svn schuld. /Gerät/InternetGatewayDevice/InternetGatewayDevice.c | grep strlcpy
45725 Brainslayer strlcpy (map->remote_host, remote_host, sizeof (map->remote_host));
45725 brainslaye strlcpy (map->protocol, protocol, sizeof (map->protocol));
45725 Brainslayer strlcpy (map->internal_client, internal_client, sizeof (map->internal_client));
45725 brainslaye strlcpy (Karte->Beschreibung, Beschreibung, Größe von (Karte->Beschreibung));
Nachricht bestätigen:
svn log -r 45725
--------------------------------------------------------
r45725 | brainslayer | 09.02.2021 10:11:39 +0100 (Di, 09. Februar 2021) | 1 Zeile

anderen potenziell unsicheren Code überarbeiten
--------------------------------------------------------

Lass die Jagd beginnen

Wir haben also zwei schwerwiegende Sicherheitslücken, die die UPnP-Implementierung betreffen, die Teil des SDK von Broadcom ist, aber es wurde nie eine Empfehlung dazu veröffentlicht. In der bisher einzigen Veröffentlichung wird DD-WRT erwähnt.

Wir haben schnell eine Regel zur Erkennung von Sicherheitslücken geschrieben und uns auf die Suche nach unserem Firmware-Datensatz gemacht. Wir haben die folgenden betroffenen Geräte identifiziert:

Firmware-Images von Asus und NETGEAR enthielten eine UPnP-Binärdatei, die aus dem SDK von Broadcom erstellt wurde, aber sowohl Stack- als auch Heap-Überläufe wurden behoben.

Abbildung der Lieferkette

Das folgende Diagramm soll Ihnen helfen, die komplexen Lieferketten besser zu verstehen. Artikel, die oben mit einem Stern markiert sind, beziehen sich auf den Stapelüberlauf, der als CVE-2021-27137 aufgezeichnet wurde.

In einer idealen Welt hätte die erste Entdeckung dieser Probleme im Jahr 2012/2013 Broadcom gemeldet werden müssen, wenn nicht von den Forschern, dann zumindest von den betroffenen Herstellern. Broadcom hätte einen Patch veröffentlicht, der wiederum von allen Herstellern angewendet worden wäre, die sich auf den UPnP-Stack von Broadcom verlassen haben. Stattdessen besteht die Sicherheitslücke auch 2021 weiter — kann aber zumindest von IoT Inspector automatisch identifiziert werden.

Flussaufwärts

Um die betroffenen Anbieter ausfindig zu machen, verlassen wir uns auf die leistungsstarke Suchmaschine von GitHub, um Repositorys zu identifizieren, die den UPnP-Code von Broadcom enthalten.

Während des Prozesses entdeckten wir unheimliche Ähnlichkeiten zwischen zwei verschiedenen SDKs: eines von Ralink Tech Inc., das 2002 veröffentlicht wurde, und das von Broadcom, das derzeit untersucht wird, wurde Mitte 2008 veröffentlicht.

Es gibt zwar vielleicht nicht hundert Möglichkeiten, eine UPnP-Dienstimplementierung in C zu schreiben, aber diese beiden Implementierungen machen exakt dieselben Fehler an genau den gleichen Stellen in ihren Codes. Jede von ihnen hätte unsichere C-Funktionen an anderen Stellen verwenden können, aber sie haben sie nur in diesen beiden spezifischen Funktionen gemacht.

Wir können nur spekulieren, ob Broadcom sich von Ralink inspirieren ließ — aber wenn das der Fall ist, sind diese beiden UPnP-Bugs seit fast 20 Jahren am Leben und wohlauf.

Fazit

Da das Bewusstsein von Sicherheitsexperten für Transparenz in der Lieferkette zunimmt, ist dies ein weiteres Beispiel für die enormen Auswirkungen einer obskuren IoT-Lieferkette. Allzu oft sind kritische Sicherheitslücken das Ergebnis einer undurchsichtigen Lieferkette, und zwar aus drei einfachen Gründen:

PSIRTS von Anbietern entlang der Lieferkette müssen beginnen, enger zusammenzuarbeiten, um sicherzustellen, dass Sicherheitsprobleme innerhalb der Lieferkette rechtzeitig gemeldet werden. Dann haben wir die Chance, dass kritische Sicherheitslücken behoben werden, bevor sie von Cyberkriminellen ausgenutzt werden.

Unser Firmware-Analyseplattform IoT Inspector kann bei der Erkennung solch entscheidender Lieferkettenprobleme helfen. Es erkennt automatisch, ob eine Firmware auf einem anfälligen Broadcom SDK basiert. Um das Internet der Dinge sicher zu machen, können Sie überprüfen Sie, ob Sie betroffen sind, kostenlos.

Zeitleiste