Sicherheitsprüfung für Nym Mixnet und Vesting-Verträge

Einführung

Im Dezember 2022 unterzog sich Nym einem unabhängigen Sicherheitsaudit, das von Oak Security durchgeführt wurde, einem in Deutschland ansässigen Cybersicherheitsberatungsunternehmen, das sich auf die Prüfung von Blockchains der dritten Generation und dezentralen Protokollen spezialisiert hat. Aufgrund seiner umfassenden Erfahrung mit Ökosystemen wie Cosmos, Terra, Polkadot und Flow wurde Oak Security damit beauftragt, zwei kritische Komponenten des Nym-Ökosystems zu bewerten: (1) das Nym-Mixnet und die Vesting-Verträge (siehe vollständiger Bericht) sowie (2) das Nym-Wallet (siehe vollständiger Bericht). Ziel des Audits war es, die Robustheit dieser Komponenten zu bewerten, potenzielle Schwachstellen zu identifizieren und die Einhaltung von Best Practices bei der Code-Entwicklung sicherzustellen. Um die Übersicht zu erleichtern, haben wir die Ergebnisse nach einzelnen Komponenten aufgeschlüsselt. Die Zusammenfassung des Nym Wallet-Audits können Sie hier einsehen.

Zusammenfassung des Audits der Nym-Mixnet- und Vesting-Verträge durch Oak Security

Die Prüfung erstreckte sich über zwei Wochen und wurde von einem Team aus vier Experten durchgeführt. Das Nym-Team gewährte Oak Security uneingeschränkten Zugriff auf den Quellcode des Projekts, detaillierte Projektspezifikationen und begleitende Dokumentation. Der Umfang der Prüfung umfasste die Verträge „contracts/mixnet“ und „contracts/vesting“, sowie die entsprechenden Importe dieser Verträge für das Nym-Mixnet und die Vesting-Verträge.

Oak Security hat den Code gründlich geprüft und dabei automatisierte Quellcode- und Abhängigkeitsanalysen mit einer manuellen Zeile-für-Zeile-Prüfung kombiniert, um Sicherheitslücken aufzudecken, die Codequalität zu bewerten und die Einhaltung der Grundsätze für sicheres Programmieren zu überprüfen. Dieser umfassende Ansatz umfasste eine eingehende Analyse kritischer Bereiche wie Schwachstellen durch Race-Conditions, Unterlauf- und Überlaufprobleme, Verfahren zur Schlüsselverwaltung, kryptografische Robustheit, Risiken durch Datenlecks, den Umgang mit Passwörtern sowie Zugriffs- und Autorisierungskontrollen.

Der Schwerpunkt der Prüfung lag darauf, die korrekte Funktionalität der Protokolle sicherzustellen, ausnutzbare Schwachstellen oder Fehler in Smart Contracts zu identifizieren und Verbesserungen hinsichtlich der Codesicherheit und Lesbarkeit zu empfehlen.

Übersicht über die Ergebnisse

Die Nym-Mixnet- und Vesting-Verträge zeichneten sich durch hohe Lesbarkeit und Klarheit aus, wobei eine umfassende Testabdeckung ihre Zuverlässigkeit untermauerte. Bei ihrer Prüfung stellten die Prüfer 19 Feststellungen fest, darunter 9 Sicherheitslücken – darunter Probleme mit kritischem und hohem Schweregrad – sowie 10 allgemeine Schwachstellen, die als geringfügig oder informativ eingestuft wurden.

Das Nym-Team hat alle kritischen und schwerwiegenden Probleme zügig behoben. Das Oak Security-Team hat unsere Korrekturen überprüft und genehmigt.

NYM-MIX-VEST-CONTRACT-1: Eine fehlgeschlagene Ausführung eines Epochen- oder Intervallereignisses blockiert den Epochenfortschritt dauerhaft (kritisch)

Bei der Prüfung wurde eine Schwachstelle bei der Verarbeitung von „AdvanceCurrentEpoch“-Nachrichten in der Datei „contracts/mixnet/src/interval/transactions.rs“ festgestellt. Eine sequenzielle Schleife verarbeitet alle ausstehenden Ereignisse direkt innerhalb des Transaktionskontexts, was bedeutet, dass ein einziges fehlgeschlagenes Ereignis die gesamte Transaktion rückgängig machen könnte, wodurch der Fortschritt von Epochen und Intervallen effektiv gestoppt würde und das Protokoll ins Stocken geriete.

Um dieses Problem zu beheben, empfahlen die Prüfer, die Ausführung von Ereignissen in Unternachrichten mit einer Antwortrichtlinie einzubinden. Dieser Ansatz würde es dem System ermöglichen, Fehler elegant zu behandeln, ohne die gesamte Transaktion rückgängig zu machen. Wir haben uns jedoch bewusst dagegen entschieden, dieser Empfehlung zu folgen. Ein Fehler während der Ereignisausführung deutet auf einen erheblichen Logikfehler hin, der den Belohnungsmechanismus beeinträchtigen könnte. Daher ist es ratsam, den Epochenfortschritt für eine manuelle Überprüfung anzuhalten, anstatt das Risiko einzugehen, in einem fehlerhaften Zustand weiterzuarbeiten. Stattdessen haben wir in der Nym-API eine erweiterte Überwachung implementiert, um fehlgeschlagene Epochenwechsel zu erkennen und uns darauf hinzuweisen. Dieser Ansatz stellt sicher, dass solche Fehler umgehend gemeldet werden, sodass rechtzeitig eingegriffen werden kann, um Probleme zu beheben.

NYM-MIX-VEST-CONTRACT-2: Angreifer können „verwaiste“ Mix-Knoten dazu zwingen, sich ohne deren Zustimmung einer Familie anzuschließen, um eine große Anzahl davon in derselben Ebene zu bündeln (kritisch)

In der Nachricht „JoinFamilyOnBehalf“ wurde eine Sicherheitslücke entdeckt, die es einem Angreifer ermöglichen könnte, einen Mix-Knoten ohne dessen Zustimmung zu einer Familie hinzuzufügen. Durch die Erstellung einer bösartigen Familie und die Verwendung des mit dem privaten Schlüssel des Opfer-Mix-Knotens signierten Identitätsschlüssels als Signatur konnte der Angreifer den Mix-Knoten in der Familie einfangen. Dies könnte es einem Angreifer möglicherweise ermöglichen, isolierte Mix-Knoten zu einer einzigen Familie zusammenzufassen, wodurch das Netzwerk gestört würde, da sich die Knoten auf derselben Ebene konzentrieren und sich die Chancen des Angreifers erhöhen, das Routing zu beeinflussen.

Um die Sicherheitslücke in der „JoinFamilyOnBehalf“-Nachricht zu beheben, wurde der Signaturmechanismus des Vertrags überarbeitet. Anstatt lediglich die Identität des Mix-Knotens zu signieren, wurden die Signaturen so aktualisiert, dass sie eine Nachricht mit einer eindeutigen Absicht und einem eindeutigen Nonce enthalten. Diese Änderung stellt sicher, dass Signaturen nicht wiederverwendet oder nachgespielt werden können.

NYM-MIX-VEST-CONTRACT-3: Eine unbegrenzte Iteration bei der Verarbeitung von „TrackUndelegation“-Nachrichten könnte dazu führen, dass der Benutzer die Delegierung nicht widerrufen kann, was zudem den Epochenfortschritt dauerhaft verhindert (kritisch)

Die unbegrenzte Iteration der „TrackUndelegation“-Nachricht könnte bei der Bearbeitung von Konten mit zahlreichen Delegierungen zu einem Gas-Mangel führen, wodurch Benutzer daran gehindert werden, Delegierungen rückgängig zu machen. Dieser Fehler würde auch den Epochenfortschritt stoppen, wodurch das Protokoll in seinem aktuellen Zustand stecken bleiben würde.

Um dieses Problem zu beheben, haben wir eine Obergrenze von 25 Vesting-Delegationen pro Konto eingeführt. Diese Lösung basierte auf der zu diesem Zeitpunkt beobachteten höchsten Anzahl an Vesting-Delegationen.

Update: Seit 2024 ist die Option zur Vergabe von Vesting-Delegationen vollständig deaktiviert.

NYM-MIX-VEST-CONTRACT-4: Ein Angreifer kann „BondMixnodeOnBehalf“- und „CreateFamilyOnBehalf“-Nachrichten vorwegnehmen und deren Nutzdaten verändern (kritisch)

Diese Sicherheitslücke würde es einem Angreifer ermöglichen, „BondMixNodeOnBehalf“- und „CreateFamilyOnBehalf“-Nachrichten vorwegzunehmen, die Signatur zu extrahieren und die Nutzlast zu verändern. Im Fall von „BondMixNodeOnBehalf“ könnte sich der Angreifer zudem selbst als Proxy festlegen und so die volle Kontrolle über den registrierten Bond erlangen.

Um die Sicherheitslücke zu beheben, haben wir eine zweigleisige Lösung implementiert. Zunächst haben wir die in NYM-MIX-VEST-CONTRACT-2 beschriebenen Änderungen bei der Signaturerstellung vorgenommen, durch die eine eindeutige Absicht und ein eindeutiger Nonce hinzugefügt wurden. Zweitens haben wir die zulässige Proxy-Adresse auf das Vesting-Konto beschränkt, um sicherzustellen, dass Angreifer sich nicht selbst als Proxy festlegen und unbefugte Kontrolle über registrierte Anleihen erlangen können.

Update: Seit 2024 sind alle Proxy-Operationen deaktiviert, wodurch der Angriff nicht mehr möglich ist.

NYM-MIX-VEST-CONTRACT-5: Signaturen können im Rahmen von „on behalf“-Transaktionen wiederholt werden, um sich als Benutzer auszugeben (kritisch)

Diese Sicherheitslücke ermöglicht die Wiederverwendung von Signaturen innerhalb von „im Namen von“-Transaktionen, wodurch Angreifer sich als Benutzer ausgeben können. Da die Signaturen nur Rohdaten ohne zusätzliche Metadaten wie Nonces oder Nachrichtenkennungen enthalten, könnte ein Angreifer eine Signatur aus einer Nachricht für eine andere wiederverwenden, um Familienmitglieder gewaltsam zu entfernen. Zudem können Angreifer Signaturen für denselben Nachrichtentyp wiederverwenden, sodass ein Mitglied mit derselben Signatur mehrfach wieder in eine Familie aufgenommen werden kann.

Die Lösung für dieses Problem entspricht der in NYM-MIX-VEST-CONTRACT-4 implementierten Lösung.

NYM-MIX-VEST-CONTRACT-6: Die Schlüsselgenerierung für (Eigentümer, Bevollmächtigter)-Paare könnte zu Kollisionen führen (kritisch)

Diese Sicherheitslücke würde es zwei verschiedenen Adresspaaren (Eigentümer, Proxy) ermöglichen, in der Funktion „generate_owner_storage_subkey“ dasselbe XOR-Ergebnis zu erzeugen, was zu Schlüsselkollisionen und Datenüberschreibungen führen könnte.

Die Lösung, die rechtmäßige Vollmacht ausschließlich auf die Adresse des Vesting-Vertrags zu beschränken, die im NYM-MIX-VEST-CONTRACT-4 angewendet wurde, behebt auch diese Sicherheitslücke. Indem sichergestellt wird, dass die XOR-Operation stets mit einer konstanten Zeichenkette durchgeführt wird, wird durch diese Änderung das Risiko von Kollisionen effektiv beseitigt.

NYM-MIX-VEST-CONTRACT-7: „track_delegation“ kann eine bestehende Delegierung überschreiben, wenn innerhalb desselben Blocks mehr als eine verarbeitet wird (kritisch)

Dieses Problem könnte zu Schlüsselkollisionen führen, wenn innerhalb desselben Blocks mehrere Delegierungen vorgenommen werden. Dies könnte dazu führen, dass die Funktion „save_delegation“ eine bestehende Delegierung überschreibt, was den Verlust der vorherigen Delegierung zur Folge hätte.

Um das Problem zu beheben, haben wir die Logik der Funktion „save_delegation“ so geändert, dass zunächst der bestehende Delegationsbetrag ausgelesen wird, bevor der neue gespeichert wird. Wenn für denselben Schlüssel bereits eine Delegation existiert, rufen wir den aktuellen Betrag ab, fügen die neue Delegation hinzu und speichern anschließend die aktualisierte Gesamtsumme, wobei wir sicherstellen, dass keine bestehende Delegation überschrieben wird.

NYM-MIX-VEST-CONTRACT-8: Der Inhaber der Anleihe kann keine Transaktionen durchführen, wenn die Anleihe „im Namen“ durch einen Bevollmächtigten (Major) erstellt wurde.

Dieses Problem würde den Anleiheinhaber daran hindern, Vorgänge im Zusammenhang mit seiner Anleihe durchzuführen, wenn die Anleihe „im Namen“ eines anderen erstellt wurde und die aktuelle Transaktion vom Inhaber selbst statt vom Bevollmächtigten initiiert wird. Da der Proxy kompromittiert werden oder verloren gehen könnte und der Eigentümer keine Möglichkeit hat, ihn zu ändern, könnte dies dazu führen, dass der Eigentümer die Kontrolle über sein Bond verliert.

Wir betrachten dies nicht als Problem, da es sich um ein beabsichtigtes, vom Design her vorgesehenes Verhalten handelt. Wenn ein Mix-Knoten über den Vesting-Vertrag gebunden wird (oder Delegationen vorgenommen werden), sollen alle nachfolgenden Interaktionen mit der Bindung oder Delegation ausschließlich über den Vesting-Vertrag erfolgen.

Update: Seit 2024 wurde der Vesting-Vertrag abgeschafft.

NYM-MIX-VEST-CONTRACT-9: Die Ausführung der Nachrichten „LeaveFamily“ und „LeaveFamilyOnBehalf“ kann fehlschlagen, wenn eine erhebliche Anzahl von Mix-Knoten Mitglieder einer Familie (Major) sind.

Dieses Problem würde dazu führen, dass die Nachrichten „LeaveFamily“ und „LeaveFamilyOnBehalf“ aufgrund von Gasmangel fehlschlagen, wenn eine große Anzahl von Familienmitgliedern in der MEMBERS-Map durchlaufen wird. Dadurch würde verhindert, dass Mix-Knoten eine Familie verlassen, wodurch sie effektiv in ihrer aktuellen Familie gebunden bleiben.

Lösung: Die Lösung bestand darin, die Logik so umzugestalten, dass direkt auf die MEMBERS-Map zugegriffen und die Zugehörigkeit eines Mix-Knotens überprüft wird. Durch diese Änderung entfiel die Notwendigkeit einer Iteration, die zu „Out-of-Gas“-Fehlern führen konnte, und es wurde sichergestellt, dass Mitglieder eine Familie erfolgreich verlassen können, selbst wenn die Familie viele Mitglieder umfasst.

Update: Ab 2024 werden Knotenfamilien entfernt.

Letzte Worte

Wir möchten dem Team von Oak Security für sein Fachwissen und sein Engagement während des gesamten Audit-Prozesses danken. Wir schätzen zudem die Zusammenarbeit und die Professionalität, die sowohl in der Planungs- als auch in der Durchführungsphase des Audits zum Ausdruck kamen. Unser kontinuierliches Engagement für Sicherheit hat weiterhin höchste Priorität, und wir freuen uns auf die weitere Zusammenarbeit mit Sicherheitsexperten, um die höchsten Standards für unser Ökosystem aufrechtzuerhalten.