Spitballing IoT Security

Mark Andrews marka at isc.org
Tue Nov 8 03:51:48 UTC 2016

In message <d8944d0b-c45a-48f7-013f-685317e07bc8 at userid.org>, Pierre Lamy write
> On 30/10/2016 12:43 AM, Eric S. Raymond wrote:
> > Ronald F. Guilmette <rfg at tristatelogic.com>:
> >>                         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 Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

More information about the NANOG mailing list