[dead]
TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy
51–60 of 128 posts
Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy
#52This 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…
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?
Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy
#53This 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…
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.
Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy
#54I'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…
> 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?
Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy
#55I'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 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.
Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy
#56Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy
#57This 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 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."
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.
Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy
#58Re: TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy
#59I'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 found out that TP-Link have their entire firmware repository in an open S3 bucket.
Nobody tell them about Linux!