VIMA and ESX Password Complexity

A few days ago I posted about setting the password complexity and other items for ESX hosts. I generally don’t use VIMA for much, as I don’t have any scripts that require periodic execution without authentication, and the logging aspect of it holds no value for me (I have a syslog server for that…). For some reason (I don’t remember why now) I was fiddling with a script on my VIMA test VM and discovered a strange error…

One thing I’ve discovered about VIMA is that when a command fails (especially the vifp commands) they give entirely useless errors back. I checked the syslog server for entries regarding the ESX host I was trying to add and discovered the following:

The important part being the last part: passwd: Authentication token manipulation error. This was very strange, considering I was able to login to the host fine via SSH using my regular account, I was able to create accounts manually, and su to root without trouble.

I did some further investigation and discovered that the vi-admin00 user was being created on the target ESX server when the vifp addserver command was executed, however the password was not being set. So I attempted to set a password for that user…no problem. Then I attempted to set a password that violated the policy (don’t ask me why it occurred to me to try this)…BAM! “Authentication token manipulation error”!

I did some additional investigation of VIMA’s scripts at this point to find out exactly what’s happening. Turns out it’s not all that complicated, but VMware has done a really good job of wrapping their SDK with user friendliness. VIMA’s primary “value add” functions (logging and fastpass) are simply perl scripts using SDK calls, with a little extra C (which, near as I can tell still uses the SDK).

Fastpass has an associated C library that is loaded into perl (using the bootstrap command, which was new to me) when an associated command is called (specifically vifpinit). The C library then provides the necessary functions for creating a new user on the remote machine (vi-admin00/vi-user00) and storing the password in the correct format and place (in vi-admin/vi-user’s home directory on the VIMA appliance). This library is also linked to the same libraries as the vifp binary. I would imagine that the SDK is used to create the user and it’s password, then some custom C stores the password on the VIMA box.

Part of vifpinit‘s process is to call a short perl script that checks to see if the requested server is configured. Using this, I did a little reverse engineering and discovered how to use their perl module to load the available servers and get the pertinent information about them from the underlying C library.

So, it’s quite easy to get the unobfuscated password for a vifp enabled server using perl. What I discovered about 30 seconds after this though was a little astonishing…I had always assumed that when you call vifpinit esx.server from a shell script on VIMA it connected to the server using the VIMA user (vi-admin/vi-user) and saved the session from that connection. The username and password are not involved in interactions with that server after that, only the session file.

Well, that isn’t true.

After calling vifpinit esx.server, I checked my environment to see if I could find the session file. I didn’t need to. The server name, port, username and password were all stored in the environment in plaintext.

I didn’t even have to dig through the perl modules and scripts to get the password…there it is, plain as day. 16 characters long, consisting of just two character classes.

My original point for this post was to point out three things: the VIMA passwords are easily obtained (as shown above), they’re seemingly weak (in the previous paragraph), and it doesn’t matter.

Two classes, assuming worst case (lower or upper case characters and numbers) means just 36 possible characters. Using my rudimentary math skills, that means there is just shy of 8 septillion password combinations ( 36^16 = 7,958,661,109,946,400,884,391,936, which according to this page 24 zeros == septillion). That many combinations would take approximately 3,313,991 years to brute force using Distributed.net‘s Project Bovine (which is stated to have the capability of 76.1 billion guesses per second here).

What does all this mean for our password settings on the ESX hosts? Well, two small changes to one command. In my original post, I used the following password complexity command:

The values with -1 are disabled, so for the above, anything less than three classes is not allowed. By changing the command to allow 16 character two class passwords and passphrases, we fix the problem…

The library won’t allow us to disable the passphrase option when the two character option is enabled, so we set it to the same length.

So, with a little bit of time, trial and error, and cursing I figured out the problem VIMA has with my password policy, but at the same time I realized that it really doesn’t matter so long as VIMA is secured the same way, preferrably better, as your ESX hosts are. Just like compromise of a single ESX host can lead to bad things happening to many virtual machines, if you are leveraging VIMA for management of your servers then it’s compromise can lead to bad things happening to many ESX servers.

4 thoughts on “VIMA and ESX Password Complexity”

  1. This was a very good article, I was not aware of the security implication and how easily you could obtain the generated password. Definitely want to make sure VIMA is properly secured as the rest of your infrastructure. Hopefully this is something that may get enhanced in future releases of VIMA to harden the processes on how the passwords are generated/stored.

    Reply
  2. seems this is changed in vma4.1
    i was using liam ups shutdown script ,
    but that is failing now after upgrade to vma4.1

    [vi-admin@vma ~]$ ./test.pl
    Use of inherited AUTOLOAD for non-method vifplib_perl::CreateVIUserInfo() is deprecated at ./test.pl line 19.
    Undefined subroutine &vifplib_perl::CreateVIUserInfo called at ./test.pl line 19

    Reply
    • luc,

      There has been some fairly significant changes to the APIs with the release of 4.1. I would highly recommend that you check to make sure you have the latest version of William’s excellent script. If that doesn’t help, you may want to leave a comment for him.

      Sorry I can’t be of more help,

      Andrew

      Reply
  3. The article is interesting, but the solution isn’t clear. I am getting the exact error as noted in the article, when I run from vMA 4.0 vifp addserver . They use AD, though more than that I don’t know. Is the problem with the root password not meeting specs or the password for the users it is creating (vi-admin00 and vi-user00, though they have /bin/false for login) or something else entirely? Bottom line, what do I need to change as I am doing a proof of concept and hung up on the addserver?

    Thanks in advance,
    Mel

    Reply

Leave a Reply