Reminds me of the [probably apocryphal] insurance claim:
"The fog was thick and, as I turned into my driveway, I collided with a tree I haven't got."
Reminds me of the [probably apocryphal] insurance claim:
"The fog was thick and, as I turned into my driveway, I collided with a tree I haven't got."
A neighbor's teenage son made a similar claim to explain the damage to his parents' car. And, as evidence, pointed to the "skid marks" leading up to a palm tree in their front yard.
But, it was obvious the "skid marks" were made by dragging his feet through the soft dirt as the distance between them diminished significantly as they neared the tree!
Or, as I explained to his dad, the next morning: "He must have been driving one of those new-fangled, variable axle-track vehicles..."
The humor was lost on the father (perhaps he was unfamiliar with the term?)
Sure. The only problem is that the appliance is the ISP's router that you don't have any control over. It exposes ONE IP for all the devices it NATs and you don't know what that address is. Then, it only works ONE WAY, from the internal network to outside world. There is no way to the internal network from outside world. It DOES forward (and de-NATs) the packets from ESTABLISHED connections but there is no way to ESTABLISH connection from outside world to a device behind the NAT.
Thw only way how it is done is having a trojan horse in the DVR (or whatever) that establish a connection to mama server from inside the local net, over NAT as if it is a usual user connection to a web site or whatever. Then, the reverse tunnel is established so that mama server gets connected to your internal net and can do whatever it wants inside your [now breached] security perimeter.
Nothing special here but it requires bringing a trojan horse inside your perimeter and let it talk to external world, no matter over NAT or not. There is no way inside the perimeter WITHOUT that trojan horse.
The mama server lives on a routable legal IP so all those moronophones can access it from anywhere and see videos from their cameras. That is a USEFUL hack which is the only way possible to somehow feed your videos (and perform some control) through that NAT on a provider's router. It is still a HACK and it gives the mama server (and whoever might hide behind it) the full access INSIDE your security perimeter i.e. it is a full blown 100% security breach. And it is made not by somebody finding a tricky way to get in but the user himself opening his door wide open without any guards.
Don Y snipped-for-privacy@foo.invalid wrote: |------------------------------------------------------------------| |"A camera can selectively decide NOT to see certain things, based | |on features in the image. You won't know about that until | |you try to see something and wonder why what the camera reports is| |not what your own eyes see." | |------------------------------------------------------------------|
Avast anti-virus-scaremongering software on Windows can evade screen-capture software, so it is less easy to make copies of baloney which it attempts to scare customers with. It does not always hide from screen-capture software. Examples are in
No. This is a commodity function. You can purchase it from whomever you trust, roll your own, etc. Likewise the "mama" service can be provided by any party.
You can select end-to-end encryption whereby the "mama" doesn't see any of your content but just provides a connection to your "remote" -- which decrypts the content. *YOU* take on the responsibility of selecting the service that fits your needs, monetary budget and technical level of expertise. Instead of letting the manufacturer "make it easy for you" -- and inserting themselves into the process and data stream.
At your level of paranoia, ANY software that you are running on your machines -- or on any appliances inside your firewall -- is a trojan. If you feel that away, then you can "roll your own" and still avoid being "hardwired" to a particular "mama".
You can isolate ports so a device on one port of your router/appliance can't see or access devices on the other ports.
None of this is magic.
All of the above indicate how that "trojan horse" can be constrained so that only the device of interest has access to the outside world and NOT the inside world.
Unless you are expecting everyone (device, appliance manufacturer, service providers, etc.) to be conspiring to give the appearance of security while secretly opening backdoors for exploitation.
No, the topology doesn't. Current implementations *might* -- for folks who don't know how to configure their network infrastructure. But, it is not a necessary consequence of that.
You can LIVE in our guest bedroom and access the internet using software of your own *design* -- and still not access any of the hundreds of other hosts within the outer perimeter. Because I considered that an important criteria when designing the network.
[*My* "stealth server" sits at a friend's business. Despite my having remote access to it -- and it having considerable compute and storage resources -- there's nothing that I can do to interfere with his business operation. To him, I am as trustworthy as some no-name IoT device.]There is nothing that constrains a manufacturer to AVOID putting itself in the middle -- or, to avoid accessing personal/private data. And, as there is financial value to them doing so, they, naturally, do!
If legislation enforced a "fiduciary" duty on anyone holding or processing such data, then lawsuits arising from breaches would quickly prove the data to be worth less than the associated risk.
OK, I'm tired and won't go any further...
The function is commodity. You can NAT any address to any address. The problem is you don't have a ROUTABLE external address. Whatever the ISP gave you on your external interface is NOT routable. It is from RFC1918 range. It is NAT'd further down, in an ISP router, into some routable address that you don't know. There is no way you can INITIATE connection from outside to your RFC1918 address which is the only one you have on your external interface. It doesn't matter what you have inside. And you can't initiate connection to your internal network using that IP you've been NAT'd to even if you knew it.
Your moronophone lives OUTSIDE your internal network. It might be also NAT'd or not. It can only access whatever is accessible over the Internet. 99.99% of "home" internet setups don't have ANY exposed IP addresses that could be accessed over the Internet.
The only way how it can connect to your DVR controlling all your cameras is by using a HACK. You setup some middleman server accessible from Internet and make a trojan horse in that DVR, which is somewhere inside your perimeter, connect to that middlemen and establish a tunnel thus breaching your perimeter. The DVR and its cameras might be on their own network, firewalled from the rest of your internal net[s] but that doesn't matter. You ONLY have ONE external IP for your ENTIRE infrastructure so everything goes via that interface. Even if you somehow firewall that cameras' network, the mama middleman still have FULL control over your DVR and all security cameras. It can't be done other way because your moronophone app must be able to control your cameras and DVR -- it won't make sense otherwise.
Sure you can. But that is not something that 99.9999% of the "home" users are able to do. Furthermore, you will have to build your own DVR that would talk to that your own server and make your own monophone's app that would talk to that server using your own protocol.
Who paranoid?! I'm paranoid? Hm... Yes, I AM paranoid. But am I paranoid ENOUGH?
They all do. Ever heard of, e.g. Imperva and such? And all devices have their own firmware with essentially ALL "US" security cameras providers like, e.g. Lorex are just a tiny storefronts for the Chinese companies.
Sergey Kubushyn snipped-for-privacy@Koi8.net wrote: |-------------| |"moronophone"| |-------------|
:) (S.
No, it is not. My current IP address is 67.212.x.y -- definitely NOT one of the RFC1918 addresses. If I visit a place like grc.com, this is the address *it* sees, prominently displays and attempts to contact in its probes.
So, the address is routable.
Getting *though* the ISPs NAT is what makes my machine not accessible to inbound connections. And, the NAT performed in *my* router.
That's just a consequence of how things are done, "now". The COTS IoT devices I've got can all be accessed from outside my home -- because they rely on a service that can be accessed from outside my home. That doesn't mean they are malevolent agents -- any more than Microsoft's, NetBSD's or FreeBSD's OSs are intentionally trying to compromise everything here.
If I don't want them to talk to the outside world, then I place them on unroutable subnets. Or, disable their outfacing interfaces. (I don't think anyone should be able to access my stove or refrigerator)
If I don't tell this PC where my printer is located (IP), it can't find it unless it responds to certain protocols on certain ports AND the PC actively probes those. If the printer is on a different subnet, good luck to the OS trying to find it!
99.999999999% just indicates people don't take care to address this. They've been *given* an effortless way around this "problem" -- why should they invest effort to solve a problem that they think has been solved?How many IoT devices still use factory passwords? Or, insecure passwords? Does that mean passwords are a waste of time and should be removed from products?
People are lazy and do the minimum that is required to get to where they (think they) want to be. But, that's not a failing of the protocols or devices; rather, a failing of those people.
I'm currently using IP cameras. There is no path (that their manufacturer would be aware of) for them to contact the outside world. Yet, they still provide the purchased functionality: delivering video to the "agents" that do scene analysis for me.
My oven and refrigerator still heat up foods and chill them, respectively. Despite not being able to talk to the outside world.
Again, no. If you don't know how to configure your internal network, then that's a limitation of your skillset, not the technology.
The middleman has control over the DVR that *they* implement, not anything that you have chosen to implement "locally" -- unless the video from the camera travels TO their server before coming back to YOUR (local) DVR.
But, that's true of any non-encrypted connection. There's no guarantee that what I am typing is being accurately delivered to my news server as it passes through many hands -- including those of the news server.
And, there's no guarantee that any encryption protocol hasn't been hacked.
But, a lot of effort would have to be expended to ensure every USENET post, social media post, email, etc. that is "secretly distorted" shows no evidence (to any party) of that distortion.
No, you don't. SOMEONE will want to address that market with a product that can survive a security audit. They will set their pricing structure to be able to operate from the revenues generated by that service instead of leaching information from their users (e.g., duck-duck-go vs google business models).
The question is whether there is a significant market to make any "realistic" pricing scheme viable.
But, if sheeple are content with insecure nanny cams spying on them while they breast feed or disable a moving vehicle or override a water treatment plant PLC, then what hope to find "better" products? At an affordable price (how much is security worth -- in dollars and cents)
When YOU design a product, where does security sit on the list of priorities? What will you sacrifice in the name of security? Can you *invite* foreign code to run *in* your device and still maintain security??! Can you detect when you've been "compromised"?
These aren't malevolent actors with buried back-doors or other exploitable hooks. Its disingenuous to rant about stupid users when manufacturers are equally incompetent/unserious about securing their products.
Likely not. I drive each of my nodes over a separate VPN so that the node can ONLY talk to the switch -- even if you rewired the fabric (no credntials shared with other nodes). I.e., an IP camera talks to an SBC that talks to the switch -- so, any "misbehaving" from the camera is identified and isolated before it gets to the switch: "No, you can't phone home!".
Externally accessible cables are run through EMC so monitoring or injecting signals is difficult, requires some time/effort and is likely to be noticeable -- not least of which to me as I wonder why a node is unexpectedly misbehaving (now or evidenced in logs).
Furthermore, the switch only allows certain connections between devices based on the current (instantaneous) system configuration. E.g., a camera should never try to contact the HVAC controller -- doing so is an indication that the camera is malfunctioning or compromised.
A malfunctioning/compromised device is of no value so power it off (PoE) AND ignore any further traffic from that port (in case an adversary can supply auxiliary power to that node). Traffic apparently originating from a node known to be "off" is indicative of a failure.
I.e., "can't happen" means DON'T LET IT HAPPEN!
[Of course, an adversary could physically break into my equipment closet and all bets are off. But, if he can do that, why not just take any valuables that he finds and be off with them?]Again, that's not a limitation of the technology, just what folks are willing to PAY for it (in its current state). People drive the market, often causing "better" products to fail against inferior offerings.
"For enough money" you can get whatever you want. The apples that I like aren't available, locally. I can buy half a dozen of them, online, for $4.50 -- each. But, can't have them shipped into the state. How much traveling am I willing to do to buy apples?? Am I willing to break the law *smuggling* them into the state???
The question becomes what you want to PAY (in money, time, convenience, etc.) for things. When The Unwashed/Mindless Masses drive the market, you're largely stuck with *their* choices.
I suppose it could be of use to the "Find my drone/missile etc" app on a smart phone.
Brian
If the message is unique (S/N based), then it can be used to tally the number of items deployed (vs. number of items sold)
Have something to add? Share your thoughts — no account required.
Ask the community — no account required