[00:00.000 --> 00:05.980] Hi, welcome everybody. We would like to talk today about a research project we did, [00:05.980 --> 00:10.400] Hacking Traffic Lights, and we would like to share our findings and our... [00:11.200 --> 00:13.800] well, the things we found in our research. [00:14.760 --> 00:20.000] Well, first of all, who are we? My name is Wesley Nele and my colleague's name is Rick van Duin. [00:20.260 --> 00:25.680] And we both have been mainly pen testing in the past years for about seven, eight years. [00:25.680 --> 00:31.320] And of course, we also have our own interests. For example, I like to play around with Internet [00:31.320 --> 00:36.200] of Things and the security of it and innovations like that. And Rick likes to play with malware [00:36.720 --> 00:43.940] and investigate that. I would like to... at least one disclaimer, we are no smart traffic experts. [00:43.940 --> 00:49.760] We're just, well, two guys that are interested in this kind of innovations. So we decided to use... [00:49.760 --> 00:54.800] to do research on it. We do use bicycles because we're Dutch, [00:54.800 --> 00:59.380] but that doesn't really help us in our investigation, in our research. [01:01.320 --> 01:07.920] Well, a small introduction. Well, what we've seen that there is... they are creating a platform, [01:07.920 --> 01:12.700] multiple vendors are creating a platform to exchange information between traffic information. [01:12.700 --> 01:19.000] For example, road signs can report die states on a network, the parking spots, [01:19.000 --> 01:25.680] how many are still available and how many are occupied. Other traffic status, for example, [01:25.680 --> 01:31.120] is there a traffic jam and stuff like that. But they are even trying to connect the traffic lights, [01:31.120 --> 01:38.560] the actual traffic light systems to the same network so it can act, well, on the messages [01:38.560 --> 01:43.820] that are sent on the network. And one of the examples is that they actually want to connect [01:43.820 --> 01:50.400] the road users to the network as well. For example, cyclists, cars, trucks, and even the [01:50.400 --> 01:56.300] rescue vehicles, the emergency vehicles. Well, I have to mention that in this research, we mainly [01:56.300 --> 02:01.740] have been focusing on the cyclist. And the reason for this is that, well, there was an app available [02:02.440 --> 02:09.100] that allows you as a cyclist to install it. And if you're cycling on a road, you will get, [02:09.100 --> 02:15.620] well, the time to green will be decreased or maybe even instant green. So, because it was [02:15.620 --> 02:21.200] available, we focused on that. Well, important fact is that in the Netherlands, there are a lot [02:21.200 --> 02:26.980] of bicycles, 23 million, and we have a lot of cycling infrastructure. So, well, imagine that [02:26.980 --> 02:33.880] on every intersection, there's almost a cycling traffic light. So, it's quite important in our [02:33.880 --> 02:43.780] country. Well, like said, we've seen multiple apps being released. So, we are mainly interested [02:44.260 --> 02:49.620] in the fact that we are able to talk to traffic lights somehow. And for example, how are we able [02:49.620 --> 02:54.580] to talk to them? And what if we are able to manipulate it? What is possible? And what can [02:54.580 --> 03:01.320] we manipulate? So, that was pretty interesting and the reason why we started the research. [03:02.280 --> 03:06.860] Well, one of the things we see in the Netherlands, there's an ongoing partnership. [03:07.700 --> 03:13.120] And the goal of that partnership is to realize smart traffic. And the goal is to improve the [03:13.120 --> 03:19.440] safety, comfort, and traffic flow. Well, a lot of things are happening in that partnership, [03:19.440 --> 03:24.440] but some of the things are, for example, the cyclist app that I was talking about. [03:24.840 --> 03:30.240] They are trying to give the user the ability to install an application on its phone. [03:30.240 --> 03:36.720] And when he's cycling on an intersection, the cyclist's time will be decreased to go to green, [03:36.720 --> 03:41.120] or maybe even instantly go to green if there's no other traffic at the intersection. [03:41.900 --> 03:49.660] But another thing is, for example, for trucks. They are trying to realize a green flow on multiple [03:49.660 --> 03:55.040] traffic lights. So, the trucks have to stop less, which is, of course, a great idea. [03:55.600 --> 04:01.940] And the emergency vehicles, well, that's maybe even the most interesting one, [04:01.940 --> 04:07.780] because those will get instantly green if they will be passing a connected traffic light. [04:07.780 --> 04:15.460] But also, other users, the road users, will be notified so that there is a vehicle coming, [04:15.460 --> 04:24.480] coming up, emergency vehicle. An important thing within the partnership is VRIs. VRIs [04:24.480 --> 04:30.180] are the systems that are actually at an intersection that are actually, well, [04:31.180 --> 04:37.360] controlling the actual traffic lights. And they are replacing the old systems for intelligent [04:37.360 --> 04:42.380] ones, so that it is compatible with the network and that it is possible to communicate to it, [04:42.380 --> 04:45.840] but also that it is able to send its own information to the network. [04:46.060 --> 04:53.480] And what we've seen that currently about 500 IVRIs or VRIs have been replaced for IVRIs, [04:53.480 --> 04:58.600] which is about 10% of the total amount of VRIs. [05:00.060 --> 05:03.680] And to give you an idea how the things are connected to each other, [05:03.680 --> 05:09.680] on the right, you will see the road users, for example, cars, cyclists, or trucks. [05:10.300 --> 05:15.760] And they are, well, connected to the network, for example, by using an app, like I said earlier, [05:15.760 --> 05:20.260] but it's also possible that it might be an onboard computer within the truck, for example. [05:20.260 --> 05:26.740] And those systems are talking to the, well, to cloud services, which are also like the apps [05:26.740 --> 05:33.920] created by multiple vendors. And in the cloud, the information that is sent to the cloud can be sent [05:33.920 --> 05:39.760] onto the network. And, for example, to traffic lights. And one of the important things in there [05:39.760 --> 05:48.940] is that mostly this is done by using come objects, which is a standard that allows you to, [05:49.620 --> 05:54.320] a traffic light network or traffic network. And Rick will be explaining more on that. [05:54.540 --> 06:00.720] Cool. So when we initially looked at the first app that allowed users to get a green light, [06:00.720 --> 06:06.940] we saw lots of references to come objects. And we saw that the app was building come objects [06:06.940 --> 06:11.500] with the position, stuff like that in it. And for us, it was unclear what those were. [06:11.500 --> 06:17.180] So we started Googling and we figured out that it's actually a part of the intelligent transport [06:17.180 --> 06:22.000] system standard, which is a European standard. There's a different one. As far as we know, [06:22.000 --> 06:26.180] there's a different one in the US and it might even be a different one in your country. [06:27.900 --> 06:34.380] So important part of this standard are the cooperative awareness messages. So come messages. [06:35.040 --> 06:41.940] In the US, they're called basic safety messages. These contain all kinds of information about the [06:41.940 --> 06:49.220] intelligent transport system. So it could be a car telling you its speed, stuff like that. [06:49.760 --> 06:57.520] So when we looked into the objects itself, we noticed that they contain lots of different [06:57.520 --> 07:05.160] information. So we can see the position, what type of vehicle you are. Important to note, [07:05.160 --> 07:12.320] later we can see why you shouldn't use the station type to determine what a user is and [07:12.320 --> 07:18.080] what they can do. But there's also a different container. So there's a high frequency container, [07:18.080 --> 07:24.580] which contains data that changes often. So stuff like data, the direction, [07:24.580 --> 07:33.660] information like that. And there's a low frequency container, having data that's more static, [07:33.660 --> 07:39.020] such as my lights are on or off, or this was my history, my path history. [07:40.220 --> 07:49.120] But more importantly, we came across a special vehicle container. And this container contains [07:49.120 --> 07:56.500] information such as I'm transporting dangerous goods, or I'm in emergency vehicle, and I [07:57.380 --> 08:03.580] need to have a green light right now, stuff like that. So this for us was the point where we were [08:03.580 --> 08:08.460] like, okay, can we manipulate this? And can we send this to the traffic lights that are connected [08:08.460 --> 08:15.540] to our apps? Well, when we started looking into this, we actually figured out that the [08:15.540 --> 08:21.580] intelligent transport system standard already has a security standard in it. It's based on [08:21.580 --> 08:29.920] public key infrastructure, where, very simplified, your vehicle receives a certificate. [08:29.920 --> 08:35.860] The certificate contains information about your vehicle and, well, not necessarily your identity, [08:35.860 --> 08:41.780] but that you are a vehicle and what you are allowed to do, which allows other systems on [08:41.780 --> 08:51.200] the road to actually validate what you are sending to them. So part of the comm messages [08:51.850 --> 08:59.820] and the certificate are the SSP and the ITS-AID. So the ITS-AID is the intelligent transport system [08:59.820 --> 09:05.400] application ID, and it describes some basic permissions, such as you are allowed to send comm [09:05.400 --> 09:13.100] messages. And there's a server-specific permission that's also in there that allows you to [09:13.100 --> 09:17.940] actually say, I'm allowed to do this. So for example, I am an emergency vehicle and I'm allowed [09:17.940 --> 09:26.060] to tell the world that I need green lights right now. So every message you send out, you sign [09:26.860 --> 09:33.400] and it's combined with the certificate in order to let other systems on the road identify that [09:33.400 --> 09:40.260] the message you are sending them is actually valid, you are allowed to send it, and that you [09:40.260 --> 09:47.640] actually have the correct permissions to request this. So when we were preparing this presentation, [09:47.640 --> 09:51.420] we actually came across some interesting work already that's being done on this. [09:51.420 --> 09:59.740] So there's a cool paper by Yosef Kamel, which goes on to assume, let's say our authentication [09:59.740 --> 10:08.240] authorization is already correct. What can we do with a valid car? So can I say to others, [10:08.940 --> 10:14.220] I'm putting on the emergency brakes right now, will other cars immediately start braking? [10:14.220 --> 10:18.940] So there's really interesting research being done. There's also some cool software being released [10:18.940 --> 10:29.280] in order to look for abuse on the network already. So the security for this exists. However, [10:29.280 --> 10:35.440] when we started looking into the apps that Wesley will talk about soon, we noticed that there's [10:35.440 --> 10:42.500] still some work to be done. Yeah, like earlier mentioned, we saw multiple [10:43.120 --> 10:49.800] well, Android applications that a cyclist could install on his phone. And if he installs it, [10:49.800 --> 10:56.280] and he's approaching an intersection, he will get green, the time will be decreased to green, [10:56.280 --> 11:02.500] or he will instantly get green. So when we saw that, we were like, okay, what's going on? How [11:02.500 --> 11:08.900] does this app work? And what is it exactly doing? And what we did, we did decompile the applications, [11:08.900 --> 11:15.540] and we saw that CommonPX were being sent over MQTT. And that was pretty interesting, because [11:15.540 --> 11:20.260] if we are able to create those CommonPX ourselves and send it over MQTT, for example, [11:20.260 --> 11:26.220] using Python, well, we might be able to trick the system. The thing was, at that time, [11:26.220 --> 11:32.700] we didn't know what CommonPX exactly were at that time. So we had quite a hard time imitating the [11:32.700 --> 11:39.040] behavior and, well, doing it in Python the same. And also because the ASN and the protobuf encoding [11:39.040 --> 11:45.760] that was done by the application. So, well, during that time, we decided to take another approach, [11:45.760 --> 11:50.920] and let's use another tool, which was called Frida. And at that time, it was the first time [11:50.920 --> 11:56.640] we used it. Well, and it's really an amazing tool. It allows you to, well, hook into an application, [11:56.640 --> 12:00.940] for example, an existing Android application that's running on an Android device. [12:00.940 --> 12:06.120] And, for example, print the information that's in the function or call other functions and do [12:06.120 --> 12:13.660] modifications, for example. So, well, after trying, we were able to print out the CommonPX. [12:13.820 --> 12:19.700] And on the right, you can see a snippet of that information. And like Rick was talking about, [12:19.700 --> 12:24.460] you see the basic container, the station type, and GPS coordinates. So we were like, [12:24.460 --> 12:29.420] this is pretty interesting. What and how the system will react if we are going to manipulate [12:29.420 --> 12:37.540] this information? So in order to do so, we also used Frida. And we were able to write a script [12:37.540 --> 12:43.120] that's on the left. And what it is doing, it's, again, just hooking before the published com [12:43.120 --> 12:48.420] function is being called. So the CommonPX is published on MQTT. But just before that, [12:48.420 --> 12:54.440] we modify the information, for example, the speed, the GPS coordinates, and information like that. [12:54.440 --> 12:59.800] And our goal was to imitate the behavior that you see in the right, in the image, [13:00.360 --> 13:05.140] to let the system believe that there is a cyclist cycling on the intersection all the time, [13:05.140 --> 13:12.280] and that in a loop. The thing was, at that time, we were just recognized as one cyclist. And that [13:12.280 --> 13:18.920] was, well, we wanted to bypass it. We wanted to be continuously, well, a loop of cyclists that are [13:18.920 --> 13:26.980] passing the intersection. So we are trying to bypass that. And well, the way to bypass it was [13:26.980 --> 13:33.820] quite simple, because we found out that just before the com is being published, disconnect [13:33.820 --> 13:39.740] and connect on the MQTT channel, we are recognized as a different and a new cyclist. So by just [13:39.740 --> 13:44.560] disconnecting and connecting, we are able to, just before every CommonPX was being sent, [13:44.560 --> 13:50.560] we are able to, well, act like we are a different cyclist instead of one. So that was cool. We [13:50.560 --> 13:57.960] were able to, well, get that flow continuously. Later on, we found another, a similar application, [13:57.960 --> 14:02.880] which is also an application. And if you install it as a cyclist, you will get, well, the time [14:02.880 --> 14:08.500] will be decreased, or you will instantly get green, depending on the situation at the intersection. [14:08.940 --> 14:13.620] But this application was even easier, because it was just sending one post request. [14:13.620 --> 14:19.800] As you can see in the slide, with similar information that we saw in the previous app, [14:19.800 --> 14:25.540] like speed, GPS coordinates, and information like that, also the station type. [14:26.300 --> 14:32.680] And that was being sent to the server. So somehow, this is probably converted, for example, [14:32.680 --> 14:38.600] to come by the backend. So we didn't have to take care of that at all. We just have to send one post [14:38.600 --> 14:43.500] and the system will react on it. And the interesting thing, there was no authentication. [14:43.500 --> 14:48.680] So there's no way to distinguish a cyclist from each other within the system. And that was quite [14:48.680 --> 14:56.660] an interesting part, because maybe we can, well, fake a lot of cyclists in the city, for example. [14:57.120 --> 15:01.600] Well, we wrote a Python script to just send this post with the correct information. [15:02.200 --> 15:06.840] And, well, we recorded the demo on it, and I would like to show the demo. [15:07.340 --> 15:13.020] Here you will see a video where we are at a traffic light, a connected traffic light on [15:13.020 --> 15:18.420] an intersection. And in this video, there is other traffic at the intersection. And you will see that [15:18.420 --> 15:24.940] the system reacts and the waiting sign turns on. But, well, it will wait until it goes to green, [15:24.940 --> 15:30.920] well, when it's safe. So that's quite important to note. The safety system stays intact. So it [15:30.920 --> 15:37.740] will never turn two lights at green at the same time. So that's lucky and good that that's still [15:38.240 --> 15:45.180] in place. Also, we recorded a second video, also at a traffic light, but in this case, [15:45.180 --> 15:50.280] without any other traffic. And as you can see, well, it reacts quite quickly and instantly. [15:50.280 --> 15:58.800] If we send one post request, the system instantly turns to green. So it just goes quite quickly. [15:58.800 --> 16:04.960] So what could we do with this vulnerability? Well, it's abusive functionality, but, [16:04.960 --> 16:10.260] well, like we mentioned, it is not able to see multiple cyclists. It's just, [16:10.260 --> 16:16.200] well, using every request and doing an action on that. So what we could do is use the previous [16:16.200 --> 16:23.100] script and do it on a lot of traffic lights at the same time, because that system was running [16:23.100 --> 16:31.500] in 10 cities currently. So you could just interrupt the traffic in a complete city at the [16:31.500 --> 16:44.260] time. So in conclusion, I think the place we are now is that there's no real use of the security [16:44.260 --> 16:50.340] part of the standard. They are using cooperative awareness messages to determine where vehicles [16:50.340 --> 16:56.060] are, but there's no clear distinction on what they are, who you are, or if you're even authorized [16:56.060 --> 17:05.160] to do so. Luckily now we're working with the public betas where cyclists are being used, [17:05.160 --> 17:12.420] but there are some closed betas going on for trucks, for emergency vehicles, and especially [17:12.420 --> 17:22.900] those could pose a real threat for traffic. Luckily security systems will stay intact, [17:22.900 --> 17:27.820] so there's no hacker style, all the lights green at the same time, cars hitting each other, [17:27.820 --> 17:35.680] stuff like that. So just currently we're able to annoy you, which is already fun. [17:37.740 --> 17:42.260] So the reason we're giving this presentation is we really believe that [17:43.460 --> 17:48.300] this is something that's coming and we need to be sure that this is actually working properly, [17:48.300 --> 17:54.580] meaning that authentication and authorization are correctly implemented. We've seen it with email, [17:54.580 --> 18:00.100] we're still having issues determining if a mail you've received is actually from the person you [18:00.100 --> 18:05.800] received it from. And so it's really important that the moment our physical lives, the traffic [18:05.800 --> 18:11.820] is being controlled by these systems, that this is something that's actually properly working. [18:13.680 --> 18:20.980] So we would recommend that these apps will start to use some form of authentication, [18:20.980 --> 18:26.660] at least knowing that there's one person operating one app. If they choose to spoof [18:26.660 --> 18:32.860] whatever it is they do, at least we would know they would only be able to control one [18:33.620 --> 18:40.420] digital cyclist. And it's becoming more and more important to detect and monitor abuse on [18:40.420 --> 18:45.980] the back end of things, meaning that the central system receiving all these messages and distributing [18:45.980 --> 18:52.960] them to the different traffic lights would need to look for unexpected or implausible behavior [18:53.760 --> 19:01.360] and block users accordingly, which would reduce the impact of somebody trying to manipulate this. [19:01.360 --> 19:07.620] And I mean after that, if the moment we have the authentication and authorization under control, [19:07.620 --> 19:14.960] we will have to see and look into abuse from a allowed user. But that's the next step. [19:15.080 --> 19:22.940] So this is as much as our presentation encompasses. If you have any questions and you want to join in [19:22.940 --> 19:30.520] Q&A, it will be on the 6th of August between 1.30 and 2 o'clock. Or if you need to contact us [19:30.520 --> 19:34.840] directly, check it out on Twitter. Thank you. Thank you.