Re: [homenet] write up of time without clocks

[Paul Duffy]

On 11/3/2016 3:26 PM, Brian E Carpenter wrote:

Yes, I agree it's possible to do better, but what's the incentive for a 
bottom-feeding vendor
of cheap devices to bother?


Lawsuits, regulation, well respected security branding (awarded after 
certification testing).


Any or all of the above.

Its got to have impact on the bottom line.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] write up of time without clocks

[Markus Stenberg]

On 3 Nov 2016, at 21.26, Brian E Carpenter  wrote:
> Yes, I agree it's possible to do better, but what's the incentive for a 
> bottom-feeding vendor
> of cheap devices to bother?

I hate to say this, but how about legal solutions? If you sell e.g. guns that 
explode if you use them, you are going to go out of business, EULA or no EULA.
(I guess this mitigation strategy works better in the US than e.g. EU, though.)

Cheers,

-Markus

P.S. Funny datapoints from my home infra:

- 2,5 years old firmware on my CER seems to be holding strong; of course, there 
are zero open ports to the outside world. Default deny policy makes even broken 
hardware work. It is the ‘call me to administer’ + weird authz when you get to 
trouble.

- The VDSL2-ethernet bridge (aka lobotomized ZyXEL router) that is in front of 
it is using about 5 years old default firmware, and I am still not worried, it 
does not talk IP.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] write up of time without clocks

[Brian E Carpenter]

Barbara,

On 04/11/2016 04:00, STARK, BARBARA H wrote:
>>> I could be wrong, but I believe that Dyn was DDoSed by the Mirai
>>> botnet, which propagates by exploiting devices configured with default
>> credentials.
>>> This has nothing to do with outdated firmwares.
>>
>> The problem is that you cannot realistically update those firmwares.
> 
> Many companies provide devices that do automated updates. It's totally 
> realistic to update firmwares.

Not always. My CE can't be updated any more, I think because its flash memory 
is too small
for recent versions. And I had the same experience a few years ago with a 
previous CE. Not to
mention that most vendors simply stop supporting old hardware after a few 
years. Also
as Juliusz pointed out, if the device was shipped with user admin, password 
admin and the
user (being a normal citizen) doesn't change it, any amount of new vendor 
firmware won't
fix it.

Yes, I agree it's possible to do better, but what's the incentive for a 
bottom-feeding vendor
of cheap devices to bother?

Regards
Brian

> There exist various methods, tools and best practices. The problem is that 
> some manufacturers don't bother to make their
devices upgradable. By not having to maintain the firmware of shipped devices, 
the devices can be sold very inexpensively. So
price-conscious consumers will  buy them, instead of the more expensive, 
well-maintained devices.
> 
>> It is trivial to compile a new firmware for those devices that doesn't 
>> request
>> upnp to open ports to telnet or ssh. But is is impossible to deploy such an
>> update.
> 
> I can't speak for others, but DIRECTV set-top-boxes all do auto update, as do 
> Digital Life IoT devices, and U-verse residential gateways. I think iControl 
> IoT devices do, too. So, no, it's not impossible. It's just cheaper and 
> requires less skill and effort to create devices that can't be updated. The 
> exploited vulnerabilities (in the Dyn attack) have been known for years, and 
> fixes have been available for years. Even after they were known, new units 
> were still shipping with the vulnerability. Secure methods for updating 
> devices and best practices for using these methods have existed for years. If 
> the device manufacturer had built in a mechanism to allow for secure, 
> automated updates (and not hard-coded a default password for access to all 
> devices that couldn't even be changed by firmware update), and had made 
> updates available in a timely manner, there wouldn't have been vast numbers 
> of devices to exploit. 
> 
>> For consumer electronics, we cannot rely on consumers to actually download
>> and install new firmware. So part of the solution to securing those devices
>> has to be that (out of the box) they will update automatically.
> 
> +1
>  
>> For the same reason, having lots of devices on the internet that have been
>> abandoned by the vendor is also a huge security risk. So ideally those 
>> devices
>> should shutdown automatically.
> 
> Which means the vendor would still be responsible for building in a remote 
> "kill switch". Ideally, manufacturers would be required to warn consumers 
> prior to purchase that the device will be bricked (or maybe just have all IP 
> connectivity disabled) if it is ever discovered to have an easily exploitable 
> vulnerability.
>  
>> Note that PCs, browsers, etc. are now somewhat secure because they
>> update automatically. We need to do the same with all other devices
>> connected to the internet.
> 
> +1
> 
> Barbara
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] write up of time without clocks

[Juliusz Chroboczek]

 ddos attack like against Dyn

>> I could be wrong, but I believe that Dyn was DDoSed by the Mirai botnet,
>> which propagates by exploiting devices configured with default credentials.
>> This has nothing to do with outdated firmwares.

> The problem is that you cannot realistically update those firmwares.

Philip -- please read my mail again.  The Dyn attack has nothing to do
with out-of-date firmwares.

I cannot stress this enough: out-of-date firmwares are the least of our
problems at this stage.  We're being attacked by devices that ship with
a well-known default password, and in some cases by devices that ship with
a well-known backdoor that's impossible to disable:

  https://mjg59.dreamwidth.org/40397.html

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] write up of time without clocks

[STARK, BARBARA H]

> >I could be wrong, but I believe that Dyn was DDoSed by the Mirai
> >botnet, which propagates by exploiting devices configured with default
> credentials.
> >This has nothing to do with outdated firmwares.
> 
> The problem is that you cannot realistically update those firmwares.

Many companies provide devices that do automated updates. It's totally 
realistic to update firmwares. There exist various methods, tools and best 
practices. The problem is that some manufacturers don't bother to make their 
devices upgradable. By not having to maintain the firmware of shipped devices, 
the devices can be sold very inexpensively. So price-conscious consumers will  
buy them, instead of the more expensive, well-maintained devices. 

> It is trivial to compile a new firmware for those devices that doesn't request
> upnp to open ports to telnet or ssh. But is is impossible to deploy such an
> update.

I can't speak for others, but DIRECTV set-top-boxes all do auto update, as do 
Digital Life IoT devices, and U-verse residential gateways. I think iControl 
IoT devices do, too. So, no, it's not impossible. It's just cheaper and 
requires less skill and effort to create devices that can't be updated. The 
exploited vulnerabilities (in the Dyn attack) have been known for years, and 
fixes have been available for years. Even after they were known, new units were 
still shipping with the vulnerability. Secure methods for updating devices and 
best practices for using these methods have existed for years. If the device 
manufacturer had built in a mechanism to allow for secure, automated updates 
(and not hard-coded a default password for access to all devices that couldn't 
even be changed by firmware update), and had made updates available in a timely 
manner, there wouldn't have been vast numbers of devices to exploit. 

> For consumer electronics, we cannot rely on consumers to actually download
> and install new firmware. So part of the solution to securing those devices
> has to be that (out of the box) they will update automatically.

+1
 
> For the same reason, having lots of devices on the internet that have been
> abandoned by the vendor is also a huge security risk. So ideally those devices
> should shutdown automatically.

Which means the vendor would still be responsible for building in a remote 
"kill switch". Ideally, manufacturers would be required to warn consumers prior 
to purchase that the device will be bricked (or maybe just have all IP 
connectivity disabled) if it is ever discovered to have an easily exploitable 
vulnerability.
 
> Note that PCs, browsers, etc. are now somewhat secure because they
> update automatically. We need to do the same with all other devices
> connected to the internet.

+1

Barbara

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] write up of time without clocks

[Philip Homburg]

>>> ddos attack like against Dyn
>
>I could be wrong, but I believe that Dyn was DDoSed by the Mirai botnet,
>which propagates by exploiting devices configured with default credentials.
>This has nothing to do with outdated firmwares.

The problem is that you cannot realistically update those firmwares.

If is trivial to compile a new firmware for those devices that doesn't 
request upnp to open ports to telnet or ssh. But is is impossible to deploy
such an update.

For consumer electronics, we cannot rely on consumers to actually download and
install new firmware. So part of the solution to securing those devices
has to be that (out of the box) they will update automatically.

For the same reason, having lots of devices on the internet that have been
abandoned by the vendor is also a huge security risk. So ideally those devices
should shutdown automatically.

Note that PCs, browsers, etc. are now somewhat secure because they update
automatically. We need to do the same will all other devices connected to
the internet.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] write up of time without clocks

[Philip Homburg]

> This started with a need for somewhat accurate system time for
> certificate validation, right? I have to deal with stuff lacking
> a RTC battery. I save system time every now and then in flash.
> During startup, clock jumps forward to RTC when warm start occurs
> (main power was not interrupted) or to saved system time when a
> cold boot occurs. When clock is behind, it jumps forwards when NTP
> syncs. My certificates do not expire during "powered off, on the
> shelf".

The problem is that security protocols like TLS and DNSSEC rely on 
secure, accurate time without specifying how to get that. At the moment
we don't have any way to distributee secure accurate time of a large scale.

Without accurate time you have too fool around to make it work. And without
a serious security analysis, you will only find out what it means to rely
on a best effort time service when the security of your system is broken
(or a security researcher gives a nice presentation on a security conference).

Note that just saving the time to flahs is very likely to break DNSSEC. Many
zones have very short lifetimes (in the order of weeks). So if the device
is off for a couple of weeks, the local time will be before the start time
of the signature and DNSSEC validation will fail.

My guess is that as letsencrypt is becoming more wide spread, having a clock
off by a couple of months will also cause issues there.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet