赏金猎人|记一次对某电商平台的多种中高危漏洞

0x01 前言概述 平台厂商注册资金8000W，平台类型为电商平台，经过探测打点平台存在多种中高危漏洞，大部分为逻辑漏洞 存在漏洞： 任意用户注册  无限短信验证发送 任意用户更改密码用户信息泄露  redis未授权访问 旁站信息泄露 * 本文涉及到相关漏洞已报送厂商并修复，本文仅限技术讨论和研究，严禁用于非法用途，否则产生后果自行承担 0x02 漏洞复现 1. 任意用户注册漏洞 域名:xxx.xx.com及xx.xx.com在用户注册时，可抓取API接口，在API接口内获取到验证码，无需经过客户端，完成用户注册 以手机号18888888888为例，在注册时，发送验证码后，截取到API后，响应内容会显示出此次验证码 通过在接口响应内容处获取到验证码，成功注册为平台用户 危害: 对平台造成无用数据，影响正常业务，对于后期正常用户无法进行正常流程注册 修复建议:避免将验证码直接暴露在API响应中：确保您的API响应不会直接包含验证码或其他敏感信息。验证码应该只通过安全的通道传输给用户。 设计更强大的验证码生成和验证机制：使用更复杂的验证码生成算法，并确保生成的验证码足够随机且不易被猜测。验证机制应该是严谨的，有效地防止恶意用户和自动化攻击。 使用短期且一次性的验证码：生成具有较短过期时间的一次性验证码，以限制攻击者利用已泄露的验证码进行注册。一旦验证码过期，就需要重新生成新的验证码。 引入验证码刷新机制：在每次请求验证码时，为用户提供一个刷新验证码的选项。这样用户可以选择刷新验证码，使已泄露的验证码无效。 增加服务器端限制和验证：在服务器端对验证码进行额外的验证，确保只有经过验证的合法请求才能成功注册用户。例如，可以实施请求频率限制、防止重放攻击等措施。 2. 短信验证码无限发送 可能会有人认为这个不算是漏洞，但是目前抓到的是，对于指定手机号，可以通过API无限发送短信验证码，造成对用户短信HZ，危害极大，并非横向短信漏洞 漏洞成因：判定平台应该是本地api生成验证码，使用SMS网关进行发送，未对发送频率做限制 危害:对厂商造成巨大的资金损失，对正常用户造成骚扰 修复建议:引入短信发送频率限制：对于同一手机号码，在一段时间内限制其能够接收到的短信数量。您可以设置一个合理的阈值，例如每小时或每天最多发送的短信数量，以防止攻击者滥用API。 实施用户注册验证流程：为用户注册过程引入多步骤验证，要求用户在注册之前完成额外的身份验证步骤，例如使用邮箱验证、人机验证（如验证码、图形验证码等）或其他验证方式。 验证码有效期和单次使用：确保所发送的验证码具有适当的有效期，并且在用户成功验证后立即使其失效。这将限制攻击者利用泄露的验证码进行恶意行为。 监控异常活动：实施实时监控和分析系统，以检测异常活动和大规模的短信发送。如果系统检测到异常行为，例如单个手机号发送大量短信，可以触发警报并采取相应的措施，如暂停该手机号的短信发送功能。 使用黑名单和白名单：维护一个可信号码的白名单，只允许向白名单中的号码发送短信。同时，记录恶意行为的号码并将其添加到黑名单中，阻止其继续使用API发送短信。 强化API安全措施：采取必要的措施，例如身份验证、访问令牌和API密钥管理等来保护短信验证API的访问权限，以防止未经授权的访问和滥用。 3. 任意用户更改密码漏洞 以手机号18888888888为例，在更改密码处抓取API数据包，成功拿到验证码 填写验证码后可以进入后期更改密码流程 危害:攻击者根据信息泄露漏洞，批量更改用户密码，对平台业务和个人业务造成巨大影响 修复建议:避免将验证码直接暴露在API响应中：确保您的API响应不会直接包含验证码或其他敏感信息。验证码应该只通过安全的通道传输给用户。 设计更强大的验证码生成和验证机制：使用更复杂的验证码生成算法，并确保生成的验证码足够随机且不易被猜测。验证机制应该是严谨的，有效地防止恶意用户和自动化攻击。 使用短期且一次性的验证码：生成具有较短过期时间的一次性验证码，以限制攻击者利用已泄露的验证码进行改密。一旦验证码过期，就需要重新生成新的验证码。 引入验证码刷新机制：在每次请求验证码时，为用户提供一个刷新验证码的选项。这样用户可以选择刷新验证码，使已泄露的验证码无效。 4. 敏感用户信息泄露数据 目前对于用户探测数据量大概在20-30万左右，存在的泄露用户信息类型有： 姓名，手机号，邮箱，家庭住址，电话座机 在收货地址位置中，数据包存在userid，通过枚举userid可以完成遍历用户信息 对用户userid(部分)修改后进行遍历得到存在的信息 危害:攻击者可通过遍历信息，拿到用户敏感信息，对用户的生活造成影响，对平台影响不好 修复建议:避免将验证码直接暴露在API响应中：确保您的API响应不会直接包含验证码或其他敏感信息。验证码应该只通过安全的通道传输给用户。 设计更强大的验证码生成和验证机制：使用更复杂的验证码生成算法，并确保生成的验证码足够随机且不易被猜测。验证机制应该是严谨的，有效地防止恶意用户和自动化攻击。 使用短期且一次性的验证码：生成具有较短过期时间的一次性验证码，以限制攻击者利用已泄露的验证码进行改密。一旦验证码过期，就需要重新生成新的验证码。 引入验证码刷新机制：在每次请求验证码时，为用户提供一个刷新验证码的选项。这样用户可以选择刷新验证码，使已泄露的验证码无效。 5. redis服务未授权漏洞 根据对信息的收集，主站域名 xxx.xxx.com的IP为1xx.57.xxx.xx 进行端口探测发现存在6379端口redis服务 且已知系统为Windows server 2016 此redis已成功写入文件，未写入webshell，未对企业造成危害 因为是IIS中间件，所以在默认web根目录下成功写入文件 此时再次扫描，成功写入文件 危害: 攻击者可进行数据篡改，数据泄露，命令执行，文件写入等 修复建议:设置密码认证：在Redis配置文件中设置密码，需要在客户端连接时提供正确的密码才能进行操作。这将阻止未经授权的访问。 绑定特定IP地址：在Redis配置文件中绑定只允许特定IP地址进行连接和访问Redis服务。将Redis监听IP地址绑定到本地或受信任的IP地址，以减少对Redis的直接公开访问。 配置防火墙规则：通过网络防火墙或安全组配置，限制来自外部环境的访问Redis服务的网络流量。只允许特定的IP地址或IP地址范围访问Redis端口。 修改Redis默认端口：使用非默认的端口号，例如将Redis的默认端口6379修改为其他数字。这可以减少针对默认端口的自动化扫描攻击。 6. 平台旁站存在敏感信息泄露 经过对旁站和IP的打点，发现很多旁站以web目录的样式进行开放，不清楚是什么情况，还是说未配置首要访问文件，造成所有文件泄露 目录下存在fckeditor上传文件，存在源代码备份文件，可以在web.config中拿到数据库地址及密码 在目录下发现了fckeditor的编辑器，想要上传来着，无奈上传所需文件被删除，很伤心 危害: 攻击者可通过泄露信息进行分析，打点，以及获取到d额源代码进行其他方式利用 修复建议:立即关闭/删除非必要的旁站：对于无需继续运行的旁站，立即关闭或删除它们，以停止潜在的数据泄露。 审查和修复源代码：仔细审查源代码中的安全漏洞，包括敏感信息硬编码、不安全的文件上传、未经身份验证的访问等。修复这些漏洞，并确保使用最新的安全性修补程序。 加强访问控制和权限管理：审查并更新网站的访问控制和权限策略。确保只有授权用户才能访问敏感数据和文件。实施强密码策略、多因素身份验证等安全措施。 加密敏感数据：对于存储在数据库或文件系统中的敏感数据，使用适当的加密算法进行加密。这将增加数据泄露时的安全性。 实施防护措施：安装和配置防火墙、入侵检测和预防系统（IDS/IPS）、反病毒软件等安全工具，以检测和阻止未经授权的访问尝试。 定期备份和监控：建立定期备份机制，确保可以还原网站数据和文件。同时，实施实时监控和日志记录，以便及时发现异常活动和潜在的数据泄露事件。 0x03 结语 目前以对该厂商所有漏洞以报送厂商修复，愿天下无风险，安全事件常有，注重保护隐私