Erinnert sich noch wer an meinen Beitrag Kleine Warnung: Finger weg von Ivanti VPN; die benutzen wohl Uralt-Tools mit vom 6. Februar 2024? Ich hatte mich mokiert, dass der Hersteller uralte Bibliotheken und Komponenten in seinen Produkten mitliefert. Ich bin aber wohl inzwischen nicht mehr der Einzige.
Anzeige
Das Problem ist wohl auch Sicherheitsforschern von Eclypsiusm aufgefallen, die sich die Ivanti Pulse Secure Firmware Version 9.1.18.2-24467.1 angesehen haben. Die läuft auf CentOS 6.4, welches im November 2020 aus dem Support gefallen ist. Die Artikel von The Hacker News und Eclypsiusm sind in obigem Beitrag verlinkt – bis auf das CentOS-Thema steckt aber nichts neues im Vergleich zu meinem Beitrag im Artikel drin.
Anzeige
Interessant ist auch, dass jetzt alles aus Ihren Höhlen gekrochen kommen und Bestätigen, dass die Software mit uralten Bibliotheken arbeitet, scheint ja vorher keinen Interessiert zu haben.
Was ist eigentlich mit den ganzen "Audit" Firmen, die da evtl. Zertifikate ausgestellt haben (so etwas wie ISO27001, NIST oder ähnliches), die sollte man auch direkt auf die Blacklist setzen und jedweder Akkredetierung entziehen, wobei, naja ein ISO27001 Zertifikat sagt auch nichts darüber aus, ob deren IT Systeme sicher sind – nur ob alles schön sauber dokumentiert wurde.)
Naja, interessiert hat es die Leute schon, nur hat niemand nachgeschaut, weil man einfach davon ausgegangen ist, das die Komponenten wohl aktuell sind.
Und das erwarte ich auch: Das bei Erscheinen einer neuen Version auch die zu diesem Zeitpunkt aktuellen Komponenten drin stecken und nicht Uraltversionen.
Aber wie sich zeigt, sehen das die Entwickler anders und nutzen noch uralten Krempel nach dem Motto "haben wir immer schon benutzt….".
Sollten nun nicht nicht Forti usw. proaktiv aufzeigen, wie neu ihre Komponenten sind? Oder sind nun alle hektisch am Patchen, damit man bei der nächsten Version keine Uraltkomponenten in aktueller Sicherheitsprodukten mehr verstecken muss?
Ich würde mich ja freuen, wenn Ivanti da eine unrühmliche Ausnahme war, aber imho kochen alle eine ähnliche Suppe.
Man kann als nur hoffen, dass die selben Sicherheitsforscher nun andere renommierte Firmen anschreiben und deren Antworten auch veröffentlichen. Nur so hat man als Kunde die Möglichkeit zu vergleichen. Und das dann mit Popcorn mit dem Gartner Magic Quadrant vergleichen und in der IT dem Chef vorlegen, ob er das wirklich immer noch als Grundlage heranziehen möchte ;)
Natürlich kochen alle eine ähnliche Suppe. Weil das, was nach den Wünschen vieler hier vom Hersteller zu leisten wäre, nicht mehr bezahlbar wäre. *Verdachtsfälle* — nach den hier angelegten Maßstäben — wären für mich sämtliche Hersteller von:
DSL-Boxen, Kabel-Boxen, Smartphones, Smart-TVs, Sat-/Kabel-/DVB-T-Receivern, Automobilen, Betriebssystemen, WLAN-Geräten, größeren Applikationen mit sehr vielen Abhängigkeiten zu inkludierten externen Bibliotheken, …
Diese Liste ist maximal unvollständig.
Quelle Eclypsium:
https //eclypsium.com/blog/flatlined-analyzing-pulse-secure-firmware-and-bypassing-integrity-checking/
CentOS hat noch bis Juli 2024 Extended Lifecycle Support, kann es natürlich nicht bestätigen, aber natürlich hätte Ivanti kommerziell auch weiterhin ein voll unterstütztes OS von Redhat, und dann gäb's auch noch Drittanbieter, die noch länger Support bieten, aber mit denen hatte ich nie zu tun.
November 2020 war nur das Ende vom gewöhnlichen Maintenance Support.
CentOS 7 hat noch Support bis June 30, 2024.
Aber hier ist von CentOS 6 die Rede
Datum Juli'24 bitte schon mal merken -> Ivanti Neurons for MDM aka MobileIron basiert auf CentOS 7 und meine bisherigen Nachfragen beim Hersteller Support klangen nicht vielversprechend…
Bitte du redest aber schon wieder vom normalen maintenance support, ich spreche vom ELS (extended lifecycle support) den man kostenpflichtig dazu buchen kann, den gibt's für centos 6 und den gibt's auch nach dem maintenance support von centos 7 – habe ich doch extra den Hinweis in der letzten Zeile darauf hingewiesen, dass es Unterschiede gibt.
Den von dir genannten ELS gibt es nur für RHEL, nicht für CentOS.
> den man kostenpflichtig dazu buchen kann,
Und selbst wenn werden sich die Updates z.B. für "Perl v5.6.1 built for i386-linux (not x64, April 2001)" nicht von allein einspielen.
Dir ist klar, dass ich hier mindestens wie Adenauer residiere, ich stelle fest, ich bin einzig
Das wird aber beliebig teuer. Denn es kommt schon vor, das eine neue Version ein neueis oder altes Loch aufreißt. Auch baut man schon Mal einen Rucksack ein, weil irgendwiewas nicht so wie dokumentiert funktioniert. Die aktuelle Version könnte diesen Würgarraund missverstehen.
Das muss bei einer neuen Library alles getestet werden. Da reicht kein "apt update" oder wie der Befehl gerade heißt.
Das kannste bei Dir zu Hause machen.
Aber nicht wenn man man eine Black Box für viel Geld an Laien verkauft.
Das muß einmal durch das Testbed gejagt werden m Und das kann dauern.
Never change a running system.
Natürlich muß es der aktuelle Patchlevel sein resp.
unmittelbar nach dem Start auf diesen geupdatet werden.
Wäre das mit den neuen Libs soooo einfach dann würde sich ja niemand die Müde machen irgendwelche Patches zu Back Porten.
https://www.inforisktoday.com/hackers-compromised-ivanti-devices-used-by-cisa-a-24566