Vereinbaren Sie ein unverbindliches Erstgespräch!

Vereinbaren Sie ganz einfach online einen Termin für ein unverbindliches und kostenloses Erstgespräch mit einem unserer Mitarbeiter.

Gespräch vereinbaren

Smart Contract Auditing

Smart Contracts sind Programme die dezentral, durch jeden Teilnehmer am Netzwerk ausgeführt werden. Somit benötigen Smart Contracts sorgfältigere audits, da diese wirtschaftlich lohnende Ziele für Hacker darstellen. Diese Ausführung hat die Eigenschaft, dass die resultierenden Ergebnisse unveränderlich sind. Fehlgeleitete Ausführungen können somit nicht rückgängig gemacht werden.

Wir auditieren Smart Contracts mit eigenen und externen Frameworks nach NCC Standard auf folgenden Blockchain-Technologienen

We are white hats.

Unsere Untersuchungs- und Analyseschwerpunkte


1) Reentrancy-Angriff

Der Reentrancy-Angriff erfolgt, wenn externe Aufrufe eines Vertrages neue Aufrufe auf den Quellvertrag tätigen dürfen, bevor die erste Ausführung abgeschlossen ist. Für eine Funktion bedeutet dies, dass sich der Vertragsstatus mitten in der Ausführung durch einen Aufruf eines nicht vertrauenswürdigen Vertrages oder die Verwendung einer Low-Level-Funktion mit einer externen Adresse ändern kann.

2) Zugriffskontrolle

In der Regel greift man auf die Funktionalität eines Vertrages über seine öffentlichen oder externen Funktionen zu. Während unsichere Sichtbarkeitseinstellungen Angreifern einfache Möglichkeiten bieten, auf die privaten Werte oder die Logik eines Vertrags zuzugreifen, sind Zugriffsbeschränkungen manchmal subtiler. Diese Schwachstellen können auftreten, wenn Verträge die veraltete tx.origin verwenden, um den Benutzer zu validieren.

3) Arithmetische Probleme

Ganzzahlige Über- und Unterläufe sind keine neue Klasse von Schwachstellen, aber sie sind besonders gefährlich in Smart Contracts in denen unsignierte Ganzzahlen weit verbreitet sind und die meisten Entwickler an einfache int Typen gewöhnt sind (die oft nur signierte Ganzzahlen sind).

4) Ungeprüfte Rückgabewerte für Low Level Calls

Eines der tieferen Merkmale von Solidity sind die Low-Level-Funktionen call(), callcode(), delegatecall() und send(). Ihr Verhalten bei der Fehlererkennung unterscheidet sich deutlich von anderen Solidity-Funktionen, da sie sich nicht verbreiten (oder aufblitzen) und nicht zu einer vollständigen Umkehrung der aktuellen Ausführung führen. Stattdessen geben sie einen booleschen Wert zurück, der auf false gesetzt ist, und der Code wird weiter ausgeführt. Wenn der Rückgabewert solcher Low-Level-Aufrufe nicht überprüft wird, kann dieses zu Ausfällen und anderen unerwünschten Ergebnissen führen.

5) Denial of Service

Während sich andere Arten von Anwendungen schließlich wiederherstellen können, können Smart Contracts durch einen einzigen dieser Angriffe für immer offline gestellt werden. Viele Wege führen zu Denials of Service, einschließlich böswilligem Verhalten als Empfänger einer Transaktion, künstlicher Erhöhung des für die Berechnung einer Funktion notwendigen Gases, Missbrauch der Zugangskontrollen für den Zugriff auf private Komponenten von Smart Contracts und die Nutzung von Verwechslungen. Diese Angriffsklasse umfasst viele verschiedene Varianten und wird sich in den kommenden Jahren weiterentwickelt.

6) Bad Randomness

Zufälligkeit ist in Ethereum schwer zu erreichen. Während Solidity Funktionen und Variablen anbietet, die auf scheinbar schwer vorhersehbare Werte zugreifen können, sind sie in der Regel entweder öffentlicher als sie erscheinen oder dem Einfluss von Minern ausgesetzt. Da diese Quelle des Zufalls bis zu einem gewissen Grad vorhersehbar sind, können böswillige Benutzer sie im Allgemeinen replizieren und die Funktion angreifen, die sich auf ihre Unberechenbarkeit stützt.

7) Front-Running

Da Miner immer mit Gasgebühren für die Ausführung von Code im Namen von externen Adressen (EOA) belohnt werden, können Benutzer höhere Gebühren festlegen, um ihre Transaktionen schneller validieren zu lassen. Da die Ethereum-Blockchain öffentlich ist, kann jeder den Inhalt der ausstehenden Transaktionen anderer sehen. Das bedeutet, wenn ein bestimmter Benutzer die Lösung für ein Rätsel oder ein anderes wertvolles Geheimnis preisgibt, kann ein böswilliger Benutzer die Lösung stehlen und seine Transaktion mit höheren Gebühren kopieren, um die ursprüngliche Lösung zu verhindern. Wenn Entwickler von Smart Contracts nicht vorsichtig sind, kann diese Situation zu praktischen und verheerenden Front-Angriffen führen.

8) Time manipulation

Manchmal müssen sich Smart Contracts auf die aktuelle Zeit stützen. Dies geschieht in der Regel über block.timestamp oder block.height Solidity. Da der Miner einer Transaktion über einen gewissen Spielraum bei der Blockerstellung verfügt, vermeiden gute Smart Contracts, sich stark auf den angekündigten Zeitpunkt zu verlassen. Weiterhin ist zu Beachten, dass block.timestamp auch manchmal (falsch) bei der Erzeugung von Zufallszahlen verwendet wird, wie in 6) beschrieben.

9) Short Address Attack

Short Address Attacks sind ein Nebeneffekt, da das EVM selbst falsches Padding akzeptiert. Angreifer können dies ausnutzen, indem sie speziell entwickelte Adressen verwenden, um schlecht kodierte Clients dazu zu bringen, Argumente falsch zu kodieren, bevor sie sie in Transaktionen aufnehmen. Obwohl diese Schwachstelle noch nicht ausgenutzt wurde, ist sie ein guter Beweis für Probleme, die sich aus der Interaktion zwischen Clienten und der Ethereum-Blockchain ergeben.

10) Unknown Unknowns

Ethereum steckt noch in den Kinderschuhen. Die Hauptsprache für die Entwicklung von Smart Contracts, Solidity, muss noch eine stabile Version erreichen, und die Werkzeuge des Ökosystems sind noch experimentell. Deswegen ist unsere Expertise und Erfahrung beim Testen besonders wichtig.

Unsere Einschätzung:

Viele Schwachstellen in Smart Contracts überraschten und es gibt keinen Grund zu der Annahme, dass es keinen weiteren Exploits geben wird. Solange Investoren beschließen, große Summen in komplexen, aber schlecht geprüften Code zu investieren, werden wir weiterhin neue Vorfälle sehen, die zu verheerenden Folgen führen. Methoden zur formalen Verifizierung von Smart Contracts sind noch nicht ausgereift. Da weiterhin neue Klassen von Schwachstellen gefunden werden, müssen Entwickler auf dem neusten Stand bleiben und neue Tools müssen entwickelt werden, um diese zu finden. Diese Top 10 werden sich wahrscheinlich schnell entwickeln, bis die Smart Contracts einen Stand der Stabilität erreicht haben.

Neugierig? Überzeugt? Interessiert?

Fordern Sie noch heute einen Beispielbericht oder unser Leistungsportfolio an. Wir bearten Sie gerne!

Wir haben Ihre Nachricht erhalten. Wir werden uns in Kürze bei Ihnen melden. Ein Fehler ist aufgetreten. Bitte versuchen Sie es erneut.