与其说这是一个漏洞,不如说这是一个特性,很多程序员不知道这种特性,所以会写出有问题的代码。
特性:多后缀名(全版本都有这个特性)
apache在解析一个文件的后缀名时,是从右往左解析后缀名的,如果右边的后缀名不认识,就会继续向左识别,直到识别到一个认识的后缀名,但是万一都不认识呢?都不认识的话默认情况下是plain/text处理。那么apache是怎么知道哪个后缀名它是认识的呢?答案是认识的后缀名们都被记录到一个叫mime.types的文件中了。这个文件呢,Windows放在conf文件夹里,linux放在/etc/mime.types(不一定在这里,需要自己找找),打开后是这样
定义了不同的后缀名应该向浏览器返回什么样的mime格式。这里要说的是有些情况下的mime.types没有提供对php的解析方法,对php的解析规则放在另一个文件,Windows下在/conf/extra/httpd-php.conf。Linux也有这个文件在/etc/apache2/mods-enabled/php7.2.conf(或者和Windows的路径一样),打开后是这样的,定义了文件名满足什么条件(正则表达式)才会将他给php处理器处理,而且,如果你mime.types里匹配到了php后缀,但这个处理器匹配文件没有匹配成功,他还是不会把php文件进行处理
可以试一试,确实是这样的,apache对这个文件第一个匹配到的后缀名是jpg,所以把它当作图片处理了,返回了图片类型的mime头,浏览器也就把这个文件当作图片处理,于是出现了这种情况
当然,用这种多域名特性去解析php文件的话,就需要在上文提到的文件里去修改修改哦。
2.4.0~2.4.29版本中存在一个解析漏洞,在解析PHP时,1.php\x0A
将被按照PHP后缀进行解析,导致绕过一些服务器的安全策略。
如果服务器开启了ssi与cgi支持,即可上传shtml文件并在shtml文件中输入ssi指令 ,如 ,然后再访问这个文件即可获得ls的结果
适用版本 iis7/7.5
前提条件:
1.php.ini里的cgi.fix_pathinfo设置为1,且结合方式是fast-cgi
2.开启Fast-CGI运行模式
作用: 在访问某个文件时,在路径后加 /.php(这里的指任意字符),即可让服务器把把该文件当作php文件解析并返回
如图我在一个txt文件中写入php代码,让后访问它时在路径最后加了/a.php,它就被解析为php文件了
1.适用版本 iis6.0
2.前提条件:服务器开启了webdav服务并且设置了写入权限
同时找到访问网站的用户是哪个并给他读取和写入权
3.概述:用PUT方法上传文件,并尝试getshell
上传,并且确实上传成功,但是大多数情况下无法上传php等脚本文件
这个时候我们就会想到用move方法来将txt文件转化为php文件,但直接move往往是不行的,要用到iis6.0解析漏洞,把它写成shell.php;.txt就可以了getshell了
iis6.0环境下会把文件畸形解析: 1.在一个文件后面加;.任意后缀名:假设有个文件是a.php,我们把它改成a.php;a.txt,他还是会被解析成php文件但是因为后缀名是txt所以会绕过一些防护
2.在一个名为 *.php(如a.php)的文件夹下的所有文件都会被解析为php
url/xxx.gif/xx.php会被解析为php文件
前提条件:cgi.fix_pathinfo=1
前提条件: nginx-conf 把这个选项改为on即可
前提概要:要用到别名alias
作用: 当设置别名时,location后面的路径没有用/闭合时,就会引起访问 url/xx../时返回的目录是当前文件夹的上层目录
可见返回的目录是上层目录
前提条件与产生原因:
1.随着业务的发展,有些网站会把http://xxx 重定向为https://xxx或http://x.com重定向为http://www.x.com,
那么这种重定向的原理在nginx上的实现方式是在location块里加入return 302 http://$host:81$uri;之类的语句,
这里的$host,$url都是变量。$host一般为请求头的host头部,$url一般为请求行里的路径部分 如 GET /url HTTP/1.1此处的/url部分. 2.http头部里,0d(cr)和0a(lf)字符是用来分割请求头部区域的字符。头部的行是以一个crlf来分割的,也就是说请求头部每个行之间都存在着一个crlf字符来分割它们,让他们成为多个独立的行。头部与body之间有两个crlf来分割
作用:当某台nginx设置了形如return 302 http://$host:80$uri; 这种配置时,url是我们完全可控的,所以可以在url中人为构造crlf字符来实现分行,从而在响应头中注入我们想要得到的响应头部。
Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
url/xxxxx.gif%20 的文件
被 url/xxxxx.gif%20\0x00.php (\0x00须在burp里的hex里改)
需开启fastcgi
然后发包请求这个文件,并且在请求时做点手脚
User ID system Password password Level Administrator User ID weblogic Password weblogic Level Administrator User ID weblogic Password weblogic User ID admin Password security User ID joe Password password User ID mary Password password User ID system Password security User ID wlcsystem Password wlcsystem User ID wlpisystem Password wlpisystem
假设我们能前台任意文件读取,但是后台的账户密码是加密的.如何破解
weblogic新版本用的是AES加密,老版本用的是3DES加密
都是对称加密,有密钥就可解
假设前台可以任意文件读取,那么我们只要用到用户的密文和加密的密钥即可破解。这两个文件在base_domain下, 为./security/SerializedSystemIni.dat
和config/config.xml
这里值得一提的是,.dat文件是二进制文件,建议burp打开不然容易乱码
把二进制信息copy to file保存下来.
获取config.xml
xml文档里这才是管理员账户
开始解密,这里使用的是 https://github.com/TideSec/Decrypt_Weblogic_Password 中的tools5
解密成功。登录就完事了
后台传jsp木马的war包就行了
怎么生成war包:
jar cvf shell.war 木马源文件
部署-》安装-》上载文件-》选择文件选择war包-》一直下一步然后完成
访问war包目录下的木马文件即可
马子是一句话马子 <%Runtime.getRuntime.exec(request.getParameter(“cmd”));%>
命令建议用这个网站编码一下,不然有可能不会执行 http://www.jackson-t.ca/runtime-exec-payloads.html
若weblogic加载了uudi组件,那么在 /uddiexplorer/SearchPublicRegistries.jsp 会存在端口探测问题
对该jsp传参
?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001
我们通过改变operator的端口发包,看页面变化即可端口探测
端口不存在,就会有could not connect over HTTP to server:
存在就有404 error code (Not Found). Please ensure that your URL is correct,
WebLogic管理端未授权的两个页面存在任意上传getshell漏洞,可直接获取权限。两个页面分别为/ws_utc/begin.do,/ws_utc/config.do
影响版本 Oracle WebLogic Server,版本10.3.6.0,12.1.3.0,12.2.1.2,12.2.1.3。
前提条件:管理员在后台 ->base_domain->配置->一般信息->高级,把这个勾选了
开启后我们来到 http://ip:port/ws_utc/config.do ,把这个改为
路径 /user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css
然后点安全,再点添加,把我们的jsp马传上去
抓包,获取该木马的时间戳
访问
http://123.57.137.109:7001/ws_utc/css/config/keystore/时间戳_文件名
成功访问我的马儿
修复: 设置Config.do、begin.do页面登录授权后访问 ,升级,加waf
转自:HACK学习呀
很赞哦! (119)