海康威视安防平台配置信息泄露漏洞复现与深度利用 1. 项目概述一次典型的信息泄露漏洞复现最近在梳理一些常见安防设备的资产时又遇到了老朋友——海康威视的综合安防管理平台。这个平台在企业、园区、校园等场景的部署量非常大负责整合视频监控、门禁、报警等各类安防子系统。在安全测试中这类集成度高的管理平台往往因为功能复杂、接口众多成为安全评估的重点对象。这次复现的漏洞是一个典型的配置信息泄露问题攻击者无需任何认证就能直接访问到平台的敏感配置文件从而获取到数据库连接信息、加密密钥等核心资产。这类漏洞虽然原理简单但危害极大因为它直接为攻击者打开了通往核心数据的大门。这个漏洞的利用过程非常直接几乎没有任何技术门槛这也是它危险的地方。它不像SQL注入或反序列化那样需要复杂的构造和绕过攻击者只需要在浏览器地址栏输入一个特定的URL路径就能像访问普通网页一样把服务器的配置文件“下载”下来。对于防守方而言这类漏洞的发现和修复优先级应该非常高因为它属于“低垂的果实”容易被自动化扫描工具批量发现并利用。接下来我会详细拆解这个漏洞的成因、复现过程、能获取到的信息价值以及在实际渗透测试中如何利用这些信息进行深度利用。2. 漏洞原理与影响范围深度解析2.1 漏洞核心成因不当的静态资源访问控制这个漏洞的本质是一个目录遍历或敏感文件未授权访问问题。在海康威视综合安防管理平台iSecure Center等版本的Web应用部署中开发人员可能出于调试、备份或配置管理的需要将一些包含敏感信息的配置文件如config.properties,web.xml,jdbc-config.xml等放在了Web应用的目录下或者其路径可以通过Web请求直接映射访问。正常情况下这些文件不应该被外部用户直接访问。Web服务器如Tomcat、Nginx或应用框架如Spring通常会通过安全配置来限制对特定路径或文件类型的访问。然而漏洞的产生往往源于以下几种情况配置缺失或错误在web.xml中没有为*.properties,*.xml,*.config等敏感文件类型配置相应的安全过滤器Security Filter或者配置的URL模式url-pattern存在遗漏。默认配置未修改应用服务器或中间件存在默认的静态文件服务目录如/static,/resources,/uploads而敏感文件被误放于此且目录浏览功能未被禁用。调试信息遗留在开发或测试阶段为了方便查看配置可能会临时开放某个接口或页面来展示配置信息。在版本发布时这个功能没有被移除或关闭导致生产环境信息泄露。路径拼接漏洞平台某个正常功能如文件下载、日志查看的接口在处理用户输入的参数时未进行严格的路径校验和规范化导致攻击者通过../等字符穿越目录访问到Web根目录之外的配置文件。从相关热词如files任意文件读取漏洞复现来看这很可能是一个更通用的任意文件读取漏洞的特例即攻击者通过构造特定的路径可以读取服务器上的任意文件而config文件只是其中价值最高的一类目标。2.2 泄露信息的价值评估成功读取到config文件后攻击者能获得什么这远不止是一个“信息泄露”那么简单它往往是整个内网渗透的起点。一份典型的应用配置文件中可能包含数据库连接信息这是最致命的。包括数据库类型MySQL/Oracle、服务器IP地址、端口、数据库名、用户名和密码可能是明文也可能是弱加密。拿到这些攻击者可以直接连接业务数据库进行增删改查窃取所有业务数据用户信息、监控记录、门禁日志等。加密密钥与盐值用于加密用户密码、会话Session或传输数据的密钥。如果密钥泄露攻击者可以解密之前抓取到的加密数据包或者伪造加密令牌进行身份认证绕过。第三方服务凭证平台可能集成了短信网关、邮件服务器、地图API、云存储等服务配置文件中会保存对应的AK/SKAccess Key/Secret Key、API令牌等。利用这些凭证攻击者可以滥用这些服务产生费用或进行钓鱼攻击。服务器与网络拓扑信息配置中可能透露内部服务器的IP段、域名、端口映射关系帮助攻击者绘制内网网络拓扑图寻找下一个攻击目标。调试与日志配置日志文件路径、日志级别等。攻击者可以尝试读取日志文件从中挖掘更多敏感信息如其他用户的登录记录、SQL查询语句可能包含其他敏感数据、系统错误信息可能暴露其他漏洞点。注意在实际测试中不同版本、不同部署方式的平台配置文件的位置、名称和内容格式可能有所不同。需要结合指纹识别和FUZZ模糊测试来尝试多种可能的路径。2.3 影响版本与资产识别根据公开的漏洞情报和以往的经验该漏洞可能影响海康威视综合安防管理平台的多个历史版本。由于厂商会持续修复新版本可能已不受影响。在资产测绘或渗透测试中可以通过以下特征快速识别潜在目标网页标题/Title页面标题或底部版权信息中包含“Hikvision”、“海康威视”、“综合安防管理平台”、“iSecure Center”等关键词。特定图标/Favicon使用海康威视特有的favicon.ico可以通过计算其哈希值如MD5进行匹配。默认路径与接口尝试访问一些默认的登录页面路径如/portal,/login,/admin观察其样式和响应特征。HTTP响应头查看服务器的Server、X-Powered-By等响应头可能包含“Tomcat”、“Java”等字样表明其基于Java技术栈。识别出目标后再针对性地进行漏洞检测。切忌在未授权的情况下对非授权目标进行测试。3. 漏洞复现环境搭建与手工验证3.1 环境准备与目标定位为了合法、安全地复现和学习该漏洞我们必须在一个受控的环境中进行。通常有两种方式搭建靶场环境如果存在公开的漏洞靶场镜像例如某些基于Vulhub或自己构建的测试环境可以在虚拟机如VMware、VirtualBox中隔离运行。这是最推荐的方式可以随意测试而不触犯法律。使用授权测试资产在获得明确书面授权的前提下对客户或自己单位内网的测试环境进行验证。绝对禁止对互联网上未经授权的任何海康威视设备进行扫描或攻击测试这是违法行为。假设我们已在虚拟机中运行了一个存在漏洞的测试平台其IP地址为192.168.1.100。我们首先通过浏览器访问其Web管理界面如http://192.168.1.100确认服务正常。3.2 手工探测与漏洞验证漏洞的利用点通常是一个固定的URL路径。根据常见的漏洞披露信息可能存在以下敏感配置文件路径注意以下路径仅为示例实际路径需根据版本确定且严禁用于非法测试/portal/static/config.properties/config/db.config/WEB-INF/classes/application.yml/file/download?fileName../../../../WEB-INF/web.xml手工验证步骤打开浏览器开发者工具按F12切换到“网络”(Network)标签页并勾选“保留日志”(Preserve log)。这有助于我们观察所有请求和响应。构造并访问可疑URL在浏览器地址栏输入http://192.168.1.100/portal/static/config.properties并访问。观察响应漏洞存在如果服务器直接返回了配置文件的内容通常是一堆键值对包含jdbc.url,username,password等并且HTTP状态码为200则证明漏洞存在。漏洞可能不存在如果返回404未找到、403禁止访问或跳转到登录页面则可能该路径不对或漏洞已修复。此时需要尝试其他常见路径或进行FUZZ。分析泄露内容如果成功读取仔细查看文件内容。重点关注jdbc.driverClassNamecom.mysql.cj.jdbc.Driverjdbc.urljdbc:mysql://192.168.1.101:3306/isecure?useUnicodetruejdbc.usernamedb_adminjdbc.passwordHik123456encrypt.keybase64encodedstring...redis.host192.168.1.102实操心得有时候配置文件不是.properties格式可能是XML或YAML。如果直接访问返回的是下载对话框或乱码可以尝试用curl命令获取并查看或者使用浏览器的“查看页面源代码”功能。另外不要只尝试一个路径基于Java的Web应用其配置文件常位于WEB-INF/classes/目录下但这个目录通常被服务器保护无法直接访问。因此需要寻找那些可能通过静态资源服务、文件下载接口暴露的路径。3.3 使用工具进行自动化FUZZ手工尝试效率较低当目标路径不明确时可以使用工具进行目录和文件爆破。这里以ffuf这款高效的FUZZ工具为例也可使用dirsearch,gobuster。准备字典我们需要一个专门针对配置文件的字典文件例如config_fuzz.txt内容包含常见的配置文件名和路径片段config.properties application.properties db.properties jdbc.properties web.xml application.yml application.yaml config.xml database.conf /static/config /api/config /admin/config ...执行FUZZ命令ffuf -w config_fuzz.txt -u http://192.168.1.100/FUZZ -fs 0-w指定字典文件。-u指定目标URLFUZZ是占位符会被字典中的词替换。-fs 0过滤掉响应大小为0的结果通常是404。分析结果工具会列出所有返回非404状态的路径。我们需要人工筛选那些返回了有意义内容的响应特别是状态码为200且返回内容看起来像配置文本的路径。重要安全提醒此步骤仅适用于你拥有完全控制权的靶机或获得明确书面授权的测试环境。对互联网资产进行目录爆破是违法行为且极易被对方的防护设备记录和告警。4. 泄露信息的利用与深度渗透思路成功获取配置文件只是第一步如何将获取到的信息转化为实际的渗透成果才是体现技术深度的关键。4.1 数据库直接连接与数据窃取假设我们从config.properties中获取到了以下信息jdbc.urljdbc:mysql://192.168.1.101:3306/hik_platform jdbc.usernameplatform_user jdbc.passwordPssw0rd!2023验证数据库连通性首先确认测试机能否访问到192.168.1.101这个IP目标数据库可能在内网。如果测试机在同一网络可以直接连接。mysql -h 192.168.1.101 -u platform_user -p # 输入密码 Pssw0rd!2023信息收集连接成功后执行SQL命令收集信息。-- 查看所有数据库 SHOW DATABASES; -- 使用目标数据库 USE hik_platform; -- 查看所有表 SHOW TABLES; -- 查看可能包含用户信息的表如 sys_user, t_user, admin 等 SELECT * FROM sys_user LIMIT 10; -- 查看门禁记录、报警记录等业务表数据导出可以将敏感表的数据导出为文件。SELECT * INTO OUTFILE /tmp/user_backup.csv FIELDS TERMINATED BY , FROM sys_user;注意INTO OUTFILE需要MySQL的FILE权限且需要指定服务器上有写入权限的路径。注意事项生产环境的数据库密码在配置文件中可能是加密的。如果遇到加密密码需要结合泄露的加密密钥encrypt.key来尝试解密。常见的加密方式有AES、DES、或简单的Base64编码。需要分析平台使用的具体加密算法有时在代码或其他配置文件中能找到线索。4.2 利用加密密钥进行权限提升配置文件中可能泄露用于签名或加密的密钥例如JWTJSON Web Token的签名密钥、会话Session的加密密钥等。识别密钥用途查看配置项如jwt.secret...,spring.session.redis.key...,security.oauth2.client.clientSecret...。伪造身份令牌如果平台使用JWT进行认证且密钥泄露攻击者就可以伪造任意用户的JWT令牌。首先从一个正常请求中捕获一个有效的JWT令牌。使用在线工具如 jwt.io或pyjwt库用泄露的密钥对这个令牌进行解码、修改例如将用户名改为admin然后重新签名。将伪造的令牌替换原有请求中的令牌可能就能以管理员身份访问系统。解密敏感数据如果配置文件中还有数据加密的密钥可以尝试解密数据库中存储的加密字段如用户密码密文、隐私数据等从而获得明文信息。4.3 横向移动与内网探测配置文件泄露的IP地址如数据库服务器192.168.1.101、Redis服务器192.168.1.102为我们描绘了初步的内网拓扑。端口与服务扫描从已攻破的Web服务器192.168.1.100作为跳板使用nmap或masscan对内网其他IP进行扫描。# 在Web服务器上执行假设已获取shell nmap -sS -p 1-65535 192.168.1.101 nmap -sS -p 1-65535 192.168.1.102服务弱口令爆破针对发现的数据库3306、Redis6379、SSH22、SMB445等服务尝试使用配置文件中找到的密码或其变体进行爆破。很多人习惯在不同系统使用相同或相似的密码。利用其他服务漏洞如果内网中的Redis未授权访问或存在弱口令可以直接写入Webshell。如果SMB服务存在永恒之蓝EternalBlue等漏洞可能直接获取系统权限。5. 漏洞修复与安全加固建议对于企业安全运维人员如果发现自身资产存在此类漏洞应立即采取以下措施5.1 紧急处置措施隔离与访问控制立即在网络层面防火墙、WAF设置规则禁止外部IP对敏感路径如/portal/static/config.*,*.properties,*.xml的访问。同时检查服务器本地防火墙配置。重置泄露凭证数据库立即修改泄露的数据库账号密码并审查该账号近期的操作日志排查是否有异常查询或数据泄露。加密密钥如果加密密钥泄露需要生成新的密钥并替换。注意这可能导致已加密的数据无法解密需要有计划地执行数据迁移或重新加密。第三方服务联系相关服务提供商重置泄露的API密钥、令牌等。删除或移动配置文件将包含敏感信息的配置文件移出Web应用的直接访问目录。例如将config.properties移到WEB-INF/classes/之外或使用操作系统环境变量、专门的配置中心如Spring Cloud Config, Apollo来管理配置。5.2 根本性修复方案应用层访问控制在Web应用的过滤器中显式禁止对配置类文件的访问。以Spring Security为例可以在配置中添加http.authorizeRequests() .antMatchers(/static/*.properties, /WEB-INF/*).denyAll() ...;Web服务器配置在Nginx或Apache的配置中添加规则阻止对特定扩展名文件的访问。# Nginx 示例 location ~* \.(properties|yml|yaml|xml|config)$ { deny all; return 403; }禁用目录浏览确保Web服务器和应用服务器的目录浏览功能被关闭。最小权限原则运行Web服务的系统账号不应具有读取非Web目录文件的权限。数据库连接账号应遵循最小权限原则只授予其应用必需的操作权限。配置信息加密对配置文件中无法避免的敏感信息如密码进行加密存储并在应用启动时在内存中解密。确保加密密钥通过更安全的方式管理如硬件安全模块HSM、或启动时从可信环境注入。定期安全扫描与代码审计将配置文件泄露检测纳入日常的漏洞扫描项。在软件开发周期中引入代码安全审计SAST检查代码中是否存在硬编码密码、敏感信息打印日志等问题。5.3 安全开发规范从源头避免此类问题需要在开发阶段就建立规范配置文件管理严禁将包含生产环境密码、密钥的配置文件提交到代码仓库如Git。使用.gitignore忽略它们。使用application-dev.yml和application-prod.yml区分环境生产配置通过运维流程在部署时注入。安全意识培训让开发人员充分认识到信息泄露的危害避免在代码、注释、调试信息中留下敏感内容。依赖组件安全定期更新Web框架、应用服务器、中间件修复已知的安全漏洞避免被通过其他漏洞间接读取配置文件。这个Hikvision config信息泄露漏洞是一个很好的案例它告诉我们安全是一个整体任何一个细微的配置疏忽都可能成为整个防御体系崩塌的起点。对于攻击者它展示了如何从一点突破逐步深入。对于防御者它强调了最小化暴露面、纵深防御和安全配置检查的重要性。在实战中遇到这类漏洞一定要穷尽一切可能去挖掘其背后的潜在价值因为它往往不是终点而是一扇新的大门。