Ripple20 - Kritische Sicherheitslücken treffen IoT-Geräte

*Kleines Update V*

Es hat sich wieder ein bisschen was getan. Die neue Liste mit betroffenen Herstellern ist herausgegeben worden:
Ripple_3006.png

Die Berichterstattung ist immer noch mau. Immerhin Kaspersky schon mal einen Artikel Online gestellt.

Es sind auch neue Stellungnahmen der Hersteller dazu gekommen:
Aruba Networks, B.Braun,Baxter, CareStream, Caterpillar, Cisco , Digi International, Green Hills, HP, Intel, Rockwell Automation, Schneider Electric, Teradici, Xerox


 
*Kleines Update VI*
Über´s Wochenende ist so einiges passiert. Die Liste ist gerade bei "Pending" ordentlich gewachsen. 20 Firmen mehr sind nun dort gelistet. :wow:

Ein paar neue Infos gibt es auch zur Reichweite der Sicherheitslücken. Die Firma Track hat in den 90ern in Zusammenarbeit mit einem japanischen Unternehmen namens Elmec Systems diesen Stack entwickelt.
Nach Beendigung der Zusammenarbeit haben aber beide Unternehmen den Stack unter jeweils anderen Namen an andere Hersteller lizensiert. Diese Hersteller haben dann wiederum Unterlizenzen verteilt. :ugly:

Ripple_06.png
 
*Kleines Update VII*
Ich hab den Startpost überarbeitet und besser strukturiert, damit das ganze etwas verständlicher ist.
Ansonsten gibt es bis jetzt nichts neues. Eine Kleinigkeit wäre evtl. erwähnenswert. Der Hersteller von Cybersicherheits-Software, Rhebo, bietet einen Schutzsoftware namens "IoT Device Protection" an, welche auch gegen Ripple20 schützen soll.

Persönliche Meinung zur Rhebo-Software:

Löblich, allerdings frag ich mich wie sicher die Software selbst ist bzw. wie ihre Sicherheitsmechanismen aufgebaut sind.

Zitat: Die Sicherheits-Software wird direkt auf dem vernetzten IoT-Gerät integriert, um lokal zu wirken und die restliche Flotte der vernetzten IoT-Geräte zu schützen. Das ist umso wichtiger in IoT-Netzwerken, in denen die vernetzten Geräte auf identischer Technologie laufen.
Diese Diskussion gibt es ja bei AV-Software auch immer wieder.

Entsteht bei solcher Software nicht ein zusätzlicher Angriffsvektor? Gerade wenn die Software auf allen IoT-Geräten innerhalb eines Netzwerks läuft, ist das Risiko gegeben bei nur einer Lücke in der Software das ganze Netzwerk mit einem Schlag zu kompromitieren. Spannend find ich solche Software auf jeden Fall. Mal sehen was ich beim Hersteller direkt über die Software erfahren kann. :)
 
Wichtiger wären eher Updates um die Lücke selbst zu schließen.

Dafür wäre es mal gut, detaillierte Modellisten zu haben.
 
Da stimme ich dir schon zu, allerdings muss man die ganze Supply-Chain überarbeiten damit so eine Geschichte nicht mehr passieren kann.

*Kleines Update VIII*

Der Blackhat-Vortrag von JSOF wurde veröffentlicht. Die Details sind sehr interessant! Hier ist der Link dazu:
https://i.blackhat.com/USA-20/Wedne...aunt-Tens-Of-Millions-Of-Critical-Devices.pdf
Ihr findet die PDF aber auch im Anhang.

Zudem wurde die Liste der betroffenen Hersteller aktualisiert. Die Listen findet ihr wie immer im Spoiler.

Ripple_08_2.png

Ripple_08_1.png
 

Anhänge

  • us-20-Oberman-Hacking-The-Supply-Chain-The-Ripple20-Vulnerabilities-Haunt-Tens-Of-Millions-Of-Cr.pdf
    1,3 MB · Aufrufe: 40
Was sind so die interessantesten Punkte in dem Vortrag?
Ich fang mal mit der Kernaussage an, die ich aus diesem Vortrag so rauslese:
We_are.png


Und das ist leider nicht übertrieben. Die Beispiele welche in dem Vortrag genannt wurden, bestätigen die Vermutungen das uns diese Lücken Jahrelang begleiten werden.
Viele Geräte die über diesen TCP/IP Stack verfügen, sind Zombies. Das bedeutet, sie sind zwar in diversen Netzwerken vorhanden, werden aber nicht gemonitort/gewartet. Der TCP/IP Stack ist bereits über 20 Jahre alt. Das alleine wäre ja nicht schlimm, aber dadurch das das jede TCP/IP Instanz anders ist bzw. sein kann, macht es das unglaublich schwierig zu ermitteln, ob und in welcher schwere die Geräte betroffen sind. Das ist vorallem dem Weiterverkauf der Lizenzen und später dann der Unterlizenzen geschuldet. Du musst also erstmal rausfinden, in welchen Lieferketten dieser Stack überhaupt vorhanden ist. Dazu kommt, das ein Gerät über mehrere Lücken verfügen kann. Interessant ist die Folie auf Seite 38. Ich interpretiere diese so, das die neue Version hier zwar Vuln #1 schließt, aber dafür Vuln #3 öffnet. :ugly:

Der Beispiel-Exploit mit der USV aus dem Vortrag ist sehr interessant, finde ich. Es gelingt ihnen durch die Lücke, via Remote-Code-Ausführung das Gerät lahm zu legen. Das ist wirklich erschreckend.

Und wie sieht es nun mit Lösungen aus?
Schwierig. Viele der Geräte sind technisch nicht in der Lage Updates einzuspielen. Die Hersteller haben das (aus Kostengründen?) bei vielen Geräten einfach nicht vorgesehen. Die offensichtliche Lösung für dieses Problem bestünde darin, mit dem Bau neuer Geräte unter Berücksichtigung der Cyber-Sicherheit zu beginnen.

Als Unternehmen hast du die Möglichkeit eine UTM-Infrastruktur aufzubauen. Die Firewall muss dabei zwingend IPS/IDS untersützen. Durch tägliche Signaturupdates können so bösartige Ripple20-Datenpakete vorab erkannt und blockiert werden. Man kann auch auf Profil- oder Anomalie-basierende Erkennung setzen. Allerdings darf das Netzwerk vorab nicht kompromitiert sein. Sonst wird ein Profil angelegt, die der Software sagt, das es normal ist, eine Schadsoftware/Eindringling im System zu haben. :ugly: Daher lohnt sich das Profil-System meiner Meinung nach nur, wenn ein Netzwerk neu aufgebaut wird. Allerdings entsteht dadurch auch wieder ein neues altes Problem. Sobald ein UTM-Programm im Einsatz ist, besteht auch hier die Gefahr das dieses Ziel eines Cyberangriffs wird. Bedeutet im Umkehrschluss: Du braucht eine zweite Verteidigungsline, falls die erste fällt. Und die sollte aus Best-of-breed-Software/Hardware bestehen. Die ganze UTM / Second Defense Geschichte ist dementsprechend kostenspielig, aber die Alternativen wären weitaus teurer.

Als Privatkunde hast du die Goldene Arschkarte. Du bist hier stark von den Herstellern und deinem eigenen Know-How abhängig. Aktualisiere die Firmware sämtlicher deiner Geräte, und verwende möglichst keine IoT-Geräte. Hab außerdem ein Auge, auf die aktuellen Meldungen der Hersteller zu Ripple20. Mehr kann man im Moment nicht tun.

Gruß
Pain
 
Wäre ja die Frage, welche betroffene Geräte man entsprechend durch neue ohne Lücke ersetzen müsste. Wäre zwar kostspielig, aber wohl die praktikabelste Lösung.
 
Wäre ja die Frage, welche betroffene Geräte man entsprechend durch neue ohne Lücke ersetzen müsste. Wäre zwar kostspielig, aber wohl die praktikabelste Lösung.
Stimmt, nur bis wirklich genau bekannt ist, welche Geräte betroffen sind, wird noch viel Zeit vergehen. Das Ganze ist wirklich sehr unübersichtlich. Aber wie schon gesagt, viele der IoT-Geräte

Aber damit es nicht langweilig wird, bis es News zu Ripple20 gibt:
 
Auch wenn es um Ripple20 etwas still geworden ist: Die Sicherheitsforscher schlafen nicht.

Dieses mal hat es die TCP/IP-Stack-Implementierungen von Nucleus Net (Siemens), FreeBSD und NetX alias Azure RTOS NetX (Microsoft) erwischt. Bis jetzt ist von mindestens 100 Millionen betroffenen Geräten die Rede.


Fazit: IoT ist und bleibt ein extrem gefährliches Pflaster.
 
FreeBSD? Da bin ich mal gespannt ob das auch Sony und Apple betrifft und ich mein, dass die Ironports von Cisco auch FreeBSD basierend sind bzw. ein Abkömmling davon.
 
Nun müsste man aber wissen, in welchen Geräten sowas läuft.
Ähnlich wie bei Ripple20 wird das Ganze wohl ähnlich undurchsichtig bleiben.

FreeBSD? Da bin ich mal gespannt ob das auch Sony und Apple betrifft und ich mein, dass die Ironports von Cisco auch FreeBSD basierend sind bzw. ein Abkömmling davon.
Das BSI hat inzwischen auch ein Whitepaper dazu veröffentlicht:

Von Sony, Apple und Cisco hab ich noch nichts gehört bzw. darüber gefunden. Mal sehen ob von denen Stellungnahmen oder Notfallpatches kommen. Ich vermute aber nicht, da die Patches dafür schon länger zur Verfügung stehen. Evtl. wurde es von den Herstellern für die Privatgeräte als "Firmware"-Update getarnt?!

Zitat:
Für angreifbar befunden wurden FreeBSD 12.1, der IPNet-Stack im (schon recht betagten, den EoL-Status erreichten!) VXWorks 6.6, NetX 6.0.1 und Nucleus NET 4.3. Mindestens im Fall von Nucleus Net sind, wie aus den am Ende dieser Meldung verlinkten Advisories hervorgeht, auch neuere Versionen verwundbar. FreeBSD wiederum ist bereits seit vergangenem Jahr abgesichert.
 
Zurück