
IoT Security Anti-Patterns - IcyApril
https://blog.cloudflare.com/iot-security-anti-patterns/
======
ctz
> With the device in their possession they can extract software from the
> embedded system chip on the device to obtain the software running on it. By
> reverse engineering this software they can learn secrets in the memory of
> the onboard microcontroller.

Hoping to keep secrets from a physical attacker on a general purpose
microcontroller is an excellent example of an IoT security anti-pattern. It's
a shame the author missed the wider point.

~~~
gol706
Can you really protect the device software if the hardware encryption element
is separate from the microcontroller? Wouldn't it be trivial to sniff the
decrypted cypher text of the software with a logic analyzer on the pin between
the microcontroller and encryption ASIC even if you can't get the actual key
out of it?

------
xg15
> _Anti-pattern: HTTP Pub /Sub_

So what is the alternative? He is not seriously advocating polling, is he?

~~~
shabble
My guess is that no, it's not about pub/sub specifically, but rather that
"you" can address & subscribe arbitrary hosts anywhere on the internet via a
naive implementation.

Segregating your 'dumb' controller/sensor nodes and restricting their ability
to talk elsewhere via routing, firewalling or proxies would reduce the risk of
a single crappy device leaking onto the internet. At the cost of some
centralisation of control in your gateway/router/whatever, of course. And you
still need some form of crypto on your local network to protect against
local/physical attackers.

Is it a coincidence that this post comes a few days after CF announces a
"private network for IoT"[1]? My wirelessly-enabled Crystal Ball says no. I
wonder if it's because the IoT is itself a big enough pie with current
attention on (lack of) security, or if it's more to protect their main
business from Mirai N+1/DDoSoT or whatever.

[1] [https://blog.cloudflare.com/orbit/](https://blog.cloudflare.com/orbit/)

------
MichailP
Is security engineering at the level of black box art, or is it at the level
of sound engineering principles that once followed will result in secure
system? Everybody is talking about security, but are there some rules to
follow or is it a jungle of black hat hackers trying to ruin your IoT devices?

~~~
chatmasta
Since there is no security panacea -- _all_ systems are vulnerable given
enough attention and focused skill -- it seems more of an art than a science.
Like all software engineering, proper security requires careful balancing of
tradeoffs and prioritization of security mitigations.

Just like you design software with the end user in mind, you should design
security systems with the attacker in mind. Just like you prioritize features
for by your expected user personas, you should prioritize security measures by
your expected attacker personas. And just like you always want to cover the
"basics" of UX, you always want to cover the "basics" of security.

First you should take care of the "low hanging fruit," meaning you should
implement industry best practices at all levels of the stack. Hopefully this
is sufficient to mostly mitigate any threats of getting caught in widely
targeted attacks, like mass scans for Wordpress vulnerabilities.

Unfortunately, implementing security best practices is only the beginning of
defending against motivated attackers focused specifically on you as a target.

Once you've taken care of the easy wins, you have to balance the tradeoffs of
engineering effort and complexity required to make certain mitigations. In
practice, this means that what your security system will look like largely
depends on the question: What is your threat model?

If you are an IoT vendor, your threat model is becoming a node in a botnet.
That means you need to defend against a focused attacker reverse engineering
your product to find a vulnerability that can be used to root the device
remotely. Unfortunately this is basically impossible to defend against, but
you can make their job much more difficult with binary obfuscation, symbol
stripping, aslr, etc. Your best hope at that point is the attacker gets
frustrated and decides to target some other product.

If you're a search engine ( _cough cough_ ) your threat model may be people
scraping your search results (as hypocritical as that is...) In that case your
first priority might be catching bots and serving up captchas.

Point is, your "security engineering" largely depends on your domain and
threat model, just like "traditional" software engineering depends on domain
and user base.

(That said, IANASecurityProfessional ;) )

~~~
MichailP
Thanks for the lovely (and elaborate) write-up!

------
beached_whale
There is a cost to implementing SSL on many of these chips and it often
results in either paying more or not having features. Even the esp8266 had
issues with size. I wonder if using an proper HMAC without data encryption
would be sufficient for non-sensitive items like dumb data loggers or even
control.

~~~
orthecreedence
With IoT, one generally has control of the devices, so one can distribute
their own keys without having to "trust" the authorities. In that case,
something like libsodium could handle the communication between devices.

~~~
beached_whale
The library doesn't always fit, let alone larger keychains. This gets you
encryption but means you have less room for the software that pays. This is
the balance. Also, many of the IoT devices have a few hundred bytes of ram and
a few kilo bytes of flash, so public key may be out of the question. It is
changing, there are devices like the esp32 that can fit a lot more along with
providing wifi/bluetooth

------
mkesper
I don't get why anyone would want a device connected to the internet at all,
in the first place.

~~~
rosalinekarr
I don't think rejecting a technology entirely is the best way to avoid abuse.
I get that some of these devices are a little silly, i.e. WiFi-connected
toasters, but a lot of IoT devices have great potential for making the world a
better place. For example, the FitBit and other health trackers can do wonders
for helping people get healthier, and devices like Bluetooth-enabled glucose
monitors can even save lives.

This idea that we shouldn't even consider connecting tools to the internet
because the internet is scary and dangerous feels like a knee-jerk reaction to
me. I believe there is a right way to build these tools where the risk added
is minimal to non-existent. Refusing to pursue this tech at all because some
people do it wrong just feels like ludditism to me.

Imagine what would have happened if people abandoned computer technology after
the first few viruses were discovered.

~~~
shabble
I think it's hard to dispute that networked sensors/controllers can have
tangible benefits.

My issue with the current trend is that 'IoT'/Internet-enabled is a way to
both sell a product, and then effectively rent access to it via the 'cloud'
interface. If you stop paying, your device is (mostly) useless. If they stop
supporting it, your device is (mostly) useless. The actual whereabouts of any
data produced by your device is probably unknown, as is its security and
usage.

It's the same tired old "If you're not paying..., you're the product", except
that _you 're actually paying_.

Many of these abuses are much harder to do if you don't expose your exciting
new Thing of Internet directly to the entire global communications
infrastructure, but then we're back in the bad old days where people had to
use software that wasn't a thin client in a browser[1].

I'd really _really_ like a LAN of Things, or a VPN of Things, that still
functions after your service has gone bankrupt or sold their souls to Oracle
or something. But of businesses, especially those riding the wave of 'your
data is feedstock to our deep-learning quantum magic pixies, and we'd never
_ever_ sell it all for a cheap buck[2]' would find it much trickier if that
sweet sweet data wasn't coming their way.

Development & distribution, as well as actually charging for for things,
become harder problems though, which means everyone wants to head to the
promised land of *aaS, where A/B unicorns frolic in the fields and green/blue
munchkins guide your clueless users down the yellow brick upgrade pipeline.

[1] Only mostly sarcastic. [2] unless someone offered

