[HN Gopher] TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows ...
___________________________________________________________________
TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy
Author : sibellavia
Score : 329 points
Date : 2025-12-19 18:19 UTC (1 days ago)
(HTM) web link (www.evilsocket.net)
(TXT) w3m dump (www.evilsocket.net)
| JaggedJax wrote:
| 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
| sidewndr46 wrote:
| 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-...
| defraudbah wrote:
| it's a stretch to call it generic hardware, all of cheap
| cameras use similar hardware, but every few months there is a
| new version of chip which you need to adjust to. It's
| challenging to find an exact chip if you want to, because
| they get out of date faster than JS frameworks
| tehlike wrote:
| They lend themselves to local connections, however, so they are
| workable for the tech savvy.
|
| Definitely a problem for regular users.
| aaronax wrote:
| 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.
| formerly_proven wrote:
| > I assume any Wi-Fi camera has basically the same problems.
|
| ftfy
| tehlike wrote:
| 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.
| stragies wrote:
| 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?
| fylo wrote:
| Don't put them on untrusted networks. This always seemed
| obvious to me.
| aaronax wrote:
| 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.
| tehlike wrote:
| Untrusted network is not sufficient, you need to cut them off
| internet, in general.
| baobun wrote:
| The internet should very much be considered an untrusted
| network.
| hdgvhicv wrote:
| Don't put it on a network, but also don't allow it to
| reach an untrusted network.
| Aurornis wrote:
| > 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.
| reddalo wrote:
| Also, they stop releasing firmware updates for older hardware
| revisions. I bet older camera models have way more exploits.
| heresie-dabord wrote:
| Both the parent _and_ you can be right in this case.
|
| The parent rightly suggested that there is the obvious
| _intention_ to exploit these devices:
|
| > 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?
|
| You explained that there could be an economic reason for the
| appalling absence of security:
|
| > The only way these ultra-cheap products are getting shipped
| at these prices is by doing the absolute bare minimum of
| software development.
|
| But the parent's point is more convincing, based on the
| observable evidence and the very clear patterns of state-
| sponsored exploitation.
|
| The vendors _could_ set default passwords to be robust. The
| vendors _could_ configure defaults to block upstream access.
| But maybe the vendors in this particular supply chain are
| more like the purveyors of shovels in a Gold Rush.
|
| A less-charitable metaphor is possible where state-sponsored
| motives are unambiguously known.
| cvhc wrote:
| 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).
|
| [1] https://www.home-assistant.io/integrations/tplink/
| mlaretallack wrote:
| 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.
| shreddit wrote:
| 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?
| walterbell wrote:
| Which AI providers have access to real-time Twitter data?
| 2gremlin181 wrote:
| Genuinely curious, what are some use cases that you require
| live Twitter data in your LLM for?
| walterbell wrote:
| The topic of this HN thread: security, which is ever-
| evolving.
| blibble wrote:
| when has anything of value been posted on twitter?
| sroussey wrote:
| Ones with better answers. Twitter dumbs down grok.
| sva_ wrote:
| I think when your political views cloud your ability to take in
| information on an objective level, it might be bad.
| wh0thenn0w wrote:
| You can just not like Elon, doesn't have to be political at
| all.
| scotty79 wrote:
| 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.
| vablings wrote:
| 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
| wyldfire wrote:
| > 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-...
| kernal wrote:
| No, because it allows us to evaluate the type of person you
| are. For example, I can tell you're a member of Bluesky.
| robertpohl wrote:
| If a friend have this camera, shuld he be worried?
| sciencejerk wrote:
| Yep
| buddhistdude wrote:
| not necessarily worried, but like put on some pants before
| entering the room
| tamimio wrote:
| 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.
| reddalo wrote:
| > they can MITM it
|
| Can they? I thought they could only do it if they're in the
| same LAN.
| defraudbah wrote:
| the exploit is to make camera disconnect and connect to
| your wifi, that's how they MITM, pretty long process unless
| you do it often
| buddhistdude wrote:
| could be automated though?
| defraudbah wrote:
| yes, everything can be automated, and as you people don't
| always have time to automate everything, so it depends if
| your area has many c200 which is a home camera, not
| outdoor
| userbinator wrote:
| If it's isolated from the Internet, no.
| g5pw wrote:
| 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!
| SilverElfin wrote:
| 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?
| notjosh wrote:
| 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.
| dns_snek wrote:
| Thingino is great for many other reasons but security is not
| one of them - definitely segregate those cameras on a locked
| down VLAN. The web interface is HTTP-only and it uses the
| same credentials as root SSH access on the camera, and most
| of the web ui handling code is highly questionable to say the
| least.
| ssl-3 wrote:
| 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.)
| rao-v wrote:
| 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.
| tecleandor wrote:
| Yep, I think it should always be that way, firmwares should be
| always available.
| jabedude wrote:
| I didn't notice a negative tone at all when he talked about the
| firmwares being publicly hosted. You did?
| AceJohnny2 wrote:
| 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.
| sally_glance wrote:
| 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.
| opello wrote:
| 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.
| wkat4242 wrote:
| 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.
| necovek wrote:
| 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).
| locknitpicker wrote:
| > An 'open S3 bucket' sounds really bad.
|
| Only to gullible, clueless types.
|
| Full blown production SPAs are served straight from
| public access S3 buckets. The only hard requirement is
| that the S3 bucket enforces read-only access through
| HTTPS. That's it.
|
| Let's flip it the other way around and make it a thought
| experiment: what requirement do you think you're
| fulfilling by enforcing any sort of access restriction?
|
| When you feel compelled to shit on a design trait, the
| very least you should do is spend a couple of minutes
| thinking about what problem it solves and what are the
| constraints.
| pacifika wrote:
| If someone DDOSes an open s3 bucket they'll get a huge
| bill. If there is something in front of it, they might
| not.
| jacquesm wrote:
| 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'.
| evilsocket wrote:
| I just meant that it was very convenient to have the
| firmware images there on S3, nothing else :D Many vendors
| make the process of even just obtaining a copy of the
| firmware much harder than that, so for once I was glad it
| has been much easier. Also being able to bindiff two
| adjacent versions of the same firmware is great ... all
| in all I was just expressing my happiness :D
| locknitpicker wrote:
| > Highlighting (repeatedly) the ease and breadth of access
| is a basic writing technique to illustrate the weakness of
| a security system.
|
| It's a firmware distribution system. It's read-only access
| to a public storage account designed to provide open access
| to software deployment packages that the company wishes to
| broadcast to all products. Of course there is no auth
| requirement at all. The system is designed to allow
| everyone in the world to install updates. What compells
| anyone to believe the system would be designed to prevent
| public access?
| lmz wrote:
| Maybe listing shouldn't be enabled even if all the files
| are public.
| dns_snek wrote:
| Why not? It's just an annoyance step that is predicated
| on obfuscating information that has already been made
| publicly available.
| locknitpicker wrote:
| > Maybe listing shouldn't be enabled even if all the
| files are public.
|
| I don't see why. Support for firmware upgrades literally
| involve querying available packages and downloading the
| latest ones (i.e., apply upgrades). Either you use
| something like the S3 interface, or you waste your time
| implementing a clone of what S3 already supports.
|
| Sometimes simple is good, specially when critics can't
| even provide any concrete criticism.
| LoganDark wrote:
| Or to illustrate the _convenience to the point of the
| article_ , being reverse engineering; not necessarily to
| critique their security practices here. Being easy to
| reverse engineer is not necessarily a weakness of security
| (as the inverse would simply be obscurity).
| moron4hire wrote:
| Yeah, that writing definitely reeks of incredulity.
| Angostura wrote:
| I didnt really interpret that as a particular criticism really
| theropost wrote:
| 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.
| fn-mote wrote:
| > 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?
| void-star wrote:
| 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.
| hdgvhicv wrote:
| > I found out that TP-Link have their entire firmware
| repository in an open S3 bucket.
|
| Nobody tell them about Linux!
| locknitpicker wrote:
| > Nobody tell them about Linux!
|
| The blogger will blow a gasket when they discover that the
| likes of GitHub provides access to both installers and
| software. A hacker's candy store!
| evilsocket wrote:
| Do you people realize that there's a big difference between
| open source and proprietary technologies right?
| void-star wrote:
| 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.
| NathanielK wrote:
| 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.
| jorvi wrote:
| I always wonder if the people who let LLMs write (and think)
| for them realize they're steadily atrophying their brain.
| nine_k wrote:
| 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.)
| mindslight wrote:
| 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.
| chatmasta wrote:
| Also, your phone doesn't need to be connected to the internet
| for contactless payments, anyway.
| tehlike wrote:
| Good thing some tapos do have alternative firmware like
| thingino.
| dns_snek wrote:
| You should still treat it as radioactive waste. Protect it
| and protect yourself from it - segregated VLAN, no internet
| access, just like you would do with official firmware.
| tehlike wrote:
| Thingino supports C200
| https://thingino.com/#:~:text=SC3336%2C%20WQ9001%2C%208MB-,T...
| c0l0 wrote:
| 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!
| rescbr wrote:
| 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!
| kqr wrote:
| 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 naive 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.
| inferiorhuman wrote:
| I got a couple of Wyze cameras and loaded Thignino via SD
| card. No fuss no muss.
| kqr wrote:
| 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.
| defraudbah wrote:
| correct, it's in beta testing right now, you can check
| for alternatives https://github.com/wltechblog/thingino-
| installers
| inferiorhuman wrote:
| Ah that's fair. One of the reasons I went with the Wyze
| units is that they were well supported and installation
| was pretty easy.
| c0l0 wrote:
| Yeah, I can see why that is a show-stopper for people.
| However, the thingino project has people among them who
| care deeply about ease of installation - so with these
| security issues discovered in the TP-Link device, chances
| are an installation method that relies on a vulnerable
| stock firmware will be provided in time :)
| inferiorhuman wrote:
| 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.
| defraudbah wrote:
| 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/
| syntaxing wrote:
| 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 .
| tamimio wrote:
| 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.
| VladVladikoff wrote:
| >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?
| hdgvhicv wrote:
| 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.
| VladVladikoff wrote:
| Doesn't seem to be the case here all of these are ipv4
| addresses
| https://www.zoomeye.ai/searchResult?q=IlRQUkktREVWSUNFIg==
| magmostafa wrote:
| 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.
| realcul wrote:
| 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.
| syntaxing wrote:
| 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/
| tapland wrote:
| P. Sure the camera in question breaks in fun ways. From my
| observations because it can't update it's time, so messing
| with it a bit leaving to a need to update, downgrade, block
| from the web again.
|
| But it's worth trying
| defraudbah wrote:
| depends on your router, but you would want to stick to onvif
| or rtsp and connect to the camera using some sort of
| tailscale. Don't fail for installing open source firmware,
| there is only thingino and openipc, both are hard to install
| if you are a beginner, even if people say it's easy for
| technical specialist, it's not
| alexfoo wrote:
| 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."
|
| The short story is he had an PoE IP-based intercom system on
| his front gate. I remembered this from when he was going on
| about his plans for his home network setup and how amazing PoE
| was and how he was going to have several cameras etc. I also
| remember seeing the purple network cable sticking out of the
| gate pillar whilst the renovation work was being done and the
| intercom hadn't yet been installed.
|
| 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.
| tguvot wrote:
| enforcing 802.1x on switch is also good solution, especially
| for "external" ports.
| onlydnaq wrote:
| 802.1x is quite trivial to bypass if you have an
| authenticated device (in this case the intercom) that you
| can transparently bridge[1].
|
| [1]. https://www.defcon.org/images/defcon-19/dc-19-presenta
| tions/...
| tguvot wrote:
| it still will block or slow down many.
|
| 802.1x is commonly deployed with macsec. will it be also
| trivial to bypass ?
| vsgherzi wrote:
| Not relevant? That's the best part! Spill it!
| dpkirchner wrote:
| I have my cameras connected to a N150 server running hostapd
| and dnsmasq and no IP forwarding. That server runs Frigate. I
| figured if I need a server anyway it might as well be the AP.
|
| It's a little bit of a pain to set up the cameras because of
| the mobile app. I have to connect to the AP on my phone and as
| it doesn't have internet access my phone nags me, and this
| specific model doesn't have an external antenna. If it did I
| think it might be the ideal setup.
| bgbntty2 wrote:
| 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.
| tills13 wrote:
| 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.
| defraudbah wrote:
| I used this website to research the camera
| https://drmnsamoliu.github.io/
___________________________________________________________________
(page generated 2025-12-20 23:01 UTC)