1
00:00:00,000 --> 00:00:08,280
One welcome to DEF CON Safe Mode, from crazy Vegas parties last year to me sitting alone in my room right now and sipping vodka in 2020.

2
00:00:08,560 --> 00:00:10,580
Wow, it's been a crazy year.

3
00:00:10,640 --> 00:00:18,900
But it's literally like Vegas in my house right now, because cocktails are acceptable at any hour, and I have no idea what time of the day it is.

4
00:00:19,020 --> 00:00:20,560
Things have changed drastically.

5
00:00:20,700 --> 00:00:26,260
In this time when everything is getting cancelled, I'm so delighted that at least we still have DEF CON.

6
00:00:26,260 --> 00:00:27,520
Welcome to the new normal.

7
00:00:27,520 --> 00:00:28,920
Thanks for joining in.

8
00:00:29,000 --> 00:00:41,820
Before we start, we would like to add a disclaimer that all content over here is specifically for demonstration purposes, and everything is informative, and we have performed all of it on demo environments.

9
00:00:41,960 --> 00:00:45,500
Now, before moving ahead, we would like to introduce ourselves.

10
00:00:45,500 --> 00:00:47,440
So, just a little bit about us.

11
00:00:47,440 --> 00:00:51,760
My name is Devan Kwan, and I work as a security consultant with the NCC group.

12
00:00:51,760 --> 00:00:57,400
I have multiple areas of interest, but the most recent one being IoT and radio hacking.

13
00:00:57,400 --> 00:01:08,400
I have also contributed in the development of NICE, that is non-intrusive confidence engine for multi-factor authentication mechanism, and I am also working on instant messaging and secret storage protocol.

14
00:01:08,560 --> 00:01:13,460
It is the first talk that I have ever given, and therefore, just a heads up to you guys.

15
00:01:13,660 --> 00:01:18,880
The talk would be pretty business friendly, and we'd go over a lot of basic topics as well.

16
00:01:18,900 --> 00:01:20,800
Now, passing on to my co-presenter.

17
00:01:20,800 --> 00:01:21,800
Thank you, Devan.

18
00:01:22,000 --> 00:01:23,040
Hello, everyone.

19
00:01:23,040 --> 00:01:30,200
My name is Shruti I'm a computer scientist working in IoT research and development at Nexus in France.

20
00:01:30,340 --> 00:01:38,760
I have three plus years of experience in IoT development for smart home, autonomous vehicles, indoor and virtual locations, precisely.

21
00:01:38,860 --> 00:01:53,640
I have previously contributed to some international projects like Inakreshi, and I'm also part of Hall of Fame for my contribution to the development of end-to-end IoT platform, which is a leading research institute in Europe.

22
00:01:53,660 --> 00:01:55,820
I'm also an independent researcher.

23
00:01:55,820 --> 00:02:01,080
I'm very passionate about IoT development, secure smart system, teaching, and women empowerment.

24
00:02:01,160 --> 00:02:09,140
Well, now moving on to the agenda for our talk today, we will begin with the idea of connected world, and how it all started.

25
00:02:09,140 --> 00:02:12,820
It's like a very boring history, including introduction for our talk.

26
00:02:12,820 --> 00:02:16,900
Well, it will be followed by the section discussing its security parameters.

27
00:02:17,220 --> 00:02:30,860
We will see how unaware we are surrounded with billions of devices with some stats, and then we will move to the section of attacks and expedition scenario, where we will be understanding a few basic concepts prior to our main demonstration.

28
00:02:31,280 --> 00:02:45,460
We will also cover some tools during this demonstration, and later discuss the crucial points, stating how we can protect our smart world from those discussed attacks, be it an organization, developer, or project designer.

29
00:02:45,460 --> 00:03:00,980
Well, lastly, we will go over the demonstration, and we will demonstrate a small tool that we have developed, which can be very useful in protecting IoT consumers, or making them aware of any attacks they might be unknowingly facing on the connected world.

30
00:03:01,620 --> 00:03:03,200
Well, our connected world.

31
00:03:03,200 --> 00:03:07,540
Okay, so are you telling me that anyone on the internet can talk to my fridge?

32
00:03:08,920 --> 00:03:18,140
Well, today in an era of COVID-19 pandemic, we all are working from home, aiming to stay connected worldwide during the time of social isolation.

33
00:03:18,140 --> 00:03:27,440
Even including this talk, completely online, and where we are missing the real interaction with the crowd and nervousness in the presenters like us.

34
00:03:27,440 --> 00:03:37,540
Although we are really nervous, but thanks to internet of things, from wearable devices and portable technologies to health-related accessories, IoT is everywhere.

35
00:03:37,540 --> 00:03:47,720
It has shifted from a futuristic concept to the central focus area of every industry, ranging from manufacturing and retail to healthcare and real estate.

36
00:03:48,340 --> 00:03:52,200
But the question is how exactly it all started.

37
00:03:52,360 --> 00:04:03,960
The internet of things emerged as the largest digital mega trend, bridging the physical and visual worlds with the fourth industrial revolution, or to say, industry 4.0.

38
00:04:03,960 --> 00:04:14,660
From the first revolution, triggered by the construction of railways, we are now aiming for increasing the networking of people, machines, and objects over the internet.

39
00:04:14,660 --> 00:04:33,040
We understand that internet of things is basically a network of things, which are simply any objects like devices, vehicles, or embedded items in electronics, with the only target of achieving connectivity to enable connection and exchange of data between the things to make our lives simpler.

40
00:04:33,040 --> 00:04:41,360
Showcasing its talent, IoT has fascinated things from eating unbotted coffee to turning off the lights when we go to sleep at night.

41
00:04:41,800 --> 00:04:45,080
I swear to God, that thing has made me so lazy.

42
00:04:45,760 --> 00:04:50,160
This is the reason why dependability has been exponentially increasing.

43
00:04:50,160 --> 00:04:59,540
Just like the COVID graph, from one million down to the expected 50.1 billion in 2020, there is a massive explosion in the usage of IoT devices.

44
00:04:59,620 --> 00:05:06,980
From smart homes, smart healthcare, smart city, and what not, we want everything to be smarter now.

45
00:05:07,120 --> 00:05:12,780
And this means, I literally have no idea how to even say this number right.

46
00:05:13,780 --> 00:05:19,260
But moving on to how safe my world is, I'll pass on to you, Devang.

47
00:05:19,260 --> 00:05:20,320
All right.

48
00:05:20,760 --> 00:05:25,420
So, what if I just tell you that the S in IoT actually stands for security?

49
00:05:25,420 --> 00:05:26,600
Yes, that is true.

50
00:05:26,700 --> 00:05:34,340
So, talking about how safe my world is, with billions of devices connecting the whole world, we care a lot about functioning, right?

51
00:05:34,340 --> 00:05:36,860
We want things to be done in just one click.

52
00:05:36,860 --> 00:05:40,680
We want things faster with less or almost no effort.

53
00:05:40,680 --> 00:05:46,120
Better be functioning soon, be click to buy in Amazon, Alibaba, or wherever you guys shop.

54
00:05:46,120 --> 00:05:50,780
But we need to understand that there's a need for security on so many levels.

55
00:05:50,840 --> 00:05:58,580
So, we should first look and compare the threat models in terms of classic web applications and then in terms of IoT devices.

56
00:05:58,980 --> 00:06:03,980
Over here, we see a simple web app server connecting to a SQL database.

57
00:06:03,980 --> 00:06:07,340
Then we have a third party web service and cloud storage.

58
00:06:07,340 --> 00:06:11,360
They all have their own corporate trust boundary and vendor trust boundary.

59
00:06:11,360 --> 00:06:14,180
And then we talk about the human user.

60
00:06:14,620 --> 00:06:18,920
The human user is actually directly interacting with the web application.

61
00:06:18,920 --> 00:06:24,840
And then they all are being separated by separate privileged levels and their own trust boundaries.

62
00:06:25,160 --> 00:06:30,240
So, as you can see, definitely in no way I'm saying that web applications are extremely similar.

63
00:06:30,240 --> 00:06:32,260
Trust me, I would never say that.

64
00:06:32,560 --> 00:06:37,880
They can definitely and more certainly are more complex than the basic diagram which I'm showing here.

65
00:06:37,880 --> 00:06:43,880
However, we get more clarity when I try to compare it to a simple IoT implementation.

66
00:06:44,400 --> 00:06:44,840
All right.

67
00:06:44,840 --> 00:06:46,540
So, in this next diagram.

68
00:06:46,540 --> 00:06:51,980
So, as you can see over here, in this IoT threat model, this is like a very simple IoT architecture.

69
00:06:51,980 --> 00:06:54,680
I'm not even going into more complex ones.

70
00:06:54,680 --> 00:06:59,020
We aren't even talking about embedded devices and airplanes and the complex architectures.

71
00:06:59,020 --> 00:07:02,420
We're literally talking about a very simple architecture here.

72
00:07:02,480 --> 00:07:06,380
Specifically focusing only on smart and connected forms.

73
00:07:06,480 --> 00:07:11,420
I would say these are more of consumer IoT and less of enterprise IoT.

74
00:07:11,420 --> 00:07:15,380
So, in this case, what we are looking at is a connected user.

75
00:07:16,320 --> 00:07:21,560
So, a connected user is basically a user who is interacting with their smart device.

76
00:07:21,560 --> 00:07:26,320
Then in this case, we have segregated the network into separate sections.

77
00:07:26,560 --> 00:07:30,360
So, as you can see, we have proximity network.

78
00:07:30,440 --> 00:07:34,080
So, in a proximity network, you're considering to have physical.

79
00:07:34,080 --> 00:07:41,660
So, we basically consider a proximity network to have physical sensors, devices, and the IoT gateway itself.

80
00:07:42,180 --> 00:07:47,120
So, basically, that would generally be inside your house.

81
00:07:47,120 --> 00:07:56,480
Then devices are connected to the proximity network by let's say a smart ring, which the user might wear, or any smart device which the user might have in their home.

82
00:07:56,480 --> 00:08:00,040
Then apart from that, the user also interacts with the mobile app.

83
00:08:00,040 --> 00:08:03,020
So, a user basically has two avenues over here.

84
00:08:03,020 --> 00:08:09,900
One is in some cases to directly interact with the embedded sensor of their smart watch or device.

85
00:08:09,900 --> 00:08:13,820
And then another one is the mobile app or any web interface.

86
00:08:14,020 --> 00:08:18,260
Apart from that proximity network, we also talk about the cloud network.

87
00:08:18,260 --> 00:08:27,900
However, for IoT devices, prior to going to cloud, we also have to consider edge servers, as that is what separates them from most of the classic web app.

88
00:08:28,080 --> 00:08:34,080
IoT's preferred microservices architecture compared to most monolithic standard apps.

89
00:08:34,080 --> 00:08:38,840
Edge servers decreases the overall latency and increases the device efficiency.

90
00:08:38,840 --> 00:08:43,380
However, it might add some more attack surfaces in the overall architecture.

91
00:08:43,380 --> 00:08:46,640
Let's just talk about a couple of attack scenarios over here now.

92
00:08:46,640 --> 00:08:57,340
So, you can see that in the proximity network, where the devices communicate over BLE, CoAP, LoRaWAN, as these are close-range protocols and the devices are in proximity.

93
00:08:57,340 --> 00:09:07,040
Therefore, in proximity network, our main threat actors are generally the pre-installed malicious IoT devices, as they might try to replay or intercept the existing traffic.

94
00:09:07,040 --> 00:09:11,480
They might also exfiltrate that traffic out through the IoT gateway.

95
00:09:11,920 --> 00:09:32,340
Okay, now moving on to the mobile interface, we might have more attack surfaces, like, let's say, a malicious application on the user's device, which might try to directly interact with the device file system and processes in order to extract sensitive user-specific data from the IoT device application.

96
00:09:32,860 --> 00:09:36,380
Okay, so let me just come back to this.

97
00:09:36,380 --> 00:09:53,520
So, the main purpose to show this threat model here is that, generally, when we consider IoT threat models, we tend to focus on external threat actors, like an attacker compromising third-party cloud services, or like a malicious app on the device, or like a malicious IoT device in the home system.

98
00:09:53,520 --> 00:09:58,200
So, basically, when talking about IoT, these are the attack surfaces we most care about.

99
00:09:58,300 --> 00:10:01,900
But what about the attack surfaces that we least care about?

100
00:10:01,900 --> 00:10:15,120
What about those benign users on your home network, who exist on your home network, who also have updated operating systems, who have updated browser versions, and they're just casually running JavaScript?

101
00:10:15,120 --> 00:10:15,600
All right.

102
00:10:15,600 --> 00:10:26,180
So, in terms of IoT devices, specifically for connected home devices, a common pattern has been noticed that the device manufacturers tend to give the least priority to device security on local area network.

103
00:10:26,220 --> 00:10:34,220
As the devices are not directly accessible to the external network, therefore, it is generally assumed to be secure without physical access.

104
00:10:34,220 --> 00:10:40,640
As in most cases, the designers just consider that physical access to be the only possible gateway to the private network.

105
00:10:40,680 --> 00:10:51,380
That is why these devices have a variety of open ports and unauthenticated HTTP interfaces running on them, which can be directly controlled by anyone who is present on the home network.

106
00:10:51,380 --> 00:10:58,680
The best example of this was Google Home's unauthenticated HTTP API, which was literally patched in 2019.

107
00:10:59,560 --> 00:11:10,040
And it gave anyone on the local network to perform multiple actions, like rebooting the device or making any sort of modifications, which a normal user could have.

108
00:11:10,040 --> 00:11:19,100
When talking about this particular attack surface, it is considered that if an attacker has physical access to the device, then the network-based attack is among the lowest concern.

109
00:11:19,100 --> 00:11:25,060
And physical attacker access might open up some other serious concerns.

110
00:11:25,060 --> 00:11:27,920
So, this one is given less priority.

111
00:11:28,200 --> 00:11:35,760
However, what if this was not the only attack tree for the exploitation of these HTTP interfaces?

112
00:11:36,340 --> 00:11:41,260
All an attacker needs is a single public gateway to break into the private network.

113
00:11:41,260 --> 00:11:48,460
For a long time, home private networks have been pretty secure, as not everyone is running servers on their local host.

114
00:11:48,460 --> 00:11:51,140
Let's just be honest about that for a minute.

115
00:11:51,140 --> 00:11:59,700
Apart from developers and other people, not everybody is running or hosting an application on their local host networks.

116
00:11:59,700 --> 00:12:10,980
However, with the advent of IoT technology, IoT has literally given an exponential rise to a variety of web interfaces running on users' private network.

117
00:12:10,980 --> 00:12:18,280
In most cases, the user is totally unaware of all the accessible IPs and even open ports on their devices.

118
00:12:18,280 --> 00:12:24,340
The question is, what if an attacker was able to proxy into the private network through a public gate?

119
00:12:24,340 --> 00:12:28,600
Now moving ahead to our next section, attacks and exfiltration scenario.

120
00:12:28,600 --> 00:12:32,280
We would first like you all to do a very simple exercise.

121
00:12:32,280 --> 00:12:39,440
I'd like you all to fire up your terminal and make a simple request, that is, perform this following NSLOOKUP.

122
00:12:40,460 --> 00:12:49,040
Now, if it returns a local IP, then there is a very high chance that you might be vulnerable to DNS rewiring attacks.

123
00:12:49,040 --> 00:12:52,580
Now look at what exactly the attack looks like.

124
00:12:52,580 --> 00:12:56,520
But for that, we need a quick refresher of how exactly DNS works.

125
00:12:58,040 --> 00:13:03,500
Well, we all know that a DNS is like an address directory of the internet.

126
00:13:03,500 --> 00:13:10,000
It translates the domain name like facebook.com, google.com to IP addresses.

127
00:13:10,000 --> 00:13:12,580
So browsers can load internet resources.

128
00:13:12,800 --> 00:13:19,760
These IP addresses are given to each device on the internet and they are necessary to find appropriate internet device.

129
00:13:19,760 --> 00:13:26,900
It's like a street address is used for a particular home, you know, to find that particular home in that particular location.

130
00:13:27,080 --> 00:13:40,640
So to understand how this translation is done, let us imagine a situation where a user is trying to access a website called shop-example.com because, you know, she's bored in this quarantine and wants to shop at least.

131
00:13:40,640 --> 00:13:57,140
So as a user types shop-example.com into a web browser, the query will traverse into the internet asking what is the IP address of shop-example.com and will be received by a DNS recursive resolver.

132
00:13:57,840 --> 00:14:11,360
Well, the next step is that if the recursive resolver has no answer, then the request will be passed on to the DNS root name server asking the same question at what is the IP address of shop-example.com.

133
00:14:11,360 --> 00:14:15,740
The root server will then respond with the address of a TLD.

134
00:14:15,740 --> 00:14:23,740
TLD is top-level domain server like .com or .net which stores the information for its domain.

135
00:14:23,740 --> 00:14:25,300
In this case, it will be .com.

136
00:14:25,300 --> 00:14:31,160
Once the address of TLD is received, the resolver then makes a request to the .com TLD.

137
00:14:31,300 --> 00:14:34,440
The TLD server will behave like a root server.

138
00:14:34,440 --> 00:14:41,220
I know this guy, you might know this guy and will respond with the IP address of the domain's main server.

139
00:14:41,300 --> 00:14:55,320
The recursive resolver then asks the domain main server where is the shop-example.com and then finally the main server will return the IP address of shop-example.com to the resolver with TLD.

140
00:14:55,780 --> 00:14:59,980
And lastly, the user's browser will have the requested IP address.

141
00:14:59,980 --> 00:15:14,440
Now the browser knows the IP address of the website, it is able to make the request for the shop-example.com as the request is offered, for instance, where the web server on the receiving the request will actually respond with that requested web page,

142
00:15:14,440 --> 00:15:16,880
you know, like 60% off.

143
00:15:16,880 --> 00:15:18,660
Wow, who doesn't like that?

144
00:15:18,720 --> 00:15:22,900
Well, we saw the complete flow to understand how DNS works.

145
00:15:22,900 --> 00:15:35,700
Instead of going through all this way and to improve the performance and reliability of data requests, this information is temporarily stored in the locations like browser, operating system, or recursive resolver.

146
00:15:35,700 --> 00:15:43,340
This is all DNS caching and the set amount of time for storing is known as time to live, in short TTL, as I said before.

147
00:15:43,720 --> 00:15:47,480
Well, let's take another situation into consideration.

148
00:15:47,560 --> 00:15:54,260
Okay, so I just, from the previous slide, I'd just like to focus on one thing, time to live.

149
00:15:54,260 --> 00:15:57,300
Please make a note of it, it'll be useful later.

150
00:15:57,300 --> 00:16:00,820
So, let's take another situation into consideration.

151
00:16:00,840 --> 00:16:06,460
Let's say that the user is trying to access some web page and there are some annoying ads on the web page.

152
00:16:06,460 --> 00:16:11,040
Among those, there is one malicious ad waiting for the user's attention.

153
00:16:11,040 --> 00:16:15,580
Since this ad has to be loaded from another domain, our browser has to fetch it.

154
00:16:15,580 --> 00:16:30,560
But loading a random JavaScript from some random domain will give the attacker access to load anything in our browser and authority to make requests to maybe our bank.com or access pages for, let's say, maybe from our smartphone devices.

155
00:16:30,700 --> 00:16:31,680
But you know what?

156
00:16:31,680 --> 00:16:53,480
There is something called same origin policy, which is actually a policy implemented by the browsers and which let the browser restrict this kind of behavior as they restrict and limit any sort of HTTP request which originates from one domain to access resources that are hosted on or served on another domain.

157
00:16:53,480 --> 00:16:56,920
So, to be specific, let's see an example.

158
00:16:56,920 --> 00:16:57,020
Okay.

159
00:16:57,020 --> 00:17:05,780
So, let's take a quick look at an example of how the same origin policy is able to protect resources from being accessed by malicious JavaScript running on websites across origins.

160
00:17:05,800 --> 00:17:15,960
So, in this example, we have a secrets file that is secrets.txt, which is located at test instance running on port 8053 that is accessible over HTTP.

161
00:17:16,200 --> 00:17:22,220
And we will see how the same origin policy can protect this resource from being accessed by malicious JavaScript running on a malicious origin.

162
00:17:22,220 --> 00:17:26,780
In this case, we are considering example.com to be that malicious origin.

163
00:17:27,240 --> 00:17:30,700
So, when we try to perform an XHR request.

164
00:17:30,700 --> 00:17:41,760
So, in the first example, it is of a totally different origin because here the host, that is example.com, as well as the port is totally different from the test instance.

165
00:17:52,060 --> 00:17:52,760
Okay.

166
00:17:52,760 --> 00:17:57,880
So, here you can see that the browser's same origin policy was able to block the malicious website from accessing the resource.

167
00:17:57,880 --> 00:18:03,640
As it said, they do not have the same origin due to them having totally different host as well as port.

168
00:18:03,760 --> 00:18:04,420
Okay.

169
00:18:04,420 --> 00:18:06,900
Now, we'll be looking at a different example.

170
00:18:07,140 --> 00:18:15,160
So, in this particular example, these two resources have the same host, that is testinstance.com.

171
00:18:15,160 --> 00:18:19,960
But they happen to have this totally different port numbers.

172
00:18:19,960 --> 00:18:26,020
One, the secrets was actually on 8053, whereas this resource is on 8056.

173
00:18:26,020 --> 00:18:28,840
And we can observe that.

174
00:18:29,480 --> 00:18:30,400
Okay.

175
00:18:30,400 --> 00:18:42,180
And in this case, when we try to perform a XML HTTP request, or basically a cross-site JavaScript fetch, we'll be able to see.

176
00:18:42,180 --> 00:18:42,800
Okay.

177
00:18:42,800 --> 00:19:03,480
So, as these two happen to have different port numbers, although they have the same host, the resource is still not able to access the secrets.txt, because the browser still considers this to be a totally different origin, because of them having totally different ports.

178
00:19:03,480 --> 00:19:06,380
Now, we will look at a standard example.

179
00:19:06,380 --> 00:19:13,120
This page is testinstance.com, and it has the same 8053 port as our secret.

180
00:19:13,120 --> 00:19:20,240
So, this happened to match all the criteria that is required for a same origin, right?

181
00:19:20,240 --> 00:19:30,900
Then, in that case, we'll just try to see how exactly the same origin policy would allow this one to access the secret.

182
00:19:30,900 --> 00:19:51,120
So, in this case, as you can see, this was able to pass the same origin policy due to exactly the same host, the same protocol, as well as the same port number, because of which it was able to access the resource which was hosted, which was actually located at secrets.txt.

183
00:19:51,120 --> 00:19:54,480
So, that basically sums up the example of same origin policy.

184
00:19:55,040 --> 00:20:02,660
So, the question that arises here is, if SOP is actually preventing this kind of attack, then what is the threat?

185
00:20:04,340 --> 00:20:06,440
Well, DNS rewinding.

186
00:20:06,440 --> 00:20:14,160
DNS rewinding is a class of exploit in which the attacker initiates repeated DNS queries to a domain under their control.

187
00:20:14,160 --> 00:20:22,280
Consider the scenario where the user is comfortably surfing over the internet to access a web page containing some advertisement.

188
00:20:22,640 --> 00:20:26,800
Among those ads, there is one malicious ad, as Ivan stated before.

189
00:20:26,800 --> 00:20:35,000
As the web page is loaded, the browser will request the malicious DNS server querying the IP address of maliciousads.com.

190
00:20:35,200 --> 00:20:54,560
When receiving this request, the attacker-controlled DNS server responds with the real IP, let's say 1.2.3.4, and it also sets the TTL value on the response to be zero minutes or a few seconds, so that the user's machine won't cache for long.

191
00:20:54,560 --> 00:20:56,940
Now, let's wait for some time.

192
00:20:57,740 --> 00:21:02,660
Now, the malicious JavaScript makes another request to maliciousads.com.

193
00:21:02,660 --> 00:21:08,780
And since the TTL is exceeded, the IP of maliciousads.com isn't found in the cache.

194
00:21:08,980 --> 00:21:13,920
Therefore, the browser will again request the IP from the DNS server.

195
00:21:13,960 --> 00:21:14,820
But what?

196
00:21:14,820 --> 00:21:15,340
Wait!

197
00:21:15,340 --> 00:21:36,980
This time, on the user's subsequent DNS request, instead of the real IP, the maliciousads.com, the name server of maliciousads.com, will respond with the IP of 10.0.0.1, which happens to be an IP within the user's local space and belongs to an IoT device on the user's network.

198
00:21:37,740 --> 00:21:48,780
The user's browser will receive this malicious DNS response and will use this provided IP to make HTTP requests, which were intended for maliciousads.com.

199
00:21:48,780 --> 00:21:53,620
Because technically, there is no change for the browser according to the normal functioning.

200
00:21:53,620 --> 00:22:00,220
Because based on SOP, browser just sees the same name and goes, oh, we have the same name.

201
00:22:00,220 --> 00:22:07,140
So we are friends and allows all queries from the same origin, irrespective of the IPs.

202
00:22:07,140 --> 00:22:14,400
But the HTTP requests are now sent to the small unprotected web server running on the user's component.

203
00:22:14,400 --> 00:22:21,560
The same network where all your smart devices are connected and that's making your smart home unsafe.

204
00:22:21,620 --> 00:22:25,340
And that's behaving as a proxy between your private and public world.

205
00:22:25,340 --> 00:22:40,160
DNS rebinding attack can actually bypass network firewalls, security controls, such as false and make every device on your local network vulnerable and available to an attacker from anywhere outside your protected internet.

206
00:22:41,120 --> 00:22:42,820
Let us do theoretically.

207
00:22:42,960 --> 00:22:44,740
Now it's time to hack.

208
00:22:44,740 --> 00:22:45,120
Okay.

209
00:22:45,120 --> 00:22:52,440
So in this example, the first thing that we'll be talking about is a router interface that allows anyone on the network to access the router controls once they have authenticated.

210
00:22:52,440 --> 00:22:58,300
However, even prior to the authentication, this allows users on the home network to access the list of all the connected devices.

211
00:22:58,680 --> 00:23:04,900
So let's see how a user on this private network can become vulnerable to the DNS rebinding attack by just navigating to a website that looks totally benign.

212
00:23:04,900 --> 00:23:06,080
In this case, cute videos.

213
00:23:06,080 --> 00:23:07,120
Because you know what?

214
00:23:07,160 --> 00:23:08,920
Who does not like cute animals?

215
00:23:09,200 --> 00:23:20,460
So as you can see in the developer options in the network request, you can see even before the page was loaded, the malicious host on the page initiated a port scan in the local network in order to identify the router interface.

216
00:23:20,460 --> 00:23:29,400
Router is an easily identifiable target in most of the because standard IP of their default gateways and therefore it is easy to scan compared to other devices.

217
00:23:29,400 --> 00:23:32,920
So here it has already identified 10.0.0.2.

218
00:23:33,080 --> 00:23:44,020
And now automatically it has started sending the JavaScript on the page has already started sending multiple requests from the page to the external URL.

219
00:23:44,300 --> 00:23:49,800
And now this page is basically just waiting for the DNS to be DNS records to be updated.

220
00:23:49,800 --> 00:23:52,400
So this video is already 11 minutes long.

221
00:23:52,400 --> 00:23:58,800
And that's like already enough time for an attacker to perform the DNS rewinding attack.

222
00:23:58,800 --> 00:24:12,600
So by the time the attacker so by the time you're even watching first 20 seconds of the video, the attacker has already been able to rewind and has been sent internal request to 10.0.0.2.

223
00:24:12,600 --> 00:24:15,960
And now we'll move to the attackers panel.

224
00:24:15,960 --> 00:24:25,740
So here you can see a WebSocket connection has been made based on which the attacker would be able to actually access things on the internal network.

225
00:24:25,740 --> 00:24:32,240
So now you can see the remote address has been updated from the attacker's IP address to the internal IP address.

226
00:24:32,240 --> 00:24:45,620
And based on that, the attacker is now able to any request that has been performed to the origin by the JavaScript is actually helping the attacker to communicate with the internal services that is running on your router.

227
00:24:45,680 --> 00:24:48,620
So now we'll just try some generic passwords.

228
00:24:48,620 --> 00:24:57,900
Oh, in this case, we just tried admin admin and that definitely worked because a lot of routers, whether we want to accept it or not, are still working on default passwords.

229
00:24:57,900 --> 00:25:14,760
So this gives any attacker multiple functionalities like setting the functionality of the router, modifying passwords, and this also allows them to enable UPnP, which might make them vulnerable to multiple other vulnerabilities apart from this.

230
00:25:14,760 --> 00:25:19,780
It also allows the attacker to remotely reset or reboot the device.

231
00:25:19,780 --> 00:25:28,520
Also, it gives an attacker full functionality to modify your DNS servers and thus serving you all the malicious websites that they want to.

232
00:25:28,520 --> 00:25:37,220
Also, they can just proxy your entire network and that would help them to take over other multiple devices on your network as well.

233
00:25:37,860 --> 00:25:40,620
So that would be, in short, pretty bad.

234
00:25:40,620 --> 00:25:43,740
And over here, you can see all those requests.

235
00:25:43,820 --> 00:25:47,780
So in this case, password update page that was being fetched by the attacker.

236
00:25:47,780 --> 00:25:52,840
So all these requests were actually being made to the external attacker's origin.

237
00:25:52,840 --> 00:25:58,600
However, the remote address was routed to 10.0.0.2, which was the router's IP.

238
00:25:58,600 --> 00:26:05,200
So by the time you're busy watching the cute dog, your entire router and the network has been taken over.

239
00:26:08,750 --> 00:26:12,710
All right, so for the second demonstration, we will be looking at a baby monitor.

240
00:26:12,710 --> 00:26:20,070
So based on the router's exploitation, the attacker already got to know more information about what all other devices exist on the local network.

241
00:26:20,070 --> 00:26:26,290
In this case, the attacker was able to identify there's a baby monitor running on 10.0.0.182.

242
00:26:26,390 --> 00:26:34,550
So for our demonstration purpose, there is a baby monitor and there is the baby root, just to show you it's live.

243
00:26:34,550 --> 00:26:35,510
There you go.

244
00:26:35,770 --> 00:26:40,570
So this baby monitor software had a couple of functionalities.

245
00:26:40,870 --> 00:26:45,430
It can connect to multiple other cameras on the same network.

246
00:26:45,430 --> 00:26:48,710
And this feed is accessible to anyone on the local network.

247
00:26:48,710 --> 00:26:51,570
So you can select all of the cameras.

248
00:26:51,570 --> 00:26:54,530
As you can see, there are three cameras here.

249
00:26:54,710 --> 00:27:00,430
Apart from that, it has functionalities to send commands to different cameras, like getting images.

250
00:27:00,430 --> 00:27:02,650
And it also has options of privacy toggle.

251
00:27:02,650 --> 00:27:05,230
Then you can see camera three is disabled.

252
00:27:05,230 --> 00:27:11,330
So it also gives an option to specifically put an IP and find a camera, if in case it is disabled.

253
00:27:11,430 --> 00:27:15,570
Moving on to the attack, we'll be using the tool Singularity.

254
00:27:15,570 --> 00:27:24,410
We'll put in the IP, the port, and then we'll be going for hook and control, because we actually want to watch the video, right?

255
00:27:24,570 --> 00:27:29,290
And the time interval is set to seven seconds, and we start the attack.

256
00:27:29,410 --> 00:27:31,450
Let's look at the developer console.

257
00:27:31,710 --> 00:27:37,550
So this way, we can see that every seven seconds, a request is being sent, and it is waiting for a DNS update.

258
00:27:38,410 --> 00:27:42,810
And there you go, as the DNS update was made.

259
00:27:42,810 --> 00:27:46,110
In this case, let's move on to the attacker's window.

260
00:27:46,590 --> 00:27:49,790
Here, you can see that the attacker... there you go.

261
00:27:49,790 --> 00:27:53,070
So the attacker is actually able to get a live feed, right?

262
00:27:53,110 --> 00:28:02,170
Also, the attacker can try to now perform queries, and in order to identify what all other IPs might be there on the network.

263
00:28:02,170 --> 00:28:04,830
So this would be really helpful for an attacker.

264
00:28:04,830 --> 00:28:12,010
So the attacker can also try to exploit things like maybe a command injection, which is definitely the case over here.

265
00:28:12,010 --> 00:28:33,250
So we'll just try to perform a curl request from the camera's interface to an external webhook that the attacker controls, in order to see if we'll be able to extract more information by performing cat, as well, in order to extract sensitive files, and also to perform curl to the external endpoint of the attacker,

266
00:28:33,250 --> 00:28:45,430
which would be very helpful in order to set up a connection, so that the attacker can then use the camera more like a bot.

267
00:28:45,630 --> 00:29:00,390
So over here, you can see that the ping request was successful, then the information was also extracted, and here you can see that there was an incoming request to the attacker's webhook from the baby monitor itself.

268
00:29:00,390 --> 00:29:03,690
As you can see over here, the request is coming from group.

269
00:29:03,690 --> 00:29:10,490
So this basically shows that, okay, the attacker's command, the curl command which the attacker executed, was successful.

270
00:29:10,490 --> 00:29:18,330
So now the attacker can actually exfiltrate a lot of information by exploiting the command execution vulnerability.

271
00:29:18,970 --> 00:29:24,810
So that's how basically like attacker can exploit it in this particular case.

272
00:29:25,210 --> 00:29:28,010
So for the third demonstration, we'll be looking at a smart home panel.

273
00:29:28,010 --> 00:29:30,890
So this is not at all a hypothetical scenario.

274
00:29:30,890 --> 00:29:33,790
This is something which we have seen very commonly.

275
00:29:33,910 --> 00:29:51,330
So this device is actually a smart home panel, which is kept unauthenticated because it is supposed to be accessible only on a local area network, and it is supposed to be placed inside of a tablet, and then it can behave more like a control panel, and it can access all these functionalities.

276
00:29:51,330 --> 00:29:57,070
As you can see over here, the lights, thermostats, and everything from a single control panel.

277
00:29:57,350 --> 00:30:06,210
So that is why these kind of devices are like pretty common on a local area network, and they are generally kept unauthenticated.

278
00:30:06,210 --> 00:30:13,490
Talking about a rebind attack on this particular device, we'll be again using the tool called Singularity.

279
00:30:13,530 --> 00:30:16,370
And in this case, we'll be doing hook and control.

280
00:30:16,450 --> 00:30:41,830
So over here, we can see once the DNS has been updated to 10.0.0.211, that is the IP of the smart panel in this case, then all the requests from the attacker's domain will actually be made to the result IP of the smart home panel on the port 8081, and that would basically allow an attacker to establish the web socket connection.

281
00:30:41,990 --> 00:30:46,670
So as you can see over here, the DNS rebinding attack is successful.

282
00:30:46,790 --> 00:30:51,710
So now you can look at the attacker's panel.

283
00:30:51,710 --> 00:31:00,790
So the attacker over here is able to take a direct control of the smart home panel remotely, and now the attacker can literally set it to night mode, day mode.

284
00:31:00,830 --> 00:31:05,970
And over here, the attacker also has the ability to enable or disable the alarms.

285
00:31:05,970 --> 00:31:14,550
So now for this application, we explicitly specified and disabled host check and made it vulnerable just for the demonstration purpose.

286
00:31:14,550 --> 00:31:25,970
But if we could just make that minor tweak in the configuration and enable host header validation, so you can see we have enabled it and now we'll be reconfiguring the application.

287
00:31:26,050 --> 00:31:31,910
So now in this case, let's try to again perform the same attack after enabling host header validation.

288
00:31:32,130 --> 00:31:37,010
So we are going to perform the exact same attack on the application.

289
00:31:37,730 --> 00:31:40,370
Let's see what exactly happens this time.

290
00:31:40,650 --> 00:31:47,470
So over here, the attack is probably again going to say that it was successful.

291
00:31:47,470 --> 00:31:50,090
So you can see it shows that it was successful.

292
00:31:50,090 --> 00:31:54,850
Moving on to the attacker's window, let's see how exactly host header would prevent.

293
00:31:54,850 --> 00:32:06,050
So when it is trying to access, the attacker is presented a screen showing invalid host header because there was a clear mismatch between the host headers.

294
00:32:06,090 --> 00:32:10,530
So this was actually prevented by the application's built-in host header validation.

295
00:32:11,130 --> 00:32:11,730
Okay.

296
00:32:11,730 --> 00:32:16,950
So we have already seen that how someone can actually exploit this.

297
00:32:16,950 --> 00:32:21,950
But now the main question that is, okay, this attack is already known, right?

298
00:32:21,950 --> 00:32:24,970
So why does it still exist?

299
00:32:25,010 --> 00:32:29,150
So let's just talk about what are the main reasons because of which it is still there.

300
00:32:29,330 --> 00:32:36,950
So IoT devices, one of the main reasons is IoT devices are available at cheap prices with almost less or no security.

301
00:32:36,950 --> 00:32:45,990
Because there has been an explosion of very cheap and smart devices and vendors who focus more on adding functionality compared to security measures.

302
00:32:45,990 --> 00:32:51,030
They do not undergo thorough pen testing or any security compliance check at all.

303
00:32:51,030 --> 00:32:54,690
We see a smart device providing such a smart feature at low cost.

304
00:32:54,690 --> 00:32:57,690
We add it to our cart and purchase it right away.

305
00:32:58,150 --> 00:33:06,690
We as a customer do not understand that the cheap cost also comes at a price that is paid by the lack of research, development, and security measures.

306
00:33:06,710 --> 00:33:18,990
Moreover, DNS rebinding bugs have a history of being dismissed by developers and product designers and many times it is left as an unaddressed issue because many of them are not aware of this threat.

307
00:33:19,030 --> 00:33:31,070
Apart from this, any specific mitigation for removal might go against the traditional procedure of DNS functioning or sometimes it might break a lot of legacy applications.

308
00:33:31,070 --> 00:33:37,050
So the next question that we ask is what individuals and organizations can do.

309
00:33:37,330 --> 00:33:53,810
So some of the common ways an individual or organization can prevent such kind of things would be to... the ISP should actually configure their DNS servers in a way that would block DNS responses which contain local IP addresses.

310
00:33:53,810 --> 00:33:59,230
Additionally, the device passwords should be changed and the firmware should be updated.

311
00:33:59,230 --> 00:34:03,090
So this is something very specific for individuals.

312
00:34:03,090 --> 00:34:15,590
They should not keep their device passwords as default because as we already showed in the demo, how a router was exploited was mostly because of default passwords being used.

313
00:34:15,590 --> 00:34:24,070
Also, one of the good things that an organization should do would be to make developers more aware of such threat vectors as well.

314
00:34:24,510 --> 00:34:30,590
There should be... they should perform extensive penetration testing of devices before rolling them out.

315
00:34:30,590 --> 00:34:38,530
Also, investing in threat modeling to identify such issues in the initial stages would be a great effort.

316
00:34:38,530 --> 00:34:40,950
Additionally, internal network segmentation.

317
00:34:40,950 --> 00:34:50,850
So basically, for anyone who is actually trying to have IoT devices on their network, they should have multiple routes in internal network categorized for IoT devices.

318
00:34:50,850 --> 00:34:54,790
Now, we move on to roles of developers and pen testers.

319
00:34:54,790 --> 00:35:13,230
So talking about developer and pen tester roles, pen testers, it would be great to actually know about this attack and to perform this kind of attack in almost all their web gaming instances because this is a type of attack which would actually help them to bypass the firewall restrictions,

320
00:35:13,230 --> 00:35:18,770
bypass SOP, and still being able to get into a private network and then pivot to other devices.

321
00:35:18,770 --> 00:35:27,570
Apart from that, for developers, we would suggest host header validation is one of the most efficient ways of handling an attack like this.

322
00:35:27,570 --> 00:35:34,230
Also, the developers should make sure that they provide proper authentication for all the local services.

323
00:35:34,230 --> 00:35:42,430
Additionally, instead of creating standard default passwords, all passwords should be uniquely generated.

324
00:35:42,430 --> 00:35:47,630
That would actually prevent a lot of vulnerabilities related to the industry binding attacks.

325
00:35:47,630 --> 00:35:59,550
Well, we saw how host header validation could prevent such attacks and the roles of organization, individuals, and developers in the prevention of the industry binding attack scenarios.

326
00:35:59,550 --> 00:36:01,310
But what about us?

327
00:36:01,310 --> 00:36:02,190
Exactly!

328
00:36:02,190 --> 00:36:11,910
We have created a browser extension called Securarity, which intends to detect such attacks and keep users safe while browsing such malicious websites.

329
00:36:11,910 --> 00:36:14,870
So let's see what we have in this tool.

330
00:36:15,010 --> 00:36:25,450
Securarity is a simple extension tool that monitors malicious behavior of domains which intend to scan the consumer's local network for internal IPs and port scans.

331
00:36:25,450 --> 00:36:38,230
Our extension provides a list of ports and IP addresses scanned by any host and also notifies the consumer if it detects any rewinding attack or if any website scans your private network.

332
00:36:38,410 --> 00:36:41,970
But the question is, does it prevent rewinding attacks?

333
00:36:41,970 --> 00:36:42,930
Yes!

334
00:36:42,930 --> 00:36:55,490
Once the attack is detected, the extension will automatically block the further request from the requested URL, thus preventing the attacker from using the consumer browser as a proxy for further intervention.

335
00:36:56,870 --> 00:37:10,290
Moreover, in this extension, we have integrated the Shodan API, which helps us in identifying the information like IP and hostname for the possible malicious domains and perform a port scan on the attacker's domain.

336
00:37:10,530 --> 00:37:18,070
We have also provided an option of manually blocking all HTTP requests based on user -provided URL patterns.

337
00:37:18,070 --> 00:37:27,150
We can simply use a blockage feature of this tool which will prevent such sites from scanning your local network or to perform a DNS rewind attack.

338
00:37:27,590 --> 00:37:45,510
However, while working from home and testing this code, we observed that there are some instances where we do not want to flag a domain as potentially malicious, specifically in cases where I'm working on a VPN and therefore the extension keeps on flagging all internal IP requests as a potential attack.

339
00:37:45,510 --> 00:37:51,110
So for that, we have also created an allow list to bypass monitoring.

340
00:37:51,190 --> 00:37:55,090
Let's now talk about how this extension works precisely.

341
00:37:55,450 --> 00:37:59,750
So how the extension is identifying inter-access scams?

342
00:37:59,750 --> 00:38:04,470
The DNS IP translations are done through the Chrome's web request API.

343
00:38:04,470 --> 00:38:10,450
The request object and the target IP is fetched and checked for the private scanning conditions.

344
00:38:10,450 --> 00:38:19,350
The extension notifies whenever the case occurs on scanning private IPs and on-click displays the details taken from the data object.

345
00:38:19,670 --> 00:38:22,670
How is it identifying rewinding attacks?

346
00:38:22,670 --> 00:38:42,270
Similarly, utilizing the web request API, the detect rewinding functions take that IP and original domain name data to process for detecting if rewinding occurs or not, for which it first validates against a set of predicts compliant to RFC-1918 and compares against the target hosting.

347
00:38:42,850 --> 00:38:49,330
It validates if the hosting resolves to a private IP and if hosting is itself not a private IP.

348
00:38:49,330 --> 00:38:59,130
When found true for these all set of conditions, it then flags the rewinding as true and notifies the user with details displayed in the table on-click.

349
00:39:00,050 --> 00:39:03,070
Let's see how it is blocking the SLA build.

350
00:39:03,070 --> 00:39:17,970
So in our extensions block functionality, we first check the valid input from the user for the domain name and then provide this valid pattern or URL to the Chrome's web request block request function in order to prevent fetching this particular hosting.

351
00:39:18,130 --> 00:39:32,270
Post permissions and content strip matching are based on a set of URLs defined by match patterns, which permits a variety of schemes like HTTP, HTTPS, FILE or FTP and also the wildcard characters.

352
00:39:32,870 --> 00:39:35,530
But how are we using Shodan API for hosting?

353
00:39:36,090 --> 00:39:41,550
We are using the standard Shodan API to fetch details about the malicious host.

354
00:39:41,550 --> 00:39:54,790
The API is used to resolve the hosting to the corresponding IP address, which then is used to perform Shodan host lookup for fetching open quotes and any other information that Shodan has about the malicious host.

355
00:39:55,790 --> 00:39:58,830
Okay, so let's see how the allow list is implemented.

356
00:39:58,830 --> 00:40:12,070
Similar to block list, we use match patterns for generating the allow list based on the user input and then that is compared against the set of scanned private IPs to not flag them as potentially malicious.

357
00:40:12,070 --> 00:40:16,050
Therefore, preventing notifications and hostname blocking.

358
00:40:16,730 --> 00:40:27,710
Now coming to the major feature of our extension, that is how secure IoT is preventing the DNS rewinding attack, in addition to notifying all the aforementioned features.

359
00:40:28,070 --> 00:40:42,090
So once the rewinding is detected from the detect rewinding function, the block rewind function blocks a further request made by the attacker's request URL on the internal IP addresses, thus automatically preventing the attack and detects filtration.

360
00:40:42,790 --> 00:40:48,110
Now we can move to the demonstration and see how the tool works.

361
00:40:48,110 --> 00:40:57,010
We are still working on this tool and aim to add features like sending monitoring updates to the users, their mobile device and other smart assistant devices on the home network.

362
00:40:57,010 --> 00:41:06,110
We also plan to further improve and add support for other browsers like Firefox and of course some beauty features because we understand that user experience should be convenient.

363
00:41:06,190 --> 00:41:08,970
So now moving on, let us see the implementation.

364
00:41:09,430 --> 00:41:12,030
So here is the extension.

365
00:41:12,070 --> 00:41:14,650
We will now just try to scan.

366
00:41:16,090 --> 00:41:26,130
As you can see, it will display scan results and you can now see the list of details that the scanner is doing, IP, code and timestamp.

367
00:41:26,130 --> 00:41:32,970
We can use the search for specific needs like a certain group number or a specific IP.

368
00:41:36,750 --> 00:41:50,150
Apart from the scan, we have other features like this one where we can see the information about the host, what ports are open, location etc.

369
00:41:52,590 --> 00:41:56,170
Okay, let us now see the rewinding detection feature.

370
00:41:56,170 --> 00:42:04,130
For that, we will now execute a rewinding attack and see if our tool is able to function as discussed before.

371
00:42:04,130 --> 00:42:06,290
So we will do a simple fetch and get.

372
00:42:07,030 --> 00:42:09,490
We need to wait for a little, only long.

373
00:42:11,610 --> 00:42:15,450
And once we are done, we can see the details displayed in our tools.

374
00:42:15,450 --> 00:42:15,890
Okay

375
00:42:21,770 --> 00:42:25,950
, so we can see the rewinding attack is successful.

376
00:42:25,950 --> 00:42:29,930
Also, our tool has notified us and it's time to check the details.

377
00:42:29,930 --> 00:42:34,090
So here we can see the details, if it is IP, domain, timestamp.

378
00:42:34,650 --> 00:42:41,610
Moving on to other features, let us see how our block and allow list work.

379
00:42:44,250 --> 00:42:49,970
So we will go to the block or allow section and add the pattern we want to block from loading.

380
00:42:50,490 --> 00:42:55,950
We can test it with, say, rewind.it and

381
00:42:59,910 --> 00:43:00,790
save.

382
00:43:02,810 --> 00:43:06,590
Now we will go to the rewind.it page we were using and reload it.

383
00:43:06,590 --> 00:43:07,470
Well, it works.

384
00:43:07,470 --> 00:43:11,550
So if the rewind is blocked, we can take another example.

385
00:43:11,550 --> 00:43:13,150
Let's say block.com.

386
00:43:13,210 --> 00:43:17,010
We will add this one as well and try to block it.

387
00:43:23,880 --> 00:43:27,180
And hit the save to see if it is blocked or not.

388
00:43:28,000 --> 00:43:31,140
Now you go back and reload the page for the blogger.

389
00:43:32,820 --> 00:43:34,220
And it is blocked.

390
00:43:34,220 --> 00:43:41,540
We can also test this case for iframes also, much relatable to the example of the malicious ad that we have seen before.

391
00:43:41,540 --> 00:43:47,840
So you can see that it is blocked by the extension and this will prevent any subsites from loading any malicious ads.

392
00:43:48,060 --> 00:43:54,860
Now moving on to the allow list feature, where we can specifically tell the extension that it should not flag any request from this domain.

393
00:43:54,960 --> 00:43:58,220
And we are doing it for rewind.it.

394
00:43:59,760 --> 00:44:06,080
So we will type rewind.it here and save to allow it.

395
00:44:13,920 --> 00:44:18,680
Okay, so let's reload the rewind.it page and scan again.

396
00:44:20,420 --> 00:44:26,380
And we can see that it does not notify as it selects the rewind scan.

397
00:44:26,620 --> 00:44:29,400
For that, we can see that we have no details.

398
00:44:30,280 --> 00:44:37,460
So now we can scan from some other site to see if the function is normal.

399
00:44:37,460 --> 00:44:39,320
So let's check here.

400
00:44:40,260 --> 00:44:44,640
It will scan and notify us with a display of details.

401
00:44:44,960 --> 00:44:47,180
Let's see if it works exactly.

402
00:44:47,320 --> 00:44:48,720
So this is it.

403
00:44:48,720 --> 00:44:50,760
And we can see the details here.

404
00:44:55,900 --> 00:44:59,860
Okay, now we will be seeing how the extension is preventing attacks.

405
00:44:59,860 --> 00:45:02,880
So as you can see, this is the router which is hosted here.

406
00:45:02,880 --> 00:45:09,040
Now we'll be trying to perform a hook and control in the rewind.it.

407
00:45:10,460 --> 00:45:13,060
And see how it is preventing.

408
00:45:15,900 --> 00:45:20,400
So let's inspect and start back.

409
00:45:26,050 --> 00:45:30,070
We can see here all the requests while doing the rewind attack.

410
00:45:31,050 --> 00:45:37,690
Okay, so we can see there were successful socket connection and our extension is able to detect the DNS rewind.

411
00:45:39,170 --> 00:45:45,390
But the next thing this extension did is to block the URL.

412
00:45:45,390 --> 00:45:46,730
So let's check.

413
00:45:46,750 --> 00:45:55,290
So for that, let us go to the attacker's panel and we can see what exactly happened.

414
00:45:55,470 --> 00:46:04,910
So here the attacker will try to load the panel and we can check if he is able to load actually or not.

415
00:46:05,330 --> 00:46:13,710
So it's trying to fetch the page and we can see in the inspect that the extension is blocking all further requests to the page.

416
00:46:19,460 --> 00:46:22,900
So all the requests are getting rejected by extension.

417
00:46:23,520 --> 00:46:28,840
Therefore, we can see that even though the attacker is trying to fetch the information, that he won't be able to.

418
00:46:29,220 --> 00:46:30,740
And we'll just keep on reading.

419
00:46:30,760 --> 00:46:33,460
So that basically concludes our talk.

420
00:46:33,520 --> 00:46:40,180
We'll soon be launching the code for security on our GitHub after some modifications and bug fixes.

421
00:46:40,740 --> 00:46:42,400
And that's it.

422
00:46:42,400 --> 00:46:46,160
So thanks a lot for making it till the end and stay safe.