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]

In message 
, Ken 
Matlock writes:
> 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.

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.

Now not everyone does this sort of thing yet, but we have examples
and things don't blow up in the user's face very often.  Even in
the case the manufacture has tried to do the right thing.  The
problem had been identified and a fix issued.  Now could this have
been automated, yes.  But it does show that what is required is
getting through to manufactures and they are trying to reduce the
problem.

We need manufactures to have a working system to accept problem
reports.  We need manufactures to issue fixes to their products
once they have been reported.  This needs to happen for the entire
expected lifetime of a product.  We need the ability to have a third
parties fix problems if a manufacture won't / is too slow.

Getting this may require legislation changes.  This may require
manufactures to publish expected product lifetimes.

> - 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  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 anyon=
> e
> > 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 durin=
> g
> > > the RIPE meeting.
> > >
> > > The same way that certifications are needed to avoid radio interference=
> s,
> > > etc., and if you don=E2=80=99t pass those certifications, you can=E2=80=
> =99t 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 th=
> at
> > > in case something is discovered in the future, they can be updated.
> > >
> > > Yes, that means cost, but a few thousand 

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  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  en nombre de Leo Bicknell <
> > bickn...@ufp.org>
> > Organización: United Federation of Planets
> > Responder a: 
> > Fecha: miércoles, 26 de octubre de 2016, 19:19
> > Para: 
> > 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:
> 

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  en nombre de Leo Bicknell <
> bickn...@ufp.org>
> Organización: United Federation of Planets
> Responder a: 
> Fecha: miércoles, 26 de octubre de 2016, 19:19
> Para: 
> 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  en nombre de Leo Bicknell 
Organización: United Federation of Planets
Responder a: 
Fecha: miércoles, 26 de octubre de 2016, 19:19
Para: 
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