Live data from Hacker News

TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy

evilsocket.net

61–70 of 128 posts

Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy

#61

>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.

Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy

#62
post #5

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 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…

> 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-...

Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy

#63
post #21

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…

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.

Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy

#64

Earlier quoted context omitted.

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…

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.

Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy

#65
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.

Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy

#66
post #21

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…

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 attacke…

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.

Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy

#67
post #57

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 sp…

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…

enforcing 802.1x on switch is also good solution, especially for "external" ports.

Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy

#68
post #3

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 10…

> 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…

Also, they stop releasing firmware updates for older hardware revisions. I bet older camera models have way more exploits.

Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy

#69
post #42

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 pl…

> they can MITM it

Can they? I thought they could only do it if they're in the same LAN.

Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy

#70
post #57

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 sp…

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…

Not relevant? That’s the best part! Spill it!
Post reply on HN