 We're going to talk about routers that are pretty horribly broken and then you can't fix them apparently but you are going to break them to fix them if they are broken. Good? Ah sure. I'm a lawyer. I do what I can. Let's give our next speaker a big round of applause. Alright thank you everybody and uh welcome. Uh so this has helped me uh uh helped me vulnerabilities. You're my only hope. Uh and this talk is about using vulnerabilities to determine if your micro tick router has been exploited. Um and I actually talk a lot about code that I wrote and data I collected um and I actually just pushed this all to get hub this morning uh slides are up there too um so check that out when you have a chance. Uh and here's just the talk's agenda. I'll start with some background on micro tick and why their routers are interesting. Uh in the middle I'll present uh the problem micro tick administrators are facing uh and then I'll present a solution to that problem. Uh finally after we get root uh I'm gonna go do a brain dump of all the fun places uh attackers can hide in router OS uh that I know about. Uh but I'm gonna start with a very brief introduction of myself and uh some work I've done. Uh my name is Jacob Baines and I use the handle of vinyl lobster uh I work at uh I work at Tenable uh as a member of the zero day research team. Uh and on the research side I really like working on micro tick routers. Uh the system design is uh fairly interesting and it uses a custom protocol that it's fun to interact with. Uh and I've written about the routers a few times as you can see. Um and that's my bald head up there at DerbyCon last year talking about the custom uh protocol. Uh and I have also found a few vulnerabilities in the system. Uh couple of which will be featured uh in this talk. Uh but not everyone's familiar with micro tick so I wanna introduce the victim. Uh micro tick is a Latvian company uh and they produce networking devices in associated software. Uh and the products uh they sell are deployed around the world and for a few reasons uh they have a very enthusiastic user base. Uh not just on uh their micro tick forums and not on places like Reddit but also uh they hold micro tick user meetings across the globe uh which can uh yield some pretty interesting results. And I'll speak about that in a little. But like I was saying micro tick makes routers uh and since I work on these routers a fair amount uh I inevitably try to talk to my coworkers about these uh unfortunately I believe this is what comes to mind when I'm talking to them uh just this little Soho router. Uh which inevitably yields this expression because who really wants to listen to some guy talk about a Soho router for months on end. But when I think about uh micro tick this is what I'm thinking about. Uh this is a cloud core router and it has uh 36 cores and it advertises 28 gigabit per second throughput. Uh and what's really interesting is uh that little Soho and this big router uh they actually share the same operating system called RouterOS. Uh now this router is good enough for a large enterprise or an ISP uh and in fact I know it's used by ISPs uh because uh they like to show up to these micro tick user meetings uh and give presentation on their ISP deployments featuring these micro tick routers. Uh you don't have to take my word for it I linked a bunch in here uh and I actually stole this screenshot uh from a small ISP in the Philippines. You can see it's just a handful of cloud core routers in Iraq. And of course uh you can actually find quite a few micro tick routers on Shodan. Uh the router does have a bunch of management interfaces uh so it's kind of hard to get an exact number on how many are in and out facing but you can see uh the web interface right there is about 600,000. Um but one interface you won't find on Shodan is for this guy uh and this is the screenshot of their management client called Winbox. Uh it uses a custom protocol over 80291 in order to communicate to the router uh and as far as I know none of the internet scanning search engines uh actually index this um which is really unfortunate because most of the recent vulnerabilities for micro ticks uh they use uh poor 80291 as the attack vector. Uh however uh back in March before they got crevced packet tell did an internet wide scan of TCP port 80291 uh and they actually tossed the results up on their website. Uh and uh the websites now kind of down or less I checked it was um but you can grab the results off the way back machine and what you find in that data set is 3.6 uh million IP addresses that respond to that TCP scan. Uh and that's uh pretty useful data point I think uh but doesn't say exactly how many are uh really micro tick routers. And since last year I'd actually released a library that can talk this micro tick protocol uh I figured well why don't I scan these 3.6 million addresses and determine which ones are micro tick. And so that that is what I did uh I wrote the scanner uh and it ran in late June into July of this year. Um and mind you the packet tell data was from March so it was getting a little stale but I was able to identify half a million micro tick routers with their wind box exposed to the internet. Um which according to micro tick itself is a pretty big no-no. Uh also interestingly uh at least 40% of uh the scan routers were vulnerable to a firewall bypass that I'd publish in February. Um so that's just our first indication of uh the poor patching practices. Um so this pie chart itself uh is not super interesting but I have a specific point I want to make here. Uh you can see that uh 60% of the devices I scanned have been patched in the last year. And that's that rather large chunk that says uh newer than 6.43 RC4. Uh but everything else is more than a year behind in patching. Uh most notable is the older than 6.28 chunk. And rather OS uh 6.28 is more than four years old now. Um and all I'm really trying to say here is uh micro trick micro tick administrators are not well known for their good patching practices. Um so that leads very nicely into this section. Uh micro tick routers have seen a number of exploitation campaigns over the last few years. Uh so I want to discuss some of those. Uh so we can start in 2017 uh and WikiLeaks released Vault 7. And Vault 7 uh contained this zero day exploit uh that was called Chime Red. Um now Vault 7 didn't actually contain the uh the exploit code or an explanation of how it works. Um but micro tick did issue a patch uh and as far as I know Big Nerd 95 here was the first to reverse it and figure out how it worked. Um and it's an unauthenticated unauthenticated stack clash in the web server. And as we've seen there are about 600,000 web servers currently available. Uh and about a year later in February 2018 Kaspersky published their research on Slingshot APT. Uh now Kaspersky noted that Slingshot had exploited micro tick routers with an unknown vulnerability uh in order to replace some DLLs on the router. Uh and the DLLs actually get dem downloaded by the Winbox client. Uh so not only did Slingshot uh exploit these routers but they're able to exploit the downstream admins as well. And still not long after that in May 2018 uh Talos uh released their first iteration of their VPN filter work. And micro tick routers were also caught up in that. Uh again no specific vulnerability mentioned uh but micro tick's official statement implied that the exploit was Kime Red. Um although I personally take that with a grain of salt. Uh either way I want to point out this FBI notice uh that simply states uh for everyone to reboot the routers uh and we will see later that that is not going to remove malware from a micro tick router. So this is more of an ongoing thing to my understanding. Uh this is a picture from a very nice analysis done by Trend Micro on Trickbot from March 2019. Uh and you can see the threat actor uh was actually using exploited micro tick routers to run command and control uh on their installed Trickbots. Uh a great way to stay hidden uh but really not great for the router owners. Uh so this post uh uh actually appears on the micro tick forums on April 20th 2018 and it basically says uh someone has logged into my router and now I have a couple weird batch scripts in my user directory. Uh and a couple posts after that a guy running a wireless ISP uh comes on and says yeah we're seeing the same thing. Uh and so this turns out that it was uh actually zero day being used in the wild. Uh and three days later micro tick actually issued a patch for this which is uh pretty good turnaround in my opinion uh and their statement basically says uh you know someone with a custom tool can connect to the Winbox port without authentication download the user uh database and recover user names and passwords. Uh but that's it for details. There was no POC. There's no CVE. Uh but a month later uh a couple researchers posted this analysis of the vulnerability and shortly after that they published a working POC and then um after that finally CVE 2018 14847 uh was assigned uh and then and the POC they wrote uh actually gives the attackers credentials they need to log in to the router and start messing with the configuration. And um you know as we've seen micro tick routers don't get patched very quickly uh so people kind of ran with this. Uh one of the things they did was inject coin hive javascripts into the custom 404 page uh that the router can serve up. Uh this is a tweet from bad packets report and it was around the peak of this coin hive madness in uh October 2018 which you can see a quarter of a million affected routers. Uh but other attackers had other ideas. Uh one of the good features of micro tick routers is that they can uh they support packet capture and forwarding uh so according to netlab 360 um about 7500 routers have their packets forwarding to a third party. Uh and another attack um mentioned by netlab had a nearly a quarter of a million routers uh with their socks for proxying enabled just for this one specific net block uh which I thought was both weird and fascinating. And I've skipped over other threats like Chime Blue uh but I think you guys kind of get the idea at this point. And the reality is none of this stuff is really going away. So this is a tweet just last month from Grey Noise uh and uh if you're not familiar with Grey Noise uh they have honey pots all over the place um and you can see here uh they notice a very large increase in scans for CBE 2018, 14847 just last month. And that actually uh written and uh deployed my own wind box honey pot around that same time period. And uh while the numbers weren't crazy almost every connection to the honey pot was uh an exploitation attempt. Uh and it only took uh about an hour and a half of the honey pot being online uh before the first exploitation attempt rolled in. Uh and again like everything uh in this talk both the code and results are up on GitHub. And of course this is a sort of different kind of threat. Um Zerodium tweeted this earlier this year uh and this this offer is still on their website last I checked. And uh while this isn't Apple zero day money it certainly isn't nothing either. Uh so presumably Zerodium has someone they want to sell this to. Uh so why did we talk about all that? Well hopefully I convinced you that these routers uh you know they're not just little home routers but they're also big beefy enterprise RISP routers um and you know they've been exploited quite a bit. Uh but what is the problem I'm here to talk about? So this is the problem. Um from left to right you're looking at wind box, web fig and the micro tick terminal. Uh and this is more or less uh what the administrator has to interact with the device. Uh when what you won't find is um uh real shell any way to uh access the underlying file system. Um the administrator really runs in a jail and um uh they just don't have any way to know if they've been exploited. And I'm not the only one to notice this. Uh this is just a small sample of uh people on the micro tick forums wanting to know how they can tell if they've been exploited. And this is actually micro tick's official statement in response to CBE 2018 14847. Uh I highlighted the good part. You can see it says there's no way to know if you were affected. Uh and the security community isn't uh much better because what we do, what do we do? Uh we write nice blogs. I'm certainly guilty of that and we publish file hashes. Uh but micro tick administrator can't actually access the file system um so the file hashes aren't incredibly useful to them. So that's kind of where the micro tick community is. Uh blindly hoping they weren't exploited or if they have upgraded that that um actor has been pushed out. Uh but to my thinking that isn't very acceptable uh cause there are serious implications implications uh for any person or organization with a compromised router. Uh you really do need to know if you're affected or not. Uh but without any type of official solution uh and really no other alternative uh we turn to our only hope. Uh and that's the vulnerabilities themselves. Uh so perhaps we can jail break these routers and get some answers. Uh but there is one immediate problem with my plan uh and that's the number of architectures that router OS actually supports. Uh I think micro tick has a goal to collect all the architectures. Um but writing and maintaining stable shell code for all these architectures uh would surely be obnoxious task that I certainly was not willing to undertake. The other problem is uh my critic releases so many versions of router OS uh they have even released a version since I gave these slides to DEF CON. Um and you can see since 2013 uh they've released about two official versions per month uh that's ignoring all the release candidates. Uh and that's just a lot of versions we need exploits for uh and uh it'd be tough to test uh stable exploits across all those versions. So that's kinda two strikes against my vulnerability saving the day plan uh but this is our saving grace. Uh router OS has a back door in it. Um it's there on purpose uh if a special file exists in a specific location uh you can gain login you can log in as uh the develop user and get a root busy box shell. Uh and I cannot emphasize enough uh users cannot, they should not and they were never intended to be able to make this file and get this root shell. Um but I think with some help from our vulnerability friends uh we might be able to get root and answer some questions. So here's the first vulnerability uh this was actually found by Hacker Fantastic and it was dropped as a zero day onto December 11th 2018 and my critic uh shortly followed up uh with some patches. Uh this vulnerability has no CVE and it's just a simple arbitrary file creation bug. Uh you can you literally just tell the town that client to uh create a file. Uh pictured here you can see that I tell the town that client to set trace file slash ram slash package slash option. Uh and that just happens to be the back door file and then log in as develop and get a busy box root shell. Uh and just a quick note about vulnerabilities requiring authentication on router OS. Uh the system ships with a default admin user uh with no password. Um and neither login for the web interface or the wind box interface have any sort of brute force protection. Uh so I've written a couple of POC to prove that out. So while Hacker Fantastic's bug does require authentication uh it's still quite serious. Um but back to the bug itself. Uh when Hacker Fantastic dropped this vulnerability it was just a basic breakdown uh of how you would manually type in the attack. Uh writing a full POC requires the author to know how the wind box protocol works and since I'm one of the three or four idiots that publicly understands that I went ahead and wrote these POC uh that automate Hacker Fantastic's exploit. Uh and these will create the back door file uh so you can log in as root. So this next vulnerability is one that I found uh and it was patch twice. Once in March of this year in the stable branch of outer OS and then again in May uh in the long term uh version of iOS. Uh interestingly MicroTik doesn't actually flag this uh patch we see here um as a vulnerability uh they simply call it improved file handling uh and they don't even mention the CVE I signed. But either way uh this bug is a file traversal bug um and it gives you the ability to um both uh create directories and read or write files. Um so it's very powerful uh but does require authentication. So I have a couple POC for this um again it just creates the back door um and again it works uh all the way up through May of this year. Uh finally the last vulnerability that we'll be using uh is CVE 2018 14847 uh and this vulnerable this is the vulnerability that actually started out on the MicroTik forums. Uh uh this is all it also turns out that this is a file traversal a directory traversal bug uh and it can also be used to read or write files anywhere on the box. Uh since I already released an exploit for this back uh for DerbyCon um there's nothing new to release today. Uh but basically the summary of the situation uh is we have these three great file creation vulnerabilities uh and they work over a variety of interfaces uh and all of them can create the back door file to enable the root shell. Um you know and also the MicroTik community has this general problem uh that they can't determine if they've been owned or not. So I'd like to introduce you to a little tool I wrote. It's called CleanArras and CleanArras aims to be a very simple tool. The user simply provides the IP of the router, a username and a password and CleanArras will do the rest. Uh it'll exploit uh it'll either try exploiting the uh windbox interface or the web fake interface uh it automatically figures out the router's version and then creates the back door file however or wherever that version dictates. CleanArras gets root on versions of router arras from 2011 all the way through May of this year by using the three vulnerabilities we talked about. Uh router arras is versions three through six. All our s- all are supported uh and all architectures are supported um because again none of these vulnerabilities actually require any type of shell code. Uh another thing that actually comes with CleanArras is a little script called RASSH. Uh all you do is you upload that to your uh router and with your brand new root shell you run it and it will look for all sorts of bad stuff in the router and let you know what is there. So it's really cool that we got root and that there's this little script to find all the bad stuff in the router. Uh but this is Defcon and we want to know about all that bad stuff. Uh so let's go exploring post exploitation. Uh and first of all a small disclaimer uh could this this discussion is really gonna focus on router OS six dot oh and above uh because before six dot oh as you can see the entire file system was read right. Um so you didn't need any special tricks to hide in the system. But modern router OS is quite different uh it's full of tempfs and read only file systems uh so surviving a reboot is not necessarily a given. Um luckily uh since the last release of router OS five um was four years ago uh there's probably no more five for our version threes out in the wild. Uh there are. Uh and just one more final point before uh we start talking about the interesting stuff. Uh if you go home and you decide to route uh a router OS VM or a router you have uh do yourself a favor and upload your own busy box. Uh the built in busy box is extremely limited. Doesn't even have LS uh so it can be quite obnoxious to use. So let's start with something simple. Uh almost everything should be, let me expand this. Almost everything on the system should be executing out of slash bin slash dash bin or slash nova slash bin. Uh and these are actually read only directories that come from digitally signed package that in theory uh should be totally trustworthy. Oops. Shouldn't be messing with stuff. Uh if you see anything executing out of slash read write or slash flash uh then you have almost certainly been owned uh so because that's persistent file save uh persistent file space that router OS does not normally use for execution. Uh finally um you should be looking at these slash package items. You can see them in the PS output uh they need to be analyzed a little closer. But before we look at these slash package items um you need to understand that everything uh in router OS is a package. Uh for example the files in Etsy and the and the binaries in bin are part of this are part of this system package you can see at the bottom of the screen. Um at boot time a squash FS file system is extracted from these packages uh and mounted as read only in the package directory. And um you know I kind of apologize for this Charlie Dayus slide uh but this is all I'm trying to say here. Uh all the packages get mounted in slash package which it's itself is a read write directory within a temp file system. Uh and because the package directory is read write anyone could add their own files there and execute them. Uh in fact pictured to the left is a very suspicious looking uh slash pack uh package slash LOL directory. Um and uh it has a very scary looking RC script. Uh so what is the take away from this slide is basically uh everything in slash package should either be uh mounted uh read only squash FS file system uh or a valid sim link into bundle. Anything else is malicious. So you can see the LOL directory and the option directory do not belong. So while it's true that package is a place that RadarOS executes from you do want to be careful and make sure nothing new has been introduced uh because if you're just looking at the PS output you'll get something like this. I'm executing busy box uh it blends right in. It doesn't belong. Uh so since we uh we're messing around in the package directory uh I personally found this a little interesting. There's this check installation button in the packages UI uh and there's not like a lot of documentation for it. There's no documentation that I could find. Um but also pictured here is a forum post of uh some guy that left his Radar open to the internet just to see what would happen. Uh and he asks a good question uh how do I know if it's been owned? Will check installation be useful? Um so uh I ran check installation with busy box running like it was in the previous slide and you can see that uh uh that RadarOS that that's just fine. Uh a different thing you want to look at is the pro- that's the slash proc slash maps for SNMP, WWW and the profiler binaries. Uh and here's a screenshot of SNMP's uh proc maps. Uh SNMP itself lives in a read only directory called Nova slash bin. Uh but you can see that I've gotten it to load a uh shared object called lol dot s o. Uh and that's basically because uh the SNMP library will loop over all the package directories uh and if it finds an SNMP subdirectory it will load any dot s o that it finds. And this is just part of that SNMP logic. As you can see uh it does compare the end of the string versus dot s o and if it is true then it will just DL open whatever. And of course hiding execution of shared library is pretty neat. So I wrote a POC that uses CVE 2019 3943 to write this to disk. Uh the POC will then stop the SNMP process and restart it uh and that way the uh the shared object gets picked up by SNMP uh and then you can see this constructor gets executed. Uh the constructor actually deletes itself and um creates the back door file so we can log in. Uh and I would again like to take a moment to be very petty and say that uh Microtik did not put out any notification to the customers about this CVE. In fact you're going to want to check the proc maps uh for all the binaries. Uh and that's because the first entry in the load library path is a directory called slash read write slash lib. Uh and you might recall I said earlier that routerOS doesn't execute out of slash read write. Uh and that is normally true. Uh in fact this directory doesn't even exist. Uh when you exploit the router you again have to create the lib directory yourself. Uh but what's really great about uh slash read write slash lib is that it lives in persistent file space so anything we add there uh will survive reboots. Uh so here we are looking at the proc maps of nova bin slash file man. Uh in all of the libraries that this binary actually wants to load uh should be in the read only directory slash lib. Uh but you can see here highlighted in red that uh I was able to load uh lib z dot s o out of read write lib. And of course uh I have a proof of concept for this one as well. Uh but this time the proof of concept is Smith's Big Indian. Uh and the way this basically worked is I downloaded the real lib z. Uh I added this silly constructor uh cross compiled the library. Uh and then I used uh CBE 2019 3943 yet again to create the lib directory and write the shared object. Uh and eventually file man will just uh restart and pick this up. Uh so uh this will create the backdoor without rebooting. Uh speaking of rebooting the system let's talk about persistence a little bit. One of the challenges uh with the backdoor file is that newer versions uh it actually got moved into temp f s package space. Uh so what that means is when you reboot the router uh the developer backdoor disappears on versions uh 6 dot 41 and above which is nearly most every release since December 2017. Uh also the behavior of upgrades is still sort of a black box. Uh lots of uh files are overwritten uh some are deleted. Uh but back to read write slash lib. Like I said uh it survives reboots like a champ. Uh lib z in particular gets loaded up somewhere very early in the boot process. Uh so the creation of the backdoor seamless. Uh and it even works on the most recent release uh which was July 19th uh 6 dot 45 dot 2 uh which is actually pictured here. Um so I actually had very high hopes that I could use this mechanism to persist across upgrades. Um unfortunately or fortunately depending on your view um the upgrade process deletes the entire read write lib directory. Uh so it's still very good for persisting across reboots. Uh very terrible for surviving upgrades. So switching gears yet again remember that everything on the system is a package uh and the packages use the MPK file format and part of that format is what appears to be uh some sort of digital signature. Uh before these packages get installed uh the signatures are are verified um and then they're stored uh in the directory slash bar slash PDB. Uh and as I've mentioned before when the system boots uh on packages the MPKs and it mounts a squash file system that's stored within. So one weird thing about uh slash bar slash PDB uh is that it's entirely read write. Uh so as root we can modify these MPK files. Uh and so uh when I figured this out I was I was just wondering what would happen if I overwrote one of these files. Uh so I had a silly experiment where I just echoed LOL over the system package. And the system package again is the one that can contains all the basic Clinixy stuff like slash bin slash lib slash XE. Uh so I overwrote it and I rebooted. And I was actually uh met with this error message. You can see it says uh no system package found. And then it went into infinite reboot. Uh so I wondered uh you know if I can overwrite a package maybe I can introduce my own. Uh so I wrote this tool called ModifyNPK. And it takes in a valid uh my Kotick MPK. And a user created a SquashFS file system. And it replaces the valid SquashFS with the user SquashFS. Uh now obviously since we modify the MPK the signature is totally invalid. But if you take the output from uh Modify MPK and uh you create your own package in slash bar slash pdb uh you reboot the system what's gonna happen? Well here you can see that I've created a package called RAS. And I've moved it into bar slash pdb and rebooted. And then you can see that my package actually successfully is installed uh despite having an invalid signature. Of course each package has their SquashFS file system mounted as read only. So what did I put in my SquashFS file system? Uh an RC script. Uh that basically just creates the back door at boot time. Uh and of course since the package was successfully installed it will survive uh reboot without any type of issue. Uh but we do finally learn what check installation does. Uh and it appears to validate uh the MPK files in bar slash pdb. Uh you can see if a user runs check installation uh when my uh my package is installed then it gets flagged as a bad image. Now my critique did eventually patch this in 6.42.1 uh but it's unclear to me if they knew they fixed this or um it just happened to get accidentally fixed uh at the bottom this is the only release note that I think could maybe sort of be related. Um but still given the number of uh pre 6.42 installs that still exist uh to me this is a pretty interesting persistence technique uh and sort of an even more interesting developer mistake. Uh so let's talk about uh RC scripts a little bit. Um I and I first saw this uh in the comment read repository uh so I can't really take any credit for it. Uh but in rather OS up to 6.40.9 uh you just you just make an RC uh directory structure off of flash slash exe um and that will be treated like any normal RC scripts uh so if you drop something like S18 LOL it will be executed uh next boot. Um and again since this is in flash it's entirely persistent across reboots. Uh super simple dead easy persistence method um fortunately uh this was fixed. And of course the system has its own RC scripts off of the exe directory uh and there are two that I want to talk about. Uh you can see first the 08 um config script uh you can it's very simple if uh slash our read write reset exists uh then it just gets executed. Um yet again another dead easy persistence mechanism uh but this was fixed after 6.40.5. Um but in 6.40.1 the script uh 12 def CF uh was actually changed so that the contents of read write def CF were executed by an eval statement. Um and this is still the case uh pictured here is 6.45.2 like I said just released in July um and this is actually the persistence mechanism that Cleaner RAS uses for these newer versions. Uh but read write def CF isn't perfect it has a couple of issues with it. Uh the first is that if uh read write def CF exists on the system and no one is yet logged in uh then it disables login for everyone uh including the back door uh so basically uh shuts down the device. Uh and the second thing is that if read write def CF exists then uh upgrade silently fail. Uh the upgrade looks like it was successful um but it will be the exact same version number uh no error logs or nothing. Uh so Cleaner RAS gets around to this login issue uh by uh using an RC scripts off of package that simply moves a staged file uh to read write def CF at shutdown. Um that seems complicated enough to me that I decided to just make a standalone POC that people can check out if they're interested. Uh basically the POC uses CVE 2019 3943 uh yet again to create a def CF file and once the system is rebooted uh the def CF file will get executed and it uh will uh put that persistence mechanism into place. Uh I never found any type of solution uh for fixing uh disabling upgrade so I'm just gonna call that a feature. Uh and in fact I never found any way uh to maintain uh execution through an upgrade. Uh although I'm sure it exists um but you know if you can't maintain execution what can you do? Uh so my solution was just to drop a sim link uh a hidden sim link in the user directory that the micro tick user can actually access. Uh you can see here I've actually FTP'd into the router and I found the sim link dot survival uh and it's a sim link to root. Uh and it's worth noting if you're using either Winbox or the web client uh neither of them show hidden files so they can't see the sim link. Uh and so this is just an example of me uh regaining execution using the sim link. Uh you see I have this def comp file, I FTP in, I traverse the sim link uh move to the read write directory and put def comp. And after a reboot um I log right in as a devl user uh and I have a full shell once again this is six dot forty six dot forty five dot two uh just released in July uh and just to prove that there uh the persistence, the reboot persistence still works uh I rebooted the system, I'm logging again and I still have my shell. Uh so that's mostly what I have for you today uh and that's uh actually a fair amount of material so I want to just provide a quick summary slide and I will not sit here and read this to you uh this is more for review uh like I said everything is on github um so you can check out the summary if you want uh but I think it's fair to say that I identified a problem with micro tick routers uh offered a solution and shared various ways I believe attackers uh could abuse the system. Uh so one of the best parts of any talk in my opinion uh is to get new ideas for your new re- new ideas for your own research uh so here are just a few things I know uh that could be tackled. Uh recently both the Winbox and JS proxy login algorithms changed uh no one has published anything about those uh that would be pretty useful uh I have never looked at the NPK loader system uh obviously we see that it has issues in the past that would probably be fun to dive into uh there are actually a lot of kernel modules micro tick has written for the system I have not peeked at any of those um and I did look briefly at package signing and verification and it looked messed up um but I'm not a crypto guy so it could just be I didn't understand it uh so someone probably do well to look at that um and of course we always need more jail breaks to expand clean our ass uh and that is all I have for you today. Appreciate everyone coming uh thank you to the goons uh and I can take any questions with what time we have left.