Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Win11 explorer bug?
Date: Thu, 12 Dec 2024 13:15:40 -0700
Organization: A noiseless patient Spider
Lines: 74
Message-ID: <vjfg9k$2tnfq$1@dont-email.me>
References: <qieclj5ca2dsc2fnpufpg51fn7qt0u2peh@4ax.com>
 <vj6im4$cf7f$1@dont-email.me> <dcselj96kvngr6gid7mje3phabj2sp876t@4ax.com>
 <vj91de$t4hr$2@dont-email.me> <jcoglj5c0cmprqek68tah1euht1amhu9ko@4ax.com>
 <vj9q8g$11i0t$2@dont-email.me> <13vgljdqp79a2onuijph2om08fk99u2fdm@4ax.com>
 <vjablv$14se5$1@dont-email.me> <addhljp8i0d5t42lavnd37a8e883ijhsqt@4ax.com>
 <vjaeii$14se5$2@dont-email.me> <gquhljd83745shtckfjgtd5u6iphkprprc@4ax.com>
 <vjblle$1fd6a$1@dont-email.me> <gsnjljdvnhu7m25ops26ek9lvca5eqvk2n@4ax.com>
 <vjec62$22pn8$1@dont-email.me> <vjefoe$23fh4$1@dont-email.me>
 <uj2r2lxum3.ln2@Telcontar.valinor> <vjennd$24vi6$1@dont-email.me>
 <vjeu9v$1k7v$1@nnrp.usenet.blueworldhosting.com>
 <vjf6rs$2rvlf$1@dont-email.me>
 <vjfdof$1d8$1@nnrp.usenet.blueworldhosting.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 12 Dec 2024 21:15:49 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ee6d8dc472cd575fee80a2b357a49690";
	logging-data="3071482"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/bFj18Fqi4GerzX0n1eFPR"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:/yYtpaFVZYd4BcpoZUarHJd8Ihc=
In-Reply-To: <vjfdof$1d8$1@nnrp.usenet.blueworldhosting.com>
Content-Language: en-US
Bytes: 5304

On 12/12/2024 12:32 PM, Edward Rawde wrote:
>> Is there any reason the camera can't talk to a phone that is also
>> hosted by the customer's access point?
>>
>> If you want to let the camera access a phone that is NOT "local",
>> then let the user subscribe to a DynDNS service -- provided by
>> any number of competing firms (even the manufacturer -- via a nice
>> clean OPEN interface).
> 
> Inbound is problematic for various reasons.
> Do you want your cameras accepting inbound connections from anywhere in the world?

Vendors have no problem selling "hubs" as a prerequisite to talk to
their devices.  Why can't the hub implement a packet filter?
Use that as a selling point:  the hub can act to protect the
local network (for a fee!!) while their access point/router likely
has not been reliably configured for that purpose.

> Ok they don't have access credentials but there's still a risk of an 0-day in a camera system which isn't going to get any more
> firmware updates.

Simply putting the camera (or any device manufactured by someone who
may or may not be trustworthy) on your "internal network puts you
at risk.

E.g., I can open an outbound connection to hostile_actor.com and let
an external agent act as command-and-control, telling me (the camera)
what to do ON THE INTERNAL NETWORK.

This traffic can be disguised to look innocuous.  E.g., resolving
"whatshouldIdo.hostile_actor.com" can deliver data to the camera that
can be augmented by then resolving "whatELSEshouldIdo.hostile_actor.com".
Results can be delivered to the external agency by resolving
"thepasswordisFOOBAR.hostile_actor.com", etc.

Or, open an HTTP connection to hostile_actor.com and anyone looking
through the logs (ha!) would just think a user visited a website of
with an oddly suspicious domain name.  (So, buy up yahooo.com,
goggle.com, etc.)

> I would do this myself because I can use a firewall to restrict inbound as necessary and I can quickly add any IP or network
> attempting brute force to a blacklist.
> But most people have no interest in that.

Hence the value of a "hub".

I "hide" my file server behind a particular "knock sequence" that is
only known to folks who should need access to it.  Trying to probe
the IP address gets you no information -- it looks like there isn't
a machine AT that IP address.

Of course, the machine SEES all attempts to connect to it.  And, which
ports and protocols are being used -- and in which sequence -- from every
potential external IP.  So, if it sees the right combination of accesses
in a particular time frame, it will THEN respond to a connection attempt
for a particular service.  Or, "callback" on a preassigned port on
the "caller's" IP address (as many ISPs frown on operating a server...
but, no constraints on ACCESSING some external service -- even if doing
so at the behest of said service!)

Meanwhile, other attempts AT THE SAME TIME still see a "dangling wire".

Once a connection is granted, there are no limits on what can be
transfered (set up a tunnel and all of those transactions are hidden)

> Most people just want the pictures on their phone wherever they are and they may wrongly assume that it's impossible for the
> pictures to be viewed by anyone other than themselves.

<https://www.shodan.io/search?query=camera>

Even if you can't (easily) access the video, the fact that someone has
INSTALLED a camera (five cameras??) has informational value.