SA权限仅需xp_regwrite即可有dos shell

删除xp_cmdshell和xplog70.dll不用担心，只要保留xp_regwrite就可以执行系统命令，拥有一个dos shell

利用RDS的一个老问题，在IIS 4.0的时候被广泛利用，现在好像没多少人想得起来了

绝对比去想办法恢复xp_cmdshell来得经济实惠，不过需要猜一下系统路径

nt/2k: x:\winnt\system32\

xp/2003: x:\windows\system32\

如果有回显，可以看到执行返回结果，否则需要先判断主机OS类型再试

当然如果野蛮一点，四个轮流来一遍也行。

首先开启沙盘模式：

exec master..xp_regwrite 'HKEY_LOCAL_MACHINE''SOFTWARE\Microsoft\Jet\4.0\Engines''SandBoxMode''REG_DWORD'1

然后利用jet.oledb执行系统命令

select * from openrowset('microsoft.jet.oledb.4.0'';database=c:\winnt\system32\ias\ias.mdb''select shell("cmd.exe /c net user admin admin1234 /add")')

--------------------------------------------------------------------------------------------------------------------------

db_owner到sysadmin的测试

sql injection终极利用方法》一文影响蛮大的，在叮当群上我们一帮人也讨论并测试了文章里的一点东西，这里把我们测试结果发一下：

在2个前提条件下，文章里的方法是可以实现的

① 连接的dbo用户必须对master有权限

② SQL必须设置为“允许对系统目录直接进行修改”（SQL Server属性--服务器设置）

这2个条件都是比较苛刻的，尤其是第2条，使的文章里提到的方法的成功率应该不是很高。

如果没有第1条，那么当我们执行drop procedure sp_addlogin操作时就会提示

服务器: 消息 3704，级别 16，状态 1，行 1

用户没有在 过程 'sp_addlogin' 上执行该操作的权限。

没有第2条，我们恢复sp_addlogin事 会提示错误

服务器: 消息 259，级别 16，状态 2，过程 sp_addlogin，行 115

未启用对系统目录的特殊更新。系统管理员必须重新配置 SQL Server 以允许这种操作。

顺便对文章里提到的xp_regwrite进行下测试，测试结果也是要求“连接的dbo用户必须对master有权限”

不过在使用 xp_regread时 并不要要求对master的权限

如果你感兴趣，也可以对其他的“扩展过程”进行这样的测试 :)

虽然文章里面的直接成功率小，但是可以做为 “后门”。

---------------------------------------------------------------------------------------------------------------------------

论在mssql中public和db_owner权限下拿到webshell或者系统权限

BBSSETTEXT:论在mssql中public和db_owner权限下拿到webshell或者系统权限 $TCSPLIT$作者：许文强

在看之前我们先回顾一下目前在公开或者已知的public和db_owner权限拿到webshell或者系统权限的思路和方法(sysadmin权限我就不说拉，给你这么一句，只要是sysadmin，拿不到webshell或者系统权限那是你的无能）public下面我还没见到一种可以真正能利用的方法。db_owner目前公开的方法主要有5种：第一种就是最普遍的backup，现在利用差异备份生成的asp文件确实要比以前小拉不少，但能否得到 webshell，目前成功率还不是很高。第二种就是在下的万能提权，此法成功率几乎为零，只有在特定的条件下面才能实现。第三种就是LCX大虾在《MSSQL db_owner角色注入直接获得系统权限》，所说的利用xp_regread读出VNC在注册表的加密密码，然后破解，直接拿到系统权限，这种方法局限性比较大，要是对方主机没有装vnc，你怎么办。第四种就是利用xp_regwrite再注册表里直接加个系统帐号或者直接写个webshell，在主机重起的时候就可以拿到webshell或者系统权限。此法适用范围比较大，成功率也相对前3种较高点，但缺点也是显而易见的，就是不能够马上得到 webshell，需要对方重起。第五种就是利用添加作业的一些存储过程，sp_add_job,sp_addtask之类得到系统权限。理论上应该说是目前这5种里面成功率最高的的一种吧（郁闷，我在本机测试的时候一次也没成功过，可能是操作系统的原因吧）。

看过以上5种方法后，应该说目前在db_owner权限下面得到系统权限的的手段无论是成功率还是从结果来看，都还是不太理想的。呵呵要是我告诉你还有第 6种，第7种，第8种呢，而且每个都纫陨先魏我恢值姆椒ǖ某晒β识几摺：呛牵 阈挪恍拧Ｎ蚁冉樯芤桓龃蠹矣Ω枚贾 赖模 铱赡艽蠹叶季 Ｓ茫墒侨疵幌氲剿 褂辛硪幻娴姆椒ǎ 野阉 凶觥 魈旃 ！Ｔ俳樯苤 盎沟糜星敫魑豢垂傧劝盐抑谱鞯亩 匆幌隆?/P>

看拉之后，不知道网管们会做何感想啊，想不到只有相对public权限（我在movie里面只有public权限，相信看过动画的各位也应该看清楚拉，之所以说是相对，那是因为我在master中有db_owner权限）的我们竟然可以使用只有sysadmin才能用的sp_oacreate及 sp_oamethod吧，利用sp_oacreate，sp_oamethod我们可以说是无所不能，你可以用来写个webshell甚至直接加个系统帐号。而且利用sp_oacreate及sp_oamethod写出来的webshell可是没有乱码的哦。那么为什么只有 sysadmin 固定服务器角色的成员才能执行的 sp_OACreate、sp_oamethod（呵呵，M$讲的），而只有相对public权限的我们却好使用，原因我也不太清楚，可能是M$送给我们的“彩蛋”吧。

可能你会问，那要是在master中是public权限,其他数据库都是public权限的情况下，我们还能得到webshell或者系统权限吗？我现在就告诉你，那是绝对不可能的事情，注意我的意思是说，在绝对public权限下面，你想通过存储过程以及扩展存储过程,得到webshell或者系统权限那是绝对不可能的事情，除非你借助其他方法才有可能在绝对的public权限下面，才有可能得到webshell或者系统权限，单靠sql的力量是肯定不够的。我在我的《终极利用方法》一文里面说的public权限的用户拿到webshell甚至系统权限的方法至少有4种，是指在相对的public权限下面，至少有4种以上。绝对的情况下面，你想用存储过程或者扩展存储过程拿到webshell或者系统权限是绝对不可能的。下面我来说说为什么在绝对的 public权限下面是绝对不可能的.

可能会有人说可以利用 sp_add_job,sp_add_jobstep,sp_add_jobserver,sp_start_job，sp_addtask这些存储过程可以得到webshell或者系统权限啊，的确是可以，(郁闷，我在自己机器上作实验一次也没成功过，肉鸡上却可以，不懂）但要在 SQLSERVERAGENT服务开启的情况下面，而且默认是不开启的哦，你想利用xp_servicecontrol来启动啊，你到查询分析器输入 exec master..xp_servicecontrol 'start','SQLSERVERAGENT'试试看，看看是不是出现错误拉。

就算是public可以使用的xp_regread,xp_dirtree,xp_subdirs这些稍微对你有用的存储过程，就算是给你用，你在检测对方的网站的时候也没办法用，你首先要建个表吧，然后才能把你要读的键值或者你要看的盘符插到表里面吧，最后才能通过暴出来才能看见你想要看见的内容。可是不要忘拉public是没有建表，插入，更新,备份等权限的，所以第一关你就过不去，你只能除拉select还是select。

至于其他的有危险的存储及扩展存储我就不一一举例拉，不是权限不够就是有限制。所以综上所述，在绝对public权限下，想要只凭借sql的力量拿到 webshell及系统权限是绝对不可能的事情（假如你可以做到的话，作个动画给大家看看，成功的话，那你绝对是牛人中的牛人拉。）

网管们也不要开心的太早拉，就算是在绝对的public权限下，只要条件成熟，sql注射配合其他手法还是可以拿到webshell的，假设你的网站有 sql injection漏洞，但是是绝对的public权限，“黑客”们虽然光凭sql的力量是无法得到webshell,但可以利用select暴出你的管理员密码然后到后台，通过上传（或者干脆就是上传漏洞）或者备份，修改，创建得到一个webshell，也可能用木马代替你的一个正常文件，得到 webshell。当然方法还有很多，不可能一一列举出来。

sql injection只是脚本漏洞的冰山一脚，网管们不要以为杜绝拉sql injection就可以高枕无忧，就算你真的杜绝拉sql injection，可是一旦在其他地方出拉问题，列如跨站拉（中国目前至少90%以上的网站都有这个问题，即使大型门户网站也不能幸免），上传拉（最近上传漏洞的确是火拉一阵啊），暴库拉（通过暴库得到数据库名，要是后缀是asp或asa的可以插入一句话木马），等等，只要你一个很小的地方出现拉问题，那么就有可能带来巨大的损失。在这里我想给所有网管们一个建议：

对于那些公开的或者是已知的漏洞和问题，我们一定要处理好，解决好，而对于那些没有公开或者只有少数人掌握的漏洞，我们只有作好完备的防范措施，这样才能在"灾难"来临时把损失降到最低。

总之一句话：安全是一个整体。

后记：

可能会有人说有谁回在其他数据库里面都是public的情况下面,而惟独给master,db_owner权限呢？确实，这种概率确实很低。在实战public提权中也没多大利用价值。

呵呵，那要是在其他数据库是db_owner权限，你认为master中具有db_owner的概率大不大？我以我实战的的经历告诉你，至少90%的网站会在给他默认数据库db_owner权限的同时，同时给master，db_owner权限，尤其是在他数据库少的时候，只有2，3个用户数据库的情况下，100%在master中具有db_owner权限。呵呵，那你说在db_owner权限下利用价值大不大。而且在所有有关的书籍里面都说拉只有 sysadmin才能用的sp_oacreate及sp_oamethod，所以大多数网管都会认为即使我们找到注射点，也没有权限使用而不会删除。即使删除拉，也无所谓，由于MSSQL强大的功能再加上大量丰富的存储过程及扩展存储过程，我们还是有办法得到webshell甚至系统权限的，所以说最好的方法就是杜绝sql injection。

应该有不少人都会在看拉之后回说我在N年前就知道拉，早就会用sp_oacreate和sp_oamethod拉，不错，你可能很早就知道拉，我也很早就知道拉，可是你知道只要有相对public权限或者说db_owner权限也可以使用吗？你可能还以为只有sysadmin固定服务器角色的成员才能执行吧。

可能有的人看过以后会有人问我要工具，呵呵，其实网上面早就有拉，xiaolu写sqlcomm里面有这个功能，不过我觉得不太好用自己又重新写拉个。这里多说几句，一直用工具的话，会把人变傻的，工具只是武器，思想才是灵魂，工具只是提高效率罢了，并不代表你的技术高超。思想决定一切.

转自：http://hi.baidu.com/shang_jianlong/blog/item/904cced8699c4a3d33fa1c96.html

您可能对以下文章有兴趣↓