Judgment Day: April 12th 2015 The Internet of Things: Who is in Control? Johannes B.
Download ReportTranscript 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