Rooting The Cradlepoint IBR600 And Other Stories

okay thank you very much thank you for the invitation it's a pleasure to be here at besides Munich um and to talk um about embedded security which is something different from what we hear uh this morning but it's interesting I can promise you um my name is Sebastian I am what is called a security researcher and um I'm especially interested obviously in eded devices and Hardware security my favorite topics actually are side chel attack and fex uh now to set the expectation today there won't be any s attacks and fault attacks in this talk but I promise you it will be interesting even without them so please stay and yeah this is a joint uh work I did uh with uh Davin um it was an excellent teamwork we learn a lot from each other and you see here or Twitter or X or whatever it is called now handles if you want to contact us uh agenda first I will present you the target of evaluation so the device um which we had a look at then we will go into the main story which is getting root privileges in in this particular device then we will have a look at the FMA updates Firma upgrade process and some interesting vulnerabilities there and at the end uh some stuff about Cloud connectivity because yeah everything ends up in the cloud today and we will conclude so the target of evolation is a rout I rooted here uh from the company called cradle point which is a us-based company um this company is maybe not that well known in in Europe uh it is now part of the Ericson group just to know and it's uh what they call Semi rout yeah you you see it it's not like the rout you have at home it's a little bit more rized um used for Public Safety that's a station from the website public safety support for Mission critical iot I guess it is like fire brigades and police it's a router so it has a lot of uh connectivity so we have Wi-Fi for sure we have an LTE 4G modem um lar and run connections and of course Cloud so this device uh will connect to an own cloud so the cloud from um credle point which is called net Cloud for device and Fleet Management it has also an internal uh web server for configuration and as you see um here on the on the right side uh this is from Zoom I you see how many devices are now accessible uh in in the internet so I mean they are accessible as a server right not not as a client so to sum up um this guy here has a very wide attack surface so a very large attack surface uh we can have a look at many different things so we have to focus a little little bit um we obviously had to look at what what was already done on this device not much was uh was public so there is this uh website here uh someone disclosed some vulnerabilities um and you see here a lot of hardcoded credentials which is somehow typical for unbedded devices so you may have some maintenance account or whatever with a hardcoded password not that good but on the positive side of things they fixed everything so we had the chance to check and everything which has been disclosed was already fixed and again lots of aced credentials this is something uh we see a lot in eded devices and now let's open the box right soor you don't see it but yeah and sorry for the mess um I added some specific features here um so what do we see first we see on the on the left side here the main CPU which is a qualcom CPU no surprise here we have a router so qualcom uh this CPU uh is connected to SD ram now DDR3 it's not that new you see this middle cases so you don't see the sdam chips but there is there are metal cases the reason is Emi because we have a rout so we have a lot of analog signals here RF signals uh uh dealing with a lot of RF signals so and and this guy here is uh producing a lot of perturbation so everything is just switching a lot so like d sdam so therefore they put it under this case and hope that it will be quiet um on the bottom the termal PA over a modem so a 4G modem a fascinating stuff but um not part of this evaluation today um but if you have a look what people are doing now uh with 4G or whatever modem basement stuff is just fascinating so the the microprocessor does not have any any embedded flash so it needs some nonvolatile memory and we have a typical combination here of uh non Flash and nor flash so nor flash is more reliable so it is used for the boot process but it is also more expensive and non flash is used for the RO file system the application user data and so on and some stuff here related more to the PO Supply so what's uh what's the beginning of uh of this adventure so now we know a little bit more of about the architecture let's have a look at the boot process which is always something uh as a security researcher was always uh have a look at it and it's there are some interesting stuff here so we were looking uh for a Serial interface a uart um normally this kind of Serial interface at boot time give gives you some information about the boot process so what kind of boot LW is used how is the boot process and we found um here on the right side the uart pins but um it was not to ctiv so we just uh it just gave some very limited information about a qualcom bootloader and then it stops completely so now the challenge was how to make it a little bit more talkative so and for that we had a look at the nor flash as I said the nor flash uh so the nonvolatile memory contains the boot information so the boot blader itself and some variables and to dump nor flash uh I use my favorite Tool The Bu parot um which is and with flash home together and with that it's very simple simple you can dump any small SPI nor Flash so SPI is the communication best used between the microprocessor and and the N Flash and then we found out that uboot is used so uboot is a typical Bootloader for embedded device which are using embedded Linux and with uboot um uboot is using what is called what are called environmental variables and these variables are mainly stored in plain text so in in in strings in aski strings in in in the binary or outside in a specific file in that case it was embedded in the binary and you can see here a few of them and especially there is one environmental variable which is called silent and you guess what it was said to yes and you guess what we set to no so um so we just remove this and and set it to no and then oh we got a uboot console which is a very nice achievement right everybody wants a uboot console and with the uboot console you can then do a lot of more stuff like having a look in the flesh and downloading some file into sdram via tftp and a lot of uh fascinating stuff so an interesting point is um is that we were able to change the variable and the device boots without noticing it so uh because secure boot is not in place so secure boot is here normally in eded device especially important um to prevent this kind of stuff so normally you will sign the every piece of software which is going to run in in your device and then at boot uh time the processor system will check the signature before it executes this particular piece of software and this is not done here right and to do that you need a public key public private key uh uh system and for signature verification obviously do you just need the public key which you put normally in uh in the microprocessor itself so in So-Cal fuses so it's a kind of mini uh nonvolatile memory which can be used for that and here again no secure boot so we can change the uh environmental variables and we get a uboot console okay now we have the content of the N Flash and as I said there is a non flash which is much bigger also much cheaper and this non flash contains the root file system the canel the application and um a lot of user data so now non flashes are a little bit more complicated to d right because they have all this B bu management e and stuff they are not that way relable so you need a a software layer on on top of that you cannot access them just uh row and unfortunately bus pet and uh flashrom do not support that so now the IDE here was to record the SPI activity so as I said the SPI is the bus between the microprocessor and the Flash to record the the activity of the SPI bus during Boot and then extract this information to extract to have the root file system and the and the can and uh we did that that with this excellent logic analyzer here the sal sal I don't know how to pronounce it in English actually and um you see there are blocks of data and this guy can also decode all the SPI uh information and then with a few um scripts we were able to remove the handshake information between the blocks right you have some handshake so you need to concatenate everything and then we add everything the root file system the Kel um yeah and that's it no surprise here the root file system as you can see here is in squash FS format squash FS is mainly used also in um eddit devices but the very big surprise for me was that the middleware or application was in python python in embedded was for me um yeah was new another point is we were able to extract this uh data because they were not no not encrypted obviously um what you can do here if you want to prevent this kind of attack you can encrypt your data at rest in in Flash and then uh in the boot process the microprocessor will decrypt the data puts them in in the sdram in plane and so and afterwards it runs from the eam however and then it comes to side Channel attack then you can do side Channel attack because the key is in the microprocessor you cannot just extract it so you can um just uh uh measure some physical Elations and with a kind of magic then you get the key yeah it's very very short uh but anyhow you can do also what we call a CO what you call a cold boot attack because as I said this information will be stored in the SD ram in plain so if you are able to put firmware inside the microprocessor so you do a reset without uh switching the device off then the data will be in the sdram so there will be Remnant in the sdram and you can extract the data of the sdram this is also another possibility okay now let's have a look at the application of the middle rare So as I said python is used quite fascinating um but not the python code obviously is stored in the device but the bite code so a kind of compiled code Um this can be very easily decompiled there are tools out there that this DEC compile 3 and obviously can be recompiled so you can decompile it patch it recompile it and here is an interesting script which runs at at boot time um which they made to reactivate the silent mode in case some people like me tried to deactivate it so it will be reactivated and you guess what we patched Al this strip so that we had no no problem with this uh uh with this uh silent mode but you see here it's very nice right it's it's just decompiled from the device so you see python script Nothing Like binary and so on so it's it's from an attacker perspective it's very nice okay now our goal is to get root privileges in this device there is a shell implemented um which is is called the CP shell I guess for credle Point um this shell is accessible via SSH or the web interface but it is very limited it is not a full Linux shell and now we found out in in the CP shell script which is also a python script that uh there is a protected command called sh which reactivate or activates uh um a full Linux uh shell and the goal here now is to patch uh this uh this particular uh to have to act to reactivate this sh command and you see here normally if this Superior variable is set to to true then it will be activated otherwise it won't be activated and the result is just an OS Command right being sh and that's all so unfortunately in that case it was not possible to decompile this big python script bit error free it happens a lot there is no I mean DEC compile 3 is very good but um a lot of times we had trouble with decompiling so in that case um we had to go to the next level uh to the assembly level and there is interestingly also an assembly level in Python uh you can disassemble the code with this uh with this tool and then you see these kind of things it is still very readable right you see all the variables in plain text and and the line of code so to find out the right place was not that difficult uh and here you see a Branch jump if false and we patched it with jump if true so that the variable the command sh was reactivated there is a pitfall here because the up codes of the of the of python are changing with each python version so be careful um if you do that do um try with this module to get the right upcut so the right uh binary uh for the for each up code the right value and then you take your favorite hex editor and you patched the right position so where the up code is for the jump if fals and you patch it to jump it through and yeah this was a workaround in case a python um bite code is not is not decompiled error free and now we are almost here um we still have to reflash all that um root file system inside the device and as I said flashing a non flash is a little bit complicated so but we have a ubut console right and ubut console with a ubut console you can download via tftp a live image inside us SD ram and run it from there and then the idea here was to take a live image from this uh uh from this open source project open w probably you know it it's a open source project for routers so they provide you with images for your particular router and in that case there was no image for this router but there was an image for this microprocessor so for the qualcom one and we triy this out um we have to modify a few things and then it it worked right we got a Linux shell via this live image it's it has nothing to do with a credle point fmer but we have a live image a live uh Linux image working on the device and then we have the um the layers which we need to flash the non flash which I called this U layer so we need this UB layer to flash the non flash because uh as I said we have this bad block management for example and so we need this layer and with these three commands here it was possible to reflash here the Kel but you can do the same uh with a root file system and with that we were able to ref flesh or patch version of um of the F and we reboot it and the sh command was activated and so we had a Linux shell and uh yeah with that that's the end of the first story um to sum up uh we first dumped all the content of the nor flash of the non flash we had a uboot console then uh we were able to patch the application which is in python python bite code okay you have to uh maybe go to assembly but it's not like assembly from a binary it's much easier and then ref fles in the device and then you get uh a r end of the first story now let's have a look at some other interesting stuff F update which is also something extremely critical and extremely interesting of course you need F update to patch your device um but on the other hand if you are not careful with the security of of this F update process you may get into very very big trouble because if an attacker is able to put an firmware like like we did here locally um then it's it's gone right it's permanent in the device so this is very important to secure the F update process and yeah there are obviously there are solution for that and here um we downloaded some images from the web server so their their F update process is now based on the cloud which is state-ofthe-art but they still have some older fare update images in the web server and for ozen so we decided to download it and to have a look the F update images were encrypted which is good but obviously um there is a global key there because because of logistical re reason right you cannot encrypt if you if you provide a binary or dat image in your website you cannot provide it encrypted for each device or let's say it's much more complicated so now we have the content of the root file system where the F will be decrypted so we have to have a look where the key is now here in that case it was a little bit of fiscated but still it is in the root file system right this is not not a problem to get the key now as I said at the beginning with the secq there is also a possibility here to do it a little bit uh better if the hardware has the capability you can also put uh this key into fuses so that U the um an attacker cannot just get the key from the root file system okay now we decrypts we decrypted the uh image and and so that there are three parts a header with a version string the body and the signature now interestingly enough the signature is only computed on the body not on the header so the header is not protected so first problem second problem this lines of Cote if the version is less than this number then signature verification will be skipped um now we see the problems together you just have to put a a string here which match to a version number which is less than that and then you can do whatever you want you put whatever signature you want the device will accept it because it's unfortunately because of Legacy reasons probably um it is there which means SEC W is completely broken it happens unfortunately a lot but they patched it okay and now we um go to the last uh stories um the because every iot device nowadays is connected to some kind of cloud so we decided to have a look at the cloud communication so this device um connects to its own cloud the net Cloud via TLS super but yeah but now we have the root file system and there is no secure boot so that we can add or own root certificate to the trusted store and the device will just trust it and this is also a problem if you do not um have secure boot or if you do not have integrity protection of your trusted story right the word thrust is not here for nothing um and if you can patch it and add an own root certificate then you can use this uh very nice tool here the money in- the middle proxy to decrypt the communication so basically you put in the trusted store the root the root CA of the man in the middle proxy and then it will Comm it will build a communication to the man in the middle proxy because it will trust this the root CA of the man in the middle proxy and then we and then man mid proxy talks to to the to the Cloud Server and then you can decrypt the communication man in the middle right and as I said um this is very important to take care about integrity of uh your trusted store uh especially in embedded devices and then then we found this one and this is the best one right um we had a look at the traffic and um we found out this this lines here with this base 64 uncoded string and it it came out that this is a a serialization a serialize python and in Python um I didn't know that there is also a calization module which is called pickle and if you have a look at the website the document website of the of this module there is a big red warning right it is not secure and the reason is and it's quite fascinating for me coming from off of the hardware side you can just with this few lines of codes execute OS command on the remote side and then with this command you will probably understand what it is it's a it's a reverse shell right so you get a reverse shell on your side so takeaway here is um be careful not use using python this serialization in uh uh in some data that you cannot trust and here since we had the possibility to decrypt and to change the traffic um we were able to change this particular string and we did that in the other s so not on the server obviously but uh the the device itself has the same capabilities so we injected uh these lines of codes um and we got a reverse shell from the device now and if you want to have a look if you want to to uh have details about this uh python pickle and how to exploit it there's this very good uh blog post here uh which gave all the information yeah so obviously calization is not only in Java it's also in Python it's very very dangero