WEBVTT 00:01.040 --> 00:02.120 Hey everyone! 00:02.120 --> 00:06.120 Welcome to my talk, Car2Cloud Talk Using MQTT for Car Hacking. 00:06.120 --> 00:07.780 My name is Jamie Lightfoot. 00:07.780 --> 00:12.260 I used to work as an electrical engineer, and now I work at Grimm doing car hacking. 00:13.900 --> 00:14.860 Hey everyone! 00:14.860 --> 00:19.180 Welcome to my talk, Car2Cloud Talk Using MQTT for Car Hacking. 00:19.180 --> 00:20.620 My name is Jamie Lightfoot. 00:20.620 --> 00:24.920 I used to work as an electrical engineer, and now I work at Grimm doing car hacking. 00:25.100 --> 00:29.860 This is a Car Hacking Village 101 talk, which is meant to introduce people to foundational 00:42.800 --> 00:47.860 So, let's talk about how MQTT works and how you can use it. 00:47.860 --> 00:51.180 Let's talk about why we're talking about it in the first place. 00:52.900 --> 00:59.840 Automotive companies won't directly come out and say it, but if you've got a newer car or truck, then they're probably collecting a lot of data. 00:59.840 --> 01:03.740 They have information on you and your driving habits all the time. 01:04.000 --> 01:12.900 Some of this is still the safety features like OnStar or other ways of remote assistance where they need to know the location of your car. 01:13.100 --> 01:15.200 Some of this is still this convenience. 01:15.200 --> 01:22.640 For example, you've got remote unlock or lock functionality, remote start, remote alarm through like a phone app. 01:22.740 --> 01:26.940 There's also over there updates so you don't have to go into a dealership. 01:26.940 --> 01:32.440 Some of this connectivity is much more for the engineering company's benefit than for the consumer. 01:32.500 --> 01:46.120 In a past job, I worked on a project where we aggregated truck engine and transmission data and we would use that to predict future maintenance needs and ship the repair parts to where we knew the trucks were going to be weeks in advance. 01:46.320 --> 01:54.400 We would save the company tons of money on downtime and we'd also get them insight into what kind of warranty claims were going to be coming up. 01:56.800 --> 02:08.540 In all of these cases, the data somehow has to get to or from the car to somewhere else useful like your OEM branded mobile app, some kind of online engineering portal, a dealership tool, or whatever. 02:08.560 --> 02:11.120 And that's where MQTT comes in. 02:11.700 --> 02:27.640 Most of this talk is going to be about the protocol itself, but to give you an idea of how this ties into an actual car, For newer cars and trucks, we have a Telematics Control Unit, or TCU, which is the PCB in this diagram. 02:28.840 --> 02:34.980 The TCU is going to be likely on the CAN bus and accept other inputs from the car. 02:34.980 --> 02:45.300 For example, if there's a GPS antenna, so it has the ability to interface with the car and it also has an understanding of what is currently happening in the car. 02:45.300 --> 02:52.300 It'll be able to use its cellular connection to the cloud to send information in the form of MQTT messages. 02:52.440 --> 03:04.880 It can also do the same thing in reverse, where it is accepting MQTT messages from the cloud and then taking some kind of action within the car, for example, sending information out over the CAN bus. 03:06.700 --> 03:20.940 The TCU device has to have, at a minimum, the ability to connect to a cellular network or more likely networks, plural, as coverage is going to vary throughout a given area and you want to be able to switch between them. 03:20.940 --> 03:28.060 And then CAN transceivers are another way of interfacing with the other parts of what is happening in the car. 03:28.260 --> 03:37.260 But if you have a cellular connection from the car to the cloud, why would you choose MQTT over some other method of communication? 03:37.260 --> 03:45.980 Like maybe you're able to send a text to the TCU device and wake it up and then have it establish an HTTP connection. 03:46.040 --> 03:53.020 The reason is because cars are a bit of a difficult use case from a network and architecture standpoint. 03:53.020 --> 04:01.400 You've got unreliable connectivity or maybe varying connectivity quality because you're driving around and you might go through areas with poor signal. 04:01.420 --> 04:06.080 So you need to have some kind of protocol that has minimal overhead and size. 04:06.080 --> 04:10.860 You might want the ability to buffer messages if you're offline for a minute. 04:11.600 --> 04:17.580 And you also might want some kind of method to know if your message was received or not. 04:18.040 --> 04:24.560 You're probably dealing with high network latency, which means that you want to reduce overhead as much as possible. 04:24.980 --> 04:31.100 MQTT clients will remain connected and they don't need to reinitiate a connection with each message. 04:31.100 --> 04:40.000 Whatever architecture you use also needs to be able to scale up to millions of vehicles and handle millions and millions of messages per day. 04:40.000 --> 04:45.180 Hopefully you're also considering the security of the system, but we'll talk about that more later. 04:46.100 --> 04:52.600 MQTT stands for MQ Telemetry Transport or Message Queuing Telemetry Transport. 04:52.600 --> 05:00.280 It came from Andy Stanford Clark and Arla Nipper who are at IBM and Eurotech respectively. 05:00.280 --> 05:06.000 IBM had a MQ or Message Queuing product at the time. 05:06.000 --> 05:16.260 The OASIS standard for MQTT does not use queues to describe the message communication, but that's where the name came from. 05:16.260 --> 05:22.100 It was originally made to monitor oil pipelines over a satellite link. 05:22.100 --> 05:27.660 So that's where the emphasis on low bandwidth, very lightweight came from. 05:27.660 --> 05:40.940 MQTT.org describes it as a publish, subscribe, extremely simple and lightweight messaging protocol designed for constrained devices and low bandwidth, high latency or unreliable networks. 05:40.960 --> 05:51.720 The design principles are to minimize network bandwidth and device resource requirements while also attempting to ensure reliability and some degree of assurance of delivery. 05:51.940 --> 05:57.040 Given the network challenges that we talked about earlier, it seems like MQTT is a good fit. 05:57.660 --> 06:00.160 So let's talk about how it works. 06:01.020 --> 06:05.180 In MQTT systems, there are two types of network entities. 06:05.180 --> 06:11.220 There's an MQTT broker, now called a server, but I call it a broker out of force of habit. 06:11.220 --> 06:14.600 You also have one or more MQTT clients. 06:15.900 --> 06:25.420 An MQTT broker is a program that receives all the messages from the clients and then routes the messages to the appropriate destination client. 06:25.420 --> 06:28.000 It's pretty much like a post office. 06:28.900 --> 06:33.740 All messages have to travel through the broker in order to get to the other clients. 06:33.740 --> 06:37.880 A client can't send anything directly to another client. 06:38.440 --> 06:52.600 A client then is a device that is either interested in receiving certain information from the broker via other clients or publishing information to the broker, which will then be sent on to the interested clients or both. 06:52.600 --> 06:59.940 In an automotive environment, a client is going to be the car or specifically the TCU unit in the car. 07:00.680 --> 07:05.400 And the broker is going to be some kind of cloud service that the car company has set up. 07:05.400 --> 07:13.080 A mobile app might also be a client, a dashboard might be a client, but there's usually some more architecture going on. 07:13.080 --> 07:17.300 So they aren't all talking unfiltered to the same broker. 07:18.040 --> 07:23.320 Here are a few examples of cloud broker services that I have seen or worked with. 07:23.320 --> 07:24.460 There are others. 07:24.460 --> 07:26.400 These are just a couple options. 07:26.800 --> 07:32.700 To visualize brokers and clients, I made this diagram where we have a broker in the middle and a number of clients. 07:33.020 --> 07:38.480 Each client can either subscribe, publish, or both. 07:38.480 --> 07:43.140 What kind of behavior they do is contingent on how they try and connect to the broker. 07:43.140 --> 07:44.980 We'll see more about that in a minute. 07:44.980 --> 07:51.760 Earlier I said that it is a publish-subscribe method, or PubSub for short. 07:51.760 --> 07:57.300 Each client can designate what information it wants to publish to the broker. 07:57.300 --> 08:02.260 And each client can also specify what information it wants to receive back. 08:02.260 --> 08:06.460 And then the broker just doles out the messages as intended. 08:06.540 --> 08:13.100 Additionally, clients can provide forms of authentication to the broker, but they aren't directly addressable. 08:13.100 --> 08:24.140 So if you have a whole fleet of trucks or cars sending out messages, you probably want to be able to keep the messages separate or organized so you know which messages apply to which vehicle. 08:24.200 --> 08:26.440 And that's where topics come in. 08:26.860 --> 08:29.340 You can designate topics however you like. 08:29.340 --> 08:31.820 However, there are some patterns to follow. 08:31.920 --> 08:51.620 Here I've got some example topic names where maybe we have a DEFCON-wide broker and there's a topic called CarHackingVillage where if you subscribe to that, you get all the information being sent out related to CarHackingVillage. 08:52.320 --> 08:58.520 And then if you publish to it, then everyone who is subscribed will receive that information. 08:59.360 --> 09:21.580 But, because CarHackingVillage has a lot of different things going on, let's break it down into subtopics where you have CarHackingVillage slash talks or CarHackingVillage CTF, where if you're only interested in the talks or the CTF, you can subscribe just to that and narrow down the information that you receive. 09:21.680 --> 09:29.320 Likewise, if you're publishing, you are publishing to a more narrowed down audience. 09:30.460 --> 09:34.240 And then you can just keep nesting as far as you want. 09:34.240 --> 09:44.440 For example, maybe in the CTF we have different team IDs and you can subscribe to your team ID and see what score you have. 09:45.480 --> 10:04.540 So, if you've got people publishing to each of these individualized nested topics, if you still want to receive all of the information about CarHackingVillage, then you will want to subscribe to CarHackingVillage slash either pound sign or hashtag, depending on how old you are, 10:04.540 --> 10:08.200 and you'll receive all of the CarHackingVillage topics. 10:08.880 --> 10:18.180 If you were to subscribe to the pound sign by itself, that would function as a wildcard and give you all topics available on that broker. 10:18.180 --> 10:24.460 So, for our DEF CON example, it would give you information on all the villages, all the CTFs, all the things happening. 10:26.420 --> 10:32.180 But if you are a client, this is probably more information than you want or that you can handle. 10:32.180 --> 10:40.220 If you're a top-level component in the architecture, you're probably interfacing with the broker in a different way to get all the information out. 10:41.020 --> 10:44.180 A client can only publish to one topic at a time. 10:44.180 --> 10:47.640 You can't publish to a group of topics or a wildcard. 10:47.640 --> 10:54.320 For the publishing volume, it's up to the client, but think on the order of maybe once per second. 10:54.320 --> 11:06.760 So, in automotive, the topics might look like car data, and then the VIN number, and lock status or location, latitude, location, longitude, information about the engine, and so on. 11:07.060 --> 11:10.080 Where you would receive back, probably JSON. 11:10.080 --> 11:13.620 All of that is defined by your system. 11:13.620 --> 11:16.680 It's kind of however you want to set that up. 11:16.680 --> 11:22.300 You can also use the pound sign and plus sign to selectively handle levels. 11:22.300 --> 11:36.680 So, you could do car data and then a plus sign, location, latitude, and that would get you all of the latitudes for all vehicles if that level that you're using the plus sign for typically handles VIN data. 11:36.680 --> 11:45.720 You could also do car data, pound sign or hashtag to get all information. 11:45.720 --> 11:53.820 So, the lock information, location, engine, and so on for all vehicles on that broker. 11:54.380 --> 12:02.620 If you are securing a MQTT broker, you want to make sure that your clients don't have wildcard privileges. 12:03.360 --> 12:08.640 There's also a set of topics that all start with dollar sign SYS. 12:08.640 --> 12:16.360 These are all administrative type topics that give information on the clients, messages being sent, and so on. 12:16.360 --> 12:22.860 If you are securing a broker, you want to make sure that these are turned off for all non-admin users as well. 12:22.860 --> 12:31.380 Revisiting this diagram, receiving information isn't like the request response workflow that you're probably used to. 12:31.380 --> 12:36.100 You are not requesting data and then getting a response back containing that data. 12:36.100 --> 12:46.820 Instead, you are subscribing to topics you want data from, and then when data is published to those topics, you receive that information. 12:49.190 --> 13:01.750 After you're subscribed, you'll continue receiving information on those topics from other clients as it gets published until you either disconnect from the broker entirely or you unsubscribe from that topic. 13:01.870 --> 13:06.450 There's also an optional small set of delivery assurance messages. 13:06.450 --> 13:08.530 We'll talk about that a little bit later. 13:08.530 --> 13:23.250 If we revisit our earlier diagram of topics, if the first client publishes something to Topic 1, the broker is going to forward that on to Client B because Client B is subscribed to Topic 1. 13:23.250 --> 13:32.510 It will also send it to Client C because Client C is subscribed to the wildcard and wants information on all topics. 13:33.850 --> 13:50.670 If we talk about the MQTT packet structure briefly, all packets are going to have a fixed header that has information about the type of packet and then some flags relating to the packet type. 13:52.150 --> 13:56.090 There are a number of packet types as listed here. 13:56.530 --> 13:57.490 They come in pairs. 13:57.490 --> 14:11.830 For example, you have Connect, and then Connect Acknowledgement, Publish, and then different types of Publish Acknowledgement, Subscribed, Subac, Unsubscribed, Unsubac, and then you have Ping, Ping Response, and then Disconnect. 14:12.550 --> 14:25.310 The next part of the fixed header is for flags, but that pretty much only applies to the Publish message type because there are Quality of Service and other configurations that need to be set. 14:25.310 --> 14:36.190 Connect, Subscribe, and Publish messages provide more information than other types of messages and need to use a variable header in addition to the fixed header to include that info. 14:36.190 --> 14:43.110 For example, a Connect message is going to provide version information, keep-alive information, and so on. 14:43.110 --> 14:46.910 And then after the headers, you have any kind of payload information. 14:46.930 --> 14:51.310 Typically, you're going to see JSON, but you can do whatever you want, really. 14:52.290 --> 14:59.530 So, here are two examples of Wireshark captures of packets. 14:59.530 --> 15:05.730 The first one is a minimal packet where it's two bytes and it is a Disconnect message. 15:05.730 --> 15:14.810 And then we have a longer packet on the bottom where we are publishing hi to the CarHackingVillage topic. 15:17.860 --> 15:26.400 If we look at a Subscribe message connection in Wireshark, the client is sending a Connect command. 15:26.400 --> 15:29.960 The broker is going to respond with a Connect acknowledgment. 15:29.960 --> 15:39.500 Then the client sends a Subscribe request, and then if it's accepted, the broker will respond with a Subscribe acknowledgment. 15:39.500 --> 15:46.060 If you're doing security testing and you can't get a connection to work, I suggest two different things. 15:46.060 --> 15:59.080 One is to use a dash d in your subscription command, and then the other one is to set up a test server and get an idea of what a known good connection looks like. 15:59.240 --> 16:10.900 If a client has been able to successfully subscribe, after that you'll see a ping and ping response periodically between the client and the server as a keep alive signal. 16:10.900 --> 16:17.040 For a Publish command, we have a Connect, a Connect, a Publish, and then a Disconnect message. 16:17.200 --> 16:22.880 If we had a higher quality of service setting, then you might get an ACK or other message back. 16:23.120 --> 16:28.660 And then the final publish line is from the broker to the other connected client. 16:29.620 --> 16:34.680 So once again, you can use the dash d to get some more debug information. 16:34.940 --> 16:38.440 There are three quality of service settings that you can choose. 16:38.440 --> 16:48.380 0 is the default, 0 is at least once, it's going to be fire and forget, there's no kind of checking or acknowledgement afterwards. 16:48.380 --> 16:56.460 Level 1 is at least once, it's going to keep sending that message until it gets acknowledgement back. 16:56.620 --> 17:06.320 Level 2, there's a little bit more going on, and as a result, you can ensure that only one copy is received. 17:07.200 --> 17:17.920 At this point, I think the best thing to do is to try out a MQTT broker on your own computer to see how it works. 17:17.920 --> 17:24.620 And to do that, I recommend that you download Mosquito, because you can do all of this on the command line. 17:24.620 --> 17:29.540 There's very minimal setup, and I think it helps cement the ideas. 17:30.680 --> 17:36.160 First of all, you need to go to their download page and get it set up on your computer. 17:36.160 --> 17:38.920 If you're on Mac, you can do brew install mosquito. 17:39.460 --> 17:41.820 Then you will need to start the service. 17:41.820 --> 17:45.800 I'm on a Mac, so I did the line shown here. 17:46.680 --> 17:49.580 And then you want to open up two more terminals. 17:49.720 --> 17:52.660 In the first one, you want to subscribe to a topic. 17:53.520 --> 17:56.400 For example, I had CarHackingVillage. 17:56.600 --> 18:01.100 And then the "-i client1 is my client ID". 18:01.100 --> 18:03.040 You don't have to provide this. 18:03.040 --> 18:07.660 It will make one for you if you don't, but just for completeness. 18:08.240 --> 18:17.220 And then in the other terminal window, you do a publish message to CarHackingVillage topic with whatever you want your message to be. 18:17.220 --> 18:24.060 And then in the first terminal window where you subscribe, you should see that data come through. 18:26.620 --> 18:30.000 Visually, that looks like starting the service. 18:30.000 --> 18:33.560 It will listen on port 1883 by default. 18:33.560 --> 18:40.520 You subscribe, you publish, and then back in the subscribe window, you see that you got Hello World. 18:41.200 --> 18:44.740 If localhost is too boring for you, then you're in luck. 18:45.380 --> 18:52.440 Mosquito.org has set up a test broker where you have ports for each type of broker service. 18:52.540 --> 18:57.960 You can subscribe to all topics using the hashtag or pound sign. 18:57.960 --> 19:07.240 And then use "-v to show topic names along with the data so you don't just get Hello World, you get CarHackingVillage topic Hello World. 19:08.040 --> 19:15.540 You can see this note on their website that says don't publish anything sensitive because anyone can be listening. 19:15.860 --> 19:17.780 You probably know where this is going. 19:17.780 --> 19:28.260 Here are some screenshots from the other day where I have subscribed to all topics on the unencrypted port 1883 test mosquito.org server. 19:28.260 --> 19:31.320 We have what seem to be plain text passwords. 19:31.320 --> 19:36.080 We've got the lighting and temperature controls for some office. 19:36.080 --> 19:40.260 Probably most concerningly an over-the-air update. 19:40.480 --> 19:45.980 And then this last person was just publishing basic C4 encoded images. 19:46.600 --> 19:50.940 A lot of the data being published here is probably junk. 19:50.940 --> 19:53.540 However, some of it does look important. 19:53.540 --> 20:07.980 A lot of times, IoT projects or other projects that use MQTT will use a default value of test.mosquito.org as their broker so that the whole project will just work right out of the box. 20:08.060 --> 20:12.180 There's usually a note to change it, but of course not everyone does that. 20:12.180 --> 20:21.980 I have seen a production TCU unit that had test.mosquito.org commented out in the configuration file, so it can happen. 20:22.440 --> 20:25.740 Since this is DEF CON, I should probably talk about security. 20:25.740 --> 20:38.640 You likely noticed that in the earlier examples, including test.mosquito.org, there is a pretty minimal set of information that we needed in order to subscribe to a topic or publish information to that topic. 20:39.120 --> 20:52.760 We would hope that MQTT offered some kind of security features so we aren't completely wide open to anyone who can guess our IP address of the broker and then sees port 1883 open on their nmap scan. 20:53.360 --> 21:00.220 As with the Mosquito test server listings, there are different levels of security that you can set on your broker. 21:00.300 --> 21:12.780 For the lowest level, which is the default, you only need to know the host name, port, which default is 1883, a topic, including wildcards, in order to subscribe. 21:12.860 --> 21:19.860 Technically, you also need a client ID, but the Mosquito command line tools will make one for you if you don't have one. 21:20.640 --> 21:25.440 By default, MQTT does not require authentication or encryption. 21:25.440 --> 21:27.600 You can set that up on your own. 21:27.600 --> 21:38.720 You can also set up authentication without encryption, but as shown in this screenshot, that means that plain text credentials are visible if you can sniff traffic. 21:44.360 --> 21:51.400 Hopefully, that isn't enough security for your connected car architecture and you want to do a little bit more. 21:51.460 --> 21:55.240 The next thing to do is to add encryption. 21:55.480 --> 21:58.840 We can do MQTT over TLS. 21:58.840 --> 22:07.700 We use a certificate to encrypt traffic between the client and the server, which means no more plain text credentials. 22:08.220 --> 22:10.960 Random people can't connect to your server. 22:10.960 --> 22:16.680 If you try and connect without a certificate, the server won't even respond with an acknowledgement. 22:17.680 --> 22:24.100 Your data is going to be encrypted in transit, which is a significant step up in security. 22:24.100 --> 22:27.360 I don't think you'll see many car networks with unencrypted traffic. 22:27.360 --> 22:30.000 I don't know that you can say the same for IoT. 22:31.120 --> 22:35.860 Let's say you have a car network set up with MQTT over TLS. 22:35.860 --> 22:39.040 You still need to use defense in depth. 22:39.400 --> 22:53.280 If you were to buy a TCU off of eBay, you get console access, you dump the firmware, and now you have the host name, the port number, what a valid client ID might look like, and then the certificate. 22:53.280 --> 22:57.940 You could connect to the broker or server using that information. 22:58.240 --> 23:00.160 You might think that's not a big deal. 23:00.160 --> 23:03.080 You're just going to get information about that TCU. 23:03.080 --> 23:15.240 Depending on how you have set up authentication and access control, you might be able to get information about other cars, which is obviously not good. 23:15.600 --> 23:19.640 That means we need to employ some level of authentication. 23:21.140 --> 23:25.380 We already said that authentication is not required by default. 23:25.380 --> 23:28.840 You can configure your broker to authenticate clients. 23:28.840 --> 23:36.820 If you are using some kind of paid-for service like AWS IoT, they probably make this even easier for you. 23:37.280 --> 23:44.040 You can pass in a username and password to authenticate devices against a device list. 23:44.040 --> 23:49.120 But what would be even better than that is to have individual client certificates. 23:49.900 --> 23:56.160 Of course, this makes the manufacturing and provisioning process more difficult and more expensive. 23:56.280 --> 24:06.020 But in this scenario, if you were to buy a TCU off of eBay and hack it, and you have set up access control correctly, you can only connect as that device. 24:06.020 --> 24:19.080 You can't guess other usernames or passwords, especially if you're doing something that is guessable, like the username is the VIN or the IMEI or something like that. 24:20.040 --> 24:25.060 If you have authentication set up, you still need to think about authorization. 24:25.380 --> 24:30.300 What kind of data or functionality should a single device have access to? 24:30.300 --> 24:39.040 Ideally, cars should only be able to see information about that car, not other cars in the fleet, and not system-wide information. 24:39.740 --> 24:49.320 If they aren't using individual client certificates, then the authorization might be based off of either the username or the client ID that you have to provide. 24:49.320 --> 24:50.960 You should try both. 24:52.720 --> 24:58.340 Brokers can be configured to disconnect clients that are asking for unauthorized topics. 24:58.340 --> 25:01.180 I don't know how common this is in the wild. 25:01.180 --> 25:14.180 For example, I know that AWS IoT lets you configure all kinds of security access violation rules, but I haven't actually seen anyone use it for production. 25:15.260 --> 25:23.980 If you manage to get connected in whatever way, what you should try then is to see if the broker allows wildcards. 25:23.980 --> 25:28.160 Can you use hashtag or pound sign to connect to all topics? 25:28.160 --> 25:32.120 If not, then you need to have a little bit more nuance. 25:32.120 --> 25:48.660 Try connecting to, for example, from earlier, car data, and then either a pound sign after that for everything under car data, or car data, and then a plus sign, and then topic names that you already know about from your car. 25:49.180 --> 25:55.880 For example, location, latitude, and see if you can get information that way. 25:55.880 --> 26:05.040 Just because they have restricted wildcards at one level doesn't necessarily mean that they have filtered them out correctly at all levels, so try a couple different permutations. 26:05.640 --> 26:13.100 You should also try the system level topics to see if you can find information about the connected clients. 26:13.100 --> 26:33.000 And then if they have locked down all of the wildcards, which hopefully they're doing, you might be able to guess what the other IDs are and essentially go through the same process, but manually trying out different VINs or IMEIs instead of making use of the wildcard. 26:33.000 --> 26:40.700 For example, if the ID is a VIN, you can probably guess other valid VINs or look them up somehow. 26:40.700 --> 26:47.480 They might also be using the IMEI or the ICC ID of the telematics control unit. 26:47.740 --> 27:01.230 Ideally, they're checking your client name or username or certificate to determine whether you're authorized to view this, but if they had to roll their own access control setup, maybe they've made mistakes somewhere. 27:02.230 --> 27:05.590 There are other security features that you could use. 27:05.590 --> 27:13.910 For example, the access control violation rules mentioned earlier or a VPN to close the attack surface up even more. 27:14.150 --> 27:19.270 I haven't used these tools a whole lot, but I found them while making this talk and I thought I'd include them. 27:19.270 --> 27:24.850 MQTT Pwn is a whole framework around MQTT testing. 27:24.850 --> 27:31.790 The second one is a fuzzer and then the last one is less for security testing and more on the development side. 27:31.790 --> 27:38.710 It has a ton of great links for frameworks and client code and things like that in a bunch of different languages. 27:39.150 --> 27:40.990 It's a great resource. 27:43.070 --> 27:54.990 So, in summary, MQTT is a PubSub protocol that runs on ports 1883 or 8883, depending on whether you're using TLS or not. 27:54.990 --> 27:58.130 You have one broker and multiple clients. 27:58.130 --> 28:05.390 In the automotive world, the clients are likely TCUs, but might be other things as well, like mobile apps. 28:05.410 --> 28:10.850 Information is separated out by topic hierarchies as defined by each system. 28:12.290 --> 28:15.970 MQTT security is important because of privacy concerns. 28:15.970 --> 28:19.610 You have car location that could be shared over MQTT. 28:19.810 --> 28:33.590 You have car safety, if you can do remote lock or unlock, and then over there, updates, where if you're somehow able to get in the middle of that, you could download malicious firmware onto the device. 28:33.670 --> 28:38.230 Hopefully, again, you have defense in depth and you have other checks for that. 28:39.130 --> 28:51.130 But MQTT is insecure by default, and it is up to the developers to implement authentication, authorization, encryption, and access control correctly. 28:51.490 --> 28:57.750 And lastly, MQTT is something that you can use in car hacking, if you have a car with a telematics component. 28:57.750 --> 29:06.390 If you don't have that, MQTT is also very common in IoT, so you might be able to practice some of these things with IoT devices you have around your house. 29:10.090 --> 29:12.150 I hope this has been useful. 29:12.150 --> 29:16.050 I'll be around in Discord for a little bit afterwards. 29:16.050 --> 29:24.410 Feel free to hit me up on Discord, CarHackingVillageJamie, or message me on Twitter if you have any questions or anything that I can help with. 29:28.780 --> 29:30.040 All right. 29:30.040 --> 29:31.580 Jamie Lightfoot, everyone. 29:31.580 --> 29:33.820 Thank you very much for your talk. 29:34.580 --> 29:38.680 Jamie, I believe you're also in the channel currently. 29:42.520 --> 29:44.520 Good evening. 29:45.220 --> 29:49.280 Actually, we don't have any questions coming from the audience. 29:49.280 --> 30:06.140 If you do have questions and you want to ask Jamie right now, please go ahead and type them into the CHP 101 support text channel, and Jamie would be happy to answer them now. 30:06.140 --> 30:18.540 Or I'm sure Jamie's going to be around for some time, and maybe you can catch her direct chat with her or in one of the channels as well. 30:20.020 --> 30:24.120 So, Jamie, thank you very much for the talk today. 30:24.120 --> 30:25.520 It was really nice. 30:26.480 --> 30:29.280 Thank you, and thank you, everyone, for listening. 30:30.640 --> 30:31.740 Great. 30:31.740 --> 30:36.600 And once again, contact Jamie if you have any questions. 30:36.600 --> 30:47.470 If you want to make any comments or just talk about MQTT, excuse me, then talk with her directly. 30:48.290 --> 30:52.250 Jamie, thank you for the presentation again. 30:52.450 --> 30:58.890 And actually, this was our last presentation, our last talk of the day.