CloudAtCost User Backdoor

CloudAtCost Ubuntu Backdoor

Oh boy! Recently, many have heard of the CloudAtCost Debian 8 image containing a backdoor user. Well, this just in – The Ubuntu image contains one too!

So, I was preparing some servers for my research botnet project that will slowly crawl different sites to find relations. I chose CloudAtCost because I already had the resources to create eight VPS’ on them and this project isn’t critical. Never host something critical on CloudAtCost, but now there are more reasons not to. After hearing about the recent Debian 8 discovery, I checked my Ubuntu deployments for anything suspicious. AH HA! A user! With a password and home directory. Across my eight VPS, this user is present with different password hashes; unlike the Debian 8 images. The username of it is user with the ID of 1000 – very inconspicuous.

Lets go a bit deeper into this user. Apparently they left their .bash_history behind. The contents below.

sudo halt

It possibly the user was used for creating the image and forgotten to be removed because halt command being the only thing in there. Lets check the .viminfo for some edit history – Also left behind.

# This viminfo file was generated by Vim 7.4.
# You may edit it if you're careful!

# Value of 'encoding' when this file was written

# hlsearch on (H) or off (h):
# Command Line History (newest to oldest):

# Search String History (newest to oldest):

# Expression History (newest to oldest):

# Input Line History (newest to oldest):

# Input Line History (newest to oldest):

# Registers:

# File marks:
'0 16 0 ~/

# Jumplist (newest first):
-' 16 0 ~/
-' 1 0 ~/

# History of marks within files (newest to oldest):

> ~/
 " 16 0

So this does make it look more like a deploy user as it was last editing a file – Probably a template script they use to create the image. Sucks we can’t comment on their coding abilities as that script is no longer around. Regardless if this is a deploy user or not, it is still a user that can login with a set password. This password I have managed to figure out is the same as the default root password when you first create your VPS. The /etc/passwd and /etc/shadow are below for your convenience.


list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin



As you can see the user has a home directory of /home/user and set password. Although the password hash is different from the root account, it is the same password as I can SSH to both accounts with the same password. Since CloudAtCost obviously stores this password conveniently and insecurely on their control panel, you really only need to crack their standard password format (/^[A-z0-9]{10}$/) to get in or the control panel password for the account – Even better. Now lets take a look at this 16834 though. The 16834 represents the last password change measured in days from 1970-01-01. If you do the math, that returns 2016-02-03 – The day I created the VPS.

Moving on to the groups the user is assigned to. I grep‘d the /etc/group file for it (A side note: I am not running id for the sole reason of they could be modifying the output or could have modified the binary. Looking at the raw file is the most accurate way).

grep 'user$' /etc/group:


Nice. As you can see, the user in question has access to all the groups above; Including:

  • ada – System log access.
  • carom – Access to CD-ROM devices in /dev.
  • sudo – sudo level access – Very bad…
  • dip – A ppp group. Normally used for networking.
  • plugdev – Access to storage devices.
  • lpadmin – Printer configuration.
  • sambashare – Use of samba share directories.

Wow, so this user has some serious privileges. Even sudo. No doubt this is a major security issue. But I found more odd stuff after finding all this. I noticed in the root account’s .bash_history file contained some junk before I started messing around. Since I am still logged in with my initial session, the file has not been written with my history items yet.


vi /etc/ssh/sshd_config

Weird, wonder what is in the .viminfo for the root account them.


# This viminfo file was generated by Vim 7.4.
# You may edit it if you're careful!

# Value of 'encoding' when this file was written

# hlsearch on (H) or off (h):
# Command Line History (newest to oldest):

# Search String History (newest to oldest):

# Expression History (newest to oldest):

# Input Line History (newest to oldest):

# Input Line History (newest to oldest):

# Registers:
""1 LINE 0
"2 LINE 0
 ls -a
"3 LINE 0
 cat .bash_history 
"4 LINE 0
 cat .bashrc 
"5 LINE 0
 man exit
"6 LINE 0
 man logout
"7 LINE 0

# File marks:
'0 2 0 /home/user/.bash_history
'1 1 0 /etc/ssh/sshd_config
'2 28 18 /etc/ssh/sshd_config

# Jumplist (newest first):
-' 2 0 /home/user/.bash_history
-' 1 0 /home/user/.bash_history
-' 1 0 /etc/ssh/sshd_config
-' 28 18 /etc/ssh/sshd_config
-' 1 0 /etc/ssh/sshd_config
-' 28 18 /etc/ssh/sshd_config

# History of marks within files (newest to oldest):

> /home/user/.bash_history
 " 2 0
 . 3 0
 + 3 0

> /etc/ssh/sshd_config
 " 1 0
 ^ 28 19
 . 28 18
 + 28 18

The history of /home/user/.bash_history was from my account since the vim files are saved after each exit. The edit of /etc/ssh/sshd_config seems interesting. However, when I ran diff against my SSH configuration from one of my systems on a different host, nothing interesting. Odd they opened the file yet didn’t change anything.

After running last, I found an odd little date issue. Remember earlier when we figured out that the password was set on 2016-02-03? Well, this date doesn’t match the last login date.

last | grep user:

user tty1 Mon Jul 28 10:47 - down (00:10)

So is that when the user ran the contents of their of their .bash_history? No idea. however, it is very odd.

After, I ran find for the user and group of the user and didn’t find anything out of the ordinary. The outputs below.

find / -user user:


find / -group user:


I didn’t see any out of the ordinary in packages installed either. Odds are this is just a deploy user but for security, we should gain as much information as possible about it.  Although there aren’t any cronjobs for the user or in the cron directories, I did find some junk in /etc/rc.local. Contents below.


#!/bin/sh -e
sh /etc/init.d/
exit 0" >>/etc/apt/sources.list
echo 600 > /sys/block/sda/device/timeout
echo 600> /sys/block/sr0/device/timeout
test -f /etc/ssh/ssh_host_dsa_key || dpkg-reconfigure openssh-server

It looks like they did this for some quick setup or hacks to get the image functional. I did take a look at /etc/init.d/ but it was empty and created on 2016-02-03 (same as before). So possibly another setup script? No clue at this point. Just a known security issue. I also took a quick skim for all recently changed files and nothing interesting stood out.


CloudAtCost now has known backdoor users for both Ubuntu 14.04 LTS and Debian 8 images. The differences between those two backdoors is the Debian 8 image uses the same password hash across all while the Ubuntu 14.04 LTS is set to the default root password. A simple solution if you aren’t concerned for security would be to remove the user by running the following.

deluser --remove-home --remove-all-files user

If you want a fully secured system, you should manually overwrite the entire disk of your VPS with a new and verified Ubuntu server ISO. CloudAtCost is ‘ok’ for temporary systems and non-critical/personal system due to their SLA, horrible support, and horrible security. Please, open support tickets, email and tweet to CloudAtCost until the issue is fixed. CloudAtCost needs to realize the nature of the situation.


2016-02-11 23:08: Many people have contacted me stating that this is intentional as a convenience. The issue with this is it is not made clear to the end-user that CloudAtCost creates this user. Most VPS customers are used to logging in as root for the first time and then creating a user themselves. Some have said this is sent in the creation email – The issue with that is the eight VPS’ I created, there were no emails sent. Another issue this poses if this is supposed to be a convenience instead of a backdoor: all the usernames are the same, making it easier to brute force (when knowing the password format – regex above). The final issue with this is if you didn’t notice the secondary user account, all someone has to do is get into your CloudAtCost panel to get the default passwords.

Author: Zachary DuBois

I am a person who makes random things and likes to problem solve.

3 thoughts on “CloudAtCost User Backdoor”

  1. Just reporting that CentOS 7 images aren’t affected – at least mine isn’t.

  2. DO you have any material about deploying your own image to cloud at cost? Thanks on advance

Comments are closed.