The address your kit still phones home to may belong to someone else now
Somewhere in your office, or a client's, there is probably a box or a config file that phones home to an address nobody has thought about in years. A NAS in the corner registering itself with its manufacturer. A web server proxying analytics traffic to a vendor. This week, two disclosures from the same researcher showed what happens when the address at the other end quietly changes hands: the traffic keeps flowing, and whoever now holds the address receives it.
No hacking was involved. That is the unsettling part.
What the researcher found
Cloud providers recycle public IP addresses. When a company releases an address, the provider hands it to the next customer who asks. If DNS records or cached lookups still point at the old address, traffic meant for the company arrives at the stranger who now holds it. The researcher, posting to the Full Disclosure mailing list as shed riot, rented recently released addresses and simply listened.
The Synology disclosure covered network-attached storage, the backup boxes found in thousands of small offices. Over two weeks in July, four addresses that Synology's infrastructure had given back received 28 requests from 23 distinct customer devices. The boxes sent authentication tokens, serial numbers, internal network addresses, management ports, and session cookies. Some sent it in plain, unencrypted form. The rest connected over HTTPS but accepted the researcher's self-signed certificate, meaning the devices never checked they were really talking to Synology.
Every device caught was running old software, pre-dating a fix Synology shipped in DSM 6.2.3-25426 Update 3. That fix closed a set of 2021 vulnerabilities which needed the attacker to sit between the device and Synology. The point of the new finding is that the stale DNS condition hands an attacker that position for the price of a cloud instance. No interception skills required. The address does the work.
The Amplitude disclosure, published a day earlier, showed the same condition in a very different place. Amplitude is a product-analytics service; websites send it data about what users do. Amplitude's documentation recommends customers route that traffic through their own domain via a proxy, and its example configuration did not switch on certificate checking for the onward connection. So when Amplitude's released cloud addresses came back into circulation, customer proxies happily forwarded live analytics data, including persistent device identifiers and session identifiers, to whoever held the address, without noticing anything wrong.
Both vendors were told. Synology classified the report as a "hardening suggestion", then quietly adjusted its infrastructure configuration. Amplitude's bug bounty programme closed the report as "Not applicable" after acknowledging the traffic had passed through customer proxies that did not validate certificates. Neither response changes what the captures showed: real customer data, delivered to an address the vendor no longer controlled.
Why this matters to a UK small business
Three reasons this is more than a curiosity.
The Synology boxes at risk are exactly the ones nobody maintains. The captured devices ran software from as far back as 2014. Several models, including the DS210j, DS710+, and DS1010+, cannot install the fixed version at all. A NAS that has quietly done backups for a decade is a fixture, not a computer, in most offices. It holds a copy of everything the business cares about, and it may be announcing its internal addresses, ports, and tokens to a stranger.
Nobody would ever notice. Passive collection leaves no trace. The device works normally. The researcher notes it is unknown how long the condition existed, or whether anyone less friendly got there first. Absence of an incident report means nothing here.
The pattern is bigger than these two vendors. Any appliance that phones home, and any proxy, load balancer, or CDN configuration that forwards traffic without validating the certificate of the thing it forwards to, has the same exposure. The researcher points out that certificate-validation gaps exist in default configurations for several common cloud load balancers and WAFs. Copy-pasted vendor example configs have a long life.
What to check
If you have a Synology NAS, find out what version of DSM it runs. Settings, then Update and Restore, or ask whoever looks after it. Anything older than DSM 6.2.3-25426 Update 3 should be updated today to the newest version available for the model. If the model cannot run that version, treat it as end of life: disable QuickConnect and Synology's relay services at minimum, and plan its replacement. A backup box that leaks tokens and network maps is not a safe place for your only copy of anything.
If your website or product uses an analytics or third-party proxy, ask one question of whoever set it up: does the onward connection validate the upstream certificate? In NGINX terms, is proxy_ssl_verify on? If the config came from a vendor's documentation, assume the answer is no until confirmed. This applies to any proxied vendor, not just Amplitude.
More generally, list what phones home. NAS boxes, printers, door systems, CCTV recorders, anything with a cloud feature. Old kit that registers itself with a manufacturer over the internet carries this class of risk for as long as it is powered on, and turning the cloud features off is often free.
How Steelwise can help
Working out which of your devices and configs are quietly talking to the internet, and whether any of them would notice an impostor at the other end, is the kind of review we do. Get in touch.