Re: Spitballing IoT Security

[Roland Dobbins]

On 30 Oct 2016, at 7:32, Ronald F. Guilmette wrote:

 you don't need to be either an omnious "state actor" or even SPECTER 
to assemble a truly massive packet weapon.


I agree:



;>

Two kids with a modest amount of knowledge and a lot of time on their 
hands can do it from their mom's basement.


And indeed have done so, many times.

The *entire purpose* of Mirai is DDoS-for-hire - it's a foundation for 
so-called 'booter/stresser' services.  So, the various  articles about 
how these botnets 'might' be for sale are uninformed - they're *for 
rent*, that's their raison d'être.


And renting them is cheap.  The economic and resource asymmetries highly 
favor the attackers.


All the speculation about how 'state actors' are somehow 'learning how 
to take down the Internet' is equally uninformed.  State actors already 
know how to do this, they don't need to 'learn' or 'test' anything.


DDoS attacks are the Great Equalizer; when it comes to DDoS, 
nation-states are just another player.


---
Roland Dobbins 

Re: Spitballing IoT Security

[Eliot Lear]

Moving offlist on this. For those who are interested, send ping.


On 11/11/16 4:42 PM, Marcel Plug wrote:
> On Fri, Nov 11, 2016 at 1:55 AM, Eliot Lear  > wrote:
>
> It is worth asking what protections are necessary for a device that
> regulates insulin.  
>
>
> Insulin pumps are an example of devices that have been over-regulated
> to the point where any and all innovation has been stifled.  There
> have been hardly any changes in the last 10+ years, during a time when
> all other technology has advanced quite a bit.  Its off-topic for
> Nanog, but i promise you this is very frustrating and annoying topic
> that hits me close to home.
>
> There has to be a middle ground.  I guarantee we do not want home
> firewalls, and all the IoT devices to be regulated like insulin pumps
> and other medical devices.  I think I'm starting to agree with those
> that want to keep government regulation out of this arena...
>
> Marcel
>  
>
> Eliot
>
>
> On 11/8/16 6:05 AM, Ronald F. Guilmette wrote:
> > In message <20161108035148.2904b5970...@rock.dv.isc.org
> >,
> > Mark Andrews > wrote:
> >
> >> * Deploying regulation in one country means that it is less likely
> >>  to be a source of bad traffic.  Manufactures are lazy.  With
> >>  sensible regulation in single country everyone else benefits as
> >>  manufactures will use a single code base when they can.
> > I said that too, although not as concisely.
> >
> >> * Automated updates do reduce the numbers of vulnerable machines
> >>  to known issues.  There are risks but they are nowhere as bad as
> >>  not doing automated updating.
> > I still maintain, based upon the abundant evidence, that
> generallized
> > hopes that timely and effective updates for all manner of
> devices will
> > be available throughout the practical lifetime of any such IoT
> thingies
> > is a mirage.  We will just never be there, in practice.  And thus,
> > manufacturers should be encouraged, by force of law if necessary, to
> > design software with a belt-and-suspenders margin of safety built in
> > from the first day of shipping.
> >
> > You don't send out a spacecraft, or a medical radiation machine,
> without
> > such addtional constraints built in from day one.  You don't
> send out
> > such things and say "Oh, we can always send out of firmware
> update later
> > on if there is an issue."
> >
> > From a software perspective, building extra layers of
> constraints is not
> > that hard to do, and people have been doing this kind of thing
> already
> > for decades.  It's called engineering.  The problem isn't in
> anybody's
> > ability or inability to do safety engineering in the firmware of IoT
> > things.  The only problem is providing the proper motivation to
> cause
> > it to happen.
> >
> >
> > Regards,
> > rfg
> >
>
>
>



signature.asc
Description: OpenPGP digital signature

Re: Spitballing IoT Security

[Marcel Plug]

On Fri, Nov 11, 2016 at 1:55 AM, Eliot Lear 
wrote:

> It is worth asking what protections are necessary for a device that
> regulates insulin.


Insulin pumps are an example of devices that have been over-regulated to
the point where any and all innovation has been stifled.  There have been
hardly any changes in the last 10+ years, during a time when all other
technology has advanced quite a bit.  Its off-topic for Nanog, but i
promise you this is very frustrating and annoying topic that hits me close
to home.

There has to be a middle ground.  I guarantee we do not want home
firewalls, and all the IoT devices to be regulated like insulin pumps and
other medical devices.  I think I'm starting to agree with those that want
to keep government regulation out of this arena...

Marcel


> Eliot
>
>
> On 11/8/16 6:05 AM, Ronald F. Guilmette wrote:
> > In message <20161108035148.2904b5970...@rock.dv.isc.org>,
> > Mark Andrews  wrote:
> >
> >> * Deploying regulation in one country means that it is less likely
> >>  to be a source of bad traffic.  Manufactures are lazy.  With
> >>  sensible regulation in single country everyone else benefits as
> >>  manufactures will use a single code base when they can.
> > I said that too, although not as concisely.
> >
> >> * Automated updates do reduce the numbers of vulnerable machines
> >>  to known issues.  There are risks but they are nowhere as bad as
> >>  not doing automated updating.
> > I still maintain, based upon the abundant evidence, that generallized
> > hopes that timely and effective updates for all manner of devices will
> > be available throughout the practical lifetime of any such IoT thingies
> > is a mirage.  We will just never be there, in practice.  And thus,
> > manufacturers should be encouraged, by force of law if necessary, to
> > design software with a belt-and-suspenders margin of safety built in
> > from the first day of shipping.
> >
> > You don't send out a spacecraft, or a medical radiation machine, without
> > such addtional constraints built in from day one.  You don't send out
> > such things and say "Oh, we can always send out of firmware update later
> > on if there is an issue."
> >
> > From a software perspective, building extra layers of constraints is not
> > that hard to do, and people have been doing this kind of thing already
> > for decades.  It's called engineering.  The problem isn't in anybody's
> > ability or inability to do safety engineering in the firmware of IoT
> > things.  The only problem is providing the proper motivation to cause
> > it to happen.
> >
> >
> > Regards,
> > rfg
> >
>
>
>

Re: Spitballing IoT Security

[Eliot Lear]

This is, amongst other things, an epidemiological problem.  We've known
through practical experience since 1989 that worms can spread at the
speed of light.  And so neither an auto-update process nor BCP 38
filtering alone will stop infection.  There may be ways like MUD to slow
an infection, but even MUD won't be enough in circumstances when device
Bob is attacking Sally on an authorized port.  MUD might have prevented
Bob from being infected in the first place, but not if the infection
came via USB key (for instance).

In some of these circumstances where it is critical, one may wish to go
"up stack" with an auditing function in the form of an application-layer
gateway functionality that examines the semantics of a transaction and
lets the good ones through.  But that in itself carries risks in several
dimensions, the first of which being that the auditor is compromised,
the second of which is that the auditor may misinterpret the semantics,
and consequently slow the pace of deployment of new code.  From an
SP/Consumer perspective, I expect this case will be rare.

It is worth asking what protections are necessary for a device that
regulates insulin.  Along these lines I've written a very DRAFTY draft
called draft-lear-network-helps-01 that discusses these sorts of
situations.  That draft needs work and co-authors, perhaps.

Eliot


On 11/8/16 6:05 AM, Ronald F. Guilmette wrote:
> In message <20161108035148.2904b5970...@rock.dv.isc.org>, 
> Mark Andrews  wrote:
>
>> * Deploying regulation in one country means that it is less likely
>>  to be a source of bad traffic.  Manufactures are lazy.  With
>>  sensible regulation in single country everyone else benefits as
>>  manufactures will use a single code base when they can.
> I said that too, although not as concisely.
>
>> * Automated updates do reduce the numbers of vulnerable machines
>>  to known issues.  There are risks but they are nowhere as bad as
>>  not doing automated updating.
> I still maintain, based upon the abundant evidence, that generallized
> hopes that timely and effective updates for all manner of devices will
> be available throughout the practical lifetime of any such IoT thingies
> is a mirage.  We will just never be there, in practice.  And thus,
> manufacturers should be encouraged, by force of law if necessary, to
> design software with a belt-and-suspenders margin of safety built in
> from the first day of shipping.
>
> You don't send out a spacecraft, or a medical radiation machine, without
> such addtional constraints built in from day one.  You don't send out
> such things and say "Oh, we can always send out of firmware update later
> on if there is an issue."
>
> From a software perspective, building extra layers of constraints is not
> that hard to do, and people have been doing this kind of thing already
> for decades.  It's called engineering.  The problem isn't in anybody's
> ability or inability to do safety engineering in the firmware of IoT
> things.  The only problem is providing the proper motivation to cause
> it to happen.
>
>
> Regards,
> rfg
>




signature.asc
Description: OpenPGP digital signature

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <20161108035148.2904b5970...@rock.dv.isc.org>, 
Mark Andrews  wrote:

>* Deploying regulation in one country means that it is less likely
>  to be a source of bad traffic.  Manufactures are lazy.  With
>  sensible regulation in single country everyone else benefits as
>  manufactures will use a single code base when they can.

I said that too, although not as concisely.

>* Automated updates do reduce the numbers of vulnerable machines
>  to known issues.  There are risks but they are nowhere as bad as
>  not doing automated updating.

I still maintain, based upon the abundant evidence, that generallized
hopes that timely and effective updates for all manner of devices will
be available throughout the practical lifetime of any such IoT thingies
is a mirage.  We will just never be there, in practice.  And thus,
manufacturers should be encouraged, by force of law if necessary, to
design software with a belt-and-suspenders margin of safety built in
from the first day of shipping.

You don't send out a spacecraft, or a medical radiation machine, without
such addtional constraints built in from day one.  You don't send out
such things and say "Oh, we can always send out of firmware update later
on if there is an issue."

>From a software perspective, building extra layers of constraints is not
that hard to do, and people have been doing this kind of thing already
for decades.  It's called engineering.  The problem isn't in anybody's
ability or inability to do safety engineering in the firmware of IoT
things.  The only problem is providing the proper motivation to cause
it to happen.


Regards,
rfg

Re: Spitballing IoT Security

[Mark Andrews]

In message , Pierre Lamy write
s:
> On 30/10/2016 12:43 AM, Eric S. Raymond wrote:
> > Ronald F. Guilmette :
> >> Two kids with a modest amount of knowledge
> >> and a lot of time on their hands can do it from their mom's basement.
> > 
> > I in turn have to call BS on this.  If it were really that easy, we'd
> > be inundated by Mirais -- we'd have several attacks a *day*.
> > 
> 
> It's not easy, Mirai was closed source until the actor released it. We
> see a pattern again and again, where the bad guys find a private
> monetization strategy, milk it, and get out before too much attention is
> focused on just them. By dumping the code, the Mirai actors obfuscate
> attribution.
> 
> Now that the code is public, we see a huge surge in dumb & pointless
> attacks against gaming/mod sites, Dyn, public schools and so on. We also
> see bad code "improvements" which were recently referenced.
> 
> http://motherboard.vice.com/read/wannabe-hackers-are-adding-terrible-and-stup
> id-features-to-mirai
> 
> The long term problem isn't any manufacturer or Mirai, it's going to be
> the long tail of IoT devices that never see a patch, deployed by people
> who don't know anything about security (nor should they need to... flame
> suit on). When millions of any type of device are put online, times
> thousands of products, it only takes one bad guy's "a-ha" moment for
> this to happen again. They'll milk it for a while, the attack
> vector/method will get pushed down to the skid level, and we'll see a
> massive increase in un-targeted attacks by those script kiddies until
> the cycle repeats. There's an endless fresh supply of script kiddies.
> 
> While I agree with BCP38 etc, it wouldn't have prevented Mirai.
> Self-update functions at some point for these devices are going to get
> borked as well, such as a company going bust or forgetting to renew
> their auto-update target domain. If you can't get (thousands?) of major
> operators to deploy common sense security configurations, how will
> similar best practices be implemented by tens of thousands of
> manufacturers? Putting device regulations in one country won't impact
> the rest of the internet's connected devices either.
> 
> Solutions...? Someone's going to have to take out a hammer, not a
> scalpel, for these issues.

Actually the way forward is to not look for a magical solution that
will stop all evil but to deploy what you can where you can.  This
reduces the problem space.

* Deploying BCP38 means you are no longer a source of spoofed traffic.
  It doesn't help with all issues but it does with some.

* Deploying regulation in one country means that it is less likely
  to be a source of bad traffic.  Manufactures are lazy.  With
  sensible regulation in single country everyone else benefits as
  manufactures will use a single code base when they can.

* Automated updates do reduce the numbers of vulnerable machines
  to known issues.  There are risks but they are nowhere as bad as
  not doing automated updating.

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

Re: Spitballing IoT Security

[Pierre Lamy]

On 30/10/2016 12:43 AM, Eric S. Raymond wrote:
> Ronald F. Guilmette :
>> Two kids with a modest amount of knowledge
>> and a lot of time on their hands can do it from their mom's basement.
> 
> I in turn have to call BS on this.  If it were really that easy, we'd
> be inundated by Mirais -- we'd have several attacks a *day*.
> 

It's not easy, Mirai was closed source until the actor released it. We
see a pattern again and again, where the bad guys find a private
monetization strategy, milk it, and get out before too much attention is
focused on just them. By dumping the code, the Mirai actors obfuscate
attribution.

Now that the code is public, we see a huge surge in dumb & pointless
attacks against gaming/mod sites, Dyn, public schools and so on. We also
see bad code "improvements" which were recently referenced.

http://motherboard.vice.com/read/wannabe-hackers-are-adding-terrible-and-stupid-features-to-mirai

The long term problem isn't any manufacturer or Mirai, it's going to be
the long tail of IoT devices that never see a patch, deployed by people
who don't know anything about security (nor should they need to... flame
suit on). When millions of any type of device are put online, times
thousands of products, it only takes one bad guy's "a-ha" moment for
this to happen again. They'll milk it for a while, the attack
vector/method will get pushed down to the skid level, and we'll see a
massive increase in un-targeted attacks by those script kiddies until
the cycle repeats. There's an endless fresh supply of script kiddies.

While I agree with BCP38 etc, it wouldn't have prevented Mirai.
Self-update functions at some point for these devices are going to get
borked as well, such as a company going bust or forgetting to renew
their auto-update target domain. If you can't get (thousands?) of major
operators to deploy common sense security configurations, how will
similar best practices be implemented by tens of thousands of
manufacturers? Putting device regulations in one country won't impact
the rest of the internet's connected devices either.

Solutions...? Someone's going to have to take out a hammer, not a
scalpel, for these issues.

Re: Spitballing IoT Security

[Doug Barton]

On 10/29/2016 05:32 PM, Ronald F. Guilmette wrote:

you don't need
to be either an omnious "state actor" or even SPECTER to assemble a
truly massive packet weapon.


Please, it's SPECTRE  show some respect

Re: Spitballing IoT Security

[bzs]

Is this report reliable? I don't know off-hand:

  
http://www.csoonline.com/article/3134721/security/amateurs-were-behind-the-dyn-inc-ddos-attack-report-says.html

or:

  http://tinyurl.com/zb9mpy5

  Amateurs were behind the Dyn Inc. DDoS attack, report says

  Flashpoint says that despite speculation, nothing they’ve seen
  points to political motivation or extortion

Here is Flashpoint's actual report link:

  https://www.flashpoint-intel.com/action-analysis-mirai-botnet-attacks-dyn/

or

  http://tinyurl.com/hrhewxg

  "...In its investigation of Dyn DDoS attacks, Flashpoint discovered
  that the infrastructure used in the attack also targeted a
  well-known video game company. While there does not appear to have
  been any disruption of service, the targeting of a video game
  company is less indicative of hacktivists, state-actors, or social
  justice communities, and aligns more with the hackers that frequent
  online hacking forums. These hackers exist in their own tier,
  sometimes called “script kiddies,” and are separate and distinct
  from hacktivists, organized crime, state-actors, and terrorist
  groups. They can be motivated by financial gain, but just as often
  will execute attacks such as these to show off, or to cause
  disruption and chaos for sport..."

  "...Flashpoint assesses with moderate confidence that these attacks
  were not financially or politically motivated..."


P.S. not sure why I include tinyurls other than long URLs tend to get
messed up in some MUAs and on rare occasion one has to retype one in
and tinyurls are tiny.

-- 
-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: Spitballing IoT Security

[Jim Hickstein]

On 10/30/16 06:35, Rich Kulawiec wrote:

On Fri, Oct 28, 2016 at 12:07:17AM -0500, Jim Hickstein wrote:

A virus that kills its host (too much of the time) is not successful.


True.  On the other hand:

"Some men aren't looking for anything logical, like money.
They can't be bought, bullied, reasoned, or negotiated with.
Some men just want to watch the world burn."

I have no doubt whatsoever that some of our adversaries fall squarely
into this category.


i.e. vandalism.

Agreed, and the respondent who brought up rational actors has pointed 
out where the computer "virus" analogy breaks down: biological viruses 
have no rational actor and no premeditated goal.  Their success, as 
usually defined (maximum incidence in a population), emerges from the 
mathematics of their operation.


DDoS attacks are ultimately caused by humans (so far) and while we may 
not know clearly their goals or the values that underlie them, they 
exist.  This would seem to call for a different response.  I wish I knew 
what.

Re: Spitballing IoT Security

[Rich Kulawiec]

On Fri, Oct 28, 2016 at 12:07:17AM -0500, Jim Hickstein wrote:
> A virus that kills its host (too much of the time) is not successful.

True.  On the other hand:

"Some men aren't looking for anything logical, like money.
They can't be bought, bullied, reasoned, or negotiated with.
Some men just want to watch the world burn."

I have no doubt whatsoever that some of our adversaries fall squarely
into this category.

---rsk

Re: Spitballing IoT Security

[John Weekes]

On 10/29/2016 9:43 PM, Eric S. Raymond wrote:

I in turn have to call BS on this.  If it were really that easy, we'd
be inundated by Mirais -- we'd have several attacks a*day*.


Some of us are seeing many significant attacks a day.

That's because botnets are frequently used to hit game servers and game 
players. In fact, the Mirai-targeted devices were not newly-seen; 
easily-exploited devices like older DVRs have been observed for years in 
attacks on game servers. The main difference in the recent botnet 
attacks (mostly, 2016) is that they have been larger and more frequent, 
likely because of incremental improvements to scanners (including in 
time-to-exploitation, which is important to building the botnet because 
these devices are so frequently rebooted) and payloads (to better block 
further exploitation by competitors). If you run a honeypot and take a 
look at what happens to one of these devices over time, you'll see an 
interesting tug-of-war between many different actors that are 
compromising them and running their own binaries.


Reflection attacks are still common, as well, of course. Previously, 
those were the ones that created the largest flows. But, the 
higher-amplification-factor reflection attacks can be mostly mitigated 
upstream with basic ACLs (as long as the upstream is willing to help, 
and has the internal capacity to do it; many NSPs do not). It is not 
uncommon to see a botnet attack at the same time as a reflection attack.


-John

Re: Spitballing IoT Security

[Eric S. Raymond]

Ronald F. Guilmette :
> 
> In message <20161030044342.ga18...@thyrsus.com>, 
> "Eric S. Raymond"  wrote:
> 
> >Ronald F. Guilmette :
> >> Two kids with a modest amount of knowledge
> >> and a lot of time on their hands can do it from their mom's basement.
> >
> >I in turn have to call BS on this.  If it were really that easy, we'd
> >be inundated by Mirais -- we'd have several attacks a *day*.
> 
> 
> You need to get out more.
> 
> http://www.nab.org/cybersecurity/Verisign-report-ddos-trends-Q22016.pdf
> 
> It *is* happening every day.  You just don't hear about it on CNN because
> a "little"  80Mbps DDoS isn't even worthy of a headline anymore, even
> though such an attack could CRUSH a local bank, and even many regional
> banks into utter oblivion.
> 
> Now, where did I put those bitcoins...  It's ransom time!

Don't change the subject.  An effective DDoS against any single site is, though
concerning, not a Mirai-class event. The difference matters, and you shouldn't
be pretending it does to score rhetorical points.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <20161030044342.ga18...@thyrsus.com>, 
"Eric S. Raymond"  wrote:

>Ronald F. Guilmette :
>> Two kids with a modest amount of knowledge
>> and a lot of time on their hands can do it from their mom's basement.
>
>I in turn have to call BS on this.  If it were really that easy, we'd
>be inundated by Mirais -- we'd have several attacks a *day*.


You need to get out more.

http://www.nab.org/cybersecurity/Verisign-report-ddos-trends-Q22016.pdf

It *is* happening every day.  You just don't hear about it on CNN because
a "little"  80Mbps DDoS isn't even worthy of a headline anymore, even
though such an attack could CRUSH a local bank, and even many regional
banks into utter oblivion.

Now, where did I put those bitcoins...  It's ransom time!


Regards,
rfg


P.S.  Of course, things were oh so much better, ya know, back in those
idylic halcyon days a decade and a half ago...

Denial of e-commerce
Feb 10th 2000 
http://www.economist.com/node/281531

  "... The Computer Emergency Response Team of Carnegie Mellon University
  hears of roughly four DOS attacks a day..."

Whew!  I guess we need to count our blessings that insightful visionary
industry leaders came forward, back in the early 00s, and spearheaded
the global changes necessary to insure that DDoS attacks would become a
thing of the past, and a distant memory.

Oh!  Wait!  Nevermind.  Sorry.  I guess that I was dozing off and dreaming
again.

At the current rate of progress I think that I can confidently predict
that the Internet industry ought to have this whole problem completely
licked by the early 23rd century, you know, at the very latest.

Re: Spitballing IoT Security

[Eric S. Raymond]

Ronald F. Guilmette :
> Two kids with a modest amount of knowledge
> and a lot of time on their hands can do it from their mom's basement.

I in turn have to call BS on this.  If it were really that easy, we'd
be inundated by Mirais -- we'd have several attacks a *day*.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <20161029180730.ga10...@thyrsus.com>, 
"Eric S. Raymond"  wrote:

>You don't build or hire a botnet on Mirai's scale with pocket change.

Proof please?

Sorry, but I am compelled to call B.S. on the above statement.  This
is a really important point that I, Krebs, and others have been trying
to drive home:  In an era when you've got a half million CCTV cams
just lying around without even passwords on them, and in an era when
nobody makes any fuss anymore about the dozens or hundreds or people
and/or organizations (e.g. Shodan) that are out there scanning your
box and my box and everybody's boxes, every damn day, you don't need
to be either an omnious "state actor" or even SPECTER to assemble a
truly massive packet weapon.  Two kids with a modest amount of knowledge
and a lot of time on their hands can do it from their mom's basement.

It is comforting, for some, to think that this is not the case, just
as it is, to this day, comforting, for some, to believe, based on scant
evidence, that it -wasn't- just some lone nut case who killed President
Kennedy.  Psychologically, people have trouble coming to terms with
great impactful tragedies unless they can be blamed on large, unseen,
but enormously capable dark forces.  And the actual available hard
evidence relating to such events does not diminish the human yearning
for a convenient comic book supervillain to pin it all on.

>And the M.O. doesn't fit a criminal organization - no ransom demand,
>no attempt to steal data.

Allow me to refer you to an alternative possible motivation:

   https://en.wiktionary.org/wiki/lulz

>That means the motive was prep for terrorism or cyberwar by a
>state-level actor.

Frankly, I am dismayed to see a well-known Internet persona with a respected
name spreading this kind of absurd, alarmist, over-the-top, retorical fear-
mongering inference, which is without clear basis in either fact or evidence.

Even the hardest of the hard-core dyed-in-the-wool Clinton surrogates are
too circumspect in their pronouncements (i.e. with respect to Russia's
"obvious" connection to the DNC hack) to ever reach anything like this
level of unfounded hyperbole.  (And for the record, I am no Trump supporter
either.  I find myself equally disgusted when either side employs the
currently fashionable verbal sleight-of-hand that politicians of all stripes
have, of late, adopted whenever they want to say something without
themselves having to take responsibility for its truth or accuracy.  I get
angry when I hear Clinton surrogates using the "Some people are saying..."
dodge, e.g. when it comes to alleged nefarious Russian involvement with
anything and everything evil, just as I do when Trump uses the exact same
dodge in reference to... well... everything.)

>Bruce Schneier is right and is only saying what
>everybody else on the InfoSec side I've spoken with is thinking - the
>People's Liberation Army is the top suspect, with the Russian FSB
>operating through proxies in Bulgaria or Romania as a fairly distant
>second.

Yes, but I believe that Schneier was a bit more careful to separate the
known facts from his personal speculations.

In any case, all of this searching for who is to blame isn't contributing
a damn thing towards actually fixing the problem.  And if we really need
to find someone to blame, I think we should all just look in the mirror.

We, society, but especially those of us with more-than-average techno savvy,
have for years been only too eager to lap up whatever whiz-bang new techno
gadgets industry could crank out, with barely an afterthought given to
the longer term implications, like security and also how the hell we are
ever going to be able to recycle any of this s***.  We've all been doing
the exact same thing, since at least Windows 3.1 or earlier, and yet we
continue to expect a different outcome.  We eagerly grab for new capabilities
and new gadgets, thinking about security last or, more often, not at all.
In short, to quote Pogo, "We have met the enemy and he is us."


Regards,
rfg


P.S.  Even if the evidence were to support the view that only a superpower-
level nation-state could have pulled off the Dyn attack... and I'm not at
all persuaded that it does... it kills me that everyone seems to jump,
within a millisecond, immediately from -that- unwarranted conclusion to
the separate unwarranted conclusion that it must have been either Russia
or China.  Apparently, nobody even stops to consider the *other* elephant
in the room, the one that stretches from sea to shining sea, and which
itself has been heard to publically brag about its own cyber-offensive
capabilities of late.

In short, maybe our own guys did this.

OK, so maybe this theory -is- worthy of le Carre, but that don't mean it
ain't possible.  I mean we aren't stupid.  We don't build warehouses full
of nuclear weapons without at least testing the design once or twice first,
you know, to make sure they aren't all gonna end up being duds 

Re: Spitballing IoT Security

[Alan Buxey]

Hi,

Hi,

>Put it another way: you bring home a NEST and the first thing you the
>expert might do is read the net to figure out which ports to open.  Are
>you really going to not open those ports?

Put onto its own isolated vlan with only internet access.  Unfortunately no 
basic routers that are for the home come with such a setup by default.  That's 
the first big win. 

alan

Re: Spitballing IoT Security

[bzs]

On October 29, 2016 at 15:35 beec...@beecher.cc (Tom Beecher) wrote:
 > "That means the motive was prep for terrorism or cyberwar by a
 > state-level actor. "
 > 
 > Or, quite possibly ( I would argue probably) it was marketing. Show off the
 > capabilities of the botnet to garner more interest amongst those who pay for
 > use of such things. 

Supposedly Khalid Sheikh Mohammed's widely publicized video of him
beheading Daniel Pearl was basically an ad for his group's for-hire
mercenary services. Look at how ruthless we are! Didn't seem to lead
to much of a career.

However the one fly in this ointment is that the Mirai virus code has
since been distributed. So unless there's some critical piece of that
they've held back it's not much of a property.

If that's true, that the virus code was subsequently distributed by
the actors, it also raises doubts about a state actor. Why would they
distribute the code? State actors tend to work in an atmosphere of
secrecy unless they're flaunting their deeds.

But, whatever, one doesn't know until one knows.

-- 
-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: Spitballing IoT Security

[Tom Beecher]

"That means the motive was prep for terrorism or cyberwar by a
state-level actor. "

Or, quite possibly ( I would argue probably) it was marketing. Show off the
capabilities of the botnet to garner more interest amongst those who pay
for use of such things.

On Sat, Oct 29, 2016 at 2:07 PM, Eric S. Raymond  wrote:

> b...@theworld.com :
> >
> > On October 28, 2016 at 22:27 l...@satchell.net (Stephen Satchell) wrote:
> >  > On 10/28/2016 10:14 PM, b...@theworld.com wrote:
> >  > > Thus far the goal just seems to be mayhem.
> >  >
> >  > Thus far, the goal on the part of the botnet opearators is to make
> >  > money.  The goal of the CUSTOMERS of the botnet operators?  Who knows?
> >
> > You're speaking in general terms, right? We don't know much anything
> > about the perpetrators of these recent Krebs and Dyn attacks such as
> > whether there was any DDoS for hire involved.
>
> We can deduce a lot from what didn't happen.
>
> You don't build or hire a botnet on Mirai's scale with pocket change.
> And the M.O. doesn't fit a criminal organization - no ransom demand,
> no attempt to steal data.
>
> That means the motive was prep for terrorism or cyberwar by a
> state-level actor.  Bruce Schneier is right and is only saying what
> everybody else on the InfoSec side I've spoken with is thinking - the
> People's Liberation Army is the top suspect, with the Russian FSB
> operating through proxies in Bulgaria or Romania as a fairly distant
> second.
>
> Me, I think this fits the profile of a PLA probing attack perfectly.
> --
> http://www.catb.org/~esr/;>Eric S. Raymond
>

Re: Spitballing IoT Security

[Jean-Francois Mezei]

On 2016-10-29 14:07, Eric S. Raymond wrote:

> You don't build or hire a botnet on Mirai's scale with pocket change.
> And the M.O. doesn't fit a criminal organization - no ransom demand,
> no attempt to steal data.

it is wrong to underestimate script kiddies and open source code. It is
wrong to underestimate a community that shares their own experiences
with different devices. One contributes default password for brand X
camera, one gives the defaults for brand Y router etc.

Imagine someone writes code for university project to scan the network
for improperly protected devices. That code, while designed as a
security audit, could be integrated into something far nastier.

At the end of the day, you may have plenty of open source information
available to assemble this into something like Mirai.


Yeah, there may be more sinister forces out there. The DYN attack may
have been a "demo" of capabilities that will be part of
threats/balckmail against other large players on the Internet.




> everybody else on the InfoSec side I've spoken with is thinking - the
> People's Liberation Army is the top suspect, with the Russian FSB
> operating through proxies in Bulgaria or Romania as a fairly distant
> second.

Or some guy in Arkansas starting a new blackmail/extortion business,
hoping to cash in on the software he put together.

And if we're gonna talk conspiracies, include Trump. he publishes a
"policy" on cyber attacks on a day, a couple days later a major cyber
attack happens. Coincidence ? :-)


I think the focus should be on preventing such attacks, and reducing
their impacts when they happen and improving traceability tools as they
happen. Speculating on who is reponsible doesn't do much to proect the
internet against such attacks.

Re: Spitballing IoT Security

[bzs]

On October 29, 2016 at 14:07 e...@thyrsus.com (Eric S. Raymond) wrote:
 > b...@theworld.com :
 > > 
 > > On October 28, 2016 at 22:27 l...@satchell.net (Stephen Satchell) wrote:
 > >  > On 10/28/2016 10:14 PM, b...@theworld.com wrote:
 > >  > > Thus far the goal just seems to be mayhem.
 > >  > 
 > >  > Thus far, the goal on the part of the botnet opearators is to make
 > >  > money.  The goal of the CUSTOMERS of the botnet operators?  Who knows?
 > > 
 > > You're speaking in general terms, right? We don't know much anything
 > > about the perpetrators of these recent Krebs and Dyn attacks such as
 > > whether there was any DDoS for hire involved.
 > 
 > We can deduce a lot from what didn't happen.
 > 
 > You don't build or hire a botnet on Mirai's scale with pocket change.

Do we know this or is this just a guess?

The infamous 1988 Morris worm was also thought to be something
similarly sinister for a short while until Bob Morris, Jr et al owned
up to it just being an experiment by a couple of students gone out of
control.

Back around 1986 I accidentally brought down at least half the net by
submitting a new hosts file (for Boston Univ) with an entry that
tickled a bug in the hosts.txt->/etc/hosts code which everyone ran at
midnight (whatever) causing a loop which filled /tmp (this would be
unix hosts but by count they were by far most of the connected
servers) and back then a full /tmp crashed unix and it often didn't
come back up until a human intervened.

Ok I doubt this was an accident, tho its scale could've been an
accident, a prank gone wild.

Anyhow what do we *know*?

That the effect was large doesn't necessarily imply that it required a
lot of resources.

We live in a world rife with asymmetric warfare. A few boxcutters and
3,000+ people dead.

 > And the M.O. doesn't fit a criminal organization - no ransom demand,
 > no attempt to steal data.

Same question. Would Dyn et al publicize ransom demands at this point?

And even if not how do we rule out a prank or similar?

Is there something specific about this attack which required
significant resources? How significant?

 > 
 > That means the motive was prep for terrorism or cyberwar by a
 > state-level actor.  Bruce Schneier is right and is only saying what
 > everybody else on the InfoSec side I've spoken with is thinking - the
 > People's Liberation Army is the top suspect, with the Russian FSB
 > operating through proxies in Bulgaria or Romania as a fairly distant
 > second.

Well, barring further details one can go anywhere with a few
suppositions.

 > 
 > Me, I think this fits the profile of a PLA probing attack perfectly.
 > -- 
 >  http://www.catb.org/~esr/;>Eric S. Raymond

-- 
-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: Spitballing IoT Security

[Eric S. Raymond]

b...@theworld.com :
> 
> On October 28, 2016 at 22:27 l...@satchell.net (Stephen Satchell) wrote:
>  > On 10/28/2016 10:14 PM, b...@theworld.com wrote:
>  > > Thus far the goal just seems to be mayhem.
>  > 
>  > Thus far, the goal on the part of the botnet opearators is to make
>  > money.  The goal of the CUSTOMERS of the botnet operators?  Who knows?
> 
> You're speaking in general terms, right? We don't know much anything
> about the perpetrators of these recent Krebs and Dyn attacks such as
> whether there was any DDoS for hire involved.

We can deduce a lot from what didn't happen.

You don't build or hire a botnet on Mirai's scale with pocket change.
And the M.O. doesn't fit a criminal organization - no ransom demand,
no attempt to steal data.

That means the motive was prep for terrorism or cyberwar by a
state-level actor.  Bruce Schneier is right and is only saying what
everybody else on the InfoSec side I've spoken with is thinking - the
People's Liberation Army is the top suspect, with the Russian FSB
operating through proxies in Bulgaria or Romania as a fairly distant
second.

Me, I think this fits the profile of a PLA probing attack perfectly.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Spitballing IoT Security

[bzs]

On October 28, 2016 at 22:27 l...@satchell.net (Stephen Satchell) wrote:
 > On 10/28/2016 10:14 PM, b...@theworld.com wrote:
 > > Thus far the goal just seems to be mayhem.
 > 
 > Thus far, the goal on the part of the botnet opearators is to make
 > money.  The goal of the CUSTOMERS of the botnet operators?  Who knows?

You're speaking in general terms, right? We don't know much anything
about the perpetrators of these recent Krebs and Dyn attacks such as
whether there was any DDoS for hire involved.

-- 
-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: Spitballing IoT Security

[Eliot Lear]

Hi Chris,


On 10/25/16 1:51 PM, Chris Boyd wrote:
>> On Oct 25, 2016, at 3:10 AM, Ronald F. Guilmette  
>> wrote:
>>
>> An IoT is -not- a general purpose computer.  In the latter case, it is
>> assumed that the owner will "pop the hood" when it comes to the software
>> configuration.
> Ah, but they are.  In many cases you can ship a product faster and cheaper 
> with an ARM based system running a stripped down Linux and some specialty I/O 
> than building a properly hardened custom microcontroller.

That something has a CPU doesn't tell you whether it is a general
purpose computer.  What tells you if a device is a general purpose is
whether it is intended for particular uses or not (the key word there
being "purpose").  More importantly, if you view every Thing as a
general purpose computer you are missing an opportunity to impose an
engineering constraint on the problem space.  If that in turn let's you
easily solve for the general case, you've had a huge win.

Eliot




signature.asc
Description: OpenPGP digital signature

Re: Spitballing IoT Security

[Eliot Lear]

Hi Mike,


On 10/27/16 11:04 AM, Mike Meredith wrote:
> On Thu, 27 Oct 2016 07:59:00 +0200, Eliot Lear 
> may have written:
>> Well yes.  uPnP is a problem precisely because it is some random device
>> asserting on its own that it can be trusted to do what it wants.  Had
> From my own personal use (and I'm aware that this isn't a general
> solution), I'd like a device that sat on those uPnP requests until I logged
> into the admin interface to review them. Now if you could automate _me_
> then it might become more generally useful :-

You need to go further.  It is no longer enough to tackle this problem
simply as a firewall problem, because there are too many
reflection-style attacks.  Not only do you want to prevent devices from
opening pinholes to the Internet, but you really want to know what
they're going to be doing inside the home.  And Quite frankly, I
disagree that you want to nag the user unless it is absolutely
necessary.  To me, that means authorizing the device in the first place,
and the access point having access to enough intelligence to know what
sort of access is necessary for a device, given its purpose.

> As someone who manages an application-based firewall, every problem looks
> like it would be easier to solve using an application-based firewall :)

I don't generally prefer application firewalls except in limited
circumstances.

Eliot



signature.asc
Description: OpenPGP digital signature

Re: Spitballing IoT Security

[Stephen Satchell]

On 10/28/2016 10:14 PM, b...@theworld.com wrote:
> Thus far the goal just seems to be mayhem.

Thus far, the goal on the part of the botnet opearators is to make
money.  The goal of the CUSTOMERS of the botnet operators?  Who knows?

Re: Spitballing IoT Security

[bzs]

On October 28, 2016 at 00:07 j...@jxh.com (Jim Hickstein) wrote:
 > On 10/27/16 22:59, b...@theworld.com wrote:
 > > What would the manufacturers' response be if this virus had instead
 > > just shut down, possibly in some cases physically damaged the devices
 > > or otherwise caused them to cease functioning ever again (wiped all
 > > their software or broke their bootability), rather than just hijacked
 > > them for a while?
 > 
 > A virus that kills its host (too much of the time) is not successful.

Hmm. So now we assume we are dealing with rational actors?

I suppose one can find some rational motives in bringing down Dyn but
I don't see that it's all that different from bricking half a million
(for starters) IoT devices.

Thus far the goal just seems to be mayhem.

-- 
-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: Spitballing IoT Security

[Jim Hickstein]

On 10/27/16 22:59, b...@theworld.com wrote:

What would the manufacturers' response be if this virus had instead
just shut down, possibly in some cases physically damaged the devices
or otherwise caused them to cease functioning ever again (wiped all
their software or broke their bootability), rather than just hijacked
them for a while?


A virus that kills its host (too much of the time) is not successful.

Re: Spitballing IoT Security

[Rich Kulawiec]

On Thu, Oct 27, 2016 at 05:13:31PM -0400, Jon Lewis wrote:
> This is one of my bigger concerns every time I buy something that's "cloud
> controlled".  Not so much that the manufacturer will force it's retirement,
> but "what happens if they go belly up, or just kill the division that
> supports my device?"  A cloud controlled networked device, with no cloud, is
> not terribly useful.

1. This has happened already, e.g., Nest.  It will happen again.  Many times.

2. Such a device may not be terribly useful *to you*, but in its
neglected, unremarked, unmaintained state it may become very useful
to attackers.

---rsk

RE: Spitballing IoT Security

[Keith Medcalf]

On Thursday, 27 October, 2016 22:09, Eliot Lear  said:

> On 10/28/16 1:55 AM, Keith Medcalf wrote:

> >>> The problem is in allowing inbound connections and going as far as
> doing
> >>> UPnP to tell the CPE router to open a inbound door to let hackers
> loging
> >>> to that IoT  pet feeder to turn it into an agressive DNS destroyer.
> >> Well yes.  uPnP is a problem precisely because it is some random device
> >> asserting on its own that it can be trusted to do what it wants.  Had
> >> that assertion come from the manufacturer, at least you would know that
> >> the device was designed to require that sort of access.**

> > And why would anyone in their right mind trust the manufacturer to make
> > this decision?  

> Because the manufacturer designed the device and knows best as to what
> sort of access it will require.

Manufacturers of devices and Operating Systems (particularly Microsoft WIndows) 
have proven over and over and over again that they cannot be trusted to make 
that decision.  One of the worst offenders, any versions of Windows subsequent 
to Windows XP, insists in dropping its knickers (opening the firewall) so that 
anything that wants to can fuck about with (connect to unrestricted from the 
internet) all the myriad of ever growing piles of shit included by Microsoft.  
Even if you close the firewall, the Manufacturer believes it knows better and 
changes your settings, without your permission.  If you are stupid enough to 
run UPNP on your network, then all the drivel flarn filth is directly 
accessible from the internet (and beyond) without restriction.

Preventing the manufacturer from doing that takes a *LOT* of *DEEP* surgery.

I wish that Ballmer fellow would just up and die, and that damn indian too, 
even more so.  If they got some help along those lines the world would be a lot 
better place.  They are both total asshats and enemies of security and 
functionality everywhere.

However, it is not just a microsoft thing -- ALL of them think they know better 
and they should all fuck off and die.

> Consider that today most devices have
> unfettered outbound access, and many can arrange for unfettered inbound
> access.  That's Not Good®.

Yes, because that is what the device manufacturers have programmed the device 
to do and to have, and to go to inordinate lengths to ignore any directions 
from the OWNER to the contrary.  They should all be strung up by their balls 
and dropped with dull rusty pinking shears!

> That doesn't mean that network
> administrators shouldn't be the kings and queens of their castles, but
> as I'm sure you well know, home users don't really know how to rule, and
> so they need some good defaults.

What is wrong with OFF?  That is a good default.

> Put it another way: you bring home a NEST and the first thing you the
> expert might do is read the net to figure out which ports to open.  Are
> you really going to not open those ports?

First of all, I would NEVER bring home a NEST, nor would I ever allow a NEST or 
anything like it to be connected to my network.  It is an evil device that does 
nothing of any use to me whatsoever.  It is also dangerous and malicious and 
will not permit me to control the damn thing, nor to retrieve data from it.  It 
is a hunk of useless shit.

And no.  Under no circumstances whatsoever do I open ports unless I know what 
they are for.  And inbound port openings require proof of paid up indemnity 
insurance in the millions per incident (trillion in total).  Therefore, no 
inbound ports get opened since no one has ever been able to satisfy this 
requirement.

End of Line.

Re: Spitballing IoT Security

[Eliot Lear]

Hi Keith,


On 10/28/16 1:55 AM, Keith Medcalf wrote:
>>> The problem is in allowing inbound connections and going as far as doing
>>> UPnP to tell the CPE router to open a inbound door to let hackers loging
>>> to that IoT  pet feeder to turn it into an agressive DNS destroyer.
>> Well yes.  uPnP is a problem precisely because it is some random device
>> asserting on its own that it can be trusted to do what it wants.  Had
>> that assertion come from the manufacturer, at least you would know that
>> the device was designed to require that sort of access.**
> And why would anyone in their right mind trust the manufacturer to make this 
> decision?  

Because the manufacturer designed the device and knows best as to what
sort of access it will require.  Consider that today most devices have
unfettered outbound access, and many can arrange for unfettered inbound
access.  That's Not Good®.  That doesn't mean that network
administrators shouldn't be the kings and queens of their castles, but
as I'm sure you well know, home users don't really know how to rule, and
so they need some good defaults.

Put it another way: you bring home a NEST and the first thing you the
expert might do is read the net to figure out which ports to open.  Are
you really going to not open those ports?

Eliot



signature.asc
Description: OpenPGP digital signature

RE: Spitballing IoT Security

[bzs]

I suppose someone could modify this Mirai virus to instead inject
antivirus software. I know, illegal.

What would the manufacturers' response be if this virus had instead
just shut down, possibly in some cases physically damaged the devices
or otherwise caused them to cease functioning ever again (wiped all
their software or broke their bootability), rather than just hijacked
them for a while?

One manufacturer agreed that half a million of their devices were
involved in the attacks in a recent press release. And they apologize.

What if half a million of their devices just suddenly stopped working,
forever?

I suspect that would require a somewhat more expensive response.

They have to be thinking that sort of thing or else they're being
pretty dumb.

-- 
-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: Spitballing IoT Security

[Laszlo Hanyecz]

On 2016-10-27 23:24, Ronald F. Guilmette wrote:

I put forward what I think is a reasonbly modest scheme to try to get
IoT things to place hard limits on their "unsolicited" packet output at
the kernel level, and I'm going to go off now and try to find and then
engage some Linux embedded kernel people and see what they think.  Maybe
the whole thing is a dumb idea and not worth persuing, but I'm not con-
vinced of that yet.  So I'll go off, investigate in some more appropriate
forum, and report back here if/when I have anything useful to say.

Hacking embedded kernels to make them fault-tolerant, even in the event
of attackers getting a root shell prompt, isn't going to save the world
from DDoS attacks, but it may be one small part of the solution.


Regards,
rfg


This doesn't make sense to me.  When the device is compromised, the 
default software with the restrictions will just be reconfigured or 
replaced.  This process is similar to installing DD-WRT, or even a 
simple update from the vendor, for example.  Botnets download and 
install the software they require and often they close the original 
infection vector to prevent another botnet from reinfecting.  Check out 
the Mirai source code that was posted.


-Laszlo

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <20161027204258.cd18057d5...@rock.dv.isc.org>, 
Mark Andrews  wrote:

>> The problem is, as I have said, this device is now the Apple equivalent
>> of Windows XP.  There could be a horrendous collection of a dozen or
>> more known critical security bugs in the thing by now, but as someone
>> noted, the last update Apple issued for the thing was in Feb 2014.
>
>But is there?  Can you list a single security bug in iOS 6.1.6 that
>would require a iOS 6.1.7?

An entirely reasonable and logical question, Mark.

I'll admit, it took me a bit of digging, but the answer would appear to
be "yes":


https://threatpost.com/apple-fixes-cookie-access-vulnerability-in-safari-on-billions-of-devices/112246/

Note that I have the latest and greatest IOS 6.1.6 on my 3GS.

The Safari HTTP User-Agent string is apparently as follows:

Mozilla/5.0 (iPhone; CPU iPhone OS 6_1_6 like Mac OS X) AppleWebKit/536.26 
(KHTML, like Gecko) Version/6.0 Mobile/10B500 Safari/8536.25

So, Q.E.D. ?


Regards,
rfg

RE: Spitballing IoT Security

[Keith Medcalf]

> > The problem is in allowing inbound connections and going as far as doing
> > UPnP to tell the CPE router to open a inbound door to let hackers loging
> > to that IoT  pet feeder to turn it into an agressive DNS destroyer.

> Well yes.  uPnP is a problem precisely because it is some random device
> asserting on its own that it can be trusted to do what it wants.  Had
> that assertion come from the manufacturer, at least you would know that
> the device was designed to require that sort of access.**

And why would anyone in their right mind trust the manufacturer to make this 
decision?  

Neither the device nor the manufacturer have the authority to make that 
decision ... ONLY the owner of the device has that authority, and once made the 
owner of the device is responsible for *all* consequences resulting from that 
decision.  If the device itself makes the decision (because it is programmed to 
do so by the manufacturer), then the manufacturer is responsible for all the 
consequences resulting therefrom.

End Of Line.

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message 
Ken Matlock  wrote:

>Fixing the current wave of 'IoT' devices and phones and Tv's etc is only
>putting a bandaid on a broken arm. It gives the illusion of progress...

>Until we accept that it's *everyone's* problem and work to fix the things
>under our control and work as an advocate for the other layers, we will
>continue to suffer attacks.

Agreed.

Even if we could snap our fingers and fix the whole morass that is
the IoT problem tomorrow, that still wouldn't prevent dumb consumers
from pulling their dusty old Windows XP laptops own out of their
closets and hooking them up directly to the Internet.  Nor would it
do anything about the small ISPs that have "mailbox full" abuse@
addresses, or the even larger ISPs that allow deliberately spoofed
packets out onto the public Internet, or the Tier 1s that still peer
with known utterly irresponsible ASNs.

But, ya know, you gotta start someplace.  And we can't let the perfect
be the enemy of the good.  That just won't wash anymore, I think.  Not
after last Friday.

I put forward what I think is a reasonbly modest scheme to try to get
IoT things to place hard limits on their "unsolicited" packet output at
the kernel level, and I'm going to go off now and try to find and then
engage some Linux embedded kernel people and see what they think.  Maybe
the whole thing is a dumb idea and not worth persuing, but I'm not con-
vinced of that yet.  So I'll go off, investigate in some more appropriate
forum, and report back here if/when I have anything useful to say.

Hacking embedded kernels to make them fault-tolerant, even in the event
of attackers getting a root shell prompt, isn't going to save the world
from DDoS attacks, but it may be one small part of the solution.


Regards,
rfg


P.S.  In the scheme I proposed, I left out one additional nicety that
embedded kernels could also do to enhance security, namely disabling
raw sockets completely in the kernel.  No normal IoT thing needs the
ability to forge outbound packets.  But I would be willing to bet my
bottom dollar, right now, that if we poked around long enough we could
surely find some easily break-in-able busybox-based thingies out there,
right now, as we speak, into which a binary could dropped that would
have no trouble at all opening raw outbound sockets.

BCP38 for toasters anyone?

Re: Spitballing IoT Security -- Dancing around a solution

[Stephen Satchell]

I've been following the discussion with quite a bit of interest.  What
had become crystal clear to me is that nobody here has been looking at
the problem from the perspective of the manufacturer, particularly how
they actually get product to marked.  A la "Dilbert".

The engineer's credo:  "Why build it when you can buy it?"  I doubt very
seriously that manufacturers are starting completely from scratch when
they design their IoT product.  They buy this piece, they buy that
piece, they buy this hunk of software, they buy these hardware
components.  Slap them together, and you have your product.

That being the case, the question of "what happens when the company goes
bankrupt" becomes less of an issue so long at the company who supplied
the IP stack is still around.  By government implementing some
not-unpleasant rules, the companies can outsource the IP stack portion,
including updates.  Then the manufacturers can concentrate on the value
add stuff.

For durable goods like refrigerators and thermostats, you could require
that the IP-capable part be in a plug-replaceable module, so that all
the customer needs to do is go to Home Depot or wherever and get a
replacement module.  Instant update!  The back end of the module would
be a well-defined API so the manufacturer can do his product, divorced
from the Net stuff.  Indeed, it wouldn't take long for the various
industry associations to codify what the modules should look like, both
physically and electrically.

The semiconductor industry did this big time in the TTL days.  There is
precedent.

So what if your washing machine is working perfectly well 15 years into
its lifecycle.  You replace the network module and get the latest and
greatest security updates.

Light bulbs are harder, but even then there is an opportunity for
someone to market an "industry standard" interface that can be upgraded
easily and cheaply.  By the original software vendor.

Can someone say "IoTsoft"?

RE: Spitballing IoT Security

[Emille Blanc]

>On Thu, 27 Oct 2016, Ronald F. Guilmette wrote:
>
>> My iPhone 3GS still works just fine,
>
>I still have a "functional" iPhone 3G (no S).  I don't think AT will 
>activate service on it at this point, and it's been relegated to iPod 
>service when I do yard work.
>
>> You can't *force* people to throw away or trade-in their old tech products,
>> especially when, from the user's point of view, there doesn't -seem- to be
>> anything wrong with them... like all of those pre- Sept. 2015 Internet video
>> cameras.
>
>Sure you can.  Just make the tech dependent on "the cloud" and when the 
>device is too old, force retirement by no longer supporting it.  That 
>doesn't force it off the network (unless the final command from the cloud 
>is "shut off [your network interface]?"), but it makes the user much more 
>likely to toss it and replace it with something newer if they still want 
>such a device.

Or shut down the network that the phone(s) support. Anyone remember the 
analogue cell network shutdown? Or am I already that old?
http://www.pcworld.com/article/142119/article.html

Granted there were other problems this presented. Decreased coverage in areas 
for example is my favourite, as it opened the doors for such revolutionary 
pay-as-you-go-licensing features for base stations such as 
range-by-the-kilometre.
But I think with this, I'm contributing to driving this thread off the topic of 
IoT security, and will now dive back into staring at some netflow data.

Re: Spitballing IoT Security

[Edward Dore]

> On 27 Oct 2016, at 21:25, Alan Buxey  wrote:
> 
> Hi,
> 
> 
>> At which point the 3GS was almost 5 years old (having originally been
>> released in June 2009) and had been already superseded by the iPhone 4,
>> 4S, 5 and 5S/5C.
> 
> But the release of and presence of those phones does not make the older phone 
> suddenly stop working.  As noted,  the phone might be obsolete to those 
> people hungering for the latest tech but as a phone and web client etc it 
> still works fine. and will continue doing so whilst the battery is okay. 
> ... and then,  with no updates it can be the next attack vector

No, but at some point everything has to be discontinued. You can't reasonably 
expect manufacturers to continue to support their products indefinitely, 
particularly without recompense.

To put it another way; are you willing to either pay more up front or some kind 
of ongoing fee in order to fund the manufacturer continuing to produce software 
updates for a device which is multiple years and multiple generations out of 
date?

> 
> Which is the point.  These things stay out there...like those winXP boxes.  
> There are 2 choices
> 
> 1) manufacturers are responsible for the devices.  No longer caring for them? 
>  Recall them.  Compensate the users.
> 
> 2) stronger obsolescence.  eg kill switch/firmware tombstoning/network 
> connectivity function ending timebomb
> 
> as a user of lots of legacy tech i find either option bad :/
> 
> alan

Windows XP was released in October 2001 and finally killed in April 2014. Even 
the last service pack was released in April 2008. That's a pretty long life and 
I don't think it would be reasonable to expect Microsoft to continue to spend 
time and money supporting it any further.

Users need to take some responsibility when it comes to making sure that their 
software (or firmware in the case of embedded devices) is still supported by 
the manufacturer. If you choose to use it past the end of the manufacturer's 
support, then you need to be prepared for the potential consequences of doing 
so, including that your service provider disconnects you from their network as 
your device(s) are participating in DoS attacks.

Of course, the manufacturer needs to provide the user with some kind of 
reasonable expectation of the lifetime of a device so that they can make the 
appropriate plans to invest in a suitable replacement.
In the case of Windows XP there has been a published official lifecycle for an 
extremely long time (since SP3 was released?). There was also a lot of press 
coverage before and after the end of support, so it shouldn't exactly come as a 
surprise to anyone.
For the iPhone, new versions of iOS generally support the last 4-5 iterations 
of the hardware (I'm not sure if there is an official published policy about 
this), which is typically updated annually. Currently that is the iPhone 5/5C 
from September 2012, the iPhone 5S from September 2013, the iPhone 6/6+ from 
September 2014, the iPhone 6S/6S+/SE from September 2015 and the iPhone 7/7+ 
from September 2016.

Edward


signature.asc
Description: Message signed with OpenPGP using GPGMail

RE: Spitballing IoT Security

[Emille Blanc]

(deleted for ambiguity)

> > Which is the point.  These things stay out there...like those winXP
> > boxes.  There are 2 choices
> >
> > 1) manufacturers are responsible for the devices.  No longer caring for
> >them? Recall them.  Compensate the users.
> >
> > 2) stronger obsolescence.  eg kill switch/firmware tombstoning/network
> >connectivity function ending timebomb
> >
> > as a user of lots of legacy tech i find either option bad :/
> >
> > alan
> 
> Or Apple could release iOS 6.1.7.  There is nothing stopping Apple doing
> so.  Apple are the ones preventing people running iOS 10.x on the 3GS.
> This puts the responsibilty on them to supply security fixes.
>
> All of the PC's running XP could run a newer version of the Windows
> regardless of whether they could run the latest version.

Well, yes and no.  As $newer_better_faster_stronger gains market share, there's 
no drive to be backwards compatible.

iOS is no different from any other operating system in that regard, it's 
designed for hardware A, B, C, D's 1 through 4 (probably more, but I'm trying 
to be somewhat abstract).  If it has to support E through Z also, for 12+ years 
of backwards compatibility, bad things can happen (bloat, instability, bugs).
I don't get upset for example, when I transplant a Win2k or Win98 drive into a 
box built up with 3 year old hardware, of which not a single device is 
supported.
That's not even taking into account the challenge of developing for different 
architectures. ARM, x86, PPC, AMD64, PowerISA, SPARC, to name a few. I won't 
even get into microcontrollers.

Don't get me wrong. I'd love to update my 12 year old Macbook Pro to Sierra, 
but I've accepted that it, like most electronics, were almost certainly not 
engineered, let alone expected, to last even half that long.
I'm reminded of that fact every time I open Youtube, and Flash Player spins 
both of its 2.33ghz Core2 Duo cores to 100% for a 460p video.
Even then, I've had to stop updating Flash sometime around mid 2014, as any 
newer versions cease to function entirely.

Re: Spitballing IoT Security

[Ca By]

On Thursday, October 27, 2016, Mark Andrews  wrote:

>
> In message <16193.1477594...@segfault.tristatelogic.com >,
> "Ronald F. Guilmette" writes:
> >
> > In message <20161027112940.gb17...@ussenterprise.ufp.org 
> >,
> > Leo Bicknell > wrote:
> >
> > >Actually, they encourage you to trade {your old iPhone} in...
> > >...
> > >If your device is too old for that program, they will still take
> > >it for free and recycle it in an enviornmentally friendly way...
> >
> > OK, so good on them.  I do compliment them for their apparent willingness
> > to take back this pile of leachable heavy metals and do something
> > responsible with it.
> >
> > But to come back to the point, what if I really don't -want- to give
> > Apple another several hundred dollars this year?  The baby needs shoes,
> > the gas tank is empty, and maybe I just don't -have- $600+ dollars this
> > month to further enrich their shareholders.
> >
> > My iPhone 3GS still works just fine, for the most part, so if I don't
> > really need all of the new whiz bang features of the newer ones, why
> > would I fork over big bucks to replace it?  Just because TV commercials
> > entice me to do so??
> >
> > The problem is, as I have said, this device is now the Apple equivalent
> > of Windows XP.  There could be a horrendous collection of a dozen or
> > more known critical security bugs in the thing by now, but as someone
> > noted, the last update Apple issued for the thing was in Feb 2014.
>
> But is there?  Can you list a single security bug in iOS 6.1.6 that
> would require a iOS 6.1.7?
>
>
Well, ios 7 - 9.3.4 is in scope for this RCE

https://blog.lookout.com/blog/2016/08/25/trident-pegasus/

And if you view jpegs, you may want to update to 10.1

https://threatpost.com/apple-patches-ios-flaw-exploitable-by-malicious-jpeg/121521/


Yes, it is annoying that iOS 10.x doesn't run on it so that you can't
> newer apps.
>
> > In the medical field, they use the term "orphan drugs" to refer to drugs
> > that have such a low return on investment that no manufacturer has any
> > interest in them anymore.  We don't use that terminology in the tech
> > field because it would be redundant.  *Every* tech product either already
> > is, or soon will be, an orphan.
> >
> > You can't *force* people to throw away or trade-in their old tech
> products,
> > especially when, from the user's point of view, there doesn't -seem- to
> be
> > anything wrong with them... like all of those pre- Sept. 2015 Internet
> video
> > cameras.  (Well, -in theory- you could force people to do this.  You
> could
> > legislate an Obamacare-esque tax which penalized everyone who -didn't-
> > throw away or trade-in their old tech gadgets after, say, 4 years, but I
> > don't think that would go down very well.)
> >
> >
> > Regards,
> > rfg
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> 
>

Re: Spitballing IoT Security

[Jon Lewis]

On Thu, 27 Oct 2016, Ronald F. Guilmette wrote:


My iPhone 3GS still works just fine,


I still have a "functional" iPhone 3G (no S).  I don't think AT will 
activate service on it at this point, and it's been relegated to iPod 
service when I do yard work.



You can't *force* people to throw away or trade-in their old tech products,
especially when, from the user's point of view, there doesn't -seem- to be
anything wrong with them... like all of those pre- Sept. 2015 Internet video
cameras.


Sure you can.  Just make the tech dependent on "the cloud" and when the 
device is too old, force retirement by no longer supporting it.  That 
doesn't force it off the network (unless the final command from the cloud 
is "shut off [your network interface]?"), but it makes the user much more 
likely to toss it and replace it with something newer if they still want 
such a device.


This is one of my bigger concerns every time I buy something that's "cloud 
controlled".  Not so much that the manufacturer will force it's 
retirement, but "what happens if they go belly up, or just kill the 
division that supports my device?"  A cloud controlled networked device, 
with no cloud, is not terribly useful.


--
 Jon Lewis, MCP :)   |  I route
 |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Spitballing IoT Security

[Mark Andrews]

In message <56b9abd3-6911-42cb-9c9d-81fb33ca5...@lboro.ac.uk>, Alan Buxey write
s:
> Hi,
> 
> 
> >At which point the 3GS was almost 5 years old (having originally been
> >released in June 2009) and had been already superseded by the iPhone 4,
> >4S, 5 and 5S/5C.
>
> But the release of and presence of those phones does not make the older
> phone suddenly stop working.  As noted,  the phone might be obsolete to
> those people hungering for the latest tech but as a phone and web client
> etc it still works fine. and will continue doing so whilst the
> battery is okay. ... and then, with no updates it can be the next attack
> vector
>
> Which is the point.  These things stay out there...like those winXP
> boxes.  There are 2 choices
>
> 1) manufacturers are responsible for the devices.  No longer caring for
>them? Recall them.  Compensate the users.
>
> 2) stronger obsolescence.  eg kill switch/firmware tombstoning/network
>connectivity function ending timebomb
>
> as a user of lots of legacy tech i find either option bad :/
>
> alan

Or Apple could release iOS 6.1.7.  There is nothing stopping Apple doing
so.  Apple are the ones preventing people running iOS 10.x on the 3GS.
This puts the responsibilty on them to supply security fixes.

All of the PC's running XP could run a newer version of the Windows
regardless of whether they could run the latest version.

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

Re: Spitballing IoT Security

[Mark Andrews]

In message <16193.1477594...@segfault.tristatelogic.com>, "Ronald F. Guilmette" 
writes:
> 
> In message <20161027112940.gb17...@ussenterprise.ufp.org>, 
> Leo Bicknell  wrote:
> 
> >Actually, they encourage you to trade {your old iPhone} in...
> >...
> >If your device is too old for that program, they will still take
> >it for free and recycle it in an enviornmentally friendly way...
> 
> OK, so good on them.  I do compliment them for their apparent willingness
> to take back this pile of leachable heavy metals and do something
> responsible with it.
> 
> But to come back to the point, what if I really don't -want- to give
> Apple another several hundred dollars this year?  The baby needs shoes,
> the gas tank is empty, and maybe I just don't -have- $600+ dollars this
> month to further enrich their shareholders.
> 
> My iPhone 3GS still works just fine, for the most part, so if I don't
> really need all of the new whiz bang features of the newer ones, why
> would I fork over big bucks to replace it?  Just because TV commercials
> entice me to do so??
> 
> The problem is, as I have said, this device is now the Apple equivalent
> of Windows XP.  There could be a horrendous collection of a dozen or
> more known critical security bugs in the thing by now, but as someone
> noted, the last update Apple issued for the thing was in Feb 2014.

But is there?  Can you list a single security bug in iOS 6.1.6 that
would require a iOS 6.1.7?

Yes, it is annoying that iOS 10.x doesn't run on it so that you can't
newer apps.
 
> In the medical field, they use the term "orphan drugs" to refer to drugs
> that have such a low return on investment that no manufacturer has any
> interest in them anymore.  We don't use that terminology in the tech
> field because it would be redundant.  *Every* tech product either already
> is, or soon will be, an orphan.
> 
> You can't *force* people to throw away or trade-in their old tech products,
> especially when, from the user's point of view, there doesn't -seem- to be
> anything wrong with them... like all of those pre- Sept. 2015 Internet video
> cameras.  (Well, -in theory- you could force people to do this.  You could
> legislate an Obamacare-esque tax which penalized everyone who -didn't-
> throw away or trade-in their old tech gadgets after, say, 4 years, but I
> don't think that would go down very well.)
> 
> 
> Regards,
> rfg
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Spitballing IoT Security

[Alan Buxey]

Hi,


>At which point the 3GS was almost 5 years old (having originally been
>released in June 2009) and had been already superseded by the iPhone 4,
>4S, 5 and 5S/5C.

But the release of and presence of those phones does not make the older phone 
suddenly stop working.  As noted,  the phone might be obsolete to those people 
hungering for the latest tech but as a phone and web client etc it still works 
fine. and will continue doing so whilst the battery is okay. ... and then,  
with no updates it can be the next attack vector 

Which is the point.  These things stay out there...like those winXP boxes.  
There are 2 choices

1) manufacturers are responsible for the devices.  No longer caring for them?  
Recall them.  Compensate the users. 

2) stronger obsolescence.  eg kill switch/firmware tombstoning/network 
connectivity function ending timebomb

as a user of lots of legacy tech i find either option bad :/

alan

Re: Spitballing IoT Security

[bzs]

Perhaps something which is needed is analogous to Maritime Law's "Law
of Salvage".

If a manufacturer abandons all support of a technical product then
they lose various intellectual property rights which might prevent a
third-party from providing support.

Including reasonable assistance such as providing source code needed
to support that product which could be provided to the third-party
under NDA. But it can't just be refused.

Perhaps this can be triggered by the sort of security concerns
expressed here.

This could be interesting since at least the US govt generally writes
minimal terms of support into purchase contracts such as soonest end
of life from time of purchase, soonest end of support thereafter,
often several years. How that works beyond a vendor's bankruptcy is
beyond the scope of this discussion but suffice it to say it's been
considered.

  https://en.wikipedia.org/wiki/Law_of_salvage

On October 26, 2016 at 18:01 r...@tristatelogic.com (Ronald F. Guilmette) wrote:
 > 
 > In message <58111bd4.80...@vaxination.ca>, 
 > Jean-Francois Mezei  wrote:
 > 
 > >My smart TV not only hasn't gotten updates in years, but Sharp has
 > >stopped selling TVs in Canada. (not sure if they still sell TVs elsewhere).
 > 
 > A little more than 2 years ago, I bought a last-of-its-kind demo
 > model of a 50 inch Panasonic Plasma TV which was on sale (due to
 > having been discontinued by the manufacturer) from the local BestBuy.
 > 
 > Not long after, once I got the thing home, I realized that the
 > thing's understanding of current local time... important in
 > conjunction with the on-screen TV guide... was locked to Eastern
 > Standard Time, and there was no way to change it.  (This was/is
 > a bit of a problem for me, as I'm in PST/PDT.)
 > 
 > I called up Panasonic and explained the whole thing to a first-
 > level tech support minion.  She had no solution to offer me.
 > I insisted on speaking to a manager.
 > 
 > A manager got on the line and I prroceeded to re-explain the whole
 > issue to him.  I said that I needed a firmware fix.  He said that
 > there was no way the company was going to develop a fix "just for
 > you".  Politely, I persisted and said that the TV firmware was
 > self-evidently faulty.
 > 
 > 
 > <>
 > <>

-- 
-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: Spitballing IoT Security

[Ken Matlock]

And I contend that the device manufacturer is only one part in this.

Yes, the manufacturers need to get better in securing their devices (that's
never been in question).

*But* the end users need to have better CPE that can do NetFlow/Sflow/etc
in a near real-time fashion. This would allow the end-user to act as a
check against the manufacturer(s) and see threats and DDoS packets
originating from their gear in real-time (and on the customer's CPE they
can get MAC or RFC1918 address to narrow it down better).

*But* that doesn't let the SP's off the hook either. The SP needs to be a
check against the end users as well, being able to do real-time (or
near-real time) flow data export/analysis. Why isn't it done currently?
Well, probably a few reasons (and more that I can't even imagine)

1) Cost - It's a real cost to put something like this in place, and upper
management does not want to spend money on something with little to no
return
2) Availability - How much SP gear even has the option to do any sort of
flow export/analysis?
3) Competition - If I am SP 'A' and I allow my customers to participate in
a DDoS against SP 'B' (who is a competitor of mine), that at least
indirectly harms my competitor, and all I have to do is absolutely nothing,
why would management in SP 'A' lift a finger to fix the problem? (Until the
DDoS is directed at them).

Fixing the current wave of 'IoT' devices and phones and Tv's etc is only
putting a bandaid on a broken arm. It gives the illusion of progress, but
the fact is the reason DDoS'es are still a problem (and honestly, they've
been a problem for decades, IRC servers and Netsplits/channel
takeovers/etc), is that each layer in the problem is pointing the finger at
the other layers and declaring them the cause of the problem and washing
their hands of it (not unlike current politics).

Until we accept that it's *everyone's* problem and work to fix the things
under our control and work as an advocate for the other layers, we will
continue to suffer attacks.

Ken



> I say again, the only way to solve these problems is if the devices
> are fundamentally secure by design, on the day they first ship to
> customers.  Post-sale patching is an ad hoc and haphazard catch-as-
> catch-can solution at best, and it's not something that most manufacturers
> have -any- financial incentive to even do.  They already got their
> money, on the day when the consumer bought the device.  The rest is
> just an afterthought.
>
> Regards,
> rfg
>

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <20161027112940.gb17...@ussenterprise.ufp.org>, 
Leo Bicknell  wrote:

>Actually, they encourage you to trade {your old iPhone} in...
>...
>If your device is too old for that program, they will still take
>it for free and recycle it in an enviornmentally friendly way...

OK, so good on them.  I do compliment them for their apparent willingness
to take back this pile of leachable heavy metals and do something
responsible with it.

But to come back to the point, what if I really don't -want- to give
Apple another several hundred dollars this year?  The baby needs shoes,
the gas tank is empty, and maybe I just don't -have- $600+ dollars this
month to further enrich their shareholders.

My iPhone 3GS still works just fine, for the most part, so if I don't
really need all of the new whiz bang features of the newer ones, why
would I fork over big bucks to replace it?  Just because TV commercials
entice me to do so??

The problem is, as I have said, this device is now the Apple equivalent
of Windows XP.  There could be a horrendous collection of a dozen or
more known critical security bugs in the thing by now, but as someone
noted, the last update Apple issued for the thing was in Feb 2014.

In the medical field, they use the term "orphan drugs" to refer to drugs
that have such a low return on investment that no manufacturer has any
interest in them anymore.  We don't use that terminology in the tech
field because it would be redundant.  *Every* tech product either already
is, or soon will be, an orphan.

You can't *force* people to throw away or trade-in their old tech products,
especially when, from the user's point of view, there doesn't -seem- to be
anything wrong with them... like all of those pre- Sept. 2015 Internet video
cameras.  (Well, -in theory- you could force people to do this.  You could
legislate an Obamacare-esque tax which penalized everyone who -didn't-
throw away or trade-in their old tech gadgets after, say, 4 years, but I
don't think that would go down very well.)


Regards,
rfg

Re: Spitballing IoT Security

[Edward Dore]

On 27 Oct 2016, at 19:02, Ronald F. Guilmette  wrote:
> 
> 
> In message <20161027084939.5bdf457d0...@rock.dv.isc.org>,
> Mark Andrews  wrote:
> 
>> Well the last update for the 3GS was iOS 6.1.6 in Feb 2014.
> 
> Bingo!
> 
> Less than a year and a half after they stopped selling it, they
> effectively stopped supporting it.
> 

At which point the 3GS was almost 5 years old (having originally been released 
in June 2009) and had been already superseded by the iPhone 4, 4S, 5 and 5S/5C.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <20161027112601.ga17...@ussenterprise.ufp.org>, 
Leo Bicknell  wrote:

>Problems I think consumer safety legislation can solve:
>
>* SSH and Telnet were enabled, but there was no notification in the UI
>  that they were enabled and no way to turn them off.  Requirements
>  could be set to show all services in the UI and if they are on or
>  off.
>
>* There was a hard coded user + pass that the consumer COULD NOT CHANGE,
>  and did not display.  Requirements could be set to never hard code an
>  account.
>
>* That the system has a user-friendly way to update.  "Click here to
>  check for update."  "Click here to install update."


I say again, #3 is useless, unless and until you also have legislation
that:

 *)  Forces tech companies to never go bankrupt.

 *)  Forces tech companies to -timely- issue security patches for all
 "critical" security issues (and good luck legally defining THAT).

 *)  Forces tech companies to continue to issue security patches for
 as long as any "significant" number of the relevant devices
 remain actively in use, even if that turns out to be 20 years
 or more.

You can force a company to implement a "user-friendly way to update",
but what's the point of doing that if the company never issues any
updates?

I say again, the only way to solve these problems is if the devices
are fundamentally secure by design, on the day they first ship to
customers.  Post-sale patching is an ad hoc and haphazard catch-as-
catch-can solution at best, and it's not something that most manufacturers
have -any- financial incentive to even do.  They already got their
money, on the day when the consumer bought the device.  The rest is
just an afterthought.

Regards,
rfg

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <1477558411.730528...@apps.rackspace.com>, 
"t...@pelican.org"  wrote:

>...I back up to the cloud...

Yes, I confess that this reasonable use case had not occured to me, and
yes, it utterly negates what I was saying.

(I myself am the paranoid type, so I -do not- back up -any- of my stuff
or things to any storage which is not physically in a place where I
myself can lay hands on it.  Given all of the massive breaches that
have been in the news over the past few years, I'm just not comfortable
sending my data into the hands of others.  But other people are obviously
happy to do this, and who am I to tell them they shouldn't?  It is 100%
reasonable for end users to occasionally use a lot of outbound bandwidth.
Period.  I'm sorry that I wasted electrons suggesting otherwise.)

Regards,
rfg

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <20161027084939.5bdf457d0...@rock.dv.isc.org>, 
Mark Andrews  wrote:

>Well the last update for the 3GS was iOS 6.1.6 in Feb 2014.

Bingo!

Less than a year and a half after they stopped selling it, they
effectively stopped supporting it.

Re: Spitballing IoT Security

[Leo Bicknell]

In a message written on Tue, Oct 25, 2016 at 04:52:58AM -, John Levine 
wrote:
> My nearest Apple stores are 50 miles away.  I'm not sure 100 miles in
> the car is a good tradeoff for one phone.

Scroll down a bit further:

"Tell us which device you have, and we’ll email you a prepaid
mailing label. Once you’ve deleted your data, ship your
device to us, and we’ll handle the rest."

-- 
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/


pgp60Yt_YI5U7.pgp
Description: PGP signature

Re: Spitballing IoT Security

[John Levine]

>Please don't, bring it to your nearest Apple Store instead where it
>will be properly recycled, .

My nearest Apple stores are 50 miles away.  I'm not sure 100 miles in
the car is a good tradeoff for one phone.

Re: Spitballing IoT Security

[Mel Beckman]

Requiring manual approval is an excellent idea for the ThingSafe RFC!

 -mel 

> On Oct 27, 2016, at 2:10 AM, Mike Meredith  wrote:
> 
> On Thu, 27 Oct 2016 07:59:00 +0200, Eliot Lear 
> may have written:
>> Well yes.  uPnP is a problem precisely because it is some random device
>> asserting on its own that it can be trusted to do what it wants.  Had
> 
> From my own personal use (and I'm aware that this isn't a general
> solution), I'd like a device that sat on those uPnP requests until I logged
> into the admin interface to review them. Now if you could automate _me_
> then it might become more generally useful :-
> 
> uPnP(ssh, for admin access) -> f/w
> 
> f/w -> uPnP device: Don't be silly.
> 
>> But if instead of a pet feeder we're talking about a home file sharing
>> system or a video camera where you don't want to share the feed into the
>> cloud?  There will be times when people want inbound connections.  We
>> need an architecture that supports them.
> 
> As someone who manages an application-based firewall, every problem looks
> like it would be easier to solve using an application-based firewall :)
> 
> -- 
> Mike Meredith, University of Portsmouth
> Principal Systems Engineer, Hostmaster, Security, and Timelord!
> 

Re: Spitballing IoT Security

[knack via NANOG]

t for inflation)
Ken

On Wed, Oct 26, 2016 at 1:40 PM, jim deleskie <deles...@gmail.com> wrote:


So device is certified,  bug is found 2 years later.  How does this help.
The info to date is last week's issue was patched by the vendor in Sept
2015, I believe is what I read. We know bugs will creep in, (source anyone
that has worked with code forever) Also certification assuming it would
work, in what country, would I need one, per country I sell into?  These
are not the solutions you are looking for ( Jedi word play on purpose)

On Wed, Oct 26, 2016 at 3:53 PM, JORDI PALET MARTINEZ <
jordi.pa...@consulintel.es> wrote:


Exactly, I was arguing exactly the same with some folks this week during
the RIPE meeting.

The same way that certifications are needed to avoid radio interferences,
etc., and if you don’t pass those certifications, you can’t sell the
products in some countries (or regions in case of EU for example),
authorities should make sure that those certifications have a broader
scope, including security and probably some other features to ensure that
in case something is discovered in the future, they can be updated.

Yes, that means cost, but a few thousand dollars of certification price
increase, among thousands of millions of devices of the same model being
manufactured, means a few cents for each unit.

Even if we speak about 1 dollar per each product being sold, it is much
cheaper than the cost of not doing it and paying for damages, human
resources, etc., when there is a security breach.

Regards,
Jordi


-Mensaje original-
De: NANOG <nanog-boun...@nanog.org> en nombre de Leo Bicknell <
bickn...@ufp.org>
Organización: United Federation of Planets
Responder a: <bickn...@ufp.org>
Fecha: miércoles, 26 de octubre de 2016, 19:19
Para: <nanog@nanog.org>
Asunto: Re: Spitballing IoT Security

 In a message written on Wed, Oct 26, 2016 at 08:06:34AM -0400, Rich
Kulawiec wrote:
 > The makers of IoT devices are falling all over themselves to rush
products
 > to market as quickly as possible in order to maximize their
profits.  They
 > have no time for security.  They don't concern themselves with
privacy
 > implications.  They don't run networks so they don't care about the
impact
 > their devices may have on them.  They don't care about liability:
many of
 > them are effectively immune because suing them would mean
trans-national
 > litigation, which is tedious and expensive.  (And even if they

lost:

 > they'd dissolve and reconstitute as another company the next day.)
 > They don't even care about each other -- I'm pretty sure we're
rapidly
 > approaching the point where toasters will be used to attack garage
door
 > openers and washing machines.

 You are correct.

 I believe the answer is to have some sort of test scheme (UL
 Labratories?) for basic security and updateability.  Then federal
 legislation is passed requiring any product being imported into the
 country to be certified, or it is refused.

 Now when they rush to market and don't get certified they get $0
 and go out of business.  Products are stopped at the boader, every
 shipment is reviewed by authorities, and there is no cross boarder
 suing issue.

 Really it's product safety 101.  UL, the CPSC, NHTSA, DOT and a
 host of others have regulations that if you want to import a product
 for sale it must be safe.  It's not a new or novel concept, pretty
 much every country has some scheme like it.

 --
 Leo Bicknell - bickn...@ufp.org
 PGP keys at http://www.ufp.org/~bicknell/




**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.

Re: Spitballing IoT Security

[Geoffrey Keating]

"Ronald F. Guilmette"  writes:

> My iPhone 3GS "goes on the Internet".
> 
> Through no fauly of my own, it is also, apparently, destined in short order
> to "go onto" a landfill, if not here, then in China or India, where a
> pitiful plethora of shoeless and sad-eyed third-world waifs will spend
> their childhoods picking through the mand-made mountains of e-refuse in a
> daily and desperate search for of anything of value.

Please don't, bring it to your nearest Apple Store instead where it
will be properly recycled, .

Re: Spitballing IoT Security

[Leo Bicknell]

In a message written on Wed, Oct 26, 2016 at 05:27:08PM -0700, Ronald F. 
Guilmette wrote:
> do let me know how I can obtain this month's security patches for my iPhone
> 3GS.
> 
> (Note that Wikipedia says that this device was only formally discontinued
> by the manufacturer as of September 12, 2012, i.e. only slightly more
> than 4 short years ago.  Nontheless, the current "security solution" for
> this product, as made available from the manufacturer... a manufacturer
> which is here being held up as a shining example of ernest social responsi-
> bility... is for me to contribute the entire device to my local landfill,
> where it will no doubt leach innumerable heavy metals into the soil for
> my children's children's children to enjoy.)

Actually, they encourage you to trade it in, where it is used for
replacement parts and/or recycled, see
http://www.apple.com/iphone/trade-up/.

If your device is too old for that program, they will still take
it for free and recycle it in an enviornmentally friendly way, see
http://www.apple.com/recycling/.

No iPhone should ever end up in a landfill.  If it does, it's your fault
for not taking advantage of the free recycling.

-- 
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/


pgpAVQuHrUrJP.pgp
Description: PGP signature

Re: Spitballing IoT Security

[Leo Bicknell]

In a message written on Wed, Oct 26, 2016 at 04:40:57PM -0300, jim deleskie 
wrote:
> So device is certified,  bug is found 2 years later.  How does this help.
> The info to date is last week's issue was patched by the vendor in Sept
> 2015, I believe is what I read. We know bugs will creep in, (source anyone
> that has worked with code forever) Also certification assuming it would
> work, in what country, would I need one, per country I sell into?  These
> are not the solutions you are looking for ( Jedi word play on purpose)

You're referencing a wider problem set than I am trying to solve.

Problems I think consumer safety legislation can solve:

* SSH and Telnet were enabled, but there was no notification in the UI
  that they were enabled and no way to turn them off.  Requirements
  could be set to show all services in the UI and if they are on or
  off.

* There was a hard coded user + pass that the consumer COULD NOT CHANGE,
  and did not display.  Requirements could be set to never hard code an
  account.

* That the system has a user-friendly way to update.  "Click here to
  check for update."  "Click here to install update."

What consumer safety legislation can't do is insure a patch is made
available at some point in the future.

As for certification, I will point out minimally all of these
products are already geting CE, UL, and FCC (if Wireless).  They
also have to meet other regulations (e.g. RoHS) to be imported.  To
really minimize burden, these security items could be added to one
of the existing schemes so there is no additional org.  But the
idea that a certification per country is difficult is pretty much
debunked by the fact that it is that way already, multiple times
over in most cases.

-- 
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/


pgpzzs_z_tQ7g.pgp
Description: PGP signature

Re: Spitballing IoT Security

[Mike Meredith]

On Thu, 27 Oct 2016 07:59:00 +0200, Eliot Lear 
may have written:
> Well yes.  uPnP is a problem precisely because it is some random device
> asserting on its own that it can be trusted to do what it wants.  Had

From my own personal use (and I'm aware that this isn't a general
solution), I'd like a device that sat on those uPnP requests until I logged
into the admin interface to review them. Now if you could automate _me_
then it might become more generally useful :-

uPnP(ssh, for admin access) -> f/w

f/w -> uPnP device: Don't be silly.

> But if instead of a pet feeder we're talking about a home file sharing
> system or a video camera where you don't want to share the feed into the
> cloud?  There will be times when people want inbound connections.  We
> need an architecture that supports them.

As someone who manages an application-based firewall, every problem looks
like it would be easier to solve using an application-based firewall :)

-- 
Mike Meredith, University of Portsmouth
Principal Systems Engineer, Hostmaster, Security, and Timelord!
 


pgpYa7dseBC5c.pgp
Description: OpenPGP digital signature

Re: Spitballing IoT Security

[t...@pelican.org]

On Thursday, 27 October, 2016 00:40, "Ronald F. Guilmette" 
 said:

> Point:  I have a DSL line which is limited to 6Mbps down and 756Kbps up.
> My guess is that if any typical/average user is seen to be using more
> than, say, 1/10 of that amount of "up" bandwidth in any one given 10
> minute time period, then something is really really REALLY wrong.

This sounds like a horrible view of the Internet as "TV, only with more funny 
cat pictures", where most users are in a second-tier that is only expected / 
allowed to consume.

One of the reasons I'm very grateful for FTTC / VDSL is that I can finally get 
a useful upstream speed.  Going from 10-14M downstream to 80M was very nice, 
but going from 1M to 20M upstream was an absolute game-changer.

I back up to the cloud - and there are plenty of services that allow regular, 
non-technical users to do this.  The initial run saturated my upstream for 
days, and the incrementals are sometimes 20 or 30 minute bursts.  I wouldn't 
even have tried on ADSL.

Every time I get back from a day out, or even more so from a holiday, I upload 
the photos from my PC to one or more cloud services.  I'll max my uplink for 
anywhere between 10 minutes and an hour - on the old ADSL, it was easily an 
overnight task.

Working from home, I can now work directly with files on network shares, rather 
than copying everything to the laptop before I leave the office and trying to 
sync changes when I get back.  I know the exact figures for this case, but 
there are a *lot* of spikes over the course of a day.  With ADSL, I could go 
and make tea every time I needed to save a large Word doc or Powerpoint back to 
the network.  On top of that, I can spend anything up to 3 or 4 hours in 
videoconferences, which will have a steady stream of a few hundred Kb/s.

Spotting atypical (or ideally malicious) traffic is a valid goal, but I think 
we need to be a whole lot smarter than "customer is using upstream".

Regards,
Tim.

Re: Spitballing IoT Security

[Mark Andrews]

In message <12439.1477528...@segfault.tristatelogic.com>, "Ronald F. Guilmette" 
writes:
> 
> In message <20161026205800.7188d57b2...@rock.dv.isc.org>, 
> Mark Andrews  wrote:
> 
> >Actually things have changed a lot in a positive direction.
> >...
> >* Microsoft, Apple, Linux and *BSD issue regular fixes for their
> >  products and users do intall them.
> 
> At the risk of repeating a point I have already made in this thread, please
> do let me know how I can obtain this month's security patches for my iPhone
> 3GS.

Your assuming that there is a need for a security update each month.
The feature set is pretty stable at this point.

> (Note that Wikipedia says that this device was only formally discontinued
> by the manufacturer as of September 12, 2012, i.e. only slightly more
> than 4 short years ago.  Nontheless, the current "security solution" for
> this product, as made available from the manufacturer... a manufacturer
> which is here being held up as a shining example of ernest social responsi-
> bility... is for me to contribute the entire device to my local landfill,
> where it will no doubt leach innumerable heavy metals into the soil for
> my children's children's children to enjoy.)

Well the last update for the 3GS was iOS 6.1.6 in Feb 2014.
 
> >> - Manufacturers need to be held accountable for devices that go on the
> >> internet...
> 
> My iPhone 3GS "goes on the Internet".
> 
> Through no fauly of my own, it is also, apparently, destined in short order
> to "go onto" a landfill, if not here, then in China or India, where a
> pitiful plethora of shoeless and sad-eyed third-world waifs will spend
> their childhoods picking through the mand-made mountains of e-refuse in a
> daily and desperate search for of anything of value.
> 
>   
> http://motherboard.vice.com/read/much-of-americas-e-waste-recycling-is-a-sham
> 
> In short, if the "good" companies, like Apple, are the solution to the 
> problem,
> then I obviously misunderstood what "the problem" is, and would be obliged
> if someone (anyone) would re-phrase it for me in simpler terms, for the
> benefit of my limited little noggin.
> 
> In lieu of that, for the moment I'd just like to emphasize again that it
> is my opinion that any "solution" to the now self-evident IoT problems
> which relies, even in the slightest, upon manufacturers providing a con-
> tinuous and timely stream of security updates is a fantasy.  Wishful
> thinking, pure and simple.  When even the "good" companies have built
> their fortunes and entire business models around convincing/forcing
> everyone to purchase "new and improved" units every two years, at a
> maximum, and when the same said companies stop issuing patches of any
> kind for products that have only departed the corporate price list
> three years earlier, then one shudders to even contemplate what the
> contribution of the "bad" companies will be to this ongoing catastrophy.
> 
> 
> Regards,
> rfg
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Spitballing IoT Security

[Eliot Lear]

Hi Jean-Francois,


On 10/25/16 10:37 AM, Jean-Francois Mezei wrote:
> On 2016-10-25 04:10, Ronald F. Guilmette wrote:
>
>> If all of the *&^%$# damn stupid vacation pet feeders had originally shipped
>> with outbound rate limits hard-coded in the kernel, maybe this could have
>> been avoided.
>
> I view this differently.
>
> The problem is in allowing inbound connections and going as far as doing
> UPnP to tell the CPE router to open a inbound door to let hackers loging
> to that IoT  pet feeder to turn it into an agressive DNS destroyer.
Well yes.  uPnP is a problem precisely because it is some random device
asserting on its own that it can be trusted to do what it wants.  Had
that assertion come from the manufacturer, at least you would know that
the device was designed to require that sort of access.**

>
> Then again, you need to have the owner access the pet feeder from the
> remote beach to feed the dog.

>
> One way around this is for the pet feeder to initiate outbound
> connection to a central server, and have the pet onwer connect to that
> server to ask the server to send command to his pet feeder to feed the dog.

Precisely so.
>
> This way, there need not be any inbound connection to the pet feeder.
>
>
But if instead of a pet feeder we're talking about a home file sharing
system or a video camera where you don't want to share the feed into the
cloud?  There will be times when people want inbound connections.  We
need an architecture that supports them.

Eliot


signature.asc
Description: OpenPGP digital signature

Re: Spitballing IoT Security

[Randy Bush]

actually, the one technical hack i liked the most so far was the
suggestion to put throttling into openwrt/lede, as they are used
for the base in much cpe.

randy

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <58112f9f.6060...@vaxination.ca>, 
Jean-Francois Mezei  wrote:

>A camera showing the baby in 4K resolution along witgh sounds of him
>crying on dolby surround to the mother who is at work would likely
>saturate upload just as much as the virus sending DNS requests. This
>falls into the tonne of feathers weighting as much as a tonne of lead
>category.

Agreed.

So the "solution" is either to define such devices out of the problem
set (i.e. to say "that is not really an IoT type device") or else to
find some other solution.

Questions:

Does the 4K baby monitor (or the 4K 7-11 parking lot cam) need to be
sending its high-bandwidth outbound feed, arbitrarily, to absolutely
anything?  Could it instead reasonably be limited to sending its high-
bitrate data _only_ back to just those clients which themselves had
first made an inbound TCP connection to the thing?  (Note: The video
data itself wouldn't necessarily have to travel back to the client
via the TCP session.  It could be sent back to the client via a separate
and parallel UDP data link directed back to the same IP that initiated,
and that is currently holding open the TCP session.  I think that this
is kinda/sorta how FTP works, actually.)

IoT devices that need to send a *lot* of data out can be programmed
to only send such high-rate/high-bulk data to client IP addresses that
currently have live TCP sessions open... ones which the clients them-
selves initiated...  and the kernel can be made to enforce this simple
restriction.  Problem solved.  No DDoSing of arbitrary IP addreses here!
Move along.

Alternatively, in the model where the security camera needs, for whatever
reason, silly or otherwise... to be the one that initiates an outbound
connection (and then just blasts its data up through that) it seems to
me that it should not be too awfully hard to minimally enforce, in the
kernel, just step 1 of a kind of SMTP-ish protocol... one where the IoT
device initiates the outbound connection, to an IP address of its choosing
(perhaps after having done a DNS lookup to find it) and where the IoT
device then does nothing unless and until it gets some kind of affirmative
signal from the other side...  like a 2xx banner/greeting which effectively
says to the IoT device "I'm here, and you are Clear-To-Send."  (Again, it
isn't necessary for the IoT device to send the actual data stream up through
this TCP connection.  It could be sent via UDP, but only to the pre-verified
"cloud" IP address that we have already established is willing to accept
the bulk data.)

Of course, it would be best if there were some sort of a standardized
port number and protocol for this specific kind of IoT-to-Cloud interaction.
It would surely cause problems to try to overload these semantics on top
of, say, port 25.

So, in summary, it isn't even necessary to define video cameras out of the
"IoT" problem set.  The problem is excessive outbound data flowing to
perfectly arbitrary "victim" IP addresses.  (And remember, even attack
reflectors are victims too.)  Given the problem statement, the solution
is obvious:  You gotta start building boxes that have kernel-enforced
restrictions that fit one or the other of these two models:

 1) Ordinary (non-cloud-oriented) things MUST either:

1a)  be prevented from sending large amounts of data outbound AT ALL,
 ever, or else

1b)  be prevented from send large amounts of data outbound *except*
 when explicitly requested to do so by some verified IP address...
 which is to say an IP address that has initiated and completed an
 inbound TCP handshake

 2)  Cloud-Oriented things MUST be prevented from sending "unsolicited"
 bulk data to any IP address other than one which has very explicitly
 consented to receive it, i.e. by accepting and completing an inbound
 TCP handshake on some specially reserved port, and perhaps also via
 some additional layered trivial RTS/CTS protocol.

That's it.  Simple, no?  Implementation is of course, completely trivial,
just as it is for all things that I myself don't actually have to write
the code for.


Regards,
rfg

Re: Spitballing IoT Security

[Josh Reynolds]

i think this would be the most effective route proposed so far.

May the force be with you :)

On Wed, Oct 26, 2016 at 12:19 PM, Leo Bicknell  wrote:
> In a message written on Wed, Oct 26, 2016 at 08:06:34AM -0400, Rich Kulawiec 
> wrote:
>> The makers of IoT devices are falling all over themselves to rush products
>> to market as quickly as possible in order to maximize their profits.  They
>> have no time for security.  They don't concern themselves with privacy
>> implications.  They don't run networks so they don't care about the impact
>> their devices may have on them.  They don't care about liability: many of
>> them are effectively immune because suing them would mean trans-national
>> litigation, which is tedious and expensive.  (And even if they lost:
>> they'd dissolve and reconstitute as another company the next day.)
>> They don't even care about each other -- I'm pretty sure we're rapidly
>> approaching the point where toasters will be used to attack garage door
>> openers and washing machines.
>
> You are correct.
>
> I believe the answer is to have some sort of test scheme (UL
> Labratories?) for basic security and updateability.  Then federal
> legislation is passed requiring any product being imported into the
> country to be certified, or it is refused.
>
> Now when they rush to market and don't get certified they get $0
> and go out of business.  Products are stopped at the boader, every
> shipment is reviewed by authorities, and there is no cross boarder
> suing issue.
>
> Really it's product safety 101.  UL, the CPSC, NHTSA, DOT and a
> host of others have regulations that if you want to import a product
> for sale it must be safe.  It's not a new or novel concept, pretty
> much every country has some scheme like it.
>
> --
> Leo Bicknell - bickn...@ufp.org
> PGP keys at http://www.ufp.org/~bicknell/

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <89795.1477520...@turing-police.cc.vt.edu>, 
valdis.kletni...@vt.edu wrote:

>> Given that, and given that "OpenWRT and kin" often provide the end-user
>> with readily accessible dials and knobs via which the user can force the
>> device to *exceed* legal/FCC limits on power output, I am not persuaded
>> that open source WiFi router firmware actually represents a shining
>> example of a methodology to prevent inexpensive devices from behaving badly.
>
>Given that out of the box, the default config is in bounds, and it requires
>actual user interaction to exceed the limits, and that we don't see a very
>large problem out in the wild, I think we have prior art for the concept
>that "shipped with default and clued user can reconfigure" is a workable 
>design.

You're right, of course, and I didn't mean to be picking on DD-WRT or
OpenWRT, both of which I have used and have great admiration and respect
for.

It's just that if it comes down to a choice between putting a big sign on
something which says "Please keep your arms and legs inside the vehicle
at all times" or actually building somewhat difficult-to-remove barriers
which physically prevent people from dangling their arms and legs out,
given what we now know about typical end-luser behaviour (e.g. not even
changing default passwords), the latter seems probably preferable to the
former.

But perhaps this is all just a matter to be sorted out in the UI.

DD-WRT and OpenWRT assume that users are adults and non-stupid, and I,
for one, certainly prefer to be treated that way.  But for garden
variety consumers it might not be such a bad idea to first ask them
to provide the cube root of 27, or the airspeed velocity of an unladen
swallow, or the answer to Life, The Universe and Everything before
allowing them to increase their WiFi transmit power above FCC legal
limits, or before allowing them to disengage the handbrake on their
Roomba outbound bandwidth limit.

(Note to self:  Patent idea:  Intellectual CAPTCHAs... you must be at
least this non-stupid in order to proceed past this point.  HEADLINE:
Sixty Eight Percent of American Adults Flunk Turing Test, Cannot Be
Reliably Distinguished From Mindless Automatons --  Ninety Seven Percent
For First-Line Tech Support Professionals :-)


Regards,
rfg

Re: Spitballing IoT Security

[Mel Beckman]

People under appreciate the power of a million-strong IoT bot net. Just a few K 
per second from each bot becomes gigabits per second at the target. 

 -mel 

> On Oct 26, 2016, at 4:41 PM, Ronald F. Guilmette  
> wrote:
> 
> 
> In message 
> 
> Ken Matlock  wrote:
> 
>> - End users need to have ways to easily see what's going on over their
>> local networks, to see botnet-like activity and DDoS participation (among
>> other things) in a more real-time fashion
> 
> This is an interesting point.
> 
> I'm not actually an ISP guy, although I do play one on TV.  Anyway,
> I hope nobody will begrudge me if I make a couple of brief points,
> and then ask a rather naive question.
> 
> Point:  I have a DSL line which is limited to 6Mbps down and 756Kbps up.
> My guess is that if any typical/average user is seen to be using more
> than, say, 1/10 of that amount of "up" bandwidth in any one given 10
> minute time period, then something is really really REALLY wrong.
> 
> Point:  I am already signed up with various services which will send me
> automated emails whenever certain events occur, e.g. when the price of
> 2TB WD Black drives falls below my personal threshold value.
> 
> Point:  My ISP knows my email address.
> 
> Question:  Could ISPs set something up so that each customer broadband
> line is continuously and individually monitored, and so that an automated
> email would be automagically dashed off to the customer if that customer's
> "up" bandwidth in some time period exceeded a value which, for that ISP,
> is deemed "reasonable"?  (I envision the hypothetical email messages in
> question would consist of a non-threatening warning to the customer which
> would include a link to a web page where there would be a list of common
> things end-lusers should check for in such circumstances, along with
> detailed and clear instructions for how to check for each, and also a
> "don't ever bother me with these warnings again" checkbox, and perhaps
> even a friendly slider where the end-luser could adjust his personal
> warning threshold value, for the future.)
> 
> Of course, any ISP that desperately -never- wants to receive -any- end-
> luser support calls quite certainly won't like this scheme.  But I'm not
> sure that that fact alone would utterly disqualify the idea from being
> useful in some contexts.
> 
> The real question is:  Is anything even remotely along these lines even
> possible with existing commonly used ISP infrastructure?  (If not, then just
> forget I mentioned it.)
> 
> 
> Regards,
> rfg
> 
> 
> P.S.  One possible big advantage to the kind of system described above is
> that if an ISP received a complaint about a given customer, alleging that
> the customer is running a bot, then the ISP could go and look at the
> warning settings for that customer.  If that's already been set to
> "don't ever bother me', then the ISP can disconnect the customer, and
> when the customer inevitably saquaks about that, the ISP can respond and
> say "We told you so."

Re: Spitballing IoT Security

[Mark Andrews]

In message <12573.1477530...@segfault.tristatelogic.com>, "Ronald F. Guilmette" 
writes:
> 
> In message <58111bd4.80...@vaxination.ca>, 
> Jean-Francois Mezei  wrote:
> 
> >My smart TV not only hasn't gotten updates in years, but Sharp has
> >stopped selling TVs in Canada. (not sure if they still sell TVs elsewhere).
> 
> A little more than 2 years ago, I bought a last-of-its-kind demo
> model of a 50 inch Panasonic Plasma TV which was on sale (due to
> having been discontinued by the manufacturer) from the local BestBuy.
> 
> Not long after, once I got the thing home, I realized that the
> thing's understanding of current local time... important in
> conjunction with the on-screen TV guide... was locked to Eastern
> Standard Time, and there was no way to change it.  (This was/is
> a bit of a problem for me, as I'm in PST/PDT.)
> 
> I called up Panasonic and explained the whole thing to a first-
> level tech support minion.  She had no solution to offer me.
> I insisted on speaking to a manager.
> 
> A manager got on the line and I prroceeded to re-explain the whole
> issue to him.  I said that I needed a firmware fix.  He said that
> there was no way the company was going to develop a fix "just for
> you".  Politely, I persisted and said that the TV firmware was
> self-evidently faulty.

Then you return it to the store as "Not Fit For Purpose" and demand
your money back.  Alternatively you pull them into court and have
them honour the warrantee.  Or you move to a juristiction with good
consumer protection laws and sic the government onto them.

Just because a model is discontinued it does not mean that warrantee
issues do not need to be addressed.

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

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <58111bd4.80...@vaxination.ca>, 
Jean-Francois Mezei  wrote:

>My smart TV not only hasn't gotten updates in years, but Sharp has
>stopped selling TVs in Canada. (not sure if they still sell TVs elsewhere).

A little more than 2 years ago, I bought a last-of-its-kind demo
model of a 50 inch Panasonic Plasma TV which was on sale (due to
having been discontinued by the manufacturer) from the local BestBuy.

Not long after, once I got the thing home, I realized that the
thing's understanding of current local time... important in
conjunction with the on-screen TV guide... was locked to Eastern
Standard Time, and there was no way to change it.  (This was/is
a bit of a problem for me, as I'm in PST/PDT.)

I called up Panasonic and explained the whole thing to a first-
level tech support minion.  She had no solution to offer me.
I insisted on speaking to a manager.

A manager got on the line and I prroceeded to re-explain the whole
issue to him.  I said that I needed a firmware fix.  He said that
there was no way the company was going to develop a fix "just for
you".  Politely, I persisted and said that the TV firmware was
self-evidently faulty.


<>
<>

Re: Spitballing IoT Security

[Brandon Butterworth]

On Wed Oct 26, 2016 at 05:10:44PM -0400, Jean-Francois Mezei wrote:
> My smart TV not only hasn't gotten updates in years, but Sharp has
> stopped selling TVs in Canada. (not sure if they still sell TVs elsewhere).
> 
> When manufacturers provide a 2 year support on a device that will last
> 10 years, it is a problem which is why they really need to get it right
> when product is released and not rely on patches.

No chance of being right first time or ever but that's not a problem
until it gets compromised

> With regards to liability. Good luck suing a chinese outfit that no
> longer exists.
> 
> And pray tell, who gets to pay the millions of dollars of lawyer fees it
> will cost to sue that bankrupt company with no money ?
 
Nobody will. This is why a kill switch is needed. If you're going to
IoT Safe mark things there needs to be a way to revoke it like with SSL certs

So say devices, which phone home anyway, are required as part of getting
the mark to check in with $version.$device.$manufacturer.iotsafe.com
it's not much more than they do to check for new firmware already

You don't want all those calling something central so delegate to manufacturers
and if they go bust drop the deleagtion and serve it centrally. An ISP
with problem devices can always fake it locally to drop them and spot the
polling traffic when looking for them

When the device checks in they can with a simple api check their version
and if they're allowed to be on the general internet on not. If banned they
go offline and maybe tell the user somehow if they can.

The deal to get IoT safe rated is that everyone agree to this, the user will
be told clearly that their thing will be removed from the net if the 
manufacturer
doesn't keep it safe so it's clear they sue them if there is a problem (or 
accept it's
so cheap they can throw it away if they go bust)

Now there's tons of holes in that like an attacher turning that bit off, there
may be better schemes I've not noticed for doing this already. All details, the
idea is a back stop is needed for when all the other stuff fails.

brandon

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <20161026205800.7188d57b2...@rock.dv.isc.org>, 
Mark Andrews  wrote:

>Actually things have changed a lot in a positive direction.
>...
>* Microsoft, Apple, Linux and *BSD issue regular fixes for their
>  products and users do intall them.

At the risk of repeating a point I have already made in this thread, please
do let me know how I can obtain this month's security patches for my iPhone
3GS.

(Note that Wikipedia says that this device was only formally discontinued
by the manufacturer as of September 12, 2012, i.e. only slightly more
than 4 short years ago.  Nontheless, the current "security solution" for
this product, as made available from the manufacturer... a manufacturer
which is here being held up as a shining example of ernest social responsi-
bility... is for me to contribute the entire device to my local landfill,
where it will no doubt leach innumerable heavy metals into the soil for
my children's children's children to enjoy.)

>> - Manufacturers need to be held accountable for devices that go on the
>> internet...

My iPhone 3GS "goes on the Internet".

Through no fauly of my own, it is also, apparently, destined in short order
to "go onto" a landfill, if not here, then in China or India, where a
pitiful plethora of shoeless and sad-eyed third-world waifs will spend
their childhoods picking through the mand-made mountains of e-refuse in a
daily and desperate search for of anything of value.

  http://motherboard.vice.com/read/much-of-americas-e-waste-recycling-is-a-sham

In short, if the "good" companies, like Apple, are the solution to the problem,
then I obviously misunderstood what "the problem" is, and would be obliged
if someone (anyone) would re-phrase it for me in simpler terms, for the
benefit of my limited little noggin.

In lieu of that, for the moment I'd just like to emphasize again that it
is my opinion that any "solution" to the now self-evident IoT problems
which relies, even in the slightest, upon manufacturers providing a con-
tinuous and timely stream of security updates is a fantasy.  Wishful
thinking, pure and simple.  When even the "good" companies have built
their fortunes and entire business models around convincing/forcing
everyone to purchase "new and improved" units every two years, at a
maximum, and when the same said companies stop issuing patches of any
kind for products that have only departed the corporate price list
three years earlier, then one shudders to even contemplate what the
contribution of the "bad" companies will be to this ongoing catastrophy.


Regards,
rfg

Re: Spitballing IoT Security

[Mark Andrews]

In message <12301.1477525...@segfault.tristatelogic.com>, "Ronald F. Guilmette"
 writes:
> 
> In message  m>
> Ken Matlock  wrote:
> 
> >- End users need to have ways to easily see what's going on over their
> >local networks, to see botnet-like activity and DDoS participation (among
> >other things) in a more real-time fashion
> 
> This is an interesting point.
> 
> I'm not actually an ISP guy, although I do play one on TV.  Anyway,
> I hope nobody will begrudge me if I make a couple of brief points,
> and then ask a rather naive question.
> 
> Point:  I have a DSL line which is limited to 6Mbps down and 756Kbps up.
> My guess is that if any typical/average user is seen to be using more
> than, say, 1/10 of that amount of "up" bandwidth in any one given 10
> minute time period, then something is really really REALLY wrong.

No.  Just uploading a video to youtube would cause a false positive
using that test.

You need to know what "bad" traffic looks like to find it.  Packets
flowing != "bad traffic".  Unusual != "bad traffic".

Mark

> Point:  I am already signed up with various services which will send me
> automated emails whenever certain events occur, e.g. when the price of
> 2TB WD Black drives falls below my personal threshold value.
> 
> Point:  My ISP knows my email address.
> 
> Question:  Could ISPs set something up so that each customer broadband
> line is continuously and individually monitored, and so that an automated
> email would be automagically dashed off to the customer if that customer's
> "up" bandwidth in some time period exceeded a value which, for that ISP,
> is deemed "reasonable"?  (I envision the hypothetical email messages in
> question would consist of a non-threatening warning to the customer which
> would include a link to a web page where there would be a list of common
> things end-lusers should check for in such circumstances, along with
> detailed and clear instructions for how to check for each, and also a
> "don't ever bother me with these warnings again" checkbox, and perhaps
> even a friendly slider where the end-luser could adjust his personal
> warning threshold value, for the future.)
> 
> Of course, any ISP that desperately -never- wants to receive -any- end-
> luser support calls quite certainly won't like this scheme.  But I'm not
> sure that that fact alone would utterly disqualify the idea from being
> useful in some contexts.
> 
> The real question is:  Is anything even remotely along these lines even
> possible with existing commonly used ISP infrastructure?  (If not, then just
> forget I mentioned it.)
> 
> 
> Regards,
> rfg
> 
> 
> P.S.  One possible big advantage to the kind of system described above is
> that if an ISP received a complaint about a given customer, alleging that
> the customer is running a bot, then the ISP could go and look at the
> warning settings for that customer.  If that's already been set to
> "don't ever bother me', then the ISP can disconnect the customer, and
> when the customer inevitably saquaks about that, the ISP can respond and
> say "We told you so."
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Spitballing IoT Security

[Chris Boyd]

> On Oct 26, 2016, at 6:40 PM, Ronald F. Guilmette  
> wrote:
> 
> Point:  I have a DSL line which is limited to 6Mbps down and 756Kbps up.
> My guess is that if any typical/average user is seen to be using more
> than, say, 1/10 of that amount of "up" bandwidth in any one given 10
> minute time period, then something is really really REALLY wrong.

Online backup service like Carbonite and Backblaze copy lots of data upstream.  
iPhone backups would probably saturate your line for a good chunk of 10 
minutes.  Even posting a bunch of photos could take that long.  Oh, and 
bittorrent.

—Chris

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message 
Ken Matlock  wrote:

>- End users need to have ways to easily see what's going on over their
>local networks, to see botnet-like activity and DDoS participation (among
>other things) in a more real-time fashion

This is an interesting point.

I'm not actually an ISP guy, although I do play one on TV.  Anyway,
I hope nobody will begrudge me if I make a couple of brief points,
and then ask a rather naive question.

Point:  I have a DSL line which is limited to 6Mbps down and 756Kbps up.
My guess is that if any typical/average user is seen to be using more
than, say, 1/10 of that amount of "up" bandwidth in any one given 10
minute time period, then something is really really REALLY wrong.

Point:  I am already signed up with various services which will send me
automated emails whenever certain events occur, e.g. when the price of
2TB WD Black drives falls below my personal threshold value.

Point:  My ISP knows my email address.

Question:  Could ISPs set something up so that each customer broadband
line is continuously and individually monitored, and so that an automated
email would be automagically dashed off to the customer if that customer's
"up" bandwidth in some time period exceeded a value which, for that ISP,
is deemed "reasonable"?  (I envision the hypothetical email messages in
question would consist of a non-threatening warning to the customer which
would include a link to a web page where there would be a list of common
things end-lusers should check for in such circumstances, along with
detailed and clear instructions for how to check for each, and also a
"don't ever bother me with these warnings again" checkbox, and perhaps
even a friendly slider where the end-luser could adjust his personal
warning threshold value, for the future.)

Of course, any ISP that desperately -never- wants to receive -any- end-
luser support calls quite certainly won't like this scheme.  But I'm not
sure that that fact alone would utterly disqualify the idea from being
useful in some contexts.

The real question is:  Is anything even remotely along these lines even
possible with existing commonly used ISP infrastructure?  (If not, then just
forget I mentioned it.)


Regards,
rfg


P.S.  One possible big advantage to the kind of system described above is
that if an ISP received a complaint about a given customer, alleging that
the customer is running a bot, then the ISP could go and look at the
warning settings for that customer.  If that's already been set to
"don't ever bother me', then the ISP can disconnect the customer, and
when the customer inevitably saquaks about that, the ISP can respond and
say "We told you so."

Re: Spitballing IoT Security

[Jean-Francois Mezei]

On 2016-10-26 18:02, Ronald F. Guilmette wrote:

> http://p.globalsources.com/IMAGES/PDT/BIG/053/B1088622053.jpg
> 
> i.e. a multitude of wall plates in every room, each one bristling with a
> multitude of RJ11 sockets into which all manner of shiny new IoT things
> will be directly plugged, thence to be issued their own IPv6 addresses

You still need to have a SOHO router, which could simply block any
incoming calls unless a port has been opened for a specific IP address.
(or UPnP for computers).

> P.S.  As noted in my prior post, the proplem of regulating IoT devices to
> insure that they do not exceed their reasonably expected operational limits,
> vis-a-vis outbound bandwidth usage

A camera showing the baby in 4K resolution along witgh sounds of him
crying on dolby surround to the mother who is at work would likely
saturate upload just as much as the virus sending DNS requests. This
falls into the tonne of feathers weighting as much as a tonne of lead
category.

Re: Spitballing IoT Security

[Valdis . Kletnieks]

On Wed, 26 Oct 2016 15:02:46 -0700, "Ronald F. Guilmette" said:

> i.e. a multitude of wall plates in every room, each one bristling with a
> multitude of RJ11 sockets into which all manner of shiny new IoT things
> will be directly plugged, thence to be issued their own IPv6 addresses
> directly via DHCP from the local provider.

Actually, it seems to be going to wireless/bluetooth, and DHCP from the
household router.  Note that although a minor difference, it's one that
can be leveraged.  If we can change the dynamic from "plug it in and it
Just Works" to "plug it in, and click the pop-up from your router confirming
that you just added a device, and it Just Works after that", the battle is
3/4 won.  The other 1/4 is the device initially telling the router what sort
of device it is. - and we already know how to do that for USB and BlueTooth...

> Given that, and given that "OpenWRT and kin" often provide the end-user
> with readily accessible dials and knobs via which the user can force the
> device to *exceed* legal/FCC limits on power output, I am not persuaded
> that open source WiFi router firmware actually represents a shining
> example of a methodology to prevent inexpensive devices from behaving badly.

Given that out of the box, the default config is in bounds, and it requires
actual user interaction to exceed the limits, and that we don't see a very
large problem out in the wild, I think we have prior art for the concept
that "shipped with default and clued user can reconfigure" is a workable design.



pgpT6KAGOJ4w5.pgp
Description: PGP signature

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <20161026123043.ga10...@thyrsus.com>, 
"Eric S. Raymond"  wrote:

>There is, however, a chokepoint we have more hope of getting decent software
>deployed to.  I refer to home and small-business routers.  OpenWRT and kin
>are already minor but significant players here. And there's an NRE-minimization
>aregument we can make for router manufacturers to use rebranded versions
>rather than rolling their own crappy firmware.
>
>I think the anti-IoT-flood strategy that makes the most sense is:
>
>1. Push open-source firmware that doesn't suck to the vendors with a
>   cost- and risk-minimization pitch.
>
>2. Ship it with egress filters.  (And telnet blocked.)

So basically, this is a proposal to "fix" the problem for all IoT devices
that are behind SOHO routers.

I am compelled to note that the grand vision of the Home of the Future[tm],
as it has been presented to me at least, looks rather more like this:

http://p.globalsources.com/IMAGES/PDT/BIG/053/B1088622053.jpg

i.e. a multitude of wall plates in every room, each one bristling with a
multitude of RJ11 sockets into which all manner of shiny new IoT things
will be directly plugged, thence to be issued their own IPv6 addresses
directly via DHCP from the local provider.

If I have misunderstood the general direction is which we are all heading,
then I will be only too happy to be disabused of my incorrect notions.

>It wouldn't be technically very difficult to make the firmware
>rate-limit outbound connections...

No, but if you do that to my desktop PeeCee, then I'm gonna be pretty mad
at you.

On the other hand, if you come up with a way for devices to somehow signal
to an associated SOHO router that they are either (a) desktop PeeCees or,
in the alternative, IoT devices, and if you should me that you method is
(a) simple and (b) fool-proof and (c) hack-proof, then I'll be the first
one to say that you're really on to something.


Regards,
rfg


P.S.  As noted in my prior post, the proplem of regulating IoT devices to
insure that they do not exceed their reasonably expected operational limits,
vis-a-vis outbound bandwidth usage, is in some ways reminicent of the FCC
regulations which, ideally, prevent SOHO WiFi routers from exceeding
reasonable power output limits designed to prevent them from interfering
with other devices.

Given that, and given that "OpenWRT and kin" often provide the end-user
with readily accessible dials and knobs via which the user can force the
device to *exceed* legal/FCC limits on power output, I am not persuaded
that open source WiFi router firmware actually represents a shining
example of a methodology to prevent inexpensive devices from behaving badly.

Re: Spitballing IoT Security

[Valdis . Kletnieks]

On Wed, 26 Oct 2016 20:53:51 +0200, JORDI PALET MARTINEZ said:

> Even if we speak about 1 dollar per each product being sold, it is much
> cheaper than the cost of not doing it and paying for damages, human resources,
> etc., when there is a security breach.

This only works if the company perceives a very real danger of having to
pay for damages in case of a breach.


pgpYR9gmtcGmF.pgp
Description: PGP signature

Re: Spitballing IoT Security

[Mark Andrews]

In message <11718.1477517...@segfault.tristatelogic.com>, "Ronald F. Guilmette" 
writes:
> In short, if sensible regulations requiring "safe" designs for IoT products
> were to come into force in one locale, it is not only possible, but
> actually quite likely that they would affect the whole market.  If a given
> Far East manufacturer was required to have safety built into the kernel
> of its toasters in order to be able to sell said toasters, say, in the
> United States... or even just in California...  would they really go to
> the trouble to strip out the additional "safety" part of their firmware
> when manufacturing what is essentially the same product, but destined
> for other markets?  I think not.  (A question for the audience:  How has
> FCC regulation of the maximum power output of WiFi routers affected the
> worldwide market for such devices, over time?  I honestly don't know, but
> I suspect that there has been a good effect, over time, on the whole
> worldwide market.)

FCC regulation has caused manufactures to do a US version and a rest
of the world version.  They have over regulated.  A simple list
for location should be enough with default on unknown which leaves
Wifi off until set.

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

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <20161026120634.ga20...@gsp.org>, 
Rich Kulawiec  wrote:

>On Mon, Oct 24, 2016 at 01:24:59PM -0700, Ronald F. Guilmette wrote:
>>2) Second, once elected I will decree that in future all new IoT devices,
>>   and also all updates to firmware for existing IoT devices will have,
>>   BUILT IN TO THE KERNEL, code/logic which (a) prevents all outbound TCP
>>   session initiation and which also (b) strictly rate-limits all other
>>   protocols to some modest value.
>
>I like this idea.  But unfortunately, I think it has no chance of succeeding.
>
>The makers of IoT devices are falling all over themselves to rush products
>to market as quickly as possible in order to maximize their profits.  They
>have no time for security.  They don't concern themselves with privacy...

Well, see, this is why I was clear at the outset that in order for this
scheme to work, I'll first need to be elected King of the World.

>From that high perch I will be able to decree, by fiat, that no Internet
connectable device shall be sold or marketed *unless* it has been certified
(i.e. by some reliable entity that knows how to test these things) to be
incapable of being converted into a weapon, i.e. incapable of spewing
unnecessarily large amounts of garbage at completely arbitrary targets,
*even if* an attacker somehow manages to get a shell prompt.

OK, so setting aside all frivolity now, how could this kind of restriction
actually be achieved?

Here's the thing:  Any solution to these problems is going to come in two
parts, technical and political.

We here, by and large, are not politicians, but we can influence them and
urge them towards solutions that are, workable, economically practical,
and above all, technically effective.  Or alternatively, we can leave
them to flouder around on their own, in the dark.  (We've all seen
*that* movie before, and it isn't pretty.  Think Clipper Chip and the
recent push for crypto backdoors.)  Left to their own devices, politicians
routinely screw up technology regulation virtually every time.

So the first order of business is for the industry itself to come up with
a rational approach... and virtually immediately, because the window of
opportunity is rapidly closing...  for solving these IoT problems, and
then get widspread agreement... or at least a lack of violent disagreement...
within the industry itself.  The industry can then speak with one voice
to the politicians and regulators, who will then be effectively bound to
doing the Right Thing.

Sensible regulations, once enacted in one jurisdiction, tend to be
contagious.  In my own state of California, state regulation of various
things, most notably air pollution, and the production thereof by cars,
has eventually affected the entire North American auto market and beyond,
in part because it is less economically palatable for manufacturers to
design and ship multiple configurations of any one product, i.e. one
which conforms to the regulations in jurisdiction X, and another that
doesn't.

In short, if sensible regulations requiring "safe" designs for IoT products
were to come into force in one locale, it is not only possible, but
actually quite likely that they would affect the whole market.  If a given
Far East manufacturer was required to have safety built into the kernel
of its toasters in order to be able to sell said toasters, say, in the
United States... or even just in California...  would they really go to
the trouble to strip out the additional "safety" part of their firmware
when manufacturing what is essentially the same product, but destined
for other markets?  I think not.  (A question for the audience:  How has
FCC regulation of the maximum power output of WiFi routers affected the
worldwide market for such devices, over time?  I honestly don't know, but
I suspect that there has been a good effect, over time, on the whole
worldwide market.)

It may be difficult, even among technologists, to find common ground and
agreement about what "IoT" things should and should not be able to do,
or even, for that matter, to agree on the definition of "IoT".  But after
last Friday, and even before, I think that most of us know what we *do not*
want them to be able to do, i.e. to send an unlimited percentage of their
available bandwidth towards any arbitrary IP address.  General purpose
computers, and also routers, need to be able to do that, but your bird
feeder, your lightbulb, your HDTV, your refrigerator and your home alarm
system don't.  So maybe that's a starting point.

I proposed something which is at base, really rather simple, even if, in
practice, the implementation details could get a bit complex.  Basically,
the proposal is that the kernels of all IoT devices should impose sensible
limits on outbound bandwidth usage, consistant with each specific device's
expected operational needs.  It seems to me that this is not particularly
different from other belt-and-suspenders approaches used 

Re: Spitballing IoT Security

[Jean-Francois Mezei]

On 2016-10-26 16:58, Mark Andrews wrote:
>
> Actually things have changed a lot in a positive direction.
> 
> * Router manufactures are using device specific passwords.
> * Microsoft, Apple, Linux and *BSD issue regular fixes for their
>   products and users do intall them.
> * My smart TV has automatic updates available and turned on.
> * Other products do the same.

My smart TV not only hasn't gotten updates in years, but Sharp has
stopped selling TVs in Canada. (not sure if they still sell TVs elsewhere).

When manufacturers provide a 2 year support on a device that will last
10 years, it is a problem which is why they really need to get it right
when product is released and not rely on patches.


With regards to liability. Good luck suing a chinese outfit that no
longer exists.

And pray tell, who gets to pay the millions of dollars of lawyer fees it
will cost to sue that bankrupt company with no money ?

Re: Spitballing IoT Security

[Mark Andrews]

xample),
> > > authorities should make sure that those certifications have a broader
> > > scope, including security and probably some other features to ensure th=
> at
> > > in case something is discovered in the future, they can be updated.
> > >
> > > Yes, that means cost, but a few thousand dollars of certification price
> > > increase, among thousands of millions of devices of the same model bein=
> g
> > > manufactured, means a few cents for each unit.
> > >
> > > Even if we speak about 1 dollar per each product being sold, it is much
> > > cheaper than the cost of not doing it and paying for damages, human
> > > resources, etc., when there is a security breach.
> > >
> > > Regards,
> > > Jordi
> > >
> > >
> > > -Mensaje original-
> > > De: NANOG <nanog-boun...@nanog.org> en nombre de Leo Bicknell <
> > > bickn...@ufp.org>
> > > Organizaci=C3=B3n: United Federation of Planets
> > > Responder a: <bickn...@ufp.org>
> > > Fecha: mi=C3=A9rcoles, 26 de octubre de 2016, 19:19
> > > Para: <nanog@nanog.org>
> > > Asunto: Re: Spitballing IoT Security
> > >
> > > In a message written on Wed, Oct 26, 2016 at 08:06:34AM -0400, Rich
> > > Kulawiec wrote:
> > > > The makers of IoT devices are falling all over themselves to rush
> > > products
> > > > to market as quickly as possible in order to maximize their
> > > profits.  They
> > > > have no time for security.  They don't concern themselves with
> > > privacy
> > > > implications.  They don't run networks so they don't care about t=
> he
> > > impact
> > > > their devices may have on them.  They don't care about liability:
> > > many of
> > > > them are effectively immune because suing them would mean
> > > trans-national
> > > > litigation, which is tedious and expensive.  (And even if they
> > lost:
> > > > they'd dissolve and reconstitute as another company the next day.=
> )
> > > > They don't even care about each other -- I'm pretty sure we're
> > > rapidly
> > > > approaching the point where toasters will be used to attack garag=
> e
> > > door
> > > > openers and washing machines.
> > >
> > > You are correct.
> > >
> > > I believe the answer is to have some sort of test scheme (UL
> > > Labratories?) for basic security and updateability.  Then federal
> > > legislation is passed requiring any product being imported into the
> > > country to be certified, or it is refused.
> > >
> > > Now when they rush to market and don't get certified they get $0
> > > and go out of business.  Products are stopped at the boader, every
> > > shipment is reviewed by authorities, and there is no cross boarder
> > > suing issue.
> > >
> > > Really it's product safety 101.  UL, the CPSC, NHTSA, DOT and a
> > > host of others have regulations that if you want to import a produc=
> t
> > > for sale it must be safe.  It's not a new or novel concept, pretty
> > > much every country has some scheme like it.
> > >
> > > --
> > > Leo Bicknell - bickn...@ufp.org
> > > PGP keys at http://www.ufp.org/~bicknell/
> > >
> > >
> > >
> > >
> > > **
> > > IPv4 is over
> > > Are you ready for the new Internet ?
> > > http://www.consulintel.es
> > > The IPv6 Company
> > >
> > > This electronic message contains information which may be privileged or
> > > confidential. The information is intended to be for the use of the
> > > individual(s) named above. If you are not the intended recipient be awa=
> re
> > > that any disclosure, copying, distribution or use of the contents of th=
> is
> > > information, including attached files, is prohibited.
> > >
> > >
> > >
> > >
> >
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Spitballing IoT Security

[bzs]

Re: certification of IoT devices analogous to UL etc

Another potentially useful channel to give this idea legs are
insurance companies, get them involved if possible.

They underwrite the risks particularly liability risks for
manufacturers. That's why "Underwriters Laboratory" is called that,
ultimately it's an arm of the insurance industry.

If the insurance companies tell a manufacturer they won't cover risk
for any non-certified device the device will almost certainly be
improved.

Similar repercussions for wholesale and retail outlets who could
decide to just not offer non-certified devices, for insurance reasons
and otherwise.

As to those who would try maneuvers such as bankrupting or using shell
companies which are dissolved when liabilities occur such willful acts
often allow "piercing of the corporate veil".

That is, those individuals involved can be sued or held criminally
liable personally and any such indemnification made worthless as a
protection or defense.

In the US, at least, if there's a pattern of such behavior, such as
serially setting up shell corps and bankrupting them when trouble
arises, the fearsome RICO statutes can be invoked. Basically they
provide the added felonies of racketeering and engaging in a
conspiracy to commit criminal acts.

Not being located in the US may not be sufficient for evasion of
prosecution, merely doing business in the US (e.g., selling one's
products, establishing a "nexus") can make one a valid target for US
(and other) law enforcement.

The fly I see in all this ointment is that getting there could be a
lot of honest work so who would do that and champion this idea?

-- 
-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: Spitballing IoT Security

[Ken Matlock]

As a relative 'outsider' I see a lot of finger-pointing and phrasing this
as (effectively) someone else's fault.

To me this is a failing on a number of levels all contributing to the
problem.

1) The manufacturer - Backdoors, hidden accounts, remote access
capabilities, no proper security testing. No enforcing of security updates.
2) The end-user - No initiative on the end-user's perspective to gain even
a basic understanding of how the device works, connects, etc. Also no tools
or understanding of how to recognize *which* of their many devices on the
network might be compromised and participating in the botnet. (Only
indication they get is maybe their internet is slow)
3) The service providers - No effective monitoring of outgoing traffic from
the end users to identify botnets and DDoS in a real-time fashion

I contend that all 3 levels have failed in this, and nothing has
fundamentally changed (today it's IoT, before it was unpatched windows
boxes, etc) in decades. We keep talking about the problem but very little
actual action has occurred to *fix* the underlying issues.

- Manufacturers need to be held accountable for devices that go on the
internet (that includes *anything* that's connected. PCs, servers, routers,
IoT devices, etc)
- End users need to have ways to easily see what's going on over their
local networks, to see botnet-like activity and DDoS participation (among
other things) in a more real-time fashion
- Service providers need to be much more proactive in watching for threats
and identifying/blocking them at the source, not allowing the traffic to
flow to your peers and making it someone else's problem. Right now there's
a financial disincentive to doing this, in both real costs (standing up
monitoring gear/etc), and imagined (my ISP is SPYING on me!).

Until we fix all 3 of these main issues we're just going to keep going in
the same set of circles we do every time a 'new' threat/vector comes in.

Now, are these issues *easy*? Oh, heck no!  Are they *cheap*? Once again,
heck no! But to 'fix' this issue it will take all 3 levels being fixed.

If we continue to keep pointing fingers at "the other guy" as the root of
the problem we're inviting external forces (Legislation) to step in and
'fix' the problem for us (and it will just make it worse).

My 2 cents (adjust for inflation)
Ken

On Wed, Oct 26, 2016 at 1:40 PM, jim deleskie <deles...@gmail.com> wrote:

> So device is certified,  bug is found 2 years later.  How does this help.
> The info to date is last week's issue was patched by the vendor in Sept
> 2015, I believe is what I read. We know bugs will creep in, (source anyone
> that has worked with code forever) Also certification assuming it would
> work, in what country, would I need one, per country I sell into?  These
> are not the solutions you are looking for ( Jedi word play on purpose)
>
> On Wed, Oct 26, 2016 at 3:53 PM, JORDI PALET MARTINEZ <
> jordi.pa...@consulintel.es> wrote:
>
> > Exactly, I was arguing exactly the same with some folks this week during
> > the RIPE meeting.
> >
> > The same way that certifications are needed to avoid radio interferences,
> > etc., and if you don’t pass those certifications, you can’t sell the
> > products in some countries (or regions in case of EU for example),
> > authorities should make sure that those certifications have a broader
> > scope, including security and probably some other features to ensure that
> > in case something is discovered in the future, they can be updated.
> >
> > Yes, that means cost, but a few thousand dollars of certification price
> > increase, among thousands of millions of devices of the same model being
> > manufactured, means a few cents for each unit.
> >
> > Even if we speak about 1 dollar per each product being sold, it is much
> > cheaper than the cost of not doing it and paying for damages, human
> > resources, etc., when there is a security breach.
> >
> > Regards,
> > Jordi
> >
> >
> > -Mensaje original-
> > De: NANOG <nanog-boun...@nanog.org> en nombre de Leo Bicknell <
> > bickn...@ufp.org>
> > Organización: United Federation of Planets
> > Responder a: <bickn...@ufp.org>
> > Fecha: miércoles, 26 de octubre de 2016, 19:19
> > Para: <nanog@nanog.org>
> > Asunto: Re: Spitballing IoT Security
> >
> > In a message written on Wed, Oct 26, 2016 at 08:06:34AM -0400, Rich
> > Kulawiec wrote:
> > > The makers of IoT devices are falling all over themselves to rush
> > products
> > > to market as quickly as possible in order to maximize their
> > profits.  They
> > > have no time for security.  They don't concern themselves with
> > privacy
> > > impli

Re: Spitballing IoT Security

[Mel Beckman]

Why does everyone think the Master Plan for World Domination has to be Evil? :)

 -mel beckman

> On Oct 26, 2016, at 12:40 PM, Eric S. Raymond  wrote:
> 
> Mel Beckman :
>> I also really like the idea of offering open source options to vendors, many 
>> of whom seem to illegally take that privilege anyway. A key fast-path 
>> component, though, is in my opinion a new RFC for IoT security best 
>> practices, and probably some revisions to UPNP. 
>> 
>> The IoT RFC would spell out basic rules for safe devices: no back doors, no 
>> default passwords, no gratuitous inbound connections, etc. It would also 
>> make encryption a requirement, and limit how existing UPNP is deployed to 
>> prevent unnecessarily exposing vulnerable TCP/UDP ports to the wild. With 
>> this RFC in hand, and an appropriate splashy icon for vendor packaging (“RFC 
>>  ThingSafe!”), vendors will have a competitive reason for compliance as 
>> a market differentiator, whether they deploy with open-source or proprietary 
>> code.
> 
> That is a good idea and I am officially adopting it as part of the Evil
> Master Plan for World Domination. :-)
> 
> I may recruit you to help draft the RFC.
> -- 
>http://www.catb.org/~esr/;>Eric S. Raymond

Re: Spitballing IoT Security

[Jean-Francois Mezei]

re: having gadgets certified (aka UL/CSA for electric stuff).

Devil is in the details. Who would certify it ? And who would set the
standards for certification?

How fast would those standards change? updated with each new attack?
Would standards update require agreement of multiple parties who rarely
agree?

Consider vendor X who starts to develop product based on standards
available in Oct 2016, but by the time he gets to market, standards have
changed and his device no longer conforms?

One of the beauties of the Internet is the freedom to innovate while
keeping to the core basic IP packet delivery. Start to regulate it or
add red tape and you start to hinder innovation.

Perhaps the RFC mechanism to define best practices for standalone "IoT"
devices might be a better mechanism.  Those who build IP stacks to be
used wholesale by gadget manufacturers could adhere to that RFC so that
end products en up using a proper IP stack that doesn't easily allow the
device to be "upgraded" to serve Dr Evil's botnet designed to take over
the world.

Re: Spitballing IoT Security

[jim deleskie]

So device is certified,  bug is found 2 years later.  How does this help.
The info to date is last week's issue was patched by the vendor in Sept
2015, I believe is what I read. We know bugs will creep in, (source anyone
that has worked with code forever) Also certification assuming it would
work, in what country, would I need one, per country I sell into?  These
are not the solutions you are looking for ( Jedi word play on purpose)

On Wed, Oct 26, 2016 at 3:53 PM, JORDI PALET MARTINEZ <
jordi.pa...@consulintel.es> wrote:

> Exactly, I was arguing exactly the same with some folks this week during
> the RIPE meeting.
>
> The same way that certifications are needed to avoid radio interferences,
> etc., and if you don’t pass those certifications, you can’t sell the
> products in some countries (or regions in case of EU for example),
> authorities should make sure that those certifications have a broader
> scope, including security and probably some other features to ensure that
> in case something is discovered in the future, they can be updated.
>
> Yes, that means cost, but a few thousand dollars of certification price
> increase, among thousands of millions of devices of the same model being
> manufactured, means a few cents for each unit.
>
> Even if we speak about 1 dollar per each product being sold, it is much
> cheaper than the cost of not doing it and paying for damages, human
> resources, etc., when there is a security breach.
>
> Regards,
> Jordi
>
>
> -Mensaje original-
> De: NANOG <nanog-boun...@nanog.org> en nombre de Leo Bicknell <
> bickn...@ufp.org>
> Organización: United Federation of Planets
> Responder a: <bickn...@ufp.org>
> Fecha: miércoles, 26 de octubre de 2016, 19:19
> Para: <nanog@nanog.org>
> Asunto: Re: Spitballing IoT Security
>
> In a message written on Wed, Oct 26, 2016 at 08:06:34AM -0400, Rich
> Kulawiec wrote:
> > The makers of IoT devices are falling all over themselves to rush
> products
> > to market as quickly as possible in order to maximize their
> profits.  They
> > have no time for security.  They don't concern themselves with
> privacy
> > implications.  They don't run networks so they don't care about the
> impact
> > their devices may have on them.  They don't care about liability:
> many of
> > them are effectively immune because suing them would mean
> trans-national
> > litigation, which is tedious and expensive.  (And even if they lost:
> > they'd dissolve and reconstitute as another company the next day.)
> > They don't even care about each other -- I'm pretty sure we're
> rapidly
> > approaching the point where toasters will be used to attack garage
> door
> > openers and washing machines.
>
> You are correct.
>
> I believe the answer is to have some sort of test scheme (UL
> Labratories?) for basic security and updateability.  Then federal
> legislation is passed requiring any product being imported into the
> country to be certified, or it is refused.
>
> Now when they rush to market and don't get certified they get $0
> and go out of business.  Products are stopped at the boader, every
> shipment is reviewed by authorities, and there is no cross boarder
> suing issue.
>
> Really it's product safety 101.  UL, the CPSC, NHTSA, DOT and a
> host of others have regulations that if you want to import a product
> for sale it must be safe.  It's not a new or novel concept, pretty
> much every country has some scheme like it.
>
> --
> Leo Bicknell - bickn...@ufp.org
> PGP keys at http://www.ufp.org/~bicknell/
>
>
>
>
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware
> that any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
>
>
>
>

Re: Spitballing IoT Security

[Eric S. Raymond]

Mel Beckman :
> I also really like the idea of offering open source options to vendors, many 
> of whom seem to illegally take that privilege anyway. A key fast-path 
> component, though, is in my opinion a new RFC for IoT security best 
> practices, and probably some revisions to UPNP. 
> 
> The IoT RFC would spell out basic rules for safe devices: no back doors, no 
> default passwords, no gratuitous inbound connections, etc. It would also make 
> encryption a requirement, and limit how existing UPNP is deployed to prevent 
> unnecessarily exposing vulnerable TCP/UDP ports to the wild. With this RFC in 
> hand, and an appropriate splashy icon for vendor packaging (“RFC  
> ThingSafe!”), vendors will have a competitive reason for compliance as a 
> market differentiator, whether they deploy with open-source or proprietary 
> code. 

That is a good idea and I am officially adopting it as part of the Evil
Master Plan for World Domination. :-)

I may recruit you to help draft the RFC.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Spitballing IoT Security

[JORDI PALET MARTINEZ]

Exactly, I was arguing exactly the same with some folks this week during the 
RIPE meeting.

The same way that certifications are needed to avoid radio interferences, etc., 
and if you don’t pass those certifications, you can’t sell the products in some 
countries (or regions in case of EU for example), authorities should make sure 
that those certifications have a broader scope, including security and probably 
some other features to ensure that in case something is discovered in the 
future, they can be updated.

Yes, that means cost, but a few thousand dollars of certification price 
increase, among thousands of millions of devices of the same model being 
manufactured, means a few cents for each unit.

Even if we speak about 1 dollar per each product being sold, it is much cheaper 
than the cost of not doing it and paying for damages, human resources, etc., 
when there is a security breach.

Regards,
Jordi


-Mensaje original-
De: NANOG <nanog-boun...@nanog.org> en nombre de Leo Bicknell <bickn...@ufp.org>
Organización: United Federation of Planets
Responder a: <bickn...@ufp.org>
Fecha: miércoles, 26 de octubre de 2016, 19:19
Para: <nanog@nanog.org>
Asunto: Re: Spitballing IoT Security

In a message written on Wed, Oct 26, 2016 at 08:06:34AM -0400, Rich 
Kulawiec wrote:
> The makers of IoT devices are falling all over themselves to rush products
> to market as quickly as possible in order to maximize their profits.  They
> have no time for security.  They don't concern themselves with privacy
> implications.  They don't run networks so they don't care about the impact
> their devices may have on them.  They don't care about liability: many of
> them are effectively immune because suing them would mean trans-national
> litigation, which is tedious and expensive.  (And even if they lost:
> they'd dissolve and reconstitute as another company the next day.)
> They don't even care about each other -- I'm pretty sure we're rapidly
> approaching the point where toasters will be used to attack garage door
> openers and washing machines.

You are correct.

I believe the answer is to have some sort of test scheme (UL
Labratories?) for basic security and updateability.  Then federal
legislation is passed requiring any product being imported into the
country to be certified, or it is refused.

Now when they rush to market and don't get certified they get $0
and go out of business.  Products are stopped at the boader, every
shipment is reviewed by authorities, and there is no cross boarder
suing issue.

Really it's product safety 101.  UL, the CPSC, NHTSA, DOT and a
host of others have regulations that if you want to import a product
for sale it must be safe.  It's not a new or novel concept, pretty
much every country has some scheme like it.

-- 
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/




**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.

Re: Spitballing IoT Security

[Jean-Francois Mezei]

While I agree that fixing home routers is the best approach, something
bugs me.

If an IoT vendor doesn't even know that its devices have telnet or ssh
enabled by default (and hence, no management interface to change
passwords)  and only focuses on the web interface it has added , then
how come the kernel would be "UPnP" the telnet port to tell the router
to send inbound telnet to that device ?

And how do routers deal with multiple cameras each sending a "send port
23 requests to me" ?

I can understand a computer sending a UPnP request when you start a game
to tell router to forward inbound calls to a certain port to that
computer/app.  But for IoT devices that are on all the time, there
should be static setup, not UPnP.

Re: Spitballing IoT Security

[Leo Bicknell]

In a message written on Wed, Oct 26, 2016 at 08:06:34AM -0400, Rich Kulawiec 
wrote:
> The makers of IoT devices are falling all over themselves to rush products
> to market as quickly as possible in order to maximize their profits.  They
> have no time for security.  They don't concern themselves with privacy
> implications.  They don't run networks so they don't care about the impact
> their devices may have on them.  They don't care about liability: many of
> them are effectively immune because suing them would mean trans-national
> litigation, which is tedious and expensive.  (And even if they lost:
> they'd dissolve and reconstitute as another company the next day.)
> They don't even care about each other -- I'm pretty sure we're rapidly
> approaching the point where toasters will be used to attack garage door
> openers and washing machines.

You are correct.

I believe the answer is to have some sort of test scheme (UL
Labratories?) for basic security and updateability.  Then federal
legislation is passed requiring any product being imported into the
country to be certified, or it is refused.

Now when they rush to market and don't get certified they get $0
and go out of business.  Products are stopped at the boader, every
shipment is reviewed by authorities, and there is no cross boarder
suing issue.

Really it's product safety 101.  UL, the CPSC, NHTSA, DOT and a
host of others have regulations that if you want to import a product
for sale it must be safe.  It's not a new or novel concept, pretty
much every country has some scheme like it.

-- 
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/


pgprvh44CzuFD.pgp
Description: PGP signature

Re: Spitballing IoT Security

[Mel Beckman]

Eric,

I agree that the home router is a viable choke point, and even though we can’t 
quickly roll out new firmware, if we had started this ten years ago we’d be 
done by now! So this is the ten-year plan, but still worth doing.

I also really like the idea of offering open source options to vendors, many of 
whom seem to illegally take that privilege anyway. A key fast-path component, 
though, is in my opinion a new RFC for IoT security best practices, and 
probably some revisions to UPNP. 

The IoT RFC would spell out basic rules for safe devices: no back doors, no 
default passwords, no gratuitous inbound connections, etc. It would also make 
encryption a requirement, and limit how existing UPNP is deployed to prevent 
unnecessarily exposing vulnerable TCP/UDP ports to the wild. With this RFC in 
hand, and an appropriate splashy icon for vendor packaging (“RFC  
ThingSafe!”), vendors will have a competitive reason for compliance as a market 
differentiator, whether they deploy with open-source or proprietary code. 

This need not add a lot to R costs either, as enterprising embedded system 
designers will now be motivated to delivering packaged ThingSafe! solutions, 
such as embedded wireless controllers, cellular modems, etc. 

Your open-source approach seems to me something that could be started today, 
and that has no downside. The RFC could give it the imprimatur of a standard, 
which makes the plan easier for vendors to sell to their thrift-minded 
management.
 
 -mel


> On Oct 26, 2016, at 5:30 AM, Eric S. Raymond  wrote:
> 
> Rich Kulawiec :
>> I think our working assumption should be that there will be zero cooperation
>> from the IoT vendors.  (Yeah, once in a while one might actually step up,
>> but that will merely be a happy anomaly.)
> 
> I agree.
> 
> There is, however, a chokepoint we have more hope of getting decent software
> deployed to.  I refer to home and small-business routers.  OpenWRT and kin
> are already minor but significant players here. And there's an 
> NRE-minimization
> aregument we can make for router manufacturers to use rebranded versions
> rather than rolling their own crappy firmware.
> 
> I think the anti-IoT-flood strategy that makes the most sense is:
> 
> 1. Push open-source firmware that doesn't suck to the vendors with a
>   cost- and risk-minimization pitch.
> 
> 2. Ship it with egress filters.  (And telnet blocked.)
> 
> It wouldn't be technically very difficult to make the firmware
> rate-limit outbound connections.  Cute trick: if we unlimit any 
> local IP address that is a port-forwarding target, most users
> will never notice because their browser sessions won't be effected.
> -- 
>   http://www.catb.org/~esr/;>Eric S. Raymond

Re: Spitballing IoT Security

[Eric S. Raymond]

Rich Kulawiec :
> I think our working assumption should be that there will be zero cooperation
> from the IoT vendors.  (Yeah, once in a while one might actually step up,
> but that will merely be a happy anomaly.)

I agree.

There is, however, a chokepoint we have more hope of getting decent software
deployed to.  I refer to home and small-business routers.  OpenWRT and kin
are already minor but significant players here. And there's an NRE-minimization
aregument we can make for router manufacturers to use rebranded versions
rather than rolling their own crappy firmware.

I think the anti-IoT-flood strategy that makes the most sense is:

1. Push open-source firmware that doesn't suck to the vendors with a
   cost- and risk-minimization pitch.

2. Ship it with egress filters.  (And telnet blocked.)

It wouldn't be technically very difficult to make the firmware
rate-limit outbound connections.  Cute trick: if we unlimit any 
local IP address that is a port-forwarding target, most users
will never notice because their browser sessions won't be effected.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Spitballing IoT Security

[Rich Kulawiec]

On Mon, Oct 24, 2016 at 01:24:59PM -0700, Ronald F. Guilmette wrote:
>2) Second, once elected I will decree that in future all new IoT devices,
>   and also all updates to firmware for existing IoT devices will have,
>   BUILT IN TO THE KERNEL, code/logic which (a) prevents all outbound TCP
>   session initiation and which also (b) strictly rate-limits all other
>   protocols to some modest value.

I like this idea.  But unfortunately, I think it has no chance of succeeding.

The makers of IoT devices are falling all over themselves to rush products
to market as quickly as possible in order to maximize their profits.  They
have no time for security.  They don't concern themselves with privacy
implications.  They don't run networks so they don't care about the impact
their devices may have on them.  They don't care about liability: many of
them are effectively immune because suing them would mean trans-national
litigation, which is tedious and expensive.  (And even if they lost:
they'd dissolve and reconstitute as another company the next day.)
They don't even care about each other -- I'm pretty sure we're rapidly
approaching the point where toasters will be used to attack garage door
openers and washing machines.

I think our working assumption should be that there will be zero cooperation
from the IoT vendors.  (Yeah, once in a while one might actually step up,
but that will merely be a happy anomaly.)

After all, why should they care?  It doesn't impact their profits,
and profits are all they care about.  They're not the ones fielding
support calls or frantically trying to stop a DoS or trying to work
out a mitigation strategy or participating in this discussion thread.
So they don't care.  They don't have to.

---rsk

Re: Spitballing IoT Security

[bzs]

On October 25, 2016 at 01:10 r...@tristatelogic.com (Ronald F. Guilmette) wrote:
 > 
 > In message , 
 > Jared Mauch  wrote:
 > 
 > >Top posting to provide some clarity:
 > 
 > That's funny.  Personally, I have always felt that top posting -destroys-
 > clarity.  But as Chaplin Tapman said in Catch-22 "I'm not here to judge
 > you."

FWIW I prefer top-posting as I assume anyone interested in the thread
has read the note being responded to and it's only there for someone
late to class or looking for perhaps a misunderstanding or mismatch
between the new text and the quoted text.

In my ideal world there wouldn't even be all this quoting sent back
and forth. It'd just become a type of link perhaps like the HTML #tag
syntax to highlight a specific region of text, which one could click
if they need it.

I'm aware that some MUA's will hide quoted text and only expand it if
asked which is something of a one-sided compromise. One-sided in that
a #tag scheme would require cooperation of some web site out there to
format and hold the target links while just hiding quoted text can be
done entirely within your phone or whatever.

But on some lists I'm on, not this one particularly, there are a lot
of notes going back and forth which are >1MB of nested quoting and the
only new text is "I agree!" or "+1".

Seems dumb but hey disk is cheap and so is talk.

-- 
-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: Spitballing IoT Security

[Bruce Curtis]

> On Oct 25, 2016, at 3:49 AM, Aled Morris  wrote:
> 
> On 25 October 2016 at 09:37, Jean-Francois Mezei <
> jfmezei_na...@vaxination.ca> wrote:
>> 
>> One way around this is for the pet feeder to initiate outbound
>> connection to a central server, and have the pet onwer connect to that
>> server to ask the server to send command to his pet feeder to feed the dog.
>> 
> 
> This is pretty common but, IMHO, the worst solution to this problem.
> 
> It creates a dependence on a cloud service which is typically undocumented
> (what protocol do they use?  where is the server located, China?); a
> centralised service is a security risk in it's own right (crack one server,
> own all the pet feeders); and it is liable to disappear when the operator
> goes out of business, rendering all the products sold useless.
> 
> A strength of IP is that it is fundamentally a peer-to-peer protocol,
> please don't break that.  NAT broke it but IPv6 can fix it again.
> 
> There's nothing wrong with accepting incoming connections if the device is
> secure.  If your problem is security, fix that.  Don't throw the baby out
> with the bath water.
> 
> Aled

  How about SDP?  SDP is most often implemented in a gateway in the network 
today but there is no reason it couldn’t be implemented in each IoT device.
With SDP inbound connections are not allowed until they are authenticated by 
another box.

A good quote from Gartner.

"Through the end of 2017, at least 10% of enterprise organizations (up from 
less than 1% today) will leverage software-defined perimeter (SDP) technology 
to isolate sensitive environments." 

http://info.vidder.com/gartner-predicts-2016-security-solutions

This is the presentation on SDP from the 2015 Internet2 Tech Exchange.

http://meetings.internet2.edu/2015-technology-exchange/detail/10003978/


Videos explaining SDP.

https://www.vidder.com/product-videos/

https://www.vidder.com/wp-content/uploads/2016/09/rethinking-connectivity.mp4

https://www.vidder.com/wp-content/uploads/2016/09/spa.mp4


SDP info from another vendor.

https://www.cryptzone.com/forms/the-software-defined-perimeter-creating-an-invisible-infrastructure

http://www.infosecurityeurope.com/__novadocuments/90951?v=63570932772583



https://cloudsecurityalliance.org/group/software-defined-perimeter/

https://en.wikipedia.org/wiki/Software_Defined_Perimeter



https://cloudsecurityalliance.org/media/news/cloud-security-alliance-to-host-third-software-defined-perimeter-sdp-hackathon-top-prize-of-1-available/

" no one was able to circumvent even the first of the five SDP security 
controls layers (single packet authorization protocol), despite more than 5 
billion packets being fired at the SDP.”


https://www.vidder.com/resources/docs/CSA-Verizon-Vidder-Hackathon4-Reliability.pdf


http://www.networkworld.com/article/3053561/security/learning-about-sdp-via-google-beyondcorp.html

https://www.sdxcentral.com/articles/news/software-defined-perimeter-remains-undefeated-in-hackathon/2015/08/





---
Bruce Curtis bruce.cur...@ndsu.edu
Certified NetAnalyst II701-231-8527
North Dakota State University

Re: Spitballing IoT Security

[Jared Mauch]

On Tue, Oct 25, 2016 at 12:09:26AM +0200, Matthias Waehlisch wrote:
> IoT is not a well-defined term.

Agreed.  This is why I call it Internet of Trash.

> IoT implementations depend on system constraints.

Of course, this is how you see LoWPAN pop up as
a possible solution.

> These constraints may relate to security (problems/solutions).

Yes, and the lack of any bar being set is critical.
The problem here isn't too many standards, it's the lack of
a consistent one.  

> It would be helpful to be more specific.
> See https://tools.ietf.org/html/rfc7228, for example.

Perhaps time for an informational RFC or similar
that can be cited as the low bar?  The problem with best
practices is they aren't, and that's clearly outlined in
the most recent weeks events.

- Jared

> Cheers
>   matthias
> 
> On Mon, 24 Oct 2016, Jared Mauch wrote:
> 
> > Top posting to provide some clarity:
> > 
> > 1) Many IoT devices are connected via some cloud service, think Nest (for 
> > example)
> > 2) Many IoT devices have cloud management, think of Ruckus, UBNT UniFi, etc 
> > that
> >phone out to a site via DHCP option or otherwise.
> > 3) Many IoT devices are something like a set top box, these need access to 
> > a CDN
> >or similar to get the content for the users.
> > 4) Many IoT consumers don’t read NANOG, so they also won’t set up a 
> > firewall other
> >than to know it is a service impairing tool that must be disabled for 
> > their
> >devices to work.
> > 5) There are few/no new lessons here compared to the default install of 
> > Redhat 3.0.3
> >from the late-1990s.  I recall it by default installed INN a usenet news 
> > server.
> >As a usenet operator, this baffled me as they had insufficient memory, 
> > storage
> >etc to do this task, and left security surface quite wide.
> > 
> >We must promote secure by default.  This means some sort of secondary 
> > authentication
> >such as a sticker on the device with default password or requiring the 
> > entering of
> >a serial number or basic setup information to work.
> > 6) Devices need to prompt for updates.
> > 
> >Apple has sorted this nicely, people are prompted for supported 
> > upgrades, disjoint
> >from carriers and other issues.  Contrast this with other ecosystems 
> > where upgrades
> >require extra steps or have a non-OEM partner involved (eg: Cell 
> > Carrier, Cable Co).
> > 
> >These devices get less frequent updates, ostensibly for testing but also 
> > leave known
> >issues exposed for months or years.
> > 7) Malware can damage systems making them require extra steps to recover 
> > them.  Whitehats
> >may know some mitigation techniques, but can’t protect you either.  Some 
> > people have
> >taken a more aggressive approach, eg: 
> > https://gitlab.com/rav7teif/linux.wifatch
> > 
> >They will block others from infecting your device until it’s rebooted.
> > 
> > - Jared
> > 
> > > On Oct 24, 2016, at 4:24 PM, Ronald F. Guilmette  
> > > wrote:
> > > 
> > > 
> > > In message , 
> > > John Weekes  wrote:
> > > 
> > >> On 10/23/2016 4:19 PM, Ronald F. Guilmette wrote:
> > > jw>>> ... The ISPs behind those IP addresses have
> > > jw>>> received notifications via email...
> > > rfg>> Just curious... How well is that working out?
> > >> 
> > >> For the IoT botnets, most of the emails are ignored or rejected, because 
> > >> most go to providers who either quietly bitbucket them or flat-out 
> > >> reject all abuse emails. Most emails sent to mainland China, for 
> > >> instance, are in that category (Hong Kong ISPs are somewhat better)...
> > > 
> > > So, given the apparently impracticality of trying to clean up all of these
> > > kinds of messes via the good old-fashioned tedious and laborious method
> > > of emailing the relevant providers and then just sort-of vaguely hoping
> > > that they will -do something- responsible with it, I am just sitting here
> > > trying to dream up some sort of generalized long-term fix for -all- of
> > > these IoT DDoS type problems.
> > > 
> > > Maybe there just plain isn't any such thing as a general solution to the
> > > problem, because it may perhaps be just technically too complex.  But I 
> > > hope
> > > no one will begrudge me if I yearn for some sort of Grand Unified Field
> > > Theory of IoT security.
> > > 
> > > So, I have a thought... probably worth what you paid for it... and I'm 
> > > just
> > > brave enough to throw it out on the table and then everybody can pile on
> > > and tell me what an idiot I am, for this or that perfectly sound technical
> > > reason.  (I'll say up front that I don't even pretend to understand many
> > > of the protocols in use these days, in particular UPnP, and to be frank,
> > > I'd never even heard of SSDP until yesterday.  So I can't and won't 
> > > begrudge
> 

Re: Spitballing IoT Security

[Chris Boyd]

> On Oct 25, 2016, at 3:10 AM, Ronald F. Guilmette  
> wrote:
> 
> An IoT is -not- a general purpose computer.  In the latter case, it is
> assumed that the owner will "pop the hood" when it comes to the software
> configuration.

Ah, but they are.  In many cases you can ship a product faster and cheaper with 
an ARM based system running a stripped down Linux and some specialty I/O than 
building a properly hardened custom microcontroller.  Source: Recently went 
through a round of proposals and bids for a small IoT type product.

Also, you probably _don’t_ want the average consumer “popping the hood” on 
their PC OS.  They will screw something up.  Worked in small business IT hell 
for 8 years, and that was the single most dangerous thing a customer could do.

—Chris

Re: Spitballing IoT Security

[Ronald F. Guilmette]

In message <580f19bf.2070...@vaxination.ca>, 
Jean-Francois Mezei  wrote:

>One way around this is for the pet feeder to initiate outbound
>connection to a central server, and have the pet onwer connect to that
>server to ask the server to send command to his pet feeder to feed the dog.
>
>This way, there need not be any inbound connection to the pet feeder.

Right.  And even that one outbound connection (from the pet feeder to
the central server) isn't going to need much in the way of bandwidth.

So if the kernel wakes up and notices "Whoa!  Wait a minute here!
This box is sending out in excess of 100 kilobits per second!" then
something is REALLY wrong here.  Time to let that ethernet interface
take a little nap.

Likewise if the kernel notices that the box has just sent out in excess
of, say, 100 outbound UDP packets with destination port set to 53 in the
last 60 seconds.  Time to send DNS to its room for a little "bad behavior"
time out!  Because in practice, for most or all of the kinds of IoT devices
I can think of, (a) they shouldn't be sending out DNS -responses-, ever,
and (b) if they are sending out more than, say, 100 outbound DNS -queries-
per minute, then the only possible reason they would be doing so is that
the box itself has been enslaved and is participating in a DNS reflection
attack.

The point is that for many (most?) types of IoT devices the engineers
who designed the box should be able to tell... or at least predict...
what the maximum theoretical outbound bandwidth usage and/or the maximum
theoretical outbound packets per second for various protocols and ports
ought to be... assuming that the box is functioning "normally", as the
original design engineers intended, and not as some miscreant's slave.
So then they, the original design engineers, can hard code limits into
the kernel... limits that are, say, 25% above these worst case "normal
operation" limits, thus allowing for a healthy margin of error.

The result would be a box that can't be turned into a weapon, no matter
what, at least not without loading up all new (and malicious) firmware,
a task which should require at least some direct, hands-on manually
fiddling (such as pressing and holding the reset button) in any event.

I refer again to the Ford Pinto, and also to the Apollo 1 fire.  I don't
think that there's really a problem with engineering belt-and-suspenders
safeguards into the firmware of IoT things.  The only real problem is
providing both companies and engineers with the motivation necessary to
insure they will do so.

Let's hope that nobody has to die before we find a way to manufacture
that motivation.  (A little temporary bad press for one Chinese manu-
facturer of CCTV cameras isn't going to be sufficient, I'm afraid.)


Regards,
rfg