hckrnws

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!

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

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?

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

They lend themselves to local connections, however, so they are workable for the tech savvy.

Definitely a problem for regular users.

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

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.

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/

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

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!

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!

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.

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?

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

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.

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

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.

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.

If a friend have this camera, shuld he be worried?

not necessarily worried, but like put on some pants before entering the room

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!

If it's isolated from the Internet, no.

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.

Yep

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.

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.

[dead]

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

No, because it allows us to evaluate the type of person you are. For example, I can tell you're a member of Bluesky.

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.

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.

Ones with better answers. Twitter dumbs down grok.

when has anything of value been posted on twitter?