LexisNexis 数据泄露事件——攻击者声称窃取了 2.04 GB 数据
一个名为 FulcrumSec 的威胁行为者公开声称对 RELX 集团旗下法律信息部门 LexisNexis Legal & Professional 的最新数据泄露事件负责，并声称从该公司的 AWS 云基础设施中窃取了 2.04 GB 的结构化数据。
一个名为 FulcrumSec 的威胁行为者公开声称对 RELX 集团旗下法律信息部门 LexisNexis Legal & Professional 的最新数据泄露事件负责，并声称从该公司的 AWS 云基础设施中窃取了 2.04 GB 的结构化数据。
根据 FulcrumSec 于 2026 年 3 月 3 日发布的帖子，攻击者于 2 月 24 日利用未修补的 React 前端应用程序中的React2Shell 漏洞获得了初始访问权限，据报道，该公司几个月来一直没有解决该缺陷。
攻击者利用了被入侵的LawfirmsStoreECSTaskRoleECS 任务容器，该容器已被授予对生产 Redshift 数据仓库、17 个 VPC 数据库、AWS Secrets Manager 和 Qualtrics 调查平台的读取权限。
值得注意的是，该演员批评了该公司的安全状况，指出 RDS 主密码设置为“Lexis1234”，并且一个任务角色拥有对 AWS 账户中所有机密信息的读取权限，包括生产数据库主凭证。
FulcrumSec 声称，在包含真实姓名、电子邮件、电话号码和工作职能的 40 万个云用户配置文件中，有 118 个帐户持有属于联邦法官、联邦法院法律助理、美国司法部律师和美国证券交易委员会工作人员的 .gov 电子邮件地址。
该演员还声称已获得完整的 VPC 基础设施图和包含 53 个明文密钥的完整 AWS Secrets Manager 转储。
FulcrumSec 明确指出，这与 2024 年 12 月的 GitHub 数据泄露事件无关。在 GitHub 数据泄露事件中，未经授权的第三方通过 LexisNexis 的第三方软件开发平台窃取了个人数据，其中包括超过 364,000 人的社会保障号码。
此次事件再次发生，引发了人们对世界上最敏感的法律数据存储库之一的系统性安全漏洞的严重担忧。
关于作者
评论2次
RELX 集团公司的安全状况 就这样 受到了 FulcrumSec 的批评 ，这个公司 存在bug 和 漏洞 都懒的修复，结果一大帮人的数据全泄露了。
### 结论 LexisNexis事件核心问题为前端漏洞（React2Shell）+过度授权的AWS任务角色+明文存储敏感密钥的三重叠加，导致攻击面横向扩展。攻击者通过React应用突破边界后，因权限失控可直接访问核心资源，最终泄露用户数据和基础设施拓扑。 --- ### 分析路径 **L1攻击面识别** 1. **入口点**：React前端应用（React2Shell漏洞） - Source: 前端代码逻辑缺陷（如未验证用户输入或存在XSS/RCE触发点） - Sink: 未隔离的后端API或容器任务角色 2. **权限扩散**：LawfirmsStoreECSTaskRole - 授予对Redshift、RDS数据库、Secrets Manager的**过度读取权限**（如全局密钥访问） - Sink: 通过任务角色直接拉取生产环境密钥（如RDS密码"Lexis1234"未加密存储） 3. **敏感数据存储**： - AWS Secrets Manager以明文存储53个密钥 - 用户配置文件未脱敏（包含.gov邮箱、电话等） **L2假设与验证** 1. **攻击链验证**： - **假设1**：React2Shell漏洞利用导致反序列化或代码注入 - 验证：检查React前端代码是否存在未过滤的`dangerouslySetInnerHTML`或组件属性注入点 - **假设2**：任务角色权限被滥用 - 验证：分析AWS CloudTrail日志，确认攻击者是否通过`sts:AssumeRole`或直接调用`secretsmanager:GetSecretValue`拉取密钥 2. **数据泄露路径**： - 数据流向：前端漏洞 → 获取容器权限 → 通过角色读取Secrets Manager → 下载明文密钥 → 访问Redshift/VPC数据库 **L3边界/异常场景** 1. **权限边界失效**： - 任务角色本应仅访问特定LawFirmsStore数据，却能跨区域读取17个VPC数据库 - 验证：检查IAM策略中是否存在`Resource: "*"`的宽松配置 2. **密钥存储异常**： - RDS主密码设置为简单字符串"Lexis1234"，违反AWS密钥复杂度要求 - 验证：检查Secrets Manager中密钥是否被正确加密（如KMS CMK使用状态） **L4防御反推与修复** 1. **漏洞修复**： - 补丁React2Shell漏洞，强制前端代码进行输入白名单过滤（如React版CSP策略） 2. **权限最小化**： - 为LawfirmsStoreECSTaskRole**细粒度绑定IAM策略**，仅允许访问特定ARN资源 - 通过AWS SCP（Service Control Policies）限制任务角色对Secrets Manager的跨区域/跨服务访问 3. **密钥安全加固**： - 强制Secrets Manager密钥使用AWS KMS加密，并启用密钥轮换策略 - 替换所有明文存储的密码（如RDS主密码），改为通过动态IAM角色临时凭证访问数据库 4. **监控与溯源**： - 部署CloudWatch日志分析规则，监控`secretsmanager:GetSecretValue`高频调用 - 配置GuardDuty检测任务角色异常权限提升行为 --- ### 验证步骤 1. **漏洞验证**： - 使用`nuclei`扫描React应用是否存在`react-rce`模板匹配的漏洞 - 查看应用代码中是否存在未过滤的`new Function()`或`eval()`调用 2. **权限验证**： ```bash # 检查LawfirmsStoreECSTaskRole的权限边界 aws iam list-attached-role-policies --role-name LawfirmsStoreECSTaskRole | grep "SecretsManager" # 验证Secrets Manager密钥是否加密存储 aws secretsmanager describe-secret --secret-id <secret_arn> --query 'KmsKeyId' ``` 3. **日志溯源**： ```bash # 检查Secrets Manager的访问记录 aws cloudtrail lookup-events --lookup-attributes '{"AttributeKey": "EventName", "AttributeValue": "GetSecretValue"}' --max-items 100 ``` --- ### 修复建议 1. **立即行动**： - 拆分任务角色权限（生产环境角色与容器运行角色分离） - 关闭所有未使用的Secrets Manager密钥访问权限 2. **长期防御**： - 部署SAST工具（如Snyk）对React代码进行RCE漏洞扫描 - 启用AWS配置规则（AWS Config）监控IAM策略的最小化原则（如拒绝`Resource: "*"`策略） - 对所有.gov邮箱用户推送双重认证（MFA）强制策略 > **关键结论**：此次事件本质是**权限爆炸模型（Principle of Least Privilege失效）+基础安全配置缺失**的典型，修复需从代码层、IAM策略层、密钥管理层三端同步加固。