 Hello everyone. Thanks for coming to our talk. What the facts? Um, let's do some 1980s hacking party. Um, yeah. So, um, my name is Yaniv Balmas and here is Yael Itkin. We are both security researchers, work for checkpoint research and let's begin with a brief history of facts. Um, so it was, it all started in 1846 when a scientist named Alexander Bain invented, uh, sent the first image of a wire and just a fun fact, this happened around 20 years before the invention of the light bulb. Um, and then facts evolved a bit and came to be these machines. Again, just before the invention of the telephone, uh, radio fakes, facts came to be. And then in 1966, uh, a small company called Xerox, uh, invented the first commercial fax machines and really changed the way we send electronic documents from one to each other. Um, and then throughout the years there was few standards for fax but at 1980 the last and most recent standards for fax came to be, uh, by an organization called ITU and namely the protocols are T30, T4, T6. Those are practically the same protocols we still use today when we send fax. Um, and now, you know, this was in the past but what's happening today? I mean, let's compare, we have better, uh, ways to send electronic documents we want to, to other, right? Uh, let's compare fax to just one of them, um, let's say email, right? So, if we compare fax to email and just to remind you we are comparing this to this, right? Um, so in terms of quality, you've just saw the pictures, you know, I have nothing to add. Uh, in terms of accessibility, I'm pretty sure most or all of you have 24 by 7 access to emails, right? I'm not so sure you're carrying around your fax machines with you. Um, in terms of reliability, so when you send an email it gets received but you know, when you send the fax it might get accidentally shredded, the dog might, might eat it or, you know, you can, you can never know if it, if it got to its destination. And in terms of authenticity, well, we can argue about email whether or not it's authenticated but we do have extensions like public key cryptography. What we don't have is we, we have nothing for fax, simply no authentication at all. Um, so, yeah. Um, look at this table, you might think, okay, so it's 2018, who is using fax? Probably nobody is using, right? Um, wrong. Uh, fax is pretty much live and kicking still. Um, it's being used all over the place. Ships, uh, Maritime use it to receive those critical maps, uh, in open seas. According to Wikipedia, uh, 90% of the Japanese population use fax. Well, they really like fax over there but, uh, I don't know why, but they are Japanese, so. Um, and if you do a lot of, uh, Google combos like, you know, contact us and fax, you'll find over 300 million fax numbers published on Google and that's just the published numbers. Think about how many fax machines, uh, don't have published numbers out there. So it's simply a huge amount of fax numbers and fax machines out there today. And the thing is that it's not only how many fax machines are out there but it's also who uses fax. Well, if you're a small corporate or a huge corporate, you have a fax number. You don't necessarily receive faxes over this, uh, number but you do have a fax number and it's published out there. If you're a bank, they love faxes in banks, right? So this is Bank of China, the biggest bank in the world with over 3.62 trillion dollars in assets and that's their fax number and maybe most importantly, government, uh, offices use fax. Um, if you ever wanted to fax, uh, our beloved Donald Trump, this is his fax number, we just Google it, it's there. Um, so the thing is that sometimes those banks and healthcare and government agencies, they don't only allow you to send fax but it's actually mandatory to send fax. You can either use postal mail or fax to send them information. It's a good thing that they took, uh, mail pigeons out of it but you know, um, so yeah, it's a thing and when you're thinking about it, well, you're thinking probably, what the fax? I mean, it's 2018, we should evolve to better ways of electronic document delivery, right? Um, and now, see, this is how fax looks like today. Well, it's no longer this standalone fax machines that we used to have 20 or 30 years ago, right? Today, fax is embedded, these old protocols are embedded within newer technologies. We have fax to email services, as I said, we have fax of a radio and fax of a satellite and we have, I think most commonly, these all-in-one printers. They have a lot of things, right? And they come, uh, pre-equipped with fax, uh, functionality in them. And now, let's take a look at these all-in-one printers for a second. Um, and if you think of it from a security point of view, uh, they are just black boxes, right? And those black boxes has interfaces. Uh, on one side, uh, they have interfaces like Wi-Fi, USB, Bluetooth, Internet, stuff like that. Those interfaces connect us to the internal network or to the external network or basically, they connect us to the world, right? And on the other hand, we have interfaces for, uh, connecting fax to the phone line and those interfaces connect us, well, to the 1970s, uh, something like that. Um, and now, this sounded interesting to us and we thought, okay, let's imagine this nice attack scenario, right? If you consider that those all-in-one printers are, at the end of the day, nothing but computers, right? They have memory, they have CPU, they are just big computers. Uh, what happens if an attacker, uh, with access to the telephone line and equipped only with its victim's phone number will be able to attack this printer just through the telephone line and exploit the printer and then take full control of it, right? In this scenario, it can then propagate from the printer through any one of the other interfaces, let's say the Internet to the internal network, right? Effectively creating a bridge between the internal network and the external network using the telephone. That's 1980s again, right? Uh, so we thought that's a really cool concept and we went on and began the research for that. And after we got excited, we sat down and talked about the challenges that we have and it seemed like we have, well, quite a few challenges, uh, uh, in front of us and they're really not simple. So let's just name a few of those challenges. Um, for example, how do we obtain the firmware, the code for this printer? Um, uh, how do we analyze the firmware once we got it? Uh, what operating system does this huge monsters are using? Um, how can we debug this thing? We have no idea. Um, how does fax even work? We just know the beeping sounds, but we have no idea how fax works. And then after we understand all that, we need to understand where should we look for vulnerabilities inside this big, big, big ecosystem? Um, so today we're gonna try and take you through these questions one by one until we'll be able to exploit this printer right here on the table. Uh, so let's begin with how do we obtain the firmware for a printer? Um, so this is our printer. I can tell you a lot of things about why we chose this printer, but basically it's the cheapest one. Uh, so yeah, we could afford to brick like four or five of those doing the research. Uh, so that was fun. Um, actually we have a lot of ink and it's really expensive, so if you want some ink, we'll be able, we'll be happy to share. Um, so we need to break fax, right? But just a minute before we break fax, uh, we need to break the printer. And I mean literally break the printer. Um, that was the fun part of the research. We broke everything up and tried to look inside and see what is this thing even built from. Um, and this is basically the brain of the printer. That's how it looks like in the inside, from the inside. Um, let's go through the major components of this PCB. So it has a flesh rom, manufactured by expansion, uh, and then some more memory. And looking at it, it looks a bit like some components are missing, right? Uh, that's mainly because the PCB has two sides. Um, so on the other side is most, the most interesting, uh, stuff like USB, Wi-Fi, electricity, SRAM, this huge battery that's used for something. Um, and then two very interesting components. One is the main CPU. Um, that's a Marvel CPU and it's manufactured uh, specifically for HP. By the way, I didn't mention that we chose HP and not because we dislike HP, but they're just the biggest vendor. They have around 40% of the market share. So, uh, they look like a good target. Um, and then another component is this component. And this is a fax modem. It's a CSP 1040. And we, uh, basically want to focus our research on those two components and understand how do they work and what is the relation between them. Um, so as I said, one of the first challenges will be to obtain the firmware of this printer. So we're taking a closer look at this PCB and we find these two very interesting, very interesting, um, uh, things in here. Like, it's serial debug and a JTAG. It's clearly marked on the PCB. So we say, okay, that's gonna be really easy. If you're not familiar with them, they are just interfaces that will let you debug the, the, the, the, the printer, the, the CPU, uh, read and write memory. So, uh, that's basically all we need to obtain the firmware. Unfortunately for us, uh, the JTAG is completely disabled. We can't access it. And the serial, well, we were able to, uh, access the serial and get this terminal. But almost every command we try to write would give us this strange message that I don't understand. Well, we don't understand either. Um, so, uh, it seems like we're not gonna go anywhere from here. We need to find an alternate path to get the firmware. Um, we looked a bit around and it turns out that, actually luckily for us, HP has this site online, an FTP site. And this site contains each and every firmware version for every HP product ever produced in history. Uh, that's a huge FTP site. It actually took us about two weeks to find our firmware within this mess of uh, of firmware's. Uh, but yeah, finally we were able to find this firmware. Now we have our firmware file. Yeah, we can start working. Uh, but then, uh, we asked ourselves, wait, how do you even upgrade a printer firmware? Have you ever done that? I haven't. Um, so we have this file. We need to understand how to do that. And the answer to this question is surprisingly simple. Well, you just print it. Um, yeah. You see, uh, HP defined this, uh, uh, standard protocol PCL, XL feature reference protocol class 2.1 supplement. That if you are still sane after reading this thing, you understand that the printer receives a, a firmware upgrade just the same way as it receives, uh, print job, a normal print job. Um, that's nice. Um, so cool. And if we look at the file that we got from this FTP site, uh, this actually correlates pretty well because you see it says PJL. It stands for print job language. Um, so now that we know that, we just need to decode this firmware. Uh, we're not going to take you to the process of decoding this thing. I'll just give you the highlights. Uh, this thing is composed of a few, uh, decoding decoders, like serial, uh, serially, uh, aligned decoders. Uh, like null decoder, tiff decoder, delta row decoder. Uh, there's a lot I can say about them, but they do something like, you know, if the previous line was all spaces, then if this line is also old spaces, just write one instead of the line, so you will save some space. Now, this makes a lot of sense if you're talking about a print job because you're expecting to see a lot of empty lines in the, in there, but when you're talking about binary file, it makes absolutely no sense to, to, to encode it this way. And to that we have to say, well, if you're a hammer, everything looks like a nail. And if you're a printer, everything looks like a print job. Um, and okay, we were finally able to decode this thing and we got ourselves what seems to be the firmware file. And now we can finally start working. Uh, but how do we analyze this file? Uh, so we start looking at this file and right in the beginning of it, we see something that looks like a table. So we're able to parse this thing and to understand that it is a table and this actually is a section table. So it means that the big file that we have is actually composed of sections. And this table actually tells us stuff like the loading address for each section. Um, sorry. Um, the section name and the location in binary and this basically enables us to break this big file into small sections and now we can inspect each and every section. Specifically there's one really big section in there that we're really interested in because it looks to be our actual firmware and we start to look at it. Uh, and when we look at it, we see this. Uh, this looks promising, but something is not right. Um, look at this. This is the part of the section. It clearly says error, I don't understand. This is the same error message we got from the serial port. So yeah, yeah, that's probably the code that we're looking for, right? Uh, but, but it's not exactly there. Something is missing. You see, we can understand it's error, I don't understand, but something is missing, some bytes are missing and those bytes are consistently, consistently missing from the entire file. So although we know we are there, we still can't analyze this thing until we will be able to fill those missing bytes. Um, and now we are trying to understand what is this thing. Um, there are a lot of options. All of them are crazy, but the least craziest option, uh, is to understand that this thing is another form of compression. Uh, because yeah, it's just, it has to be, there's no other option. Uh, it's a really bad compression because when we try to compress this thing with Zilib for, for example, we get 80% better compression and the thing is that we know that we have Zilib in the printer because we see the strings to it. So why would we use this compression? I don't know, but it must be a compression. And now let's try to analyze this thing together here. Um, so this is one of the snippets I've just showed you before and let's try to analyze it. Basically, it's composed of two parts. One part is ASCII characters, stuff that we can read, right? And the other part is non-ASCII characters, stuff that we can't read. Those non-ASCII characters are actually the missing bytes that we have. And we need to understand how to, you know, uh, understand what they are. So what we do is just take this, uh, byte view, right? And take all the ASCII characters out of it. And now we are left with, with our missing bytes, right? Um, now if you stare this long enough, you will start seeing a pattern. Um, and let me help you a bit with this because, you see, this thing is composed of single bytes and double bytes, right? And the distance between the single bytes looks suspiciously pattern-ish, I would say, like eight bytes, nine bytes, nine bytes, eight bytes. And now try to look at this for a second from a different perspective. So from this perspective, the pattern starts seeing, uh, being more clear, right? Because you see the F7 and F7, they look the same, the FF and FF, they look the same. But what does it mean? Uh, well, to understand that, you need to sharpen your binary view for a second. And if you understand that FF, for example, is just eight one bits, right? Uh, and if you do this consistently for every chunk that you have here, you will see the pattern. And the pattern is that the zero bit always falls within this two bytes whole. And that practically means that the first byte is just a bitmap describing the next, the following eight bytes. So this is all nine byte chunks and the first byte is just a map of the, of the following eight bytes. That's amazing. So now we understand what this one byte, one byte are, and all we need to do is to understand this two bytes, what are those two bytes? And they must be replaced for some characters, but what are they replaced for? Um, that's a big question. It took us some time to, to, to understand that. And if you know anything about compression, you know that you don't have a lot of options here. It can either be a forward or backward pointer. It could be some kind of dictionary or it could be a sliding window. Now we could pretty easily say that it's not a forward and backward pointer and it's also not a dictionary because we try to find references with, with, uh, from within our file and we can't. So the only valid option will be that this thing is a sliding window, right? And equipped with this information, we go to our favorite place to Google. Um, and in some dark corner of the internet, we find this wiki, strange wiki page, uh, defining something called a soft disk library format. And this thing within it has a compression algorithm that looks really familiar and it looks really like ours. I mean, really, really like ours. I mean, it looks exactly like our compression, exactly the same thing. Uh, we find it really funny and the thing is that this thing, anybody knows what soft disk is? Uh, so it turns out that this compression algorithm was invented by soft disk. Uh, and it was used once in history, once in the past. Uh, you will never guess where, um, that's because it was used in Commander Kinn. Yeah. Now, how did this make its way into an HP printer? I have no idea. But it did. Uh, so if you want to follow up on that field free, um, and now, uh, once we have, we're equipped with this information, we actually know what those two bytes are. I mean, they are just composed of, you know, this, this, uh, bitmap which, uh, stands for two values, a window location and a data length. And that's basically all the information we, we required in order to open this thing. Let me show you how it works. So we have an input text, an output text, and a sliding window. And let's try to compress this string here, A, B, C, D, E, F, G. Uh, so what we do is the first byte, as I said, is a bitmap. So we just leave it open for now. We don't know what the value will be. And we start working. So A, we write it both in the output text and the sliding window, same for B, C, D, and then we get to A. A is already present in the sliding window. So we don't need to write it in the output text. And then B, again, is just following A. And then when we eat E, we just write zero, zero, zero two. That means go to the sliding window at position zero and take the first two bytes. That's, that's the replacement that we were looking for, right? And then we continue E, F, G. And once we have that, we can just put our bitmap here, see that the, the replacement was at this position and we, we have our bitmap. That's pretty easy. Looking at that way, of course. So when you're doing it in, in reverse, it's kind of a bit more tricky. Um, but with this, we were able to open the firmware file. And now we have a full firmware file that we can finally, finally analyze. Um, and now that we have that, we need to understand what operating system is this monster using? Um, well, we spent quite a few time on that, but let me give you a brief explanation. So basically this thing, uh, as a operating system called TREDX. It's a real time operating system and the CPU is running on his arm line big in the end. Um, something really sexy. Um, and then there's some system and stuff here, some common libraries a little loaded and tasks, which are the rough equivalent of processes in normal operating systems. Um, now the, for system we have two stage bootloader and some networking functionalities and some other stuff. Uh, we have a lot of common libraries, just common libraries. And then we have tasks. And once we have this picture in mind, we know that we have to focus on this specific tasks because this is what we're looking for. T30, fax log, T modem, all the rest we can pretty much put aside, right? Uh, so we need to start analyzing them. But just a second before we do that, we notice something that looks fishy. Um, you see, this thing has a spider monkey library. Now if you're not familiar with this, spider monkey is the Mozilla implementation of JavaScript. It's used in Firefox. And we were thinking to ourselves, why would a printer use JavaScript? It makes absolutely no sense. Uh, and we were intrigued by this question. So we tried looking at where does this thing implement JavaScript. And it turns out that the answer is simple. It uses that in a feature called pack, P-A-C. Uh, this stands for Proxy Auto Configuration. It uses JavaScript in order to auto configure proxy. It's a pretty, pretty common thing. Um, and the thing is that the top layer functionality of this thing was written by HP. And when we're looking at this top layer functionality, um, we see this. This thing, before it does the pack, uh, functionality, it con- it contacts this URL, fakeurl1234.com. It does nothing with it. It just, it just contacts to it. And, and that's it. Like some sort of sanity test, maybe, I don't know. Uh, but the interesting thing is, does anybody know who owns the domain, fakeurl1234.com? Any guesses? How did you know? Yes, it wasn't registered. So we just registered this domain. So if anybody is interested in a domain, um, please contact me. I have a very good price, uh, for this domain. Uh, basically every HP printer in the world now con- connects to my domain. So, uh, that's really nice. Um, and now after we've done all that, we need to actually start looking at facts. And for that, I will hand it over to Eyal. So, so, thank you Yannir. Um, after we finish messing around with SpiderMonkey, we can actually focus on T30. T30 is a standard to find the fax protocol. It's called ITU, T- Recommendation T30. It's in its full name. The standard to find the procedures and phrases and messages. Needed in order to send it to see the fax document. It's actually a huge standard. It has a PDF. We've over 300 pages. Um, we read through it all. And it's complicated. And the standard itself was first designed on 1985. And it was last updated more than a decade ago. So from our perspective, it was like, it's an old standard. It's complicated. We're going to find vulnerabilities in it. While we read through the standard, we started to reverse engineer the T30 state machine in the firmware. And you can look to see how it looks like. Don't let this graph view fool you. As most of the code blocks you see over there contains additional state machines inside them. And this means we're going to have a pretty rough job reversing it. As this, that wasn't enough. It turns out that the firmware heavily relies on function pointers and global variables. And it's going to be a real mess to statically reverse engineering this thing. So we decided to change tactics. We are going to use dynamic reverse engineering. We'll need a debugger. So how can you debug a printer? Uh, we can't connect to it. Um, you know you've already said that we tried to connect to the JTAG and the serial port. But that worked very helpful. We then tried to look for a built in GDB stuff we could connect to. But we couldn't find one either. At this point we should remember that I can't simply load a debugger. Because we don't have any control over the execution flow. And even if we could load a debugger, the printer uses a harder watchdog. As soon as the CPU will halt or enter another slope, the watchdog will trigger a reboot. And a breakpoint usually halts the program. So we can't simply hit breakpoints without the watchdog kicking us out. At this point we decided to split it parts. If we could find a code execution vulnerability, we could try to exploit it and load our own debugger. Um, at this point we had a stroke of luck. Actually we believe that luck is an important part of every research project and we sure had our stroke of luck. On the 19th of July, Sanrio published a vulnerability called Devil's Ivy. Devil's Ivy is actually a remote code execution vulnerability in the GSO open source library. Embedded devices and our printer included tend to implement a embedded web server inside them so you could manage and configure your embedded device. In our case the printer uses GSO in its web server. After we dug in a bit deeper we saw that we had a jackpot. Our printer is vulnerable to Devil's Ivy and we now have how I debug vulnerability. So for those of you who are not familiar with Devil's Ivy, this is a relevant piece of code and here is the vulnerability itself. The bad part about this vulnerability is that it's assigned integer under flow. And this means we need to send roughly 2 gigabytes of data in order to exploit it. Uh, I don't know if you're familiar with the data rates of printers. However, printers are pretty slow. So after many optimization rounds we were planning to reduce the transmission time to roughly 7 minutes. So Eat Successful Exploit took us 7 minutes. And this practically signals the end of our stoke of luck because our exploit had several side effects on top of them. So after Eat Successful Exploit we're going to have a grace period of 3 to 10 minutes and then the printer crashes. So we waited a lot of 7 minutes in our research. Um, but at least we have an ex- uh, vulnerability. We can try to use it for debugging. It's better than nothing. So we had pretty much, uh, we had several debugging challenges. Uh, so we need to focus up. Originally we wanted to read RAM and write RAM so we could dynamically reverse engineer the T30 state machine. So now we have a control of the execution flow. We can use Devil's Ivy. We can try to exploit it in order to load a debugger for own. Once loaded we'll need to tell the MPU that our debugger is worthy of execution so we get its privileges. Um, and when we start de- uh, executing our debugger we need to actually install it and blend it inside the firmware address space because we want to connect to this debugger and it will, you don't want it to crash the printer. So it should natively blend inside the firmware address space. We couldn't find any known debugger. We know that does it and my brother always tells me to stop reinventing the wheel and is correct because wheels are not very useful so we reinvented the debugger instead. So meet Scout. Scout is an instruction-based debugger that we've developed. It currently supports Intel CPUs as well as ARM and in fact it even supports ARM thumb mode. I don't really like this mode but that's what the printer uses so you get it as a bonus. Um, on our previous research we used actually a prototype version of Scout in a Linux kernel environment in which we loaded Scout as a Linux kernel driver to debug RPE. This time over we used Scout in its embedded environment. In this environment we use Scout with a fully positioned independent compilation. It actually uses its own global of the table when it tries to locate and execute functions from the firmware itself. All you have to do in order to use Scout is to compile it and supply it with the addresses in the firmware of user firmware functions such as socket, bind, mem copy or even sleep. Once compiled you throw the compiled binary somewhere inside the outer space of your target and you have it. Once executed Scout will create a network server and wait for instruction because it's an instruction-based debugger. By remotely connecting to the newly created network server we can now issue instructions to read RAM, write RAM or any other extension you wish to implement. It's extendable. In checkpoint research we believe in sharing with the community so we can find Scout in our GitHub account. It includes an embedded environment, tutorials and even the Linux kernel driver we used for previous research. At this point on the topic we covered many different subjects but we haven't covered yet the most important thing, how fax actually works. Using Scout we were able to dynamically reverse engineer the firmware so let us now tell you how fax actually works. In order to set a fax I need a fax machine. It's going to be sent to the receiver's modem. The modem will transfer packets to the CPU which handle the T30 state machine and later on the data will be handled for processing and printing. When we start interacting between both of the modems we have network interaction, we have probing and ranging, we have our equalizer and echo counselor and we have additional trainings. You should be quite familiar with these four phases. They actually sound like this. What we actually done was to create an HDLC tunnel. Using this HDLC tunnel we are able now to send our T30 packets as HDLC data grams from our fax machine to the receiver fax machine. T30 itself has many phases of its own. On phase A we send our caller ID, it's 20 bytes, a string, we can send whatever we want. On phase B we negotiate our capabilities. And phase C is the most important phase of them all because here we actually send the data itself. So our document is going to be sent line by line, page by page until it's finally received. And on phase D we finish. We send acts, we receive acts and that's it. So let us now see how a normal black and white fax document is going to be sent through this protocol. So here's our document. It's will go through the HDLC tunnel, the data will be transferred using phase C and the received result looks like this. We actually send the data of a TIF file format, a compressed in G3 or G4 compression layers. And if you think that something here is missing, then you're correct. We can't control the headers of the TIF file. The printer actually builds them itself using data we negotiated on phase A and phase B. So from an attacker's perspective these are partially bad news. There are many vulnerabilities and TIF parsers however they usually require us to control the header. This time we only control the data itself so we're a bit limited. And after we finish building up and processing the TIF file it's going to be sent for printing you know because that's what normal people do with fax documents. And here where it becomes really interesting because we figured out that T30 had several extensions for it and one of the extensions can you guess? Well the extension is color extension. I didn't know that faxes can be colorful but it's a thing. So let's see how a colorful fax is going to be sent. We have here our fax document which will travel through the HDLC tunnel using phase C of the T30 protocol and the received result will be a JPEG file. This time we control the entire JPEG file, its headers and data because a colorful fax is in fact a fully functional JPEG file. So we received a T file with a black and white fax and a JPEG file with a colorful fax. Both will be sent for printing. Now that we finally understood how fax even works where we should look for vulnerabilities in it. So all of the layers we showed earlier can contain vulnerabilities. We have complicated state machines, we exchange strings, several decompression layers and we have two different file formats we need to parse. We decided that the most convenient layer of them all will be the application one and more specifically the JPEG parser because we can fully control the entire JPEG file so we have a much better attack service. Let us now see how JPEG file actually looks like. So this is JPEG file, it stands for, it defines a colorful image and the most important thing is that JPEG consists of markers. You have a start marker, after which you have an additional marker with its opcode, length field and data, after which you have a marker with its opcode, length and data and so on and so on and you finish with a marker. Now we know how JPEG file actually looks like, let's zoom in on one such marker. Our specific marker is going to present compression table. We define a 4x4 compression matrix to efficiently compress our specific document. In T files you use other tables and they were designed and fixed and JPEG files you can use your own compression table for a specific image. The marker itself looks like this, you have our opcode, length field, the 4x4 matrix and our data. If you zoom in a bit deeper we can see that the values of our 4x4 matrix are going to be accumulated together. The matrix is supposed to be really sparse as you can see over there, most of the zeros, some 1's, some 2's. The accumulated value is going to be the length field for the data inside the marker. In this case we have our data is 6, so we're going to have 6 data bytes. The data bytes themselves are going to be copied into a smaller way located on the stack. So let's sum it up a bit. We're going to sum all of the values in our 4x4 matrix. The length field will be 6 in this case and 6 bytes are going to be copied into our local stack buffer. As so. At this point we're like with effects because what will happen if we'll use large values inside our matrix, we have 16 bytes in our 4x4 matrix and we're going to sum them all up to roughly 4 kilobytes and 4 kilobytes of data are going to be copied into a small stack buffer of size 256 bytes. So that's bad news for the firmware. We have an overflow. Now that we found our vulnerability, it's a trivial stack based buffer overflow, let us see if we have any sort of constraints. Because we simply copied data from our file to the stack buffer, we'll have no constraints or forbidden bytes. We can use null bytes, non-asky bytes, whatever bytes you choose. We can use up to 4 kilobytes of data and we can control the length. So we actually used in our exploit roughly 2k, so it's controllable. And since we actually sent a large jpeg file, we can embed inside it much more data to be used later. So we can use roughly 4k for exploit and our exploit can load enormous amount of data from the fax itself so we can continue on. At this point we have our vulnerability. Let us now see what bypass we should use for operating system security mitigations. Nah, not really, because it's a real time operating system. All of the addresses are fixed with no stack anaries. All of the tasks share the same address space. We're running the highest of privileges, so it's an AIDs party. And it couldn't be easier. Once we found the vulnerability, we contacted HP and we started a responsible disclosure process. We actually flew over there to HP's campus to help them. We demonstrated a vulnerability and we helped them patch it. It was quite interesting because at first we were told to fly to Portland and there are no HP offices in Portland. So we talked to them a bit more and they told you need I should fly to Vancouver and we were like Vancouver in Canada. So I flew to Portland and I drove to Vancouver, Washington and we helped them fix it. And if you were to the black hat, I was the black hat on first time this year, you couldn't miss a huge booth of HP using the wolf or the fixer this year. So you probably know that HP really cares about the security of its product. So we got an official CVEs from HP here, the two CVEs. They're both rated as critical with a CVS score of 9.8 out of 10, so that's quite rare. Maybe even familiar with these two CVEs because they got several media attention in the past week. So here's the official response from HP. When HP learned of the issue they worked quickly to provide updates to mitigate risks. HP takes security seriously and encourages customers to keep the systems updated to protect against potential vulnerabilities. And once we finish this, this is a good time for our live demo. Okay, thank you. So we don't, we don't have a lot of time. Let's see this thing in action. So we brought you here printer. Defconn could supply us with phone lines. So we just brought our own phone thing. And then we have the attacker laptop over there. And we're sending our fax now. Yeah, it will answer in two rings. Take a look at the LCD screen of the, of the printer. Receiving fax from malicious attacker if, if you can read it. So if you see these fax run away. And should be here now. Yeah, fax is a little slow. Sorry for that. Yeah, fax received. Now the JPEG parsing is going on. And basically we have control of the printer. So this is our logo and that means the printer is ours. Thank you, thank you. But, but we have, we have, we have something else because now that we have control of the printer it's not enough. We want to show that we can propagate from the printer to the rest of the network. And basically what we did is to embed eternal blue, the leaked NSA exploit within our fax. And now this printer, once it, once it identifies any connected computer you just try to exploit it. And here A.L. connects. If you look at the laptop for a second. Then you will see a calc popping. So we did it. It was a long research let me tell you. But it was successful. We think that this is groundbreaking. I hope you feel the same. And now let's sum up with some conclusions. If you switch back to the presentation. Yeah, thank you. So conclusions. Well PSTN is still a valid attack surface even in 2018. Fax can be used as a gateway to internal networks. And another thing is that all, and outdated protocols are probably bad for you. So keep an eye for them. And now probably you're asking yourselves what can you do? Well you can do some stuff. You can patch your printers. As we said, HP published patches for these specific vulnerabilities. You can find them in this URL here. And instructions from HP to identify. By the way this works for any HP office jet printer. Like 80 or 100 models of them. So make sure you are patched. Another thing is don't connect fax. If you don't need it right. And if you do need to connect fax then make sure to segregate your printers so they won't be connected to the rest of the network. So if somebody manages to take over your printers at least the risk will be contained within the printer and you won't be able to propagate to the rest of the network. Now these are all really good suggestions. But really the best suggestions I have to give you today is please stop using fax. And now we really couldn't do a lot of this research if it wasn't for our wonderful friends. So they helped us physically, technically and mentally throughout the entire process of this research. So they deserve some, some clapping. Thank you. Thank them. And one specific guy, Yanai, also helped us a lot in the, in the fumer thing. And that's practically it. So thank you very much. And if you want to follow us, please follow us on Twitter. Read our stuff on the, on our blog. And thank you very much for coming to this talk.