1 00:00:00,000 --> 00:00:19,255 *35C3 preroll music* 2 00:00:19,255 --> 00:00:30,393 Herald Angel: So… Yaniv Balmas is a software engineer and he started tinkering 3 00:00:30,393 --> 00:00:35,558 with Commodore's C64 when he was 8 years old. 4 00:00:35,558 --> 00:00:38,836 He was kind of a teenage hacker of games as well. 5 00:00:38,836 --> 00:00:43,497 And now he's in the security field and he got interested in the fax machine 6 00:00:43,497 --> 00:00:51,762 together with his friend Eyal Itkin, who is also a security guy and malware researcher. 7 00:00:51,762 --> 00:00:57,373 And together they're going to tell us about the fax machines and What The Fax?! 8 00:00:57,373 --> 00:01:00,911 Why still using people those machines? 9 00:01:00,911 --> 00:01:03,805 And it's gonna be really interesting I think. 10 00:01:03,805 --> 00:01:08,278 And the title is also "Hacking your network likes it's 1980 again" 11 00:01:08,278 --> 00:01:12,308 I'm really excited. Please give a warm round of applause to those two guys. 12 00:01:12,308 --> 00:01:15,552 *applause* 13 00:01:15,552 --> 00:01:25,159 *fax modem sounds* 14 00:01:31,259 --> 00:01:35,568 Yaniv: Thank you, thank you guys. Hi, CCC! 15 00:01:35,568 --> 00:01:39,276 You probably know this sound, right? And now get to know us: 16 00:01:39,276 --> 00:01:44,553 My name is Yaniv Balmas, I'm a security researcher. I work at Check Point Research, 17 00:01:44,553 --> 00:01:50,172 and with me here today is Eyal Itkin, also a security researcher, also works at 18 00:01:50,172 --> 00:01:55,269 Check Point Research, and let's begin with talking a bit about the history of fax. 19 00:01:55,269 --> 00:01:59,131 So I guess that not many of you know that fax started, 20 00:01:59,131 --> 00:02:03,745 it was first invented in 1846 by a scientist called Alexander Bain. 21 00:02:03,745 --> 00:02:09,480 Fun fact, this happened 20 years before the invention of the light bulb. 22 00:02:09,480 --> 00:02:14,060 And then it had some more advances to it, this is the actual first thing that looked 23 00:02:14,060 --> 00:02:16,582 like a fax machine, a standard fax machine. 24 00:02:16,582 --> 00:02:20,710 And again, this thing was invented 20 years before the invention of the telephone. 25 00:02:20,710 --> 00:02:25,292 So humanity was sending faxes before we had light or talked over the phone. 26 00:02:25,292 --> 00:02:29,948 And then there was some more advancements like radio fax, 27 00:02:29,948 --> 00:02:34,894 and an another important point in time is 1966, where a small unknown company 28 00:02:34,894 --> 00:02:39,995 called Xerox invented – came out with the first commercial fax machine. 29 00:02:39,995 --> 00:02:42,988 This is the advertisement for it. 30 00:02:42,988 --> 00:02:49,805 And in 1980 a strange organization called ITU defined the core standards for fax. 31 00:02:49,805 --> 00:02:56,234 Namely it's T.30, T.4, T.6, and those standars are still the same standards 32 00:02:56,234 --> 00:03:00,304 that we use today – basically, with just minor changes to them. 33 00:03:00,304 --> 00:03:05,065 So this was all in the past. But what's happening today? 34 00:03:05,065 --> 00:03:09,512 I mean today we have far better ways to send electronic documents 35 00:03:09,512 --> 00:03:11,544 from one to the other, right? 36 00:03:11,544 --> 00:03:14,882 You know, let's compare fax to just, I dunno, off the top of my head 37 00:03:14,882 --> 00:03:21,704 just, you know, one method like, let's say, email. And just to, you know, remind you. 38 00:03:21,704 --> 00:03:27,758 We are comparing this… to this, okay? So… let's look at some of the features here. 39 00:03:27,758 --> 00:03:36,433 In terms of quality, in terms of accessibility, I'm pretty sure that all of you here 40 00:03:36,433 --> 00:03:43,424 have 24/7 access to emails. Not so sure you're carrying around your fax machines with you. 41 00:03:43,424 --> 00:03:48,679 In terms of reliability, well, when you send a fax, you don't really know 42 00:03:48,679 --> 00:03:52,979 if it got received or not. Yes, there is this strange confirmation page, 43 00:03:52,979 --> 00:03:55,910 but it doesn't really mean anything. I mean, if there's no paper in the 44 00:03:55,910 --> 00:04:01,812 receiving fax, you still get it. If the dog ate it, you still get it. 45 00:04:01,812 --> 00:04:08,895 There's absolutely no reliability in fax. Regarding authenticity, well, we can argue 46 00:04:08,895 --> 00:04:12,638 about emails, if it's authenticated or not, it could be forged, of course. 47 00:04:12,638 --> 00:04:16,449 But we do have public key cryptography and stuff like that, that will help us 48 00:04:16,449 --> 00:04:21,842 when talking about emails, while we don't have… we don't have nothing when it comes to fax. 49 00:04:21,842 --> 00:04:26,487 Absolutely no authenticity. So, if we're looking at this table, one might think to 50 00:04:26,487 --> 00:04:31,307 himself: Okay, so… Who the hell still uses fax today? It's 2018. 51 00:04:31,307 --> 00:04:37,285 I mean, it deserves a place in the museum of great technologies and that's it. 52 00:04:37,285 --> 00:04:40,144 So, nobody is using fax today, right? 53 00:04:40,227 --> 00:04:41,796 Wrong. 54 00:04:41,858 --> 00:04:44,929 Everybody are using fax today. 55 00:04:44,929 --> 00:04:52,322 You see, fax is used to send these very critical maritime maps to ships at open seas 56 00:04:52,322 --> 00:04:57,924 90% of the japanese population uses fax – according to Wikipedia at least. 57 00:04:57,924 --> 00:05:02,965 And if you google any kind of combos like "contact us" and "fax" or stuff like that, 58 00:05:02,965 --> 00:05:08,379 you will come up with something like 300 million results. 300 million published 59 00:05:08,379 --> 00:05:13,006 fax numbers in Google. And that's not counting the unpublished numbers. 60 00:05:13,006 --> 00:05:17,978 That's a huge amount of numbers. But it's not all about numbers. It's not "how many 61 00:05:17,978 --> 00:05:22,126 fax machines are out there?", but it's also "Who is using fax?" 62 00:05:22,126 --> 00:05:25,957 You see, if you're a small corporation, a medium corporation, a huge corporation, 63 00:05:25,957 --> 00:05:30,344 you have fax. Not necessarily anybody is sending fax to this number, but there is a 64 00:05:30,344 --> 00:05:35,614 fax machine sitting there waiting for a fax to be received. If you're a bank, 65 00:05:35,614 --> 00:05:41,211 you simply love faxes. This is Bank of China, the biggest bank in the 66 00:05:41,211 --> 00:05:47,129 world, and that's the fax number of it. I think most importantly, if you're a 67 00:05:47,129 --> 00:05:49,697 government organization… you… *laughter* 68 00:05:49,697 --> 00:05:53,362 … simply wake up in the morning and you want to have more fax. This is 69 00:05:53,362 --> 00:05:56,979 Donald Trump's fax number if anybody wants to send him a fax. Go ahead. 70 00:05:56,979 --> 00:06:02,975 That's it. It's not a secret, it's from Google… We should send him something 71 00:06:02,975 --> 00:06:10,020 by the way. And the thing is that, you know, those banks and government institutions, they 72 00:06:10,020 --> 00:06:14,844 don't only support fax, allow you to send fax, the funny thing is that actually most 73 00:06:14,844 --> 00:06:18,726 of the time, it's mandatory to send fax, there is no other way. You can either 74 00:06:18,726 --> 00:06:22,473 postal mail it, or fax it. They didn't hear about anything else. 75 00:06:22,473 --> 00:06:26,426 So we looked at this, state of affairs, strange state of affairs, 76 00:06:26,426 --> 00:06:31,063 and said to ourselves: "This looks strange". I mean, it can't be true. 77 00:06:31,063 --> 00:06:35,840 Humanity came so far and we're still using these old technologies, so… 78 00:06:35,840 --> 00:06:38,572 What The Fax?! 79 00:06:38,572 --> 00:06:43,369 And we decided and try to do something about it. And we started very long 80 00:06:43,369 --> 00:06:50,224 research to try and find some security vulnerabilities in fax. And before we do 81 00:06:50,224 --> 00:06:56,698 that, you need to explain how fax looks like today. You see, today fax doesn't 82 00:06:56,698 --> 00:07:01,888 look like it looked 20 or 30 years ago. Then, it was just standalone fax machines. 83 00:07:01,888 --> 00:07:02,618 Right? 84 00:07:02,618 --> 00:07:08,382 Today, fax is mostly old technology embedded within newer technology. 85 00:07:08,382 --> 00:07:16,030 So, we have fax to email services or email to fax services, we have as I said before, 86 00:07:16,030 --> 00:07:22,237 radio fax and fax over satellite and stuff like that. I think most commonly, we have 87 00:07:22,237 --> 00:07:28,725 this. These machines. All-in-one printers. You buy them, they scan, they print. 88 00:07:28,725 --> 00:07:32,525 And they fax. It actually comes with a phone cable out of the box, so you can 89 00:07:32,525 --> 00:07:37,341 connec… I guess most people connect it? I also think that is the most common 90 00:07:37,341 --> 00:07:41,838 faxing solution today. So we decided to take a look at these machines. 91 00:07:41,838 --> 00:07:47,412 These fax machines. If you look at these boxes 92 00:07:47,412 --> 00:07:52,248 from a security point of view you can imagine them to be just black boxes. 93 00:07:52,248 --> 00:07:56,464 And those black boxes have interfaces. In one side of the box we have interfaces 94 00:07:56,464 --> 00:08:02,021 like WiFi, bluetooth, ethernet, stuff like that, these interfaces connect the printer 95 00:08:02,021 --> 00:08:05,751 to the internal network, the external network, basically it connects it to the 96 00:08:05,811 --> 00:08:11,534 world. And on the other side of this box, there's this little interface here that 97 00:08:11,534 --> 00:08:16,721 connects this black box to somewhere to the 1970s I would say. 98 00:08:16,721 --> 00:08:18,396 *Laughter* 99 00:08:18,396 --> 00:08:19,986 So that's pretty funny. 100 00:08:20,041 --> 00:08:26,894 And if you remember, at the end of the day these printers are basically nothing but 101 00:08:26,894 --> 00:08:31,468 computers. They have CPUs, they have memories, they have operating systems, 102 00:08:31,476 --> 00:08:34,598 they are computers. Not standard ones, but they are computers. 103 00:08:34,598 --> 00:08:39,871 And we were thinking to ourselves, imagine this scenario: There's an attacker sitting 104 00:08:39,871 --> 00:08:45,326 somewhere in the world. All he has is access to a phone line and his targets fax 105 00:08:45,326 --> 00:08:50,366 number. What will happen if this attacker, this guy, would be able to send a 106 00:08:50,366 --> 00:08:55,443 malicious fax and with this malicious fax he would be able to exploit the printer. 107 00:08:55,448 --> 00:09:00,958 Then he has complete control over the printer, right? If he does that, he could 108 00:09:00,978 --> 00:09:07,196 then maybe pivot through any one of those other interfaces, let's say the Ethernet 109 00:09:07,196 --> 00:09:12,228 and jump from this printer to the rest of the network, the internal network. 110 00:09:12,228 --> 00:09:16,778 Effectively creating a bridge between the external world and the internal network 111 00:09:16,778 --> 00:09:20,090 through the phone line. That's 1980s again! 112 00:09:20,090 --> 00:09:26,377 So we thought this is a really cool attack scenario and we decided to accept this 113 00:09:26,377 --> 00:09:31,774 challenge and go for it. Try and actually show this thing happening in reality. 114 00:09:31,774 --> 00:09:37,282 We were really excited about this. But then after we slept a bit and drank 115 00:09:37,282 --> 00:09:42,797 a bit, sat down and talked about it, we kind of found out that there is like a lot 116 00:09:42,797 --> 00:09:47,920 of challenges, really hard challenges in front of us and we're not really sure how 117 00:09:47,920 --> 00:09:54,148 to deal with them. Let me name just a few of them. One of the challenges is how do 118 00:09:54,148 --> 00:09:58,010 we obtain the firmware. The code that this printer runs. It's not like you have it 119 00:09:58,010 --> 00:10:02,566 everywhere. And after we get it, how do we analyze this firmware? 120 00:10:02,566 --> 00:10:03,776 After we analyze it, 121 00:10:03,776 --> 00:10:07,521 we need to understand what operating system are those printers running. 122 00:10:07,521 --> 00:10:10,122 And then we need to understand how to debug a printer.. 123 00:10:10,122 --> 00:10:11,792 I never debugged a printer before.. 124 00:10:11,792 --> 00:10:15,098 I need to understand how to debug a printer. And after we do all that, 125 00:10:15,098 --> 00:10:20,032 we need to understand… How does fax even work? We only know the beeping sounds like 126 00:10:20,032 --> 00:10:25,823 most of us I think. And after we did all that, we can start talking about where can 127 00:10:25,823 --> 00:10:29,325 we find vulnerabilities inside this big, big, big ecosystem. 128 00:10:29,325 --> 00:10:33,716 And today, we'll try to take you through these challenges, one-by-one and explain 129 00:10:33,716 --> 00:10:38,157 how to do it until we'll be able to actually do the scenario that we just 130 00:10:38,157 --> 00:10:43,634 showed you. So, let's start with the first challenge. 131 00:10:43,634 --> 00:10:49,282 How do we obtain the firmware for the printer? 132 00:10:49,282 --> 00:10:53,082 So, meet our nice printer. It's an HP inkjet printer, 133 00:10:53,082 --> 00:10:59,237 an HP Officejet printer, we chose this model, first of all we chose HP because 134 00:10:59,237 --> 00:11:03,729 it has like – I think – 40% of the market share so it's not that we dislike HP, we 135 00:11:03,729 --> 00:11:07,632 really like them, but unfortunately for them, they are just the biggest target out 136 00:11:07,632 --> 00:11:12,108 there. And this specific model, well we had a lot of reasons why we chose this 137 00:11:12,108 --> 00:11:16,800 printer. But basically it's the cheapest one. 138 00:11:16,800 --> 00:11:19,267 *Laughter* 139 00:11:19,267 --> 00:11:23,029 We bought it. We didn't have a lot of budget. We bought it and we abused it for 140 00:11:23,029 --> 00:11:30,716 a lot of time. And our goal was to break fax, but before we do that, we had to 141 00:11:30,716 --> 00:11:36,877 break the printer. I mean literally break the printer. So yeah, that was the fun 142 00:11:36,877 --> 00:11:42,320 part of the project, we broke it. And inside the printer we find this thing: 143 00:11:42,320 --> 00:11:46,583 The main PCB, the brains behind the printer, and it looks like this. 144 00:11:46,583 --> 00:11:49,006 Let's map the critical components of it: 145 00:11:49,006 --> 00:11:53,836 So we have here: Flash ROM, SPANSION some model, 146 00:11:53,836 --> 00:11:59,131 and then we have some more memory here, this might look like not a lot, because 147 00:11:59,131 --> 00:12:04,594 the PCB has two sides to it of course, and on the other side of it we have the 148 00:12:04,594 --> 00:12:08,001 more interesting components, like USB, WiFi, electricity, SRAM, 149 00:12:08,001 --> 00:12:13,457 battery – probably for the memory but who knows – and now we have two very 150 00:12:13,457 --> 00:12:18,682 interesting components here. One of them is the main CPU. It's a Marvell CPU, and 151 00:12:18,682 --> 00:12:23,530 it's proprietarily manufactured for HP. So we can't tell anything about it, 152 00:12:23,530 --> 00:12:27,526 there's no available specs, nothing. We can just find bits of information 153 00:12:27,526 --> 00:12:34,712 here and there. And then we have the fax modem. It's located here and it's a 154 00:12:34,712 --> 00:12:42,717 CSP1040. What we need to understand now is how do these two components operate and 155 00:12:42,717 --> 00:12:46,646 what is the relationship between them? If we do that, we're one step further. 156 00:12:46,646 --> 00:12:53,184 So that's what we tried to do. And as I said, the first challenge is to get the 157 00:12:53,184 --> 00:12:57,153 firmware of this thing. And when we're looking a bit closer into this PCB, we 158 00:12:57,153 --> 00:13:02,262 find these 2 very interesting interfaces: One of them is a serial debug, the other 159 00:13:02,262 --> 00:13:08,151 is JTAG. If you're familiar with them, you know that they give you debugging 160 00:13:08,151 --> 00:13:11,951 capabilities, or at least memory read, memory write, exactly what we need to get 161 00:13:11,951 --> 00:13:15,444 the firmware. So we're smiling to ourselves saying "Haha, this is going to 162 00:13:15,444 --> 00:13:19,519 be really easy". But unfortunately it's not. Because the JTAG is, of couse, 163 00:13:19,519 --> 00:13:24,747 disabled completely. We can't do anything with it. And the serial port, we managed 164 00:13:24,747 --> 00:13:30,228 to connect to it. And we get this terminal that for almost every instruction we type 165 00:13:30,228 --> 00:13:34,302 gives us this error: "I don't understand". Well, we don't understand either. 166 00:13:34,302 --> 00:13:35,795 *laughter* 167 00:13:36,102 --> 00:13:40,394 But it looks like this terminal is not going to get us very far. So we dropped 168 00:13:40,394 --> 00:13:45,433 this path and tried and look for other ways to get the firmware and obviously one 169 00:13:45,433 --> 00:13:52,963 of the most common ways is to try and grab the firmware upgrade and after looking a 170 00:13:52,963 --> 00:13:59,429 bit in the internet we find this jewel, this FTP site by HP that contains 171 00:13:59,429 --> 00:14:02,734 every firmware version for every HP product 172 00:14:02,734 --> 00:14:05,186 ever produced in the history of HP and the Internet 173 00:14:05,186 --> 00:14:08,130 and a lot of other stuff. 174 00:14:08,130 --> 00:14:12,713 And it actually took us about, I think, two weeks to find our firmware within 175 00:14:12,713 --> 00:14:12,963 *Laughter* 176 00:14:12,963 --> 00:14:18,197 … this mess of firmwares. But once we did, 177 00:14:18,197 --> 00:14:21,082 we had a firmware upgrade file. *Applause* 178 00:14:21,082 --> 00:14:24,971 Yes, thank you! It's still alive so you can go there and look for some… there's a 179 00:14:24,971 --> 00:14:29,101 lot of interesting stuff in there. And now we've got ourselves a file. And this file 180 00:14:29,101 --> 00:14:33,201 is the firmware upgrade file. It's not an executable file, it's just a binary, 181 00:14:33,201 --> 00:14:36,396 and now we kinda need to understand… 182 00:14:36,396 --> 00:14:38,924 How do you even upgrade a printer firmware? 183 00:14:38,924 --> 00:14:42,787 I never did it i before. Anybody did it? Anybody upgraded these firmwares? Lately? 184 00:14:42,787 --> 00:14:46,948 Ah, good. Good for you. Good for you. 185 00:14:46,948 --> 00:14:52,320 Anyway, the answer to this question is surprisingly… funny, I would say. 186 00:14:52,320 --> 00:14:54,170 You just print it. 187 00:14:54,170 --> 00:14:55,170 *Laughter* 188 00:14:55,170 --> 00:14:59,366 That's because, you see, a printer receives a firmware upgrade just the same 189 00:14:59,366 --> 00:15:04,155 way as it receives a normal print job. That's the thing and it's actually pretty 190 00:15:04,155 --> 00:15:09,504 nice and it's defined in a HP protocol, it's called PCL XL Feature Reference 191 00:15:09,504 --> 00:15:13,984 Protocol Class 2.1 Supplement. And if you're still sane after reading this like 192 00:15:13,984 --> 00:15:19,837 300 pages of insanity you understand that this thing defines something called a 193 00:15:19,837 --> 00:15:24,455 PJL – print job language. If you ever scanned from a printer to the network you 194 00:15:24,455 --> 00:15:30,198 see this port I think 9100, something like that, open, that you send print jobs to, 195 00:15:30,198 --> 00:15:35,583 and it's the same port that you send the firmware upgrade to, and that's nice. 196 00:15:35,583 --> 00:15:38,255 So when we look at the file, it actually confirms this, 197 00:15:38,255 --> 00:15:41,783 because it actually begins with the words: PJL – Print job language. 198 00:15:41,783 --> 00:15:44,499 So that's nice. So now we know it's a print job language. 199 00:15:44,499 --> 00:15:48,317 But unfortunately this document doesn't document anything about the firmware 200 00:15:48,317 --> 00:15:53,010 upgrade protocol, or anything, because it's HP proprietary. 201 00:15:53,010 --> 00:15:55,710 So unfortunately we had to do it ourselves 202 00:15:55,710 --> 00:16:01,931 and analyze this thing. Now I'm not going to take you through the entire process of 203 00:16:01,931 --> 00:16:07,169 unwrapping this firmware because frankly it's quite boring. But I'll just tell you 204 00:16:07,169 --> 00:16:11,167 that it's composed of several layers of compression, one of them is called 205 00:16:11,167 --> 00:16:14,974 NULL decoder, the other is called TIFF decoder, and another one called Delta Raw 206 00:16:14,974 --> 00:16:21,344 decoder. And the thing is that these things do something like… If the previous 207 00:16:21,344 --> 00:16:25,685 line was all blanks, and if this line is also all blanks, just write one instead of 208 00:16:25,685 --> 00:16:30,095 the line, so that gives you some kind of compression, and it makes really a lot of 209 00:16:30,095 --> 00:16:34,702 sense when you're talking about print jobs because paper has a lot of spaces in it, 210 00:16:34,702 --> 00:16:39,626 but when you're talking about binary files it makes absolutely no sense to do it this 211 00:16:39,626 --> 00:16:46,809 way. But still, it just works this way, so after we understand that, we were able to 212 00:16:46,809 --> 00:16:50,489 decode everything, decompress everything, and we're talking to ourselves and 213 00:16:50,489 --> 00:16:53,420 laughing, when you're a hammer everything looks like a nail, 214 00:16:53,420 --> 00:16:56,333 and when you're a printer, everything looks like a print job. 215 00:16:56,333 --> 00:16:58,000 *Laughter* 216 00:16:58,000 --> 00:17:02,241 So that was nice. And now, after we did that, we have a big file that hopefully 217 00:17:02,241 --> 00:17:04,986 now is our firmware. 218 00:17:04,986 --> 00:17:07,408 So how do we analyze it? 219 00:17:07,408 --> 00:17:10,929 Looking at this thing right at the beginning of the file, there's something 220 00:17:10,929 --> 00:17:14,917 that really looks like a table. It doesn't only really look like a table, it is 221 00:17:14,917 --> 00:17:20,636 a table. We define it, it looks like this. And what this table defines is a loading 222 00:17:20,636 --> 00:17:25,560 address, section name and location in binary. So what that means is that our big 223 00:17:25,560 --> 00:17:30,548 file is actually split into several sections. This table just defines those 224 00:17:30,548 --> 00:17:35,350 sections. So now we are able to split this big file into several smaller chunks and 225 00:17:35,350 --> 00:17:40,867 inspect each chunk. The most important chunk, the one that looks most promising 226 00:17:40,867 --> 00:17:47,102 looks like it contains our firmware. So we took a closer look into that and that's 227 00:17:47,102 --> 00:17:52,249 what we saw: It actually looks like our firmware. That's because you see: That's 228 00:17:52,249 --> 00:17:55,412 one of the strings that we've seen here. 229 00:17:55,412 --> 00:17:56,569 *Laughter* 230 00:17:56,569 --> 00:18:00,896 Yeah! We all saw that before, right? It's "Error: I don't understand". But it's not 231 00:18:00,896 --> 00:18:05,348 completely "Error: I don't understand". There's some missing bytes in here. 232 00:18:05,348 --> 00:18:09,537 And actually those missing bytes are pretty consistent throughout the entire 233 00:18:09,537 --> 00:18:13,945 chunk. So although we know that we are looking at the code, we can't actually 234 00:18:13,945 --> 00:18:18,638 see the code until we have those missing bytes filled. We need to understand: Why 235 00:18:18,638 --> 00:18:23,764 are they there and what were they replaced with? So let's try to analyze this thing 236 00:18:23,764 --> 00:18:28,578 together, quickly, now. But first, let's try to understand what is this thing. 237 00:18:28,578 --> 00:18:34,750 We have a lot of things in mind, every one seemed crazy, but I think the least crazy 238 00:18:34,750 --> 00:18:40,682 option was that this is yet another form of compression. A really bad one, again. 239 00:18:40,682 --> 00:18:44,437 Because when we tried to compress this thing with zlib, for example, we get like 240 00:18:44,437 --> 00:18:49,146 80% better compression than it currently is, and we know that the printer has zlib, 241 00:18:49,146 --> 00:18:53,895 because we see zlib strings in there, so why not use zlib? I don't know. 242 00:18:53,895 --> 00:18:57,716 But still, we are left with a challenge. So this is one snippet of the code that 243 00:18:57,716 --> 00:19:00,420 you just saw, so let's try to decompress this. 244 00:19:00,420 --> 00:19:03,957 First of all, you need to understand this thing is composed of two types of 245 00:19:03,957 --> 00:19:08,471 characters, one are ASCII characters, stuff that you can read, and some other 246 00:19:08,471 --> 00:19:13,781 are stuff that you can't read, non-ASCII characters. And those non-ASCII characters 247 00:19:13,781 --> 00:19:18,054 are actually those missing bytes that we have. So we need to understand what they 248 00:19:18,054 --> 00:19:22,135 are, so let's take a closer look at them. And if you stare at this thing long enough 249 00:19:22,135 --> 00:19:27,386 you'll start seeing some kind of pattern. I'll save you the trouble and just show you. 250 00:19:27,386 --> 00:19:33,529 It's composed of these one single bytes, and then those double bytes in there. 251 00:19:33,529 --> 00:19:37,838 And if the distance between the single bytes looks suspiciously patterned, 252 00:19:37,838 --> 00:19:42,212 8 bytes, 9 bytes, 9 bytes, 8 bytes, over and over again, so what does this mean, 253 00:19:42,212 --> 00:19:47,094 where is the pattern here? If you look at this from a different angle, maybe the 254 00:19:47,094 --> 00:19:52,353 pattern will look a bit clearer. You see that F7 and F7, they look the same. 255 00:19:52,353 --> 00:19:55,469 The FF and FF, they look the same. Something here looks really pattern-ish. 256 00:19:55,469 --> 00:20:00,044 In order to understand this pattern, you need to sharpen your binary view a bit, 257 00:20:00,044 --> 00:20:05,124 and if you understand that FF is just 8 one bits, and if you do that 258 00:20:05,124 --> 00:20:08,794 consistently for all of these chunks, you will start seeing the pattern. 259 00:20:08,794 --> 00:20:13,631 The pattern is that the zero bit always falls within this two-byte hole. 260 00:20:13,631 --> 00:20:18,131 It's consistent throughout the file. And what this means is that the first byte is 261 00:20:18,131 --> 00:20:22,638 just a bitmap describing the following 8 bytes after it. That's what it means. 262 00:20:22,638 --> 00:20:27,171 And that's perfect because now we understand what is this single bytes, but 263 00:20:27,171 --> 00:20:32,202 we still don't understand, what are those double bytes? And they were replaced with 264 00:20:32,202 --> 00:20:37,615 something, but with what? So if you know anything about compression, you know that 265 00:20:37,615 --> 00:20:41,572 there's not a lot of options here really. It could be either a forward or backward 266 00:20:41,572 --> 00:20:46,499 pointer, it could be a dictionary of some sort, or it could be a sliding window. 267 00:20:46,499 --> 00:20:50,200 Now we can pretty easily confirm that it's not a forward/backward pointer just 268 00:20:50,200 --> 00:20:54,167 because we tried to follow the references in the file, we see nothing that should be 269 00:20:54,167 --> 00:20:58,922 there, same goes for dictionary. We can't find anything that's consistent enough to 270 00:20:58,922 --> 00:21:03,000 be a dictionary. So it leaves us only with with the option of a sliding window. 271 00:21:03,000 --> 00:21:08,366 Once we're equipped with this information, we go to our favorite place, to Google. 272 00:21:08,366 --> 00:21:12,821 And try to find some similar implementations to this. Luckily for us, 273 00:21:12,821 --> 00:21:18,797 in some very dark corner of the internet, we find this wiki page. It defines 274 00:21:18,797 --> 00:21:25,145 something called a Softdisk Library Format. I won't ask if someone knows what 275 00:21:25,145 --> 00:21:31,988 Softdisk is, because probably somebody knows here, it's CCC after all. But inside 276 00:21:31,988 --> 00:21:35,817 this thing it defines some kind of compression algorithm that looks very 277 00:21:35,817 --> 00:21:41,623 similar to ours. It looks actually really really like ours. Actually, it's exactly 278 00:21:41,623 --> 00:21:48,299 our compression algorithm. So yeah. That's nice. And I think the funny thing here is 279 00:21:48,299 --> 00:21:53,786 that this compression algorithm was used in the past somewhere, and only there. 280 00:21:53,786 --> 00:21:56,221 Can you guess where? 281 00:21:56,235 --> 00:21:58,612 *Waiting for response from the audience* 282 00:21:58,612 --> 00:22:03,820 Uh, yeah, somebody who didn't see *chuckles* this presentation before? 283 00:22:04,116 --> 00:22:06,661 Yeah! It was used in Commander Keen. 284 00:22:06,661 --> 00:22:09,230 Softdisk is the company who produced Commander Keen. 285 00:22:09,230 --> 00:22:12,181 So the compression algorithm from Commander Keen made its way, 286 00:22:12,181 --> 00:22:17,094 somehow, into the entire HP line of products. 287 00:22:17,094 --> 00:22:18,860 *Laughter* 288 00:22:18,860 --> 00:22:23,284 *Applause* 289 00:22:23,284 --> 00:22:27,577 How? I don't know! You can check if there was anybody who was fired from Softdisk 290 00:22:27,577 --> 00:22:32,062 and hired in HP. Probably that would be my guess. But we'll never know. 291 00:22:32,062 --> 00:22:36,757 So now we understand exactly what is this thing, and how does this compression work. 292 00:22:36,757 --> 00:22:40,687 We have the missing data that we need. And this data means that those two bytes are 293 00:22:40,687 --> 00:22:44,541 actually composed of window location and data length. And that's all we need, and 294 00:22:44,541 --> 00:22:48,404 let me show you, like really quickly, how this compression works. So we have an 295 00:22:48,404 --> 00:22:51,950 input text, output text and sliding window. We want to compress this string 296 00:22:51,950 --> 00:22:56,397 over here, and let's try and do it. So first byte is the bitmap, so we leave 297 00:22:56,397 --> 00:23:01,170 it empty for now. Then, second byte, we start with "A". So we place it both in the 298 00:23:01,170 --> 00:23:05,447 output text and in the sliding window. Then we go to "B", same thing. "C", same 299 00:23:05,447 --> 00:23:09,717 thing. "D", again, and now we get to "A". But "A" is already present in the sliding 300 00:23:09,717 --> 00:23:13,631 window, so we don't need to write it in the output text, we can just do 301 00:23:13,631 --> 00:23:19,183 nothing and then go to "B", same thing, it's just the following character in the 302 00:23:19,183 --> 00:23:23,735 sliding window, and then when we get to "E", we just write "00 02". That means 303 00:23:23,735 --> 00:23:28,636 "Go to the sliding window at position 0, and take the first two bytes". That's what 304 00:23:28,636 --> 00:23:33,420 it means. Then we continue to "E", "F", "G", after we did that, we input our 305 00:23:33,420 --> 00:23:38,490 bitmap here, and now we know the bitmap value and that's all there is to it. 306 00:23:38,490 --> 00:23:40,130 That's the compression algorithm. 307 00:23:40,130 --> 00:23:42,885 It's pretty easy looking at it this way, right? 308 00:23:42,885 --> 00:23:48,979 Looking at it in reverse is a bit more difficult, but yes, now we can do that. 309 00:23:48,979 --> 00:23:52,839 And now we completely open everything, and yes, we have our firmware, you can read 310 00:23:52,839 --> 00:23:56,321 everything. It's actual code. And now we need to understand: 311 00:23:56,321 --> 00:24:00,139 What does this code mean? And basically, first of all, we need to understand what 312 00:24:00,139 --> 00:24:03,984 architecture is this, what is the operating system and so on and so on. 313 00:24:03,984 --> 00:24:09,771 So it took us quite some time to do that. But let me give you a brief explanation. 314 00:24:09,771 --> 00:24:13,575 First of all, the operating system is called ThreadX. It's a real-time operating 315 00:24:13,575 --> 00:24:20,707 system. The CPU, the processor, is ARM9 big-endian, and then it has several 316 00:24:20,707 --> 00:24:25,039 components to it, like stuff that's related to system, some common libraries, 317 00:24:25,039 --> 00:24:31,936 and tasks. Tasks are the equivalent of processes in normal operating systems. 318 00:24:31,936 --> 00:24:37,129 In the system stuff we have boot loaders and some networking functionality and some 319 00:24:37,129 --> 00:24:43,356 other stuff, Common Libraries we have a lot of common libraries, and tasks, once 320 00:24:43,356 --> 00:24:46,811 we're able to isolate them, we can understand exactly the tasks, and once 321 00:24:46,811 --> 00:24:52,677 we do that, we now know that all we need to do is focus on these tasks, because 322 00:24:52,677 --> 00:24:55,230 they're the tasks relevant to fax protocols, 323 00:24:55,230 --> 00:24:56,940 we can leave everything else aside. 324 00:24:56,940 --> 00:25:01,807 It will make our work much more easy. We want to start doing that. But, 325 00:25:01,807 --> 00:25:07,704 just a second before we do that. Looking at this, we see something that looks not 326 00:25:07,704 --> 00:25:13,286 really… I don't know, it doesn't make sense a lot. This thing is Spidermonkey. 327 00:25:14,066 --> 00:25:18,818 Every HP printer contains a Spidermonkey library. I don't know if you know what 328 00:25:18,818 --> 00:25:22,724 Spidermonkey is, but basically it's the JavaScript implementation by Mozilla. 329 00:25:22,955 --> 00:25:26,275 It's used in Firefox for example. And we were thinking to ourselves: 330 00:25:26,275 --> 00:25:30,487 Why does a printer need to render JavaScript? It makes no sense. 331 00:25:30,487 --> 00:25:34,893 I mean yeah, it has a web server, but it's not a web client. We couldn't think of 332 00:25:34,893 --> 00:25:37,955 any situation in which a printer needs to render JavaScript. 333 00:25:37,955 --> 00:25:43,402 It looked really strange to us. So we decided to try and see where this printer 334 00:25:43,402 --> 00:25:49,365 is actually using JavaScript, so we went back a bit and checked and we found that 335 00:25:49,385 --> 00:25:53,949 JavaScript is used in a feature called PAC – Proxy Auto Configuration. 336 00:25:53,982 --> 00:26:04,612 It's pretty common, it's a good protocol. It defines proxies when you're doing DHCP 337 00:26:04,760 --> 00:26:09,716 or something like that. The thing is that the top layer functionality of this entire 338 00:26:09,716 --> 00:26:15,408 PAC functionality was written by HP. And when we were looking at that, we see 339 00:26:15,408 --> 00:26:20,424 all this functionality, and we see this strange thing here. The printer once it 340 00:26:20,424 --> 00:26:23,519 does this PAC functionality, it tries to connect to this domain: 341 00:26:23,519 --> 00:26:26,846 fakeurl1234.com. Just connect to it and do nothing with it. 342 00:26:26,846 --> 00:26:31,378 Some sort of sanity test I guess? I don't really know why. 343 00:26:31,378 --> 00:26:39,386 But the interesting thing here is: Do you know who owns the domain fakeurl1234.com? 344 00:26:39,386 --> 00:26:42,115 *Laughter mixed with murmur* 345 00:26:42,115 --> 00:26:42,908 No, it's not HP. 346 00:26:42,908 --> 00:26:44,731 *Murmur & responses from the audience* 347 00:26:44,734 --> 00:26:47,614 Ehh, Check Point is kinda… eh…, yeah. 348 00:26:48,886 --> 00:26:49,595 I own it. 349 00:26:50,087 --> 00:26:51,690 *Laughter* 350 00:26:51,690 --> 00:26:53,080 *Applause* 351 00:26:53,080 --> 00:26:58,290 It just wasn't registered. So, we registered it for 5 Dollars. 352 00:26:58,290 --> 00:27:02,115 And now every HP printer is connecting to my domain. *Chuckling* 353 00:27:02,336 --> 00:27:06,336 *Laughter* 354 00:27:06,496 --> 00:27:09,899 *Applause* 355 00:27:09,899 --> 00:27:13,319 So, if anybody wants to buy the domain, I have a very good price for you: 356 00:27:13,319 --> 00:27:14,560 More than 5 dollars. 357 00:27:14,560 --> 00:27:18,808 And now I'll hand it over to Eyal to continue. 358 00:27:19,363 --> 00:27:23,394 Eyal Itkin: Okay, thank you Yaniv. After we've finished messing around with 359 00:27:23,394 --> 00:27:27,378 Spidermonkey, it's time to focus back on fax, so T.30. 360 00:27:27,378 --> 00:27:31,706 T.30 – in its full name it's ITU-T recommendation T.30 – is a standard 361 00:27:31,706 --> 00:27:37,521 that defines the fax protocol. Actually it's a very very long PDF, more than 362 00:27:37,521 --> 00:27:42,025 300 pages. It defines all the phases and messages we need in order to send and 363 00:27:42,025 --> 00:27:48,131 receive a fax document. It was first defined very long ago, 1985, and was last 364 00:27:48,131 --> 00:27:53,377 updated more than a decade ago. So from our perspective that's a very good idea, 365 00:27:53,377 --> 00:27:59,504 because we want to find vulnerabilities in an old and complicated protocol. 366 00:27:59,504 --> 00:28:04,439 We're most probably going to find some. After we read through the standard we 367 00:28:04,439 --> 00:28:12,358 started to dynamically look at it, opened it in IDA and look up on the T.30 task. 368 00:28:12,358 --> 00:28:17,798 And you can see that the state machine is quite huge as you can see here in IDA, and 369 00:28:17,798 --> 00:28:22,984 actually that's a small state machine. Because most of the code blocks you can 370 00:28:22,984 --> 00:28:27,309 see over here contain additional state machines inside them. Meaning that this is 371 00:28:27,309 --> 00:28:31,894 going to be a very very huge and complicated state machine to reverse. 372 00:28:31,894 --> 00:28:36,594 And if that wasn't enough it turns out that HP really likes to use 373 00:28:36,594 --> 00:28:40,388 function pointers and global variables in their code. Meaning that statically 374 00:28:40,388 --> 00:28:47,336 reverse-engineering this huge task is going to be very complicated. Although I 375 00:28:47,336 --> 00:28:52,266 personally prefer to statically reverse-engineer, this time we had to 376 00:28:52,266 --> 00:28:56,783 choose a different tactic, we'll need to dynamically reverse-engineer this thing 377 00:28:56,783 --> 00:29:00,463 and for this we'll need to have a debugger. 378 00:29:00,463 --> 00:29:06,235 As Yaniv mentioned earlier, nobody knows how can we debug a printer. 379 00:29:06,235 --> 00:29:11,976 We already tried built-in JTAG and serial port and that failed. 380 00:29:11,976 --> 00:29:16,084 We then searched for a builtin GDB stub we could use, 381 00:29:16,084 --> 00:29:18,964 but I couldn't find any such stub. 382 00:29:18,964 --> 00:29:24,215 At this point it's very important to remember that even if we could control the 383 00:29:24,215 --> 00:29:29,432 execution flow, no-one can put a debugger without controlling the execution flow, 384 00:29:29,432 --> 00:29:34,760 and we can't do anything, it's a black box, I can send papers and that's it. 385 00:29:35,330 --> 00:29:40,948 And even if I could control the execution flow and load my debugger, the printer 386 00:29:40,948 --> 00:29:46,295 uses a hardware watchdog. And this is an external hardware mechanism that monitors 387 00:29:46,295 --> 00:29:51,566 the main CPU and whenever the main CPU enters an endless loop or it halts, 388 00:29:51,566 --> 00:29:59,140 the watchdog reboots the entire printer. This means that since essentially a 389 00:29:59,140 --> 00:30:02,904 breakpoint halts the program, 390 00:30:02,904 --> 00:30:06,239 whenever we hit a breakpoint, the watchdog will kill us. 391 00:30:06,239 --> 00:30:11,086 So we need to find a way around this thing, the easiest way we could find out 392 00:30:11,086 --> 00:30:16,780 was to split this enormous task into chunks, if we could find any code 393 00:30:16,780 --> 00:30:21,785 execution vulnerability, we could try to execute code over the printer and load our 394 00:30:21,785 --> 00:30:27,066 own debugger. And at this stage we had luck, and we believe that luck is an 395 00:30:27,066 --> 00:30:35,058 important part in every research project. On the 19th of July, SENRIO published a 396 00:30:35,058 --> 00:30:37,538 vulnerability called "Devil's Ivy". 397 00:30:37,694 --> 00:30:42,875 Devil's Ivy is a remote code execution in gSOAP and many embedded devices (and our 398 00:30:42,875 --> 00:30:47,334 printer included) tend to implement a web server for management and configuration, 399 00:30:47,334 --> 00:30:52,604 and in our case this web server uses gSOAP, and it even uses a vulnerable 400 00:30:52,604 --> 00:30:57,810 version of gSOAP, so we now have our vulnerability, and we'll need to exploit 401 00:30:57,810 --> 00:31:03,310 it. For those of you not familiar with Devil's Ivy, here is the code. 402 00:31:03,737 --> 00:31:05,495 And here is the vulnerability itself. 403 00:31:06,361 --> 00:31:10,629 Devil's Ivy is a signed integer underflow vulnerability, 404 00:31:10,629 --> 00:31:13,199 meaning that we'll need to send 405 00:31:13,199 --> 00:31:19,240 enough data for the variable to go from negative back to positive. And that means 406 00:31:19,240 --> 00:31:22,695 we need to send roughly 2 Gigabytes of data to the printer. 407 00:31:23,446 --> 00:31:26,870 So HP really prides itself on the printing speed of the printer, 408 00:31:26,870 --> 00:31:28,817 but not on the network speed. 409 00:31:30,355 --> 00:31:35,382 After many optimization rounds we managed to reduce the exploit time to roughly 410 00:31:35,382 --> 00:31:43,419 7 minutes. So you start the exploit, you wait, and after 7 minutes you have 411 00:31:43,419 --> 00:31:50,761 your exploit. And here our good luck ended, because we had a side effect in our 412 00:31:50,761 --> 00:31:57,216 exploit, and after two to ten minutes the printer will crash. And this means we will 413 00:31:57,216 --> 00:32:02,600 need to wait an additional 7 minutes, we'll have 2 minutes to debug it, 414 00:32:02,600 --> 00:32:08,518 and then it will crash again. So we waited a lot of 7 minutes in our research. 415 00:32:08,518 --> 00:32:10,539 *Laughter* 416 00:32:10,539 --> 00:32:15,793 If you recall, we wanted a debugger so we could dynamically reverse-engineer the 417 00:32:15,793 --> 00:32:20,240 firmware. We wanted read memory and write memory, and now we have a debugging 418 00:32:20,240 --> 00:32:25,179 vulnerability, so we can load a debugger, we need to execute this debugger, so 419 00:32:25,179 --> 00:32:28,930 we'll need executing permissions to load it. 420 00:32:28,930 --> 00:32:30,638 The most important thing is that we need 421 00:32:30,638 --> 00:32:35,391 to execute our debugger without crashing the firmware. Because we want the debugger 422 00:32:35,391 --> 00:32:41,159 to run and the firmware to debug and we want them to blend inside the 423 00:32:41,159 --> 00:32:44,808 virtual address space of the printer, living happily together. 424 00:32:44,808 --> 00:32:52,163 We couldn't find any debugger that achieve this goal, so I did what my mother usually 425 00:32:52,163 --> 00:32:56,597 tells me not to do, we actually wrote our own debugger. 426 00:32:58,089 --> 00:33:02,492 So this is Scout. Scout is an instruction based debugger that supports Intel CPUs 427 00:33:02,492 --> 00:33:07,309 and ARM CPUs, because we have an ARM printer. As a prototype we had a Linux 428 00:33:07,309 --> 00:33:11,489 kernel driver, and this time we're going to use it its embedded mode. 429 00:33:12,062 --> 00:33:15,672 In embedded mode we compile it to be fully positioned in the *unintelligible*, 430 00:33:15,672 --> 00:33:19,607 because we essentially throw it somewhere inside the firmware and expect it to 431 00:33:19,607 --> 00:33:25,230 execute. We pre-equip it with useful addresses like: 432 00:33:25,230 --> 00:33:29,339 memcpy, socket, bind, listen, we find using IDA. 433 00:33:29,339 --> 00:33:33,330 And whenever it tries to call these functions it goes to its 434 00:33:33,330 --> 00:33:35,827 own GAT, finds the address and 435 00:33:35,827 --> 00:33:38,292 jumps to it. 436 00:33:38,292 --> 00:33:45,137 After we compile it, we use it in our exploit, we jump into this blob, and it 437 00:33:45,137 --> 00:33:49,354 starts up a TCP server, we can now connect to to send instructions to 438 00:33:49,354 --> 00:33:52,651 read memory, to write memory, and whatever we want. 439 00:33:53,588 --> 00:33:59,219 You can find Scout in our GitHub, with the examples for Linux kernel driver and 440 00:33:59,219 --> 00:34:02,791 embedded mode. And we're actually using it for some CVEs now, 441 00:34:02,791 --> 00:34:06,913 so it's highly recommended. 442 00:34:06,913 --> 00:34:09,487 Now that we reach this point in our talk, 443 00:34:09,487 --> 00:34:14,813 we haven't yet described to you how a fax actually works, so with Scout we 444 00:34:14,813 --> 00:34:18,252 dynamically reverse-engineered the firmware, and now we can actually 445 00:34:18,252 --> 00:34:24,669 describe to you how a fax actually works. In order to send a fax, we need a sending 446 00:34:24,669 --> 00:34:29,688 machine, we need to send it to some modem, the packets from the modem will be 447 00:34:29,688 --> 00:34:35,266 processed in the CPU, and afterwards, the data is going to be processed and probably 448 00:34:35,266 --> 00:34:42,021 printed. Let's see how it starts. We start with network interaction, 449 00:34:42,021 --> 00:34:48,402 probing and ranging, equalizer and echo cancelling, more training, 450 00:34:48,402 --> 00:34:51,738 and you actually need to be quite familiar with these steps, 451 00:34:51,738 --> 00:34:53,314 because they sound like this: 452 00:34:53,314 --> 00:34:55,333 *repetitive fax modem sounds* 453 00:34:56,017 --> 00:35:01,298 With these beeps, we actually created an HDLC tunnel. Through this tunnel, we're 454 00:35:01,298 --> 00:35:07,882 going to send our T.30 messages, to the CPU. In T.30 you have phase A, 455 00:35:07,882 --> 00:35:12,784 in which we send the caller ID, which is a string. In phase B you negotiate the 456 00:35:12,784 --> 00:35:16,996 capabilities, so I send my capabilities and receive the printer's capabilities. 457 00:35:17,726 --> 00:35:21,730 Phase C is the important step because here we actually send our fax data, 458 00:35:21,730 --> 00:35:26,971 line after line, and page after page. And in phase D, we finish. I send an ACK, 459 00:35:26,971 --> 00:35:31,520 I receive an ACK, and that's it. Let us now see how a normal black/white 460 00:35:31,520 --> 00:35:36,161 fax document is going to be sent through the protocol. So we have our document, 461 00:35:36,161 --> 00:35:41,426 it's going to be sent over the HDLC tunnel using T.30 messages, over phase C, and the 462 00:35:41,426 --> 00:35:46,686 receive document is actually the body of a TIFF file compressed in G.3 or G.4 463 00:35:46,686 --> 00:35:52,370 compressions. From our perspective, that's partial good news, because there are 464 00:35:52,370 --> 00:35:56,867 many vulnerabilities when parsing TIFF headers, and we only control the data 465 00:35:56,867 --> 00:36:01,116 of the file. The headers themselves are going to be constructed by the printer 466 00:36:01,116 --> 00:36:03,899 itself, using messages from phase A and phase D. 467 00:36:03,899 --> 00:36:11,255 So, we partially control a TIFF file and after it's done and ready, the file 468 00:36:11,255 --> 00:36:17,143 is going to be printed. Like every good protocol – and here it becomes very 469 00:36:17,143 --> 00:36:22,785 interesting – T.30 many extensions. Can you guess what interesting extensions 470 00:36:22,785 --> 00:36:24,293 there are in the protocol? 471 00:36:27,510 --> 00:36:31,640 There's a security extension, but no-one uses it, the other extension… 472 00:36:31,750 --> 00:36:33,740 is.. 473 00:36:33,740 --> 00:36:34,597 Color Extension! 474 00:36:34,822 --> 00:36:36,955 Actually you can send colorful faxes and 475 00:36:36,955 --> 00:36:39,902 they really use it in hospitals for some reason 476 00:36:41,670 --> 00:36:44,362 Let's see how colorful fax works. 477 00:36:44,362 --> 00:36:47,440 We send a document through the HDLC tunnel, 478 00:36:47,440 --> 00:36:53,836 over phase C, and the received document is actually a JPEG file. This time we control 479 00:36:53,836 --> 00:36:58,587 the header and the data of the file, and we can do whatever we want to it, 480 00:36:58,587 --> 00:37:00,476 and send it for printing. 481 00:37:00,476 --> 00:37:02,806 Now that we know how a fax actually works, 482 00:37:02,806 --> 00:37:05,125 where should we look for vulnerabilities in it? 483 00:37:05,125 --> 00:37:10,036 Well, we have complicated state machines, withstand strings, there are 484 00:37:10,036 --> 00:37:13,518 several file layers, but the most convenient layer is the applicative one, 485 00:37:13,518 --> 00:37:17,452 and most importantly, JPEG, because we control the entire file. 486 00:37:18,461 --> 00:37:22,802 If we look at a JPEG file, it mainly consists of markers, we have a 487 00:37:22,802 --> 00:37:26,165 start marker, application marker with length and data, more markers with length 488 00:37:26,165 --> 00:37:29,367 and data, and so and and so on. 489 00:37:29,367 --> 00:37:35,504 If we zoom in on one such marker, we can see that in this marker we have a 490 00:37:35,504 --> 00:37:41,368 compression table, a 4x4 compression matrix for the exact document we send, we 491 00:37:41,368 --> 00:37:45,510 have a header, length field, 4x4 matrix, and the data itself. 492 00:37:46,383 --> 00:37:52,667 If you zoom in a bit deeper, we can see that here we get a matrix, we sum up all 493 00:37:52,667 --> 00:37:56,656 of the values. This matrix should be rather sparse, with zeroes, ones, 494 00:37:56,656 --> 00:38:00,183 and twos. The accumulated value is going to be our length field, 495 00:38:00,183 --> 00:38:04,882 in this case 6 bytes, and 6 bytes are going to be copied from the data to 496 00:38:04,882 --> 00:38:08,582 a local, small, stack buffer. Like this. 497 00:38:09,175 --> 00:38:12,969 So if you consider vulnerabilities, at this point we were like "What The Fax?!" 498 00:38:13,352 --> 00:38:18,078 because that doesn't make sense. We control the entire header. If you put huge 499 00:38:18,078 --> 00:38:23,503 values in our matrix, like so, we have a 4 kilobyte length field copied into 500 00:38:23,503 --> 00:38:29,232 a stack buffer of 256 bytes, effectively having a stack-based buffer overflow in 501 00:38:29,232 --> 00:38:30,909 our printer. 502 00:38:34,018 --> 00:38:38,020 It's a trivial stack buffer overflow, we have no byte constraints, we can use 503 00:38:38,040 --> 00:38:43,773 whatever we want, null bytes, non-ASCII bytes, whatever we want. And 4 kilobytes 504 00:38:43,773 --> 00:38:49,429 user-controlled data, that's more than enough to exploit. At this point we had to bypass 505 00:38:49,625 --> 00:38:53,946 several operating system security mitigations… Nah, not exactly. 506 00:38:53,946 --> 00:38:55,441 *Laughter* 507 00:38:55,441 --> 00:39:00,395 It's an …, fixed address spaces, no canaries, it's the eighties, it's really 508 00:39:00,395 --> 00:39:06,147 simple. We've got the CVEs from HP, 9.10 critical, you should really patch 509 00:39:06,147 --> 00:39:11,339 your printers now. And here you can see the response we have seen from HP after 510 00:39:11,339 --> 00:39:14,463 we've worked with them to patch these vulnerabilities, 511 00:39:14,463 --> 00:39:17,392 which is a good time for our demo! 512 00:39:20,505 --> 00:39:24,044 Yaniv Balmas: Unfortunately we couldn't really live-demo, so we just filmed 513 00:39:24,044 --> 00:39:27,530 something for you. So, this is our attacker machine, all you need to do is 514 00:39:27,530 --> 00:39:31,150 run this script, it's connected to a modem that we bought for like 10 dollars 515 00:39:31,150 --> 00:39:38,270 from Amazon. We're sending our malicious fax to this printer, and… yeah. 516 00:39:38,270 --> 00:39:42,554 Incoming call… from who? 517 00:39:45,000 --> 00:39:46,000 Wait just a second. 518 00:39:46,778 --> 00:39:49,459 Eyal Itkin: Faxes are slow. Yaniv Balmas: Yeah, they are. 519 00:39:49,996 --> 00:39:54,587 Yaniv Balmas: So, from an evil attacker of course, we forged this easily. And now, 520 00:39:54,587 --> 00:40:00,298 the printer is receiving the fax, and processing it, and now it's obviously a 521 00:40:00,298 --> 00:40:04,729 colorful fax, and now we have full control over the printer, so it's ours. 522 00:40:05,795 --> 00:40:09,654 But that's not enough! Because we want to show that we can propagate to another 523 00:40:09,654 --> 00:40:16,077 computer, so our malicious fax, contained EternalBlue in it, so once any computer is 524 00:40:16,077 --> 00:40:20,746 connected to the network, the fax now will recognize it, and will try to exploit it, 525 00:40:20,746 --> 00:40:22,672 and here you go! 526 00:40:22,893 --> 00:40:31,482 *Laughter & Applause* 527 00:40:31,743 --> 00:40:36,318 So yeah, we made it after all. It was a long way. 528 00:40:36,482 --> 00:40:40,645 Some conclusions we have to tell you: First, PSTN seems to still be 529 00:40:40,645 --> 00:40:45,487 a valid attack surface in 2018. Fax can be used as a gateway to internal networks, 530 00:40:45,487 --> 00:40:49,680 and old and outdated protocols… probably not so good for you, try not to use them 531 00:40:49,680 --> 00:40:54,260 if you can. What can you do to defend yourself against this catastrophy? 532 00:40:54,407 --> 00:40:57,953 A lot of things. First of all, you can patch your printers, as Eyal said, 533 00:40:57,953 --> 00:41:03,193 this link will just tell you if your printer is vulnerable, by the way, every 534 00:41:03,193 --> 00:41:08,497 HP Inkjet (or HP Officejet) printer is vulnerable to this thing, it's the biggest 535 00:41:08,497 --> 00:41:11,364 line of printers from HP, over – I think – 200 or … 536 00:41:11,364 --> 00:41:13,949 Eyal Itkin: 300 Yaniv Balmas: … 300 models are vulnerable 537 00:41:13,949 --> 00:41:19,447 to this thing, so really go and update! Another thing I could tell you is: 538 00:41:19,447 --> 00:41:25,282 If you don't need fax, don't use it. Also, if you do need to use fax after all, 539 00:41:25,282 --> 00:41:29,997 try and make sure your printer is segregated from the rest of the network, 540 00:41:29,997 --> 00:41:33,576 so even if somebody takes over the printer, he will just be confined to the 541 00:41:33,576 --> 00:41:38,988 printers, and won't be able to take over your entire network. These are really good 542 00:41:38,988 --> 00:41:41,565 suggestions, all of them, but really, 543 00:41:41,565 --> 00:41:43,864 the best suggestion I have to give you today is: 544 00:41:43,874 --> 00:41:46,373 Please! Stop using fax! 545 00:41:46,604 --> 00:41:47,923 *Laughter* 546 00:41:47,923 --> 00:41:52,112 *Applause* 547 00:41:52,775 --> 00:41:53,916 Thank you, thank you! 548 00:41:53,916 --> 00:41:59,569 And, just one second before we finish, this was a long way, a long journey. 549 00:41:59,569 --> 00:42:04,162 We had some very good friends that helped us a lot along the way, 550 00:42:04,162 --> 00:42:06,022 physically, mentally, technically, 551 00:42:06,022 --> 00:42:10,795 so we must mention them. These are the guys here. Some of them are 552 00:42:10,795 --> 00:42:13,837 in the crowd, so they deserve come claps. 553 00:42:13,998 --> 00:42:16,246 *applause* 554 00:42:16,246 --> 00:42:21,574 One special guy that helped us is Yannay Livneh, he also deserves this, and… 555 00:42:21,574 --> 00:42:25,997 … that's it basically, guys! So if you want to follow more of our work, 556 00:42:25,997 --> 00:42:30,386 you can find us here. Follow us. Thank you very much! 557 00:42:30,386 --> 00:42:41,670 *Applause* 558 00:42:41,670 --> 00:42:45,097 Herald Angel: Thank you very much. We have 5 minutes for Q&A. 559 00:42:45,097 --> 00:42:48,082 So please line up at the microphones. If you want to leave now, 560 00:42:48,082 --> 00:42:52,710 please do it to your right side, so this side. From the stage it's the left side, 561 00:42:52,710 --> 00:42:56,944 but for you it's the right side. So please line up at the microphones. 562 00:42:56,944 --> 00:43:05,679 I think I can see microphone 4 already, so we'll start with microphone 4. 563 00:43:06,780 --> 00:43:12,611 Question: First, thank you for this talk. It's scary to see that these can be 564 00:43:12,611 --> 00:43:18,762 exploited today. You talked about email-to-fax or fax-to-email services, 565 00:43:18,762 --> 00:43:26,371 and I wondered: Is it possible that there are vulnerabilities in those as well? 566 00:43:26,371 --> 00:43:33,615 I know Fritz!Box routers allow fax-to-email, could you attack those, 567 00:43:33,615 --> 00:43:34,561 possibly? 568 00:43:35,353 --> 00:43:39,995 Yaniv Balmas: So basically, those services use T.30 as well. We didn't look at them, 569 00:43:39,995 --> 00:43:44,360 frankly. We had so much work to do with the printer, that we didn't look at any 570 00:43:44,360 --> 00:43:50,793 other printers, or any other services. I can't say for sure, but if you're 571 00:43:50,793 --> 00:43:54,481 looking for vulnerabilities, I would recommend to go look there as well. 572 00:43:56,127 --> 00:43:58,194 Herald Angel: Great, microphone number 5 please. 573 00:43:59,395 --> 00:44:04,213 Question: What can you disclose about the data that's hitting your URL? 574 00:44:05,425 --> 00:44:06,252 Yaniv Balmas: The…? Uh! 575 00:44:06,473 --> 00:44:10,188 Question: What can you disclose about the machines that are knocking on your URL, 576 00:44:10,188 --> 00:44:12,652 the fakeurl1234. 577 00:44:13,056 --> 00:44:15,058 Yaniv Balmas: There are a lot of HP printers out there. 578 00:44:15,058 --> 00:44:17,243 *Laughter* 579 00:44:17,461 --> 00:44:23,277 That's all I can disclose. Sorry. 580 00:44:25,842 --> 00:44:27,626 Herald Angel: We have one question from the Signal Angel, please. 581 00:44:28,771 --> 00:44:33,295 Signal Angel: Did you try to activate JTAG by upgrading to a modified firmware? 582 00:44:33,295 --> 00:44:38,677 Eyal Itkin: We tried to use the JTAG, we think it's disabled from the factory 583 00:44:38,677 --> 00:44:45,014 lines, it was too much work. So we decided to use Devil's Ivy, it's a good 584 00:44:45,014 --> 00:44:50,305 vulnerability. Once we have Devil's Ivy and we can use Scout, Scout is more than 585 00:44:50,305 --> 00:44:51,412 enough for debugging. 586 00:44:52,503 --> 00:44:59,159 Essentially, after we used the JPEG vulnerability and we loaded up Scout, 587 00:44:59,159 --> 00:45:03,143 Scout survived for weeks on a printer without any crash. 588 00:45:03,693 --> 00:45:05,010 So that's more than enough. 589 00:45:06,735 --> 00:45:09,636 Herald Angel: Great, we'll go with microphone number 2 please. 590 00:45:09,636 --> 00:45:13,490 Question: Yes, thank you for the nice talk, and I think you're completely right 591 00:45:13,490 --> 00:45:19,048 you can have many problems with legacy protocols, the only thing I do not really 592 00:45:19,048 --> 00:45:25,526 get was the part how you then can automatically successfully attack your 593 00:45:25,526 --> 00:45:31,577 laptop on the network. My point would be: My laptop is as secured as I'm going to 594 00:45:31,577 --> 00:45:35,768 the internet cafe or something else, so you would not be able – with your HP 595 00:45:35,768 --> 00:45:40,228 printer – to start the calculator on my Linux or even on my Windows. 596 00:45:41,502 --> 00:45:46,891 Yaniv Balmas: Your laptop might be secure, I'm sure it is, but many others are not. 597 00:45:46,891 --> 00:45:52,440 We tried to show it using the EternalBlue exploit, as you know, WannaCry, stuff like 598 00:45:52,440 --> 00:45:56,183 that. This thing created a lot of… – and there were patches out there – 599 00:45:56,183 --> 00:46:01,840 …and still it was… So… we're not here to attack anyone. We're just saying that 600 00:46:01,840 --> 00:46:05,186 theoretically, if somebody wants to get into the network and he has a 601 00:46:05,186 --> 00:46:08,894 vulnerability that you have may have not patched or secured, fax would be a bad 602 00:46:08,894 --> 00:46:10,134 idea to have. 603 00:46:10,834 --> 00:46:14,442 Question: But it was nothing which was part of the printer… 604 00:46:14,442 --> 00:46:20,551 Herald Angel: Sorry, unfortunately we do not have more time for Q&A, so thank you 605 00:46:20,551 --> 00:46:22,748 again very much. 606 00:46:22,994 --> 00:46:24,192 Yaniv Balmas: Thank you! 607 00:46:24,513 --> 00:46:32,694 *Applause* 608 00:46:32,694 --> 00:46:36,764 *Music* 609 00:46:36,764 --> 00:46:55,000 subtitles created by c3subtitles.de in the year 2019. Join, and help us!