[00:00.000 --> 00:04.740]  One welcome to DEF CON Safe Mode, from crazy Vegas parties last year to me
[00:04.740 --> 00:08.280]  sitting alone in my room right now and sipping vodka in 2020.
[00:08.560 --> 00:13.140]  Wow, it's been a crazy year. But it's literally like Vegas in my house right now,
[00:13.140 --> 00:18.900]  because cocktails are acceptable at any hour, and I have no idea what time of the day it is.
[00:19.020 --> 00:23.240]  Things have changed drastically. In this time when everything is getting cancelled,
[00:23.240 --> 00:27.520]  I'm so delighted that at least we still have DEF CON. Welcome to the new normal.
[00:27.520 --> 00:33.160]  Thanks for joining in. Before we start, we would like to add a disclaimer that all content over
[00:33.160 --> 00:39.520]  here is specifically for demonstration purposes, and everything is informative, and we have performed
[00:39.520 --> 00:45.500]  all of it on demo environments. Now, before moving ahead, we would like to introduce ourselves.
[00:45.500 --> 00:50.640]  So, just a little bit about us. My name is Devan Kwan, and I work as a security consultant with
[00:50.640 --> 00:56.660]  the NCC group. I have multiple areas of interest, but the most recent one being IoT and radio
[00:56.660 --> 01:01.820]  hacking. I have also contributed in the development of NICE, that is non-intrusive confidence engine
[01:01.820 --> 01:07.100]  for multi-factor authentication mechanism, and I am also working on instant messaging and secret
[01:07.100 --> 01:12.620]  storage protocol. It is the first talk that I have ever given, and therefore, just a heads up to you
[01:12.620 --> 01:18.880]  guys. The talk would be pretty business friendly, and we'd go over a lot of basic topics as well.
[01:18.900 --> 01:24.020]  Now, passing on to my co-presenter. Thank you, Devan. Hello, everyone. My name is Shruti
[01:24.020 --> 01:31.200]  I'm a computer scientist working in IoT research and development at Nexus in France. I have three
[01:31.200 --> 01:36.720]  plus years of experience in IoT development for smart home, autonomous vehicles, indoor and
[01:36.720 --> 01:42.520]  virtual locations, precisely. I have previously contributed to some international projects like
[01:42.520 --> 01:48.760]  Inakreshi, and I'm also part of Hall of Fame for my contribution to the development of end-to-end
[01:48.760 --> 01:54.880]  IoT platform, which is a leading research institute in Europe. I'm also an independent
[01:54.880 --> 01:59.640]  researcher. I'm very passionate about IoT development, secure smart system, teaching,
[01:59.640 --> 02:05.680]  and women empowerment. Well, now moving on to the agenda for our talk today, we will begin with the
[02:05.680 --> 02:11.120]  idea of connected world, and how it all started. It's like a very boring history, including
[02:11.120 --> 02:15.840]  introduction for our talk. Well, it will be followed by the section discussing its security
[02:15.840 --> 02:21.300]  parameters. We will see how unaware we are surrounded with billions of devices with some
[02:21.300 --> 02:26.740]  stats, and then we will move to the section of attacks and expedition scenario, where we will
[02:26.740 --> 02:32.860]  be understanding a few basic concepts prior to our main demonstration. We will also cover some tools
[02:33.500 --> 02:38.860]  during this demonstration, and later discuss the crucial points, stating how we can protect our
[02:38.860 --> 02:45.460]  smart world from those discussed attacks, be it an organization, developer, or project designer.
[02:45.460 --> 02:51.640]  Well, lastly, we will go over the demonstration, and we will demonstrate a small tool that we have
[02:51.640 --> 02:57.740]  developed, which can be very useful in protecting IoT consumers, or making them aware of any attacks
[02:57.740 --> 03:03.820]  they might be unknowingly facing on the connected world. Well, our connected world. Okay, so are you
[03:03.820 --> 03:11.580]  telling me that anyone on the internet can talk to my fridge? Well, today in an era of COVID-19
[03:11.580 --> 03:16.760]  pandemic, we all are working from home, aiming to stay connected worldwide during the time of
[03:16.760 --> 03:22.660]  social isolation. Even including this talk, completely online, and where we are missing the
[03:22.660 --> 03:28.120]  real interaction with the crowd and nervousness in the presenters like us. Although we are really
[03:28.120 --> 03:34.160]  nervous, but thanks to internet of things, from wearable devices and portable technologies to
[03:34.160 --> 03:40.580]  health-related accessories, IoT is everywhere. It has shifted from a futuristic concept to the
[03:40.580 --> 03:47.720]  central focus area of every industry, ranging from manufacturing and retail to healthcare and real estate.
[03:48.340 --> 03:55.600]  But the question is how exactly it all started. The internet of things emerged as the largest
[03:55.600 --> 04:01.780]  digital mega trend, bridging the physical and visual worlds with the fourth industrial revolution,
[04:01.780 --> 04:08.140]  or to say, industry 4.0. From the first revolution, triggered by the construction of railways, we are
[04:08.140 --> 04:14.660]  now aiming for increasing the networking of people, machines, and objects over the internet.
[04:14.660 --> 04:19.540]  We understand that internet of things is basically a network of things, which are simply any objects
[04:19.540 --> 04:26.460]  like devices, vehicles, or embedded items in electronics, with the only target of achieving
[04:26.460 --> 04:33.040]  connectivity to enable connection and exchange of data between the things to make our lives simpler.
[04:33.040 --> 04:38.960]  Showcasing its talent, IoT has fascinated things from eating unbotted coffee to turning off the
[04:38.960 --> 04:45.080]  lights when we go to sleep at night. I swear to God, that thing has made me so lazy.
[04:45.760 --> 04:50.620]  This is the reason why dependability has been exponentially increasing. Just like the
[04:50.620 --> 04:56.820]  COVID graph, from one million down to the expected 50.1 billion in 2020, there is a
[04:56.820 --> 05:02.920]  massive explosion in the usage of IoT devices. From smart homes, smart healthcare, smart city,
[05:03.040 --> 05:08.160]  and what not, we want everything to be smarter now. And this means,
[05:09.460 --> 05:12.780]  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:25.900]  All right. So, what if I just tell you that the S in IoT actually stands for security? Yes, that is
[05:25.900 --> 05:32.180]  true. So, talking about how safe my world is, with billions of devices connecting the whole world,
[05:32.180 --> 05:37.140]  we care a lot about functioning, right? We want things to be done in just one click. We want
[05:37.140 --> 05:43.060]  things faster with less or almost no effort. Better be functioning soon, be click to buy in
[05:43.060 --> 05:48.660]  Amazon, Alibaba, or wherever you guys shop. But we need to understand that there's a need for
[05:48.660 --> 05:54.560]  security on so many levels. So, we should first look and compare the threat models in terms of
[05:54.560 --> 06:01.800]  classic web applications and then in terms of IoT devices. Over here, we see a simple web app
[06:01.800 --> 06:07.340]  server connecting to a SQL database. Then we have a third party web service and cloud storage.
[06:07.340 --> 06:12.680]  They all have their own corporate trust boundary and vendor trust boundary. And then we talk about
[06:12.680 --> 06:18.920]  the human user. 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:35.360]  Trust me, I would never say that. They can definitely and more certainly are more complex
[06:35.360 --> 06:41.080]  than the basic diagram which I'm showing here. However, we get more clarity when I try to compare
[06:41.080 --> 06:47.880]  it to a simple IoT implementation. All right. So, in this next diagram. So, as you can see over here,
[06:47.880 --> 06:53.000]  in this IoT threat model, this is like a very simple IoT architecture. I'm not even going into
[06:53.000 --> 06:58.340]  more complex ones. We aren't even talking about embedded devices and airplanes and the complex
[06:58.340 --> 07:03.700]  architectures. We're literally talking about a very simple architecture here. Specifically focusing
[07:03.700 --> 07:10.480]  only on smart and connected forms. I would say these are more of consumer IoT and less of enterprise
[07:10.480 --> 07:18.520]  IoT. So, in this case, what we are looking at is a connected user. So, a connected user is basically
[07:18.800 --> 07:24.220]  a user who is interacting with their smart device. Then in this case, we have segregated the network
[07:24.220 --> 07:32.140]  into separate sections. So, as you can see, we have proximity network. So, in a proximity network,
[07:32.140 --> 07:37.220]  you're considering to have physical. So, we basically consider a proximity network to have
[07:37.220 --> 07:44.120]  physical sensors, devices, and the IoT gateway itself. So, basically, that would generally be
[07:44.980 --> 07:51.280]  inside your house. Then devices are connected to the proximity network by let's say a smart ring,
[07:51.280 --> 07:56.480]  which the user might wear, or any smart device which the user might have in their home.
[07:56.480 --> 08:01.360]  Then apart from that, the user also interacts with the mobile app. So, a user basically has
[08:01.360 --> 08:07.560]  two avenues over here. One is in some cases to directly interact with the embedded sensor
[08:07.560 --> 08:13.820]  of their smart watch or device. And then another one is the mobile app or any web interface.
[08:14.020 --> 08:19.940]  Apart from that proximity network, we also talk about the cloud network. However, for IoT devices,
[08:19.940 --> 08:26.060]  prior to going to cloud, we also have to consider edge servers, as that is what separates them from
[08:26.060 --> 08:32.320]  most of the classic web app. IoT's preferred microservices architecture compared to most
[08:32.320 --> 08:38.060]  monolithic standard apps. Edge servers decreases the overall latency and increases the device
[08:38.060 --> 08:43.380]  efficiency. However, it might add some more attack surfaces in the overall architecture.
[08:43.380 --> 08:47.920]  Let's just talk about a couple of attack scenarios over here now. So, you can see that in the
[08:47.920 --> 08:54.820]  proximity network, where the devices communicate over BLE, CoAP, LoRaWAN, as these are close-range
[08:54.820 --> 08:59.220]  protocols and the devices are in proximity. Therefore, in proximity network, our main
[08:59.220 --> 09:04.280]  threat actors are generally the pre-installed malicious IoT devices, as they might try to
[09:04.280 --> 09:09.960]  replay or intercept the existing traffic. They might also exfiltrate that traffic out through
[09:09.960 --> 09:16.640]  the IoT gateway. Okay, now moving on to the mobile interface, we might have more attack surfaces,
[09:16.640 --> 09:23.940]  like, let's say, a malicious application on the user's device, which might try to
[09:23.940 --> 09:28.740]  directly interact with the device file system and processes in order to extract sensitive
[09:28.740 --> 09:36.660]  user-specific data from the IoT device application. Okay, so let me just come back to this. So, the
[09:36.660 --> 09:42.140]  main purpose to show this threat model here is that, generally, when we consider IoT threat models,
[09:42.140 --> 09:47.120]  we tend to focus on external threat actors, like an attacker compromising third-party cloud
[09:47.120 --> 09:53.520]  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:04.220]  But what about the attack surfaces that we least care about? What about those benign users on your
[10:04.220 --> 10:10.880]  home network, who exist on your home network, who also have updated operating systems, who have
[10:10.880 --> 10:16.280]  updated browser versions, and they're just casually running JavaScript? All right. So, in terms of
[10:16.280 --> 10:20.580]  IoT devices, specifically for connected home devices, a common pattern has been noticed that
[10:20.580 --> 10:26.180]  the device manufacturers tend to give the least priority to device security on local area network.
[10:26.220 --> 10:31.380]  As the devices are not directly accessible to the external network, therefore, it is generally
[10:31.380 --> 10:36.600]  assumed to be secure without physical access. As in most cases, the designers just consider that
[10:36.600 --> 10:42.120]  physical access to be the only possible gateway to the private network. That is why these devices
[10:42.120 --> 10:47.700]  have a variety of open ports and unauthenticated HTTP interfaces running on them, which can be
[10:47.700 --> 10:53.060]  directly controlled by anyone who is present on the home network. The best example of this was
[10:53.060 --> 11:02.020]  Google Home's unauthenticated HTTP API, which was literally patched in 2019. And it gave anyone on
[11:02.020 --> 11:07.480]  the local network to perform multiple actions, like rebooting the device or making any sort of
[11:07.480 --> 11:12.380]  modifications, which a normal user could have. When talking about this particular attack surface,
[11:12.380 --> 11:16.820]  it is considered that if an attacker has physical access to the device, then the network-based
[11:16.820 --> 11:24.360]  attack is among the lowest concern. And physical attacker access might open up some other serious
[11:24.360 --> 11:31.900]  concerns. So, this one is given less priority. However, what if this was not the only attack
[11:31.900 --> 11:38.340]  tree for the exploitation of these HTTP interfaces? All an attacker needs is a single
[11:38.340 --> 11:43.600]  public gateway to break into the private network. For a long time, home private networks have been
[11:43.600 --> 11:49.700]  pretty secure, as not everyone is running servers on their local host. Let's just be honest about
[11:49.700 --> 11:57.480]  that for a minute. Apart from developers and other people, not everybody is running or hosting an
[11:57.480 --> 12:04.020]  application on their local host networks. However, with the advent of IoT technology,
[12:04.020 --> 12:10.200]  IoT has literally given an exponential rise to a variety of web interfaces running on users'
[12:10.200 --> 12:16.380]  private network. In most cases, the user is totally unaware of all the accessible IPs and
[12:16.380 --> 12:22.080]  even open ports on their devices. The question is, what if an attacker was able to proxy into
[12:22.080 --> 12:27.160]  the private network through a public gate? Now moving ahead to our next section, attacks and
[12:27.160 --> 12:33.500]  exfiltration scenario. We would first like you all to do a very simple exercise. I'd like you all to
[12:33.500 --> 12:39.440]  fire up your terminal and make a simple request, that is, perform this following NSLOOKUP.
[12:40.460 --> 12:47.060]  Now, if it returns a local IP, then there is a very high chance that you might be vulnerable to
[12:47.060 --> 12:52.580]  DNS rewiring attacks. 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:11.260]  It translates the domain name like facebook.com, google.com to IP addresses. So browsers can load
[13:11.260 --> 13:16.860]  internet resources. These IP addresses are given to each device on the internet and they are
[13:16.860 --> 13:22.300]  necessary to find appropriate internet device. It's like a street address is used for a particular
[13:22.300 --> 13:28.500]  home, you know, to find that particular home in that particular location. So to understand how
[13:28.500 --> 13:34.080]  this translation is done, let us imagine a situation where a user is trying to access a
[13:34.080 --> 13:39.020]  website called shop-example.com because, you know, she's bored in this quarantine and
[13:39.020 --> 13:46.400]  wants to shop at least. So as a user types shop-example.com into a web browser, the query
[13:46.400 --> 13:53.340]  will traverse into the internet asking what is the IP address of shop-example.com and will be
[13:53.340 --> 14:01.120]  received by a DNS recursive resolver. Well, the next step is that if the recursive resolver has
[14:01.120 --> 14:07.320]  no answer, then the request will be passed on to the DNS root name server asking the same question
[14:07.320 --> 14:14.280]  at what is the IP address of shop-example.com. The root server will then respond with the address
[14:14.280 --> 14:22.940]  of a TLD. TLD is top-level domain server like .com or .net which stores the information for its
[14:22.940 --> 14:28.740]  domain. In this case, it will be .com. Once the address of TLD is received, the resolver then
[14:28.740 --> 14:35.380]  makes a request to the .com TLD. The TLD server will behave like a root server. I know this guy,
[14:35.380 --> 14:41.460]  you might know this guy and will respond with the IP address of the domain's main server. The
[14:41.460 --> 14:47.760]  recursive resolver then asks the domain main server where is the shop-example.com and then
[14:47.760 --> 14:55.320]  finally the main server will return the IP address of shop-example.com to the resolver with TLD.
[14:55.780 --> 15:01.260]  And lastly, the user's browser will have the requested IP address. Now the browser knows the
[15:01.260 --> 15:06.780]  IP address of the website, it is able to make the request for the shop-example.com as the
[15:06.780 --> 15:12.080]  request is offered, for instance, where the web server on the receiving the request will actually
[15:12.080 --> 15:18.660]  respond with that requested web page, you know, like 60% off. Wow, who doesn't like that?
[15:18.720 --> 15:24.660]  Well, we saw the complete flow to understand how DNS works. Instead of going through all this
[15:24.660 --> 15:30.100]  way and to improve the performance and reliability of data requests, this information is temporarily
[15:30.100 --> 15:36.700]  stored in the locations like browser, operating system, or recursive resolver. This is all DNS
[15:36.700 --> 15:42.500]  caching and the set amount of time for storing is known as time to live, in short TTL, as I said
[15:42.500 --> 15:50.780]  before. Well, let's take another situation into consideration. Okay, so I just, from the previous
[15:50.780 --> 15:56.480]  slide, I'd just like to focus on one thing, time to live. Please make a note of it, it'll be useful
[15:56.480 --> 16:02.160]  later. So, let's take another situation into consideration. Let's say that the user is trying
[16:02.160 --> 16:08.240]  to access some web page and there are some annoying ads on the web page. Among those, there is one
[16:08.240 --> 16:13.860]  malicious ad waiting for the user's attention. Since this ad has to be loaded from another domain,
[16:13.860 --> 16:18.820]  our browser has to fetch it. But loading a random JavaScript from some random domain will give the
[16:18.820 --> 16:24.120]  attacker access to load anything in our browser and authority to make requests to maybe our
[16:24.120 --> 16:31.680]  bank.com or access pages for, let's say, maybe from our smartphone devices. But you know what?
[16:31.680 --> 16:38.160]  There is something called same origin policy, which is actually a policy implemented by the
[16:38.160 --> 16:44.440]  browsers and which let the browser restrict this kind of behavior as they restrict and limit any
[16:44.440 --> 16:51.520]  sort of HTTP request which originates from one domain to access resources that are hosted on
[16:51.520 --> 16:57.880]  or served on another domain. So, to be specific, let's see an example. Okay. So, let's take a quick
[16:57.880 --> 17:02.960]  look at an example of how the same origin policy is able to protect resources from being accessed
[17:02.960 --> 17:07.880]  by malicious JavaScript running on websites across origins. So, in this example, we have a secrets
[17:07.880 --> 17:14.880]  file that is secrets.txt, which is located at test instance running on port 8053 that is accessible
[17:14.880 --> 17:19.340]  over HTTP. And we will see how the same origin policy can protect this resource from being
[17:19.340 --> 17:23.900]  accessed by malicious JavaScript running on a malicious origin. In this case, we are considering
[17:23.900 --> 17:31.220]  example.com to be that malicious origin. So, when we try to perform an XHR request. So, in the first
[17:31.220 --> 17:37.280]  example, it is of a totally different origin because here the host, that is example.com, as well as the
[17:37.280 --> 17:54.340]  port is totally different from the test instance. Okay. So, here you can see that the browser's
[17:54.340 --> 17:58.460]  same origin policy was able to block the malicious website from accessing the resource. As it said,
[17:58.460 --> 18:04.420]  they do not have the same origin due to them having totally different host as well as port. Okay.
[18:04.420 --> 18:11.740]  Now, we'll be looking at a different example. So, in this particular example, these two resources have
[18:11.740 --> 18:18.840]  the same host, that is testinstance.com. But they happen to have this totally different
[18:18.840 --> 18:26.020]  port numbers. One, the secrets was actually on 8053, whereas this resource is on 8056.
[18:26.020 --> 18:35.580]  And we can observe that. Okay. And in this case, when we try to perform a XML HTTP request,
[18:35.580 --> 18:44.480]  or basically a cross-site JavaScript fetch, we'll be able to see. Okay. So,
[18:44.480 --> 18:49.100]  as these two happen to have different port numbers, although they have the same
[18:49.100 --> 18:57.860]  host, the resource is still not able to access the secrets.txt, because the browser still
[18:57.860 --> 19:03.480]  considers this to be a totally different origin, because of them having totally different ports.
[19:03.480 --> 19:10.760]  Now, we will look at a standard example. This page is testinstance.com, and it has the same
[19:10.760 --> 19:17.560]  8053 port as our secret. So, this happened to match all the criteria that is required for
[19:19.160 --> 19:24.560]  a same origin, right? Then, in that case, we'll just try to see how exactly the same
[19:24.560 --> 19:33.080]  origin policy would allow this one to access the secret. So, in this case, as you can see,
[19:33.080 --> 19:40.120]  this was able to pass the same origin policy due to exactly the same host, the same protocol,
[19:40.120 --> 19:43.860]  as well as the same port number, because of which it was able to access the resource
[19:44.640 --> 19:52.480]  which was hosted, which was actually located at secrets.txt. So, that basically sums up the
[19:52.480 --> 19:59.540]  example of same origin policy. So, the question that arises here is, if SOP is actually preventing
[19:59.540 --> 20:08.060]  this kind of attack, then what is the threat? Well, DNS rewinding. DNS rewinding is a class
[20:08.060 --> 20:13.260]  of exploit in which the attacker initiates repeated DNS queries to a domain under their
[20:13.260 --> 20:19.420]  control. Consider the scenario where the user is comfortably surfing over the internet to access
[20:19.700 --> 20:25.000]  a web page containing some advertisement. Among those ads, there is one malicious ad,
[20:25.000 --> 20:30.980]  as Ivan stated before. As the web page is loaded, the browser will request the malicious DNS server
[20:30.980 --> 20:37.820]  querying the IP address of maliciousads.com. When receiving this request, the attacker-controlled
[20:37.820 --> 20:46.600]  DNS server responds with the real IP, let's say 1.2.3.4, and it also sets the TTL value
[20:46.600 --> 20:53.560]  on the response to be zero minutes or a few seconds, so that the user's machine won't cache
[20:53.560 --> 21:00.460]  for long. Now, let's wait for some time. Now, the malicious JavaScript makes another request
[21:00.460 --> 21:07.740]  to maliciousads.com. And since the TTL is exceeded, the IP of maliciousads.com isn't found in the
[21:07.740 --> 21:15.340]  cache. Therefore, the browser will again request the IP from the DNS server. But what? Wait!
[21:15.340 --> 21:22.680]  This time, on the user's subsequent DNS request, instead of the real IP, the maliciousads.com,
[21:22.680 --> 21:32.380]  the name server of maliciousads.com, will respond with the IP of 10.0.0.1, which happens to be an
[21:32.380 --> 21:36.980]  IP within the user's local space and belongs to an IoT device on the user's network.
[21:37.740 --> 21:43.880]  The user's browser will receive this malicious DNS response and will use this provided IP to
[21:43.880 --> 21:50.280]  make HTTP requests, which were intended for maliciousads.com. Because technically,
[21:50.280 --> 21:54.640]  there is no change for the browser according to the normal functioning. Because based on
[21:54.640 --> 22:01.160]  SOP, browser just sees the same name and goes, oh, we have the same name. So we are friends
[22:01.880 --> 22:09.080]  and allows all queries from the same origin, irrespective of the IPs. But the HTTP requests
[22:09.080 --> 22:14.400]  are now sent to the small unprotected web server running on the user's component.
[22:14.400 --> 22:20.120]  The same network where all your smart devices are connected and that's making your smart home
[22:20.120 --> 22:26.100]  unsafe. And that's behaving as a proxy between your private and public world. DNS rebinding
[22:26.100 --> 22:32.520]  attack can actually bypass network firewalls, security controls, such as false and make
[22:32.520 --> 22:38.240]  every device on your local network vulnerable and available to an attacker from anywhere
[22:38.240 --> 22:44.740]  outside your protected internet. Let us do theoretically. Now it's time to hack.
[22:44.740 --> 22:48.400]  Okay. So in this example, the first thing that we'll be talking about is a router interface
[22:48.400 --> 22:52.440]  that allows anyone on the network to access the router controls once they have authenticated.
[22:52.440 --> 22:55.800]  However, even prior to the authentication, this allows users on the home network to access the
[22:55.800 --> 23:01.140]  list of all the connected devices. So let's see how a user on this private network can become
[23:01.140 --> 23:04.900]  vulnerable to the DNS rebinding attack by just navigating to a website that looks totally benign.
[23:04.900 --> 23:08.920]  In this case, cute videos. Because you know what? Who does not like cute animals?
[23:09.200 --> 23:14.240]  So as you can see in the developer options in the network request, you can see even before
[23:14.240 --> 23:18.680]  the page was loaded, the malicious host on the page initiated a port scan in the local network
[23:18.680 --> 23:23.200]  in order to identify the router interface. Router is an easily identifiable target in most of the
[23:23.200 --> 23:27.640]  because standard IP of their default gateways and therefore it is easy to scan
[23:27.640 --> 23:32.920]  compared to other devices. So here it has already identified 10.0.0.2.
[23:33.080 --> 23:38.420]  And now automatically it has started sending the JavaScript on the page has already started
[23:38.420 --> 23:46.160]  sending multiple requests from the page to the external URL. And now this page is basically just
[23:46.160 --> 23:51.600]  waiting for the DNS to be DNS records to be updated. So this video is already 11 minutes
[23:51.600 --> 23:58.800]  long. And that's like already enough time for an attacker to perform the DNS rewinding attack.
[23:58.800 --> 24:05.360]  So by the time the attacker so by the time you're even watching first 20 seconds of the video,
[24:05.360 --> 24:12.600]  the attacker has already been able to rewind and has been sent internal request to 10.0.0.2.
[24:12.600 --> 24:18.540]  And now we'll move to the attackers panel. So here you can see a WebSocket connection has been
[24:18.540 --> 24:25.740]  made based on which the attacker would be able to actually access things on the internal network.
[24:25.740 --> 24:30.920]  So now you can see the remote address has been updated from the attacker's IP address to the
[24:30.920 --> 24:35.540]  internal IP address. And based on that, the attacker is now able to any request that has
[24:35.540 --> 24:41.800]  been performed to the origin by the JavaScript is actually helping the attacker to communicate
[24:41.800 --> 24:47.840]  with the internal services that is running on your router. So now we'll just try some generic
[24:47.840 --> 24:52.120]  passwords. Oh, in this case, we just tried admin admin and that definitely worked because
[24:52.940 --> 24:57.900]  a lot of routers, whether we want to accept it or not, are still working on default passwords.
[24:57.900 --> 25:04.700]  So this gives any attacker multiple functionalities like setting the functionality
[25:04.700 --> 25:11.240]  of the router, modifying passwords, and this also allows them to enable UPnP, which might
[25:11.240 --> 25:16.320]  make them vulnerable to multiple other vulnerabilities apart from this. It also allows the attacker to
[25:17.000 --> 25:23.380]  remotely reset or reboot the device. Also, it gives an attacker full functionality to modify
[25:23.380 --> 25:28.520]  your DNS servers and thus serving you all the malicious websites that they want to.
[25:28.520 --> 25:33.360]  Also, they can just proxy your entire network and that would help them to take over other
[25:33.360 --> 25:41.420]  multiple devices on your network as well. So that would be, in short, pretty bad. And over here,
[25:41.420 --> 25:46.800]  you can see all those requests. So in this case, password update page that was being
[25:46.800 --> 25:52.160]  fetched by the attacker. So all these requests were actually being made to the external attacker's
[25:52.160 --> 25:58.900]  origin. However, the remote address was routed to 10.0.0.2, which was the router's IP. So by
[25:58.900 --> 26:05.200]  the time you're busy watching the cute dog, your entire router and the network has been taken over.
[26:08.750 --> 26:12.870]  All right, so for the second demonstration, we will be looking at a baby monitor. So
[26:12.870 --> 26:17.370]  based on the router's exploitation, the attacker already got to know more information about
[26:17.370 --> 26:21.190]  what all other devices exist on the local network. In this case,
[26:21.190 --> 26:26.290]  the attacker was able to identify there's a baby monitor running on 10.0.0.182.
[26:26.390 --> 26:33.310]  So for our demonstration purpose, there is a baby monitor and there is the baby root,
[26:33.310 --> 26:39.730]  just to show you it's live. There you go. So this baby monitor software had a couple of
[26:39.730 --> 26:45.930]  functionalities. It can connect to multiple other cameras on the same network. And this
[26:45.930 --> 26:51.890]  feed is accessible to anyone on the local network. So you can select all of the cameras. As you can
[26:51.890 --> 26:57.650]  see, there are three cameras here. Apart from that, it has functionalities to send commands
[26:57.650 --> 27:02.650]  to different cameras, like getting images. And it also has options of privacy toggle.
[27:02.650 --> 27:08.670]  Then you can see camera three is disabled. So it also gives an option to specifically put an IP
[27:08.670 --> 27:14.350]  and find a camera, if in case it is disabled. Moving on to the attack, we'll be using the
[27:14.350 --> 27:20.390]  tool Singularity. We'll put in the IP, the port, and then we'll be going for
[27:20.390 --> 27:26.310]  hook and control, because we actually want to watch the video, right? And the time interval is
[27:26.310 --> 27:32.250]  set to seven seconds, and we start the attack. Let's look at the developer console. So this way,
[27:32.250 --> 27:37.550]  we can see that every seven seconds, a request is being sent, and it is waiting for a DNS update.
[27:38.410 --> 27:45.410]  And there you go, as the DNS update was made. In this case, let's move on to the attacker's
[27:45.410 --> 27:51.150]  window. Here, you can see that the attacker... there you go. So the attacker is actually able
[27:51.150 --> 27:58.630]  to get a live feed, right? Also, the attacker can try to now perform queries, and in order to
[27:58.630 --> 28:04.210]  identify what all other IPs might be there on the network. So this would be really helpful for an
[28:04.210 --> 28:10.170]  attacker. So the attacker can also try to exploit things like maybe a command injection, which is
[28:10.170 --> 28:16.490]  definitely the case over here. So we'll just try to perform a curl request from the camera's
[28:16.490 --> 28:22.690]  interface to an external webhook that the attacker controls, in order to see if we'll be able to
[28:23.250 --> 28:29.670]  extract more information by performing cat, as well, in order to extract sensitive files,
[28:29.670 --> 28:35.470]  and also to perform curl to the external endpoint of the attacker, which would be very helpful
[28:35.470 --> 28:45.430]  in order to set up a connection, so that the attacker can then use the camera more like a bot.
[28:45.630 --> 28:51.290]  So over here, you can see that the ping request was successful, then the information was also
[28:51.290 --> 28:57.410]  extracted, and here you can see that there was an incoming request to the attacker's webhook
[28:57.410 --> 29:02.710]  from the baby monitor itself. As you can see over here, the request is coming from
[29:02.710 --> 29:08.410]  group. So this basically shows that, okay, the attacker's command, the curl command which the
[29:08.410 --> 29:13.510]  attacker executed, was successful. So now the attacker can actually exfiltrate a lot of
[29:13.510 --> 29:21.650]  information by exploiting the command execution vulnerability. So that's how basically like
[29:21.650 --> 29:26.950]  attacker can exploit it in this particular case. So for the third demonstration, we'll be looking
[29:26.950 --> 29:31.830]  at a smart home panel. So this is not at all a hypothetical scenario. This is something which
[29:31.830 --> 29:37.870]  we have seen very commonly. So this device is actually a smart home panel, which is kept
[29:37.870 --> 29:42.170]  unauthenticated because it is supposed to be accessible only on a local area network,
[29:42.170 --> 29:48.750]  and it is supposed to be placed inside of a tablet, and then it can behave more like a control
[29:48.750 --> 29:54.330]  panel, and it can access all these functionalities. As you can see over here, the lights, thermostats,
[29:54.330 --> 30:00.450]  and everything from a single control panel. So that is why these kind of devices are like pretty
[30:00.450 --> 30:06.730]  common on a local area network, and they are generally kept unauthenticated. Talking about
[30:07.430 --> 30:13.490]  a rebind attack on this particular device, we'll be again using the tool called Singularity.
[30:13.530 --> 30:19.470]  And in this case, we'll be doing hook and control. So over here, we can see once the DNS has
[30:19.470 --> 30:27.150]  been updated to 10.0.0.211, that is the IP of the smart panel in this case, then all the
[30:27.150 --> 30:34.410]  requests from the attacker's domain will actually be made to the result IP of the smart home panel
[30:35.130 --> 30:41.830]  on the port 8081, and that would basically allow an attacker to establish the web socket connection.
[30:41.990 --> 30:49.170]  So as you can see over here, the DNS rebinding attack is successful. So now you can look at
[30:49.470 --> 30:55.450]  the attacker's panel. So the attacker over here is able to take a direct control of the
[30:55.850 --> 31:00.790]  smart home panel remotely, and now the attacker can literally set it to night mode, day mode.
[31:00.830 --> 31:07.010]  And over here, the attacker also has the ability to enable or disable the alarms. So now for this
[31:07.010 --> 31:13.310]  application, we explicitly specified and disabled host check and made it vulnerable just for the
[31:13.310 --> 31:18.030]  demonstration purpose. But if we could just make that minor tweak in the configuration and enable
[31:18.030 --> 31:24.910]  host header validation, so you can see we have enabled it and now we'll be reconfiguring the
[31:24.910 --> 31:30.390]  application. So now in this case, let's try to again perform the same attack after enabling
[31:30.390 --> 31:38.130]  host header validation. So we are going to perform the exact same attack on the application. Let's
[31:38.130 --> 31:46.370]  see what exactly happens this time. So over here, the attack is probably again going to say that it
[31:46.370 --> 31:51.850]  was successful. So you can see it shows that it was successful. Moving on to the attacker's window,
[31:51.850 --> 31:58.650]  let's see how exactly host header would prevent. So when it is trying to access, the attacker is
[31:58.650 --> 32:04.810]  presented a screen showing invalid host header because there was a clear mismatch between the
[32:04.810 --> 32:10.530]  host headers. So this was actually prevented by the application's built-in host header validation.
[32:11.130 --> 32:17.690]  Okay. So we have already seen that how someone can actually exploit this. But now the main
[32:17.690 --> 32:25.470]  question that is, okay, this attack is already known, right? So why does it still exist? So let's
[32:25.470 --> 32:30.850]  just talk about what are the main reasons because of which it is still there. So IoT devices, one of
[32:30.850 --> 32:36.950]  the main reasons is IoT devices are available at cheap prices with almost less or no security.
[32:36.950 --> 32:42.850]  Because there has been an explosion of very cheap and smart devices and vendors who focus more on
[32:42.850 --> 32:48.230]  adding functionality compared to security measures. They do not undergo thorough pen testing
[32:48.230 --> 32:54.010]  or any security compliance check at all. We see a smart device providing such a smart feature at low
[32:54.010 --> 33:00.290]  cost. We add it to our cart and purchase it right away. We as a customer do not understand that the
[33:00.290 --> 33:05.650]  cheap cost also comes at a price that is paid by the lack of research, development, and security
[33:05.650 --> 33:10.970]  measures. Moreover, DNS rebinding bugs have a history of being dismissed by developers and
[33:10.970 --> 33:17.230]  product designers and many times it is left as an unaddressed issue because many of them are not
[33:17.230 --> 33:23.750]  aware of this threat. Apart from this, any specific mitigation for removal might go against the
[33:23.750 --> 33:31.070]  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:43.430]  So some of the common ways an individual or organization can prevent such kind of things would
[33:43.430 --> 33:51.650]  be to... the ISP should actually configure their DNS servers in a way that would block DNS responses
[33:51.650 --> 33:57.890]  which contain local IP addresses. Additionally, the device passwords should be changed and the
[33:57.890 --> 34:03.950]  firmware should be updated. So this is something very specific for individuals. They should not
[34:03.950 --> 34:10.630]  keep their device passwords as default because as we already showed in the demo, how a router was
[34:10.630 --> 34:17.970]  exploited was mostly because of default passwords being used. Also, one of the good things that
[34:17.970 --> 34:23.130]  an organization should do would be to make developers more aware of such threat vectors as
[34:23.130 --> 34:29.150]  well. There should be... they should perform extensive penetration testing of devices before
[34:29.150 --> 34:35.790]  rolling them out. Also, investing in threat modeling to identify such issues in the initial
[34:35.790 --> 34:41.870]  stages would be a great effort. Additionally, internal network segmentation. So basically,
[34:41.870 --> 34:47.110]  for anyone who is actually trying to have IoT devices on their network, they should have multiple
[34:47.110 --> 34:53.270]  routes in internal network categorized for IoT devices. Now, we move on to roles of developers
[34:53.270 --> 34:59.410]  and pen testers. So talking about developer and pen tester roles, pen testers, it would be great
[34:59.410 --> 35:05.930]  to actually know about this attack and to perform this kind of attack in almost all their
[35:05.930 --> 35:11.730]  web gaming instances because this is a type of attack which would actually help them to bypass
[35:11.730 --> 35:17.570]  the firewall restrictions, bypass SOP, and still being able to get into a private network and then
[35:17.570 --> 35:22.050]  pivot to other devices. Apart from that, for developers, we would suggest host header validation
[35:22.050 --> 35:29.550]  is one of the most efficient ways of handling an attack like this. Also, the developers should
[35:29.550 --> 35:34.850]  make sure that they provide proper authentication for all the local services. Additionally,
[35:35.630 --> 35:42.430]  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:54.370]  Well, we saw how host header validation could prevent such attacks and the roles of organization,
[35:54.370 --> 35:59.550]  individuals, and developers in the prevention of the industry binding attack scenarios.
[35:59.550 --> 36:05.490]  But what about us? Exactly! We have created a browser extension called Securarity,
[36:06.110 --> 36:11.910]  which intends to detect such attacks and keep users safe while browsing such malicious websites.
[36:11.910 --> 36:18.510]  So let's see what we have in this tool. Securarity is a simple extension tool that monitors malicious
[36:18.510 --> 36:24.090]  behavior of domains which intend to scan the consumer's local network for internal IPs and
[36:24.090 --> 36:30.870]  port scans. Our extension provides a list of ports and IP addresses scanned by any host and
[36:30.870 --> 36:36.850]  also notifies the consumer if it detects any rewinding attack or if any website scans your
[36:36.850 --> 36:43.630]  private network. But the question is, does it prevent rewinding attacks? Yes! Once the attack
[36:43.630 --> 36:49.570]  is detected, the extension will automatically block the further request from the requested URL,
[36:49.570 --> 36:55.490]  thus preventing the attacker from using the consumer browser as a proxy for further intervention.
[36:56.870 --> 37:02.410]  Moreover, in this extension, we have integrated the Shodan API, which helps us in identifying the
[37:02.410 --> 37:08.830]  information like IP and hostname for the possible malicious domains and perform a port scan on the
[37:08.830 --> 37:16.230]  attacker's domain. We have also provided an option of manually blocking all HTTP requests based on
[37:16.230 --> 37:21.770]  user-provided URL patterns. We can simply use a blockage feature of this tool which will prevent
[37:21.770 --> 37:28.670]  such sites from scanning your local network or to perform a DNS rewind attack. However, while
[37:28.670 --> 37:34.310]  working from home and testing this code, we observed that there are some instances where we do not want
[37:34.310 --> 37:39.810]  to flag a domain as potentially malicious, specifically in cases where I'm working on a VPN
[37:39.810 --> 37:45.510]  and therefore the extension keeps on flagging all internal IP requests as a potential attack.
[37:45.510 --> 37:52.850]  So for that, we have also created an allow list to bypass monitoring. Let's now talk about how
[37:52.850 --> 37:59.750]  this extension works precisely. So how the extension is identifying inter-access scams?
[37:59.750 --> 38:05.910]  The DNS IP translations are done through the Chrome's web request API. The request object and
[38:05.910 --> 38:11.610]  the target IP is fetched and checked for the private scanning conditions. The extension notifies
[38:11.610 --> 38:17.830]  whenever the case occurs on scanning private IPs and on-click displays the details taken from the
[38:17.830 --> 38:24.470]  data object. How is it identifying rewinding attacks? Similarly, utilizing the web request
[38:24.470 --> 38:31.270]  API, the detect rewinding functions take that IP and original domain name data to process for
[38:31.270 --> 38:37.030]  detecting if rewinding occurs or not, for which it first validates against a set of predicts
[38:37.030 --> 38:44.150]  compliant to RFC-1918 and compares against the target hosting. It validates if the hosting
[38:44.150 --> 38:50.130]  resolves to a private IP and if hosting is itself not a private IP. When found true
[38:50.130 --> 38:56.310]  for these all set of conditions, it then flags the rewinding as true and notifies the user with
[38:56.310 --> 39:03.830]  details displayed in the table on-click. Let's see how it is blocking the SLA build. So in our
[39:03.830 --> 39:09.610]  extensions block functionality, we first check the valid input from the user for the domain name
[39:09.610 --> 39:14.270]  and then provide this valid pattern or URL to the Chrome's web request block request function
[39:14.270 --> 39:19.970]  in order to prevent fetching this particular hosting. Post permissions and content strip
[39:19.970 --> 39:26.350]  matching are based on a set of URLs defined by match patterns, which permits a variety of schemes
[39:26.350 --> 39:34.830]  like HTTP, HTTPS, FILE or FTP and also the wildcard characters. But how are we using Shodan API for
[39:34.830 --> 39:41.870]  hosting? We are using the standard Shodan API to fetch details about the malicious host. The
[39:41.870 --> 39:46.950]  API is used to resolve the hosting to the corresponding IP address, which then is used
[39:46.950 --> 39:52.730]  to perform Shodan host lookup for fetching open quotes and any other information that Shodan has
[39:52.730 --> 39:59.790]  about the malicious host. Okay, so let's see how the allow list is implemented. Similar to block
[39:59.790 --> 40:05.770]  list, we use match patterns for generating the allow list based on the user input and then that
[40:05.770 --> 40:12.070]  is compared against the set of scanned private IPs to not flag them as potentially malicious.
[40:12.070 --> 40:18.770]  Therefore, preventing notifications and hostname blocking. Now coming to the major feature of our
[40:18.770 --> 40:25.490]  extension, that is how secure IoT is preventing the DNS rewinding attack, in addition to notifying
[40:25.490 --> 40:30.870]  all the aforementioned features. So once the rewinding is detected from the detect
[40:30.870 --> 40:35.570]  rewinding function, the block rewind function blocks a further request made by the attacker's
[40:35.570 --> 40:41.210]  request URL on the internal IP addresses, thus automatically preventing the attack and detects
[40:41.210 --> 40:48.710]  filtration. Now we can move to the demonstration and see how the tool works. We are still
[40:48.710 --> 40:53.270]  working on this tool and aim to add features like sending monitoring updates to the users,
[40:53.270 --> 40:57.870]  their mobile device and other smart assistant devices on the home network. We also plan to
[40:57.870 --> 41:02.730]  further improve and add support for other browsers like Firefox and of course some beauty features
[41:02.730 --> 41:07.910]  because we understand that user experience should be convenient. So now moving on, let us see the
[41:07.910 --> 41:17.370]  implementation. So here is the extension. We will now just try to scan. As you can see, it will
[41:17.370 --> 41:22.870]  display scan results and you can now see the list of details that the scanner is doing, IP,
[41:22.870 --> 41:30.670]  code and timestamp. We can use the search for specific needs like a certain group number
[41:30.670 --> 41:39.730]  or a specific IP. Apart from the scan, we have other features
[41:42.590 --> 41:47.110]  like this one where we can see the information about the host,
[41:47.110 --> 41:50.150]  what ports are open, location etc.
[41:52.590 --> 41:57.870]  Okay, let us now see the rewinding detection feature. For that, we will now execute
[41:59.270 --> 42:04.130]  a rewinding attack and see if our tool is able to function as discussed before.
[42:04.130 --> 42:09.490]  So we will do a simple fetch and get. 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:27.730]  Okay, so we can see the rewinding attack is successful. Also, our tool has notified us
[42:27.730 --> 42:34.090]  and it's time to check the details. 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 --> 43:00.790]  We can test it with, say, rewind.it and save.
[43:02.810 --> 43:07.890]  Now we will go to the rewind.it page we were using and reload it. Well, it works. So if the
[43:07.890 --> 43:14.750]  rewind is blocked, we can take another example. Let's say block.com. We will add this one as well
[43:14.750 --> 43:29.020]  and try to block it. And hit the save to see if it is blocked or not. Now you go back and
[43:29.020 --> 43:37.220]  reload the page for the blogger. And it is blocked. We can also test this case for iframes
[43:37.220 --> 43:41.860]  also, much relatable to the example of the malicious ad that we have seen before. So you
[43:41.860 --> 43:46.640]  can see that it is blocked by the extension and this will prevent any subsites from loading any
[43:46.640 --> 43:51.440]  malicious ads. Now moving on to the allow list feature, where we can specifically tell the
[43:51.440 --> 43:58.220]  extension that it should not flag any request from this domain. 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:39.320]  So now we can scan from some other site to see if the function is normal. So let's check here.
[44:40.260 --> 44:47.180]  It will scan and notify us with a display of details. Let's see if it works exactly.
[44:47.320 --> 44:50.760]  So this is it. And we can see the details here.
[44:55.900 --> 45:00.760]  Okay, now we will be seeing how the extension is preventing attacks. So as you can see,
[45:00.760 --> 45:04.400]  this is the router which is hosted here. Now we'll be trying to perform
[45:06.180 --> 45:09.040]  a hook and control in the rewind.it.
[45:10.460 --> 45:20.400]  And see how it is preventing. 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:33.970]  Okay, so we can see there were successful socket connection
[45:33.970 --> 45:37.690]  and our extension is able to detect the DNS rewind.
[45:39.170 --> 45:46.730]  But the next thing this extension did is to block the URL. 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:03.390]  So here the attacker will try to load the panel and we can check if he is able to load
[46:03.390 --> 46:08.610]  actually or not. So it's trying to fetch the page and we can see in the inspect
[46:09.230 --> 46:13.710]  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:27.120]  Therefore, we can see that even though the attacker is trying to fetch the information,
[46:27.120 --> 46:30.740]  that he won't be able to. And we'll just keep on reading.
[46:30.760 --> 46:36.420]  So that basically concludes our talk. We'll soon be launching the code for security
[46:36.420 --> 46:40.180]  on our GitHub after some modifications and bug fixes.
[46:40.740 --> 46:46.160]  And that's it. So thanks a lot for making it till the end and stay safe.