Transcription

In our previous video we showed you how we hacked the TP-Link router and got a win in the Pwn2Win competition. One of the most frequent questions we got asked was how did we get initial access to the device to perform recon. Today we will show you the exact techniques we used and how we can do the same to get a root shell in many IoT devices. So sit back and enjoy the ride. Hey guys, this is Pedro from the Flashback team. And I am Radek. And today we are here to show you what is UART and what you can do with it from a hacker's point of view. So have fun and if you enjoy the video please like, please subscribe, but more importantly please share it with friends, colleagues or whoever might be interested in it. So let's get going. UART is an extremely important protocol that is used in many devices. It allows components to speak to each other and you will find it in almost any embedded device like routers, cameras, phones or even cars. But for us we are the most interested in the UART as a debug interface. So what can we do with UART? Most embedded devices will have this serial console which is used for various purposes during manufacturing, for debugging, etc. And if we are lucky, when we connect to it, we get a root shell. So this will help us do recon on the device, debug exploits, etc. We can also use it to explore the file system, to dump the firmware, and in some cases even perform attacks such as attacking the bootloader, accessing an encrypted memory, etc. Of course, not all that glitters is gold. Sometimes some device manufacturers, they disable the UART console, the serial console before shipping a device. So sometimes we can bypass restrictions. There's a certain secret key combination we have to enter at boot to activate the console. They also might have a login. This login might have an easy to guess password or a very hard randomized per device password. We might also land in a sort of restricted shell that allows us to run some commands but not many, and then we'd have to find a way to bypass it. Or in some cases, we only get a read-only console. This is just showing a boot log, showing what's happening, and there's nothing we can do. We cannot interact with it. So the good news is that we're hackers, right? So we can always find a way. So we can use command injection or other tricks to bypass some shell restrictions and execute the command we want. We can also try to guess the login password either by cracking it or by inspecting the firmware. In some cases, we can even dump the firmware over a UART-restricted serial shell. We can also try to interrupt the bootloader and use some other tricks to get a root shell. And the thing is, even if you just get a read-only console and there's no way to bypass it, it can still be very useful. For example, we can use the boot log to see what's happening on device, what services are being started, what components are there in the board, where's the memory, where's the file system. And in some cases, we've seen this in the past, we have passwords echoed into this boot log, which we can use to enter SSH or some services like that. But also very importantly, we also have crash logs from our exploitation attempts. So let's say you only have read-only access to a console, you can only see what's happening. But you know there's a service and you're attacking it, you're fuzzing it, or you're sending network packets. And if there's a crash, very likely that this boot log will contain the crash dump. So it'll show you what's on the registers, what's happening at crash time, etc., which can be very useful to debug and exploit. Okay, good intro, Pedro. Let's continue and try to understand how a UART communication works. We know that UART is a serial communication protocol between two devices. In this case, a device A, which is us, wants to speak to device B, which is our target. So we need a connection from our transmission line, TX, to a receiver line on a target, ARX. And the same goes in the opposite direction. Target will send its data on its TX line, and the data will end up on our end on the ARX line. And both devices have to be grounded. But how do we really find a physical UART interface on the target? Well, in most of the cases, we'll be looking for a sequence of paths or pins. We know that we need three pins to connect to, an ARX, a TX, and a ground. We can ignore the VCC pin, which is usually also there. It is where the power line from the target's device is routed, but we don't really need it in our purpose. If we additionally find a mark for the pin number one, then it's even better, as it might confirm that we are looking on some sort of interface. But remember, the mark only informs us which side of the pins should be referenced from. But UART interface does not always look the same. You will need some experience to quickly narrow down your candidates. So let's take a quick look on some examples. Here we have a Netgear router. The UART interface is marked with a red square. In this case, we are super lucky. The pins are already soldered and labeled. It could not be easier than this. On this device, UART interface is a row of four pins with a triangle marking pin number one. We might have to solder our own pin header and identify the ARX, TX, and the ground. And here, we don't have the pin headers, but the pins are labeled. Not too bad. Still saves us some time. Oh, that's a good one. It's a security camera. You can see it has an interface that is a so-called edge connector. Vendor most likely has a special connector for it, but you can do without. Just find the ARX, TX, and ground, and you're good to go. Another camera sample. But this time, there are no through holes, but a pad. Notice the very tiny marks of ARX and TX. If you want to connect to this one, the best would be to use articulated arms that I have showed you in the previous video. Or just solder wires into it. And the last example. It's a Tesla ECU with a card edge connector. So, now you can see that there are many variants how the UART interface could be implemented on a device. But this is not the complete list. In some cases, the pins might be hidden or removed completely. As we now know how to find a candidate for the UART interface, let's go to the next step. How to find out the purpose of each of the pins. I would start off with a multimeter and a ground pin. Simply switch a multimeter into a continuity mode, find a grounded element on the router, and move a probe one by one. When you hear the beep sound, that is your ground. Now, you are ready to find TX and ARX. You could use a logic analyzer for that or continue with a multimeter. With the router power on, test the remaining pins. A pin with a constant 3.3V is most likely a power pin. You don't need it now. A pin with 0V is probably an ARX, as it would expect data from you. A pin that has a floating voltage is a TX, as that's the data that the router is sending. As we have found out the purpose of each pin, we can try to communicate with it. For this, we need a device that can speak UART like this one. I connected to my computer via USB port and wired up with the target. Remember, the ARX goes to TX and TX goes to ARX. Ground goes to ground. Ok, everything wired up. Now, we need a software that can use the UART device and actually speak with the target. I like to use Screen Linux tool, but let's use the Minicom this time, as probably more people are familiar with it for a serial communication. Power up the target. Oh, snap! What is that? Well, I must have messed up something in the settings. Let's take a quick look into that. Damn, that's a lot of things that can go wrong. Ok, it's time to dig more into the UART protocol itself. UART sends data in a form of well-defined frames. The frame always starts with a start bit to indicate the beginning of the frame. Then, the data follows. In most of the cases, it will be 8 bits of data, but protocol specifies it can be from 5 to 9 bits. After that, a parity bit comes. The purpose of parity bit is to indicate the potential errors in the transmission. Depending on the mode, it counts the number of 1s, and by adding or, well, not adding a parity bit, it tries to make them odd or even. But the parity bit is really an optional field, and actually it is very rarely used. The frame end is indicated with a stop bit. It can be 1, 1.5 or 2 bits in size. But again, in most of the cases, it will be just 1 bit in size. Let's assume we would like to send data with a letter A, which is 0x41. We have a high line that indicates a positive voltage, for example 3.3V, and a low line 0V. By default, the line idles in high, so that means if we want to start transmission of our frame, we have to pull it down to 0V to indicate a start bit, which is 0. Now data comes in. It is sent with the least significant bit first. As in 0x41, the first bit is 1. The voltage has to rise to indicate it. Then a bunch of 0s comes, a 1, and the most significant bit 0. And that's the end of the data part. In this example, I have also included a parity bit, but for completeness only. As said before, it is rarely used in our targets. The frame is closed with a stop bit. And the last thing that you need to know is the bound rate. The bound rate indicates how fast the data will be sent over the wire. So this is crucial that a receiver and a transmitter have set the same bound rate. There are a few defined rates in the protocol, but most common are 9600 for some older or less powerful devices, and 115200 bits per second. OK, now with all that information, we can simply try to see what happened that our target didn't want to speak properly with us. Let's look into the wire and see what UART frames have been transmitted, and we'll find out. We can use a logic analyzer for it, such as this one. It's Celia. It is a 4-channel version, which means I can intercept traffic on 4 wires at the same time. It will help us to understand how the voltage changes on the wire, which we can interpret as logical 1 or 0. On the reverse, you can see its pinout. G stands for ground and the channels. So I use the pin headers to hook the logic analyzer to the ground and the TX pin on the router. Now, connect the logic analyzer to the computer. Wait for it to be discovered by the software. Power up the router and let's find out what is sent on the wire. This is an interface for the Celia. We'll see what is happening on the wire of channel 0 for both digital and analog inputs. Let's hit that play button and intercept the data. Oh yes, baby, something is coming up. Let's dig into it. When I zoom in, you can see individual changes in the voltage. That will represent logical data, of course. As we assume we are looking at the UART, let's find some recurring waves to calculate the band rate, or how fast the bits are sent on the wire. If we measure the width of the logical 1 wave, we can use the calculator to get the rate. It's quite easy. You just take 1 and divide 1 by the width of the bit and we adjust for the units as we are working with seconds and microseconds. Now we know we need to use 115200 band rate. Let's add the analyzer of the async serial and confirm our assumption. Input channel 0. Now we know the bit rate. 8 bits of data per frame. 1 stop bit. No parity bit. Basically, all standard. OK, let's quickly look at the beginning of the communication. We can see the idle which is pulled down. That would indicate the start bit. Then 8 bits of data. And the stop bit. So far, so good. Let's change the data encoding to ASCII. Oh, that looks like proper data. I think I have figured out the band rate now. Let's confirm it with the minicon again, but I have a good feeling we gonna win this one. Minicom, here we come. Let's pop that help window. I am interested in configuring minicom, so I press O. Now press E, so I can set the speed of the device. And again E, so we set it to 115200. Notice the remaining settings. We say 8 bits of data, no parity and 1 stop bit. Power up the target. Finally, this is the boot log of the router. We win. Let's stop that autoboot. Why it doesn't react? Ah, yes. Do you remember from the previous video we had to use that super neat hack to connect the RX line of the router? Let me quickly explain you how we could deal with that problem. I took a picture of the target and loaded it to GIMP. I am sorry it might look small, but I didn't find a way to increase the font in GIMP. On the picture we see a main CPU and a lot of traces that go from it. And some of the traces are going to the area of the UART interface. That is usually already a good sign. So this is our busted RX pin. Notice a connection to that R24 pad. Notice a connection to that R24 pad. Maybe it was a resistor that TP-Link decided to remove to disable the UART, I don't know. But then I measured it and I knew there is no connection between the pin and the rest of the line. And if you would be tracing the line you would notice that it disappears at some point. It's because the PCBs are multilayered, which means the traces run on various levels. However, for simpler PCBs we can try to visually connect them. Let me show you how. I colored both traces, the TX with pink and RX with red. Then, if I use the settings for the transparent level and align pictures of front and back, you can trace them kind of end-to-end. You can even remove the green color, that could help us visualize it better. So now we can see that both RX and TX do terminate on the main CPU. You could try to find a datasheet for that chip and confirm it, but I will skip it for now. To recap, we know that our RX line is broken. That's why we can't send data to it. So all we have to do is to reconnect it again and we did it by placing that paperclip bridge. So now the line is connected and we have a very high probability that we can send data over it and eventually get root shells via UART. Please share this video and subscribe to the channel. If you haven't seen our previous video where we present a complete walkthrough how to gain a remote code execution on this router, please check it out. You'll be able to understand this much better. Make sure to visit our website flashback.sh where we upload more technical documents and security advisories. Take care. you