SIPHON: Towards Scalable High-Interaction Physical Honeypots

3.4 MB·

by  Juan Guarnizo

SIPHON: Towards Scalable High-Interaction Physical
Honeypots
Juan Guarnizo*, Amit Tambe*, Suman Sankar Bhunia*, Mart´ın Ochoa*, Nils Tippenhauer*, Asaf
Shabtai** and Yuval Elovici*
{juan guarnizo, amit tambe, suman bhunia, martin ochoa, nils tippenhauer,
yuval elovici}@sutd.edu.sg, [email protected]
7
1 ABSTRACT of their sensors, and their behavior relies on that interac-
0
tion with the analog world. During the last decade, rapid
2 In recent years, the emerging Internet-of-Things (IoT) has
advancement in sensor fabrication and miniaturization has
led to rising concerns about the security of networked em-
n fueledthegrowthofthethings tremendously. Itisexpected
bedded devices. In this work, we focus on the adapta-
a thatbytheendof2016,6.4billionthings willbeconnected
tion of Honeypots for improving the security of IoTs. Low-
J
to the Internet, growing to 11.8 billion by 2018 [5].
interaction honeypots are used so far in the context of IoT.
2 IoThaspropelledtheusageofapplicationssuchassmart
Suchhoneypotsarelimitedandeasilydetectable,andthus,
1 wearable devices, intelligent transportation, and industrial
thereisaneedtofindwayshowtodevelophigh-interaction,
automation (among others). As a large number of things
reliable, IoT honeypots that will attract skilled attackers.
] arebeingusedordeployedcommercially,itisbecomingchal-
R Inthiswork,weproposetheSIPHONarchitecture—aScal-
lengingtoprovidesuitablesecuritymechanisms. Incorrectly
able high-Interaction Honeypot platform for IoT devices.
C
configuredthings willprovideopportunitiesforattackersto
OurarchitectureleveragesIoTdevicesthatarephysicallyat
. performmaliciousactivities,rangingfromsabotageofcriti-
s one location and are connected to the Internet through so-
c called wormholes distributed aroundthe world. The result- cal infrastructure to privacy violations. It is estimated that
[ by the year 2017, 90% of organizations that install IoT de-
ing architecture allows exposing few physical devices over a

2 largenumberofgeographicallydistributedIPaddresses. We vicesintheirpremiseswillsufferfromattackstotheirback-
end IT systems, stemming from vulnerabilities in IoT de-
v demonstratetheproposedarchitectureinalargescaleexper-
vices [6].
6 imentwith39wormholeinstancesin16citiesin9countries.
In fact, recent Distributed Denial of Service attacks on
4 Basedonthissetup,sixphysicalIPcameras,oneNVRand
core internet services such as DYN’s Managed DNS infras-
4 oneIPprinterarepresentedas85realIoTdevicesontheIn-
tructurewereperformedpartiallyusingIoTdevices(IPcam-
2 ternet,attractingadailytrafficof700MBforaperiodoftwo
eras)thathaddefaultorweakhard-codedpasswordsonTel-
0 months. A preliminary analysis of the collected traffic indi-
net and SSH interfaces [12].
. catesthatdevicesinsomecitiesattractedsignificantlymore
1 Therefore, there is a strong need to develop suitable and
traffic than others (ranging from 600 000 incoming TCP
0 cost efficient methods to find vulnerabilities in IoT devices,
connectionsforthemostpopulardestinationtolessthan50
7 inordertoaddressthembeforeattackerstakeadvantageof
000fortheleastpopular). Werecordedover400brute-force
1
them. In traditional IT security, Honeypots [7,29,30] are
: login attempts to the web-interface of our devices using a
v total of 1826 distinct credentials, from which 11 attempts commonly used to better understand the dynamic threat
Xi were successful. Moreover, we noted login attempts to Tel- landscape without exposing critical assets. Usually honey-
potsattempttomimicacertaininteractioninarealisticway
net and SSH ports some of which used credentials found in
r (such as a login shell), encouraging unsolicited connections
the recently disclosed Mirai malware.
a
and potentially encouraging attempts to perform (possibly
unknown) attacks.
Keywords
WithinthecontextofIoT,itischallengingtorealistically
InternetofThings,Low-InteractionHoneypot,High-Interaction mimictheinteractionofIoTdevices. Forinstance,consider
Honeypot, Wormholes, Scalability the case of IP cameras. In order to virtualize or simulate
their behaviour in a realistic way, one would need not only
tobroadcastsomevideotoanattacker,butalsoreactfaith-
1. INTRODUCTION
fullytocommandssuchastiltingthecameraorzoomingin.
The Internet of Things (IoT) has gained immense pop- Although not impossible, this requires a significant amount
ularity, creating a bridge between the physical world and oftechnicalworkthatcannotbeeasilyreusedformimicking
the Internet. According to the International Telecommu- differenttypesofIoTdevicesfromdifferentvendors,dueto
nications Union (ITU) specifications, IoT can be defined as the heterogeneity of such devices.
Internetconnectedphysicalobjectsorsensorswhichmaybe Ontheotherhand,sinceIoTdevicesaresensingandactu-
called as things [3]. This implies that, unlike conventional atingonthephysicalworld,theymighthaveadifferentper-
network nodes in the Internet such as servers or PCs, IoT ceived value to attackers depending on their location (e.g.,
devices have a stronger link to physical reality by means
different organizations or countries). This is similar to the 2. We propose an architecture for a high-interactive IoT
trend seen on the botnet underground market where com- honeypotusinglimitednumberofphysicalIoTdevices.
promised servers in different regions are rented at differ-
ent prices [18]. Therefore a Honeypot exposing IoT devices 3. Wepresentanimplementationofthatarchitecturebased
shouldideallyappeargeographicallydistributedtoattackers on seven devices presented as 85 distinct services on
interacting with it. the Internet.
Basedontherequirementsmentionedabove,aframework
for deploying IoT honeypots should: (1) be able to provide 4. Weanalyzecapturedtraffic,andshowthatgeographic
high-interactioninordertomotivateskilledattackerstoper- locations of our wormholes matter - attackers show
form their activity and expose the vulnerabilities they are more interest in some of the locations.
exploiting;(2)makeitpossibletoeasily“place”theIoTde-
We focus on high interaction distributed honeypot con-
vicesinawiderangeofgeographiclocations; and(3)easily
sisting of real IoT devices. That setup allows us to capture
scaletodevicesofmultiplevendorsandofdifferentkindsin
andanalyzetrafficandattacksacrossdifferentgeo-locations.
order to keep track of a dynamic threat landscape.
Tothebestofourknowledge,wearethefirsttoproposeand
Inthispaperweproposeanabstractarchitectureandin-
implement such an architecture.
sights on a prototype implementation of such a Honeypot,
Thisworkisorganizedasfollows. Thebackgroundofthis
that we call SIPHON. Our implementation allows us to de-
work is presented in Section 2. We propose the main archi-
ploy over 80 high-interactive devices with a diverse set of
tectureinSection3,anditsimplementationinSection4. We
IPs located in different regions of the world by using only
analyzeanddiscussthetrafficcollectedbyourimplementa-
sevenrealIoTdevicesinourlab. WeranSIPHONforape-
tioninSection5. RelatedworkissummarizedinSection6.
riod of two months gathering 20GB of raw traffic data. On
Finally, the paper is concluded in Section 7.
doingapreliminaryanalysisofthedata,wewereabletosee
thatinstancesindifferentcitiesreceivedsignificantlydiffer-
ent amounts of attention (in terms of connections and traf- 2. BACKGROUND
fic). Moreover,curioususersfromtheInternetattemptedto
A honeypot is an infrastructure commonly used to at-
brute-forcetheauthenticationofthedevices,gainingaccess
tract potential attackers to a controlled and monitored en-
totheadmininterfaceandinteractingwithdevicesinsome
vironment, without exposing critical assets, with the goal
cases.
of understanding the threat landscape at a given point in
Inparticular,wesummarizetheresearchproblemandour
time. Usually, it may consist of real or virtual systems [30]
contributions as follows.
that mimic production environments [34]. Interactions of
ProblemStatement. IoTdevicesofferarichsetofpoten- theattackerswiththehoneypotaretypicallymonitoredand
tialattackvectorstotheattacker. Ourgoalistolearnabout recorded for further analysis. Researchers can then design
existing and novel attack vectors on IoT devices. In partic- appropriate mitigation techniques for attacks after analyz-
ular,inthisworkwefocusongatheringunsolicitedtrafficto ingthetracescollectedbythehoneypot. Fromthepointof
IoT devices exposed to the Internet. Conventional honey- intrusionanalysts,“honeypotsprovideanotherindicationof
potsusevirtualizationorsimulationapproachestoreplicate wave of network attacks”[35].
the device under attack, and attract attackers. In the con- Honeypots may be set up in such a manner that they
textofIoT,replicatingthedeviceswithvirtualmachineswill will provide convincing fake information which may be de-
bechallenging. Onlyhighinteractionhoneypots(e.g.,allow- sirable to potential attackers, in order to attract their in-
ingauser tomoveacamera)willconvinceskilledattackers terest. Also, honeypots can help to redirect attackers to
to use advanced attack methods while exploiting zero-day a decoy system and thus indirectly protect critical systems
vulnerabilities. Themainquestionthatmotivatesthiswork or infrastructure from a possible compromise: if attackers
isHow can we construct a large scale honeypot consisting of are misled to think they are interacting with a real system,
high-interaction IoT devices? theyarewastingtimeandresourcestocausedamagetoreal
Approach. We propose the SIPHON architecture for scal- infrastructures.
ablehigh-interactionIoTHoneypots. Ourarchitectureuses Securityresearchersclassifyhoneypotsaseitherhigh-inte-
physicalIoTdevicesthatareconnectedtovariousgeograph- raction or low-interaction in accordance with the privileges
ical locations through so-called“wormholes”. The proposed enjoyed by the attackers and real vulnerabilities being ex-
architecture was implemented in a large scale distribution posed to them. In the following we briefly recap these two
with 85 instances in 16 cities, nine countries while using categories.
only five physical IP cameras, one NVR and one IP printer
2.1 Lowinteractionhoneypots
(i.e., seven IoT devices). In our implementation, network
traffic was forwarded leveraging an infrastructure of cloud Low-interactionhoneypotsemulatewell-knownvulnerable
serviceprovidersconsistingofAmazonEC2instances,Digi- networkservicesbypartiallyimplementingtheTCPandIP
talOceanandLinode. Wepreliminaryanalyzedthecollected stacks, in order to attract attackers. They do not give an
traffic and found insights in terms of amount of interest in attacker access to a real system, but rather to some sort of
variousgeographicallocationsandtypesofinteractionwith emulated system [13]. Since usually they do not run a fully
the devices. featured operating system, they are considered to be safer
in terms of remote exploitation. However, due to their sim-
Contributions. Thecontributionsofthispaperareasfol-
plicity, the main disadvantage of low-interaction honeypots
lows:
isthehigherlikelihoodofbeingdetectedasartificialbythe
1. Weexplaintheexpectedbenefitsfromahigh-interaction attacker,especiallyiftheattackerisahuman. Theattacker
IoT honeypot and define the design challenges. may find that the real services are emulated and services
areonlypartiallyimplemented,andthusloseinterest. Low- gets by attackers. Moreover, the Shodan API provides a
interaction honeypots are by construction not optimal to servicethattriestoestimateifadeviceexposedbyShodan
capture zero-day vulnerabilities, since by their nature such is a Honeypot or not. This service is called Honeyscore1,
vulnerabilities are unknown at the time of the deployment which is also accessible from the developer’s command line
of the honeypot, and thus cannot be simulated [31]. Low interface API of Shodan. The Honeyscore uses a heuristic
interaction honeypots can be used to detect a new wave of toclassifydevicesaspotentialhoneypots,givingascorebe-
attack for a very limited time until the honeypot is labeled tween 0 (likely not a honeypot) and 1 (likely a honeypot).
as such by attackers and dedicated search engines.
2.2 Highinteractionhoneypots
High interaction honeypots help to observe attacks in a
morerealisticsettingthanlow-interactionhoneypots. They
do not emulate any services, functionalities, or base oper-
ating systems. They thus allow to learn more about the
tools, tactics, and motives of the attacker, because they do
not restrict the attacker’s behavior in the way that a low-
interaction honeypot would [31]. As a result, high inter-
action honeypots are better suited to monitoring complex
interactions between the attackers and the system [13].
On the other hand, according to [13], there are disadvan-
tages to high-interaction honeypots. First they are usually
difficult and costly to deploy and maintain. Also they pose Figure 1: Example of a camera listed on Shodan (in
a higher security risk, since attackers can stop normal op- this case, one of our wormholes).
eration of the device after scaling their privileges and may
use the device at their will. If one is interested in exposing
many vulnerabilities that might depend on different hard- 3. SIPHON:ASCALABLEHIGH-INTERAC-
ware/softwareconfigurations(likevariousOSversionsetc.),
TIONPHYSICALHONEYPOT
alargeheterogeneousdeploymentofrealdevicesisrequired.
Last,althoughhigh-interactionhoneypotscaterformonitor- Inthissection,wepresentourdesignforSIPHON:aScal-
ingawiderangeofevents(suchasnetworktrafficandhost- ablehigh-InteractionPhysicalHONeypot. Westartbyout-
based activity such as system calls), this usually results in lining our attacker and system model, and then present the
a large number of logs, making security analysis more chal- abstract system design.
lenging.
3.1 ProblemStatement
2.3 Wormholes Our goal is to learn about existing and novel attack vec-
Inthecontextofwirelesscommunications,thetermworm- torsforIoTdevices. Inparticularwewanttousethewisdom
hole referstomaliciousforwardingofcommunicationbythe of the crowd of attackers in order to learn about the exis-
attacker[21],oftenthroughanout-of-bandchannel. Inpar- tenceofvulnerabilitiesthatarecommonlyexploited. Inthis
ticular,wormholescanbeusedtoinfluenceroutingschemes workwefocusongatheringunsolicitedtraffictoIoTdevices
in dynamic sensor networks [20], or to attack wireless key exposed to the Internet. Conventional honeypots use vir-
schemes for cars [14]. Wormholes are typically very chal- tualization or simulation approaches to replicate the device
lenging or impossible to detect [19]. under attack, and attract attackers. In the context of IoT,
In this work, we will use the term wormhole in a novel, replicating the devices with virtual machines will be chal-
but related way. Instead of offensive wormholes used by an lenging. Onlyhighinteractionhoneypots(e.g.,thoseallow-
attacker, our wormholes are defensively used by the honey- ingthe user tomovecameras)willallowtoconvince skilled
potoperator. Totheattacker,thepresenceofthewormhole attackers to use advanced attacks. The main question that
(and in particular the location of the other end) should be motivates this work is How can we construct a large scale
transparent. We discuss how to achieve that in Section 3. honeypotconsistingofalimitednumberofrealIoTdevices?
3.2 DesignConsiderations
2.4 Shodan
In the following, we assume that attackers are using the
Shodan[10]isasearchenginethatlistsIoTdevicesfound
Internet (and in particular Shodan [25]) to identify poten-
on the internet, including Industrial Control Systems (ICS)
tiallyvulnerableorunsecuredIoTdevicessuchaswebcams,
devices such as Programmable Logical Controllers (PLCs)
smart fridges or similar. Typically, the attacker starts with
and household devices such as IP cameras among others.
a reconnaissance phase, followed by an exploit phase. The
Figure 1 shows a device in our Honeypot found on Shodan
attacker could use either automated tools or manual inter-
that corresponds to the search for cameras in a specific lo-
action for either of those phases.
cation.
The devices under attack are assumed to be reachable
Shodan uses port scanning on internet IPs and analyzes
from the Internet directly (i.e. on public IP addresses).
the obtained responses to identify the type of device found.
They will expose one or more services on open ports. Such
Inaverage,ittakes1to2weeksforanewlydeployeddevice
servicescouldbeHTTP,telnet,SSH,oramorespecificpro-
to be listed by Shodan [10].
tocolsuchasRTSP.Thedeviceswillbeembeddedinareal
In the following, our hypothesis is that Shodan will be
used as the primary source of information on potential tar- 1https://honeyscore.shodan.io/
Storage & Wormholes For that reason, we propose to ensure that the worm-
Analysis Unit holes have public IP addresses that are localized in a range
of physical locations, ideally spanning multiple countries or
Attacker even continents.
That goal can be achieved in a number of ways. While
Device under Attack nowadays the IPv4 address space is becoming scarce [32],
Internet
the easiest way to obtain public IP addresses seems to be
Forwarder a) home users (who often get one IP per subscription line),
andb)serversonthecloud(cloudprovidersownlargeIPv4
Figure 2: Abstract overview of distributed physical address spaces). In this work, we focus on the latter (see
honeypot Section 4). To take advantage of public IP addresses of
home users, we also considered preparing devices such as
Raspberry PIs with a specific configuration as wormhole to
environment, i.e. the cameras will show live images, the
forwardtraffictothehoneypotforwarder. Thedisadvantage
fridgewillcontainrealfood,etc. Deviceswillbeconfigured
of that approach is the fact that such home setups would
withminimaleffort(i.e. potentiallywithdefaultpasswords).
likelyrequirethehomeusertosetupportforwardingonthe
Nodedicatedsecuritysolutionsarepresent(suchasfirewalls
homeNATdevice(oftencalledrouter inthatcontext). That
orIDS).IfthedevicesarereachablethroughaNATservice,
configurationeffortmightbenon-trivialformanyusers,and
then the exposed services are forwarded by the NAT.
thus we have not followed this implementation path.
3.3 DesignOverview
3.5 ForwardingMethod
Our design (see Figure 2) is based on real physical IoT
Thetunnelsbetweentheforwarderandthewormholescan
devices, that are exposed to the Internet through a large
berealizedusingarangeofdifferentforwardingtechniques.
number of tunnels that forward traffic from wormholes (re-
We now discuss a number of options that we considered.
motepublicIPaddresses)tothelocalphysicalIoTdevices.
Application-Layer Proxy. If the honeypot should repre-
Wormhole. The wormhole device presents a number of
sent only few selected services, it would be possible to use
open ports to the general Internet on a public IP address.
proxiesonthewormholesforthoseservices(E.g.,anHTTP
Incoming traffic on those ports is either logged locally, or
proxy like mitmproxy). There are a number of advantages
transparentlyforwardedtoaspecificportonaremotephysi-
of that approach, for example the option to cache static in-
calIoTdeviceviatheForwarderdevice. Thereareanumber
formation and thus reduce the traffic load on the DUAs.
of options on how this forwarding can be achieved, we dis-
cusstheminSection3.5. Morethanonephysicaldevicecan Encapsulation. On the transport and application layers,
beassociatedtoeachwormhole,buteachserviceforwarded services such as SSH and TLS can be used to encapsulate
will need a unique port on the wormhole. selected traffic with low configuration overhead. In our im-
plementation,wechoseanSSHtunnelasmethodtoforward
Forwarder. Theforwarderensuresthatthetrafficbetween
the traffic.
the wormhole and the IoT device is re-written in real-time
to hide the fact that devices are physically located some- Network-Layer VPN. A number of network-layer VPN
where else, or communicating with many other tunnels. If services are available (e.g., IPSec), a detailed comparison
required, the forwarder can also act as a TLS man-in-the- of which is out of scope here (we refer to [23]). Such ser-
middle because it will have access to the private keys of vicesmighthaveanadvantageoverselectiveforwardingus-
certificates used by the IoT devices. ingSSH,aslargenumbersofportscouldbeforwardedwith
little configuration.
Device under Attack (DUA). The local (IoT) device
under attack in the SIPHON architecture can be a normal 3.6 CompromiseDetectionandRestoration
commercial off-the shelf device. It will expose one or more
As the SIPHON architecture exposes real devices to the
services via the network, most likely over TCP. The device
attacker,itispossiblefortheattackertofullycompromisea
is able to maintain a number of concurrent connections at
deviceaspartofanattack. Oncecompromised,thedevices
any point in time.
couldbeusedtoattackotherdevices,thegeneralneighbor-
Storage&AnalysisUnit(SAU).TheSAUobtainstraf-
inginfrastructure,ordistributemalwaretootherattackers.
ficrecordsandgenerallogsfromthewormholes,andaggre-
There are several options to mitigate or prevent such sce-
gatesthedataforofflineanalysis. Forexample,therecorded
narios.
traffic can be analyzed by a suitable framework (e.g. Suri-
cata or Snort [8]). In addition, dedicated analysis frame- Periodic Reset. A simplistic approach to mitigate the
worksforotherhoneypotdeploymentscouldbeused(similar impact of compromised devices would be a setup that pe-
to [27]). riodically resets the configuration and firmware of all IoT
devices that are used in the lab. That approach has sev-
3.4 LocationofWormholes eral disadvantages (i.e. timeliness, completeness of reset).
On the other hand, it is easy to set up with some manual
As IoT devices are embedded in the physical world and
intervention.
interactwithit,ourhypothesisisthatthephysicallocation
of the device under attack is correlated to its attractive- IPS.IntrusionpreventionsystemsliketheopensourceSuri-
nesstotheattacker. Whilethedirectphysicallocationofa cata [8] could be used together with custom rules tailored
communicationpartnerontheInternetisnoteasytodeter- towards the IoT devices to prevent their ongoing compro-
mine [9], many services on the web provide IP geolocation mise. In addition, an IDS/IPS could be used to detect the
services (e.g., [17]). changed behavior of a compromised device to identify that
such a compromise has happened. Device Model Password Difficulty
Full instrumentation. The most reliable detection of a HP Pro Printer 6830 1234567890 Easy
compromisecouldbeachievedthroughlow-levelinstrumen- D-Link DCS-9050 password123 Easy
tation of the IoT devices, e.g. through JTAG or similar D-Link DCS-930L YAQvwrjy Hard
connections. The setup and maintenance of such instru- D-Link DCS-942L 1234567890 Easy
mentation is possible, but expected to be challenging and Aztech WIPC409HD admin Default
expensive [16]. Sineoji PT603V 9WgnTMxe Hard
Trendnet Emulator admin Easy
3.7 Scalability
HikVision NVR xDk2PKHU Hard
As we claim in the acronym SIPHON, the proposed ar- 7604NI-E1/4P
chitecture should be scalable. Our intuition for that is as
follows: for n physical IoT devices and m wormholes, the
numberofdevicespresentedtotheattacker,withoutexpos- Table 1: IoT Device Details
ing the same device twice in the same wormhole, can be
up to n∗m. For instance, if n = 100 and m = 1000 up
ports [26], we do not actively seek information on attacks
to 100,000 services could be exposed to the Internet. The
made on these ports. This is due to the following reasons:
numberofservicesperwormholeislimitedtoaround65,000
1)Telnet/SSHwouldnotprovideahigh-interactionenviron-
due to port numbering restrictions. The number of worm-
mentasanenvironmentthatenablesvideotransmissionvia
holesperphysicaldeviceislimitedbytheamountofparallel
HTTPandthereforewouldbelessinteresting2)Telnet/SSH
traffic that can be handled by each physical device. In our
wasalreadyexploredinthiscontextbyIoTPOT[27]3)None
practical implementation, we chose lower values for both n
oftheIoTdevicesusedbyushaveopenTelnetorSSHports
andmduetobudgetandspaceconstraintsaswewilldiscuss
in the following.
4. A DISTRIBUTED IP-CAMERA HONEY-
POT
In this section, we discuss an implementation of the pro-
posed SIPHON architecture for a specific class of IoT de-
vices: IP cameras used for home or public surveillance. We
chosethatclassofdevicesasthenumberofIPcamerascon-
nectedtotheInternetisincreasingdaily,andrecentresearch
findingshaveshownthattheIPcamerasandNetworkVideo
Recorder (NVR) are vulnerable to attacks [12,27],thus at-
tracting more unsolicited traffic than other IoT devices in
the market. In addition, IP cameras allow access to private
video, and often allow complex interactions with the user Figure 4: Example of device view through a worm-
(e.g. manual movement control). hole
Inourimplementation,locationsofthecamerasarespoofed
using wormholes based on instances in cloud services. The The devices in our lab were connected to cloud servers
instances are deployed in different cities around the world. from three different cloud service providers (viz. Amazon,
From the perspective of the attacker, the cameras are lo- LiNodeandDigitalOcean)invariouscities. Duringourex-
cated across cities (e.g., by using the location feature of periment, a total of thirty nine servers were deployed and
search engines such as Shodan). All traffic is directed from eachofthemhadadistinctpublicstaticIP.Eachofthecloud
the wormholes to our lab for in-depth analysis. servers was designated as a wormhole with up to three (3)
connected devices. The devices were connected on different
4.1 Implementation
ports of the cloud server. In total, 85 devices were visible
Figure3showsourprototypeinfrastructurefortheSIPHON to the attackers on the Internet, while only eight physical
deploymentwithIPcamerasandanetworkedvideorecorder deviceswereused,therebyyieldinginaverageabout10pos-
(NVR). Table 1 shows the list of devices used. sible virtual connections to each physical device. Shodan
By default, all the devices expose an administration web obtainedtheinformationaboutthedevicesusingdevicefin-
interface protected by a password. In order to attract com- gerprintingheuristicssuchasparsingtheHTTPresponseof
plexinteractionswiththedevices,weusedefaultpasswords the device and published the devices along with their geo-
for some of the cameras while we use weak passwords for locations, accessible ports and other useful information as
others. A screenshot of one of the HTTP interfaces of the illustrated in Figure 1.
camerasaftersuccessfulauthenticationisshowninFigure4. Eventually, all the traffic (i.e. device solicitations or at-
Using the administration web interfaces aligns well with tacks) was being diverted to the IP cameras or Network
our goal of capturing high interaction traffic. They provide VideoRecorders(NVR)inourlab. Alltrafficwascaptured
aptopportunitiestoexposetotheattacker,multipledevice using tcpdump on each of the wormhole servers and the re-
interaction scenarios, such as camera motion, wi-fi network sultingtraces(in.pcapformat)werestoredlocallyforoffline
scanning, etc. Even though more recent attacks, like the analysis.
one using Mirai malware, rely completely on the discovery
4.2 TechnicalSetupforTrafficForwarding
and exploitation of vulnerabilities via the Telnet and SSH
Rsync
Storage Unit Analysis Unit
Public Network
Internet
Forwarder
SSH
Tunnel
Periodic connections
Devices under attack Permanent connections

Example of completed virtual link
Figure 3: SIPHON prototype implementation in our lab
TheIoTdevicesareisolatedfromotherdevicesinthelab
through the use of 802.1Q VLANs. That ensures that even
compromised devices can at most interact with other IoT
devices, and the server.
4.3 LocationsofWormholes
For the attackers, the IoT devices are placed in the cities
where the actual wormhole is placed. Physically, the IoT
devices can be located in a common area together with the
forwarder.
Figure 6 shows the locations of honeypot deployment in
various cities in different continents around the world. The
SIPHONexperimentaldeploymentcoveredthefollowing16
cities in 9 different countries: a) USA (San Jose, Board-
man, Ashburn, New York, San Francisco, Dallas, Fremont,
Newark) b) Canada (Toronto) c) Europe (Frankfurt, Lon-
don,Dublin,Amsterdam)d)Asia(Singapore,Bangalore)e)
Figure 5: Setup of Cameras and NVR in Lab.
Australia (Sydney).
Our technical setup relies on a network gateway scheme,
as described abstractly in Figure 2. To implement the for-
warder,weusedalocalserverinourlabwhichmanagesthe
TCPconnectionsfromthewormholeinstancesinthecloud.
This server alone handles all m wormhole to n IoT devices
communications. The server itself is a VM guest with 1
virtual core and 4GB of RAM, running Ubuntu 16.04.
The connection between the forwarder and the cloud in-
stancesisestablishedwithreversesshtunnelsthatredirect
traffic of a specific port (i.e. port 80) on the wormhole to
a port in the forwarder. Once the traffic has reached the Figure 6: Prototype wormhole locations in cities
forwarder,wecompletethetrafficredirectiontotheIoTde- around the world.
vicesbymeansofthesocatlinuxcommand,whichalsofor-
wards the device’s responses to the cloud instance through Thissetuphadatotalcost(for39wormholeinstancesat
the forwarder. This process is easy to automatize by using threedifferentproviders)ofabout12USDperday. Wenote
adifferentlocalportintheforwarderforeachcloudreplica thatthesmallestinstancesizesareusuallysufficientforthe
of a physical device (wormhole). setup, which allows to keep the cost low.
4.4 Hidingthehoneypotcharacter vulnerable IP cameras.
Theliterature[31]definesdifferentdetectionmethodsde- Shodan Listing. Wespeculatedthatattackersmaytarget
ployed by attackers to detect the existence of honeypots. devices more after they get listed on Shodan. We look for
Such methods usually vary depending on the tool used to differences in the connection attempts before and after a
create the honeypot. For e.g. a honeypot created using the device gets listed on Shodan.
tool ‘Nepenthes’ can be detected using NMap (a network
High-interaction vs. Low-interaction. We conjecture
open port mapping tool). NMap is able to identify the ver-
that attackers might behave differently when exposed to a
sion of only one service amongst multiple services that are
lowinteractionimplementationofourdevices,forinstancea
running on a Nepenthes machine. On the other hand, a
cameraadministrationweb-servicethathasanidenticallook
honeypotcreatedusing‘Sebek’canbedetectedbydiscover-
and feel as the original, but shows a static image instead of
ingthememoryaddressesofthesystemcalls‘sys read’and
video.
‘sys write’ and ensuring that they are not more than 4096
In order to validate the points above, we take into ac-
bytesapartfromeachother. Usually,lowinteractionhoney-
count the following interaction factors. First, we want to
potsusetoolsthatpartiallymimicnetworkstacks(TCP/IP)
understand how many TCP connections we are receiving
to attract attackers by exposing vulnerable services. Such
perwormhole,andwhatkindofservicesarebeingconsulted
network stacks may be susceptible to well crafted packets
(SSH,ourHTTPportsetc.) Thisalreadyshedslightonhow
therebyrevealingtheexistenceofahoneypot. Also,bytheir
manywormholeshavebeendiscoveredandhowmuchatten-
verynaturehoneypotsbuiltusingvirtualmachinesaresub-
tion do they receive.
ject to timing attacks. For e.g. the timestamp in TCP
Next we are interested in understanding whether such
packets over different virtual machines hosted in the same
interactions are being performed using well-known scripts
physical machine can exhibit a similar skew over a period
based on the number of connections received per wormhole
oftimeincontrasttothesamesetupoverdifferentphysical
inshorttimeframes,thenumberofdifferentportsaccessed
machines [31].
by the same wormhole, as well as the user agent in HTTP
Although we have not yet fully explored ad-hoc attacks
sessions(forexample,inthecollectedtrafficweidentifiedthe
againstourinfrastructure,afterrunningourdistributedhon-
masscan agent [2]). Moreover, since to have access to our
eypot for a while, we checked whether its IP addresses are
devices’ admin interface an attacker needs to authenticate,
marked as“honeypot”by Shodan. During the experiment
we are interested in counting brute-force login attempts, to
run,ourIPaddressesweremostlynotdetectedashoneypot
count how many of those have been successful, and to fur-
byShodan(seeFigure1),inparticularthescorewegetfrom
ther investigate what happens after a successful login.
Honeyscore through the Shodan’s developer API ranges in
Tofurtherevaluateattackerattemptstogainaccesstoour
most cases from 0.0 to 0.5 (not honeypot), with an average
devices, we have assigned default, easy and hard passwords
scoreof0.16andonlyoneinstancewaslabelledasaHoney-
(Table 1). We can then, by analysing the HTTP responses
pot with confidence 0.8. The exact method how Shodan is
issuedaftersuccessfullogin,gatherstatisticsonmovements
detectinghoneypotsisunknowntous,butmostlikelyitisa
or zoom-ins on the cameras, scanning for WiFi networks (a
heuristic based on well-known open source honeypot tools.
feature often offered in the admin interfaces of IP cameras)
and more interestingly, firmware updates.
5. PRELIMINARYANALYSISOFTRAFFIC
5.2 High-interactionIPcamerahoneypot
In this section, we present the results of our analysis of
the traffic captured by our prototype. In particular, we fo- All the network traffic is collected and stored on a local
cus onthe followingaspects: a)whether the locationof the machine in our lab. We store the raw pcaps obtained with
wormhole matters to the attacker, b) whether some devices tcpdump, and then in order to perform the aforementioned
weremoreattractivetoattackersthanothersc)whetherbe- analysis, we parse the pcaps and store the basic features of
ing listed in Shodan had an impact in terms of unsolicited each TCP connection in an SQL database.
connections d) whether attackers would show different be- Distinct remote IPs. Uponanalyzingthemorethantwo
haviour when interacting with a low-interaction version of months’ worth of data, we observed incoming TCP connec-
our setup and e) the kind of interactions between the at- tions from over 13000 distinct remote IP addresses.
tacker and the devices.
Connections to wormhole per city. Based on the ge-
5.1 AnalysisGoals ographical distribution of our wormholes, we observed that
wormholesinsomecitiesreceivedmoreattentionthanworm-
Interests of attackers may vary depending on several fac-
holes in other cities. Figure 7 depicts the distribution of
torsasdiscussedabove. Inthiswork,thefollowinghypothe-
incoming TCP connections received by wormholes per city.
ses have been considered in this regard.
Thewormhole(s)inFrankfurtreceivedthemostconnections
Location. We conjectured that attackers prefer to invest (almost 600 000), while San Jose in US received the least
more time in certain cities to ascertain their targets than number of connections (about 50 000).
others. They search for devices in a particular city of their
Wormhole ports. However, we observed that most of the
interest and initiate interactions subsequently. This can be
incomingconnections(about97%)wereonport22(SSH)of
motivatedforinstancebyacommercialinterestoftheloca-
the wormholes, whereas HTTP ports like port 80 and port
tion’s IP for re-selling after infection (such as in the case of
8080receivedjust1.27%and1.12%oftotalconnectionsre-
botnets [18]), or as a starting point for targeted attacks.
spectively. Other HTTP ports which we had opened got a
Device type. We assumed that attackers target particu- mere 0.25% of the total incoming TCP connections. Fig-
lar models or device types that might have known vulner- ure 8 shows the distribution of incoming TCP connections
abilities. For example, attackers may particularly look for according to the wormhole ports.
Figure 9: Incoming connections according to their
Figure7: DistributionofTCPconnectionstoworm-
country of origin
holes according to their city
Figure 8: Connections to ports of wormholes
Figure 10: Incoming connections according to user
agents
Location of attackers. Although not a reliable indica-
tor (since attackers can easily tunnel through IPs located
anywhere in the world), we also gathered statistics on the attentionfromattackersduetoarecentreportinthemedia
location of remote IPs. We analyzed the origin of all the about the presence of vulnerabilities in its firmware [1].
incoming connections by country. Figure 9 shows the dis-
Brute force login attempts. We have setup the IoT de-
tribution of incoming TCP connections by their countries
vices with different levels of password difficulties (Table 1).
of origin. We saw that more than 70% of the connections
Weretainedthedefaultcredentialsforthewebinterfacelo-
originated in China followed by 8% connections originating
gin on some, while we modified the credentials on others.
in USA. Netherlands, France and other countries make up
We configured some cameras to have easy to guess pass-
the remaining list as shown in Figure 9.
words, whereas others were configured with hard to guess
User-agents used by attackers. Next, we enumerated passwords. Withthissetup,weobserved404bruteforceat-
the agents being used in the connections to our devices. In temptsonallthedevicescombinedfrom137distinctremote
Figure 10, usage of different user agents in incoming TCP IPs. We deem a login attempt as a brute force attempt if
connectionshasbeenshown. Mostoftheconnections(76%) the same remote IP tries to perform more than three login
were made using Mozilla as the user agent. Apart from attempts in an HTTP session. Of these 404 brute force at-
this,Chrome,PythonRequest,Wget(linux),Curl,Scanbot, tempts,weobservedatotalof11attemptssucceed. Allthe
Telesphoreo and Masscan [2] agents were used. Other user successful login attempts were on devices with easy pass-
agents were combined together into the ‘Others’ category words, and no login was recorded on a device with a hard
thatcontributed2.8%ofthetotalconnectionsandincluded password. We note that these easy passwords are present
IP Camera Viewer, Cam Finder, Morfeus F Scanner, Msqq in most of the dictionaries used by automated brute-force
agents, etc. Usage of Nmap was detected several times. To attacks. Ontheotherhand,thesepasswordscanbeguessed
top this, we also noticed around 9000 Shell shock attempts or brute forced easily even when attacking manually.
on our devices.
ImpactofdevicelistingonShodan
Attacked devices. In Figure 11, we depict the combined
amount of interest generated (based on HTTP traffic only) Anothergoalofthisanalysiswastoinvestigatetheimpactof
by the different physical devices. We observe that the ma- thelistingofawormholeonShodan. Wetriedtounderstand
jority of traffic was directed towards the DLink DCS-930L thisbycomputingthenumberofTCPconnectionsreceived
camera. We conjecture that this device attracted the most bywormholesbeforeandaftertheirShodanlistings. Shodan
devices. Weareinterestedingarneringknowledgeaboutat-
tackers’ behavior towards other IoT devices as well. There-
fore, we added another IoT device, the IP printer, to our
honeypot, for about four weeks. This IoT device was con-
nected to a cloud instance of Digital Ocean and located in
London. Thus, similar to the IP cameras, even though the
device was physically present in our lab, it appeared to be
located in London.
After analyzing four weeks’ worth of network traffic data
from the IP printer, we present our results.
Wormhole ports. We observed that most of the con-
nections (99%) were on port 22 (SSH) of the wormholes,
whereasport80(HTTP)receivedameager1%. Eveninthe
caseofIPcameras,weobservedthattheSSHportreceived
Figure 11: Traffic breakup for the devices more number of connections compared to HTTP ports.
Location of attackers. Similar to the observation in the
case of IP cameras, we noticed that the highest percentage
usuallytakesbetweenone-twoweekstoenlistanIPafterit
ofincomingconnectionstotheIPprinter(79%),originated
becomes live on the Internet. With respect to this, we took
in China. Taiwan was next with 11% of connections origi-
intoconsiderationoneweek’sworthofincomingconnections
nating in Taiwan. France, India, Kazakhstan, Netherlands,
before and after Shodan listing.
Ukraine and USA made up the remaining portions.
Brute force login attempts. We had changed the cre-
dentialsoftheIPprintertoapasswordthatshouldbeeasy
to guess (admin:1234567890). During our experiment, we
observed only one brute force login attempt. Similar to the
caseofIPcameras,wedeemaloginattemptasabruteforce
attempt if the same remote IP tries to perform more than
three login attempts in an HTTP session. A total of four
successfulloginattemptswerenoted,fromthreedistinctre-
mote IPs, all from China.
User-agentsusedbyattackers. SimilartothecaseofIP
cameras,wetriedtounderstandwhichdifferentuser-agents
wereusedintheconnectionstoIPprinter. Weobservedthat
all the four successful login attempts were made using the
Mozillauser-agent. UnlikeinthecaseofIPcameras,wedid
not notice a few user-agents (viz. cameraviewer, IPcamera
Figure 12: Impact of Shodan listing on no. of in- finder,Scanbot,MorfeusFscanner,Msqqetc.). Inaddition,
coming connections wedidnotnoticeanyShellshock attemptsontheIPprinter
either.
In Figure 12, we show the combined impact of Shodan
5.4 Lowinteractionhoneypot
listing for all wormholes. In particular, we show how many
average connections the wormholes attracted per week, be- One of our hypothesis for the low interaction honeypot
foreandafterthelisting. InFigure12,thetopbarrepresents is that most of the attacks are executed in an automated
theaveragenumberofconnectionsacrossallthewormholes manner using bots. We assume that these bots are not ca-
beforetheygetlistedonShodan. Thebarinthemiddlerep- pabletodistinguishbetweenrealandvirtualorfakedevices.
resents the average number of connections during the first So, these bots may conduct repeated attempts considering
week after getting listed on Shodan, while the bottom bar the device as a real one. In contrast, a human being will
representstheaveragenumberofconnectionsduringthefirst discover a fake device and will not make repeated attempts
twoweeksaftergettinglistedonShodan. Asurgeinincom- consequently.
ing connections is evident after listing on Shodan. We also We have implemented a low interaction honeypot using
observedthatthissurgeinconnectionscontinueseveninthe thesamemethodologiesasofthehighinteractionone. How-
secondweekafterShodanlisting,butisreducedinincrease. ever,insteadofarealphysicaldevice,weusedtheTrendnet
Thus,wecaninferthatthereisanimmediateimpactofthe camera emulator in the low interaction honeypot. Hence,
Shodanlisting,andattackerstrytocompromisethedevices this camera is a fake camera and not a real one. The entry
immediately after listing on Shodan. In the long term, the point (i.e. wormhole) to the low interaction honeypot has
number of incoming connections decreases. been created using an instance from cloud service provider
Linode, located in Singapore. Thereafter, we gathered data
5.3 OtherIoTdevices from the low interaction honeypot for almost six weeks.
The results from six weeks of data are now presented.
Sofar,wehaveusedonlyIP-camerasandanNVRinthe
Wormhole ports. We observed that most of the connec-
high interaction honeypot and gained knowledge about the
attackers’ behavior/interaction with them. But these de- tions to the fake camera i.e. Trendnet camera emulator
vices do not represent the entire spectrum of existing IoT (87%) were on port 22 (SSH) whereas HTTP Ports 8080
and 80 received 12% and 1% of the total incoming connec- traffic in the wormholes was directed to the ports exposing
tions respectively . In that respect, the behavior seen is thewebinterfaceofourIoTdevices. Attackersseemedmuch
consistent with the trends observed with the high interac- more interested in SSH connections, possibly because com-
tion honeypots. monautomatedattacktoolsaretailoredtore-flashfirmware
User-agents used by attackers. Similar to the corre- usingashell,whichisageneralapproachthatworksinmany
sponding observation in the case of high interaction hon- devices. Webelievethatthefirmwareupgradeattemptswe
eypot, we observed the maximum percentage of incoming received were performed manually, but we also think such
connections to be having the user-agent as various versions attacks will increase in the future as attack tools automa-
ofMozilla. Apartfromthat,theattackersalsousedWGET tize this process for different brands. It is also likely that
(Linux), python, masscan and Probethenet Scanner. All in the future access to SSH ports on many devices such as
theseuseragentswereobservedinthehighinteractionhon- home-cameraswillbemorerestricted,whereasaccesstothe
eypot as well. web-interface might be still desirable for convenience of ac-
cess.
Login attempts. We have noted three successful login at-
Additionally, one might argue that an IoT device con-
temptswiththedefaultcredentialsadmin:admin fromthree
nectedtotheInternetthroughanIPthatisownedbyAma-
distinctremoteIPs. Onesuccessfulloginattemptwasmade
zon is suspicious to start with. However, given the amount
each from China, Russia and Iran.
ofinterestreceivedintermsoftrafficandthefactthatthere
Wealsoobservedthattheattackersdidnotspendenough
were some (potentially manual) logins, we think that using
time to explore the device or its functionality. They spent
IPsbelongingtocloudservicesmightnotbeconsideredsus-
on an average only around 30 seconds in the low interac-
picious to a wide range of attackers. Indeed, the fact that
tion honeypot, compared to about one minute or even up
most of our wormholes are classified as not Honeypots by
to an hour in the case of real cameras. The time spent by
Shodan’s Honeyscore (score of 0.0), preliminarily indicates
the attacker exploring the device is calculated based on the
thatoursettingappearstoberealisticfromatechnicalpoint
timestamps of the first and last packets in the TCP session
of view.
captured via tcpdump. It is understood that the duration
Incidentallywenoticeatleastother6cloudinstancesex-
of a session is correlated to human intervention. session
posing cameras to Shodan. All of those instances had a
time will be longer when the attacker will try to explore
Honeypot score of 0.5, which in principle makes them more
functionality of the device. Human beings can easily dis-
suspiciousthanourset-up,butindicatespotentiallythatei-
tinguish between a still image and a streaming video unlike
ther such a setting is not uncommon (if not honeypot), or
automated bots. Thus, we can more easily determine man-
that other people have been less stealthy in their Honeypot
ualattacksusingthislowinteractionhoneypotcomparedto
setup than us.
our earlier high interaction honeypot.
5.5 Discussionandcommentsonvalidity 6. RELATEDWORK
By analyzing the traffic, we see that our proposed archi- Honeypotsareacommonmeasuretounderstandattacker
tecture was successful in attracting a high number of con- activitiesincomputernetworks. Theauthorsof[13]provide
nections,whichconfirmsouroveralldesign. Inaddition,we ataxonomyofhoneypots,anddifferentiatebetweenlowand
were able to observe interesting interactions in our prelim- high interaction honeypots. Both low and high interaction
inary analysis of the gathered data. We note that in our honeypots are compared in [7], and the authors conclude
analysis, we assume that interaction between the attacker that high interaction honeypots provide more insights on
and IoT device over HTTP is more likely performed by hu- attacker behavior than low interaction ones.
mans than scripts, since interaction with unknown HTTP The Honeynet Project [34] is a well-established project
interfacesishardertoautomate[27]. Ourprototypeisthus that focuses on monitoring and analyzing attacks to com-
apromisingfirststeptowardseffectivelylearningthethreat plement intrusion detection tools. The Honeynet project
landscape in IoT security. does not use emulation, and instead leverages real systems
Weareawareofseveralissueswithourcurrentprototype. and applications. For that reason, the Honeynet project is
First, one might argue that an intelligent attacker can spot an example of high interaction honeypots.
our honeypot in different ways. For example, the attacker In [15], the authors describe honeynets that can be used
can detect that two wormholes represent the same physical to increase security in a large computer network. In short,
devicebysimultaneouslyloggingintothesamedevicesfrom honeynets are clusters of honeypots.
twodifferentwormholes. Weacknowledgethisshortcoming, Alowinteractionhoneypotsystemisimplementedin[22].
butnotethatduringourexperiment,ourdataindicatesthat The honeypot monitors behaviors and learns the advanced
atleastnosingleIPhasdiscoveredallthewormholesandthe attacksthatmaynotbedetectedbyIDStools. Thesession
majority only interacted with a small subset (typically 5 or of the attacker is redirected to the honeypot system, which
less). Theissuecanalsobemitigatedbyhavingonedifferent thenservesrequestsfromtheattacker. Forthatpurpose,the
physical device per wormhole. Since we were interested in authors provided service daemons and a fake shell so that
comparingdifferentlocations,wedecidedtoscalethesystem theattackerisnotabletodiscoverthesystemashoneypot.
in a 1 to n fashion instead of a bijective relation between In[4],theDecoyPort systemwasproposedwhichredirects
devices and wormholes. attackers towards honeypots. The system creates Decoy-
Comparedtorelatedworksuchas[27],wehavesofarob- Ports onactivecomputers,thoseportsarenotusedbyreal
served very few attempts to upgrade the firmware, which is services. Wheneveranyqueryorrequestcomestotheports,
a very common objective of attackers who want to spread the system diverts the same to the honeypot. The system
botnets or malware. We conjecture a possible explanation does not only act as a port forwarder but also is capable
forthisasfollows. Wehavenoticedthatonlytheminorityof of controlling network loads caused by attackers. With this