Android攻破

本文揭示了一种在Android设备上广泛存在的远程代码执行漏洞,该漏洞可通过公共Wi-Fi网络被利用,即使设备已安装最新补丁。文章详细介绍了漏洞背景、利用方式及严重性评估。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

“你走进一个咖啡店坐下来。等咖啡的时候,你拿出你的智能手机开始玩一款你前些天下载的游戏。接着,你继续工作并且在电梯里收邮件。在你不知情下,有攻击者获取了公司网络的地址并且不断地感染你所有同事的智能手机。

等下, 什么?

尽管权限提升技术在Android上很普遍(并形成了“root”设备的惯例),但远程代码执行是一种罕见且危险得多的漏洞。它允许攻击者不经授权就在用户设备上执行特定代码。这个Bug特别另人关注,因为,即使在它被修复后过了18个月,在安装了所有补丁的最新型的Android设备上仍可被利用。想想看,如果这是真的,利用此漏洞需要付出多少努力。

我们用了两种不同的方法研究此Bug。首先,在类似公共WIFI的环境中利用它,也就是你可能在咖啡店中遇到到环境。我们启动了一些 Android设备和廉价的网络设备,开始攻击。第二步是估计普通用户有多大的可能遇到这种最坏的情形。为此,我们使用了统计分析技术,看看有多少有漏洞 的App和设备。

在开始细节之前,先了解一下此Bug的背景知识:

背景知识

它始于2012年的Javascript在addJavascriptInterface API中的远程代码执行Bug,CVE-2012-6636。此Bug允许Javascript代码获得访问系统的更大权限,这并非开发者的本意。至此,如此糟糕。MWR的研究人员在几个月后的研究结果显示有大量App使用了广告供应商的框架程序,而这些框架程序通常受此Bug影响而且还在运行时下载Javascript代码。

这些因素结合起来意味着,大量的App采用不安全的方式从互联网下载Javascript代码,因此恶意攻击者劫持下载并发动远程代码执行的攻击并不难。

还没修复?

Android 4.2修复了这个潜在的javascript漏洞。不幸的是,由于向后兼容的原因,修复只意味着在特定的场景中关闭了漏洞。现实中的Android版本碎片化和Android上的广告商业模式意味着这些场景并不常见。我们检查了Google Play上的100,000个APK文件,发现大约有12%即使运行在最新的Android设备上仍然有漏洞风险。

APK分析结果:一半没有漏洞风险,因为它们的目标SDK版本大于或等于17;剩下的31%没有使用存在漏洞的API;7%由于APK混淆或分析出错而没有分析。

另外,不管此漏洞是否被修复,超过50%的Android设备仍旧使用着低于4.2的版本。对于这些设备,没有修复程序,它们依旧存在漏洞风险。

技术点

为了修复成功,调用addJavascriptInterface的程序必须编译为API 17及以上,也就是说你的目标Android版本必须是4.2及以后的。为了兼容更多的设备,App和框架程序经常用尽可能低的API版本编译。重点就是即使运行在打了补丁程序的Android 4.2, 4.3或4.4的设备上,App仍存在漏洞攻击风险。

广告商业模式在Android中很流行:也就是App免费,开发者通过向用户展示广告而获得收入。在Android中,有超过50个不同的广告框架程序,这使得开发者很容易实现广告功能,事实上他们经常在App中使用不止一个广告框架程序。有的App发现使用了20个之多。这些框架程序大都有这种行为——当app第一次运行时,它们通过HTTP下载javascript库。这也就是说App通常不安全地下载了未验证的javascript代码,而这些代码运行在可执行任意代码的环境中。

代码的执行意味着对设备的无限制访问

迄今为止,这个漏洞仅仅允许一个攻击者在一个安卓应用环境中去执行代码。这很糟糕,但是仍然被安卓权限系统限制在单独的应用中去访问数据。然而,一旦一个攻击者有了一个在系统中的立足点,这就类似于他们可能获得额外的特权。以futex漏洞为例,它影响当前使用的每个Linux内核版本,包括安卓系统以及最近第一次被成功root的Galaxy S5。尽管他们不是等价的,但我们还是应该养成“远程代码执行”与“root权限”在严重等级上等价的习惯,因为迟早,一个下定决心的黑客将可能从一个地方蹦到另一个地方,获取设备的完全控制权。

真实世界中的漏洞利用

我们谈了如何利用漏洞和漏洞为什么如此严重。现在我们撇开分析,验证一下漏洞到底有多容易被利用。

我们从PlayStore随机下载了102,189个免费的app,并通过统计分析发现其中的12.8%存在潜在的漏洞风险。这些APK同时使用了过低的目标API版本和addJavascriptInterface API。这些APK调用addJavascriptInterface时的漏洞事实上可以通过中间人攻击的方式利用,当从互联网不安全地下载的javascript脚本时可以发起中间人攻击。

我们会测试通过中间人攻击劫持非安全的javascript下载,并注入一些javascript脚本来探查addJavascriptInterface漏洞。

测试app的漏洞

我们设置了一个充当透明web代理中间人的wifi无线接入点(AP)。它被设置为对任何接入此AP的设备在通过HTTP请求任何脚本时都注入恶意代码。AP设置了密码,以防有人误用,但本方法可以用到公开访问的AP。即使当AP不受控制时,DNS毒化或ARP缓存欺骗等技术也可以用来实现中间人代理。或者可以安装一个模仿成合法AP的假AP。也就是说,有各种方法实现中间人代理,使用wifi的任何人都将通过我们的代理访问网络。

javascript的动态性意味着我们不需要检测特定的应用程序或广告框架程序以作为目标。当运行时,恶意代码扫描整个javascript命名空间中的对象,查找不正确地使用了addJavascriptInterface API的对象,然后对每个进行漏洞测试。如果没有找到漏洞,它就静悄悄地退出,不影响app的运行。如果成功了,它将运行一个shell命令启动计算器 app(这是漏洞揭露中的一个传统,表明你完成了代码运行——如何你可以启动计算器,你就证明了可以执行任何代码)。

注入的 javascript片断

Js代码   收藏代码
  1. <span>function findVulnerableObject() {      
  2. for (var prop in window) {          
  3. try {              
  4. // If getClass() doesn’t throw, the object is vulnerable            window[prop].getClass();              
  5. return window[prop];  
  6.         }        catch(err) { }     
  7.  }      
  8. return null;   
  9. }</span>  

 

我设置好AP后,从13,119个标明有潜在漏洞的app中随机选了一些,把它们安装到接入了AP的一台Nexus 5(运行4.4.3)和一台三星XE700t(运行AOSP 4.2的x86平板)。我们只不过是启动每个App,做些简单的交互操作,就成功地在超过半数的应用中触发了远程代码执行,它们加载了通过中间人代理注入的恶意代码。

全是广告惹得

通过查看TCP/IP包的轨迹,很快发现广告框架程序就是联合使用了addJavascriptInterface和非安全HTTP下载的罪魁祸首。在我们调查的框架程序中没有一个使用HTTPS,也就意味着任何使用这些框架程序的app在非安全地下载javascript时也易受到攻击。以往的研究显示有17%的app虽然使用了HTTPS,但用法不当,但这是另一回事了。

我们认真地检查了一些app,看看使用用了哪些广告框架。AdMob是用得最多的(通常也是更新最频繁的),但我们发现用到的大量框架仍然在不安全 地使用addJavascriptInterface。在检查的app中,有超过80%的非付费app包含了至少一款广告框架。总体上讲,在识别的 2140个app中出现了4190个广告框架。

问题有多严重?

Google在PlayStore上公布了所有app的大致下载量。仅就我们手工确认了存在漏洞的小部分用例,就有超过1.5亿的下载量。这并不是说就保证会有150,000,000部有漏洞的设备,因为一台设备可能安装多个不同的有漏洞的应用。但考虑到我们在分析中发现的比例——10%的app有潜在的风险,其中有50%的有风险的app被实地测试可以被攻击——这就存在非常多有漏洞的设备。

而且,别忘了有57%的Android设备运行在低于4.2的版本上。所以即使明天所有有漏洞的app和框架打上了基于4.2的补丁,仍然有超过一半的Android设备不能修复这个漏洞。

一旦你实现了远程代码的执行,结束之前在咖啡店所描述的灾难情形,不是什么大的进步。初始化一个匹配的root权限,一个被损害的设备会变成某种中间人,它随后会进入任何网络。因此,攻击开始传播,举例来说,在自带移动设备的世界里,共同的wifi网络是那样地受欢迎。

合并设备分析器(Device Analyser)的数据

设备分析器(Device Analyser)是另外一个用于统计安卓设备的(数据)来源。其中的一项功能就是它追踪用户启动不同的应用的频繁程度。他们用足够地耐心去相互参照潜在缺陷应用的列表上的数据,给出了下面的结果:

每天每用户打开潜在缺陷应用的平均数量

过去一年左右的时间,设备分析器(Device Analyser)的数据显示设备的使用者们每天平均打开0.4-0.5个潜在漏洞的应用。或者换言之,平均一周内就有几次收到(漏洞)攻击。我们不能假 设应用的版本比我们分析过存在漏洞的版本新,因此,当我们的示例数据已不再是最新版本,与图形对应也就表现为急剧下降。如果我们对最近的APK版本重新进 行我们的分析,我们很有可能看到它仍在0.4分。DA(设备分析器:DeviceAnalyser)的数据是一个相当小的样本,让它去引导更多地关于安卓设备的结论,在整体上是困难的。

结论

我们发现,通过使用相对简单的中间人代理技术,无需特定的应用程序或设备可以远程运行有危害的应用程序,即使 Android设备安装了完全补丁。使用静态分析我们发现,相当大比例的应用很可能仍然脆弱,我们证实,通过随机测试超过一半的应用确实缺乏抵抗力。

因此,我们建议当连接到一个不可信的wi-fi无线网络时不要使用任何Android应用程序显示广告。Android App存在的漏洞,是黑客下手的首要目标,因此,要及时用漏洞检测工具Safe.ijiami去检测下,并根据漏洞做相应的修复或保护,利用Android App安全保护平台ijiami给App做加密保护,维护自己的切身利益!

【基于QT的调色板】是一个使用Qt框架开发的色彩选择工具,类似于Windows操作系统中常见的颜色选取器。Qt是一个跨平台的应用程序开发框架,广泛应用于桌面、移动和嵌入式设备,支持C++和QML语言。这个调色板功能提供了横竖两种渐变模式,用户可以方便地选取所需的颜色值。 在Qt中,调色板(QPalette)是一个关键的类,用于管理应用程序的视觉样式。QPalette包含了一系列的颜色角色,如背景色、前景色、文本色、高亮色等,这些颜色可以根据用户的系统设置或应用程序的需求进行定制。通过自定义QPalette,开发者可以创建具有独特视觉风格的应用程序。 该调色板功能可能使用了QColorDialog,这是一个标准的Qt对话框,允许用户选择颜色。QColorDialog提供了一种简单的方式来获取用户的颜色选择,通常包括一个调色板界面,用户可以通过滑动或点击来选择RGB、HSV或其他色彩模型中的颜色。 横渐变取色可能通过QGradient实现,QGradient允许开发者创建线性或径向的色彩渐变。线性渐变(QLinearGradient)沿直线从一个点到另一个点过渡颜色,而径向渐变(QRadialGradient)则以圆心为中心向外扩散颜色。在调色板中,用户可能可以通过滑动条或鼠标拖动来改变渐变的位置,从而选取不同位置的颜色。 竖渐变取色则可能是通过调整QGradient的方向来实现的,将原本水平的渐变方向改为垂直。这种设计可以提供另一种方式来探索颜色空间,使得选取颜色更为直观和便捷。 在【colorpanelhsb】这个文件名中,我们可以推测这是与HSB(色相、饱和度、亮度)色彩模型相关的代码或资源。HSB模型是另一种常见且直观的颜色表示方式,与RGB或CMYK模型不同,它以人的感知为基础,更容易理解。在这个调色板中,用户可能可以通过调整H、S、B三个参数来选取所需的颜色。 基于QT的调色板是一个利用Qt框架和其提供的色彩管理工具,如QPalette、QColorDialog、QGradient等,构建的交互式颜色选择组件。它不仅提供了横竖渐变的色彩选取方式,还可能支持HSB色彩模型,使得用户在开发图形用户界面时能更加灵活和精准地控制色彩。
标题基于Spring Boot的二手物品交易网站系统研究AI更换标题第1章引言阐述基于Spring Boot开发二手物品交易网站的研究背景、意义、现状及本文方法与创新点。1.1研究背景与意义介绍二手物品交易的市场需求和Spring Boot技术的适用性。1.2国内外研究现状概述当前二手物品交易网站的发展现状和趋势。1.3论文方法与创新点说明本文采用的研究方法和在系统设计中的创新之处。第2章相关理论与技术介绍开发二手物品交易网站所涉及的相关理论和关键技术。2.1Spring Boot框架解释Spring Boot的核心概念和主要特性。2.2数据库技术讨论适用的数据库技术及其在系统中的角色。2.3前端技术阐述与后端配合的前端技术及其在系统中的应用。第3章系统需求分析详细分析二手物品交易网站系统的功能需求和性能需求。3.1功能需求列举系统应实现的主要功能模块。3.2性能需求明确系统应满足的性能指标和安全性要求。第4章系统设计与实现具体描述基于Spring Boot的二手物品交易网站系统的设计和实现过程。4.1系统架构设计给出系统的整体架构设计和各模块间的交互方式。4.2数据库设计详细阐述数据库的结构设计和数据操作流程。4.3界面设计与实现介绍系统的界面设计和用户交互的实现细节。第5章系统测试与优化说明对系统进行测试的方法和性能优化的措施。5.1测试方法与步骤测试环境的搭建、测试数据的准备及测试流程。5.2测试结果分析对测试结果进行详细分析,验证系统是否满足需求。5.3性能优化措施提出针对系统性能瓶颈的优化建议和实施方案。第6章结论与展望总结研究成果,并展望未来可能的研究方向和改进空间。6.1研究结论概括本文基于Spring Boot开发二手物品交易网站的主要发现和成果。6.2展望与改进讨论未来可能的系统改进方向和新的功能拓展。
1. 用户与权限管理模块 角色管理: 学生:查看个人住宿信息、提交报修申请、查看卫生检查结果、请假外出登记 宿管人员:分配宿舍床位、处理报修申请、记录卫生检查结果、登记晚归情况 管理员:维护楼栋与房间信息、管理用户账号、统计住宿数据、发布宿舍通知 用户操作: 登录认证:对接学校统一身份认证(模拟实现,用学号 / 工号作为账号),支持密码重置 信息管理:学生完善个人信息(院系、专业、联系电话),管理员维护所有用户信息 权限控制:不同角色仅可见对应功能(如学生无法修改床位分配信息) 2. 宿舍信息管理模块 楼栋与房间管理: 楼栋信息:名称(如 "1 号宿舍楼")、层数、性别限制(男 / 女 / 混合)、管理员(宿管) 房间信息:房间号(如 "101")、户型(4 人间 / 6 人间)、床位数量、已住人数、可用状态 设施信息:记录房间内设施(如空调、热水器、桌椅)的配置与完好状态 床位管理: 床位编号:为每个床位设置唯一编号(如 "101-1" 表示 101 房间 1 号床) 状态标记:标记床位为 "空闲 / 已分配 / 维修中",支持批量查询空闲床位 历史记录:保存床位的分配变更记录(如从学生 A 调换到学生 B 的时间与原因) 3. 住宿分配与调整模块 住宿分配: 新生分配:管理员导入新生名单后,宿管可按专业集中、性别匹配等规则批量分配床位 手动分配:针对转专业、复学学生,宿管手动指定空闲床位并记录分配时间 分配结果公示:学生登录后可查看自己的宿舍信息(楼栋、房间号、床位号、室友列表) 调整管理: 调宿申请:学生提交调宿原因(如室友矛盾、身体原因),选择意向宿舍(需有空位) 审批流程:宿管审核申请,通过后执行床位调换,更新双方住宿信息 换宿记录:保存调宿历史(申请人、原床位、新床位、审批人、时间) 4. 报修与安全管理模块 报修管理: 报修提交:学生选择宿舍、设施类型(如 "
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值