• Posted by: Michal Zuberek
• July 24, 2024

What’s your plan B? The short story of an unowned fallback domain.

Some time ago, our system recorded an application installer trying to communicate with fallback-url.com domain. It looks strange to say the least, so we started to check if maybe that vendor owns such a fancy name to maintain their fallback infrastructure. To our surprise, we discovered that the domain is not owned by anyone, so… we bought it.

You can imagine many scenarios of how code using such domain can sneak into production – some sample code copy-pasted from online forums, someone adding it in with a "TODO: put a correct domain later", maybe some AI-generated code snippet. During tests the main domain works, so the fallback path might never be taken. On production systems the fallback part might stay dormant for months, or years until some transient network instability kicks in and code starts to send data to a domain not controlled by you.

What can be affected?

Anything that talks to online resources. It’s not related to any particular programming language. It can affect both servers and clients, depending on where the fallback logic will be executed.

Is it only http?

Our honeypot listens only to http/https requests on standard ports, but any other protocol on any port will have the same problem – when fallback domain is chosen and you don’t control that domain, potentially sensitive traffic will be redirected to whoever controls that domain.

Should I only search for fallback-url.com in my code?

No, that’s the one we found, but there’s a lot of domain names one can come up as a placeholder – fallback.com, serverB.org, put-fallback-server-here.eu… sky is the limit. A quick check shows that many obvious names are still free to buy.
You should check any code that in case of failure will try to communicate with fallback servers. It’s possible that it won’t even be in source code, but in configuration of 3rd party tool, like a load balancer.

What seems to be affected right now?

It’s really hard to tell from our point of view. What we see are http headers, request body and originating IP. So far, apart from lots of web crawlers and automated exploit attempts, we got a bunch of JWT tokens, WebSocket connections, passwords. Some of them seem to come from backend infrastructure, some from customers’ web browsers/mobile applications. Requests usually appear over short periods of time, which would point at some intermittent network problems causing the main domain to be unreachable and triggering the fallback path. We also see one very persistent InnoDB installer that constantly wants to download things from us. Would it execute our payload after download? That we won’t check.

Did you tell affected companies?

In cases where we could identify the owner – yes, we did. So far, we never heard back from any of them. We hope this blog post will reach the right people and trigger source and configuration check for fallback server addresses.

If you want to ensure that software you’re using is not communicating with unexpected servers due to misconfiguration, supply chain, or exploit attack – drop us a line. We can also help your QA to catch such events before you ship your next update to your customers.