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.

The 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.
Running the 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/emailAddress=support@nexenta.com/localityName=Cupertino
| Issuer: commonName=nmv.nexenta.com/organizationName=Nexenta Systems Inc/stateOrProvinceName=California/countryName=US/organizationalUnitName=Storage Technology/emailAddress=support@nexenta.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.

Conclusions

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.