TAKING A LOOK AROUND
On one of my domains, the host is offering CLI access as part of their hosting plan. What could be possible go wrong with giving SSH access to the customers? Apparently a lot of things.
He Who Cannot Be Named
To avoid privacy issues, the real hosting name won't be revealed, I'll be using the fictional name Foobar Hosting.
Foobar Hosting™ allows his customers to have SSH access to the server: honestly, this is a very handy feature since from time to time I have to run CLI commands or handle large files, something that you can't do from a web interface.
However, I was curious to test how secure would be such environment, where regular users have access to the system and I found several issues, spanning from bad, to terrible bad.
First of all there's no chroot jail: I was able to wander around and analyse all the files I had access to. Personally, I think this is a bad practice, since the whole sicurity is delegated to file permissions. If there's any flaw in the permissions, an attacker could have access to some private files, with terrible consequences.
The very bad
Looking at the database, it seems that the installed version is quite old and vulnerable to a powerful exploit (CVE-2016-6662):
At this link you can find the whole explanation of the exploit; without going too much into the details, it means that you escalate your current user to root using MySQL.
This requires to mess around with configuration files and force the database service to restart. That's something I'm not comfortable to do in a production environment, so I didn't actually tested it; but I can assume the server is vulnerable and any careless attacker would try to run it without second thoughts.
The very, very bad
The best way to guess a password is to find its plaintext somewhere, usually in the log files.
find /var/log -name '*.log' 2>/dev/null | xargs -l10 egrep 'pwd|password' 2>/dev/null
Usually this command returns a lot of noise, since you can find entries such as Remember to change your password, Password required, however sometimes it's worth the time spent.
Like in this case.
## REPORT_START Welcome to DirectAdmin verion 1.49.1! You are now about to run the install program. If DirectAdmin is already installed, it may destroy previous data. Here is the information given: Admin user: [REDACTED] Admin email: [REDACTED] Server IP: [REDACTED] Server IP Netmask: 255.255.255.0 Server Hostname: [REDACTED] Name Servers: [REDACTED] options.conf exists, not installing the httpd.conf. Relying on custombuild. Backup of /etc/proftpd.conf to /etc/proftpd.conf.back successfull ## INSTALL_COMPLETE ## ACCOUNT_INFO The following information has been set: Admin username: [REDACTED] Admin password: [REDACTED] Admin email: [REDACTED] Server IP: [REDACTED] Server Hostname: [REDACTED] To login now, follow this link: [REDACTED] and enter your Admin username and password when prompted. ## REPORT_END
It seems the log file of a DirectAdmin installation. Even if the owner was root, the file was publicy accessible. Let's try that credentials:
Ehm... it seems they're still valid...
This is not as bad as becoming root using some kind of privilege escalation, but for an hosting company it's almost the same. With a single click of the mouse I could delete customer sites or configure the DNS to something different.
The terribly bad
What could be even worse to act and manage customers web space? Just wait for it.
mount command revealed some interesting stuff:
It seems we have a mounted filesystem on
/srv/repo, that I was able to freely access (too bad a forgot to get a screenshot of it :( ). Inside that folder there were several scripts and a couple of repositories, an attacker could create a symlink to his own webspace and then download everything.
Anyway, I now have the IP address of an intersting internal target, maybe there's a way to fetch more info?
Spoiler alert: yes, there is.
Let me introduce you my friends NMAP, ProxyChains and SOCKS
The best way to inspect a target is to use nmap, however we have a problem: the target is no publicy accessible.
That's not a problem, ProxyChains and Dynamic Tunnel to the rescue!
From your current machine we have to create a dynamic tunnel using the SSH access:
ssh -D 1080 username@target
Then use proxychains to tunnel nmap requests to our local port to the remote server and finally to the internal target:
proxychains nmap -vvv -sT -A -T2 10.0.9.29
Remember to change your proxychains configuration to use the new port you just opened.
Nmap found a several open ports, the most important is the number 2000:
2000/tcp open ssl/http syn-ack CherryPy httpd 2.3.0 |_http-favicon: Unknown favicon MD5: CF4EA8739B06B3E562B5D1700C65D328 | http-methods: |_ Supported Methods: GET HEAD POST OPTIONS |_http-server-header: CherryPy/2.3.0 |_http-title: Did not follow redirect to https://10.0.9.29/status/general/ | ssl-cert: Subject: commonName=nmv.nexenta.com/organizationName=Nexenta Systems Inc/stateOrProvinceName=California/countryName=US/organizationalUnitName=Storage Technology/emailAddressfirstname.lastname@example.org/localityName=Cupertino | Issuer: commonName=nmv.nexenta.com/organizationName=Nexenta Systems Inc/stateOrProvinceName=California/countryName=US/organizationalUnitName=Storage Technology/emailAddressemail@example.com/localityName=Cupertino
Nexenta is a software for datacenters dedicated to storage of large quantities, most likely backups.
A quick search online revelead that there are default access details. I tried with the admin and root account: no luck.
What about the guest user?
...and I'm in.
At first glance, it seems this is a NAS for internal usage; I could explore more, but my inner daemon started yelling to stop. Enough issues were found, so I reported everything to the hosting.
While working on this server, it reminded me about Offensive Security virtual labs: misconfigured environments are a reality and are very dangerous.
You don't need any fancy 0-day or complex exploits to full compromise a server.