欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

运用WebDAV特性建立windows系统下隐蔽的后门

来源:本站整理 作者:佚名 时间:2017-09-21 TAG: 我要投稿
User-Agent: Microsoft-WebDAV-MiniRedir/10.0.14393
translate: f
Host: 10.211.55.2
WebDAV办事器平日将经由进程以下相应停止回应,具体阐明其完成支撑的一切选项:
HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Thu, 07 Sep 2017 10:15:36 GMT
Content-Length: 0
DAV: 1
Allow: GET,HEAD,PUT,DELETE,MKCOL,COPY,MOVE,PROPFIND,OPTIONS
Proxy-Connection: Close
Connection: Close
Age: 0
那末平日会应用一些标题为“Depth: 0”的PROPFIND哀求,以便WebDAV客户端获得无关它地点地位的信息(目次,巨细,创立日期和其余范例的元数据)和某些默许的Windows文件作为“Desktop.ini”或“Autorun.inf”(不管这些文件能否存在于WebDAV办事器上)。 哀求看起来像如许:
PROPFIND / HTTP/1.1
Connection: Keep-Alive
User-Agent: Microsoft-WebDAV-MiniRedir/10.0.14393
Depth: 0
translate: f
Content-Length: 0
Host: 10.211.55.2
重要的是要留意,在这一点上,客户端的硬盘驱动器上没有传输现实的文件,也没有缓存。
而后,假如WebDAV客户端请求长途目次中一切文件的列表,它将收回一些PROPFIND哀求,此中一个标题为“Depth: 1”,以下所示:
PROPFIND / HTTP/1.1
Connection: Keep-Alive
User-Agent: Microsoft-WebDAV-MiniRedir/10.0.14393
Depth: 1
translate: f
Content-Length: 0
Host: 10.211.55.2
WebDAV办事器将答复以后目次中存在的一切文件的XML格局列表,和一些元数据信息(巨细,创立日期等)。 每一个  块对应一条文件信息:
HTTP/1.1 207 Multi-Status
Server: nginx/1.6.2
Date: Thu, 07 Sep 2017 10:27:23 GMT
Content-Length: 8084
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
xml version="1.0" encoding="utf-8" ?>
D:multistatus xmlns:D="DAV:">
D:response>
D:href>/D:href>
D:propstat>
D:prop>
D:creationdate>2017-09-07T10:27:23ZD:creationdate>
D:displayname>filenameD:displayname>
D:getcontentlanguage/>
D:getcontentlength>4096D:getcontentlength>
D:getcontenttype/>
D:getetag/>
D:getlastmodified>Thu, 07 Sep 2017 10:27:23 GMTD:getlastmodified>
D:lockdiscovery/>
D:resourcetype>D:collection/>D:resourcetype>
D:source/>
D:supportedlock/>
D:prop>
D:status>HTTP/1.1 200 OKD:status>
D:propstat>
D:response>
[...]
D:multistatus>
在这一点上,仍旧没有现实的文件传输,客户端硬盘上没有缓存文件。
终极,当WebDAV客户端想要拜访文件时,它将收回现实传输文件的哀求,以下所示:
GET /calc.hta HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
User-Agent: Microsoft-WebDAV-MiniRedir/10.0.14393
translate: f
Host: 10.211.55.2
WebDAV办事器应用包含哀求文件的非常尺度的HTTP相应停止答复。 在这一点上,文件被传输并缓存在客户端的驱动器上(C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore\Tfs_DAV\)。
咱们可以或许看到,上述两个毛病仅在文件现实从办事器传输到客户端时产生。然则事实证实,用于列出目次中的文件的PROPFIND哀求也拥有可用于传输随意率性数据的大批信息。
仅应用PROPFIND哀求
以是咱们想要完成的只是应用PROPFIND哀求传输随意率性数据。我提出了以下设法主意:
1.    文件名自己就是在列出具备PROPFIND哀求的目次时传送的信息。
2.    目次中可以或许必要/必要的文件数目尽可以或许多(可以或许会有一个限定,但仍旧可以或许处置)。
3.    固然这取决于WebDAV客户端和办事器完成,但每一个文件名可以或许大抵为250个字符。
4.    文件名只能支撑必定数目的字符(比方'/'和''不支撑)
这就让我产生了以下设法主意,假定给定一个我想通报的Payload,可经由进程以下步调处置:
1.    先对其停止base64编码
2.    调换文件名中不支撑的一切字符(用'_'调换'/',这彷佛是罕见的做法)
3.    将其切成250个字符的块
4.    使其可用作目次名
在远端,我必要找到一种办法:
1.    只列出虚构目次上的文件(不GET任何器械)
2.    重组那些块
3.    将调换的字符调换返来
4.    将base64成果解码回初始Payload
一切这些都必要支付价值:大批的机能和通讯挥霍。但它可以或许让咱们解脱上述两个毛病!
为了完成这一点,我创立了一个(疾速而且写的很差的)python剧本,它的行动就像一个异常异常简洁的WebDAV办事器(仅支撑OPTIONS和PROPFIND哀求)。但这只是足以满意咱们的需要。应用有用载荷文件作为参数挪用此剧本,和要应用的base64编码范例(与powershell兼容或不兼容),并将在端口80上启动WebDAV办事器:

在客户端,有许多办法可以或许履行恰当的哀求,以是我创立了一些例子,应用VBA宏或Powershell剧本,它们都只依赖于WebClient办事,如许咱们曩昔评论辩论的一切其余利益仍旧存在:
1.    收集核心进攻系统平台(IPS,杀毒软件)没有检测到传输的Payload。
2.    没有文件写在WebDAV客户端缓存中,也就是磁盘上。
WebDav传输工具和一些客户端stager示例托管在此gist页面上:

上一页  [1] [2] [3]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载