RSS Feed
更好更安全的互联网

  • DeDeCMS v5.7 密码修改漏洞分析

    2018-01-18

    作者：LoRexxar'@知道创宇404实验室

    #### 0x01 背景

    织梦内容管理系统(DedeCms)以简单、实用、开源而闻名，是国内最知名的PHP开源网站管理系统，也是使用用户最多的PHP类CMS系统，在经历多年的发展，目前的版本无论在功能，还是在易用性方面，都有了长足的发展和进步，DedeCms免费版的主要目标用户锁定在个人站长，功能更专注于个人网站或中小型门户的构建，当然也不乏有企业用户和学校等在使用该系统。

    2018年1月10日， 锦行信息安全公众号公开了一个关于DeDeCMS前台任意用户密码修改漏洞的细节\[2]。

    2018年1月10日，Seebug漏洞平台\[3]收录该漏洞，漏洞编号为SSV-97074，知道创宇404漏洞应急团队成功复现该漏洞。

    2018年1月17日，阿里先知平台公开了一个任意用户登陆漏洞\[4]\[5]，和一个安全隐患\[6]，通过组合漏洞，导致后台密码可以被修改。

    2018年1月18日，知道创宇404漏洞应急团队成功复现该漏洞。

    #### 0x02 漏洞简述

    整个漏洞利用链包括3个过程：

    1. 前台任意用户密码修改漏洞
    2. 前台任意用户登陆漏洞
    3. 前台管理员密码修改可影响后台的安全隐患

    通过3个问题连起来，我们可以重置后台admin密码，如果我们获得了后台地址，就可以进一步登陆后台进行下一步攻击。

    ##### 1、前台任意用户密码修改漏洞
    前台任意用户密码修改漏洞的核心问题是由于DeDeCMS对于部分判断使用错误的弱类型判断，再加上在设置初始值时使用了NULL作为默认填充，导致可以使用弱类型判断的漏洞来绕过判断。

    漏洞利用有几个限制：

    1. 漏洞只影响前台账户 admin账户在前台是敏感词无法登陆
    2. admin账户的前后台密码不一致，无法修改后台密码。
    3. 漏洞只影响未设置密保问题的账户

    ##### 2、前台任意用户登陆漏洞

    前台任意用户登陆漏洞主要是利用了DeDeCMS的机制问题，通过一个特殊的机制，我们可以获得任意通过后台加密过的cookie，通过这个cookie我们可以绕过登陆，实现任意用户登陆。

    漏洞利用有一个限制：

    如果后台开启了账户注册审核，那就必须等待审核通过才能进行下一步利用。

    ##### 3、前台管理员密码修改可影响后台的安全隐患

    在DeDeCMS的设计中，admin被设置为不可从前台登陆，但是当后台登陆admin账户的时候，前台同样会登陆管理员账户。

    而且在前台的修改密码接口，如果提供了旧密码，admin同样可以修改密码，并且这里修改密码会同步给后台账户。

    通过3个漏洞配合，我们可以避开整个漏洞利用下的大部分问题。

    前台任意用户密码修改漏洞->修改admin密码，前台任意用户登录漏洞->登陆admin账户，通过刚才修改的admin密码，来重置admin账户密码。

    #### 0x03 漏洞复现

    ##### 1、 登陆admin前台账户

    安装DeDeCMS
    ![](https://images.seebug.org/content/images/2018/01/5d867e22-6725-44a0-8921-eb1a470accb1.png-w331s)

    注册用户名为000001的账户

    ![](https://images.seebug.org/content/images/2018/01/2c982abb-8803-4ace-b900-b76fdebb1090.png-w331s)

    由于是本地复现漏洞，所以我们直接从数据库中修改为审核通过

    ![](https://images.seebug.org/content/images/2018/01/62afac8d-5130-4df8-9755-b14d505cadc2.png-w331s)

    访问

    http://your_website/member/index.php?uid=0000001

    ![](https://images.seebug.org/content/images/2018/01/f5289b12-2d0c-4d1c-9c7a-f4ad0d1053cd.png-w331s)

    获取cookie中last_vid_ckMd5值，设置DeDeUserID_ckMd5为刚才获取的值，并设置DedeUserID为0000001

    访问

    http://your_website/member/

    ![](https://images.seebug.org/content/images/2018/01/81bdc4e1-6df5-4cb8-be06-1aebe66d7e47.png-w331s)

    ##### 2、修改admin前台登陆密码

    使用DeDeCMS前台任意用户密码修改漏洞修改admin前台密码。

    构造漏洞利用请求


    http://yourwebsite/member/resetpassword.php

    dopost=safequestion&safequestion=0.0&safeanswer=&id=1

    ![](https://images.seebug.org/content/images/2018/01/65169b22-9cca-49a4-b049-6b781721bad5.png-w331s)

    从Burp获取下一步利用链接

    /member/resetpassword.php?dopost=getpasswd&id=1&key=nlszc9Kn

    ![](https://images.seebug.org/content/images/2018/01/01734ff4-d48d-42ca-b5d2-ec8837ee70e9.png-w331s)

    直接访问该链接，修改新密码

    ![](https://images.seebug.org/content/images/2018/01/c0f3ffe5-6eb1-4064-92e4-16c366d84ba8.png-w331s)

    成功修改登陆admin密码

    ##### 3、修改后台密码

    访问


    http://yourwebsite/member/edit_baseinfo.php

    使用刚才修改的密码再次修改密码

    ![](https://images.seebug.org/content/images/2018/01/e77740d5-d2f6-443b-b4db-3ba0dbb7a37b.png-w331s)

    成功登陆

    ![](https://images.seebug.org/content/images/2018/01/c68183da-b541-40e3-86d2-8b75aadb361a.png-w331s)

    #### 0x04 代码分析

    ##### 1、 前台任意用户登陆

    在分析漏洞之前，我们先来看看通过cookie获取登陆状态的代码。


    /include/memberlogin.class.php 161行

    ![](https://images.seebug.org/content/images/2018/01/ca006dbb-b378-48b4-a907-1fb7ea9b3c85.png-w331s)

    通过GetCookie函数从DedeUserID取到了明文的M_ID，通过intval转化之后，直接从数据库中读取该id对应的用户数据。

    让我们来看看GetCookie函数


    /include/helpers/cookie.helper.php 56行

    ![](https://images.seebug.org/content/images/2018/01/0a4a3a7c-3378-4d06-b4d4-e92f6f838185.png-w331s)

    这里的cfg_cookie_encode是未知的，DeDeCMS通过这种加盐的方式，来保证cookie只能是服务端设置的，所以我们没办法通过自己设置cookie来登陆其他账户。

    这里我们需要从别的地方获取这个加密后的值。


    /member/index.php 161行

    ![](https://images.seebug.org/content/images/2018/01/083c37a6-97ff-4655-8c96-0bf481c554e9.png-w331s)

    161行存在一段特殊的代码，这段代码是用来更新最新的访客记录的，当last_vid没有设置的时候，会把userid更新到这个变量中，更新到flag中。

    而这里的userid就是注册时的用户名（如果不是已存在的用户名的话，会因为用户不存在无法访问这个页面）。

    通过这种方式，我们就可以通过已知明文来获取我们想要的密文。

    这里我们通过注册userid为形似00001或者1aaa这样的用户，在获取登陆状态时，mid会经过intval的转化变为1，我们就成功的登陆到admin的账户下。

    ps：该漏洞影响所有用户

    ##### 2、前台任意用户密码修改

    漏洞主要逻辑在 /member/resetpassword.php 75行至95行

    ![](https://images.seebug.org/content/images/2018/01/80dc5c44-533f-4eb2-8dae-c75f255a936b.png-w331s)

    当找回密码的方式为安全问题时

    dedecms会从数据库中获取用户的安全问题、回答进行比对，当我们在注册时没设置安全问题时。

    从数据库中可以看到默认值为NULL（admin默认没有设置安全问题）

    ![](https://images.seebug.org/content/images/2018/01/33dd3447-bc19-4fc4-a869-f3961a67bd55.png-w331s)

    下面是设置了安全问题时数据库的样子，safequestion代表问题的id，safeanswer代表安全问题的回答。

    我们需要绕过第一个判断

    if(empty($safequestion)) $safequestion = '';

    这里我们只要传入0.0就可以绕过这里，然后0.0 == 0为True，第二个判断NULL==""为True，成功进入sn函数。

    跟入/member/inc/inc_pwd_functions.php 第150行

    ![](https://images.seebug.org/content/images/2018/01/005be5b8-87cc-433d-8b39-2f7dadeec734.png-w331s)

    有效时间10分钟，进入newmail函数

    跟入/member/inc/inc_pwd_functions.php 第73行

    ![](https://images.seebug.org/content/images/2018/01/23657efd-40df-4619-a322-89d3d68974c9.png-w331s)

    77行通过random生成了8位的临时密码。

    这里我们使用的是安全问题修改密码，所以直接进入94行，将key代入修改页。

    跳转进入形似

    /member/resetpassword.php?dopost=getpasswd&id=1&key=nlszc9Kn

    的链接，进入修改密码流程

    唯一存在问题的是，这里&错误的经过一次编码，所以这里我们只能手动从流量中抓到这个链接，访问修改密码。

    ##### 3、修改后台密码安全隐患

    在DeDeCMS的代码中，专门对前台修改管理员密码做了设置，如果是管理员，则一并更新后台密码，也就是这个安全隐患导致了这个问题。


    /member/edit_baseinfo.php 119行

    ![](https://images.seebug.org/content/images/2018/01/921e15f3-9e3e-4a34-a1f3-54475a6f25eb.png-w331s)

    #### 0x05 修复方案

    截至该文章完成时，DeDeCMS的官方仍然没有修复该漏洞，所以需要采用临时修复方案，等待官方正式修复更新。

    由于攻击漏洞涉及到3个漏洞，但官方仍然没有公开补丁，所以只能从一定程度上减小各个漏洞的影响。

    - 前台任意用户登陆漏洞：开启新用户注册审核，当发现userid为1xxxx或1时，不予以
    通过审核。

    在官方更新正式补丁之前，可以尝试暂时注释该部分代码，以避免更大的安全隐患

    /member/index.php 161-162行

    ![](https://images.seebug.org/content/images/2018/01/f88b5b3e-567b-4f72-a3cb-5efb4a7a18cb.png-w331s)

    - 前台修改后台管理员密码：设置较为复杂的后台地址，如果后台地址不可发现，则无法登陆后台。
    - 前台任意用户密码修改漏洞：

    修改文件/member/resetpassword.php 第84行
    ![](https://images.seebug.org/content/images/2018/01/7b8c7600-68dc-4eb9-bfc5-bfee00d158b7.png-w331s)

    将其中的==修改为===

    ![](https://images.seebug.org/content/images/2018/01/920c7470-c038-44a7-b43d-12c27a8f5a87.png-w331s)

    即可临时防护该该漏洞。

    #### 0x06 ref

    [1] DeDeCMS官网

    [2] 漏洞详情原文

    [3] Seebug漏洞平台

    [4] 阿里先知平台漏洞分析1

    [5] 阿里先知平台漏洞分析2

    [6] 漏洞最早分析原文

    作者：dawu | Categories:安全研究、技术分享 | Tags:
    没有评论

  • 如何通过TTL调试光猫

    2018-01-17

    作者：Sebao@知道创宇404实验室

    序言

    众所周知，光猫是现在每个家庭必备的一款设备，但是光猫背面写的账号密码，只是普通用户权限，会限制很多功能。这篇文章讲述，如何通过TTL调试的方法获取光猫超级管理员的权限。

    0x00 名词解释

    引脚介绍（COM口pin比较多，但是常用的也是这几个）：

    VCC：供电pin，一般是3.3v，在我们的板子上没有过电保护，这个pin一般不接更安全

    GND：接地pin，有的时候rx接受数据有问题，就要接上这个pin，一般也可不接

    RX：接收数据pin

    TX：发送数据pin，我之前碰到串口只能收数据，不能发数据问题，经baidu，原来是设置了流控制，取消就可以了，适用于putty,SecureCRT

    在调试的时候, 多数情况下我们只引出rx，tx即可.

    0x01 所需工具：

    1，万用表

    2，TTL转USB版

    3，电烙铁

    4，杜邦线若干只

    5，SecureCRT

    0x02 华为光猫

    TTL调试的第一步骤就是拆机，拆机步骤这里就不详细描述。这里先看一下拆下来的光猫板子是什么样子的。

    TTL调试我们首先要找出 GND，RX，TX。从图中可以看到，已经标识出了 GND，RX，TX的接口，就需要通过USB转TTL小板串口读取固件。 查找GND，可以用万用表查找。

    用杜邦线连接到板子上，线序为GND接GND，RXD接TTL板的TXD，TXD 接TTL板的RXD。

    USB端连接上电脑，在控制面板，设备管理器查看串口（一般在COM1-COM12之间），Connection type设置为：Serial，Serial line设置为你电脑上显示的串口，Speed设置为115200，然后连接。接通电源后等待，在这一段时间内串口应该会打印很多启动信息，启动差不多后，敲回车：

    然后输入默认的账号root 密码 admin登录进去，输入shell命令，进入busybox.看一下此设备的cpu架构，用的是ARM7.

    准备查找超级管理员的密码。进入/mnt/jffs2目录，复制配置文件hw_ctree.xml到myconf.xml.gz中。这个文件是AES加密的，所以先解密，命令为aescrypt2 1 myconf.xml.gz tmp。

    解密后的文件还是被压缩了的，所以要用gzip命令展开压缩文件myconf.xml.gz，得到myconf.xml。命令为：gzip -d myconf.xml.gz。

    然后用 grep 命令 查找telecomadmin，也就是超级管理员的密码。命令为：grep telecomadmin myconf.xml

    0x03 烽火光猫

    和上述步骤一样，首先拆开光猫找到 GND，RX，TX。这个板子人性化的已经标明了GND，RX，TX。

    所以直接用杜邦线连接到板子上，线序为GND接GND，RXD接TTL板的TXD，TXD 接TTL板的RXD。

    USB端连接上电脑。

    接通电源后等待，在这一段时间内串口应该会打印很多启动信息，这里直接CTRL+C 跳过直接进入shell模式，这个也算是一个“后门”。输入命令 cat proc/cpuinfo查看cpu的架构。

    进入shell获取超级管理员的方法差不多，参考上文即可，这里不再详细描述。

    0x04 长虹光猫

    和上述步骤一样。

    因为这里没有针孔，所以需要焊接杜邦线到板子上，以便于固定杜邦线。

    USB端连接上电脑。

    0x05 总结

    感谢 知道创宇404实验室 dawu，fenix提供的思路以及技巧。

    作者：dawu | Categories:安全研究、技术分享 | Tags:
    没有评论

  • Huawei HG532 系列路由器远程命令执行漏洞分析

    2017-12-28

    作者：fenix@知道创宇404实验室
    English version: https://paper.seebug.org/508/

    背景

    华为 HG532 系列路由器是一款为家庭和小型办公用户打造的高速无线路由器产品。

    2017/11/27，Check Point 软件技术部门报告了一个华为 HG532 产品的远程命令执行漏洞(CVE-2017-17215)【1】 。

    该漏洞在被报告前，互联网上产生了大量未被关注的此类漏洞攻击利用包，遍及全球多个国家。Payload 已被证实是知名病毒 Mirai 的升级版变种 OKIRU/SATORI。该 Payload 功能非常简单，主要通过发送精心制作的 UDP/TCP 报文来对目标发起 DDoS 攻击。

    2017/11/23，知道创宇 404 实验室的 ZoomEye 网络探针系统也捕获到了该攻击的 Payload。

    漏洞分析

    固件下载

    网上有 HG532e 版本的公开固件，下载地址【2】

    下载该固件，利用 binwalk 直接解压。

    目标系统是 MIPS 32 位 大端架构。

    漏洞分析

    根据 Check Point 的报告【1】，该远程命令执行漏洞的漏洞点位于 UPnP 服务中。

    UPnP 是由“通用即插即用论坛”（UPnP™ Forum）推广的一套网络协议。该协议的目标是使家庭网络（数据共享、通信和娱乐）和公司网络中的各种设备能够相互无缝连接，并简化相关网络的实现。

    直接将固件中负责 UPnP 服务的 upnp 程序扔到 IDA。

    通过字符串 NewStatusURL 对漏洞点进行定位。

    跟踪数据交叉引用

    漏洞点如下

    ATP_XML_GetChildNodeByName 函数的定义如下。

    程序首先进行 SOAP XML 报文解析，得到元素 NewDownloadURL 和 NewStatusURL 的值。然后进行以下拼接，最终调用 system() 函数执行。

    upg 是路由器的一个升级程序，他的参数功能如下。

    现在我们有两个命令注入点，NewDownloadURL 和 NewStatusURL。

    漏洞验证

    目标系统提供了以下命令。

    利用 wget 命令进行漏洞测试。发送以下报文。

    可以看到，我们成功在监听的端口上收到了请求。

    值得一提的是，HG532e 路由器的 uPnP 服务和防火墙都是默认开启的，防火墙默认等级为低级。

    在默认设置下，从 WAN 口访问 37215 端口会被防火墙拦截，漏洞无法被利用。

    防护方案

    2017/11/30，华为官方发布了安全公告【4】，确认了该漏洞。
    公告中提到了以下漏洞缓解措施

    • 配置路由器内置的防火墙
    • 更改路由器默认密码
    • 在路由器外部署防火墙

    是的，没找到固件升级包，所以，没有补丁分析…

    总结

    1. 和爱尔兰宽带路由器 SetNTPServers 命令注入【3】类似，这个漏洞整体来看就是一个简单的命令拼接。
    2. 该漏洞也为我们漏洞挖掘提供了一个很好的方向。snprintf()、system() 等函数附近的程序逻辑都应该被重点关注。
    3. 还是那句话，一切进入函数的变量都是有害的。大部分远程命令执行漏洞要么是过滤不全，导致命令拼接。要么是没有进行变量长度控制，造成缓冲区溢出。关于这点设备供应商应该负责任，安全开发意识非常重要。

    参考链接

    【1】 Check Point 漏洞报告
    https://research.checkpoint.com/good-zero-day-skiddie/
    【2】 HG532e 固件下载
    https://ia601506.us.archive.org/22/items/RouterHG532e/router%20HG532e.rar
    【3】 爱尔兰宽带路由器 SetNTPServers 命令注入
    https://www.seebug.org/vuldb/ssvid-97024/https://www.seebug.org/vuldb/ssvid-97024
    【4】 华为安全公告
    http://www.huawei.com/en/psirt/security-notices/huawei-sn-20171130-01-hg532-en/http://www.huawei.com/en/psirt/security-notices/huawei-sn-20171130-01-hg532-en

    作者：dawu | Categories:安全研究、技术分享 | Tags:
    没有评论

  • Vivotek 摄像头远程栈溢出漏洞分析及利用

    2017-12-14

    作者：fenix@知道创宇404实验室

    前言

    近日，Vivotek 旗下多款摄像头被曝出远程未授权栈溢出漏洞，攻击者发送特定数据可导致摄像头进程崩溃。

    漏洞作者@bashis 放出了可造成摄像头 Crash 的 PoC ：https://www.seebug.org/vuldb/ssvid-96866/https://www.seebug.org/vuldb/ssvid-96866

    该漏洞在 Vivotek 的摄像头中广泛存在，按照官方的安全公告，会影响以下版本

    Vivotek 官方提供了各种型号摄像头的固件下载：http://www.vivotek.com/firmware/ ，这也为我们的研究带来了很多便利。

    我们发现，漏洞被曝出之后，在官网固件下载页面中的大多数固件均早于漏洞曝出时间，我们下载了几款摄像头的最新固件进行验证，发现漏洞依然存在，这意味着截止漏洞被曝出，Vivotek 官方对该漏洞的修复并不彻底。众所周知，栈溢出是存在潜在的远程命令执行风险的，为了深入了解该漏洞的影响，我们决定研究下该漏洞的原理及利用。

    调试环境搭建

    固件下载

    由于手头上并没有 Vivotek 的摄像头，我们在官网下载其中一款摄像头固件，使用 qemu 模拟运行。（注：官方在陆续发布各个版本的固件更新，可根据固件发布时间判断官方是否已经修复漏洞）

    首先下载摄像头固件：http://download.vivotek.com/downloadfile/downloads/firmware/cc8160firmware.zip/http://download.vivotek.com/downloadfile/downloads/firmware/cc8160firmware.zip

    通过 binwalk 直接解压出其中的文件系统，和漏洞有关的主要文件如下

    根据 file 命令的结果可知目标架构为 ARM、小端、32位。且该 ELF 文件为动态链接。

    修复运行依赖

    尝试用 qemu 运行，结果如下

    服务没有运行起来，且没有明显的报错，猜想到可能是缺少某些依赖，程序直接退出了，扔到 IDA，从程序退出前的提示：gethostbyname:: Success，回溯程序异常退出原因。

    依次加载IDA 菜单栏 -> View -> Open subviews -> Strings，Command + F 搜索 gethostname

    查看交叉引用信息，定位相应代码段

    异常退出部分代码如下

    为了看的更直观，我们来贴一下 F5 的结果，如下

    这部分主要涉及两个函数。gethostname()：返回本地主机的标准主机名，如果函数成功，则返回 0。如果发生错误则返回 -1。gethostbyname()：用域名或主机名获取IP地址。

    Linux 操作系统的 hostname 是一个 kernel 变量，可以通过 hostname 命令来查看本机的 hostname。也可以直接 cat /proc/sys/kernel/hostname 查看。

    我们只需要将二者改成一致，httpd 服务即可成功运行。

    调试环境

    为了方便调试，还需要搭建 qemu 虚拟机环境。

    qemu 镜像文件下载：https://people.debian.org/~aurel32/qemu/armel/ （下载内核 3.2 的版本）

    远程调试 gdbserver：https://github.com/mzpqnxow/gdb-static-cross/tree/master/prebuilt-static/https://github.com/mzpqnxow/gdb-static-cross/tree/master/prebuilt-static

    qemu 虚拟机建议采用 桥接 方式和主机连接。

    启动虚拟机，进行简单配置等待远程调试。

    漏洞研究

    定位溢出点

    以下为漏洞作者 @bashis 提供的 PoC

    老套路， 根据 Content-Length 很容易定位到溢出点，如下

    惊讶到了，strncpy() 函数的长度参数竟然这么用，妥妥的溢出。

    调用栈布局

    dest 缓冲区起始地址距离栈底 0x38 字节，栈上依次为 LR、R11-R4。Content-Length 长度超过 0x38 - 4 字节就会覆盖函数的返回地址 LR。

    exp 研究

    strncpy() 函数引起的栈溢出，在利用时就会有很 egg hurt 的 0x00 坏字符问题，如果我们的输入数据中包含 0x00，将会被截断导致漏洞利用失败。根据溢出点附近的汇编代码来看，0x0a 也会被截断。且开启了 NX 保护，这意味着我们无法在栈上部署 shellcode。

    ​

    尝试通过 return2libc 的方式 getshell。由于没有实际的摄像头，我们不知道目标系统是否开启了 ASLR ，如果 ASLR 是开启的且没有其它可用来暴露 libC 动态链接库内存地址的漏洞，那么利用该漏洞将会是一个很难受的过程。

    采用以下方式暂时关闭 ASLR

    libC 库的加载地址如下

    接下来就需要精心构造数据，劫持函数的执行流程了。有一点需要注意，X86 架构下的所有参数都是通过堆栈传递的，而在 MIPS 和 ARM 架构中，会优先通过寄存器传递参数，如果参数个数超过了寄存器的数量，则将剩下的参数压入调用参数空间（即堆栈）。

    从前面的分析来看，只要我们构造 0x38 - 4 字节以上的数据，栈底的函数返回地址就会被我们劫持。system() 函数地址 = libC 库在内存中的加载基址 + system() 函数在 libC 库中的偏移，通过劫持该地址为 libC 库中的 system() 函数地址，再设置 R0 寄存器指向命令字符串，就可以执行任意命令。

    经过验证，nc 命令可以正常使用。

    接下来我们开始构造 ROP 利用链，大致思路见以下汇编代码。

    Github 上有个很赞的项目：https://github.com/JonathanSalwan/ROPgadget/https://github.com/JonathanSalwan/ROPgadget

    它可以用来搜索 ELF 文件中的 gadgets，方便我们构造 ROP 链。

    我们需要将字符串参数 nc -lp2222 -e/bin/sh 部署到栈上，并且将地址存入 R0。该参数包含 20 个字节，且不含坏字符。

    libC 基址为 0xb6f2d000，由该地址可知 gadget 在内存中的有效地址。发生溢出时栈顶地址为 0xbeffeb50。

    利用 ROPgadget 搜索可用的 gadgets，在选择 gadget 时要还考虑坏字符的问题。比如说如下的 gadget 就不得行。

    再搜索一条可用的 gadget，俗称曲线救国。

    选择以下两条 gadget，构造 ROP 如下。

    通过调试 ，我们可以获得崩溃时的栈顶地址，为了确保命令能执行，我们在真正要执行的命令前加了部分命令作为缓冲。

    可以看到，开启了 NX 保护的栈上虽然不可执行代码，但是依然可以在上面部署数据。我们只需要将要执行的命令部署到栈上，构造 ROP 让 R0 寄存器指向栈上的命令所在区域，然后 return2libC 调用系统函数，就可以执行任意命令了。

    已将 PoC 和 EXP 整理成 Pocsuite 脚本：https://www.seebug.org/vuldb/ssvid-96866/https://www.seebug.org/vuldb/ssvid-96866，验证效果如下。

    致谢

    第一次接触 ARM 汇编，有很多不足之处，欢迎各大佬指正。中途踩了不少坑，感谢 404 小伙伴 @Hcamael 和 @没有ID 的各种疑难解答。

    参考链接

    作者：dawu | Categories:安全研究、技术分享 | Tags:
    没有评论

  • CVE-2017-16943 Exim UAF漏洞分析–后续

    2017-12-13

    作者：Hcamael@知道创宇404实验室

    上一篇分析出来后，经过@orange的提点，得知了meh公布的PoC是需要特殊配置才能触发，所以我上一篇分析文章最后的结论应该改成，在默认配置情况下，meh提供的PoC无法成功触发uaf漏洞。之后我又对为啥修改了配置后能触发和默认情况下如何触发漏洞进行了研究

    重新复现漏洞

    比上一篇分析中复现的步骤，只需要多一步，注释了/usr/exim/configure文件中的control = dkim_disable_verify

    然后调整下poc的padding，就可以成功触发UAF漏洞，控制rip

    分析特殊配置下的触发流程

    在代码中有一个变量是dkim_disable_verify, 在设置后会变成true，所以注释掉的情况下，就为默认值false, 然后再看看receive.c中的代码：

    进入了dkim_exim_verify_init函数，之后的大致流程：

    在上一篇文章中说过了，无法成功触发uaf漏洞的原因是，被free的堆处于堆顶，释放后就和top chunk合并了。

    在注释了dkim的配置后，在dkim_exim_verify_init 函数的流程中，执行了一个store_get 函数，申请了一个0x4000大小的堆，然后在dkim_exim_verify_init 函数和dkim_exim_verify_feed 函数中，都有如下的代码：

    store_pool全局变量被修改为了1，之前说过了，exim自己实现了一套堆管理，当store_pool不同时，相当于对堆进行了隔离，不会影响receive_msg 函数中使用堆管理时的current_block这类的堆管理全局变量

    当dkim相关的代码执行结束后，还把store_pool恢复回去了

    因为申请了一个0x4000大小的堆，大于0x2000，所以申请之后yield_length全局变量的值变为了0，导致了之后store_get(0x64)再次申请了一块堆，所以有了两块堆放在了heap1的上面，释放heap1后，heap1被放入了unsortbin，成功触发了uaf漏洞，造成crash。(之前的文章中都有写到)

    默认配置情况下复现漏洞

    在特殊配置情况下复现了漏洞后，又进行了如果在默认配置情况下触发漏洞的研究。

    在@explorer大佬的教导下，发现了一种在默认情况下触发漏洞的情况。

    其实触发的关键点，就是想办法在heap1上面再malloc一个堆，现在我们从头来开始分析

    首先，当有新连接进来的时候，fork一个子进程，然后进入上面代码中的那个分支，smtp_setup_msg函数是用来接收命令的函数，我们先发一堆无效的命令过去(padding)，控制yield_length的值小于0x100，目的上一篇文章说过了，因为命令无效，流程再一次进入了smtp_setup_msg

    这时候我们发送一个命令BDAT 16356

    然后有几个比较重要的操作：

    首先是把输入的16356赋值给chunking_data_left

    然后把receive_getc换成bdat_getc函数

    再做完这些的操作后，进入了receive_msg函数，按照上篇文章的流程差不多，显示申请了一个0x100的heap1

    然后进入receive_getc=bdat_getc读取数据:

    lwr_receive_getc=smtp_getc通过该函数获取16356个字符串

    首先，我们发送16352个a作为padding，然后执行了下面这流程:

    • store_extend return 0 -> store_get -> store_release

    先申请了一个0x4010的heap2，然后释放了长度为0x2010的heap1

    然后发送:\r\n，进入下面的代码分支:

    跳到了EOL，最重要的是最后几行代码：

    把一些变量重新进行了初始化，因为之前因为padding执行了store_get(0x4000)，所以这个时候yield_length=0 这个时候再次调用store_get将会申请一个0x2000大小堆，从unsortbin中发现heap1大小正好合适，所以这个时候得到的就是heap1，在heap1的顶上有一个之前next->text使用，大小0x4010，未释放的堆。

    之后流程的原理其实跟之前的差不多，PoC如下：

    exp

    根据该CVE作者发的文章，得知是利用文件IO的fflush来控制第一个参数，然后通过堆喷和内存枚举来来伪造vtable，最后跳转到expand_string函数来执行命令，正好我最近也在研究ctf中的_IO_FILE的相关利用(之后应该会写几篇这方面相关的blog)，然后实现了RCE，结果图如下：


    参考链接

    1. https://devco.re/blog/2017/12/11/Exim-RCE-advisory-CVE-2017-16943-en/
    作者：dawu | Categories:安全研究、技术分享 | Tags:
    没有评论

  • CVE-2017-16943 Exim UAF漏洞分析

    2017-12-01

    作者：Hcamael@知道创宇404实验室

    感恩节那天，meh在Bugzilla上提交了一个exim的uaf漏洞：https://bugs.exim.org/show_bug.cgi?id=2199，这周我对该漏洞进行应急复现，却发现，貌似利用meh提供的PoC并不能成功利用UAF漏洞造成crash

    漏洞复现

    首先进行漏洞复现

    环境搭建

    复现环境：ubuntu 16.04 server

    然后再修改下配置文件/etc/exim/configure文件的第364行，把
    accept hosts = : 修改成 accept hosts = *

    PoC测试

    从https://bugs.exim.org/attachment.cgi?id=1050获取到meh的debug信息，得知启动参数：

    PoC有两个:

    1. https://bugs.exim.org/attachment.cgi?id=1049
    2. https://bugs.exim.org/attachment.cgi?id=1052

    需要先安装下pwntools，直接用pip装就好了，两个PoC的区别其实就是padding的长度不同而已

    然后就使用PoC进行测试，发现几个问题：

    1. 我的debug信息在最后一部分和meh提供的不一样
    2. 虽然触发了crash，但是并不是UAF导致的crash

    debug信息不同点比较：

    发现的确是抛异常了，但是跟meh的debug信息在最后却不一样，然后使用gdb进行调试，发现：

    根本就不是meh描述的利用UAF造成的crash，继续研究，发现如果把debug all的选项-d+all换成只显示简单的debug信息的选项-dd，则就不会抛异常了

    又仔细读了一遍meh在Bugzilla上的描述，看到这句，所以猜测有没有可能是因为padding大小的原因，才导致crash失败的？所以写了代码对padding进行爆破，长度从0-0x4000，爆破了一遍，并没有发现能成功造成crash的长度。

    This PoC is affected by the block layout(yield_length), so this line: r.sendline('a'*0x1250+'\x7f') should be adjusted according to the program state.

    所以可以排除是因为padding长度的原因导致PoC测试失败。

    而且在漏洞描述页，我还发现Exim的作者也尝试对漏洞进行测试，不过同样测试失败了，还贴出了他的debug信息，和他的debug信息进行对比，和我的信息几乎一样。(并不知道exim的作者在得到meh的Makefile和log后有没有测试成功)。

    所以，本来一次简单的漏洞应急，变为了对该漏洞的深入研究

    浅入研究

    UAF全称是use after free，所以我在free之前，patch了一个printf：

    重新编译跑一遍，发现竟然成功触发了uaf漏洞：

    然后gdb调试的信息也证明成功利用uaf漏洞造成了crash：

    PS: 这里说明下./build-Linux-x86_64/exim这个binary是没有patch printf的代码，/usr/exim/bin/exim是patch了printf的binary

    到这里就很奇怪了，加了个printf就能成功触发漏洞，删了就不能，之后用puts和write代替了printf进行测试，发现puts也能成功触发漏洞，但是write不能。大概能猜到应该是stdio的缓冲区机制的问题，然后继续深入研究。

    深入研究

    来看看meh在Bugzilla上对于该漏洞的所有描述：

    在这里先提一下，在Exim中，自己封装实现了一套简单的堆管理，在src/store.c中

    UAF漏洞所涉及的关键函数：

    • store_get_3 堆分配
    • store_extend_3 堆扩展
    • store_release_3 堆释放

    还有4个重要的全局变量：

    • chainbase
    • next_yield
    • current_block
    • yield_length
    第一步

    发送一堆未知的命令去调整yield_length的值，使其小于0x100。

    yield_length表示的是堆还剩余的长度，每次命令的处理使用的是src/receive.c代码中的receive_msg函数

    在该函数处理用户输入的命令时，使用next->text来储存用户输入，在1709行进行的初始化：

    在执行1709行代码的时候，如果0x100 > yield_length则会执行到newblock = store_malloc(mlength);，使用glibc的malloc申请一块内存，为了便于之后的描述，这块内存我们称为heap1。

    根据store_get_3中的代码，这个时候：

    • current_block->next = heap1 (因为之前current_block==chainbase，所以这相当于是chainbase->next = heap1)
    • current_block = heap1
    • yield_length = 0x2000
    • next_yield = heap1+0x10
    • return next_yield
    • next_yield = next_yield+0x100 = heap1+0x110
    • yield_length = yield_length - 0x100 = 0x1f00
    第二步

    发送BDAT 1，进入receive_msg函数，并且让receive_getc变为bdat_getc

    第三步

    发送BDAT \x7f

    相关代码在src/smtp_in.c中的bdat_getc函数：

    BDAT命令进入下面这个分支：

    因为\x7F 所以sscanf获取长度失败，进入synprot_error函数，该函数同样是位于smtp_in.c文件中：

    然后在synprot_error函数中有一个string_printing函数，位于src/string.c代码中：

    在string_printing2函数中，用到store_get, 长度为length + nonprintcount * 3 + 1，比如BDAT \x7F这句命令，就是6+1*3+1 => 0x0a，我们继续跟踪store中的全局变量，因为0xa < yield_length，所以直接使用的Exim的堆分配，不会用到malloc，只有当上一次malloc 0x2000的内存用完或不够用时，才会再进行malloc

    • 0xa 对齐-> 0x10
    • return next_yield = heap1+0x110
    • next_yield = heap1+0x120
    • yield_length = 0x1f00 - 0x10 = 0x1ef0

    最后一步，就是PoC中的发送大量数据去触发UAF：

    再回到receive.c文件中，读取用户输入的是1788行的循环，然后根据meh所说，UAF的触发点是下面这几行代码：

    当输入的数据大于等于0x100-4时，会触发store_extend函数，next->text的值上面提了，是heap1+0x10，oldsize=0x100, header_size = 0x100*2 = 0x200

    然后在store_extend中，有这几行判断代码：

    其中next_yield = heap1+0x120, ptr + 0x100 = heap1+0x110

    因为判断的条件为true，所以store_extend返回False

    这是因为在之前string_printing函数中中分配了一段内存，所以在receive_msg中导致堆不平衡了，

    随后进入分支会修补这种不平衡，执行store_get(0x200)

    • return next_yield = heap1+0x120
    • next_yield = heap1+0x320
    • yield_length = 0x1ef0 - 0x200 = 0x1cf0

    然后把用户输入的数据复制到新的堆中

    随后执行store_release函数，问题就在这里了，之前申请的0x2000的堆还剩0x1cf0，并没有用完，但是却对其执行glibc的free操作，但是之后这个free后的堆却仍然可以使用，这就是我们所知的UAF, 释放后重用漏洞

    其中，bb = chainbase->next = heap1, 而且next->text == bb + 0x10

    所以能成功执行free(bb)

    因为输入了大量的数据，所以随后还会执行：

    • store_extend(next->text, 0x200, 0x400)
    • store_extend(next->text, 0x400, 0x800)
    • store_extend(next->text, 0x800, 0x1000)

    但是这些都不能满足判断：if (CS ptr + rounded_oldsize != CS (next_yield[store_pool]) || inc > yield_length[store_pool] + rounded_oldsize - oldsize)

    所以都是返回true，不会进入到下面分支

    但是到store_extend(next->text, 0x1000, 0x2000)的时候，因为满足了第二个判断0x2000-0x1000 > yield_length[store_pool], 所以又一次返回了False

    所以再一次进入分支，调用store_get(0x2000)

    因为0x2000 > yield_length所以进入该分支：

    这里就是该漏洞的关键利用点

    首先：newblock = current_block = heap1

    然后：newblock = newblock->next

    我猜测的meh的情况和我加了printf进行测试的情况是一样的，在printf中需要malloc一块堆用来当做缓冲区，所以在heap1下面又多了一块堆，在free了heap1后，heap1被放入了unsortbin，fd和bk指向了arena

    所以这个时候，heap1->next = fd = arena_top

    之后的流程就是：

    • current_block = arena_top
    • next_yield = arena_top+0x10
    • return next_yield = arena_top+0x10
    • next_yield = arena_top+0x2010

    在执行完store_get后就是执行memcpy:

    上面的newtext就是store_get返回的值arena_top+0x10

    把用户输入的数据copy到了arena中，最后达到了控制RIP=0xdeadbeef造成crash的效果

    但是实际情况就不一样了，因为没有printf，所以heap1是最后一块堆，再free之后，就会合并到top_chunk中，fd和bk字段不会被修改，在释放前，这两个字段也是用来储存storeblock结构体的next和length，所以也是没法控制的

    总结

    CVE-2017-16943的确是一个UAF漏洞，但是在我的研究中却发现没法利用meh提供的PoC造成crash的效果

    之后我也尝试其他利用方法，但是却没找到合适的利用链

    发现由于Exim自己实现了一个堆管理，所以在heap1之后利用store_get再malloc一块堆是不行的因为current_block也会被修改为指向最新的堆块，所以必须要能在不使用store_get的情况下，malloc一块堆，才能成功利用控制RIP，因为exim自己实现了堆管理，所以都是使用store_get来获取内存，这样就只能找printf这种有自己使用malloc的函数，但是我找到的这些函数再调用后都会退出receive_msg函数的循环，所以没办法构造成一个利用链

    引用

    1. Exim源码
    2. Bugzilla-2199
    作者：dawu | Categories:安全研究、技术分享 | Tags:
    没有评论

  • TP-LINK WR941N路由器研究

    2017-11-10

    作者：Hcamael@知道创宇404实验室

    之前看到了一个CVE, CVE-2017-13772

    是TP-Link WR940N后台的RCE, 手头上正好有一个TP-Link WR941N的设备，发现也存在相同的问题，但是CVE-2017-13772文章中给的EXP并不通用

    所以准备进行复现和exp的修改，折腾了将近4天，记录下过程和遇到的坑

    第一次研究mips指令的RCE，之前只学了intel指令集的pwn，所以进度挺慢的

    Day 1

    第一天当然是配环境了，该路由器本身在默认情况下是不提供shell的，在@fenix帮助下获取到了路由器的shell，该款路由器上的busybox的命令比较少，curl, nc, wget这些命令都没有，只能用tftp进行数据传输，而且只有/tmp目录可写，路由器重启后，传上去的文件就没了，这些问题都可以通过刷固件解决，不过太麻烦了，只需要传上去一个gdbserver就好了，能根据固件中的bin得知这是一个大端mips指令集的设备，gdbserver也不用自己编译，直接下编译好的: https://github.com/rapid7/embedded-tools/tree/master/binaries/gdbserver

    把gdbserver.mipsbe通过tftp上传到路由器的/tmp目录下

    然后根据cve-2017-13772分析文章说的那样使用gdbserver attach httpd最新的一个进程，然后就可以进行远程gdb调试了

    Day 2

    第二天准备开始调试，但是发现gdb的两个编译选项, 一个--host，表示gdb运行的环境，一般默认就是本机环境，还有一个--target表示调试的目标环境，默认也是本机环境，所以一个64位ubuntu上默认的gdb只能调试64 elf程序。所以需要设置--target=mipsbel-linux参数进行编译gdb，才能调试大端的mips程序。

    编译差不多编译了半天，准备改天搞一个8核的机器专门来编译程序….

    编译成功后，就可以进行远程调试了，在路由器上执行:

    然后使用编译好gdb进行调试：

    但是失败了，又折腾了半天

    Day 3

    第三天才真正的开始调试程序，首先说说我第二天遇到的问题，问题是下了断点没用，原因比较傻逼，我下断点的地址是wr940n的地址，我把两个bin搞混了

    然后根据cve-2017-13772分析文章中说的栈溢出的指令，在wr941n中也找到了该指令，而溢出情况也是一样，所以拿了wr940n的exp来打了一遍，结果当然是失败了。

    在wr940n的exp中，ROP是在libuClibc-0.9.30.so中找的，根据$ cat /proc/pid/maps命令，发现wr941n路由器的基地址和文章中显示的wr940n路由器的是一样的，然后再比较libuClibc-0.9.30.so文件的hash值，发现不同，所以要修改ROP地址。

    由于libc文件太大，用手找太累了，所以使用了那篇文章中的ida的mipsrop插件，这里又踩了一个坑，因为我用的是ida7.0，而这个插件只能在ida6.8(更低的没试过)版本使用。

    修改了ROP后，再进行尝试exp，发现仍然失败，然后进行调试查看原因，跟踪ROP执行流，发现能成功跳转到栈上执行shellcode，但是shellcode和文章中的，文章中的shellcode开头有一个使用xor进行解密的过程，执行完之后的指令和文章中的不一样。所以准备自己写一个shellcode

    Day 4

    第四天就是开始写shellcod，首先给个mips指令和bin互转的网站：Online Assembler and Disassembler

    然后说说写的过程中遇到的问题，该路由器输入是不接受\x00和\x20，所以ROP不是在ELF中寻找而是去libc中寻找：libuClibc基地址：0x2aae000， httpd基地址：0x00400000

    如果在ELF中寻找ROP，则地址中总会有个\x00，所以ROP是在libc中寻找不存在\x00和\x20的地址。但是在shellcode中，这两个字符却很难避免，所以那篇文章中对shellcode进行了xor加密

    wr940n的exp使用的是一个bind shell的shellcode，而我改成了一个反弹shell的shellcode

    然后就是最后遇到的一个大坑，使用gdb调试成功的一个反弹shell的shellcode，在实际测试中却失败了，使用gdb成功，直接打失败，因为这个问题折腾了挺长的时间

    然后查阅资料，在看雪的一篇文章中找到了原因：

    mips 的 exp 编写中还有一个问题就是 cache incoherency。MIPS CPUs 有两个独立的 cache：指令 cache 和数据 cache。指令和数据分别在两个不同的缓存中。当缓存满了，会触发 flush，将数据写回到主内存。攻击者的攻击 payload 通常会被应用当做数据来处理，存储在数据缓存中。当 payload 触发漏洞，劫持程序执行流程的时候，会去执行内存中的 shellcode。

    如果数据缓存没有触发 flush 的话，shellcode 依然存储在缓存中，而没有写入主内存。这会导致程序执行了本该存储 shellcode 的地址处随机的代码，导致不可预知的后果。

    最简单可靠的让缓存数据写入内存的方式是调用一个堵塞函数。比如 sleep(1) 或者其他类似的函数。sleep 的过程中，处理器会切换上下文让给其他正在执行的程序，缓存会自动执行 flush。

    这个坑点在那篇文章中也提及了，但是没具体说明，如果没实际踩一踩，不一定能理解。但是讲道理，如果直接用wr940n的exp，修改下ROP地址和shellcode，应该是不会遇到这个坑的，但是我仍然遇到了，经过研究发现，是usleep的问题，猜测是由于堵塞的时间过短所以未执行flush？然后进行实际测试了一番，把usleep的时间修改为18217，同样没用，然后简单看了下两者的汇编，发现usleep只是简单的调用nanosleep，而sleep除了调用nanosleep还进行其他相关的操作，网上没搜到相关文章，因为精力有限，作为遗留问题，以后有时间的时候再继续研究。

    不过有几个猜测，

    1. 时间问题，usleep的单位是微秒，18217也只有10ms，是不是要睡到1s？因为找不到合适的ROP，所以暂时没法证明
    2. flush内存是靠sleep中的几个信号相关的函数？

    所以最终我的做法是在wr940n的exp的ROP链中，调用的是usleep(0xc*2+1)，但是我将usleep改成sleep => sleep(0xc*2+1)，数据缓存被成功flush到主内存中，就能成功执行shellcode了

    Shellcode编写

    在本次研究中，最后时间的除了一开始的调试环境搭建外，就是shellcode的编写了，因为在那篇cve分析的文章中已经给出了wr940n的exp，ROP只需要修改修改地址就好了，所以工作量最大的还是在Shellcode的编写这一部分

    首先是syscall部分，比如：

    • mips采用的是RISC，32位系统下，指令固定采用4byte，syscall的字节码是\x0c，剩余的三字节默认用\x00补全，但是因为路由器不接受\x00的输入，所以在大端的情况下改成\x01\x01\x01\x0c，进行反汇编，就是syscall 0x40404

    系统调用的相关函数除了几个mips特有的，其他的都是跟linux下的syscall一样，可参考: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/uapi/asm/unistd.h

    比如sys_socket：

    所以$v0=4183表示的就是socket函数，具体参数信息可以去参考linux的系统调用: http://asm.sourceforge.net/syscall.html

    现在，先用c来实现一遍反连shell的代码：

    这里有个关键点，https://chromium.googlesource.com/chromiumos/third_party/glibc-ports/+/6cc02c7aaedec87cfb2d105f9682b12b2154e54f/sysdeps/unix/sysv/linux/mips/bits/socket.h

    和其他架构不一样，mips架构中，tcp是2，udp是1

    所以上面的代码比如在ubuntu中，是一个udp反连的代码，但是在mips中就是tcp反连

    还有一点就是wr941n是大端，所以12345端口是0x3039而不是0x3930，ip地址同理

    然后把上面代码转换成mips指令的汇编

    但是有个问题，之前说了该路由器不接收\x00和\x20两个字符，而上面的汇编转换成字节码:

    所以要把这句指令进行修改, 因为$a0和$a1的值都为2，所以可以这样修改：

    把上面的汇编转成shellcode替换exp中的shellcode，实际测试，又发现一个问题，设备成功反连了控制端，但是却不能执行命令，到路由器上用ps查看，发现sh已经变为僵尸进程

    经研究，问题出在execve("/bin/sh",0,0)，如果我修改成execve("/bin/sh", ["/bin/sh", 0], 0)则成功反弹shell，可以任意命令执行

    参考链接

    1. https://www.fidusinfosec.com/tp-link-remote-code-execution-cve-2017-13772/
    2. https://github.com/rapid7/embedded-tools/tree/master/binaries/gdbserver
    3. http://shell-storm.org/online/Online-Assembler-and-Disassembler/?opcodes=%5Cx3c%5Cx1c%5Cx2a%5Cxb3%5Cx37%5Cx9c%5Cx17%5Cxb0&arch=mips32&endianness=big#disassembly
    4. https://www.kanxue.com/article-read-218.htm
    5. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/uapi/asm/unistd.h
    6. http://asm.sourceforge.net/syscall.html
    7. https://chromium.googlesource.com/chromiumos/third_party/glibc-ports/+/6cc02c7aaedec87cfb2d105f9682b12b2154e54f/sysdeps/unix/sysv/linux/mips/bits/socket.h
    作者：dawu | Categories:安全研究、技术分享 | Tags:
    没有评论

  • D-Link系列路由器漏洞挖掘入门

    2017-10-27

    作者：Sebao@知道创宇404实验室

    前言

    前几天去上海参加了geekpwn，看着大神们一个个破解成功各种硬件，我只能在下面喊 6666，特别羡慕那些大神们。所以回来就决定好好研究一下路由器，争取跟上大神们的步伐。看网上公开的D-Link系列的漏洞也不少，那就从D-Link路由器漏洞开始学习。

    准备工作

    既然要挖路由器漏洞，首先要搞到路由器的固件。
    D-Link路由器固件下载地址：

    ftp://ftp2.dlink.com/PRODUCTS/

    下载完固件发现是个压缩包，解压之后里面还是有一个bin文件。听说用binwalk就可以解压。kali-linux自带binwalk，但是缺少一些依赖，所以还是编译安装了一下。

    按照上面的命令就可以完整的安装binwalk了，这样就可以解开市面上的大部分固件包。
    然后用 binwalk -Me 固件包名称 解固件，然后我们会得到以下划线开头的名称的文件夹，文件夹里squashfs-root文件夹，就是路由器的完整固件包。

    漏洞挖掘

    此文章针对历史路由器的web漏洞进行分析，路由器的web文件夹 一般就在suashfs-root/www或者
    suashfs-root/htdocs文件夹里。路由器固件所使用的语言一般为 asp,php,cgi,lua 等语言。这里主要进行php的代码审计来挖掘漏洞。

    D-Link DIR-645 & DIR-815 命令执行漏洞

    Zoomeye dork: DIR-815 or DIR-645

    这里以 D-Link DIR-645固件为例，解开固件进入 suashfs-root/htdocs 文件夹。

    这个漏洞出现在 diagnostic.php文件。直接看代码

    分析代码可以看到，这里没有进行权限认证，所以可以直接绕过登录。继续往下看，set("/runtime/diagnostic/ping", $_POST["dst"]); 这段代码就是造成漏洞的关键代码。参数dst 没有任何过滤直接进入到了 ping的命令执行里，导致任意命令执行漏洞。继续往下看 $result = "OK";无论是否执行成功，这里都会显示OK。所以这是一个盲注的命令执行。以此构造payload

    因为是盲注的命令执行，所以这里需要借助一个盲打平台（如：ceye），来验证漏洞是否存在。

    D-Link DIR-300 & DIR-320 & DIR-600 & DIR-615 信息泄露漏洞

    Zoomeye dork:DIR-300 or DIR-600

    这里以 D-Link DIR-300固件为例，解开固件进入 suashfs-root/www 文件夹。

    漏洞出现在/model/__show_info.php文件。

    这里看到已经禁止了$REQUIRE_FILE的参数为var/etc/httpasswd和var/etc/hnapasswd。这么一看无法获取账号密码。但是我们可以从根路径开始配置httpasswd的路径，就可以绕过这个过滤了。

    payload：

    这里设置REQUIRE_FILE=/var/etc/httpasswd 成功绕过上面的 if判断，进行任意文件读取。

    D-Link DIR-300 & DIR-320 & DIR-615 权限绕过漏洞

    Zoomeye dork:DIR-300 or DIR-615

    这里以 D-Link DIR-300固件为例，解开固件进入 suashfs-root/www 文件夹

    默认情况下，Web界面中的所有页面都需要进行身份验证，但是某些页面（如 登录页面） 必须在认证之前访问。 为了让这些页面不进行认证，他们设置了一个PHP变量NO_NEED_AUTH：

    此漏洞触发的原因在于 全局文件 _html_head.php。

    这里我们看到 $NO_NEED_AUTH!="1" 如果 $NO_NEED_AUTH 不为 1 则进入身份认证。如果我们把$NO_NEED_AUTH值 设置为 1 那就绕过了认证进行任意操作。

    payload：

    localhost/bsc_lan.php?NO_NEED_AUTH=1&AUTH_GROUP=0

    这里AUTH_GROUP=0 表示admin权限

    D-Link DIR-645 信息泄露漏洞

    Zoomeye dork:DIR-645

    这里以 D-Link DIR-300固件为例，解开固件进入 suashfs-root/htdocs 文件夹

    D-Link DIR-645 getcfg.php 文件由于过滤不严格导致信息泄露漏洞。

    这里我们可以看到 $GETCFG_SVC 没有任何过滤直接获取了 POST 传递过来的SERVICES的值。如果$GETCFG_SVC不为空，则进行文件读取。这里我们就可以读取存储此设备信息的DEVICE.ACCOUNT.xml.php文件。

    payload：

    总结

    可以发现此篇文章所提及的漏洞都是web领域的常见漏洞，如权限绕过，信息泄露，命令执行等漏洞。由于路由器的安全没有得到足够的重视，此文涉及到的漏洞都是因为对参数过滤不严格所导致的。
    路由器的漏洞影响还是很广泛的，在此提醒用户，及时更新路由器固件，以此避免各种入侵事件，以及个人信息的泄露。

    参考链接

    作者：dawu | Categories:安全研究、技术分享 | Tags:
    没有评论

  • Typecho 前台 getshell 漏洞分析

    2017-10-26

    作者：LoRexxar’@知道创宇404实验室

    0x01 简述

    Typecho是一个简单，轻巧的博客程序。基于PHP，使用多种数据库（Mysql，PostgreSQL，SQLite）储存数据。在GPL Version 2许可证下发行，是一个开源的程序，目前使用SVN来做版本管理。

    2017年10月13日，Typecho爆出前台代码执行漏洞，知道创宇404团队研究人员成功复现了该漏洞。

    经过分析确认，该漏洞可以无限制执行代码，通过这种方式可以导致getshell。

    0x02 复现

    打开安装好的Typecho

    生成对应的payload

    设置相应的cookie并发送请求向

    成功执行phpinfo

    0x03 漏洞分析

    漏洞的入口点在install.php，进入install.php首先经过两个判断

    只要传入GET参数finish，并设置referer为站内url即可。

    跟入代码，找到漏洞点入口点，install.php 232行到237行

    看起来比较清楚，一个比较明显的反序列化漏洞

    问题在于如何利用，反序列化能够利用的点必须要有相应的魔术方法配合。其中比较关键的只有几个。

    其中__destruct()是在对象被销毁的时候自动调用，__Wakeup在反序列化的时候自动调用，__toString()是在调用对象的时候自动调用。

    这里如果构造的反序列化是一个数组，其中adapter设置为某个类，就可以触发相应类的__toString方法

    寻找所有的toString方法，我暂时只找到一个可以利用的的类方法。

    /var/Typecho/Feed.php 文件223行

    顺着分析tostring函数

    290行 调用了$item['author']->screenName，这是一个当前类的私有变量

    358行 同样调用了同样的变量，这里应该也是可以利用的

    这里要提到一个特殊的魔术方法__get，__get会在读取不可访问的属性的值的时候调用，我们可以通过设置item来调用某个位置的__get魔术方法，让我们接着寻找。

    /var/Typecho/Request.php 第269行应该是唯一一个可利用的__get方法.

    跟入get函数

    最后进入159行 applyFilter函数

    我们找到了call_user_func函数，回溯整个利用链

    我们可以通过设置item['author']来控制Typecho_Request类中的私有变量，这样类中的_filter和_params['screenName']都可控，call_user_func函数变量可控，任意代码执行。

    但是当我们按照上面的所有流程构造poc之后，发请求到服务器，却会返回500.

    回顾一下代码

    在install.php的开始，调用了ob_start()

    在php.net上关于ob_start的解释是这样的。

    因为我们上面对象注入的代码触发了原本的exception，导致ob_end_clean()执行，原本的输出会在缓冲区被清理。

    我们必须想一个办法强制退出，使得代码不会执行到exception，这样原本的缓冲区数据就会被输出出来。

    这里有两个办法。
    1、因为call_user_func函数处是一个循环，我们可以通过设置数组来控制第二次执行的函数，然后找一处exit跳出，缓冲区中的数据就会被输出出来。
    2、第二个办法就是在命令执行之后，想办法造成一个报错，语句报错就会强制停止，这样缓冲区中的数据仍然会被输出出来。

    解决了这个问题，整个利用ROP链就成立了

    0x04 poc

    0x05 Reference

    0x06 后记

    我们在10月25日收到p0的漏洞分析投稿http://p0sec.net/index.php/archives/114//http://p0sec.net/index.php/archives/114/，与我们撞洞了，这里一并表示感谢。

    作者：dawu | Categories:安全研究、技术分享 | Tags:
    没有评论

  • 前端防御从入门到弃坑–CSP变迁

    2017-10-25

    作者：LoRexxar’@知道创宇404实验室

    0x01 前端防御的开始

    对于一个基本的XSS漏洞页面，它发生的原因往往是从用户输入的数据到输出没有有效的过滤，就比如下面的这个范例代码。

    对于这样毫无过滤的页面，我们可以使用各种方式来构造一个xss漏洞利用。

    对于这样的漏洞点来说，我们通常会使用htmlspecialchars函数来过滤输入，这个函数会处理5种符号。

    一般意义来说，对于上面的页面来说，这样的过滤可能已经足够了，但是很多时候场景永远比想象的更多。

    对于这样的场景来说，上面的过滤已经没有意义了，尤其输入点在script标签里的情况，刚才的防御方式可以说是毫无意义。

    一般来说，为了能够应对这样的xss点，我们会使用更多的过滤方式。

    首先是肯定对于符号的过滤，为了能够应对各种情况，我们可能需要过滤下面这么多符号

    但事实上过度的过滤符号严重影响了用户正常的输入，这也是这种过滤使用非常少的原因。

    大部分人都会选择使用htmlspecialchars+黑名单的过滤方法

    这样的过滤方式如果做的足够好，看上去也没什么问题，但回忆一下我们曾见过的那么多XSS漏洞，大多数漏洞的产生点，都是过滤函数忽略的地方。

    那么，是不是有一种更底层的防御方式，可以从浏览器的层面来防御漏洞呢？

    CSP就这样诞生了…

    0x02 CSP（Content Security Policy）

    Content Security Policy （CSP）内容安全策略，是一个附加的安全层，有助于检测并缓解某些类型的攻击，包括跨站脚本（XSS）和数据注入攻击。

    CSP的特点就是他是在浏览器层面做的防护，是和同源策略同一级别，除非浏览器本身出现漏洞，否则不可能从机制上绕过。

    CSP只允许被认可的JS块、JS文件、CSS等解析，只允许向指定的域发起请求。

    一个简单的CSP规则可能就是下面这样

    其中的规则指令分很多种，每种指令都分管浏览器中请求的一部分。

    每种指令都有不同的配置

    简单来说，针对不同来源，不同方式的资源加载，都有相应的加载策略。

    我们可以说，如果一个站点有足够严格的CSP规则，那么XSS or CSRF就可以从根源上被防止。

    但事实真的是这样吗？

    0x03 CSP Bypass

    CSP可以很严格，严格到甚至和很多网站的本身都想相冲突。

    为了兼容各种情况，CSP有很多松散模式来适应各种情况。

    在便利开发者的同时，很多安全问题就诞生了。

    CSP对前端攻击的防御主要有两个：
    1、限制js的执行。
    2、限制对不可信域的请求。

    接下来的多种Bypass手段也是围绕这两种的。

    1

    天才才能写出来的CSP规则，可以加载任何域的js

    随意开火

    2

    最普通最常见的CSP规则，只允许加载当前域的js。

    站内总会有上传图片的地方，如果我们上传一个内容为js的图片，图片就在网站的当前域下了。

    直接加载图片就可以了

    3

    当你发现设置self并不安全的时候，可能会选择把静态文件的可信域限制到目录，看上去好像没什么问题了。

    但是如果可信域内存在一个可控的重定向文件，那么CSP的目录限制就可以被绕过。

    假设static目录下存在一个302文件

    像刚才一样，上传一个test.jpg
    然后通过302.php跳转到upload目录加载js就可以成功执行

    4

    CSP除了阻止不可信js的解析以外，还有一个功能是组织向不可信域的请求。

    在上面的CSP规则下，如果我们尝试加载外域的图片，就会被阻止

    在CSP的演变过程中，难免就会出现了一些疏漏

    在CSP1.0中，对于link的限制并不完整，不同浏览器包括chrome和firefox对CSP的支持都不完整，每个浏览器都维护一份包括CSP1.0、部分CSP2.0、少部分CSP3.0的CSP规则。

    5

    无论CSP有多么严格，但你永远都不知道会写出什么样的代码。

    下面这一段是Google团队去年一份关于CSP的报告中的一份范例代码

    机缘巧合下，你写了一段执行输入字符串的js。

    事实上，很多现代框架都有这样的代码，从既定的标签中解析字符串当作js执行。

    对于这种情况来说，CSP就毫无意义了

    6

    或许你的站内并没有这种问题，但你可能会使用jsonp来跨域获取数据，现代很流行这种方式。

    但jsonp本身就是CSP的克星，jsonp本身就是处理跨域问题的，所以它一定在可信域中。

    这样你就可以构造任意js，即使你限制了callback只获取\w+的数据，部分js仍然可以执行，配合一些特殊的攻击手段和场景，仍然有危害发生。

    唯一的办法是返回类型设置为json格式。

    7

    比起刚才的CSP规则来说，这才是最最普通的CSP规则。

    unsafe-inline是处理内联脚本的策略，当CSP中制定script-src允许内联脚本的时候，页面中直接添加的脚本就可以被执行了。

    既然我们可以任意执行js了，剩下的问题就是怎么绕过对可信域的限制。

    第一种办法是通过js来生成link prefetch

    这种办法只有chrome可以用，但是意外的好用。

    2 跳转 跳转 跳转

    在浏览器的机制上， 跳转本身就是跨域行为

    通过跨域请求，我们可以把我们想要的各种信息传出

    3 跨域请求

    在浏览器中，有很多种请求本身就是跨域请求，其中标志就是href。

    包括表单的提交，都是跨域请求

    0x04 CSP困境以及升级

    在CSP正式被提出作为减轻XSS攻击的手段之后，几年内不断的爆出各种各样的问题。

    2016年12月Google团队发布了关于CSP的调研文章《CSP is Dead, Long live CSP》

    https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45542.pdf

    Google团队利用他们强大的搜索引擎库，分析了超过160w台主机的CSP部署方式，他们发现。

    加载脚本最常列入白名单的有15个域，其中有14个不安全的站点，因此有75.81%的策略因为使用了了脚本白名单，允许了攻击者绕过了CSP。总而言之，我们发现尝试限制脚本执行的策略中有94.68%是无效的，并且99.34%具有CSP的主机制定的CSP策略对xss防御没有任何帮助。

    在paper中，Google团队正式提出了两种以前被提出的CSP种类。

    1、nonce script CSP

    动态的生成nonce字符串，只有包含nonce字段并字符串相等的script块可以被执行。

    这个字符串可以在后端实现，每次请求都重新生成，这样就可以无视哪个域是可信的，只要保证所加载的任何资源都是可信的就可以了。

    2、strict-dynamic

    SD意味着可信js生成的js代码是可信的。

    这个CSP规则主要是用来适应各种各样的现代前端框架，通过这个规则，可以大幅度避免因为适应框架而变得松散的CSP规则。

    Google团队提出的这两种办法，希望通过这两种办法来适应各种因为前端发展而出现的CSP问题。

    但攻与防的变迁永远是交替升级的。

    1、nonce script CSP Bypass

    2016年12月，在Google团队提出nonce script CSP可以作为新的CSP趋势之后，圣诞节Sebastian Lekies提出了nonce CSP的致命缺陷。

    Nonce CSP对纯静态的dom xss简直没有防范能力

    http://sirdarckcat.blogspot.jp/2016/12/how-to-bypass-csp-nonces-with-dom-xss.html

    Web2.0时代的到来让前后台交互的情况越来越多，为了应对这种情况，现代浏览器都有缓存机制，但页面中没有修改或者不需要再次请求后台的时候，浏览器就会从缓存中读取页面内容。

    从location.hash就是一个典型的例子

    如果JS中存在操作location.hash导致的xss，那么这样的攻击请求不会经过后台，那么nonce后的随机值就不会刷新。

    这样的CSP Bypass方式我曾经出过ctf题目，详情可以看

    https://lorexxar.cn/2017/05/16/nonce-bypass-script/

    除了最常见的location.hash，作者还提出了一个新的攻击方式，通过CSS选择器来读取页面内容。

    当匹配到对应的属性，页面就会发出相应的请求。

    页面只变化了CSS，纯静态的xss。

    CSP无效。

    2、strict-dynamic Bypass

    2017年7月 Blackhat，Google团队提出了全新的攻击方式Script Gadgets。

    Strict-dynamic的提出正是为了适应现代框架
    但Script Gadgets正是现代框架的特性

    Script Gadgets
    一种类似于短标签的东西，在现代的js框架中四处可见

    Script Gadgets本身就是动态生成的js，所以对新型的CSP几乎是破坏式的Bypass。


    0x05 写在最后

    说了一大堆，黑名单配合CSP仍然是最靠谱的防御方式。

    但，防御没有终点…

    0x06 ref

    作者：dawu | Categories:安全研究、技术分享 | Tags:
    没有评论
« 上一页 下一页 »