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.
Wow, it's been a crazy year. 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.
Things have changed drastically. In this time when everything is getting cancelled,
I'm so delighted that at least we still have DEF CON. Welcome to the new normal.
Thanks for joining in. 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. Now, before moving ahead, we would like to introduce ourselves.
So, just a little bit about us. My name is Devan Kwan, and I work as a security consultant with
the NCC group. I have multiple areas of interest, but the most recent one being IoT and radio
hacking. 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. It is the first talk that I have ever given, and therefore, just a heads up to you
guys. The talk would be pretty business friendly, and we'd go over a lot of basic topics as well.
Now, passing on to my co-presenter. Thank you, Devan. Hello, everyone. My name is Shruti
I'm a computer scientist working in IoT research and development at Nexus in France. I have three
plus years of experience in IoT development for smart home, autonomous vehicles, indoor and
virtual locations, precisely. 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. I'm also an independent
researcher. I'm very passionate about IoT development, secure smart system, teaching,
and women empowerment. 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. It's like a very boring history, including
introduction for our talk. Well, it will be followed by the section discussing its security
parameters. 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. 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.
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. Well, our connected world. Okay, so are you
telling me that anyone on the internet can talk to my fridge? 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. Even including this talk, completely online, and where we are missing the
real interaction with the crowd and nervousness in the presenters like us. Although we are really
nervous, but thanks to internet of things, from wearable devices and portable technologies to
health-related accessories, IoT is everywhere. 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.
But the question is how exactly it all started. 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. 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.
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.
Showcasing its talent, IoT has fascinated things from eating unbotted coffee to turning off the
lights when we go to sleep at night. I swear to God, that thing has made me so lazy.
This is the reason why dependability has been exponentially increasing. 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. From smart homes, smart healthcare, smart city,
and what not, we want everything to be smarter now. And this means,
I literally have no idea how to even say this number right.
But moving on to how safe my world is, I'll pass on to you, Devang.
All right. So, what if I just tell you that the S in IoT actually stands for security? Yes, that is
true. So, talking about how safe my world is, with billions of devices connecting the whole world,
we care a lot about functioning, right? We want things to be done in just one click. We want
things faster with less or almost no effort. Better be functioning soon, be click to buy in
Amazon, Alibaba, or wherever you guys shop. But we need to understand that there's a need for
security on so many levels. So, we should first look and compare the threat models in terms of
classic web applications and then in terms of IoT devices. Over here, we see a simple web app
server connecting to a SQL database. Then we have a third party web service and cloud storage.
They all have their own corporate trust boundary and vendor trust boundary. And then we talk about
the human user. The human user is actually directly interacting with the web application.
And then they all are being separated by separate privileged levels and their own trust boundaries.
So, as you can see, definitely in no way I'm saying that web applications are extremely similar.
Trust me, I would never say that. They can definitely and more certainly are more complex
than the basic diagram which I'm showing here. However, we get more clarity when I try to compare
it to a simple IoT implementation. All right. So, in this next diagram. So, as you can see over here,
in this IoT threat model, this is like a very simple IoT architecture. I'm not even going into
more complex ones. We aren't even talking about embedded devices and airplanes and the complex
architectures. We're literally talking about a very simple architecture here. Specifically focusing
only on smart and connected forms. I would say these are more of consumer IoT and less of enterprise
IoT. So, in this case, what we are looking at is a connected user. So, a connected user is basically
a user who is interacting with their smart device. Then in this case, we have segregated the network
into separate sections. So, as you can see, we have proximity network. So, in a proximity network,
you're considering to have physical. So, we basically consider a proximity network to have
physical sensors, devices, and the IoT gateway itself. So, basically, that would generally be
inside your house. 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.
Then apart from that, the user also interacts with the mobile app. So, a user basically has
two avenues over here. One is in some cases to directly interact with the embedded sensor
of their smart watch or device. And then another one is the mobile app or any web interface.
Apart from that proximity network, we also talk about the cloud network. 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. IoT's preferred microservices architecture compared to most
monolithic standard apps. Edge servers decreases the overall latency and increases the device
efficiency. However, it might add some more attack surfaces in the overall architecture.
Let's just talk about a couple of attack scenarios over here now. 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. 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. They might also exfiltrate that traffic out through
the IoT gateway. 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. Okay, so let me just come back to this. 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.
So, basically, when talking about IoT, these are the attack surfaces we most care about.
But what about the attack surfaces that we least care about? 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? All right. 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.
As the devices are not directly accessible to the external network, therefore, it is generally
assumed to be secure without physical access. As in most cases, the designers just consider that
physical access to be the only possible gateway to the private network. 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. The best example of this was
Google Home's unauthenticated HTTP API, which was literally patched in 2019. 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. 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. And physical attacker access might open up some other serious
concerns. So, this one is given less priority. However, what if this was not the only attack
tree for the exploitation of these HTTP interfaces? All an attacker needs is a single
public gateway to break into the private network. For a long time, home private networks have been
pretty secure, as not everyone is running servers on their local host. Let's just be honest about
that for a minute. Apart from developers and other people, not everybody is running or hosting an
application on their local host networks. 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. In most cases, the user is totally unaware of all the accessible IPs and
even open ports on their devices. The question is, what if an attacker was able to proxy into
the private network through a public gate? Now moving ahead to our next section, attacks and
exfiltration scenario. We would first like you all to do a very simple exercise. I'd like you all to
fire up your terminal and make a simple request, that is, perform this following NSLOOKUP.
Now, if it returns a local IP, then there is a very high chance that you might be vulnerable to
DNS rewiring attacks. Now look at what exactly the attack looks like.
But for that, we need a quick refresher of how exactly DNS works.
Well, we all know that a DNS is like an address directory of the internet.
It translates the domain name like facebook.com, google.com to IP addresses. So browsers can load
internet resources. These IP addresses are given to each device on the internet and they are
necessary to find appropriate internet device. It's like a street address is used for a particular
home, you know, to find that particular home in that particular location. 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. 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. 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. The root server will then respond with the address
of a TLD. TLD is top-level domain server like .com or .net which stores the information for its
domain. In this case, it will be .com. Once the address of TLD is received, the resolver then
makes a request to the .com TLD. The TLD server will behave like a root server. I know this guy,
you might know this guy and will respond with the IP address of the domain's main server. 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.
And lastly, the user's browser will have the requested IP address. 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, you know, like 60% off. Wow, who doesn't like that?
Well, we saw the complete flow to understand how DNS works. 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. 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. Well, let's take another situation into consideration. Okay, so I just, from the previous
slide, I'd just like to focus on one thing, time to live. Please make a note of it, it'll be useful
later. So, let's take another situation into consideration. Let's say that the user is trying
to access some web page and there are some annoying ads on the web page. Among those, there is one
malicious ad waiting for the user's attention. Since this ad has to be loaded from another domain,
our browser has to fetch it. 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. But you know what?
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. So, to be specific, let's see an example. Okay. 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. 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. And we will see how the same origin policy can protect this resource from being
accessed by malicious JavaScript running on a malicious origin. In this case, we are considering
example.com to be that malicious origin. So, when we try to perform an XHR request. 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. Okay. So, here you can see that the browser's
same origin policy was able to block the malicious website from accessing the resource. As it said,
they do not have the same origin due to them having totally different host as well as port. Okay.
Now, we'll be looking at a different example. So, in this particular example, these two resources have
the same host, that is testinstance.com. But they happen to have this totally different
port numbers. One, the secrets was actually on 8053, whereas this resource is on 8056.
And we can observe that. Okay. 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. Okay. 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.
Now, we will look at a standard example. This page is testinstance.com, and it has the same
8053 port as our secret. So, this happened to match all the criteria that is required for
a same origin, right? Then, in that case, we'll just try to see how exactly the same
origin policy would allow this one to access the secret. 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. So, that basically sums up the
example of same origin policy. So, the question that arises here is, if SOP is actually preventing
this kind of attack, then what is the threat? Well, DNS rewinding. DNS rewinding is a class
of exploit in which the attacker initiates repeated DNS queries to a domain under their
control. Consider the scenario where the user is comfortably surfing over the internet to access
a web page containing some advertisement. Among those ads, there is one malicious ad,
as Ivan stated before. As the web page is loaded, the browser will request the malicious DNS server
querying the IP address of maliciousads.com. 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. Now, let's wait for some time. Now, the malicious JavaScript makes another request
to maliciousads.com. And since the TTL is exceeded, the IP of maliciousads.com isn't found in the
cache. Therefore, the browser will again request the IP from the DNS server. But what? Wait!
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.
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. Because technically,
there is no change for the browser according to the normal functioning. Because based on
SOP, browser just sees the same name and goes, oh, we have the same name. So we are friends
and allows all queries from the same origin, irrespective of the IPs. But the HTTP requests
are now sent to the small unprotected web server running on the user's component.
The same network where all your smart devices are connected and that's making your smart home
unsafe. And that's behaving as a proxy between your private and public world. 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. Let us do theoretically. Now it's time to hack.
Okay. 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.
However, even prior to the authentication, this allows users on the home network to access the
list of all the connected devices. 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.
In this case, cute videos. Because you know what? Who does not like cute animals?
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. 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. So here it has already identified 10.0.0.2.
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. And now this page is basically just
waiting for the DNS to be DNS records to be updated. So this video is already 11 minutes
long. And that's like already enough time for an attacker to perform the DNS rewinding attack.
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.
And now we'll move to the attackers panel. 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.
So now you can see the remote address has been updated from the attacker's IP address to the
internal IP address. 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. So now we'll just try some generic
passwords. 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.
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. It also allows the attacker to
remotely reset or reboot the device. Also, it gives an attacker full functionality to modify
your DNS servers and thus serving you all the malicious websites that they want to.
Also, they can just proxy your entire network and that would help them to take over other
multiple devices on your network as well. So that would be, in short, pretty bad. And over here,
you can see all those requests. So in this case, password update page that was being
fetched by the attacker. So all these requests were actually being made to the external attacker's
origin. However, the remote address was routed to 10.0.0.2, which was the router's IP. So by
the time you're busy watching the cute dog, your entire router and the network has been taken over.
All right, so for the second demonstration, we will be looking at a baby monitor. 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. In this case,
the attacker was able to identify there's a baby monitor running on 10.0.0.182.
So for our demonstration purpose, there is a baby monitor and there is the baby root,
just to show you it's live. There you go. So this baby monitor software had a couple of
functionalities. It can connect to multiple other cameras on the same network. And this
feed is accessible to anyone on the local network. So you can select all of the cameras. As you can
see, there are three cameras here. Apart from that, it has functionalities to send commands
to different cameras, like getting images. And it also has options of privacy toggle.
Then you can see camera three is disabled. So it also gives an option to specifically put an IP
and find a camera, if in case it is disabled. Moving on to the attack, we'll be using the
tool Singularity. 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? And the time interval is
set to seven seconds, and we start the attack. Let's look at the developer console. So this way,
we can see that every seven seconds, a request is being sent, and it is waiting for a DNS update.
And there you go, as the DNS update was made. In this case, let's move on to the attacker's
window. Here, you can see that the attacker... there you go. So the attacker is actually able
to get a live feed, right? Also, the attacker can try to now perform queries, and in order to
identify what all other IPs might be there on the network. So this would be really helpful for an
attacker. So the attacker can also try to exploit things like maybe a command injection, which is
definitely the case over here. 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, 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.
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. As you can see over here, the request is coming from
group. So this basically shows that, okay, the attacker's command, the curl command which the
attacker executed, was successful. So now the attacker can actually exfiltrate a lot of
information by exploiting the command execution vulnerability. So that's how basically like
attacker can exploit it in this particular case. So for the third demonstration, we'll be looking
at a smart home panel. So this is not at all a hypothetical scenario. This is something which
we have seen very commonly. 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. As you can see over here, the lights, thermostats,
and everything from a single control panel. So that is why these kind of devices are like pretty
common on a local area network, and they are generally kept unauthenticated. Talking about
a rebind attack on this particular device, we'll be again using the tool called Singularity.
And in this case, we'll be doing hook and control. 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.
So as you can see over here, the DNS rebinding attack is successful. So now you can look at
the attacker's panel. 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.
And over here, the attacker also has the ability to enable or disable the alarms. So now for this
application, we explicitly specified and disabled host check and made it vulnerable just for the
demonstration purpose. 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. So now in this case, let's try to again perform the same attack after enabling
host header validation. So we are going to perform the exact same attack on the application. Let's
see what exactly happens this time. So over here, the attack is probably again going to say that it
was successful. So you can see it shows that it was successful. Moving on to the attacker's window,
let's see how exactly host header would prevent. 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. So this was actually prevented by the application's built-in host header validation.
Okay. So we have already seen that how someone can actually exploit this. But now the main
question that is, okay, this attack is already known, right? So why does it still exist? So let's
just talk about what are the main reasons because of which it is still there. So IoT devices, one of
the main reasons is IoT devices are available at cheap prices with almost less or no security.
Because there has been an explosion of very cheap and smart devices and vendors who focus more on
adding functionality compared to security measures. They do not undergo thorough pen testing
or any security compliance check at all. We see a smart device providing such a smart feature at low
cost. We add it to our cart and purchase it right away. 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. 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. 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.
So the next question that we ask is what individuals and organizations can do.
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. Additionally, the device passwords should be changed and the
firmware should be updated. So this is something very specific for individuals. 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. Also, one of the good things that
an organization should do would be to make developers more aware of such threat vectors as
well. There should be... they should perform extensive penetration testing of devices before
rolling them out. Also, investing in threat modeling to identify such issues in the initial
stages would be a great effort. Additionally, internal network segmentation. 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. Now, we move on to roles of developers
and pen testers. 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, bypass SOP, and still being able to get into a private network and then
pivot to other devices. Apart from that, for developers, we would suggest host header validation
is one of the most efficient ways of handling an attack like this. Also, the developers should
make sure that they provide proper authentication for all the local services. Additionally,
instead of creating standard default passwords, all passwords should be uniquely generated.
That would actually prevent a lot of vulnerabilities related to the industry binding attacks.
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.
But what about us? Exactly! We have created a browser extension called Securarity,
which intends to detect such attacks and keep users safe while browsing such malicious websites.
So let's see what we have in this tool. 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. 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. But the question is, does it prevent rewinding attacks? Yes! 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.
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. We have also provided an option of manually blocking all HTTP requests based on
user-provided URL patterns. 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. 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.
So for that, we have also created an allow list to bypass monitoring. Let's now talk about how
this extension works precisely. So how the extension is identifying inter-access scams?
The DNS IP translations are done through the Chrome's web request API. The request object and
the target IP is fetched and checked for the private scanning conditions. The extension notifies
whenever the case occurs on scanning private IPs and on-click displays the details taken from the
data object. How is it identifying rewinding attacks? 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. It validates if the hosting
resolves to a private IP and if hosting is itself not a private IP. 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. Let's see how it is blocking the SLA build. 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. 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. But how are we using Shodan API for
hosting? We are using the standard Shodan API to fetch details about the malicious host. 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. Okay, so let's see how the allow list is implemented. 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.
Therefore, preventing notifications and hostname blocking. 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. 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. Now we can move to the demonstration and see how the tool works. 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. 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. So now moving on, let us see the
implementation. So here is the extension. We will now just try to scan. 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. We can use the search for specific needs like a certain group number
or a specific IP. 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.
Okay, let us now see the rewinding detection feature. For that, we will now execute
a rewinding attack and see if our tool is able to function as discussed before.
So we will do a simple fetch and get. We need to wait for a little, only long.
And once we are done, we can see the details displayed in our tools.
Okay, so we can see the rewinding attack is successful. Also, our tool has notified us
and it's time to check the details. So here we can see the details, if it is IP, domain, timestamp.
Moving on to other features, let us see how our block and allow list work.
So we will go to the block or allow section and add the pattern we want to block from loading.
We can test it with, say, rewind.it and save.
Now we will go to the rewind.it page we were using and reload it. Well, it works. So if the
rewind is blocked, we can take another example. Let's say block.com. We will add this one as well
and try to block it. And hit the save to see if it is blocked or not. Now you go back and
reload the page for the blogger. And it is blocked. We can also test this case for iframes
also, much relatable to the example of the malicious ad that we have seen before. So you
can see that it is blocked by the extension and this will prevent any subsites from loading any
malicious ads. 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. And we are doing it for rewind.it.
So we will type rewind.it here and save to allow it.
Okay, so let's reload the rewind.it page and scan again.
And we can see that it does not notify as it selects the rewind scan.
For that, we can see that we have no details.
So now we can scan from some other site to see if the function is normal. So let's check here.
It will scan and notify us with a display of details. Let's see if it works exactly.
So this is it. And we can see the details here.
Okay, now we will be seeing how the extension is preventing attacks. So as you can see,
this is the router which is hosted here. Now we'll be trying to perform
a hook and control in the rewind.it.
And see how it is preventing. So let's inspect and start back.
We can see here all the requests while doing the rewind attack.
Okay, so we can see there were successful socket connection
and our extension is able to detect the DNS rewind.
But the next thing this extension did is to block the URL. So let's check.
So for that, let us go to the attacker's panel and we can see what exactly happened.
So here the attacker will try to load the panel and we can check if he is able to load
actually or not. 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.
So all the requests are getting rejected by extension.
Therefore, we can see that even though the attacker is trying to fetch the information,
that he won't be able to. And we'll just keep on reading.
So that basically concludes our talk. We'll soon be launching the code for security
on our GitHub after some modifications and bug fixes.
And that's it. So thanks a lot for making it till the end and stay safe.