问答
发起
提问
文章
攻防
活动
Toggle navigation
首页
(current)
问答
商城
实战攻防技术
活动
摸鱼办
搜索
登录
注册
Piwigo_12.2.0_两枚SQL注入_CVE
漏洞分析
近期与朋友一起看的两个洞，Piwigo 的两枚 SQL 注入漏洞，二次注入的漏洞挺有意思的，在这里记录一下。
本文仅用于技术讨论与研究，文中的实现方法切勿应用在任何违法场景。如因涉嫌违法造成的一切不良影响，本文作者概不负责。 0x00 前言 ------- 近期与朋友一起看的两个洞，`Piwigo` 的两枚 `SQL` 注入漏洞，二次注入的漏洞挺有意思的，在这里记录一下。 0x01 漏洞环境 --------- `Piwigo` 可以通过 `github` 或者其官网下载。 `github` 地址：<https://github.com/Piwigo/Piwigo> 官网：<https://piwigo.org/> 0x02 CVE-2022-26266 ------------------- ### 漏洞描述 `Piwigo` 在 12.2.0 版本的 `pwg.users.php` 文件中发现一枚`SQL` 注入漏洞，可通过该漏洞获取数据库中的数据。 ### 漏洞分析 `cve` 官方漏洞描述中已经点出漏洞文件为 `pwg.users.php` ，我们直接看到这里，位于 `include/ws_functions/pwg.users.php` 这里很多数据库操作，而且很多都是在拼接，出现注入的概率确实挺大的。 这个文件全都是函数，也就是说我们无法直接访问到这里，因此现在需要做的是找到调用的位置 第一个函数是 `ws_users_getList` ，直接全局搜索该函数  在这里的 `ws.php` 中，`ws_users_getList` 被 `addMethod` 添加到 `$service` 的 `method` 列表中，实际上这里是 `piwigo` 自身定义的访问模式，这里就不细讲了，大概就是将一些路由与函数绑定在一起，当出现访问时，通过回调的方式去访问。 要想访问 `ws_users_getList` ，我们只需要访问 `ws.php` ，并 `get` 一个 `method` 参数，值为 `pwg.users.getList` 即可。 我们再回来看这个 `ws_users_getList` 的内容  `$params` 中存放的是我们请求的值与系统默认的一些值，看到上图，当我们的输入中带有单引号等特殊字符时，会自动转义，这是系统对输入值的过滤，不允许直接输入单双引号等危险字符。如上很多的拼接字符串都使用不了，因为他们都需要闭合前面的引号，我们只能找可以直接拼接而不用闭合引号的参数。 `order by` 是常用的突破点，我们直接找到此处 208 行，并在输入中输入 `order` 参数  这里我们不用闭合单引号，因此可以直接对其进行注入 ### 漏洞复现 本漏洞需要登录后台利用，登录后如下点击 ```php 用户 -> 管理 -> 用户列表 ```  抓包，但是放掉第一个包，进入第二个包如下  这里并没有 `order` 参数，我们添加进去即可，之后发包可见报错  仅验证，点到即止 0x03 CVE-2022-32297 ------------------- ### 漏洞描述 `Piwigo` 在 12.2.0 版本的搜索功能中存在一个二次`SQL` 注入漏洞，该漏洞可以从前台获取数据库中的数据。 ### 漏洞分析 #### 数据插入部分分析 我们先来到前台搜索处，随意搜索，然后抓包查看，这里游客身份进入即可 通过抓包，我们可以抓到处理搜索功能的文件为 `qsearch.php` ，进入后直接下断点  顺利进入该文件，跟进代码，看之后经历的操作，根据网上的信息，该漏洞为二次注入漏洞，因此可以格外关注 `insert into` 的数据库操作。 从上面的图中可以看到搜索的参数为 `q` ，而在代码中也有体现  这里实际上就是根据搜索的 `q` 得到 `search` 数组，序列化数组并用 `addslashes` 处理后查找，存在该搜索就更新，不存在就插入，成功插入后返回搜索的 `id` ，这里序列化操作后 `addslashes` 处理了，因此不存在直接的注入漏洞。 这里先简单说一下，其余的部分在后面写出来 #### 管理员操作部分 插入值后，寻找该值被使用的位置，直接可以搜索 `SEARCH_TABLE`  调用的位置不多，可以一个个看，主要关注取值的位置，来到 `admin/history.php` ，根据取值的位置找到如下代码  当存在`get` 的参数中存在 `search_id` 时，就会根据 `search_id` 查找 `rules` ，从上一部分的分析来看，这个 `rules` 是被序列化后的查询数据，我们也可以通过直接去看数据库内容看出来  取出来的值直接反序列化，得到 `$page['search']` ，当 `get` 的参数中还存在 `user_id` 时，则会将 `$page['search']` 序列化后再次插入数据库中，但是这里的序列化数据并没有进行处理，也就是说数据里面存在单引号等就可以直接闭合，刚好这里的数据是我们可以利用第一部分的搜索操作控制的，因此造成了一个二次注入。 这里的构造需要很巧妙，既要闭合 `SQL` 操作，又要通过序列化操作，不得不说这个漏洞发现者很强，在此之前我是想不到还可以这样玩的。 这里简单说一下构造，因为 `insert` 是支持一次性插入多条数据的，通过逗号隔开即可，我们第一步的搜索语句中，插入时存在 `addslashes` ，因此插进去时是什么样子，拿出来也会是什么样子，这里一部分先闭合，随意给一个值即可，比如给一个 `test'` ，此处 `insert` 只有一个字段，因此必须先闭合括号，然后开启插入的第二个数据，写一下大概就是如下 ```php test'), ``` 由于这个字段的数据都是序列化后的，因此我们必须满足序列化的规则才方便被正常取出，我们先构造一个获取管理员密码的语句如下： ```php SELECT password FROM piwigo_users where id=1 ``` 使用这条语句获取到密码后，再将其放入模板中 ```php a:1:{s:1:"q";s:4:"xxxx";} ``` `xxxx` 就是我们获取到的密文，前面的4跟随密文长度变化，我看了下，这里加密方式产出的密文好像都是 34 位，因此这里直接设 34。 密码获取需要通过上面的语句获取，使用 `concat` 拼接获取，配合前面的内容得到 ```php test'),((select concat('a:1:{s:1:"q";s:34:"',(SELECT password FROM piwigo_users where id=1),'";}')))# ``` 构造如上 `payload` ，通过前台搜索功能插入后，在这里就可以获取到密文，并将密文存储到数据库中 #### 访问前台获取密码 接下来是获取该数据库内容，因此涉及的数据库仍然是刚刚的数据库，可以继续搜索 `SEARCH_TABLE` ，找到一处前台获取该数据库内容的位置，位于 `include/functions_search.inc.php`  这里是一个函数，直接根据 `$search_id` 搜索，然后反序列化 `rules` 后返回，我们看看调用位置  定位到 `search_rules.php`  比较简单就知道可以成功获取。 ### 漏洞复现 #### 将payload通过前台插入数据库 按照之前说的注入  记录返回的 `id` 值，对应插入记录的 `id` 但是发现之后的利用会出错，这是为什么呢？按照前面说的，这里的 `q` 写入的是什么，之后获取就应该是那个值，但是 `$_GET` 在利用前实际上会被处理一次，位于 `include/common.inc.php` ，这是文件开头就会调用的  因此我们这里写入的 `payload` 中的单引号会被加上 `\` ，就像上面图中的数据库 一样 这里的解决方法是将参数 `q` 作为一个数组写入，数组的键为 `payload` ，而 之后的处理由于是序列化，因此这个键也会被写入，之后取出来也适用。  如此，进入数据库的值就不会被转义了 #### 管理员用户点击该漏洞链接 此操作需要管理员权限  可以看到，执行完后，会在数据库中生成两条记录，其中一条就获取到了密文 #### 攻击者前台访问获取密码 这里唯一需要注意的一点是我们需要知道 `search_id` ，也就是插入的那条含有密文的数据的 `id` 值  0x04 总结 ------- 相对来说，`CVE-2022-32297` 会更有意思，而且该漏洞比较难以发现，虽然需要管理员用户点击，但用户可以从前台获取到数据，比 `CVE-2022-26266` 的危害更加大。这个漏洞让我想起了 `Laravel` `CVE-2021-3129` 漏洞，同样是取出来后又放进去，从而导致了漏洞，虽然造成漏洞的本质并不一样，但有着异曲同工之妙。
发表于 2022-11-30 09:00:01
阅读 ( 4904 )
分类：
漏洞分析
3 推荐
收藏
0 条评论
请先
登录
后评论
shenwu
10 篇文章
×
发送私信
请先
登录
后发送私信
×
举报此文章
垃圾广告信息：
广告、推广、测试等内容
违规内容：
色情、暴力、血腥、敏感信息等内容
不友善内容：
人身攻击、挑衅辱骂、恶意行为
其他原因：
请补充说明
举报原因:
×
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
