跳到主要内容

服务元数据与 Banner 凭据收集

不少服务会把凭据或线索写进自描述元数据：TLS 证书的 Subject/SAN、UPnP 的设备描述 XML、FTP 的轮换 banner、HTTP 的自定义响应头。这类信息不需要漏洞利用，一次读取即可拿到，属于低成本高回报的收集面。

核心习惯是：凡是服务主动吐出的结构化信息，都值得逐字段读完。

仅限授权环境

以下手法用于授权测试，发现的凭据线索只在目标范围内验证。

方法 A：TLS 证书字段​

nmap --script ssl-cert -p 443 <target>
openssl s_client -connect host:443

Subject CN/SAN 中出现 CN=user:password 形态凭据的情况并非罕见。证书 SAN 同时是虚拟主机发现的重要来源，具体见 TLS 证书 SAN 与虚拟主机发现。

方法 B：UPnP 设备描述​

服务监听在非常规端口（如 8888）并返回 XML 时，优先请求设备描述文档：

curl http://<target>:8888/rootDesc.xml

friendlyName、modelName 字段可能就是按 user:password 命名约定写入的凭据。

服务时通时断时，用重试循环等它恢复再读。

方法 C：FTP banner 轮换​

重复连接 FTP，观察每次返回的 banner 是否变化。多条 banner 的**首字母拼接（acrostic）**可能构成密码线索：收集若干条后按序拼出候选口令，再到登录口验证。

方法 D：自定义响应头​

curl -D - http://<target>/

观察非标准响应头（如 X-Flag），标记信息或线索常藏在自定义头里。

复核要点​

  • 证书字段、UPnP 字段中的 user:password 组合，逐一在 SSH/登录口验证。
  • banner 记录多次连接的结果，首字母按序拼接后再试。
  • 自定义响应头在不同路径、不同端口可能不同，多个入口都看一遍。

防御建议​

  1. 证书字段只放主机身份信息，不写入任何凭据。
  2. UPnP 元数据脱敏，friendlyName/modelName 不承载口令。
  3. banner 最小化，不输出动态拼接的敏感信息。
  4. 定期审计响应头，移除调试与标记类自定义头。