RIoT (Raiding Internet of Things) by Jacob Holcomb
•
3 likes•1,152 views
The recorded version of 'Best Of The World Webcast Series' [Webinar] where Jacob Holcomb speaks on 'RIoT (Raiding Internet of Things)' is available on CISOPlatform.
Best Of The World Webcast Series are webinars where breakthrough/original security researchers showcase their study, to offer the CISO/security experts the best insights in information security.
For more signup(it's free): www.cisoplatform.com
1 of 51
More Related Content
RIoT (Raiding Internet of Things) by Jacob Holcomb
1. R I o T – R a i d i n g I n t e r n e t o f T h i n g s
Jacob Holcomb, Security Analyst @ ISE
2. Speaker Information
• Who? Jacob Holcomb
» I specialize in application and network security, and
exploit research and development.
» I have responsibly disclosed ~100 vulnerabilities
since 2012.
• What? Security Analyst @ ISE
• Why? Security is IMPORTANT!
3. About ISE
• We are:
- Ethical Hackers
- Computer Scientists
- Individuals
• Our Customers are:
- Fortune 500 Enterprises
- Entertainment, Security Software, Healthcare
• Our perspective is:
– Whitebox (vs. Blackbox)
4. Why IoT Security is Important
• 100% of IoT systems evaluated were vulnerable to
exploitation.
• Routers and storage systems are not the only
embedded devices with egregious deficiencies.
• These systems CAN and ARE being mass exploited.
• Everyday devices are becoming connected and
transmitting data.
5. “Gartner Says the Internet of Things
Installed Base Will Grow to 26 Billion Units
By 2020”
*Source: https://www.gartner.com/newsroom/id/2636073
6. ISE IoT Research
Independent Security Evaluators
– Exploiting SOHO Routers
– Exploiting SOHO Router Services
– Exploiting N.A.S.ty Systems (Network Storage Exploitation)
– Hospital Systems and Infrastrucutre
– https://securityevaluators.com/knowledge/
8. Topics
• Inherent Risks of Networking Equipment
• Threat Modeling and Testing Methodology
• Remediation and Security Design Principles
• IoT Integration
9. Security Risks
• Large attack surface
• Insecure by default
• Assumption of security on the (wireless) LAN
• Poor security design and implementation
10. Threat Modeling
• Threat Modeling allows engineers to identify
and remediate software issues in early
development stages. Cost-effective
• Thorough understanding of system and assets
• Should be a core component of any SDLC
process
17. Analyzing Web Applications
• Understand the application
– Programming languages used
• Server side
• Client side
– Protocols and APIs used (e.g., SOAP, REST)
– Internet Media Type/MIME (e.g., JavaScript, HTML)
• Tools
– Web proxy (e.g., Burpsuite)
– Firebug (JavaScript debugger, HTML inspection)
– Web Crawler
– Python!
19. Analyzing Network Servers
• Authentication
– Type (e.g., Password, Key Pair)
– Anonymous access/Weak or no credentials
– Misconfigurations (e.g., Directory listing, permissions)
• Protocol
– Standard? Custom? Can you speak it?
• Encryption
– SSL/TLS?
– SSH (AES, 3DES)?
20. Static Code Analysis
• If source code is available, GET IT!
• Things to look for:
– Logic flaws (e.g., authentication, authorization)
– Functions not performing bounds-checking
– Backdoors
29. Cross-Site Request Forgery
#define: CSRF is an
attack that forces an
unsuspecting victim into
executing web
commands that perform
unwanted actions on a
web application.
31. Cross-Site Request Forgery
Countermeasures
• Users
– Logout of web applications
– Do NOT save credentials in your browser
• Developers
– Implement Anti-CSRF tokens AND HTTP
referrer checking
– Feeling ambitious? Require users to
authenticate before performing a state change
33. Testing for Command Injection
• Survey the application
– Look for application features that could call underlying
system functionality(e.g., ping, traceroute)
– Source code? Static analysis!
• Test Examples
– ifconfig ; cat /etc/passwd ß Linux
– dir | ipconfig ß Windows/Linux
– ls /var/www/`<cmd>` or $(<cmd>) ß Linux**Command substitution
34. Command Injection Countermeasures
• Developers
– Avoid calling shell commands when possible
– If an API does not exist, sanitize user input
before passing it to a function that executes
system commands.
• Python Example
– BAD: os.system(‘ls ‘ + dir)
– GOOD: os.listdir(dir)
35. Buffer Overflow
#define: Buffer Overflows occur when a program attempts
to write data that exceeds the capacity of a fixed length
buffer, and consequently, overwrites adjacent memory.
Stack Based Buffer Overflow (x86)
36. Testing for Buffer Overflows
• Testing for overflows
– Dynamic Analysis
– Static Analysis
37. Buffer Overflow Countermeasures
• Developers
– Don’t use unsafe functions
– Perform bounds checking
– Compile/Link with overflow prevention techniques
• Canary/Stack Cookie
– gcc –fstack-protector
• ASLR
– gcc –fPIE || ld -pie
• DEP/NX
– gcc marks the stack non-executable by default
39. If that terrifies you…Mass Exploitation
• N.A.S.ty Worm
– D-LINK DNS-345
– TRENDnet TN-200/TN-2011T1
– Western Digital MyCloud EX4
• Similar Occurrences?
40. N.A.S.ty Worm Operation
1. Scan IP Range for TCP/80
2. Fingerprint TCP/80
3. Exploit Target
4. Download and Run
5. Rinse and Repeat
42. Security Design Principles
• Least Privilege
• Secure by Default
• Failsafe
• Defense in Depth
• Audit
• Trust Model
43. Least Privilege
• Least privilege refers to the principle that a
task should be accomplished with the
absolute lowest level of privilege required.
44. Secure by Default
• A system is secure by default if the out-of-
the-box settings put the system in a
secure state.
45. Failsafe
• Failing safe refers to the tendency for a
failure of the system to leave it in a secure
state as opposed to an insecure state.
46. Defense in Depth
• Layers of defensive measures such that
the failure of any one component will not
lead to total system compromise.
47. Audit
• Audit is a critical part of the system that
assists in recovery, investigation and
deterrence.
48. Trust Model
• A trust model clearly defines the trust
assumptions made by the system and may
highlight improper assumptions on the part
of the designers.
50. YIKES! What can we do?
• Consumers
– Harden your SOHO devices.
– Demand that vendors put more emphasis into
securing SOHO networking equipment.
• Vendors
– Abide by Security Design Principles
– Follow coding best practices
– Patch management
51. Presenter Information
Name: Jacob Holcomb
Twitter: @rootHak42
Blog: http://infosec42.blogspot.com
Github: https://github.com/Gimppy042