I think there is a very serious security vulnerability in CWP right now.

CWP should handle the basics. The default installation is several versions behind the current ones.

While we can do manual updates, if CWP later updates its default version, it can break things because we are no longer running a default CWP installation.

If we all agree that the default installation is several versions behind and that manually upgrading core components can create compatibility issues later, then the obvious question is:

What is the solution?

Continuing to rely on manual upgrades after every fresh installation is not really a solution, especially for those of us managing multiple VPSs and production environments.

Is there a plan to update the installation script and the default software stack?

Is there a roadmap for bringing the default installation in line with current stable versions of MariaDB, Apache, Nginx, phpMyAdmin, Roundcube and PHP?

Because from an administrator's perspective, a fresh installation should already provide a modern and secure baseline instead of requiring immediate post-installation upgrades and forum-based workarounds.

Guys,

I had these problems with an eval($_POST['shell']) type attack in the logs, in the admin area, two years ago (Jun/07/2024).
It was saving an error.php file in an area restricted to the admin, and running it.
In other words, somehow CWP was allowing files to be saved in the admin's restricted area.
I informed the CWP team, but I haven't received any feedback, and I don't know if it was resolved or not.

So, I proposed a temporary solution of restricting access to the admin area with the nginx server password, because the 'cwpsrv' process is actually 'nginx'.

This attack is very similar to the one that happened two years ago, so I have reason to believe that this attack is related to the attack from that time.
But since then, after restricting the admin area, I haven't had any more problems of this type.
So, if you are having problems even after updating to the new version of CWP, and have still suffered attacks, I recommend that you restrict the admin area with the nginx password.

You and your users will still be able to use CWP, as long as you have the specified password.

This doesn't solve the problem, but it brings much more peace of mind to day-to-day use until there is time to discover and fix the real problem.

To restrict the admin area, run this script:

Code: [Select]

if [[ ! -e /usr/local/cwpsrv/conf/include/security.conf ]]; then
read -p "Install additional authentication layer to CWP? (Y/n): " -r
echo    # (optional) move to a new line
if [[ $REPLY =~ ^[Ss]$ ]]; then
# To create additional password to use cwpsrv
# It will work on the block ports 2031 e 2087:
# Replace XY.XW.XZ.XX with any IP address if you want restrict a IP adresses, or delete 'allow' lines
# Creating the file /usr/local/cwpsrv/conf/include/security.conf with the following content:
echo "Creating additional authentication layer to cwpsrv..."
IP_REMOTO_ATUAL=$(w -i| grep root | cut -d' ' -f10| head -1)
cat << EOT > /usr/local/cwpsrv/conf/include/security.conf
satisfy any;
allow XY.XW.XZ.XX;
allow 127.0.0.1;
deny  all;
auth_basic    "Protected site";
auth_basic_user_file /usr/local/cwpsrv/conf/htpasswd;
EOT

echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "!!!! Now creating the password to additional authentication layer to CWP server !!!!"
echo "                      ( You can choose any password you want )"
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "root:"$(openssl passwd -apr1) > /usr/local/cwpsrv/conf/htpasswd
if [[ $? -eq 0 ]]; then
echo "Password sucessfully configured!"
else
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "!!!!!!!!!!!!!!!!!!!!!!.....ALERT.......!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
echo "There was some problem, and was not possible to configure the password, you must verify the problem!"
fi
echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
fi
fi
read -p "Press [enter] to restart cwpsrv"
/scripts/restart_cwpsrv

You can choose any password you want, but choose wisely.

Regards,
Netino

To delete the .ssh folders under each user's /home directory

for d in /home/*/.ssh; do
    if [ -d "$d" ]; then
        chattr -R -ia "$d" 2>/dev/null
        rm -rf "$d"
        echo "removed: $d"
    fi
done

and this is clean.sh

#!/bin/bash

# home
TARGET_DIR="/home"

# Malware string which we are looking for
MALWARE_STRING='eval(base64_decode("aW5pX3NldCgiZGlzcGxheV9lcnJvcnMiLCAwKTs'

echo "starting..."
echo "scanning: $TARGET_DIR"
echo "wait..."
echo "------------------------------------------------"


find "$TARGET_DIR" -type f -name "*.php" | while read -r file; do

    # check for malware
    if grep -qF "$MALWARE_STRING" "$file"; then
        echo "[!] code is detected: $file"

        # removing
        sed -i "/eval(base64_decode(\"aW5pX3NldCgiZGlzcGxheV9lcnJvcnMiLCAwKTs/d" "$file"

    fi
done

echo "------------------------------------------------"
echo "done."

chmod 755 clean.sh then start. At least it will help you clean up

My server was recently compromised, and many websites hosted on it had their index.php files injected with malicious code similar to:

eval(base64_decode("aW5pX3NldCgiZGlzcGxheV9lcnJv..."));

I also found unauthorized SSH keys added to authorized_keys files and several suspicious files such as defauit.php across different accounts.

I have cleaned the infections multiple times, removed the malicious files, changed passwords, and scanned the server, but the infection keeps returning approximately every 30 minutes.

What I've observed is that the reinfection process appears to run for about 2-3 minutes. During that time, if I clean the infected files, they are immediately reinfected. Outside of that window, there is usually a delay of around 30 minutes before the files are modified again.

So far, I have been unable to identify the root cause or the process responsible for the reinfection. There are no obvious cron jobs, and the malware continues to reappear after cleanup.

Has anyone dealt with a similar compromise or persistent reinfection on a CWP/CentOS server? Any advice on how to trace the source of the reinfection, identify the responsible process, or locate hidden backdoors would be greatly appreciated.

I ran into the same issues, but unfortunately, I couldn’t find a solution. The hacker had literally taken over the server. Even though sshd, FTP, Apache, and Nginx were disabled, .ssh folders were being created every time, and code was being injected. Unfortunately, the only solution I found was to switch to a different control panel.

I found an entry point and an the privilage escalation that is currently atacking my servers. Should I post it here?

I think any kind of information can be useful to us.

Well, this is so bad that I feel uncomfortable that share it now publicly when there is no fix.

But I can say this:
BLOCK THIS IP NOW!!!! 152.53.173.29 that is the C&C server.

EDIT: Where can I send a message to an dev?

@ideal:

Code: [Select]


systemctl list-unit-files --type=service --state=enabled

İf you see "defunct.service" in list:
systemctl stop defunct.service
systemctl disable defunct.service
cat /usr/lib/systemd/system/defunct.service (You can see: '/usr/bin/defunct'")
rm -f /usr/lib/systemd/system/defunct.service
systemctl daemon-reload
rm -f /usr/bin/defunct

Yo can kill it :)

After:
search .ssh dirs
delete all .ssh dirs

example for root/.ssh:
sudo chattr -R -i /root/.ssh

check /home dir if this dirs exists: (login chromeuser) delete:
sudo chattr -R -i /home/login
sudo chattr -R -i /home/chromeuser
rm -rf /home/login
rm -rf /home/chromeuser

Search files for infaction codes and clear all

I think this security issue cause of Roundcube version: 1.4.14



Well, this is so bad that I feel uncomfortable that share it now publicly when there is no fix.

But I can say this:
BLOCK THIS IP NOW!!!! 152.53.173.29 that is the C&C server.

EDIT: Where can I send a message to an dev?

This is a Netcup IP, and they are very good at suspending service of hackers on their network.

You can send the hacker info to: abuse@netcup.de

Pleases update cwp sh /scripts/update_cwp

Well, this is so bad that I feel uncomfortable that share it now publicly when there is no fix.

But I can say this:
BLOCK THIS IP NOW!!!! 152.53.173.29 that is the C&C server.

EDIT: Where can I send a message to an dev?

This is a Netcup IP, and they are very good at suspending service of hackers on their network.

You can send the hacker info to: abuse@netcup.de

Great, I send them a mail aswel.


89.248.172.118 is also good to block, it gave the original payload, but it's apparently an IP from an 'bulletproof hoster'.

Pleases update cwp sh /scripts/update_cwp

0.9.8.1235 that is fast!

to resolve hackers issues just update cwp with this script, run the script two times.
This will also be resolved by cwp update automatically so even if you don't run the script it will be updated in 24h.

Code: [Select]

/scripts/update_cwp

Our server was also one of the victims of this issue.

For safety reasons, we are dumping this server and moving to a new server now because we can't make sure how comprimised the server is while attacker has root access for days.

I wanted to share my way of dealing with it but forum is rejecting some  parts of my post (probably because of mod_security). Let me know if there is another way to share it with everyone:

Code: [Select]

#check if there is someone connected to your server except you:

netstat -antp | grep -E "ESTABLISHED|LISTEN"

#if yes, kill its process and ban the ip
kill [PID]

=============================
#Then Hunt for the signature:

grep -R "/usr/bin/defunct\|mm_percpu_wq" /etc /root /var/spool/cron /usr/local/cwpsrv /usr/local/apache 2>/dev/null > /root/defunct-references-small.log

# You are likely to see this line:

/etc/systemd/system/multi-user.target.wants/defunct.service
ExecStart=/bin/bash -c "GS_ARGS='-k /lib/systemd/system/defunct.dat -ilq' exec -a '[mm_percpu_wq]' '/usr/bin/defunct'"

#Kill it:

systemctl stop defunct.service
systemctl disable defunct.service
rm -f /etc/systemd/system/multi-user.target.wants/defunct.service
rm -f /usr/bin/defunct
rm -f /lib/systemd/system/defunct.dat
systemctl daemon-reload

#recheck:

systemctl status defunct.service
ps aux | grep '[m]m_percpu'
find /etc/systemd /lib/systemd -name '*defunct*' -o -name '*mm_percpu*' 2>/dev/null


#Then go for the injected SSH keys:

find / -path '*/.ssh*' 2>/dev/null

#remove all ssh keys except root:

find / -path '*/.ssh/authorized_keys*' -type f ! -path '/root/.ssh/authorized_keys' -print0 2>/dev/null | while IFS= read -r -d '' f; do
  chattr -i "$f" 2>/dev/null
  rm -f "$f"
done

# remove all ssh directories except root:

find / -path '*/.ssh' -type d ! -path '/root/.ssh' -print0 2>/dev/null | while IFS= read -r -d '' d; do
  chattr -i "$d"/* 2>/dev/null
  rm -rf "$d"
done

# own root ssh back:

chown root:root /root/.ssh
chmod 700 /root/.ssh
chattr -i /root/.ssh/authorized_keys

# edit root ssh:
nano /root/.ssh/authorized_keys

# remove all injected lines with CTRL+K and save it with CTRL + X

(if you don't have a SSH key yourself for root, remove that authorized_keys file too rm -f /root/.ssh/authorized_keys )


#now deal with injected php files under public_html

#find injections:
grep -RIl --include='*.php' 'aW5pX3NldCgiZGlzcGxheV9lcnJvcnMi' /home


<forum didn't allow me to post clean line due to mod_security>

#check if its cleaned now:

grep -RIl --include='*.php' 'aW5pX3NldCgiZGlzcGxheV9lcnJvcnMi' /home


#check injected .html / .json / .htaccess files:

<forum didn't allow me to post this line due to mod_security>

#remove injection:

<forum didn't allow me to post this line due to mod_security>

change your root password just in case