Posted by sibellavia 12/19/2025
In particular, I don't love it when an article attacks a best practice as a cheap gotcha:
"and this time it was super easy! After some basic reversing of the Tapo Android app, I found out that TP-Link have their entire firmware repository in an open S3 bucket. No authentication required. So, you can list and download every version of every firmware they’ve ever released for any device they ever produced"
That is a good thing - don't encourage security through obscurity! The impact of an article like this is as likely to get management to prescribe a ham-handed mandate to lock down firmware as it is to get them to properly upgrade their security practices.
Nobody tell them about Linux!
The blogger will blow a gasket when they discover that the likes of GitHub provides access to both installers and software. A hacker's candy store!
Not a bad blogpost because of this, but you need to be careful reading. I've noticed most of the article on the HN front page are written with AI assistance.
Edit: just want to add, the “how I got the firmware” part of this is also the least interesting part of this particular story.
Here, I'll emphasize the words that elicit the tone:
> After some basic reversing of the Tapo Android app, I found out that TP-Link have their entire firmware repository in an open S3 bucket. No authentication required. So, you can list and download every version of every firmware they’ve ever released for any device they ever produced: [command elided] The entire output is here, for the curious. This provides access to the firmware image of every TP-Link device - routers, cameras, smart plugs, you name it. A reverse engineer’s candy store.
Highlighting (repeatedly) the ease and breadth of access is a basic writing technique to illustrate the weakness of a security system.
Replace [firmware] with [random popular GitHub repo] and nobody would blink. Replace [firmware] with [customer email address] and it would be a legal case. Differentiating here is important.
Furthermore, the repeated use of every when discussing the breadth of access seems like it would easily fall into the "absolutes are absolutely wrong" way of thinking. At least without some careful auditing it seems like another narrative flourish to marvel at this treasure trove (candy store) of firmware images that has been left without adequate protection. But it seems like most here agree that such protection is without merit, so why does it warrant this emphasis? I'm only left with the possible thought that the author considered it significant.
Sure an open bucket is bad, if it's stuff you weren't planning on sharing with the whole world anyway.
But how is an open, read-only S3 bucket worse than a read-only HTTPS site hosting exactly the same data?
The only thing I can see is that it is much easier to make it writeable by accident (for HTTPS web site or API, you need quite some implementation effort).
Only to gullible, clueless types.
Full blown production SPAs are served straight from public access S3 buckets. The only hard requirement is that the S3 bucket enforces read-only access through HTTPS. That's it.
Let's flip it the other way around and make it a thought experiment: what requirement do you think you're fulfilling by enforcing any sort of access restriction?
When you feel compelled to shit on a design trait, the very least you should do is spend a couple of minutes thinking about what problem it solves and what are the constraints.
I'm not shitting on anything except the wording in the article.
I guess I didn't word it clearly.
In our company we don't really serve directly from open buckets but through cloudfront. Though this is more because we are afraid of buckets marked open by mistake so they are generally not allowed. But I agree there's nothing bad about it. I just meant it sounds much worse (at least to someone in cybersec like me) and I don't like the effect used as such in the article.
When in fact TP-Link is doing the right thing with keeping older versions available. So this risks some higher up there thinking 'fuck it, we can't win, might as well close it all off'.
It's a firmware distribution system. It's read-only access to a public storage account designed to provide open access to software deployment packages that the company wishes to broadcast to all products. Of course there is no auth requirement at all. The system is designed to allow everyone in the world to install updates. What compells anyone to believe the system would be designed to prevent public access?
I don't see why. Support for firmware upgrades literally involve querying available packages and downloading the latest ones (i.e., apply upgrades). Either you use something like the S3 interface, or you waste your time implementing a clone of what S3 already supports.
Sometimes simple is good, specially when critics can't even provide any concrete criticism.
What worries me more is security through herd mentality, where everyone copies the same patterns, tooling, and assumptions. When one breaks, they all break. Some obscurity, used deliberately, can raise the bar against casual incompetence and lazy attacks, which, frankly, account for far more incidents than sophisticated adversaries. We should absolutely design systems that are easy to operate safely, but there is a difference between “simple to use” and “safe to run critical infrastructure.” Not every button should be green, and not every role should be interchangeable. If an approach only works when no one understands it, that is bad security. But if it fails because operators cannot grasp basic layered defenses, that is a staffing and governance problem, not a philosophy one.
Isn’t the complaint that the location of the repo is not publicized?
Nobody would complain if it were linked directly from the company’s web page, I assume?
This page[1] lists the C200 as last having a firmware update in October, but also lists the latest version as 1.4.4 while the article lists 1.4.2. It seems like they have pushed other updated in this time, but not these security fixes.
[1]https://community.tp-link.com/us/smart-home/kb/detail/412852
https://www.hydrogen18.com/blog/hacking-zyxel-ip-cameras-pt-...
https://www.hydrogen18.com/blog/hacking-zyxel-ip-cameras-pt-...
Definitely a problem for regular users.
Neither of these seem like good ideas for someone like me, who is relatively hardware naïve and has small children running around making it hard to concetrate for more than 30 minutes at a time.
The question is genuine. I want to do this but don't actually know by which method.
I’m more than happy to ditch the scrappy RTSP setup that I have to support these cheap cameras!
I generally try not to be a huge Rust cheerleader but seriously. Yikes.
I assume any Wi-Fi camera under $150 has basically the same problems. I guess the only way to run a security camera where you don't have Ethernet is to use a non-proprietary Wi-Fi <-> 1000BASE-T adapter. Probably only something homebuilt based on a single board computer and running basically stock Linux/BSD meets that requirement.
The camera sells for $17.99 on their website right now.
Subtract out the cost of the hardware, the box, warehousing, transit to the warehouse, assembly, testing, returns, lost shipments, warranty replacements, support staff, and everything else, then imagine how much is left over for profit. Let's be very optimistic and say $5 per unit.
That $5 per unit profit would mean an additional $100,000 invested in software development would be like taking 20,000 units of this camera and lighting them on fire. Or they could not do that and improve their bottom line numbers by $100,000.
TP-Link has a huge lineup of products and is constantly introducing new things. Multiply that $100,000 across the probably 100+ products on their websites and it becomes tens of millions of dollars per year.
The only way these ultra-cheap products are getting shipped at these prices is by doing the absolute bare minimum of software development. They take a reference design from the chip vendor, have 1 or 2 low wage engineers change things in the reference codebase until it appears to work, then they ship it.
The parent rightly suggested that there is the obvious intention to exploit these devices:
> This is so bad that it must be intentional, right? Even though these are dirt cheap, they couldn't come up with $100,000 to check for run-of-the-mill vulnerabilities?
You explained that there could be an economic reason for the appalling absence of security:
> The only way these ultra-cheap products are getting shipped at these prices is by doing the absolute bare minimum of software development.
But the parent's point is more convincing, based on the observable evidence and the very clear patterns of state-sponsored exploitation.
The vendors could set default passwords to be robust. The vendors could configure defaults to block upstream access. But maybe the vendors in this particular supply chain are more like the purveyors of shovels in a Gold Rush.
A less-charitable metaphor is possible where state-sponsored motives are unambiguously known.
For the tech savvy, there is thingino as a firmware alternative - works local only, no cloud, and supports mqtt etc.
ftfy
How does this happen? Doesn’t pretty much every ISP give a router with their modem? How do people manage this?
In IPv6 they likely will auto configure onto a public ip address which may not have a stateful firewall.
PSA: Don't connect any TV used a dumb monitor to the internet. This is like connecting your toaster to the internet and begging for trouble.