[HN Gopher] Yes, Android 14 still allows modification of system ...
       ___________________________________________________________________
        
       Yes, Android 14 still allows modification of system certificates
        
       Author : g1a55er
       Score  : 135 points
       Date   : 2023-09-15 12:27 UTC (10 hours ago)
        
 (HTM) web link (www.g1a55er.net)
 (TXT) w3m dump (www.g1a55er.net)
        
       | maven29 wrote:
       | There are ways to bypass any of these restrictions imposed by the
       | Android system, even if they were real. Android ships with eBPF,
       | so you just need root.
       | 
       | https://github.com/gojue/ecapture
        
         | RockRobotRock wrote:
         | Very cool. Does this work better than a Frida hook for
         | capturing encrypted HTTP calls while bypassing cert pinning?
        
         | 1vuio0pswjnm7 wrote:
         | https://github.com/gojue/ecapture/releases/expanded_assets/v...
         | 
         | Anyone know why there is an aarch64 nocore but not an x86_64
         | nocore.
        
         | post_break wrote:
         | How many normal phones can you root these days?
        
           | orangepurple wrote:
           | Anything that LineageOS supports
           | https://wiki.lineageos.org/devices/
        
           | modeless wrote:
           | Every Pixel phone purchased from the Google store
        
             | downWidOutaFite wrote:
             | After wiping all data and losing access to a bunch of
             | features and apps.
        
               | [deleted]
        
               | garciansmith wrote:
               | You do have to unlock the bootloader to root a device,
               | hence wiping the data, but that doesn't matter if it's
               | the first thing you do when you get the phone.
               | 
               | Features though? Maybe I don't realize all the great
               | things I'm missing out on since I've only ever used
               | rooted phones since I got my first Android device many
               | years ago.
               | 
               | As for apps, I've only heard of certain games (I don't
               | play games on my phone) and banking apps (thankfully mine
               | doesn't care, though I'd rather use a desktop web
               | interface for financial stuff).
        
               | AshamedCaptain wrote:
               | Including everything I could possibly ever want an
               | Android device for, like my bank's 2FA program.
               | 
               | It's all been slowly cooking for a decade, yet people
               | will still claim "but you can still do it with root, so
               | it's as free as before!" (or some other ridiculously
               | complicated workaround with lots of nasty side-effects)
        
               | hackermatic wrote:
               | Yup. When I updated my company's secure development
               | requirements, and compared them to others, I was
               | confronted with a lot of choices that would increase
               | security somewhat, but at the expense of user control of
               | their own devices, like refusing to function if the
               | device was jailbroken, or requiring the use of the system
               | keyboard only (which is also an accessibility problem).
               | 
               | These are tempting choices, but they go a lot further
               | than, for example, requiring only modern TLS ciphersuites
               | to be used to communicate with my servers. They dictate
               | the state of your entire device, and no one app or
               | company should have that power, unless you work for the
               | company and they issue you the device -- but even then,
               | modern MDM/MAM can and should sandbox company apps from
               | the rest of the device.
        
               | a_t48 wrote:
               | When I worked on iOS games, I ended up having to ban all
               | jailbroken devices. I didn't like doing it, but basically
               | - every cheater we found was using a jailbroken phone,
               | the number of non cheaters with jailbroken phones was
               | tiny, and it would have basically taken up all my time to
               | deal with cheaters rather than implement fun features.
               | I'd have just ignored them if it wasn't for the fact that
               | they made the leaderboards look really fake.
        
               | mintplant wrote:
               | Magisk [0] + safetynet-fix [1] can work around that.
               | 
               | [0] https://github.com/topjohnwu/Magisk
               | 
               | [1] https://github.com/Displax/safetynet-fix
        
         | kelnos wrote:
         | "Just" is doing a lot of work there. Getting root isn't always
         | possible or easy, depending on your device manufacturer. And if
         | you do manage to get root, your phone will likely stop passing
         | SafetyNet, and you'll lose access to a bunch of apps that you
         | may care about. SafetyNet can be spoofed in some situations,
         | but not all, and even when spoofing does work, it all seems
         | very brittle to me.
         | 
         | Yes, of course, you _can_ do this, but let 's not pretend there
         | aren't trade offs.
        
           | 1vuio0pswjnm7 wrote:
           | "Yes, of course, you can do this, but let's not pretend there
           | aren't trade offs."
           | 
           | Are there some words in the parent comment that "pretend
           | there aren't tradeoffs". Is it that he did not include a
           | warning about "SafetyNet". What would this "pretending" look
           | like.
           | 
           | Losing access to "a bunch of apps you may care about" seems
           | to be dependent on an assumption: that the reader cares about
           | certain unnamed apps. Yet we cannot even name these apps. We
           | cannot know what apps a user cares about unless the user
           | tells us. I know Android users that do not use any apps that
           | rely on SafetyNet.
           | 
           | Nor do we know what device manufacturer the reader may be
           | dealing with. It might be one that makes rooting easy.
           | 
           | Perhaps we can refrain from making assumptions about readers.
        
           | jeroenhd wrote:
           | In the context of "changes to Android 14", "just" is right.
           | Android has required root access for modifying random apps
           | since before Android 6, and that's only because many apps
           | didn't bother implementing certificate pinning (which was
           | already known advice at that point).
           | 
           | Alternatively, you can use ADB + Frida to pull an APK from
           | the device, inject a binary, and inject code at runtime using
           | Javascript or Python. That's much easier for intercepting
           | traffic than messing with certificate stores or eBPF ever was
           | in my opinion.
        
           | [deleted]
        
       | assassinator42 wrote:
       | Can't you still install a CA certificate through Settings like
       | you always could? https://stackoverflow.com/a/65319223
        
         | kristopolous wrote:
         | I've used this to sniff traffic on my phone to great success.
         | 
         | The MITM attacks by manipulating the keys was a godsend
         | 
         | Invaluable debugging tools
         | 
         | We need some new tact, pro-user AND pro-security - those are
         | often seen as in conflict with each other.
        
         | jeroenhd wrote:
         | You can, but that's not the system certificate store.
         | 
         | Android has two certificate stores (the user store and the
         | system store). The user store can be altered through the method
         | you linked. The system store used to be part of the system
         | image (you could always disable certificates, of course) and
         | will now be moved to an APEX location that Google can update
         | (to prevent the Let's Encrypt issue in the future).
         | 
         | To alter the system store, you need root access. At the moment
         | it's just a matter of dropping a file with the right name and
         | encoding at /etc/system/cacerts (through Magisk style overlays,
         | or by modifying the system image) but that will change soon.
        
       | twleo wrote:
       | Looks good. I hate how IOS does, especially with certificate
       | pinning, so I cannot use my ad-block http mitmproxy to block ads
       | in Apps.
       | 
       | EDIT: thanks for people clarifying that pinning is done by Apps
       | and not by IOS.
        
         | WirelessGigabit wrote:
         | Would you mind sharing your setup?
        
         | jeroenhd wrote:
         | Another note: cert pinning is made very easy by Android as well
         | (just needs a fingerprint in an XML file).
         | 
         | It's a good feature for security (stalkerware remains a huge
         | problem) but it does suck from a reverse engineering
         | standpoint.
        
         | jiofj wrote:
         | cert pinning is done by the apps, not by the OS
        
           | rwmj wrote:
           | That's a distinction without a difference in these tightly
           | controlled ecosystems.
        
             | ladberg wrote:
             | Android apps could also do certificate pinning with the
             | same effect though? In this case there isn't any difference
             | between Android and iOS in functionality.
        
         | ShrimpHawk wrote:
         | iOS is even easier than Android to add system certificates and
         | can be done without rooting or jailbreaking the device unlike
         | android. cert pinning is done by the apps not the system.
        
         | kelnos wrote:
         | That's not necessarily specific to iOS. Certificate pinning is
         | usually done inside an app, not at the OS level. An app can
         | choose to ignore the system certificate store and, for example,
         | pin the cert used to talk to its private API. This is possible
         | both on iOS and Android.
        
       | inetknght wrote:
       | Allowing a user to add system certificates a good thing. The user
       | owns the device.
        
         | shadowgovt wrote:
         | Everything in the category "the user owns the device" is
         | tricky.
         | 
         | For a lot of users, "It's really hard to break" is a value-add.
         | Every capacity the user has to modify permissions is an
         | opportunity for an attacker to compromise a device. You can see
         | an example of this in web browsers these days, where sites have
         | to `log` a big scary "Don't paste anything someone tells you to
         | paste into here" message into the built-in developer tools
         | because no matter how many safety features get added to the
         | browser security model, the dev tools can bypass them.
         | 
         | It is definitely important that the purchaser knows what kind
         | of phone they're getting (whether it's easy or hard to crack
         | open all the layers of its protection model), but "The phone's
         | protection model is easily broken by the owner" as a universal
         | absolute applied to all devices should be considered harmful.
        
           | amalcon wrote:
           | "Easily, but there's a big scary warning that the person
           | asking you to do this might be trying to hack you" is still
           | "easily". That obviously seems more consumer friendly than
           | either extreme.
        
           | michaelmrose wrote:
           | How do you make something that isn't trivially turned to
           | oppression without allowing users a trivial escape from the
           | devices protection model?
           | 
           | Isn't installing your own OS on your general purpose computer
           | a trivial out? Shall we likewise disable that ability on all
           | general purpose computers?
        
         | __MatrixMan__ wrote:
         | I agree with your first sentence. The second seems to get less
         | and less true all the time.
        
       | teakie wrote:
       | disable CAs is a thing
       | 
       | or can you add your own for every domain or something?
        
       | hospitalJail wrote:
       | Gosh I love linux/root.
       | 
       | I havent needed it on recent androids due to WFH and spending
       | more time on my laptop, but back when I was flying more for work,
       | I was much more into my phone.
       | 
       | Cant remember if it was my motorolla or nexus, but I felt like I
       | had a full fledged laptop in my pocket back then.
       | 
       | Meanwhile, one of the straws that broke the camels back for
       | Windows was the insane difficulty/impossibility of remove
       | bloatware/malware that comes preinstalled with windows 11. In
       | 2023, its mind boggling to think you have easier access to modify
       | a cellphone OS than a desktop OS.
        
         | __MatrixMan__ wrote:
         | I recently got tired of trying to hack together a sane workflow
         | on the windows computers in the lab at my university, so
         | installed nix-on-droid and gotty on my phone.
         | 
         | Now I just open a tab to my phone's IP address and benefit from
         | the big screen and full sized keyboard while still having
         | exactly the tools I'm used to having elsewhere. When I get home
         | and want to resume work on beefier hardware, I just push from
         | my phone, pull from my desktop, and I'm just where I left off,
         | except now with more resources.
         | 
         | You have to be a bit austere about your tool choices to make
         | the similarity happen (sorry VSCode), but it feels like a bit
         | of a superpower just the same.
        
       ___________________________________________________________________
       (page generated 2023-09-15 23:00 UTC)