Vulnerability – Exim Exploit – ShellBot RK/CVE-2019-10149
Hey debian-pb users, today i will share with you guys some knowledge about the vuln of exim that happens with versions 4.87 till 4.91 (CVE-2019-10149/Remote command execution). The compromises are hapenning massively known from since day Jun 13 is that what @0xAmit, a security researcher said on twitter, and i was start my audit/investigation more deep a bit about this. So i have the idea to told here what steps i have done on my investigation. Everything happens with the vuln and the help of ShellBot Rootkit on file /lib/libgrubd.so (library bin camo) and this is are implemented by a bash/python script call with nohup under exim vuln (remote command execution), this is an executable/bin that are executed/loaded by all binarys, on the server, take a look below:
================== $ lsof -nP /lib/libgrubd.so COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME init 1 root mem REG 8,4 20600 78480014 /lib/libgrubd.so udevd 1236 root mem REG 8,4 20600 78480014 /lib/libgrubd.so portreser 3393 root mem REG 8,4 20600 78480014 /lib/libgrubd.so irqbalanc 3564 root mem REG 8,4 20600 78480014 /lib/libgrubd.so named 3582 named mem REG 8,4 20600 78480014 /lib/libgrubd.so rpcbind 3629 rpc mem REG 8,4 20600 78480014 /lib/libgrubd.so acpid 3712 root mem REG 8,4 20600 78480014 /lib/libgrubd.so pmqos-sta 3799 root mem REG 8,4 20600 78480014 /lib/libgrubd.so python2.7 3848 root mem REG 8,4 20600 78480014 /lib/libgrubd.so mcelog 4466 root mem REG 8,4 20600 78480014 /lib/libgrubd.so mysqld_sa 4493 root mem REG 8,4 20600 78480014 /lib/libgrubd.so mysqld 4665 mysql mem REG 8,4 20600 78480014 /lib/libgrubd.so abrtd 5474 root mem REG 8,4 20600 78480014 /lib/libgrubd.so abrt-dump 5499 root mem REG 8,4 20600 78480014 /lib/libgrubd.so axond 5535 root mem REG 8,4 20600 78480014 /lib/libgrubd.so wsshdict 6288 imunify360-webshield mem REG 8,4 20600 78480014 /lib/libgrubd.so wsshdict 6292 imunify360-webshield mem REG 8,4 20600 78480014 /lib/libgrubd.so imunify36 6310 root mem REG 8,4 20600 78480014 /lib/libgrubd.so imunify36 6340 root mem REG 8,4 20600 78480014 /lib/libgrubd.so imunify36 6355 root mem REG 8,4 20600 78480014 /lib/libgrubd.so pure-ftpd 6367 root mem REG 8,4 20600 78480014 /lib/libgrubd.so pure-auth 6369 root mem REG 8,4 20600 78480014 /lib/libgrubd.so tuned 6384 root mem REG 8,4 20600 78480014 /lib/libgrubd.so atd 6436 root mem REG 8,4 20600 78480014 /lib/libgrubd.so queueproc 6472 root mem REG 8,4 20600 78480014 /lib/libgrubd.so rhnsd 7805 root mem REG 8,4 20600 78480014 /lib/libgrubd.so puppetd 7978 root mem REG 8,4 20600 78480014 /lib/libgrubd.so collectl 8231 root mem REG 8,4 20600 78480014 /lib/libgrubd.so mingetty 8248 root mem REG 8,4 20600 78480014 /lib/libgrubd.so mingetty 8250 root mem REG 8,4 20600 78480014 /lib/libgrubd.so mingetty 8252 root mem REG 8,4 20600 78480014 /lib/libgrubd.so mingetty 8254 root mem REG 8,4 20600 78480014 /lib/libgrubd.so mingetty 8256 root mem REG 8,4 20600 78480014 /lib/libgrubd.so mingetty 8258 root mem REG 8,4 20600 78480014 /lib/libgrubd.so udevd 8259 root mem REG 8,4 20600 78480014 /lib/libgrubd.so udevd 8260 root mem REG 8,4 20600 78480014 /lib/libgrubd.so imunify36 8822 imunify360-webshield mem REG 8,4 20600 78480014 /lib/libgrubd.so ossec-exe 252739 root mem REG 8,4 20600 78480014 /lib/libgrubd.so ossec-ana 252750 ossec mem REG 8,4 20600 78480014 /lib/libgrubd.so ossec-log 252755 root mem REG 8,4 20600 78480014 /lib/libgrubd.so ossec-sys 252766 root mem REG 8,4 20600 78480014 /lib/libgrubd.so ossec-mon 252772 ossec mem REG 8,4 20600 78480014 /lib/libgrubd.so crond 286686 root mem REG 8,4 20600 78480014 /lib/libgrubd.so mailmanct 518012 mailman mem REG 8,4 20600 78480014 /lib/libgrubd.so p0f 518032 cpanelconnecttrack mem REG 8,4 20600 78480014 /lib/libgrubd.so cpanellog 518047 root mem REG 8,4 20600 78480014 /lib/libgrubd.so proxyexec 714971 root mem REG 8,4 20600 78480014 /lib/libgrubd.so pure-ftpd 983466 root mem REG 8,4 20600 78480014 /lib/libgrubd.so pure-ftpd 983467 root mem REG 8,4 20600 78480014 /lib/libgrubd.so zabbix_ag 1990679 zabbix mem REG 8,4 20600 78480014 /lib/libgrubd.so zabbix_ag 1990680 zabbix mem REG 8,4 20600 78480014 /lib/libgrubd.so zabbix_ag 1990681 zabbix mem REG 8,4 20600 78480014 /lib/libgrubd.so zabbix_ag 1990683 zabbix mem REG 8,4 20600 78480014 /lib/libgrubd.so zabbix_ag 1990684 zabbix mem REG 8,4 20600 78480014 /lib/libgrubd.so zabbix_ag 1990685 zabbix mem REG 8,4 20600 78480014 /lib/libgrubd.so pure-ftpd 2495605 elicomun mem REG 8,4 20600 78480014 /lib/libgrubd.so pure-ftpd 2495606 root mem REG 8,4 20600 78480014 /lib/libgrubd.so pure-ftpd 2499391 elicomun mem REG 8,4 20600 78480014 /lib/libgrubd.so pure-ftpd 2499392 root mem REG 8,4 20600 78480014 /lib/libgrubd.so python2.7 3409468 root mem REG 8,4 20600 78480014 /lib/libgrubd.so python2.7 3409506 root mem REG 8,4 20600 78480014 /lib/libgrubd.so ================== |
I was used lsof for see the opened files with the libgrubd.so with parameter -n (inhibits the conversation of network) and -P (inhibits the
port numbers and replace for names)
This file called $ /lib/libgrubd.so is not normal exists on clean linux servers, cause this library doesn’t exists. In case of this file exists on your server, probably your server was owned/rooted:
========================= [04:56:25 b root@ ~]c# stat /lib/libgrubd.so File: `/lib/libgrubd.so' Size: 20600 Blocks: 48 IO Block: 4096 regular file Device: 804h/2052d Inode: 78480014 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 12/ <strong>mail</strong>) Access: 2019-06-19 07:01:39.000000000 -0300 Modify: 2019-06-19 07:01:39.000000000 -0300 Change: 2019-06-19 07:01:39.000000000 -0300 ========================= |
This bin/executable, is installed with a default, when a new proccess starts, it will be executed always with him attached, and it is not safe, and easily you can have problems, including the fact that you not know what the attacker have done on the system.
Another thing that are a big clue, is that libgrubd.so have the group mail, why? Cause was created by mail user on the RCE(Remote Command Execution), since the attacker was use the vuln of exim, they can catch a validation of exim to execute commands, i have identified and searched, and found they are using scripts bash/python shuffled with base64 with onion/tor/pastebin links calling other scripts inside of the main script:
=============== [root@b ~]# ls -la /lib/libgrubd.so -rwxr-xr-x 1 root mail 20600 Jun 19 07:01 /lib/libgrubd.so =============== |
Using the $ strings command (that permits you see and read some parts of actions from a bin/executable), we will see some details about these actions:
================== [root@b ~]# strings /lib/libgrubd.so __gmon_start__ _init _fini __cxa_finalize _Jv_RegisterClasses syscall_list pam_authenticate strdup pam_get_item strstr strcmp pam_prompt free strlen malloc memset sprintf pam_putenv clean_logz pam_open_session getpwnam getpwnam_r strncpy pam_acct_mgmt libc pam_sm_authenticate pam_get_user dlopen dlsym orig getspnam crypt getenv ttyname lseek fputs fclose write read fgets strcpy ptrace exit snprintf tmpfile sscanf strtoul inet_ntoa atoi fseek libc.so.6 libdl.so.2 libutil.so.1 libpam.so.0 _edata __bss_start _end libgrubd.so GLIBC_2.2.5 LIBPAM_EXTENSION_1.0 LIBPAM_1.0 %z1 %r1 %j1 %b1 %Z1 %R1 %J1 %B1 %:1 %21 %*1 %"1 ATSubH t$PH t$HH t$@H t$8H t$0H t$(H t$ H Password: %s=%s HISTFILE=/dev/null /root /lib64/security/pam_unix.so pam_sm_authenticate getspnam root /var/log/lastlog /dev/host0 root ss2x ================== |
These last lines from stdout from $ strings, will be the most important part of this ShellBot, cause are the actions of binary that is relevant, this rootkit, works on pamd. The pamd are known the guy that made the authentication, working with cryptography, ldap and other things. On this scenario, the bin/executable will do changes on the lib of pam, pam_unix, that lib do many calls on the system for do changes on de user accounts and processes for authentication. This lib (pam_unix) uses informations of /etc/passwd and /etc/shadow, but if you change this native method, you will be capable for scale privileges, and this is what happen here with the help of /etc/ld.so.preload.
This bin, do some actions on enviroments variables(HISTFILE) and clean some traces of their actions on (lastlog).
This customizations maded by the rootkit on pamd, cause alot of problems on the authentication of linux, including with the user root, is something like, broke the linux authentication mode, and everything that needs permissions, and need certain types of permissions, will be broked at this point. Because pamd will cannot validate nothing correctly on passwd and shadow:
================ root@r [~]# crontab -e System error You (root) are not allowed to access to (/usr/bin/crontab) because of pam configuration. ================ |
Here you see the PAM without authenticate nothing on /var/log/secure:
================ Jun 24 10:45:01 server1 crond[22400]: pam_access(crond:account): auth could not identify password for [root] Jun 24 10:45:01 server1 crond[22404]: pam_access(crond:account): auth could not identify password for [admin] Jun 24 10:45:01 server1 crond[22400]: pam_localuser(crond:account): auth could not identify password for [root] Jun 24 10:45:01 server1 crond[22402]: pam_access(crond:account): auth could not identify password for [root] Jun 24 10:45:01 server1 crond[22405]: pam_access(crond:account): auth could not identify password for [admin] Jun 24 10:45:01 server1 crond[22400]: pam_localuser(crond:account): auth could not identify password for [root] ================ |
and on /var/log/cron.log :
================ Jun 24 12:40:01 server1 crond[26129]: (admin) PAM ERROR (Authentication information cannot be recovered) Jun 24 12:40:01 server1 crond[26129]: (admin) FAILED to authorize user with PAM (Authentication information cannot be recovered) Jun 24 12:40:01 server1 crond[26130]: (admin) PAM ERROR (Authentication information cannot be recovered) Jun 24 12:40:01 server1 crond[26130]: (admin) FAILED to authorize user with PAM (Authentication information cannot be recovered) Jun 24 12:40:01 server1 crond[26125]: (root) PAM ERROR (Authentication information cannot be recovered) Jun 24 12:40:01 server1 crond[26125]: (root) FAILED to authorize user with PAM (Authentication information cannot be recovered) Jun 24 12:40:01 server1 crond[26127]: (root) PAM ERROR (Authentication information cannot be recovered) Jun 24 12:40:01 server1 crond[26127]: (root) FAILED to authorize user with PAM (Authentication information cannot be recovered) Jun 24 12:40:01 server1 crond[26131]: (admin) PAM ERROR (Authentication information cannot be recovered) Jun 24 12:40:01 server1 crond[26131]: (admin) FAILED to authorize user with PAM (Authentication information cannot be recovered) ================ |
The pamd will cannot read nothing on passwd and shadow, and the communication of pam will be broked.
I have discovered that libgrubd.so is loaded by ‘/etc/ld.so.preload’ that are basically the ‘bad guy’ here, this file is for custom libs that i want load before of all libs when the system starts, in this case, the libgrubd.so is loaded before of all libs like i have printed above with de $ lsof command , and we catch that guy on the ‘/etc/ld.so.preload’. If you remove him from that file called /etc/ld.so.preload, the issues with pamd will be fixed. Just remove the line that contain ‘/lib/libgrubd.so‘.
root@s [~]# crontab -e System error You (root) are not allowed to access to (/usr/bin/crontab) because of pam configuration. root@s [~]# echo > /etc/ld.so.preload root@s [~]# crontab -e /usr/bin/crontab: no changes made to crontab root@s [~]# service crond status crond (pid 5086) is running... echo "Fixed momentarily the issue with pam/cron/services Only, server is still compromised. Be careful" |
But remember, you dont know what is happened here, you just fixed the issue, but you dont know if the server is secure anymore, asks yourself, what the attacker have done, if him was have root level access? Yes, OS Reinstall is the best bet here.
I have found this main script, and want share how the Remote Command Execution starts analyzing the code, they are using nohup tool, this will prevent that proccess receive a hangup (HUP) , and this is the logic of this attack , cause always will be calling another script inside of another script, like a tree, that attack was called too with the codiname of “The Return of the WIZard” (WIZ and DEBUG was vulns from 90’s that happened with Sendmail (MTA) ):
On the main script, they are telling, about this incursion is happening only for mine, and they not want any data, lol, who can trust on this? 😛
#1) We only Wanna Mine. #2) We don't want your data, or anything or even a ransom. #3) Please if you find this code, don't post about it. #4) We make your security better by breaking it. |
I confess this is the most funniest on this disclaimer “We make your security better by breaking it.”.
Cya / send me an e-mail 🙂 hey@igorlnx.com
Deixe uma resposta