去年年底，我被邀请参加Facebook的Bountycon该活动是受邀者可以参加的应用安全会议，其中包括现场黑客链接。虽然参与者可以提交任何信息Facebook但是Facebook邀请我们关注Facebook游戏。因为之前测试过。Facebook产品，所以我知道这将是一个困难的挑战。多年来，他们的安全控制越来越严格——即使是像跨站脚本攻击这样的简单漏洞也很难找到，这就是为什么他们愿意为这些漏洞付出很高的奖励。因此，顶级白帽黑客经常从第三方软件的角度挖掘Facebook例如Orange Tsai着名的MobileIron MDM漏洞。
鉴于我的时间有限（由于某种原因，我迟到了），我决定专注于不进行全面的漏洞研究Facebook Gaming访问控制是简单的安全审计。然而，正如人们所期望的，移动和网页应用程序的安全性非常好。经过一番折腾，我发现了Facebook Gameroom这是一个玩程序的程序Facebook游戏的Windows本地客户端。于是，我踏上了将攻击性反向分析应用于本地桌面应用的启蒙之旅。
关于Facebook Gameroom
你还没听说过吗？Facebook Gameroom——这很正常，我以前没听说过。事实上，Gameroom2016年11月发布，被誉为Steam强大的对手，支持Unity、Flash和最近的HTML5然而，近年来，随着流媒体的兴起，Facebook将注意力转向其移动和 *** 平台。事实上，Gameroom计划今年6月退休。幸运的是，当我挖出安全漏洞时，它还没有退出市场。
我注意到的之一件事是安装Gameroom没有必要增加任何权限。这似乎是一个分步安装程序：首先，通过一个小的安装程序从 *** 上下载额外的文件，也就是说，它的安装程序不是集成的。事实上，我很快就找到了安装目录，即C:\Users\< USERNAME >\AppData\Local\Facebook\Games因为大多数用户级应用程序都在这里C:\Users\< USERNAME >\AppData所以我很快就在文件夹中找到了安装目录。这个文件夹包含了很多.dll文件和几个可执行文件。有些事情对我很重要:
1. Gameroom自带的7zip可执行文件(7z.exe和7z.dll)，可能已经过时，容易受到攻击。
2. Gameroom存储用户会话数据Cookies SQLite这对攻击者来说是一个非常有吸引力的目标。
3. Gameroom包含了CefSharp库(CefSharp.dll)，经过进一步研究，发现这是一种用途C#的嵌入式Chromium浏览器。
第三点表明，Gameroom是用.NET编写框架。我们知道，.NET可以将程序编译成通用中间语(CIL)代码，而不是机器代码，也就是说，这些代码可以在时，这些代码可以在应用程序虚拟机中运行。这样做有很多好处，比如改进.NET应用程序的互操作性和可移植性。然而，由于这些应用程序被编译成CIL而不是纯机器代码，译回接近源码的过程要容易得多，而不是纯机器代码。
对于.NET程序集，DNSpy是实际标准。逆向工程师可以使用DNSpy调试调试和分析.NET包括实时修改在内的应用程序。所以，我把FacebookGameroom.exe拖拽到DNSpy中，开始进行分析。
挖掘包含漏洞的函数
首先，我们开始查找易受攻击的函数，如不安全的反序列化函数等。限于篇幅，这里就不对反序列化攻击进行详细介绍了，简单来说，这涉及到将数据类型转换为易于传输的格式，然后再转换回来，如果处理不当，这可能会导致严重的漏洞。例如，微软就曾警告不要使用BinaryFormatter，因为BinaryFormatter不安全，也不能使其安全。
不幸的是，我在搜索“Deserialize”字符串时，BinaryFormatter出乎意料
然而，我还需要找到易受攻击的代码路径。为此，我右击搜索结果，选择“Analyze”，然后沿着“Used By”链找到了Gameroom使用BinaryFormatter.Deserialize的地方。
最后，这让我找到了System.Configuration.ApplicationSettingsBase.GetPreviousVersion(string)和System.Configuration.ApplicationSettingsBase.GetPropertyValue(string)函数。Gameroom反序列化函数用于检索应用程序的相关设置——但是这些设置是从哪里来的呢？通过对安装文件夹的调查，我发现了它fbgames.settings，这是序列化的blob。因此，如果我在本文件中注入恶意反序列化payload，您可以获得代码执行权限。然而，在此之前，我还需要找到一个反序列化gadget。根据已知的反序列化gadget我进一步搜索列表，发现Gameroom使用的是WindowsIdentity类。
在此基础上，我研究了代码执行漏洞的概念验证过程：
1. 使用ysoserial通过命令反序列化攻击工具ysoserial.exe -f BinaryFormatter -g WindowsIdentity -o raw -c "calc" -t > fbgames.settings生成了相应的代码执行payload。
2. 接下来，我会的fbgames.settings复制到C:\Users\
3. 最后，打开Facebook Gameroom，计算器就弹了出来!
虽然获得代码执行权限是件非常令人兴奋的事情，但在与Facebook经过进一步的讨论，我们同意这与他们的威胁模型不符。Gameroom它是作为用户级应用程序执行的，因此没有机会升级权限。此外，由于覆盖文件需要一定程度的访问权限（例如，需要批准才能公开列出的恶意权限）Facebook因此，没有可行的远程攻击载体。
我从当地应用程序构成的不同威胁环境中学到了一个重要的教训——在深入研究代码级漏洞之前，更好先寻找可行的远程攻击载体。
规划探索路径
点击邮件中的链接是否神奇地启动？Zoom经验？这背后发生了什么？其实很简单，只是用了定制的。URI它允许你像 *** 上的其他链接一样打开应用程序。Zoom注册了zoommtg: URI解决方案，分析以下链接： zoommtg:zoom.us/join?confno=123456789&pwd=xxxx&zc=0&browser=chrome&uname=Betty。
同样，我也注意到了Gameroom使用自定义URI方案可以单击Web浏览器中的链接自动打开Gameroom。搜索代码后，我发现Gameroom会通过FacebookGames\Program.cs来检查fbgames：URI方案：
即使Gameroom已经用fbgames://URI打开后，它将继续通过SchemeHelper分析类别：
如果URI含有gameid主机，它会用的SchemeHelper.SchemeType.Game.Game进行分析。如果使用它launch_local主机，会用 SchemeHelper.SchemeType.LaunchLocal来分析一下。所以，我从最有希望的开始launch_local路径开始，跟踪FacebookGames.SchemeHelper.GenLocalLaunchFile(Uri)：
不幸的是，即使我能通过肖像fbgames://launch_local/C:/evilapp.exe这样的URI启动系统中的任何文件(就像Facebook记录的)，但仍将被确认对话框阻止。我试图绕过格式字符串和非标准输入，但没有成功。
于是，我转过头来gameid这条路径是基于的URI中的游戏ID打开Facebook URL。例如，如果你想Gameroom中启动Words With Friends，可访问浏览器fbgame://gameid/168378113211268，这时Gameroom就会在本地应用窗口中打开https://apps.facebook.com/168378113211268。
然而，我发现了GetGameSchemeId会从URI中提取ID，并添加app.facebook.com URL但是，它没有得到验证slug是否有效ID。因此，攻击者可以重新定向本地应用程序窗口Facebook任何其他页面。
例如，fbgame://gameid/evilPage会把Gameroom重定向窗口https://apps.facebook.com/evilPage。
但是，我怎么能在这里呢？Gameroom从中重定向到攻击者控制的代码呢？这里有很多 *** ，包括滥用app.facebook.com开放式重定向漏洞。不幸的是，我手头没有这样的漏洞。另一种 *** 是重定向，允许嵌入自定义代码iframe的Facebook页面或广告。
这时，我遇到了障碍。我需要修改它。GetGameSchemeId因为它只拿代码URI之一条路径slug，所以fbgame://gameid/evilPage/app/123456将引导原始应用窗口https://apps.facebook.com/evilPage，并会丢弃/app/123456。
幸运的是，我还可以借助于其他的代码gadget。另外，在Gameroom中使用的Chrome浏览器版确实有点老：63.0.3239.132——当时的版本是86.0.4240.75。因此，它不支持新版本Facebook Pages。经典的Facebook Pages版本会接受一个sk这样，参数，https://apps.facebook.com/evilPage?sk=app_123456攻击者控制的代码位于自定义标签页面上https://apps.facebook.com/evilPage/app/123456!
但是，我们如何在自定义方案中注入额外的查询参数呢？别忘了，Gameroom会丢弃之一个URL slug之后的所有内容，包括查询参数。真的是这样吗？FacebookGames/SchemeHelper.cs，我发现了GetCanvasParamsFromQuery：
传递自定义URI之前，GetCanvasParamsFromQuery查询参数将被搜索canvas_params，并将其序列化为 *** ON并将字典转换为新字典URL，并作为查询参数。
这让我想起了最后payload方案——fbgames://gameid/evilPage?canvas_params={"sk": "app_123456"}将被Gameroom浏览器窗口中的分析成本应用https://apps.facebook.com/evilPage/app/123456，然后执行我的自定义JavaScript代码。
如前所述，原生应用的威胁环境和Web应用程序差别很大。Chrome原生窗口重定向攻击者控制Javascript三年前攻击者可以继续嵌入代码Chromium已知的漏洞在浏览器上执行。虽然代码尚未公开发布完整的漏洞，但我仍然可以使用它们CVE-2018-6056概念验证代码通过类型混淆漏洞Chrome引擎崩溃。
此外，攻击者本质上可以创造一个合法的起源MessageBoxes弹出框用于钓鱼攻击，或试图阅读缓存证明文件。幸运的是，与集成Node. *** APIs的Electron不同的应用程序，CefSharp限制了API访问。然而，它仍然很容易接受Chromium以及第三方仓库漏洞的影响。
小结
Facebook将本文介绍的安全漏洞评为高风险，并立即修复。与此同时，我升职了Bountycon排名前十。Gameroom即将退出市场，但它仍然给我留下了攻击性逆向分析的美好回忆（和实践机会）。对于应用逆向工程的新手，Electron、CefSharp以浏览器为基础的其他框架是一种很好的练习工具，可用于测试跨站脚本攻击和开放式重定向Web同时，也可以使用桌面应用独特的代码执行手段。
本文翻译自：https://spaceraccoon.dev/applying-offensive-reverse-engineering-to-facebook-gameroom若转载，请注明原文地址。