start	end	text
0	4740	One welcome to DEF CON Safe Mode, from crazy Vegas parties last year to me
4740	8280	sitting alone in my room right now and sipping vodka in 2020.
8560	13140	Wow, it's been a crazy year. But it's literally like Vegas in my house right now,
13140	18900	because cocktails are acceptable at any hour, and I have no idea what time of the day it is.
19020	23240	Things have changed drastically. In this time when everything is getting cancelled,
23240	27520	I'm so delighted that at least we still have DEF CON. Welcome to the new normal.
27520	33160	Thanks for joining in. Before we start, we would like to add a disclaimer that all content over
33160	39520	here is specifically for demonstration purposes, and everything is informative, and we have performed
39520	45500	all of it on demo environments. Now, before moving ahead, we would like to introduce ourselves.
45500	50640	So, just a little bit about us. My name is Devan Kwan, and I work as a security consultant with
50640	56660	the NCC group. I have multiple areas of interest, but the most recent one being IoT and radio
56660	61820	hacking. I have also contributed in the development of NICE, that is non-intrusive confidence engine
61820	67100	for multi-factor authentication mechanism, and I am also working on instant messaging and secret
67100	72620	storage protocol. It is the first talk that I have ever given, and therefore, just a heads up to you
72620	78880	guys. The talk would be pretty business friendly, and we'd go over a lot of basic topics as well.
78900	84020	Now, passing on to my co-presenter. Thank you, Devan. Hello, everyone. My name is Shruti
84020	91200	I'm a computer scientist working in IoT research and development at Nexus in France. I have three
91200	96720	plus years of experience in IoT development for smart home, autonomous vehicles, indoor and
96720	102520	virtual locations, precisely. I have previously contributed to some international projects like
102520	108760	Inakreshi, and I'm also part of Hall of Fame for my contribution to the development of end-to-end
108760	114880	IoT platform, which is a leading research institute in Europe. I'm also an independent
114880	119640	researcher. I'm very passionate about IoT development, secure smart system, teaching,
119640	125680	and women empowerment. Well, now moving on to the agenda for our talk today, we will begin with the
125680	131120	idea of connected world, and how it all started. It's like a very boring history, including
131120	135840	introduction for our talk. Well, it will be followed by the section discussing its security
135840	141300	parameters. We will see how unaware we are surrounded with billions of devices with some
141300	146740	stats, and then we will move to the section of attacks and expedition scenario, where we will
146740	152860	be understanding a few basic concepts prior to our main demonstration. We will also cover some tools
153500	158860	during this demonstration, and later discuss the crucial points, stating how we can protect our
158860	165460	smart world from those discussed attacks, be it an organization, developer, or project designer.
165460	171640	Well, lastly, we will go over the demonstration, and we will demonstrate a small tool that we have
171640	177740	developed, which can be very useful in protecting IoT consumers, or making them aware of any attacks
177740	183820	they might be unknowingly facing on the connected world. Well, our connected world. Okay, so are you
183820	191580	telling me that anyone on the internet can talk to my fridge? Well, today in an era of COVID-19
191580	196760	pandemic, we all are working from home, aiming to stay connected worldwide during the time of
196760	202660	social isolation. Even including this talk, completely online, and where we are missing the
202660	208120	real interaction with the crowd and nervousness in the presenters like us. Although we are really
208120	214160	nervous, but thanks to internet of things, from wearable devices and portable technologies to
214160	220580	health-related accessories, IoT is everywhere. It has shifted from a futuristic concept to the
220580	227720	central focus area of every industry, ranging from manufacturing and retail to healthcare and real estate.
228340	235600	But the question is how exactly it all started. The internet of things emerged as the largest
235600	241780	digital mega trend, bridging the physical and visual worlds with the fourth industrial revolution,
241780	248140	or to say, industry 4.0. From the first revolution, triggered by the construction of railways, we are
248140	254660	now aiming for increasing the networking of people, machines, and objects over the internet.
254660	259540	We understand that internet of things is basically a network of things, which are simply any objects
259540	266460	like devices, vehicles, or embedded items in electronics, with the only target of achieving
266460	273040	connectivity to enable connection and exchange of data between the things to make our lives simpler.
273040	278960	Showcasing its talent, IoT has fascinated things from eating unbotted coffee to turning off the
278960	285080	lights when we go to sleep at night. I swear to God, that thing has made me so lazy.
285760	290620	This is the reason why dependability has been exponentially increasing. Just like the
290620	296820	COVID graph, from one million down to the expected 50.1 billion in 2020, there is a
296820	302920	massive explosion in the usage of IoT devices. From smart homes, smart healthcare, smart city,
303040	308160	and what not, we want everything to be smarter now. And this means,
309460	312780	I literally have no idea how to even say this number right.
313780	319260	But moving on to how safe my world is, I'll pass on to you, Devang.
319260	325900	All right. So, what if I just tell you that the S in IoT actually stands for security? Yes, that is
325900	332180	true. So, talking about how safe my world is, with billions of devices connecting the whole world,
332180	337140	we care a lot about functioning, right? We want things to be done in just one click. We want
337140	343060	things faster with less or almost no effort. Better be functioning soon, be click to buy in
343060	348660	Amazon, Alibaba, or wherever you guys shop. But we need to understand that there's a need for
348660	354560	security on so many levels. So, we should first look and compare the threat models in terms of
354560	361800	classic web applications and then in terms of IoT devices. Over here, we see a simple web app
361800	367340	server connecting to a SQL database. Then we have a third party web service and cloud storage.
367340	372680	They all have their own corporate trust boundary and vendor trust boundary. And then we talk about
372680	378920	the human user. The human user is actually directly interacting with the web application.
378920	384840	And then they all are being separated by separate privileged levels and their own trust boundaries.
385160	390240	So, as you can see, definitely in no way I'm saying that web applications are extremely similar.
390240	395360	Trust me, I would never say that. They can definitely and more certainly are more complex
395360	401080	than the basic diagram which I'm showing here. However, we get more clarity when I try to compare
401080	407880	it to a simple IoT implementation. All right. So, in this next diagram. So, as you can see over here,
407880	413000	in this IoT threat model, this is like a very simple IoT architecture. I'm not even going into
413000	418340	more complex ones. We aren't even talking about embedded devices and airplanes and the complex
418340	423700	architectures. We're literally talking about a very simple architecture here. Specifically focusing
423700	430480	only on smart and connected forms. I would say these are more of consumer IoT and less of enterprise
430480	438520	IoT. So, in this case, what we are looking at is a connected user. So, a connected user is basically
438800	444220	a user who is interacting with their smart device. Then in this case, we have segregated the network
444220	452140	into separate sections. So, as you can see, we have proximity network. So, in a proximity network,
452140	457220	you're considering to have physical. So, we basically consider a proximity network to have
457220	464120	physical sensors, devices, and the IoT gateway itself. So, basically, that would generally be
464980	471280	inside your house. Then devices are connected to the proximity network by let's say a smart ring,
471280	476480	which the user might wear, or any smart device which the user might have in their home.
476480	481360	Then apart from that, the user also interacts with the mobile app. So, a user basically has
481360	487560	two avenues over here. One is in some cases to directly interact with the embedded sensor
487560	493820	of their smart watch or device. And then another one is the mobile app or any web interface.
494020	499940	Apart from that proximity network, we also talk about the cloud network. However, for IoT devices,
499940	506060	prior to going to cloud, we also have to consider edge servers, as that is what separates them from
506060	512320	most of the classic web app. IoT's preferred microservices architecture compared to most
512320	518060	monolithic standard apps. Edge servers decreases the overall latency and increases the device
518060	523380	efficiency. However, it might add some more attack surfaces in the overall architecture.
523380	527920	Let's just talk about a couple of attack scenarios over here now. So, you can see that in the
527920	534820	proximity network, where the devices communicate over BLE, CoAP, LoRaWAN, as these are close-range
534820	539220	protocols and the devices are in proximity. Therefore, in proximity network, our main
539220	544280	threat actors are generally the pre-installed malicious IoT devices, as they might try to
544280	549960	replay or intercept the existing traffic. They might also exfiltrate that traffic out through
549960	556640	the IoT gateway. Okay, now moving on to the mobile interface, we might have more attack surfaces,
556640	563940	like, let's say, a malicious application on the user's device, which might try to
563940	568740	directly interact with the device file system and processes in order to extract sensitive
568740	576660	user-specific data from the IoT device application. Okay, so let me just come back to this. So, the
576660	582140	main purpose to show this threat model here is that, generally, when we consider IoT threat models,
582140	587120	we tend to focus on external threat actors, like an attacker compromising third-party cloud
587120	593520	services, or like a malicious app on the device, or like a malicious IoT device in the home system.
593520	598200	So, basically, when talking about IoT, these are the attack surfaces we most care about.
598300	604220	But what about the attack surfaces that we least care about? What about those benign users on your
604220	610880	home network, who exist on your home network, who also have updated operating systems, who have
610880	616280	updated browser versions, and they're just casually running JavaScript? All right. So, in terms of
616280	620580	IoT devices, specifically for connected home devices, a common pattern has been noticed that
620580	626180	the device manufacturers tend to give the least priority to device security on local area network.
626220	631380	As the devices are not directly accessible to the external network, therefore, it is generally
631380	636600	assumed to be secure without physical access. As in most cases, the designers just consider that
636600	642120	physical access to be the only possible gateway to the private network. That is why these devices
642120	647700	have a variety of open ports and unauthenticated HTTP interfaces running on them, which can be
647700	653060	directly controlled by anyone who is present on the home network. The best example of this was
653060	662020	Google Home's unauthenticated HTTP API, which was literally patched in 2019. And it gave anyone on
662020	667480	the local network to perform multiple actions, like rebooting the device or making any sort of
667480	672380	modifications, which a normal user could have. When talking about this particular attack surface,
672380	676820	it is considered that if an attacker has physical access to the device, then the network-based
676820	684360	attack is among the lowest concern. And physical attacker access might open up some other serious
684360	691900	concerns. So, this one is given less priority. However, what if this was not the only attack
691900	698340	tree for the exploitation of these HTTP interfaces? All an attacker needs is a single
698340	703600	public gateway to break into the private network. For a long time, home private networks have been
703600	709700	pretty secure, as not everyone is running servers on their local host. Let's just be honest about
709700	717480	that for a minute. Apart from developers and other people, not everybody is running or hosting an
717480	724020	application on their local host networks. However, with the advent of IoT technology,
724020	730200	IoT has literally given an exponential rise to a variety of web interfaces running on users'
730200	736380	private network. In most cases, the user is totally unaware of all the accessible IPs and
736380	742080	even open ports on their devices. The question is, what if an attacker was able to proxy into
742080	747160	the private network through a public gate? Now moving ahead to our next section, attacks and
747160	753500	exfiltration scenario. We would first like you all to do a very simple exercise. I'd like you all to
753500	759440	fire up your terminal and make a simple request, that is, perform this following NSLOOKUP.
760460	767060	Now, if it returns a local IP, then there is a very high chance that you might be vulnerable to
767060	772580	DNS rewiring attacks. Now look at what exactly the attack looks like.
772580	776520	But for that, we need a quick refresher of how exactly DNS works.
778040	783500	Well, we all know that a DNS is like an address directory of the internet.
783500	791260	It translates the domain name like facebook.com, google.com to IP addresses. So browsers can load
791260	796860	internet resources. These IP addresses are given to each device on the internet and they are
796860	802300	necessary to find appropriate internet device. It's like a street address is used for a particular
802300	808500	home, you know, to find that particular home in that particular location. So to understand how
808500	814080	this translation is done, let us imagine a situation where a user is trying to access a
814080	819020	website called shop-example.com because, you know, she's bored in this quarantine and
819020	826400	wants to shop at least. So as a user types shop-example.com into a web browser, the query
826400	833340	will traverse into the internet asking what is the IP address of shop-example.com and will be
833340	841120	received by a DNS recursive resolver. Well, the next step is that if the recursive resolver has
841120	847320	no answer, then the request will be passed on to the DNS root name server asking the same question
847320	854280	at what is the IP address of shop-example.com. The root server will then respond with the address
854280	862940	of a TLD. TLD is top-level domain server like .com or .net which stores the information for its
862940	868740	domain. In this case, it will be .com. Once the address of TLD is received, the resolver then
868740	875380	makes a request to the .com TLD. The TLD server will behave like a root server. I know this guy,
875380	881460	you might know this guy and will respond with the IP address of the domain's main server. The
881460	887760	recursive resolver then asks the domain main server where is the shop-example.com and then
887760	895320	finally the main server will return the IP address of shop-example.com to the resolver with TLD.
895780	901260	And lastly, the user's browser will have the requested IP address. Now the browser knows the
901260	906780	IP address of the website, it is able to make the request for the shop-example.com as the
906780	912080	request is offered, for instance, where the web server on the receiving the request will actually
912080	918660	respond with that requested web page, you know, like 60% off. Wow, who doesn't like that?
918720	924660	Well, we saw the complete flow to understand how DNS works. Instead of going through all this
924660	930100	way and to improve the performance and reliability of data requests, this information is temporarily
930100	936700	stored in the locations like browser, operating system, or recursive resolver. This is all DNS
936700	942500	caching and the set amount of time for storing is known as time to live, in short TTL, as I said
942500	950780	before. Well, let's take another situation into consideration. Okay, so I just, from the previous
950780	956480	slide, I'd just like to focus on one thing, time to live. Please make a note of it, it'll be useful
956480	962160	later. So, let's take another situation into consideration. Let's say that the user is trying
962160	968240	to access some web page and there are some annoying ads on the web page. Among those, there is one
968240	973860	malicious ad waiting for the user's attention. Since this ad has to be loaded from another domain,
973860	978820	our browser has to fetch it. But loading a random JavaScript from some random domain will give the
978820	984120	attacker access to load anything in our browser and authority to make requests to maybe our
984120	991680	bank.com or access pages for, let's say, maybe from our smartphone devices. But you know what?
991680	998160	There is something called same origin policy, which is actually a policy implemented by the
998160	1004440	browsers and which let the browser restrict this kind of behavior as they restrict and limit any
1004440	1011520	sort of HTTP request which originates from one domain to access resources that are hosted on
1011520	1017880	or served on another domain. So, to be specific, let's see an example. Okay. So, let's take a quick
1017880	1022960	look at an example of how the same origin policy is able to protect resources from being accessed
1022960	1027880	by malicious JavaScript running on websites across origins. So, in this example, we have a secrets
1027880	1034880	file that is secrets.txt, which is located at test instance running on port 8053 that is accessible
1034880	1039340	over HTTP. And we will see how the same origin policy can protect this resource from being
1039340	1043900	accessed by malicious JavaScript running on a malicious origin. In this case, we are considering
1043900	1051220	example.com to be that malicious origin. So, when we try to perform an XHR request. So, in the first
1051220	1057280	example, it is of a totally different origin because here the host, that is example.com, as well as the
1057280	1074340	port is totally different from the test instance. Okay. So, here you can see that the browser's
1074340	1078460	same origin policy was able to block the malicious website from accessing the resource. As it said,
1078460	1084420	they do not have the same origin due to them having totally different host as well as port. Okay.
1084420	1091740	Now, we'll be looking at a different example. So, in this particular example, these two resources have
1091740	1098840	the same host, that is testinstance.com. But they happen to have this totally different
1098840	1106020	port numbers. One, the secrets was actually on 8053, whereas this resource is on 8056.
1106020	1115580	And we can observe that. Okay. And in this case, when we try to perform a XML HTTP request,
1115580	1124480	or basically a cross-site JavaScript fetch, we'll be able to see. Okay. So,
1124480	1129100	as these two happen to have different port numbers, although they have the same
1129100	1137860	host, the resource is still not able to access the secrets.txt, because the browser still
1137860	1143480	considers this to be a totally different origin, because of them having totally different ports.
1143480	1150760	Now, we will look at a standard example. This page is testinstance.com, and it has the same
1150760	1157560	8053 port as our secret. So, this happened to match all the criteria that is required for
1159160	1164560	a same origin, right? Then, in that case, we'll just try to see how exactly the same
1164560	1173080	origin policy would allow this one to access the secret. So, in this case, as you can see,
1173080	1180120	this was able to pass the same origin policy due to exactly the same host, the same protocol,
1180120	1183860	as well as the same port number, because of which it was able to access the resource
1184640	1192480	which was hosted, which was actually located at secrets.txt. So, that basically sums up the
1192480	1199540	example of same origin policy. So, the question that arises here is, if SOP is actually preventing
1199540	1208060	this kind of attack, then what is the threat? Well, DNS rewinding. DNS rewinding is a class
1208060	1213260	of exploit in which the attacker initiates repeated DNS queries to a domain under their
1213260	1219420	control. Consider the scenario where the user is comfortably surfing over the internet to access
1219700	1225000	a web page containing some advertisement. Among those ads, there is one malicious ad,
1225000	1230980	as Ivan stated before. As the web page is loaded, the browser will request the malicious DNS server
1230980	1237820	querying the IP address of maliciousads.com. When receiving this request, the attacker-controlled
1237820	1246600	DNS server responds with the real IP, let's say 1.2.3.4, and it also sets the TTL value
1246600	1253560	on the response to be zero minutes or a few seconds, so that the user's machine won't cache
1253560	1260460	for long. Now, let's wait for some time. Now, the malicious JavaScript makes another request
1260460	1267740	to maliciousads.com. And since the TTL is exceeded, the IP of maliciousads.com isn't found in the
1267740	1275340	cache. Therefore, the browser will again request the IP from the DNS server. But what? Wait!
1275340	1282680	This time, on the user's subsequent DNS request, instead of the real IP, the maliciousads.com,
1282680	1292380	the name server of maliciousads.com, will respond with the IP of 10.0.0.1, which happens to be an
1292380	1296980	IP within the user's local space and belongs to an IoT device on the user's network.
1297740	1303880	The user's browser will receive this malicious DNS response and will use this provided IP to
1303880	1310280	make HTTP requests, which were intended for maliciousads.com. Because technically,
1310280	1314640	there is no change for the browser according to the normal functioning. Because based on
1314640	1321160	SOP, browser just sees the same name and goes, oh, we have the same name. So we are friends
1321880	1329080	and allows all queries from the same origin, irrespective of the IPs. But the HTTP requests
1329080	1334400	are now sent to the small unprotected web server running on the user's component.
1334400	1340120	The same network where all your smart devices are connected and that's making your smart home
1340120	1346100	unsafe. And that's behaving as a proxy between your private and public world. DNS rebinding
1346100	1352520	attack can actually bypass network firewalls, security controls, such as false and make
1352520	1358240	every device on your local network vulnerable and available to an attacker from anywhere
1358240	1364740	outside your protected internet. Let us do theoretically. Now it's time to hack.
1364740	1368400	Okay. So in this example, the first thing that we'll be talking about is a router interface
1368400	1372440	that allows anyone on the network to access the router controls once they have authenticated.
1372440	1375800	However, even prior to the authentication, this allows users on the home network to access the
1375800	1381140	list of all the connected devices. So let's see how a user on this private network can become
1381140	1384900	vulnerable to the DNS rebinding attack by just navigating to a website that looks totally benign.
1384900	1388920	In this case, cute videos. Because you know what? Who does not like cute animals?
1389200	1394240	So as you can see in the developer options in the network request, you can see even before
1394240	1398680	the page was loaded, the malicious host on the page initiated a port scan in the local network
1398680	1403200	in order to identify the router interface. Router is an easily identifiable target in most of the
1403200	1407640	because standard IP of their default gateways and therefore it is easy to scan
1407640	1412920	compared to other devices. So here it has already identified 10.0.0.2.
1413080	1418420	And now automatically it has started sending the JavaScript on the page has already started
1418420	1426160	sending multiple requests from the page to the external URL. And now this page is basically just
1426160	1431600	waiting for the DNS to be DNS records to be updated. So this video is already 11 minutes
1431600	1438800	long. And that's like already enough time for an attacker to perform the DNS rewinding attack.
1438800	1445360	So by the time the attacker so by the time you're even watching first 20 seconds of the video,
1445360	1452600	the attacker has already been able to rewind and has been sent internal request to 10.0.0.2.
1452600	1458540	And now we'll move to the attackers panel. So here you can see a WebSocket connection has been
1458540	1465740	made based on which the attacker would be able to actually access things on the internal network.
1465740	1470920	So now you can see the remote address has been updated from the attacker's IP address to the
1470920	1475540	internal IP address. And based on that, the attacker is now able to any request that has
1475540	1481800	been performed to the origin by the JavaScript is actually helping the attacker to communicate
1481800	1487840	with the internal services that is running on your router. So now we'll just try some generic
1487840	1492120	passwords. Oh, in this case, we just tried admin admin and that definitely worked because
1492940	1497900	a lot of routers, whether we want to accept it or not, are still working on default passwords.
1497900	1504700	So this gives any attacker multiple functionalities like setting the functionality
1504700	1511240	of the router, modifying passwords, and this also allows them to enable UPnP, which might
1511240	1516320	make them vulnerable to multiple other vulnerabilities apart from this. It also allows the attacker to
1517000	1523380	remotely reset or reboot the device. Also, it gives an attacker full functionality to modify
1523380	1528520	your DNS servers and thus serving you all the malicious websites that they want to.
1528520	1533360	Also, they can just proxy your entire network and that would help them to take over other
1533360	1541420	multiple devices on your network as well. So that would be, in short, pretty bad. And over here,
1541420	1546800	you can see all those requests. So in this case, password update page that was being
1546800	1552160	fetched by the attacker. So all these requests were actually being made to the external attacker's
1552160	1558900	origin. However, the remote address was routed to 10.0.0.2, which was the router's IP. So by
1558900	1565200	the time you're busy watching the cute dog, your entire router and the network has been taken over.
1568750	1572870	All right, so for the second demonstration, we will be looking at a baby monitor. So
1572870	1577370	based on the router's exploitation, the attacker already got to know more information about
1577370	1581190	what all other devices exist on the local network. In this case,
1581190	1586290	the attacker was able to identify there's a baby monitor running on 10.0.0.182.
1586390	1593310	So for our demonstration purpose, there is a baby monitor and there is the baby root,
1593310	1599730	just to show you it's live. There you go. So this baby monitor software had a couple of
1599730	1605930	functionalities. It can connect to multiple other cameras on the same network. And this
1605930	1611890	feed is accessible to anyone on the local network. So you can select all of the cameras. As you can
1611890	1617650	see, there are three cameras here. Apart from that, it has functionalities to send commands
1617650	1622650	to different cameras, like getting images. And it also has options of privacy toggle.
1622650	1628670	Then you can see camera three is disabled. So it also gives an option to specifically put an IP
1628670	1634350	and find a camera, if in case it is disabled. Moving on to the attack, we'll be using the
1634350	1640390	tool Singularity. We'll put in the IP, the port, and then we'll be going for
1640390	1646310	hook and control, because we actually want to watch the video, right? And the time interval is
1646310	1652250	set to seven seconds, and we start the attack. Let's look at the developer console. So this way,
1652250	1657550	we can see that every seven seconds, a request is being sent, and it is waiting for a DNS update.
1658410	1665410	And there you go, as the DNS update was made. In this case, let's move on to the attacker's
1665410	1671150	window. Here, you can see that the attacker... there you go. So the attacker is actually able
1671150	1678630	to get a live feed, right? Also, the attacker can try to now perform queries, and in order to
1678630	1684210	identify what all other IPs might be there on the network. So this would be really helpful for an
1684210	1690170	attacker. So the attacker can also try to exploit things like maybe a command injection, which is
1690170	1696490	definitely the case over here. So we'll just try to perform a curl request from the camera's
1696490	1702690	interface to an external webhook that the attacker controls, in order to see if we'll be able to
1703250	1709670	extract more information by performing cat, as well, in order to extract sensitive files,
1709670	1715470	and also to perform curl to the external endpoint of the attacker, which would be very helpful
1715470	1725430	in order to set up a connection, so that the attacker can then use the camera more like a bot.
1725630	1731290	So over here, you can see that the ping request was successful, then the information was also
1731290	1737410	extracted, and here you can see that there was an incoming request to the attacker's webhook
1737410	1742710	from the baby monitor itself. As you can see over here, the request is coming from
1742710	1748410	group. So this basically shows that, okay, the attacker's command, the curl command which the
1748410	1753510	attacker executed, was successful. So now the attacker can actually exfiltrate a lot of
1753510	1761650	information by exploiting the command execution vulnerability. So that's how basically like
1761650	1766950	attacker can exploit it in this particular case. So for the third demonstration, we'll be looking
1766950	1771830	at a smart home panel. So this is not at all a hypothetical scenario. This is something which
1771830	1777870	we have seen very commonly. So this device is actually a smart home panel, which is kept
1777870	1782170	unauthenticated because it is supposed to be accessible only on a local area network,
1782170	1788750	and it is supposed to be placed inside of a tablet, and then it can behave more like a control
1788750	1794330	panel, and it can access all these functionalities. As you can see over here, the lights, thermostats,
1794330	1800450	and everything from a single control panel. So that is why these kind of devices are like pretty
1800450	1806730	common on a local area network, and they are generally kept unauthenticated. Talking about
1807430	1813490	a rebind attack on this particular device, we'll be again using the tool called Singularity.
1813530	1819470	And in this case, we'll be doing hook and control. So over here, we can see once the DNS has
1819470	1827150	been updated to 10.0.0.211, that is the IP of the smart panel in this case, then all the
1827150	1834410	requests from the attacker's domain will actually be made to the result IP of the smart home panel
1835130	1841830	on the port 8081, and that would basically allow an attacker to establish the web socket connection.
1841990	1849170	So as you can see over here, the DNS rebinding attack is successful. So now you can look at
1849470	1855450	the attacker's panel. So the attacker over here is able to take a direct control of the
1855850	1860790	smart home panel remotely, and now the attacker can literally set it to night mode, day mode.
1860830	1867010	And over here, the attacker also has the ability to enable or disable the alarms. So now for this
1867010	1873310	application, we explicitly specified and disabled host check and made it vulnerable just for the
1873310	1878030	demonstration purpose. But if we could just make that minor tweak in the configuration and enable
1878030	1884910	host header validation, so you can see we have enabled it and now we'll be reconfiguring the
1884910	1890390	application. So now in this case, let's try to again perform the same attack after enabling
1890390	1898130	host header validation. So we are going to perform the exact same attack on the application. Let's
1898130	1906370	see what exactly happens this time. So over here, the attack is probably again going to say that it
1906370	1911850	was successful. So you can see it shows that it was successful. Moving on to the attacker's window,
1911850	1918650	let's see how exactly host header would prevent. So when it is trying to access, the attacker is
1918650	1924810	presented a screen showing invalid host header because there was a clear mismatch between the
1924810	1930530	host headers. So this was actually prevented by the application's built-in host header validation.
1931130	1937690	Okay. So we have already seen that how someone can actually exploit this. But now the main
1937690	1945470	question that is, okay, this attack is already known, right? So why does it still exist? So let's
1945470	1950850	just talk about what are the main reasons because of which it is still there. So IoT devices, one of
1950850	1956950	the main reasons is IoT devices are available at cheap prices with almost less or no security.
1956950	1962850	Because there has been an explosion of very cheap and smart devices and vendors who focus more on
1962850	1968230	adding functionality compared to security measures. They do not undergo thorough pen testing
1968230	1974010	or any security compliance check at all. We see a smart device providing such a smart feature at low
1974010	1980290	cost. We add it to our cart and purchase it right away. We as a customer do not understand that the
1980290	1985650	cheap cost also comes at a price that is paid by the lack of research, development, and security
1985650	1990970	measures. Moreover, DNS rebinding bugs have a history of being dismissed by developers and
1990970	1997230	product designers and many times it is left as an unaddressed issue because many of them are not
1997230	2003750	aware of this threat. Apart from this, any specific mitigation for removal might go against the
2003750	2011070	traditional procedure of DNS functioning or sometimes it might break a lot of legacy applications.
2011070	2017050	So the next question that we ask is what individuals and organizations can do.
2017330	2023430	So some of the common ways an individual or organization can prevent such kind of things would
2023430	2031650	be to... the ISP should actually configure their DNS servers in a way that would block DNS responses
2031650	2037890	which contain local IP addresses. Additionally, the device passwords should be changed and the
2037890	2043950	firmware should be updated. So this is something very specific for individuals. They should not
2043950	2050630	keep their device passwords as default because as we already showed in the demo, how a router was
2050630	2057970	exploited was mostly because of default passwords being used. Also, one of the good things that
2057970	2063130	an organization should do would be to make developers more aware of such threat vectors as
2063130	2069150	well. There should be... they should perform extensive penetration testing of devices before
2069150	2075790	rolling them out. Also, investing in threat modeling to identify such issues in the initial
2075790	2081870	stages would be a great effort. Additionally, internal network segmentation. So basically,
2081870	2087110	for anyone who is actually trying to have IoT devices on their network, they should have multiple
2087110	2093270	routes in internal network categorized for IoT devices. Now, we move on to roles of developers
2093270	2099410	and pen testers. So talking about developer and pen tester roles, pen testers, it would be great
2099410	2105930	to actually know about this attack and to perform this kind of attack in almost all their
2105930	2111730	web gaming instances because this is a type of attack which would actually help them to bypass
2111730	2117570	the firewall restrictions, bypass SOP, and still being able to get into a private network and then
2117570	2122050	pivot to other devices. Apart from that, for developers, we would suggest host header validation
2122050	2129550	is one of the most efficient ways of handling an attack like this. Also, the developers should
2129550	2134850	make sure that they provide proper authentication for all the local services. Additionally,
2135630	2142430	instead of creating standard default passwords, all passwords should be uniquely generated.
2142430	2147630	That would actually prevent a lot of vulnerabilities related to the industry binding attacks.
2147630	2154370	Well, we saw how host header validation could prevent such attacks and the roles of organization,
2154370	2159550	individuals, and developers in the prevention of the industry binding attack scenarios.
2159550	2165490	But what about us? Exactly! We have created a browser extension called Securarity,
2166110	2171910	which intends to detect such attacks and keep users safe while browsing such malicious websites.
2171910	2178510	So let's see what we have in this tool. Securarity is a simple extension tool that monitors malicious
2178510	2184090	behavior of domains which intend to scan the consumer's local network for internal IPs and
2184090	2190870	port scans. Our extension provides a list of ports and IP addresses scanned by any host and
2190870	2196850	also notifies the consumer if it detects any rewinding attack or if any website scans your
2196850	2203630	private network. But the question is, does it prevent rewinding attacks? Yes! Once the attack
2203630	2209570	is detected, the extension will automatically block the further request from the requested URL,
2209570	2215490	thus preventing the attacker from using the consumer browser as a proxy for further intervention.
2216870	2222410	Moreover, in this extension, we have integrated the Shodan API, which helps us in identifying the
2222410	2228830	information like IP and hostname for the possible malicious domains and perform a port scan on the
2228830	2236230	attacker's domain. We have also provided an option of manually blocking all HTTP requests based on
2236230	2241770	user-provided URL patterns. We can simply use a blockage feature of this tool which will prevent
2241770	2248670	such sites from scanning your local network or to perform a DNS rewind attack. However, while
2248670	2254310	working from home and testing this code, we observed that there are some instances where we do not want
2254310	2259810	to flag a domain as potentially malicious, specifically in cases where I'm working on a VPN
2259810	2265510	and therefore the extension keeps on flagging all internal IP requests as a potential attack.
2265510	2272850	So for that, we have also created an allow list to bypass monitoring. Let's now talk about how
2272850	2279750	this extension works precisely. So how the extension is identifying inter-access scams?
2279750	2285910	The DNS IP translations are done through the Chrome's web request API. The request object and
2285910	2291610	the target IP is fetched and checked for the private scanning conditions. The extension notifies
2291610	2297830	whenever the case occurs on scanning private IPs and on-click displays the details taken from the
2297830	2304470	data object. How is it identifying rewinding attacks? Similarly, utilizing the web request
2304470	2311270	API, the detect rewinding functions take that IP and original domain name data to process for
2311270	2317030	detecting if rewinding occurs or not, for which it first validates against a set of predicts
2317030	2324150	compliant to RFC-1918 and compares against the target hosting. It validates if the hosting
2324150	2330130	resolves to a private IP and if hosting is itself not a private IP. When found true
2330130	2336310	for these all set of conditions, it then flags the rewinding as true and notifies the user with
2336310	2343830	details displayed in the table on-click. Let's see how it is blocking the SLA build. So in our
2343830	2349610	extensions block functionality, we first check the valid input from the user for the domain name
2349610	2354270	and then provide this valid pattern or URL to the Chrome's web request block request function
2354270	2359970	in order to prevent fetching this particular hosting. Post permissions and content strip
2359970	2366350	matching are based on a set of URLs defined by match patterns, which permits a variety of schemes
2366350	2374830	like HTTP, HTTPS, FILE or FTP and also the wildcard characters. But how are we using Shodan API for
2374830	2381870	hosting? We are using the standard Shodan API to fetch details about the malicious host. The
2381870	2386950	API is used to resolve the hosting to the corresponding IP address, which then is used
2386950	2392730	to perform Shodan host lookup for fetching open quotes and any other information that Shodan has
2392730	2399790	about the malicious host. Okay, so let's see how the allow list is implemented. Similar to block
2399790	2405770	list, we use match patterns for generating the allow list based on the user input and then that
2405770	2412070	is compared against the set of scanned private IPs to not flag them as potentially malicious.
2412070	2418770	Therefore, preventing notifications and hostname blocking. Now coming to the major feature of our
2418770	2425490	extension, that is how secure IoT is preventing the DNS rewinding attack, in addition to notifying
2425490	2430870	all the aforementioned features. So once the rewinding is detected from the detect
2430870	2435570	rewinding function, the block rewind function blocks a further request made by the attacker's
2435570	2441210	request URL on the internal IP addresses, thus automatically preventing the attack and detects
2441210	2448710	filtration. Now we can move to the demonstration and see how the tool works. We are still
2448710	2453270	working on this tool and aim to add features like sending monitoring updates to the users,
2453270	2457870	their mobile device and other smart assistant devices on the home network. We also plan to
2457870	2462730	further improve and add support for other browsers like Firefox and of course some beauty features
2462730	2467910	because we understand that user experience should be convenient. So now moving on, let us see the
2467910	2477370	implementation. So here is the extension. We will now just try to scan. As you can see, it will
2477370	2482870	display scan results and you can now see the list of details that the scanner is doing, IP,
2482870	2490670	code and timestamp. We can use the search for specific needs like a certain group number
2490670	2499730	or a specific IP. Apart from the scan, we have other features
2502590	2507110	like this one where we can see the information about the host,
2507110	2510150	what ports are open, location etc.
2512590	2517870	Okay, let us now see the rewinding detection feature. For that, we will now execute
2519270	2524130	a rewinding attack and see if our tool is able to function as discussed before.
2524130	2529490	So we will do a simple fetch and get. We need to wait for a little, only long.
2531610	2535450	And once we are done, we can see the details displayed in our tools.
2535450	2547730	Okay, so we can see the rewinding attack is successful. Also, our tool has notified us
2547730	2554090	and it's time to check the details. So here we can see the details, if it is IP, domain, timestamp.
2554650	2561610	Moving on to other features, let us see how our block and allow list work.
2564250	2569970	So we will go to the block or allow section and add the pattern we want to block from loading.
2570490	2580790	We can test it with, say, rewind.it and save.
2582810	2587890	Now we will go to the rewind.it page we were using and reload it. Well, it works. So if the
2587890	2594750	rewind is blocked, we can take another example. Let's say block.com. We will add this one as well
2594750	2609020	and try to block it. And hit the save to see if it is blocked or not. Now you go back and
2609020	2617220	reload the page for the blogger. And it is blocked. We can also test this case for iframes
2617220	2621860	also, much relatable to the example of the malicious ad that we have seen before. So you
2621860	2626640	can see that it is blocked by the extension and this will prevent any subsites from loading any
2626640	2631440	malicious ads. Now moving on to the allow list feature, where we can specifically tell the
2631440	2638220	extension that it should not flag any request from this domain. And we are doing it for rewind.it.
2639760	2646080	So we will type rewind.it here and save to allow it.
2653920	2658680	Okay, so let's reload the rewind.it page and scan again.
2660420	2666380	And we can see that it does not notify as it selects the rewind scan.
2666620	2669400	For that, we can see that we have no details.
2670280	2679320	So now we can scan from some other site to see if the function is normal. So let's check here.
2680260	2687180	It will scan and notify us with a display of details. Let's see if it works exactly.
2687320	2690760	So this is it. And we can see the details here.
2695900	2700760	Okay, now we will be seeing how the extension is preventing attacks. So as you can see,
2700760	2704400	this is the router which is hosted here. Now we'll be trying to perform
2706180	2709040	a hook and control in the rewind.it.
2710460	2720400	And see how it is preventing. So let's inspect and start back.
2726050	2730070	We can see here all the requests while doing the rewind attack.
2731050	2733970	Okay, so we can see there were successful socket connection
2733970	2737690	and our extension is able to detect the DNS rewind.
2739170	2746730	But the next thing this extension did is to block the URL. So let's check.
2746750	2755290	So for that, let us go to the attacker's panel and we can see what exactly happened.
2755470	2763390	So here the attacker will try to load the panel and we can check if he is able to load
2763390	2768610	actually or not. So it's trying to fetch the page and we can see in the inspect
2769230	2773710	that the extension is blocking all further requests to the page.
2779460	2782900	So all the requests are getting rejected by extension.
2783520	2787120	Therefore, we can see that even though the attacker is trying to fetch the information,
2787120	2790740	that he won't be able to. And we'll just keep on reading.
2790760	2796420	So that basically concludes our talk. We'll soon be launching the code for security
2796420	2800180	on our GitHub after some modifications and bug fixes.
2800740	2806160	And that's it. So thanks a lot for making it till the end and stay safe.