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.
- Die Anzahl der einzelnen Hosts, auf denen Ivanti Connect Secure läuft, hat sich über Nacht verdoppelt.
- 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).
- 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
- Ab dem 14. Februar sind Patches für alle fünf kürzlich bekannt gewordenen Schwachstellen verfügbar (Ivanti Connect Secure (Versionen 9.1R15.3, 9.1R16.3, 22.1R6.1, 22.2R4.1, 22.3R1.1 und 22.4R1.1) und Ivanti Policy Secure (Versionen 9.1R16.3, 22.4R1.1 und 22.6R1.1)
- Der KB-Artikel von Ivanti enthält die aktuellsten Informationen zur Schadensbegrenzung: https://forums.ivanti.com/s/article/KB-CVE-2023-46805-Authentication-Bypass-CVE-2024-21887-Command-Injection-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure-Gateways?language=en_US
- Wenn Sie das Integrity Checker Tool (ICT) des Anbieters verwenden, um nach Anzeichen für eine Kompromittierung zu suchen, beachten Sie bitte die jüngsten Erkenntnisse von Eclypsium, die besagen, dass das ICT beim Scannen nach einer möglichen Kompromittierung mehrere dauerhafte Verzeichnisse übersehen kann. Dies bedeutet, dass das ICT möglicherweise keine umfassende Bewertung darüber liefert, ob Ihr Gerät kompromittiert wurde. https://eclypsium.com/blog/flatlined-analyzing-pulse-secure-firmware-and-bypassing-integrity-checking/
