search

myvesta / vesta

myVESTA Control Panel
https://myvestacp.com
GNU General Public License v3.0
266 stars 46 forks source link

Use https when downloading executable scripts, signatures, keys, etc. #78

Open vestacp-user opened 4 years ago

vestacp-user commented 4 years ago

Use https when downloading executable scripts, signatures, keys, etc.

Example:

The documentation at https://github.com/myvesta/vesta/blob/master/README.md suggests running the following: curl -O http://c.myvestacp.com/vst-install-debian.sh Unfortunately, this opens up a whole series of man-in-the-middle attacks during the highly vulnerable install process. The fix is easy since you already have a working certificate, thus it should be replaced with: curl -O https://c.myvestacp.com/vst-install-debian.sh

The same goes for any other downloads during the install, setup, updating or other related processes.

vestacp-user commented 4 years ago

Other examples: vst-install-debian.sh Line 518: echo "deb http://nginx.org/packages/debian/ $codename nginx" > $apt/nginx.list Line 519: wget http://nginx.org/keys/nginx_signing.key -O /tmp/nginx_signing.key Line 523: echo "deb http://$RHOST/$codename/ $codename vesta" > $apt/vesta.list Line 524: wget $CHOST/deb_signing.key -O deb_signing.key Line 533: echo "deb http://archive.debian.org/debian jessie-backports main" Line 1125: wget -nv -O /root/phpmyadmin/pma.sh http://c.myvestacp.com/debian/10/pma/pma.sh Line 1126: wget -nv -O /root/phpmyadmin/create_tables.sql http://c.myvestacp.com/debian/10/pma/create_tables.sql Line 1249: wget -nv -O $clamavfolder/foxhole_all.cdb http://c.myvestacp.com/tools/clamav/foxhole_all.cdb

etc... all make the install process vulnerable to MITM attacks and a very easy to fix simply with https instead of http.

myvesta commented 4 years ago

I agree, I will fix that in some future releases.

However, it has very small chance to happen, we have just 360 active installations... we are just on begining... who will target this... it is just theoretical situation for now. However, will be fixed.

Plus, I will reduce commands that uses wget/curl, better to put those files in .deb packages, because it has additional layer of protection because packages are signed by GPG key.

vestacp-user commented 4 years ago

Agreed, extremely small and very specific window for attack, only during the install process if the attacker can get in between the installer and the http:// server (eg, Cloud Providers, Network Operators, Compromised WiFi, Public WiFi, Internet Providers, etc.)

Does not affect any existing installations (unless it was previously compromised during install).

myvesta commented 4 years ago

Before 2 years, vestacp.com server is compromised twice. Hopefuly, I used installer downloaded from github, and thanks to that I avoided malicious code. That is the moment when I decided to make my own apt repo and other server resources (c.myvestacp.com etc...) On that machine I have only nginx installed (and SSH with ssh-key auth). No PHP, no MySQL, no Exim, literally nothing except nginx and SSH. Plus IP is hidden via CloudFlare. So pretty better security than on official vestacp.com.

Wiki, forum and myvestacp.com site are on totally separated server.

vestacp-user commented 4 years ago

On a different topic of this issue, but related to your comment of having a hidden IP and since I saw that you have a way to make a hidden link to the Control Panel, you might be interested in using hidden tor onion sevices instead. Install tor, create hidden onion services for sshd port 22 and another for port 8083 vestacp, then you can completely firewall off the server for these ports. Even portscanners will never be able to find your sshd or vestacp, never mind even getting to brute force password attacks. You are also protected against compromised at CloudFare, which is one of your risks with the CloudFare hidden IP). Obviously, make sure you have alternate access to the server if something goes wrong!

Examples: torify ssh root@sadf237uin8case...as3d.onion Tor Browser: https://cn2ue73d...23dh4.onion:8083

You can also use apt-transport-tor (see section "Using Tor with Apt") https://wiki.debian.org/SourcesList

This futher protects your servers against DNS based attacks and also completely hides what software is installed by making it impossible to know what repo packages your server is checking and downloading. /etc/apt/sources.list: deb-src tor://sgvtcaew4bxjd7ln.onion/debian-security stretch/updates main

Keep in mind that tor will be alot slower, but usually doesn't really matter.

vestacp-user commented 4 years ago

For the https issue, see my last comment on this issue, since it is almost the same for myVestaCP. https://github.com/hestiacp/hestiacp/issues/949

There needs to be more dicipline in key downloads sources and repos to avoid a variety of MITM compromises, delayed security updates and increased attack surface when unnecessarily using the most recent versions of packages.

kpapad904 commented 4 years ago

I discussed this particular issue in https://github.com/hestiacp/hestiacp/issues/695 back in Feb-2020 and also offered code diffs, depending on whether the project would prefer to download the signing keys from a URL (preferrably over https) or from a keyserver.