0x00 背景现在越来越多的站喜欢用java语言的框架做web应用了，这里应用有很多大型站点经常采用jboss或者weblogic做web服务器。出于安全原因，他们都提供把数据源连接密码以及web服务器后台密码加密的功能，jboss用的是blowfish，weblogic旧版的加密算法一般为3DES，新版的则都是AES。这几种加密算法都是可逆的，因为在web服务器连接到数据库的时候还是要把密码解密成明文之后发过去或者和challenge运算的，所以我们有了两个突破口，第一个就是，解密后的明文密码必然保留在内存中，如果把web服务器的内存空间dump下来分析是肯定可以找到明文密码的，这个方法在前段时间hip发的memory forensic文章里有涉及到。第二个方法就是，调用服务器程序自身的解密函数，让它把明文echo出来。0x01 JBoss解密jboss的数据库连接密码一般存在%JBOSS_HOME%\server\%appname%\deploy下面的各种xml里面，比如oracle的是oracle-ds.xml,mysql是mysql-ds.xml…… 在没有加密的情况下，密码是

在拿站的过程中有时候会遇到这种编辑器，它相当的简陋，没有管理后台，没有数据库备份，也没有什么可以直接上传webshell的地方，简陋到只有一个editor的界面。如下图：相信这个编辑器大家都见过，我记得雷池新闻系统用的就是这个编辑器，呵呵。下面我们来看看利用方法：点击图片上传后会出现上传页面，地址为http://www.xxx.cn/admin/uploadPic.asp?language=&editImageNum=0&editRemNum=用普通的图片上传后，地址为http://www.xxx.cn/news/uppic/41513102009204012_1.gif记住这时候的路径在点击图片的上传，这时候地址就变成了http://www.xxx.cn/news/admin/uploadPic.asp?language=&editImageNum=1&editRemNum=41513102009204012很明显。图片的地址是根据RemNum后面的编号生成的。利用很简单 配合IIS的解析漏洞，把RemNum后面的数据修改为1.asp;41513102

提权的时候,如果遇到了服务器开启了3306 端口，但是不允许root外连的情况，我们可以在shell里面执行如下的语句来开启root用户的外连，方便我们提权。GRANT ALL PRIVILEGES ON *.* TO ‘root’@'%’ IDENTIFIED BY ‘rootpassword’ WITH GRANT OPTION;

本文我将就以ASP+Access为基础构建的网站可能存在的各种安全问题进行汇总讲解，给大家一个宏观上的认识。攻击方法在黑客学习过程中，我们很容易发现，国内80%的网站几乎使用的都是ASP，而小站的数目远远多于大型网站。对于小站，若是动态网站，国内普遍采用ASP＋Access结构，由于使用者数量众多，具有针对性，这里我们就来详细研究一下ASP＋Access网站安全的解决方案。要建设一个安全的站，我们不能不了解目前针对ASP＋Access网站的主流攻击手段，时下的攻击方法有XSS跨站、SQL注入、Cookie欺骗、%5C暴库、上传漏洞等。下面我们就针对这些问题做出相应对策。防范措施1）上传漏洞对于上传漏洞，一般的程序员都能做到在前台避免ASP、ASA、CER等类型的文件上传，所以对于前台的问题，这里不再赘述。2）XSS跨站针对XSS跨站，最大的作用就是HTML注入和获取Cookie。我想，更多的人是利用它来获取Cookie，取得Cookie后，目的只有一个，就是看网站是否有漏洞，得以让攻击方通过欺骗的方式进入后台。对于这种攻击方法，最好的防范措施就是把服务器端的验证改为Session。3）

漏洞介绍：IIS是微软推出的一款webserver，使用较为广泛，在支持asp/asp.net的同时还可以较好的支持PHP等其他语言的运行。但是80sec发现在IIS的较高版本中存在一个比较严重的安全问题，在按照网络上提供的默认配置情况下可能导致服务器泄露服务器端脚本源码，也可能错误的将任何类型的文件以PHP的方式进行解析，使得恶意的攻击者可能攻陷支持PHP的IIS服务器，特别是虚拟主机用户可能受的影响较大。漏洞分析：IIS支持以CGI的方式运行PHP，但是此种模式下，IIS处理请求的时候可能导致一些同80sec提到的nginx安全漏洞一样的问题，任何用户可以远程将任何类型的文件以PHP的方式去解析，你可以通过查看Phpinfo中对php的支持方式，其中如果为CGI/FAST-CGI就可能存在这个问题。黑盒访问http://321cc.cn/robots.txt/1.php查看文件是否存在和返回的HTTP头就可以知道是否存在此漏洞。同时，如果服务器支持了PHP，但应用中使用的是asp就可以通过如下方式来直接查看服务端asp源码http://321cc.cn/some.asp/1.php