Hello there,
I was trying to find this security vulnerability mentioned on this forum page: Hestia Control Panel 1.9.3 Remote Code Execution - exploit database | Vulners.com.
Unfortunately, I was unable to locate it.
Recently, a few of our servers were hijacked, and the attacker installed Bitcoin mining software. Is this something related ? Has this security issue already been fixed, considering it was just published a few days ago?
Hi @stwn
From what I’ve seen, that “exploit” requires the username and password to access Hestia, and then it only adds a cron job using Hestia’s built-in page for adding user cron jobs. Honestly, I don’t see a vulnerability here, but as I said, my knowledge of this is very limited.
I tried using the exploit and while the login worked, it didn’t create the cron job.
Let’s hope someone with more knowledge can clarify whether this actually needs to be fixed or not.
Yes, since my knowledge is very limited as well, I hope someone here can clarify this issue. Maybe the script can be developed to perform more prohibited actions.
Seems that the “exploit” can only do what the user can, nothing more, nothing less.
No, we have never seen this “vulnerability” before… (Via email / whatever)
I don’t know how we can fix the issue unless we “don’t” allow the user to create cron jobs…
So, can it be considered safe with nothing that needs to be fixed?
I don’t think we should consider it safe but on the other hand I don’t know how we can prevent it with the exception of white listing certain commands.
But if someone is able to login, surely it may not be limited to cron tasks? As you said someone with more idea on this can help.
I have thrown this question in my workplace. Hoping someone can come up with something there.
The login requires the a username / password. So it will be provided to client…
It is the same as giving the user your house address at the same time providing the user the key. Most users won’t steal anything but the might be some users who will do it.
So ISPconfig provides 2 level of cron:
Direct admin:
So idea is implement 3 levels:
I’m not using it, but we do have chrooted shells for users isn´t it? Could we only allow user cronjobs in the (chrooted, if selected) user shell?
Hi everyone,
After reviewing this vulnerability, it seems that it requires valid credentials to log into the HestiaCP web panel before an attacker can create cron jobs. While this isn’t ideal, it doesn’t grant direct unauthorized access.
To mitigate any risk, I would suggest to take the following precaution:
• Enable Two-Factor Authentication (2FA) for HestiaCP web logins for all users (the ones with “administrator” role and the ones with the “user” role), which prevents unauthorized access even if credentials are compromised (link to the HestiaCP documentation on how to do it)
Although it’s not related, I’d strongly suggest to to apply the following additional security measures:
With these measures in place, I’m quite confident that your setup is quite protected.
~Make the rest of your life the best of your life!
Thank you for giving the suggestions
Yes, Point 1. is compulsary.
However, there is an easy method that I use since almost about three decades now. It is indeed including the point 3., i.e. changing to a different SSH port but differs drastically.
On my private side, I use a dynamic public IP address that is mapped to my router domain. That gets updated by my NAS.
On the public side, most of the services are binding to the public domain of my router and port. The bash script will detect the change of Dynamic IP based on the router domain and update inside the firewall, dovecot, etc. because these services are binding to that.
Like this, all admin services will connect to one single IP of my Router.
This is the most secure method, which is more-or-less you suggested but quite different in details.
Of course, it is important that there is a script activated or run by cron to check a change of Dynamic IP of that router domain every xx minutes. I myself have no access, if there is a change of IP and I have to wait until that bash scrfipt will open access through the firewall and I can access all admin services.
Sometimes that did not work. In that case, I need to either restart the VPS from the provider control panel or login through the console and execute that bash script to detent the dyn. IP.
This setup has been active on my oldest server since 1997 on Redhat version 3. Until today, I have never faced any hacking attempt. This is one more reason why I never cared where or if HestiaCP (or earlier VestaCP) was or is buggy because hackers never make to any of the admin area!
Hello Eris!
Well, I have protected HestiaCP login page by an ip binding. So my installation is secured. But it would help everyone, who can use it, to secure HestiaCP and make it 100% safe.
If the login page is protected by the dynamic ip of the admin, then those installations will be 100% secure.
Ofcourse, this applies only to those, who have only one admin. If there are users from different public IPs logging in, that method above will not work.
Can you share the script and steps either here or by dm please?
Hi,
In my comments above, I have described the idea. More than that I cannot share here or by DM.
The reason is there are multiple bash scripts working in a framework and a special environment driven by a system and sh directories. In all these scripts, many variables and detection methods are pulled or refered from the scripts residing in the system directory and only then the frontend executable scripts from the sh directory will function. Plus, all these scripts are meant to run from a bash created menu based on a numbering system.
Like this, there are more than 150 scripts which almost works as a bash panel.
So, I can only pour some ideas here. I cannot share any part of these scripts because I am not interested to share the whole bash panel written by me.
However, there are many scripts written in bash that are available on Github. That will definately serve the purpose, if you want to achieve what I have described above.
I use this script to add a firewall rule (using Hestia’s v-add-firewall-rule) for the current dynamic ip of my connection. Of course, you must have a dynamic DNS service so it is always updated with your current dynamic ip.
Note: the script also removes previous (and now not valid) ip.
#!/usr/bin/env bash
set -euo pipefail
if [[ $EUID -ne 0 ]]; then
echo "Script must be executed as root user" >&2
exit 1
fi
BIN="/usr/local/hestia/bin"
basedir="/var/lib/add_fw_rule_dyn"
host="$1"
port="$2"
iplist="$basedir/${host}_${port}.iplist"
iplist_log="$basedir/${host}_${port}.iplist.log"
cur_ip=""
saved_ip=""
if [[ -z $host || -z $port ]]; then
echo "Usage $0 domainname port"
exit 1
fi
if [[ ! -d $basedir ]]; then mkdir -p "$basedir"; fi
if ! cur_ip="$(dig +short "$host" | tail -n1)"; then
echo "Error resolving domain $host"
exit 2
fi
if [[ -z $cur_ip ]]; then
echo "Error, host $host is not resolving"
exit 3
fi
if [[ -f $iplist ]]; then saved_ip="$(head -n1 "$iplist")"; fi
if [[ "$cur_ip" == "$saved_ip" ]]; then exit; fi
if [[ -n $saved_ip ]]; then
if rulesavedip="$("$BIN"/v-list-firewall plain | sed -E 's/\s{1,}/ /g' | grep -E "\s$port\s$saved_ip\s")"; then
rule_number="$(cut -d ' ' -f1 <<<"$rulesavedip")"
"$BIN"/v-delete-firewall-rule "$rule_number"
fi
fi
if ! "$BIN"/v-list-firewall plain | sed -E 's/\s{1,}/ /g' | grep -E "\s$port\s$cur_ip\s"; then
"$BIN"/v-add-firewall-rule ACCEPT "$cur_ip" "$port" TCP DYN_IP
fi
echo "$cur_ip" >"$iplist"
echo "$(date +'%Y-%m-%d %H:%M:%S') $cur_ip" >>"$iplist_log"
You must run it as:
/path/to/script host port
If the script name is add_fw_rule_dyn, it’s located in /usr/local/bin/, the dynamic host is dyn.example.net and you want to open port 8083 use this
/usr/local/bin/add_fw_rule_dyn dyn.example.net 8083
Note: to allow all ports, use 0 in port argument.
/usr/local/bin/add_fw_rule_dyn dyn.example.net 0
Then just add a cron job for root that will check the current ip every 5 minutes. If the ip is the same, it will do nothing. If the ip changed, it will remove the old firewall rule and will create a new one for the new ip.
*/5 * * * * /usr/local/bin/add_fw_rule_dyn dyn.example.net 8083
thanks SO much for sharing this. I’m looking forward to checking this out.
PS - I THINK that I’m gonna have MULTIPLE DynDNS records
username-ipv4
username-ipv6
Obviously this doesn’t work with IPv6? I’ve got docker containers on Unraid to do the administration of the DynDNS links.
Also if I wanted to whitelist
mywan-IPv4
as well as allowing stuff from
mypartner1-IPv4
and
mypartner2-IPv4
I’d really LOVE to get this working for MULTIPLE dyndns records.
I love dyndns. I can’t get it to work properly on DDWRT, but my new Unraid features, I’m hoping to roll this out to me and a couple of close friends / partners soon.
Thanks