Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

evilsocket.net

Post reply on HN
Print view View original

71–80 of 128 posts

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

#71

Post by syntaxing »

realcul wrote: post #53
magmostafa wrote: post #49

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…

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/

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

#72

Post by opello »

sally_glance wrote: post #64
AceJohnny2 wrote: post #55

Earlier quoted context omitted.

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.

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.

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

#74

Post by kqr »

c0l0 wrote: post #27
tehlike wrote: post #24

Thingino supports C200 https://thingino.com/#:~:text=SC3336%2C%20WQ9001%2C%208MB-,T...

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.

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

#75

Post by wkat4242 »

opello wrote: post #72
sally_glance wrote: post #64

Earlier quoted context omitted.

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…

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.

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

#76

Post by necovek »

wkat4242 wrote: post #75
opello wrote: post #72

Earlier quoted context omitted.

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…

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

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

#77

Post by jacquesm »

sally_glance wrote: post #64
AceJohnny2 wrote: post #55

Earlier quoted context omitted.

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.

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

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

#78

Post by inferiorhuman »

kqr wrote: post #74
c0l0 wrote: post #27

Earlier quoted context omitted.

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…

I got a couple of Wyze cameras and loaded Thignino via SD card. No fuss no muss.

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

#79

Post by inferiorhuman »

c0l0 wrote: post #27
tehlike wrote: post #24

Thingino supports C200 https://thingino.com/#:~:text=SC3336%2C%20WQ9001%2C%208MB-,T...

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

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

#80

Post by kqr »

inferiorhuman wrote: post #78
kqr wrote: post #74

Earlier quoted context omitted.

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…

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.
Post reply on HN