RT @dobsec: "Nicio persoană obișnuită nu folosește un VPN" arată că în mod clar nu a văzut miliardul de creatori care vând VPN-uri în fiecare videoclip.

BlockThreat - Săptămâna 28, 2025 💙 Sponsorizat de @SecurityOak 🔥 Exploatarea în masă a contractelor proxy descoperite de @deeberiroz și pălărie albă de @pcaversaccio @dedaub și @_SEAL_Org 💸 @GMX_IO hack de reintrare 42 de milioane de dolari (37 de milioane de dolari recuperați) 💸 @KintoXYZ proxy neinițializat. 1,55 milioane USD

Lecții pentru experții în securitate: Auditați proxy-ul riguros. Monitorizați lanțurile delegatecall (ușor de făcut în aplicația noastră) și asigurați integritatea stocării cu modele complexe de proxy. Recuzita merge la @deeberiroz @VennBuild @pcaversaccio @_SEAL_Org Rămâneți vigilenți.

așa că am aflat că este și mai elegant. Am observat că tx (de către atacatori) numește 'initialize' și protocoalele apelează și _successfully_ 'initialize' after (astfel ei cred că totul este normal). Dar stai, cum este posibil acest lucru? A trebuit să mă uit foarte adânc în modificările slotului de stocare și să ghicesc ce am găsit: au resetat valoarea slotului de stocare "_initialized" la sfârșitul tx-ului de rulare frontală (după ce au trecut la contractul de implementare rău intenționat). Aceasta înseamnă că stocarea proxy arată acum ca și cum nu a fost niciodată inițializată. Slotul de stocare relevant de analizat este 'keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))' = '0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00' Acesta este răul de nivel următor.

La începutul acestei săptămâni, a fost identificată o potențială vulnerabilitate în contractul de manager cross-chain al Orderly pe lanțul BNB. Ca răspuns, seiful nostru BNB pentru depuneri și retrageri a fost imediat întrerupt, contractele au fost migrate și depozitele/retragerile au fost reluate în 2 ore. ✅ Niciun fond al utilizatorilor nu este în pericol sau nu a fost pierdut. Mulțumiri speciale @deeberiroz, @VennBuild, @seal_911, @pcaversaccio și restului echipei care au ajutat la semnalarea acestui lucru! Mai siguri împreună 🤝

[5/5] Apel nominal de recunoștință • @SlowMist_Team pentru triaj non-stop și patch-uri • @dedaub, @pcaversaccio și camera de război @seal_911 pentru o măturare a codului de 36 de ore • @etherscan pentru curățarea rapidă a interfeței de utilizare • Și din nou, mulțumesc @deeberiroz, @VennBuild, @davidberiro – atenția ta a salvat ziua 💙

Devine și mai fantezist: modul în care Etherscan a fost păcălit arătând contractul de implementare greșit se bazează pe setarea a 2 sloturi proxy diferite în același top tx. Deci, Etherscan folosește o anumită euristică care încorporează diferite sloturi de stocare pentru a prelua contractul de implementare. Există un proxy vechi de la OpenZeppelin care folosea următorul slot: 'keccak256("org.zeppelinos.proxy.implementation")' = '0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3' Acum avem și slotul standard EIP-1967 'bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)' = '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc' Deci ceea ce s-a întâmplat este că vechiul slot proxy OpenZeppelin a fost scris cu adresa de implementare benignă _și_ slotul standard EIP-1967 a fost scris și el cu adresa de implementare rău intenționată. Deoarece Etherscan interoghează mai întâi vechiul slot proxy, l-a recuperat mai întâi pe cel cu aspect benign și astfel l-a afișat.

RT @devops199fan: .@seal_911 servește practic ca centru voluntar de operațiuni de securitate globală (GSOC) al criptomonedelor Suntem norocoși să avem oameni care...

Dar adevărata amenințare pentru Ethereum nu este statul de fapt (cel puțin nu astăzi). Sunt VC-urile și carieriștii de protocol care încearcă să-l neutralizeze într-un teren de joacă fintech strălucitor pentru DeFi "sigur" și conform. Ascultați-mă: nu vor cod de neoprit. Nu vor rezistență. Vor al naibii de _control_. Pentru că, în adâncul sufletului, ei știu ce ar putea deveni Ethereum dacă este lăsat neînlănțuit: un strat de execuție globală rezistent la cenzură, care pune confidențialitatea pe primul loc, pe care niciun stat, nicio corporație, niciun cartel de costume nu l-ar putea opri vreodată. Să facem acest lucru o realitate.

Așa că cineva te contactează pe LinkedIn cu o oportunitate de muncă promițătoare. Sună frumos, nu-i așa? Par legitime (după ce le-am verificat timp de 1 minut) și după o scurtă conversație vă trimit un depozit GitHub cu o simplă Next.js "sarcină de recrutare". Îl clonezi, îl rulezi... Și 10 minute mai târziu, dispozitivul tău este complet compromis când afli că portofelele fierbinți au fost golite. Ok, ce s-a întâmplat? Având în vedere faptul că noi (= SEAL 911) am văzut acest atac din nou și din nou, permiteți-mi să dezvălui câteva dintre cele mai importante detalii: - în primul rând, cel mai important avertisment: NU rulați cod aleatoriu pe care ți-a trimis-o un tip aleatoriu. Sincer, al naibii nu. - verificați întotdeauna cu atenție fișierele de configurare _executabile_ ale depozitelor. În acest caz particular, fișierul "next.config.js" avea o umplutură mare care ascundea sarcina utilă rău intenționată departe în dreapta. - Derulați întotdeauna pe orizontală - doar pentru că nu vedeți nimic rău intenționat când vă uitați la conținut nu înseamnă că este curat. Important: codul rău intenționat poate fi ascuns în fișierele în care aveți încredere, dar nu acolo unde vă așteptați. Sper cu adevărat că acest tweet va ajunge la suficienți oameni pentru a preveni cel puțin câteva viitoare victime să cadă în capcana acestui tip de atac.