1 00:00:01,040 --> 00:00:02,120 Hey everyone! 2 00:00:02,120 --> 00:00:06,120 Welcome to my talk, Car2Cloud Talk Using MQTT for Car Hacking. 3 00:00:06,120 --> 00:00:07,780 My name is Jamie Lightfoot. 4 00:00:07,780 --> 00:00:12,260 I used to work as an electrical engineer, and now I work at Grimm doing car hacking. 5 00:00:13,900 --> 00:00:14,860 Hey everyone! 6 00:00:14,860 --> 00:00:19,180 Welcome to my talk, Car2Cloud Talk Using MQTT for Car Hacking. 7 00:00:19,180 --> 00:00:20,620 My name is Jamie Lightfoot. 8 00:00:20,620 --> 00:00:24,920 I used to work as an electrical engineer, and now I work at Grimm doing car hacking. 9 00:00:25,100 --> 00:00:29,860 This is a Car Hacking Village 101 talk, which is meant to introduce people to foundational 10 00:00:42,800 --> 00:00:47,860 So, let's talk about how MQTT works and how you can use it. 11 00:00:47,860 --> 00:00:51,180 Let's talk about why we're talking about it in the first place. 12 00:00:52,900 --> 00: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. 13 00:00:59,840 --> 00:01:03,740 They have information on you and your driving habits all the time. 14 00:01:04,000 --> 00: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. 15 00:01:13,100 --> 00:01:15,200 Some of this is still this convenience. 16 00:01:15,200 --> 00:01:22,640 For example, you've got remote unlock or lock functionality, remote start, remote alarm through like a phone app. 17 00:01:22,740 --> 00:01:26,940 There's also over there updates so you don't have to go into a dealership. 18 00:01:26,940 --> 00:01:32,440 Some of this connectivity is much more for the engineering company's benefit than for the consumer. 19 00:01:32,500 --> 00: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. 20 00:01:46,320 --> 00: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. 21 00:01:56,800 --> 00: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. 22 00:02:08,560 --> 00:02:11,120 And that's where MQTT comes in. 23 00:02:11,700 --> 00: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. 24 00:02:28,840 --> 00:02:34,980 The TCU is going to be likely on the CAN bus and accept other inputs from the car. 25 00:02:34,980 --> 00: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. 26 00:02:45,300 --> 00:02:52,300 It'll be able to use its cellular connection to the cloud to send information in the form of MQTT messages. 27 00:02:52,440 --> 00: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. 28 00:03:06,700 --> 00: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. 29 00:03:20,940 --> 00:03:28,060 And then CAN transceivers are another way of interfacing with the other parts of what is happening in the car. 30 00:03:28,260 --> 00: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? 31 00:03:37,260 --> 00: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. 32 00:03:46,040 --> 00:03:53,020 The reason is because cars are a bit of a difficult use case from a network and architecture standpoint. 33 00:03:53,020 --> 00: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. 34 00:04:01,420 --> 00:04:06,080 So you need to have some kind of protocol that has minimal overhead and size. 35 00:04:06,080 --> 00:04:10,860 You might want the ability to buffer messages if you're offline for a minute. 36 00:04:11,600 --> 00:04:17,580 And you also might want some kind of method to know if your message was received or not. 37 00:04:18,040 --> 00:04:24,560 You're probably dealing with high network latency, which means that you want to reduce overhead as much as possible. 38 00:04:24,980 --> 00:04:31,100 MQTT clients will remain connected and they don't need to reinitiate a connection with each message. 39 00:04:31,100 --> 00: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. 40 00:04:40,000 --> 00:04:45,180 Hopefully you're also considering the security of the system, but we'll talk about that more later. 41 00:04:46,100 --> 00:04:52,600 MQTT stands for MQ Telemetry Transport or Message Queuing Telemetry Transport. 42 00:04:52,600 --> 00:05:00,280 It came from Andy Stanford Clark and Arla Nipper who are at IBM and Eurotech respectively. 43 00:05:00,280 --> 00:05:06,000 IBM had a MQ or Message Queuing product at the time. 44 00:05:06,000 --> 00: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. 45 00:05:16,260 --> 00:05:22,100 It was originally made to monitor oil pipelines over a satellite link. 46 00:05:22,100 --> 00:05:27,660 So that's where the emphasis on low bandwidth, very lightweight came from. 47 00:05:27,660 --> 00: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. 48 00:05:40,960 --> 00: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. 49 00:05:51,940 --> 00:05:57,040 Given the network challenges that we talked about earlier, it seems like MQTT is a good fit. 50 00:05:57,660 --> 00:06:00,160 So let's talk about how it works. 51 00:06:01,020 --> 00:06:05,180 In MQTT systems, there are two types of network entities. 52 00:06:05,180 --> 00:06:11,220 There's an MQTT broker, now called a server, but I call it a broker out of force of habit. 53 00:06:11,220 --> 00:06:14,600 You also have one or more MQTT clients. 54 00:06:15,900 --> 00: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. 55 00:06:25,420 --> 00:06:28,000 It's pretty much like a post office. 56 00:06:28,900 --> 00:06:33,740 All messages have to travel through the broker in order to get to the other clients. 57 00:06:33,740 --> 00:06:37,880 A client can't send anything directly to another client. 58 00:06:38,440 --> 00: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. 59 00:06:52,600 --> 00:06:59,940 In an automotive environment, a client is going to be the car or specifically the TCU unit in the car. 60 00:07:00,680 --> 00:07:05,400 And the broker is going to be some kind of cloud service that the car company has set up. 61 00:07:05,400 --> 00: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. 62 00:07:13,080 --> 00:07:17,300 So they aren't all talking unfiltered to the same broker. 63 00:07:18,040 --> 00:07:23,320 Here are a few examples of cloud broker services that I have seen or worked with. 64 00:07:23,320 --> 00:07:24,460 There are others. 65 00:07:24,460 --> 00:07:26,400 These are just a couple options. 66 00:07:26,800 --> 00: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. 67 00:07:33,020 --> 00:07:38,480 Each client can either subscribe, publish, or both. 68 00:07:38,480 --> 00:07:43,140 What kind of behavior they do is contingent on how they try and connect to the broker. 69 00:07:43,140 --> 00:07:44,980 We'll see more about that in a minute. 70 00:07:44,980 --> 00:07:51,760 Earlier I said that it is a publish-subscribe method, or PubSub for short. 71 00:07:51,760 --> 00:07:57,300 Each client can designate what information it wants to publish to the broker. 72 00:07:57,300 --> 00:08:02,260 And each client can also specify what information it wants to receive back. 73 00:08:02,260 --> 00:08:06,460 And then the broker just doles out the messages as intended. 74 00:08:06,540 --> 00:08:13,100 Additionally, clients can provide forms of authentication to the broker, but they aren't directly addressable. 75 00:08:13,100 --> 00: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. 76 00:08:24,200 --> 00:08:26,440 And that's where topics come in. 77 00:08:26,860 --> 00:08:29,340 You can designate topics however you like. 78 00:08:29,340 --> 00:08:31,820 However, there are some patterns to follow. 79 00:08:31,920 --> 00: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. 80 00:08:52,320 --> 00:08:58,520 And then if you publish to it, then everyone who is subscribed will receive that information. 81 00:08:59,360 --> 00: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. 82 00:09:21,680 --> 00:09:29,320 Likewise, if you're publishing, you are publishing to a more narrowed down audience. 83 00:09:30,460 --> 00:09:34,240 And then you can just keep nesting as far as you want. 84 00:09:34,240 --> 00: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. 85 00:09:45,480 --> 00: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, 86 00:10:04,540 --> 00:10:08,200 and you'll receive all of the CarHackingVillage topics. 87 00:10:08,880 --> 00: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. 88 00:10:18,180 --> 00: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. 89 00:10:26,420 --> 00:10:32,180 But if you are a client, this is probably more information than you want or that you can handle. 90 00:10:32,180 --> 00: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. 91 00:10:41,020 --> 00:10:44,180 A client can only publish to one topic at a time. 92 00:10:44,180 --> 00:10:47,640 You can't publish to a group of topics or a wildcard. 93 00:10:47,640 --> 00:10:54,320 For the publishing volume, it's up to the client, but think on the order of maybe once per second. 94 00:10:54,320 --> 00: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. 95 00:11:07,060 --> 00:11:10,080 Where you would receive back, probably JSON. 96 00:11:10,080 --> 00:11:13,620 All of that is defined by your system. 97 00:11:13,620 --> 00:11:16,680 It's kind of however you want to set that up. 98 00:11:16,680 --> 00:11:22,300 You can also use the pound sign and plus sign to selectively handle levels. 99 00:11:22,300 --> 00: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. 100 00:11:36,680 --> 00:11:45,720 You could also do car data, pound sign or hashtag to get all information. 101 00:11:45,720 --> 00:11:53,820 So, the lock information, location, engine, and so on for all vehicles on that broker. 102 00:11:54,380 --> 00:12:02,620 If you are securing a MQTT broker, you want to make sure that your clients don't have wildcard privileges. 103 00:12:03,360 --> 00:12:08,640 There's also a set of topics that all start with dollar sign SYS. 104 00:12:08,640 --> 00:12:16,360 These are all administrative type topics that give information on the clients, messages being sent, and so on. 105 00:12:16,360 --> 00: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. 106 00:12:22,860 --> 00:12:31,380 Revisiting this diagram, receiving information isn't like the request response workflow that you're probably used to. 107 00:12:31,380 --> 00:12:36,100 You are not requesting data and then getting a response back containing that data. 108 00:12:36,100 --> 00: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. 109 00:12:49,190 --> 00: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. 110 00:13:01,870 --> 00:13:06,450 There's also an optional small set of delivery assurance messages. 111 00:13:06,450 --> 00:13:08,530 We'll talk about that a little bit later. 112 00:13:08,530 --> 00: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. 113 00:13:23,250 --> 00: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. 114 00:13:33,850 --> 00: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. 115 00:13:52,150 --> 00:13:56,090 There are a number of packet types as listed here. 116 00:13:56,530 --> 00:13:57,490 They come in pairs. 117 00:13:57,490 --> 00: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. 118 00:14:12,550 --> 00: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. 119 00:14:25,310 --> 00: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. 120 00:14:36,190 --> 00:14:43,110 For example, a Connect message is going to provide version information, keep-alive information, and so on. 121 00:14:43,110 --> 00:14:46,910 And then after the headers, you have any kind of payload information. 122 00:14:46,930 --> 00:14:51,310 Typically, you're going to see JSON, but you can do whatever you want, really. 123 00:14:52,290 --> 00:14:59,530 So, here are two examples of Wireshark captures of packets. 124 00:14:59,530 --> 00:15:05,730 The first one is a minimal packet where it's two bytes and it is a Disconnect message. 125 00:15:05,730 --> 00:15:14,810 And then we have a longer packet on the bottom where we are publishing hi to the CarHackingVillage topic. 126 00:15:17,860 --> 00:15:26,400 If we look at a Subscribe message connection in Wireshark, the client is sending a Connect command. 127 00:15:26,400 --> 00:15:29,960 The broker is going to respond with a Connect acknowledgment. 128 00:15:29,960 --> 00:15:39,500 Then the client sends a Subscribe request, and then if it's accepted, the broker will respond with a Subscribe acknowledgment. 129 00:15:39,500 --> 00:15:46,060 If you're doing security testing and you can't get a connection to work, I suggest two different things. 130 00:15:46,060 --> 00: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. 131 00:15:59,240 --> 00: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. 132 00:16:10,900 --> 00:16:17,040 For a Publish command, we have a Connect, a Connect, a Publish, and then a Disconnect message. 133 00:16:17,200 --> 00:16:22,880 If we had a higher quality of service setting, then you might get an ACK or other message back. 134 00:16:23,120 --> 00:16:28,660 And then the final publish line is from the broker to the other connected client. 135 00:16:29,620 --> 00:16:34,680 So once again, you can use the dash d to get some more debug information. 136 00:16:34,940 --> 00:16:38,440 There are three quality of service settings that you can choose. 137 00:16:38,440 --> 00: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. 138 00:16:48,380 --> 00:16:56,460 Level 1 is at least once, it's going to keep sending that message until it gets acknowledgement back. 139 00:16:56,620 --> 00: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. 140 00:17:07,200 --> 00: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. 141 00:17:17,920 --> 00:17:24,620 And to do that, I recommend that you download Mosquito, because you can do all of this on the command line. 142 00:17:24,620 --> 00:17:29,540 There's very minimal setup, and I think it helps cement the ideas. 143 00:17:30,680 --> 00:17:36,160 First of all, you need to go to their download page and get it set up on your computer. 144 00:17:36,160 --> 00:17:38,920 If you're on Mac, you can do brew install mosquito. 145 00:17:39,460 --> 00:17:41,820 Then you will need to start the service. 146 00:17:41,820 --> 00:17:45,800 I'm on a Mac, so I did the line shown here. 147 00:17:46,680 --> 00:17:49,580 And then you want to open up two more terminals. 148 00:17:49,720 --> 00:17:52,660 In the first one, you want to subscribe to a topic. 149 00:17:53,520 --> 00:17:56,400 For example, I had CarHackingVillage. 150 00:17:56,600 --> 00:18:01,100 And then the "-i client1 is my client ID". 151 00:18:01,100 --> 00:18:03,040 You don't have to provide this. 152 00:18:03,040 --> 00:18:07,660 It will make one for you if you don't, but just for completeness. 153 00:18:08,240 --> 00: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. 154 00:18:17,220 --> 00:18:24,060 And then in the first terminal window where you subscribe, you should see that data come through. 155 00:18:26,620 --> 00:18:30,000 Visually, that looks like starting the service. 156 00:18:30,000 --> 00:18:33,560 It will listen on port 1883 by default. 157 00:18:33,560 --> 00:18:40,520 You subscribe, you publish, and then back in the subscribe window, you see that you got Hello World. 158 00:18:41,200 --> 00:18:44,740 If localhost is too boring for you, then you're in luck. 159 00:18:45,380 --> 00:18:52,440 Mosquito.org has set up a test broker where you have ports for each type of broker service. 160 00:18:52,540 --> 00:18:57,960 You can subscribe to all topics using the hashtag or pound sign. 161 00:18:57,960 --> 00: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. 162 00:19:08,040 --> 00:19:15,540 You can see this note on their website that says don't publish anything sensitive because anyone can be listening. 163 00:19:15,860 --> 00:19:17,780 You probably know where this is going. 164 00:19:17,780 --> 00: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. 165 00:19:28,260 --> 00:19:31,320 We have what seem to be plain text passwords. 166 00:19:31,320 --> 00:19:36,080 We've got the lighting and temperature controls for some office. 167 00:19:36,080 --> 00:19:40,260 Probably most concerningly an over-the-air update. 168 00:19:40,480 --> 00:19:45,980 And then this last person was just publishing basic C4 encoded images. 169 00:19:46,600 --> 00:19:50,940 A lot of the data being published here is probably junk. 170 00:19:50,940 --> 00:19:53,540 However, some of it does look important. 171 00:19:53,540 --> 00: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. 172 00:20:08,060 --> 00:20:12,180 There's usually a note to change it, but of course not everyone does that. 173 00:20:12,180 --> 00: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. 174 00:20:22,440 --> 00:20:25,740 Since this is DEF CON, I should probably talk about security. 175 00:20:25,740 --> 00: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. 176 00:20:39,120 --> 00: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. 177 00:20:53,360 --> 00:21:00,220 As with the Mosquito test server listings, there are different levels of security that you can set on your broker. 178 00:21:00,300 --> 00: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. 179 00:21:12,860 --> 00: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. 180 00:21:20,640 --> 00:21:25,440 By default, MQTT does not require authentication or encryption. 181 00:21:25,440 --> 00:21:27,600 You can set that up on your own. 182 00:21:27,600 --> 00: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. 183 00:21:44,360 --> 00:21:51,400 Hopefully, that isn't enough security for your connected car architecture and you want to do a little bit more. 184 00:21:51,460 --> 00:21:55,240 The next thing to do is to add encryption. 185 00:21:55,480 --> 00:21:58,840 We can do MQTT over TLS. 186 00:21:58,840 --> 00:22:07,700 We use a certificate to encrypt traffic between the client and the server, which means no more plain text credentials. 187 00:22:08,220 --> 00:22:10,960 Random people can't connect to your server. 188 00:22:10,960 --> 00:22:16,680 If you try and connect without a certificate, the server won't even respond with an acknowledgement. 189 00:22:17,680 --> 00:22:24,100 Your data is going to be encrypted in transit, which is a significant step up in security. 190 00:22:24,100 --> 00:22:27,360 I don't think you'll see many car networks with unencrypted traffic. 191 00:22:27,360 --> 00:22:30,000 I don't know that you can say the same for IoT. 192 00:22:31,120 --> 00:22:35,860 Let's say you have a car network set up with MQTT over TLS. 193 00:22:35,860 --> 00:22:39,040 You still need to use defense in depth. 194 00:22:39,400 --> 00: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. 195 00:22:53,280 --> 00:22:57,940 You could connect to the broker or server using that information. 196 00:22:58,240 --> 00:23:00,160 You might think that's not a big deal. 197 00:23:00,160 --> 00:23:03,080 You're just going to get information about that TCU. 198 00:23:03,080 --> 00: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. 199 00:23:15,600 --> 00:23:19,640 That means we need to employ some level of authentication. 200 00:23:21,140 --> 00:23:25,380 We already said that authentication is not required by default. 201 00:23:25,380 --> 00:23:28,840 You can configure your broker to authenticate clients. 202 00:23:28,840 --> 00:23:36,820 If you are using some kind of paid-for service like AWS IoT, they probably make this even easier for you. 203 00:23:37,280 --> 00:23:44,040 You can pass in a username and password to authenticate devices against a device list. 204 00:23:44,040 --> 00:23:49,120 But what would be even better than that is to have individual client certificates. 205 00:23:49,900 --> 00:23:56,160 Of course, this makes the manufacturing and provisioning process more difficult and more expensive. 206 00:23:56,280 --> 00: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. 207 00:24:06,020 --> 00: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. 208 00:24:20,040 --> 00:24:25,060 If you have authentication set up, you still need to think about authorization. 209 00:24:25,380 --> 00:24:30,300 What kind of data or functionality should a single device have access to? 210 00:24:30,300 --> 00: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. 211 00:24:39,740 --> 00: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. 212 00:24:49,320 --> 00:24:50,960 You should try both. 213 00:24:52,720 --> 00:24:58,340 Brokers can be configured to disconnect clients that are asking for unauthorized topics. 214 00:24:58,340 --> 00:25:01,180 I don't know how common this is in the wild. 215 00:25:01,180 --> 00: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. 216 00:25:15,260 --> 00: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. 217 00:25:23,980 --> 00:25:28,160 Can you use hashtag or pound sign to connect to all topics? 218 00:25:28,160 --> 00:25:32,120 If not, then you need to have a little bit more nuance. 219 00:25:32,120 --> 00: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. 220 00:25:49,180 --> 00:25:55,880 For example, location, latitude, and see if you can get information that way. 221 00:25:55,880 --> 00: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. 222 00:26:05,640 --> 00:26:13,100 You should also try the system level topics to see if you can find information about the connected clients. 223 00:26:13,100 --> 00: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. 224 00:26:33,000 --> 00:26:40,700 For example, if the ID is a VIN, you can probably guess other valid VINs or look them up somehow. 225 00:26:40,700 --> 00:26:47,480 They might also be using the IMEI or the ICC ID of the telematics control unit. 226 00:26:47,740 --> 00: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. 227 00:27:02,230 --> 00:27:05,590 There are other security features that you could use. 228 00:27:05,590 --> 00:27:13,910 For example, the access control violation rules mentioned earlier or a VPN to close the attack surface up even more. 229 00:27:14,150 --> 00: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. 230 00:27:19,270 --> 00:27:24,850 MQTT Pwn is a whole framework around MQTT testing. 231 00:27:24,850 --> 00: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. 232 00:27:31,790 --> 00: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. 233 00:27:39,150 --> 00:27:40,990 It's a great resource. 234 00:27:43,070 --> 00: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. 235 00:27:54,990 --> 00:27:58,130 You have one broker and multiple clients. 236 00:27:58,130 --> 00:28:05,390 In the automotive world, the clients are likely TCUs, but might be other things as well, like mobile apps. 237 00:28:05,410 --> 00:28:10,850 Information is separated out by topic hierarchies as defined by each system. 238 00:28:12,290 --> 00:28:15,970 MQTT security is important because of privacy concerns. 239 00:28:15,970 --> 00:28:19,610 You have car location that could be shared over MQTT. 240 00:28:19,810 --> 00: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. 241 00:28:33,670 --> 00:28:38,230 Hopefully, again, you have defense in depth and you have other checks for that. 242 00:28:39,130 --> 00: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. 243 00:28:51,490 --> 00:28:57,750 And lastly, MQTT is something that you can use in car hacking, if you have a car with a telematics component. 244 00:28:57,750 --> 00: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. 245 00:29:10,090 --> 00:29:12,150 I hope this has been useful. 246 00:29:12,150 --> 00:29:16,050 I'll be around in Discord for a little bit afterwards. 247 00:29:16,050 --> 00: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. 248 00:29:28,780 --> 00:29:30,040 All right. 249 00:29:30,040 --> 00:29:31,580 Jamie Lightfoot, everyone. 250 00:29:31,580 --> 00:29:33,820 Thank you very much for your talk. 251 00:29:34,580 --> 00:29:38,680 Jamie, I believe you're also in the channel currently. 252 00:29:42,520 --> 00:29:44,520 Good evening. 253 00:29:45,220 --> 00:29:49,280 Actually, we don't have any questions coming from the audience. 254 00:29:49,280 --> 00: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. 255 00:30:06,140 --> 00: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. 256 00:30:20,020 --> 00:30:24,120 So, Jamie, thank you very much for the talk today. 257 00:30:24,120 --> 00:30:25,520 It was really nice. 258 00:30:26,480 --> 00:30:29,280 Thank you, and thank you, everyone, for listening. 259 00:30:30,640 --> 00:30:31,740 Great. 260 00:30:31,740 --> 00:30:36,600 And once again, contact Jamie if you have any questions. 261 00:30:36,600 --> 00:30:47,470 If you want to make any comments or just talk about MQTT, excuse me, then talk with her directly. 262 00:30:48,290 --> 00:30:52,250 Jamie, thank you for the presentation again. 263 00:30:52,450 --> 00:30:58,890 And actually, this was our last presentation, our last talk of the day.