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.
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.
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).
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.
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?
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.
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!
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'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 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 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.
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.
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/
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 .
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.
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.
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.
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.
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.
35 comments
[ 2.7 ms ] story [ 49.8 ms ] threadThis 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 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.
[1] https://www.home-assistant.io/integrations/tplink/
Is it wrong to judge people for their choice of ai providers?
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.)
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.
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.
Nobody tell them about Linux!
Edit: just want to add, the “how I got the firmware” part of this is also the least interesting part of this particular story.
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.
(Phones is one notable exception. I need contactless payments to work.)
How does this happen? Doesn’t pretty much every ISP give a router with their modem? How do people manage this?
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.
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.