Can You Get Root With A MITM Attack?

[opticyclic]

I have a Samsung A535w which doesn't have OEM unlock enabled so I can't unlock the bootloader and thus I can't get Root.

Is it possible to use a man in the middle attack to hijack an update to enable the option?

Alternatively, can I install a rootkit to do a similar thing?

Are either of these even theoretically possible?

I read about rootkits coming from apps in the PlayStore all the time.
Does the bootloader need to be unlocked to do this?

Ignore the implicit dangers of this and assume that I am going to craft the attack updates myself.

 

[$cronos_]

I have a Samsung A535w which doesn't have OEM unlock enabled so I can't unlock the bootloader and thus I can't get Root.

Is it possible to use a man in the middle attack to hijack an update to enable the option?

Alternatively, can I install a rootkit to do a similar thing?

Are either of these even theoretically possible?

I read about rootkits coming from apps in the PlayStore all the time.
Does the bootloader need to be unlocked to do this?

Ignore the implicit dangers of this and assume that I am going to craft the attack updates myself.

hello, i cannot find any info on this device, is the processor mtk, qcom, or exynos

 

[xXx yYy]

To root a phone's Android it's never needed to unlock phone's bootloader: this is a fairy tale which is told hundreds of times here and elsewhere.

 

[V0latyle]

I have a Samsung A535w which doesn't have OEM unlock enabled so I can't unlock the bootloader and thus I can't get Root.

Is it possible to use a man in the middle attack to hijack an update to enable the option?

Alternatively, can I install a rootkit to do a similar thing?

Are either of these even theoretically possible?

I read about rootkits coming from apps in the PlayStore all the time.
Does the bootloader need to be unlocked to do this?

Ignore the implicit dangers of this and assume that I am going to craft the attack updates myself.

Assuming the OEM uses the AOSP model (which Samsung doesn't), no.

Hardware backed Keystore
SELinux
Trusty
Android Verified Boot

All of these work together.

When the bootloader is locked, the boot image is verified (using a cryptographic hash signed by the hardware keystore, which is itself verified) to determine its integrity. This prevents persistent rootkits.
During run time, SELinux enforces access control over all processes, even those with root privileges.
Trusty is a completely separate and isolated secure environment that runs alongside the Android kernel and is used as a "trusted verifier"

And this isn't even getting into the security features implemented in the update process.

For this attack vector you're describing to work, you would have to have the OEM's private and proprietary key used to sign everything in the update package, otherwise an unsigned or incorrectly signed package will be rejected. And even if you did manage to sign the update package, you'd have to essentially reprogram the hardware keys to match, because even if the update flashed to the device, all the images would fail verification because of the hardware keystore authentication.

To root a phone's Android it's never needed to unlock phone's bootloader: this is a fairy tale which is told hundreds of times here and elsewhere.

Source?

How do you get elevated permissions in a protected environment without compromising the boot image, which would make the device fail to boot?

 

[xXx yYy]

Source?

How do you get elevated permissions in a protected environment without compromising the boot image, which would make the device fail to boot?

You probably don't know how rooting Android is accomplished: no elevated permissions are needed to run SU binary.

 

[V0latyle]

You probably don't know how rooting Android is accomplished: no elevated permissions are needed to run SU binary.

Explain?

 

[opticyclic]

hello, i cannot find any info on this device, is the processor mtk, qcom, or exynos

Samsung Galaxy A53 5G - Full phone specifications

www.gsmarena.com

Although it says exynos on that page, I believe this is a Snapdragon as it has the W suffix on the model and as I am in Canada it looks to be the US version.

PSA: There is No OEM Unlock on US Galaxy A53's

Whether you get a carrier version or the factory unlocked U1 model, OEM unlock does not exist on this phone. So those in the US that were thinking of doing custom roms with this cheap new Android device, look elsewhere.

forum.xda-developers.com

Assuming the OEM uses the AOSP model (which Samsung doesn't), no.

Hardware backed Keystore
SELinux
Trusty
Android Verified Boot

All of these work together.

When the bootloader is locked, the boot image is verified (using a cryptographic hash signed by the hardware keystore, which is itself verified) to determine its integrity. This prevents persistent rootkits.
During run time, SELinux enforces access control over all processes, even those with root privileges.
Trusty is a completely separate and isolated secure environment that runs alongside the Android kernel and is used as a "trusted verifier"

And this isn't even getting into the security features implemented in the update process.

For this attack vector you're describing to work, you would have to have the OEM's private and proprietary key used to sign everything in the update package, otherwise an unsigned or incorrectly signed package will be rejected. And even if you did manage to sign the update package, you'd have to essentially reprogram the hardware keys to match, because even if the update flashed to the device, all the images would fail verification because of the hardware keystore authentication.

Thanks for the info.

 

[V0latyle]

@pndwal since you're much more knowledgeable on this topic than I, care to jump in here?

 

[pndwal]

@pndwal since you're much more knowledgeable on this topic than I, care to jump in here?

Topic of temp root etc using vulns / exploits?; All I know is from reading...

This 'Deployment' developer doc was removed in January but mentioned Magisk deployment via exploits:
https://github.com/topjohnwu/Magisk...62964e41201b9f157923b/docs/deploy.md#exploits

I believe this temp MagiskSU from such a root shell can then often be used to flash/obtain full-fleged Magisk root...

Exploit / vulnerability based root certainly has benefits, one of which is ease of properly (and fully) bypassing device integrity attestations since kernel can be modified while bootloader remains locked... John commented here (and on future potential):
www.twitter.com/topjohnwu/status/1299903496028790785
... Doubt he'll be elaborating on this any more somehow...

There may not be many useful exploits for root due to security research, pen testing, patching, anti rollback etc... Here's a recent one that can be leveraged for Pixel 6; POC here:
https://github.com/polygraphene/DirtyPipe-Android
... This is already patched from 2022-04-05...
Could be used for Realme GT2 Pro, some Galaxy S22 models, others(?)... The process notes may be enlightening: https://github.com/polygraphene/DirtyPipe-Android/blob/master/TECHNICAL-DETAILS.md#exploit-process

XDA article re. 'infamous "Dirty Pipe" vulnerability can be exploited on the Samsung Galaxy S22 and the Google Pixel 6 Pro to gain root shell access':
https://www.xda-developers.com/tag/root-exploit/

This vuln caused a minor furore over Google anti-rollback w/ A13 update etc... Ex XDA editor Mishael commented:
www.twitter.com/MishaalRahman/status/1511036735433715719
Johns here:
www.twitter.com/topjohnwu/status/1511107456566390785
... I want "MagiPipe" One-Click Root app w/ the rainbow Magikarp icon!
Further:
www.twitter.com/topjohnwu/status/1559786740050644992
And Shawn Willden on patching, anti-rollback counters etc here:
www.twitter.com/shawnwillden/status/1559893884120928256

Older 'Linux Kernel bug dubbed 'Dirty Cow' can Root every version of Android' article by Mishael:
https://www.xda-developers.com/9-ye...-dirty-cow-can-root-every-version-of-android/

PW

 

[pndwal]

Assuming the OEM uses the AOSP model (which Samsung doesn't), no.

...

Please can you explain what you mean here?... I understood '(AOSP) is the bedrock of modern Android skins like One UI and MIUI'...
https://www.androidauthority.com/aosp-explained-1093505/

Is this wrong?...

Can't see how even heavy OEM Android OS skins would make a difference to OEM unlock (or even using a root kit hypothetically)... Aren't unlock options etc determined by OEMs and re-sellers?...

And user does have Samsung device anyway... PW

 

[V0latyle]

...

Please can you explain what you mean here?... I understood '(AOSP) is the bedrock of modern Android skins like One UI and MIUI'...
https://www.androidauthority.com/aosp-explained-1093505/

Is this wrong?...

Can't see how even heavy OEM Android OS skins would make a difference to OEM unlock (or even using a root kit hypothetically)... Aren't unlock options etc determined by OEMs and re-sellers?...

And user does have Samsung device anyway... PW

What I mean is whether Samsung follows the same Android security model, with verified boot, dm-verity, and so on. They do have security features implemented to prevent unsigned binaries (even if the bootloader is unlocked) but they also add a lot of their own stuff like Knox and Vaultkeeper. Either way, it would be difficult for a rootkit to persist after reboot because of these security features.

My understanding of OneUI is that it's not just a reskin/overlay but it also changes a lot of the core components as well. I could be wrong.

 

[pndwal]

What I mean is whether Samsung follows the same Android security model, with verified boot, dm-verity, and so on.

Of course they do... AVB (ie Verified Boot 2.0) is mandated for any Android 8+ certified implementation...

An AOSP-compatible device must conform to the list of requirements in the Compatibility Definition Document (CDD). An Android-compatible device must conform to the list of requirements in the CDD and Vendor Software Requirements (VSR) and tests such as those in the Vendor Test Suite (VTS) and Compatability Test Suite (CTS).

https://source.android.com/docs/core/architecture#hidl

Eg. CCD:
https://source.android.com/docs/compatibility/cdd
see 9.9.2. File Based Encryption:

• [C-1-4] MUST support Verified Boot and ensure that DE keys are cryptographically bound to the device's hardware root of trust. etc...

https://source.android.com/docs/compatibility/8.0/android-8.0-cdd

device-mapper-verity (dm-verity) is simply a kernel feature used since A 4.4 to implement Verified Boot...

They do have security features implemented to prevent unsigned binaries (even if the bootloader is unlocked) but they also add a lot of their own stuff like Knox and Vaultkeeper.

Sure; and MIUI adds Xiaomi Security Centre...

OEMs can add what they like as long as they comply with the CDD and VSR incl VTS and CTS...

Either way, it would be difficult for a rootkit to persist after reboot because of these security features.

Well maybe...

I'm unaware of any special safeguards against root whether userspace based or exploit based personally...

My understanding of OneUI is that it's not just a reskin/overlay but it also changes a lot of the core components as well. I could be wrong.

Well Android skins are necessarily software tweaks that live on top of stock Android; "They often look very different and offer features that other skins don't. In other words, underneath all the additional design and functionality tweaks, the core version of Android is on all Android devices." More on this here:
https://www.androidauthority.com/android-skins-945375/

Also these can't change security requirements for API/SDK level compliance... There is lattitude for OEMs to use their own components, but this is of course costly; Eg OEMs are free to implement their own TEE OS instead of Google's Trusty TEE, but most use Trusty as it's free and works fine!... PW

 

[opticyclic]

All very interesting. Thanks.

I remember using Dirty Cow to root a previous device.
My first phone was the Samsung Galaxy Nexus and after that I used several Chinese brands and got root on everything.
Because of the popularity of Samsung I assumed that root would be available.