Polymarket traders lose ~$2.7M after DebugBear script hijacked via registrar DNS compromise
On October 29, malicious code replaced a page-speed script that Polymarket loaded from DebugBear's real user monitoring (RUM) service. It sold or moved the positions of signed-in traders to an attacker wallet. Polymarket says it is refunding about $2.7 million to 726 affected wallets, and about $2.64 million in POL reached the attacker wallet in under an hour. DebugBear says its DNS records were compromised through its domain registrar, and early findings suggest the attack targeted a single customer. It has seen no sign of a break-in to its own systems, though its investigation continues.
Detalhes técnicos
- Hudson Rock analyzed the malicious file without running it. The code reuses the access a signed-in trader already has in an open Polymarket page and reads account data stored in the browser, including trading API keys. It found no code that exfiltrates keys, passwords, seed phrases or private keys.
- The code locates the site's order-placing component and the account's signer, then asks that signer to sign requests and passes them to Polymarket's relayer. Accounts using their own crypto wallet had positions moved directly to the attacker wallet. Email-login accounts had positions sold at ever-worse prices and the proceeds moved out. Hudson Rock noted that a signing request alone does not prove a trader signed without a prompt, since the wallet provider may still ask, refuse or apply its own session rules.
- Ohey found a different server answering for DebugBear's web addresses at 18:13 UTC, while the malicious file was still online. Earlier that day the normal script had been served from Google Cloud Storage. Each DebugBear customer loads its own copy, and the swapped file was Polymarket's.
- Per Ohey's blockchain trace, the attacker wallet received funds between 17:10 and 18:02 UTC, collecting 28.6 million POL (about $2.64 million at $0.0922) and positions from 33 wallets. It forwarded all the POL to three other addresses between 18:28 and 18:38 UTC.
- Polymarket posted its first status update at 17:38 UTC and put the exchange in cancel-only mode with relayer actions paused at 18:05 UTC. It removed the script, cleared caches, reset all login sessions, paused trading and referred the case to law enforcement.
- By October 30, 689 of the 726 affected wallets had been refunded, with the remaining 37 being paid as they were checked. Polymarket is also paying $1.19 million to about 5,500 wallets that lost money during the trading pause or had positions taken, for $3.9 million returned in total.
Remediação
- DebugBear told RUM customers to remove its embed code. cdn.debugbear[.]com had no DNS record when checked on November 1.
- Polymarket is reintroducing third-party scripts with a stronger Content Security Policy (CSP), pinned versions and sandboxing.
- Hudson Rock advises keeping unneeded third-party code off pages where users trade or sign, and using Subresource Integrity (SRI) where files can be pinned, since a CSP that allows a trusted CDN does not verify the files it serves. It also advises reviewing what code on a signed-in page can ask the signer to do, and telling traders to reject unexpected signing requests.
Linha do tempo
-
Polymarket traders lose ~$2.7M after DebugBear script hijacked via registrar DNS compromise
ler a análise desta fonte ocultar
On October 29, malicious code replaced a page-speed script that Polymarket loaded from DebugBear's real user monitoring (RUM) service. It sold or moved the positions of signed-in traders to an attacker wallet. Polymarket says it is refunding about $2.7 million to 726 affected wallets, and about $2.64 million in POL reached the attacker wallet in under an hour. DebugBear says its DNS records were compromised through its domain registrar, and early findings suggest the attack targeted a single customer. It has seen no sign of a break-in to its own systems, though its investigation continues.
Technical Details
- Hudson Rock analyzed the malicious file without running it. The code reuses the access a signed-in trader already has in an open Polymarket page and reads account data stored in the browser, including trading API keys. It found no code that exfiltrates keys, passwords, seed phrases or private keys.
- The code locates the site's order-placing component and the account's signer, then asks that signer to sign requests and passes them to Polymarket's relayer. Accounts using their own crypto wallet had positions moved directly to the attacker wallet. Email-login accounts had positions sold at ever-worse prices and the proceeds moved out. Hudson Rock noted that a signing request alone does not prove a trader signed without a prompt, since the wallet provider may still ask, refuse or apply its own session rules.
- Ohey found a different server answering for DebugBear's web addresses at 18:13 UTC, while the malicious file was still online. Earlier that day the normal script had been served from Google Cloud Storage. Each DebugBear customer loads its own copy, and the swapped file was Polymarket's.
- Per Ohey's blockchain trace, the attacker wallet received funds between 17:10 and 18:02 UTC, collecting 28.6 million POL (about $2.64 million at $0.0922) and positions from 33 wallets. It forwarded all the POL to three other addresses between 18:28 and 18:38 UTC.
- Polymarket posted its first status update at 17:38 UTC and put the exchange in cancel-only mode with relayer actions paused at 18:05 UTC. It removed the script, cleared caches, reset all login sessions, paused trading and referred the case to law enforcement.
- By October 30, 689 of the 726 affected wallets had been refunded, with the remaining 37 being paid as they were checked. Polymarket is also paying $1.19 million to about 5,500 wallets that lost money during the trading pause or had positions taken, for $3.9 million returned in total.
Remediation
- DebugBear told RUM customers to remove its embed code. cdn.debugbear[.]com had no DNS record when checked on November 1.
- Polymarket is reintroducing third-party scripts with a stronger Content Security Policy (CSP), pinned versions and sandboxing.
- Hudson Rock advises keeping unneeded third-party code off pages where users trade or sign, and using Subresource Integrity (SRI) where files can be pinned, since a CSP that allows a trusted CDN does not verify the files it serves. It also advises reviewing what code on a signed-in page can ask the signer to do, and telling traders to reject unexpected signing requests.