Hintergrund
Offizielle von Celer Network erklärten am 18. August, dass zwischen 3:45 und 6:00 Uhr Pekinger Zeit bestimmte cBridge-Benutzer auf bösartige Smart Contracts umgeleitet wurden. Zunächst wurde vermutet, dass die Front-End-Schnittstelle von cBridge durch einen DNS-Angriff kompromittiert wurde.
Im völligen Gegensatz zu früheren Cross-Chain-Bridge-Hacking-Vorfällen wie Nomad, Wormhole, Ronin, Harmony usw. wurde dieser Angriff nicht durch Fehler in Smart Contracts und Cross-Chain-Protokollen oder das Eindringen zugehöriger Server verursacht, und die in cBridge gesperrten Cross-Chain-Assets wurden ebenfalls sicher aufbewahrt. Bei diesem Angriff zielten die Hacker direkt auf die zugrunde liegende Infrastruktur in der Internetarchitektur außerhalb des Celer-Systems ab und ermöglichten Cross-Chain-Benutzern innerhalb eines bestimmten Zeitraums Zugriff auf eine „Phishing“-Front-End-Benutzeroberfläche, indem sie das zugrunde liegende Routing-Protokoll (BGP) des Internets täuschten. Das Celer-Netzwerk konnte dank seiner schnellen Reaktion den Schaden begrenzen. Das liegt daran, dass das Celer-Netzwerkteam über ein 24-Stunden-Überwachungssystem verfügt. Das Kundenserviceteam konnte das Problem rechtzeitig identifizieren und die Community warnen. Das Celer-Netzwerkteam beauftragte das SlowMist-Sicherheitsteam, auf diesen Notfall zu reagieren und eine gründliche Untersuchung durchzuführen.
Analyseprozess
Das Celer Network-Team vermutete zunächst einen DNS-Angriff und nach Rücksprache mit ihnen konnten wir mehr über den fraglichen Domänennamen erfahren: cbridge-prod2.celer.network. Wir stellten fest, dass der Browser während des Angriffs keinen Zertifikatsfehler gemeldet hatte. Daher befassten wir uns bei unserer Untersuchung zunächst mit der Möglichkeit eines DNS-Angriffs. (Besonderer Dank geht an @greysign1 für die Hilfe bei der schnellen Überprüfung der Möglichkeit eines DNS-Angriffs.)
Wir begannen mit der Überprüfung der relevanten Zertifikatsinformationen:
Das Zertifikat scheint unerwartet geändert worden zu sein, wobei das ursprüngliche Zertifikat von Let’s Encrypt durch ein gefälschtes Zertifikat von GoGetSSL ersetzt wurde.
GoGetSSL kann ein kostenloses 90-Tage-Zertifikat ausstellen:
Analyse von Zertifikat 1: https://crt.sh/?id=7356185959
Zu folgenden Zeitpunkten wird auf dem Zertifikat ein CRL-Prüfungsfehler angezeigt:
Analyse von Zertifikat 2: https://crt.sh/?id=7356185959
Dieses Zertifikat weist außerdem zu folgenden Zeitpunkten einen CRL-Prüfungsfehler auf:
Nachdem wir die IP-Adresse, das Zertifikat und weitere mit Zertifikat 1 verknüpfte Informationen untersucht hatten, stellten wir fest, dass die an dieses Zertifikat gebundene IP-Adresse 44.235.216.69 lautete.
Die IP-Adresse von Zertifikat 2 konnte die dem Zertifikat 2 entsprechende IP-Adresse nicht abfragen, was an der kurzen Dauer des Angriffs und dem Versäumnis der Internetsuchmaschine liegen könnte, relevante Informationen zu erfassen.
Aus diesem Grund haben wir unsere Analyse auf die IP-Auflösungsdaten für die Domäne cbridge-prod2.celer.network konzentriert:
Die IP-Adresse 44.235.216.69 war über einen längeren Zeitraum mit cbridge-prod2.celer.network verknüpft.
Hier ist die Frage: Die Tatsache, dass diese IP-Adresse, 44.235.216.69, über einen längeren Zeitraum mit cbridge-prod2.celer.network verknüpft war, beweist, dass sie zum offiziellen Celer Network-Server gehörte. Dies wurde auch vom Celer Network-Team bestätigt. Warum war dieser IP also ein gefälschtes Zertifikat zugeordnet?
Also begannen wir, das AS von 44.235.216.69 zu untersuchen und stellten fest, dass das dieser IP entsprechende AS ungewöhnlich war.
AS16509 gibt Bogons bekannt::
Beim Durchsehen der Bogons können wir feststellen, dass dies im Allgemeinen der Fall ist, wenn ein Angreifer eine IP-Adresse fälscht, um einen Angriff durchzuführen: https://networkdirection.net/articles/routingandswitching/bgp-bogonsandmartians/ https://forum.networklessons.com/t/what-are-bogons/6333
Da das AS bei 44.235.216.69 Anomalien aufwies, vermuteten wir zunächst, dass das Problem bei BGP lag. Daher kontaktierten wir das Celer-Netzwerk, um die IP-Adresse des Angreifers zu erhalten: 54.84.236.100. Wir stellten fest, dass AS14618, wo sich die IP-Adresse befindet, ebenfalls eine Ausnahme hatte. (AS14618 meldet auch Bogons)
Zufälligerweise war der Upstream von AS14618 AS16509 (AS16509 ist auch das AS, bei dem sich 44.235.216.69 befindet). Dies machte uns auf die Möglichkeit eines BGP-Angriffs aufmerksam.
Unsere Untersuchung ergab, dass die IP-Adresse 54.84.236.100 als bösartig gekennzeichnet wurde.
Wir haben in unserer Community relevante Informationen zur IP-Adresse 54.84.236.100 gesammelt und einen Hinweis darauf gefunden, dass diese IP-Adresse mit einem anderen BGP-Angriffsvorfall aus dem Jahr 2014 in Verbindung steht. Da dieser Vorfall jedoch schon lange her ist, ist er möglicherweise nicht mehr relevant.
Anschließend setzten wir unsere Untersuchung fort, indem wir die Aufzeichnungen verfolgten, die dieser BGP-Angriff hinterlassen hatte:
Die Verfolgung des BGP-Eintrags für die Angriffs-IP: 54.84.236.100 ergab, dass die Route nicht mehr verfügbar ist.
Wir haben die BGP-Router-Traces für die IP von Celer weiter verfolgt: 44.235.216.69 und konnten die richtige Route finden.
Anschließend haben wir das Änderungsprotokoll des BGP-Knotens überprüft: Pekinger Zeit: 18.08.2022 02:48 Uhr – 18.08.2022 07:48 Uhr UTC+8
Am 18.08.2022 wurde im Zeitraum zwischen 02:48 Uhr und 07:48 Uhr BST eine große Anzahl von Knotenhinzufügungen und Löschungen von Änderungsdatensätzen festgestellt.
Wir überwachten weiterhin das AS-Änderungsprotokoll und stellten fest, dass AS14618 früher die Routing-Informationen 44.235.216.0/24 hatte, der Pfad dann aber in „Withdrawn“ geändert wurde, was Folgendes beweist:
44.235.216.0/24 in AS14618 war früher der optimale Pfad
Jetzt ist 44.235.216.0/24 in AS14618 nicht mehr der optimale Pfad; er wird zurückgezogen.
(Bei einem BGP-Angriff veröffentlicht der Angreifer einen optimalen Pfad, um den Verkehr auf seinen eigenen Server umzuleiten.)
Um genauere Daten zu erhalten, haben wir das folgende bgplay verwendet, um die Änderungen der Pfade im Zusammenhang mit 44.235.216.69 zum Zeitpunkt des Angriffs zu überprüfen.
Am 17.08.2022 können wir sehen, dass es im Zeitraum zwischen 19:19:23 +UTC und 23:19:23 +UTC zu erheblichen Schwankungen bei den Informationen zu den BGP-Routingpfaden kam.
Diese Änderung spiegelt sich in der Umleitung des Datenverkehrs von 44.235.216.0/24 zu AS14618 wider, wobei der Datenverkehr von 44.235.216.0/24 nach dem Angriff über AS16509 weitergeleitet wird.
Aus diesem Grund gehen wir davon aus, dass es sich bei diesem Vorfall wahrscheinlich um einen BGP-Angriff handelte, bei dem es sich bei AS14618 offenbar um einen Knoten unter der Kontrolle des Angreifers handelt (der Router von AS14618 weist möglicherweise Sicherheitsprobleme auf und kann von Angreifern ausgenutzt werden). Der Angriff dauerte etwa 4 Stunden.
Der Angreifer konnte Zertifikat 1 (gefälschtes Zertifikat) an die IP-Adresse 44.235.216.69 von Celer Network binden, da er einen bösartigen Server mit derselben IP-Adresse hatte. Da gogetssl http zur Authentifizierung unterstützt, kann er einfach von gogetssl bereitgestellten Text in den bösartigen Server eingeben. Dadurch ist es möglich, Zertifikat 1 zu binden, indem der Datenverkehr über einen BGP-Angriff an den bösartigen Server mit derselben IP-Adresse geleitet wird. Der Browser wurde daraufhin über den Zertifikatsfehler informiert.
Wir haben aus folgenden Gründen festgestellt, dass AS14618 vom Angreifer kontrolliert wurde.
Der Angreifer leitete den Datenverkehr von 44.235.216.69 zunächst an AS14618 um und routete 44.235.216.69 nach dem Angriff zurück an AS16509.
Angriffs-IP: 54.84.236.100 befindet sich auch innerhalb von AS14618.
Nach dem Angriff wurde AS14618 auf 44.235.216.69 zurückgezogen.
Um diese Frage zu beantworten: Die Tatsache, dass diese IP-Adresse, 44.235.216.69, über einen längeren Zeitraum mit cbridge-prod2.celer.network verknüpft war, beweist, dass sie zum offiziellen Celer Network-Server gehörte. Dies wurde auch vom Celer Network-Team bestätigt. Warum war also ein gefälschtes Zertifikat mit dieser IP verknüpft?
Wenn Sie zur Kommunikation das HTTPS-Protokoll verwenden, können Sie die Daten (einschließlich der Daten der Client/Server-Kommunikation) nicht verschlüsseln/entschlüsseln, ohne den privaten Schlüssel des Zertifikats zu erhalten. Um sicherzustellen, dass das Zertifikat korrekt ist und den Man-in-the-Middle-Angriff durchführen zu können, muss der Angreifer das in der Behörde angewendete Zertifikat erneut an den bösartigen Server mit derselben IP 44.235.216.69 binden. Dadurch kann der Angreifer die Daten des Clients entschlüsseln und den bösartigen Code in die Daten des Antwortpakets einfügen.
Analyse Fazit
Wir haben diesen Angriff in Zusammenarbeit mit dem Celer Network-Team untersucht. Obwohl es sich um einen ausgeklügelten BGP-Angriffsversuch auf das Celer Network handelte, hat der Angreifer alles vorbereitet, vom Zeitpunkt des Angriffs über die Zertifikatsfälschung bis hin zur AS-Kontrolle und anderen Vorgängen.
Letztendlich erkennen wir an, dass viele Projekte sich der mit BGP-Angriffen verbundenen Risiken bereits bewusst sind und entsprechende Vorkehrungen getroffen haben. Viele sind sich jedoch noch immer nicht bewusst, insbesondere wenn es um durch AS-Änderungen verursachte Netzwerkpfadänderungen geht. Ohne angemessene Vorbereitungs- und Reaktionsmaßnahmen besteht ein erhebliches Risiko weiterer Angriffe durch dieselben oder andere Angreifer. Daher fordern wir Organisationen, ISPs und Server-Hosting-Anbieter dringend auf, solche Risiken zu erkennen und Abwehrstrategien zu koordinieren, um zu verhindern, dass sich ähnliche Vorfälle wiederholen. Und wie immer gilt: Wenn Sie jemals Hilfe benötigen, wenden Sie sich bitte an das SlowMist Security Team.
Anhang
cbridge-prod2.celer.network DNS-Diagramm:
