I'm a little frustrated with articles like this that scattershot their critique by conflating genuine failures with problems that even FAANGs struggle with.
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.
Doesn't matter really, keeping blobs hidden doesn't actually do anything except make it slightly harder to analyze the software. Making all blobs easily and readily available is exactly what I want the vendor to do. Black boxes don't make things secure.
This blog post is pretty readable, but it's still obviously written with the help of an LLM.
A common trend is that LLMs lack the nuance and write everything with the same enthusiasm. So in a blogpost it'll infer things are novel or good/bad that are actually neutral.
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.
I think maybe you’re reading this wrong. Reverse-engineering blog posts like this are just a fun and instructive way of telling the story of how someone did a thing. Having written and read a bunch of these in the past myself, I found this one to be a great read!
Edit: just want to add, the “how I got the firmware” part of this is also the least interesting part of this particular story.
Yes, heavily, because of the use of adjectives and repeating the points.
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.
To me the phrasing seems objective. Making your binaries available to the public is good (though source would be better).
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.
I think it fails to be objective because of the repetition. It's an open S3 bucket. No need to state that no authentication was required, it's already open. It's not about economy of writing but the repetition emphasizes the point, elevating the perceived significance to the author or that the author wants the reader to take away.
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.
An 'open S3 bucket' sounds really bad. If it were posted on an HTTPS site without authentication, like the firmware for most devices, it wouldn't sound so bad.
Sure an open bucket is bad, if it's stuff you weren't planning on sharing with the whole world anyway.
Since firmware is supposed to be accessible to users worldwide, making it easier to get it is good.
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).
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.
No I agree with you. I think it is bad framing as "S3 open bucket" when people would totally understand an open website :)
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.
No, it clearly has a gloating tone to it. 'A reverse engineer's candy store' is clearly meant as a slur.
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'.
I just meant that it was very convenient to have the firmware images there on S3, nothing else :D Many vendors make the process of even just obtaining a copy of the firmware much harder than that, so for once I was glad it has been much easier. Also being able to bindiff two adjacent versions of the same firmware is great ... all in all I was just expressing my happiness :D
> Highlighting (repeatedly) the ease and breadth of access is a basic writing technique to illustrate the weakness of a security system.
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?
> Maybe listing shouldn't be enabled even if all the files are public.
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.
It's not a necessary interface. Do the clients actually use S3 listing to determine what the latest firmware is? Personally I would put a service in the middle that takes in the model number, region, etc and then returned the most recent firmware URL. There's no reason to have historical versions be easily listable by curious people.
Why not? The firmware was already public at one point. If people are analyzing your app to find an S3 bucket full of firmware, I'd assume they'd have a pretty good reason to go through the effort.
Or to illustrate the convenience to the point of the article, being reverse engineering; not necessarily to critique their security practices here. Being easy to reverse engineer is not necessarily a weakness of security (as the inverse would simply be obscurity).
I think this kind of critique often leans too hard on “security through obscurity” as a cheap punchline, without acknowledging that real systems are layered, pragmatic, and operated by humans with varying skill levels. An open firmware repository, by itself, is not a failure. In many cases it is the opposite: transparency that allows scrutiny, reproducibility, and faster remediation. The real risk is not that attackers can see firmware, but that defenders assume secrecy is doing work that proper controls should be doing anyway.
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.
I’m beginning to think maybe I’m the only one that read this whole thing. The firmware storage isn’t the security through obscurity problem being talked about here. The hardcoded TLS private key definitely is though. And yes, it deserves shaming… terrible practice leads to terrible outcomes. Nobody is surprised that this is coming from tp-link at this point though.
This is exactly why network segmentation is critical for IoT devices. I always recommend putting all smart cameras and IoT devices on a separate VLAN with no direct internet access - only local network access through a firewall with strict egress rules.
For anyone concerned about their TP-Link cameras, consider:
1. Disable UPnP on your router
2. Use VLANs to isolate IoT devices
3. Block all outbound traffic except specific required endpoints
4. Consider replacing stock firmware with open alternatives when available
5. Regularly check for firmware updates (though as this article shows, updates can be slow)
The hardcoded keys issue is particularly troubling because it means these vulnerabilities persist across the entire product line. Thanks for the detailed writeup - this kind of research is invaluable for the security community.
A friend once asked me to do some pen-testing on a machine he was running on his home network. He said I'd need to come round to his house to do this as he didn't want to provide access to the machine via the Internet. Fair enough.
When he opened his front door the conversation went something like this:
Him: "Ah hello, thanks for coming round to do this. It should be fun, come in and we can get started."
Me: "OK, but I'm already done."
Him: "What?"
Me: "I'm done. I've already got root on the machine and I left a little text file in root's home directory as proof."
Him: "What? But ... what? Wifi?"
Me: "Nope. Let me in and I'll explain how."
The short story is he had an PoE IP-based intercom system on his front gate. I remembered this from when he was going on about his plans for his home network setup and how amazing PoE was and how he was going to have several cameras etc. I also remember seeing the purple network cable sticking out of the gate pillar whilst the renovation work was being done and the intercom hadn't yet been installed.
I'd arrived 45 minutes early, unscrewed the faceplate of the intercom system and, with a bit of wiggling, I got access to a lovely Cat-5 ethernet jack. Plugging that into my laptop I was able to see his entire home network, the port for the intercom was obviously not on its own VLAN. Finding and rooting the target machine was a different matter but those details are not relevant to this story.
I suppose I got lucky. He could have put the IoT devices on separate VLANs. He could have had some alerting setup so that he'd be notified that the intercom system had suddenly gone offline. He could have limited access to the important internal machines to a known subset of IPs/ports/networks.
He learned about all of the above mitigations that day.
I've always wondered just how many people have exposed their own internal network in a similar way when trying to improve their external security (well, deterrent, not really security) but configuring it poorly.
Now we need to get an enterprise grade switch - doubt Cisco would add macsec into SOHO gear. Along with enterprise grade intercoms, cameras, doorbells...
And beloved by many Unifi is out of question - they still can't bake IPv6 support.
So looks like it's feasible but the cost wouldn't be good.
i well familiar with macsec. we use it between datacenters and for aws directlink. it de-facto standard for this kind of stuff. i even worked on hardware that provided macsec support
a couple of years ago I tried to use it inside datacenter during fedramp implementation. it crashed and burned for a couple of reasons:
- linux wpa_supplicant was crashing during session establishment
- switch had a limit on number of macsec session per port
I have my cameras connected to a N150 server running hostapd and dnsmasq and no IP forwarding. That server runs Frigate. I figured if I need a server anyway it might as well be the AP.
It's a little bit of a pain to set up the cameras because of the mobile app. I have to connect to the AP on my phone and as it doesn't have internet access my phone nags me, and this specific model doesn't have an external antenna. If it did I think it might be the ideal setup.
do you happen to have a guide on how to achieve this - I am fairly technical but still configuring Vlans and moving devices there would be good with some step by step instructions.
P. Sure the camera in question breaks in fun ways. From my observations because it can’t update it’s time, so messing with it a bit leaving to a need to update, downgrade, block from the web again.
depends on your router, but you would want to stick to onvif or rtsp and connect to the camera using some sort of tailscale. Don't fail for installing open source firmware, there is only thingino and openipc, both are hard to install if you are a beginner, even if people say it's easy for technical specialist, it's not
They're also limited to older hardware, newer 3K+ cameras aren't supporter. Different chip in use, I guess, or there manufacturers have learned to sign this firmware and burn in the keys.
It's probably fair to assume that most of their other camera models are affected by the same or similar issues. It looks like they pump out quite a few models that I image have similar firmware.
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.
I looked at some older Zyxel products and came to the same conclusion a while back. There's a whole industry of labeling generic hardware as being part of someone's else ecosystem
it's a stretch to call it generic hardware, all of cheap cameras use similar hardware, but every few months there is a new version of chip which you need to adjust to. It's challenging to find an exact chip if you want to, because they get out of date faster than JS frameworks
This is why all my cameras internal or external live on an isolated VLAN with no internet access. It’s nice because HomeKit can still talk to them and I can see it online or locally without an additional app even though the camera themselves has no internet access .
it does not, there are 5 versions of C200 as of now and thingino only supports one or two, it is very important to get the right chip, you can check https://openipc.org/
I came here to post this, too :) What the thingino community managed to do with their firmware for these cameras is nothing short of amazing - if you happen to have a compatible camera, you really, really should give it a whirl!
I'd love to but... how? One alternative seems to be a programmer chip that must be puchased and then modified to not fry the camera with 5V. Another is maybe stripping a USB cable and soldering it to the wifi pads on the camera chip?
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.
Yeah, I can see why that is a show-stopper for people. However, the thingino project has people among them who care deeply about ease of installation - so with these security issues discovered in the TP-Link device, chances are an installation method that relies on a vulnerable stock firmware will be provided in time :)
In this case I'm asking specifically about the C200 this article is about. Sorry for not being more clear. From what I understand the C200 does not boot from SD card.
I think Thingino is great. But there are definitely still dragons lurking. I reported a bug last year and mostly forgot about it. Got a response a few months ago to check out a fix related to unexpected memory access.
I generally try not to be a huge Rust cheerleader but seriously. Yikes.
Do you think the S3 bucket with the firmware will be available for the foreseeable future? If not could someone archive it somewhere? Maybe make a torrent out if it? My network is very slow and I estimated it's about 990 GiB of data (by summing the column with the bytes in the ls output the author linked).
It might be useful to have it as a resource in the future for a variety of reasons.
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? There must be many millions sold. Quite handy for some intel agencies.
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.
> 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?
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.
Both the parent and you can be right in this case.
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.
Is there a table of supported hardware, that contains info about the USB-connection (or ethernet) on these devices. Like, which have data-lines connected, can the device electrically do host and device mode? Can I use a POE2USBC adapter, that presents itself as a USB-network device to the camera?
Ability to filter on those columns would be great.
Is thingino using the Ingenic linux kernel 3.ancient SDK version, or do they have/use something newer?
It's been long known many older TP-Link IoT devices doesn't require any authentication to connect, as my Kasa HS300 strips. Later models requires the account credential [1], but I'm not surprised that they still left something wide open (e.g., WiFi config endpoint for provisioning). I tend to believe this is just poor software engineering (Hanlon's razor).
My initial read of proximity being sufficient to exploit 3 is incorrect, so yeah as long as you control the Wi-Fi network sufficiently then things should be fine.
Great article. I have the same model and few months ago I did notice it was restarting in a non-scheduled time, and you can tell it restarts because it does a full rotation. First time it happened I ignored it but the second time I knew something was up so I disconnected it and since then been offline, it was recording an insignificant thing anyway.
For the home/lab, an second-hand enterprise network main switch and an OSS router like OPNsense to enforce security policies on the wired side of things. For WiFi gear, I've been a fan of Ubiquiti APs managed by a self-installed UniFi instance without cloud features. This, and some custom glue jobs/scripts on the unifi VM, make it easier to track down troublemakers and lock them down so they can't just dial-home or self-update and brick themselves.
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.
I have a few of these that I use with unifi for non-critical things over ONVIF and there's a reason they are on a separate vlan and not allowed to access the internet... Thankfully they don't die when you block them from phoning home.
So which camera brand has adequately designed software? It’s hard to know as a consumer what to trust or not trust, because how do you evaluate the quality of their work when the device SEEMS to work as expected? Is Ring the only choice?
If the firmware is not open and buildable, then it can only be an untrustable black box.
If you don't want untrustable black boxes hanging around, then your options become pretty limited.
You can DIY something with an SBC like a Raspberry Pi or whatever. You can hang USB cameras off of your computers like it's 2002 again. You can try to find something that OpenIPC or thingino or whatever supports. (You'll never finish with this project as the years wear on, the hardware fails, product availability ebbs and flows, and the scope changes. Maybe that sounds like a fun way to burn time for someone, but it doesn't sound like fun to me.)
Or, you can accept that the world is corrupted -- and by extension, the cameras are also all corrupted.
The safe solution is then actually pretty simple: Use wired-only cameras that work with Frigate (or whatever your local NVR of choice may be), keep them on their own private VLAN that lacks Internet access, and don't worry about it.
The less-safe solution is also pretty simple: Do what everyone else is doing, and just forget the problem exists at all. Switch your brain off, buy whatever, and use it. (And if there's an area that you don't want other people to see, then: Don't put a camera there.)
(We probably are not as interesting as we may think we are, anyway.)
Thingino is great for many other reasons but security is not one of them - definitely segregate those cameras on a locked down VLAN. The web interface is HTTP-only and it uses the same credentials as root SSH access on the camera, and most of the web ui handling code is highly questionable to say the least.
Very interesting, I had a go with Ghidra and AWS Amazon Q, used it to reverse the video feed on a toy drone. I did not think to look for GhidraMCP, would of made it a lot quicker.
You should still treat it as radioactive waste. Protect it and protect yourself from it - segregated VLAN, no internet access, just like you would do with official firmware.
If you call up your contactless payment provider, most will send you a physical device that will do contactless payments on its own, for free even. You can tape it to the back of your phone, or anywhere else for that matter.
As soon as i read the author used grok as an ai assistant, i was somehow less interested to keep on reading. Not because of the usage of ai, but the chosen provider. (I don’t know whether grok is just the best choice for this kind of work.)
Is it wrong to judge people for their choice of ai providers?
It's worth interacting with all models. In my experience, for programming questions grok delivered better answers than ChatGPT (and Claude) often enough that at some point I wasn't sure which model I should be asking first.
Per the article, the attacker can restart the camera and potentially find the accurate position of it. However, if the attacker can be physically in proximity within the camera range, they can MITM it and intercept the video feed. So it depends on your friend's threat model. If the camera is recording something in a public location and they don't mind the location being exposed and potentially the video feed (like plenty of live public cameras), then it shouldn't be an issue. Otherwise, they need to disable it until it gets fixed.
yes, everything can be automated, and as you people don't always have time to automate everything, so it depends if your area has many c200 which is a home camera, not outdoor
As @tehlike said in a sibling comment, it looks like it is supported by https://thingino.com, so you can 'update' the firmware to a more secure (and FOSS) one!
I'm a little frustrated with articles like this that scattershot their critique by conflating genuine failures with problems that even FAANGs struggle with.
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.
> I found out that TP-Link have their entire firmware repository in an open S3 bucket.
Nobody tell them about Linux!
> 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!
This blogger is the author of bettercap, safe to say they're fairly across Github
Do you people realize that there's a big difference between open source and proprietary technologies right?
Doesn't matter really, keeping blobs hidden doesn't actually do anything except make it slightly harder to analyze the software. Making all blobs easily and readily available is exactly what I want the vendor to do. Black boxes don't make things secure.
Agreed 100%, never said the opposite
This blog post is pretty readable, but it's still obviously written with the help of an LLM. A common trend is that LLMs lack the nuance and write everything with the same enthusiasm. So in a blogpost it'll infer things are novel or good/bad that are actually neutral.
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.
I always wonder if the people who let LLMs write (and think) for them realize they're steadily atrophying their brain.
I think maybe you’re reading this wrong. Reverse-engineering blog posts like this are just a fun and instructive way of telling the story of how someone did a thing. Having written and read a bunch of these in the past myself, I found this one to be a great read!
Edit: just want to add, the “how I got the firmware” part of this is also the least interesting part of this particular story.
I didn't notice a negative tone at all when he talked about the firmwares being publicly hosted. You did?
Yes, heavily, because of the use of adjectives and repeating the points.
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.
To me the phrasing seems objective. Making your binaries available to the public is good (though source would be better).
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.
I think it fails to be objective because of the repetition. It's an open S3 bucket. No need to state that no authentication was required, it's already open. It's not about economy of writing but the repetition emphasizes the point, elevating the perceived significance to the author or that the author wants the reader to take away.
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.
If someone DDOSes an open s3 bucket they’ll get a huge bill. If there is something in front of it, they might not.
An 'open S3 bucket' sounds really bad. If it were posted on an HTTPS site without authentication, like the firmware for most devices, it wouldn't sound so bad.
Sure an open bucket is bad, if it's stuff you weren't planning on sharing with the whole world anyway.
Since firmware is supposed to be accessible to users worldwide, making it easier to get it is good.
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).
No wait I agree with you. I think it is bad framing as "S3 open bucket" when people would totally understand an open website :)
> An 'open S3 bucket' sounds really bad.
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.
No I agree with you. I think it is bad framing as "S3 open bucket" when people would totally understand an open website :)
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.
No, it clearly has a gloating tone to it. 'A reverse engineer's candy store' is clearly meant as a slur.
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'.
I just meant that it was very convenient to have the firmware images there on S3, nothing else :D Many vendors make the process of even just obtaining a copy of the firmware much harder than that, so for once I was glad it has been much easier. Also being able to bindiff two adjacent versions of the same firmware is great ... all in all I was just expressing my happiness :D
> Highlighting (repeatedly) the ease and breadth of access is a basic writing technique to illustrate the weakness of a security system.
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?
Maybe listing shouldn't be enabled even if all the files are public.
> Maybe listing shouldn't be enabled even if all the files are public.
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.
It's not a necessary interface. Do the clients actually use S3 listing to determine what the latest firmware is? Personally I would put a service in the middle that takes in the model number, region, etc and then returned the most recent firmware URL. There's no reason to have historical versions be easily listable by curious people.
Why not? The firmware was already public at one point. If people are analyzing your app to find an S3 bucket full of firmware, I'd assume they'd have a pretty good reason to go through the effort.
Why not? It's just an annoyance step that is predicated on obfuscating information that has already been made publicly available.
Or to illustrate the convenience to the point of the article, being reverse engineering; not necessarily to critique their security practices here. Being easy to reverse engineer is not necessarily a weakness of security (as the inverse would simply be obscurity).
Yeah, that writing definitely reeks of incredulity.
Yep, I think it should always be that way, firmwares should be always available.
I didnt really interpret that as a particular criticism really
I think this kind of critique often leans too hard on “security through obscurity” as a cheap punchline, without acknowledging that real systems are layered, pragmatic, and operated by humans with varying skill levels. An open firmware repository, by itself, is not a failure. In many cases it is the opposite: transparency that allows scrutiny, reproducibility, and faster remediation. The real risk is not that attackers can see firmware, but that defenders assume secrecy is doing work that proper controls should be doing anyway.
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.
I’m beginning to think maybe I’m the only one that read this whole thing. The firmware storage isn’t the security through obscurity problem being talked about here. The hardcoded TLS private key definitely is though. And yes, it deserves shaming… terrible practice leads to terrible outcomes. Nobody is surprised that this is coming from tp-link at this point though.
> An open firmware repository, by itself, is not a failure
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 is exactly why network segmentation is critical for IoT devices. I always recommend putting all smart cameras and IoT devices on a separate VLAN with no direct internet access - only local network access through a firewall with strict egress rules.
For anyone concerned about their TP-Link cameras, consider: 1. Disable UPnP on your router 2. Use VLANs to isolate IoT devices 3. Block all outbound traffic except specific required endpoints 4. Consider replacing stock firmware with open alternatives when available 5. Regularly check for firmware updates (though as this article shows, updates can be slow)
The hardcoded keys issue is particularly troubling because it means these vulnerabilities persist across the entire product line. Thanks for the detailed writeup - this kind of research is invaluable for the security community.
A friend once asked me to do some pen-testing on a machine he was running on his home network. He said I'd need to come round to his house to do this as he didn't want to provide access to the machine via the Internet. Fair enough.
When he opened his front door the conversation went something like this:
The short story is he had an PoE IP-based intercom system on his front gate. I remembered this from when he was going on about his plans for his home network setup and how amazing PoE was and how he was going to have several cameras etc. I also remember seeing the purple network cable sticking out of the gate pillar whilst the renovation work was being done and the intercom hadn't yet been installed.I'd arrived 45 minutes early, unscrewed the faceplate of the intercom system and, with a bit of wiggling, I got access to a lovely Cat-5 ethernet jack. Plugging that into my laptop I was able to see his entire home network, the port for the intercom was obviously not on its own VLAN. Finding and rooting the target machine was a different matter but those details are not relevant to this story.
I suppose I got lucky. He could have put the IoT devices on separate VLANs. He could have had some alerting setup so that he'd be notified that the intercom system had suddenly gone offline. He could have limited access to the important internal machines to a known subset of IPs/ports/networks.
He learned about all of the above mitigations that day.
I've always wondered just how many people have exposed their own internal network in a similar way when trying to improve their external security (well, deterrent, not really security) but configuring it poorly.
Not relevant? That’s the best part! Spill it!
enforcing 802.1x on switch is also good solution, especially for "external" ports.
802.1x is quite trivial to bypass if you have an authenticated device (in this case the intercom) that you can transparently bridge[1].
[1]. https://www.defcon.org/images/defcon-19/dc-19-presentations/...
it still will block or slow down many.
802.1x is commonly deployed with macsec. will it be also trivial to bypass ?
Did you ever seen an intercom or IP camera with macsec support?
yes
for example https://newsroom.axis.com/en-us/press-release/macsec-zero-tr...
That's great.
Now we need to get an enterprise grade switch - doubt Cisco would add macsec into SOHO gear. Along with enterprise grade intercoms, cameras, doorbells...
And beloved by many Unifi is out of question - they still can't bake IPv6 support.
So looks like it's feasible but the cost wouldn't be good.
ADD: also read this article: https://news.ycombinator.com/item?id=41531699
Looks like some Ubiquiti UniFi switches (definitely SOHO) support 802.1x
i well familiar with macsec. we use it between datacenters and for aws directlink. it de-facto standard for this kind of stuff. i even worked on hardware that provided macsec support
a couple of years ago I tried to use it inside datacenter during fedramp implementation. it crashed and burned for a couple of reasons:
- linux wpa_supplicant was crashing during session establishment
- switch had a limit on number of macsec session per port
I have my cameras connected to a N150 server running hostapd and dnsmasq and no IP forwarding. That server runs Frigate. I figured if I need a server anyway it might as well be the AP.
It's a little bit of a pain to set up the cameras because of the mobile app. I have to connect to the AP on my phone and as it doesn't have internet access my phone nags me, and this specific model doesn't have an external antenna. If it did I think it might be the ideal setup.
do you happen to have a guide on how to achieve this - I am fairly technical but still configuring Vlans and moving devices there would be good with some step by step instructions.
Are you running Ubiquiti hardware? If so, should be very straight forward (one of the main reasons I went back to Ubiquiti stuff after running my own OPNsense router) https://lazyadmin.nl/home-network/unifi-zone-based-firewall/
P. Sure the camera in question breaks in fun ways. From my observations because it can’t update it’s time, so messing with it a bit leaving to a need to update, downgrade, block from the web again.
But it’s worth trying
depends on your router, but you would want to stick to onvif or rtsp and connect to the camera using some sort of tailscale. Don't fail for installing open source firmware, there is only thingino and openipc, both are hard to install if you are a beginner, even if people say it's easy for technical specialist, it's not
They're also limited to older hardware, newer 3K+ cameras aren't supporter. Different chip in use, I guess, or there manufacturers have learned to sign this firmware and burn in the keys.
It's probably fair to assume that most of their other camera models are affected by the same or similar issues. It looks like they pump out quite a few models that I image have similar firmware.
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
I looked at some older Zyxel products and came to the same conclusion a while back. There's a whole industry of labeling generic hardware as being part of someone's else ecosystem
https://www.hydrogen18.com/blog/hacking-zyxel-ip-cameras-pt-...
https://www.hydrogen18.com/blog/hacking-zyxel-ip-cameras-pt-...
it's a stretch to call it generic hardware, all of cheap cameras use similar hardware, but every few months there is a new version of chip which you need to adjust to. It's challenging to find an exact chip if you want to, because they get out of date faster than JS frameworks
They lend themselves to local connections, however, so they are workable for the tech savvy.
Definitely a problem for regular users.
This is why all my cameras internal or external live on an isolated VLAN with no internet access. It’s nice because HomeKit can still talk to them and I can see it online or locally without an additional app even though the camera themselves has no internet access .
Thingino supports C200 https://thingino.com/#:~:text=SC3336%2C%20WQ9001%2C%208MB-,T...
it does not, there are 5 versions of C200 as of now and thingino only supports one or two, it is very important to get the right chip, you can check https://openipc.org/
I came here to post this, too :) What the thingino community managed to do with their firmware for these cameras is nothing short of amazing - if you happen to have a compatible camera, you really, really should give it a whirl!
I'd love to but... how? One alternative seems to be a programmer chip that must be puchased and then modified to not fry the camera with 5V. Another is maybe stripping a USB cable and soldering it to the wifi pads on the camera chip?
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.
Yeah, I can see why that is a show-stopper for people. However, the thingino project has people among them who care deeply about ease of installation - so with these security issues discovered in the TP-Link device, chances are an installation method that relies on a vulnerable stock firmware will be provided in time :)
I got a couple of Wyze cameras and loaded Thignino via SD card. No fuss no muss.
In this case I'm asking specifically about the C200 this article is about. Sorry for not being more clear. From what I understand the C200 does not boot from SD card.
Ah that's fair. One of the reasons I went with the Wyze units is that they were well supported and installation was pretty easy.
correct, it's in beta testing right now, you can check for alternatives https://github.com/wltechblog/thingino-installers
Oh, this is great! I do have this exact camera and another one that’s on the list!
I’m more than happy to ditch the scrappy RTSP setup that I have to support these cheap cameras!
I think Thingino is great. But there are definitely still dragons lurking. I reported a bug last year and mostly forgot about it. Got a response a few months ago to check out a fix related to unexpected memory access.
I generally try not to be a huge Rust cheerleader but seriously. Yikes.
Do you think the S3 bucket with the firmware will be available for the foreseeable future? If not could someone archive it somewhere? Maybe make a torrent out if it? My network is very slow and I estimated it's about 990 GiB of data (by summing the column with the bytes in the ls output the author linked). It might be useful to have it as a resource in the future for a variety of reasons.
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? There must be many millions sold. Quite handy for some intel agencies.
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.
> 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?
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.
Both the parent and you can be right in this case.
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.
Also, they stop releasing firmware updates for older hardware revisions. I bet older camera models have way more exploits.
Some cameras that "charge" with USB also can use a USB network adapter (provided they can supply power).
For the tech savvy, there is thingino as a firmware alternative - works local only, no cloud, and supports mqtt etc.
Is there a table of supported hardware, that contains info about the USB-connection (or ethernet) on these devices. Like, which have data-lines connected, can the device electrically do host and device mode? Can I use a POE2USBC adapter, that presents itself as a USB-network device to the camera? Ability to filter on those columns would be great. Is thingino using the Ingenic linux kernel 3.ancient SDK version, or do they have/use something newer?
It's been long known many older TP-Link IoT devices doesn't require any authentication to connect, as my Kasa HS300 strips. Later models requires the account credential [1], but I'm not surprised that they still left something wide open (e.g., WiFi config endpoint for provisioning). I tend to believe this is just poor software engineering (Hanlon's razor).
[1] https://www.home-assistant.io/integrations/tplink/
Don't put them on untrusted networks. This always seemed obvious to me.
Untrusted network is not sufficient, you need to cut them off internet, in general.
The internet should very much be considered an untrusted network.
Don’t put it on a network, but also don’t allow it to reach an untrusted network.
My initial read of proximity being sufficient to exploit 3 is incorrect, so yeah as long as you control the Wi-Fi network sufficiently then things should be fine.
> I assume any Wi-Fi camera has basically the same problems.
ftfy
Great article. I have the same model and few months ago I did notice it was restarting in a non-scheduled time, and you can tell it restarts because it does a full rotation. First time it happened I ignored it but the second time I knew something was up so I disconnected it and since then been offline, it was recording an insignificant thing anyway.
For the home/lab, an second-hand enterprise network main switch and an OSS router like OPNsense to enforce security policies on the wired side of things. For WiFi gear, I've been a fan of Ubiquiti APs managed by a self-installed UniFi instance without cloud features. This, and some custom glue jobs/scripts on the unifi VM, make it easier to track down troublemakers and lock them down so they can't just dial-home or self-update and brick themselves.
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.
>25000 devices exposed directly
How does this happen? Doesn’t pretty much every ISP give a router with their modem? How do people manage this?
In ipv4 these will be src-natted and thus have a statefuo firewall by necessity.
In IPv6 they likely will auto configure onto a public ip address which may not have a stateful firewall.
Doesn’t seem to be the case here all of these are ipv4 addresses https://www.zoomeye.ai/searchResult?q=IlRQUkktREVWSUNFIg==
I have a few of these that I use with unifi for non-critical things over ONVIF and there's a reason they are on a separate vlan and not allowed to access the internet... Thankfully they don't die when you block them from phoning home.
So which camera brand has adequately designed software? It’s hard to know as a consumer what to trust or not trust, because how do you evaluate the quality of their work when the device SEEMS to work as expected? Is Ring the only choice?
If the firmware is not open and buildable, then it can only be an untrustable black box.
If you don't want untrustable black boxes hanging around, then your options become pretty limited.
You can DIY something with an SBC like a Raspberry Pi or whatever. You can hang USB cameras off of your computers like it's 2002 again. You can try to find something that OpenIPC or thingino or whatever supports. (You'll never finish with this project as the years wear on, the hardware fails, product availability ebbs and flows, and the scope changes. Maybe that sounds like a fun way to burn time for someone, but it doesn't sound like fun to me.)
Or, you can accept that the world is corrupted -- and by extension, the cameras are also all corrupted.
The safe solution is then actually pretty simple: Use wired-only cameras that work with Frigate (or whatever your local NVR of choice may be), keep them on their own private VLAN that lacks Internet access, and don't worry about it.
The less-safe solution is also pretty simple: Do what everyone else is doing, and just forget the problem exists at all. Switch your brain off, buy whatever, and use it. (And if there's an area that you don't want other people to see, then: Don't put a camera there.)
(We probably are not as interesting as we may think we are, anyway.)
I've installed Thingino on my cameras such as this. Cheap camera + custom (local only!) firmware is a good solution imo.
No guarantee that it'll be perfect either, obviously, but it's open source and actively maintained. Highly recommended.
Thingino is great for many other reasons but security is not one of them - definitely segregate those cameras on a locked down VLAN. The web interface is HTTP-only and it uses the same credentials as root SSH access on the camera, and most of the web ui handling code is highly questionable to say the least.
Very interesting, I had a go with Ghidra and AWS Amazon Q, used it to reverse the video feed on a toy drone. I did not think to look for GhidraMCP, would of made it a lot quicker.
I used this website to research the camera https://drmnsamoliu.github.io/
I more and more tend to not buy any network-connected product if there's no open-source firmware to run on it.
(Phones is one notable exception. I need contactless payments to work.)
Good thing some tapos do have alternative firmware like thingino.
You should still treat it as radioactive waste. Protect it and protect yourself from it - segregated VLAN, no internet access, just like you would do with official firmware.
If you call up your contactless payment provider, most will send you a physical device that will do contactless payments on its own, for free even. You can tape it to the back of your phone, or anywhere else for that matter.
Also, your phone doesn’t need to be connected to the internet for contactless payments, anyway.
As soon as i read the author used grok as an ai assistant, i was somehow less interested to keep on reading. Not because of the usage of ai, but the chosen provider. (I don’t know whether grok is just the best choice for this kind of work.)
Is it wrong to judge people for their choice of ai providers?
I think when your political views cloud your ability to take in information on an objective level, it might be bad.
You can just not like Elon, doesn't have to be political at all.
I think it's hard to say. Grok is pretty good and also fairly free with good usage limits.
Every single AI company in my opinion is committing fairly grave misdeeds with the ruthless scraping of the internet and lack of oversight.
Not to mention the shady backdoor deals going on with big tech and the current administration.
Grok is also pretty bad with its whole gas turbines in one state and datacenter in another and some possible environmental issues
It's more of a pick your poison at this point
> also fairly free with good usage limits.
But doesn't it need to have such free usage in order to overcome image problems? Referring to itself as a Nazi [1][2] for example.
[1] https://www.npr.org/2025/07/09/nx-s1-5462609/grok-elon-musk-...
[2] https://www.politico.com/news/magazine/2025/07/10/musk-grok-...
It's worth interacting with all models. In my experience, for programming questions grok delivered better answers than ChatGPT (and Claude) often enough that at some point I wasn't sure which model I should be asking first.
No, because it allows us to evaluate the type of person you are. For example, I can tell you're a member of Bluesky.
Which AI providers have access to real-time Twitter data?
Genuinely curious, what are some use cases that you require live Twitter data in your LLM for?
The topic of this HN thread: security, which is ever-evolving.
when has anything of value been posted on twitter?
Ones with better answers. Twitter dumbs down grok.
If a friend have this camera, shuld he be worried?
Per the article, the attacker can restart the camera and potentially find the accurate position of it. However, if the attacker can be physically in proximity within the camera range, they can MITM it and intercept the video feed. So it depends on your friend's threat model. If the camera is recording something in a public location and they don't mind the location being exposed and potentially the video feed (like plenty of live public cameras), then it shouldn't be an issue. Otherwise, they need to disable it until it gets fixed.
> they can MITM it
Can they? I thought they could only do it if they're in the same LAN.
the exploit is to make camera disconnect and connect to your wifi, that's how they MITM, pretty long process unless you do it often
could be automated though?
yes, everything can be automated, and as you people don't always have time to automate everything, so it depends if your area has many c200 which is a home camera, not outdoor
not necessarily worried, but like put on some pants before entering the room
If it's isolated from the Internet, no.
As @tehlike said in a sibling comment, it looks like it is supported by https://thingino.com, so you can 'update' the firmware to a more secure (and FOSS) one!
Yep
[dead]