Zum Inhalt springen
Bringen Sie Ihre Internet-Intelligenz zum Blühen | Sichern Sie sich 20 % Rabatt auf Censys Search Teams oder Solo-Jahrespläne mit dem Code Spring24 bis 31.5.2009 | Jetzt sparen
Blogs

Ivanti Connect (un)sicher - neu betrachtet

Zusammenfassung

  • Ab Montag, Feb 19, 2024, Censys beobachtet 24,590 exponierte Ivanti Connect Secure-Gateways
  • Über 6.000 (fast 24.7% der insgesamt exponierten Gateways zeigen Anzeichen dafür, dass sie eine Version verwenden, die für eine oder mehrere der fünf kürzlich bekannt gewordenen Sicherheitslücken anfällig ist (CVE-2023-46805, CVE-2024-21887, CVE-2024-21888, CVE-2024-21893 und CVE-2024-22024)
  • Die Zahl der potenziell gefährdeten Hosts ist um rund 7.880 Instanzen gesunken (56.5%) seit dem 31. Januar zurückgegangen, dem Tag, an dem die CISA aktualisierte Abhilfemaßnahmen für FCEB-Behörden veröffentlichte. Beachten Sie, dass diese Daten das Ausmaß der Anfälligkeit wahrscheinlich unterschätzen, da nicht alle Ivanti Connect Secure (ICS) Gateways ihre Versionen bekannt geben.
  • Während dieser Untersuchung haben wir eine außergewöhnliche Anzahl von betrügerischen Hosts aufgedeckt, die vorgeben, Ivanti Connect Secure zu sein. Diese gefälschten Hosts waren über mehrere Amazon AWS-Regionen verteilt, darunter insbesondere APAC und China.
  • Censys Search Query for exposed Ivanti Connect Secure: services.software.product: {“Connect Secure”, “connect_secure”}

Rekapitulation 

In den letzten zwei Monaten hat Ivanti fünf verschiedene Schwachstellen aufgedeckt, die ihre verschiedenen Produkte betreffen, vor allem Ivanti Connect Secure und Policy Secure.

Nach unserer Berichterstattung über die massenhafte Ausnutzung von CVE-2023-46805 und CVE-2024-21887 im Januar, sind die drei neuesten Schwachstellen in Ivanti Connect Secure und Ivanti Policy Secure:

  1. CVE-2024-21888 (Eskalation von Privilegien) - 8.8 CVSS
  2. CVE-2024-21893 (Server Side Request Forgery) - 8.2 CVSS
  3. CVE-2024-22024 (XML External Entity Injection) - 8.3 CVSS

Diese haben einen niedrigeren CVSS-Schweregrad und scheinen keine so große Bedrohung darzustellen wie das erste Paar von Sicherheitslücken, aber sie sind dennoch besorgniserregend.

CISA änderte schließlich seine Anleitung für Ivanti von "Mitigations anwenden" zu "alle Instanzen abschalten", und alle Bundesbehörden der zivilen Exekutive (Federal Civilian Executive Branch, FCEB) mussten ihre Appliances am 9. Februar abschalten.

Daher ist es an der Zeit, erneut zu prüfen, ob die Zahl der gefährdeten Geräte im Internet abnimmt.

Irgendetwas ist faul

Als wir in den letzten Wochen die Trends bei der Nutzung von Ivanti Connect Secure untersuchten, fiel uns etwas Ungewöhnliches auf.

Die obige Grafik zeigt, dass die Anzahl der exponierten Hosts und Services mit Ivanti Connect Secure bis zum 31. Januar, als die CISA eine Aktualisierung ihrer ursprünglichen Notfallrichtlinie herausgab, konstant bei 26.000 Hosts und 27.300 Services lag.

Als wir diese Zahlen jedoch eine Woche später erneut überprüften, stiegen sie auf ~41.800 Hosts und ~46.000 Services an, was im Grunde eine Verdoppelung der Host- und Serviceanzahl bedeutet.

Hier ist etwas Ungewöhnliches im Gange. Diese unerwartete Spitze erweckt Verdacht, da sie vom typischen Verhalten legitimer Hosts abweicht. Das Internet ist zwar oft langsam, wenn es darum geht, Patches zu erstellen, aber normalerweise werden nach der Bekanntgabe einer großen Zero-Day-Schwachstelle nicht noch mehr betroffene Hosts in Betrieb genommen.

Bei näherer Betrachtung wurde die Ursache für diese Anomalie deutlich: Honeypots.

In den Bereichen Sicherheit und Netzwerke ist ein Honeypot in der Regel ein System oder ein Dienst, der strategisch so konzipiert ist, dass er reale Ziele nachahmt. Auf diese Weise sollen Bedrohungsakteure angelockt werden, mit dem Dienst zu interagieren, damit ihre Aktivitäten überwacht werden können.

Auf Censys haben wir eine bestimmte Klasse von Honeypot-ähnlichen betrügerischen Entitäten festgestellt, die darauf ausgelegt zu sein scheinen, Internet-Scanner abzufangen, wie bereits in unserem Blog über Red Herrings und Honeypots beschrieben. Diese Dienste versuchen, viele verschiedene und legitime Softwareprodukte über einen Dienst zu emulieren und so die Überprüfung zu erschweren, indem sie Datensätze mit falsch positiven Ergebnissen überschwemmen.

Die Anzahl der neuen Ivanti Connect Secure-Hosts war unser erster Hinweis darauf, dass etwas nicht in Ordnung war. Fast über Nacht verdoppelte sich die Gesamtzahl der Connect Secure-Hosts, was für eine einzelne Software ein ungewöhnliches Muster darstellt.

Der Unterschied zwischen Host- und Service-Anzahl war unser zweiter Hinweis darauf, dass es sich wahrscheinlich um Honeypots handelt. Während die Anzahl der Hosts und der Dienste zu Beginn des Zeitraums nahe beieinander lag, stieg die Anzahl der Dienste in den nächsten Tagen überproportional zur Anzahl der Hosts an, was darauf hindeutet, dass die Hosts mehrere Dienste erstellen, die alle als mit Ivanti Connect Secure ausgeführt gemeldet werden. Bei einer durchschnittlichen Bereitstellung von Connect Secure werden nur ein oder zwei Dienste als mit dieser Software ausgeführt angezeigt.

Ein weiterer aufschlussreicher Hinweis waren die Domänennamen, die im Abschnitt Common Name (CN) der TLS-Zertifikate der einzelnen Dienste zu finden waren. Jeder einzelne Domänenname wirkte fehl am Platz und war in einigen Fällen zu schön, um wahr zu sein. Das heißt, wenn die Domänen echt wären, würde es sich um hochwertige Ziele handeln, wie z. B. Produktionsserver auf staatlichen Top-Level-Domänen.

Durch die Kombination der beiden letztgenannten Schlüsselindikatoren waren wir in der Lage, eine einfache Logik zu entwickeln, mit der diese Hosts als betrügerisch eingestuft werden können. Die genaue Art dieser Methode wird später in diesem Beitrag erläutert.

CensysDie Perspektive der aktuellen Ivanti Connect Secure Server

Wenn man die betrügerischen Dienste ausschließt, entspricht der Trend eher dem, was wir erwarten würden, und zeigt einen allmählichen Rückgang der Hosts und Dienste, da die Unternehmen beginnen, Instanzen zu deaktivieren. Am Montag, den 19. Februar 2024, beobachtete Censys 24.590 exponierte Gateways.

Karte der gefährdeten Ivanti Connect Secure Gateways am 19. Februar 2024 (nicht alle sind unbedingt gefährdet)

Wie viele davon sind potenziell gefährdet?

Das folgende Diagramm konzentriert sich auf Instanzen, die Anzeichen für die Ausführung einer Version aufweisen, die potenziell für eine der fünf kürzlich bekannt gewordenen Sicherheitslücken in Ivanti Connect Secure (CVE-2023-46805, CVE-2024-21887, CVE-2024-21888, CVE-2024-21893 und CVE-2024-22024) anfällig ist.

Am Montag, den 19. Februar, beobachtete Censys 6.000 potenziell anfällige Ivanti Connect Secure Gateways. Es ist ermutigend, dass diese Zahl im Vergleich zu den 13.970 potenziell gefährdeten Instanzen, die am 31. Januar beobachtet wurden, um 56,5 % gesunken ist.

Die Trends in der obigen Abbildung stimmen auch mit dem Zeitpunkt der CISA-Ankündigungen überein - man beachte den starken Rückgang nach der ersten Aktualisierung der ursprünglichen Executive Directive (ED), die am 31. Januar veröffentlicht wurde. Bis zum 9. Februar, dem Tag, an dem die CISA ihre zweite Aktualisierung veröffentlichte und eine Anleitung zum "Trennen aller Verbindungen" herausgab, gab es ein relatives Plateau und einen kleinen Anstieg, woraufhin die Zahl der gefährdeten Dienste wieder zu sinken begann.

Mit Stand vom 19. Februar ist die Konzentration dieser gefährdeten Gateways in den Vereinigten Staaten und Japan besonders hoch:

Viele laufen in einer Mischung aus großen japanischen Telekommunikations- und ISP-Netzen. Der Großteil der US-Präsenz dieser Hosts konzentriert sich auf Akamai sowie Expedient, einen Anbieter von Cloud-Diensten. NTT Communications, KDDI und Arteria Networks sind allesamt große japanische Telekommunikations- und Netzwerkunternehmen.

Die häufigste verwundbare Version von Ivanti Connect Secure, die zum Zeitpunkt der Erstellung dieses Berichts von Censys beobachtet wurde, ist 22.3.17. Besorgniserregend ist, dass die End-of-Life-Version (EOL) 8.3.7 an zweiter Stelle steht. Dies deutet darauf hin, dass es sich bei diesen Fällen möglicherweise um ältere Hosts handelt, die vernachlässigt oder aufgegeben wurden.

Nachforschungen über betrügerische Hosts

Nachdem wir nun wissen, welche realen Hosts exponiert sind und auf denen potenziell anfällige Ivanti Connect Secure-Instanzen laufen, wollen wir uns die Honeypots genauer ansehen.

Zunächst wurden diese Hosts in Censys als Ivanti Connect Secure-Hosts gekennzeichnet, da ihre HTTP-Antwortkörper alle verräterischen Zeichen eines legitimen Ivanti Connect Secure-Dienstes enthielten. Mit anderen Worten, erst bei genauerer Betrachtung stellen wir fest, dass dies alles eine Täuschung war.

Oben sehen wir, dass die Anzahl der gefälschten Ivanti Connect Secure-Dienste am 2. Februar auf über 17.000 Hosts angestiegen ist. Dies ist einer der Schlüsselindikatoren, der uns Aufschluss über das Ausmaß dieses Betrugs gibt - eine seltene Beobachtung, wenn man bedenkt, dass dieser Anstieg etwa zur gleichen Zeit wie die Ankündigung der Sicherheitslücke erfolgte.

Den Lärm durchdringen

Wir haben drei Hauptindikatoren verwendet, um festzustellen, was rechtmäßig ist und was nicht.

  1. Die Anzahl der einzelnen Hosts, auf denen Ivanti Connect Secure läuft, hat sich über Nacht verdoppelt. 
  2. Zwischen der Anzahl der Hosts und der Anzahl der Ivanti Connect Secure-Services klafft eine immer größere Lücke (Anzahl der Hosts gegenüber der Anzahl der Services).
  3. Verdächtige Common-Name-Elemente in den TLS-Zertifikaten der einzelnen Dienste.

Da wir bereits den Anstieg der Zahl der Installationen und die wachsende Kluft zwischen der Zahl der Hosts und der Dienste erörtert haben, wollen wir uns nun die verdächtigen gemeinsamen Namen genauer ansehen, die wir in den TLS-Zertifikaten gefunden haben.

dev.appliance.bright-manufacturing.mil
devo-hydro.state-medicine.ua
interne.thermische.erste-Finanzierung.mil
pilot-vsphere.west-power.ua
privat.sslvpn.city-oil.co.il
secret-kace.first-airforce.gov
staging.support.east-power.ca
pilot-sonicwall.south.oil.ca
Auf der linken Seite sehen Sie einige Beispiele für die in den TLS-Zertifikaten dieser Hosts vorkommenden Namen.

Für uns sah es so aus, als ob diese Namen auf der Grundlage einer vordefinierten Liste von Schlüsselwörtern erstellt wurden. Genauer gesagt, auf Schlüsselwörtern, die strategisch so gewählt wurden, dass sie auffällig sind und nur dem Zweck dienen, die Aufmerksamkeit eines Angreifers auf sich zu ziehen.

So fanden wir beispielsweise mehrere staatliche und föderale Top-Level-Domains wie ".gov" und ".mil" sowie vorangestellte Token wie "private", "dev" oder "prod" (die ein privates Entwicklungs- oder Produktionssystem bezeichnen). All dies könnte als ein hochwertiges Ziel angesehen werden.

Bei einer umfassenderen Analyse von Zehntausenden dieser "einzigartigen" allgemeinen Namen zeigte sich ein Muster in der Anordnung dieser scheinbar zufälligen Domänennamen. Zunächst haben wir jeden Namen in Teilstrings zerlegt und ihre relative Position notiert, z. B. mit pilot-vsphere.west-power.ua:

 

Wert Teilstring Position
Pilot 1
vsphere 2
West 3
Macht 4
ua TLD 

Wir haben festgestellt, dass jede Teilzeichenkette einen vordefinierten Satz möglicher Werte für ihre jeweilige Position in der Zeichenkette hat. Sie werden feststellen, dass in der obigen Beispielliste von Zertifikatsnamen der Begriff "Pilot" ausschließlich an der äußersten linken Teilstringposition (Position 1) erscheint. Dies gilt für "Pilot" für alle gängigen Namen, die wir gefunden haben.

Nachstehend finden Sie zwei Diagramme, die die von uns entdeckten Muster und ihre jeweiligen Token-Positionen ("P1" bis "P4" und die "TLD") zeigen. Das bedeutet, dass für jede Position ein anderer Satz von Wörtern verwendet wurde, um einen voll qualifizierten Domänennamen zu erzeugen. Unabhängig davon, ob die Token durch einen Punkt oder einen Bindestrich verbunden waren, blieb die Anzahl der Positionen gleich.

Nachfolgend finden Sie eine Tabelle, in der wir diese Sätze aufgeschlüsselt haben, um die zehn am häufigsten verwendeten Token für jede entsprechende Position sowie die Anzahl der Beobachtungen für jedes Token an dieser Position zu ermitteln.

Position 1 - #Occurences Position 2 - #Occurences  Position 3 - #Occurences Position 4 - #Occurences TLD - #Occurences
preprod 

37,804

Helpdesk 

13,923

hell

46,555

Öl

40,150

ua

66699

Test 

37,773

Förderband

13,896

West

46,389

Macht

40,137

mil

66617

privat

37,621

docs

13,785

nächste

46,048

aero

40,089

co.il

66610

corp

37,587

Austausch

13,727

Stadt

46,047

Bank

39,992

ca

66505

beta

37,566

Zusammenfluss

13,701

Staat

46,003

Herstellung

39,941

us

66470

intern

37,548

Konten

13,696

heute

45,948

Stahl

39,924

gc.ca

66,432

Entwicklung

37,349

Unterstützung

13,692

Roman

45,946

navy

39,898

com

66,220

Forschung 

37,342

mfa

13,650

Süden

45,934

elektrisch

39,839

org

65,941

devo

37,319

jira

13,622

Osten

45,905

Sicherheit

39,786

.

65,522

Pilot

37,216

Verpackung

13,620

Haupt

45,885

Energie

39,747

K.A.
DURCHSCHNITT: 37,512.5 DURCHSCHNITT: 13,731.2 DURCHSCHNITT: 46066.0 DURCHSCHNITT: 39,950.3 DURCHSCHNITT: 66335.1

Wie wir sehen können, sind die an den jeweiligen Positionen verwendeten eindeutigen Wörter ziemlich gleichmäßig verteilt, was auf einen anständigen Zufallszahlengenerator hindeutet, was wiederum darauf hindeutet, dass hinter der Erstellung und Bereitstellung dieser Hosts ein hoher Grad an Automatisierung steckt. Im Folgenden finden Sie ein einfaches Python-Skript, das die Grundfunktionalität dieser (offensichtlich) computergenerierten Domänennamen nachahmt.

zufällig importieren
Zeit importieren

p1_toks = ["preprod", "test", "private" "etc..."]
p2_toks = ["helpdesk", "converyor", "docs", "etc..."]
p3_toks = ["bright", "west", "next", "etc..."]
p4_toks = ["oil", "power", "aero", "etc..."]
tld_toks = ["ua", "mil", "co.il", "etc..."]

random.seed(time.time())

p1_tok = p1_toks[int(random.random()) % len(p1_toks)]
p2_tok = p2_toks[int(random.random()) % len(p2_toks)]
p3_tok = p3_toks[int(random.random()) % len(p3_toks)]
p4_tok = p4_toks[int(random.random()) % len(p4_toks)]
tld_tok = tld_toks[int(random.random()) % len(tld_toks)]

print(f"{p1_tok}.{p2_tok}.{p3_tok}-{p4_tok}.{tld_tok}")

Aus einem werden viele

Censys entdeckte am 2. Februar erstmals einen einzelnen Honeypot-Host, auf dem Ivanti Connect Secure lief. Innerhalb eines Tages stieg die Zahl auf 260 Hosts und erreichte am 7. Februar mit rund 17.900 Hosts ihren Höhepunkt. Die Fähigkeit, eine so große Anzahl von Hosts in so kurzer Zeit einzurichten, setzt den Einsatz beträchtlicher Ressourcen voraus, was darauf hindeutet, dass es sich um einen gut finanzierten Akteur und nicht um einen Amateur handelt.

Censys haben am 15. Februar damit begonnen, diese Wirte aktiv anders zu kennzeichnen, woraufhin ihre Zahl leicht zurückging, sie aber immer noch vorhanden sind.

Patient Null

Am 2. Februar 2024 sahen wir zum ersten Mal einen Host mit dem gefälschten Ivanti Connect Secure mit den im vorherigen Abschnitt beschriebenen Merkmalen (den zufällig generierten Domänennamen) laufen.

 

IP 52.40.12.180
Hafen 2096
Autonomes System AMAZON-02 (AS16509)
Land Vereinigte Staaten
Version Null (kein Körperhash)
HTML-Titel Ivanti Connect Sicher
Zertifikat Common Name  staging.siemens.today-oil.ca

Es gibt einige interessante Dinge über diesen Dienst zu berichten:

  • Es wird auf einem scheinbar zufälligen Port gehostet, der vom normalen Verhalten abweicht - die überwältigende Mehrheit der echten Ivanti Connect Secure Gateways ist auf Port 443 konzentriert, wie diese Grafik zeigt:

  • Der Host befindet sich in AMAZON-02, einem der bekanntesten AWS-Netzwerke. Dort waren auch die Honeypots konzentriert, als wir das letzte Mal über sie geschrieben haben.
  • Der Common Name des Zertifikats erregt einigen Verdacht. Auf den ersten Blick sieht es wie ein rechtmäßiges Zertifikat aus, aber bei näherer Betrachtung ist der Common Name eine ungewöhnliche Kombination von Wörtern für die Root- und Subdomains.

Isoliert man die Hosts, die diesem Zertifikatsbenennungsmuster folgen, sieht man, wie sich die Verteilung der Honeypot-Hosts über die Netzwerke im Laufe der Zeit verändert hat:

Da die meisten dieser Dienste bei AWS gehostet werden, ist die Identifizierung eines bestimmten Eigentümers eine Herausforderung. Dennoch befand sich ein kleinerer Teil der Hosts in den autonomen Systemen "Ningxia West Cloud" und "BJ-GUANGHUAN", die als Transitprovider von AWS in China dienen. Dies allein deutet auf die Beteiligung einer Organisation mit Verbindungen nach China hin, da der Kontoinhaber über eine offiziell registrierte Geschäftslizenz aus China verfügen muss, um Hosts in diesen spezifischen, an AWS angrenzenden autonomen Systemen einzurichten.

Es gibt noch ein paar andere ziemlich auffällige Anzeichen dafür, dass es sich um eine Fälschung handelt:

1. Spiegelbildliche Host Count Trends in ~10 Ländern:

Die nachstehende Abbildung zeigt die Trends bei der IP-Geolokalisierung dieser Hosts:

Beachten Sie, dass es anscheinend ~10 Länder gibt, die alle bemerkenswert ähnliche Trends bei der Anzahl der Hosts aufweisen. Dieses Muster deutet darauf hin, dass diese Hosts in jedem Land systematisch eingesetzt und überwacht wurden, wahrscheinlich mit Hilfe eines Skripts.

2. Einheitlicher HTML-Titel, keine Versionen

Alle haben genau denselben HTML-Titel: "Ivanti Connect Secure", und aus keinem von ihnen konnte eine Version extrahiert werden. Diese gemeinsamen Merkmale bestärken unseren Verdacht auf ein "skriptgeneriertes" Verhalten.

3. Rascher Anstieg der Anzahl von Anschlüssen pro Host

Im Laufe der Zeit vervierfachte sich die durchschnittliche Anzahl der Ports auf jedem Host mit Ivanti Connect Secure von 1 auf 4, wie in der Abbildung unten dargestellt. Es ist unwahrscheinlich, dass ein durchschnittlicher legitimer Host das VPN-Gateway auf 4 separaten Ports gleichzeitig laufen lässt, oder dass sie RECHTS erhöhen, wenn größere Sicherheitslücken entdeckt werden.

4. Häufige Zertifikatsrotation

Wir wollten herausfinden, ob diese Hosts ihre Zertifikate regelmäßig aktualisierten oder ihre Namen änderten. Die Beweggründe für häufige Zertifikatswechsel variieren zwar, aber im Zusammenhang mit betrügerischen Hosts ist eine plausible Hypothese, dass sie dies tun, um einen dynamischen Aspekt hinzuzufügen, der es schwieriger macht, zwischen echten und gefälschten Systemen zu unterscheiden, und sich so möglicherweise länger der Entdeckung entziehen.

Das nachstehende Diagramm zeigt die Verteilung der Anzahl der eindeutigen Zertifikate, die an einem einzelnen Port über den gesamten analysierten Zeitraum (vom 31. Januar bis zum 19. Februar) beobachtet wurden.

Unterscheidbarer gebräuchlicher Name 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Anzahl der Dienste 16323 22465 23965 22935 19744 15552 10575 6547 3959 2007 797 347 152 42 25 8 6

Über einen Zeitraum von 20 Tagen verzeichnete Censys im Durchschnitt 4 verschiedene Zertifikate an einem einzigen Port, wobei drei bestimmte Dienste sogar 17 verschiedene Zertifikate anzeigten. Diese Wechselrate ist nicht typisch und deutet darauf hin, dass hier etwas Ungewöhnliches vor sich geht. Auch hier handelt es sich in Ermangelung eindeutigerer Beweise lediglich um eine Vermutung, die sich jedoch mit unseren anderen Beobachtungen deckt.

Dieses spezifische Muster von Honeypot-Hosts ist nicht ausschließlich auf Ivanti Connect Secure beschränkt. Uns sind ähnliche Hosts aufgefallen, auf denen Software im Zusammenhang mit anderen kürzlich bekannt gewordenen Sicherheitslücken zu laufen scheint. Zum jetzigen Zeitpunkt ist es schwierig, die Verantwortlichen zu identifizieren, aber die Anzeichen häufen sich, dass sie dies absichtlich tun. Wir werden die Situation im Auge behalten und weitere Entwicklungen beobachten. 🔎

Was kann getan werden? Abhilfemaßnahmen für Ivanti Connect Secure-Schwachstellen

Über den Autor

Das Forschungsteam Censys
Lösungen für das Management von Angriffsflächen
Mehr erfahren