上周，译者透过试验FacebookAndroid应用领域APP，辨认出可以借助其聊天室的文档浏览机能同时实现特别针对FacebookAndroid应用领域的任一流程执行（ACE）。

安全可靠漏洞辨认出

译者在试验Facebook聊天室文档的浏览机能时辨认出，其有三种文档浏览监督机制。假如使用者间接从聊天室回帖中浏览文档，所以将透过内建名叫DownloadManager的Android服务项目浏览，，这是一种安全可靠的文档浏览形式。假如使用者要从聊天室的文档条码（ Files Tab）中浏览文档，所以FacebookAndroid应用领域Sonbhadra以获取文档，接着将其无过滤器举措地留存到浏览产品目录中。下列是存有安全可靠漏洞的复原后的标识符短片，复原前的标识符没有下列棕色的标识符行：

方向结点

理所应当的是，第三种浏览形式存有安全可靠漏洞。虽然Facebook在上载文档时采行的一连串的保护举措，但却很难被绕开。具体来说，FacebookAndroid应用领域使用者从Facebook聊天室文档条码中浏览的文档会被储存到使用者智能手机中的产品目录/sdcard/Downloads/FILE_NAME，这其中虽然未对文档名FILE_NAME做过滤器处置，引致该处存有产品目录结点安全可靠漏洞。后，我立刻想不到的是，若想用方向结点的形式改写全面覆盖掉流程的原先流程库同时实现流程执行。

接下去，布季谢Burp全权截击了文档上载的允诺包，接着把其文档名更改成 ../../../sdcard/PoC，再进行上载：

意外的是，虽然Facebook服务项目器端的保护举措，我内部结构的这个方向结点Payload文档换角了，因此其他式样的Payload也不见效，不能同时实现往/sdcard产品目录写文档的目地。

绕开保护举措

历经数次的Payload内部结构，也极难绕开安全可靠过滤器举措，最终，我返回了FacebookAndroid应用领域这类，在加进文档处终有辨认出！

从这个加进文档机能处，首先，我辨认出可以从FacebookAndroid应用领域中上载文档。因此，接下去我从智能手机中设置Burp全权，截击捕获文档上载允诺，把其中的文档名filename更改成../../../sdcard/PoC，后，Payload文档成功被上载到了/sdcard产品目录，且文档名处的方向内部结构也是有效的。

接着，我尝试在聊天室发贴中来浏览该文档，但是FacebookAndroid应用领域的DownloadManger服务项目是安全可靠的，无法找到破绽。还是在文档条码处（Files Tab）来做试验吧，首先，要明确我可以把文档上载到/sdcard/PoC产品目录。那就像之前考虑的那样，先来个路径结点，再来个对原生库的全面覆盖改写试试。

安全可靠漏洞借助

为此，我又创建了一个Android原生库标识符（Native Development Kit）来生成原生库，我把我的恶意试验标识符放到了JNI_OnLoad函数中，以便加载库文档时可以对其进行调用。如下：

#include

#include

#include

JNIEXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved) {

system(“id > /data/data/com.facebook.katana/PoC”);

return JNI_VERSION_1_6;

透过对上述恶意原生库的生成构建，再把它用前述方向结点+改写全面覆盖的形式上载到FacebookAndroid应用领域服务项目器端中。

/../../../../../data/data/com.facebook.katana/lib-xzs/libbreakpad.so

最终，以这种重写全面覆盖的形式可成功同时实现任一流程执行。

安全可靠漏洞上报和处置进程

2020.4.29  安全可靠漏洞提交

2020.4.29  Facebook安全可靠团队成功复现

2020.4.29  安全可靠漏洞分类

2020.6.16  安全可靠漏洞复原

关于赏金的讨论

当我公布该安全可靠漏洞后，Twitter上有一些网友说Facebook的赏金给少了，于是，我就试图和Facebook安全可靠团队进行一些讨论。但他们说这个赏金数额是非常公平合理的，不管了，那就这样吧，反正安全可靠漏洞已上报了。也许没报之前还有讨价还价的余地。

参考来源

精彩推荐