Exploiting zero days in abandoned hardware
24 comments
·July 25, 2025myself248
sidewndr46
I find the EOL aspect of this discussion out of place. These devices shipped like this. They didn't gain these vulnerabilities due to aging or something like that.
You can have a device that is 100% supported by everyone from the chip vendor, board assembler, and an OEM that is still trivially vulnerable.
Hilift
It's probably relevant due to companies usually dump EOL hardware, and some of it gets a new life in a non-business environment. But if it needs a firmware update for a security vulnerability you're out of luck. There is legitimate commercial market for used EOL hardware as parts for people that keep old hardware a bit longer, but that's probably short term until it can be replaced.
bee_rider
There really ought to be an “open source your drivers or offer a refund” law for companies that want to EOL devices. It isn’t the 90’s anymore, hardware innovation has really slowed, a chip could be good for decades.
Zigurd
I bought a TV on deep discount. The Android TV OS was already trailing-edge and soon went unsupported. Being just a little paranoid, I monitored the network for continued activity after I removed the network configuration from the built-in software, which I replaced with an external device that's fully supported. I doubt many of the other customers for this cheap TV are as vigilant.
sidewndr46
But no one should be buying or using these devices when they are brand new. Why would I care about them when used?
swinglock
My thought too. They are not insecure because they won't be patched, they are just insecure. Even if patched, what's to say there are not 99 other vulnerabilities lurking, even in their supported products?
sidewndr46
I seem to remember at least one case where a manufacturer attempted to patch an issue like this and managed to actually introduce another one in its place.
yjftsjthsd-h
If it's supported, then as soon as somebody finds a vulnerability (and notifies the vendor) it should get fixed.
sidewndr46
Why would I care if I have already been compromised? It's like I was murdered and the prosecutor leaves a "got em!" note on my grave after a conviction. I don't think I'm going to care very much.
tonyhart7
or they sell them to blackmarket as 0 day exploit
nickpsecurity
The differences are vulnerability disclosure, vulnerability class, and patch availability. The device is most-vulnerable between the moment common hackers know how to exploit it and when a patch (or mitigation) for that vulnerability is applied.
Older hardware has had longer for vulnerabilities to be found. Some might not mitigate new classes of vulnerabilities. The EOL hardware will not receive patches for any vulnerabilities. So, they're at higher risk of attack.
From there, the attack will be either malicious input to that machine over the network or a file that embeds an attack. Many problems can be mitigated by running secure software, esp for input validation, on that hardware. One might also use them offline or on trusted networks with software that's hand-chosen for them. (That's what I do.)
ge96
I'm wondering if not upgrading from Win 10 to Win 11 will be considered EOL
I have a powerful gaming desktop but says not eligible to upgrade to win 11
mbs159
You can upgrade to Windows 11 LTSC Enterprise IoT - it has leaner hardware requirements, but also less bloatware
iszomer
This was my baseline 20 or so years ago starting from the WRT54G. Now, it's just a bullet point in the miscellaneous section of my cv.
dguido
In case anyone is looking for them, here are the exploits for these EOL devices. I avoided allowing Trail of Bits to release exploits for 13 years, but I decided it was finally time for a policy change. We'll be dropping a lot more as time goes on now.
Here's the exploit for the Netgear WGR614v9: https://github.com/trailofbits/exploits/tree/main/junkyard-2...
Here's the exploit for the BitDefender Box 1: https://github.com/trailofbits/exploits/tree/main/junkyard-2...
There's a lot of included detail so you can learn how to write your own and really understand every decision we made in writing them.
bornfreddy
I have mixed feelings about the message "no updates -> vulnerable". The vulnerabilities have been in these devices all along. Some techniques for uncovering them got better over time, but I would guess not substantially. So why should abandoned hardware be any riskier than a brand new router, whose vulnerabilities haven't yet been discovered?
If they support OpenWRT or similar, fair enough - maturity does bring some additional safety. But in general this is not the case. Or am I missing something?
ectospheno
This is why my routers are dell computers with an intel quad port nic and openbsd installed. Dell gives bios updates far past most other vendors, intel nics just work, and openbsd is trivial to upgrade and gets updates.
jgalt212
Is Android TV OS planned obsolescence for Sony (et al) TVs?
nickpsecurity
I do want to note about the secure, update claim that there is a tension between providing systems that can't receive false updates and giving users control of their hardware. Solutions for the former often prevent the latter.
An alternative would be to have the firmware show a description of the signed content, like version information, that the user must OK. It might show it along with the current version with a warning if versions are downgrading or the whole thing is changing. The warning might tell you to be sure of the source of this update. If it's the same software, and another version, it might be set to automatically update.
If it's the lowest-level, unrecoverable firmware, I like it being hard for attackers to change it. One idea I used to push was putting that in EEPROM with a jumper (or switch) required to update it. The software will have already performed numerous checks from the kernel state to the payload with external inputs (eg networking) shut down. If malicious, it can't do anything without that physical interaction.
The regular, update mechanism which uses other storage is in that EEPROM. It has highly, security-enhanced mechanisms for updates. It might even have it's own partition if it's a microkernel-based system. So, we have one that's hard to attack with software while the other takes physical attack or social engineering. Also, I think a Chromebook or something implemented a ROM/flash combo.
variadix
I feel like there are better ways to make it hard to push malicious updates, while still allowing a user to flash their own devices.
For example: manufacturer bakes in their public key and a per device public/private key pair. The bootloader checks firmware updates against the manufacturers public key and the per device public key. The per device private key is only readable with hardware access via serial or USB etc. The user can extract their device’s private key to be able to sign their own firmware updates. Additionally, the bootloader could support adding new public keys to verify firmware with, so long as the payload to add the new public key was signed by the per device key. This would simplify getting updates from e.g. OpenWRT if they have their own key pair they sign with, vs requiring each user to sign each firmware update with their personal key.
> If you have an EOL device, it may not be necessary to throw it away, but you should consider the risks of continuing to use it. For consumers, this necessitates careful consideration not just of a device’s features but its entire security lifecycle, including manufacturer support commitments and community firmware options.
Which I read as "Don't buy it in the first place, if it's not already supported by OpenWRT."
Simple enough.