Wie kann man beurteilen, ob ein sogenannter „HACK“, der einem Krypto- oder Blockchain-Projekt passiert ist, legitim ist oder ob es nur ein Mechanismus ist, um einen RUG zu verbergen?

Nach dem, was mit MtGox oder QuadrigaCX oder ähnlichen Fällen passiert ist, in denen Gründer behaupteten, sie hätten die privaten Schlüssel verloren, die den Großteil der digitalen Assets ihrer Börsen enthielten, während sie verschwanden oder später tot aufgefunden wurden, sind die Menschen in der Krypto-Sphäre offensichtlich zunehmend misstrauisch, wenn sie von a hören ein Projekt hacken, und der erste Gedanke, der mir in den Sinn kommt, ist, dass die Gründer im Grunde den Fonds geleert haben und damit durchgebrannt sind, das ist das, was allgemein als RUG bezeichnet wird.

Dies war wahrscheinlich in vielen Projekten der Fall, aber nicht unbedingt in allen. Daher betrachten wir heute einen Fall, den wir aufgrund der Natur der Situation für einen echten Hack halten.

Wir denken, dass es ein interessanter Fall ist, ihn zu analysieren, da er dazu beitragen wird, die Bedeutung von Sicherheit und Audits in Smart-Contract- oder Blockchain-bezogenen Projekten im Allgemeinen besser zu verstehen.

Wir werden das Drama, das mit dem RING Financial-Projekt passiert ist, einem Token, das auf der BSC (Binance Blockchain) gestartet wurde, objektiv analysieren.

Bevor wir zum Hack kommen, fassen wir zunächst das Projekt und seine Situation davor zusammen:

RING Financial vor dem Hack

RING Financial war ein DeFi-Projekt mit dem Ziel, das DeFi für die DeFi- und Krypto-Community zugänglicher zu machen. Ein ehrgeiziges Projekt, das ein Node-Yield-Protokoll erstellen wollte, das von Node-Inhabern verwaltet und Liquidität in mehr als 300 Protokolle gleichzeitig zuweisen würde. Ziel war es, über einen RING-Knoten und über die RING-Dapp Zugriff auf alle Protokolle zu erhalten.

Diese Protokolle wurden vom Team überprüft und dann stimmte die Community darüber ab, wo sie zugewiesen werden sollten. Das gleiche Abstimmungskonzept wie bei einem DAO, was RING sehr attraktiv machte.

RING Financial vereinfachte auch einen Großteil des Recherche- und Bereitstellungsprozesses für einen einzelnen Node-Inhaber. Eine Dapp für den Zugriff auf alle anderen Dapps, sodass Sie nur eine Schnittstelle benötigen, anstatt 300 verschiedene mit eigenen Zugängen und eigenen Knoten.

Schließlich war es das Ziel von RING Financial, die Gebühren für die Bereitstellung auf verschiedenen Protokollen zu senken, da mit dem Volumen niedrigere Transaktionsgebühren für einzelne Inhaber einhergehen, was eines der Hauptverkaufsargumente des Projekts war. Ein Projekt mit Flair und Ehrgeiz, die Dinge für die Community einfacher zu machen und für diejenigen, die Defi nicht kennen, noch mehr Mainstream zu machen.

Allerdings reichen Fingerspitzengefühl und Ehrgeiz nicht immer aus, und Sie benötigen Fachwissen und Wissen, das in neuen und unreifen Märkten selten zu finden ist und weshalb RING Financial sein Versprechen nicht vollständig einlösen konnte.

Was ist also wirklich mit RING Financial passiert? Und warum wurde es gehackt? Dank der Blockchain haben wir alle forensischen Beweise, die wir brauchen, um uns damit zu befassen und zu sehen, wo die Schwachstellen waren und warum RING Financial war kein Betrug.

Der RING Financial HACK fand am 5. Dezember 2021 zwischen 2:01 Uhr und 2:06 Uhr UTC statt.

Ja, alles geschah in buchstäblich nur 5 Minuten! Dank des Blockchain-Scanners für diese Details stellen wir Ihnen übrigens direkt darunter die Links der Transaktionen im Zusammenhang mit dem HACK sowie die Vertragsadresse für diejenigen zur Verfügung, die detaillierter suchen möchten.

Hier ist die Zusammenfassung, die den Fehler erklärt, den der Angreifer ausgenutzt hat:

Sie müssen verstehen, dass der Smart Contract von RING Financial aus mehreren Teilen bestand, einem für den Token und alle damit verbundenen Daten und einem anderen für alles, was mit der Abrechnung von Knoten und Belohnungen zu tun hat. Der Teil des Tokens hatte eine Sicherheit, so dass nur der Administrator des Vertrags die wichtigen Daten dieses ändern kann, um Ihnen einen Code zu zeigen, hier ist ein Header einer Funktion des Vertrags, die über das Attribut „onlyOwner“ geschützt ist. die vorschreibt, dass die Funktion nur vom Administrator ausgeführt werden kann:

Eine Funktion, die keine hat nur Besitzer -Attribut (oder ein gleichwertiges Attribut zum Schutz des Funktionszugriffs) kann von praktisch jedem ausgeführt werden.

Nun, weißt du was? Die Funktionen im Nodes and Rewards-Teil hatten dieses Attribut nicht, wie Sie sehen können, wenn Sie sich die Funktionsnamen unten ansehen (die nur Besitzer Attribut fehlt):

Und wie Sie sich vorstellen können, hat ein Hacker diesen Fehler ausgenutzt und betrogen, um eine exponentielle Anzahl von Belohnungen in RING zu erhalten, und sie dann in den Liquiditätspool geworfen und ihn in wenigen Minuten fast gewaltsam geleert. So hat er seine Betrügereien begangen.

Jetzt stellen Sie sich wahrscheinlich zwei Fragen:

Wie konnten die Entwickler eine solche Lücke hinterlassen?

Nach einem Gespräch mit Solidity-Entwicklern (Sprache, die zum Codieren von Smart-Contracts auf Ethereum verwendet wird), ist dies ein Fehler im Zusammenhang mit der Rollenvererbung zwischen zwei Smart-Contracts. Vererbung ist ein Begriff der Programmiersprache, und um Ihnen keine Kopfschmerzen zu bereiten, wir Bleiben wir bei einfachen Worten: Grundsätzlich ist es sehr wahrscheinlich, dass die Person, die den Vertrag codiert hat, dachte, dass die Funktionen des Node-Teils die Sicherheitsrollen der Funktionen des Token-Teils erben, aber das ist in Solidity leider nicht der Fall, und Es ist notwendig, die Rollen jeder Funktion jedes Vertrags neu zu definieren, unabhängig von ihrer Verbindung. Unsere Schlussfolgerung zu diesem Punkt ist also, dass der Entwickler kein Experte war und dass er den Vertrag wahrscheinlich veröffentlicht hat, OHNE sich die Zeit zu nehmen, ihn erneut zu lesen, wahrscheinlich in Eile.

Woher wissen Sie, dass es nicht der Entwickler selbst ist, der diesen Fehler absichtlich hinterlassen hat, und dass es kein Betrug war?

Sehr guter Einwand und es ist leicht, einen Betrug anzunehmen, wenn Sie sich nicht sicher sind, wie Smart Contracts Arbeit, aber es ist eigentlich sehr einfach, die Unschuld des Entwicklers anzunehmen, denn er hat den gesamten Code des Smart-Contracts öffentlich auf BSCSCAN.COM (dem beliebtesten Scanner der Binance Blockchain), am 19. November 2021, veröffentlicht und verifiziert Das heißt, mehr als zwei Wochen bevor der RING Financial HACK passierte. Und wie bereits erwähnt, stand der Fehler SCHWARZ AUF WEISS im Vertrag und jeder erfahrene Entwickler hätte ihn bemerkt und reagiert, aber leider hatte der erste überhaupt keine Gnade. Es ist daher offensichtlich, dass sich der Entwickler dieses Fehlers nicht bewusst war, weil er zu keinem Zeitpunkt das Risiko eingegangen wäre, jemanden das RING Financial-Projekt töten zu lassen.

Um auf die Fortsetzung des RING Financial HACK zurückzukommen, der Entwickler erkannte seinen Fehler und fror einfach den Vertrag ein, um jegliche Verteilung von Belohnungen zu stoppen, damit der Angreifer den Pool nicht vollständig leert. Anschließend stellte er einen Node-Vertrag erneut bereit, diesmal mit dem Sicherheitsattribut „onlyOwner“. Dieser neue Node-Vertrag konnte die neue Belohnungsverteilung korrekt handhaben, nur dass es zu spät war, da durch den HACK jegliches Vertrauen in das Projekt und das Team verloren gegangen war und der Verkaufsdruck den Token tötete und beendete und das Projekt.

Abschließend haben wir diese Geschichte ausgewählt, weil sie zwei wichtige Dinge über Smart-Contracts und Krypto-Projekte zeigt: Programmieren Sie niemals einen Vertrag in Eile und wenden Sie sich immer an die Wirtschaftsprüfungsgesellschaften, denn sobald der Hack passiert, ist es zu spät, um das Boot zu retten, und Das RING Financial-Projekt ist ein gutes Beispiel, sie haben außerdem gemäß ihrer Mitteilung Wirtschaftsprüfungsgesellschaften für diesen zweiten Node-Vertrag kontaktiert und ihn nicht öffentlich auf BSCSCAN veröffentlicht, bis sie sich seiner Sicherheit sicher waren. Aber wie gesagt, für RING Financial war es zu spät, und der Schaden war irreversibel.

Hier sind alle Links des Scanners und die Vertragsadressen:

Brieftasche, die Transaktion für Hack-Exploit ausführt: 0xfe58c9e2ecb95757be6f4bca33162cfa346cc34f

 Ring smart-contract address: 0x521ef54063148e5f15f18b9631426175cee23de2

Ring reward pool address: 0xa46cc87eca075c5ae387b86867aa3ee4cb397372

 Transaktions-Hack-Exploit:

 TRX 1

    link: https://bscscan.com/tx/0x596d38494ea5ae640b2a556a7029692928f15713d22b5948477c4eb4a92cf68e

TRX 2

    link: https://bscscan.com/tx/0xfc890c855709bb6aeb5177ee31e08751561344402a88af13e7dfd02b9a2f6003

TRX 3

    link: https://bscscan.com/tx/0x35c2f1ed9c5ce13a714af6c0dcbbce8fe720f7d6212232b6dd3657d8799a10f1

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
• Quelle: https://www.fintechnews.org/how-to-judge-if-a-so-called-hack-that-happened-to-a-crypto-or-blockchain-project-is-legit-or-if-its-just-a-mechanism-to-hide-a-rug/