GitHub开源AI安全代理在Android应用中发现 24 个漏洞
GitHub安全实验室用开源Taskflow Agent审计Android应用，报告了 24 个漏洞，包括OsmAnd可被任意应用静默导入设置以追踪位置，以及Wikipedia应用通过deeplink实现账户接管。
AI解读：GitHub安全实验室把针对Android应用的审计流程写成了可复用的AI任务流，并放进开源仓库seclab-taskflows，用来自动化寻找漏洞。作者Kevin Stubbings说，靠这套任务流已报告超过 20 个Android应用漏洞，博客成稿时总数是 24 个。
这套流程不是让大模型自由发挥，而是先拆分步骤：先找出攻击者可控数据的入口点，再按入口点类型核对常见漏洞类别。作者还提到同一个提示跑多次、宽松和严格提示搭配，能减少漏报。
对真正会用的人，重点在三个限制：运行需要GitHub Copilot许可证、会消耗高级模型请求和大量token，中等规模仓库可能要跑一两个小时。跑完后结果是SQLite数据库，要自己筛has_vulnerability列。
大模型找漏洞有短板。作者说它会报出现实中几乎不可能触发的问题、错估严重程度，甚至在你明确要求不要报低危漏洞时仍然报。所以每个发现仍需懂移动应用的安全研究员复核。
两个已披露的例子说明影响可以很严重：OsmAnd的导出Activity接受任意intent extras，可被无权限应用静默替换地图瓦片地址，泄露用户加载过的瓦片坐标和路线起终点；Wikipedia Android应用则因域名判断逻辑缺陷，可加载伪造的wikipedia.org页面并泄露长期有效的cookie，进而接管账户。
GitHub安全实验室的Kevin Stubbings在GitHub官方博客发文，介绍团队如何用开源的GitHub Security Lab Taskflow Agent对Android应用做安全审计，并报告了 24 个漏洞。
这套任务流放在seclab-taskflows仓库中，目标是把安全研究员认为有效的AI提示和工作流打包、复用。作者说，新模型理解代码的能力在提升，但自定义任务流提示可以让研究员把研究拆成增量步骤，帮助大模型更快找到复杂漏洞，或者找到它原本会漏掉的漏洞。
作者给出的运行方式：去seclab-taskflows仓库启动一个codespace，等几分钟初始化，然后在终端运行 ./scripts/audit/run_mobile.sh myorg/myrepo。中等规模仓库可能要跑一两个小时。跑完后会打开一个SQLite查看器，打开audit_results表，找has_vulnerability列有勾选的行。
作者明确列出了使用条件：需要GitHub Copilot许可证，提示会使用高级模型请求；运行过程会产生大量工具调用，很容易消耗大量token。
文章还点名了作者对这套流程的定位：AI驱动的安全研究是目前保护开源项目最好的方式之一，这套能力可用于Web应用、移动应用和桌面应用。
为Android应用定制的两条任务流
作者在已有审计任务流基础上做了针对Android的调整。第一条新增任务流叫gather_mobile_entry_point_info.yaml，作用是把代码中的入口点区分成移动入口点和非移动入口点。入口点指攻击者可控数据可能流经的位置。这样做让AI能跑在同时包含移动应用、Web服务器、桌面应用等多种类型的仓库上，仍然理解正确的攻击面。
第二条修改的是classify_application_local.yaml。作者在里面列出一批常见漏洞类别，要求大模型针对每个入口点和组件逐一考虑。文中给出的理由是：移动应用漏洞的公众认知度较低，而大模型是非确定性的，所以要确保它检查某些关键漏洞类别。比如上一步识别出基于intent的入口点，就应该有对应的常见intent漏洞清单，例如confused deputy或不安全广播。
作者说，把严格提示和宽松提示在多次运行中结合，才能同时拿到两边的好处：严格提示加重复运行保证明显漏洞不被漏掉，宽松提示让AI尽量发挥创造力。
OsmAnd：任意应用可静默改设置，泄露位置与路线
OsmAnd是一款第三方导航应用，以OpenStreetMap为主要数据源，在App Store和Play Store上架，Android版下载量超过 1000 万。作者称这是他们发现的三个漏洞中最有趣的一个：恶意应用可以追踪设备位置。
问题出在OsmAnd导出了一个叫MapActivity的Activity。Activity是Android应用中提供用户交互界面的单个聚焦屏幕。MapActivity负责在应用内打开设置文件和deeplink，且处于导出状态。导出意味着应用外部的组件也能启动它。打开设置文件时，该应用接受若干intent extras：settings_version、silent_import、replace、export_type_list_key。Intent是Android中用于请求另一个应用组件执行动作的消息对象，intent extras是附在intent上的键值对数据。
MapActivity原本只预期这些extras来自一个AIDL服务，本应通过进程内通道传递，而不是走intent extras。原因是任何应用都能向任何导出Activity的任意intent塞入任意extras，Android没有机制限制外部调用方可以设置哪些extras。由于MapActivity被导出，任何应用都能发intent给它，附带攻击者想要的extras，包括能静默导入设置的extras。
文章展示了handleOsmAndSettingsImport函数。其中replace、silentImport、exportTypeKeys三个值都直接来自extras，也就是攻击者可控，并被传入真正的导入逻辑。作者指出，因为可以导入任意设置，就能做几项关键修改。例如替换地图瓦片。OsmAnd按urlTemplate格式生成每个瓦片的URL，默认使用本地瓦片，但可以把默认瓦片文件覆盖成攻击者域名下的URL：f"{ATTACKER_DOMAIN}/tiles/{{0}}/{{1}}/{{2}}.png"。
这样一来，用户加载过的每个瓦片的精确x、y坐标都会发往攻击者服务器。攻击者服务器后端按请求返回OpenStreetMap对应瓦片的图片，用户端看起来一切正常。文章给出示例输出：z=15 x=9649 y=12320，中心点 40.70979, -73.98743。结论是，任何应用，哪怕没有任何权限，都能覆盖OsmAnd的设置，把私人位置数据发回自己的服务器。
同一漏洞还能拿到用户每次路线的起点和终点，发往攻击者服务器，用户察觉不到变化。文章给出示例：vehicle=car，waypoints=2，路径为 /osrm/car/-122.084,37.4219983;-122.32450103759766,37.99944305419922，起点 37.421998, -122.084000，终点 37.999443, -122.324501。
Wikipedia Android应用：deeplink加cookie泄露导致账户接管
第二个例子是Wikipedia Android应用。该应用注册了wikipedia:// deeplink以便在应用内浏览维基百科页面，形如wikipedia://wikipedia.org/wiki/PoC。文中指出hostname解析存在逻辑缺陷，导致可以加载非维基百科的URL。
相关代码片段显示：在handleIntent中，如果action是ACTION_VIEW且data不为空，就检查authority是否以WikiSite.BASE_DOMAIN结尾，若满足则把wikipedia:// 替换成默认scheme并交给PageActivity。作者说，这个原语可以让攻击者用wikipedia:// deeplink把用户导向任意网站，并让用户以为自己在维基百科页面上，实际上页面由攻击者控制。此外，攻击者还能在应用的WebView中执行任意JavaScript，这被视为一个危险原语，让攻击者进入通常被认为安全的环境。
作者指出同样的漏洞模式在同一个应用里出现了两次。第二处代码在SharedPreferenceCookieManager.kt第 101 行：如果domain以domainSpec结尾，就构建cookie列表。该片段判断某个页面是否应该带有wikipedia.org的cookie。
把两个问题串起来，就能泄露Wikipedia页面长期有效的cookie，形成一次账户接管。文章描述的链条是：受害者通过浏览器访问一个含deeplink的恶意网页并点击，Wikipedia Android应用自动打开，加载一个以wikipedia.org结尾的攻击者控制页面，比如evil-wikipedia.org；受害者以为这是维基百科页面，应用自动把用户cookie发出去。攻击者随后拿到用户名、长期token，以及在所有Wikimedia项目间有效的会话token，包括所有维基百科、Commons、Wikidata、Meta等。
大模型找得到漏洞，但严重性判断仍不可靠
作者总结说，大模型能发现逻辑漏洞并带来严重后果，不只是通用bug类型。但大模型擅长找漏洞，不擅长估计严重程度。他遇到的常见情况是：AI返回的问题需要非常特定的状态，现实中几乎不可能出现；即使明确要求不要报低危漏洞，它仍然会报低危漏洞。所以每个发现都应由有移动应用知识的安全研究员复核。
严重性评估还经常出错。实际影响常因缓解因素而下降。作者举路径穿越为例：如果文件路径被限制在外部存储，这类问题的相对严重性就低。而这类缓解因素很难被大模型看到，除非明确提示它“写一个概念验证”，并且需要多次运行，不仅为了找漏洞，也为了做概念验证，迫使大模型真正尝试利用漏洞。这取决于模型的可用性和速度，需要把额外时间花在可能影响不大的漏洞上。
即便这样，大模型仍可能出错。作者举的例子是：如果应用同时使用内部存储和外部存储的数据，内部存储数据通常优先级更高。大模型可能假设来自外部存储的数据（攻击者可通过路径穿越写入）会改变应用实际数据；但如果内部存储覆盖了攻击者控制的外部数据，就根本不存在漏洞。这类复杂行为会导致误报。作者认为随着大模型上下文增大和推理能力提升，误报会减少；但在目前，唯一的解决办法是给大模型一个调试器来运行概念验证和原始代码，或者由研究员提示大模型专门查找这些问题。
作者还惊讶于大模型对API行为的了解。他举例说，Go中用path.Clean比filepath.Clean安全性差很多，常导致影响流行产品Windows版本的漏洞。他表示，即使没有语言源代码，大模型也能很好地理解各种语言中常见安全相关API的行为。多数情况下，在给大模型一份漏洞报告后要求它生成概念验证，作者这边几乎不需要修改，说明它对以往安全漏洞和API行为有深入了解。
对于结果，作者称成稿时在移动应用中发现了 24 个Android漏洞。很多是路径穿越这类简单漏洞，也发现了一些严重漏洞，博客里展示了其中一部分。他还提到，Android应用安全性相当强，发现的漏洞类型正是安全研究员预期会出现的位置，比如WebView中的跨应用脚本，或暴露的JavaScript桥。