[HN Gopher] Exploiting zero days in abandoned hardware
___________________________________________________________________
Exploiting zero days in abandoned hardware
Author : ingve
Score : 102 points
Date : 2025-07-25 12:38 UTC (4 days ago)
(HTM) web link (blog.trailofbits.com)
(TXT) w3m dump (blog.trailofbits.com)
| myself248 wrote:
| > 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.
| iszomer wrote:
| 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.
| sidewndr46 wrote:
| 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.
| yjftsjthsd-h wrote:
| If it's supported, then as soon as somebody finds a
| vulnerability (and notifies the vendor) it should get fixed.
| tonyhart7 wrote:
| or they sell them to blackmarket as 0 day exploit
| sidewndr46 wrote:
| 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.
| kej wrote:
| It would matter quite a bit to the next person on the
| murderer's hit list, just like it matters to people whose
| devices haven't been compromised yet.
| swinglock wrote:
| 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 wrote:
| 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.
| Hilift wrote:
| 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.
| sidewndr46 wrote:
| But no one should be buying or using these devices when
| they are brand new. Why would I care about them when used?
| Zigurd wrote:
| 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.
| bee_rider wrote:
| 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.
| nickpsecurity wrote:
| 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 wrote:
| 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
| gnopgnip wrote:
| After Oct 14, yes. You won't receive security patches
| ge96 wrote:
| sucks gotta dump the box, excuse to get an SFF I guess
| mbs159 wrote:
| You can upgrade to Windows 11 LTSC Enterprise IoT - it has
| leaner hardware requirements, but also less bloatware
| nickpsecurity wrote:
| 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 wrote:
| 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.
| bornfreddy wrote:
| 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 wrote:
| 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 wrote:
| Is Android TV OS planned obsolescence for Sony (et al) TVs?
| dguido wrote:
| 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.
___________________________________________________________________
(page generated 2025-07-29 23:01 UTC)