XRPL-Konsensmechanismus weist kritische Mängel auf, Angreifer können Validierungsnetzwerk lahmlegen – bereits behoben

XRP-2,92%

XRPL修復安全漏洞

Sicherheitsforschungsunternehmen Common Prefix hat zuvor zwei schwerwiegende Sicherheitslücken im XRP Ledger (XRPL) dem Ripple-Team gemeldet. Beide Schwachstellen betreffen die Validierungs-Node-Verarbeitung des Konsensmechanismus bei Transaktionssätzen. Wenn eine Validierungsnode im einzigen Node-Liste (UNL) kompromittiert wird, kann ein Angreifer bösartige Nachrichten senden, die zu einer Kettenreaktion von Abstürzen der Validierungsnodes führen. Die entsprechenden Fixes wurden in rippled Version 3.0.0 integriert.

Kernrisiko der Schwachstellen: Eine kompromittierte Validierungsnode kann das gesamte Netzwerk beeinflussen

Ripple漏洞修復

Der Konsensmechanismus des XRPL erfordert, dass Validierungsnodes bei einer Transaktionsgruppe Einigkeit erzielen. Jede Node schlägt bekannte, noch nicht verarbeitete Transaktionen vor, und durch den Austausch von Nachrichten wird der endgültige Konsens über den Transaktionssatz hergestellt. Die Schwachstellen basieren auf einem Fehler in der rippled-Software, die die Logik bei der Verarbeitung von „Streittransaktionen“ (Transaktionen, die zwischen verschiedenen Validierungsnodes unterschiedlich sind) betrifft.

Der Angriff setzt voraus, dass eine der etwa 35 Validierungsnodes in der UNL kompromittiert wird. Obwohl UNL-Validierungsnodes meist hinter Proxy-Nodes versteckt sind und nur mit diesen kommunizieren, was den Angriff erschwert, weist Nikolaos Kamarinakis von Common Prefix darauf hin, dass dies nicht unmöglich ist. Bei erfolgreichem Angriff kann der Angreifer modifizierte rippled-Tools einsetzen, um kontinuierlich bösartige Nachrichten an andere Validierungsnodes zu senden, bis die kompromittierte Node aus der UNL entfernt wird.

Technische Mechanismen der Schwachstellen und Fixes

Schwachstelle 1 — Vergleich von Transaktionen (Comparing Transactions):
Eine kompromittierte Node behauptet, dass eine Transaktion auf einem Knoten im SHAMap existiert, der tatsächlich nicht vorhanden ist. Andere Nodes stürzen ab, wenn sie versuchen, eine Transaktion anhand einer ungültigen Node-ID zu finden.

Fix 1:
Ein zusätzlicher Validierungsschritt wurde eingeführt, um zu prüfen, ob die Transaktion tatsächlich auf dem im Vorschlag angegebenen Knoten existiert. Dadurch wird die Absturzroute bei ungültigen IDs blockiert.

Schwachstelle 2 — Weiterleitung von Transaktionen (Relaying Transactions):
Die kompromittierte Node sendet eine bösartige Transaktionssammlung mit beliebigen Hash-Werten. Andere Nodes erkennen diese als Streittransaktionen und versuchen, sie weiterzuleiten. Beim Ausführen der „Fake-Transaktionsprüfung“ kommt es aufgrund ungültiger Daten zu einem Absturz.

Fix 2:
Es wurde eine try-catch-Fehlerbehandlung eingeführt, um Ausnahmen durch bösartige Daten abzufangen und eine Weiterverbreitung von Abstürzen zu verhindern.

Das Ripple-Entwicklungsteam hat die beiden Schwachstellen in einer isolierten Testumgebung mit einem unabhängigen Verifikationsprogramm erfolgreich reproduziert. Nach Anwendung der Fixes stürzten die Nodes bei Erhalt bösartiger Nachrichten nicht mehr ab.

Bestätigung der Fixes und Roadmap zur Sicherheitsverstärkung des XRPL

Die Fixes wurden in rippled Version 3.0.0 integriert. Ripple hat in Testumgebungen bestätigt, dass die Nodes nach Anwendung der Fixes bei Angriffen auf die gleichen Vektoren stabil bleiben.

Ripple kündigt zudem eine zukünftige Roadmap zur Sicherheitsverstärkung des XRPL an, inklusive erweiterter Sicherheitsüberprüfungen, um frühzeitig unentdeckte Probleme im Code zu erkennen, den Einsatz von KI-gestützter Code-Überprüfung zur systematischen Identifikation potenzieller Sicherheitslücken, Sicherheits-Hackathons und einer Erhöhung der Bug-Bounty-Programme, um externe Sicherheitsforscher zu motivieren, Schwachstellen zu melden.

In dem Bericht bedankt sich Ripple offiziell bei Common Prefix für die verantwortungsvolle Offenlegung der Schwachstellen und die technische Zusammenarbeit während der Fix-Phase.

Häufig gestellte Fragen

Wie hoch ist die tatsächliche Angriffswahrscheinlichkeit bei diesen Schwachstellen im XRPL?

Der Angriff erfordert den Zugriff auf eine der etwa 35 Validierungsnodes in der UNL. Diese Nodes sind meist hinter Proxy-Nodes versteckt und kommunizieren nur mit diesen, was die Angriffsfläche begrenzt. Sicherheitsforscher weisen jedoch darauf hin, dass ein Angriff nicht unmöglich ist. Daher ist es notwendig, die Schwachstellen vor Veröffentlichung zu beheben.

Welche Maßnahmen sollten Node-Betreiber ergreifen?

Alle Betreiber, die rippled Version 2.6.2 oder älter verwenden, sollten so schnell wie möglich auf rippled 3.0.0 upgraden, um vollständigen Schutz gegen die beiden Schwachstellen zu gewährleisten. Vorherige Versionen sind anfällig für Kettenreaktionen von Node-Abstürzen bei Angriffen auf die UNL.

Was bedeutet dieses Sicherheitsereignis langfristig für die Sicherheit des XRPL?

Der Vorfall zeigt den standardmäßigen verantwortungsvollen Offenlegungsprozess: Common Prefix informierte im Juni 2025 vertraulich, Ripple behebt die Schwachstellen in rippled 3.0.0, und die Öffentlichkeit wurde im März 2026 informiert. Ripple kündigt eine Sicherheits-Roadmap an, die KI-gestützte Code-Überprüfung und eine Erhöhung der Bug-Bounty-Programme umfasst, was auf eine kontinuierliche Investition in die Sicherheitsentwicklung hinweist.

Original anzeigen
Disclaimer: The information on this page may come from third parties and does not represent the views or opinions of Gate. The content displayed on this page is for reference only and does not constitute any financial, investment, or legal advice. Gate does not guarantee the accuracy or completeness of the information and shall not be liable for any losses arising from the use of this information. Virtual asset investments carry high risks and are subject to significant price volatility. You may lose all of your invested principal. Please fully understand the relevant risks and make prudent decisions based on your own financial situation and risk tolerance. For details, please refer to Disclaimer.
Kommentieren
0/400
Keine Kommentare