Judgment Day: April 12th 2015 The Internet of Things: Who is in Control? Johannes B.
Download
Report
Transcript Judgment Day: April 12th 2015 The Internet of Things: Who is in Control? Johannes B.
Judgment Day: April 12th 2015
The Internet of Things: Who is in Control?
Johannes B. Ullrich, Ph.D.
[email protected]
@johullrich
1
About Me
• Dean of Research,
SANS Technology Institute
• SANS Internet Storm Center
https://isc.sans.edu
• Created DShield.org
• Instructor for SANS
• Past: Physicist, Web Developer
• Living in Jacksonville, FL
2
3
Are We in Control?
Quantified
Self
Internet
of
Things
Data
Devices
4
Quantified Self: Dawn to Dusk
Photo: Withings.com
5
Quantified Self: Dawn to Dusk
Photo: thevesl.com
6
Quantified Self: Dawn to Dusk
Photo: Progressive
7
Quantified Self: Dawn to Dusk
Photo: Fitbit
8
Hello Barbie
9
Quantified Self: Dawn to Dusk
10
Home / Small Business
11
Enterprise Networks
12
Municipal/Gov Networks
13
The “Internet of Things”
14
New Protocols: IPv6
•
•
•
•
Easier to Scale then IPv4
Auto configuration
Extensible
Integrated with various Layer 2
options
15
New Protocols: 6LoWPAN / IEEE 802.15.4
• IPv6 over Low power Wireless
Personal Area Network
• Easier network management
• Low Power
• Low Hardware Requirements
• Security
16
Risks: New Wireless Protocols
• IEEE 802.15.4 / 6LoWPAN
• AES identified as encryption
algorithm
• Key Management challenge: Auto
configuration / on-boarding at scale
• IPSec (IKEv2) may not work due to
power constraints
17
Example: LIFX Light Bulbs
• Light Bulbs communicate via 6LoWPAN
with each other (mesh)
• One light bulb acts as router/controller
to connect to Wi-Fi (802.11)
• Pre-shared AES key hardcoded. Same
for all bulbs
• 6LoWPAN is used to exchange WiFi
credentials (which are now at risk)
• Solution: Derive 6LoWPAN key from WiFi Password.
18
Risks: New Attack Platforms
• Many devices use customized
versions of commodity operating
systems (Linux/Windows)
• Wide range of architectures, not just
x86
• Embedded systems can even be
found inside conventional systems
19
SciFi
Photo: Paramount Pictures
Photo: Warner Brothers
Photo: tailgrab.org
20
ISC Mission
• Global Network Security Information
Sharing Community
• We share fast, ask readers for insight
• Expanding diverse sensors for
automatic data collection
• Built around DShield platform
• Raw data available for others to
analyze
21
ISC: The big picture
22
ISC Handlers
• Currently about 30 volunteer
handlers
• Located worldwide and working in
different industries
23
How to use our data
• Threat Intelligence
– Diaries
– IP Address Feeds
– Domain Feeds
• Data is free to use for your own
network (Creative Commons License)
• Share back!
24
Case #1 – Compromised Routers
• E-Mail + phone call from ISP in
Wyoming
– Affects Linksys E1000/1200
– Scanning for Port 80/8080
– Latest firmware not affected
– Reset of router clears malware
25
Case #1: Verification
• Check DShield Logs: No spike in port
80/8080, but they are always busy
26
Case #1: Honeypot Data
Seeing “interesting” requests:
GET /HNAP1/ HTTP/1.1
Host: a.b.c.d:8080
But nothing else…
Something seems to be going on, publishing first
“Diary”
27
Case #1: Experiment
wget http://routerip/HNAP1/
<?xml version="1.0" encoding="utf8"?> <soap:Envelope
xmlns:xsi="http://www.w3.org/…”> <soap:Body> <GetDev
iceSettingsResponse ... >
<DeviceName>Cisco40033</DeviceName> <
VendorName>Linksys</VendorName> …<Mod
elName>E4200</ModelName>
…
</GetDeviceSettingsResponse> </soap:Body> </soap:Env
elope>
28
Case #1: Honeypot
• Setting up a simple Honeypot to
simulate router (reply with correct
HNAP response)
• Scanning routers now send exploit:
POST /tmUnblock.cgi HTTP/1.1
Host: [ip of honeypot]:8080
Authorization: Basic
YWRtaW46JmkxKkBVJDZ4dmNH
29
Case #1: The Moon Worm
30
Case #1: Challenges
• MIPS Architecture
• No common virtual environments
available
• Most reverse analysis tools are x86
centric
• Exploit requires specific firmware
versions
• NO PATCH?!!
31
Case #2: Port 5000 Traffic
32
Case #2: Compromised DVRs
• Security Camera DVRs
• Exposed to Internet for remote
monitoring
33
Case #2: Exploit
• Very simple exploit: default
username/password (root/12345)
used to telnet
• Various binaries copied to DVR
– Bitcoin miner
– Scanner for Synology Vulnerability
– wget / helper tools
34
Case #2: Why Vulnerable?
• Simple Password Dialog
• Not possible to turn off telnet
35
Case #2: Who Did it?
36
Case #2: Who did it?
37
Case #2: Why Vulnerable?
38
Echo File Transfer
echo -ne
'\x00\x00\x00\x2f\x00\x00\x00\x1a\x00
\x00
\x00\x00\x00\x00\x00\x05\x00\x00\x00\
x00
\x00\x00\x00\x04\x00\x00\x00\x00\x00\
x00 \x00\x31\x00\x00\x00\x00\x00
\x00\x00\x2a\x00\x00\x00\x1b\x00\x00\
x00 \x14\x00\x00\x00' >>
/var/run/rand0-btcminer-arm && echo e '\x64\x6f\x6e\x65'
39
Case #3: Synology Disk Stations
Vulnerable web based admin interface
Exposed on port 5000
Allows remote code execution
Exploited before patch
became available
• Difficult to patch devices
•
•
•
•
40
Case #3: Synology Vulnerability History
• CVE-2014-2264: Hardcoded VPN
Password
• CVE-2013-6955: webman
vulnerability allows appending to
arbitrary files
• CVE-2013-6987: read/write/delete
files via directory traversal
41
Case #3: Iowa State Breach
• Iowa State stored student data including
SSNs on Synology devices
• Devices got breached by Bitcoin miner
campaign
• 5 devices breached
• 29,780 SSNs exposed
42
Case #3: Continuation … Synolocker
https://www.facebook
.com/events/birthday
s?extra_data%5Bstart
_date%5D=2015%2F0
4%2F11
43
Case #4: Handheld Inventory Scanners
44
Case #4: Targeted Attack
• 12 of 40 scanners delivered to a
robotics/logistic company came with
malware pre-installed
• Malware attacked network “from the
inside”
• Targeting accounting systems
• Exfiltrating data
• Firmware downloaded from
manufacturer site was infected as well
45
Case #4: Malware Details
• Scanner runs Windows XP Embedded
• Malware only detected due to
network monitoring
• Not possible to install standard AV or
Whitelist tools on scanner
46
Defensive Strategies
47
We need solutions that scale!
48
Network Segmentation
• Target: Air Conditioner network not
sufficiently segmented, allowed for
breach of “business” network.
• How many segments can we
manage?
• Do all devices fit into the same
segment?
• How do they talk to the rest of the
network?
49
Onboarding Devices
• Accounting for devices / inventory
• Configuring security parameters
(passwords, keys)
• Establishing baseline configuration
• Develop/Procure tools to provision
devices at scale securely
50
Patching
• How are patches distributed /
validated?
• Can automatic patching be used?
• Centralized patch management
solutions?
• Inventory/Onboarding first. Needs to
integrate with Patching
51
Logging / Monitoring
• What logs to collect and how?
• Flooded by meaningless logs?
• Setup “satellite collectors” that
aggregate and pre-filter before
sending to central log management
system
52
Solution 1: Don’t buy crap
• Ask the right questions before
purchasing devices:
– Onboarding tools?
– Logging standards?
– Support contracts?
53
Solution 2: Scalable & Repeatable Processes
• Take what you learned from your
desktop/server environment
• Automation!
54
Conclusion
Are we still in control?
Probably not… but not clear who is in
control… the machines? The cloud?
The miscreant pw0ning your
machines?
55
Thanks!
Questions?
[email protected]
http://isc.sans.edu
Daily Updates * Daily Podcast * Data Feeds
Twitter: @johullrich / @sans_isc
LinkedIn
56