WPE|52wpe|我爱WPE

 找回密码
 注册会员
搜索
  • 1755查看
  • 0回复

主题

好友

-50

积分

禁止访问

发表于 2009-12-20 20:03:07 |显示全部楼层
好多人有一个误解,他们认为rootkit是用作获得系统root访问权限的工具。实际上,rootkit是攻击者用来隐藏自己的踪迹和保留root访问权限的工具。通常,攻击者通过远程攻击获得root访问权限,或者首先密码猜测或者密码强制破译的方式获得系统的访问权限。进入系统后,如果他还没有获得root权限,再通过某些安全漏洞获得系统的root权限。接着,攻击者会在侵入的主机中安装rootkit,然后他将经常通过rootkit的后门检查系统是否有其他的用户登录,如果只有自己,攻击者就开始着手清理日志中的有关信息。通过rootkit的嗅探器获得其它系统的用户和密码之后,攻击者就会利用这些信息侵入其它的系统。

  一 全面认识rootkit:

  Rootkit出现于二十世纪90年代初,在1994年2月的一篇安全咨询报告中首先使用了rootkit这个名词。这篇安全咨询就是CERT-CC的CA-1994-01,题目是Ongoing Network Monitoring Attacks,最新的修订时间是1997年9月19日。从出现至今,rootkit的技术发展非常迅速,应用越来越广泛,检测难度也越来越大。

  rootkit介绍Rootkit是一种奇特的程序,它具有隐身功能:无论静止时(作为文件存在),还是活动时,(作为进程存在),都不会被察觉。换句话说,这种程序可能一直存在于我们的计算机中,但我们却浑然不知,这一功能正是许多人梦寐以求的——不论是计算机黑客,还是计算机取证人员。黑客可以在入侵后置入Rootkit,秘密地窥探敏感信息,或等待时机,伺机而动;取证人员也可以利用Rootkit实时监控嫌疑人员的不法行为,它不仅能搜集证据,还有利于及时采取行动。

  二 了解Rootkit的攻击原理:

  要了解Rootkit的攻击原理,就必须从系统原理说起,我们知道,操作系统是由内核(Kernel)和外壳(Shell)两部分组成的,内核负责一切实际的工作,包括CPU任务调度、内存分配管理、设备管理、文件操作等,外壳是基于内核提供的交互功能而存在的界面,它负责指令传递和解释。由于内核和外壳负责的任务不同,它们的处理环境也不同,因此处理器提供了多个不同的处理环境,把它们称为运行级别(Ring),Ring让程序指令能访问的计算机资源依次逐级递减,目的在于保护计算机遭受意外损害——内核运行于Ring 0级别,拥有最完全最底层的管理功能,而到了外壳部分,它只能拥有Ring 3级别,这个级别能操作的功能极少,几乎所有指令都需要传递给内核来决定能否执行,一旦发现有可能对系统造成破坏的指令传递(例如超越指定范围的内存读写),内核便返回一个“非法越权”标志,发送这个指令的程序就有可能被终止运行,这就是大部分常见的“非法操作”的由来,这样做的目的是为了保护计算机免遭破坏,如果外壳和内核的运行级别一样,用户一个不经意的点击都有可能破坏整个系统。

  由于Ring的存在,除了由系统内核加载的程序以外,由外壳调用执行的一般程序都只能运行在Ring 3级别,也就是说,它们的操作指令全部依赖于内核授权的功能,一般的进程查看工具和杀毒软件也不例外,由于这层机制的存在,我们能看到的进程其实是内核 “看到”并通过相关接口指令(还记得API吗?)反馈到应用程序的,这样就不可避免的存在一条数据通道,虽然在一般情况下它是难以被篡改的,但是不能避免意外的发生,Rootkit正是“制造”这种意外的程序。简单的说,Rootkit实质是一种“越权执行”的应用程序,它设法让自己达到和内核一样的运行级别,甚至进入内核空间,这样它就拥有了和内核一样的访问权限,因而可以对内核指令进行修改,最常见的是修改内核枚举进程的API,让它们返回的数据始终 “遗漏”Rootkit自身进程的信息,一般的进程工具自然就“看”不到Rootkit了。更高级的Rootkit还篡改更多API,这样,用户就看不到进程(进程API被拦截),看不到文件(文件读写API被拦截),看不到被打开的端口(网络组件Sock API被拦截),更拦截不到相关的网络数据包(网络组件NDIS API被拦截)了,幸好网络设备的数据指示不受内核控制,否则恐怕Rootkit要让它也不会亮了才好!我们使用的系统是在内核功能支持下运作的,如果内核变得不可信任了,依赖它运行的程序还能信任吗?

快速发帖

您需要登录后才可以回帖 登录 | 注册会员

手机版|Archiver|WPE|52wpe|我爱WPE ( 闽ICP备15009081号 )

GMT+8, 2024-5-21 09:11 , Processed in 0.057867 second(s), 16 queries .

返回顶部