前些日子联系上了一个昔日的好友，据他说他所在大学的网站的安全工作做得不错，他搞了很久还是一无所获所以希望我帮他看一看。不过既然朋友肯赏脸，我就厚着脸皮帮他看看好了，接着就有了本文。
俗话说知己知彼方能百战不殆，打开朋友给的网址，浏览一下页面也好大致了解一下网站的情况。
打开网站的首页，看起来还是很规范的，图文并茂布局合理，当然我们并不关心内容，我们关心的是它是否足够安全。网站采用ASP.NET开发，通过后台生成.html的静态页面来展示新闻。在首页的最下方我发现了一个比较隐蔽的超链接。
看了一下这个超链接的路径，感觉很有可能是网站的后台，打开之后发现果然如此。
顺手试了几个常用的万能密码：
‘or 1=1–
‘or’=’0r’
如果网站对提交的参数过滤不严格的话，也许就可以绕过验证进入后台了。不过这个方法在这个网站是行不通的。
看来要拿下这个网站真的要下点功夫了。静下心想一想，很多高校的网站为了管理和分类方便，一般会采用不同的二级域名指向不同的院系。不同的院系为了满足自身的需要又会采用不同的程序，这样一来出现漏洞的机会就大大增加了！当然我们的目标是主站，最直接的方法是拿下和主站ip地址相同的院系的分站。当然这仅仅是猜想，要动手试一下才知道是否行得通。
打开百度，输入“site:www.weixianmanbu.com”搜索www.weixianmanbu.com相关的二级域名。（为了不引起误会什么的我用自己的域名代替了）
搜索结果的第二项是一个“XX学院异网同显系统”，域名是xxx这个域名。
可以发现和主站的ip地址都是125.*.*.220。这基本上可以判断这两个网站是在同一台服务器上的了。
现在我们就把矛头指向二级域名的这个网站。打开，在首页最下方有了小小的收获。
看到这里也许有些读者会很不解，不明白笔者的真实用意。其实看到下方这行文字的时候，首先应该想到这是一个第三方的程序，联系上文我们看到的这个网站的标题“xx学院异网同显系统”，这让我们有了一条新的思路：就是拿到这套“异网同显系统”的源码进行白盒测试，沿着这个方向前进，或许就会少走很多弯路。
打开百度，搜索“异网同显系统”，可以看到有非常多的学校都使用了这套系统。
随便打开一个网站，在后面加上admin/就跳出了后台的登录页面（纯属经验）。试了一下常用的几个用户名密码：
Admin—-123456
Admin—-888888
admin—-admin
最后用户名admin，密码admin成功登入了这个网站的后台管理页面。
又随便打开了其他几个网站，发现很多网站都能用admin/admin登陆进去，看来高校管理员的安全意识有待提高啊！同时我发现在后台的“管理员设置”页面，有许多网站竟然都存在有webmaster123和webmaster123123这两个帐户。
很容易的想到，这两个帐户是程序开发人员留下作为测试用途的。既然这样，我们的目标很可能也存在这两个帐户。可是后台无法看到管理员的密码（加密保存，并且不显示），这下怎么办呢？只好用一下社会工程学了。观察发现：两个账户webmaster123和webmaster123123都是”webmaster”+”123”的组合，又因为这两个账户是程序开发人员为了测试程序用的所以密码应该不会很复杂（这样才符合正常人的逻辑嘛！），所以密码应该是简单的“123”、“123456”、“123123”之类的数字组合。
打开目标站点的后台，猜测一下用户名和密码。当试到用户名为webmaster123123密码为123123的时候成功进入了后台。在后台看了一下，发现有发布文章的地方，并且可以上传附件。最重要的是对上传文件的类型没有任何限制！
这下就好办了，直接传个asp木马上去拿到webshell。
用webshell看了一下服务器的情况，发现权限设置的不是很严格，并且也成功找到了主站所在的目录，这就证实了之前的猜想，他们的确是在同一台服务器的。
可是仅仅拿到了webshell怎么能满足呢？Systemshell才是我们的最终目标啊!
之前提到过这个网站是用asp.net开发的，熟悉asp.net的朋友们都知道asp.net一般是选择mssql作为数据库的。如果管理员的安全意识不强，使用system权限的sa帐户来连接mssql数据库，那我们就可以执行任意命令了。
用拿到的webshell仔细查找数据库连接文件，功夫不负有心人，总算被我发现了数据库连接的信息。
我们可以很清楚的得到连接mssql数据库的用户名是“sal”密码是“elit***”。马上用webshell的“数据库操作”功能来验证一下。可是当我用上面的用户名和密码连接时却发现根本无法连接mssql数据库，提示“[Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server不存在或访问被拒绝”。这是为什么呢？莫非mssql的默认端口被改了？
用webshell的“端口扫描”功能扫描一下，结果mssql的默认端口1433果然被改了。
这个小小的困难是无法阻止我取得最高权限的决心的！试了一下发现默认的cmd.exe拒绝访问无法执行命令，上传一个cmd.exe到“C:Documents and SeitingsAIl UsersDocuments”目录下，执行netstat-an命令，成功了。
结果之中有一个127.0.0,1:1434，状态为LISTENING的非常引人注意，因为1434和mssql的默认端口号1433实在是太像了！再次用webshell的数据库连接功能连接，成功了！
依次执行如下4条sql命令添加一个用户名为apple密码为apple123的windows帐户：
当我试图执行上述语句的时候提示错误，“SQL Server阻止了对组件’Ole Automation Procedures’的过程’sys.sp_OACreate’的访问，因为此组件已作为此服务器安全配置的一部分而被关闭。系统管理员可以通过使用sp_configure启用’Ole Automation Procedures’。”
没关系，使用sql命令来启用’sys.sp_OACreate’，依次执行如下命令：
现在就可以畅通无阻的执行刚才添加系统账户的命令了。
执行完毕后用webshell执行”net user”命令查看一下系统帐户，发现刚才添加的名为apple的管理员的确存在系统账户之中了，打开远程桌面，顺利登陆服务器。至此，已经拿到该大学主站的最高权限。
简单的总结一下，其实入侵不一定要用到很高的技术，重要的是思路灵活并善于发现细节，不要错过任何一个可以利用的条件。
为了保护他人的利益，笔者模糊了文中相关网站的域名等敏感信息，请大家见谅！
评论留言