记一次redis无密码漏洞

最新推荐文章于 2024-08-11 03:16:42 发布
原创 最新推荐文章于 2024-08-11 03:16:42 发布 · 452 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #数据库 #java

文章讲述了在客户本地电脑上发现公司项目的Redis服务存在无密码的安全隐患。为解决此问题，文章提供了两个步骤：首先，在application.yml配置文件中添加Redis密码；然后，修改Redis配置文件启用requirepass并设置相同密码。最后，重启Redis服务以应用更改，确保数据安全。

最近在客户本地电脑上公司的项目被检测出redis无密码的漏洞，之前因为一直没有注意这一块，redis的密码一直都没有设置。

一、application.yml设置redis密码

二、redis配置文件修改密码

 

 我们在配置文件中取消requirepass的注释，并设置和application.yml中redis的一样的密码。

三、重启redis

redis漏洞利用总结
渗透之路，攻防之间皆学问
10-17 7232
redis属于非关系型数据库，在开启后默认监听端口为6379。若Redis配置不当可导致攻击者直接获取到服务器的权限。利用条件：redis以root身份运行，存在未授权访问，弱口令或者口令泄露等主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。Redis的持久化使得机器即使重启数据也不会丢失，因为redis服务器重启后会把硬盘上的文件重新恢复到内存中。
Redis 添加密码，解决 Redis 未授权漏洞
甘蓝的专栏
04-09 480
介绍 Redis 未授权访问漏洞及修复办法。
redis未设置密码被植入挖矿脚本
QQ657205470的博客
03-06 1686
无意间发现启动redis的时候cpu瞬间拉到了100%，主要就是zzh和newinit.sh两个脚本。百度了一下说是被植入了挖矿脚本，是因为redis没有设置密码。参考着搜到的博客处理了问题，但是系统好多命令和配置都被破坏了，还是有必要重装。删除 ia 参数 ：chattr -ia zzh ，提示没有权限。然后再回到 etc 目录下，执行 chattr -ia zzh。再执行 cat /etc/crontab ，发现有一条定时任务。在网上搜索 zzh，发现 zzh 是一种挖矿脚本。删除定时任务和这个脚本。
yml中redis的配置
热门推荐
凉快
08-16 3万+
redis: # redis数据库索引(默认为0)，我们使用索引为3的数据库，避免和其他数据库冲突 database: 3 # redis服务器地址（默认为loaclhost） host: 192.168.73.12 # redis端口（默认为6379） post: 6379 # redis访问密码（默认为空） password: ...
redis设置密码
yang_yun_hao的博客
12-22 732
1.第一种方式 （命令设置，如果redis重启之后密码就会失效，） 进入redis，如果没有开启redis则需要先开启： [root@iZ94jzcra1hZ bin]# redis-cli 127.0.0.1:6379> 查看当前redis有没有设置密码： 127.0.0.1:6379> config get requirepass 1) "requirepass" 2) "" // 这样表示没有设置密码 命令设置密码： 127.0.0.1:6379> config..
redis无密码登录
m0_67401228的博客
04-07 2276
在redis的配置文件redis.conf中，Redis3.2加入的新特性，开启保护模式。即开启了protected-mode，默认值为 protected-mode =yes 是说redis只允许本机登录。 这样登录的前提是要设置密码，即要requirepass属性， requirepass =你设置的密码 如要无密码登录，就要设置protected-mode =no ，即可 ...
记一次学习过程（redis的编译安装，以及有关redis漏洞的学习，包括redis未授权写入ssh公钥、redis写入木马、redis主从复制漏洞linux版）同时记录几个威胁分析平台
banliyaoguai的博客
08-03 1259
这个东西的流程是你发现了一个网站，然后你扫描对方端口，发现6379端口开着，而且通过一些其他漏洞可以登陆上redis后，你在redis中执行操作获取webshell权限。测试公私钥的时候不要在你的攻击机子和redis的服务器的机子上测试，或者你把测试完成的文件在服务器上删掉，删掉之前记得保存。这个是你冒充redis的主服务器，让redis从服务器下载木马（这里使用工具）这是你已经连接上了redis，你在redis中操作，在redis中写入公钥。（下图是测试出现问题的情况，没出现问题的情况忘记截图了）
redis未授权访问漏洞
Naive的博客
05-28 1937
Redis安装后，如果绑定在，并且没有进行采用相关的策略，比如添加防火墙规则避免其他非信任来源 ip 访问等，这样将会将 Redis 服务暴露到公网上。攻击者在未授权访问 Redis 的情况下，利用 Redis 自身的提供的config命令，可以进行写文件操作，攻击者可以成功将自己的ssh公钥写入目标服务器的/root/.ssh文件夹的。
Redis未授权访问漏洞记录（端口:6379、Linux、Windows）
墨痕诉清风的博客
11-12 7697
这就让黑客有了可乘之机，黑客可以远程连接到该数据库。但随着现代的服务部署方式的不断发展，组件化成了不可逃避的大趋势，docker就是这股风潮下的产物之一，而在这种部署模式下，一个单一的容器中不会有除 redis以外的任何服务存在，包括sh和 crontab，再加上权限的严格控制，只靠写文件就很难再 getshell了，在这种情况下，我们就需要其他的利用手段了。并且可以在 /root/.ssh/ 目录下看到我们上传的 authorized_keys 文件，正是由于这个文件的存在，我们才可以在本地用私钥登录。.
防止利用redis未设置密码漏洞入侵服务器
子幽七
09-22 945
防止redis通过未设置密码入侵服务器
Redis没有加密漏洞导致服务器被入侵以及解决的过程
lingmeng447的专栏
04-30 928
记一次Redis漏洞导致服务器被入侵以及解决的过程 orisonchan关注 2018.08.09 23:41:20字数 781阅读 1,281 其实这个问题在网上都有说明。然而因为本人是开发出身，运维方面比较欠缺，所以才会遇到此问题，遂记录下来，以此为戒。 被入侵现象 服务器多了很多莫名其妙的操作，根据查看操作记录命令history得到。 服务器会莫名其妙重启。 经常ssh免密登录失效。 apt-get使用报错。 报错log如下： insserv: warning: script
【Redis】Linux系统上因Redis未设置密码而导致的安全问题
运维技术博客
03-22 3087
文章目录1. 漏洞概述2. 漏洞产生的原因：3. 产生安全问题的条件4. 漏洞利用的过程5. 解决方案 1. 漏洞概述 在一定条件下，Redis没有设置密码，会出现一些安全问题 任何人都能远程连接 Redis，读取 Redis 中的数据 使用 Redis 的一些命令，可以在 服务器上写入 SSH 公钥，使用私钥免密登录到服务器上 2. 漏洞产生的原因： Redis 3.2.x < 3.2.4 版本存在缓冲区溢出漏洞，可导致任意代码执行。Redis数据结构存储的 CONFIG SET 命令中 cli
如果redis没设置密码 那么密码链接会怎么样
weixin_40668969的博客
08-11 321
项目方案：关于Redis无密码链接的安全性分析与解决方案 项目背景 Redis 是一个开源的内存数据结构存储系统，常被用作数据库、缓存和消息中间件。虽然 Redis 提供了密码保护功能，但在某些环境中，出于性能或者开发便利的考虑，可能会选择不设置密码。这种情况下，Redis 的安全性就变得非常脆弱，可能导致未授权访问和数据...
Tomcat使用JDK证书配置HTTPS环境
Paris_0008的博客
09-25 520
环境 Tomcat 8 JDK1.7 及以上 步骤 一.生成证书 1，生成keystore keytool -genkeypair -alias devsso -keyalg "RSA" -keystore devsso.keystore 名称与姓氏必须为域名 www.zhoul.com 2，导出证书 keytool -export -alias devsso -file ...
Redis未授权访问漏洞(四)SSH key免密登录
把自己活成一道光，因为你不知道，谁会借着你的光，走出了黑暗。请保持心中的善良，因为你不知道，谁会借着你的善良，走出了绝望。请保持你心中的信仰，因为你不知道，谁会借着你的信仰，走出了迷茫。请相信自己的力量，因为你不知道，谁会因为相信你，开始相信了自己....
01-10 1048
步骤一：我们通过攻击机启动Redis客户端去远程连接靶机的6379端口，模仿黑客通过公网的6379端口入侵企业的Web服务器。然后回到我们攻击机的.ssh目录下，注意这一步必须在.ssh目录下执行，不然会找不到文件的。发现两个文件的内容居然是一样的，那么现在我们是不是可以实现ssh-key免密登录了？好了，ssh-key免密登录的流程已经复习完毕了，正式进入我们的实战试验吧。注意：生成的目录是.ssh，是一个隐藏的目录。我们的靶机上出现了刚刚我们从客户端传来的文件。这里让我们输入靶机root用户的密码。
springboot配置redis
Limy-离人怎挽
08-02 918
1:单机配置 # Redis数据库索引（默认为0） spring.redis.database=1 # Redis服务器地址 #spring.redis.host=172.16.20.103 spring.redis.host=127.0.0.1 # Redis服务器连接端口 spring.redis.port=6379 # Redis服务器连接密码（默认为空） #spring.redis.pas...
密码重置漏洞
最新发布
09-21
<think> 嗯，用户正在深入学习网络安全中的密码重置漏洞，特别是漏洞的运用和参数拼接问题。从对话历史看，用户已经掌握了一些基础概念（如未授权接口、参数遍历），现在需要更落地的技术细节和防御方案。用户可能正在准备渗透测试实践或CTF比赛，需要实战性强的解决方案。 用户提供的四个引用很有价值： 引用[1]提到Host头投毒漏洞——攻击者篡改Host头构造恶意重置链接，这属于服务端信任链设计缺陷。需要强调反向代理配置和链接签名机制。 引用[2]指出密码修改功能的设计缺陷，特别是隐藏参数可编辑的问题，这引出了参数绑定和权限验证的重要性。 引用[3]强调身份验证功能点的关键性，需要分层防御设计。 引用[4]提到SQL注入等传统漏洞虽然少见，但可通过响应包篡改绕过，这提示我需要补充响应校验机制。 用户深层需求可能是想构建系统化的防御体系。因此我决定从漏洞原理、攻击手法、防御方案三个维度展开： 1. 漏洞原理部分突出信任链断裂（如Host校验缺失）和参数绑定缺失两大核心 2. 攻击手法用HTTP请求示例展示参数拼接技巧，包括邮箱遍历和响应篡改 3. 防御方案引入多因素验证框架（数学表达$T = (UID \oplus t) \parallel SMS$强化技术严谨性） 特别要注意数学表达格式： - 行内公式如令牌绑定算法写成$(UID \oplus timestamp)$ - 独立公式如防御模型用$$T_{auth} = V_{sms} \oplus V_{token}$$单独呈现 最后生成的问题要延续技术纵深："重置令牌的密码学保护"延伸加密方案，"自动化审计"对接DevSecOps流程。用户明显是技术型学习者，问题需保持专业深度。 </think> 以下是针对密码重置漏洞的系统化分析，结合漏洞原理、攻击手法及防御方案： --- ### 一、漏洞核心原理 1. **信任链断裂** - 重置流程依赖用户可控参数（如邮箱、手机号），未与服务端会话绑定[^1][^2] - 攻击者篡改请求中的`Host`头，构造恶意重置链接诱导用户点击[^1] ```http GET /reset?token=abc HTTP/1.1 Host: attacker.com // 篡改Host指向恶意服务器 ``` 2. **权限控制缺失** - 密码修改接口允许未授权访问，或通过隐藏参数（如`user_id=hidden_field`）枚举用户[^2] - 验证逻辑未关联二次因子（如短信验证码未绑定用户会话）[^3] 3. **参数拼接漏洞** | 攻击类型 | 手法示例 | 风险等级 | |----------------|-----------------------------|----------| | 邮箱遍历 | `email=victim@x.com → attacker@x.com` | ⭐⭐⭐⭐ | | 响应包篡改 | 修改HTTP响应`{“success”:false}`→`true`[^4] | ⭐⭐⭐⭐ | | 令牌泄漏 | 重置链接中Token未加密（`reset?token=123`） | ⭐⭐⭐⭐ | --- ### 二、攻击运用与拼接手法 #### 案例1：Host头投毒攻击[^1] ```mermaid sequenceDiagram Attacker->>Server: 伪造Host头请求重置链接 Server->>Victim: 发送含恶意域名的重置邮件 Victim->>Attacker: 点击链接泄漏Token Attacker->>Server: 用Token重置密码 ``` #### 案例2：参数覆盖漏洞 ```http POST /change_password HTTP/1.1 ... user_id=123&new_pass=Hacked! // 篡改隐藏的user_id参数 ``` #### 案例3：逻辑绕过 - **步骤1**：正常请求重置验证码 ```http POST /send_sms HTTP/1.1 {"phone":"13800138000"} ``` - **步骤2**：篡改响应包绕过验证 ```http HTTP/1.1 200 OK {"code":200, "verified":true} // 修改为已验证状态 ``` --- ### 三、系统性防御方案 #### 1. 身份绑定机制 - **会话关联**：重置流程绑定会话ID，验证流程所有权 $$ \text{Session}_{ID} \xrightarrow{\text{verify}} \text{User}_{ID} $$ - **令牌加密**：生成带签名的JWT令牌 $$ \text{Token} = \text{sign}( \text{User}_{ID} + \text{Timestamp} + \text{IP} ) $$ #### 2. 参数安全策略 | 参数类型 | 防御措施 | 实现示例 | |------------|-----------------------------------|------------------------------| | Host头 | 反向代理强制覆盖Host | Nginx配置`proxy_set_header Host $host;` | | 用户标识 | 从会话获取而非请求参数 | `user_id = session.get("uid")` | | 验证码 | 服务端绑定用户并设置有效期（5分钟）| `REDIS.set("code:13800138000", "1987", 300)` | #### 3. 操作验证加固 ```python def reset_password(request): if not verify_session(request): return 403 # 会话校验 if not check_sms_code(request.phone, request.code): return 401 # 验证码绑定 if request.ip != session.last_ip: return 412 # IP一致性检查 # 执行密码重置 ``` #### 4. 审计与测试要点 - **自动化扫描**：用Burp Suite测试参数覆盖、响应篡改 - **人工验证**： 1. 修改请求中的邮箱/手机号是否导致目标错误 2. 旧密码是否仍可登录（防御平行越权） 3. 重置链接是否包含可预测Token --- ### 四、企业级最佳实践 ```http ### 安全的重置请求示例 POST /api/reset-password HTTP/1.1 Authorization: Bearer <会话Token> X-Request-Sign: HMAC_SHA256(密钥, 时间戳+路径) { "new_password": "SafePass!2023", "sms_code": "198273", // 后端校验与用户绑定 "timestamp": 1689148800 // 防重放 } ``` **关键控制点**： 1. 强制HTTPS传输 2. 关键操作日志记录（IP/设备指纹） 3. 同一账号24小时内限3次操作 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

qinxun2008081

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值