Share This:

In a previous post I asserted that the security boundary of the Outpost should be considered to be the OS. This is given additional weight if you consider the UI authentication mechanism: at install time, a local administrator password is chosen:


Outpost Login.png


(Aside: the Outpost's password needs to be at least 8 characters, but there doesn't seem to be any configurable options, like there are for appliance users; a 10-level password history is kept)


This account information is stored locally to the Outpost - it is not linked to the local OS, Active Directory or an appliance. If you look in the registry under the key:

  • HKEY_LOCAL_MACHINE\SOFTWARE\BMC Software\Discovery Outpost


Outpost Registry.png


you will find settings OutpostAdminSalt and OutpostAdminPassword. The password is stored with a modern digest algorithm with a random salt, so it should be resistant to rainbow table attacks to recover the password.


However, any Windows user with Administrator rights can simply replace these values with ones that correspond to a known password (normal Users can only read). This is a useful way to proceed if you have forgotten the Outpost password. Which you should never do, of course, since you will be using a good password manager. Right...?


You could obtain the required values by either:



Installing another Outpost somewhere, entering your desired password, and grabbing the values from its registry (it doesn't need to be connected to an appliance)



Using the values here:

  • OutpostAdminSalt:
  • OutpostAdminPassword:


After restarting of the Outpost service, the password is set to "secretpass" (see - I can do irony). You should then login and immediately change the password in the Outpost UI to something of your choosing:


Change Passowrd.png


In addition to the password hash, the salt is also updated when you change the password in the UI.


So, is this a security problem? Well, only if you take misguided actions based on an incomplete understanding of how the system works. Again, it's about where the boundary is. Perhaps it would be nice to be able to have more flexibiliy on how to authenticate to the local OS or external systems, but it's really no different from:

  • Unux/Linux root being able to copy entries in /etc/shadow file
  • Tomcat user passwords being configured in the tomcat-users.xml file
  • OpenLDAP storing the Manager DN password hash in olcRootPW field in an .ldif file
  • The tideway CLI user controlling Discovery UI users with the tw_passwd command.


Where if you have control of the OS, you control the applications that run on it.


Let me know your thoughts on how this architecture fits into your security policies and controls, and if you agree or disagree with my thinking.