Anyone from GoDaddy here?

[Mark Andrews]

Can you please explain why you do not acknowledge reports of your
nameservers being broken.

Can you please explain why you are are blocking EDNS 1 queries over
IPv4 when your servers are clearly capable of handling them over
IPv6?

Can you please explain why your servers mishandle EDNS flags?  What
part of the following is unclear.  You *send* replies.  The flag
bits should be empty in the replies even if they are set in the
request.  You obviously are not ignore them as you echo them back
(IPv6) or drop the query (IPv4).  This will make the flag bits less
useful when they are finally defined as no one will be able to
depend on the bits not being echoed.  We already have a flag bit
where we can't depend on its return state (AD) because too many
server just echo it.  We do not need this to happen to any other
bits.

   Z
  Set to zero by senders and ignored by receivers, unless modified
  in a subsequent specification.

Mark

Checking: 'utahtrust.gov' as at 2016-10-09T22:37:30Z

utahtrust.gov @216.69.185.50 (pdns01.domaincontrol.com.): edns=ok edns1=timeout 
edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=timeout docookie=ok 
edns@512tcp=ok optlist=nsid,subnet
utahtrust.gov @2607:f208:207::32 (pdns01.domaincontrol.com.): edns=ok edns1=ok 
edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=mbz docookie=ok 
edns@512tcp=ok optlist=nsid,subnet
utahtrust.gov @208.109.255.50 (pdns02.domaincontrol.com.): edns=ok 
edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=timeout 
docookie=ok edns@512tcp=ok optlist=nsid,subnet
utahtrust.gov @2607:f208:303::32 (pdns02.domaincontrol.com.): edns=ok edns1=ok 
edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=mbz docookie=ok 
edns@512tcp=ok optlist=nsid,subnet
The Following Tests Failed

Warning: test failures may indicate that some DNS clients cannot resolve the 
zone or will get a unintended answer or resolution will be slower than 
necessary.

Warning: failure to address issues identified here may make future DNS 
extensions that you want to use ineffective. In particular echoing back unknown 
EDNS options and unknown EDNS flags will break future signaling between DNS 
client and DNS server. We already have examples of this were you cannot depend 
on the AD flag bit meaning anything in replies because too many DNS servers 
just echo it back. Similarly the EDNS Client Subnet (ECS) option cannot just be 
sent to everyone in part because of servers just echoing it back.

EDNS - Unknown Version Handling (edns1)

dig +nocookie +norec +noad +edns=1 +noednsneg soa zone @server
expect: BADVERS
expect: OPT record with version set to 0
expect: not to see SOA
See RFC6891, 6.1.3. OPT Record TTL Field Use

EDNS - Unknown Version with Unknown Option Handling (edns1opt)

dig +nocookie +norec +noad +edns=1 +noednsneg +ednsopt=100 soa zone @server
expect: BADVERS
expect: OPT record with version set to 0
expect: not to see SOA
expect: that the option will not be present in response
See RFC6891

EDNS - Unknown Flag Handling (ednsflags)

dig +nocookie +norec +noad +ednsflags=0x80 soa zone @server
expect: SOA
expect: NOERROR
expect: OPT record with version set to 0
expect: Z bits to be clear in response
See RFC6891, 6.1.4 Flags

Codes

ok - test passed.
nsid - NSID supported [RFC5001].
subnet - EDNS Client Subnet supported [RFC7871].
mbz - EDNS flags echoed back.
timeout - lookup timed out.
To retrieve this report in the future: 
https://ednscomp.isc.org/ednscomp/79f338bd47


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:  +61 2 9871 4742  INTERNET: ma...@isc.org

Re: IoT security, was Krebs on Security booted off Akamai network

[bzs]

On October 9, 2016 at 20:24 m...@beckman.org (Mel Beckman) wrote:
 > You might as well wish for fingerprint readers. It's not going to happen, 
 > and thus can't be remedied. But there are already acceptable COTS solutions 
 > that need no special hardware.  IoT vendors simply have to use them. 

Ok, let them go for that, or not.

But I well remember proposed spam mitigations back in 2000 being just
as forcefully shot down because IT WOULD TAKE A DECADE TO IMPLEMENT
THAT!!!

That was 16 years ago.

It's a dumb sort of thing to waste people's time posting, whether it's
attractive or not will stand on its own merits and not someone arguing
that in their opinion (based on who knows what) market penetration is
insurmountable.

And many smart phones do have fingerprint readers and have for a few
years now, so do quite a few keyboards. My trackpad on my 4 year old
laptop has one (Aspire 8930G.)

Your point is several years too late already.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: IoT security, was Krebs on Security booted off Akamai network

[Mel Beckman]

You might as well wish for fingerprint readers. It's not going to happen, and 
thus can't be remedied. But there are already acceptable COTS solutions that 
need no special hardware.  IoT vendors simply have to use them. 

 -mel beckman

> On Oct 9, 2016, at 1:20 PM, "b...@theworld.com"  wrote:
> 
> 
>> On October 9, 2016 at 20:07 m...@beckman.org (Mel Beckman) wrote:
>> Barry,
>> 
>> The problem isn't authentication during initial installation, since that can 
>> be done using SSL and a web login to the cloud service. The problem is that 
>> vendors aren't even using minimal security protections, such as SSL, and 
>> then leaving devices open to inbound connections, which is bad even behind a 
>> firewall (because viruses typically scan LANs for these vulnerable devices). 
>> These are the devices exploited by hackers to become DDoS attack vectors.
> 
> It helps solve the bad (including manufacturer's default) password
> problem which was one of the attack vectors.
> 
> The proposal only forces this to be used during initial installation
> and configuration (and any reconfig) arguing that it so lowers the
> threshold, just swipe a magstripe, there's really no excuse. And
> eliminates the owner choosing a password for the device, bad or
> otherwise.
> 
> But, again, alas no swipe hardware. Big historical error I think but
> rectifying is feasible.
> 
> -- 
>-Barry Shein
> 
> Software Tool & Die| b...@theworld.com | 
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*

Re: IoT security, was Krebs on Security booted off Akamai network

[bzs]

On October 9, 2016 at 20:07 m...@beckman.org (Mel Beckman) wrote:
 > Barry,
 > 
 > The problem isn't authentication during initial installation, since that can 
 > be done using SSL and a web login to the cloud service. The problem is that 
 > vendors aren't even using minimal security protections, such as SSL, and 
 > then leaving devices open to inbound connections, which is bad even behind a 
 > firewall (because viruses typically scan LANs for these vulnerable devices). 
 > These are the devices exploited by hackers to become DDoS attack vectors. 

It helps solve the bad (including manufacturer's default) password
problem which was one of the attack vectors.

The proposal only forces this to be used during initial installation
and configuration (and any reconfig) arguing that it so lowers the
threshold, just swipe a magstripe, there's really no excuse. And
eliminates the owner choosing a password for the device, bad or
otherwise.

But, again, alas no swipe hardware. Big historical error I think but
rectifying is feasible.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: IoT security, was Krebs on Security booted off Akamai network

[Mel Beckman]

Barry,

The problem isn't authentication during initial installation, since that can be 
done using SSL and a web login to the cloud service. The problem is that 
vendors aren't even using minimal security protections, such as SSL, and then 
leaving devices open to inbound connections, which is bad even behind a 
firewall (because viruses typically scan LANs for these vulnerable devices). 
These are the devices exploited by hackers to become DDoS attack vectors. 

 -mel beckman

> On Oct 9, 2016, at 1:02 PM, "b...@theworld.com"  wrote:
> 
> 
> Elsewhere, for decades, I've bemoaned the fact that keyboards (etc)
> don't have credit card swipes (perhaps today "and chip readers") so
> with some care on the part of the software someone could prove they
> likely have physical access to the card.
> 
> But it would be very useful in this IoT problem.
> 
> You power up a new device, it won't enable until you run some web
> (e.g.) interface.
> 
> At that point you swipe a card which generates a hash which secures
> the IoT device from further config until it's presented again. The
> device can have the usual reset to factory config button for the case
> of lost cards.
> 
> It needn't even be an active credit card. It could be an old spent
> gift card. It could even be a free card that comes right in the box
> tho that might invite predictability, but maybe a basket of cards to
> use at the checkout counter "take one you'll need it for setup".
> 
> The software just has to be able to read the magstripe or chip and use
> the info to generate a reasonably secure hash which is stored
> (preferably in the device.)
> 
> Need to reconfig, open the window, swipe the same card.
> 
> Hotel safes often use this approach as an alternative to PIN entry.
> 
> The device doesn't store any info about the card directly, only the
> hash. And as I said it could be most anything that looks like a credit
> card and has a readable mag stripe.
> 
> The user doesn't have to come up with a password and can't use the
> device until a hash is stored.
> 
> But, alas, no swipes...
> 
> -- 
>-Barry Shein
> 
> Software Tool & Die| b...@theworld.com | 
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*

Re: IoT security, was Krebs on Security booted off Akamai network

[bzs]

Elsewhere, for decades, I've bemoaned the fact that keyboards (etc)
don't have credit card swipes (perhaps today "and chip readers") so
with some care on the part of the software someone could prove they
likely have physical access to the card.

But it would be very useful in this IoT problem.

You power up a new device, it won't enable until you run some web
(e.g.) interface.

At that point you swipe a card which generates a hash which secures
the IoT device from further config until it's presented again. The
device can have the usual reset to factory config button for the case
of lost cards.

It needn't even be an active credit card. It could be an old spent
gift card. It could even be a free card that comes right in the box
tho that might invite predictability, but maybe a basket of cards to
use at the checkout counter "take one you'll need it for setup".

The software just has to be able to read the magstripe or chip and use
the info to generate a reasonably secure hash which is stored
(preferably in the device.)

Need to reconfig, open the window, swipe the same card.

Hotel safes often use this approach as an alternative to PIN entry.

The device doesn't store any info about the card directly, only the
hash. And as I said it could be most anything that looks like a credit
card and has a readable mag stripe.

The user doesn't have to come up with a password and can't use the
device until a hash is stored.

But, alas, no swipes...

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Large Hadron Collider]

Sorry florian. Meant to put it to list.


On 2016-10-09 12:25 PM, Large Hadron Collider wrote:



On 2016-10-09 04:20 AM, Florian Weimer wrote:

* Eliot Lear:


Not my end goal.  My end goal is that consumers have a means to limit
risk in their home environments, and service providers have a means to
deliver that to them.

They already have, with today's technology.  It's just not a
mass-market business.  Consumers either have to educate themselves
(which is not that hard), and service providers need to provide actual
service, instead charging a fee for access to a computer system.

There is little interest in this, however.  There's a comparable
business case for providing managed PCs to consumers, and I'm not sure
if any such companies are still left.
I'd wager that after the Indian tech support fucks, they've went like 
"too risky"


But yeah there's a good case. If I had it in me I'd hire a bunch of 
people to manage consumers' managed PCs.



I'm not convinced that expected traffic profiles are the right answer.
We already have that in the server hosting market, and it does
constraint the types of services you can run on hosted servers (for
the hosting providers who does this).  I'm wary of the network putting
severe constraints on application architecture, way beyond what is
dictated by current technology.  NAT more or less killed servers on
consumer networks, and this kind of traffic profiling has begun to
kill clients on server networks.

The whole point of MUD is to leave control in the hands of those who
have developed and have to support Things.  It is not simply for the SP
to decide what traffic is ok, or to charge more for it, but to respect
the wishes of the developers.  That may be sufficient to stop a lot of
bad things from happening to a lot of Things.

Nobody respects what developers want, otherwise we wouldn't have any
shipping products at all.

What I'm trying to say: Cutting corners is more often a
non-development decision.  If you can ship today without any security,
or at some unknowable date in the future, with additional security
features whose impact may not matter, things usually head for the
earlier shipping date.

I used to be frustrated by such decisions, but over the past few
years, I've come to realize that most of us have so little data on the
effectiveness of security features that mandates for them are
essentially arbitrary.


And again, this is the wrong way to look at it.  The consumer should
always get final say.  They're the customer.  This is a chance for the
manufacturer of the device they're using to explain how the device is
supposed to behave on the network.

If we want to make consumers to make informed decisions, they need to
learn how things work up to a certain level.  And then current
technology already works.

(Sorry that I'm not inclined to read upon the specs—I do wonder how
this an improvement over UPnP.)

Re: IoT security, was Krebs on Security booted off Akamai network

[Large Hadron Collider]

On 2016-10-09 08:33 AM, Stephen Satchell wrote:

On 10/09/2016 07:31 AM, Mel Beckman wrote:

remote RF temperature sensor hub for home, the GW-1000U.
...
The device accepts TCP connections on 22, 80, and 443.  Theoretically
I can't see why it ever needs ongoing inbound connections, so this
seems to be a security concession made by the maker. Also, it appears
to support SSL, but uses plaintext. Why? Because it's easier to debug
in the early deployments, I'll wager. But the thing has been out for
years and they're still not using encryption, even though the device
apparently has the ability.

I could see one reason, and one reason only:  to allow the customer to
use a "control panel" with a local computer, smartphone app, or tablet
app to set capabilities, options, and preferences.  That said, the
manufacturer probably thought that the sensor would be shielded from the
Internet by a Wireless Access Point with NAT, so that there would be no
direct exposure (in theory) to inbound connections from the outside world.

For IPv4, this is barely tolerable.  For IPv6, not so much.
For v6, what I'd do is firewall all but the safest (SIP, RTP basically) 
of out-of-local-network(s) inbounds to the device unless you visit an 
intranet webpage from the device that allows you to open all inbound. 
The page would be a one time deal (would survive across reinstalls as 
long as the router remembers you) and would record your MAC address. It 
would ask "You hereby agree that your device's connection security is 
your responsibility and only your responsibility. You hereby indemnify 
and hold harmless the owner of the network infrastructure for [bla de 
bla legal jargon basically don't sue if yer hakt]. Would you like to 
open blocked inbound connections? [Yes / Oui / Да] [No / Non / Нет]"


As a developer, I can tell you that "easier to debug in the early
deployments" means that the later deployments won't be locked down until
the manufacturer gets a fine, judgement, or other monetary hit.

Would you put this thing on a DMZ?  I thought not...   :)
I wouldn't even put a well-secured desktop running all the best 
firewalling in a TNZ (trusted network zone, term I think is less 
misleading than DMZ, referring to a state of being unfirewalled)

Re: IoT security, was Krebs on Security booted off Akamai network

[Florian Weimer]

* John R. Levine:

> On Sun, 9 Oct 2016, Florian Weimer wrote:
>
>> If we want to make consumers to make informed decisions, they need to
>> learn how things work up to a certain level.  And then current
>> technology already works.
>
> I think it's fair to say that security through consumer education has
> been a failure every time anyone has tried it.  Why do you think this
> would be any different?

People start to care once they have to.  Currently, there is not much
reason to worry about which devices you connect to your home network.
Even the interaction with Internet banking appears to be benign these
days.

If your Internet connection goes down because something starts spewing
packets, you can probably find it by disconnecting everything until
you have found the culprit.  It's probably not much different from how
you find which device triggers the breaker.

Anything that's more proactive requires some level of knowledge, and
if we assume that it cannot be dispersed to consumers, then it means
someone else gets to manage their home networks.  And I'm not sure if
the ISPs should be doing this (or if they want any part in this, maybe
except if it enables them to charge per connected device and
function).

>> There is little interest in this, however.  There's a comparable
>> business case for providing managed PCs to consumers, and I'm not sure
>> if any such companies are still left.
>
> There's at least two large ones: Microsoft and Apple.  Try installing
> Windows 10 without letting Microsoft update and reconfigure the
> software any time they want, any way they want.

I don't think I can phone Microsoft if something goes wrong.  In most
countries, they even disclaim responsiblity for breakage introduced by
updates and point to the PC makers instead (from whom most consumers
baught their OEM version).

Apple may be different.

> Expecting consumers to evaluate the security behavior of their
> lightbulbs and their refrigerator is absurd.  We need to figure out
> how to have the devices and routers configure themselves so the
> devices can do what they need to do without doing what we really don't
> want them to do.

We already have UPnP.  Clearly, it does not work, but it's not obvious
to me why any different solution would end up as being just as
ineffective.

Re: IoT security, was Krebs on Security booted off Akamai network

[Mel Beckman]

The idea behind IoT is that devices collect data, but the power to process that 
data, and archive it, is in the cloud. 

 -mel beckman

> On Oct 9, 2016, at 11:30 AM, "valdis.kletni...@vt.edu" 
>  wrote:
> 
> On Sun, 09 Oct 2016 18:05:20 -, Mel Beckman said:
>> I don't know why it's "sub optimal" to use the cloud from an isolated 
>> network. Can you elaborate?
> 
> Why should something out in the cloud have any part of the communication,
> other than perhaps telling your cellphone the current address of your widget?
> 
> (And *that* should probably have a standardized protocol/service rather than
> every vendor rolling their own.  Hello, IETF?)
> 
> And even *that* can be bypassed if you cellphone is able to talk to your
> home network directly.

Re: IoT security, was Krebs on Security booted off Akamai network

[Jim Shankland]

On 10/9/16 11:30 AM, valdis.kletni...@vt.edu wrote:

On Sun, 09 Oct 2016 18:05:20 -, Mel Beckman said:

I don't know why it's "sub optimal" to use the cloud from an isolated network. 
Can you elaborate?

Why should something out in the cloud have any part of the communication,
other than perhaps telling your cellphone the current address of your widget?

(And *that* should probably have a standardized protocol/service rather than
every vendor rolling their own.  Hello, IETF?)

And even *that* can be bypassed if you cellphone is able to talk to your
home network directly.


A fair question, if it's intended rhetorically. If not, then the short 
answer is: because monetizing your personal information is a large 
(possibly dominant) part of the IoT business model, today.


Rampant security holes don't necessarily perturb that model excessively 
-- though goodness knows they should, and maybe eventually they will. In 
the meantime, we have what Zeynep Tufekci has called the "Internet of 
Hacked Things" (anybody want to help get the acronym IoHT into general 
currency?).


Jim

Re: IoT security, was Krebs on Security booted off Akamai network

[Valdis . Kletnieks]

On Sun, 09 Oct 2016 18:05:20 -, Mel Beckman said:
> I don't know why it's "sub optimal" to use the cloud from an isolated 
> network. Can you elaborate?

Why should something out in the cloud have any part of the communication,
other than perhaps telling your cellphone the current address of your widget?

(And *that* should probably have a standardized protocol/service rather than
every vendor rolling their own.  Hello, IETF?)

And even *that* can be bypassed if you cellphone is able to talk to your
home network directly.


pgp9pPLyIgpzK.pgp
Description: PGP signature

Re: IoT security, was Krebs on Security booted off Akamai network

[Mel Beckman]

I don't know why it's "sub optimal" to use the cloud from an isolated network. 
Can you elaborate?

 -mel beckman

> On Oct 9, 2016, at 10:28 AM, "valdis.kletni...@vt.edu" 
>  wrote:
> 
> On Sun, 09 Oct 2016 14:31:54 -, Mel Beckman said:
> 
>> I just bought a $20 Lacrosse remote RF temperature sensor hub for home, the
>> GW-1000U. It does the usual IoT things: after you plug it in, it gets a DHCP
>> address and phones home, then you register it using a smartphone on the same
>> LAN, which I'm guessing finds the device via a broadcast and then configures
>> the hub with my Lacrosse account info. All communication is thereafter 
>> through
>> the cloud.
> 
> That last sentence is sub-optimal.  And as you note, things go downhill from
> there

Re: IoT security, was Krebs on Security booted off Akamai network

[Valdis . Kletnieks]

On Sun, 09 Oct 2016 14:31:54 -, Mel Beckman said:

> I just bought a $20 Lacrosse remote RF temperature sensor hub for home, the
> GW-1000U. It does the usual IoT things: after you plug it in, it gets a DHCP
> address and phones home, then you register it using a smartphone on the same
> LAN, which I'm guessing finds the device via a broadcast and then configures
> the hub with my Lacrosse account info. All communication is thereafter through
> the cloud.

That last sentence is sub-optimal.  And as you note, things go downhill from
there


pgpkoGOH38QLq.pgp
Description: PGP signature

Re: IoT security, was Krebs on Security booted off Akamai network

[Mel Beckman]

Stephen,

But they don’t, in fact, allow such a console. And I don’t think such a thing 
is even a good idea on IoT devices, because permitting inbound connections is a 
pathway to exploitation. 

As I noted in my post, I’ve put it on its own VLAN, which is better than a DMZ: 
no inbound access at all, and no access to any other network or devices. I only 
permit port 80 outbound to the Lacrosse cloud server, and will get notified of 
any other traffic.

But this is a wired device, which made it easier to sequester. If it were WiFi 
my task would have been much harder, and most IoT devices do seem to be WiFi.

 -mel

> On Oct 9, 2016, at 8:33 AM, Stephen Satchell  wrote:
> 
> On 10/09/2016 07:31 AM, Mel Beckman wrote:
>> remote RF temperature sensor hub for home, the GW-1000U.
>> ...
>> The device accepts TCP connections on 22, 80, and 443.  Theoretically
>> I can't see why it ever needs ongoing inbound connections, so this
>> seems to be a security concession made by the maker. Also, it appears
>> to support SSL, but uses plaintext. Why? Because it's easier to debug
>> in the early deployments, I'll wager. But the thing has been out for
>> years and they're still not using encryption, even though the device
>> apparently has the ability.
> 
> I could see one reason, and one reason only:  to allow the customer to
> use a "control panel" with a local computer, smartphone app, or tablet
> app to set capabilities, options, and preferences.  That said, the
> manufacturer probably thought that the sensor would be shielded from the
> Internet by a Wireless Access Point with NAT, so that there would be no
> direct exposure (in theory) to inbound connections from the outside world.
> 
> For IPv4, this is barely tolerable.  For IPv6, not so much.
> 
> As a developer, I can tell you that "easier to debug in the early
> deployments" means that the later deployments won't be locked down until
> the manufacturer gets a fine, judgement, or other monetary hit.
> 
> Would you put this thing on a DMZ?  I thought not...   :)

Re: IoT security, was Krebs on Security booted off Akamai network

[Stephen Satchell]

On 10/09/2016 07:31 AM, Mel Beckman wrote:
> remote RF temperature sensor hub for home, the GW-1000U.
> ...
> The device accepts TCP connections on 22, 80, and 443.  Theoretically
> I can't see why it ever needs ongoing inbound connections, so this
> seems to be a security concession made by the maker. Also, it appears
> to support SSL, but uses plaintext. Why? Because it's easier to debug
> in the early deployments, I'll wager. But the thing has been out for
> years and they're still not using encryption, even though the device
> apparently has the ability.

I could see one reason, and one reason only:  to allow the customer to
use a "control panel" with a local computer, smartphone app, or tablet
app to set capabilities, options, and preferences.  That said, the
manufacturer probably thought that the sensor would be shielded from the
Internet by a Wireless Access Point with NAT, so that there would be no
direct exposure (in theory) to inbound connections from the outside world.

For IPv4, this is barely tolerable.  For IPv6, not so much.

As a developer, I can tell you that "easier to debug in the early
deployments" means that the later deployments won't be locked down until
the manufacturer gets a fine, judgement, or other monetary hit.

Would you put this thing on a DMZ?  I thought not...   :)

Re: IoT security, was Krebs on Security booted off Akamai network

[Mel Beckman]

I just bought a $20 Lacrosse remote RF temperature sensor hub for home, the 
GW-1000U. It does the usual IoT things: after you plug it in, it gets a DHCP 
address and phones home, then you register it using a smartphone on the same 
LAN, which I'm guessing finds the device via a broadcast and then configures 
the hub with my Lacrosse account info. All communication is thereafter through 
the cloud. 

 It set itself up quite conveniently and efficiently, and now will start 
charging me $12/year for alerts and texts. An acceptable business model.

Except the thing is a teaming mass of security vulnerabilities. 

How much authentication went on in this process? None. I captured the thing's 
packets in my firewall's onboard sniffer from the get go. All data is exchanged 
as plaintext on port 80. The protocol is completely undocumented, but I've 
since discovered that at least one enterprising tinkerer has reverse engineered 
it so people can bypass the manufacturer's monetization model. 

The device accepts TCP connections on 22, 80, and 443.  Theoretically I can't 
see why it ever needs ongoing inbound connections, so this seems to be a 
security concession made by the maker. Also, it appears to support SSL, but 
uses plaintext. Why? Because it's easier to debug in the early deployments, 
I'll wager. But the thing has been out for years and they're still not using 
encryption, even though the device apparently has the ability.

As a knowledgable consumer (and security researcher) I'll overcome these 
shortcomings by putting this device on its own VLAN with extensive firewalling. 
Still, I can't be sure it won't be malicious, or get exploited through the 
cloud. And VLANs have their own security weaknesses, despite my using pricey 
enterprise hardware at home. 

My point is that if an expert has to expend several hours of highly technical 
labor to "responsibly" use a $20 IoT sensor, and use enterprise-grade IT gear 
and methods to gain even a modicum of safety, then what hope do Ma and Pa 
Kettle have? 

This is not a consumer education problem, unless we think consumers should also 
learn  thermodynamics in order to drive, the Bernoulli principle in order to be 
airline passengers, and biochemistry to cook their own food. It's clearly a 
giant screw-up by manufacturers who could easily spread the cost of 
best-practice security measures across a large customer base.

That they don't shows lack of moral character, and nothing else. 

 -mel beckman

> On Oct 9, 2016, at 7:03 AM, John R. Levine  wrote:
> 
>> On Sun, 9 Oct 2016, Florian Weimer wrote:
>> 
>> If we want to make consumers to make informed decisions, they need to
>> learn how things work up to a certain level.  And then current
>> technology already works.
> 
> I think it's fair to say that security through consumer education has been a 
> failure every time anyone has tried it.  Why do you think this would be any 
> different?
> 
>> There is little interest in this, however.  There's a comparable
>> business case for providing managed PCs to consumers, and I'm not sure
>> if any such companies are still left.
> 
> There's at least two large ones: Microsoft and Apple.  Try installing Windows 
> 10 without letting Microsoft update and reconfigure the software any time 
> they want, any way they want.
> 
> Expecting consumers to evaluate the security behavior of their lightbulbs and 
> their refrigerator is absurd.  We need to figure out how to have the devices 
> and routers configure themselves so the devices can do what they need to do 
> without doing what we really don't want them to do.
> 
> Regards,
> John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for 
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

Re: IoT security, was Krebs on Security booted off Akamai network

[John R. Levine]

On Sun, 9 Oct 2016, Florian Weimer wrote:


If we want to make consumers to make informed decisions, they need to
learn how things work up to a certain level.  And then current
technology already works.


I think it's fair to say that security through consumer education has been 
a failure every time anyone has tried it.  Why do you think this would be 
any different?



There is little interest in this, however.  There's a comparable
business case for providing managed PCs to consumers, and I'm not sure
if any such companies are still left.


There's at least two large ones: Microsoft and Apple.  Try installing 
Windows 10 without letting Microsoft update and reconfigure the software 
any time they want, any way they want.


Expecting consumers to evaluate the security behavior of their lightbulbs 
and their refrigerator is absurd.  We need to figure out how to have the 
devices and routers configure themselves so the devices can do what they 
need to do without doing what we really don't want them to do.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Florian Weimer]

* Eliot Lear:

> Not my end goal.  My end goal is that consumers have a means to limit
> risk in their home environments, and service providers have a means to
> deliver that to them.

They already have, with today's technology.  It's just not a
mass-market business.  Consumers either have to educate themselves
(which is not that hard), and service providers need to provide actual
service, instead charging a fee for access to a computer system.

There is little interest in this, however.  There's a comparable
business case for providing managed PCs to consumers, and I'm not sure
if any such companies are still left.

>> I'm not convinced that expected traffic profiles are the right answer.
>> We already have that in the server hosting market, and it does
>> constraint the types of services you can run on hosted servers (for
>> the hosting providers who does this).  I'm wary of the network putting
>> severe constraints on application architecture, way beyond what is
>> dictated by current technology.  NAT more or less killed servers on
>> consumer networks, and this kind of traffic profiling has begun to
>> kill clients on server networks.
>
> The whole point of MUD is to leave control in the hands of those who
> have developed and have to support Things.  It is not simply for the SP
> to decide what traffic is ok, or to charge more for it, but to respect
> the wishes of the developers.  That may be sufficient to stop a lot of
> bad things from happening to a lot of Things.

Nobody respects what developers want, otherwise we wouldn't have any
shipping products at all.

What I'm trying to say: Cutting corners is more often a
non-development decision.  If you can ship today without any security,
or at some unknowable date in the future, with additional security
features whose impact may not matter, things usually head for the
earlier shipping date.

I used to be frustrated by such decisions, but over the past few
years, I've come to realize that most of us have so little data on the
effectiveness of security features that mandates for them are
essentially arbitrary.

> And again, this is the wrong way to look at it.  The consumer should
> always get final say.  They're the customer.  This is a chance for the
> manufacturer of the device they're using to explain how the device is
> supposed to behave on the network.

If we want to make consumers to make informed decisions, they need to
learn how things work up to a certain level.  And then current
technology already works.

(Sorry that I'm not inclined to read upon the specs—I do wonder how
this an improvement over UPnP.)