A Hacker's Perspective on Embedded Device Security, presented by Paul Dant of Independent Security Evaluators at the Security of Things Forum, Sept. 10, 2015
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
SOHOpelessly Broken
1. S O H O p e l e s s l y B r o k e n
A Hacker’s Perspective on Embedded
Device Security
2. Who Am I?
ISE Confidential - not for distribution
Paul Dant
Chief Strategist @ ISE
9: First digital product
13: First legit black hat hack
17: First hacker caught
19: First legit white hat hack
(p0wned a bank data
processing center as part of
a compliance audit)
3. About ISE
• We are:
- Ethical Hackers
- Computer Scientists
• Our clients are:
- Fortune 500 Enterprises
- Entertainment, Security Software, Healthcare
• Our perspective is:
– Everything is broken!
– White hat testing rules
4. Why Should You Listen To Us?
• 100% of network 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.
5. #SOHOpelessly Broken
HACK ROUTERS AND GET PAID
https://sohopelesslybroken.com
DEFCON 23, DerbyCon v4.0, BSIDES DC, ToorCon
We launched the first IoT Village @ DEFCON 23
7. Agenda
Embedded Device Security Risks
Why Do We Care?
Hacking Methodology
Real World Examples
What Can We Do?
Summary and Q&A
ISE Confidential | Not for Distribution
8. Embedded Device Security Risks
• Large attack surface
• Default configurations are typically not
secure at all
• Assumption of security on the (wireless) LAN
• Poor security design and implementation
9. Why Do We Care?
• Large attack surface
• Insecure by default
• Assumption of
security on the
(wireless) LAN
• Poor (or missing!)
security design and
implementation
15. Analyzing Web Applications
• Understand the application
– Programming languages used
• Server side (e.g., PHP, .NET, Python, ASP, Ruby on Rails)
• Client side (e.g., JavaScript, HTML, JSON, Flash)
– Protocols and APIs used (e.g., SOAP, REST)
– Internet Media Type/MIME (e.g., JavaScript, HTML)
• Toolz
– Web proxy (i.e., Burpsuite)
– Firebug (JavaScript debugger, HTML inspection)
– Web Crawler
18. 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
25. Reverse Engineering Toolz and
Techniques
• Grep: grep –R <string> *
*Code from the TRENDnet TEW-812DRU
26. Exploit Development
• Cross-Site Request Forgery
• Command Injection
• Missing Function Level Access Control
– Authentication Bypass
– Authorization Bypass
• Directory Traversal
• Buffer Overflow
27. 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.
Gimppy
(Attacker)
Jad
(Victim)
Web
Application
Attacker
Web Server
29. 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 the user to
authenticate before performing a state change
31. 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
33. 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)
34. Missing Function Level Access Control
#define: The absence of
server-side authentication and
authorization checks.
35. Testing for Missing Function Level
Access Control
• Calling privileged API’s as an
unprivileged user.
• Accessing system resources that do
not belong to the attacker.
– Insecure Direct Object Reference
– Direct Request/Forced Browsing
36. Missing Function Level Access Controls
Countermeasures
• Developers
– Perform server-side authentication and
authorization checks.
37. Directory Traversal
#define: Directory Traversal is a form of attack where an
attacker can access files and directories outside of the
intended directory.
38. Testing for Directory Traversal
• Enumerate the application
– Are there commands or request parameters that could be used
for file-related operations?
• URL Encoding (Web only)
– %2f /
– %2e%2e%2f ../
• Test Examples
– http://infosec2.blogspot.com/DT.php?file=../../../../etc/passwd%00
– http://JadWebApp.com/DT.php?dir=..%2f..%2fetc%2fpasswd
– symlink / rootfs SMB
40. Directory Traversal Countermeasures
• Developers
– Try not to use user input in file system calls
– Perform path canonicalization (symlinks, . & .. are
resolved)
– Properly configure services
41. 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)
42. Testing for Buffer Overflows
• Testing for overflows
– Dynamic Analysis
– Static Analysis
43. Buffer Overflow – Vulnerable Code
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char * argv[]){
char argument[42];
if (argc < 2){
printf("n[!!!] Please supply a program argument. [!!!]nn");
exit(0);
}
printf("n[*] Gimppy's BOF code examplen");
strcpy(argument, argv[1]);
printf("[*] You supplied '%s' as your argument!n", argument);
printf("[*] Program Completed. n");
return 0;
}
44. 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
45. Buffalo TeraStation: Hacking Files
• Missing function-level
access control
• Susceptible to
command injection
• p0wned
46. YIKES! What Can We Do?
• Consumers
– Protect your security & privacy! Harden your
networked devices!
– Demand that vendors put more emphasis into
securing SOHO networking equipment.
• Vendors
– Consider and integrate security into your product
design
– Abide by the principal of least privilege
– Follow coding best practices
– Patch management
47. Q & A
Thanks for your time!
Paul Dant
Chief Strategist @ ISE
pdant@securityevaluators.com