LakeCTF At your Service 题解

type

Post

status

Published

date

Dec 13, 2024

slug

LakeCTF At your Service

summary

0x00 参考

https://blog.csdn.net/q1165328963/article/details/123125342

https://gityuan.com/2016/03/05/binder-clearCallingIdentity/

https://juejin.cn/post/6856287075969925127

0x01 题目说明

首先是service1.cc 实现了一个简单的Android Binder服务，主要功能是处理用户信息并进行简单的认证。能够通过Binder 通信接收用户信息并进行处理。通过add方法添加用户信息到队列中，并在消费者线程中处理这些信息，计算密码的哈希值并存储。通过give方法进行简单的认证，但是认证不认证密码，但是如果当前用户UID=0的情况下认证成功，将FlagImpl对象的强引用写入Parcel对象中返回给调用者。

然后是flag.h 就是实际上主要内容就是下面的部分，如果拿到FlagImp强引用对象，即可通过binder调用获取flag

0x02 漏洞利用

1. binder通信过程中`pid`和`uid`变化

在Binder IPC调用过程中每个线程都有自己独一无二的IPCThreadState对象，记录当前线程的pid和uid，可通过方法getCallingPid()和getCallingUid()获取。而在A与B通信的过程中（A的binder线程通过IPC调用到B的binder线程），在B执行binder_thread_read过程中保存发送者(sender) 的uid和pid。

然后在IPCThreadState的transact收到BR_TRANSACION则会修改mCallingPid、mCallingUid。在Binder被调用端执行完后，最后将其恢复到之前的调用进程的pid和uid。

💡

这里需要注意的是，当oneway（异步通信）的的情况下mCallingPid=0，不过mCallingUid可以拿到正确值（虽然这个点和题目并没有关系）

在BBinder执行期间，它可以通过Binder的getCallingPid和getCallingUid来取到调用者的pid和uid，也就是mCallingPid和mCallingUid，以此完成可能需要的权限检查。如果此时B的binder线程要使用Binder访问本线程中的其他组件或者对象，如果这些组件或者对象需要检查访问者的IPC标记(即pid和uid)，那么此时需要将B线程保存的Binder IPC标记修改为自身进程的IPC标记，这样组件或对象针对的是B进行权限检查，这时候就需要通过clearCallingIdentity将Binder线程的IPC标记设置为当前进程的pid和uid，并将调用者A的pid和uid暂时保存起来，当B调用完后再通过restoreCallingIdentity恢复即可。

2. 题目漏洞说明

由于服务端一开始并无用户，需要通过add方法添加uid=0的用户，主要关注下面的方法，可以发现其逻辑就是直接创建一个新用户并添加，然后在后面判断IPCThreadState::self()->getCallingPid() 是否为0。

但是这里的返回值显然不会是0，因为此处的getCallingPid 由于处在一个新的线程std::thread consumer(consumerThread);中，而不是处理Binder通信的那个线程，因此这里的getCallingPid 返回的一定是service1这个服务的PID。

如果在add用户时service->transact(0x69, add_payload, nullptr, IBinder::FLAG_ONEWAY); 设置异步标志。并且在题目的onTransact 的return add(username, password, uid);前加上打印PID的信息就会发现打印出来的PID是0，也就是前面提到的oneway异步通信时将会返回0，如果不使用异步标志则会返回客户端（通信发起者）的pid。

所以这里的利用方式不是通过异步通信实现绕过的。关注上面的实现可以发现，在收到添加用户的请求后首先直接通过push_back添加新用户，而后续没有通过鉴权时才修改已添加用户的UID，那么就可以想到竞争的方式来利用。即在添加用户的同时循环登录，以寻找一个时机：已经添加好了用户，但是还没有来得及修改UID为-1