Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Rob McEwen]

On 1/11/2019 2:50 PM, Grant Taylor via NANOG wrote:

On 01/11/2019 12:32 PM, Rob McEwen wrote:
but if done right, fwiw,, wouldn't that be sent over SMTP using TLS 
encryption?


Oy vey.  in-flight vs at-rest encryption.  


which is why i said "fwiw", acknowledging upfront that TLS transmission 
encryption has a limited scope. I guess you missed that?  But I was 
specifically replying to a complaint about passwords being sent in plain 
text, and I was suggesting that TLS would solve that problem. At that 
point in the discussion, it wasn't a discussion about all things 
encryption. ("context" is very helpful - are you still facepalming?)




On 01/11/2019 12:32 PM, Rob McEwen wrote:

(but, then again, that ALSO requires a certificate!)
Let's Encrypt works perfectly fine for that too.  }:-) 



Exactly! That was sort of my point too. The person creating that 
dumpsterfire list seemed to be trying to avoid having to install a 
security certificate, but having that security certificate solves other 
problems besides the website getting https, such as enabling TLS, too. 
That was my basic point, I was just trying to be less wordy.


--
Rob McEwen, invaluement

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[cosmo]

Whaddya expect guys, the mailing list is hosted on an embedded DVR recorder

On Fri, Jan 11, 2019 at 12:52 PM Töma Gavrichenkov 
wrote:

> 11 Jan. 2019 г., 23:19 Mark Andrews :
> >> So STARTTLS strip is not a problem anymore?
>
>>
> > If you deploy DANE (client and server
> > sides) then stripping STARTTLS is
> > ineffective for the target domain.
>
> If you defer to send (and finally bounce) everything targeted at a domain
> that fails TLSA lookup, then fair enough. I don't think this is (and is
> going to be in the near future) the case for the dumpsterfire mailing list,
> but you may rightfully assume I haven't checked yet.
>
> > gmail.com hasn’t (server side at least).
>
> Google folks are on this mailing list, so it's best if they speak for me
> (though I believe I pretry much know their reasoning).
>
> --
> Töma
>

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Töma Gavrichenkov]

11 Jan. 2019 г., 23:19 Mark Andrews :
>> So STARTTLS strip is not a problem anymore?

>
> If you deploy DANE (client and server
> sides) then stripping STARTTLS is
> ineffective for the target domain.

If you defer to send (and finally bounce) everything targeted at a domain
that fails TLSA lookup, then fair enough. I don't think this is (and is
going to be in the near future) the case for the dumpsterfire mailing list,
but you may rightfully assume I haven't checked yet.

> gmail.com hasn’t (server side at least).

Google folks are on this mailing list, so it's best if they speak for me
(though I believe I pretry much know their reasoning).

--
Töma

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Mark Andrews]

> On 12 Jan 2019, at 6:36 am, Töma Gavrichenkov  wrote:
> 
> 11 Jan. 2019 г., 22:33 Rob McEwen :
> > but if done right, fwiw,, wouldn't that
> > be sent over SMTP using TLS encryption
> 
> So STARTTLS strip is not a problem anymore?

If you deploy DANE (client and server sides) then stripping STARTTLS is
ineffective for the target domain. 

We (isc.org) have but gmail.com hasn’t (server side at least).  On could be
asking why you are using gmail.com when they don’t care enough to signal to
the world that STARTTLS is supported and should be there in the EHLO.

% dig mx isc.org +dnssec
;; BADCOOKIE, retrying.

; <<>> DiG 9.13.1+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4910
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 13

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: bfabca20a2ed6fe032fae4e75c38f7eecca21769def0a3e3 (good)
;; QUESTION SECTION:
;isc.org.   IN  MX

;; ANSWER SECTION:
isc.org.7140IN  MX  20 mx.ams1.isc.org.
isc.org.7140IN  MX  10 mx.pao1.isc.org.
isc.org.7140IN  RRSIG   MX 5 2 7200 20190206233314 
20190107233314 19923 isc.org. 
UBu26XwokUyCwZvBzp5+kajy686RF4cdA/Un3Z3vtEARG8qx0hQfHoTk 
lGfGPkt21QdZmqX+ZJcdO3LfA+qU9A3aEJMXZi9aMZkPDWu1aPsJBu6U 
3U3Tj9j+DsqL2Uk780TAqQQQWFUwIHF+y0hcRIWPaqUuvygl/5jxdVDN Mls=

;; ADDITIONAL SECTION:
mx.pao1.isc.org.3541IN  A   149.20.64.53
mx.ams1.isc.org.3544IN  A   199.6.1.65
mx.pao1.isc.org.3541IN  2001:4f8:0:2::2b
mx.ams1.isc.org.3544IN  2001:500:60::65
mx.pao1.isc.org.3541IN  RRSIG   A 5 4 3600 2019020623 
2019010723 13902 pao1.isc.org. 
WrDcCGC0SmNUSh+DBxogVXWU2PQVpJ/6S/WJxpU4fLDpI+0J85aep+e1 
NwZRUuw9N5RRuslQSz0y+aiwB0RACq2wbPUxDem21KpzKE8rlrAlf0U9 
k9sT1PeCkWu7QOiWgEksnoJijyCVY41Q/GB0HnWzaO4jUtay6e/PBj4c IiA=
mx.pao1.isc.org.3541IN  RRSIG    5 4 3600 2019020623 
2019010723 13902 pao1.isc.org. 
EaYgxAGrmJ9oiX4u2DfIcHKCqen3RNGylmWT0VjJ8VWY5e/c5TA1eI5U 
evGsvYhvLD4WvR8hzvKxp4Pc5EYKLoB+YRI4ttUgnTydsEI0xFCcgB4+ 
dFb+89h8e6tHSPhUa1wa7ObriKm1O5FzplEXLfNFbgEUN6oJOIMw7q8w cC8=
_25._tcp.mx.pao1.isc.org. 3543  IN  RRSIG   TLSA 5 6 3600 2019020623 
2019010723 13902 pao1.isc.org. 
liSDcLgGpDXqgTxkv2sQBI3OsACPflpxoZxcrgSge4yTe5gA97NOPe0l 
ECmDBPzUkhcRI6Mwv+uBCmm5FBvgh0leNxLXzACdkCX8EscE3v74wd5o 
ReCRGFAhV6TBjycwejkGARVTYF23RyRflq2/fRV2hoOdH2ImcW7/SMqA 8Jg=
mx.ams1.isc.org.3544IN  RRSIG   A 5 4 3600 20190206233315 
20190107233315 5730 ams1.isc.org. 
E+6nzEbFAcftlr3UTaCcw0LAHYIdVe5TNfyIwVwU71AzZB22jiif/BrQ 
KxemOrR7LT7ukfDRjnEzfV1/s0Wwfxh0b79otxrDwssKzNKz9XhaIhVf 
j17oyuQBkYjYv5RBuwsrmKQmSbu56Zu7G35xp2qbKi6E+3lpXPghnrnJ DBk=
mx.ams1.isc.org.3544IN  RRSIG    5 4 3600 20190206233315 
20190107233315 5730 ams1.isc.org. 
ov/6HUTx8v7t31KBYVgDy02Bpe8rJX431vPDdRZvKKhffFrYmUOIXEqD 
Q/3+DNV1axSJCTONJ1NwzoSC8LDwQQFUcAsXnhcW/C/Z3rbaEthetmmP 
TERuRGjF3QdA+qFM8RCc83s+hp1RXo5cU+9wA8OTPT5nTmfthkDs/cUi 0o8=
_25._tcp.mx.ams1.isc.org. 3545  IN  RRSIG   TLSA 5 6 3600 20190206233315 
20190107233315 5730 ams1.isc.org. 
qdzOyIbkPhufqw6/B5bwpxJ0pfVeUay2v8O5spUa+xgHdLQFNS851vlW 
KOYrNfZALDomXkOyfAVTEZXQ1g3xf0gzIcRCy0PHcgDtgl5a56AilFGB 
n6LZVkh6lbAkQ8lSmlKWmOvAmJnXh6L6dX8/CQzpWT7G0EEL1EcvLW6p uZ0=
_25._tcp.mx.pao1.isc.org. 3543  IN  TLSA3 0 1 
71903FF43D60CA91BDB7AA0DFE9C247B1A2C5A6002C436451C3C1684 0C607AE0
_25._tcp.mx.ams1.isc.org. 3545  IN  TLSA3 0 1 
5EF9B10DA21B2711522982EAD699FBABE77FD07FF07AC810608A85DA 66AFE916

;; Query time: 7 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jan 12 07:09:18 AEDT 2019
;; MSG SIZE  rcvd: 1555

% 

> --
> Töma

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

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Anne P. Mitchell, Esq.]

Additionally, subscribe mail to the email address is bouncing.

Anne

Anne P. Mitchell, 
Attorney at Law
CEO/President, 
SuretyMail Email Reputation Certification
http://www.SuretyMail.com/
Certified Sender DNSBL here: iadb.isipp.com 
Info here: https://www.isipp.com/email-accreditation/for-isps/
GDPR, CCPA (CA) & CCDPA (CO) Compliance Consulting


> On Jan 10, 2019, at 9:57 AM, J. Hellenthal via NANOG  wrote:
> 
> Unfortunately I don’t see this as having very much connectivity where I am at.
> 
> host firemountain.net
> firemountain.net has address 207.114.3.55
> firemountain.net mail is handled by 10 taos.firemountain.net.
> firemountain.net mail is handled by 20 ukiah.firemountain.net.
> 
> host www.firemountain.net
> www.firemountain.net has address 207.114.3.55
> 
> Sending 5, 100-byte ICMP Echos to 207.114.3.55, timeout is 2 seconds:
> !
> Success rate is 20 percent (1/5), round-trip min/avg/max = 51/51/51 ms
> 
> Tracing the route to firemountain.net (207.114.3.55)
> 
>  1  0 msec 0 msec 0 msec
>  2 142.254.152.249 9 msec 9 msec 17 msec
>  3 ae62.nwblwi1801h.midwest.rr.com (24.164.241.145) 16 msec 16 msec 9 msec
>  4 be63.milzwift01r.midwest.rr.com (65.31.112.122) 25 msec 16 msec 17 msec
>  5 be40.clmkohpe01r.midwest.rr.com (65.25.137.109) 25 msec 25 msec 34 msec
>  6 be1.clmkohpe02r.midwest.rr.com (65.29.1.35) 34 msec 34 msec 25 msec
>  7 ae1.uparohgd01h.midwest.rr.com (24.33.161.209) 34 msec 42 msec 25 msec
>  8 69.23.10.160 34 msec 25 msec 25 msec
>  9 rrcs-98-102-146-106.central.biz.rr.com (98.102.146.106) 25 msec 34 msec 25 
> msec
> 10 xe-0-0-0.upa-core1.expedient.com (66.230.78.130) 33 msec 34 msec 25 msec
> 11 et-0-2-0.acm-core2.expedient.com (209.166.144.209) 34 msec 34 msec 34 msec
> 12 irb-4038.acm-core1.expedient.com (209.166.144.21) 33 msec 33 msec 25 msec
> 13 et-3-0-0.152-core2.expedient.com (66.230.78.194) 33 msec 33 msec 34 msec
> 14 ae2.152-core1.expedient.com (66.230.78.161) 42 msec 34 msec 34 msec
> 15 xe-0-3-0.fil-node.expedient.com (206.210.75.234) 42 msec 42 msec 51 msec
> 16 xe-0-3-0.1sc-node.expedient.com (216.230.108.246) 50 msec 42 msec 59 msec
> 17 ten1-6-2.tdp-core.expedient.com (216.230.108.229) 42 msec 42 msec 50 msec
> 18 firemountain.net (207.114.3.55) 50 msec 42 msec 51 msec
> 
> 
> HTH
> 
>> On Jan 10, 2019, at 10:22, Rich Kulawiec  wrote:
>> 
>> The "dumpsterfire" mailing list is for the discussion of security and
>> privacy issues related to the IoT (Internet of Things).  Arguably,
>> the entire IoT *is* a security and privacy issue, but we'll get to that
>> in good time.
>> 
>> If you want to join, you can either use the list's web page:
>> 
>>  http://www.firemountain.net/mailman/listinfo/dumpsterfire
>> 
>> or the list's subscription/unsubscription address:
>> 
>>  dumpsterfire-requ...@firemountain.net
>> 
>> The list is public and so is its archive.
>> 
>> ---rsk
> 
> 
> —
> 
> J. Hellenthal
> 
> The fact that there's a highway to Hell but only a stairway to Heaven says a 
> lot about anticipated traffic volume.
> 
> 
> 
> 
> 

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Bryan Holloway]

On 1/11/19 12:11 PM, Andreas Ott wrote:

On Fri, Jan 11, 2019 at 12:17:09PM -0500, Rich Kulawiec wrote:

On Fri, Jan 11, 2019 at 08:23:31AM -0800, Yang Yu wrote:

   * no HTTPS


HTTPS isn't needed for this application.  I'll probably add it anyway
when I have a chance, but there are other things ahead of it.


I respectfully disagree:

http://www.firemountain.net/mailman/options/dumpsterfire/b...@example.com

asks for a "password" which is then transported over clear text. The year
is 2019 and there's always letsencrypt SSL certs. Admittedly, mailman does
send you the password in clear text over SMTP if you ask for it.


-andreas

To borrow a quote: The 'S' in IoT stands for 'Security'.



I thought it stood for ZEPPELIN.

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Grant Taylor via NANOG]

On 01/11/2019 12:32 PM, Rob McEwen wrote:
but if done right, fwiw,, wouldn't that be sent over SMTP using TLS 
encryption?


Oy vey.  in-flight vs at-rest encryption.  


(but, then again, that ALSO requires a certificate!)


Let's Encrypt works perfectly fine for that too.  }:-)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Töma Gavrichenkov]

11 Jan. 2019 г., 22:33 Rob McEwen :
> but if done right, fwiw,, wouldn't that
> be sent over SMTP using TLS encryption

So STARTTLS strip is not a problem anymore?

--
Töma

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Rob McEwen]

On 1/11/2019 1:11 PM, Andreas Ott wrote:

Admittedly, mailman does
send you the password in clear text over SMTP if you ask for it



 but if done right, fwiw,, wouldn't that be sent over SMTP using TLS 
encryption? (but, then again, that ALSO requires a certificate!)


--
Rob McEwen, invaluement

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Andreas Ott]

On Fri, Jan 11, 2019 at 12:17:09PM -0500, Rich Kulawiec wrote:
> On Fri, Jan 11, 2019 at 08:23:31AM -0800, Yang Yu wrote:
> >   * no HTTPS
> 
> HTTPS isn't needed for this application.  I'll probably add it anyway
> when I have a chance, but there are other things ahead of it.

I respectfully disagree:

http://www.firemountain.net/mailman/options/dumpsterfire/b...@example.com

asks for a "password" which is then transported over clear text. The year 
is 2019 and there's always letsencrypt SSL certs. Admittedly, mailman does
send you the password in clear text over SMTP if you ask for it.


-andreas

To borrow a quote: The 'S' in IoT stands for 'Security'.

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Töma Gavrichenkov]

Thank you! Forwarded that to the RIPE IoT WG.

10 Jan. 2019 г., 19:23 Rich Kulawiec :

> The "dumpsterfire" mailing list is for the discussion of security and
> privacy issues related to the IoT (Internet of Things).  Arguably,
> the entire IoT *is* a security and privacy issue, but we'll get to that
> in good time.
>
> If you want to join, you can either use the list's web page:
>
> http://www.firemountain.net/mailman/listinfo/dumpsterfire
>
> or the list's subscription/unsubscription address:
>
> dumpsterfire-requ...@firemountain.net
>
> The list is public and so is its archive.
>
> ---rsk
>

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Rich Kulawiec]

On Thu, Jan 10, 2019 at 10:57:02AM -0600, J. Hellenthal via NANOG wrote:
> Unfortunately I don???t see this as having very much connectivity where I am 
> at.

It's not the best-connected or most powerful server, however it's been
running a bunch of public/private mailing lists for many years and
for that purpose, it's sufficed nicely.   (That's one of the many major
advantages of mailing lists over web forums: they don't need much in
the way of connectivity, bandwidth, or horsepower.)  Sure, I'd like
to have bigger/better/faster/more, but since I'm paying for this
out of my own pocket...

---rsk

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Rich Kulawiec]

On Fri, Jan 11, 2019 at 08:23:31AM -0800, Yang Yu wrote:
>   * no HTTPS

HTTPS isn't needed for this application.  I'll probably add it anyway
when I have a chance, but there are other things ahead of it.

>   * archive is returning HTTP 403

That is exactly what you should expect to see when a Mailman archive is empty,
as it is for any new mailing list.  Now it's not.  So now you won't.

---rsk

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Brian Kantor]

On Fri, Jan 11, 2019 at 10:30:57AM -0600, Mike Hammett wrote:
> No HTTPS?!?! Where are the tar and feathers??!?!! 
> 
> This isn't something that needs HTTPS. 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 

True, but our browser overlords would condemn it because they seem
to believe that EVERYTHING should be guarded by https.
- Brian

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Mike Hammett]

No HTTPS?!?! Where are the tar and feathers??!?!! 




This isn't something that needs HTTPS. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Yang Yu"  
To: "Rich Kulawiec"  
Cc: "NANOG list"  
Sent: Friday, January 11, 2019 10:23:31 AM 
Subject: Re: Announcing: "dumpsterfire", the mailing list for IoT 
security/privacy issues 

On Thu, Jan 10, 2019 at 8:23 AM Rich Kulawiec  wrote: 
> 
> The "dumpsterfire" mailing list is for the discussion of security and 
> privacy issues related to the IoT (Internet of Things). Arguably, 
> the entire IoT *is* a security and privacy issue, but we'll get to that 
> in good time. 
> 
> If you want to join, you can either use the list's web page: 
> 
> http://www.firemountain.net/mailman/listinfo/dumpsterfire 
> 
> or the list's subscription/unsubscription address: 
> 
> dumpsterfire-requ...@firemountain.net 
> 
> The list is public and so is its archive. 

* no HTTPS 
* archive is returning HTTP 403 

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Ross Tajvar]

A dumpster fire, indeed.

On Fri, Jan 11, 2019, 11:26 AM Yang Yu  On Thu, Jan 10, 2019 at 8:23 AM Rich Kulawiec  wrote:
> >
> > The "dumpsterfire" mailing list is for the discussion of security and
> > privacy issues related to the IoT (Internet of Things).  Arguably,
> > the entire IoT *is* a security and privacy issue, but we'll get to that
> > in good time.
> >
> > If you want to join, you can either use the list's web page:
> >
> > http://www.firemountain.net/mailman/listinfo/dumpsterfire
> >
> > or the list's subscription/unsubscription address:
> >
> > dumpsterfire-requ...@firemountain.net
> >
> > The list is public and so is its archive.
>
>   * no HTTPS
>   * archive is returning HTTP 403
>

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Yang Yu]

On Thu, Jan 10, 2019 at 8:23 AM Rich Kulawiec  wrote:
>
> The "dumpsterfire" mailing list is for the discussion of security and
> privacy issues related to the IoT (Internet of Things).  Arguably,
> the entire IoT *is* a security and privacy issue, but we'll get to that
> in good time.
>
> If you want to join, you can either use the list's web page:
>
> http://www.firemountain.net/mailman/listinfo/dumpsterfire
>
> or the list's subscription/unsubscription address:
>
> dumpsterfire-requ...@firemountain.net
>
> The list is public and so is its archive.

  * no HTTPS
  * archive is returning HTTP 403

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[J. Hellenthal via NANOG]

Unfortunately I don’t see this as having very much connectivity where I am at.

host firemountain.net
firemountain.net has address 207.114.3.55
firemountain.net mail is handled by 10 taos.firemountain.net.
firemountain.net mail is handled by 20 ukiah.firemountain.net.

host www.firemountain.net
www.firemountain.net has address 207.114.3.55

Sending 5, 100-byte ICMP Echos to 207.114.3.55, timeout is 2 seconds:
!
Success rate is 20 percent (1/5), round-trip min/avg/max = 51/51/51 ms

Tracing the route to firemountain.net (207.114.3.55)

  1  0 msec 0 msec 0 msec
  2 142.254.152.249 9 msec 9 msec 17 msec
  3 ae62.nwblwi1801h.midwest.rr.com (24.164.241.145) 16 msec 16 msec 9 msec
  4 be63.milzwift01r.midwest.rr.com (65.31.112.122) 25 msec 16 msec 17 msec
  5 be40.clmkohpe01r.midwest.rr.com (65.25.137.109) 25 msec 25 msec 34 msec
  6 be1.clmkohpe02r.midwest.rr.com (65.29.1.35) 34 msec 34 msec 25 msec
  7 ae1.uparohgd01h.midwest.rr.com (24.33.161.209) 34 msec 42 msec 25 msec
  8 69.23.10.160 34 msec 25 msec 25 msec
  9 rrcs-98-102-146-106.central.biz.rr.com (98.102.146.106) 25 msec 34 msec 25 
msec
 10 xe-0-0-0.upa-core1.expedient.com (66.230.78.130) 33 msec 34 msec 25 msec
 11 et-0-2-0.acm-core2.expedient.com (209.166.144.209) 34 msec 34 msec 34 msec
 12 irb-4038.acm-core1.expedient.com (209.166.144.21) 33 msec 33 msec 25 msec
 13 et-3-0-0.152-core2.expedient.com (66.230.78.194) 33 msec 33 msec 34 msec
 14 ae2.152-core1.expedient.com (66.230.78.161) 42 msec 34 msec 34 msec
 15 xe-0-3-0.fil-node.expedient.com (206.210.75.234) 42 msec 42 msec 51 msec
 16 xe-0-3-0.1sc-node.expedient.com (216.230.108.246) 50 msec 42 msec 59 msec
 17 ten1-6-2.tdp-core.expedient.com (216.230.108.229) 42 msec 42 msec 50 msec
 18 firemountain.net (207.114.3.55) 50 msec 42 msec 51 msec


HTH

> On Jan 10, 2019, at 10:22, Rich Kulawiec  wrote:
> 
> The "dumpsterfire" mailing list is for the discussion of security and
> privacy issues related to the IoT (Internet of Things).  Arguably,
> the entire IoT *is* a security and privacy issue, but we'll get to that
> in good time.
> 
> If you want to join, you can either use the list's web page:
> 
>   http://www.firemountain.net/mailman/listinfo/dumpsterfire
> 
> or the list's subscription/unsubscription address:
> 
>   dumpsterfire-requ...@firemountain.net
> 
> The list is public and so is its archive.
> 
> ---rsk


—

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.







signature.asc
Description: Message signed with OpenPGP

Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

[Rich Kulawiec]

The "dumpsterfire" mailing list is for the discussion of security and
privacy issues related to the IoT (Internet of Things).  Arguably,
the entire IoT *is* a security and privacy issue, but we'll get to that
in good time.

If you want to join, you can either use the list's web page: 

http://www.firemountain.net/mailman/listinfo/dumpsterfire

or the list's subscription/unsubscription address:

dumpsterfire-requ...@firemountain.net

The list is public and so is its archive.

---rsk

Re: IoT security

[Rich Kulawiec]

On Tue, Feb 07, 2017 at 08:58:46AM -0500, Ray Soucy wrote:
> Ideally a cloud-managed device so that the config wouldn't need
> to be rebuilt in the event of a hardware swap.

That opens them to a class breach: instead of one getting compromised
they *all* get compromised.  Better to save the configuration to cheap
local media like a USB stick.  Yes, it could get lost, but that doesn't
break or compromise the device, and it only affects one device.

---rsk

Re: IoT security

[clinton mielke]

That being said, I think if other ISPs took virgins lead then we can start
getting this population of devices reduced. The hard part is getting
overseas ISPs to help with the problem.

Most inbound infectious scanning traffic appears to come from China and
Vietnam. I need to create some better aggregate statistics.

On Feb 10, 2017 5:48 AM, "Marco Slater"  wrote:

>
> > As an ISP, scan your customers netrange, and notify customers with known
> > vulnerable devices. With regards to the current Mirai threat, theres
> only a
> > handful of devices that are the most critical importance. IE, biggest
> > fraction of the infected host pie.
>
> Virgin Media in the UK do this for Mirai-infected or susceptible devices
> already.
>
> What they send out: https://twitter.com/2sec4u/status/825337376692121601
>
> Quite interesting approach. If more consumers were aware of this, they may
> do something about it.. although.. people are lazy. :(

Re: IoT security

[clinton mielke]

It's hilarious they reported on his honeypots :)
Kinda surprised I haven't gotten similar letters. I've gotten infected so
many times.

Amazon certainly noticed my cloud honeypot instances.

On Feb 10, 2017 5:48 AM, "Marco Slater"  wrote:

>
> > As an ISP, scan your customers netrange, and notify customers with known
> > vulnerable devices. With regards to the current Mirai threat, theres
> only a
> > handful of devices that are the most critical importance. IE, biggest
> > fraction of the infected host pie.
>
> Virgin Media in the UK do this for Mirai-infected or susceptible devices
> already.
>
> What they send out: https://twitter.com/2sec4u/status/825337376692121601
>
> Quite interesting approach. If more consumers were aware of this, they may
> do something about it.. although.. people are lazy. :(

Re: IoT security

[Marco Slater]

> As an ISP, scan your customers netrange, and notify customers with known
> vulnerable devices. With regards to the current Mirai threat, theres only a
> handful of devices that are the most critical importance. IE, biggest
> fraction of the infected host pie.

Virgin Media in the UK do this for Mirai-infected or susceptible devices 
already. 

What they send out: https://twitter.com/2sec4u/status/825337376692121601

Quite interesting approach. If more consumers were aware of this, they may do 
something about it.. although.. people are lazy. :( 

RE: IoT security

[Keith Medcalf]

On Tuesday, 7 February, 2017 06:59, Ray Soucy said:

> I think the fundamental problem here is that these devices aren't good
> network citizens in the first place.  The odds of getting them to add
> functionality to support a new protocol are even likely than getting them
> to not have open services externally IMHO.
>
> Couldn't a lot of this be caught by proactive vulnerability scanning and
> working with customers to have an SPI firewall in place, or am I missing
> something?
>
> Historically residential ISP CPE options have been terrible.  If you could
> deliver something closer to user expectations you would likely see much
> more adoption and less desire to rip and replace.  Ideally a cloud-managed
> device so that the config wouldn't need to be rebuilt in the event of a
> hardware swap.

I do not permit "cloud managed" devices on my network unless the "cloud" also 
belongs to me and is located on my network (in other words, a good old 
fashioned server on my network run by me).  No ISP is permitted to put "cloud" 
or even remotely configured (by anyone who is not me) devices on my network.  
Such devices go on THEIR network not MY network.  If they malfunction or get 
hacked, the problem is THEIRS not MINE.

Such a policy ensures that I am entirely and exclusively responsible for the 
good behaviour of the equipment on MY network.  If I were to permit devices 
managed by NOT-ME on MY network, then I would not be responsible.  Therefore 
such filth should stay on NOT-MY network.

So the CPE equipment owned, managed and configured by the ISP is on the ISP 
network, not my network.  The demarc is the ethernet connection between the ISP 
network and MY network.  The ISP cannot configure nor touch anything on MY 
network, nor I on THEIRS.

As for "cloud" crap, anything that even mentions the work "cloud" on the box or 
glossy brochure gets an immediate 10,000,000 point penalty applied to ensure 
that it is forever off the consideration list.

If someone is opposed to this policy and cannot live with it, either a network 
carrier or ISP, product vendor or whatever, I really do not give a rats butt.  
I will simply go do business with someone who has more sense.

Re: IoT security

[bzs]

On February 9, 2017 at 12:04 r...@gsp.org (Rich Kulawiec) wrote:
 > On Wed, Feb 08, 2017 at 08:30:15AM -0800, Damian Menscher wrote:
 > > The devices are trivially compromised (just log in with the default root
 > > password).  So here's a modest proposal: log in as root and brick the
 > > device.
 > 
 > No.  It's never a good idea to respond to abuse with abuse.  Not only
 > is it unethical and probably illegal (IANAL, this is not legal advice)
 > but it won't take more than a day for someone to figure out that this
 > is happening and use some variety of misdirection to cause third parties
 > to target devices that aren't actually part of the problem.

Ok but what if you broke in and fixed their security w/o breaking the
user experience? Would a vendor, presented with a good demo, sign off
on that? If so isn't it just a mandatory patch?

-- 
-Barry Shein

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

Re: IoT security

[clinton mielke]

It probably doesn't account for those situations. In the case of security
products, it's also likely that multiple devices are hosting port 80

But it doesn't matter too much. Having this kind of data helps us
prioritize what devices have the biggest chunk of the infected pie.

On Feb 9, 2017 12:04 PM,  wrote:

> On Wed, 08 Feb 2017 22:19:01 -0800, clinton mielke said:
>
> > Yup! All the mapping Ive done is over port 80. Id have a lot more than I
> > currently have if I was looking at other ports, probably.
>
> Wow.  How does this work if more than one IoPT(*)
> device is in play in the home network, especially from different
> manufacturers?
>
> (*) Internet of Pwned Things.
>

Re: IoT security

[valdis . kletnieks]

On Thu, 09 Feb 2017 14:54:26 -0500, William Herrin said:

> Is there some way an industry association could overcome this? Perhaps
> have some trivial way to assign each model of IoT device some kind of
> integer and have the device report the integer instead of its plain
> text manufacturer and hardware model number? Where the assigned
> integer is intentionally not published by the industry association
> though of course trivially determinable by anyone who owns one of the
> devices.

Or anybody who knows how to use the internet to look for reports of owners who
have issues.  All it takes is one smarter than the average bear user posting
"I've got a MobyWombat 3000 light bulb, and it keeps sending 1193432542 to some
server someplace"

> Wouldn't especially impair building a database of vulnerable
> devices but it would raise the bar for trying to turn the

If it doesn't *heavily* impair building a database of vulnerable devices,
it's not a solution to the problem under discussion.





pgpjlt6i21YAd.pgp
Description: PGP signature

Re: IoT security

[valdis . kletnieks]

On Wed, 08 Feb 2017 22:19:01 -0800, clinton mielke said:

> Yup! All the mapping Ive done is over port 80. Id have a lot more than I
> currently have if I was looking at other ports, probably.

Wow.  How does this work if more than one IoPT(*)
device is in play in the home network, especially from different manufacturers?

(*) Internet of Pwned Things.


pgpaEIWqokf9X.pgp
Description: PGP signature

Re: IoT security

[William Herrin]

On Thu, Feb 9, 2017 at 12:04 PM, Rich Kulawiec  wrote:
> On Wed, Feb 08, 2017 at 08:30:15AM -0800, Damian Menscher wrote:
>> The devices are trivially compromised (just log in with the default root
>> password).  So here's a modest proposal: log in as root and brick the
>> device.
>
> No.  It's never a good idea to respond to abuse with abuse.

Hi Rich,

On that we agree. Vigilantism is a non-starter.

> [regarding the tattler kill switch]
> 2. This will allow ISPs to build a database of which customers have
> which IOT devices.  This is an appalling invasion of privacy.

Is there some way an industry association could overcome this? Perhaps
have some trivial way to assign each model of IoT device some kind of
integer and have the device report the integer instead of its plain
text manufacturer and hardware model number? Where the assigned
integer is intentionally not published by the industry association
though of course trivially determinable by anyone who owns one of the
devices. Wouldn't especially impair building a database of vulnerable
devices but it would raise the bar for trying to turn the
self-reporting in to business intelligence. Particularly if industry
association rules forbid retaining a record of device self-reports on
pain of whatever.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: IoT security

[Rich Kulawiec]

On Wed, Feb 08, 2017 at 08:30:15AM -0800, Damian Menscher wrote:
> The devices are trivially compromised (just log in with the default root
> password).  So here's a modest proposal: log in as root and brick the
> device.

No.  It's never a good idea to respond to abuse with abuse.  Not only
is it unethical and probably illegal (IANAL, this is not legal advice)
but it won't take more than a day for someone to figure out that this
is happening and use some variety of misdirection to cause third parties
to target devices that aren't actually part of the problem.

---rsk

Re: IoT security

[clinton mielke]

Yup! All the mapping Ive done is over port 80. Id have a lot more than I
currently have if I was looking at other ports, probably.

On Wed, Feb 8, 2017 at 10:00 PM,  wrote:

> On Wed, 08 Feb 2017 21:04:07 -0800, clinton mielke said:
>
> > As an ISP, scan your customers netrange, and notify customers with known
> > vulnerable devices. With regards to the current Mirai threat, theres
> only a
> > handful of devices that are the most critical importance. IE, biggest
> > fraction of the infected host pie.
>
> Do enough of these poorly designed devices punch themselves a UPNP hole
> in the CPE firewall and make themselves detectable, to make this a viable
> approach?
>

Re: IoT security

[valdis . kletnieks]

On Wed, 08 Feb 2017 21:04:07 -0800, clinton mielke said:

> As an ISP, scan your customers netrange, and notify customers with known
> vulnerable devices. With regards to the current Mirai threat, theres only a
> handful of devices that are the most critical importance. IE, biggest
> fraction of the infected host pie.

Do enough of these poorly designed devices punch themselves a UPNP hole
in the CPE firewall and make themselves detectable, to make this a viable
approach?


pgpWPLUu32sLl.pgp
Description: PGP signature

Re: IoT security

[clinton mielke]

Having spent the last few months systematically scanning ~700k of these
hosts, Im thinking the following could be considered:

As an ISP, scan your customers netrange, and notify customers with known
vulnerable devices. With regards to the current Mirai threat, theres only a
handful of devices that are the most critical importance. IE, biggest
fraction of the infected host pie.

Maybe someday I'll get around to parsing my database and auto-emailing the
abuse emails of the affected netranges. That was my intention. but
dayjob got in the way.

This breaks down however when you look at the geographic distribution of
infected devices. Most are in Asian countries, so there would need to be
more cooperation among network operators there.

On Wed, Feb 8, 2017 at 6:03 PM, Carl Byington  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Wed, 2017-02-08 at 08:30 -0800, Damian Menscher wrote:
> > So here's a modest proposal: log in as root and brick the
> > device.
>
> I strongly suspect that when the problem gets bad *enough*, someone will
> do exactly that. Yes, it is illegal in many places. Since when has the
> fact that any particular act is illegal been sufficient to deter
> *everyone*?
>
> People still drive while drunk.
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEAREKAAYFAlibzdIACgkQL6j7milTFsH/WgCdEvde+zMvm8lRUyx2ay3EltZT
> 97kAn3Hl2tjPe2eUqiagDXxlE75OO/Xg
> =W+Cq
> -END PGP SIGNATURE-
>
>
>

Re: IoT security

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2017-02-08 at 08:30 -0800, Damian Menscher wrote:
> So here's a modest proposal: log in as root and brick the
> device.

I strongly suspect that when the problem gets bad *enough*, someone will
do exactly that. Yes, it is illegal in many places. Since when has the
fact that any particular act is illegal been sufficient to deter
*everyone*?

People still drive while drunk.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlibzdIACgkQL6j7milTFsH/WgCdEvde+zMvm8lRUyx2ay3EltZT
97kAn3Hl2tjPe2eUqiagDXxlE75OO/Xg
=W+Cq
-END PGP SIGNATURE-

Re: IoT security

[Michael Yoon]

Very clear illustration, thanks for sharing.

It would seem solution would involve non market regulation (EPA for
pollution), or aligning with market forces such as aligning impact to buyer
of security with risk of public access to compromised information (like
videos from IP cameras).

Michael Yoon

On Feb 8, 2017 9:36 AM, "Ed Lopez" <ed.lo...@corsa.com> wrote:

In a recent article (
https://www.schneier.com/blog/archives/2017/02/security_and_th.html), Bruce
Schneier sums up the IoT security mitigation issue quite nicely in this
paragraph:

"The market can't fix this because neither the buyer nor the seller cares.
The owners of the webcams and DVRs used in the denial-of-service attacks
don't care. Their devices were cheap to buy, they still work, and they
don't know any of the victims of the attacks. The sellers of those devices
don't care: They're now selling newer and better models, and the original
buyers only cared about price and features. There is no market solution,
because the insecurity is what economists call an externality: It's an
effect of the purchasing decision that affects other people. Think of it
kind of like invisible pollution."

- Ed Lopez
--
Ed Lopez | Security Architect | Corsa Technology
Email: ed.lo...@corsa.com
Mobile: +1.703.220.0988
www.corsa.com

sent from my iPad ... I apologize for any auto-correct errors

Re: IoT security

[William Herrin]

On Wed, Feb 8, 2017 at 11:30 AM, Damian Menscher  wrote:
> On Wed, Feb 8, 2017 at 7:22 AM, William Herrin  wrote:
>> On Wed, Feb 8, 2017 at 10:12 AM, Rich Kulawiec  wrote:
>> > We need to make it their problem.
>>
>> How?
>
>
> The devices are trivially compromised (just log in with the default root
> password).  So here's a modest proposal: log in as root and brick the
> device.

Okay, so within the confines of lawful activity, how?

'Cause I'm guessing that coordinated criminal activity is going to be
a community non-starter. At least when it's this unambiguous. ;)

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: IoT security

[Damian Menscher]

On Wed, Feb 8, 2017 at 7:22 AM, William Herrin  wrote:

> On Wed, Feb 8, 2017 at 10:12 AM, Rich Kulawiec  wrote:
> > In a better world, vendors would be far more
> > responsible, professional, and ethical.  But we don't live in that
> > world.  We live in one where they will happily dump toxic waste on
> > the Internet as fast as they can shovel it -- as long as it's not
> > their problem.
> >
> > We need to make it their problem.
>
> How?


The devices are trivially compromised (just log in with the default root
password).  So here's a modest proposal: log in as root and brick the
device.

This will encourage the consumer to seek a solution.  When 100k consumers
all discover their devices broke at the same time, they'll file a
class-action lawsuit against the manufacturer, or at least never buy from
them again.  Market forces then solve the problem naturally, both for that
manufacturer and for others who don't want the same fate.

I realize there are drawbacks (including legal implications) to this method
(which is why I'm posting from a personal, not work, account).  But I
challenge anyone to propose another solution that will work as well.  Most
other proposals I've heard depend on individual ISPs to take action, or
governments to regulate devices and hope that foreign manufacturers care,
or 

Damian

Re: IoT security

[William Herrin]

On Wed, Feb 8, 2017 at 10:12 AM, Rich Kulawiec  wrote:
> In a better world, vendors would be far more
> responsible, professional, and ethical.  But we don't live in that
> world.  We live in one where they will happily dump toxic waste on
> the Internet as fast as they can shovel it -- as long as it's not
> their problem.
>
> We need to make it their problem.

How?

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: IoT security

[Rich Kulawiec]

On Tue, Feb 07, 2017 at 10:01:29PM +, Ed Lopez quoted Bruce Schneier:
> There is no market solution, because the insecurity is what economists
> call an externality: It's an effect of the purchasing decision that
> affects other people.

This is precisely correct.  The only way to change this is to make
*our* problem *their* problem.   Let me remind everyone of one of
very best things ever said on this mailing list:

If you give people the means to hurt you, and they do it, and
you take no action except to continue giving them the means to
hurt you, and they take no action except to keep hurting you,
then one of the ways you can describe the situation is "it isn't
scaling well".
--- Paul Vixie

This movie has been playing here 24x7 for the last few decades with
the spam problem (among others): most operations which emit it will
take absolutely no action of any kind until/unless it stops being *our*
problem and starts being *their* problem.  Having observed and studied
that particular issue since it existed to be observed and studied,
I've concluded that the only thing that has ever worked effectively is
blacklisting: that is, the revocation of access/service privileges.

And that's because it makes *our* problem *their* problem.  Everything
else is just avoidance and evasion.  It's feel-good stuff that might,
on a good day, deal with the symptoms of the problem -- but that's
all it is.  And dealing with symptoms isn't bad, per se: it makes the
patient feel better.  But it should never be accepted as a substitute
for dealing with the underlying problem.

Now we can either spend another couple more decades trying to tapdance
around this or we can learn the lesson that's been taught to us thousands
of times over many years and just cut to the chase.

So how about if we save some time?

If IOT-driven attacks and abuse are coming from X, then that needs to be
made X's problem.  Because right now X has no idea that this is happening,
and even if told, will take no action because it's not X's problem.

So make it X's problem.

And I don't just mean "X", the person who bought some badly-designed
poorly-engineered rushed-to-market never-tested piece of shiny
new cruft that was pre-compromised at the factory and hijacked by
attackers the moment it went live: I mean "X" the vendor who pulled that
stunt in order to make a quick buck and then dumped it on us.

We, for many values of "we" are not obligated to provide services to that
vendor.  (I do recognize that some are, due to contractual agreements.)
We should cut them off until/unless they recall all those devices,
get them removed from service, and solve what is now *their* problem
to *our* satisfaction.  I strongly suspect that it'll only take a
few pointed lessons in order for the message that this conduct is
unacceptable to be communicated in a language they understand.

I don't like this.   In a better world, vendors would be far more
responsible, professional, and ethical.  But we don't live in that
world.  We live in one where they will happily dump toxic waste on
the Internet as fast as they can shovel it -- as long as it's not
their problem.

We need to make it their problem.

---rsk

Re: IoT security

[Ed Lopez]

In a recent article (
https://www.schneier.com/blog/archives/2017/02/security_and_th.html), Bruce
Schneier sums up the IoT security mitigation issue quite nicely in this
paragraph:

"The market can't fix this because neither the buyer nor the seller cares.
The owners of the webcams and DVRs used in the denial-of-service attacks
don't care. Their devices were cheap to buy, they still work, and they
don't know any of the victims of the attacks. The sellers of those devices
don't care: They're now selling newer and better models, and the original
buyers only cared about price and features. There is no market solution,
because the insecurity is what economists call an externality: It's an
effect of the purchasing decision that affects other people. Think of it
kind of like invisible pollution."

- Ed Lopez
-- 
Ed Lopez | Security Architect | Corsa Technology
Email: ed.lo...@corsa.com
Mobile: +1.703.220.0988
www.corsa.com

sent from my iPad ... I apologize for any auto-correct errors

Re: IoT security

[Michael Thomas]

On 02/07/2017 02:05 PM, William Herrin wrote:

On Tue, Feb 7, 2017 at 3:27 PM, Randy Bush  wrote:

On Tue, Feb 07, 2017 at 06:56:40AM -0500, William Herrin wrote:

Immaterial. The point is to catch vulnerable devices before they're
hacked.

you have a 30 second window there, maybe five minutes if you are lucky.

Hi Randy,

I'd expect a tattler kill switch to take maybe a tenth of that from
the anycast notification when the nic comes up to the ISPs response
that it is known to be vulnerable and should disconnect.


assuming that it wasn't conveniently factory installed, cf usb sticks.

Mike

Re: IoT security

[William Herrin]

On Tue, Feb 7, 2017 at 3:27 PM, Randy Bush  wrote:
>> On Tue, Feb 07, 2017 at 06:56:40AM -0500, William Herrin wrote:
>>> Immaterial. The point is to catch vulnerable devices before they're
>>> hacked.
>
> you have a 30 second window there, maybe five minutes if you are lucky.

Hi Randy,

I'd expect a tattler kill switch to take maybe a tenth of that from
the anycast notification when the nic comes up to the ISPs response
that it is known to be vulnerable and should disconnect.

Regards,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: IoT security

[Richard]

On 02/07/2017 02:27 PM, Randy Bush wrote:

On Tue, Feb 07, 2017 at 06:56:40AM -0500, William Herrin wrote:

Immaterial. The point is to catch vulnerable devices before they're
hacked.

you have a 30 second window there, maybe five minutes if you are lucky.


Looking at my logs from the past couple of months I think you are 
being generous by giving it thirty seconds.


Richard

Re: IoT security

[Randy Bush]

> On Tue, Feb 07, 2017 at 06:56:40AM -0500, William Herrin wrote:
>> Immaterial. The point is to catch vulnerable devices before they're
>> hacked.

you have a 30 second window there, maybe five minutes if you are lucky.

Re: IoT security

[William Herrin]

 On Tue, Feb 7, 2017 at 8:13 AM, Tom Beecher  wrote:
>> " any IoT device must _by default_ emit a UDP packet to an
>> anycast address reserved for the purpose which identifies the device
>> model and software build. "
>
> Any semi-competent attacker will simply alter the way the network stack on
> the device works to make it _not_ look like an IoT device for the purposes
> of this check, rendering it moot.

Hi Tom,

Again, the idea is to remediate devices with insecure software
-before- they're breached. Obviously once breached the attacker can
present any profile he wants save that it has to emit packets
consistent with his desired attack.


>> "If the IoT
>> device receives the fail message, it must try to report the problem to
>> its owner and remove its default route so that it can only communicate
>> on the local lan."
>
> If the vendor isn't thinking about security already, as evidenced by the
> current issues with these devices, how are they to be convinced to add code
> to make said device do something exceptionally specific?

Because it's consistent with the carelessly throw-together free open
source software process the trash vendors currently follow and when
the industry promotes its "look for the safe network logo" program
they won't want to have problems with their retailers over a trivially
added bit of free software.


> I believe it's important to remember that network endpoints will never be
> sure fully secure. They will never be fully in compliance with $standard .
> They will never always follow best practices.

You can say that again.


On Tue, Feb 7, 2017 at 8:58 AM, Ray Soucy  wrote:
> I think the fundamental problem here is that these devices aren't good
> network citizens in the first place.  The odds of getting them to add
> functionality to support a new protocol are even likely than getting them to
> not have open services externally IMHO.

Hi Ray,

I can speak to that with authority, but again my working theory is
that adding the kill switch is consistent with the carelessly
throw-together free open source software process the trash vendors
currently follow.

> Couldn't a lot of this be caught by proactive vulnerability scanning and
> working with customers to have an SPI firewall in place, or am I missing
> something?

One of us is missing something. The customer isn't scanning his
network (if he was, we wouldn't have the problem), and from the
outside of an SPI firewall how is the ISP supposed to do that?

> Historically residential ISP CPE options have been terrible.  If you could
> deliver something closer to user expectations you would likely see much more
> adoption and less desire to rip and replace.

The customer buys cool stuff he finds at CostCo. Seeking different
behavior seems unlikely to succeed to me.


On Tue, Feb 7, 2017 at 9:50 AM, Rich Kulawiec  wrote:
> On Tue, Feb 07, 2017 at 06:56:40AM -0500, William Herrin wrote:
>> Immaterial. The point is to catch vulnerable devices before they're
>> hacked.
>
> This won't work on the majority of devices: they're pre-compromised
> at the factory.

Well that's a silly misdirection Rich. Manufacturer's misbehavior is a
whole different class of problem than equipment breached by a third
party after deployment. Unless you claim a convenient way to merge
solutions, take it to your own thread.

>> If the ISP can't keep control of its security head-end then sure, at
>> least until the ISP regains control.
>
> I think you're severely underestimating the threat.

I'm not estimating the threat at all, just stating the precondition
for a kill switch to be a denial of service vector.

>> Regardless, I encourage you to suggest alternate solutions which don't
>> run afoul of the problems you mention. The problem isn't going away.
>
> I'm aware of that.  But this is not the way.  I've seen this movie
> WAY too many times:
>
> 1. We must do something
> 2. This is something.
> 3. Let's do this.
> 4. We have done something.
> 5. Congrats and awards all around, everybody.

And I've heard this song before too: If you choose not to decide you
still have made a choice.

Neither one of us will like the government solution, so if you have an
idea that hasn't already demonstrated its failure, let's hear it. When
there's no consensus on an optimal solution, we move forward by trying
ideas until something sticks. That's progress, including the attempts
which fail.

Regards,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: IoT security

[Rich Kulawiec]

On Tue, Feb 07, 2017 at 06:56:40AM -0500, William Herrin wrote:
> Immaterial. The point is to catch vulnerable devices before they're
> hacked. That can't always happen (even with customers and vendors
> engaged in best practice patching), but it need only happen often
> enough to limit the size of the resulting botnets.

This won't work on the majority of devices: they're pre-compromised
at the factory.  By the time you see the first packet from them,
IF you see the first packet from them, it will already be too late.

And a lot of them are deliberately designed and built to conduct attacks, e.g.:

Vizio tracked and sold your TV viewing habits without consent

https://www.engadget.com/2017/02/06/vizio-smart-tv-viewing-history-settlement-ftc/

What a nice favor to do for attackers: Vizio spent its time and money
putting this in place for them, so they didn't have to.

This is going to get worse -- MUCH worse -- as the few flimsy consumer
protections in place are systematically dismantled and the agencies
charged with enforcing them defunded.


> As I envision it, it's an opt-out system. 

No.  In fact, HELL NO.  Too many ISPs have already put absolutely clinching
proof on the table that they will silently opt-in customers to all manner
of tracking, surveillance, and security/privacy attacks.  (I'm looking at
you, Verizon, at the moment.)  Opt-out is inherently abusive.


> Possible, though an ISP which retains the data opens itself to a class
> action lawsuit if it can't keep control of it.

First, that's a meaningless remedy.   Even if someone has the financial
resources to sue an ISP, they're going to wind up quietly settling years
later, the lawyers will get rich(er), the settlement will be sealed,
and they'll just keep right on doing it.

See the Vizio case above.  Did anybody go to prison?  No.  Did it
cost them anything?  Not really: the fine is just chump change.
Will Vizio do it again?  OF COURSE they will, they'd be crazy not to.
All they have to do is wait a little while, rename it, shuffle things
around a bit, and they'll be fine.

Second, the most likely outcome here is that the ISP will use this data
to spy on its users and market to them.  The next outcome is that someone
inside the ISP will figure out that this is a potential revenue source
and start selling it, under the argument that consumers didn't opt-out,
therefore they WANT their private data sold.

So let's not pretend that the delusional fiction of a successful class-action
lawsuit is a deterrent.  It's just a belly laugh for the executives and a
windfall for the attorneys.


> If the ISP can't keep control of its security head-end then sure, at
> least until the ISP regains control.

I think you're severely underestimating the threat.  And note that even
though you're just thinking about the problem from the perspective of ISPs,
they're not the only ones affected.  There are a lot of attack vectors
available to anyone who's already on the inside.


> Regardless, I encourage you to suggest alternate solutions which don't
> run afoul of the problems you mention. The problem isn't going away.

I'm aware of that.  But this is not the way.  I've seen this movie
WAY too many times:

1. We must do something
2. This is something.
3. Let's do this.
4. We have done something.
5. Congrats and awards all around, everybody.

---rsk

Re: IoT security

[Ray Soucy]

I think the fundamental problem here is that these devices aren't good
network citizens in the first place.  The odds of getting them to add
functionality to support a new protocol are even likely than getting them
to not have open services externally IMHO.

Couldn't a lot of this be caught by proactive vulnerability scanning and
working with customers to have an SPI firewall in place, or am I missing
something?

Historically residential ISP CPE options have been terrible.  If you could
deliver something closer to user expectations you would likely see much
more adoption and less desire to rip and replace.  Ideally a cloud-managed
device so that the config wouldn't need to be rebuilt in the event of a
hardware swap.

On Mon, Feb 6, 2017 at 5:31 PM, William Herrin  wrote:

> This afternoon's panel about IoT's lack of security got me thinking...
>
>
> On the issue of ISPs unable to act on insecure devices because they
> can't detect the devices until they're compromised and then only have
> the largest hammer (full account ban) to act...
>
> What about some kind of requirement or convention that upon boot and
> successful attachment to the network (and maybe once a month
> thereafter), any IoT device must _by default_ emit a UDP packet to an
> anycast address reserved for the purpose which identifies the device
> model and software build. The ISP can capture traffic to that anycast
> address, compare the data against a list of devices known to be
> defective and, if desired, respond with a fail message. If the IoT
> device receives the fail message, it must try to report the problem to
> its owner and remove its default route so that it can only communicate
> on the local lan.  The user can override the fail and if desired
> configure the device not to emit the init messages at all. But by
> default the ISP is allowed to disable the device by responding to the
> init message.
>
> Would have to cryptographically sign the fail message and let the
> device query the signer's reputation or something like that to avoid
> the obvious security issue. Obvious privacy issues to consider.
> Anyway, throwing it out there as a potential discussion starting
> point.
>
>
>
> The presentation on bandwidth policers...
>
> Seems like we could use some form of ICMP message similar to
> destination unreachable that provides some kind of arbitrary string
> plus the initial part of the dropped packet. One of the potential
> strings would be an explicit notice to the sender that packets were
> dropped and the bandwidth available.
>
> Yes, we already have ECN, but ECN tells the receiver about congestion,
> not the sender. More to the point, ECN can only be flagged on packets
> that are passed, not the packets that are dropped, so the policer
> would have to be complicated enough to note on the next packet that
> the prior packet was dropped. Also, ECN only advises that you're close
> to the limit not any information about the policer's target limit.
>
> This thought is not fully baked. Throwing it out for conversation purposes.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: 
>



-- 
Ray Patrick Soucy
Senior Cyber Security Engineer
Networkmaine, University of Maine System US:IT

207-581-3526

Re: IoT security

[Tom Beecher]

" any IoT device must _by default_ emit a UDP packet to an
anycast address reserved for the purpose which identifies the device
model and software build. "

Any semi-competent attacker will simply alter the way the network stack on
the device works to make it _not_ look like an IoT device for the purposes
of this check, rendering it moot.

"If the IoT
device receives the fail message, it must try to report the problem to
its owner and remove its default route so that it can only communicate
on the local lan."

If the vendor isn't thinking about security already, as evidenced by the
current issues with these devices, how are they to be convinced to add code
to make said device do something exceptionally specific?

I believe it's important to remember that network endpoints will never be
sure fully secure. They will never be fully in compliance with $standard .
They will never always follow best practices. This is not to say we should
do nothing (obligatory 'Perfect is the enemy of good' comment) but it's
something to think about when discussing possibilities.


On Tue, Feb 7, 2017 at 6:56 AM, William Herrin  wrote:

> On Tue, Feb 7, 2017 at 5:26 AM, Rich Kulawiec  wrote:
> > On Mon, Feb 06, 2017 at 05:31:10PM -0500, William Herrin wrote:
> >> What about some kind of requirement or convention that upon boot and
> >> successful attachment to the network (and maybe once a month
> >> thereafter), any IoT device must _by default_ emit a UDP packet to an
> >> anycast address reserved for the purpose which identifies the device
> >> model and software build.
> >
> > I can think of at least four reasons why this idea must be killed
> > immediately and permanently.  This is off the top of my head *before*
> > coffee, so I strongly suspect there are more.
> >
> > 1. An attacker who takes control of an IoT device can change the contents
> > of that packet, cause it to be emitted, suppress it from being emitted,
> etc.
>
> Hi Rich,
>
> Immaterial. The point is to catch vulnerable devices before they're
> hacked. That can't always happen (even with customers and vendors
> engaged in best practice patching), but it need only happen often
> enough to limit the size of the resulting botnets.
>
>
> > 2. This will allow ISPs to build a database of which customers have
> > which IOT devices.  This is an appalling invasion of privacy.
>
> As I envision it, it's an opt-out system. Anyone who cares and knows
> enough to secure their network can turn it off for their devices. No
> permission or action from the ISP required to turn it off. In fact,
> you need only block packets to the well-known anycast address to
> disable it for all devices on your network.
>
>
> > 3. This will allow ISPs to build a database of which customers have
> > which IOT devices.  This will create one-stop shopping for attackers.
>
> Possible, though an ISP which retains the data opens itself to a class
> action lawsuit if it can't keep control of it.
>
> Nevertheless, let's not oversell the privacy implications: most of the
> IoT devices we're talking about phone home anyway. They're tied to
> this or that cloud service rather than accepting local access. An ISP
> can't learn as much information by watching who they phone home to
> (deep packet inspection), but they can learn an awful lot.
>
>
> > 4. It won't take long for this to be used as a DDoS vector.
>
> If the ISP can't keep control of its security head-end then sure, at
> least until the ISP regains control.
>
>
> Regardless, I encourage you to suggest alternate solutions which don't
> run afoul of the problems you mention. The problem isn't going away.
> Entirely cutting off customers doesn't work because there are too many
> impacted customers and ISPs don't have the resources or the will to do
> so. Demanding that trash vendors not produce trash won't get it done
> either. When you eliminate responsible device hardening, cutting
> customer connections and the kill switch, what's left?
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: 
>

Re: IoT security

[William Herrin]

On Tue, Feb 7, 2017 at 5:26 AM, Rich Kulawiec  wrote:
> On Mon, Feb 06, 2017 at 05:31:10PM -0500, William Herrin wrote:
>> What about some kind of requirement or convention that upon boot and
>> successful attachment to the network (and maybe once a month
>> thereafter), any IoT device must _by default_ emit a UDP packet to an
>> anycast address reserved for the purpose which identifies the device
>> model and software build.
>
> I can think of at least four reasons why this idea must be killed
> immediately and permanently.  This is off the top of my head *before*
> coffee, so I strongly suspect there are more.
>
> 1. An attacker who takes control of an IoT device can change the contents
> of that packet, cause it to be emitted, suppress it from being emitted, etc.

Hi Rich,

Immaterial. The point is to catch vulnerable devices before they're
hacked. That can't always happen (even with customers and vendors
engaged in best practice patching), but it need only happen often
enough to limit the size of the resulting botnets.


> 2. This will allow ISPs to build a database of which customers have
> which IOT devices.  This is an appalling invasion of privacy.

As I envision it, it's an opt-out system. Anyone who cares and knows
enough to secure their network can turn it off for their devices. No
permission or action from the ISP required to turn it off. In fact,
you need only block packets to the well-known anycast address to
disable it for all devices on your network.


> 3. This will allow ISPs to build a database of which customers have
> which IOT devices.  This will create one-stop shopping for attackers.

Possible, though an ISP which retains the data opens itself to a class
action lawsuit if it can't keep control of it.

Nevertheless, let's not oversell the privacy implications: most of the
IoT devices we're talking about phone home anyway. They're tied to
this or that cloud service rather than accepting local access. An ISP
can't learn as much information by watching who they phone home to
(deep packet inspection), but they can learn an awful lot.


> 4. It won't take long for this to be used as a DDoS vector.

If the ISP can't keep control of its security head-end then sure, at
least until the ISP regains control.


Regardless, I encourage you to suggest alternate solutions which don't
run afoul of the problems you mention. The problem isn't going away.
Entirely cutting off customers doesn't work because there are too many
impacted customers and ISPs don't have the resources or the will to do
so. Demanding that trash vendors not produce trash won't get it done
either. When you eliminate responsible device hardening, cutting
customer connections and the kill switch, what's left?

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: IoT security

[Rich Kulawiec]

On Mon, Feb 06, 2017 at 05:31:10PM -0500, William Herrin wrote:
> What about some kind of requirement or convention that upon boot and
> successful attachment to the network (and maybe once a month
> thereafter), any IoT device must _by default_ emit a UDP packet to an
> anycast address reserved for the purpose which identifies the device
> model and software build.

I can think of at least four reasons why this idea must be killed
immediately and permanently.  This is off the top of my head *before*
coffee, so I strongly suspect there are more.

1. An attacker who takes control of an IoT device can change the contents
of that packet, cause it to be emitted, suppress it from being emitted, etc.

2. This will allow ISPs to build a database of which customers have
which IOT devices.  This is an appalling invasion of privacy.

3. This will allow ISPs to build a database of which customers have
which IOT devices.  This will create one-stop shopping for attackers.

4. It won't take long for this to be used as a DDoS vector.

---rsk

Re: IoT security

[William Herrin]

On Mon, Feb 6, 2017 at 7:14 PM, joel jaeggli <joe...@bogus.com> wrote:
> On 2/6/17 2:31 PM, William Herrin wrote:
>> This afternoon's panel about IoT's lack of security got me thinking...

Hi Joel,

For clarification I was referring to this:

http://nanog.org/meetings/abstract?id=3051

The long and short of the panel was: as an industry (device vendors
and service providers both) it behooves us to voluntarily get on top
of the IoT security problem before some catastrophic event requires
the government to dictate the precise manner in which we will get on
top of the problem.


>> What about some kind of requirement or convention that upon boot and
>> successful attachment to the network (and maybe once a month
>> thereafter), any IoT device must _by default_ emit a UDP packet to an
>> anycast address reserved for the purpose which identifies the device
>> model and software build.

> self identification is privacy hostile and tantamount to indicating a
> willingness to be subverted (this is why we disable lldp on external
> interfaces) even if it would otherwise be rather useful. the use of
> modified eui64 addresses as part of v6 address selection hash basically
> gone away for similar reasons.

I'm not sure how we get on top of the problem without offering an
effective network kill switch to the nearest security-competent
person. I think I'd prefer a user-disableable kill-switch used on a
single piece of equipment to a kill switch for my entire Internet
connection.

The IPv6 SLAAC address suffers a rather worse case of the privacy
problem since it allows the entire Internet to track your hardware,
not just your local ISP.

In any case, I thought "how do we fix this long term" could stand
discussion on the list. Because yes, the IoT device vendors mostly
produce trash and if (to borrow a phrase) it saves them a buck at
retail they will keep producing trash. But we're the ones letting that
trash cause nation-scale problems and when the regulatory hammer
crashes down it's gonna hit us all.


On Mon, Feb 6, 2017 at 7:10 PM, Michael Thomas <m...@mtcc.com> wrote:
> Uh, yuck at many levels. Do you leak your cisco ios versions to the
> internet?

Hi Michael,

I'm not aware of any Cisco IOS devices that qualify as IoT. Some
lighter weight Cisco gear, yes. And no, I do not want to broadcast my
information. But I'm professional who customizes my gear when I plug
it in. I don't run with the defaults.


> Do you really want the responsibility for the remote kill switch for IoT S
> gear?

I already have the kill switch for the customer's entire S transit
link. I'd prefer to also have a smaller hammer whose use won't net me
a furious call from Sales.


> And of course, you're depending on rfc 3514, right?

Nope. I'll decide what's evil and what's not (more likely I'll pay a
service to provide me a regularly updated database) and I depend only
on a high enough percentage of the devices offering themselves up for
that decision that it becomes impractical to construct another Mirai.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: <http://www.dirtside.com/>

Re: IoT security

[joel jaeggli]

On 2/6/17 2:31 PM, William Herrin wrote:
> This afternoon's panel about IoT's lack of security got me thinking...
>
>
> On the issue of ISPs unable to act on insecure devices because they
> can't detect the devices until they're compromised and then only have
> the largest hammer (full account ban) to act...
>
> What about some kind of requirement or convention that upon boot and
> successful attachment to the network (and maybe once a month
> thereafter), any IoT device must _by default_ emit a UDP packet to an
> anycast address reserved for the purpose which identifies the device
> model and software build. The ISP can capture traffic to that anycast
> address, compare the data against a list of devices known to be
> defective and, if desired, respond with a fail message. If the IoT
> device receives the fail message, it must try to report the problem to
> its owner and remove its default route so that it can only communicate
> on the local lan.  The user can override the fail and if desired
> configure the device not to emit the init messages at all. But by
> default the ISP is allowed to disable the device by responding to the
> init message.
self identification is privacy hostile and tantamount to indicating a
willingness to be subverted (this is why we disable lldp on external
interfaces) even if it would otherwise be rather useful. the use of
modified eui64 addresses as part of v6 address selection hash basically
gone away for similar reasons.
> Would have to cryptographically sign the fail message and let the
> device query the signer's reputation or something like that to avoid
> the obvious security issue. Obvious privacy issues to consider.
> Anyway, throwing it out there as a potential discussion starting
> point.
>




signature.asc
Description: OpenPGP digital signature

Re: IoT security

[Michael Thomas]

On 2/6/17 2:31 PM, William Herrin wrote:

This afternoon's panel about IoT's lack of security got me thinking...


On the issue of ISPs unable to act on insecure devices because they
can't detect the devices until they're compromised and then only have
the largest hammer (full account ban) to act...

What about some kind of requirement or convention that upon boot and
successful attachment to the network (and maybe once a month
thereafter), any IoT device must _by default_ emit a UDP packet to an
anycast address reserved for the purpose which identifies the device
model and software build. The ISP can capture traffic to that anycast
address, compare the data against a list of devices known to be
defective and, if desired, respond with a fail message. If the IoT
device receives the fail message, it must try to report the problem to
its owner and remove its default route so that it can only communicate
on the local lan.  The user can override the fail and if desired
configure the device not to emit the init messages at all. But by
default the ISP is allowed to disable the device by responding to the
init message.


Uh, yuck at many levels. Do you leak your cisco ios versions to the 
internet?


Do you really want the responsibility for the remote kill switch for IoT 
S gear?


And of course, you're depending on rfc 3514, right?

Mike

IoT security

[William Herrin]

This afternoon's panel about IoT's lack of security got me thinking...


On the issue of ISPs unable to act on insecure devices because they
can't detect the devices until they're compromised and then only have
the largest hammer (full account ban) to act...

What about some kind of requirement or convention that upon boot and
successful attachment to the network (and maybe once a month
thereafter), any IoT device must _by default_ emit a UDP packet to an
anycast address reserved for the purpose which identifies the device
model and software build. The ISP can capture traffic to that anycast
address, compare the data against a list of devices known to be
defective and, if desired, respond with a fail message. If the IoT
device receives the fail message, it must try to report the problem to
its owner and remove its default route so that it can only communicate
on the local lan.  The user can override the fail and if desired
configure the device not to emit the init messages at all. But by
default the ISP is allowed to disable the device by responding to the
init message.

Would have to cryptographically sign the fail message and let the
device query the signer's reputation or something like that to avoid
the obvious security issue. Obvious privacy issues to consider.
Anyway, throwing it out there as a potential discussion starting
point.



The presentation on bandwidth policers...

Seems like we could use some form of ICMP message similar to
destination unreachable that provides some kind of arbitrary string
plus the initial part of the dropped packet. One of the potential
strings would be an explicit notice to the sender that packets were
dropped and the bandwidth available.

Yes, we already have ECN, but ECN tells the receiver about congestion,
not the sender. More to the point, ECN can only be flagged on packets
that are passed, not the packets that are dropped, so the policer
would have to be complicated enough to note on the next packet that
the prior packet was dropped. Also, ECN only advises that you're close
to the limit not any information about the policer's target limit.

This thought is not fully baked. Throwing it out for conversation purposes.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

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*