记录黑客技术中优秀的内容, 传播黑客文化,分享黑客技术精华

美国eEye公司对于缓冲区溢出攻击研究的发展情况

2014-11-20 12:25

1999124日,该公司的技术人员在利用Retina的人工智能引擎对IIS 进行测试的时候,通过构造一个FTP的访问逻辑,发现在IISFTP服务器在处理NLST命令时存在一个缓冲区溢出漏洞,使得用户在客户端输入的数据被填写到系统EIP指向的地址中,这样可以改变程序的执行流程,攻击者可以利用这个缓冲区溢出攻击在目标系统上执行任何指令。

测试过程其实很简单:

ftp> ls AAAAAAAAAAA…AAAA

给出316505A即可触发这个缓冲区溢出漏洞的问题。

这可能是eEye公司最早的,利用软件测试的方法测试出缓冲区溢出漏洞的报告。

1999526日,eEye公司又公布了利用Retina对一些其它Internet服务系统的测试结果,发现了CMailFTGuateNTMail的漏洞,不过这次除了缓冲区溢出漏洞以外,主要公布了另外一种类型的漏洞,源代码泄露漏洞,这主要是../类型的路径上朔漏洞。同时eEye公司的技术人员提示:我们确信在其他的软件中也会发现类似的漏洞。后来的事实证明这一预见绝对没有错。

199968日,eEye公司又公布了到那时为止他们引以为豪的Retina的最大收获,这个收获之大简直使他们几乎不知该如何公布这样一个发现——Internet90%Windows NTweb服务器都开放着一个容许攻击者在其上执行任何指令的漏洞!

 

目标:找出能够对90%以上的Windows NT web服务器都有影响的漏洞,并利用这个缓冲区溢出漏洞。

 

思路:在IIS的缺省扩展(.ASP.IDC.HTR)中至少存在一个缓冲区溢出漏洞。他们认为IIS将把整个URL传递给处理这些扩展功能的DLL。因此,如果ISAPI DLL没有做好边界检查的话,它就会把产生缓冲区溢出,并可在inetifno.exe的环境中执行任何指令。

结果:在Retina运行了一个小时后,他们确认得到了一个缓冲区溢出漏洞。当向IIS发送“GET /[overflow].htr HTTP/1.0”之后,使得IIS崩溃。接下来,启动一个调试工具,并让Retina重复前面的工作,通过调试器深入了解现场情况,以及IIS究竟发生了什么。(这里overflow是大约3K的数据)

原因:这个溢出是.HTR扩展中的一个缓冲区溢出漏洞。IIS中包含了容许Windows 用户通过web服务修改口令的功能。这个功能的实现是通过一套.HTR文件和ISAPI扩展ISM.DLL实现的。因此,沿着这样一条处理线索,IISURL传递给ISM.DLL。但是后者没有进行边界检查,因而产生了溢出。、

利用:eEye对这个漏洞的利用实现了精确定位,不需要进行连机的偏移猜测,不会造成服务器崩溃,对SP4SP5都有效。由于微软未能给予eEye公司的安全报告以足够的重视,在得到报告后的第五天开始停止对eEye公司的email的响应,因此eEye公司决定在第8天,也就是16日在网上公布了这个漏洞的利用程序。该利用程序通过这个漏洞向目标系统上传一个木马——ncx.exe,攻击者利用这个木马可以得到系统shell

影响:在Internet上几乎90%以上的Windows NT IIS服务器都受到这个漏洞影响,哪怕它们被锁在一间空房子里,前面还架设着 CiscoPIX防火墙。

 

致微软的一段话:我们诸多发现中的一个发现表明IIS未能记录我们所做的任何攻击。因此我们建议把所有发送给服务器的请求在传递给任何ISAPI 之前发送给日志服务。日志服务应该是一个运行在独立的地址空间上的真正的服务,这样才才能在inetinfo崩溃的时候仍然能够记录入侵活动。

20001222日,eEye公司公布了FrontPage拒绝服务攻击。

200151日,eEye公司公布了IIS 5.0.printer缓冲区溢出漏洞。

下面让我们来看一看eEye公司是如何发现这个漏洞的:

首先,eEye对这个漏洞的描述不像其它漏洞的描述,采用了一段发人深省的,颇有些文学色彩的文字:

一个智者曾经说过:“当公布一个利用的时候,它是一个了不起的攻击。当你是第一个攻击Internet上百万计的计算机上运行的一个产品的后续各个版本的时候,你便创建了一个王朝。”

有时最伟大的发现是那些最难与人共享的发现。这并不是不愿意告诉他人,而是由于确实不知道如何才能不让人们了解到我们的世界变得何等脆弱时被惊呆。我们正在慢慢地把我们的世界推向一个人们一年前开始梦想的那个数字世界——一个万物互联的世界,www.hackdig.com只做一点点工作就可以支持现实网络系统中存在的虚幻的大缺口。

不再罗嗦了,eEye Digital Security奉献“对任何缺省的Windows2000 IIS 5.0 web服务器的远程系统级访问权”

 

这个漏洞是由eEye公司的RileyHassell在修改RetinaCHAM时发现的,他的目的是查找Windows 2000 IIS 5.0所提供的新功能中是否存在新的漏洞。其中一个功能是.printer过滤器扩展。最新版本的Retina对实验室的一台IIS服务器进行测试,在几分钟内inetinfo.exe就使得调试器由于缓冲区溢出错误而被弹出。

这说明Retina的最新代码可以找出.printer ISAPI过滤器(c:\winnt\system32\msw3prt.dll)中的缓冲区溢出漏洞。当对.printer ISAPI发出的HTTP请求中Host域中的主机名长度达到420字节时就会引发溢出:

GET /NULL.printer HTTP/1.0

Host: [buffer]

这个溢出能够用攻击者提供的任何内容改写EIP寄存器,这也就意味着可以通过改写EIP把控制转移到攻击代码上。

eEye公司的shellcode专家Ryan Permeh给出了一个示范shellcode,它的功能的在溢出成功后在目标服务器上创建一个文本文件,告诉用户从eEye的网站上了解如何弥补这个漏洞的信息。我们在特网侦察中用到的利用程序至少有两个版本,它们分别可以在目标系统上创建一个管理员帐户和打开一个系统shell

日志:与大多数的IIS缓冲区溢出类似,这个攻击也没有在日志中留下痕迹。这意味着Internet上一些运行IIS的大型web服务器在受到这种类型的攻击并被成功利用后在IIS日志中没有任何记录显示受到了攻击。

 

后续影响:与eEye公司两年前的第一个系统级远程利用类似,IIS的第二个远程缓冲区溢出的影响也是非常的。因为无论你事先设置了什么安全防护措施,防火墙、IDS等等,它们都会被甩在一边,web服务器完全可以由这一个漏洞而失去控制。随后eEye推出了它的产品SecureIIS,声称可以停止已知和未知的IIS web服务器的这种攻击。

 

20011220日,eEye公司公布了UPNP漏洞。UPNP结构给PC机提供了任何代理、智能部件和无线设备的点对点网络连接。UPNP借助TCP/IPWeb来实现家庭、办公室以及它们之间的任何网络设备之间在控制和数据传输之上的无缝网络连接。eEye公司确信在UPNP协议本身就存在一些安全问题,除此之外在它的实现中还发现了三个漏洞:一个缓冲区溢出漏洞,一个拒绝服务漏洞和一个分布式拒绝服务漏洞。特别是缓冲区溢出漏洞,存在于Windows XP的缺省配置中,并可利用来获得系统级的访问权限。我们听到这个消息时刻离我们刚刚参加的微软Windows XP发布会仅相隔很短的时间。

eEye公司对于UPNP的缓冲区溢出漏洞的测试情况如下:在测试UPNP服务的时候发现以不同的速率发送错误构造的广告时会引起目标主机上的内存访问异常。这些异常大多是由于指针被改写的原因。其中的一个测试例子是:

NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=10
LOCATION: http://IPADDRESS:PORT/.xml
NT: urn:schemas-upnp-org:device:InternetGatewayDevice:1
NTS: ssdp:alive
SERVER: EEYE/2001 UPnP/1.0 product/1.1
USN: uuid:EEYE

 

当Location RUL的protocol、port和uri域的数据 不断增大,并以10000毫秒的间隔发送时,就可以开始看到访问异常的报警。在这种情况下,EAX和ECX寄存器将包含从被改写的内存数据中得到的地址,并且svchost.exe将在一条mov指令中访问一个无效的内存地址。访问异常错误报警的原因是目的地址是一个被改写的指针。在测试中发现存在多处利用。其中有堆栈溢出和堆溢出,它们都是可利用的。SSDP服务在多路广播和广播上监听。因此,有可能仅仅利用一个匿名的UDP SSDP攻击会话就可以获得整个网络上XP机器的系统访问权。

UPNP由多个协议组成,SimpleService Discovery Protocol是其中之一。当一个UPNP使能的设备是安装在网络上的时候,无论它是计算机、网络设备,或者甚至是一个家用的部件,这些设备都会发送一个广告消息来通知它自己的存在。在缺省的XP配置中,没有像从“网络服务”安装UPNP设备那样支持增加设备控制。虽然微软增加了一个缺省的“InternetGatewayDevice”支持,但是如果一个程序要配置为sniffer整个网络,可以看到在加载XP时XP在搜索这个设备。增加这种支持是为了引导网络硬件厂家生产使能了UPnP的网络设备。通过发送恶意伪造的包含SSDP广告的UDP数据包,攻击者可以强制XP/ME客户端连回到一个指定的IP地址,并传递一个特殊构造的HTTP/HTTPS请求。

 

例子数据包:

NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=1
LOCATION: URL
NT: urn: schemas-upnp-org:device:InternetGatewayDevice:1
NTS: ssdp:alive
SERVER: EEYE/2001 UPnP/1.0 PASSITON/1.1
USN: uuid:EEYE

 

上面的数据包应该发送到XP/ME系统的1900端口。

当XP系统接收到这个请求的时候,它将翻译LOCATION后面的URL,然后没有经过任何检查,它就把这个URL传递给Windows Internet Service API中的函数。这个字符串被分解并创建一个新的会话。

例如:LOCATION:http//xptest.example.com:19/himom.html

恶意的攻击者可以指定一个远程的chargen服务,使得XP客户端连接到该服务并进入一个read/malloc循环。这种攻击会使得系统进入一个不稳定的状态,CPU的利用率达到100%,内存也被一直分配到全部消耗完。

另外一个更大的问题是,它还可以演变成为分布式拒绝服务攻击,因为SSDP支持组播和广播。这样一个UDP数据包就可以导致目标网络上的所有XP机器都向着一个指定的URL进行攻击。

特别是由于UPNP服务的实现基于UDP通信,使得这些攻击很难追踪。

现在让我们来关注一下发现和利用这个漏洞的功臣:

 

Ryan Permeh:对这个非常困难的逆向工程给予了技术建议和利用分析。这种困难的挑战一直是Ryan Permeh的梦想。

 

Marc Maiffret:总是以超级的技术洞察力帮助发现和利用这个漏洞。

Neothoth:他简直就是一台打字机器,在eEye实验室里夜以继日地敲击出URL头中存在的漏洞。

当这个安全公司向世界宣告他们热爱Tequila酒的时候,也许没有人知道这竟是违法的。这个11月Marc和Riley就是21岁了,大家都是合法的了。这也就是说下次NSA在SEC会议上给他们买酒的时候,不会再有违法的问题了。

2001年6月28日,eEye公司公布了IIS的.iad缓冲区溢出漏洞,这个漏洞的一个利用造成了2001年7、8月间席卷全球的红色代码风暴,至今我们在许多运行着的IDS报警信息中仍然可以见到它们的踪迹。

这次漏洞发现与前面几次几乎相同,也是在改进Retina的CHAM(CommonHacking Attack Methods)的时候。当用一段代码对实验室的IIS服务器进行测试时,几个小时的运行后测试进程突然停止了,因为IIS 进程突然死了。进一步分析这个漏洞时发现.iad ISAPI含有缓冲区溢出漏洞。

测试这个漏洞的例子:

GET/NULL.ida?[buffer]=X HTTP/1.1

Host: werd

其中buffer是大约240字节的数据。

 

eEye公司的“利用武士”Ryan这样介绍这个漏洞的利用问题:这个缓冲区溢出发生在宽字符操作中。它把缓冲区中的ASCII字符(单字节)转换为宽字符/unicode字符串(每字符两字节)。例如,字符串AAAA应被转换为\0A\0A\0A\0A。在这个转换中没有进行缓冲区长度检查,并可利用这个溢出改写EIP寄存器。

 

听起来这是一个常见的缓冲区溢出,但是要利用这个漏洞还有一些关键点。首先,把2字节转换为4字节的时候,有2个字节是我们无法控制的。这是一种非常糟糕的情况,但并不是完全无法利用。可是这两个无法控制的字节刚好是空字节。一般地,我们需要这两个字节的字符串,并设法使它指向攻击代码。传统上,我们利用被我们改写的EIP来跳转到一个call esp或jmpesp指令,从而跳回到我们已经在堆栈上定位的好的shellcode上,实现shellcode所具有的任何功能。但在这个利用中,这种传统的做法却有了问题。

GET/a.ida?[AAAAA]=x HTTP/1.0

上面的例子将用0x00410041来改写EIP。还有一个问题是,传统上我们都是把shellcode插入到被溢出的缓冲区中,这样我们的shellcode遇到了与EIP相同的问题——它会被系统扩展。这就使本来已经比较成熟的写shellcode方法遇到困难,成为一件头疼的事。有两种方法来解决这个问题:

1.   定制shellcode。有可能编写一些shellcode,使它在间隔的NULL字节的结构下也能工作。

2.   对shellcode编码。可以写一个解码算法,它把诸如0x0041形式的字符作为输入,然后再把它变成单字节写回到堆栈上。解码算法本身必须要写成0x00bb的形式,是对它自身的挑战。实际上这与方法1一致,只不过只需要定制解码算法本身而已。

当然,所有这一切仅当我们在内存中找到一个通过0x00aa00bb形式的地址可控的位置的时候,才有可能实现。这个限制使我们在整个内存中只能在大约65K个点上去寻找希望,确实颇有些为难。

在宽字符串条件下的利用:

非常幸运地能够用上这种方法。我们被限制到仅仅可以在一个非常小的内存范围内去寻找跳转字节。我们一直认为正在失去战场,直到发现IIS ISAPI的堆分配的内存范围是0x00aabbcc。这样,我们就开发了一个喷射技术,目的是向堆中压入足够的数据,使得我们所要求的位置上是我们进行跳转时所需的数据。

 

例如,在Windows2000 SP1下,我们的请求数据在0x0042deaa位置上。因为我们能够达到的最接近的位置是0x00430001(通过在溢出串的结尾处放置C%01,这给我们提供了一线希望,也许可以在请求中加入更多的数据,使得系统分配更多的堆空间,使我们的请求数据更加接近所期望的位置)。

GET /a.ida?[Cx240]=xHTTP/1.1

Host: the.victim.com

eEye:[Cx10,000][shellcode]

现在,我们把EIP改写为0x00430043。通过我们新的,更大的请求包,0x00430043刚好落在我们建立的大缓冲区的里面。这就好象溢出代码中的一个滑板,一直接入到shellcode。

还有一些情况需要注意,利用这种强制堆增长的技术的目的还是要造成一个可利用的内存位置是可控的。事实上可以注意到还有请求数据的4-5份拷贝存在于在内存的不同地方,而且在地址0x00aabbcc的范围内。也就是说,0x00430043也许不是内存中的最好位置。这种攻击方法还有一个潜在的问题:不同的系统可能有不同的利用堆的方法。在eEye公司的内部测试中,注意到堆的使用与使能了哪些ISAPI扩展有关。而且,引起例外的请求被异常处理程序接管时不释放它们的堆的话,有可能导致堆中的某些部分变为不可用状态。这样,原来选中的位置就不能再使用了。对于Windows 2000这不成为问题,因为如果没有成功利用的话它会重新启动,从而提供一个干净的堆使用)。

影响:根据NetCraft的资料,有5.9M个web服务器运行IIS,但是如果把内部网络也考虑在内的话,数量恐怕还要大得多。这些服务器中任何一个,只要是缺省配置就会受此漏洞的威胁。

玩笑:有人可能感到奇怪,为什么这个建议没有了eEye那种传统的幽默?其原因是这已经是eEye的第4个远程系统级漏洞了,玩笑已经枯竭了。

 

2001年7月17日,eEye公司公布了.ida 红色代码蠕虫分析报告。在eEye公司公布了.ida漏洞的一个月之后,发生了利用.ida漏洞的、席卷全球的红色代码风暴。xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

 

xxxxxxxxxxxxxxxxxxx。

2001年8月5日,eEye公司公布了.ida红色代码II的蠕虫分析报告。红色代码II不并是红色代码的变种,完全是.ida漏洞的另一个利用程序。

2002年3月8日,eEye公司公布了WindowsShell的缓冲区溢出漏洞。Windows Shell披露了一些功能,使开发者可以编写他们自己的URL处理器。例如,ICQ、AIM、MS Conference、IRC、WindowsMedia Player和Outlook/Express都安装了自己的URL控制器,使得它们能够通过URL接收功能请求。例如,我们可以写一个定制的URL控制器“eeye”,那么,任何人,在任何时候提交一个请求“eeye://data”,都会使得data被传递给处理URL“eeye”的控制程序。

这个缓冲区溢问题发生在当在注册表中映射的URL处理器所对应的程序不存在的时候。注册表中的URL映射定义如下:

HKEY_CLASSES_ROOT\urlhandler\shell\open\command由这个注册表键指向的可执行程序将被作为处理这个特定URL的处理器。AOL的InstantMessenger就在HKEY_CLASSES_ROOT\aim安装了一个URL处理器。我们之所以知道AIM是一个URL处理器是由于键URL Protocol的存在告诉Windows Shell Aim是一个URL处理器。通过在注册表中枚举URL Protocol键来确定所安装的全部URL处理器。这样我们就可以确定安装了,但是映射到一个不存在的程序的URL处理器。

如果注册表中指定的URL处理器指向一个并不存在的程序,可以通过传递给该处理器的数据制造一个在URL中可被利用的缓冲区溢出,例如aim://overflow,这里overflow是一个大约324字节长的数据。这个溢出可以使我们获得对EIP的控制并改变执行流程,这也意味着可以在目标系统上执行任何我们发送的指令。

特别需要指出的是,这并不是URL处理器中的问题,问题出在Windows Shell的代码中。

有些程序在卸载的时候,卸载程序没有清除干净注册表中的映射,或者用户只是删除了程序使得注册表的URL映射指向不存在的文件,在这些情况下URL处理器有可能成为可被利用的程序。虽然在缺省安装的Windows系统中这个漏洞不能利用,但它确实是存在的。随着时间的推移,如果有一些应用没有正确删除的话,系统就变为可利用了。

 

这个漏洞是一个本地利用漏洞,但是由于Windows系统的本身完整性特点,有可能通过任何一个支持URL的程序来远程利用这个漏洞。例如,为了让系统去处理可被利用的URL,我们可以在Outlook邮件中邮寄一个攻击性的URL,或者我们可以把一个攻击性的URL放在恶意的web页面中。当这个漏洞被利用的时候,无论是远程利用还是本地利用,利用代码都只能以被攻击的用户的权限执行。如果执行恶意URL的用户是Administrator,利用代码将以管理员的权限运行。

2002年4月10 日,eEye公司公布了IIS的asp缓冲区溢出漏洞。问题出在对接收到的form数据进行解码和翻译的时候。通过form数据的分段编码,可以使IIS改写任意地址上的四个字节数据。

触发这个漏洞的例子如下:


POST /iisstart.aspHTTP/1.1
Accept: */*
Host: eeye.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

10
PADPADPADPADPADP
4
DATA
4
DEST
0
[enter]
[enter]

上面的输入将会发生异常,使得在dllhost中执行被缺省的异常处理程序截获,这时会弹出一个报错窗口,显示:

DLLHOST.EXE-Applicationerror

The Instruction at0x77fcb397 reference memory 0x54534544

0x54534544是“TSED”的16进制编码。DLLHOST.EXE的处理试图拷贝“DATA”到“DEST”,由于内存地址0x54534544是不可写的,所以产生了访问异常,NT核心的结构化异常处理机制截获异常并杀死dllhost.exe进程。

这个问题的关键在于:被我们的数据改写的内存包含堆管理头结构,而AllocteHeap()要用到这个结构。特别地,当我们改写头结构的时候,我们控制了其中的2个4字节地址。这些地址与‘“population”和使用“lookaside”表有关。第一个4字节地址(在上面的例子里被改写为“DATA”)被拷贝到第二个4字节地址。我们还用“DEST”改写了第二个4字节地址。通过改写这两个4字节地址,我们可以把4字节的任何数据写到任何dllhost.exe具有写权限的地方。这样,我们就可以改写函数指针、保存的指令指针、异常处理程序或其它任何可以使把控制转移到我们的利用代码的地方。我们已经通过改写堆栈上的异常结构地址成功地利用了这个漏洞。由于我们提供的地址并没有与一个有效的“loogaside”表相关联,因此系统进行有关操作的时候会产生异常,从而调用异常处理。此时它将调用我们修改古的例程,直接指向我们的利用代码。

 

需要注意的是,虽然这个漏洞存在于.ASP ISAPI中,还要满足一些要求才能使恶意请求触发.ASP ISAPI中含有漏洞的函数。虽然带有form提交的页使得更加容易展示这个漏洞,但还存在其他一些方法使得程序去执行这些代码,而不需要引用form变量。在上面的例子中,我们使用了缺省的.asp文件,其中包含了一些与.ASP Server Variables有关的脚本代码。当.ASP ISAPI执行对这些Server Variables的处理时,我们可以引起溢出并执行代码。在IIS中有一些缺省的.asp文件,它们会引起处理Server Variables,因此可以利用它们来在缺省安装上展示这个漏洞。

2002年5月8日,eEye公司公布了MSNMessenger OCX的缓冲区溢出漏洞。这是一个可用于攻击客户端的漏洞。这个漏洞是由于MSN  Messenger处理传递给它的参数的方式会导致缓冲区溢出。这个漏洞可以通过email,web或其他一些使得IE去显示一个攻击者提供的HTML脚本任何方法,也包括那些使用web浏览器ActiveX控制的软件。

因为这是一个微软签发的OCX,所以所有IE用户都有可能受到影响。没有安装Microsoft  Messenger的用户,或者没有升级MicrosoftMessenger的用户只有在弹出“Install Now”并选择安装时才会受到影响。

测试数据:


<objectclassid="clsid:9088E688-063A-4806-A3DB-6522712FC061"

width="455"

height="523">

<paramname="_cx" value="12039">

<paramname="_cy" value="13838">



<paramname="BackColor" value="50331647">


<paramname="ForeColor" value="43594547">

<paramname="RedirectURL" value="">

<paramname="ResDLL" value="AAAAAAA[27,257 bytes is where the EIP starts]">

</object>

MSNChat OCX是一个随MicrosoftMessenger安装的AxtiveX控件。ResDll中对参数没有进行检查。通过提交一个非常大的缓冲区可以改写堆栈上的重要部分,包括保存的返回地址和例外处理程序地址。

 

知识来源: www.2cto.com/Article/201411/353379.html

阅读:115474 | 评论:0 | 标签:溢出

想收藏或者和大家分享这篇好文章→复制链接地址

“美国eEye公司对于缓冲区溢出攻击研究的发展情况”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

公告

关注公众号hackdig,学习最新黑客技术

推广

工具

标签云