V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
timeromantic
V2EX  ›  程序员

我是 printf520 提供今日热榜 API 的博主, Redis 感染了自动化挖矿蠕虫。目前已经修复

  •  
  •   timeromantic · 2019-07-19 12:16:56 +08:00 · 8879 次点击
    这是一个创建于 1953 天前的主题,其中的信息可能已经有所发展或是发生改变。

    首先谢谢发帖告知我 API 感染挖矿病毒的 V 友。 @zpfhbyx

    事情围观: https://www.v2ex.com/t/584216#reply23 api 文档: https://www.v2ex.com/t/578957#reply6 微信截图_20190719120326.png

    目前已经做了修复处理

    感染原因如下:

    Redis 默认情况下,会绑定在 0.0.0.0:6379,在没有利用防火墙进行屏蔽的情况下,将会将 Redis 服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。攻击者在未授权访问 Redis 的情况下利用 Redis 的相关方法,可以成功将自己的公钥写入目标服务器的 ~/.ssh 文件夹的 authotrized_keys 文件中,进而可以直接登录目标服务器;如果 Redis 服务是以 root 权限启动,可以利用该问题直接获得服务器 root 权限。

    经过对捕获的事件进行分析,整个入侵流程大概是包含以下几个环节:

    • 扫描开放 6379 端口的 Linux 服务器(后续感染扫描网段为 1.0.0.0/16 到 224.255.0.0/16 )
    • 通过 redis-cli 尝试连接 Redis 并执行预置在.dat 文件里的利用命令将 Redis 的数据文件修改为 /var/spool/cron/root,然后通过在 Redis 中插入数据,将下载执行脚本的动作写入 crontab 任务
    • 通过脚本实现以上的相关行为,完成植入并启动挖矿程序

    Redis 服务加固

    • 导致入侵的主要原因是 Redis 未授权访问问题,所以如果要扼制入侵的入口,需要针对 Redis 服务进行加固,避免黑客通过该途径进行入侵植入挖矿蠕虫。
    • 如无必要,修改 bind 项,不要将 Redis 绑定在 0.0.0.0 上,避免 Redis 服务开放在外网,可以通过 iptables 或者腾讯云用户可以通过安全组限制访问来源
    • 在不影响业务的情况,不要以 root 启动 Redis 服务,同时建议修改默认的 6379 端口,大部分针对 Redis 未授权问题的入侵都是针对默认端口进行的
    • 配置 AUTH,增加密码校验,这样即使开放在公网上,如果非弱口令的情况,黑客也无法访问 Redis 服务进行相关操作
    • 使用 rename-command CONFIG "RENAME_CONFIG"重命名相关命令,这样黑客即使在连接上未授权问题的 Redis 服务,在不知道命令的情况下只能获取相关数据,而无法进一步利用
    第 1 条附言  ·  2019-07-19 20:45:24 +08:00
    统一解释一下

    调用我的 API 的 V 友们,我这里返回的 sort 值对于 JavaScript 来说,只是一个 json 的 string,对你们来说无任何影响。
    52 条回复    2019-07-21 01:25:30 +08:00
    timeromantic
        1
    timeromantic  
    OP
       2019-07-19 12:32:52 +08:00
    @zpfhbyx 谢谢告知
    ResetTrap
        2
    ResetTrap  
       2019-07-19 12:57:25 +08:00   ❤️ 4
    redis 不是默认 127.0.0.1:6379 吗
    cmlanche
        3
    cmlanche  
       2019-07-19 13:00:24 +08:00
    我的站的 redis 也被入侵了,开防火墙,重启下服务器就好了
    IsaacYoung
        4
    IsaacYoung  
       2019-07-19 13:05:34 +08:00 via iPhone
    🐂🍺
    shmilypeter
        5
    shmilypeter  
       2019-07-19 13:06:25 +08:00
    谢谢告知,我打算好好研究下你的项目
    timeromantic
        6
    timeromantic  
    OP
       2019-07-19 13:06:37 +08:00 via Android
    @cmlanche 嗯,是的,已经做了相关的处理
    timeromantic
        7
    timeromantic  
    OP
       2019-07-19 13:07:47 +08:00 via Android
    @ResetTrap 127.0.0.1 只是你本地地址
    laoyur
        8
    laoyur  
       2019-07-19 13:09:16 +08:00   ❤️ 2
    redis 漏洞都爆出多久了
    nihaoaa
        9
    nihaoaa  
       2019-07-19 13:10:04 +08:00
    学到了
    ResetTrap
        10
    ResetTrap  
       2019-07-19 13:13:12 +08:00   ❤️ 1
    @timeromantic #7 与此无关,redis 的默认配置是监听 127.0.0.1,除了本机是不能连接的,你肯定是把配置文件改成 0.0.0.0 了
    1iuh
        11
    1iuh  
       2019-07-19 13:18:04 +08:00
    什么时候被入侵,持续时间多久,期间 API 被调用多少次不披露一下么?
    chenqh
        12
    chenqh  
       2019-07-19 13:20:25 +08:00
    这种端口默认不是不开启的吗,在安全组那里
    timeromantic
        13
    timeromantic  
    OP
       2019-07-19 13:22:12 +08:00 via Android
    @1iuh 昨天下午入侵的,持续时间为零,redis 跑在 docker 没有影响到主机
    1iuh
        14
    1iuh  
       2019-07-19 13:22:30 +08:00
    另外,为什么你服务器被挂的挖矿程序会影响你 API 的返回数据?
    timeromantic
        15
    timeromantic  
    OP
       2019-07-19 13:26:09 +08:00 via Android
    api 返回的 sort 值是 redis 存的知乎点击量,病毒是把知乎的 key 设置成他的挖矿脚本了。我获取 sort 就带出来了
    timeromantic
        16
    timeromantic  
    OP
       2019-07-19 13:27:02 +08:00 via Android
    @1iuh api 返回的 sort 值是 redis 存的知乎点击量,病毒是把知乎的 key 设置成他的挖矿脚本了。我获取 sort 就带出来了
    RicardoY
        17
    RicardoY  
       2019-07-19 13:27:28 +08:00
    redis 默认情况下绑在 127.0.0.1 的呀
    timeromantic
        18
    timeromantic  
    OP
       2019-07-19 13:28:24 +08:00 via Android
    @RicardoY 跑在 redis 里面的一个容器,外网能访问到
    @ResetTrap
    ResetTrap
        19
    ResetTrap  
       2019-07-19 13:29:51 +08:00
    @timeromantic #18 那就是你操作问题了,相当于 0.0.0.0 了,这种方式很不推荐的
    timeromantic
        20
    timeromantic  
    OP
       2019-07-19 13:32:07 +08:00 via Android
    @RicardoY redis 是跑在 docker 里面的一个容器,外网能访问到
    @ResetTrap
    wh1012023498
        21
    wh1012023498  
       2019-07-19 13:32:21 +08:00
    = = 这个 redis 安全问题。。不是早就暴露了吗。。
    kzfile
        22
    kzfile  
       2019-07-19 13:33:00 +08:00
    我的也入侵了,结果因为是 windows 系统,挖矿脚本没跑起来
    1iuh
        23
    1iuh  
       2019-07-19 13:34:10 +08:00
    据我所知,利用 redis 未授权漏洞是需要 flushall 的, 而且我想不到为什么还能只替换你知乎的 key。依据的你的描述来看,只是被脚本扫到了, 不是针对你的攻击。
    另外你说持续时间为 0 这个我也无法认同,都有 V 友调用你接口发现问题了,怎么会持续时间为 0。
    timeromantic
        24
    timeromantic  
    OP
       2019-07-19 13:37:09 +08:00 via Android
    @1iuh 我说的持续时间为零是指的。他的脚本并未成功在我服务器上面挖矿,跑在 docker 容器。不过入侵我的 redis 倒是有一段时间。调用我 api 的朋友是不受影响的
    timeromantic
        25
    timeromantic  
    OP
       2019-07-19 13:37:57 +08:00 via Android
    @wh1012023498 老哥,又见到了你了,因为头像记得你
    zpfhbyx
        26
    zpfhbyx  
       2019-07-19 13:57:30 +08:00
    ScepterZ
        27
    ScepterZ  
       2019-07-19 14:20:15 +08:00
    解决方法呢,有办法不让 docker 绑定 0.0.0.0 吗
    realpg
        28
    realpg  
       2019-07-19 14:21:30 +08:00
    @RicardoY #17
    ubuntu 的软件包是的

    CENTOS 表示我们从来都是 0.0.0.0
    ScepterZ
        29
    ScepterZ  
       2019-07-19 14:23:16 +08:00
    查了一下,docker run -p 127.0.0.1:6379:6379 就行了
    fuxkcsdn
        30
    fuxkcsdn  
       2019-07-19 16:34:43 +08:00
    容器运行默认都只绑定在 127.0.0.1 上
    除非你启动容器时用 -P 或者 -p 6379:6379
    根据你的描述应该是后者
    fuxkcsdn
        31
    fuxkcsdn  
       2019-07-19 16:35:49 +08:00
    上面打错了
    -p 6379:6379 也只会绑定在 127.0.0.1 上,应该是 -p 0.0.0.0:6379:6379
    x66
        32
    x66  
       2019-07-19 16:42:37 +08:00
    不懂就问:
    1. 为什么是 cur ?而不是 curl ?
    2. 什么情况下请求者会受到这个 json 中的命令攻击?
    bin20060407
        33
    bin20060407  
       2019-07-19 16:45:50 +08:00
    Redis 表示这锅我不背,默认是绑在 127.0.0.1 的
    mangoDB
        34
    mangoDB  
       2019-07-19 19:14:22 +08:00
    借楼学习一下,那个挖矿脚本如何会被触发呢?
    难道需要好奇心比较重的用户,手动执行吗?
    cuixiao603
        35
    cuixiao603  
       2019-07-19 20:22:19 +08:00
    同好奇如何触发
    Trim21
        36
    Trim21  
       2019-07-19 20:27:34 +08:00 via Android
    为啥这个 sort 会让 Redis 被入侵,有没有大佬解释一下…
    scnace
        37
    scnace  
       2019-07-19 20:51:28 +08:00 via Android
    @cuixiao603 @mangoDB 触发应该是通过把 redis 的 dir 和 dbnamefile 指向 /etc/crontab 然后把这个 value 写入到 crontab 里面(但是好像 curl 拼错了?

    LZ 能看下自己的 crontab 列表确认下吗?难道是写完之后又改回去了?
    scnace
        38
    scnace  
       2019-07-19 20:53:05 +08:00 via Android
    @scnace typo : dbnamefile => dbfilename
    sampeng
        39
    sampeng  
       2019-07-19 23:35:49 +08:00 via iPhone
    这个史前时代的问题…你居然把 redis 扔公网上。佩服佩服…
    JasperWong
        40
    JasperWong  
       2019-07-20 00:32:19 +08:00
    我也中过这个
    Hopetree
        41
    Hopetree  
       2019-07-20 00:53:44 +08:00
    我服务器的端口连 MySQL 的都不开,redis 的更不开,要用的时候可以开一下用一下,感觉挺方便啊
    ericgui
        42
    ericgui  
       2019-07-20 01:16:28 +08:00
    @cmlanche 使用密码链接 redis 也会导致被黑吗?
    Kinnice
        43
    Kinnice  
       2019-07-20 01:28:52 +08:00 via Android
    @1iuh 调用他 API 的用户应该在 json 解析那一步就会报错了,应该影响不到安全问题,好奇心手动执行除外。
    Kinnice
        44
    Kinnice  
       2019-07-20 01:30:26 +08:00 via Android
    @Kinnice 这里的报错指这个数据本来应该是一个数的,而这里变成了一个链接
    imycc
        45
    imycc  
       2019-07-20 05:05:48 +08:00
    @fuxkcsdn
    -p 6379:6379 是将容器的 6379 映射到主机上
    容器本身是监听了容器自己的 127.0.0.1 的(假设,我没注意过),但是映射到主机上时如果没有指定 host ip,就相当于在主机外网的 6379 端口上开了个 redis 服务。
    imycc
        46
    imycc  
       2019-07-20 05:08:44 +08:00   ❤️ 1
    使用 docker 或者使用 docker-compose,`-p`跟`--ports`如果没有必要就不要随便用~

    只暴露那些需要外部访问的即可,同个机器上的调用可以用 link 来做。
    如果需要暴露端口,有机房内网的话最好只是开在内网上。开到外网的话注意加上白名单。
    bghtyu
        47
    bghtyu  
       2019-07-20 08:46:49 +08:00 via Android   ❤️ 1
    docker 的 -p 如果直接 6379:6379 是会默认绑定 0.0.0.0 的,而且还会自动打开防火墙的这个端口,不注意很容易被坑的,必须要-p 127.0.0.0:6379:6379 这样用才行
    tailf
        48
    tailf  
       2019-07-20 10:14:01 +08:00
    这不是 redis 漏洞,是楼主不会做运维
    lozzow
        49
    lozzow  
       2019-07-20 10:30:29 +08:00 via iPhone
    @kzfile 咋感觉在黑巨硬呢🌚
    timeromantic
        50
    timeromantic  
    OP
       2019-07-20 11:48:03 +08:00 via Android
    @tailf 哈哈,开发还是要多掌握一点运维的知识
    opengps
        51
    opengps  
       2019-07-20 18:55:55 +08:00
    开发人员很多都不懂安全防御,不具备运维能力。
    楼主能分析故障复盘原理已经是大佬了,能公开分析过程的更值得佩服,留名点赞!
    timeromantic
        52
    timeromantic  
    OP
       2019-07-21 01:25:30 +08:00
    @opengps 哈哈。谢谢理解
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5298 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 52ms · UTC 08:11 · PVG 16:11 · LAX 00:11 · JFK 03:11
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.