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