1 00:00:02,150 --> 00:00:07,130 We will now pass up for a moment the issue of physical access to a computer and we'll get to know what 2 00:00:07,130 --> 00:00:14,840 kind of information can be gathered remotely 30 years ago when that working protocols still in use today 3 00:00:14,840 --> 00:00:16,430 were being developed. 4 00:00:16,430 --> 00:00:22,420 Hardly anyone thought about security the first network connected for trusted computers. 5 00:00:23,700 --> 00:00:28,500 When you design a protocol to govern the communication between four computers that run three programs 6 00:00:28,530 --> 00:00:33,540 each and are used by seven people six of whom are your friends. 7 00:00:33,750 --> 00:00:38,030 You don't think much about security. 8 00:00:38,160 --> 00:00:45,200 You don't think how to protect them from DiDio US attacks or data flow tracking. 9 00:00:45,210 --> 00:00:52,500 This is why none of the protocols designed back then TCAP IAP included was designed with security in 10 00:00:52,500 --> 00:00:53,210 mind. 11 00:00:55,000 --> 00:00:58,750 This is very candidly stated in the RAFC architectural document. 12 00:01:00,180 --> 00:01:08,390 If you look up the original RAFC 11:22 document which describes a TCAP protocol you will find that it 13 00:01:08,390 --> 00:01:09,880 ends with the following note. 14 00:01:10,840 --> 00:01:16,790 There are many security issues in the communication layers of hostes software with a full discussion 15 00:01:16,790 --> 00:01:21,060 is beyond the scope of this RAFC. 16 00:01:21,210 --> 00:01:28,770 The problem persists low level protocols do not have any intrinsic security features. 17 00:01:28,780 --> 00:01:34,570 The problem is even more serious because high level protocols rely completely on low level protocols. 18 00:01:36,730 --> 00:01:43,840 High level protocols don't verify or validate the data sent by low level protocols. 19 00:01:43,840 --> 00:01:50,560 Moreover although the RAFC documents contain very detailed descriptions of protocols functions they 20 00:01:50,560 --> 00:01:54,840 lack implementation guidelines. 21 00:01:54,850 --> 00:02:03,330 This led to different implementations of the TZP IP stack people who were responsible for implementation 22 00:02:03,330 --> 00:02:10,870 of the protocols had to make some choices of their own and obviously their choices differed Ethernet 23 00:02:10,880 --> 00:02:19,260 minimum frame size is one example all Ethernet frames must carry a minimum payload. 24 00:02:19,310 --> 00:02:23,520 But what if an operating system wants to transfer less data than the minimum payload. 25 00:02:25,570 --> 00:02:28,800 It has to fill up the frame. 26 00:02:28,860 --> 00:02:33,230 The protocol standard does not specify what to fill up the frame with. 27 00:02:33,250 --> 00:02:36,840 The decision is made by the network card driver. 28 00:02:36,890 --> 00:02:41,550 It turns out that some drivers tend to fill up the frame with random data stored in the memory buffer. 29 00:02:43,150 --> 00:02:51,140 For example a part of the Word document we are currently preparing it is impossible to effectively secure 30 00:02:51,140 --> 00:02:53,890 protocols developed 30 or 40 years ago. 31 00:03:02,290 --> 00:03:07,060 It's difficult to fix that kind of situation because these standards are in constant use 32 00:03:10,020 --> 00:03:13,230 a common practice used to make up for it is to subnet or network 33 00:03:15,890 --> 00:03:20,050 that is to use network switches to split the network into smaller parts. 34 00:03:20,940 --> 00:03:25,830 It is not true that switches are safer than hubs. 35 00:03:26,040 --> 00:03:31,460 Nor is it true that two people connected to different ports at the same switch cannot see the other 36 00:03:31,470 --> 00:03:34,130 transmissions. 37 00:03:34,140 --> 00:03:36,590 There are ways to bypass that solution. 38 00:03:37,980 --> 00:03:45,220 The case is similar with virtual local area networks or volens Lancer's subnets created on a managed 39 00:03:45,220 --> 00:03:46,050 switch. 40 00:03:46,980 --> 00:03:53,680 You need only one managed switch to define multiple subnets users can be grouped in VLAN domains by 41 00:03:53,680 --> 00:03:58,790 ports or MAC addresses in such a networking arrangement. 42 00:03:58,800 --> 00:04:04,290 There must be a system to govern which Ethernet frame enters which port. 43 00:04:04,450 --> 00:04:12,870 This means the VLAN information tag must be inserted into the Internet frame this information is not 44 00:04:12,870 --> 00:04:17,800 in any way secured or encrypted. 45 00:04:17,840 --> 00:04:22,640 Moreover it can be modified in a way that enables tracking of data sent to other lands 46 00:04:28,930 --> 00:04:33,990 attackers exploit security weaknesses in the design of TCAP IP protocol. 47 00:04:35,970 --> 00:04:42,510 Transport layer protocols TZP and UDP reveal much information about the operating system and services 48 00:04:42,510 --> 00:04:46,140 performed by the computer. 49 00:04:46,280 --> 00:04:54,030 This is connected with the issue of scanning remote systems identifying open ports as a method of TCAP 50 00:04:54,030 --> 00:04:59,300 protocols scanning. 51 00:04:59,360 --> 00:05:05,790 We will try to establish a TCAP session but we will only initiate the procedure. 52 00:05:05,830 --> 00:05:10,980 We will send a sin synchronization packet but we won't respond to it. 53 00:05:11,210 --> 00:05:16,730 If we encounter a firewall protect a computer that filters send packets we will try to unexpectedly 54 00:05:16,730 --> 00:05:19,970 end the session and we'll wait for a response from the firewall. 55 00:05:22,380 --> 00:05:26,940 It is possible that it will send this back and Aristid packet which will tell us that the port behind 56 00:05:26,940 --> 00:05:29,740 the firewall is open. 57 00:05:29,820 --> 00:05:35,050 We can scan a computer protected by a firewall by fragmenting packets. 58 00:05:35,130 --> 00:05:42,510 We can do fragmentation at a lower layer thanks to that after reassembling the peccant is not treated 59 00:05:42,510 --> 00:05:44,120 by the firewall as hostile.