WEBVTT 1 00:00:00.000 --> 00:00:01.260 In this lesson, 2 00:00:01.260 --> 00:00:04.410 we will learn about DNS security. 3 00:00:04.410 --> 00:00:08.130 DNS security is used to protect the system 4 00:00:08.130 --> 00:00:11.100 from attacks and misconfigurations 5 00:00:11.100 --> 00:00:15.000 that could disrupt or manipulate network traffic. 6 00:00:15.000 --> 00:00:17.190 DNS security concepts 7 00:00:17.190 --> 00:00:22.190 include the Domain Name Security Extensions or DNSSEC, 8 00:00:22.650 --> 00:00:27.540 zone transfers, DNS poisoning, and sinkholing. 9 00:00:27.540 --> 00:00:30.750 Domain Name System Security Extensions 10 00:00:30.750 --> 00:00:35.520 add a layer of security to the name resolution process 11 00:00:35.520 --> 00:00:38.550 by digitally signing DNS data 12 00:00:38.550 --> 00:00:42.120 to ensure its integrity and authenticity. 13 00:00:42.120 --> 00:00:47.100 Next, zone transfers are a normal and expected mechanism 14 00:00:47.100 --> 00:00:52.100 used to replicate DNS databases across DNS servers, 15 00:00:52.170 --> 00:00:56.970 but if misconfigured, the process can be attacked. 16 00:00:56.970 --> 00:01:00.780 Next, DNS poisoning or cache poisoning 17 00:01:00.780 --> 00:01:03.690 is an attack where false DNS data 18 00:01:03.690 --> 00:01:07.650 is injected into a DNS resolver's cache. 19 00:01:07.650 --> 00:01:11.610 And finally, sinkholing is a defensive technique 20 00:01:11.610 --> 00:01:14.190 that redirects malicious traffic, 21 00:01:14.190 --> 00:01:17.790 such as that resulting from DNS poisoning, 22 00:01:17.790 --> 00:01:21.000 to a safe destination for analysis. 23 00:01:21.000 --> 00:01:26.000 Let's learn more about DNS Security Extensions or DNSSEC, 24 00:01:26.010 --> 00:01:30.960 zone transfers, DNS poisoning, and DNS sinkholing. 25 00:01:30.960 --> 00:01:33.000 Then we'll do a quick demo 26 00:01:33.000 --> 00:01:35.200 showing an act of directory misconfiguration 27 00:01:36.510 --> 00:01:39.450 that could lead to a zone transfer attack. 28 00:01:39.450 --> 00:01:43.290 First we have DNS Security Extensions, 29 00:01:43.290 --> 00:01:48.290 but before diving into DNS Security Extensions or DNSSEC, 30 00:01:48.690 --> 00:01:51.180 let's review how DNS works. 31 00:01:51.180 --> 00:01:55.920 Whenever you try to visit a website like diontraining.com, 32 00:01:55.920 --> 00:01:58.050 your computer needs to figure out 33 00:01:58.050 --> 00:02:00.330 where that website is located. 34 00:02:00.330 --> 00:02:03.720 However, computers do not understand names 35 00:02:03.720 --> 00:02:05.130 the way people do. 36 00:02:05.130 --> 00:02:08.940 Instead, they use and understand IP addresses, 37 00:02:08.940 --> 00:02:13.290 like 66.23.47.12. 38 00:02:13.290 --> 00:02:16.080 The Domain Name System or DNS 39 00:02:16.080 --> 00:02:20.070 is the service that translates human-friendly domain names 40 00:02:20.070 --> 00:02:23.250 into machine-friendly IP addresses. 41 00:02:23.250 --> 00:02:26.250 This process happens behind the scenes 42 00:02:26.250 --> 00:02:29.613 every time you click on a link or type in a URL. 43 00:02:30.780 --> 00:02:35.610 The problem with DNS is that it was created in the 1980s 44 00:02:35.610 --> 00:02:37.920 when fewer people used the internet 45 00:02:37.920 --> 00:02:41.070 and security was less of a concern. 46 00:02:41.070 --> 00:02:45.870 As a result, DNS lacks built-in security features. 47 00:02:45.870 --> 00:02:49.290 When your computer tries to resolve a domain name, 48 00:02:49.290 --> 00:02:51.660 it goes through a series of steps, 49 00:02:51.660 --> 00:02:53.970 starting at the root servers, 50 00:02:53.970 --> 00:02:58.970 then the top-level domain servers like .com or .org, 51 00:02:59.970 --> 00:03:04.170 then to domain servers like diontraining.com, 52 00:03:04.170 --> 00:03:08.880 and so on until it finds the correct IP address. 53 00:03:08.880 --> 00:03:12.300 This is called iterative DNS resolution. 54 00:03:12.300 --> 00:03:15.420 Unfortunately, there is no way to verify 55 00:03:15.420 --> 00:03:18.840 whether the response your computer finally gets 56 00:03:18.840 --> 00:03:21.930 is actually from the correct source. 57 00:03:21.930 --> 00:03:25.620 Attackers can take advantage of this vulnerability 58 00:03:25.620 --> 00:03:27.900 by sending fake responses, 59 00:03:27.900 --> 00:03:32.130 which then gets stored or cached in your DNS server 60 00:03:32.130 --> 00:03:34.050 as if they were legitimate. 61 00:03:34.050 --> 00:03:37.170 This is known as DNS cache poisoning, 62 00:03:37.170 --> 00:03:40.650 and it could direct a victim to a malicious website 63 00:03:40.650 --> 00:03:45.210 without the victim even realizing they are being redirected. 64 00:03:45.210 --> 00:03:50.190 To address this, DNS Security Extensions or DNSSEC 65 00:03:50.190 --> 00:03:53.179 were introduced in the 1990s. 66 00:03:53.179 --> 00:03:55.710 DNSSEC uses digital signatures 67 00:03:55.710 --> 00:03:57.960 and public key cryptography 68 00:03:57.960 --> 00:04:01.770 to ensure that DNS data is authentic. 69 00:04:01.770 --> 00:04:05.250 To do this, each DNS zone is given 70 00:04:05.250 --> 00:04:07.560 a public and private key. 71 00:04:07.560 --> 00:04:10.560 The zone owner uses the private key 72 00:04:10.560 --> 00:04:13.860 to digitally sign the DNS data, 73 00:04:13.860 --> 00:04:17.160 ensuring that it's from the correct source. 74 00:04:17.160 --> 00:04:20.730 The public key, which is available to everyone, 75 00:04:20.730 --> 00:04:23.610 is then used to verify the data. 76 00:04:23.610 --> 00:04:26.010 This process prevents attackers 77 00:04:26.010 --> 00:04:29.370 from poisoning the cache with false data 78 00:04:29.370 --> 00:04:32.640 because the system checks the digital signature 79 00:04:32.640 --> 00:04:36.090 before accepting any DNS responses. 80 00:04:36.090 --> 00:04:41.040 However, both the DNS zone owner and the resolvers, 81 00:04:41.040 --> 00:04:44.880 which are the two systems that request DNS data, 82 00:04:44.880 --> 00:04:48.750 need to be configured to support DNSSEC. 83 00:04:48.750 --> 00:04:51.690 So, if you manage a DNS server, 84 00:04:51.690 --> 00:04:54.990 enabling DNSSEC can protect your network 85 00:04:54.990 --> 00:04:56.460 from cache poisoning 86 00:04:56.460 --> 00:05:00.870 and ensure the accuracy of your DNS records. 87 00:05:00.870 --> 00:05:03.810 Second we have zone transfers. 88 00:05:03.810 --> 00:05:08.160 A DNS zone is a portion of the DNS namespace 89 00:05:08.160 --> 00:05:13.140 that a specific DNS server or a group of servers manages. 90 00:05:13.140 --> 00:05:16.380 Zone transfers are the normal process 91 00:05:16.380 --> 00:05:19.890 by which DNS servers share and synchronize 92 00:05:19.890 --> 00:05:23.550 this zone information amongst themselves. 93 00:05:23.550 --> 00:05:28.550 For instance, if one authoritative DNS server goes down, 94 00:05:28.620 --> 00:05:32.610 another authoritative DNS server can take over 95 00:05:32.610 --> 00:05:35.370 because it already has a copy 96 00:05:35.370 --> 00:05:38.310 of the same DNS zone data. 97 00:05:38.310 --> 00:05:42.870 This makes zone transfers an essential part of DNS, 98 00:05:42.870 --> 00:05:47.640 ensuring that multiple servers have up-to-date information, 99 00:05:47.640 --> 00:05:51.360 which improves reliability and redundancy. 100 00:05:51.360 --> 00:05:55.950 However, if zone transfers are not properly secured, 101 00:05:55.950 --> 00:05:57.810 they can be exploited. 102 00:05:57.810 --> 00:06:02.430 An attacker could initiate an unauthorized zone transfer 103 00:06:02.430 --> 00:06:06.840 and gain access to all the DNS records in a zone. 104 00:06:06.840 --> 00:06:09.480 This could reveal critical details 105 00:06:09.480 --> 00:06:11.760 about the network's infrastructure, 106 00:06:11.760 --> 00:06:15.510 including system names and IP addresses, 107 00:06:15.510 --> 00:06:17.850 making it easier for the attacker 108 00:06:17.850 --> 00:06:20.130 to target those systems. 109 00:06:20.130 --> 00:06:22.410 So, to prevent this, 110 00:06:22.410 --> 00:06:25.800 administrators must secure zone transfers 111 00:06:25.800 --> 00:06:28.050 by limiting which DNS servers 112 00:06:28.050 --> 00:06:31.470 are authorized to request a zone transfer 113 00:06:31.470 --> 00:06:36.470 and using methods like transaction signatures or TSIGs 114 00:06:36.720 --> 00:06:39.180 to authenticate the transfer. 115 00:06:39.180 --> 00:06:41.310 Without proper security, 116 00:06:41.310 --> 00:06:45.390 zone transfers can become a significant vulnerability, 117 00:06:45.390 --> 00:06:47.940 exposing sensitive information 118 00:06:47.940 --> 00:06:51.090 and increasing the risk of an attack. 119 00:06:51.090 --> 00:06:54.150 Third we have a DNS poisoning. 120 00:06:54.150 --> 00:06:57.480 DNS cache poisoning occurs with an attacker 121 00:06:57.480 --> 00:07:01.440 sends fake or malicious DNS responses, 122 00:07:01.440 --> 00:07:06.150 which are then accepted as valid by the DNS resolver. 123 00:07:06.150 --> 00:07:08.610 Once the fake response is stored 124 00:07:08.610 --> 00:07:11.850 or cached on the DNS server, 125 00:07:11.850 --> 00:07:14.400 anyone who requests that domain 126 00:07:14.400 --> 00:07:17.310 will be sent to the wrong IP address, 127 00:07:17.310 --> 00:07:19.800 often controlled by an attacker. 128 00:07:19.800 --> 00:07:22.980 This can lead users to malicious websites 129 00:07:22.980 --> 00:07:24.660 that appear legitimate, 130 00:07:24.660 --> 00:07:29.070 but are designed to steal information or install malware. 131 00:07:29.070 --> 00:07:34.070 Attackers use several techniques to poison a DNS cache. 132 00:07:34.110 --> 00:07:38.460 One common method is DNS response spoofing. 133 00:07:38.460 --> 00:07:41.700 Here, the attacker floods the DNS server 134 00:07:41.700 --> 00:07:43.530 with fake responses, 135 00:07:43.530 --> 00:07:47.220 hoping one matches a legitimate request. 136 00:07:47.220 --> 00:07:51.090 If the DNS server accepts the malicious response, 137 00:07:51.090 --> 00:07:54.030 it will store the incorrect information 138 00:07:54.030 --> 00:07:58.050 and return it to anyone who asks for that domain. 139 00:07:58.050 --> 00:08:01.230 Another method is exploiting vulnerabilities 140 00:08:01.230 --> 00:08:05.460 in outdated or poorly-configured DNS servers, 141 00:08:05.460 --> 00:08:10.460 which may accept data without verifying its authenticity. 142 00:08:10.530 --> 00:08:13.170 Once DNS poisoning occurs, 143 00:08:13.170 --> 00:08:15.390 it can be hard to detect. 144 00:08:15.390 --> 00:08:19.290 Users might not realize they are on a fake website 145 00:08:19.290 --> 00:08:21.960 because everything will look normal. 146 00:08:21.960 --> 00:08:26.100 This makes DNS poisoning a dangerous attack. 147 00:08:26.100 --> 00:08:27.780 To defend against it, 148 00:08:27.780 --> 00:08:32.520 DNS servers should implement security measures like DNSSEC, 149 00:08:32.520 --> 00:08:37.230 which verifies DNS responses with digital signatures. 150 00:08:37.230 --> 00:08:41.580 Additionally, keeping DNS servers updated and patched 151 00:08:41.580 --> 00:08:45.840 helps close vulnerabilities that attackers might exploit. 152 00:08:45.840 --> 00:08:49.231 Fourth and last, we have sinkholing. 153 00:08:49.231 --> 00:08:54.231 DNS sinkholing is a technique used by security professionals 154 00:08:54.240 --> 00:08:59.010 to divert malicious traffic away from its intended target 155 00:08:59.010 --> 00:09:02.160 and direct it to a controlled environment 156 00:09:02.160 --> 00:09:04.350 called a sinkhole server. 157 00:09:04.350 --> 00:09:07.470 So, instead of letting harmful traffic 158 00:09:07.470 --> 00:09:09.360 reach its destination, 159 00:09:09.360 --> 00:09:12.630 like an external command and control server, 160 00:09:12.630 --> 00:09:14.880 the DNS server redirects it 161 00:09:14.880 --> 00:09:17.850 to a safe location called a sinkhole. 162 00:09:17.850 --> 00:09:22.850 This is especially useful for stopping malware like botnets 163 00:09:23.040 --> 00:09:25.440 from communicating for direction 164 00:09:25.440 --> 00:09:28.080 or spreading their malicious code. 165 00:09:28.080 --> 00:09:32.790 The DNS sinkholing process starts when the DNS server 166 00:09:32.790 --> 00:09:37.560 identifies a malicious domain or IP address. 167 00:09:37.560 --> 00:09:39.840 The server is then configured 168 00:09:39.840 --> 00:09:43.590 to reroute any traffic headed to that domain 169 00:09:43.590 --> 00:09:46.260 into the sinkhole instead. 170 00:09:46.260 --> 00:09:50.370 For instance, if malware on an infected device 171 00:09:50.370 --> 00:09:53.760 tries to connect to a command and control server 172 00:09:53.760 --> 00:09:56.310 to receive further instructions, 173 00:09:56.310 --> 00:09:59.280 the DNS server intercepts the request 174 00:09:59.280 --> 00:10:02.250 and directs it to the sinkhole instead. 175 00:10:02.250 --> 00:10:05.520 The sinkhole server either drops the traffic 176 00:10:05.520 --> 00:10:09.240 or allows security analysts to monitor it 177 00:10:09.240 --> 00:10:11.970 in a safe and controlled environment, 178 00:10:11.970 --> 00:10:16.050 giving them insight into how the malware is operating. 179 00:10:16.050 --> 00:10:19.080 DNS sinkholing is an effective strategy 180 00:10:19.080 --> 00:10:23.160 for stopping further damage after a threat is detected. 181 00:10:23.160 --> 00:10:24.960 It cuts off communication 182 00:10:24.960 --> 00:10:28.740 between infected devices and their controllers, 183 00:10:28.740 --> 00:10:33.300 which helps stop the spread of malware and maliciousness. 184 00:10:33.300 --> 00:10:36.510 For sinkholing to work properly, however, 185 00:10:36.510 --> 00:10:39.870 the DNS server must be regularly updated 186 00:10:39.870 --> 00:10:42.150 with the latest threat intelligence 187 00:10:42.150 --> 00:10:46.290 to ensure it knows which domains or IP addresses 188 00:10:46.290 --> 00:10:49.140 are linked with malicious activity. 189 00:10:49.140 --> 00:10:52.770 Additionally, sinkhole servers must be secured 190 00:10:52.770 --> 00:10:57.270 to prevent them from becoming a new target for attackers. 191 00:10:57.270 --> 00:11:00.270 Now, let's take a look at a demonstration 192 00:11:00.270 --> 00:11:02.940 that highlights a misconfiguration 193 00:11:02.940 --> 00:11:05.850 that could lead to a zone transfer attack 194 00:11:05.850 --> 00:11:08.970 in Microsoft Active Directory. 195 00:11:08.970 --> 00:11:10.410 In this demonstration, 196 00:11:10.410 --> 00:11:12.180 I have two virtual machines 197 00:11:12.180 --> 00:11:14.940 running on the same virtual network. 198 00:11:14.940 --> 00:11:16.470 On the left-hand side, 199 00:11:16.470 --> 00:11:19.950 I have a Parrot Security Operating System operating. 200 00:11:19.950 --> 00:11:21.930 On the right-hand side of the screen, 201 00:11:21.930 --> 00:11:25.260 I have Windows Server 2022 operating 202 00:11:25.260 --> 00:11:27.930 with a DNS service configured. 203 00:11:27.930 --> 00:11:30.720 Let's take a closer look at the DNS records 204 00:11:30.720 --> 00:11:34.380 by going to Tools then DNS. 205 00:11:34.380 --> 00:11:36.420 Here in the DNS Manager, 206 00:11:36.420 --> 00:11:40.080 you can see that I have a forward lookup zone configured 207 00:11:40.080 --> 00:11:42.570 called myZone.com. 208 00:11:42.570 --> 00:11:44.340 And in this zone, 209 00:11:44.340 --> 00:11:47.940 I've configured a few DNS records. 210 00:11:47.940 --> 00:11:51.060 Let's prove that we can query for those records 211 00:11:51.060 --> 00:11:54.360 from the Parrot Security Operating System. 212 00:11:54.360 --> 00:11:56.100 We'll use the dig command 213 00:11:56.100 --> 00:11:59.703 and just look for an A record for myZone.com. 214 00:12:00.990 --> 00:12:02.550 And we've got an answer. 215 00:12:02.550 --> 00:12:04.530 We can see that the IP address 216 00:12:04.530 --> 00:12:09.277 that was returned for myZone.com is 192.168.56.111. 217 00:12:13.020 --> 00:12:16.410 We could even test for the mail exchange record 218 00:12:16.410 --> 00:12:20.310 by just changing our dig request. 219 00:12:20.310 --> 00:12:25.310 And you can see that there is a myZoneEmailServer01.com 220 00:12:25.500 --> 00:12:28.620 that is configured in these DNS records. 221 00:12:28.620 --> 00:12:32.370 If we wanted to try to grab all of the records at one time, 222 00:12:32.370 --> 00:12:34.740 we could attempt a zone transfer. 223 00:12:34.740 --> 00:12:39.390 That would be done using the axfr command in dig. 224 00:12:39.390 --> 00:12:41.100 Let's go ahead and try it. 225 00:12:41.100 --> 00:12:43.710 We can see that that transfer failed 226 00:12:43.710 --> 00:12:48.210 because of the configuration on Windows Server 2022, 227 00:12:48.210 --> 00:12:50.250 but what we are going to find 228 00:12:50.250 --> 00:12:53.220 is that we're only one selection away 229 00:12:53.220 --> 00:12:58.050 from allowing zone transfers to anyone who requests them 230 00:12:58.050 --> 00:13:02.070 on this Windows Server 2022 configuration. 231 00:13:02.070 --> 00:13:07.070 So, I'll go to myZone.com and I'll select Properties. 232 00:13:08.040 --> 00:13:11.880 In Properties, I'm going to go to the Zone Transfers tab, 233 00:13:11.880 --> 00:13:14.970 and you can see that zone transfers are allowed, 234 00:13:14.970 --> 00:13:17.670 and again, they are a totally normal part 235 00:13:17.670 --> 00:13:20.760 of operations within a domain. 236 00:13:20.760 --> 00:13:23.340 And you can see we are currently configured 237 00:13:23.340 --> 00:13:26.310 to allow zone transfers only to servers 238 00:13:26.310 --> 00:13:29.040 listed in the Name Servers tab, 239 00:13:29.040 --> 00:13:30.333 and there is only one. 240 00:13:31.562 --> 00:13:34.770 But we are going to insert a misconfiguration 241 00:13:34.770 --> 00:13:38.550 and we're going to allow zone transfers to any server. 242 00:13:38.550 --> 00:13:42.660 So, one select of the radio button to any server 243 00:13:42.660 --> 00:13:45.150 and one click of the Apply, 244 00:13:45.150 --> 00:13:48.540 now let's try that zone transfer 245 00:13:48.540 --> 00:13:51.030 from Parrot Security again. 246 00:13:51.030 --> 00:13:53.310 And you can see that we were able to grab 247 00:13:53.310 --> 00:13:58.230 all of the records from the DNS server at myZone.com 248 00:13:58.230 --> 00:14:00.930 with our zone transfer request. 249 00:14:00.930 --> 00:14:02.790 So, as you can see, 250 00:14:02.790 --> 00:14:07.110 the zone transfer here to a simulated unauthorized device, 251 00:14:07.110 --> 00:14:10.230 the Parrot Security machine, was permitted, 252 00:14:10.230 --> 00:14:15.180 and we were only a single radio button selection and apply 253 00:14:15.180 --> 00:14:17.190 from this misconfiguration 254 00:14:17.190 --> 00:14:20.400 that could lead to this significant vulnerability. 255 00:14:20.400 --> 00:14:25.170 So, remember, DNS security is essential 256 00:14:25.170 --> 00:14:29.490 to protect networks from attacks and misconfigurations 257 00:14:29.490 --> 00:14:32.400 that could compromise network traffic. 258 00:14:32.400 --> 00:14:35.010 Key concepts in DNS security 259 00:14:35.010 --> 00:14:40.010 include Domain Name System Security Extensions or DNSSEC, 260 00:14:40.350 --> 00:14:45.350 zone transfers, DNS poisoning, and DNS sinkholing. 261 00:14:46.262 --> 00:14:49.620 DNSSEC adds a layer of security 262 00:14:49.620 --> 00:14:51.540 by using digital signatures 263 00:14:51.540 --> 00:14:55.530 to verify the authenticity of DNS data, 264 00:14:55.530 --> 00:14:57.780 ensuring that users are directed 265 00:14:57.780 --> 00:15:00.810 to the correct IP addresses. 266 00:15:00.810 --> 00:15:02.970 Next, zone transfers, 267 00:15:02.970 --> 00:15:06.390 which allow DNS servers to synchronize data, 268 00:15:06.390 --> 00:15:09.030 must be secured to prevent attackers 269 00:15:09.030 --> 00:15:13.860 from gaining unauthorized access to sensitive DNS records. 270 00:15:13.860 --> 00:15:17.670 Next, DNS poisoning or cache poisoning 271 00:15:17.670 --> 00:15:21.660 occurs when attackers insert false DNS data 272 00:15:21.660 --> 00:15:23.760 into a server's cache, 273 00:15:23.760 --> 00:15:27.150 redirecting users to malicious sites. 274 00:15:27.150 --> 00:15:31.440 And finally, DNS sinkholing is a defensive technique 275 00:15:31.440 --> 00:15:35.640 that redirects malicious traffic to a safe server, 276 00:15:35.640 --> 00:15:39.873 preventing malware from reaching its intended destination.