WEBVTT 00:00.000 --> 00:08.280 One welcome to DEF CON Safe Mode, from crazy Vegas parties last year to me sitting alone in my room right now and sipping vodka in 2020. 00:08.560 --> 00:10.580 Wow, it's been a crazy year. 00:10.640 --> 00:18.900 But it's literally like Vegas in my house right now, because cocktails are acceptable at any hour, and I have no idea what time of the day it is. 00:19.020 --> 00:20.560 Things have changed drastically. 00:20.700 --> 00:26.260 In this time when everything is getting cancelled, I'm so delighted that at least we still have DEF CON. 00:26.260 --> 00:27.520 Welcome to the new normal. 00:27.520 --> 00:28.920 Thanks for joining in. 00:29.000 --> 00:41.820 Before we start, we would like to add a disclaimer that all content over here is specifically for demonstration purposes, and everything is informative, and we have performed all of it on demo environments. 00:41.960 --> 00:45.500 Now, before moving ahead, we would like to introduce ourselves. 00:45.500 --> 00:47.440 So, just a little bit about us. 00:47.440 --> 00:51.760 My name is Devan Kwan, and I work as a security consultant with the NCC group. 00:51.760 --> 00:57.400 I have multiple areas of interest, but the most recent one being IoT and radio hacking. 00:57.400 --> 01:08.400 I have also contributed in the development of NICE, that is non-intrusive confidence engine for multi-factor authentication mechanism, and I am also working on instant messaging and secret storage protocol. 01:08.560 --> 01:13.460 It is the first talk that I have ever given, and therefore, just a heads up to you guys. 01:13.660 --> 01:18.880 The talk would be pretty business friendly, and we'd go over a lot of basic topics as well. 01:18.900 --> 01:20.800 Now, passing on to my co-presenter. 01:20.800 --> 01:21.800 Thank you, Devan. 01:22.000 --> 01:23.040 Hello, everyone. 01:23.040 --> 01:30.200 My name is Shruti I'm a computer scientist working in IoT research and development at Nexus in France. 01:30.340 --> 01:38.760 I have three plus years of experience in IoT development for smart home, autonomous vehicles, indoor and virtual locations, precisely. 01:38.860 --> 01:53.640 I have previously contributed to some international projects like Inakreshi, and I'm also part of Hall of Fame for my contribution to the development of end-to-end IoT platform, which is a leading research institute in Europe. 01:53.660 --> 01:55.820 I'm also an independent researcher. 01:55.820 --> 02:01.080 I'm very passionate about IoT development, secure smart system, teaching, and women empowerment. 02:01.160 --> 02:09.140 Well, now moving on to the agenda for our talk today, we will begin with the idea of connected world, and how it all started. 02:09.140 --> 02:12.820 It's like a very boring history, including introduction for our talk. 02:12.820 --> 02:16.900 Well, it will be followed by the section discussing its security parameters. 02:17.220 --> 02:30.860 We will see how unaware we are surrounded with billions of devices with some stats, and then we will move to the section of attacks and expedition scenario, where we will be understanding a few basic concepts prior to our main demonstration. 02:31.280 --> 02:45.460 We will also cover some tools during this demonstration, and later discuss the crucial points, stating how we can protect our smart world from those discussed attacks, be it an organization, developer, or project designer. 02:45.460 --> 03:00.980 Well, lastly, we will go over the demonstration, and we will demonstrate a small tool that we have developed, which can be very useful in protecting IoT consumers, or making them aware of any attacks they might be unknowingly facing on the connected world. 03:01.620 --> 03:03.200 Well, our connected world. 03:03.200 --> 03:07.540 Okay, so are you telling me that anyone on the internet can talk to my fridge? 03:08.920 --> 03:18.140 Well, today in an era of COVID-19 pandemic, we all are working from home, aiming to stay connected worldwide during the time of social isolation. 03:18.140 --> 03:27.440 Even including this talk, completely online, and where we are missing the real interaction with the crowd and nervousness in the presenters like us. 03:27.440 --> 03:37.540 Although we are really nervous, but thanks to internet of things, from wearable devices and portable technologies to health-related accessories, IoT is everywhere. 03:37.540 --> 03:47.720 It has shifted from a futuristic concept to the central focus area of every industry, ranging from manufacturing and retail to healthcare and real estate. 03:48.340 --> 03:52.200 But the question is how exactly it all started. 03:52.360 --> 04:03.960 The internet of things emerged as the largest digital mega trend, bridging the physical and visual worlds with the fourth industrial revolution, or to say, industry 4.0. 04:03.960 --> 04:14.660 From the first revolution, triggered by the construction of railways, we are now aiming for increasing the networking of people, machines, and objects over the internet. 04:14.660 --> 04:33.040 We understand that internet of things is basically a network of things, which are simply any objects like devices, vehicles, or embedded items in electronics, with the only target of achieving connectivity to enable connection and exchange of data between the things to make our lives simpler. 04:33.040 --> 04:41.360 Showcasing its talent, IoT has fascinated things from eating unbotted coffee to turning off the lights when we go to sleep at night. 04:41.800 --> 04:45.080 I swear to God, that thing has made me so lazy. 04:45.760 --> 04:50.160 This is the reason why dependability has been exponentially increasing. 04:50.160 --> 04:59.540 Just like the COVID graph, from one million down to the expected 50.1 billion in 2020, there is a massive explosion in the usage of IoT devices. 04:59.620 --> 05:06.980 From smart homes, smart healthcare, smart city, and what not, we want everything to be smarter now. 05:07.120 --> 05:12.780 And this means, I literally have no idea how to even say this number right. 05:13.780 --> 05:19.260 But moving on to how safe my world is, I'll pass on to you, Devang. 05:19.260 --> 05:20.320 All right. 05:20.760 --> 05:25.420 So, what if I just tell you that the S in IoT actually stands for security? 05:25.420 --> 05:26.600 Yes, that is true. 05:26.700 --> 05:34.340 So, talking about how safe my world is, with billions of devices connecting the whole world, we care a lot about functioning, right? 05:34.340 --> 05:36.860 We want things to be done in just one click. 05:36.860 --> 05:40.680 We want things faster with less or almost no effort. 05:40.680 --> 05:46.120 Better be functioning soon, be click to buy in Amazon, Alibaba, or wherever you guys shop. 05:46.120 --> 05:50.780 But we need to understand that there's a need for security on so many levels. 05:50.840 --> 05:58.580 So, we should first look and compare the threat models in terms of classic web applications and then in terms of IoT devices. 05:58.980 --> 06:03.980 Over here, we see a simple web app server connecting to a SQL database. 06:03.980 --> 06:07.340 Then we have a third party web service and cloud storage. 06:07.340 --> 06:11.360 They all have their own corporate trust boundary and vendor trust boundary. 06:11.360 --> 06:14.180 And then we talk about the human user. 06:14.620 --> 06:18.920 The human user is actually directly interacting with the web application. 06:18.920 --> 06:24.840 And then they all are being separated by separate privileged levels and their own trust boundaries. 06:25.160 --> 06:30.240 So, as you can see, definitely in no way I'm saying that web applications are extremely similar. 06:30.240 --> 06:32.260 Trust me, I would never say that. 06:32.560 --> 06:37.880 They can definitely and more certainly are more complex than the basic diagram which I'm showing here. 06:37.880 --> 06:43.880 However, we get more clarity when I try to compare it to a simple IoT implementation. 06:44.400 --> 06:44.840 All right. 06:44.840 --> 06:46.540 So, in this next diagram. 06:46.540 --> 06:51.980 So, as you can see over here, in this IoT threat model, this is like a very simple IoT architecture. 06:51.980 --> 06:54.680 I'm not even going into more complex ones. 06:54.680 --> 06:59.020 We aren't even talking about embedded devices and airplanes and the complex architectures. 06:59.020 --> 07:02.420 We're literally talking about a very simple architecture here. 07:02.480 --> 07:06.380 Specifically focusing only on smart and connected forms. 07:06.480 --> 07:11.420 I would say these are more of consumer IoT and less of enterprise IoT. 07:11.420 --> 07:15.380 So, in this case, what we are looking at is a connected user. 07:16.320 --> 07:21.560 So, a connected user is basically a user who is interacting with their smart device. 07:21.560 --> 07:26.320 Then in this case, we have segregated the network into separate sections. 07:26.560 --> 07:30.360 So, as you can see, we have proximity network. 07:30.440 --> 07:34.080 So, in a proximity network, you're considering to have physical. 07:34.080 --> 07:41.660 So, we basically consider a proximity network to have physical sensors, devices, and the IoT gateway itself. 07:42.180 --> 07:47.120 So, basically, that would generally be inside your house. 07:47.120 --> 07:56.480 Then devices are connected to the proximity network by let's say a smart ring, which the user might wear, or any smart device which the user might have in their home. 07:56.480 --> 08:00.040 Then apart from that, the user also interacts with the mobile app. 08:00.040 --> 08:03.020 So, a user basically has two avenues over here. 08:03.020 --> 08:09.900 One is in some cases to directly interact with the embedded sensor of their smart watch or device. 08:09.900 --> 08:13.820 And then another one is the mobile app or any web interface. 08:14.020 --> 08:18.260 Apart from that proximity network, we also talk about the cloud network. 08:18.260 --> 08:27.900 However, for IoT devices, prior to going to cloud, we also have to consider edge servers, as that is what separates them from most of the classic web app. 08:28.080 --> 08:34.080 IoT's preferred microservices architecture compared to most monolithic standard apps. 08:34.080 --> 08:38.840 Edge servers decreases the overall latency and increases the device efficiency. 08:38.840 --> 08:43.380 However, it might add some more attack surfaces in the overall architecture. 08:43.380 --> 08:46.640 Let's just talk about a couple of attack scenarios over here now. 08:46.640 --> 08:57.340 So, you can see that in the proximity network, where the devices communicate over BLE, CoAP, LoRaWAN, as these are close-range protocols and the devices are in proximity. 08:57.340 --> 09:07.040 Therefore, in proximity network, our main threat actors are generally the pre-installed malicious IoT devices, as they might try to replay or intercept the existing traffic. 09:07.040 --> 09:11.480 They might also exfiltrate that traffic out through the IoT gateway. 09:11.920 --> 09:32.340 Okay, now moving on to the mobile interface, we might have more attack surfaces, like, let's say, a malicious application on the user's device, which might try to directly interact with the device file system and processes in order to extract sensitive user-specific data from the IoT device application. 09:32.860 --> 09:36.380 Okay, so let me just come back to this. 09:36.380 --> 09:53.520 So, the main purpose to show this threat model here is that, generally, when we consider IoT threat models, we tend to focus on external threat actors, like an attacker compromising third-party cloud services, or like a malicious app on the device, or like a malicious IoT device in the home system. 09:53.520 --> 09:58.200 So, basically, when talking about IoT, these are the attack surfaces we most care about. 09:58.300 --> 10:01.900 But what about the attack surfaces that we least care about? 10:01.900 --> 10:15.120 What about those benign users on your home network, who exist on your home network, who also have updated operating systems, who have updated browser versions, and they're just casually running JavaScript? 10:15.120 --> 10:15.600 All right. 10:15.600 --> 10:26.180 So, in terms of IoT devices, specifically for connected home devices, a common pattern has been noticed that the device manufacturers tend to give the least priority to device security on local area network. 10:26.220 --> 10:34.220 As the devices are not directly accessible to the external network, therefore, it is generally assumed to be secure without physical access. 10:34.220 --> 10:40.640 As in most cases, the designers just consider that physical access to be the only possible gateway to the private network. 10:40.680 --> 10:51.380 That is why these devices have a variety of open ports and unauthenticated HTTP interfaces running on them, which can be directly controlled by anyone who is present on the home network. 10:51.380 --> 10:58.680 The best example of this was Google Home's unauthenticated HTTP API, which was literally patched in 2019. 10:59.560 --> 11:10.040 And it gave anyone on the local network to perform multiple actions, like rebooting the device or making any sort of modifications, which a normal user could have. 11:10.040 --> 11:19.100 When talking about this particular attack surface, it is considered that if an attacker has physical access to the device, then the network-based attack is among the lowest concern. 11:19.100 --> 11:25.060 And physical attacker access might open up some other serious concerns. 11:25.060 --> 11:27.920 So, this one is given less priority. 11:28.200 --> 11:35.760 However, what if this was not the only attack tree for the exploitation of these HTTP interfaces? 11:36.340 --> 11:41.260 All an attacker needs is a single public gateway to break into the private network. 11:41.260 --> 11:48.460 For a long time, home private networks have been pretty secure, as not everyone is running servers on their local host. 11:48.460 --> 11:51.140 Let's just be honest about that for a minute. 11:51.140 --> 11:59.700 Apart from developers and other people, not everybody is running or hosting an application on their local host networks. 11:59.700 --> 12:10.980 However, with the advent of IoT technology, IoT has literally given an exponential rise to a variety of web interfaces running on users' private network. 12:10.980 --> 12:18.280 In most cases, the user is totally unaware of all the accessible IPs and even open ports on their devices. 12:18.280 --> 12:24.340 The question is, what if an attacker was able to proxy into the private network through a public gate? 12:24.340 --> 12:28.600 Now moving ahead to our next section, attacks and exfiltration scenario. 12:28.600 --> 12:32.280 We would first like you all to do a very simple exercise. 12:32.280 --> 12:39.440 I'd like you all to fire up your terminal and make a simple request, that is, perform this following NSLOOKUP. 12:40.460 --> 12:49.040 Now, if it returns a local IP, then there is a very high chance that you might be vulnerable to DNS rewiring attacks. 12:49.040 --> 12:52.580 Now look at what exactly the attack looks like. 12:52.580 --> 12:56.520 But for that, we need a quick refresher of how exactly DNS works. 12:58.040 --> 13:03.500 Well, we all know that a DNS is like an address directory of the internet. 13:03.500 --> 13:10.000 It translates the domain name like facebook.com, google.com to IP addresses. 13:10.000 --> 13:12.580 So browsers can load internet resources. 13:12.800 --> 13:19.760 These IP addresses are given to each device on the internet and they are necessary to find appropriate internet device. 13:19.760 --> 13:26.900 It's like a street address is used for a particular home, you know, to find that particular home in that particular location. 13:27.080 --> 13:40.640 So to understand how this translation is done, let us imagine a situation where a user is trying to access a website called shop-example.com because, you know, she's bored in this quarantine and wants to shop at least. 13:40.640 --> 13:57.140 So as a user types shop-example.com into a web browser, the query will traverse into the internet asking what is the IP address of shop-example.com and will be received by a DNS recursive resolver. 13:57.840 --> 14:11.360 Well, the next step is that if the recursive resolver has no answer, then the request will be passed on to the DNS root name server asking the same question at what is the IP address of shop-example.com. 14:11.360 --> 14:15.740 The root server will then respond with the address of a TLD. 14:15.740 --> 14:23.740 TLD is top-level domain server like .com or .net which stores the information for its domain. 14:23.740 --> 14:25.300 In this case, it will be .com. 14:25.300 --> 14:31.160 Once the address of TLD is received, the resolver then makes a request to the .com TLD. 14:31.300 --> 14:34.440 The TLD server will behave like a root server. 14:34.440 --> 14:41.220 I know this guy, you might know this guy and will respond with the IP address of the domain's main server. 14:41.300 --> 14:55.320 The recursive resolver then asks the domain main server where is the shop-example.com and then finally the main server will return the IP address of shop-example.com to the resolver with TLD. 14:55.780 --> 14:59.980 And lastly, the user's browser will have the requested IP address. 14:59.980 --> 15:14.440 Now the browser knows the IP address of the website, it is able to make the request for the shop-example.com as the request is offered, for instance, where the web server on the receiving the request will actually respond with that requested web page, 15:14.440 --> 15:16.880 you know, like 60% off. 15:16.880 --> 15:18.660 Wow, who doesn't like that? 15:18.720 --> 15:22.900 Well, we saw the complete flow to understand how DNS works. 15:22.900 --> 15:35.700 Instead of going through all this way and to improve the performance and reliability of data requests, this information is temporarily stored in the locations like browser, operating system, or recursive resolver. 15:35.700 --> 15:43.340 This is all DNS caching and the set amount of time for storing is known as time to live, in short TTL, as I said before. 15:43.720 --> 15:47.480 Well, let's take another situation into consideration. 15:47.560 --> 15:54.260 Okay, so I just, from the previous slide, I'd just like to focus on one thing, time to live. 15:54.260 --> 15:57.300 Please make a note of it, it'll be useful later. 15:57.300 --> 16:00.820 So, let's take another situation into consideration. 16:00.840 --> 16:06.460 Let's say that the user is trying to access some web page and there are some annoying ads on the web page. 16:06.460 --> 16:11.040 Among those, there is one malicious ad waiting for the user's attention. 16:11.040 --> 16:15.580 Since this ad has to be loaded from another domain, our browser has to fetch it. 16:15.580 --> 16:30.560 But loading a random JavaScript from some random domain will give the attacker access to load anything in our browser and authority to make requests to maybe our bank.com or access pages for, let's say, maybe from our smartphone devices. 16:30.700 --> 16:31.680 But you know what? 16:31.680 --> 16:53.480 There is something called same origin policy, which is actually a policy implemented by the browsers and which let the browser restrict this kind of behavior as they restrict and limit any sort of HTTP request which originates from one domain to access resources that are hosted on or served on another domain. 16:53.480 --> 16:56.920 So, to be specific, let's see an example. 16:56.920 --> 16:57.020 Okay. 16:57.020 --> 17:05.780 So, let's take a quick look at an example of how the same origin policy is able to protect resources from being accessed by malicious JavaScript running on websites across origins. 17:05.800 --> 17:15.960 So, in this example, we have a secrets file that is secrets.txt, which is located at test instance running on port 8053 that is accessible over HTTP. 17:16.200 --> 17:22.220 And we will see how the same origin policy can protect this resource from being accessed by malicious JavaScript running on a malicious origin. 17:22.220 --> 17:26.780 In this case, we are considering example.com to be that malicious origin. 17:27.240 --> 17:30.700 So, when we try to perform an XHR request. 17:30.700 --> 17:41.760 So, in the first example, it is of a totally different origin because here the host, that is example.com, as well as the port is totally different from the test instance. 17:52.060 --> 17:52.760 Okay. 17:52.760 --> 17:57.880 So, here you can see that the browser's same origin policy was able to block the malicious website from accessing the resource. 17:57.880 --> 18:03.640 As it said, they do not have the same origin due to them having totally different host as well as port. 18:03.760 --> 18:04.420 Okay. 18:04.420 --> 18:06.900 Now, we'll be looking at a different example. 18:07.140 --> 18:15.160 So, in this particular example, these two resources have the same host, that is testinstance.com. 18:15.160 --> 18:19.960 But they happen to have this totally different port numbers. 18:19.960 --> 18:26.020 One, the secrets was actually on 8053, whereas this resource is on 8056. 18:26.020 --> 18:28.840 And we can observe that. 18:29.480 --> 18:30.400 Okay. 18:30.400 --> 18:42.180 And in this case, when we try to perform a XML HTTP request, or basically a cross-site JavaScript fetch, we'll be able to see. 18:42.180 --> 18:42.800 Okay. 18:42.800 --> 19:03.480 So, as these two happen to have different port numbers, although they have the same host, the resource is still not able to access the secrets.txt, because the browser still considers this to be a totally different origin, because of them having totally different ports. 19:03.480 --> 19:06.380 Now, we will look at a standard example. 19:06.380 --> 19:13.120 This page is testinstance.com, and it has the same 8053 port as our secret. 19:13.120 --> 19:20.240 So, this happened to match all the criteria that is required for a same origin, right? 19:20.240 --> 19:30.900 Then, in that case, we'll just try to see how exactly the same origin policy would allow this one to access the secret. 19:30.900 --> 19:51.120 So, in this case, as you can see, this was able to pass the same origin policy due to exactly the same host, the same protocol, as well as the same port number, because of which it was able to access the resource which was hosted, which was actually located at secrets.txt. 19:51.120 --> 19:54.480 So, that basically sums up the example of same origin policy. 19:55.040 --> 20:02.660 So, the question that arises here is, if SOP is actually preventing this kind of attack, then what is the threat? 20:04.340 --> 20:06.440 Well, DNS rewinding. 20:06.440 --> 20:14.160 DNS rewinding is a class of exploit in which the attacker initiates repeated DNS queries to a domain under their control. 20:14.160 --> 20:22.280 Consider the scenario where the user is comfortably surfing over the internet to access a web page containing some advertisement. 20:22.640 --> 20:26.800 Among those ads, there is one malicious ad, as Ivan stated before. 20:26.800 --> 20:35.000 As the web page is loaded, the browser will request the malicious DNS server querying the IP address of maliciousads.com. 20:35.200 --> 20:54.560 When receiving this request, the attacker-controlled DNS server responds with the real IP, let's say 1.2.3.4, and it also sets the TTL value on the response to be zero minutes or a few seconds, so that the user's machine won't cache for long. 20:54.560 --> 20:56.940 Now, let's wait for some time. 20:57.740 --> 21:02.660 Now, the malicious JavaScript makes another request to maliciousads.com. 21:02.660 --> 21:08.780 And since the TTL is exceeded, the IP of maliciousads.com isn't found in the cache. 21:08.980 --> 21:13.920 Therefore, the browser will again request the IP from the DNS server. 21:13.960 --> 21:14.820 But what? 21:14.820 --> 21:15.340 Wait! 21:15.340 --> 21:36.980 This time, on the user's subsequent DNS request, instead of the real IP, the maliciousads.com, the name server of maliciousads.com, will respond with the IP of 10.0.0.1, which happens to be an IP within the user's local space and belongs to an IoT device on the user's network. 21:37.740 --> 21:48.780 The user's browser will receive this malicious DNS response and will use this provided IP to make HTTP requests, which were intended for maliciousads.com. 21:48.780 --> 21:53.620 Because technically, there is no change for the browser according to the normal functioning. 21:53.620 --> 22:00.220 Because based on SOP, browser just sees the same name and goes, oh, we have the same name. 22:00.220 --> 22:07.140 So we are friends and allows all queries from the same origin, irrespective of the IPs. 22:07.140 --> 22:14.400 But the HTTP requests are now sent to the small unprotected web server running on the user's component. 22:14.400 --> 22:21.560 The same network where all your smart devices are connected and that's making your smart home unsafe. 22:21.620 --> 22:25.340 And that's behaving as a proxy between your private and public world. 22:25.340 --> 22:40.160 DNS rebinding attack can actually bypass network firewalls, security controls, such as false and make every device on your local network vulnerable and available to an attacker from anywhere outside your protected internet. 22:41.120 --> 22:42.820 Let us do theoretically. 22:42.960 --> 22:44.740 Now it's time to hack. 22:44.740 --> 22:45.120 Okay. 22:45.120 --> 22:52.440 So in this example, the first thing that we'll be talking about is a router interface that allows anyone on the network to access the router controls once they have authenticated. 22:52.440 --> 22:58.300 However, even prior to the authentication, this allows users on the home network to access the list of all the connected devices. 22:58.680 --> 23:04.900 So let's see how a user on this private network can become vulnerable to the DNS rebinding attack by just navigating to a website that looks totally benign. 23:04.900 --> 23:06.080 In this case, cute videos. 23:06.080 --> 23:07.120 Because you know what? 23:07.160 --> 23:08.920 Who does not like cute animals? 23:09.200 --> 23:20.460 So as you can see in the developer options in the network request, you can see even before the page was loaded, the malicious host on the page initiated a port scan in the local network in order to identify the router interface. 23:20.460 --> 23:29.400 Router is an easily identifiable target in most of the because standard IP of their default gateways and therefore it is easy to scan compared to other devices. 23:29.400 --> 23:32.920 So here it has already identified 10.0.0.2. 23:33.080 --> 23:44.020 And now automatically it has started sending the JavaScript on the page has already started sending multiple requests from the page to the external URL. 23:44.300 --> 23:49.800 And now this page is basically just waiting for the DNS to be DNS records to be updated. 23:49.800 --> 23:52.400 So this video is already 11 minutes long. 23:52.400 --> 23:58.800 And that's like already enough time for an attacker to perform the DNS rewinding attack. 23:58.800 --> 24:12.600 So by the time the attacker so by the time you're even watching first 20 seconds of the video, the attacker has already been able to rewind and has been sent internal request to 10.0.0.2. 24:12.600 --> 24:15.960 And now we'll move to the attackers panel. 24:15.960 --> 24:25.740 So here you can see a WebSocket connection has been made based on which the attacker would be able to actually access things on the internal network. 24:25.740 --> 24:32.240 So now you can see the remote address has been updated from the attacker's IP address to the internal IP address. 24:32.240 --> 24:45.620 And based on that, the attacker is now able to any request that has been performed to the origin by the JavaScript is actually helping the attacker to communicate with the internal services that is running on your router. 24:45.680 --> 24:48.620 So now we'll just try some generic passwords. 24:48.620 --> 24:57.900 Oh, in this case, we just tried admin admin and that definitely worked because a lot of routers, whether we want to accept it or not, are still working on default passwords. 24:57.900 --> 25:14.760 So this gives any attacker multiple functionalities like setting the functionality of the router, modifying passwords, and this also allows them to enable UPnP, which might make them vulnerable to multiple other vulnerabilities apart from this. 25:14.760 --> 25:19.780 It also allows the attacker to remotely reset or reboot the device. 25:19.780 --> 25:28.520 Also, it gives an attacker full functionality to modify your DNS servers and thus serving you all the malicious websites that they want to. 25:28.520 --> 25:37.220 Also, they can just proxy your entire network and that would help them to take over other multiple devices on your network as well. 25:37.860 --> 25:40.620 So that would be, in short, pretty bad. 25:40.620 --> 25:43.740 And over here, you can see all those requests. 25:43.820 --> 25:47.780 So in this case, password update page that was being fetched by the attacker. 25:47.780 --> 25:52.840 So all these requests were actually being made to the external attacker's origin. 25:52.840 --> 25:58.600 However, the remote address was routed to 10.0.0.2, which was the router's IP. 25:58.600 --> 26:05.200 So by the time you're busy watching the cute dog, your entire router and the network has been taken over. 26:08.750 --> 26:12.710 All right, so for the second demonstration, we will be looking at a baby monitor. 26:12.710 --> 26:20.070 So based on the router's exploitation, the attacker already got to know more information about what all other devices exist on the local network. 26:20.070 --> 26:26.290 In this case, the attacker was able to identify there's a baby monitor running on 10.0.0.182. 26:26.390 --> 26:34.550 So for our demonstration purpose, there is a baby monitor and there is the baby root, just to show you it's live. 26:34.550 --> 26:35.510 There you go. 26:35.770 --> 26:40.570 So this baby monitor software had a couple of functionalities. 26:40.870 --> 26:45.430 It can connect to multiple other cameras on the same network. 26:45.430 --> 26:48.710 And this feed is accessible to anyone on the local network. 26:48.710 --> 26:51.570 So you can select all of the cameras. 26:51.570 --> 26:54.530 As you can see, there are three cameras here. 26:54.710 --> 27:00.430 Apart from that, it has functionalities to send commands to different cameras, like getting images. 27:00.430 --> 27:02.650 And it also has options of privacy toggle. 27:02.650 --> 27:05.230 Then you can see camera three is disabled. 27:05.230 --> 27:11.330 So it also gives an option to specifically put an IP and find a camera, if in case it is disabled. 27:11.430 --> 27:15.570 Moving on to the attack, we'll be using the tool Singularity. 27:15.570 --> 27:24.410 We'll put in the IP, the port, and then we'll be going for hook and control, because we actually want to watch the video, right? 27:24.570 --> 27:29.290 And the time interval is set to seven seconds, and we start the attack. 27:29.410 --> 27:31.450 Let's look at the developer console. 27:31.710 --> 27:37.550 So this way, we can see that every seven seconds, a request is being sent, and it is waiting for a DNS update. 27:38.410 --> 27:42.810 And there you go, as the DNS update was made. 27:42.810 --> 27:46.110 In this case, let's move on to the attacker's window. 27:46.590 --> 27:49.790 Here, you can see that the attacker... there you go. 27:49.790 --> 27:53.070 So the attacker is actually able to get a live feed, right? 27:53.110 --> 28:02.170 Also, the attacker can try to now perform queries, and in order to identify what all other IPs might be there on the network. 28:02.170 --> 28:04.830 So this would be really helpful for an attacker. 28:04.830 --> 28:12.010 So the attacker can also try to exploit things like maybe a command injection, which is definitely the case over here. 28:12.010 --> 28:33.250 So we'll just try to perform a curl request from the camera's interface to an external webhook that the attacker controls, in order to see if we'll be able to extract more information by performing cat, as well, in order to extract sensitive files, and also to perform curl to the external endpoint of the attacker, 28:33.250 --> 28:45.430 which would be very helpful in order to set up a connection, so that the attacker can then use the camera more like a bot. 28:45.630 --> 29:00.390 So over here, you can see that the ping request was successful, then the information was also extracted, and here you can see that there was an incoming request to the attacker's webhook from the baby monitor itself. 29:00.390 --> 29:03.690 As you can see over here, the request is coming from group. 29:03.690 --> 29:10.490 So this basically shows that, okay, the attacker's command, the curl command which the attacker executed, was successful. 29:10.490 --> 29:18.330 So now the attacker can actually exfiltrate a lot of information by exploiting the command execution vulnerability. 29:18.970 --> 29:24.810 So that's how basically like attacker can exploit it in this particular case. 29:25.210 --> 29:28.010 So for the third demonstration, we'll be looking at a smart home panel. 29:28.010 --> 29:30.890 So this is not at all a hypothetical scenario. 29:30.890 --> 29:33.790 This is something which we have seen very commonly. 29:33.910 --> 29:51.330 So this device is actually a smart home panel, which is kept unauthenticated because it is supposed to be accessible only on a local area network, and it is supposed to be placed inside of a tablet, and then it can behave more like a control panel, and it can access all these functionalities. 29:51.330 --> 29:57.070 As you can see over here, the lights, thermostats, and everything from a single control panel. 29:57.350 --> 30:06.210 So that is why these kind of devices are like pretty common on a local area network, and they are generally kept unauthenticated. 30:06.210 --> 30:13.490 Talking about a rebind attack on this particular device, we'll be again using the tool called Singularity. 30:13.530 --> 30:16.370 And in this case, we'll be doing hook and control. 30:16.450 --> 30:41.830 So over here, we can see once the DNS has been updated to 10.0.0.211, that is the IP of the smart panel in this case, then all the requests from the attacker's domain will actually be made to the result IP of the smart home panel on the port 8081, and that would basically allow an attacker to establish the web socket connection. 30:41.990 --> 30:46.670 So as you can see over here, the DNS rebinding attack is successful. 30:46.790 --> 30:51.710 So now you can look at the attacker's panel. 30:51.710 --> 31:00.790 So the attacker over here is able to take a direct control of the smart home panel remotely, and now the attacker can literally set it to night mode, day mode. 31:00.830 --> 31:05.970 And over here, the attacker also has the ability to enable or disable the alarms. 31:05.970 --> 31:14.550 So now for this application, we explicitly specified and disabled host check and made it vulnerable just for the demonstration purpose. 31:14.550 --> 31:25.970 But if we could just make that minor tweak in the configuration and enable host header validation, so you can see we have enabled it and now we'll be reconfiguring the application. 31:26.050 --> 31:31.910 So now in this case, let's try to again perform the same attack after enabling host header validation. 31:32.130 --> 31:37.010 So we are going to perform the exact same attack on the application. 31:37.730 --> 31:40.370 Let's see what exactly happens this time. 31:40.650 --> 31:47.470 So over here, the attack is probably again going to say that it was successful. 31:47.470 --> 31:50.090 So you can see it shows that it was successful. 31:50.090 --> 31:54.850 Moving on to the attacker's window, let's see how exactly host header would prevent. 31:54.850 --> 32:06.050 So when it is trying to access, the attacker is presented a screen showing invalid host header because there was a clear mismatch between the host headers. 32:06.090 --> 32:10.530 So this was actually prevented by the application's built-in host header validation. 32:11.130 --> 32:11.730 Okay. 32:11.730 --> 32:16.950 So we have already seen that how someone can actually exploit this. 32:16.950 --> 32:21.950 But now the main question that is, okay, this attack is already known, right? 32:21.950 --> 32:24.970 So why does it still exist? 32:25.010 --> 32:29.150 So let's just talk about what are the main reasons because of which it is still there. 32:29.330 --> 32:36.950 So IoT devices, one of the main reasons is IoT devices are available at cheap prices with almost less or no security. 32:36.950 --> 32:45.990 Because there has been an explosion of very cheap and smart devices and vendors who focus more on adding functionality compared to security measures. 32:45.990 --> 32:51.030 They do not undergo thorough pen testing or any security compliance check at all. 32:51.030 --> 32:54.690 We see a smart device providing such a smart feature at low cost. 32:54.690 --> 32:57.690 We add it to our cart and purchase it right away. 32:58.150 --> 33:06.690 We as a customer do not understand that the cheap cost also comes at a price that is paid by the lack of research, development, and security measures. 33:06.710 --> 33:18.990 Moreover, DNS rebinding bugs have a history of being dismissed by developers and product designers and many times it is left as an unaddressed issue because many of them are not aware of this threat. 33:19.030 --> 33:31.070 Apart from this, any specific mitigation for removal might go against the traditional procedure of DNS functioning or sometimes it might break a lot of legacy applications. 33:31.070 --> 33:37.050 So the next question that we ask is what individuals and organizations can do. 33:37.330 --> 33:53.810 So some of the common ways an individual or organization can prevent such kind of things would be to... the ISP should actually configure their DNS servers in a way that would block DNS responses which contain local IP addresses. 33:53.810 --> 33:59.230 Additionally, the device passwords should be changed and the firmware should be updated. 33:59.230 --> 34:03.090 So this is something very specific for individuals. 34:03.090 --> 34:15.590 They should not keep their device passwords as default because as we already showed in the demo, how a router was exploited was mostly because of default passwords being used. 34:15.590 --> 34:24.070 Also, one of the good things that an organization should do would be to make developers more aware of such threat vectors as well. 34:24.510 --> 34:30.590 There should be... they should perform extensive penetration testing of devices before rolling them out. 34:30.590 --> 34:38.530 Also, investing in threat modeling to identify such issues in the initial stages would be a great effort. 34:38.530 --> 34:40.950 Additionally, internal network segmentation. 34:40.950 --> 34:50.850 So basically, for anyone who is actually trying to have IoT devices on their network, they should have multiple routes in internal network categorized for IoT devices. 34:50.850 --> 34:54.790 Now, we move on to roles of developers and pen testers. 34:54.790 --> 35:13.230 So talking about developer and pen tester roles, pen testers, it would be great to actually know about this attack and to perform this kind of attack in almost all their web gaming instances because this is a type of attack which would actually help them to bypass the firewall restrictions, 35:13.230 --> 35:18.770 bypass SOP, and still being able to get into a private network and then pivot to other devices. 35:18.770 --> 35:27.570 Apart from that, for developers, we would suggest host header validation is one of the most efficient ways of handling an attack like this. 35:27.570 --> 35:34.230 Also, the developers should make sure that they provide proper authentication for all the local services. 35:34.230 --> 35:42.430 Additionally, instead of creating standard default passwords, all passwords should be uniquely generated. 35:42.430 --> 35:47.630 That would actually prevent a lot of vulnerabilities related to the industry binding attacks. 35:47.630 --> 35:59.550 Well, we saw how host header validation could prevent such attacks and the roles of organization, individuals, and developers in the prevention of the industry binding attack scenarios. 35:59.550 --> 36:01.310 But what about us? 36:01.310 --> 36:02.190 Exactly! 36:02.190 --> 36:11.910 We have created a browser extension called Securarity, which intends to detect such attacks and keep users safe while browsing such malicious websites. 36:11.910 --> 36:14.870 So let's see what we have in this tool. 36:15.010 --> 36:25.450 Securarity is a simple extension tool that monitors malicious behavior of domains which intend to scan the consumer's local network for internal IPs and port scans. 36:25.450 --> 36:38.230 Our extension provides a list of ports and IP addresses scanned by any host and also notifies the consumer if it detects any rewinding attack or if any website scans your private network. 36:38.410 --> 36:41.970 But the question is, does it prevent rewinding attacks? 36:41.970 --> 36:42.930 Yes! 36:42.930 --> 36:55.490 Once the attack is detected, the extension will automatically block the further request from the requested URL, thus preventing the attacker from using the consumer browser as a proxy for further intervention. 36:56.870 --> 37:10.290 Moreover, in this extension, we have integrated the Shodan API, which helps us in identifying the information like IP and hostname for the possible malicious domains and perform a port scan on the attacker's domain. 37:10.530 --> 37:18.070 We have also provided an option of manually blocking all HTTP requests based on user -provided URL patterns. 37:18.070 --> 37:27.150 We can simply use a blockage feature of this tool which will prevent such sites from scanning your local network or to perform a DNS rewind attack. 37:27.590 --> 37:45.510 However, while working from home and testing this code, we observed that there are some instances where we do not want to flag a domain as potentially malicious, specifically in cases where I'm working on a VPN and therefore the extension keeps on flagging all internal IP requests as a potential attack. 37:45.510 --> 37:51.110 So for that, we have also created an allow list to bypass monitoring. 37:51.190 --> 37:55.090 Let's now talk about how this extension works precisely. 37:55.450 --> 37:59.750 So how the extension is identifying inter-access scams? 37:59.750 --> 38:04.470 The DNS IP translations are done through the Chrome's web request API. 38:04.470 --> 38:10.450 The request object and the target IP is fetched and checked for the private scanning conditions. 38:10.450 --> 38:19.350 The extension notifies whenever the case occurs on scanning private IPs and on-click displays the details taken from the data object. 38:19.670 --> 38:22.670 How is it identifying rewinding attacks? 38:22.670 --> 38:42.270 Similarly, utilizing the web request API, the detect rewinding functions take that IP and original domain name data to process for detecting if rewinding occurs or not, for which it first validates against a set of predicts compliant to RFC-1918 and compares against the target hosting. 38:42.850 --> 38:49.330 It validates if the hosting resolves to a private IP and if hosting is itself not a private IP. 38:49.330 --> 38:59.130 When found true for these all set of conditions, it then flags the rewinding as true and notifies the user with details displayed in the table on-click. 39:00.050 --> 39:03.070 Let's see how it is blocking the SLA build. 39:03.070 --> 39:17.970 So in our extensions block functionality, we first check the valid input from the user for the domain name and then provide this valid pattern or URL to the Chrome's web request block request function in order to prevent fetching this particular hosting. 39:18.130 --> 39:32.270 Post permissions and content strip matching are based on a set of URLs defined by match patterns, which permits a variety of schemes like HTTP, HTTPS, FILE or FTP and also the wildcard characters. 39:32.870 --> 39:35.530 But how are we using Shodan API for hosting? 39:36.090 --> 39:41.550 We are using the standard Shodan API to fetch details about the malicious host. 39:41.550 --> 39:54.790 The API is used to resolve the hosting to the corresponding IP address, which then is used to perform Shodan host lookup for fetching open quotes and any other information that Shodan has about the malicious host. 39:55.790 --> 39:58.830 Okay, so let's see how the allow list is implemented. 39:58.830 --> 40:12.070 Similar to block list, we use match patterns for generating the allow list based on the user input and then that is compared against the set of scanned private IPs to not flag them as potentially malicious. 40:12.070 --> 40:16.050 Therefore, preventing notifications and hostname blocking. 40:16.730 --> 40:27.710 Now coming to the major feature of our extension, that is how secure IoT is preventing the DNS rewinding attack, in addition to notifying all the aforementioned features. 40:28.070 --> 40:42.090 So once the rewinding is detected from the detect rewinding function, the block rewind function blocks a further request made by the attacker's request URL on the internal IP addresses, thus automatically preventing the attack and detects filtration. 40:42.790 --> 40:48.110 Now we can move to the demonstration and see how the tool works. 40:48.110 --> 40:57.010 We are still working on this tool and aim to add features like sending monitoring updates to the users, their mobile device and other smart assistant devices on the home network. 40:57.010 --> 41:06.110 We also plan to further improve and add support for other browsers like Firefox and of course some beauty features because we understand that user experience should be convenient. 41:06.190 --> 41:08.970 So now moving on, let us see the implementation. 41:09.430 --> 41:12.030 So here is the extension. 41:12.070 --> 41:14.650 We will now just try to scan. 41:16.090 --> 41:26.130 As you can see, it will display scan results and you can now see the list of details that the scanner is doing, IP, code and timestamp. 41:26.130 --> 41:32.970 We can use the search for specific needs like a certain group number or a specific IP. 41:36.750 --> 41:50.150 Apart from the scan, we have other features like this one where we can see the information about the host, what ports are open, location etc. 41:52.590 --> 41:56.170 Okay, let us now see the rewinding detection feature. 41:56.170 --> 42:04.130 For that, we will now execute a rewinding attack and see if our tool is able to function as discussed before. 42:04.130 --> 42:06.290 So we will do a simple fetch and get. 42:07.030 --> 42:09.490 We need to wait for a little, only long. 42:11.610 --> 42:15.450 And once we are done, we can see the details displayed in our tools. 42:15.450 --> 42:15.890 Okay 42:21.770 --> 42:25.950 , so we can see the rewinding attack is successful. 42:25.950 --> 42:29.930 Also, our tool has notified us and it's time to check the details. 42:29.930 --> 42:34.090 So here we can see the details, if it is IP, domain, timestamp. 42:34.650 --> 42:41.610 Moving on to other features, let us see how our block and allow list work. 42:44.250 --> 42:49.970 So we will go to the block or allow section and add the pattern we want to block from loading. 42:50.490 --> 42:55.950 We can test it with, say, rewind.it and 42:59.910 --> 43:00.790 save. 43:02.810 --> 43:06.590 Now we will go to the rewind.it page we were using and reload it. 43:06.590 --> 43:07.470 Well, it works. 43:07.470 --> 43:11.550 So if the rewind is blocked, we can take another example. 43:11.550 --> 43:13.150 Let's say block.com. 43:13.210 --> 43:17.010 We will add this one as well and try to block it. 43:23.880 --> 43:27.180 And hit the save to see if it is blocked or not. 43:28.000 --> 43:31.140 Now you go back and reload the page for the blogger. 43:32.820 --> 43:34.220 And it is blocked. 43:34.220 --> 43:41.540 We can also test this case for iframes also, much relatable to the example of the malicious ad that we have seen before. 43:41.540 --> 43:47.840 So you can see that it is blocked by the extension and this will prevent any subsites from loading any malicious ads. 43:48.060 --> 43:54.860 Now moving on to the allow list feature, where we can specifically tell the extension that it should not flag any request from this domain. 43:54.960 --> 43:58.220 And we are doing it for rewind.it. 43:59.760 --> 44:06.080 So we will type rewind.it here and save to allow it. 44:13.920 --> 44:18.680 Okay, so let's reload the rewind.it page and scan again. 44:20.420 --> 44:26.380 And we can see that it does not notify as it selects the rewind scan. 44:26.620 --> 44:29.400 For that, we can see that we have no details. 44:30.280 --> 44:37.460 So now we can scan from some other site to see if the function is normal. 44:37.460 --> 44:39.320 So let's check here. 44:40.260 --> 44:44.640 It will scan and notify us with a display of details. 44:44.960 --> 44:47.180 Let's see if it works exactly. 44:47.320 --> 44:48.720 So this is it. 44:48.720 --> 44:50.760 And we can see the details here. 44:55.900 --> 44:59.860 Okay, now we will be seeing how the extension is preventing attacks. 44:59.860 --> 45:02.880 So as you can see, this is the router which is hosted here. 45:02.880 --> 45:09.040 Now we'll be trying to perform a hook and control in the rewind.it. 45:10.460 --> 45:13.060 And see how it is preventing. 45:15.900 --> 45:20.400 So let's inspect and start back. 45:26.050 --> 45:30.070 We can see here all the requests while doing the rewind attack. 45:31.050 --> 45:37.690 Okay, so we can see there were successful socket connection and our extension is able to detect the DNS rewind. 45:39.170 --> 45:45.390 But the next thing this extension did is to block the URL. 45:45.390 --> 45:46.730 So let's check. 45:46.750 --> 45:55.290 So for that, let us go to the attacker's panel and we can see what exactly happened. 45:55.470 --> 46:04.910 So here the attacker will try to load the panel and we can check if he is able to load actually or not. 46:05.330 --> 46:13.710 So it's trying to fetch the page and we can see in the inspect that the extension is blocking all further requests to the page. 46:19.460 --> 46:22.900 So all the requests are getting rejected by extension. 46:23.520 --> 46:28.840 Therefore, we can see that even though the attacker is trying to fetch the information, that he won't be able to. 46:29.220 --> 46:30.740 And we'll just keep on reading. 46:30.760 --> 46:33.460 So that basically concludes our talk. 46:33.520 --> 46:40.180 We'll soon be launching the code for security on our GitHub after some modifications and bug fixes. 46:40.740 --> 46:42.400 And that's it. 46:42.400 --> 46:46.160 So thanks a lot for making it till the end and stay safe.