Polymarket hack transferon 2,64 milionë dollarë përmes një script-i të rrëmbyer
Polymarket hack i 29 tetorit përdori JavaScript keqdashës, të ngarkuar nga faqja e internetit e tregut të parashikimeve, për të shitur pozicionet e disa tregtarëve që kishin hyrë në llogari dhe për t’i transferuar fondet në një wallet nën kontrollin e sulmuesit. Kodi zëvendësoi një script monitorimi të performancës nga një palë e tretë, të ofruar nga DebugBear. Polymarket thotë se po rimburson rreth 2,7 milionë dollarë për 726 wallet-e të prekura, ndërsa të dhënat e blockchain të shqyrtuara nga studiuesit tregojnë se afërsisht 2,64 milionë dollarë në kriptomonedha arritën në wallet-in e sulmuesve në më pak se një orë.
Skedari legjitim i përkiste shërbimit real user monitoring (RUM) të DebugBear, i cili mat performancën e ngarkimit të faqeve për vizitorët realë. DebugBear tha se records e tij të Domain Name System (DNS), të cilat drejtojnë trafikun e internetit te destinacioni i saktë online, u komprometuan përmes regjistruesit të domain-it të kompanisë. Gjetjet fillestare të kompanisë sugjerojnë se objektivi ishte faqja e internetit e një klienti. Ajo nuk kishte gjetur prova se sistemet e veta ishin shkelur, megjithëse hetimi vazhdonte.
Studiuesit e Hudson Rock e shkarkuan skedarin keqdashës më 29 tetor nga adresa që Polymarket përdorte për script-in e DebugBear. Ata identifikuan gjithashtu një ndryshim të mëvonshëm në kodin e faqes së Polymarket që e hoqi integrimin. Studiuesit e Ohey zbuluan se një server tjetër po përgjigjej për adresat e internetit të DebugBear në orën 18:13 UTC, ndërkohë që skedari armiqësor vazhdonte të ishte i disponueshëm. Më herët po atë ditë, script-i normal ishte ofruar nga Google Cloud Storage. DebugBear i jep secilit klient një kopje të veçantë të skedarit të monitorimit dhe kopja e zëvendësuar ishte ajo që ngarkohej nga Polymarket.
Hudson Rock e analizoi skedarin pa e ekzekutuar dhe zbuloi se ai ripërdorte lejet që ishin tashmë të disponueshme brenda një faqeje të hapur dhe të autentikuar të Polymarket. Ai lexonte informacionin e llogarisë të ruajtur në browser, përfshirë API keys për tregtim, të cilat janë kredenciale që software-i përdor për të komunikuar me një shërbim online. Këto API keys nuk mjaftonin për të dërguar një urdhër, sepse Polymarket kërkonte gjithashtu një wallet signature, miratimin kriptografik të një llogarie për një transaksion.
Studiuesit nuk gjetën kod që transmetonte API keys, një fjalëkalim, një seed phrase ose një private key te serveri në distancë me të cilin lidhej script-i. Në vend të kësaj, kodi keqdashës kërkonte në faqe funksionet e Polymarket për vendosjen e urdhrave dhe signer-in përgjegjës për miratimin e transaksioneve të llogarisë. Kjo do të thoshte se Polymarket hack përpiqej të përdorte procesin ekzistues dhe të besuar të transaksioneve të faqes, në vend që të nxirrte kredencialet më të ndjeshme të wallet-it të tregtarit.
Script-i ndiqte rrugë të ndryshme në varësi të mënyrës se si tregtari kishte hyrë në llogari. Për personat që përdornin wallet-et e tyre kripto, ai përpiqej t’i transferonte pozicionet e tregtimit drejtpërdrejt te wallet-i i sulmuesve. Për llogaritë e bazuara në email, ai i shiste pozicionet me çmime gjithnjë e më të pafavorshme përpara se të transferonte fondet e përftuara. Në të dyja rastet, kodi i kërkonte signer-it të vetë llogarisë të miratonte udhëzimet e tij dhe ia kalonte ato relayer-it të Polymarket, një shërbim që dërgon transaksionet e nënshkruara.
Hudson Rock paralajmëroi se një kërkesë e dërguar te një signer nuk provon se një transaksion u përfundua pa i shfaqur tregtarit një kërkesë miratimi. Një ofrues wallet-i mund të shfaqte ende një paralajmërim, ta refuzonte kërkesën ose të zbatonte rregulla të tjera të sesionit. Mësimi praktik për tregtarët është se kërkesat e papritura për transaksione mund të jenë të rrezikshme edhe kur shfaqen brenda një faqeje ku përdoruesi ka hyrë tashmë në llogari.
Gjurmimi i blockchain nga Ohey zbuloi se wallet-i i përfshirë në kodin keqdashës mori fondet e para në orën 17:10 UTC dhe të fundit në orën 18:02 UTC. Gjatë kësaj periudhe, ai grumbulloi 28,6 milionë token-a POL dhe pozicione tregtimi nga 33 wallet-e. DefiPrime llogariti se vetëm POL vlente rreth 2,64 milionë dollarë në orën 18:19 UTC, duke përdorur çmimin prej 0,0922 dollarësh të DefiLlama. Ky vlerësim nuk përfshinte pozicionet e transferuara. Të dhënat e transaksioneve tregojnë se të gjithë 28,6 milionë token-at POL u dërguan më pas në tri adresa të tjera midis orës 18:28 dhe 18:38 UTC.
Polymarket publikoi përditësimin e parë të statusit për aktivitetin e paautorizuar të wallet-eve në orën 17:38 UTC. Në orën 18:05 UTC, platforma e kaloi bursën në cancel-only mode, duke lejuar anulimin e urdhrave ekzistues ndërsa ndalonte tregtimin normal, dhe pezulloi veprimet e relayer. Kompania tha se e hoqi script-in e prekur brenda një ore, pastroi cache-et, përfundoi çdo sesion aktiv hyrjeje dhe pezulloi tregtimin ndërsa kontrollonte që faqja të ishte e pastër. Ajo ia ka referuar incidentin organeve të zbatimit të ligjit.
Deri më 30 tetor, Polymarket tha se 689 nga 726 wallet-et e prekura kishin marrë rimbursime të plota. Pagesat për 37 wallet-et e mbetura po përpunoheshin ndërsa rastet e tyre kontrolloheshin. Kompania po paguan veçmas 1,19 milionë dollarë për rreth 5.500 wallet-e që humbën para gjatë ndërprerjes së tregtimit ose të cilave iu morën pozicionet, duke e çuar shumën totale që planifikon t’u kthejë tregtarëve në 3,9 milionë dollarë. Përdoruesit nuk kanë nevojë të paraqesin kërkesa, megjithëse faqja e statusit ofron një formular për këdo që beson se një pagesë mungon ose është e pasaktë.
DebugBear i këshilloi klientët e RUM të hiqnin kodin e tij të integrimit nga faqet e tyre. Kur The Hacker News kontrolloi më 1 nëntor, cdn.debugbear.com nuk kishte më një DNS record. Polymarket tha se do t’i rikthente script-et e palëve të treta me kontrolle shtesë, përfshirë versione të fiksuara, sandboxing dhe një Content Security Policy (CSP) më të fortë, e cila kufizon burimet e jashtme që një browser lejohet të ngarkojë ose ekzekutojë.
Hudson Rock rekomandon që kodi i jashtëm i panevojshëm të mbahet larg faqeve ku përdoruesit tregtojnë ose miratojnë transaksione. Kur një skedar mund të fiksohet në një version të njohur, faqet mund të përdorin Subresource Integrity (SRI), një kontroll i browser-it që e refuzon skedarin kur përmbajtja e tij nuk përputhet më me vlerën e pritshme. Vetëm lejimi i një adrese të besuar për shpërndarjen e përmbajtjes përmes një politike sigurie nuk verifikon çdo skedar që ofrohet nga ajo adresë. Operatorët e faqeve duhet të shqyrtojnë gjithashtu se çfarë mund t’i kërkojë një signer-i transaksionesh të miratojë kodi që ekzekutohet në një faqe të autentikuar.
Ky incident thekson gjithashtu rëndësinë e të kuptuarit se ku qëndron besimi te DNS brenda supply chain të një faqeje interneti; AEU DNS ofron DNS privat dhe të sigurt për të gjithë, megjithëse komprometimi i raportuar këtu përfshinte records të menaxhuara nga regjistruesi, të përdorura nga një ofrues i jashtëm script-esh. Për pronarët e faqeve, çështja kryesore është se kodi i ngarkuar nga një domain tjetër mund të trashëgojë qasje në një faqe të ndjeshme ku përdoruesi ka hyrë në llogari, duke e bërë heqjen e script-eve, kontrollet e rrepta të browser-it dhe miratimin e kujdesshëm të transaksioneve pjesë të rëndësishme të kufizimit të ekspozimit.