Trend-Themen
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.

sudo rm -rf --no-preserve-root /
Wir arbeiten daran, was als nächstes kommt.
Beschreibung: 063E 966C 93AB 4356 492F E032 7C3B 4B4B 7725 111F
sudo rm -rf --no-preserve-root / erneut gepostet
BlockThreat - Woche 28, 2025
💙 Gesponsert von @SecurityOak
🔥 Massenexploitation von Proxy-Verträgen entdeckt von @deeberiroz und whitehatted von @pcaversaccio @dedaub und @_SEAL_Org
💸 @GMX_IO Reentrancy-Hack $42M ($37M wiederhergestellt)
💸 @KintoXYZ nicht initialisierter Proxy. $1,55M
2,42K
sudo rm -rf --no-preserve-root / erneut gepostet
Lektionen für Sicherheitsexperten: Auditieren Sie Proxy-Initialisierungen gründlich.
Überwachen Sie die Delegatecall-Ketten (einfach in unserer App zu tun) und stellen Sie die Integrität des Speichers mit komplexen Proxy-Mustern sicher.
Props gehen an @deeberiroz @VennBuild @pcaversaccio @_SEAL_Org
Bleiben Sie wachsam.
1,99K
Also habe ich herausgefunden, dass es noch ausgeklügelter ist. Ich habe beobachtet, dass die Frontrunning-Transaktion (von den Angreifern) `initialize` aufruft und Protokolle ebenfalls _erfolgreich_ `initialize` danach aufrufen (daher denken sie, dass alles normal ist). Aber warte, wie ist das überhaupt möglich? Ich musste sehr tief in die Änderungen der Speicherplätze eintauchen und rate mal, was ich gefunden habe: Sie _setzen_ den Wert des Speicherplatzes `_initialized` am Ende der Frontrunning-Transaktion zurück (nachdem sie zum bösartigen Implementierungsvertrag gewechselt haben). Das bedeutet, dass der Proxy-Speicher jetzt aussieht, als wäre er nie initialisiert worden.
Der relevante Speicherplatz, den man sich ansehen sollte, ist `keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))` = `0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00`
Das ist next-level böse.



sudo rm -rf --no-preserve-root /10. Juli, 22:13
Es wird noch ausgefallener: Die Art und Weise, wie Etherscan getäuscht wurde, um den falschen Implementierungsvertrag anzuzeigen, basiert darauf, dass in derselben Frontrunning-Transaktion 2 verschiedene Proxy-Slots gesetzt werden. Etherscan verwendet eine bestimmte Heuristik, die verschiedene Speicher-Slots einbezieht, um den Implementierungsvertrag abzurufen.
Es gibt einen alten Proxy von OpenZeppelin, der den folgenden Slot verwendet hat: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3`
Wir haben jetzt auch den Standard-EIP-1967-Slot `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`
Was passiert ist, dass der alte OpenZeppelin-Proxy-Slot mit der harmlosen Implementierungsadresse _und_ der Standard-EIP-1967-Slot ebenfalls mit der bösartigen Implementierungsadresse beschrieben wurde. Da Etherscan zuerst den alten Proxy-Slot abfragt, wurde zuerst die harmlos aussehende Adresse abgerufen und somit angezeigt.

21,55K
sudo rm -rf --no-preserve-root / erneut gepostet
Früher in dieser Woche wurde eine potenzielle Schwachstelle im Cross-Chain-Manager-Vertrag von Orderly auf der BNB-Chain identifiziert.
Als Reaktion darauf wurde unser BNB-Vault für Einzahlungen und Abhebungen sofort pausiert, die Verträge wurden migriert und Einzahlungen/Abhebungen innerhalb von 2 Stunden wieder aufgenommen.
✅ Keine Benutzerfonds sind gefährdet oder gingen verloren.
Ein besonderer Dank geht an @deeberiroz, @VennBuild, @seal_911, @pcaversaccio und das gesamte Team, das geholfen hat, dies zu kennzeichnen!
Gemeinsam sicherer 🤝
7,53K
sudo rm -rf --no-preserve-root / erneut gepostet
[5/5]
Dankbarkeits-Rollcall • @SlowMist_Team für unermüdliche Triage & Patching • @dedaub, @pcaversaccio und das @seal_911 Krisenteam für einen 36-stündigen Code-Check • @etherscan für blitzschnelle UI-Bereinigung • Und nochmals vielen Dank an @deeberiroz, @VennBuild, @davidberiro—euer Hinweis hat den Tag gerettet 💙
12,32K
Es wird noch ausgefallener: Die Art und Weise, wie Etherscan getäuscht wurde, um den falschen Implementierungsvertrag anzuzeigen, basiert darauf, dass in derselben Frontrunning-Transaktion 2 verschiedene Proxy-Slots gesetzt werden. Etherscan verwendet eine bestimmte Heuristik, die verschiedene Speicher-Slots einbezieht, um den Implementierungsvertrag abzurufen.
Es gibt einen alten Proxy von OpenZeppelin, der den folgenden Slot verwendet hat: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3`
Wir haben jetzt auch den Standard-EIP-1967-Slot `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`
Was passiert ist, dass der alte OpenZeppelin-Proxy-Slot mit der harmlosen Implementierungsadresse _und_ der Standard-EIP-1967-Slot ebenfalls mit der bösartigen Implementierungsadresse beschrieben wurde. Da Etherscan zuerst den alten Proxy-Slot abfragt, wurde zuerst die harmlos aussehende Adresse abgerufen und somit angezeigt.

41,05K
Ich weiß nicht, Mann, aber die wahre Bedrohung für Ethereum ist nicht der Staat, tatsächlich (zumindest nicht heute). Es sind die VCs und Protokoll-Karrieristen, die versuchen, es in einen glänzenden Fintech-Spielplatz für "sichere", konforme DeFi zu verwandeln. Hör mir zu: Sie wollen keinen unaufhaltsamen Code. Sie wollen keinen Widerstand. Sie wollen verdammte _Kontrolle_. Denn tief im Inneren wissen sie, was Ethereum werden könnte, wenn es ungebunden bleibt: eine zensurresistente, datenschutzorientierte globale Ausführungsschicht, die kein Staat, kein Konzern, kein Kartell von Anzugträgern jemals aufhalten könnte. Lass uns das zur Realität machen.
19,38K
Also kontaktiert dich jemand auf LinkedIn mit einer vielversprechenden Jobmöglichkeit. Klingt gut, oder? Sie scheinen legitim zu sein (nachdem du sie 1 Minute lang überprüft hast) und nach einigem kurzen Gespräch senden sie dir ein GitHub-Repo mit einer einfachen Next.js "Rekrutierungsaufgabe". Du klonst es, führst es aus... und 10 Minuten später ist dein Gerät vollständig kompromittiert, als du feststellst, dass deine Hot Wallets leergeräumt wurden. Ok, was ist passiert? Angesichts der Tatsache, dass wir (= SEAL 911) diesen Angriff immer wieder gesehen haben, lass mich einige der wichtigsten Details offenlegen:
- Erstens, der wichtigste Hinweis: Führe NICHT zufälligen Code aus, den dir irgendein Typ geschickt hat. Ehrlich, mach das verdammte nicht.
- Überprüfe immer die _ausführbaren_ Konfigurationsdateien der Repos gründlich. In diesem speziellen Fall hatte die `next.config.js`-Datei eine große Polsterung, die die bösartige Nutzlast weit nach rechts versteckte.
- Scrolle immer horizontal - nur weil du beim Blick auf den Inhalt nichts Bösartiges siehst, bedeutet das nicht, dass es sauber ist.
Wichtig: Bösartiger Code kann in Dateien versteckt sein, denen du vertraust, nur nicht dort, wo du es erwartest.
Ich hoffe wirklich, dass dieser Tweet genug Menschen erreicht, um zumindest einige zukünftige Opfer davon abzuhalten, auf diese Art von Angriff hereinzufallen.



34,45K
Top
Ranking
Favoriten
Onchain-Trends
Im Trend auf X
Aktuelle Top-Finanzierungen
Am bemerkenswertesten