datacon
This commit is contained in:
Cool-Y
parent
93e65e6a90
commit
fec4feef62
@ -194,4 +194,4 @@ typedef struct _IMAGE_IMPORT_DESCRIPTOR {
|
||||
} IMAGE_IMPORT_DESCRIPTOR;
|
||||
```
|
||||
- 一个exe程序加载dll的IMAGE_IMPORT_DESCRIPTOR
|
||||
|
||||
|
||||
|
||||
@ -29,13 +29,13 @@ SMB协议是客户机/服务器型协议，客户机通过该协议可以访问
|
||||
# 漏洞成因
|
||||
处于``\source3\rpc_server\src_pipe.c的is_known_pipename()``函数未对传进来的管道名`pipename`的路径分隔符`/`进行识别过滤，导致可以用绝对路径调用恶意的so文件，从而远程任意代码执行。
|
||||
首先看到`is_known_pipename()``函数
|
||||
|
||||
|
||||
|
||||
跟进到`smb_probe_module()`
|
||||
|
||||
|
||||
|
||||
再跟进到`do_smb_load_module()`，发现调用的过程就在其中,调用了传进来的moudule_name对应的init_samba_module函数
|
||||
|
||||
|
||||
|
||||
我们可以通过smb服务上传一个恶意的so文件，随后通过上述过程进行调用，执行任意代码。
|
||||
|
||||
@ -159,45 +159,45 @@ exploit
|
||||
然后重启smbd服务。
|
||||
|
||||
# 分析POC，查找原因
|
||||
(来自[Wz'blog](https://www.wzsite.cn/2018/07/20/Samba%E8%BF%9C%E7%A8%8B%E6%BC%8F%E6%B4%9E%E5%88%A9%E7%94%A8%E5%88%86%E6%9E%90%20CVE-2017-7494/))
|
||||
(来自[Wz'blog](https://www.testzero-wz.com/2018/07/20/Samba%E8%BF%9C%E7%A8%8B%E6%BC%8F%E6%B4%9E%E5%88%A9%E7%94%A8%E5%88%86%E6%9E%90%20CVE-2017-7494/))
|
||||
|
||||
## 建立SMB连接。若需要账号密码登录，则必须登录后才能继续
|
||||
从微软上扒的SMB协议建立时序图：
|
||||
|
||||
|
||||
|
||||
对应POC:
|
||||
|
||||
|
||||
|
||||
|
||||
## 利用NetShareEnumAll遍历目标服务器的共享名(ShareName)以及获取对应的共享文件夹下的可写路径(Path)
|
||||
|
||||
|
||||
|
||||
其中find_writeable_path()函数需要跟进看一下：
|
||||
|
||||
|
||||
|
||||
再跟进看enumerate_directories()以及verify_writeable_directory函数
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
可以看到代码逻辑很清楚，首先遍历出当前路径所有的文件夹，然后尝试往里面写一个随机的txt文件用作可写测试，随后删除掉txt文件，记录下可写的文件路径。
|
||||
至此，我们得到了一个共享名(即本例中的data)以及其当前路径下的可写目录(/tmp)
|
||||
|
||||
## 利用NetShareGetInfo获取共享文件夹的绝对路径(SharePath)
|
||||
|
||||
|
||||
至此获取到了共享名data的绝对路径。
|
||||
值得注意的是，这里跟早期的Payload不一样，早期的payload是靠暴力猜解目录，所以跟一些分析文章有些出入。现在的Payload是根据NetShareGetInfo直接获取到准确的路径，极大地提高了攻击的成功率。
|
||||
|
||||
## 上传恶意so文件
|
||||
|
||||
|
||||
其中写入的so文件是Metasploit生成的反弹shell，很简单的执行一句命令。有一点需要注意的是里面的函数名必须是samba_init_module并且是一个导出函数，这个原因上述的漏洞分析也有提及。
|
||||
|
||||
## 调用恶意文件，并执行echo命令打印随机字符串检验是否调用成功
|
||||
|
||||
|
||||
利用从第2步获取到的可写文件目录(Path)以及从第3步得到的共享文件绝对路径(SharePath)构造恶意管道名\\PIPE\/SharePath/Path/Evil.so，然后通过SMB_COM_NT_CREATE_ANDX进行调用。
|
||||
在复现时，调用恶意so文件总会失败，产生Error Code为：STATUS_OBJECT_NAME_NOT_FOUND的错误。尚未能明白为什么会出现这种首次失败的情况，也许要详细看看smb协议才能知道了。
|
||||
POC代码将STATUS_OBJECT_PATH_INVALID作为我们payload被加载的标志，随后就是用NBSS协议进行了一次远程代码执行的测试，执行代码为echo随机字符串。
|
||||
|
||||
## 删除恶意so文件，断开smb连接
|
||||
|
||||
|
||||
|
||||
由msf给出的poc过程可见，对路由器的攻击在第五步出现问题，因此出现Failed to load STATUS_OBJECT_NAME_NOT_FOUND
|
||||
|
||||
120
source/_posts/coremail.md
Normal file
120
source/_posts/coremail.md
Normal file
@ -0,0 +1,120 @@
|
||||
---
|
||||
title: DataCon Coremail邮件安全第三题 Writeup
|
||||
|
||||
date: 2020-10-16 11:07:33
|
||||
tags:
|
||||
- 钓鱼邮件
|
||||
- phishing email
|
||||
categories:
|
||||
- 杂七杂八
|
||||
---
|
||||
研一的时候参加了第一届datacon，可惜因为课程任务太重了，最后连答案都没提交。今年和研一两位师弟师妹组队参加，本以为又要躺过去了，最后被两位的热情感染，完成了比赛还取得不错的成绩，也算是完成了研究生阶段的一个小遗憾。
|
||||
我之前没做过数据分析也没接触过邮件安全，借这次赛题好好的补了一课，第一题是识别发件人伪造，第二题是垃圾邮件分类，第三题是识别威胁邮件，全部是真实数据，难度层层递进。
|
||||
|
||||
## 赛题理解
|
||||
|
||||
### 目标
|
||||
|
||||
> 在真实的企业网络环境中，一些攻击者总能想方设法绕过邮件检测引擎，使攻击邮件抵达员工的收件箱，最终达到窃取用户登录凭证等目的。与此同时，企业网络安全管理团队的精力十分有限，不可能实现对企业的全部邮件进行逐一审查。
|
||||
|
||||
> 如果你是一家企业的邮件安全负责人，能否基于数据分析，利用长达三个月的企业邮件服务器日志摘要信息，设计检测模型，输出一批威胁程度较高的邮件，以便于后续的人工审查。请注意：检测模型不允许使用第三方威胁情报，检测系统必须能够离线运行。
|
||||
|
||||
|
||||
从赛题说明中，我们可以提取出几个关键词：邮件、窃取用户凭证、威胁程度、离线运行，最终目的是从邮件通信日志中筛选出钓鱼邮件（窃取用户登录凭证）。
|
||||
|
||||
### 数据
|
||||
|
||||
> 约80万封邮件通信日志，赛事主办方已经对数据进行了脱敏和匿名化处理。
|
||||
|
||||
> 提示：根据既往经验知识，威胁程度较高的邮件规模约在2千至2万左右。
|
||||
|
||||
主办方给了威胁邮件的大致数量范围，邮件通信日志与第一题真实的邮件格式不同，每一封邮件都是json格式的数据，只保留了8个字段，而且做了匿名化处理。
|
||||
|
||||
```
|
||||
* rcpt：收信人邮箱地址 ---> [salt+hash]@[salt+hash替换掉敏感域名，其它保留].[真实TLD]
|
||||
* sender：发件人邮箱地址 ---> 同上
|
||||
* ip：企业邮箱用户登录ip ---> 经过映射处理，不是真实的ip地址，但保留子网关系
|
||||
* fromname：发信人名称 ---> 对于白名单关键词（比如admin，hr，管理员，经理等）进行保留。除了白名单的其它部分salt+hash
|
||||
* url：直接从邮件正文、subject、附件、fromname中提取出来的url ---> [真实协议]://hash+salt替换掉敏感域名.真实TLD/真实参数
|
||||
* @timestamp：时间戳
|
||||
* region：企业邮箱用户登录ip所在地区
|
||||
* authuser：收信时False，发信时True，注意企业邮箱域内互发的话是只有一条发信记录
|
||||
* tag：邮件编号，提交答案需要用到
|
||||
```
|
||||
|
||||
### 提交规则
|
||||
|
||||
主办方给的方法很简单，每一封邮件均有字段tag，结果只需要每行一个威胁邮件的tag，换行使用`\n`
|
||||
|
||||
### 评分
|
||||
|
||||
> 比赛过程中排行榜展示每位选手的F1-score，未提交答案F1-score视为0，比赛结束后，每位选手的得分由`min-max归一化*100`计算得出，保留1位小数（四舍五入）
|
||||
|
||||
最终得分不仅取决于自己的F1-score，还取决于所有选手的整体成绩。另外利用F1-score，我们还能推测出这80万封邮件中大致的威胁邮件数量，后续再说。
|
||||
|
||||
## 解题思路
|
||||
|
||||
在初步浏览了一些邮件日志内容后，我们将目标锁定为寻找钓鱼邮件的数量。首先需要知道钓鱼邮件是什么，具备哪些特征。
|
||||
|
||||
### 1. 使用短链接
|
||||
|
||||
短链接就是将较长的网址，通过特定的算法转换为简短的网址字符串。用户无法通过短链接地址直接看出点击这个短链接地址后究竟会打开什么样的网站。
|
||||
常见的有：`t.cn`、 `bit.ly`、 `bit.do`、 `u.to`、 `url.cn`
|
||||
|
||||
### 2. 使用十六进制IP地址编码格式进行混淆
|
||||
|
||||
网络攻击者正在不断发展其工具、策略和技术，以逃避垃圾邮件检测系统。 一些垃圾邮件活动非常依赖电子邮件信息中的混淆URL。其中就有使用了URL主机名部分中使用的十六进制IP地址编码格式来逃避检测。
|
||||
从技术上讲，IP地址可以用多种格式表示，因此可以在URL中使用，如下所示：
|
||||
|
||||
* **https://216.58.199.78**
|
||||
点分十进制IP地址，此示例使用Google.com的IP
|
||||
* **https://0330.0072.0307.0116**
|
||||
八进制IP地址，将每个十进制数字转换为八进制
|
||||
* **https://0xD83AC74E**
|
||||
十六进制IP地址，将每个十进制数字转换为十六进制
|
||||
* **https://3627730766**
|
||||
整数或DWORD IP地址，将十六进制IP转换为整数
|
||||
|
||||
浏览器将自动将十六进制或其他IP格式转换为十进制的IP地址。
|
||||
|
||||
### 3. 邮件钓鱼测试工具固有特征
|
||||
|
||||
PhEmail是基于python编写的一款网络钓鱼邮件测试工具。PhEmail可以同时向多个用户发送钓鱼邮件，并记录点击的用户的邮箱和IP等信息。PhEmail可以通过Google收集邮箱，完成邮箱收集工作。
|
||||
收集邮箱后钓鱼邮件发送常用参数：`-w 钓鱼网站url地址，发送后会自动添加index.php?email=等内容`
|
||||
钓鱼邮件中的url链接伪造时添加email地址并进行编码，通过钓鱼网站中php文件代码来识别email并记录log文件中。php可以进行重定向到其他网站。
|
||||
|
||||
### 4. 冒充管理员等身份
|
||||
|
||||
对于企业用户来说，OA钓鱼邮件是最具危险性的钓鱼邮件。攻击者冒充系统管理员发送邮件，以邮箱升级、邮箱停用等理由诱骗企业用户登录钓鱼网站，并进而骗取企业员工的帐号、密码、姓名、职务等信息。
|
||||
钓鱼邮件经常伪装的发件人身份有以下几个主要类型：
|
||||
|
||||
* 冒充系统管理员，以系统升级、身份验证等为由，通过钓鱼网站等方式骗取企业员工的内网帐号密码或邮箱帐号密码。
|
||||
* 冒充特定组织，如协会、机构、会议组织者或政府主管部门等身份发送邮件，骗取帐号密码或钱财。
|
||||
* 冒充客户或冒充自己，即攻击者会冒充企业客户或合作方对企业实施诈骗，或者是攻击者冒充某企业员工对该企业的客户或合作方实施诈骗。当然也有可能 是冒充某个企业的管理者对企业员工实施诈骗。
|
||||
|
||||
从fromname（发信人名称）中获得的常见名称有：admin、support、安全、service、管理员等。
|
||||
|
||||
|
||||
### 5. 同形异义词攻击
|
||||
|
||||
同形异义字是利用IDN中一些非拉丁字符语种的字母与拉丁字符非常相似，字面看很难区分的特性，找到对应的字符来实现钓鱼攻击。例如16ვ.com(U+10D5)、16ဒ.com (U+1012)、16ҙ.com (U+0499) 都在一定程度上和163.com有相似性，基于一些开放的https证书服务这些域名还能取得相应的证书，进一步增加钓鱼成功的可能性。
|
||||
Punycode是RFC 3492标准设计的编码系统，用于把Unicode转换为可用的DNS系统的编码，比如16ҙ.com就会被转成**xn--16-8tc.com**，这在一定程度上可以防止IDN欺骗。
|
||||
|
||||
### 6. URL跳转
|
||||
|
||||
使用URL跳转可以突破钓鱼软件检测系统。这类钓鱼软件检测系统在检测是否是钓鱼网站或者恶意系统的时候，检测的是URL，而并非网站的内容。比如，从qq邮箱打开一个URL的时候，会弹出一个网页提示。但并不是所以的网站都会提示，一些知名网站是不可能做钓鱼网站的，所以邮箱就不会拦截，也就是说，当邮箱碰到不认识的网站的时候才会进行提示。
|
||||
这样攻击者就可以利用URLt跳转来躲过恶意检测。比如：**http://www.baidu.com/page?url=http://www.evil.com**
|
||||
|
||||
## 参考
|
||||
2016中国企业邮箱安全性研究报告 https://www.anquanke.com/post/id/85416
|
||||
PhEmail https://github.com/Dionach/PhEmail
|
||||
微软：最新钓鱼技术2019总结 https://www.4hou.com/posts/A9oz
|
||||
[译] APT分析报告：02.钓鱼邮件网址混淆URL逃避检测 https://blog.csdn.net/Eastmount/article/details/108728139
|
||||
2017中国企业邮箱安全性 研究报告 http://zt.360.cn/1101061855.php?dtid=1101062514&did=491163339
|
||||
基于URL跳转与XSS组合利用的钓鱼分析 https://xz.aliyun.com/t/6303
|
||||
IDN Spoof漏洞自动化挖掘 https://blog.lyle.ac.cn/2018/12/08/idnfuzz/
|
||||
APT杂项篇一种老旧，但却防不胜防的钓鱼攻击（Punycode 钓鱼攻击）https://www.codenong.com/cs106406317/
|
||||
钓鱼网站也在使用https加密，如何识别钓鱼网站？ https://www.freebuf.com/company-information/208790.html
|
||||
恶意邮件智能监测与溯源技术研究 https://www.anquanke.com/post/id/172046#h2-0
|
||||
钓鱼邮件的投递和伪造 https://xz.aliyun.com/t/6325#toc-0、
|
||||
用机器学习检测钓鱼网站 http://blog.hubwiz.com/2019/09/17/detect-phishing-url/
|
||||
@ -22,7 +22,7 @@ categories:
|
||||
|
||||
**香农信息论**
|
||||
|
||||
|
||||
|
||||
|
||||
**什么是信息？** 用来减少随机不确定的东西
|
||||
|
||||
@ -42,7 +42,7 @@ categories:
|
||||
1. 中间人攻击
|
||||
> "指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。"
|
||||
|
||||
|
||||
|
||||
* 公共wifi、路由器劫持
|
||||
* 一般使用加密来防御
|
||||
* 加密的代价：维护密钥证书、影响功能（运营商无法做缓存）
|
||||
@ -59,7 +59,7 @@ categories:
|
||||
----------------
|
||||
|
||||
### TCP三次握手
|
||||
|
||||
|
||||
>1. 客户端通过向服务器端发送一个SYN来创建一个主动打开，作为三路握手的一部分。客户端把这段连接的序号设定为*随机数A*。
|
||||
>2. 服务器端应当为一个合法的SYN回送一个SYN/ACK。ACK的确认码应为A+1，SYN/ACK包本身又有一个*随机产生的序号B*。
|
||||
>3. 最后，客户端再发送一个ACK。当服务端收到这个ACK的时候，就完成了三路握手，并进入了连接创建状态。此时包的序号被设定为收到的确认号A+1，而响应号则为B+1。
|
||||
@ -82,12 +82,12 @@ categories:
|
||||
|
||||
**攻击模型：**
|
||||
给受害者安装一个无特权的应用程序（仅能网络连接），这个程序跟非中间人的攻击者里应外合，劫持手机上所有的TCP连接。
|
||||
|
||||
|
||||
|
||||
**如何劫持TCP**
|
||||
1. 需要的信息：Facebook的连接IP地址和端口号，由此可以知道TCP连接的序列号，利用序列号伪装成Facebook给手机发消息。
|
||||
使用netstat命令获取：
|
||||
|
||||
|
||||
|
||||
2. 任务：由于TCP的序列号通常连续，所以要精确猜到它的下一个序列号。
|
||||
3. 如何验证序列号正确：通过某种侧信道，这个恶意软件在后台可以提供反馈。
|
||||
@ -116,9 +116,9 @@ categories:
|
||||
**如何利用共享限速器：**
|
||||
先判断是否建立了连接。然后伪造TCP包，需要猜测源端口，如果猜测正确，服务器会返回一个challenge，攻击者不断触发，一共可以收到99个（还有一个发给了客户端）；如果猜测错误，则一共可以收到100个challenge。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**评估：** 是否建立了连接：<10s ; Seq：30s ； ACK:<10s
|
||||
|
||||
@ -132,15 +132,15 @@ Can Jeopardize Your Secrets
|
||||
之前的漏洞无论是计数器还是限速器都属于软件，很好更正，但这篇文章的漏洞利用无法修复。
|
||||
|
||||
**TCP收包的原理：** 通常TCP收包要看这个包是否匹配了当前的某一个连接。如果连接匹配上了，就会去看这个包的序列号；如果序列号不对，会触发一个回复，说明这个序列号存在问题；如果序列号正确，但反向序列号不对，也会丢包。当连接匹配、序列号和反向序列号正确时，就会返回一个数据包。
|
||||
|
||||
|
||||
|
||||
**侧信道：** 攻击者伪装成服务器给客户端发包，正确的序列号会有***回复***，错误则没有。但回复时发送给服务器的，有没有回复攻击者并不知道。那么如何去判断有没有回复，利用无线网络的 ***半双工*** 传输。
|
||||
让有回包和没有回包的时间差异放大。
|
||||
|
||||
**判断流程：** 客户端和路由器之间wifi通信。攻击者依次发送三个数据包，第一个包用来测试正常的RTT。第2个包是伪装成服务器发送的，如果第2个包猜对了，客户端会向服务器返回数据包，这会导致占用更长时间的wifi信道，从而会使第3个包的RTT更长。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**评估：** 在本地环境下，如果发送40个包，就有20ms的RTT差别。
|
||||
|
||||
@ -160,14 +160,14 @@ Can Jeopardize Your Secrets
|
||||
**4. 细节：**
|
||||
* **连接（四元组）推断：** 每一轮使用30个重复包测试一个端口，如果端口号正确，就会发现RTT大幅增加。如果还要完成 ***web缓存投毒*** ，还需要傀儡初始化连接来协助，根据系统不同，有不同的端口选择算法可以优化：***windows&macOS*** 使用全局和顺序端口分配策略为其TCP连接选择短暂的端口号，这意味着攻击者可以在观察到与恶意Web服务器的初始连接后推断出要使用的下一个端口号，这完全消除了对端口号推断的需要。***NAT*** 端口保留，不需要关心外部端口被转换成不可预知的内部端口。***来自同一域名的多个IP地址***，这意味着攻击者需要付出更大的代价来推断端口号。
|
||||
* **序列号推断：** 通过利用时序侧信道来判断是否存在相应的响应，从而将窗口序列号与窗外序列号区分开来。一旦我们得到一个 ***窗口内序列号***，通过进行二分搜索进一步将序列号空间缩小到单个值 ***RCV.NXT***。如果还要使用傀儡建立的连接发起web缓存投毒，可以进一步优化：***增大接收窗口的大小***，可以减少猜测的迭代次数，通常可以放大到500000(之前是65535)，而且根据RFC793,窗口放大之后就永远不会缩小。
|
||||
|
||||
|
||||
* **TCP劫持：** 通过劫持傀儡初始化的连接，可以简化web缓存投毒的过程。三个os在ACK验证上都不符合规范，所以各自处理情况也不同——***windows***：客户端必须持续发送请求以防止ACK接收窗口仅为一个字节，这要求攻击者必须能准确预期下一个序列号并解决大量流量带来的噪声。
|
||||
因此，作者设计了一种新策略，该策略利用处理重叠数据的TCP行为和处理损坏的HTTP响应的浏览器行为——在Windows主机上缓冲的攻击者注入数据可能会破坏来自服务器的真实HTTP响应。 ***（1）注入***，傀儡不断从服务器上请求脚本，而攻击者发送2^23/|wnd|个欺骗性数据包，这些包的窗口序列号与RCV.NXT加上偏移量相匹配，其中|wnd|为ack接收窗口大小，第i个数据包的ACK号为i*|wnd|，payload为
|
||||
```
|
||||
websocket.send(|wnd|*i)
|
||||
```
|
||||
因此，这些数据包中包含有效ACK号的一个包将被缓冲，并破坏真实的HTTP响应头。浏览器执行注入的脚本时，它将通过websocket发送猜测的ACK号，提供有效的窗口内ACK号。
|
||||
|
||||
|
||||
***（2）利用***，由于客户端已经接受了额外的欺骗payload，推进了其预期的序列号，因此客户端和服务器实际上已经被去同步。攻击者现在可以简单地发送欺骗性响应（知道预期的序列号和有效的ACK号）。如果我们只想执行一次性注入，只需用恶意脚本替换第一步中的payload就足够了。
|
||||
此外，针对Windows的注入步骤存在更加通用的替代策略，不依赖于浏览器行为。 具体来说，由于HTTP响应的前几个字节是可预先确定的（即HTTP），不破坏真实的响应，而是覆盖标题和正文以形成合法但恶意的响应。 在这种情况下，浏览器将完全忘记注入的存在。 这表明一旦序列号泄露，就存在各种方法来有效地将数据注入浏览器，而不用进行基于时间信道的慢得多的ACK号推断。
|
||||
|
||||
|
||||
1
themes/next-reloaded
Submodule
1
themes/next-reloaded
Submodule
@ -0,0 +1 @@
|
||||
Subproject commit d24c48efb1ff1182b23926a3835e350f9c3ab6eb
|
||||
Loading…
Reference in New Issue
Block a user