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

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

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

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

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

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

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

> 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

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

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/

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

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

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

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. . .

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

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

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

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

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

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

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

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

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

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

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

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

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

"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 discuss

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

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

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

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

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

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

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:

Re: IoT security

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

Re: IoT security

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

Re: IoT security

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

Re: IoT security

> 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

RE: IoT security

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

Re: IoT security

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 > >

Re: IoT security

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

Re: IoT security

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

Re: IoT security

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

Re: IoT security

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. >

Re: IoT security

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

Re: IoT security

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

Re: IoT security

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

Re: IoT security

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

Re: IoT security

-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

Re: IoT security

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

Re: IoT security

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

Re: IoT security

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

Re: IoT security

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

Re: IoT security

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

Re: IoT security

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

Re: IoT security

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

Re: IoT security

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

Re: IoT security

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

Re: IoT security

> 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

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

Re: IoT security

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

Re: IoT security

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

Re: IoT security

" 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

Re: IoT security

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

Re: IoT security

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

Re: IoT security

=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.

Re: IoT security

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

Re: IoT security

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

IoT security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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 >

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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.

Re: Spitballing IoT Security

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

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

"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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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 >>

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

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

Re: Spitballing IoT Security

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),

Re: Spitballing IoT Security

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

RE: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

RE: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

RE: Spitballing IoT Security

> > 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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security -- Dancing around a solution

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

RE: Spitballing IoT Security

ted 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

> 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

RE: Spitballing IoT Security

(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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

Re: Spitballing IoT Security

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

  1   2   >