利用http暗藏通道大举攻破局域网Word文档下载推荐.docx
《利用http暗藏通道大举攻破局域网Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《利用http暗藏通道大举攻破局域网Word文档下载推荐.docx（9页珍藏版）》请在冰豆网上搜索。
我们看到，这里有ICQ,Napster等软件，相信我们的读者很多都使用过走proxy的ICQ,OICQ等等，其实他们的原理是差不多的。
什么是Httptunnel
作为一个实际的例子，我们下面来介绍一个在"
非公开领域"
使用的的通道软件，httptunnel。
在httptunnel主页上有这么一端话，
httptunnelcreatesabidirectionalvirtualdataconnectiontunnelledinHTTPrequests.TheHTTPrequestscanbesentviaanHTTPproxyifsodesired.Thiscanbeusefulforusersbehindrestrictivefirewalls.IfWWWaccessisallowedthroughaHTTPproxy,it'
spossibletousehttptunneland,say,telnetorPPPtoconnecttoacomputeroutsidethefirewall.
从这段说明中我们可以看出来它就是我们今天说要介绍的tunnel技术的一个证明，我们下面大致介绍一下它的使用。
httptunnel目前比较稳定的版本是3.0.5,支持各种常见的unix系统，包括window平台。
可以从相关站点下载，它的安装是比较简单的，照INSTALL文件做就可以了，这里不介绍。
整个软件安装完毕后，我们会得到两个关键文件，htc和hts,其中htc是客户端（c），而hts是server（s）端，我们来看看具体怎么使用的。
假设有A（域名）机，B（域名）机，两机均为solaris环境，A机在防火墙保护中，B机在防火墙以外，防火墙的管理员控制了访问规则，仅ALLOW80和53端口的进出数据包。
而我们的任务是要利用Httptunnel从A机telnet到B机上，穿过防火墙的限制。
操作如下:
首先我们在A上启动client端，命令很简单:
#htc-F1234:
80，
系统回到提示符下，此刻我们用netstat-an可以看到系统内多出了1234端口的侦听
*.1234 *.* 0 0 0 0LISTEN
然后我们在B机上启动server端，命令如下:
#hts-Flocalhost:
2380
系统回到提示符下，此刻我们用netstat看
*.80 *.* 0 0 0 0LISTEN
80端口处于侦听状态，需要注意的是，如果系统本身跑的有web服务（80端口本身处于侦听），并不会影响Httptunnel的工作。
Ok,server以及client端都启动了，我们可以开始我们的"
试验了，在上执行一下如下命令看看:
C#telnetlocalhost1234
Trying0.0.0.0...
Connectedto0.
Escapecharacteris'
^]'
.
SunOS5.7
Thisisyiming'
sprivatebox!
Anyquestion,contactmewithyiming@
login:
看到B机的登录提示符了,输入账号密码看看是否工作正常?
Login:
yiming
Password:
（omithere;
））
#ls
bak check go httpd lost+foundmrtg run soft wg
OK!
工作正常，和正常的telnet没有什么差别。
仔细观察整个过程，会发现在最开始的地方显示的是Trying0.0.0.0...，Connectedto0.而不是Trying…,Connectto，这就很直观的可以看出来client端是转发1234数据包到本机80端口的。
（然后再转发到远端）而不是直接连接远端的B机。
上面是比较直观的测试，为了进一步验证server和client之间不是通过23端口通讯，我们抓取数据包来看看。
我们在server起个抓包工具tcpdump瞧瞧。
#tcpdumphost
tcpdump:
listeningonhme0
14:
42:
54.213699.51767>
.80:
S1237977857:
1237977857（0）win8760（DF）
.80>
.51767:
S1607785698:
1607785698（0）ack1237977858win8760（DF）
54.216186.51768>
.ack1win8760（DF）
54.218661.51768>
P1:
44（43）ack1win8760（DF）
54.218728.51768>
P44:
48（4）ack1win8760（DF）
篇幅所限，上面只是截取了结果中的一点点数据包，但已经可以说明问题了，我们看到server和client之间顺利的完成了三次握手，然后开始push数据，而且通讯确实走的是80端口。
有点意思噢。
看是看出来了，但太不直白，到底在搞什么呀，我们再稍微改动一下tcpdump的运行方式，进一步在来看看telnet的数据是否被封装在80端口的数据包内传输?
#tcpdump-Xhost
43:
05.246911.80>
.51768:
.2997:
4457（1460）ack89win8760（DF）
0x0000450005dc3b234000ff06e2c2yyyyyyyy E...;
#@......f.D
0x0010xxxxxxxx0050de425fd5ac4f39ac016f .f.#.P.B_..O9..o
0x00205010223898e40000746f74616c203636 P."
8....total.66
0x0030370d0a64727778722d78722d78202032 7..drwxr-xr-x..2
0x00403920726f6f742020202020726f6f7420 9.root.....root.
呵呵，这次清楚多了，上面应该是一次ls命令的输出结果，可以清楚的看到telnet的结果!
果然telnet的数据是在80端口的数据包内!
Httptunnel带来的安全问题
写到这里，我们可以想象一下，如果管理员完全信赖防火墙，那么在一个有这样隐患的的局域网中，会发生什么样的后果?
我们可以看到，多年以来，对防火墙的依赖也一直列在SANS的Top10安全问题中。
既然如此，就很自然的会产生一个问题是:
这种httptunnel行为能被发现吗?
首先我们想到的是使用入侵检测系统，在目前的网络安全设计中，防火墙加入侵检测系统是一种比较流行的安全联动配置，既然httptunnel绕过了防火墙，那么IDS系统呢?
我们来测测看看。
在下面的测试中，我们将使用IDS系统是Snort，版本1.8.2。
这可是大名鼎鼎的开放源代码的IDS系统，在它的说明中，被描述为一个轻量级的，可跨平台工作的入侵检测系统，在2001年12月英国的独立测试实验室NSS的评测中，击败了包括商用IDS系统的所有对手，这些商用软件可是包括ISS，CISCOSECUREIDS，CAETRUST，CYBERSAFECENTRAX，NFR。
有兴趣的读者还可以看这篇名为OpensourcemountsIDSchallenge的报道。
好，对Snort的大致介绍完毕，我们来看看结果吧，Snort对整个试验过程抓获的数据包产成了告警，如下:
[**]WEB-MISCwhiskerspliceattack[**]
12/02-14:
54.389175:
51767->
:
80
TCPTTL:
251TOS:
0x0ID:
3327IpLen:
20DgmLen:
42DF
***AP***Seq:
0x49CA0BA7Ack:
0x5FD4DCE3Win:
0x2238TcpLen:
20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
[**]WEB-MISCwhiskerspliceattack[**]
03.195006:
51767->
3439IpLen:
41DF
0x49CA0C20Ack:
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
04.630268:
51768->
3496IpLen:
0x49CA0C4EAck:
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+我们看到snort对抓获的数据包产生了WEB-MISCwhiskerspliceattack的告警，然而这种攻击并没有发生，同时snort对tunnel数据包没有察觉。
这样snort就同时出现了IDS系统的两个问题，falsepositive，falsenegative。
这也很正常，因为这也是基于签名的IDS系统的通病，目前决大数IDS系统包括著名的商用软件ISS,NFR等都是基于签名的，也就是说系统维护着一套特定攻击数据包的数据模式签名。
系统工作时，检查经过的数据包的内容，和自己数据库内数据模式签名对比，如果和某种攻击模式签名相同，那么就判断发生了某种攻击。
由此我们可以看出很明显的存在若干问题:
如对签名的依赖不可避免的导致两个结果，falsenegative,falsepositive。
也就是说会产生漏报和误报，这一点很容易理解，当新出现一种攻击模式时，由于IDS系统内没有相应的数据签名，那么就不可能捕获相应的攻击数据包，falsenegative由此发生。
同时，过于依赖签名模式也很容易误报，就象我们上面的例子。
同时，对数据签名的依赖会在一定程度上降低系统性能-经过的数据包都需要和IDS系统的签名对照。
此外，基于签名的IDS系统本身有可能由于依据签名这一特性而被攻击，一个例子是stick，这个程序的作者利用IDS系统进行签名匹配工作原理，发送大量带有攻击特征的数据包给IDS系统，使IDS系统本身处理能力超过极限，从而导致IDS系统无法响应。
按照作者CoretezGiovanni的说法，运行2秒钟stick就能使著名的商用IDS系统ISSrealsecure崩溃。
由上我们看到，对IDS系统的完全依赖同样是有风险的。
一些解决思路
看来依靠手头的IDS是无法察觉这种行为了，那么有其它办法吗?
我们仔细分析一下事件过程中截获的httptunnel数据包再说吧。
仔细观察截获的httptunnel数据包，可以发现紧跟着三次握手完成后的第一个数据包包含着一个POST动作，是由htc（client端）发送到hts（server端）的。
如下:
55:
39.128908.51767>
S3521931836:
3521931836（0）win8760（DF）
0x00004500002cd3cc4000fb0653c9xxxxxxxx E..,..@...S..f.#
0x0010yyyyyyyyca370050d1ec6a3c00000000 .f.D.7.P..j<
....
0x00206002223817080000020405b40000 `."
8..........
39.128945.80>
S2946004964:
2946004964（0）ack3521931837win8760（DF）
0x00004500002ccb854000ff065810yyyyyyyy E..,..@...X..f.D
0x0010xxxxxxxx0050ca37af9877e4d1ec6a3d .f.#.P.7..w...j=
0x002060122238ef790000020405b4 `."
8.y......
39.131002.51767>
0x000045000028d3cd4000fb0653ccxxxxxxxx E..（.#
0x0010yyyyyyyyca370050d1ec6a3daf9877e5 .f.D.7.P..j=..w.
0x00205010223807370000000000000000 P."
8.7........
39.132841.80>
.ack44win8760（DF）
0x000045000028cb864000ff065813yyyyyyyy E..（ 0x0010xxxxxxxx0050ca37af9877e5d1ec6a68 .f.#.P.7..w...jh
0x002050102238070c0000 P."
8....
39.132860.51767>
0x000045000053d3ce4000fb0653a0xxxxxxxx
0x002050182238d23a0000504f5354202f696e P."
8.:
..POST/in
0x00306465782e68746d6c3f637261703d3130 dex.html?
crap=10
0x0040303738383034383620485454502f312e 07880486.HTTP/1.
0x0050310d0a 1..
1..
看起来是发送client端的数据包到server端的，那么server有什么反应呢?
我们往下看,在上面这个过程完成后，htc和hts又发生了一次握手（注意，又一次握手），如下:
39.134301.51768>
S2851199448:
2851199448（0）win8760（DF）
0x00004500002cd3df4000fb0653b6xxxxxxxx E..,..@...S..f.#
0x0010yyyyyyyyca380050a9f1d9d800000000 .f.D.8.P........
0x002060022238cf650000020405b40000 `."
8.e........
39.134389.80>
S2946060449:
2946060449（0）ack2851199449win8760（DF）
0x00004500002ccb8f4000ff065806yyyyyyyy E..,..@...X..f.D
0x0010xxxxxxxx0050ca38af9950a1a9f1d9d9 .f.#.P.8..P.....
0x002060122238cf190000020405b4 `."
8........
39.136527.51768>
0x000045000028d3e04000fb0653b9xxxxxxxx E..（
0x0010yyyyyyyyca380050a9f1d9d9af9950a2 .f.D.8.P......P.
0x002050102238e6d60000000000000000 P."
39.137333.51768>
43（42）ack1win8760（DF）
0x000045000052d3e14000fb06538exxxxxxxx
0x00205018223825ce00004745542
升级会员 