Dear all.
I have found this same issue in my custom ROM as well.
My ROM is using Lollipop 5.1 with Kernel 3.4.
Kingroot apk downloads so many binaries&scripts from there server and
try to get root access with various methods.
I was trying to find a vulnerable point in kernel,
it's difficult because they're using so many binaries to root though.
It is a problem that kingroot binares are changed to init domain by vulnerable
kernel.
Now, I'm trying to add some codes in kernel to look for the attack location.
Maybe I can add some codes to force a crash when kingroot binaries are being
changed to init. Afater crash, I can collect a crash dump and will be able to
find a root point in kernel.
However, I've added some points in SELinux and kernel, but I couldn't find it.
Where would be a great point to find that?
Thanks
HAN
-----Original Message-----
From: "William Roberts"<bill.c.robe...@gmail.com>
To: jonesn5...@gmail.com;
Cc: <seandroid-list@tycho.nsa.gov>; "Stephen
Smalley"<s...@tycho.nsa.gov>;
Sent: 2015-12-02 (수) 11:23:19
Subject: Re: How to prevent kingroot.apk..
On Dec 1, 2015 9:15 PM, "심현용" <jonesn5...@gmail.com> wrote:
>
> Dear William.
>
> Thank you for your explanation.
>
> I'm doing debugging this apk a bit more.
>
>
> > Really only kernel should be allowed to transition to init. So we
likely want to verify the policy has this.
>
> As your mention, I want to find kernel source where domain changed
untrusted_app to init.
>
> But, I'm SELinux developer not kernel developer.. so please help me, where
can i find this source where change init domain in kernel?
You might not even need to go that deep. Just look at what the policy allows.
The kernel enforces the policy, assuming no defects or tampering. The tampering
could be from a kernel exploit. Use tools like sesearch.
The code that changes to init domain is likely part of the payload of the
exploit run by kingroot.
>
> I always thank you for your help..
>
> Thanks.
>
>
> 2015-11-29 22:55 GMT+09:00 William Roberts
<bill.c.robe...@gmail.com>:
>>
>>
>> On Nov 28, 2015 4:40 AM, "심현용" <jonesn5...@gmail.com> wrote:
>> >
>> > Thank you for your quick reply.
>> >
>> > I checked more detail about kingroot.
>> >
>> > It using chcon using in their toolbox.
>> >
>> > postroot.sh
>> > kr_set_perm() {
>> > #if [ -f "$5" -o -d "$5" ]; then
>> > $MY_TOOLBOX chown $1.$2 $5
>> > if [ -f "/system/bin/chcon" ]; then
>> > $MY_TOOLBOX chcon $3 $5
>> > fi
>> > $MY_TOOLBOX chmod $4 $5
>> > #fi
>> > }
>> >
>> > kr_set_perm 0 0 u:object_r:system_data_file:s0 00755
/data/data-lib
>> >
>> > kr_set_perm 0 0 u:object_r:system_data_file:s0 00755
/data/data-lib/king
>> >
>> > kr_set_perm 0 0 u:object_r:system_data_file:s0 00755
/data/data-lib/com.kingroot.RushRoot
>> >
>> > kr_set_perm 0 0 u:object_r:system_file:s0 00755 /system/xbin/krdem
>> >
>> > kr_set_perm 0 0 u:object_r:system_file:s0 00755 $1/xbin/supolicy
>> >
>> >
>> > so, their apk file and other daemon will change system_file,
>> >
>> > Why chcon needed in toolbox?
>> >
>> > It is very vulnerable to hackers..
>>
>> Whether or not chcon exists is irrelevant. One could bundle that in
the apk if they wanted to. Code is never a security boundary. The policy would
have to allow it to chcon and do other things. I bet their is more to the story
then just calling chcon.
>>
>> >
>> > even that it could change init domain..
>> >
>> > Kingroot apk also changed to init domain during rooting process..
>>
>> I'm a bit remote at the moment (sitting in the middle of a forest
hunting deer) but the policy shouldn't allow domain transitions from untrusted
app to init. Really only kernel should be allowed to transition to init. So we
likely want to verify the policy has this. I can't recall offhand.
>>
>> >
>> >
>> > Is it possible disable chcon in toolbox?
>> >
>> > Thanks.
>> >
>> > 2015-11-27 23:05 GMT+09:00 William Roberts
<bill.c.robe...@gmail.com>:
>> >>
>> >> From what I can tell, kingroot bundles up exploits on a
server and then figures out what one will work on your device and tries it.
>> >>
>> >> I would start by patching and fixing all known
vulnerabilities for a given system.
>> >>
>> >> From there, you state it does a setenforce 0. IIRC only init
has this capability, so somehow its already gotten its process context to init.
You could remove this permission and pass enforcing mode via kernel cmdline,
but that's not going to help you here. If it was able to change process context
to init, its likely doing kernel exploits and poking at kernel data structures.
A good example of an exploit that does this would be towel root. In a nutshell,
any exploit that provides the ability to tamper with kernel memory, especially
strict cred and the auxillary void * for lsms, all bets are off for selinux.
>> >>
>> >> You could start to see if a change to policy would prevent
the proper execution of a given exploit. However something like towel root used
a futex vulnerability, their is no selinux controls on futex usage, so its very
exploit dependent.
>> >>
>> >> You could, as an additional safeguard, use some type of
higher privilege mode of execution (think trustzone or hypervisor) to protect
various kernel pages like the cred and selinux structures in memory, so even
the kernel has to trap to you to write these pages. The techniques to do this
are highly architecture specific.
>> >>
>> >> On Nov 27, 2015 5:42 AM, "심현용" <jonesn5...@gmail.com>
wrote:
>> >>>
>> >>> Dear all.
>> >>>
>> >>> Thank you for your always kindly explain.
>> >>> I have some question about rooting app 'kingroot'
>> >>>
>> >>> You can install apk bellow site.
>> >>> http://www.kingroot.net/
>> >>>
>> >>> It can root device though supolicy.
>> >>> I think It use to policy-inject, It will change
setenforce 0 (permissive mode)
>> >>> and will change permissive per domain like init,
init_shell, toolbox, etc...
>> >>>
>> >>> How can I prevent this apk's tool.
>> >>> Is it any method to fix?
>> >>>
>> >>> Please help me..
>> >>>
>> >>> Thanks.
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Seandroid-list mailing list
>> >>> Seandroid-list@tycho.nsa.gov
>> >>> To unsubscribe, send email to
seandroid-list-le...@tycho.nsa.gov.
>> >>> To get help, send an email containing "help" to
seandroid-list-requ...@tycho.nsa.gov.
>> >
>> >
>
>
_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to
seandroid-list-requ...@tycho.nsa.gov.
