Upload
dayna-davis
View
216
Download
1
Tags:
Embed Size (px)
Citation preview
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.