1 00:00:04,360 --> 00:00:10,600 When you exit please exit out the back right side. Actually if you're looking at me it's 2 00:00:10,600 --> 00:00:13,920 your back left side. My right side. 3 00:00:30,340 --> 00:00:35,360 Good body girl, way up body look tight. And me and you up inside this dance here tonight. 4 00:00:35,560 --> 00:00:39,800 Me no see you with no partner, who up say me right. She say no, but she still say you 5 00:00:39,800 --> 00:00:44,980 forward and right. Then we go inna the corner. Outta the life us make the, buy you a drink 6 00:00:44,980 --> 00:00:49,540 babes if that's alright. Me ask her what she want, she say brandy and Sprite. So are you 7 00:00:49,540 --> 00:00:51,840 want a double? She say yeah if you like. 8 00:01:00,120 --> 00:01:01,520 Yeah. 9 00:01:07,520 --> 00:01:08,920 Yeah. 10 00:01:11,280 --> 00:01:12,680 Yeah. 11 00:01:14,880 --> 00:01:16,280 Yeah. 12 00:01:16,460 --> 00:01:17,760 Yeah. 13 00:01:24,460 --> 00:01:25,160 Yeah. 14 00:01:35,660 --> 00:01:40,780 Good body girl, way up body look tight. And me and you up inside this dance here tonight. 15 00:01:40,940 --> 00:01:45,600 We no see you with no partner, who up say me right. She say no, but she still say you forward 16 00:01:45,600 --> 00:01:50,720 and right. Then we go inna the corner. Outta the life us make the, buy you a drink babes 17 00:01:50,720 --> 00:01:55,320 if that's alright. Me ask her what she want, she say brandy and Sprite. So are you want 18 00:01:55,320 --> 00:01:59,640 to double? She say yeah if you like. Come back with this drink stem, grab she by the 19 00:01:59,640 --> 00:02:02,580 Take her now and darken her via Snow White session 20 00:02:02,580 --> 00:02:05,060 The way she hold me, me feel the connection 21 00:02:05,520 --> 00:02:07,740 Me know she feel me cause she ask me a question 22 00:02:07,740 --> 00:02:10,920 Some things where she a tell me Lord it turn me on 23 00:02:10,920 --> 00:02:13,580 And when she say she would a love a star in a pond 24 00:02:13,580 --> 00:02:16,100 Me leg them buckle, me head it gone 25 00:02:16,100 --> 00:02:18,800 Me long love it and me cure when me ready be proper 26 00:02:51,440 --> 00:02:54,200 You never, never, never, never cross over 27 00:02:54,200 --> 00:02:56,600 You never, never, never, never go far 28 00:02:56,600 --> 00:02:57,600 Rusha lalalalal 29 00:02:57,600 --> 00:02:59,600 I'll never cross over 30 00:02:59,600 --> 00:02:59,620 I'll never cross over 31 00:02:59,640 --> 00:03:02,300 You never, never, never, never go commercial 32 00:03:46,000 --> 00:03:48,460 You never, never, never, never go commercial 33 00:03:48,460 --> 00:03:51,320 You never, never, never, never go commercial 34 00:03:51,320 --> 00:03:56,800 You never, never, never, never go commercial 35 00:03:56,800 --> 00:03:59,100 Jump, jump, jump, jump 36 00:03:59,100 --> 00:03:59,620 Jump, jump, jump, jump 37 00:03:59,620 --> 00:04:03,000 Joke, joke, joke, joke 38 00:04:37,920 --> 00:04:59,600 Joke, joke, joke, joke 39 00:05:11,480 --> 00:05:29,600 Joke, joke, joke, joke 40 00:05:38,120 --> 00:05:58,380 Joke, joke, joke, joke 41 00:06:09,180 --> 00:06:29,540 Joke, joke, joke, joke 42 00:06:42,100 --> 00:06:59,600 Joke, joke, joke, joke 43 00:06:59,620 --> 00:07:29,580 Joke, joke, joke, joke 44 00:07:36,660 --> 00:07:59,600 Joke, joke, joke, joke 45 00:08:06,780 --> 00:08:27,580 Joke, joke, joke, joke 46 00:08:37,480 --> 00:08:59,540 Joke, joke, joke, joke 47 00:08:59,620 --> 00:09:29,520 Joke, joke, joke, joke 48 00:09:56,800 --> 00:09:59,600 Joke, joke, joke, joke 49 00:09:59,620 --> 00:10:00,380 Joke, joke, joke, joke 50 00:10:07,580 --> 00:10:25,620 Joke, joke, joke, joke, joke 51 00:10:36,840 --> 00:10:43,640 hello everyone and welcome to this talk called analyzing the security of bgp message passing 52 00:10:43,640 --> 00:10:49,940 so this talk will be presented by daniel dos santos and myself simon guillot 53 00:10:51,160 --> 00:10:58,780 so first quick introduction the people that work on this vulnerability research project 54 00:10:58,780 --> 00:11:05,840 are stanislav dashevsky amin amri and usama kero and there's a direction of daniel here 55 00:11:06,510 --> 00:11:14,080 and we are from the vedere labs team in at force code technologies and our mission 56 00:11:14,080 --> 00:11:19,260 includes the vulnerability research threat research and threat intelligence 57 00:11:21,170 --> 00:11:27,820 so now we're going to look at the relevant past research past research so is that we did 58 00:11:28,780 --> 00:11:37,560 so we had an initiative called project memoria where we analyzed multiple tcp ip stacks that 59 00:11:37,560 --> 00:11:47,120 we found in iot and ot devices and in total we found the 61 vulnerabilities that we presented 60 00:11:47,120 --> 00:11:55,080 to the community previously and this is inspired us to do this bgp research because most of the 61 00:11:55,080 --> 00:11:58,760 issues we formed were in were passing issue there and very few are in way Muslim 분�ity that is 62 00:11:58,780 --> 00:12:09,740 issues and we even published an informational RFC specifically about DNS implementations. 63 00:12:11,820 --> 00:12:18,920 So first Daniel will present you what is BGP and how and where it is used, then I will 64 00:12:19,200 --> 00:12:25,460 talk more about the vulnerabilities we found and the methodology we used and we will conclude 65 00:12:25,460 --> 00:12:27,080 with the security implications. 66 00:12:29,020 --> 00:12:34,180 So wait, hold on. So I just heard a rumor. You guys have never spoken here before, is that correct? 67 00:12:34,520 --> 00:12:34,800 First time. 68 00:12:35,240 --> 00:12:38,060 What's the tradition for first time speakers at DEF CON? 69 00:12:57,440 --> 00:12:58,720 There you go. 70 00:13:01,760 --> 00:13:04,200 To the first time speakers, Salud! 71 00:13:15,920 --> 00:13:18,080 So let's talk a little bit about BGP, right? 72 00:13:18,180 --> 00:13:24,460 And I do expect that a lot of people here will know at least that BGP exists, more or less what it's used for, 73 00:13:24,460 --> 00:13:30,500 and kind of what it looks like. But I want to talk a little bit about different uses of BGP as 74 00:13:30,500 --> 00:13:36,400 well that people might not be so much aware of. So first of all, you know, the Internet in kind 75 00:13:36,400 --> 00:13:42,420 of a nutshell, right? Where is BGP used that kind of everybody knows about? You have edge 76 00:13:42,420 --> 00:13:47,320 devices on a network communicating to other edge devices on a network, on another network, and 77 00:13:47,320 --> 00:13:51,800 those devices communicate via data packets that are routed from one network to another via 78 00:13:51,800 --> 00:13:56,060 routers, and those routers need to know how to get these packets, you know, from network A to 79 00:13:56,060 --> 00:14:00,540 network B, and BGP is the routing protocol that allows these routers to exchange routing 80 00:14:00,540 --> 00:14:05,800 information and kind of say, you know, I'm responsible for networks X, Y, and Z with this 81 00:14:05,800 --> 00:14:12,560 specific IP block and so on. And as Simon mentioned, we did some research in the past into 82 00:14:13,740 --> 00:14:18,620 TCP IP stacks and basically the protocols used at the edge devices, and now we wanted to focus 83 00:14:18,620 --> 00:14:21,500 on the router side of things and on BGP, right? 84 00:14:21,800 --> 00:14:27,060 So BGP, routing for the Internet, it's the protocol that is used to exchange routing and 85 00:14:27,060 --> 00:14:32,100 reachability information among autonomous systems, and an autonomous system is a block of 86 00:14:32,100 --> 00:14:37,300 IPs that is leased to an organization by a register for a certain time period, right? Just 87 00:14:37,300 --> 00:14:43,340 like you have in the domain name system, a domain is assigned to somebody for a certain period 88 00:14:43,340 --> 00:14:49,740 of time. Similarly, an autonomous system does that for a block of IPs. So BGP is the protocol 89 00:14:49,740 --> 00:14:51,780 that is used to advertise IPs. 90 00:14:51,800 --> 00:14:56,360 So it's based on autonomous system numbers and peer networks that are considered to be part of an 91 00:14:56,360 --> 00:15:02,100 autonomous system, and it can be either used internally within an autonomous system, so called 92 00:15:02,100 --> 00:15:09,220 internal BGP, or externally called external BGP with peers on the own Internet. And BGP is a 93 00:15:09,220 --> 00:15:13,620 protocol that makes routing decisions based on paths, network policies, rule sets, and so on, 94 00:15:13,660 --> 00:15:20,160 to kind of decide how a packet gets from one device in one network to another device in a network 95 00:15:20,160 --> 00:15:21,780 all the way on the other side of the network. 96 00:15:21,800 --> 00:15:25,960 side of the world potentially. But as I mentioned at the beginning, there are other use cases 97 00:15:25,960 --> 00:15:33,720 nowadays for BGP beyond the typical network internet scale routing. So data centers in the 98 00:15:33,720 --> 00:15:41,380 past decade have grown to such a large size that many organizations use BGP internally these 99 00:15:41,380 --> 00:15:49,600 days for routing internally in their own data centers, right? BGP is also used for MPLS, 100 00:15:49,600 --> 00:15:55,500 layer three VPNs across different organization sites. So a same organization that has sites 101 00:15:55,500 --> 00:16:00,580 across the globe and wants to connect them via a VPN sometimes use BGP to exchange specific 102 00:16:00,580 --> 00:16:06,400 information for making that VPN possible. It's also embedded in custom appliances that go 103 00:16:06,400 --> 00:16:12,020 sometimes in internet service providers or internet exchanges. Some content providers like 104 00:16:12,020 --> 00:16:17,920 Netflix, for instance, they have their specific way to, you know, treat traffic and do that more 105 00:16:17,920 --> 00:16:19,080 efficiently. And they 106 00:16:19,080 --> 00:16:19,580 kind of 107 00:16:19,580 --> 00:16:25,800 embed these appliances directly in some ISPs. And, you know, there are emerging use cases like 108 00:16:25,800 --> 00:16:31,220 load balancing and people get creative and they're using BGP for a lot of other use cases these 109 00:16:31,220 --> 00:16:37,520 days. So just want to kind of open your mind to the fact that everything that we mentioned, you 110 00:16:37,520 --> 00:16:43,460 know, BGP being used for the internet routing cases is the typical use case. It's what it's 111 00:16:43,460 --> 00:16:49,340 mostly used for still these days, but there are many other uses for it. So in summary, why I'm 112 00:16:49,340 --> 00:16:54,560 saying that is because BGP security per se is not just for internet service providers and internet 113 00:16:54,560 --> 00:17:00,300 exchanges anymore, right? Any organization will potentially be using a BGP and should be 114 00:17:00,300 --> 00:17:06,660 responsible for the security of BGP within their networks. So the basics of BGP, right, so BGP is 115 00:17:06,660 --> 00:17:13,140 a protocol with a kind of a simple state machine. You have six states there, a limited set of 116 00:17:13,140 --> 00:17:17,720 messages that, you know, transition from those states. So basically you have peers that are 117 00:17:17,720 --> 00:17:22,480 waiting. They set up a connection. There is a keep alive message that keeps that connection open 118 00:17:22,480 --> 00:17:27,840 that is sent every X seconds. There is a notification when some error happens or there's 119 00:17:27,840 --> 00:17:32,860 an update message to update the routing tables between the peers. And the packets are also 120 00:17:32,860 --> 00:17:40,980 relatively straightforward, right? So you have a package that has a header with a length and a 121 00:17:40,980 --> 00:17:46,060 type of a message. And then you have the content of the message, which is also not super complex, 122 00:17:46,180 --> 00:17:53,580 right? So what potentially could go wrong with BGP? So, well, the fact, and going back to kind 123 00:17:53,580 --> 00:17:57,880 of the basics, and this is something that is well known, that BGP, like DNS, like many other 124 00:17:57,880 --> 00:18:02,620 early Internet protocols, has no built-in security, right? Like authentication, authorization 125 00:18:02,620 --> 00:18:07,760 mechanisms, and things like that. So mistakes or intentional attacks that lead to network 126 00:18:07,760 --> 00:18:10,640 outages and traffic redirection in BGP happen. 127 00:18:10,980 --> 00:18:17,720 Frequently, right? The situation has been improving in past years. And we'll talk in the next 128 00:18:17,720 --> 00:18:22,920 slide a little bit about some of the traditional routing BGP security. But the fact is that 129 00:18:22,920 --> 00:18:30,580 still thousands of incidents happen per year of route leaks and hijacks, where basically a 130 00:18:30,580 --> 00:18:36,080 network or a router originates in the BGP jargon, right? So basically claims to be responsible 131 00:18:36,080 --> 00:18:40,960 for a prefix or a set of IPs that is owned by a network, another network, that is owned by a 132 00:18:40,980 --> 00:18:46,040 network without the permission of that other network, right? And that in some cases is used by 133 00:18:46,040 --> 00:18:52,540 attackers to make packets, you know, go through specific networks that an attacker controls and can 134 00:18:52,540 --> 00:18:59,040 maybe read or tamper with packets. So in many cases, it's actually accidental. And in other 135 00:18:59,040 --> 00:19:07,460 cases, it potentially is, you know, an actual attack, right? Especially when countries or more 136 00:19:07,460 --> 00:19:10,640 riskier countries, let's say, are involved in this kind of activity. 137 00:19:11,620 --> 00:19:17,680 So traditional BGP security has to do mainly with filtering out this incorrect or malicious routing 138 00:19:17,680 --> 00:19:22,680 information, right? Doing origin validation, so verifying that a network that announces a route is 139 00:19:22,680 --> 00:19:29,660 actually authorized to do it. And path validation, right? Ensuring that no unauthorized network is 140 00:19:29,660 --> 00:19:36,260 actually diverting traffic via a false route. So there are many techniques, protocols, and ideas 141 00:19:36,260 --> 00:19:40,960 these days to do that. And I invite you to have a look at those specific techniques that you can use to 142 00:19:40,980 --> 00:19:49,880 do these things, like RPKI, BGP Sec, and so on. But again, most of BGP security until now, you know, 143 00:19:49,960 --> 00:19:57,820 like the typical discussion around BGP security is always this kind of routing security, right? 144 00:19:57,900 --> 00:20:04,360 But what about vulnerabilities in BGP implementations themselves? So when BGP fails because of software 145 00:20:04,360 --> 00:20:10,140 implementations, it has happened in the past also, specific incidents where because of different 146 00:20:10,980 --> 00:20:16,280 implementations and the way that some BGP implementations would parse messages, routers would 147 00:20:16,280 --> 00:20:21,840 actually crash and, you know, cause network outages and things like that. So specific example that 148 00:20:21,840 --> 00:20:26,880 happened in 2019 with the FR routing BGP implementation, and we're going to talk a little bit 149 00:20:26,880 --> 00:20:33,780 further about FR routing in the rest of this presentation, it led to some network outages around 150 00:20:33,780 --> 00:20:39,740 Asia and Australia that the fact was that some researchers were trying some new features, 151 00:20:40,980 --> 00:20:45,780 that we were trying some new things in the kind of an academic task, but the fact is that not every 152 00:20:45,780 --> 00:20:52,200 router was ready to parse those new types of messages. So why do we think it's important then to research 153 00:20:52,200 --> 00:20:57,700 these BGP implementations, right? So the latest systematized work that we found about testing BGP 154 00:20:57,700 --> 00:21:04,360 implementations was 20 years ago, actually, exactly 20 years ago in 2003. It was a presentation at 155 00:21:04,360 --> 00:21:10,960 Black Hat, a team at Cisco that looked at both implementation and configuration of BGP across, like, 156 00:21:10,980 --> 00:21:16,380 different vendors. They did a work that actually turned out in the end, we did, we kind of followed 157 00:21:16,380 --> 00:21:21,520 some of their paths. So they created a fuzzer, they analyzed seven implementations and they found 158 00:21:21,520 --> 00:21:26,440 four new CVs at that time, right? But they also concluded that at that time, misconfigurations 159 00:21:26,440 --> 00:21:32,680 were more dangerous than actual implementation issues. And again, that was 20 years ago. There 160 00:21:32,680 --> 00:21:39,580 has been a lot of improvement in BGP and in the actual implementation of BGP security features 161 00:21:39,580 --> 00:21:47,460 in those 20 years, right? Also in 2007, a team at Juniper analyzed specifically the update message 162 00:21:47,460 --> 00:21:54,820 handling across several vendors and they issued an advisory together with the CertCC and they saw 163 00:21:54,820 --> 00:21:59,980 that mishandling of those update messages could lead to the loss of service in several cases. So 164 00:21:59,980 --> 00:22:07,340 they saw seven vendors affected, 10 not affected, and 25 that never responded to the advisory. And 165 00:22:07,340 --> 00:22:09,560 in the meantime, between, you know, the two of them, there was a lot going on. And so, in the 166 00:22:09,580 --> 00:22:16,780 middle of that 2003 original research and now, those 20 years, we actually found 129 CVs on BGP 167 00:22:16,780 --> 00:22:21,920 implementation. We found meaning, those exist already, right? Those were well known. We found in 168 00:22:21,920 --> 00:22:29,220 the national vulnerability database. And some of them include remote code executions. So 95% of 169 00:22:29,220 --> 00:22:33,960 those vulnerabilities are actually because of message parsing issues. So definitely it is a big 170 00:22:33,960 --> 00:22:39,040 problem in BGP implementations as well. So if we drill down a little bit into this 171 00:22:39,580 --> 00:22:48,120 previous vulnerabilities, we see that there is a mix of CVs on open and closed implementations of 172 00:22:48,120 --> 00:22:53,260 BGP, right? So if you look, for instance, at Cisco and Juniper, the big networking vendors, of 173 00:22:53,260 --> 00:22:59,980 course, there have been CVs on equipment from those vendors. But there's also implementations 174 00:22:59,980 --> 00:23:05,160 like the project I mentioned before, FR routing, which in the figure there, we actually put 175 00:23:05,160 --> 00:23:09,560 Quaga and FR routing together because Quaga is the project that we're working on right now. And so, 176 00:23:09,580 --> 00:23:14,720 the project that originated FR routing, FR routing is a more recent fork of the Quaga project. And 177 00:23:15,520 --> 00:23:21,360 again, just to make sure that we're all on the same page, the fact that Juniper and Cisco are 178 00:23:21,360 --> 00:23:24,520 highlighted there with, you know, a higher number of vulnerabilities doesn't mean necessarily 179 00:23:24,520 --> 00:23:28,200 that they are the most vulnerable, right? It's just because they're vendors that actually issue 180 00:23:28,200 --> 00:23:32,480 CVs and they do their own research and from time to time publish issues and so, so, potentially 181 00:23:32,480 --> 00:23:39,560 they are the more transparent, not necessarily the more vulnerable. But if we look at the 182 00:23:39,580 --> 00:23:46,000 CVs, those, again, 120 something in the past 20 years per impact, we see that the vast majority of 183 00:23:46,000 --> 00:23:50,700 them allowed for denial of service. Some of them also allowed for information leaks or remote code 184 00:23:50,700 --> 00:23:56,480 executions, but the vast majority was denial of service. And if we look at the timeline of 185 00:23:56,480 --> 00:24:02,480 disclosure for those vulnerabilities, we see that there is an increasing interest starting more or 186 00:24:02,480 --> 00:24:09,560 less from 2017. So, from 2017 onwards, there is always at least around 15, 18, 20, 20, 30, 30, 187 00:24:09,580 --> 00:24:16,180 20 vulnerabilities per year on BGP implementations, popular BGP implementations being discovered. 188 00:24:17,720 --> 00:24:22,020 So, going beyond the vulnerabilities and into kind of the threat landscape per se, right? So, 189 00:24:22,140 --> 00:24:27,400 okay, we know that vulnerabilities exist, but still, why does it even matter to look at these 190 00:24:27,400 --> 00:24:32,360 things? So, the first point is that threat actors are focusing on network infrastructure these 191 00:24:32,360 --> 00:24:36,320 days, right? This is something that, I mean, it always has happened, of course, but it has been 192 00:24:36,320 --> 00:24:39,560 intensifying. And there are examples of, you know, there's a lot of, you know, there's a lot of 193 00:24:39,580 --> 00:24:44,460 nation-state actors, but also ransomware groups, other cybercriminals, hacktivists. It's becoming 194 00:24:44,460 --> 00:24:50,500 more and more widespread and popular to go after network infrastructure, things like routers, 195 00:24:50,540 --> 00:24:55,580 things like switches, firewalls, and so on, that are kind of at the perimeters of networks, 196 00:24:55,760 --> 00:25:00,860 right? So, recently, a couple of months ago, actually, CISA released a Biden operational 197 00:25:00,860 --> 00:25:08,080 directive specifically about the risks of exposed management interfaces on network 198 00:25:08,080 --> 00:25:09,320 infrastructure devices, right? 199 00:25:10,060 --> 00:25:17,080 Partly because of this increased interest from threat actors into this kind of device. But 200 00:25:17,080 --> 00:25:21,920 still, there are several BGP implementations that were not systematically analyzed. And as I 201 00:25:21,920 --> 00:25:27,000 mentioned in the previous slide with some open implementations having vulnerabilities found, 202 00:25:27,160 --> 00:25:31,040 those open implementations are becoming very popular these days and gaining a lot of traction 203 00:25:31,040 --> 00:25:36,340 with a trend that is called network function disaggregation, NFT. And basically, network 204 00:25:36,340 --> 00:25:39,100 function disaggregation is the fact that network function disaggregation is the fact that network 205 00:25:39,100 --> 00:25:39,560 function disaggregation is the fact that network function disaggregation is the fact that network 206 00:25:39,580 --> 00:25:47,240 function disaggregation is the fact that network function disaggregation is the fact that network 207 00:25:47,240 --> 00:25:50,120 function disaggregation is the fact that network function disaggregation is the fact that network 208 00:25:50,120 --> 00:25:53,960 function disaggregation is the fact that network function disaggregation is the fact that network 209 00:25:54,540 --> 00:25:55,140 function disaggregation is the fact that network function disaggregation is the fact that network 210 00:25:55,140 --> 00:25:57,300 function disaggregation is the fact that network function disaggregation is the fact that network 211 00:25:57,300 --> 00:25:59,360 function disaggregation is the fact that network function disaggregation is the fact that network 212 00:25:59,360 --> 00:26:01,880 function disaggregation is the fact that network function disaggregation is the fact that network 213 00:26:01,880 --> 00:26:04,020 function disaggregation is the fact that network function disaggregation is the fact that network 214 00:26:04,020 --> 00:26:08,520 function disaggregation is the fact that network function disaggregation is the fact that network 215 00:26:08,520 --> 00:26:15,460 52 routing protocols, 40 of those are open, 12 are closed protocols, 20 routing platforms, 216 00:26:15,720 --> 00:26:21,280 17 of those were open, and 53 network operating systems, and 20 of those were open. 217 00:26:21,480 --> 00:26:23,980 So of course we had to narrow down the research, right? 218 00:26:24,360 --> 00:26:31,120 It's a lot, like we cannot look at 53 different network operating systems, so we kind of went 219 00:26:31,120 --> 00:26:35,980 after the most popular ones, and Simone is going to mention that in the methodology part 220 00:26:35,980 --> 00:26:36,440 later on. 221 00:26:37,900 --> 00:26:45,460 But going a little bit deeper even into the threat landscape and threat actors looking 222 00:26:45,460 --> 00:26:47,460 into network infrastructure, as I mentioned before. 223 00:26:47,960 --> 00:26:55,420 So CISA tracks, well, in May it was 925 non-exploited vulnerabilities, now it's probably a little 224 00:26:55,420 --> 00:26:56,400 bit closer to 1,000. 225 00:26:56,500 --> 00:27:03,120 And most of those affect traditional IT software, right, Windows, Linux, Mac, you know, Adobe 226 00:27:03,120 --> 00:27:04,260 and so on and so on. 227 00:27:04,320 --> 00:27:05,860 But 179. 228 00:27:05,860 --> 00:27:09,580 179 of those vulnerabilities can actually be mapped to specific devices that you will 229 00:27:09,580 --> 00:27:10,300 have on your network. 230 00:27:10,520 --> 00:27:18,320 And out of those, 88, or almost 50%, 49% of those 179 target specifically routers. 231 00:27:18,420 --> 00:27:23,700 So they're the most popular type of device being actually attacked right now. 232 00:27:25,120 --> 00:27:32,420 And yeah, I'm referring to another presentation there at Virus Bulletin in 2019 that talks 233 00:27:32,420 --> 00:27:34,980 a little bit about this threat landscape for routers as well. 234 00:27:34,980 --> 00:27:36,180 Have a look at that. 235 00:27:36,260 --> 00:27:40,380 But the reasons are kind of obvious, right, why attackers would go after routers. 236 00:27:40,460 --> 00:27:41,160 They are at the perimeter. 237 00:27:41,500 --> 00:27:47,100 There are new vulnerabilities coming up all the time in routers, and they tend to be not 238 00:27:47,100 --> 00:27:52,380 that difficult to exploit as, you know, exploit mitigations and things like that are not 239 00:27:52,380 --> 00:27:54,980 always yet implemented in this type of device. 240 00:27:56,880 --> 00:28:04,960 But again, drilling even further down, non-exploited vulnerabilities on BGP, per se, right? 241 00:28:04,980 --> 00:28:13,940 Out of those 88 vulnerabilities that we saw exploited in routers, three of those are 242 00:28:14,600 --> 00:28:21,280 decades old CVEs affecting Cisco BGP devices that are being exploited in 2022. 243 00:28:22,860 --> 00:28:29,560 So even if a vulnerability is, you know, from 2010 or 2009 or 2017, as in the cases 244 00:28:29,560 --> 00:28:32,920 there, they are still being exploited up to this day, right? 245 00:28:33,540 --> 00:28:34,960 There were also other vulnerabilities. 246 00:28:34,980 --> 00:28:40,620 There were also other two denial-of-service vulnerabilities on Cisco IOS, but those are 247 00:28:40,620 --> 00:28:42,420 affecting a different protocol and not BGP. 248 00:28:42,500 --> 00:28:44,620 So we're focusing here on the BGP side. 249 00:28:44,780 --> 00:28:48,580 And the interesting thing is, keep it in mind, Simone will make the connections here 250 00:28:48,580 --> 00:28:51,780 later on, but keep it in mind that those vulnerabilities allow for denials of service. 251 00:28:51,860 --> 00:28:58,240 They are being exploited by threat actors, and they have to do mostly with the parsing 252 00:28:58,240 --> 00:29:01,860 of open messages in BGP implementations. 253 00:29:02,440 --> 00:29:04,960 So let's talk about the new research that we're doing. 254 00:29:07,340 --> 00:29:10,220 So first let's talk about our methodology. 255 00:29:11,360 --> 00:29:18,280 So as we said, we already did the prior work on vulnerability research, so we had already 256 00:29:18,280 --> 00:29:22,060 some ideas, so mainly to look at the message parsing. 257 00:29:23,080 --> 00:29:28,360 We also looked at the previous implementations where vulnerabilities were found. 258 00:29:28,500 --> 00:29:31,080 So we selected all these implementations. 259 00:29:31,280 --> 00:29:34,960 And alongside, we added the most popular ones. 260 00:29:34,980 --> 00:29:41,980 So this led us to have both open source and closed source targets. 261 00:29:43,200 --> 00:29:50,340 And so we tried to start with static analysis, but of course, for closed source software, 262 00:29:50,500 --> 00:29:52,140 it's a lot more difficult. 263 00:29:52,400 --> 00:30:00,240 So we decided to try to develop a fuzzer that will help us in analyzing these specific 264 00:30:01,360 --> 00:30:02,040 implementations. 265 00:30:02,780 --> 00:30:04,960 And in the end, we also used BGP. 266 00:30:04,980 --> 00:30:07,180 And we used the fuzzer for open source implementations. 267 00:30:09,400 --> 00:30:16,500 So first, the manual analysis we did led us to find multiple interesting things. 268 00:30:16,960 --> 00:30:25,540 First, we found some issues in the design of BGP, because it's a very old protocol. 269 00:30:25,760 --> 00:30:29,560 I think the first RFC about BGP is from 1989. 270 00:30:31,000 --> 00:30:34,880 So for example, there is a lot of type link failure. 271 00:30:34,980 --> 00:30:40,560 There are a few parameters inside BGP messages, which means that when doing parsing of BGP 272 00:30:40,560 --> 00:30:48,960 messages, you first need to extract some fields to get information on the next fields to extract. 273 00:30:49,300 --> 00:30:56,400 And it brings a lot of exception handling and parsing quirks that make everything more 274 00:30:56,400 --> 00:30:56,840 difficult. 275 00:30:57,120 --> 00:31:00,080 Also, optional parameters are RMS. 276 00:31:02,360 --> 00:31:04,960 And another thing is that there are a lot of parameters in BGP. 277 00:31:04,960 --> 00:31:07,600 And sometimes peer responds to any open messages. 278 00:31:07,920 --> 00:31:14,100 So the open messages are the messages used to first establish a BGP connection. 279 00:31:14,860 --> 00:31:17,040 So it's called the BGP peering. 280 00:31:17,600 --> 00:31:29,080 And sometimes we even have update messages that are accepted by peers without prior BGP 281 00:31:29,080 --> 00:31:30,400 connection establishment. 282 00:31:30,900 --> 00:31:34,940 So it's a big attack surface on the BGP. 283 00:31:34,940 --> 00:31:35,440 On the internet. 284 00:31:37,820 --> 00:31:43,060 And this is why we decided to focus mainly on open and update messages. 285 00:31:44,180 --> 00:31:49,360 So first, for open messages, we examined multiple implementations. 286 00:31:49,580 --> 00:31:52,640 We found two things. 287 00:31:53,220 --> 00:31:59,720 So first, most of the implementations, they have the BGP running in the user mode, which 288 00:31:59,720 --> 00:32:04,880 means that we first have the TCP connection established. 289 00:32:04,940 --> 00:32:08,540 Because TCP handshake is handled by the kernel. 290 00:32:08,780 --> 00:32:18,920 So we cannot have filtering on the connections before looking at the BGP messages themselves. 291 00:32:19,380 --> 00:32:24,500 But except for Cisco IOS, where the BGP is running in the kernel. 292 00:32:25,680 --> 00:32:34,380 And so for one implementation in particular, so FL routing, we found that some parameters 293 00:32:34,380 --> 00:32:34,920 are perfect. 294 00:32:34,940 --> 00:32:39,320 We passed before the origin of the messages is validated. 295 00:32:40,000 --> 00:32:45,680 So we only had to spoof the source IP address to trace some attacks. 296 00:32:47,780 --> 00:32:49,380 Now about the phasing. 297 00:32:50,380 --> 00:32:56,660 So first, to explain quickly what is a phaser, it's basically a program that will generate 298 00:32:56,660 --> 00:33:02,720 automatically malformed input to send to a target. 299 00:33:02,980 --> 00:33:04,920 And then we just pass it. 300 00:33:04,940 --> 00:33:06,960 wait for the target to crash at some point. 301 00:33:08,360 --> 00:33:11,340 And so in our case, we used the Bufuzz, 302 00:33:11,540 --> 00:33:16,260 which is an open source framework to make fuzzers. 303 00:33:17,340 --> 00:33:20,040 And so with this fuzzer, we only had 304 00:33:20,040 --> 00:33:23,620 to describe roughly what is BGP. 305 00:33:24,680 --> 00:33:29,140 Like, we did some test cases by explaining to the fuzzer 306 00:33:29,140 --> 00:33:32,140 what the BGP message looks like so that it's 307 00:33:32,140 --> 00:33:36,200 able to generate messages that look like BGP but are, 308 00:33:36,320 --> 00:33:41,240 in fact, malformed and contain possibly dangerous values. 309 00:33:43,040 --> 00:33:49,020 And we also implemented an RPC monitor. 310 00:33:49,460 --> 00:33:51,860 So the goal of the RPC monitor is 311 00:33:51,860 --> 00:33:57,720 to install it alongside of the BGP daemon. 312 00:33:58,000 --> 00:34:01,540 And so the goal is to wait, because as soon 313 00:34:01,540 --> 00:34:02,120 as the BGP daemon is installed, it 314 00:34:02,140 --> 00:34:03,760 will crash. 315 00:34:04,400 --> 00:34:07,960 The RPC monitor will report the crash to the fuzzer. 316 00:34:08,380 --> 00:34:11,200 So the fuzzer will know that a specific payload made 317 00:34:11,200 --> 00:34:14,640 the daemon crash, and will save the payload 318 00:34:14,640 --> 00:34:18,340 and restart automatically the BGP daemon. 319 00:34:18,940 --> 00:34:22,360 And it's open source, so if you want to contribute, 320 00:34:22,560 --> 00:34:23,880 you can look at the code. 321 00:34:25,160 --> 00:34:27,800 And so now for the demo of the fuzzer. 322 00:34:29,280 --> 00:34:31,980 So on the terminal on the right, you will have, 323 00:34:31,980 --> 00:34:33,420 the BGP daemon running. 324 00:34:34,230 --> 00:34:36,600 And on the left, you will have the fuzzer. 325 00:34:37,490 --> 00:34:40,260 So first, we launch the BGP daemon. 326 00:34:42,900 --> 00:34:45,320 It's now waiting for connections. 327 00:34:46,470 --> 00:34:48,300 Next, we launch the fuzzer. 328 00:34:49,170 --> 00:34:53,040 And the fuzzer will just generate many malformed messages 329 00:34:54,380 --> 00:34:56,720 attempting to crash the BGP daemon. 330 00:35:02,540 --> 00:35:04,160 And it will soon crash. 331 00:35:06,120 --> 00:35:07,800 So now the BGP daemon crashed. 332 00:35:08,280 --> 00:35:14,440 And we will see that the fuzzer generated the Python file, which 333 00:35:14,440 --> 00:35:18,460 contains the payload that made the BGP daemon crashed. 334 00:35:19,540 --> 00:35:24,580 And next, we just have to launch the BGP daemon again, 335 00:35:24,720 --> 00:35:26,440 but this time inside the debugger, 336 00:35:26,500 --> 00:35:31,940 so we can look at the specific issues that made the daemon 337 00:35:31,940 --> 00:35:31,960 crash. 338 00:35:35,360 --> 00:35:39,180 So now we launch the BGP daemon inside the debugger. 339 00:35:43,780 --> 00:35:46,320 Again, it's now waiting for connections. 340 00:35:47,300 --> 00:35:50,480 And now we will execute again the same payload that 341 00:35:50,480 --> 00:35:52,560 made it crash the first time. 342 00:35:56,860 --> 00:35:58,080 Now it crashed again. 343 00:35:58,360 --> 00:36:00,740 And we will look at the backtrace 344 00:36:00,740 --> 00:36:01,940 to see what happened. 345 00:36:01,940 --> 00:36:03,840 And we will see in which functions the problem is. 346 00:36:05,480 --> 00:36:08,740 And I don't know if you can see, but basically, 347 00:36:08,800 --> 00:36:12,120 there's a function called the BGP open receive, 348 00:36:12,420 --> 00:36:16,140 which is a function that takes care of the open message 349 00:36:16,420 --> 00:36:16,740 passing. 350 00:36:19,560 --> 00:36:24,000 So with this fuzzer, we found a total of three vulnerabilities, 351 00:36:24,480 --> 00:36:25,960 which are denial of service. 352 00:36:27,460 --> 00:36:30,380 They are all due to a problem. 353 00:36:31,920 --> 00:36:32,600 We were able to find a very good solution, 354 00:36:32,600 --> 00:36:35,300 is an optional parameter in BGP. 355 00:36:36,120 --> 00:36:40,260 There are quite easy to find, and they 356 00:36:40,260 --> 00:36:43,140 are similar to the Cisco iOS vulnerabilities 357 00:36:43,140 --> 00:36:45,120 that Daniel introduced previously. 358 00:36:45,580 --> 00:36:51,300 And also, we wanted to mention that the FRO team were really 359 00:36:51,300 --> 00:36:52,720 quick in fixing the issues. 360 00:36:53,160 --> 00:36:56,660 So it was a really good working with them. 361 00:36:57,540 --> 00:37:01,900 So for the first vulnerability, it's a very quick and very, very, very, very fast. 362 00:37:01,900 --> 00:37:04,880 So we have an if condition that will look 363 00:37:06,900 --> 00:37:11,920 if the optional parameters are activated, basically. 364 00:37:12,340 --> 00:37:14,440 And if they are activated, it will 365 00:37:14,440 --> 00:37:16,560 try to get the next byte in the packet, 366 00:37:17,080 --> 00:37:21,120 but without checking beforehand if this next byte exists. 367 00:37:21,520 --> 00:37:25,240 So we just have to send a packet that ends with the values 368 00:37:25,240 --> 00:37:26,800 that the if is looking for. 369 00:37:27,140 --> 00:37:30,600 And we'll get a readout of bound of one byte. 370 00:37:31,960 --> 00:37:34,960 And just below, in the same function, 371 00:37:35,120 --> 00:37:38,220 we have exactly the same issue two times. 372 00:37:39,500 --> 00:37:41,900 The second vulnerability is, again, very similar. 373 00:37:43,020 --> 00:37:45,280 But this time, we have a check to see 374 00:37:45,280 --> 00:37:47,860 if we can read two bytes more. 375 00:37:48,700 --> 00:37:50,720 But in case of optional parameter, 376 00:37:51,060 --> 00:37:54,240 we actually read three bytes instead of two, 377 00:37:54,280 --> 00:37:56,460 which is, again, a readout of bounds. 378 00:37:57,080 --> 00:38:00,300 And the third one is also the same. 379 00:38:00,600 --> 00:38:03,380 So it's a very similar code from the previous one. 380 00:38:05,940 --> 00:38:08,000 But it's in another function. 381 00:38:12,680 --> 00:38:13,220 Right. 382 00:38:13,340 --> 00:38:13,620 Thanks. 383 00:38:13,740 --> 00:38:17,720 So kind of summarizing the results, or the new results, 384 00:38:17,840 --> 00:38:19,880 besides the things that I mentioned before 385 00:38:21,300 --> 00:38:23,720 with previous vulnerabilities, so we 386 00:38:23,720 --> 00:38:26,700 do see that still there are some popular implementations that 387 00:38:26,700 --> 00:38:28,340 are too permissive, right? 388 00:38:28,420 --> 00:38:29,300 So in some cases. 389 00:38:29,300 --> 00:38:32,320 This is not necessarily filtering out correctly 390 00:38:33,300 --> 00:38:35,240 unwanted open messages. 391 00:38:35,540 --> 00:38:39,060 And in other cases, even parsing these messages 392 00:38:39,060 --> 00:38:43,260 before filtering them, before discarding them, 393 00:38:44,200 --> 00:38:46,440 before they actually realize whether it's 394 00:38:46,440 --> 00:38:49,200 coming from a wanted source or an unwanted source, right? 395 00:38:49,300 --> 00:38:52,200 And on the other hand, some of this parsing 396 00:38:52,200 --> 00:38:54,860 can lead to denial of service vulnerabilities, 397 00:38:55,580 --> 00:38:58,940 and can be abused by attackers to take 398 00:38:58,940 --> 00:39:00,840 down some routers. 399 00:39:01,240 --> 00:39:04,060 Sorry, some BGP implementations on the routers, 400 00:39:04,060 --> 00:39:05,880 and potentially the routing tables, and so on. 401 00:39:05,940 --> 00:39:09,320 So let's talk a little bit about the impact of these issues. 402 00:39:09,520 --> 00:39:12,740 So any of these three new CVs lead to denial of service 403 00:39:12,740 --> 00:39:14,960 on a vulnerable BGP peer, as I mentioned, 404 00:39:15,620 --> 00:39:17,920 dropping the BGP sessions and routing tables, 405 00:39:18,100 --> 00:39:22,160 and rendering the peer unresponsive for some time. 406 00:39:23,060 --> 00:39:25,280 BGP is typically a so it will restart 407 00:39:25,280 --> 00:39:28,380 after a certain timeout, but this denial of service can be 408 00:39:28,380 --> 00:39:30,180 prolonged by just repeatedly sending. 409 00:39:30,340 --> 00:39:34,620 It's one packet, right, that crashes the server. 410 00:39:36,360 --> 00:39:40,300 Two issues out of those three can be triggered before, 411 00:39:40,440 --> 00:39:43,620 as I was mentioning, FR routing validates BGP identifier 412 00:39:44,040 --> 00:39:46,940 and ASN fields, so even before knowing 413 00:39:46,940 --> 00:39:50,200 if it's coming from a trusted peer, in a way. 414 00:39:50,320 --> 00:39:53,420 So in this case, an attacker only needs to spoof a valid IP 415 00:39:53,420 --> 00:39:55,520 address to send this message. 416 00:39:56,140 --> 00:39:57,600 And beyond these vulnerabilities, 417 00:39:57,600 --> 00:40:00,980 if we look at typical IPv4 scans, 418 00:40:01,180 --> 00:40:03,420 like show them the figure that we have there, 419 00:40:03,600 --> 00:40:06,960 there are more than 330,000 hosts with BGP enabled 420 00:40:06,960 --> 00:40:09,900 on the internet, more than 200,000 hosts 421 00:40:09,900 --> 00:40:12,540 that are running Quagga, the predecessor of FR routing. 422 00:40:12,700 --> 00:40:14,560 Not all of those are running BGP, necessarily, 423 00:40:14,660 --> 00:40:19,340 because Quagga is a routing suite that has other protocol 424 00:40:19,340 --> 00:40:23,320 implementations, and there are also more than 1,000 hosts 425 00:40:23,320 --> 00:40:25,800 running FR routing directly, right? 426 00:40:28,020 --> 00:40:31,720 There are also implications of this type of vulnerability 427 00:40:31,720 --> 00:40:34,420 because it deals with an open source project 428 00:40:34,420 --> 00:40:39,940 and because it's a component that will be embedded 429 00:40:39,940 --> 00:40:41,260 in other components and so on. 430 00:40:41,280 --> 00:40:43,460 There are kind of supply chain issues and supply chain 431 00:40:43,460 --> 00:40:44,500 implications here, right? 432 00:40:44,560 --> 00:40:47,080 So if you take FR routing, it's an open source project 433 00:40:47,080 --> 00:40:52,380 that came from a previous project that is even older, 434 00:40:52,860 --> 00:40:56,260 and it currently has more than 1,000 forks on GitHub. 435 00:40:56,260 --> 00:41:03,540 So we work very well with the project developers 436 00:41:03,540 --> 00:41:07,280 to fix it on the main branch of the project, let's say. 437 00:41:07,360 --> 00:41:10,420 But downstream forks, it's difficult to know when, 438 00:41:10,500 --> 00:41:13,960 how they will actually apply those patches. 439 00:41:14,460 --> 00:41:17,180 Also, this type of component ends up 440 00:41:17,180 --> 00:41:18,520 in different network operating systems. 441 00:41:18,760 --> 00:41:21,200 So I have some examples there, Dan, Sonic, Cumulus. 442 00:41:21,340 --> 00:41:22,980 They are popular network operating systems 443 00:41:22,980 --> 00:41:25,980 that are also open source and use FR routing as a specific 444 00:41:25,980 --> 00:41:26,240 component. 445 00:41:26,260 --> 00:41:28,560 So again, it's difficult to know which one of those, 446 00:41:28,720 --> 00:41:31,640 when and which versions will actually apply those patches. 447 00:41:31,960 --> 00:41:34,020 Those operating systems, in turn, 448 00:41:34,160 --> 00:41:36,560 are used by networking vendors, and that 449 00:41:37,000 --> 00:41:39,880 is what ends up in the networks of end users, right? 450 00:41:39,960 --> 00:41:44,720 So between the patches on the original project 451 00:41:44,720 --> 00:41:46,880 and the end users, there's a long way 452 00:41:46,880 --> 00:41:51,480 to go before sometimes these patches are applied, right? 453 00:41:51,520 --> 00:41:56,100 So almost any kind of research in two 454 00:41:56,100 --> 00:41:56,180 or three years, we're still not sure. 455 00:41:56,180 --> 00:41:57,280 But I think the issue of vulnerabilities in open source 456 00:41:57,280 --> 00:41:59,600 these days has this kind of consideration, right? 457 00:41:59,660 --> 00:42:02,100 Supply chain is a big emerging issue, 458 00:42:02,240 --> 00:42:04,320 and we need to be aware of that. 459 00:42:05,380 --> 00:42:08,580 But if we talk about risk mitigation also, 460 00:42:08,700 --> 00:42:11,100 I want to go back to the beginning of the talk 461 00:42:11,100 --> 00:42:14,080 and say that routing security is still very important 462 00:42:14,080 --> 00:42:15,180 and still not solved. 463 00:42:15,360 --> 00:42:20,280 And specifically for internet service providers, or for people 464 00:42:20,280 --> 00:42:24,940 who are dealing with BGP on a day-to-day basis, there are several good guides of, 465 00:42:27,440 --> 00:42:32,360 security and basically good implementations of BGP out there, right? 466 00:42:32,460 --> 00:42:34,060 So Manners is a good project. 467 00:42:34,340 --> 00:42:37,400 There are specific RFCs for BGP operations and security. 468 00:42:37,660 --> 00:42:41,100 There are guidelines from NIST and several other agencies 469 00:42:41,100 --> 00:42:44,840 about implementing the proper routing security mechanisms. 470 00:42:45,340 --> 00:42:48,440 But threat actors, as we mentioned in the beginning, 471 00:42:48,520 --> 00:42:51,140 have been attacking network infrastructure devices directly. 472 00:42:51,360 --> 00:42:53,220 So don't forget software vulnerabilities, right? 473 00:42:53,300 --> 00:42:54,920 That is specifically for BGP. 474 00:42:54,920 --> 00:42:57,840 But also for other protocols, other implementations. 475 00:42:59,840 --> 00:43:02,040 Those devices can be vulnerable. 476 00:43:02,220 --> 00:43:05,980 So you need to identify those devices on your network that may be using BGP 477 00:43:05,980 --> 00:43:08,480 and assess those vulnerabilities and patch when possible, 478 00:43:08,620 --> 00:43:10,860 taking into account all the supply chain issues that we mentioned. 479 00:43:12,100 --> 00:43:15,460 Also, the fuzzer that we released, it's open on GitHub, 480 00:43:15,580 --> 00:43:18,940 and it comes with the prepared test cases for the CVEs that we found. 481 00:43:19,120 --> 00:43:22,380 So if we want to test that against any implementation that you have 482 00:43:22,380 --> 00:43:24,900 that is using FR routing for whatever reason, 483 00:43:24,900 --> 00:43:27,820 you can run those scripts directly. 484 00:43:28,060 --> 00:43:30,540 And if you want to test any new implementation, 485 00:43:30,980 --> 00:43:34,540 you're free and welcome to extend the fuzzer as well 486 00:43:34,540 --> 00:43:38,160 or to use it out of the box on the implementation 487 00:43:38,160 --> 00:43:39,540 that you are interested in. 488 00:43:39,660 --> 00:43:42,420 And we would really be glad to hear about results 489 00:43:42,420 --> 00:43:44,780 or ways to improve the fuzzer and so on. 490 00:43:45,780 --> 00:43:49,300 So going to takeaways and future work, right? 491 00:43:49,380 --> 00:43:51,900 So BGP is still crucial for the internet, 492 00:43:52,040 --> 00:43:54,880 and it's widely used beyond internet service providers. 493 00:43:54,900 --> 00:43:58,820 And internet exchanges, unlike embedded TCP IP stacks, 494 00:43:59,060 --> 00:44:01,800 which we looked at in another project, 495 00:44:02,620 --> 00:44:04,940 BGP implementations have matured very well 496 00:44:04,940 --> 00:44:07,620 and in general do not have obvious mistakes, right? 497 00:44:07,760 --> 00:44:10,600 But some popular BGP implementations still have vulnerabilities 498 00:44:10,600 --> 00:44:11,880 or are too permissive. 499 00:44:11,920 --> 00:44:13,440 That's the main conclusion here. 500 00:44:14,280 --> 00:44:17,980 Network function disaggregation will make some BGP implementations, 501 00:44:18,000 --> 00:44:20,440 some open implementations very popular that's already happening. 502 00:44:20,600 --> 00:44:24,500 So it's very important to keep the security of those projects in check. 503 00:44:24,900 --> 00:44:27,400 And keep doing research on those. 504 00:44:27,700 --> 00:44:30,840 Threat actors are exploiting these kinds of issues, 505 00:44:31,080 --> 00:44:33,820 and the mitigation should not only be about routing security 506 00:44:33,820 --> 00:44:36,860 and should not be only delegated to your ISP, right? 507 00:44:36,940 --> 00:44:40,260 It's everyone's responsibility, let's say, 508 00:44:40,280 --> 00:44:42,600 to make sure that things are running securely. 509 00:44:43,640 --> 00:44:47,180 In terms of future work, I think keep fuzzing new versions 510 00:44:47,180 --> 00:44:49,840 and new implementations, improving the fuzzer with new test cases 511 00:44:49,840 --> 00:44:51,000 and so on is very important. 512 00:44:51,180 --> 00:44:54,880 And exploring other parts of the routing infrastructure and the routing apps, 513 00:44:54,900 --> 00:44:56,700 and attack surface as well, like other routing protocols, 514 00:44:57,100 --> 00:45:00,840 looking glass servers, remote control functions and so on is important. 515 00:45:01,280 --> 00:45:06,980 And it would be very interesting to understand what specific for which campaigns 516 00:45:06,980 --> 00:45:10,220 these threat actors are leveraging these BGP denials of service. 517 00:45:11,180 --> 00:45:12,020 So that's it. 518 00:45:12,220 --> 00:45:15,580 Thank you very much for your time and happy to take some questions down.