1) The document discusses vulnerabilities found in IoT devices, including a lack of strong passwords, encryption of communications and updates, and other security issues. 2) The author analyzed 50 smart home devices and found major issues with all of them, such as none enforcing strong passwords or using mutual authentication. 3) The document provides examples of potential attacks on IoT devices when an attacker has access to the local network, such as intercepting unencrypted traffic or reprogramming devices by spoofing firmware updates.

1. GURUGRAM CYBER CRIME CELL
INTERNSHIP PROGRAM2017
RESEARCH PAPER
ON
Jay Nagar
Information security researcher
Email: nagarjay007@gmail.co
Cell:+91-9601957620
Website : www.jaynagarblog.wordpress.com
Research By:
Er. Jay Nagar
Saffrony InstituteOf Technology
IoT Vulnerability Analysis and IOT Insecurity Controls

2. OVERVIEW
The Internet of Things (IoT) markethas begun to take off. Consumers can buy
connected versions of nearly every household appliance available. However,
despite its increasing acceptance by consumers, recentstudies of IoTdevices
seem to agree that “security” is not a word that gets associated with this category
of devices, leaving consumers potentially exposed. To find out for ourselves how
IoTdevices fare when it comes to security, we analyzed 50 smarthome devices
that are available today. We found that none of the devices, enforced strong
passwords, used mutualauthentication, or protected accounts against brute-
forceattacks. Almosttwo out of ten of the mobile apps used to control the tested
IoTdevices did not useSecure Sockets Layer (SSL) to encryptcommunications to
the cloud. The tested IoTtechnology also contained many common
vulnerabilities. All of the potential weaknesses thatcould afflict IoTsystems, such
as authentication and traffic encryption, arealready well known to the security
industry, butdespite this, known mitigation techniques are often neglected on
these devices. IoTvendors need to do a better job on security before their devices
become ubiquitous in every home, leaving millions of people at risk of
cyberattacks.

3. INTRODUCTION
“The use of weakpasswordsisa securityissue thathasrepeatedlybeenseeninIoTdevices.”
Our IoTdevices were analyzed and threats due to malware of IoT devices were investigated.First is analyzing
Telnet-based scans in Darknet(usingunused IP addresses),we recognized that the attacks (scans) on Telnet had
dramatically increased since2014.Moreover, by grabbingTelnet banners and web contents of the attackers,a
majority of the attacks were indeed from IoT devices.Motivated by this,we proposed IoTPOT, a novel honeypot to
emulate Telnet services of various its devices to analyses ongoingattacks in depth with backend high interaction
virtual environments called IoTBOX (sandbox analysisfor IoTdevices) for different CPU architectures.Over 39 days
of experimental operation, we observed 76,605 download attempts of malwarebinaries from16,934 visitingIPs.
We also confirmed thatnone of these binaries could havebeen captured by existinghoneypots that handled
Telnet protocol such as honey and telnet password honeypot becausethey were not ableto handledifferent
incomingcommands sent by the attackers.Combiningthe observations results of IoTPOTand the sandbox analysis
by IoTBOX,
We confirmed that
I) There were at leastfour distinct malwarefamilies spreadingvia Telnet,
ii) There common behavior was performing DDoS and further propagation over Telnet,
iii) Some families evolved quickly,updatingfrequently and shippingbinaries for a variety of CPU architectures,
even in the limited observation period of 39 days.
Based on the work on the vulnerableIoT devices which were owned by individualswithoutany management, we
propose a method to implement security controls for the less-controlled IoTdevices.The security controls should
be provided from three different angles.
1) Security guidelines should beprovided to improve IoTdevice owners’ awareness such as promotingthe use of
appropriateIDs and Passwords,
2) Proper shippingof IoTdevices by IoT vendors for the initial settingof a more secure use of the Internet (e.g.
closeport 23)
3) Removing malwares from infected IoT, or stoppingthe activation of malwares (deletion of registry,exe, or
scheduler).
It is importantto consider a time-line of IoT devices,that is,a) most of the vulnerableIoT devices are already in the
market and in use (already shipped),b) IoT devices are goingto be shipped by IoT vendors,and c) future types of
IoT devices of which we arestill notableto for see the characteristics.The above security control 1) could be
applicablefor all a)-c),however, security control 2) is for b) and security control 3) is basically for a).
Furthermore, in connection with the security control 3), the implementation of an appropriatesoftware/firmware
update function was significantly importantfor IoT devices in all time-lines (a)-c)).In this paper,consideration is
given to this update function for IoT software/firmware based on the ITS secure update procedure. Finally,a listof
research topics for the IoT environment is provided for future collaborativeresearch.

4. Key findings
Duringour research,we foundissuessuchasthe following:
• Around19 percentof all testedmobile appsthatare usedtocontrol IoTdevicesdidnotuse Secure
SocketLayer(SSL) connectionstothe cloud
• None of the analyzeddevicesprovidedmutual authenticationbetweenthe clientandthe server
• Some devicesofferednoenforcementandoftennopossibilityof strongpasswords
• Some IoTcloudinterfacesdidnotsupporttwo-factorauthentication(2FA)
• Many IoT servicesdidnothave lock-outordelayingmeasurestoprotectusers’accountsagainst brute-
force attacks
• Some devicesdidnotimplementprotectionsagainstaccountharvesting
• Many of the IoT cloudplatformsincludedcommonwebapplicationvulnerabilities
• We foundtensecurityissuesinfifteenwebportalsusedtocontrol IoTdeviceswithoutperformingany
deeptests.Six of themwere seriousissues,allowingunauthorizedaccesstothe backendsystems.
• Most of the IoT servicesdidnotprovide signedorencryptedfirmware updates,if updateswere
providedatall IntroductionRecent Gartnerresearchpredictsthatthere will be more than2.9 billion
connectedIoTdevicesinconsumersmarthome environmentsin20151 . These connecteddevicescould
provide amuch largersurface for attackersto targethome networks.Currently,mostproposedIoT
attacks are proof-of-conceptsandhave yettogenerate anyprofitforattackers.Thisdoesnot meanthat
attackerswon’ttarget IoTdevicesinfuture,evenif itisjusttomisuse the technologyorhave a
persistentanchorina home network.The use of weakpasswordsisasecurityissue thathas repeatedly
beenseeninIoTdevices.These devicesoftendonothave a keyboard,soconfigurationhastobe done
remotely.Unfortunately,notall vendorsforce the usertochange the devices’defaultpasswordsand
manyhave unnecessaryrestrictionswhichmake the implementationof long,complex passwords
impossible.The OpenWebApplicationSecurityProject’s(OWASP) Listof TopTenInternetof Things
Vulnerabilitiessumsupmostof the concernsand attack vectorssurroundingthiscategoryof devices:
• Insecure webinterface
• Insufficientauthentication/authorization
• Insecure networkservices
• Lack of transportencryption
• Privacyconcerns
• Insecure cloudinterface
• Insecure mobile interface
• Insufficientsecurityconfigurability
• Insecure software/firmware

5. CONNECTED HOMEDEVICES
“With the Internetof Things(IoT) findingitswayintothe homes,there are lotsof new devicesthatcan
connectto the same network.”
Connectedhome devices there are manydifferentsmarthome devicesavailable onthe markettoday,
and the numberissteadilyincreasing.Forthispaper,we lookedat50 differentdevicesfromthe
followingcategories:
• Smartthermostats
• Smartlocks
• Smartlightbulbs
• Smartsmoke detectors
• Smartenergymanagementdevices
• Smarthubs
Our findings could also apply to other IoT devices and smart home products, such as:
• Securityalarms
• Surveillance IPcameras
• Entertainmentsystems(smartTV,TV set-topboxes,etc.)
• Broadbandrouters
• Networkattachedstorage (NAS) devicesSmarthome devicesmayalsouse a back-endcloudservice to
monitorusage or allowuserstoremotelycontrol these systems.Userscanaccessthisdata or control
theirdevice throughamobile applicationorwebportal.
Home network topology
Today’shome networksare typicallymade upof a broadbandrouterofferinginternetaccesstodevices
throughWi-Fi andEthernetconnections.Mostof the devicesthatconnectto these home networks
include laptops,desktopcomputers,andmobiledevices,suchasphonesandtablets.Everythingis
connectedinthe local networkandcan communicate freelywithone another.Connectionstothe
internetare directedthroughthe central router,whichmaycontainbasicfirewallfilteringfunctionality.
Withthe Internetof Things(IoT) findingitswayintothe homes,there are lotsof new devicesthatcan
connectto the same network.These devicescanbe classifiedintwobasiccategories.One category,
whichincludesTV set-topboxes,usesalready-existingnetworkingtechnologiessuchasWi-Fi and
Ethernetconnections.The othercategory,whichincludessensors,mayuse differentwireless
technologiesthatbettersuitsome of the devices’needs,suchaslower energyconsumptionorad-hoc
networkcoverage.There iscurrentlynosingle standardprotocol inIoT.

6. As a result,we have seenIoT
devicesthatsupportsome of
the followingcommunication
methods:
• Z-Wave
• Zigbee
• Powerline
• Bluetooth4.0
• Otherradiofrequency(RF)
protocols
Z-Wave,Zigbee andPowerline
are the mostcommon protocols
usedbyhome automation
manufacturersatthe moment.
There are some hybridsolutions
that use bothPowerline and
customRF protocols.Amongthe smart hubdevicesthatwe tested,66 percentofferedZ-Waveand48
percentofferedZigBee connectivity.
Figure 1. The smart home ecosystem
Devicesthatuse a single wirelessconnectivityprotocoloftenrelyonacentral hubdevice tohandle the
coordinationof the communication.Thiscould,forexample,be asmart lightbulbthatcan be switched
on or off througha webportal runningon a local hub.The usercan access the webportal throughtheir
webbrowserandcontrol lightbulbsconnectedtothe hub.Due to IoT’sneedto use simple integrations
and the broad use of the IEEE 802.11 wirelessstandards,manynew deviceshave switchedtoregular
Wi-Fi forcommunicationwhere possible.
Some classesof devicestrytoprovide everypossible optionforconnection.Outof all of the deviceswe
lookedat,58 percentsupportedWi-Fi connectivity.Table.FeaturesofferedinanalyzedIoTdevices
Home device featuresNumberof analyzeddevicesthatsupportfeature Percentage of analyzeddevices
that supportfeature SupportsWi-Fi connections.

7. EXAMPLE ATTACKS:
“For our test,we usedthe preconditionthatthe attackerhassuccessfullycrackedthe Wi-Fi password
and has accessto the local network.”
In order to showhow simple, itistoconduct an attack againstconnectedhome devices,we will
describe twoof the attack scenariosthatwe performedduringourtests.We usedthe LightwaveRFand
BelkinWeMosmart hubsinthese examples,thoughsimilarattacksare possible againstotherdevices.
For our test,we usedthe preconditionthatthe attackerhassuccessfullycrackedthe Wi-Fi passwordand
has accessto the local network.We believethatthisisa reasonable assumptiontomake,giventhat
manypeople use weakpasswordstoprotecttheirwirelessnetworkathome.
By usinga networksniffersuchasWiresharktoanalyze the networktraffic,we noticedthatthe
LightwaveRFsmarthubgeneratescertainnetworktrafficeachtime itrestartsandevery15 minutesto
checkfor firmware updates.The devicesendsthistraffictoa remote Trivial File TransferProtocol (TFTP)
serveronthe Internet.Since thisconnectionisneitherencryptednorauthenticated,itcaneasilybe
targetedbyan attacker withaccessto the network,allowingthemtoconducta man-in-the-middle
(MITM) attack.
In our tests,we chose touse AddressResolutionProtocol (ARP)poisoningtoredirectthe smarthub’s
requesttoour ownTFTP server.Since the firmware update isanunsignedblobinaraw format,it iseasy
to unpackand modifyit.Once the modifiedfirmware updateisservedtothe device andinstalled,the
attackergets full control overthe smarthub device andcouldstartattackingotherconnecteddevices
fromthere.
In additiontothis,attackerscan sniff the RFlinkfor commandpacketsandreplaythem.Witha smart
hubthat just turnsdevicesonandoff,itonlyreceivesasmall numberof differentcommandpackets.As

8. a result,the attackersdon’tneedtoworry aboutbreakinganypairingif theyare close enoughtothe
device toinjectspoofedpackets.Thiscanallow themtotake control of the targeteddevice.
Anotherattackexample focusesonthe BelkinWeMoconnectedswitch.Inthiscase,we analyzedthe
networktrafficthatwas sentfromthe device’scontrollerapplication.The device didnotrequire the
userto provide authenticationinordertoconnectto it.If the attackeris onthe same networkasthe
device,theycansendanycommandstheywantto the connectedswitch.
Researchershave createdpubliclyavailablemodulesforthe penetrationframeworkMetasploitthat
couldgive attackersa way to injectcode inthe BelkinWeMoconnectedswitch.Thiscouldallow themto
run commandsas the root useron the switch.Alongwiththis,the switch’s firmware isencryptedwith
GNU PrivacyGuard (GPG),but the private keyhasbeenextractedandsharedonthe internet.Attackers
couldtarget bothof these issuesandcompletelyreprogramthe s witch.Researchersdiscoveredfurther
vulnerabilitiesinthe switchlastyear,whichhave since beenfixedbythe vendor.
Attack surface
Attackerscan interceptorchange the behaviorof smarthome devicesinmanyways.Some methods
require physical accesstothe device,makinganattackmore difficulttoconduct.Otherattackscan be
carriedout overthe internetfroma remote location.The followingsectionslistthe differentattack
scenariosbasedonthe access level thatthe attackermayhave.
Physical access
An attackercan gain the highestlevel of accessto the smart home device if theygetphysical accesstoit.
Althoughthismightseemlikeanimprobableattackvector,itisstill a plausiblethreat.Yourfriendscould
gainphysical accessto yourIoT device toplaya prankwhile visitingyou.Anex-boyfriendorgirlfriend
couldattemptto reconfigure some of the deviceswhile theystill have accesstothe home.Forsome
devices,suchassecuritycamera,an attackercouldsimplycutthe cablestoturn themoff.
Anotherplausible physical accessattackscenariotakesadvantage of the marketforsecond-handIoT
devices.Some usersmightbuyauseddevice off the internetinordertosave some money,butcould
endup witha device thathasbeencompromisedtospyon people.
Smart home devicescouldalsobe compromisedthroughsupplychainhacks.Inthisscenario,attackers
compromise asuppliercompany’snetworkandTrojanize theirsoftware updates,allowingthe threatto
spreadto any device thatavailsof the poisonedupdate.Thisisnota new scenario;we have seenattack
groupsconduct supply-chainattackstospreadtheirmalware totraditional computersmanytimes
before,suchasduringsome of the HiddenLynx attackers’campaigns.Unfortunately,thereiscurrently
no easywayto verifythatan IoT device hasnotbeentamperedwith.
Havingphysical accessto the device allowsthe attackertoalterconfigurationsettings.These could
include issuinganewdevice pairingrequest,resettingthe devicetofactorysettingsandconfiguringa
newpassword,orinstallingcustomSSLcertificatesandredirectingtraffictoa servercontrolledbythe
attacker.

9. Physical accessmayalsoallowa skilledattackertoreadthe device’sinternal memoryanditsfirmware.
Theycould do thisby accessingprogrammaticinterfacesleftonthe circuitboard,suchas JTAG and
RS232 serial connectors.Some microcontrollersmayhave disabledthese interfaces,butcouldstill allow
directreadsfrom the attachedmemorychipsif the attackersoldersonnew connectionpins.
Readingthe internal memoryandreversingthe firmwareallowsanattackerto betterunderstandhowa
device works,allowingthemtofindvulnerabilities,cryptographickeymaterials,backdoors,ordesign
flawsthatcouldbe usedtoperformfurtherattacks.If the attackergainsa full understandingof the
firmware,theycoulduse thisknowledgetocreate theirownmaliciousversionof the firmwareand
uploaditto the device.Thiscouldgive the attackerfull control overthe device.Thisactof re-flashing
the device maybe conductedthroughthe JTAG or RS232 connection.
Most newdevicesofferwaysforuserstoupdate the firmware throughoutthe lifecycle of the device.
These updatescouldarrive throughaUSB connection,an SD card, or overthe network.The majorityof
testeddevicesdidnotuse encryptednordigitallysignedtheirfirmware updates,makingiteasyforan
attackerto generate a valid,maliciousfirmwareupdate thatcouldbe installed.
Local attacks over Wi-Fi/Ethernet
An attackerwithaccessto the local home network,eitherwirelesslyorthroughanEthernetconnection,
isable to performvariousattacksagainstsmart home devices.There are generallytwocommonmodes
of forsmart home devices:cloudpollinganddirectconnection.Dependingonthe function,the device
may use eitherof these methodstoreceivecommands.
Cloud polling
In the case of cloudpolling,the smarthome device isinconstantcommunicationwiththe cloud.The
device checksthe cloudservertosee if there are any commandsto be executedandthenuploadsits
currentstatus.The device mayuse thismethodif itwantsto keeppollingthe cloudservertocheckif
there isa newfirmware versionavailablethatneedstobe downloadedandinstalled.
Attackersmayneedto performanMITM attack to targetsuch an implementation.Forthistosucceed,
the attackerscan try andredirectnetworktrafficwithnetwork-level attacks,suchasARPpoisoningor
by modifyingthe domainname system(DNS)settings.A self-signedcertificate ortoolssuchasSSLstrip
can helpattackersinterceptHTTPSconnections.
Unfortunately,some of the testeddevicesdonotverifyif the certificate istrustedandbelongstothe
vendorat all−theyapprove of the connectionaslongasit’sdone overHTTPS. To make mattersworse,
none of the testeddevicesperformamutual SSLauthentication,where bothsidesauthenticate with
one anotherinsteadof justthe serverauthenticatingwiththe client.Mostdevicescompletelyignore
certificate revocationlists,allowinganattackerto use keysthatwere obtainedthroughadata breach
withoutanyproblem.

10. Direct connection
Some devicesuse directconnectionstocommunicate withahubor applicationinthe same network.
For example,amobile appmaybe able toscan the local networkfornew devicesandlocate themby
probingeveryIPaddressfora specificport.Anothermethodistouse the Simple Service Discovery
Protocol/Universal PlugandPlay(SSDP/UPNP) protocol todiscover the devices.Thismeansthatany
attackercould dothe same to easilyfindthesedevices.
A commonmistake thatwe’ve seeninthese devicesisthe use of unencryptednetwork
communications.Almosttwooutof ten(19 percent) of the testeddevicescommunicate totheirback-
endcloudservice orapplicationwithoutencryption,suchasSSL. For communicationsinthe local
network,the numberof unencryptedconnectionsisevenhigher.The lackof encryptionraisesamajor
privacyconcern.Devicesmaypasspersonal data,logincredentials,ortokensincleartext,lettingan
attackerinterceptthem.
The most commonmethodforusersto interactwithan IoT device isthroughawebbrowseror a
smartphone app.More powerful devicesrunasmall webserverandallow the userto use a web-based
GUI to sendcommands.Otherdevicesoffertheirownapplication programminginterface (API) thatthe
usercan interactwith.If the userwantsto remotelycontrol the deviceswhenthey’re notathome,then
theyneedtobe able toopenan inboundportat the router.This maybe done througha UPNPrequest
or may be manuallyimplementedbythe user.
Many of these interfaceshave beenfoundtobe vulnerable tocommonandknowntypesof
vulnerabilities,includingthe following:
• Use of unauthenticatedrequeststoperformactions(forexample,reconfiguration,dataretrieval,
managementfunctions,etc.)
• Abilitytoperformunrequestedfirmware upgrades
• Commandinjections
• Buffer/heapoverflows
• OWASP’sListof the Top Ten WebVulnerabilities:
• Infectionflaws
• Brokenauthentication
• Cross-site scripting(XSS)
• Insecure directobjectreferences
• Securitymisconfiguration
• Sensitive dataexposure
• Missingfunction-level accesscontrol
• Cross-site requestforgery(CSRF)

11. Malware
Malicioussoftware installedonanydevice connectedtothe home networkcouldhave the abilityto
interactwithsmart home devicesandletthe attackerperformthe attacksas previouslydescribed.Most
likely,acompromisedsmartphoneorcomputercouldbe usedtoattack otherdevices.One of the
biggestconcernsisthat an infectedIoTdevice wouldremaincompromisedforaverylongtime,asthere
iscurrentlyno integratedsecuritysoftware thatcoulddetectitandnouser interface thatcouldinform
the userof any issues.
Fortunately,asof now,we have notseenwidespreadmalware attacksagainstIoTdevices.The news
reportabout spam-sendingfridgesturnedouttobe untrue,buttechnically,itispossible.Proof-of-
conceptmalware hasbeendevelopedforIoTdevices,suchassmart TVs.Furthermore,we have seen
malware attackingrouters,NAS,andsimilardevicesforawhile now.
It isjust a matterof time until attackersfindawayto profitfromattackingIoT devices.Thismayleadto
connectedtoastersthatmine cryptocurrenciesorsmartTVsthat are heldransombymalware.
Unfortunately,the currentstate of IoTsecuritydoesnotmake it difficultforattackersto compromise
these devicesonce theysee the benefitof doingso.
Cloud infrastructureattacks
A smart home device mayinclude aback-endcloudservice,dependingonthe categoryof the device.In
our tests,68 percentof the devicesofferedacloudservice.Suchaservice couldbe usedforstatistical
purposes,suchas loggingthe home’selectricityusage orCO2 levelsoveranumberof months.Other
cloudsystemsallowthe remote managementof IoTdevices,suchaslightbulbsor heating.Some
vendorsevenforce the usertoconnectto theircloudback-endsystemanddonot provide userswith
the optionof locallymanagingtheirdevices.The companieseitherprovideaccesstothe cloudservice
througha smartphone applicationorawebportal,where userscan login.
Unfortunately, nearlyall of the testedIoTcloudservicesallow the usertochoose weakpasswords,such
as “1234”. Evenworse,manyservicespreventthe userfromusingstrongpasswordswithasufficient
level of complexity,due tounreasonable restrictions.One service,forexample,restrictedthe usertoa
PIN code witha maximum lengthof fournumbers.Thismakesiteasyforany attackerthat knowsthe
user’semail addresstobrute-force theirPIN code andtake overtheiraccount.
Most of the analyzedservicesdon’tlockusersoutof theiraccountsafter a numberof failedlogin
attempts,furtherallowingattackerstobrute-force accounts.None of the analyzedback-endcloud
servicesprovidedthe optionof two-factorauthentication(2FA).
Some of the cloudinterfaceshave anunsecure passwordrecoverymethodorreveal toomuch
informationduringthe recoveryprocess,suchasdisplayingthe validityof anaccount. Thiscouldleadto
account-harvestingattacks,whichmayallow the attackerstotake control of the IoT devicesandgather
the users’personal data.
All of the testedcloudmanagementconsolesusedSSLencryptionforcommunications.The serverswere
patchedagainstthe OpenSSLMan in the Middle SecurityBypassVulnerability(CVE-2014-0224), more
commonlyknownasthe Heartbleedbug.Unfortunately,some of the serviceswere still vulnerableto

12. the SSL Man In The Middle InformationDisclosure Vulnerability (CVE-2014-3566),also knownasthe
Poodle bug,andallowedthe use of weakerciphermethods.
Some cloudserviceshave logical errors,whichcouldallow anattackerto obtainsensitive customer
informationoraccessdeviceswithoutauthentication.These servicesalsocontainedcommon
managementconsole vulnerabilities,includingthose listedinOWASP’sListof the TopTen Web
Vulnerabilities.While observingnetworktraffic for15 applications,we foundandreportedten
vulnerabilitiesrelatedtocross-site scripting(XSS),pathtraversal,unrestrictedfileuploading(remote
code execution),andSQLinjection.One of the testedcloudconsolewasforsmartlocks,so this
vulnerabilitycouldhave allowedanyonetoremotelyopenthe locks.
For example,we foundthatone cloudmanagementconsole wassusceptibletoa blindSQLinjection
attack. Thisallowsanattacker to readthe console’sdatabase,whichcontainedthe logincredentialsfor
otherusers.Once the attackers obtainthe credentials,theycoulduse themaspartof a simple script
that sendsrequeststoturnoff connecteddevicesordelete entire accountsaltogether.We informedthe
vendorandthe issue hasnowbeenpatched.The mostconcerningpartisthat these webmanagement
platformsare accessible toeveryoneoverthe internet.Attackerscouldgainunauthorizedaccessto
these serviceswithoutneedinglocal accesstothe home network.Ourresearchinthisarea has only
scratchedthe surface,the relevantcloudservice vendorswouldneedtoconductfull webapplication
testsinorder to findall of the potential issuesintheirdevicesandservices.
Mitigation:
Unfortunately,itisdifficultforauserto secure theirIoT devicesthemselves,asmostdevicesdonot
provide asecure mode of operation.Nonetheless,usersshouldadhere tothe followingadvice toensure
that theyreduce the riskof these attacks:
• Use strong passwordsfordevice accountsandWi-Fi networks
• Change defaultpasswords
• Use a strongerencryptionmethodwhensettingupWi-Fi networkssuchasWPA2
• Disable orprotectremote accessto IoT deviceswhennotneeded
• Use wiredconnectionsinsteadof wirelesswhere possible
• Be careful whenbuyingusedIoTdevices,astheycouldhave beentamperedwith
• Researchthe vendor’sdevice securitymeasures
• Modifythe privacyandsecuritysettingsof the device toyourneeds
• Disable featuresthatare not beingused
• Install updateswhentheybecome available
• Use devicesonseparate home networkwhenpossible

13. • Ensure that an outage,forexample due tojammingora networkfailure,doesnotresultinaunsecure
state of the installation
• Verifyif the smartfeaturesare reallyrequiredorif a normal device wouldbe sufficient
Manufacturersof smart homedevices shouldensure that they implementbasicsecurity standardsat
the very least:
• Use SSL/TLS-encryptedconnectionsforcommunication
• Mutuallycheckthe SSL certificate andthe certificate revocationlist
• Allowandencourage the use of strongpasswords
• Require the usertochange defaultpasswords
• Do notuse hard-codedpasswords
• Provide asimple andsecure update processwithachainof trust
• Provide astandalone optionthatworkswithoutinternetandcloudconnections
• Preventbrute-force attacksatthe loginstage throughaccount lockoutmeasures
• Secure anywebinterface andAPIfrombugslistedinthe OWASPListof Top Ten Webvulnerabilities
• Implementasmart fail-safemechanismwhenconnectionorpowerislostor jammed
• Where possible,lockthe devicesdowntopreventattacksfromsucceeding
• Remove unusedtoolsanduse whitelistingtoonlyallow trustedapplicationstorun
• Use secure boot chainto verifyall software thatisexecutedonthe device
• Where applicable,securityanalyticsfeaturesshouldbe providedinthe devicemanagementstrategy

14. My Analysis
We analysisand investigateIoT devices We found the many loop holes and the threat of vulnerableIoT devices
which is compromised by malware by means of the proposed IoTPOT (honey) and IoTBOX (sandbox). The
vulnerableIoTdevices which are owned by individualswithoutany management, we proposetwo types
(approaches) of security controls for the less-controlled IoTdevices.Recognizing the current situation where many
vulnerableIoTdevices arealready infected by several types of malware, the firstapproach proposes a security
solution to remove malwarefrom infected IoT devices, or to stop the activation of malware(deletion of registry,
exe, or scheduler).In the second approach,in order to develop general security controls which arecommonly
applicable,the development of a security function for updating software/firmwaremodules located in IoT devices
is proposed.This security solution provides an initial securesoftware/firmwareupdate procedure based on the
secure software update procedure for ECUs (Electronic Control Units) in an ITS (IntelligentTransportation System)
which has been developed in an ITU-T (International Standardization Body) as proposed by authors of this paper.
Finally,a listof research topics for the IoT environment is provided for future collaborativeresearch.
Introduction
Methods:
Accordingto the current use-cases of IoT devices,we have recognized two major uses of IoT devices as follows:
Use-case-1: IoT devices are used and well controlled under the IoT based “services”such as lighting, parking,home
networking and so on. In this case,the owner of the IoTdevices is the serviceprovider and security controls should
be considered by the provider;
Use-case-2: IoT devices are purchased by individualsfor their own purposes such as health-care,home-network,
security-monitoring,and so on. In this case,the device owner is the individual who has basic responsibility for the
security.
In this paper, we basically focus on the Use-case-2. In addition to these use-cases above, we need to consider the
time-line of IoT devices in use as follows:
Time-line-a: IoT devices that are already in the market and in use (already shipped) and there aremany vulnerable
devices observed based on our previous findings [1];
Time-line-b: IoT devices that are going to be shipped by IoT vendors and in this case,there islittleroomto
implement security controls before shipping;
Time-line-c: the new types of IoT devices which are expected to be availablein about3 years.In this case,we will
not be ableto anticipatehow to use the IoT devices.
Based on the above use-cases of IoT devices (Use-case-1 and 2) and the Time-lines (a-c), the followingtwo
practical research approaches can beidentified in this paper:
Approach-1: By means of usingour previous work on IoT POT and IoT BOX, we firstly conductthe processes of
“Monitoring IoT devices”and “Analyzing IoT behaviors”.These two processes arecovered by the previous work
[1]. The next process can be identified as the “Execution of IoT security controls”for vulnera bleIoT devices and the
lastprocess is “Sharingknowledgeof IoT intelligence”to be utilized for future security management. In this paper,
we concentrate on the third process of the “Execution of IoT security controls”for IoT vulnerabledevices for Use-
case-2 and Time-line-a.

15. Approach-2: In order to develop general security controls which areapplicableto all in common, one example
could be the development of a security function for updatingsoftware/firmware modules located in the IoT
devices. This approach could beapplicablefor Use-case-2 (even for Use-case-1) and for Time-line-b and c. In this
paper, the security function of updating software/firmwarefor IoT devices is considered based on a similar
function developed for the ITS (IntelligentTransportation System) environment.
Results and discussion
Approach-1
Recognizing the current status where many vulnerableIoT devices arealready infected by several types of
malwares,methods to remove malwares from infected IoT devices,or to stop the activation of malwares (deletion
of registry,exe, or scheduler) areconsiderablesolutions in this approach.
More specifically,after identifying the “infected IoT device” by means of IoTPOT (Honey) and getting its IoTfinger-
printabout the infected IoT, the IoT finger-printinformation can then be forwarded from IoTPOT (Honey) to IoT
devices vendors or IoTintegrated maintenance centers as shown in Figure 1.
Figure 1. Scheme for curing IoT devices
In the scheme illustrated in Figure1, we basically consider a new entity of IoT devices vendors or IoTintegrated
maintenance centers. Becauseof the “illegal access protection law”established in many countries,the IoTPOT
never directly accesses theinfected IoT devices without permission obtained fromthe owner of the IoTdevices. It
is sometimes hard to obtain the permission of the IoT device owner who is an individual,becausethe device owner
sometimes has very poor awareness of the IoT device and poor security knowledge. IoT devices vendors can cure
the infected IoT devices for the purposeof maintenance of their own products (IoT devices). Furthermore, if the
device vendors don’t have the capability to cure the devices (e.g. because of the expense), then the IoT integrated
maintenance centers can be another solution to totally cover many types of IoT devices for the purposeof curing
the infected devices under contract with the IoT device vendors.
Consideringthe above scheme, we have started the testing to cure infected devices from remote in our own
experimental environment equipped with several types of IoT devices that are the same products observed by
IoTPOT. Accordingto current experimental results,itwas difficult to remove malwares in the infected IoT devices
without havingan agent software likeanti-virus-software,butit was possibleto stop activatingthe target
malwares by deleting the registry,the exe. File,or its scheduler and so on. As it was not feasiblefor IoT devices

16. vendors to deploy anti-virus-softwarein the IoT devices, therefore, curingthe IoT devices from the vendors or IoT
integrated maintenance centers was the feasiblesolution for this security control.
Approach-2
It is remarkablethat the number of IoT devices have been dramatically increasingand thus,hundreds of security
threats have been detected every day includingvulnerability identification for general ICTenvironments. It is
anticipated that the next market target of cyber-attacks (security threats) could be IoT environments. Considering
the above circumstances,the function of secure remote updating software and/or firmware insideIoTdevices
should be a major consideration in IoTmarkets.
In the ITS (IntelligentTransportation System), the above secure remote updatingfunction for ECUs (Electronic
Control Unit) in the vehiclewhich were similar to IoTdevices in terms of ITS environments have been understudy
and are being standardized on an international level.
In the context of the remote updatingfunction at the ITU-T (International Telecommunication Union –
Technology), the followingscopes of standards (Recommendation) have been identified [4]:
In the context of updates of software modules in the electric devices of vehicles in the intelligenttransportation
system (ITS) communication environment, this Recommendation aims to providea procedure of secure software
updatingfor ITS communication devices for the application layer in order to prevent threats such as tamperingof
and malicious intrusion to communication devices on vehicles.This includes a bas icmodel of software update, its
threat and risk analysis,security requirements and controls for software updates and a specification of abstract
data format of the update software module.
The procedure is intended to be applied to communication devices on ITS vehicles under vehicle-to-infrastructure
(V2I) communication by means of the Internet and/or ITS dedicated networks. The procedure can be practically
utilized by car manufacturers and ITS-related industries as a setof standard secureprocedures and security
controls.
Figure 2. Basic components for secure software updates

17. In this paper, as an initial consideration,wetried to apply the secure procedure developed by ITU-T for ECUs in the
ITS environment for the IoT software/firmware updating function. As shown in Figure2, the basic components for
the secure software update of ECUs in vehicles were “update server includinglogDB”, “Vehicle MobileGateway
(VMG, called Head Unit)” and a series of ECUs. Update information stored in the update servicewas provided by
the “Supplier of ECUs”.
In the caseof software/firmwareupdates for IoT devices,“IoT integrated maintenance centers and IoT devices
vendors” would have similar roles for the “Update service/Suppler of ECUs” in order to cure IoT devi ces in
Approach-1. “IoT devices” would be the same target component as for “ECUs”. At this point, it was not clear
whether the Gateway component for the IoT updating function was needed. Which was similarto “VMG” in the
caseof ITS.
Figure 3. Software update procedure for ITS
Before consideringthe IoT software/firmware update function, the ITS software update procedure (function)
needs to be learned in Figure 3 with the followingdescriptionsof each Steps.
1. At the firststep of the process,an update module is provided by an automotive component supplier,which
occurs asynchronously with the following
2. As the initiation of the update procedure starts,a vehiclemobile gateway (VMG) requests ECUs to submittheir
software list.
3. An ECU checks its software status,generates a listof software modules and reports it to the VMG.
4. The VMG submits the collected listto the update server to check whether any update for the vehicleexists.
5. The update server sends back a receipt of the submitted listto the VMG.
6. Accordingto the list,the update server inspects the status of the installed softwareof the vehicleand
determines the necessary software updates for the ECUs.

18. 7. Since this inspection may take a longtime, VMG periodically checks the necessity of the updates for the vehicle.
8. If there is any update, the update server sends an access uniformresourcelocators (URLs) for the updates;
otherwise, itsends back only an acknowledgement message.
9. If there is any update for the vehicle, the VMG connects to the update server to download the update modules
for the vehicle.
10. Before applyingthe updates to the ECUs, the VMG notifies the driver to confirmthe application of the updates.
11. The driver confirms and accepts to apply the updates.
12. VMG delivers the update files to the correspondingECUs and requests them to apply the updates (See 6.2.3).
13. Each ECU applies theupdate and reports the application resultto the vehiclemobilegateway.
14. The vehiclemobile gateway submits a report of the application results to the update server.
15. Finally theupdate server sends back a
• Receipt of the update information.If the
• Application of the update has failed or
• Some remainingupdate is found, the update
• Server retries the procedure from step 6 to
• 14 until the application has succeeded.
As the basic assumption for investigatingtheIoT software update procedure (function), the “IoT update handler”
in IoT devices should be basically implemented by IoT devices vendors in order to provide update functions for the
IoT devices. Based on the above software update procedure for the ITS environment,
we propose the followingsoftwareupdate procedure which can be simplified and adaptablefor IoTdevices as
follows:1. At the firststep of the process,an update module should be provided by an IoT devices vendor, and be
stored in the IoT integrated maintenance center/IoT devices vendors. The update occurs asynchronously with the
followingsteps.
2. We can eliminatestep-2 of the ITS for IoT update.
3. We can eliminatestep-3 of the ITS for IoT update.
4. The IoT device submits a status information concerningthe software/firmware implemented in the IoT device
to the “IoT integrated maintenance center/IoT devices vendors” askingto check whether any update for the IoT
device exists.
5. The “IoT integrated maintenance center/IoT devices vendors” sends back a receipt of the submitted status
information to the IoT device.
6. Accordingto the status information,the “IoT integrated maintenance center/IoT devices vendor” inspects the
status of the installed softwareof the IoT device and determines the necessary softwareupdates for the IoT
device.
7. We can eliminatestep-7 of the ITS for the IoT update.
8. If there is any update, the “IoT integrated maintenance center/IoT devices vendor” sends an access uniform
resourcelocators (URLs) for the updates; otherwise, itsends back only an acknowledgement message.

19. 9. If there is any update for the IoT device, the IoT device connects to the “IoT integrated maintenance center/ IoT
devices vendor” to download the update modules for the IoT device.
10. We can eliminatestep-10 of the ITS for the IoT updat 11. We can eliminatestep-11 of the ITS for the IoT
update.
12. We can eliminatestep-12 of the ITS for the IoT update.
13. The IoT device applies the update and reports the application resultto the “IoT integrated maintenance
center/IoT devices vendor”.
14. We can eliminatestep-14 of the IT’S for the IoT update.
15. Finally the“IoT integrated maintenance center/IoT devices vendor” sends back a receipt of the update
information.If the application of the update has failed or some remainingupdate is found, the “IoT integrated
maintenance center/IoT devices vendor” retries the procedure from step 6 to 13 until the application has
succeeded. It should be noted that number of retries should be defined in the policy statement provided by the IoT
device vendor.
Mobile ApplicationInterface
Thisdomaincoversdirectcommunicationbetweenmobile applicationsandadevice (e.g.,overWi-Fi or
Bluetooth).Thisdoesnotcoverindirectcommunications,suchasthose througha back-endservice.
1. Sensitive Data SecuredTest: Is all sensitive datasentbetweenthe device andmobileapplications
encrypted?
Impact: Withoutadequate protection,sensitivedatacan be monitoredbyattackerswiththe capability
to observe local networktraffic.
Thisattack can be avoidedwiththe use of encryptionorthe absence of messagesthatinclude sensitive
data.
2. TLS Certificate ValidationTest: If mobile applicationsemployTLS/SSL,dothose applicationsfollow
bestpracticesand properlyvalidatethe device’sTLScertificate (e.g.,throughcertificatepinning)?
Impact: The impropervalidationof certificatesallowsattackerswiththe capabilitytoperformaman-in-
the-middle attack,whichcouldgive themaccesstoall data sentbetweenthe applicationandthe
service.

20. Discussion and future research topics
Approaches-1 and -2 only providesecurity controls for reducingthe impactagainstinfected malwarein IoT devices
and for providinginitial updatesolution for the IoT device software/firmware update. However, the two
approaches do not cover the rest of security issues for IoTenvironments.
The followingfurther studies arerequired in connection with the two approaches in this paper:
A) Cyber-security information captured by our IoTPOT (honey) should be correctly and appropriately shared with
the right stakeholders includingresearchers for activecollaboration on IoTvulnerability analysis;
B) Remote curingmethod should be further investigated includingevaluation under the text-bed environment;
C) IoT software/firmware update function and procedures should be further practically evaluated through
experimental environments;
D) IoT security guidelines should bedeveloped and standardized for IoT device owners, IoT serviceproviders and
IoT device vendors. Furthermore, in addition to the above issues,the followingresearch topics should beshared
and investigated among researchers and experts:
E) Developing a generic IoT system model and reference architecture and investigatingthe management/
measurement of IoT security includingtheIoT risk assessmentmethod;
F) Another detection method of malwares,malfunctions and/or intrusionsfor IoTdevices (rather than using
IoTPOT);
G) Study of a light-weight crypto mechanismfor data confidentiality of IoT communications;
H) Appropriate Authentication and Access control utilized for IoT environments in a light-weight manner;
I) Incident handlingschemes for IoT environments includingthreats information sharing;
J) Depending on the generic IoT model, the roleof the Gateway function should be investigated includingGateway
security;
K) Issues related to Privacy and BigData under the IoT environment should be studied;
L) A secure design of application for IoTsystems should be also investigated.
The research topics listed aboveare the initial candidates of research for IoTdevices, IoT systems and IoT
environments in order to kick-off the research discussion regardingIoTissues.Themethod ofuse of IoT devices
and IoT system may differ in different regions such as in EU, US and Asia,however, the above research topics can
be generally applicablefor many regions with cross-region collaboration.

21. References
Pa Pa, YM, Suzuki, S, Yoshioka,K,Matsumoto, T, Kasama,T and Rossow,C 2015, ‘IoTPOT: Analysingthe Riseof IoT
Compromises’, 9th USENIX Workshop on Offensive Technologies (USENIX WOOT 2015)
Yoshioka,K 2016 IoT Security - Research Center for Information and Physical Security,Yokohama National
University,viewed 1 May 2016,<http://ipsr.ynu.ac.jp/iot/index.html>
Eto, M, Inoue, D, Song, J, Nakazato, Ohtaka, K and Nakao, K 2011,‘nicter: a large-scalenetwork incidentanalysis
system: casestudies for understandingthreat landscape’,BADGERS 11 Proc.FirstWorkshop Build.Anal.Datasets
Gather. Exp. Returns Secure
Eto, M and Nakao, K 2016 ‘Secure software update capability for intelligenttransportation systemcommunication
devices’ ITU-T draftRecommendation