新闻链接：http://www.freebuf.com/vuls/64521.html
新闻时间：2015-04-21
新闻正文：由于过去的6个月比较忙，没有跟进D-Link最新的“诡计”。为了寻求一些乐趣，于是到了他们的主页上，就看到了这样的一幕：
我认为这种路由器最”insane”（疯狂）的一点就是它运行包含数年来已经被揭露的相同的bug的固件，而且这种攻击也一直在持续。然后，我就开始了对它的探索之旅……
OK，首先我们像通常那样先获取最新发布的固件，用binwalk来获取一些基本信息：
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 DLOB firmware header, boot partition: "dev=/dev/mtdblock/7"
116 0x74 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 4905376 bytes
1835124 0x1C0074 PackImg section delimiter tag, little endian size: 6345472 bytes; big endian size: 13852672 bytes
1835156 0x1C0094 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 13852268 bytes, 2566 inodes, blocksize: 131072 bytes, created: 2015-02-11 09:18:37
看到没，这是非常标准的Linux固件镜像，如果你曾经留意过过去几年来任意一款D-Link固件的话，你也许会认出主目录的结构：
$ ls squashfs-root
bin dev etc home htdocs include lib mnt mydlink proc sbin sys tmp usr var www
有趣的htdocs/cgibin文件
所有的HTTP/UPnP/HNAP文件都位于htdocs目录下，其中最有趣的文件是htdocs/cgibin。
一般ARM ELF二进制文件是用来支持web服务器，与CGI、UPnP及HNAP相关的URLs也被链接到了这种二进制文件中：
$ ls -l htdocs/web/*.cgi
lrwxrwxrwx 1 eve eve 14 Mar 31 22:46 htdocs/web/captcha.cgi -> /htdocs/cgibin
lrwxrwxrwx 1 eve eve 14 Mar 31 22:46 htdocs/web/conntrack.cgi -> /htdocs/cgibin
lrwxrwxrwx 1 eve eve 14 Mar 31 22:46 htdocs/web/dlapn.cgi -> /htdocs/cgibin
lrwxrwxrwx 1 eve eve 14 Mar 31 22:46 htdocs/web/dlcfg.cgi -> /htdocs/cgibin
lrwxrwxrwx 1 eve eve 14 Mar 31 22:46 htdocs/web/dldongle.cgi -> /htdocs/cgibin
lrwxrwxrwx 1 eve eve 14 Mar 31 22:46 htdocs/web/fwup.cgi -> /htdocs/cgibin
lrwxrwxrwx 1 eve eve 14 Mar 31 22:46 htdocs/web/fwupload.cgi -> /htdocs/cgibin
lrwxrwxrwx 1 eve eve 14 Mar 31 22:46 htdocs/web/hedwig.cgi -> /htdocs/cgibin
lrwxrwxrwx 1 eve eve 14 Mar 31 22:46 htdocs/web/pigwidgeon.cgi -> /htdocs/cgibin
lrwxrwxrwx 1 eve eve 14 Mar 31 22:46 htdocs/web/seama.cgi -> /htdocs/cgibin
lrwxrwxrwx 1 eve eve 14 Mar 31 22:46 htdocs/web/service.cgi -> /htdocs/cgibin
lrwxrwxrwx 1 eve eve 14 Mar 31 22:46 htdocs/web/webfa_authentication.cgi -> /htdocs/cgibin
lrwxrwxrwx 1 eve eve 14 Mar 31 22:46 htdocs/web/webfa_authentication_logout.cgi -> /htdocs/cgibin
也许在分析的时候会遇到一些麻烦，但是很多有用的字符串会给我们带来很多帮助。第一件main所做的事情就是拿argv[0]和所有已知的符号链（captcha.cgi,conntrack.cgi等）相比较，来决定接下来该采取什么处理操作：
“Staircase” code graph, typical of if-else statements
这些都是用strcmp函数来对那些符号链接名进行比较：
Function handlers for various symlinks
这些都使得关联函数句柄和相应的符号链接名以及合适地重命名函数名更加容易一些：
Renamed symlink function handlers
现在我们已经标示了一些高级的函数，然后就一起来寻找那些bug吧。其它的一些本质上运行相同固件的D-Link设备之前都已经通过它们的HTTP和UPnP接口进行了相关的漏洞利用。但是，这个在cgibin中被hnap_main操作的HNAP接口，看起来好像经常被忽略掉了。
HNAP协议
HNAP(Home Network Administration Protocol,家庭网络管理协议)是一种基于SOAP(Simple Object Access Protocol,简单对象管理协议)的协议，和UPnP很像，通常被D-Link的”EZ”设置程序用来初始化设置路由器。和UPnP不一样的是，除了GetDeviceInfo（基本上没用）外所有的HNAP操作都要求进行HTTP基本认证：
POST /HNAP1 HTTP/1.1
Host: 192.168.0.1
Authorization: Basic YWMEHZY+
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://purenetworks.com/HNAP1/AddPortMapping"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<AddPortMapping xmlns="http://purenetworks.com/HNAP1/">
<PortMappingDescription>foobar</PortMappingDescription>
<InternalClient>192.168.0.100</InternalClient>
<PortMappingProtocol>TCP</PortMappingProtocol>
<ExternalPort>1234</ExternalPort>
<InternalPort>1234</InternalPort>
</AddPortMapping>
</soap:Body>
</soap:Envelope>
这个SOAPAction头在HNAP请求中是极为重要的，因为它指明了HNAP将会采取什么样的操作（在上面的例子中是AddPortMapping）。
由于cgibin是被web服务器作为CGI来执行，hnap_main通过环境变量来访问HNAP请求数据，比如SOAPAction头部。
SOAPAction = getenv(“HTTP_SOAPACTION”);
在hnap_main的结尾处有一个通过system来执行的shell命令，这个命令是由sprintf动态链接产生的：
sprintf(command, “sh %s%s.sh > /dev/console”, “/var/run/”, SOAPAction);
很明显，hnap_main是使用来自SOAPAction头的数据作
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
