Ethically, you’ve uncovered a flaw that provides a modest benefit to you (direct access to your IP camera), but serious detriment to both the manufacturer and the other owners of the cameras. Leaving aside the company’s position, this flaw could result in malign actors invading the privacy of a large number of innocent parties. Given the probability that other actors have already, or will otherwise, uncover and exploit this flaw, I’d say you have an ethical duty to try and prevent those invasions of privacy from taking place. Ethical disclosure to the company, followed by public disclosure (of the flaw’s existence, not or not necessarily of the exploit code or details) if they affirmatively refuse to take action, would be the responsible course here.

There is no universal duty to disclose security flaws. Some people have value systems that require disclosure (I'm one of them), but other people don't, and there are coherent, ethical rationales behind those value systems. A lot of it comes down to what you personally believe will happen after you disclose.

I'm automatically itchy when people talk about "ethical disclosure". If you truly do believe that people who become aware of vulnerabilities are ethically obligated to disclose them, setting terms on how they do that seems hard to defend. "Ethical" or "responsible disclosure" seem more like coercive rhetorical devices to get unpaid researchers to adopt the values and priorities of vendors than anything else --- that's part of the reason the term "responsible disclosure" has fallen out of fashion (it's been replaced with "coordinated disclosure", which is value-neutral).

> Some people have value systems that require disclosure (I'm one of them), but other people don't

If you don't believe that your value system binds anyone else to behave in a certain way then how much does it really bind you to behave that way? Ethics and morality are either objective and universally binding or they're merely an arbitrary personal inclination that isn't even binding on those that have the inclination beyond legal or professional implications.

"Morality is either objective or completely arbitrary" is a false dichotomy. Obviously ethics isn't objective (I mean what would that even mean, absent some deity?), but with some reasonable foundational beliefs such as "I generally want people to have it good and not suffer", you're already pretty constrained and guided in your reasoning. But the belief that it's generally good when people don't suffer is obviously subjective, even if widespread.

Ethics is hard. There's a reason it's not a solved problem.

> "Morality is either objective or completely arbitrary" is a false dichotomy > some reasonable foundational beliefs such as "I generally want people to have it good and not suffer" > But the belief that it's generally good when people don't suffer is obviously subjective, even if widespread.

Why is generally not wanting to hurt people a "reasonable foundational belief?" It's definitely not universal in humanity right now let alone historically just look at the celebrations of war crimes in Russia. Everyone who thinks there are binding ethical beliefs in any way must ascribe it to others otherwise they're just talking about personal taste and we don't need words like "ethics" or "morals."

I'm not sure what your point is. I think a good amount of people at least like to think they value the absence of suffering, which makes that a useful shared idea which ethical discussions can be had on top of, but my whole point is that it's not universal or objective.

This is a discussion that started with notifying people of a possible webcam bug and ended with Russian war crimes. I think we can declare the thread spent.

Does Godwin's law need to be updated to mention Russia from now on?

>> look at the celebrations of war crimes in Russia

Unfortunately this point doesn't prove/refute any point about morality.

Because most of the russians pro-war idiots (including most propaganda producers) sincerely believe propaganda and from their moral perspective they really are doing good by fighting Ukranian war criminals.

Agreeing with the other comment, that’s a false binary in your logic. Ethics, and morality, are different things and can’t be contained in an either/or statement well.

"this flaw could result in malign actors invading the privacy of a large number of innocent parties."

It's also possible this is a feature, not flaw. There's longstanding suspicion that some Chinese made camera have vulnerabilities for their benefit. Several manufacturers are based from government use over these concerns.

Google "ethical disclosure."

The standard in the security research community is you inform the manufacturer and give them an opportunity to patch the flaw. Then you wait some number of days (some people say 30, other say "depends on the details of the vulnerability"). Then you publish the code along with enough text to explain the vulnerability to a reasonably technical audience.

But it sounds like OP wants the flaw. If the company fixes it then OP will no longer have "full local access to [their] wireless security cameras without the cloud", so disclosing is directly against OP's interests. In that case it's probably best to just keep the flaw private to yourself.

OP may or may not want to live in a society where people are not vulnerable to an invasion of privacy from outside parties, which would (or would not) make it in their best interest to ethically disclose this vulnerability.

You could presumably just not update its software.

If they are wireless cameras that connect to the cloud it sounds like they might be prone to auto-updating. You'd have to do extra setup to ensure the cameras are both connected to your WiFi but are not connected to the internet.

Which could be as simple as sequestering them off on their own subnet, no?

It's only in OP interests if nobody else ever has access to this exploit.

I wouldn't feel great knowing that a camera somewhere in my space had an issue like this, because it seems somewhat naïve to assume nobody else ever figures this out.

yes, OP might want the "flaw" however it still could be discovered by somebody else and eventually patched, next week, next month, ect... just because you use bug now does not mean it won't be "fixed" (or broken worse) in the future.

personally if i were in OP's shoes: i'd hope that said company has a bug-bounty program and use that for a little side cash and a "look what i found" - along with denying auto-updates to my own devices to keep utilizing said functionality (ive always been a fan of choice vs enforcement of arbitrary updates).

Depends on your criteria for "best". Utility or ethics?

You might also want to check if the company has a bug bounty program. Unlikely but worth looking...

Adding to this, when publicly disclosing after the grace period it may be safer to let a high profile security site [1] do the public disclosing so they receive most blow-back from the vendor. Krebs is no stranger to drama and could refer to you by your security researcher nickname that is not used anywhere else. Some of the less reputable shoddy IoT manufacturers may respond poorly to public disclosure.

[1] - https://krebsonsecurity.com/

One thing I'd add is to be firm on the number of days you wait. As someone else said, that industry is scum, and I wouldn't be surprised for them to drag their feet on the fix. That's on them.

You do whatever you want. You weren't paid to find this issue with the cameras. If you're relying on the behavior, disclosing it will almost certainly get the bug killed. People hold back more serious vulnerabilities than this all the time.

If your values include maximizing the number of people who can tinker with their cameras, publish (make sure you're not falling afoul of the camera's license before you do).

If your values include doing whatever you can to keep the most people safe, then inform the camera vendor, and give them 60 days to come up with a patch or a response before you publish.

> disclosing it will almost certainly get the bug killed.

You must deal with much better vendors than my coworkers do.

Just out of curiosity, is 60 days a sort of undefined (or defined, I don't know) "standard" for disclosure? Not the first time I've seen that duration in reference to a bug like this.

60 or 90 days is pretty standard for non-bounty disclosure, and has been used by high profile projects like project zero.

Why do you assume this is a bug?

One aspect that other commenters haven't addressed is that, if you do publicly disclose, it's likely (or at least possible) that the company would close the hole and remove the functionality that you're currently using, which you might not want.

Of course, if you keep the approach private and use it for yourself, there's no guarantee that someone won't find it in the future and either exploit it or report it themselves. Do you feel comfortable having cameras in your house that could (in theory) be accessed silently by an unknown 3rd party?

1. Contact the manufacturer securely (if they have public keys, use those) to alert them of the vulnerability.

2. Demonstrate the exploitation of the vulnerability (without giving the whole thing away)

3. Negotiate timelines. Find out how quickly they can patch the system.

4. Negotiate a bounty. You're not obligated to give them anything without payment.

5. Sign NDA.

6. Deliver evidence of vulnerability.

7. Collect payment.

8. Wait until blackout period is over and the issue has been patched.

9. Publish your report (if allowed under NDA).

As someone who has submitted vulnerability reports to these bullshit camera manufacturers, I can promise you this is effectively working as intended from their end. You'll submit, they'll say "patched", give you a binary where it is patched, then next week they'll "forget" to merge it back in. Name and shame; anyone telling you about responsible disclosure has no experience in this field with this particular industry.

Is it actually a vulnerability?

Or is this just the way the camera is supposed to operate (even if undocumented)?

It's technically the way the camera is supposed to operate but in order to find that mode of operation I had to disassemble and study a binary. I'll say it's not a user-facing feature.

The description sounded a little like it allows you to access any camera given a public IP address without authentication.

If it still requires user authentication it sounds like a useful feature that many users would appreciate!

The "authenticate itself" bit is what makes me curious. Is the tool authenticating with credentials this person created, a backdoor account left in by the manufacturer, or something else?

One step in this process is "authenticate itself." If that involves exploiting a vulnerability to actually bypass authentication, ethical disclosure is the way to proceed.

If authentication is actually taking place, this sounds like a legitimate and useful feature that would steer me toward using this brand of camera. The only reasons that would make me hesitate to release would be 1) the cameras have an automatic remote firmware update mechanism, AND 2) it is likely the company would see this as a threat to a significant revenue stream. If one of those is not true I would release.

Either way, sounds very interesting!

The responsible thing to do is, of course, to notify the manufacturer of the vulnerability and give them some time to fix it before publishing.

> given an IP of the camera

So this is an internal tool, not something you can gain access to remote cameras behind NAT firewalls? I think a lot of people are assuming this is a WAN attack.

Sounds genuinely useful, especially if it can be worked into PVR software to integrate with more hardware.

OP didn’t specify if it worked on IPv6. There each device is theoretically reachable from the www.

Do domestic IPv6 networks typically expose things by default?

I can just about get on board with using legal addressing for internal nodes, but I wouldn't dream of exposing everything just because the addressing scheme allowed it.

This is a genuine question. IPv6 is yet to reach me at home.

Instead of configuring NAT (usually referred to as "port forwarding"), with IPv6 you only need to worry about configuring your firewall to allow certain connections and block everything else.

At the end of the day you have a router that acts as a firewall. Whether the devices are globally routable/reachable (IPv6) or not (IPv4) shouldn't make a difference.

IPv6 hasn't reached me either, but I would expect a sane default configuration in consumer-grade routers to block external connections by default.

Theoretically yes, in practice no. IPV6 devices are reachable, however many routers by default configure firewalls to block incoming traffic.

IoT camera that can do IPv6 is much rarer than IoT camera with security issue.

I feel like "full local access" to a camera you paid for is something that should be available anyway.

So I'm voting for the github option.

You found a bug that potentially allows strangers to invade the privacy of others. My personal opinion is that you have a moral obligation to report it to the manufacturer and give them an opportunity to patch it before releasing anything publicly.

Not disclosing it is putting countless people at risk. How would you feel if someone looked into your house and was able to see you and your family members in situations where they were expecting privacy? You have a chance to prevent that.

Don't put others at risk for your own convenience. Doing the right thing is never the wrong thing.

If you install surveillance gear that operates through the vendor's cloud management solution then you are already giving strangers the ability to invade your privacy.

Sure, the OP doesn't need to make it any worse, but it's already bad.

This sounds like how every IP camera I've ever used is supposed to work. How did we let the cloud get involved?

I suspect you're using the rtsp protocol to get the A/V streams from the camera, in which case I would consider your software another front-end for an IP CCTV system-- is that right?

There are plenty of IP CCTV solutions that use any number of manufacturer's cameras because of standard protocols, and that sort software should be fine to publish. However, if you're spawning the streams because the camera mfg. has a closed protocol and you're exploiting some bug, then maybe give it some more thought.

No, I am assembling raw packets of their own protocol to create frames.

I would either: 1. keep quiet and enjoy your access. The hole will get patched.

2. Share on github. Give back to the community and ask people to pay it forward.

3. Entered into a dangerous conversation with the company that could provide you with some cash or land you in legal trouble depending on how the conversation goes.

Facing those choices I would probably do 1 because it is the easiest and safest but seeing how you made a post about it.. I think you want to do 2 and I think you should share.

I personally would set up an anonymous account and email the manufacturer, asking them about bug bounty without revealing anything. Say something like that you are a security researcher and wondering if they have a bug bounty program for security of their webcams.

If they are willing to pay you, set up a proof of concept to demonstrate that the exploit works (ask them to give you an ip of a publicly accessible cam under their control and send them the image capture), and then ask to be paid out in BTC. Do everything behind the VPN of course. Remember, the company can simply sue you without any reason for some bullshit "unauthorized computer use" on a whim by someone who doesn't understand technology, so remaining anonymous is essential.

If they don't have a bug bounty, disclose it to them first, and give them a timeline to fix the exploit with guidance on how to do so, after which you can publicly disclose it, with instructions on how to mitigate (probably set up firewall rules im guessing), along with publishing all of the communication chain between you.

I'm not sure law authorize you to publish the code even if you have warned the manufacturer and waited a number of days. The warning could also be taken for blackmail. You'll face serious problems as this is proprietary technology and so you'll violate their copyright.They also can consider your action as intrusive. Further more, if your exploit is used by others for criminal damages, you'll sure be taken for responsible. So :

1. search for a bug bounty programm linked to the company, 2. if no programm found, contact the manufacturer in an anonymous way (there are examples of people accused end sued of trespassing by companies when they were acting in good faith, 3. if no news from them, leave it to others or contact a lawyer in order to insist if you think what you have found can really be harmful.

But never (never) publish the code without having been able to negotiate with the firm and obtain authorization.

Keep at home. I deal with the question alot, and the question you need to ask yourself. "If a pedophile or a terrorist used this program on github, would it cause more harm than gain to the world?". Usually the answer is it causes more harm, so you should keep the technique and methods to yourself.

I’d caution against publishing the code directly to the public if we’re talking about a well known brand name like Ring, Wyze, Nest, etc. You may end up getting involved in a legal dispute if you do that so for your sake report it through their vulnerability disclosure process. If it’s a no-name brand camera, those are frequently published and corrected in future firmware updates so it’s more or less ok to publish those.

Don’t count on that vulnerability being around forever though, at some point someone else is liable to find the same issue and report it. Sucks that vendors won’t give us access to the underlying OS for the device we’ve purchased. A lot of the consumer grade cameras would instantly be more valuable to me if I had that kind of access without having to hack the device for it.

Not telling you what to do but offering an alternate viewpoint.

If this was ten years ago myself might have agreed with others on the full-disclosure approach. However considering the irresponsibility of 'lowest common denominator' of people in modern times do you really want to enable script-kiddies to violate the privacy of many unwitting victims with a metaphorical loaded gun?

Perhaps an amicable middle-ground could be demonstrating the existence of these vulnerabilities in public (such as with a video) and withholding the exact exploit code from publication at least initially. Assuming you are at minimal risk of retaliation from the vendor and a diplomatic resolution fails to achieve results you could carefully measure the pros and cons of full publication and wash your hands of it.

I chose to read the prior comments posted, wish I had not done so. The answer to your question has zero to do with ethics, morals, etc. We live quite literally within a surveillance state that becomes more sophisticated and invasive by the day. FANG profit models, undisclosed deals between govt/SV and the omnipresence of video cameras have effectually made the 4th Amendment mute.

You have 3 choices and each of them is absolutely fine and at your discretion: 1. Treat your work as a "bug bounty" and contact each manufacturer for compensation. 2. Choose educate ecosystem via github post. 3. Keep quiet and use for exact purpose you intended.

Why wouldn't you tell the manufacturer so that they can fix it? What you're proposing is kind of immoral and irresponsible as a member of society. Whatever you do, do not reveal your identity to the manufacturer, some are likely to sue you for disclosing such a vulnerability. Better to release it on the dark web forums that -all- security pros check out than on github where you are easily tracked and outted. Remember that corporations are amoral entities meant for only 1 real purpose, to make their owners money.

Eufy has allowed this for a while. I use it myself for Home Assistant[0]. I believe their implementation also does autodiscovery so you don't have to scan for the camera. As long as you can't trigger the stream with a websocket (rogue JS apps shouldn't be able to read my network cameras) then I think you're fine. It's restricted to the local network.

[0]: https://github.com/fuatakgun/eufy_security

The handshake involves telling the camera which IP address to stream the video to so this can be done on any IP address whether local or not.

An my opinion, do not share the constant moral delemiah already exists daily for one humanbeingand,and also as we all know all of us love living in the fishbowl, and it's your find so That permits you to do whatever you wish with it as long as honesty,Intgrety, and ethics are all involved I also see what we do as a kinda with skills as such the responsibility, that tags along shall have the same. Skill set only aimed in another direction,

It's a simple choice.

Imagine 2 worlds: one, where you'd prefer someone in your position to act A, another, where he acts B.

Choose the option which aligns with the world you'd rather live in.

Sell it to TrendMicro Zero Day Initiative https://www.zerodayinitiative.com/

Since you are asking, I'd assume you care for the consequences on others. So I'd say contact the manufacturer, try to have it fixed in a reasonable time (like 2 months). After that the safest thing you can do for others is to disclose so that they can either fix themselves or stop using the product (as it's not unlikely you are not the only one to have found the flaw anyway and it becomes more and more likely as time passes)

Please, please share with the general public. I have wanted something like this for years. I hope it works with Nest. My Nest cams work pretty well, I just wish I had control over the awful fucking interface it comes with. I have about 10 cameras in multiple locations, it is impossible to display all feeds tiled on one screen like you used to be able to do in, I don’t know, the 80s?

Surprised no one has asked. Does this affect the manufacturer's income? That is, is this also a way to escape an otherwise mandatory subscription fee?

If no, I say publish it without further consideration.

If yes, there might be a DMCA claim against you and you'll want to consider that in your decision. Personally I would likely keep it to myself.

I'd just publish it for the lulz.

Honestly I don't get people who do ethical disclosure: you are going out of your way (and wasting your time) to do what? Tell a company that likely hasn't even took security into consideration hoping that they publish a patched version of the firmware nobody will install either way?

This situation is similar to the Starcraft Gold Master Source Code CD found by someone who posted their discovery on Reddit. The results were... to say the least, mixed.

I think a lot of us "unethical" geeks would love to gawk at your finding, but it's up to you whether you want to disclose it or not.

Writing this post in Hacker News is the best way to get people to send you DM to get your exploit in exchange for $s

Good job!

Check if the vendor has a responsible disclosure program. Otherwise, try to contact them providing all the details. If you don't get any response after a while (2 months) you can make it public. Another way may be to contact your national CERT and inform them about the issue

Can you get rewarded by the company doing something? Do you think any security or intelligence agency doesn’t have that already? Perhaps it is a duty to disclose it, and you might want to privately contact the company before doing so, so they have a chance to patch it.

Are you talking about accessing the stream of a camera via its IP on your local network, or externally by the public IP of your home connection? This pretty drastically changes the severity of what you're describing.

The protocol uses UDP hole punching so it doesn't matter if it's local or not.

Definitely not Amcrest whew

Perhaps there's a chance other people already know about this bug and are already streaming video directly from your house. It's in your interest to have this fixed if you want to keep the camera.

Do it. Watch the world burn.

Plz share. If a hole exists, interested party will know about it, sooner or later (or already). So, IMHO it's better if just everyone knows. This is only my opinion.

Would it be illegal to buy options and publish the vulnerability?

i would recommend you email the vendor, ask give them 14 days to reply on whether they are interested in having a 60 day window to issue a fix (without telling more than "remote exploit, full camera access"). If they do not reply, publish immediately, if they do, you let them know how it works, and give them a date in the calendar for when it will be disclosed publicly.

RTSP running on generic crappy ip cams is a known issue.

Google it. There’s entire websites to browse these streams. Some even have access to the PTZ.

Fwiw, most of the cameras are behind NATs, the ones on the sites have public IPs. A NAT effectively firewalls your camera from the internet, but yes once on LAN they’re unauthenticated.

The way these IP cameras work is that when you configure them from an app or some dodgy viewer is that that software calls the cloud server, and tells it what the details are for your LAN connected IP cameras.

You really can't let them know how to dial out. Most of them have hardcoded passwords and/or known exploits.

It's why they're so cheap on the 'zon.

Or secure your network with just NAT if you want. I really don't care.

Yeah, NAT is fairly secure in the sense that it blocks incoming connections... you're kind of a security nut if you lock down all ports. Anyone outgoing will just stream over 80 or 443 anyways, port based firewalls are pretty antiquated. You can't really lock down port 80 and still have a functional network unless you whitelist every device you connect.

But you can lock down that egress for your cameras. Why does your camera need to establish any outbound stream at all? Might want to keep an eye on that...

This is capturing raw frames, not RTSP.

related but not related, how does a security camera transmit data via TCP/IP without a mobile network connection? does it run off a local wifi network to send and receive data? is there an interface to translate data from a mobile network connection back to TCP/IP allowing you to access via the IP addr?

Network security cameras connect to Wifi and/or Ethernet; they use TCP/IP. Connecting remotely can be done by opening up firewall or by camera connecting to cloud.

Mobile networks use IP, there is no translation needed. But mobile networks do not allow remote connections. Access would require cloud service, either from the provider or VPN.

so if we run the traffic through a VPN we can connect existing infrastructure to mobile network devices? i'm very intrigued by the intersection of mobile networks and the existing TCP/IP that runs most of the modern data center. curious how those two pieces will evolve and communicate together. as a side note, any edge device that is outside of wifi network range also seems to be isolated. until you bring that device back into range there is no way to transmit the data, leading to localized storage issues the way i see it.

Mess this up even a little bit and the only profit to be seen will be at the jail's commissary.

I would report this using the responsible disclosure program of the manufacturer.

This is why I have my cameras on a routerless subnet with dual NIC viewing machines.

You assume nobody else has discovered this yet…

NSA wants to know your location.

NSA already knows his location and is streaming video from his house. :-)

Ghidra...

dLink, right?

re "name", Minor player? Of which country?

It sounds like they need to rewrite it in Rust.

It sounds like they need to hire people that have the most basic understanding of security and authentication -- but that's just too expensive when most customers are looking for the cheapest camera and barely care. Also, you know... beg for forgiveness and all.

I wouldn't be surprised if this happened to this company before.

Absolutely release this. The security camera industry is pure evil, fostering oppression and exploiting the powerless. Bring them down.