Kleine Warnung: Finger weg von Ivanti VPN; die benutzen wohl Uralt-Tools mit

Sicherheit (Pexels, allgemeine Nutzung)[English]Ich greife mal das Thema Ivanti VPN erneut auf, damit Administratoren in ihrem Umfeld geeignet reagieren können. Nach einigen Sicherheitsmeldungen gibt es in den USA ja die Aufforderung der Cybersicherheitsbehörde CISA an alle Behörden, Ivanti VPN bis vergangenen Samstag, den 2. Februar 2024, zu deaktivieren, es sei denn, es sind bestimmte Voraussetzungen gegeben. Gerade ist mir ein Fundstück in einem Tweet zugegangen, der sich nur als "Finger weg von Ivanti VPN" interpretieren lässt – die Entscheidung trifft aber jeder Administrator selbst.


Anzeige

Vorab ein Bekenntnis, "ich hab von nix einen Ahnung, davon aber ganz viel" – was auch auf Details der Ivanti-Produktlinie zutrifft. Und es gilt "Ist der Ruf erst ruiniert, bloggt es sich gänzlich ungeniert", d.h. ich beobachte, ziehe meine Schlüsse und stelle es im Blog ein – damit Betroffene sich selbst schlau machen und die notwendigen Schlüssel eigenverantwortlich treffen können. Seit dem AnyDesk-Hack werden meine Postfächer und Sozial Media Accounts aber mit Informationsbrocken geflutet, wo ich gelegentlich ganz schön zu beißen habe, um den Kontext und die Relevanz zu erfassen. Heute war wieder so ein Event, wo ich einige Sekunden nachdenken musste, bis sich mir die Haare im Nacken aufgestellt haben – aber der Fall passt in die aktuelle Software-Landschaft.

Kurzer Rückblick zum Thema Ivanti

Bis vor kurzem hätte ich Ivanti für eine Schokoladenmarke oder irgendwas mit Pizza gehalten. Ok, hätte auch ein beliebig anderes Produkt sein können – aber es ist ein Firmenname mit einigen Software-Produkten. Dann gab es im Juli 2023 den Fall des Hacks in Norwegen, den ich im Blog-Beitrag Norwegens Regierung über Ivanti-Zero-Day gehackt auf-, und weiteren Beiträgen nachbereitet habe. In Norwegen wurde die IKT-Plattform (Informations- und Kommunikationssystem) angegriffen, auf der 12 Ministerien arbeiten. Die Angreifer konnten über eine 0-Day-Schwachstelle eindringen und dann wohl Daten abziehen. Die norwegische Sicherheitsorganisation, Norwegian Security and Service Organization (DSS), hat über den Vorfall informiert. Die Angreifer haben eine 0-Day-Schwachstelle im Ivanti Endpoint Manager Mobile (EPMM, MobileIron Core) ausgenutzt, um in die Systeme einzudringen.

Seit dieser Zeit gibt es hier im Blog regelmäßig Beiträge zu Schwachstellen in Ivanti-Produkten (ok, gibt es auch in anderer Software), die dringend gepatcht werden müssen. Letzte Meldung hier im Blog war, dass dass die Ivanti VPN-Lösung arge Sicherheitsprobleme aufweist (siehe Ivanti Connect Secure: Neue Schwachstellen CVE-2024-21888 und CVE-2024-21893 gepatcht) und meiner Kenntnis nach auch im Fokus von Angreifern steht. Über die Schwachstellen könnten die auf die Systeme der Nutzer zugreifen und in deren Netzwerke eindringen.

CISA weist US-Behörden zum Stillegen an

Im Artikel  Cyberangriffe: Landratsamt Kelheim; Caritas-Klinik Dominikus in Berlin; Datenfunde im Darknet habe ich erwähnt, dass die US-Cybersicherheitsbehörde CISA US-Behörden angewiesen hat, Ivanti Connect Secure (ICS) bis zum 2. Februar 2024 außer Betrieb zu nehmen. Die Kollegen von Bleeping Computer haben hier was dazu veröffentlicht. Die betreffende CISA-Direktive lässt sich hier nachlesen.

Ivanti VPN – Blick in den Abgrund

Die Nacht wurde ich von einem Leser über folgenden Tweet informiert. Sicherheitsforscher Will Dormann hat sich Ivanti VPN mal genauer angeschaut und dabei erstaunliche Entdeckungen gemacht.

Eine aktuelle Installation der Ivanti VPN-Software (als Ivanti VPN box bezeichnet) kommt mit einer curl-Implementierung, die vor 14 Jahren aktualisiert wurde. Zu curl 7.19.7 liefert mir diese Seite, dass die am 4. November 2009 ausgerollte Version 61 Sicherheitsprobleme aufweist. Darunter ein Auth/cookie leak bei Redirects.

Ein OpenSSL  1.0.2n-fips ist bereits sechs Jahre als, die 1.0.2 bekommt seit dem 1. Januar 2020 keine Updates mehr. Perl hat als Implementierung perl 5.6.1 23 Jahre mit diesen Schwachstellen auf dem Buckel. Und psql 9.6.14 ist auf einem Stand vor fünf Jahren (hier die Liste des Grauens mit dem Hinweis "You are currently viewing PostgreSQL security vulnerabilities for an unsupported version. If you are still using PostgreSQL 9.6, you should upgrade as soon as possible."). Noch Fragen? Mit solchen "Beigaben" braucht es keine Sicherheitslücken mehr, die geschlossen werden. Das Produkt scheint eine einzige Sicherheitslücke zu sein.


Anzeige

Zum Thema curl hatte ich ja hier im Blog schon mal was in Verbindung mit Microsoft und Windows geschrieben. Auch dort hat der Software-Gigant aus Redmond Probleme, aktualisierte curl-Versionen auszuliefern, und es gibt immer wieder Phasen, wo curl mit bekannten Schwachstellen in Windows enthalten ist. Aber Ivanti VPN scheint den Vogel abzuschießen, wenn der obige Tweet bei allen Versionen so zutrifft. Wer also Ivanti VPN bei sich einsetzt, sollte nachschauen, ob das oben skizzierte Szenario bei einer gepatchten Installation zugrifft und gegebenenfalls sofort aktiv werden. Vielleicht melden sich ja Ivanti-Administratoren, ob die Beobachtung stimmt oder alles "nur heiße Luft" ist.

Ergänzung: Das Thema ist wohl auch The Hacker News aufgefallen, die das Ganze zum 15. Februar 2024 im Beitrag Ivanti Pulse Secure Found Using 11-Year-Old Linux Version and Outdated Libraries aufbereitet haben. Die beziehen sich auf diesen Artikel der Sicherheitsforscher von Eclypsiusm vom gleichen Datum.

Ähnliche Artikel:
Warnung vor Schwachstellen; Fortinet, Ivanti und mehr (Januar 2024)
Tausende Geräte per Ivanti VPN-Schwachstellen angegriffen – mind. 19 in Deutschland
Massive Angriffswelle auf Ivanti VPN-Appliances; Warnung, Konfigurations-Pushes kann Härtungsmaßnahmen gefährden
Ivanti Connect Secure: Neue Schwachstellen CVE-2024-21888 und CVE-2024-21893 gepatcht
Windows: cURL 8.4.0 Update kommt zum 14. November 2023-Patchday
Windows: Microsoft liefert cURL-Bibliothek weiterhin mit Schwachstellen aus (Feb. 2023)
Windows und die cURL-Falle; gelöschte Curl-Instanz macht Windows-Update kaputt


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

25 Antworten zu Kleine Warnung: Finger weg von Ivanti VPN; die benutzen wohl Uralt-Tools mit

  1. Daniel sagt:

    Das betrifft leider viele Software-Pakete im geschäftlichen Einsatz.
    Die Abhängigkeiten werden oftmals sehr stiefmütterlich behandelt. DLLs, die aus der Windows XP-Zeit stammen, findet man auch heute noch immer wieder.

    • R.S. sagt:

      Stimmt.
      Hier bei einem Softwarepaket gibts ein mitgeliefertes Datenbanksystem, das ist Stand 2011, die neueste Version des Versionszweiges ist von 2019.
      Und da gibt es eine ganze Reihe von Sicherheitslücken, die geschlossen wurden.
      Inzwischen gibt es 3 neuere Versionszweige, letztes Update Januar 2024.
      Ich könnte einfach auf die letzte Version des Versionszweiges updaten (da sind alle bekannten Sicherheitslücken geschlossen), aber da gabs auch funktionale Änderungen. Und da ist es fraglich, ob die Software da mit macht oder ob das zu Fehlern führt.
      Daher lasse ich davon die Finger.
      Aber den Softwareanbieter werde ich kontaktieren, mal sehen was der zu der total veralteten Datenbank sagt.

  2. M.D. sagt:

    Sehe ich jetzt nicht als so dramatisches Problem. Am ehesten kann man die openssl-Version bemängeln, es kommt aber drauf an, wie genau die eingesetzt wird, welche Verfahren. Perl, curl und Postgres können steinalt sein, jedenfalls solange Postgres nur auf dem loopback läuft und die beiden anderen tools nur für interne Verwaltungszwecke bzw. zum Download von Updates aus einem sehr eingeschränkten IP-Bereich benötigt und eingesetzt werden.

    Viele Millionen Android-Handys sind in Verwendung, die — wenn man diesen Maßstab anlegt — sofort außer Betrieb genommen werden müssten, weil die einen zu alten kernel einsetzen.

    Das Alter allein — und selbst bekannte Bugs — kann niemals das alleinige Ausschlusskriterium für eine Software sein, der Einsatzzweck und die Zugriffsberechtigungen spielen da wohl die größere Rolle.

    • Günter Born sagt:

      M.D., MW: Ähm, ich staune ein wenig über die Antworten. Gerne dürft ihr das in den Topf werfen, und es gibt sicherlich gute Argumente dafür.

      Aber nur mal ganz langsam zum Mitschreiben – vielleicht verstehe ich das ja alles falsch: Wenn ich ein altes Android Handy verwende und nicht gerade der Verteidigungs- oder Außenminister von Deutschland bin, sondern ein altes Mütterlein, welches die Enkel damit mal anruft, hält sich der Schaden in Grenzen.

      Ivanti VPN wird doch (korrigiert mich, wenn ich falsch liege) für den Zugang zu Netzwerken in Firmen verwendet? Legt ihr die Hand dafür ins Feuer, dass die Software-Beigaben in einer Verkettung von Schwachstellen nicht doch ausgenutzt werden können? Klar, wenn ich sicherstelle, dass das alles nur intern angesprochen werden kann. Perl ist doch eine (Script-)Programmiersprache, die wohl intern durch die Ivanti-Software genutzt wird.

      Wenn da aber irgendwelche alten Bibliotheken, die längst aus dem Support gefallen sind, mitgeliefert werden, sollte man schon Fragen stellen dürfen. Mir liegt da immer noch das "wie kann man nur so blöd sein" im Ohr, wenn ich über Cybervorfälle bei Firma XYZ berichte und mal ausnahmsweise ein paar Details, wieso der Hack möglich war, offen legen kann.

      Ich würde mir an dieser Stelle nicht die Aussage "Leute, die alten Versionen sind kein Problem, weil …" zutrauen. Und wenn ich sehe, dass Will Dormann (der immer recht vorsichtig agiert) da mit dem Finger drauf zeigt, kommt das sicher nicht von ungefähr.

      Im aktuellen Fall ist die Empfehlung "Finger weg" ja CISA-basiert. Aber obige Beobachtung komplettiert das Bild, warum Ivanti plötzlich ständig in der Berichterstattung mit Sicherheitslücken auftaucht.

      Unter dem Strich: Ich muss ja glücklicherweise nicht euren Job machen – und als fieser Möpp bin ich der Welt da draußen recht dankbar, dass sie so agiert wie sie agiert – gehen mir die Themen zum Bloggen nie aus – es sei denn, es kollabiert demnächst alles, weil die bösen Buben ihr Besteck mal richtig auspacken und sich die Segnungen der KI zunutze machen ;-).

      • R.S. sagt:

        Die Bedenken sind schon richtig.
        Lt. einer Statistik des BSI sind 11% aller Sicherheitsvorfälle 2022 auf veraltete Software zurückzuführen.

        Und ich erwarte einfach, das mit einem Versionsupdate einer Software auch alle mitgelieferten Komponenten von Fremdherstellern ebenfalls auf den aktuellen Stand aktualisiert werden.
        Bei z.B. Buchhaltungssoftware geht das doch auch.
        Z.B. beim Elster-Modul, das zwangsweise aktuell gehalten werden muß, da Meldungen mit veraltetem Elster-Modul vom Finanzamt schlicht abgewiesen werden.

        • Carsten C. sagt:

          Ich bin auch ein Befürworter, Software stets auf einem aktuellen Stand zu halten.
          Bei manchen Applikationen zieht ein Update bisweilen allerdings einen Rattenschwanz an zusätzlichen Updates an anderer Stelle nach sich – z.B. wenn sich der Softwarehersteller entschließt, nur noch bestimmte Versionen eines Serverbetriebssystems oder eines SQL-Servers zu unterstützen, was dann evtl. Kosten für neue Hardware, neue Software, neue Lizenzen und Stundenaufwände bedeutet.
          Im von Günter geschilderten Fall hätte ich wiederum kein gutes Gefühl, Ivanti VPN einzusetzen, weil da offenbar Sicherheitslücken bei zentralen Komponenten bestehen.

      • M.D. sagt:

        Auch wenn die alte Software auf einem Zugangssystem zu einem Netzwerk liegt, ist das Alter m.M.n. irrelevant. Die Nutzer/Geräte verbinden zum VPN-Daemon, bekommen eine IP zugewiesen werden entsprechend in das zu erreichende Netz geroutet. Mehr nicht. Direkten Zugriff auf das darunter liegende System haben sie nicht. Insofern kommen sie weder an perl noch an curl oder postgres heran.

        Wenn jemand an diese Tools heran kommt, ist das Kind eh bereits in den Brunnen gefallen, weil ein Fehler an anderer Stelle ausgenutzt wurde. Dann ist es aber egal, ob ein altes curl oder ein aktuelles curl zum Nachladen von schädlicher Software verwendet wird. Mit perl kann man tolle skripte ausführen, und zwar mit den Berechtigungen, die man bereits hat. Insofern egal, ob perl 5.6.x oder 5.38.x. Im Zweifel bietet aber die letztere Version wesentlich mehr Möglichkeiten, Unfug zu treiben.
        Postgres ist eine Datenbank und die läuft — zumindest unter Linux — in der Regel unter einem eigenen User mit beschränkten Rechten.

        Solange die oben beschriebenen Tools nicht bei der Validierung von (Remote)Input Verwendung finden, ist es völlig egal, wie alt sie sind. Sie sind nur lokal erreichbar und verwendbar. Sollte es trotzdem jemandem gelingen an anderer Stelle eine Hürde zu überwinden und diese Tools zu missbrauchen, will man besten keines der Tools im System haben, weder in veralteter noch in brandaktueller Version.

        Das Problem bei diesen "Lösungen" wie Ivanti ist meistens die Remote Erreichbarkeit und Konfigurierbarkeit über ein grafisches Interface. Wenn man über dieses Interface — wegen mangelhafter Prüfung der Eingaben — diese Tools ansteuern kann, dann liegt das allerdings wohl kaum an der Version der Tools.

        Ich sehe das Ganze bezogen auf diesen Aspekt eher entspannt, setze Ivanti aber auch nicht ein.

        • Gi7w0rm sagt:

          Ist das nicht genau die Argumentation die Unternehmen verwenden würden wenn sie Legacy-Systeme im Netzwerk nicht als Sicherheitsrisko verstehen?
          Nehmen wir als Beispiel den Angriff auf Microsoft der vor kurzem bekannt wurde:
          https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/

          Natürlich kann man hier jetzt sagen: Das Kind ist in den Brunnen gefallen weil das Passwort geknackt wurde.

          Man kann sich aber auch fragen warum ein Legacy System überhaupt noch vorhanden war, mit weitreichenden Rechten versehen war und somit überhaupt erst die schweren Folgen ermöglichte.

          Dadurch das Ivanti diese Altlast mit sich rum schleppt haben es Angreifer potenziell einfacher von Stufe A eines Angriffs zu Stufe B zu kommen.

          Der normale Nutzer mag das für Belanglos halten.
          Bei einem Produkt was sich "Secure VPN" nennt, von seiner Natur aus her direkten Zugriff in mein Netzwerk ermöglicht, dafür gedacht ist die falschen Leute draußen zu halten und noch dazu eine Stange Geld kostet erwarte ich allerdings einen weitaus höheren Sicherheitsstandard als alles davon abhängig zu machen das ein Angreifer da ja wohl schon nicht dran kommen wird.

        • FriedeFreudeEierkuchen sagt:

          Wir haben erst vor kurzem in der Analyse von Kaspersky gesehen, dass sich durch die Verkettung von einzelnen, nicht allzu gravierenden, Sicherheitslücken ein maximal verheerender Exploit auf Apple Geräten zusammen bauen ließ. Verkettete Angriffe kommen oft vor.
          Ich vertrete daher immer den Ansatz, im gesamten System möglichst keine Lücken entstehen zu lassen.

          Dein Urteil basiert auf einigen Annahmen:
          "Die Nutzer/Geräte verbinden zum VPN-Daemon, bekommen eine IP zugewiesen werden entsprechend in das zu erreichende Netz geroutet."
          Du weißt nicht, wo es noch Ansatzpunkte am VPN-Server vorbei gibt (z.B. offene Ports). Du weißt nicht was beim Connect im Hintergrund für Prozesse angest0ßen werden und welche Parameter diese verarbeiten. Du kannst so nicht sagen, ob es eine Möglichkeit gibt, durch Manipulation der Verbindungsaushandlung Fehlerzustände auszulösen und auszunutzen.

          "Postgres ist eine Datenbank und die läuft — zumindest unter Linux — in der Regel unter einem eigenen User mit beschränkten Rechten."
          In der Regel… Selbst große Firmen wie Microsoft weichen immer wieder von den Regeln ab und holen sich massive Lücken ins Haus. Auch hier: Ich würde ohne tiefere Untersuchung meine Hand nicht ins Feuer legen, dass man durch schlaue Verkettung nicht irgendwelchen Unfug machen kann.
          Da der Ersteller der Software-Versionsliste sicher ohne Einblick in den Quellcode auskommen muss, können sich auch andere einen Überblick verschaffen und ein bisschen "herumspielen".

          Darüber hinaus, wie auch in anderen Post hier schon geschrieben: Eine Software, die so alte Komponenten enthält, ist generell in sehr schlecht gewartetem Zustand. Das will ich gerade bei einem VPN nicht haben. Eine veraltete OpenSSL Version auf einem VPN? Ein No-Go. Das alles ist auch für mich ein klares "Finger-weg" Statement.

        • M.D. sagt:

          @Gi7w0rm + FriedeFreudeEierkuchen
          Mir geht das mit "(ver)alte(te) Software ist generell schlecht" zu einfach und zu pauschal, jedenfalls kommt diese Ansicht im Artikel und vielen Kommentaren so rüber. Es mögen viele auch strikt so sehen, ich sehe es ein wenig anders. Die Anwendungsfälle können durchaus verschieden sein und ein unbedingtes Update erforderlich machen oder eben auch nicht.

        • Andreas sagt:

          > Direkten Zugriff auf das darunter liegende System haben sie nicht. Insofern kommen sie weder an perl noch an curl oder postgres heran.

          Aber ggf. indirekten. Es werden Sockets und Files erzeugt, Logs geschrieben. IP-Header verarbeitet…

          Dass man sich nicht etwas seltsam vorkommt so zu argumentieren bei einem Artikel zu einer Software, wo gerade deutlich wird, dass es eben doch ein Problem ist.

          Zum einen ist es etwas einfach zu glauben, dass der Netzwerkstack fehlerfrei ist und dann weiter auch noch davon auszugehen, dass man sich als Angreifer nicht über weiteren Lücken freut, um dann aus einem unkritischen Einzelfehler doch weiterzukommen. Offenbar bist Du in der gesamten Thematik nicht drin: https://www.heise.de/news/Pwn2Own-Touch-Bar-eines-MacBook-Pro-via-Safari-gehackt-3998145.html (um mal ein direktes Beispiel zu bringen…). Oh warte: https://www.synacktiv.com/publications/old-bug-shallow-bug-exploiting-ubuntu-at-pwn2own-vancouver-2023 … eine Netzwerkkomponente hat einen Fehler? Unglaublich Bob! Und man kann sich danach über ein altes curl freuen? Volltreffer…

          Zum anderen ist es auch nicht wirklich schlauer zu glauben, dass die Rechtetrennung, das Routing, die Verschlüsselung etc. pp. besser umgesetzt sind als das Dependency Management. Aber klar, DA haben die sich dann Mühe gegeben!!11elf!!… meine Güte, Ignoranz ist Stärke?

      • Christian Krause sagt:

        mit fehlt hier noch:
        wenn ein Anbieter über 20 Jahre alte Software mit liefert, für die normalerweise ein Prozess existieren sollte, diese automatisch zu aktualisieren: welche organisatorischen Verfehlungen hat der Anbieter dann an anderer stelle?

        • Thorsten M. sagt:

          Genau so sehe ich das auch! Wenn ein Teil der Software stinkt, dann gibt es ein Problem in der Denkweise oder bei den Prozessen des Herstellers. Dann muss man grundsätzlich davon ausgehen, dass es weitere unentdeckte Schwachstellen gibt (0-days).

          Und nun zu der Argumentation mancher Leute hier "Die veralteten Komponenten kommen nicht in Kontakt mit der Außenwelt, somit stellen sie keine Schwachstelle dar": Diese Denkweise empfehle ich abzugewöhnen. Derjenige, der solche Überlegungen anstellt, hat weder die Zeit noch die Fähigkeiten und das Wissen, das professionelle Hacker haben. Es genügt schon eine Schwachstelle, um ins System zu kommen. Meist ein 0-day. Anschließend hangeln sich Angreifer weiter und weiter. Und bei jedem Schritt nutzen sie eine andere Schwachstelle aus.

          Bei einem erfolgreichen Angriff kommt fast immer eine Kette von Schwachstellen zum Einsatz.

          Das Ziel und die Denkweise eines IT-Verantwortlichen muss grundsätzlich sein: Es darf keine Schwachstelle geben in einem System, das über das Internet erreichbar ist. Sobald eine Schwachstelle bekannt wird, muss umgehend ein Patch angewendet werden! Egal wie banal die Schwachstelle erscheint.

    • Anonymous sagt:

      Wenn das alles kein Problem ist warum wurde dann in den USA die Ansage gemacht sofort alles raus reissen?
      Gruß

    • Andreas sagt:

      Das ist auf vielen Ebenen falsch. Du tust gerade so, als könne das Netzwerk alles schützen und blendest mindestens alle

      1. indirekte Kommunikation
      2. Lücken zur Rechte-Erweiterung

      aus. Einfach einem beliebigen pwn-Wettbewerb folgen und sehen, dass ein Einbruch fast immer eine Verkettung von Lücken ist, die möglich ist wegen solch beschränkter Sichtweisen wie der Deinen. Nur einzeln betrachtet kann man VIELLEICHT so argumentieren.

      Beispiel für 1.: Was ist wenn ich durch meinen Netzwerkzugang oder aufbauen einer simplen Verbindung Logfiles erzeuge und damit steuern kann durch die Parameter, was ein Logger schreibt? Kann ich damit etwa indirekt auf eine angreifbare Komponente schreiben (z.B. indem ich Mist in meine Absenderaddresse schreibe, die dann geloggt wird und die Payload enthält oder meine Rechte ausweitet)? Gibt es nicht? Oh, log4j verschlafen? Was ist, wenn ich ggf. schaffe indirekt eine File erzeugen zu lassen, die dann von einem deiner doch so toll geschützten Prozesse gelesen wird? Und diese dann Dinge tun mit deren Rechten?

      Pardon: Was für ein Stuss. Deine Haltung ist ein Problem. Wer seine Abhängigkeiten nicht im Griff hat gehört vom Markt anstatt das „abzusichern". Härten, abtrennen und Segmentierung sind gut aber dennoch Mitigations für unbekannte Lücken, keine Lösung für *bekannte*. Bekannte Lücken hat man durch Update zu beheben.

  3. Anonymous sagt:

    es gibt auch noch massig (aktuelle!) Drucker mit integriertem LAN auf dem Markt deren Webinterface nicht mal TLS 1.2 oder entsprechende Ciphers unterstützt und deren SSL Implementation schon 20 Jahre alt ist (obwohl aktueller Drucker). Damit sind dort 20 Jahre alte Sicherheitslücken drin die man schön angreifen kann.

  4. mw sagt:

    alt == buggy? Das sti,mmt m. E. so nicht. Wenn nur Wartung in Form von Bugfixes gemacht werden würde, dann stimme ich dem zu. Aber es werden immer auch irgendwelche Features, nützlich oder auch nicht, hibzugebaut, d. h. der Kode wächst und bringt neue Bugs mit, ggf. auch 0-days. Insofern ist das Alter einer Version kein zuverlässiger Indikator dafür, wie sicher das Release ist. Da ist jetzt von Ivanti völlig unabhängig. Aber was will man von einem Unternehmen im Besitz einer Heuschrecke, die sich einen Gemischtwarenladen zusammengekauft hat, schon erwarten?

    • Christian Krause sagt:

      Aber die Bugs alter versionen sind – im Gegensatz zu neuen bugs aktueller Versionen – Öffentlichkeit bekannt.
      Insofern entspricht die regelmäßige aktualisierung dem rote königinnen Prinzip in der Biologie.

    • R.S. sagt:

      Ja, alte Software muß nicht zwingend Bugs oder Sicherheitslücken haben.
      Aber eins ist ziemlich sicher:
      Der Hersteller macht für Uraltsoftware keinen Support mehr.

  5. Mathias sagt:

    Moin,
    ich denn auch das Produkt Mobile Iron Core und Sentry (EMM) betroffen? Damit lässt sich ja auch ein VPN-Tunnel herstellen.

    Gruß

    • Ralph D. Kärner sagt:

      Stellt sich die Frage überhaupt noch? Ich für meinen Teil würde ungefragt alles entsorgen, was aus der Pommesbude kommt. Aber mir fehlt auch jedes Verständnis für diese ständige "ja, aber vielleicht ist das oder jenes noch brauchbar"-Mentalität.

    • Art sagt:

      Nein.

      Ivanti Connect Secure ist das ehemalige Pulse Secure Geraffel.

      Ivanti hat sich mit Ihrer Kriegskasse einen bunten Bauchladen an Produkten, Services, Firmen zusammengekauft…wobei Pulse das Mosanto für Ivanti zu werden scheint.

  6. GenauerLeser sagt:

    Ähm, wenn ich die CISA Anweisung richtig lese, steht da nicht drin, dass alles rausgerissen werden muss, sondern nur dass alles was nicht nach der Anweisung des Herstellers platt gemacht und neu hochgezogen ist außer Betrieb bleiben muss, bis dem so ist.

    • Günter Born sagt:

      @GenauerLeser: Sicherlich hast Du den Satz "Nach einigen Sicherheitsmeldungen gibt es in den USA ja die Aufforderung der Cybersicherheitsbehörde CISA an alle Behörden, Ivanti VPN bis vergangenen Samstag, den 2. Februar 2024, zu deaktivieren, es sei denn, es sind bestimmte Voraussetzungen gegeben. " genau gelesen und verstanden?

      Aber ich frage provokativ: Wenn Du einen Fisch angeboten bekommst, wo der Kopf stinkt und alt gammelt, würdest Du eine Fischsuppe davon kochen, nur weil auf dem Schild am Marktstand nicht steht "Mindesthaltbarkeit noch nicht abgelaufen"? Ich schröb ja oben: "die Entscheidung trifft aber jeder Administrator selbst."

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.