恶意npm包利用Redis与PostgreSQL建立后门的技术分析-育师

1. 恶意npm包的威胁现状与攻击模式

最近安全研究人员发现了36个恶意npm包，它们通过伪装成常用工具库的方式潜入开发者的项目依赖中。这些包一旦被安装，就会利用Redis和PostgreSQL数据库服务建立持久化后门，使攻击者能够长期控制受害系统。

这类攻击之所以危险，是因为它完美利用了现代开发流程中的几个关键弱点：

开发者习惯性地信任npm官方仓库中的包
项目构建时自动安装所有依赖项
Redis和PostgreSQL这类数据库服务在开发环境中普遍存在

攻击者精心设计了这些恶意包的package.json文件，使其看起来像是解决常见问题的实用工具。比如有的伪装成"redis-utils"、"pg-helpers"这样的常见辅助库，有的则使用与流行包极其相似的名称（如"lodash"与"lodashh"）。

重要提示：在安装任何npm包前，务必检查其下载量、维护者信息和issue记录。对于新发布或下载量突然激增的包要特别警惕。

2. 恶意包如何利用数据库服务建立持久化

2.1 Redis被滥用的技术细节

这些恶意包一旦被执行，会首先检查本地或可访问的Redis服务。它们使用以下典型攻击链：

通过默认端口6379尝试连接Redis
如果认证开启，会尝试常见弱密码（如"password"、"redis123"等）

连接成功后，会创建特殊的键值对：

SET backdoor:session "<malicious_script>" CONFIG SET dir /var/spool/cron/ CONFIG SET dbfilename root

通过Redis的持久化机制，将恶意脚本写入crontab实现定时执行

这种技术利用了Redis的两个危险特性：

能够修改持久化存储位置
能够将内存数据转储到任意文件

2.2 PostgreSQL的攻击向量

对于PostgreSQL，攻击者采用了更隐蔽的方式：

扫描5432端口寻找可用实例
尝试使用postgres用户和空密码连接

创建恶意函数并设置为自动执行：

CREATE OR REPLACE FUNCTION public.backdoor() RETURNS void LANGUAGE plpgsql AS $$ BEGIN COPY (SELECT '恶意内容') TO '/etc/cron.hourly/malicious'; END; $$; ALTER DEFAULT PRIVILEGES GRANT EXECUTE ON FUNCTIONS TO public;

通过PostgreSQL的COPY命令实现文件写入

3. 如何检测系统是否已受影响

3.1 Redis服务检查清单

执行以下命令检查Redis是否存在异常：

# 查看所有键 redis-cli KEYS '*' # 检查持久化设置 redis-cli CONFIG GET dir redis-cli CONFIG GET dbfilename # 查看计划任务 crontab -l ls -la /etc/cron* /var/spool/cron/

重点关注：

异常的键名（如包含backdoor、shell等字样）
持久化路径被修改为非默认位置
出现未知的定时任务

3.2 PostgreSQL服务检查清单

执行以下SQL查询检查可疑对象：

SELECT proname,prosrc FROM pg_proc WHERE proname LIKE '%backdoor%'; SELECT * FROM pg_default_acl WHERE defaclobjtype = 'f'; \df public.*

危险信号包括：

名称可疑的函数
公共执行权限的异常函数
来源不明的存储过程

4. 彻底清除恶意组件的操作指南

4.1 Redis环境修复步骤

立即修改Redis密码：

redis-cli CONFIG SET requirepass "强密码"

重置持久化配置：

redis-cli CONFIG SET dir /var/lib/redis redis-cli CONFIG SET dbfilename dump.rdb

删除恶意键：

redis-cli --scan --pattern '*backdoor*' | xargs redis-cli DEL

检查并清理cron任务：

sudo rm -f /etc/cron*/*malicious* sudo crontab -u root -e

4.2 PostgreSQL环境修复步骤

撤销可疑权限：

REVOKE EXECUTE ON ALL FUNCTIONS IN SCHEMA public FROM public;

删除恶意函数：

DROP FUNCTION IF EXISTS public.backdoor();

检查并清理写入的文件：

sudo find /etc/cron* -name "*malicious*" -delete

修改postgres用户密码：

ALTER USER postgres WITH PASSWORD '强密码';

5. 预防此类攻击的最佳实践

5.1 npm包安全策略

使用npm audit定期扫描依赖：
```
npm audit
```
配置.npmrc禁用自动执行脚本：
```
ignore-scripts=true
```
使用锁定文件确保依赖一致性：
```
npm ci --only=production
```
考虑使用安全替代方案：
- Socket.dev（依赖行为分析）
- npm-force-resolutions（强制依赖版本）

5.2 数据库服务加固建议

Redis安全配置：

# redis.conf关键设置 requirepass 强密码 rename-command CONFIG "" protected-mode yes bind 127.0.0.1

PostgreSQL安全配置：

-- 限制公共权限 REVOKE ALL ON SCHEMA public FROM public; GRANT USAGE ON SCHEMA public TO 特定角色; -- 启用SSL ALTER SYSTEM SET ssl = on;

5.3 开发环境隔离方案

建议采用以下架构隔离关键服务：

开发容器（无生产权限） ↓ 受限访问 数据库容器（强认证） ↓ 独立网络 生产环境

使用Docker的典型配置：

# 开发容器 FROM node:18 RUN npm config set ignore-scripts true # 数据库容器 FROM postgres:15 COPY pg_hba.conf /etc/postgresql/

6. 事件响应与持续监控

6.1 入侵指标(IOC)清单

这些恶意npm包常见的特征包括：

异常的postinstall脚本
依赖项中包含不常见的二进制包
版本号异常跳跃（如从0.0.1直接跳到2.0.0）
维护者信息缺失或可疑

6.2 监控方案实施

建议部署以下监控措施：

文件完整性监控：

# 监控关键目录 sudo apt install aide aideinit

数据库活动审计：

-- PostgreSQL审计配置 ALTER SYSTEM SET log_statement = 'all';

网络流量分析：

# 监控非常规数据库连接 sudo tcpdump -i any port 5432 or port 6379

6.3 应急响应流程

发现入侵后的标准操作流程：

立即断开受影响系统与网络的连接
保存当前状态（内存dump、进程列表）
按照第4节步骤清理恶意组件
轮换所有相关凭证和密钥
从干净环境重建系统
进行根本原因分析并更新防御策略

我在实际安全审计中发现，很多团队在Redis配置上存在严重疏漏。有一次审计中，我们发现开发环境的Redis不仅使用弱密码，而且CONFIG命令未被禁用，这相当于给攻击者敞开了大门。安全无小事，特别是在开发环境中，往往因为"只是临时使用"而忽视了基本的安全措施。

恶意npm包利用Redis与PostgreSQL建立后门的技术分析