the 7 deadly sins security-based design flaws in iot products 1 drew redshift porter maker &...

The 7 Deadly Sins

Security-Based Design Flaws in IoT Products

1

Drew Redshift PorterMaker & Breaker

Bastille

Agenda

Stor

y Ti

me

It’s A

ll Fu

n an

d Ga

mes

7Dea

dly

Sins

Wha

t Not

to

Do

How

to D

o It

Ques

tions

2

Story Time

3

Story Time

4

THE 7 DEADLY SINSHOW TO MAKE SURE YOUR PRODUCT IS NOT A TALK AT A CON

5

This is baby town

Even with non-sensitive data, you should not do this

Super low hanging fruit

Use Of Clear Text Protocols

6Sin #7

Communication Done Correctly

Look to see if there are any secure implementations of the protocol

Make sure implementation is done correctly

Almost every protocol has a secure version

7

Software or Hardware

Even if not “active”

First attack vector

Debugging Enabled or Pins Exposed

8Sin #6

Debugging Done Correctly

Disable all debugging functions before production (Software and Hardware)

Ensure that debugging is disabled

Do not provide the options for debugging on the board

9

Radio protocols are difficult to do correctly

Security through obscurity

Compounding security flaws

Your Own Proprietary Radio Protocol

10Sin #5

Radio Done Correctly

Use tried and true radio hardware

Use tried and true radio protocols

Make sure it is secure, even if it is popular*cough* BLE/BT Smart *cough*

11

Are you authorized???Why, yes I am

Easy to fool, easy to break

Is this the early 2000s?

User-Side App Verification

12Sin #4

App Verification Done Correctly

Have your app request authentication verification from an external server

Look into multi-step verification

Read the many guides online about app verification

13

You are not smarter than the NSA’s mathematicians…

Sorry

Static encryption keys

Weakening of good encryption methods

Proprietary Encryption Or Weakening

14Sin #3

Encryption Done Correctly

Use tried and true encryption methods

Do not think you are better than the PhDs who develop crypto

Ensure that encryption is implemented correctly

15

Do we really have to talk about this one???

TL;DR BLE is broken to hell and should not be used by itself*

*When using BLE for authentication or secure communication

Using BLE Only and Calling It Secure

16Sin #2

BLE Done Correctly

BLE with WiFi or some other communication method

BLE with OOB (No real COTS solution for this right now)

17

Assuming Your Product Is Secure

FOR THE LOVE OF GOD, NEVER DO THIS!

18Sin #1

Making Sure Your Product Is Secure

Having your own security team run tests against your product

Have your product tested by a third party companyMake sure they do both automated and manual

testingMake sure they have a hardware guy/gal

Maybe even have it tested by 2 companies

19

7 Deadly Sins

7• Use Of Clear Text Protocols

6• Debugging Enabled or Pins Exposed

5• Your Own Proprietary Radio Protocol

4• User-Side App Verification

3• Proprietary Encryption Or Weakening

2• Using BLE Only and Calling It Secure

1• Assuming Your Product Is Secure

20

Look for these in your next product pentest

Design with these 7 in mind

Share this with everyone you know

Summary

21

REVPLEX.COMFor those who keep on asking about my meshnet project.

Thank You

Drew Redshift Porter

@iamredshift

iamredshift@gmail.com

Bastille BASTILLE.IO

23