printer research, okay? Thanks also to Tesco for giving us this great opportunity. Okay, first of all, just a brief introduction about who we are. This is Mario Rivas and I'm Daniel Romero. Um, both work as a security consultant and researchers at NCC Group

in the Madrid office, okay? Here you have our Twitter account and e-mail, but if you want to know us better, we are always up for a beer, so just ping us. Okay, this is the agenda. This is a really classical agenda. First, an introduction about, uh, about our research and the type two fate that we have covered. Uh, the testing methodology, Mario will present

the testing methodology and some facts that we have developed and a way across the different vulnerabilities that we have found. And after that, we will show you some exploit that we have developed. And just, finally, uh, brief conclusions. Let's go with introduction. Okay, um, the main goal of the research was testing enterprise devices,

okay? And figure out the current state of security of them. For this reason, we thought that printer will be a good target, okay? Uh, we selected six different medium sized enterprise printers and we decided to focus this research in a great teaming approach, okay? So, we did vulnerability research, exploitation and post exploitation. Keep in mind

that it was not an assessment, so we only need one vulnerability that provides us remote code execution. We don't need to find all the vulnerabilities that the printer have, okay? And why printers? These are really good questions. Printers have been really, uh, well extended, say, many years ago, around the, the, the companies. And they are usually

connected to the different networks, different VLANs, so we can use them in order to, uh, pivot in so the different department that company could have, okay? And obviously information that could, could be managed by, uh, a company is really sensitive. We have

corporate information, personal, financial customers, and don't forget the information which was include, or is include within the, uh, configuration. We can have, uh, domain accounts, credentials, password and etcetera, okay? And, well, usually, uh, printers are considered low risk targets, so probably they are not included within the path cycle. And,

uh, they probably are not configured securely or properly, okay? And then we have uncontrolled devices managing really sensitive information and connected to the most of the company's networks. This is an example of this week where Microsoft catches Russian

state hackers using printers in order to, to attack companies, for example. And why not? Some vendors, some vendors decided to make statements like this one, so it is a challenge for us. The most important probably. Okay, let's go with the attack surface. Uh, first of all, just comment that we identify two different, uh, operation

systems within our printers. Uh, the real-time operation system, RTOS, and Linux. And obviously we identify many different attack surfaces. Like web applications and web service, web services, sorry. Mobile applications, file parsers, update and framework analysis, printer languages and services, external services, like the, um,

Google crowd print or air print, management services, telnet, SNMP, and others. And proximity, proximity attacks like Wi-Fi, USB, and et cetera. And we also decided to include all the two tasks. Post exploitation and hardware analysis, okay? But

obviously we didn't have enough time to cover all these attack surfaces. And we finally decided to include the following ones. Those painted in grays because we didn't include them in all the printers tests, okay? Uh, this is a more detailed picture about our attack surface where you can see the different elements that we covered during this, in this

research. Uh, for example, for the printer languages and file formats, we decided to include the PGL, PGL, PCL, and PS language formats, okay? Let's go with the testing and methodology. So this is the methodology that we mainly, uh, used during the

research. Uh, we started with the state of the art on, uh, setting up our printers and then we chose a scope of our attack surface as we just saw. And then in a cycling process, uh, we started searching for vulnerabilities, uh, passing different protocols, um, finding some crashes, then analyzing them, and then trying to exploit them in order to gain more

knowledge of the device. Uh, all these while also analyzing the framework in the cases we were able to obtain it and also, uh, using the hardware to get some more useful information. Talking about fuzzing, uh, we started with dumb fuzzers, uh, which are very quick to launch but also, uh, well, and we continued developing, uh, smarter ones, uh,

which require more time but, uh, give better results. Both techniques, uh, gave us great results, but we also felt that we were spending more time that, uh, we should. Uh, so we

decided to create our own fuzzer. While looking at the state of the art, uh, we found two amazing tools, uh, Sally and Bufas. By the way, um, Joshua Pereira, uh, the maintainer of Bufas and Karl Pearson were here yesterday. Um, these two tools have great, uh,

but we were changing a lot of the code. So, we decided to, to fork Bufas and after Sally and Boo, uh, the next one was Wasowski, so we called this Wasowski. Uh, we wrote it in Python 3, uh, and we changed, uh, improved some of the modules like the string, string

fuzzing libraries. And, um, we also made fuzzer modules to keep all protocol fuzzers under a single, uh, program with a similar behavior. Um, between the rest of the changes, uh, we wanted to solve some difficulties that we were having. Different implementations of the same protocol behave, uh, different in different targets and when a

device crashes, it can go totally down or maybe the, the service may stop answering or maybe it just print a stack trace in some debugging interface. For this, um, we made a main program with a lot of arguments to, uh, avoid touching the code, um, for

different targets and we made monitor modules to constantly check the target. Then, when the device crashes, um, a lot of times we will need to reboot it manually. So, we made restart the modules, um, to, for example, turn off and on a smart plug and adapt to any

necessity we, we were having. And then, uh, to give usability to the, to the fuzzer, we made, uh, a nice console where we can pause and control the fuzzing session and, uh, do things like retest, uh, suspect packet, uh, suspect this case of crashing a device and do

other things like printing human readable format the packets that we are sending and, uh, we can also save standalone scripts, uh, that we can, for example, uh, send to a manufacturer. So, let's go with, uh, a very quick demo. Before that, uh, you can see here, um, a typical Bufas, uh, test case, uh, printing and below, um, the, our console with the

test case, the number of test cases, our target and some more information about the actual test case. Let's go for the demo. That's it. Okay, um, so we can see, um,

below a pink to the, um, to the target and we can see above, um, the help with a lot of the com- the options that we have, uh, the different modules, the fuzzer modules that we have, uh, developed, the restarted modules, the monitor modules and other options. We

are going now to launch, uh, the fuzzer to our target, the printer one in the port six three one, using the internet printing protocol, uh, fuzzer, and the get printer attributes command of the IPP protocol. And we are also using a restarted module that

turns off and on a smart plug when the device goes down. We can see here our cool logo and the console, where, with a lot of the commands that we implemented. We are going now to just test the connection, sending a non-fast packet to the printer. And

after checking that the connection is okay, we are going to go to a different test case and we are going to continue the execution from, from there. We can see here, uh, the different test cases that we are sending, uh, like in, very similar to Buffa's. And

after sending two of them, we will see below, uh, that we will stop receiving ICMP messages, uh, the printer has gone down and now we cannot connect to the target and we are going to use the restarted module to restart the target. After that it will wait for it to recover and, um, it will continue the execution automatically. But we

don't want to do that, we can control C, go to the console, uh, and we can, for example, print the suspects, where you can see the five phone and one. And we can also print this, uh, test case in a human real format, uh, you can see all the decoded packet and

the longest line, uh, is, you can see we are sending 10,000 Cs instead of the default value which was Ian. And we can also say, uh, see a proof of concept that we can copy and paste into a script and, for example, send it to a manufacturer or use it in

an exploit. Then, um, after this, uh, reloading, uh, we are going to, uh, recover, we will retest it to see if it was this test case which was, uh, causing the crash or it was any other reason. For that we can use the fast command and, uh, we are going to

launch the fast command for the five phone and one, we will just test this test case and after that we stop receiving ICMPs again. Uh, we have a bug, in this case it was, uh, skip buffer flow and we can also save the, uh, standard script into a file with the crash command and, um, disable this element to not test it anymore because we already know

it's vulnerable and we don't want to spend more time with this. So, that was the, the main demo. Uh, we, we can find all the code after the talk in our external

GitHub and let's go for just a bit of hardware. We took a very good look at the hardware, mainly searching for things that will help us with the exploitation of things. Like debugging the faces like, uh, serial ports, UART, JTAC and other, uh, information that

will allow us to dump the firmware or other useful information from the memory. And while doing that, um, we also were having too much fun, uh, playing with the hardware. Uh, we did something that we shouldn't and, uh, one of the printers will never print again because of that. Um, we could say maybe kill a printer, save a tree, I don't know. Um,

so one of the first things that we did was, uh, looking for exposed memories, like in this case, where we used, uh, bus pirate, which was connected to one of the chips and through the SPI protocol, we downloaded the firmware from the, from the, from that

memory. We also found, uh, serial ports in 3 of the 6 printer, uh, tested. Which, uh, also we found, uh, some data ports that seem to be disabled and, uh, the serial ports were extremely useful as they gave us a lot of information, uh, the back

information, uh, errors and the stack traces. And this was, of course, very useful to exploit some of the vulnerabilities that we found. Uh, also one of them had a interactive shell that allowed to write and read, uh, memory and also execute from arbitrary positions. So, we decided to make a hardware backdoor with this, um, which could be

implanted with, by someone with physical access to the printer in 2 or 3 minutes. For this, we used, uh, Raspberry Pi, uh, as you can see in the picture, which was connected to the, to the serial port and was also powered by it. So, whenever the printer is

on, our Raspberry Pi will be on. And then the Raspberry Pi will connect to an, an access point and from there we could just, uh, access to this console and have this, this capabilities. That was a very quick look at the hardware and let's go for some of the most common frauds found in most of the printers. Um, we started with the web

applications and we found really weak default configuration, exposing all most services available in the printers, uh, more than 20 in some cases. And we also found that it was giving access to the management panel with default or without credentials. Uh, we

got the feeling that it was like the pro security of 20 years ago. Um, and of course we found a lot of the typical issues in our web, like, uh, cross site request forgery, uh, lack of access controls in some functionalities like, um, uh, one that allowed us to

load a full, uh, backup of the configuration including, uh, passwords in clear text of course and, uh, other things like cross site scripting issues like 1, 2, 3 and 4. And a bit more interesting, path traversal, uh, which allowed us to, to load some files but

unfortunately, eh, we were only able to load some specific extensions and we are not able to further exploit this to get closer to our objective which was, uh, to get remote code execution. So, this is not bad, but we are looking for something that may allow us to get, uh, full control of the device. So, looking at the frameworks, we

found a few slightly more interesting functionalities. Like this one, you can see there are a lot of information, uh, a lot of debugging information like authorization and security logs including session pa- uh, cookies and also more information like active

directory logs, uh, Kerberos logs, the full list of processes running in the machine and more information about the underlying operating system and Linux in this case. In this second case was very similar to the first one, um, with different functionalities under different URLs and this was, uh, very useful to exploit one of the vulnerabilities that we

will see later. And this third one was even better because it directly allowed us to download the full memory of the device containing any secret, eh, passwords, uh, anything in that, at that moment. We also used this as a memory leak issue to defeat

ASLR, uh, when, when exploiting one of the issues. We will see also that later. And of course, all this was, uh, accessible without any authentication because it's not even in the menus or anything, so. So, going for the memory corruption issues, we found a lot

of them in a lot of services, not only in the web, but also in, um, in other services like, uh, printer protocols, IPP or LPD, or SNMP in the Google Cloud Print implementations, basically a lot, uh, more than we could handle or investigate, so we really stopped searching for more. Um, we, we had basically vulnerabilities everywhere,

which lead to crashes everywhere and also some useful extra traces in some of the interfaces that we found, like this one, where you can see that the PC is overwritten. And this is from, uh, exploit that we won't, uh, show you today, but don't worry, Danny's

now going to, to explain to others that are nice. Okay, let's go with, uh, couple of, of exploit examples, sorry, uh, couple of exploit examples that we, we, we developed for this research. This is the first one, this is the easy case, and it was found by one of, uh,

web application farces, okay, as you can see in, in the image, after sending a crafted HTTP request, and we, uh, with a long cookie value, we were able to, uh, crash the print, so probably this is a basic stack buffer flow, okay. But looking into the

framework, we identified that, uh, developers forgot to include boundary checks in the whole code, so probably this is, so, this string and copy here, uh, which is copying the cookie value into a stack array, could lead to a stack buffer flow, okay. And, uh, important, and also important point here is the common variable. The common variable is the, is the

cookie size, including the cookie name, the equal symbol, and the, uh, cookie value, okay. And it, for, it, it's, for example, used in some parts within the, um, within the string copy, uh, function, like within the, the size argument, where, where, uh, 15 byte, where

subtract it from this, from this variable, okay. Question here, um, will be, do you really think that there is only one byte here? The answer of this is no. Imagine that we replace the, uh, equal symbol by a semi-coloured symbol, okay. The common variable will result in 14, and 14 minus 15 is a negative number, so the string and copy

function will copy a really huge space in memory into the local array. So we have two different vulnerabilities in the same line. Here you have two personal concepts, the first one just sending a really long cookie value, and the second one just replacing the equal

symbol by a, by a semi-coloured symbol, okay. And thinking about exploitation, uh, so, looks, looks like we are going back to the 90's exploit, which is scarce, uh, let's go to check the different difficulties that we came across. The first one is, uh, we identify ASLR within the stack and the heap. We then have, um, software debug, and we're

trying to exploit our real-time operation system. We, so we need to reverse engineering the framework in order to identify some potential functionalities, for example, and use the, that functionalities in our shell code, because we don't have a shell here, okay. Help us only, we have a direct PC over-written, a potential read-write, an

execute table in the whole space of memory, and we, we have the stack execute table, okay. And finally, as Mario commented before, in the same printer we identify, uh, memory bl- leak vulnerability that provide, that allow us to get the full memory. So, what, what, what, what we're going to do here is try to use this memory leak in order to

bypass the ASLR, okay. So, this prediction change should be, we're going to send a shell code to the printer between patterns, okay. We're going to use the memory leak vulnerability in order to dump the, the memory. We're going to try to identify in that memory original code, and we're, uh, try to look into, into where original code was

allocated. We're going to try to, uh, trigger the buffer overflow, and after that, jump into original code, okay. Okay, uh, but for our, uh, writing tools, we want something

more. And, but, so, what is the mo- one of the most important data management by a printer? Obviously, the documents. And so, why don't create a shell code that distill all documents into the printer and send them through a reverse shell, which sounds like a good plan. Okay, let's go with the demo. For this demo, we are going to have two

different machines. The first one is the attacker machine, which is going to execute exploit, and exploit handle that we will receive the, the data from the printer, okay. And the second machine is a victim machine that we're going to send the, the document to the printer. Okay, let me check the video, this, the, sorry. I can see it well. And, uh,

okay, here you have the, the demo, sorry for this. Okay, uh, this is the, the demo, uh, here

you have the, the attacker machine with, uh, with the IP address and below you can see the exploit. Exploit need three different arguments. The first one is the target IP,

the target port, and the reverse IP. We are going to include here the ta- the, uh, the attacker machine IP address. So, we are going to attack the printer one in the port 80, and after that the, we are going to include the printer machine. Before execute the exploit, we are going to execute or exploit handler that will, will receive all, uh, all data sent from the printer, and listening in the pro, in the port 1337, okay. And,

after executing the exploit, as you can see in the, uh, third line, we are, we are using the memory liability in order to find, uh, all payload in memory, okay. So, we have now received a connection from the printer with the sentence, had the standard frame, because it was included within the shellcode, okay. This is now the, um, the

attacker machine, the solid, the victim machine, uh, with a different IP address, uh, what, what, what we are going to do now is sending this document to the printer, okay. We are going to send this document to the printer one, which is this one, and after sending the comment, you can see here, for example, how the exploit handle

receives some data, data from the printer, okay. So, now converting this data to a PDF. And so, after 2 seconds, you can see here how we were able to, uh, steal all data, all documents sent to the printer, okay. And the printer continues printing normally, and

our exploit handler also forward the, all data sent to another printer, controlled by that target. So, we were able to steal all data, all documents sent to our printer. Thank you. Okay, let's go with the second exploit, uh, this was the easy case, this

is going to be the tricky case, uh, as we didn't have software and hardware debug, and all the protections and difficulties was implemented in this, uh, this printer. So, it's not going to be easy to explain, uh, but Google tried it, okay. So, be patient please,

because it's a bit tricky, okay. We found, uh, a similar idea in the same place, but for this printer, but in this case, we have 2 different parts in the cookie value, okay. The first part is, the first part is something like a hash, and the second part, separated by a, a comma, it's something like, uh, base64 string, okay. After reverse

engineering the printer, the printer frameworks, we identified some potential vulnerabilities that could contain this vulnerability, okay. But the most important function was the function that decode the base64 decode value, okay. Uh, after analyzing this function, we identify how a struct was based as argument to this, to the

function, to the base64 decode function, and this has different elements included within this struct. The first, uh, element is the source, source pointer, which is the base64 string, the second is the destination pointer, which is the result of the base64

string, uh, that will, this will be filled, uh, within this, this, this function. The source length and the destination length, okay. But this function, the base64 function was called by the code in the highlighted area. As you can see here, you are calling the base64 decode function, and we are passing a struct as argument, okay.

And the buffer flow occurs because the destination pointer, which is here, was associated to a local array. So, if we send a really long cookie value, base64 encode, what over, what, um, the, the base64 decode function will overflow the stack, okay. So,

this was analyzed locally, so we need to corroborate this dynamically, okay. So, we used the, the UNICOM framework in order to emulate some, some framework, if you don't know the UNICOM framework, uh, this framework allows you to emulate different parts of code.

Let's see the, the result, for example, the registers. And we decided to create an script that, um, emulate the, the function that get and check the second part of the cookie, the string length, the base64, the code, and other functions, okay. And after execute this, the, um, the script, where we paste 100, uh, 100, uh,

base64, uh, uh, argument, we, we're able to identify that the PC register, the problem counter register, was over with, uh, by, by, by ACE, okay. We can also see how the, uh, stack pointer, all, all data, all data included with the stack pointer, we can control all this data. And, uh, the R4, the R4 and R5 register were also over with

them by, by ACE, okay. This is because the last instruction, instruction execute before, before trigger, all over with this is a public instruction which is popping the R4, uh, R4, R5, um, the, the PC register, okay. So, we have now all the information that

we need in order to create our shellcode. But, everything become inside here. We identified that the stack was not executable. We also identified that we tried to, to, to use many finger addresses in order to create our shellcode to a drop change, but none of them work properly, okay. And we also identified, uh, this, uh, the, the printer was

using a, a modified T kernel RTOS, but the most important point here is that this is a normal monolithic operation system and different tasks could be executed at the same time. So, probably what the kernel is doing here is take, uh, a code from the firmware and execute this code in memory in a different address, okay. So, this is the

reason because we were not able to use, uh, finger addresses to create our, our shellcode, order of change. So, therefore, we didn't know where and how our shellcode can be executed. We have something like SLR or, or knobsets. We have, uh, NX, um, we didn't,

we, uh, we were not able to identify valid addresses to create order of change. Uh, but we needed, we needed to identify valid addresses in order to do that, okay. So, thinking about it, we thought about different approach that we can use, for example, reverse

engineering the T kernel structure, but obviously we didn't have enough time to do it because it could take weeks. Uh, reverse engineering the whole other in order to identify potential static addresses, identify static memory, but we didn't know what permit, like configuration for example, but we didn't know what permission could be associated to that piece of code, or memory, sorry. But for random addresses, like we'll

see now, on looking for helpers, okay. Helpers like this one, this is an infinite loop that we found within the, the ball order. So, and we thought that it could be a good option. Use this infinite loop in order to create a blind exploitation, okay. Imagine

that we have a code that we don't know if it was executed or executed or not properly. What we're gonna do now is just, after that code, we're going to try to jump to our infinite loop, okay. If the printer reminds up, that means that the code was executed properly. If the printer crashes, that means that the code was not executed

properly. So it's something like a blind execution but with memory corruptions, okay. Um, okay, uh, we decided to mix the, the infinite loop call helper with uh, the following approach of brute force in the PC register with potential firmware addresses and figure out what instructions were executed. Let me explain, okay. Uh, the main goal here is uh, we're

going to, helping us with the code, with the infinite loop, uh, call helper. We're going to try to brute force in the PC register, okay. And we're going to, to, to try to guess or identify what instruction was executed more, in memory, blindly, okay.

So, remember that we can control the PC register on all data included within the stack pointer, okay. Imagine that we, we force in the PC register, we finally jump into a pop instruction but we don't know that this is a pop instruction, okay. And we're

going to include some data within our step pocketing, like three set of A's and after that, the infinite loop address. If we execute this code, the PC, the R0 register will be overgreeted by the first set of A's, okay. Uh, and the second, um, the PC register will be overgreeted by the second first of, second set of A's, sorry. And, so the printer will

be down, the printer will crash, yes. Okay, but in order to solve this and try to guess what instruction was executed in memory, we can change the information including, we included within the stack pointer. This is uh, another example. Uh, but for the

case, we're going to just include one set of A's within the stack pointer and after that, the infinite loop address. If we execute the same code, the same address, after they execute this address, the R0 register will be overgreeted by the first set of A's and the PC register will be overgreeted by the second, I'm sorry, by the second address,

which is the infinite loop. So, the printer will remain up. So, using this methodology, we were able to identify that in memory, uh, we are executing memory at pop register, okay, which is popping at one register and after that the, when the problem counters. So, using this methodology, uh, or approach, we were able to identify three

instructions in memory, the first one in the address 12, which was an at instruction, the second is, uh, in the address 12, uh, 14, sorry, uh, which was a, a pop instruction and in a distance of 500 bytes, we, we were able to identify another pop instruction, okay? So, our manual here state to identify the same pattern that we have

found in memory in our framework, okay? And we finally were able to identify this pattern but in another address. That means that the, when the kernel is executing this code, the kernel is applying an offset to, to this, to this code and we now know the

address, the, the exact offset that the kernel is using, okay? This provide us useful rock gadgets in order to create our shellcode and potential helpers to continue with the task execution. Sorry for that, but this is the way that we found in order to create our exploits. Okay, but it was not enough. We need more rock gadgets in order to create

our exploit and at this, this moment, we remember that, as Mario commented before, we remember that another function, another vulnerability which allow us, would provide us some useful, useful information, was found in the same printer. This, um, memory leak

or, or information leak vulnerability provides where exactly, uh, images and GIFs were allocated in mobile. So, we can use this information in order to bypass the ASLR protection, for example. And why not? We can also use this information in order to create a rock change, okay? Or we're going to do something like exploitation with images,

okay? So, we're going to download all the images and GIFs to our laptop and we're going to use the rock gadget script in order to find some interesting rock gadgets, okay? Obviously, this is not code and code, code and code because they are images, but we, we're able to identify some useful, useful rock gadgets to create our full exploit, okay? But, we

came across with another problem. This was the last problem, I promised you. Um, we identify, uh, we came across with caches, okay? So, we need to close the caches. There

are some options here, like call RM instructions or different, uh, functions like sleep, main protocol and others. Or continue with execution flow, which is probably the most harder, the harder but the most professional option. And we choose this option. Yes, quickly, um, in order to continue with execution flow, we need that original code

implement three different, um, parts. The first one is our exploit, for example, we can use, uh, we can create something like, for the previous, uh, exploit, where we are going to code the print function ID and steal all data through reverse connection. The second part, uh, should change the address that we, we were able, we were able to override

with the, with the vulnerability in order to jump in a value function. And then we, we want to continue with execution. So, we need a value function that we can read here, okay? And the third, uh, the third part, like, um, we should align the stack pointer again to a

previous pointer because we have, for example, execute or payload or change some addresses, so we need to align this stack pointer to a previous state, okay? And after that, just trigger the vulnerability as many times as you want, okay? Let's go with the demo. Uh, for the previous, uh, exploit, we tried to attack the documents of, of a

printer, but for this demo, we are going to attack, to try to attack all the information included within the, within a printer, data. Uh, let me check the demo. Okay, for, for this demo, we implemented three different function IDs within the, within our, our

exploit. The first one is, uh, write, so we can write bytes into the, into the printer memory and after that, jump into that, to that memory. For example, we can write, uh, a shellcode and after that, jump into our shellcode. The second is similar to the

previous one, but we can write a file that we have in our computer, for example, in, uh, a piece of code. And the last one is the read functionality. This allow us to read some data from the printer memory, but we need a way in order to allocate the memory or copy the memory, okay? So, what we did here is we are going to try to copy the memory that

we want to read in a known place. We know where exactly images and GIFs were allocated, so we are going to use this piece of memory in order to read the information, okay? Uh, what, do you need the software? And after that, the, the, the size, uh, here you have the, uh, the image that we are going to use in order to, to

exploit this, this function, uh, here you have seen, you can see how it is a normal PNG header, okay? So, we are going to, we use the read functionality to read this address, reading 500 bytes, and you can see here, for example, how we are reading the information, the address that we have set, and writing this information in another, in

another address, which is the image, okay? And after that, we are going to download again the, the image, as you can see here, the information, the, included within the image changes, and it is now, uh, uh, certificate, included within the old printer memory, okay? So, with this function, we were able to read credentials, domain

accounts, uh, uh, and other, uh, sensitive information, okay? So, let's go with the second, uh, the first functionality, which is the write. We can write a shellcode, for example, but for this demo, we are going to just write, uh, a sentence, the higher requirement sentence. We are not to jump to this, this code, because it's a, it's a, it's a

sentence, and after write this information, if we download again the image, we can see, for example, how the higher requirement sentence was, uh, was write in the first, um, in the first line of the image, okay? And let's go with the, the, the third example, which is the write file. So, what we are going to do here is we are going to

try to overwrite an existing web portal image, okay? Uh, so, we're going to select, uh, a, a, a logo that we have in memory, and we, we are going to try to overwrite an existing image in the, in the memory. It can take a bit, so, we are selected a logo, a logo, and

we are writing the, the information in the logo in a, in a known address. Let's go to move this forward, because it takes a bit. And, after two seconds, we are going to open the, the, the web portal image, which is this one, that we are going to, we are going

to overwrite, and if we refresh again this image, we can see how the insta-guru logo overwrite the image that we have in memory. So, so we can control all the information that we have in the printer memory, in order to read this, or, or to write this, uh, into, into our printer, okay? Let's go with the last part, the

conclusions. Okay, I hope you're all still alive after Danny trying to explain this last exploit. Um, let's go with the responsible vulnerability disclosure. Uh, we started this process in February, and we got a very mixed response from the vendors. Some of them

had a very mature procedure for this, and were really quick fixing the issues and, uh, which response was great. And, on the other hand, some others we could just say that, uh, it

was easier to find the vulnerabilities than their security department. So, uh, there is some work to do in that area. Um, we already published all the security advisories, um, most of them two days ago. And, as a quick overview, as you just saw, uh, we found a lot

of issues in a lot of places, which, uh, lead, uh, in most cases to remote code, uh, code execution issues. And, let's go for the CVE party. Uh, we found, uh, fi- uh, we got 50, uh, CVEs. Um, most of them high-hand critical risk ones, and just don't take the

number per manufacturer as an indicative of their state of security because some of them grouped different vulnerabilities under the same entries. Um, just for, uh, quick reference the full list. And, going for the main conclusions, um, this research aimed to show how

the state of security of common office devices, uh, such as printers, which are present in most, if not all organizations, is still very mature and largely not. We found a large number of critical and high-risk issues in all the printers tested. Uh, we got, uh,

proof of concept for four of them. We show, he, uh, we showed here two of them. One for documents and one for other data within the printer. And we ran out of time to, um, to

show, uh, to develop, uh, exploits for the two others. So, but anyway, there were issues that cooled it, uh, easily to that. Uh, a lot of CVEs and we stopped searching for vulnerabilities. So, this was important. We think there is a lot more of issues, uh, waiting in there. And we only checked a few services. Uh, there is a lot, uh, more things

to research here. And by what we saw, uh, the first one looking at this will probably find gold in there. And we only checked these printers, but we do not expect the same manufacturer having different implementations for some of the protocol sites, such as IPP

or different web applications, etc. So, probably the number of, uh, devices affected by these issues is huge. Um, much bigger than the number gave by some of the manufacturers. We could also say to some vendors that less marketing and more security. Um,

and the main recommendations for, for manufacturers will be to simply invest in securities necessary in all the development, uh, phases of a product. Uh, for

organizations, they should start considering these as the threats they are. Um, they have a lot of sensitive information, uh, not only documents, but also, uh, important, uh, information in the configuration like passwords, domain credentials, etc. And they are connected to their corporate networks. So, they are really high risk and no low risk, uh,

devices. And finally, for hackers, uh, this is a very mature field. If you spend some time with embedded devices, starting from the, with the very basics, uh, you will probably find, uh, a lot of issues. Uh, you will learn a lot and there is a lot of fun in here. So, you should give it a try. And about internet, uh, suspected, uh, quick shot and search

revealed a lot of these devices connected to internet. And we even saw that, um, some different vendors seem to be using the same code for some things like this web application of two different ones, which as you can see is quite similar. So, maybe we

tested more vendors that, than we thought. And finally, acknowledgements, uh, thanks, uh, to the Madrid office, to Matt Lewis and Philip Moss for all their help and support.

Also, thanks to Maribel and Chris which suffered us the most. Uh, and last but not least, thank you to Alvaro Felipe, uh, who was part of the research during the first days and also helped us with great ideas, uh, during the exploitation phases. So, it was very difficult to put this talk in, these months of research in just 45 minutes, but, uh,

thank you for suffering us. That's it.