BSidesROC 2024 - PostScript Pirates - Justin Taft

actually kind of fun. We were talking about how how many of you got into this from the gaming side of the world. Like didn't like losing at computer games, didn't like having to go through the whole freaking thing and said, "Screw it. We're going to break the damn thing." Yeah, you need to listen to this guy. So, for everybody, this is Justin. Justin Taft. Uh a hacker at heart, as are many of us, let's face it. Um started back in the early Windows days, 95 days. So, yeah, fun on those ones. uh broken into the scene by writing video games uh hence the uh and the training areas for it and exploiting files all over the place. Uh a few achievements uh

gaining rce by attacking shared memory through GPU. You can explain to the audience what all those acronyms mean. And uh gaining RC by fragging players in Counterstrike via memory. So basically he's taken what we got fed up with doing on gaming to an entirely new level. So please put your hands together. Say hi to Justin. [Applause] Hey. Uh yeah, thanks for joining. Really excited to been here. I've been at Bides a few times and yeah, decided to time to give back to the community and kind of share what we do. Um so yeah, the title of the talk is called Postcripts Pirates. We're going to be looking at some printer hacking today and how we're

going to get code execution on a printer through a print job basically. Um so super interesting. Basically, we could back door the printer, take full control of it, and uh it's probably not easily detectable. So, quick overview of the talk. Um it's kind of broken up to four sections. First, we're going to go over target selection about why we actually chose the printer and just like initial review of the printer and um you know, what was vulnerable at first. Then, we actually get into a little bit more hardware or hardcore hacking where we do some firmware dumping, removing chips from the printer, like dumping contents of it and some basic web hacking. um that wasn't enough to actually get into

the printer for the level we wanted. So, we had to actually uh you know do some more harder hacking. And then uh we're going to talk about how we do some fuzzing to find memory crashes on the printer. And finally, we're going to write an exploit to actually gain code execution on the printer. And if we have time, we'll talk about um how we use that to escalate privileges. And we're able to display, you know, uh our dog dogs on the screen of the printer by um writing to it. So, yeah. Um quick introduction I was just given but yeah my name is Justin Taft. Um been doing application consulting and form research for quite some time. Uh started when I

was a kid when I was 11 so like 20 plus years. Um worked with a bunch of Fortune50 startups, nonprofits. Um just all over the place from you know web hacking to low-level firmware reviews, fuzzing, um architecture designs, etc. Um big thing for me though like what really drives me is just um I think security and privacy is something that's you know like human right. everyone should have those things. So, um yeah, I got to work with some nonprofits with uh creating like cryptographic systems, people communicating like oppressed countries securely. So, that was really um you know, fulfilling. Um this talk and um this hack was done with my buddy Chris on the right. Uh super awesome

friend of mine. Uh we both skateboard. Uh we met in San Francisco. Um yeah, he hacking drums, skateboarding, etc. Um he's a pone toone winner. um big hacking competition, really technical stuff and uh had multiple other entries. So yeah, let's uh dive into the actual um talk. So the story begins with pone toone. It's basically legal hacking competition um by trend micro. Um what it is that people bring very um variety of devices so like cars um routers, desktops, software etc. and people are finding bugs within software to you know exploit and gain like control of it. Um their whole spin on it is that they work with vendors like um they've thrown endpoint protection systems so they buy

like vulnerabilities from people they work with vendors to get them patched and while they're getting patched they're able to protect people's systems in the meantime. Um so it's super um useful in my opinion. So when we're entering the competi competition, we really wanted to make sure we had like a successful entry. Like our goal was basically to find a device that we could attack and do it successfully. And when you have like a list of devices and only a limited set of time, I think we had about two months in our case. Um we wanted to really find like you know have the best odds at being successful for our attack. So a couple of things like

to look for when you're trying to pick a target that might have vulnerabilities in it is a wide attack surface. So, like the more features it has, um, the more probability it's going to have like a bug that you could use to get into the system. Um, something not reviewed heavily is probably also easier because less people are looking at means there's probably more bugs to be found, stuff that has been patched. Um, any previous vulnerability research on the device is really important, too, because it kind of gives you information about how people attempted to get into the device and might be helpful for you when you're attempting to to it. And you want to

find something that's reasonably effort. So if if it's something way outside of your skill range for a competition, you might want to dial it back just so you don't run out of time basically. Um so yeah, this was the target we selected. It was a printer. Um again, it's kind of interesting like at first like what could you do to a printer? Like why would you select this? Um the this thing has like a load of interface interfaces. So, you know, as a fax interface, so anybody who could fax the machine, send a print job to it, um, you know, could potentially take control of the device and if confidential documents are being sent to it, uh, that's a problem. Or if

it's on internal network, attackers could use that to pivot and attack other systems. Um, print jobs, again, loads of different types of um, print types such as Postcript and um, just other network services in general. And again, the main reason we took it to was just because it was in the competition and we thought we had a good chance. So, we're start diving into a little bit more technical stuff. Um, the main thing to take away from this talk is um just see like how more low-level hacking is done and learn some tools about how it's done. Um, I will get into a bit more specifics, but I think the main takeaway is just see like how hackers get into

systems about passwords and things like that and learn a trick or two. Um, so initially we tried to enter the system through a quick uh file path reversal. So sometimes you could overwrite files um by like on systems by using like special characters and file paths. Um we didn't have a luck there. Um we used some command injection. So um we weren't able to run any program we wanted to through the web interface. Um so that didn't work. We also looked at other common attacks such as SQL injections and this other toolkit called prer um exploitation toolkit. Um we that one allows you to talk to the printer through its own print languages but we

couldn't really access any like hidden credentials or do anything interesting there. Um so we had to uh you know get a little bit deeper with the system and see um what else there was. So what we did was that we downloaded the firmware from the internet and the firmware is a thing that basically runs the printer. Um very interesting thing is to update the printer you basically send it a print job which is just firmware. So you print the firmware. Um, so this basically, you know, updates the system and we were we were really hoping that we could just update the firmware through this, like change a couple bytes and just back door the printer. Um, when

we started looking into it, um, the actual contents was pretty garbled up. So that generally means that it's probably encrypted or it's like compressed. We did a quick test. We ran it through a compression algorithm and nothing got compressed and we didn't see any compression headers. So it probably meant it's encrypted. So we couldn't really modify it and just you know uh insert our own commands in the printer like that. So the next thing we had to do was do some recon. We needed to um uh you know get into the printer somehow. And we found this a blog post where they basically uh dumped the firmware off the printer by like desiring some chips. And uh that was

their like initial foothold to see like the internal programs of the printer. Um, there was a couple other methods they tried to use, but they didn't have success. So, we didn't bother wasting it. So, yeah, we had to get a little dirty, whip out our soldering iron, and try to, you know, get into this thing. Um, so the way this works is basically there's a nan chip on the printer, and all you have to do is basically desolder it. And once it's off there, you could plug into this adapter and basically dump the memory contents. So, the printer itself just was running Linux, so it's just like a normal file system. So once you get the contents,

you could explore what's inside. Um so once we got the contents, um it's basically like just a bunch of numbers and you have to figure out what's actually inside of it. Um for the technical stuff, there's a program called binwalk which kind of extracts the content. U when we ran it, it didn't run everything at first. So we had to run this additional command called UBI reader. And once we did that, we got the actual file contents. And the reason we know it worked is because um when we dumped the contents, we found some CGI scripts that weren't um basically exposed initially and we were able to navigate to the page um through the like

the web interface of the printer. So we knew that um we had the contents and we were able to start digging into what's inside of it. So um when breaking into a device um generally you want to get a shell. So a shell just basically allows you to run commands on the printer, do whatever you want. Um, one thing we could have done is basically after we dumped the nan chip, we could have just overwrote the contents and, you know, gave us like wrote an application to it to solder it back on and basically give us access to the system. But yeah, um, we decided not to do that. Um, when we dumped it, it

was giving us different um, content. So, we worried about like corrupting it and breaking the printer, but we ended up breaking the printer anyway when we tried to solder the chip back on. A very expensive mistake. You got to buy your own um, you know, your own devices for these hacking competitions. So, I think this was like a $400 mistake, which is very ouchy. Um, but yeah, we knew um the payout was going to definitely be greater than that. We we're fairly confident in breaking into things, so we decided to march forward. So, um after we got the contents, we were looking for hidden like scripts that weren't normally exposed to the web interface and we

actually found one that had command injection into it. Um this was act after post authentication. So in order to contact this um like this web page you need to get like amarant credentials which we didn't have but getting initial foothold on the running system is really useful and the way we verified this um basically we sent a command that caused the web server just to sleep for 5 seconds and if you see on the right it took a little bit more than 5 seconds to respond so we know it worked. um this particular page didn't actually dump the contents to you. So you couldn't um you know get file contents that way but uh there's other ways to do it such as um

setting it to like remote servers but this was just our initial test and um yeah so once we got the command injection we wanted to have a way to interface it with a lot like easier instead of keep sending like web requests every time. So we wrote a payload to basically fetch a script for the internet that we had and it basically opened up a port on the printer that we could just tone net into and after that we were basically into the system and we could just run whatever Linux commands we want. Um we were running as a web server as is as HTTP so we weren't root yet. Um, and root basically allows you to do whatever

you want to the system more or less. And we wanted to um basically get that in order to um, like I said, display our pet animals on the LCD screen just for funs. Uh, so we were looking for a quick privilege escalation. Um, easy way to do this is something like for su binaries. So when you run them on Linux, they run as like another user such as admin. We found this one that ran um, sniff capture debug. And when we looked at the contents of that program, uh, basically called these two other programs, um, ox and gp, um, this is a really kind of like old school vulnerability. If you update your path in Linux, um, you could

get your own program to be called. So since this runs as root, we could get our own script running as root that was basically named grip. So now we have root on the printer and, um, we could do whatever we want. Um, again, this wasn't enough for the hacking competition because um, we needed credentials and actually to get to this point. So we had to find that initial foothold into the system. Um yeah so uh like I said the printer had a bunch of attack surfaces and we wanted to uh find an interesting target that probably had bugs. So we looked at postcript and postcript is basically a print language more or less. Um here's the actual uh example

postcript. So really simple um it basically is a program to draw a line. Uh all it does is basically saying start a new path and it has a couple different functions it calls like move to this point um then draw a line to this point etc. And when you send a print job in postcript like images and all that stuff it basically converts it to this and prints it. Um there's different image formats it supports of course but um postcript is basically just like a I don't want to call like JavaScript but it's just like a a language interpreter that's running in the printer. It's like a general general purpose computer you could use. Um but it's pretty locked

down like you can't normally access files and all that stuff um externally. Um so once we kind of like dug through the postcripts uh we um postcript we really wanted to understand how it worked and so and we wanted to like find a vulnerability in the um postcript interpreter. So um basically the normal way this works is that programs are massive like there's massive amounts of code that goes into system and doing code review manually manually like looking at every line of code is going to be really time intensive. So generally you write a program to basically uh generate input to a program and it processes it and hopefully if you generate a certain test

case it might crash the printer then you know that something's interesting happened like something is doing something that it wasn't intended to do. Um, so yeah, if a program ever crashes, not all the time, but generally there's like a memory violation error or something and it's a good way to um a good point to like investigate further. Um, so yeah, fuzzing a printer is really interesting because um, you know, we could have wrote a fuzzer that just kept sending print jobs to the printer, but we probably end up with massive loads of paper and ink cartridge and it's going to be really expensive. So definitely didn't want to do this. Um, we wanted to find something that was

a lot easier to do. Um, and also doing it off the device is a lot um, allows you to paralyze it. So, whatever processor in the printer is probably going to be a lot slower than, you know, if you have a system with like 12 CPUs in it. So, you could really hammer on your computer, find a bug, and once you find the bug on the computer, you could send it to the printer to actually crash it. Um, yeah, everyone hanging in there. I know this talk's a little technical but super exciting. Um so yeah so yeah so now that we um kind of understood postcript we had to find like the actual program that ran postcript

and interpreted the job and the way we did this is when we started um our print job on the printer um as you saw from earlier we had our command injection so we basically were able to list processes that were running. So, um, when we like fired a printer job, we saw this program called Pagemaker startup and we're like, okay, that's probably like the thing that, you know, actually handles print jobs. Um, so yeah, initially we tried to use this thing called Q uh, EMU. Um, what this allows you to do is run a program designed for a different architecture on your computer. So, um, since the printer had ARM architecture, the instruction set wasn't compatible

with my normal like computer, which was x86. And so QMU is just another program that does like translation real time, allows you to execute other programs for different systems on your computer. Um, so we tried throwing pagemaker in there and it didn't want to start cuz it was trying to talk to hardware which didn't exist on our computer. So we wanted to see if we could find like a smaller target before we got really crazy with it and to create a fuzzing harness. And so what I did was um we looked for a postcript command. It could have been anything. We just chose invert matrix after looking through the postcript documentation because it seemed kind of

unique and other programs probably doesn't have that string. So when we ran grap um we found like a few different matches for programs. Um thumb was the first one that popped up. So we decided to look into it. And when we ran it, it basically said would convert a postcript um into like a image file like a PNG. So it was like a nice and simple target to like look at. Um here I was just showing that um besides the invert matrix text it had a bunch of other postcript calls. So this definitely looked like it had a postcript interpreter. Um using qmu um we ran we after we dumped the firmware and all that stuff we ran the um the

binary that was on the printer on thumb on our own machine and out came the ping file that we expected. So, uh, we know this was like a very simple target to try to attack. And, um, likely, um, it seemed like it shared like a lot of the same functionality. So, if we could find a bug in this program, we could run it on the more, um, comp make complicated pagemaker program on the printer. Um, so this, like I said, this finding a simpler target is always very nice to do. Just makes things easier. Um, so instead of instead of like fuzzing something that might take, you know, 5 seconds, 10 seconds to process, you

could all of a sudden get like a thousand executions per second. So, you're just churning a lot more data and likely could break into it easier and find a bug. Um, going on, uh, we found some, um, there's a couple different ways to fuzz. Uh, these are some very like simple fuzzers out there, uh, that take like an input data and like take like produces some output to it by doing little tweaks. Uh, so ZCUF um is a simple one. It basically just flips some bits in the data. Like it doesn't really care if it's a number. you might accidentally change that to like a like alphabet character or something like that. Um so that didn't give us fruitful

results because like postcript is very structured. Um so we tried redamza which was a little bit more intelligent. So um as you saw in our postcript example where we had like move to and it took a couple numbers we're like replace numbers with numbers sort of thing to um kind of keep the structure of the job. Um so after um going through it we actually got a crash and when we sent you to the printer it got a blue screen. Uh so anyone you know from Windows 98 days that is not the safe thing but the blue screen of death kind of came back. So that kind of made me happy but digging into it u this wasn't

exploitable um for technical reasons I won't get into. Um so we had to look for additional crash but since we got this thing given a segmentation fault um which is like the six sev text um it means like a memory access violation probably occurred. So um normally a program um has like a bunch of data in memory and if it tries to act something access something that like that's not really mapped to it like it'll throw uh that sort of exception or it might try to write somewhere where it can't be written to because of protections. um that same bug would pop up too. Um so yeah, we were really we really knew we were like uh you know hot on the trail

here and um really interested in finding like a bug. So at this point um we decided to double down in postcript and really look at the functionality here. And so uh what we were looking for when looking to attack the postcript uh interpreter was anything that did crazy thing with memory allocation. So um in computer science there's things like you know arrays and uh dictionaries and things like that um just like copying data and moving data around and postcript has some of those functions and usually um bugs are um found in those sort of cases because they're not doing proper checks to make sure they're moving things where they shouldn't sort of things. Um so

yeah after we went through the spec um we found like a handful of these functions and um these are just like a couple instructions from the postcript sets. Um again the main thing to take away from this talk it's not so much all the technical details about postcript but um just kind of like the mythology we used to actually get foothold in the system. Um so yeah these are kind of like memory um memory commands you could do. So you could like store stuff in memory, get stuff in memory. Um stuff like get interval put interval allows us to take like a huge um sequence of data and make it smaller and get a reference

to it. Um and we also have um some other commands just do more additional memory uh specific stuff. So we were really interested in those and there's a ton of other postcript functions and we're like okay how do we actually like test all these functions like we don't want to write all these programs by hand and uh that's going to take way way too long to like um get code coverage. So code coverage is just basically the amount of functionality that you're testing. So um I didn't want to spend like you know months and months and months just writing programs in postcript covering everything and we really wanted to see if we could like autogenerate programs

to do this. Um so this is where we decided to um look for a postcript fuzzer which basically generates the programs but there wasn't any on the internet. Um so what we wanted to do was basically generate these postcript jobs that were valid postcripts. So like um we sent them to the printer and like the printer doesn't reject it because like malformed or anything like that. Um so what we had to do was oh yeah and we did want to look into the lexer grammar. So when you send like a a a job to something, there's like multiple stages. Um so like lexer and grammarss are like the first thing that just kind of checks

its formatted rate, the next stage is where the execution happens and that's where like a lot more functionality is. So by doing more structured fuzzing, we could get a lot more coverage this way instead of just wasting CPU cycles that wouldn't do anything. And um to do this, we decided to use a program called tomato. Um it was usually used to find like bugs in Chrome and things like that. Um so um typically allows you to like fuzz the JavaScript engine to find like memory corruption vulnerab things like that. Um has support for declaring and using like variables in programming languages which is like use really uh useful uh because program allow like languages if it have

a reference to something. There's text like there's um bugs called us use after free where like the value might disappear and um if you still have a reference to it you could read something else that was there before or write something and that could lead to getting code execution some places. Um so yeah we decided to build our own grammar using this tool. um roughly like 95% of the time we had it generating like valid postcript uh data but like we still wanted to get some lexer coverage so we um 5% like didn't um so yeah this is a quick example of like what a like a fuzzing um the tomato language looks like. Uh so here's like some example

postcript um like explained as a grammar here. Uh first is basically the postcript commands. um tomato kind of allows you to specify a symbol on the left then um like constants or arguments on the right and I'll explain this more in a second it'll make more sense but um basically we said okay like a poster command is popped or it could be a number number and a plus sign which basically do addition um then you could define what a number is so here we said like it's a normal integer so just like you know a normal number it could be a string from like uh 20 characters to 80 characters or it could be another

postcript commands cuz There might be a scenario where like a output from one postcript command might be do doing something really weird if you send it to another postcript command. Um so after after that um oh yeah the last thing is uh um this is also really helpful for people who are writing um exploits. Um if you have a test case that's invalid um some interpreters like will just stop. So like if you have something invalid in like the second line and there's like 10,000 more lines, it's going to stop at the second line here and um by doing these like try guard catches, it basically catches it so the program can continue executing and so

that allows you to um get like more executions per second, allow things to continue. Um so yeah, when we run the program, basically this is what it produces. It's just um every time you run it, you get a variation of the output data based on the grammar you specify. So just showing here each time you run it it's just a different postcript program. So as you spec out the whole postcript language you're going to get like you know millions millions and millions of postcript programs are like very different from each other. And the idea is as you run them, hopefully it cause a crash on the partner. And um yeah, after we spent some time looking at the spec and you

know define our own grammar um we actually got crashes and a lot of them. And I never I never thought uh having computer too many computer crashes would be a bad thing. But uh yeah, it's you know there's there always could be a false positive. Just because a program crashes doesn't mean it's exploitable. Um so basically what we wanted to do was um not have to go through all these test cases manually and we wanted to uh focusing on like interesting ones only and there's a program called GDB GDB exploitable which tells you like um this is likely crash based or exploitable based on the crash type. It looks at like you know CPU registers like memory

allocations and things like that and um just gives you like a very quick way to kind of shift through a bunch of um interesting test cases. And one of the cases we came across um was this. So there's probably no way I was going to come up this by myself. Um this is why fuzzing is really important because it generates stuff that you probably wouldn't or don't have time to do. Um but this is this is the core of the vulnerability uh that caused the crash. So um the first thing you do is we have a string uh which is just four a characters. The next part is really interesting because it basically says um get like it represents like the

four bytes string a aa but it says um create like a new array starting at like a gigabyte index from the beginning and yeah a gigabyte is so many more bytes than just four. So this is basically giving us a offset that's not within our original string. And then here we see we have a rate B which is doing a memory write to something outside of the smallest string we have. So this is looking really good because it's given us a um memory rate to some data that shouldn't be written to. Um normally you would only be able to change like maybe one of the letters in the AA string to like you know a B or C or whatever. But

here we're able to um treat the string as if it's like a gigabyte long which is massive and overwrite data that wasn't originally intended to. So this was like a bug within the postcript interpreter itself. Um let's go and get a little bit more technical but uh yeah we're almost we're almost um through the um the explanation of how it works. So really quick um this is basically assembly language. All computers uh you know they have ones and zeros like one step up above that for humans to be able to read are these very simple instructions. Um when I say simple they're very simple like add two numbers move this memory uh piece of data from this memory address to that

sort of thing. So it's very small but um as you like you know chain all these commands like together you could create more complex programs and a lot of pro programmers used to program this back in the day. uh hackers still do when they're trying to exploit things. Um so basically what this bug was doing was storing this um the letter B at this memory address um which was pretty far off and we're like okay what what's actually at this address. Uh so when we looked at it um we took the memory address of the D6 D3 etc and we um subtracted that large offset that was in our payload and we got the numbers 41

4141 and um in hexadimal that represents our aaa string. So basically this is giving us a memory rate um so again we have our aa string and it's given us a memory rate like way to the far right of it. Um, so this was really exciting and um, we thought we could turn this into exploit. So, um, there's a couple less steps we had to do here. Um, just because we have a crash in a memory rate, it does actually mean, um, it's useful. You could turn into control of the printer. So, what we had to do was, um, kind of understand the bug a bit more. Um, we knew basically we couldn't use like an arbitrary index. So like that

large number you saw that was a gigabyte um had to be like within a certain range but we realized we could use some math here to um get it to like a smaller value that we wanted to. And um the way this works is basically u computers use something called modular arithmetic for unsigned addition. And so by adding like a very large number you could get it to um decrease its value actually. So uh yeah this is the interesting part. So um if you look at the code we have the x= x plus then some large number um so that's just adding like a really huge number to it. But if you look at the output at the

bra bottom you see it's actually decreasing every time because the computer doesn't have enough um like uh register space to actually store it. Uh and it basically um registers or CPUs are programmed to do this thing called overflow. So when it gets to zero like rack back to like the highest value and start decreasing again. Um so we found a way to use this bug to uh point to any or point back to the original address. So by causing wrapping multiple times um we could wrap it back to initial string uh beginning and this will allow us to write to like any adjacent memory or absolute address. Um yeah so this is uh trying to

put this all together. Uh this is what the actual um memory layout looks like. So here we have our two strings in memory we could allocate. And so basically we have like a string a a aa and that's size of four and a string bbb of a size of four. And we have these things called pointers which like point to the actual contents. So when we write our exploit um what we actually do is first we create our own uh basically string that points to the same a string but using our uh bug we found we're able to expand what it can write to. So normally only could modify a aaa but now we're able to modify all

the stuff to the right of it. And so what we did was um using that new bug, we decided to update one other portion called the string pointer. Um so we were able to target any address um on the system. And once we're able to like point to something of interest, uh we could do our exploit to actually overwrite the value. Um so this is kind of like the core like how memory corruption bugs works. you get to um modify something interesting in memory and kind of update the contents. So um yeah, the last couple things we had to do is exploit development is an arm race, right? So it's been around for a long time. So every time like attacker

comes up with attack method, uh there's another, you know, defense person creating some mitigation for it. So people are always trying to out compete each other. Um, luckily for this particular exploit, there was a um they didn't have full hardening amount on there. So, we were able to leverage that to um overwrite something interesting. Um, so how do we actually put this all together to control the printer, right? Like we have all these like pieces. Uh, so starting back from like the beginning, we could start we could call like postcript function with any sort of data we want because we could control the print job, right? So why not just like update the post script itself to

call like a system command instead? So it's basically patching the interpreter at runtime. Um and like the first function we need to patch needed to be a string. So what we did was we found out that postcript allows you to open files and we decided to uh patch that to run a system command instead. Um so instead of normally like if you say like open a file it would just open the file so you could read the contents but in our case since we patched it we could gain uh system commands instead. Um so yeah here's basically the exploit of it. Um this is like the full postcript. So um we had our bug. This is basically

weaponizing the bug to achieve whatever we want. Um, you want normally you wouldn't see these sort of exploits being used against just like, you know, out in the wild against normal things. Uh, usually they're more targeted just because they're hard to find um when like attackers are trying to break into things. But, um, our first step here, we basically allocate our strings on the heap um, which is basically just some memory area and we allocate a way so we could use our bug to point anywhere we want to. Um, we use our wrapping bug here to wrap all the way back to the beginning of the A's. So, we could write to the right of

it. Um using our um memory bug that we found, we update the pointer to point to um the CFS open call that we could overwrite in the got entry table, which is um an area that the program uses to um find like other code to run on machines when like um when code isn't like always in the binary. Sometimes it's in multiple files. Uh next we after we corrupted the CFS open we point that to basically the system command. And the main takeaway here is after all this is that we're able to um call system commands instead of um instead of uh just opening and reading files here. So when we actually run it here um

we this is basically the file we're setting to the program. um re-execute it and all of a sudden we're dumping the contents of etc password. So at this point we're able to run arbitrary commands by just sending a print job to it. Um this is really interesting too because um the same bug works against the printer. Um a couple things have to be changed but if you if you have a print file on your computer it might just be like invoice but when you go to print it um since the printer has a bug it's actually going to exploit it and you could gain like persistent access on there. So um this is really important because you know governments

use printers. So like you know if governments print things you you know it can end up as a back door on the system or um it could be a way for attackers to attack other devices on the network. So uh yeah and there's probably no virus scanners running on printers either. So uh it's probably not going to be caught and um yeah it was it was basically you know fun little exploit. So um I get excited about this stuff. It's um Thank you. Um yeah. Um again, this was pretty technical. A lot of hacks, you don't have to go this hard to break into things, but sometimes you got to and just having another tool chain in your

belt being able to do this stuff is really important. Um I did want to mention the industry is kind of trying to slowly move away from these sort of bugs because they plague anything from like routers to modems, phones. Like there's scenarios where you could get like a text on your phone that you don't even see and someone compromises your phone. Um I wouldn't worry about that too much because those are really variable like variable like people probably like pay millions for those type of bugs. Um so they're like you know they're not used against just like normal people. It's more like government stuff but um yeah the same concept applies to like basically any device has

these programming languages. Um so I have a little bit more time here. Uh I'll quickly go through some just escaping it. So um here we were able to um run as pagemaker but it wasn't root. Um so again we were able to run arbitrary commands on the printer but was locked down and for those who know Linux um so Linux is just an operating system typically found like a lot of devices is free. Uh they have something called a system DJL. So it kind of restricts what you can actually do to process. So um let's say like you know I got in through page maker here um they have something here called uh no new privileges. So we couldn't use our

old bug um directly to get to um root because um basically it's locked down by the operating system and there's additional restrictions like you couldn't just read arbitrary files as you see at the bottom the rewrite paths it's only locked down to set amount of files. So um the system GJ jail was like a quick way to mitigate you know attackers getting to your systems. Um so what we did was continue looking through the system and we found this thing called Rob which was uh just a demon that like a bunch of other programs talk on the printer. Um it was over a Unix socket. Um so Unix sockets are a little bit different than TCP

sockets. Uh TCP sockets you know you have IP addresses things like that. Unix sockets are just like local files on a system more or less and they're used for like two processes to communicate with each other. Um so we what we did was we ran this program called socat and allowed us to like intercept communications to that socket and see what it was used for and um we actually found that allowed us to um create like an admin credential through here. So uh remember like a first really old bug that we had where it was post admin. Um basically we use this internal system command to create an admin account then through the web um page we exploited the

vulnerability to get the root and we had um execution on the printer. Um I have a link to the slide where it's by pone to own a video card. I didn't want to show it for licensing purposes. decided to do it off camera. But um yeah, here you can see us getting um execution on the printer and we like flash some fun stuff on this the printer and we have it like start singing a song basically by the PC speaker. Um yeah, that was basically the talk. Uh happy to answer any questions. Um yeah, I I really find security very interesting. Uh it's it's pretty broad broad and I think the big thing for me

is um you know security can be very complex and I want to try to make it more accessible to people who are interested in it. Um you know so if anyone's interested in hacking it could be like anything. It doesn't have to be these low-level exploits but um yeah feel free to you know come after me after talk and say hello and whatnot. So yeah thank [Applause] you. Um, are there any questions at all by any chance? Yes. Were you um was this mostly ghost script that you're I mean the postcript interpreter is that's a great question. Um yeah, so the Lex Mark actually had their own in postcript interpreter so it's all custom code. Um

yeah, so great question. Yes. If there was an issue with the postcript interpreter, was it able to be replicated on the other Lex Markers? That's a good question. Um, I assume so, but we haven't tested. Uh, there's other people that did vulnerability research um against Lexark and they found other bugs in the postcript. So, yeah, it's most likely likely. Um so like the big thing um that's why software updates are valuable uh like very val valuable because um these sort of bugs get patched and you know um when you update it they're not exploitable anymore but printers often don't get updated anyway. Exactly. So um yeah cool um well awesome. Yeah. Thank you a lot

for everyone's talk. That's I think all I have for today. [Applause]