
Ripple20 – Gefährliche Sicherheitslücke in unzähligen Geräten entdeckt
Nozomi
Forscher der israelischen Sicherheitsfirma JSOF haben in der Low-Level TCP/IP Software-Bibliothek der Firma Treck 19 Sicherheitslücken entdeckt, die dazu ausgenutzt werden können, mit geringem Aufwand entweder Daten zu entwenden oder zu manipulieren. Auch die komplette Kontrolle über ein Gerät ist möglich. Die Sicherheitslücken haben einen CVSSv3 Score von bis zu 10, was einer Remote-Code-Execution Lücke entspricht. Das heißt, es kann Remote, sprich über das Internet, beliebiger Code auf einem Gerät ausgeführt werden, ohne dass eine Aktivität seitens des Nutzers/Betreibers erforderlich ist.
Entsprechende CVEs lauten:
CVE ID | CSSv3 Wert | Beschreibung |
CVE-2020-11896 | 10 | Diese Schwachstelle kann durch das Senden mehrerer missgebildeter IPv4-Pakete an ein Gerät, das IPv4-Tunneling unterstützt, ausgenutzt werden. Sie betrifft jedes Gerät, auf dem Treck mit einer bestimmten Konfiguration läuft. Sie kann eine stabile Remote-Codeausführung ermöglichen und wurde auf einem Digi International-Gerät demonstriert. Varianten dieser Schwachstelle können ausgenutzt werden, um eine anhaltende Dienstverweigerung (Denial-of-Service) zu verursachen, die einen Hard-Reset des Geräts erfordern. |
CVE-2020-11897 | 10 | Diese Schwachstelle kann durch das Senden mehrerer missgebildeter IPv6-Pakete an ein Gerät ausgenutzt werden. Sie betrifft jedes Gerät, auf dem eine ältere Version von Treck mit IPv6-Unterstützung läuft. Es kann möglicherweise eine Remote-Codeausführung ermöglichen. |
CVE-2020-11901 | 9 | Diese Schwachstelle kann durch die Beantwortung einer einzelnen DNS-Anfrage des Geräts ausgenutzt werden. Es betrifft jedes Gerät, auf dem Treck mit DNS-Unterstützung läuft, und es wurde demonstriert, dass es auch zur Remote-Code-Ausführung auf einer APC-USV von Schneider Electric verwendet werden kann. Trotz eines CVSS-Scores von 9,0 ist diese eine der schwerwiegendsten Schwachstellen, da DNS-Anfragen das Netzwerk, in dem sich das Gerät befindet, verlassen können und ein raffinierter Angreifer diese Schwachstelle nutzen kann, um ein Gerät von außerhalb des Netzwerks durch DNS-Cache-Poisoning oder andere Methoden zu übernehmen. So kann ein Angreifer in das Netzwerk eindringen und das Gerät mit Umgehung aller Sicherheitsmaßnahmen übernehmen. |
CVE-2020-11898 | 9,1 | Das missgebildete Paket ist fast vollständig RFC-konform, so dass es für Sicherheitsprodukte wie Firewalls wahrscheinlich schwierig sein wird, diese Schwachstelle zu erkennen. Auf sehr alten Versionen des Treck-Stacks, die auf einigen Geräten noch laufen, ist die Transaktions-ID nicht randomisiert, was den Angriff erleichtert. |
CVE-2020-11900 | 8,2 | Unsachgemäße Behandlung der Längenparameter-Inkonsistenz (CWE-130) in der IPv4/ICMPv4-Komponente bei der Behandlung eines gesendeten Pakets von einem nicht autorisierten Netzwerkangreifer. Mögliche Preisgabe sensibler Informationen (CWE-200) |
CVE-2020-11902 | 7,3 | Möglicherweise Double Free (CWE-415) in der IPv4-Tunnelkomponente bei der Behandlung eines gesendeten Pakets von einem Netzwerkangreifer. Verwendung nach Freigabe (CWE-416) |
CVE-2020-11904 | 5,6 | Falsche Eingabevalidierung (CWE-20) in IPv6OverIPv4-Tunneling-Komponente bei der Behandlung eines gesendeten Pakets von einem nicht autorisierten Netzwerkangreifer. Mögliches Out-of-Bounds Lesen (CWE-125) |
CVE-2020-11899 | 5,4 | Möglicher Integer-Overflow oder Wraparound (CWE-190) in der Speicherzuweisungskomponente bei der Behandlung eines von gesendeten Pakets einem nicht autorisierten Netzwerkangreifer Mögliches "Out-of-Bounds"-Schreiben (CWE-787) |
CVE-2020-11903 | 5,3 | Falsche Eingabevalidierung (CWE-20) in IPv6-Komponente bei der Behandlung eines gesendeten Pakets von einem nicht autorisierten Netzwerkangreifer . Mögliche Out-of-bounds-Lesung (CWE-125) und mögliche Dienstverweigerung (Denial of Service). |
CVE-2020-11905 | 5,3 | Mögliches Out-of-bounds Read (CWE-125) in der DHCP-Komponente bei der Behandlung eines gesendeten Pakets von einem nicht autorisierten Netzwerkangreifer gesendeten Pakets. Mögliche Preisgabe sensibler Informationen (CWE-200) |
CVE-2020-11906 | 5 | Unsachgemäße Eingabevalidierung (CWE-20) in der Ethernet-Link-Layer-Komponente aus einem gesendeten Paket von einem nicht autorisierten Benutzer. Ganzzahliger Unterlauf (CWE-191) |
CVE-2020-11907 | 5 | Unsachgemäße Behandlung der Längenparameter-Inkonsistenz (CWE-130) in der TCP-Komponente aus einem gesendeten Paket von einem nicht autorisierten Netzwerkangreifer. Ganzzahliger Unterlauf (CWE-191) |
CVE-2020-11909 | 3,7 | Falsche Eingabevalidierung (CWE-20) in IPv4-Komponente bei der Behandlung eines gesendeten Pakets von einem nicht autorisierten Netzwerkangreifer. Ganzzahliger Unterlauf (CWE-191) |
CVE-2020-11910 | 3,7 | Falsche Eingabevalidierung (CWE-20) in der ICMPv4-Komponente bei der Behandlung eines gesendeten Pakets von einem nicht autorisierten Netzwerkangreifer. Mögliches Out-of-Bounds Lesen (CWE-125) |
CVE-2020-11911 | 3,7 | Unzulässige Zugriffskontrolle (CWE-284) in der ICMPv4-Komponente bei der Handhabung eines gesendeten Pakets von einem nicht autorisierten Netzwerkangreifer. Falsche Berechtigungszuweisung für kritische Ressource (CWE-732) |
CVE-2020-11912 | 3,7 | Falsche Eingabevalidierung (CWE-20) in der TCP-Komponente bei der Behandlung eines gesendeten Pakets von einem nicht autorisierten Netzwerkangreifer. Mögliches Out-of-Bounds Lesen (CWE-125) |
CVE-2020-11913 | 3,7 | Falsche Eingabevalidierung (CWE-20) in IPv6-Komponente bei der Behandlung eines gesendeten Pakets von einem nicht autorisierten Netzwerkangreifer. Mögliches Out-of-Bounds Lesen (CWE-125) |
CVE-2020-11914 | 3,1 |
Unsachgemäße Eingabevalidierung (CWE-20) in der ARP-Komponente bei der Handhabung eines gesendeten Pakets von einem nicht autorisierten Netzwerkangreifer. |
CVE-2020-11908 | 3,1 |
Unzulässige Nullterminierung (CWE-170) in der DHCP-Komponente bei der Behandlung eines gesendeten Pakets von einem nicht autorisierten Netzwerkangreifer. |
Die Sicherheitslücken wurde mit Version 6.0.1.67 der Software-Bibliothek behoben, welche am 3. März 2020 veröffentlicht wurde. Leider ist es dem Endanwender meist nicht möglich, diese Software-Bibliothek selber zu aktualisieren. Hier ist ein manuelles Update seitens der Hersteller erforderlich.
Welche Geräte sind von Ripple20 betroffen?
Dies ist eine gute Frage, auf die es leider noch keine ausreichende Antwort gibt. Grundsätzlich ist jedes Produkt mit dieser Software-Bibliothek betroffen. Dabei kann es sich um einen einfachen Drucker, eine Smart Home-Komponente wie beispielsweise eine ferngesteuerte Steckdose oder sogar gewisse Industriemaschinen handeln. Zudem seien auch manche Flugzeuge und Satelliten betroffen. Die Frage sollte wohl eher lauten, welche Geräte sind nicht von Ripple20 betroffen?
Da der Hersteller Treck mit seinen Kunden ein Non-Disclosure-Agreement (NDA) unterzeichnet hat, ist dieser nicht in der Lage, eine Liste von Kunden zu veröffentlichen. Treck hat jedoch alle Kunden kontaktiert, über die Sicherheitslücken informiert und die aktualisierte Version der Software-Bibliothek bereitgestellt.
Die Forscher von JSOF haben selber versucht herauszufinden, welche Hersteller betroffen sind und welche davon bereits Gegenmaßnahmen ergriffen haben. Die folgende Liste hat den Stand vom 18. Juni 2020 und erhebt keinen Anspruch auf Vollständigkeit oder Korrektheit. Bitte kontaktieren Sie den Hersteller ihrer IP-fähigen Geräte, wenn Sie vermuten, dass sie von den Sicherheitslücken betroffen sein könnten.
Status: Bestätigt |
Status: Nicht betroffen laut Hersteller |
B.Braun | Abbott |
Baxter | AMD |
Caterpillar | GE Healthcare |
Cisco (über Starent) | Laird |
Green Hills | Philips |
HP | Texas Instruments |
HPE | Zebra Technologies |
Maxlinear (über HLFN) |
|
Rockwell | |
Scandia National Labs | |
Schneider Electric/ APC | |
Digi | |
HCL Tech | |
Status: Möglicherweise betroffen |
||
EMC (jetzt Dell) | Guidant medical | SAIC |
GE general electric (über Quadros) | Hitache europe | ScriptPro |
NASA | HLFN | Semtech |
Verifone | Honeywell | Sigma Designs |
Agilent | Itron | SimCom Wireless |
Airlinq (über Netsnapper Technologies SARL) | Kadak | Starent Networks |
Arburg | L-3 Chesapeake Sciences Corporation | Synamedia (über Cisco)/NDSUK |
Audiocodes | Lockheed Martin | Syncroness |
BAE systems | Marvell | Technicolor (über Cisco) |
BD | Maxim Integrated Products | Thinkcom/ThinKom |
BECK | Memjet | Tollgrade communications |
Broadcom | MTS Technologies | Ultra Electronics Flightline Systems |
Capsule (über Digi) | Netafim | Vicom |
DASAN Zhone (über vpacket) | Netsnapper Technologies SARL | Videotek |
Datamax Corporation | nVidia (über Portalplayer) | Vocera |
Enghouse (über tollgrade communications) | Portalplayer | vpacket (jetzt DHASAN Zhone) |
Extreme Networks | Qualstar.com | Weibel weibel.dk |
Foundry | Quadros | Western geco |
Fraunhofer IZFP | Red lion controls | Xilionx |
Gainspan (telit) | Redcom | Zodiac Aerospace |
Wie kann das Risiko minimiert werden, mittels Ripple20 angegriffen zu werden?
Als ersten Schritt sollte man einen kompletten Überblick über das eigene Netzwerk alle angeschlossenen Geräte erhalten. Mit einem kompletten Inventar kann im Folgenden eruiert werden, ob sich betroffene Geräte im Netzwerk befinden. Daraufhin sollte überprüft werden, ob für die Geräte ggf. Updates verfügbar sind.
Zu den generellen Best-Practice-Ansätzen gehört natürlich ebenfalls die Standard-Vorgehensweisen:
- Geräte nur wenn unbedingt nötig Zugang zum Internet gewähren.
- Segmentierung von Netzwerken und der Einsatz von Firewalls zwischen den Netzwerken.
- Nach Möglichkeit nur Fernwartungszugänge zu den Geräten über gesicherte und verschlüsselte VPN-Verbindungen erlauben.
Für die Inventarisierung und Analyse Ihres Netzwerkes und der darin befindlichen Geräte gibt es eine Lösung der Firma Greenbone, welche aktiv oder passiv nach Sicherheitslücken sucht und Ergebnisse in einfach verständlichen Berichten zusammenfasst. Zudem kann die Lösung automatisiert nach Geräten im Netzwerk suchen und eine ISO27001 konforme Inventarliste generieren.
Für das Monitoring bieten wir Lösungen von Nozomi Networks an, welche mit KI-gestützten Systemen erlernt, wie Geräte innerhalb eines Netzwerkes miteinander sprechen, um nach der Lernphase Anomalien gezielt entdecken und melden zu können.
Sollten Sie Interesse an einer Beratung oder einer Teststellung der vorgestellten Lösungen haben, so können Sie uns gerne über Telefon, E-Mail oder unser Kontaktformular erreichen.