Operation Triangulation The last hardware mystery Securelist
pSolutions forppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppLearn MoreppThreatsppThreatsppCategoriesppCategoriesppOther sectionspp
Research
pp
Research
pp27 Dec 2023pp
minute read ppTable of ContentsppAuthorsppToday on December 27 2023 we Boris Larin Leonid Bezvershenko and Georgy Kucherin delivered a presentation titled Operation Triangulation What You Get When Attack iPhones of Researchers at the 37th Chaos Communication Congress 37C3 held at Congress Center Hamburg The presentation summarized the results of our longterm research into Operation Triangulation conducted with our colleagues Igor Kuznetsov Valentin Pashkov and Mikhail VinogradovppThis presentation was also the first time we had publicly disclosed the details of all exploits and vulnerabilities that were used in the attack We discover and analyze new exploits and attacks using these on a daily basis and we have discovered and reported more than thirty inthewild zerodays in Adobe Apple Google and Microsoft products but this is definitely the most sophisticated attack chain we have ever seenppHere is a quick rundown of this 0click iMessage attack which used four zerodays and was designed to work on iOS versions up to iOS 162ppWe are almost done reverseengineering every aspect of this attack chain and we will be releasing a series of articles next year detailing each vulnerability and how it was exploitedppppHowever there are certain aspects to one particular vulnerability that we have not been able to fully understand ppWhat we want to discuss is related to the vulnerability that has been mitigated as CVE202338606 Recent iPhone models have additional hardwarebased security protection for sensitive regions of the kernel memory This protection prevents attackers from obtaining full control over the device if they can read and write kernel memory as achieved in this attack by exploiting CVE202332434 We discovered that to bypass this hardwarebased security protection the attackers used another hardware feature of Appledesigned SoCsppIf we try to describe this feature and how the attackers took advantage of it it all comes down to this they are able to write data to a certain physical address while bypassing the hardwarebased memory protection by writing the data destination address and data hash to unknown hardware registers of the chip unused by the firmwareppOur guess is that this unknown hardware feature was most likely intended to be used for debugging or testing purposes by Apple engineers or the factory or that it was included by mistake Because this feature is not used by the firmware we have no idea how attackers would know how to use itppWe are publishing the technical details so that other iOS security researchers can confirm our findings and come up with possible explanations of how the attackers learned about this hardware featureppVarious peripheral devices available in the SoC may provide special hardware registers that can be used by the CPU to operate these devices For this to work these hardware registers are mapped to the memory accessible by the CPU and are known as memorymapped IO MMIOppAddress ranges for MMIOs of peripheral devices in Apple products iPhones Macs and others are stored in a special file format DeviceTree Device tree files can be extracted from the firmware and their contents can be viewed with the help of the dt utilityppppExample of how MMIO ranges are stored in the device treeppFor example in this screenshot you can see the start 0x210f00000 and the size 0x50000 of the accimpl MMIO range for cpu0ppWhile analyzing the exploit used in the Operation Triangulation attack I discovered that most of the MMIOs used by the attackers to bypass the hardwarebased kernel memory protection do not belong to any MMIO ranges defined in the device tree The exploit targets Apple A12A16 Bionic SoCs targeting unknown MMIO blocks of registers that are located at the following addresses 0x206040000 0x206140000 and 0x206150000ppThe prompted me to try something I checked different device tree files for different devices and different firmware files no luck I checked publicly available source code no luck I checked the kernel images kernel extensions iboot and coprocessor firmware in search of a direct reference to these addresses nothingppHow could it be that that the exploit used MMIOs that were not used by the firmware How did the attackers find out about them What peripheral devices do these MMIO addresses belong toppIt occurred to me that I should check what other known MMIOs were located in the area close to these unknown MMIO blocks That approach was successfulppLet us take a look at a dump of the device tree entry for gfxasc which is the GPU coprocessorppppDump of the device tree entry for gfxascppIt has two MMIO ranges 0x2064000000x20646C000 and 0x2060500000x206050008 Let us take a look at how they correlate with the regions used by the exploitppppCorrelation of the gfxasc MMIO ranges and the addresses used by the exploitppTo be more precise the exploit uses the following unknown addresses 0x206040000 0x206140008 0x206140108 0x206150020 0x206150040 and 0x206150048 We can see that most of these are located in the area between the two gfxasc regions and the remaining one is located close to the beginning of the first gfxasc region This suggested that all these MMIO registers most likely belonged to the GPU coprocessorppAfter that I took a closer look at the exploit and found one more thing that confirmed my theory The first thing the exploit does during initialization is writing to some other MMIO register which is located at a different address for each SoCpp
ppPseudocode for the GFX power manager control code from the exploitppWith the help of the device tree and Siguzas utility pmgr I was able to discover that all these addresses corresponded to the GFX register in the power manager MMIO rangeppFinally I obtained a third confirmation when I decided to try and access the registers located in these unknown regions Almost instantly the GPU coprocessor panicked with a message of GFX SERROR Exception class0x2f SError interrupt IL1 iss0 power1ppThis way I was able to confirm that all these unknown MMIO registers used for the exploitation belonged to the GPU coprocessor This motivated me to take a deeper look at its firmware which is also written in ARM and unencrypted but I could not find anything related to these registers in thereppI decided to take a closer look at how the exploit operated these unknown MMIO registers The register 0x206040000 stands out from all the others because it is located in a separate MMIO block from all the other registers It is touched only during the initialization and finalization stages of the exploit it is the first register to be set during initialization and the last one during finalization From my experience it was clear that the register either enableddisabled the hardware feature used by the exploit or controlled interrupts I started to follow the interrupt route and fairly soon I was able to recognize this unknown register 0x206040000 and also discovered what exactly was mapped to the address range of 0x2060000000x206050000 Below you can see the reverseengineered code of the exploit that I was able to recognize I have given it a proper namepp
ppPseudocode for the usage of the 0x206040000 register by the exploitppI was able to match the mldbgwraphaltcpu function from the pseudocode above to a function with the same name in the dbgwrapc file of the XNU source code This file contains code for working with the ARM CoreSight MMIO debug registers of the main CPU The source code states that there are four CoreSightrelated MMIO regions named ED CTI PMU and UTT Each occupies 0x10000 bytes and they are all located next to one another The mldbgwraphaltcpu function uses the UTT region and the source code states that unlike the other three it does not come from ARM but is a proprietary Apple feature that was added just for convenienceppI was able to confirm that 0x2060000000x206050000 was indeed a block of CoreSight MMIO debug registers for the GPU coprocessor by writing ARMDBGLOCKACCESSKEY to the corresponding location Each core of the main CPU has its own block of CoreSight MMIO debug registers but unlike the GPU coprocessor their addresses can be found in the device treeppIt is also interesting that the authors of this exploit knew how to use the proprietary Apple UTT region to unhalt the CPU this code is not part of the XNU source code Perhaps it is fair to say that this could easily be found out through experimentationppSomething that cannot be found that way is what the attackers did with the registers in the second unknown region I am not sure what blocks of MMIO debug registers are located there or how the attackers found out how to use them if they were not used by the firmwareppLet us look at the remaining unknown registers used by the exploitppThe registers 0x206140008 and 0x206140108 control enablingdisabling and running the hardware feature used by the exploitpp
ppPseudocode for the usage of the 0x206140008 and 0x206140108 registers by the exploitppThe register 0x206150020 is used only for Apple A15A16 Bionic SoCs It is set to 1 during the initialization stage of the exploit and to its original value during the finalization stageppThe register 0x206150040 is used to store some flags and the lower half of the destination physical addressppThe last register 0x206150048 is used for storing the data that needs to be written and the upper half of the destination physical address bundled together with the data hash and another value possibly a command This hardware feature writes the data in aligned blocks of 0x40 bytes and everything should be written to the 0x206150048 register in nine sequential writespp
ppPseudocode for the usage of the 0x206150040 and 0x206150048 registers by the exploitppAs long as everything is done correctly the hardware should perform a direct memory access DMA operation and write the data to the requested locationppThe exploit uses this hardware feature as a Page Protection Layer PPL bypass mainly for patching page table entries It can also be used for patching the data in the protected PPLDATA segment The exploit does not use the feature to patch the kernel code but once during a test I was able to overwrite an instruction in the TEXTEXEC segment of the kernel and get an Undefined Kernel Instruction panic with the expected address and value This only worked oncethe other times I tried I got an AMCC panic I have an idea about what I did right that one time it worked and I am planning to look deeper into this in the future because I think it would be really cool to take a vulnerability that was used to harm us and use it for something good like enabling kernel debugging on new iPhonesppNow that all the work with all the MMIO registers has been covered let us take a look at one last thing how hashes are calculated The algorithm is shown belowpp
ppPseudocode for the hash function used by this unknown hardware featureppAs you can see it is a custom algorithm and the hash is calculated by using a predefined sbox table I tried to search for it in a large collection of binaries but found nothingppYou may notice that this hash does not look very secure as it occupies just 20 bits 1010 as it is calculated twice but it does its job as long as no one knows how to calculate and use it It is best summarized with the term security by obscurityppHow could attackers discover and exploit this hardware feature if it is not used and there are no instructions anywhere in the firmware on how to use itppI ran one more test I checked and found that the M1 chip inside the Mac also has this unknown hardware feature Then I used the amazing m1n1 tool to conduct an experiment This tool has a tracerange function which traces all access to a provided range of MMIO registers I used it to set up tracing for the memory range 0x2061100000x206400000 but it reported no usage of these registers by macOSppThrough an amazing coincidence both my 37C3 presentation and this post discuss a vulnerability very similar to the one I talked about during my presentation at the 36th Chaos Communication Congress 36C3 in 2019ppIn the presentation titled Hacking Sony PlayStation Bluray Drives I talked about how I was able to dump firmware and achieve code execution on the Bluray drives of Sony PlayStation 3 and 4 by using MMIO DMA registers that were accessible through SCSI commandsppppI was able to discover and exploit this vulnerability because earlier versions of the firmware used these registers for all DRAM operations but then Sony stopped using them and started just accessing DRAM directly because all DRAM was also mapped to the CPU address space Because no one was using these registers anymore and I knew how to use them I took advantage of them It did not need to know any secret hash algorithmppCould something similar have happened in this case I do not know that but this GPU coprocessor first appeared in the recent Apple SoCs In my personal opinion based on all the information that I provided above I highly doubt that this hardware feature was previously used for anything in retail firmware Nevertheless there is a possibility that it was previously revealed by mistake in some particular firmware or XNU source code release and then removedppI was hoping to find out what was located inside the second unknown region from the fix for this vulnerability implemented in iOS 166 I was able to find out how Apple mitigated this issue but they obfuscated the fixppApple mitigated this vulnerability by adding the MMIO ranges 0x2060000000x206050000 and 0x2061100000x206400000 used by the exploit to the pmapioranges stored in the device tree XNU uses the information stored there to determine whether to allow mapping of certain physical addresses All entries stored there have a meaningful tag name that explains what kind of memory the range belongs toppppExample of entries stored in the pmapiorangesppHere PCIe stands for Peripheral Component Interconnect Express DART stands for Device Address Resolution Table DAPF means Device Address Filter and so onppAnd here are the tag names for regions used by the exploit They stand out from the restppppEntries for regions used by the exploitppThis is no ordinary vulnerability and we have many unanswered questions We do not know how the attackers learned to use this unknown hardware feature or what its original purpose was Neither do we know if it was developed by Apple or its a thirdparty component like ARM CoreSightppWhat we do knowand what this vulnerability demonstratesis that advanced hardwarebased protections are useless in the face of a sophisticated attacker as long as there are hardware features that can bypass those protectionsppHardware security very often relies on security through obscurity and it is much more difficult to reverseengineer than software but this is a flawed approach because sooner or later all secrets are revealed Systems that rely on security through obscurity can never be truly secureppFamous hardware hacker Hector Martin marcan was able to figure out that what we thought was a custom hash was actually something a little different It is an error correction code ECC or more precisely a Hamming code with a custom lookup table what we call sbox table in the text aboveppThis discovery helps us understand the original purpose of this unknown hardware feature We originally thought it was a debugging feature that provided direct memory access to the memory and was protected with a dummy hash for extra security But the fact that it involves an ECC coupled with the unstable behavior observed when trying to use it to patch the kernel code leads to the conclusion that this hardware feature provides direct memory access to the cacheppThis discovery also raises the possibility that this unused hardware feature could have been found through experimentation but to do so would require attackers to solve a large number of unknown variables Attackers could find values in a custom lookup table using brute force but they would also need to know that such a powerful cache debugging feature exists that it involves Hamming code and most importantly they would need to know the location and purpose of all the MMIO registers involved and how and in what order to interact with them Were the attackers able to resolve all these unknown variables by themselves or was this information revealed somewhere by mistake It still remains a mysteryppAuthorsppOperation Triangulation The last hardware mysteryppYour email address will not be published Required fields are marked ppName ppEmail ppCancel
ppppΔdocumentgetElementById akjs1 setAttribute value new Date getTime ppAgronymous Coward ppAs you say so weird that they had all those components to access an undocumented feature like that successfully Surely Apple need to issue more of an explanationppInteresting that the earliest affected GPU is A12 as that was the first real Apple designed GPU according to Anandtech httpswwwanandtechcomshow13392theiphonexsxsmaxreviewunveilingthesiliconsecrets2 ppCould that imply that the naughty MMIO pathway had to be Apple created rather than a throwback to ARM like Coresight or PowerVR IP ppAlso I see you used m1n1 but have you had any discussion with the Asahi Linux crew They have patches for the G11P along with the other Apple GPUs and may recognise somethingppWes ppDoes this exploit affect phones running in Lockdown modeppMarku Wolf ppyesppHCS ppGensran this is a hardware level vulnerability The after that question is yes The only way you would not get this thing used against you if you were the target is for you to never have the phone online so youd have to have all radios all remote connectivity everything turned offppEddy ppEven though I dont understand a lot of it I wanted to say amazing work Boris for deconstructing the whole thing wowppWiz ppThanks brofor informing usppReuben Johnston ppThe academic community needs more case study examples like this one Thank you to the authors for sharing this researchppHasan Kilid ppIf something like this had happened to huaweixiaomi they call it chinese HW backdoor
But there are not any backdoor in US products ppJosh ppI wouldnt say an API that requires a custom hash with a custom SBOX is security by obscurity Its bigger key than most ciphersppDennis ppIf this hidden feature was known to Apple its extremely suspicious and points to a likely AppleNSA PRISMlike backdoor collaborationppAmun ppIs there a way to detect andor block such attacksppSvengaliExploit ppIn my mind this feels like an intentionally designed backdoor for bypassing hardware securityppFrancisco ppUn posible backdoor espionaje industrial Espionaje en masappAGRONYMOUS COW HERD ppThe implications of the comment by AGRONYMOUS COWARD Posted on December 28 2023 are significant If correct they indicate a deliberately introduced hardware backdoor communicated to an external third party by the manufacturer This has happened before
httpsenwikipediaorgwikiClipperchip
httpswwwforbescomsitesdaveywinder20200212ciasecretlyboughtglobalencryptionproviderbuiltbackdoorsspiedon100foreigngovernmentsppTable of ContentsppGReAT webinarsppFrom the same authorsppThe hottest research right in your inboxppΔdocumentgetElementById akjs2 setAttribute value new Date getTime ppIn the same categorypppp
Research
pp
Research
pp
Research
pp
Research
pp
Technologies and services
pp
Threat intelligence and IR
pp
Cyberthreat talks
pp
Cyberthreat talks
ppIn this report Kaspersky researchers provide an analysis of the previously unknown HrServ web shell which exhibits both APT and crimeware features and has likely been active since 2021ppAsian APT groups target various organizations from a multitude of regions and industries We created this report to provide the cybersecurity community with the bestprepared intelligence data to effectively counteract Asian APT groupsppWe unveil a Lazarus campaign exploiting security company products and examine its intricate connections with other campaignsppHow Kaspersky researchers obtained all stages of the Operation Triangulation campaign targeting iPhones and iPads including zeroday exploits validators TriangleDB implant and additional modulesppThe hottest research right in your inboxppΔdocumentgetElementById akjs3 setAttribute value new Date getTime ppThreatsppThreatsppCategoriesppCategoriesppOther sectionspp 2024 AO Kaspersky Lab All Rights Reserved
Registered trademarks and service marks are the property of their respective ownersppThe hottest research right in your inboxppΔdocumentgetElementById akjs4 setAttribute value new Date getTime p
Research
pp
Research
pp27 Dec 2023pp
minute read ppTable of ContentsppAuthorsppToday on December 27 2023 we Boris Larin Leonid Bezvershenko and Georgy Kucherin delivered a presentation titled Operation Triangulation What You Get When Attack iPhones of Researchers at the 37th Chaos Communication Congress 37C3 held at Congress Center Hamburg The presentation summarized the results of our longterm research into Operation Triangulation conducted with our colleagues Igor Kuznetsov Valentin Pashkov and Mikhail VinogradovppThis presentation was also the first time we had publicly disclosed the details of all exploits and vulnerabilities that were used in the attack We discover and analyze new exploits and attacks using these on a daily basis and we have discovered and reported more than thirty inthewild zerodays in Adobe Apple Google and Microsoft products but this is definitely the most sophisticated attack chain we have ever seenppHere is a quick rundown of this 0click iMessage attack which used four zerodays and was designed to work on iOS versions up to iOS 162ppWe are almost done reverseengineering every aspect of this attack chain and we will be releasing a series of articles next year detailing each vulnerability and how it was exploitedppppHowever there are certain aspects to one particular vulnerability that we have not been able to fully understand ppWhat we want to discuss is related to the vulnerability that has been mitigated as CVE202338606 Recent iPhone models have additional hardwarebased security protection for sensitive regions of the kernel memory This protection prevents attackers from obtaining full control over the device if they can read and write kernel memory as achieved in this attack by exploiting CVE202332434 We discovered that to bypass this hardwarebased security protection the attackers used another hardware feature of Appledesigned SoCsppIf we try to describe this feature and how the attackers took advantage of it it all comes down to this they are able to write data to a certain physical address while bypassing the hardwarebased memory protection by writing the data destination address and data hash to unknown hardware registers of the chip unused by the firmwareppOur guess is that this unknown hardware feature was most likely intended to be used for debugging or testing purposes by Apple engineers or the factory or that it was included by mistake Because this feature is not used by the firmware we have no idea how attackers would know how to use itppWe are publishing the technical details so that other iOS security researchers can confirm our findings and come up with possible explanations of how the attackers learned about this hardware featureppVarious peripheral devices available in the SoC may provide special hardware registers that can be used by the CPU to operate these devices For this to work these hardware registers are mapped to the memory accessible by the CPU and are known as memorymapped IO MMIOppAddress ranges for MMIOs of peripheral devices in Apple products iPhones Macs and others are stored in a special file format DeviceTree Device tree files can be extracted from the firmware and their contents can be viewed with the help of the dt utilityppppExample of how MMIO ranges are stored in the device treeppFor example in this screenshot you can see the start 0x210f00000 and the size 0x50000 of the accimpl MMIO range for cpu0ppWhile analyzing the exploit used in the Operation Triangulation attack I discovered that most of the MMIOs used by the attackers to bypass the hardwarebased kernel memory protection do not belong to any MMIO ranges defined in the device tree The exploit targets Apple A12A16 Bionic SoCs targeting unknown MMIO blocks of registers that are located at the following addresses 0x206040000 0x206140000 and 0x206150000ppThe prompted me to try something I checked different device tree files for different devices and different firmware files no luck I checked publicly available source code no luck I checked the kernel images kernel extensions iboot and coprocessor firmware in search of a direct reference to these addresses nothingppHow could it be that that the exploit used MMIOs that were not used by the firmware How did the attackers find out about them What peripheral devices do these MMIO addresses belong toppIt occurred to me that I should check what other known MMIOs were located in the area close to these unknown MMIO blocks That approach was successfulppLet us take a look at a dump of the device tree entry for gfxasc which is the GPU coprocessorppppDump of the device tree entry for gfxascppIt has two MMIO ranges 0x2064000000x20646C000 and 0x2060500000x206050008 Let us take a look at how they correlate with the regions used by the exploitppppCorrelation of the gfxasc MMIO ranges and the addresses used by the exploitppTo be more precise the exploit uses the following unknown addresses 0x206040000 0x206140008 0x206140108 0x206150020 0x206150040 and 0x206150048 We can see that most of these are located in the area between the two gfxasc regions and the remaining one is located close to the beginning of the first gfxasc region This suggested that all these MMIO registers most likely belonged to the GPU coprocessorppAfter that I took a closer look at the exploit and found one more thing that confirmed my theory The first thing the exploit does during initialization is writing to some other MMIO register which is located at a different address for each SoCpp
ppPseudocode for the GFX power manager control code from the exploitppWith the help of the device tree and Siguzas utility pmgr I was able to discover that all these addresses corresponded to the GFX register in the power manager MMIO rangeppFinally I obtained a third confirmation when I decided to try and access the registers located in these unknown regions Almost instantly the GPU coprocessor panicked with a message of GFX SERROR Exception class0x2f SError interrupt IL1 iss0 power1ppThis way I was able to confirm that all these unknown MMIO registers used for the exploitation belonged to the GPU coprocessor This motivated me to take a deeper look at its firmware which is also written in ARM and unencrypted but I could not find anything related to these registers in thereppI decided to take a closer look at how the exploit operated these unknown MMIO registers The register 0x206040000 stands out from all the others because it is located in a separate MMIO block from all the other registers It is touched only during the initialization and finalization stages of the exploit it is the first register to be set during initialization and the last one during finalization From my experience it was clear that the register either enableddisabled the hardware feature used by the exploit or controlled interrupts I started to follow the interrupt route and fairly soon I was able to recognize this unknown register 0x206040000 and also discovered what exactly was mapped to the address range of 0x2060000000x206050000 Below you can see the reverseengineered code of the exploit that I was able to recognize I have given it a proper namepp
ppPseudocode for the usage of the 0x206040000 register by the exploitppI was able to match the mldbgwraphaltcpu function from the pseudocode above to a function with the same name in the dbgwrapc file of the XNU source code This file contains code for working with the ARM CoreSight MMIO debug registers of the main CPU The source code states that there are four CoreSightrelated MMIO regions named ED CTI PMU and UTT Each occupies 0x10000 bytes and they are all located next to one another The mldbgwraphaltcpu function uses the UTT region and the source code states that unlike the other three it does not come from ARM but is a proprietary Apple feature that was added just for convenienceppI was able to confirm that 0x2060000000x206050000 was indeed a block of CoreSight MMIO debug registers for the GPU coprocessor by writing ARMDBGLOCKACCESSKEY to the corresponding location Each core of the main CPU has its own block of CoreSight MMIO debug registers but unlike the GPU coprocessor their addresses can be found in the device treeppIt is also interesting that the authors of this exploit knew how to use the proprietary Apple UTT region to unhalt the CPU this code is not part of the XNU source code Perhaps it is fair to say that this could easily be found out through experimentationppSomething that cannot be found that way is what the attackers did with the registers in the second unknown region I am not sure what blocks of MMIO debug registers are located there or how the attackers found out how to use them if they were not used by the firmwareppLet us look at the remaining unknown registers used by the exploitppThe registers 0x206140008 and 0x206140108 control enablingdisabling and running the hardware feature used by the exploitpp
ppPseudocode for the usage of the 0x206140008 and 0x206140108 registers by the exploitppThe register 0x206150020 is used only for Apple A15A16 Bionic SoCs It is set to 1 during the initialization stage of the exploit and to its original value during the finalization stageppThe register 0x206150040 is used to store some flags and the lower half of the destination physical addressppThe last register 0x206150048 is used for storing the data that needs to be written and the upper half of the destination physical address bundled together with the data hash and another value possibly a command This hardware feature writes the data in aligned blocks of 0x40 bytes and everything should be written to the 0x206150048 register in nine sequential writespp
ppPseudocode for the usage of the 0x206150040 and 0x206150048 registers by the exploitppAs long as everything is done correctly the hardware should perform a direct memory access DMA operation and write the data to the requested locationppThe exploit uses this hardware feature as a Page Protection Layer PPL bypass mainly for patching page table entries It can also be used for patching the data in the protected PPLDATA segment The exploit does not use the feature to patch the kernel code but once during a test I was able to overwrite an instruction in the TEXTEXEC segment of the kernel and get an Undefined Kernel Instruction panic with the expected address and value This only worked oncethe other times I tried I got an AMCC panic I have an idea about what I did right that one time it worked and I am planning to look deeper into this in the future because I think it would be really cool to take a vulnerability that was used to harm us and use it for something good like enabling kernel debugging on new iPhonesppNow that all the work with all the MMIO registers has been covered let us take a look at one last thing how hashes are calculated The algorithm is shown belowpp
ppPseudocode for the hash function used by this unknown hardware featureppAs you can see it is a custom algorithm and the hash is calculated by using a predefined sbox table I tried to search for it in a large collection of binaries but found nothingppYou may notice that this hash does not look very secure as it occupies just 20 bits 1010 as it is calculated twice but it does its job as long as no one knows how to calculate and use it It is best summarized with the term security by obscurityppHow could attackers discover and exploit this hardware feature if it is not used and there are no instructions anywhere in the firmware on how to use itppI ran one more test I checked and found that the M1 chip inside the Mac also has this unknown hardware feature Then I used the amazing m1n1 tool to conduct an experiment This tool has a tracerange function which traces all access to a provided range of MMIO registers I used it to set up tracing for the memory range 0x2061100000x206400000 but it reported no usage of these registers by macOSppThrough an amazing coincidence both my 37C3 presentation and this post discuss a vulnerability very similar to the one I talked about during my presentation at the 36th Chaos Communication Congress 36C3 in 2019ppIn the presentation titled Hacking Sony PlayStation Bluray Drives I talked about how I was able to dump firmware and achieve code execution on the Bluray drives of Sony PlayStation 3 and 4 by using MMIO DMA registers that were accessible through SCSI commandsppppI was able to discover and exploit this vulnerability because earlier versions of the firmware used these registers for all DRAM operations but then Sony stopped using them and started just accessing DRAM directly because all DRAM was also mapped to the CPU address space Because no one was using these registers anymore and I knew how to use them I took advantage of them It did not need to know any secret hash algorithmppCould something similar have happened in this case I do not know that but this GPU coprocessor first appeared in the recent Apple SoCs In my personal opinion based on all the information that I provided above I highly doubt that this hardware feature was previously used for anything in retail firmware Nevertheless there is a possibility that it was previously revealed by mistake in some particular firmware or XNU source code release and then removedppI was hoping to find out what was located inside the second unknown region from the fix for this vulnerability implemented in iOS 166 I was able to find out how Apple mitigated this issue but they obfuscated the fixppApple mitigated this vulnerability by adding the MMIO ranges 0x2060000000x206050000 and 0x2061100000x206400000 used by the exploit to the pmapioranges stored in the device tree XNU uses the information stored there to determine whether to allow mapping of certain physical addresses All entries stored there have a meaningful tag name that explains what kind of memory the range belongs toppppExample of entries stored in the pmapiorangesppHere PCIe stands for Peripheral Component Interconnect Express DART stands for Device Address Resolution Table DAPF means Device Address Filter and so onppAnd here are the tag names for regions used by the exploit They stand out from the restppppEntries for regions used by the exploitppThis is no ordinary vulnerability and we have many unanswered questions We do not know how the attackers learned to use this unknown hardware feature or what its original purpose was Neither do we know if it was developed by Apple or its a thirdparty component like ARM CoreSightppWhat we do knowand what this vulnerability demonstratesis that advanced hardwarebased protections are useless in the face of a sophisticated attacker as long as there are hardware features that can bypass those protectionsppHardware security very often relies on security through obscurity and it is much more difficult to reverseengineer than software but this is a flawed approach because sooner or later all secrets are revealed Systems that rely on security through obscurity can never be truly secureppFamous hardware hacker Hector Martin marcan was able to figure out that what we thought was a custom hash was actually something a little different It is an error correction code ECC or more precisely a Hamming code with a custom lookup table what we call sbox table in the text aboveppThis discovery helps us understand the original purpose of this unknown hardware feature We originally thought it was a debugging feature that provided direct memory access to the memory and was protected with a dummy hash for extra security But the fact that it involves an ECC coupled with the unstable behavior observed when trying to use it to patch the kernel code leads to the conclusion that this hardware feature provides direct memory access to the cacheppThis discovery also raises the possibility that this unused hardware feature could have been found through experimentation but to do so would require attackers to solve a large number of unknown variables Attackers could find values in a custom lookup table using brute force but they would also need to know that such a powerful cache debugging feature exists that it involves Hamming code and most importantly they would need to know the location and purpose of all the MMIO registers involved and how and in what order to interact with them Were the attackers able to resolve all these unknown variables by themselves or was this information revealed somewhere by mistake It still remains a mysteryppAuthorsppOperation Triangulation The last hardware mysteryppYour email address will not be published Required fields are marked ppName ppEmail ppCancel
ppppΔdocumentgetElementById akjs1 setAttribute value new Date getTime ppAgronymous Coward ppAs you say so weird that they had all those components to access an undocumented feature like that successfully Surely Apple need to issue more of an explanationppInteresting that the earliest affected GPU is A12 as that was the first real Apple designed GPU according to Anandtech httpswwwanandtechcomshow13392theiphonexsxsmaxreviewunveilingthesiliconsecrets2 ppCould that imply that the naughty MMIO pathway had to be Apple created rather than a throwback to ARM like Coresight or PowerVR IP ppAlso I see you used m1n1 but have you had any discussion with the Asahi Linux crew They have patches for the G11P along with the other Apple GPUs and may recognise somethingppWes ppDoes this exploit affect phones running in Lockdown modeppMarku Wolf ppyesppHCS ppGensran this is a hardware level vulnerability The after that question is yes The only way you would not get this thing used against you if you were the target is for you to never have the phone online so youd have to have all radios all remote connectivity everything turned offppEddy ppEven though I dont understand a lot of it I wanted to say amazing work Boris for deconstructing the whole thing wowppWiz ppThanks brofor informing usppReuben Johnston ppThe academic community needs more case study examples like this one Thank you to the authors for sharing this researchppHasan Kilid ppIf something like this had happened to huaweixiaomi they call it chinese HW backdoor
But there are not any backdoor in US products ppJosh ppI wouldnt say an API that requires a custom hash with a custom SBOX is security by obscurity Its bigger key than most ciphersppDennis ppIf this hidden feature was known to Apple its extremely suspicious and points to a likely AppleNSA PRISMlike backdoor collaborationppAmun ppIs there a way to detect andor block such attacksppSvengaliExploit ppIn my mind this feels like an intentionally designed backdoor for bypassing hardware securityppFrancisco ppUn posible backdoor espionaje industrial Espionaje en masappAGRONYMOUS COW HERD ppThe implications of the comment by AGRONYMOUS COWARD Posted on December 28 2023 are significant If correct they indicate a deliberately introduced hardware backdoor communicated to an external third party by the manufacturer This has happened before
httpsenwikipediaorgwikiClipperchip
httpswwwforbescomsitesdaveywinder20200212ciasecretlyboughtglobalencryptionproviderbuiltbackdoorsspiedon100foreigngovernmentsppTable of ContentsppGReAT webinarsppFrom the same authorsppThe hottest research right in your inboxppΔdocumentgetElementById akjs2 setAttribute value new Date getTime ppIn the same categorypppp
Research
pp
Research
pp
Research
pp
Research
pp
Technologies and services
pp
Threat intelligence and IR
pp
Cyberthreat talks
pp
Cyberthreat talks
ppIn this report Kaspersky researchers provide an analysis of the previously unknown HrServ web shell which exhibits both APT and crimeware features and has likely been active since 2021ppAsian APT groups target various organizations from a multitude of regions and industries We created this report to provide the cybersecurity community with the bestprepared intelligence data to effectively counteract Asian APT groupsppWe unveil a Lazarus campaign exploiting security company products and examine its intricate connections with other campaignsppHow Kaspersky researchers obtained all stages of the Operation Triangulation campaign targeting iPhones and iPads including zeroday exploits validators TriangleDB implant and additional modulesppThe hottest research right in your inboxppΔdocumentgetElementById akjs3 setAttribute value new Date getTime ppThreatsppThreatsppCategoriesppCategoriesppOther sectionspp 2024 AO Kaspersky Lab All Rights Reserved
Registered trademarks and service marks are the property of their respective ownersppThe hottest research right in your inboxppΔdocumentgetElementById akjs4 setAttribute value new Date getTime p
