DebugBear's DNS was hijacked, and its monitoring script served malicious code

A performance monitoring script sits on every page a site owner lets it onto. On 29 October, Search Engine Journal reports, attackers took over DebugBear's DNS records at its domain registrar. They used them to serve malicious JavaScript from the company's Real User Monitoring script.

DebugBear's own statement is quoted by SEJ. The DNS records were compromised through the registrar. The attackers targeted "the website of a specific customer" rather than DebugBear itself. The company has "not seen any indication of a compromise of our internal systems". Email to the DebugBear domain was unreachable during the window.

What a site owner should do

The RUM product is a one-line embed. Site owners paste it into templates, plugins and tag managers. SEJ writes that affected site owners should remove the embed code at once. That comes before anything else in the clean-up.

Then they should reset passwords and invalidate sessions. Start with administrator accounts. A script running on every pageview can read any cookie that is not marked HttpOnly.

SEJ writes to check for unauthorised changes to accounts, permissions and files. Search server and application logs for suspicious activity in the window. Reverse any malicious changes. A compromised site can be put in maintenance mode with HTTP 503 responses while this is done.

The window of exposure

SEJ reports that DebugBear's first update on LinkedIn was on 29 October, with follow-ups the next day. DebugBear has not published a tagged incident write-up at the time of this item. The exact start time of the malicious serving is not public.

The practical consequence is that a site owner cannot narrow the clean-up to a known window. Every session active during the whole known period has to be treated as exposed.

The subcontractor problem again

A third-party script is a subcontractor the site owner cannot audit. The site owner trusts the vendor's DNS, the vendor's TLS, the vendor's build pipeline and the vendor's domain registrar. Any one failure in that chain drops arbitrary code onto every page that embeds the script.

The DebugBear case is the registrar link breaking. The script's own operator was the first to lose control of what it served.

A team that embeds any third-party tag has three choices. Audit the vendor's full chain. Use Subresource Integrity, so a changed script fails to execute rather than running with new contents. Self-host the vendor's code, so a vendor-side compromise cannot change what the page loads. SRI is cheap. It breaks silently on a legitimate vendor update. It would have stopped this one at the browser.

Source

Hackers Hijacked DebugBear's DNS To Serve Malicious JavaScript, Search Engine Journal.