Shared Host Integrated Password System: SHIPS

ID N0WHERE:32347
Type n0where
Reporter N0where
Modified 2016-03-16T19:35:25


SHIPS is a solution to provide unique and rotated local super user or administrator passwords for environments where it is not possible or not appropriate to disable these local accounts for both Windows and Linux. Clients may be configured to rotate passwords automatically. Stored passwords can be retrieved by desktop support personnel as required, or updated when a password has to be manually changed in the course of system maintenance. By having unique passwords on each machine and logging of password retrievals, security can be improved by making networks more resistant to lateral movement by attackers and enhancing the ability to attribute actions to individual persons.

When performing penetration tests, our common attack vector is through compromising one host and pivoting to other systems with the information obtained. It is common to see large-scale breaches utilizing this method and that is where SHIPS comes into play.

SHIPS is designed to make post-exploitation more difficult and minimize what systems attackers gain access to. Once SHIPS is set up, there isn’t much else that is needed and it’s simple to integrate into existing business processes.

SHIPS version 2 Released!

Shared Host Integrated Password System

Project Goals:

  • A complete solution packaged as a single application which can be deployed on a variety of platforms
  • Deployments should be simple to move or relocate (this may be required in disaster recovery situations)
  • Immediately useable with little or no training for support personnel
  • Low resource consumption on server and clients
  • Low impact on WANs
  • Support a wide variety of clients
  • Simple client protocol so various operating systems and devices can be integrated with the server through shell scripts and utilities such as cURL
  • Simple to integrate with external directories or asset management tools
  • Ability to easily script interaction with the server in order to facilitate systemdeployment processes, or integrate with other support tools


A script is deployed to the endpoints, servers, and any other systems through group policy or similar deployment tools. The script is run on a determined timeframe from the organization. The script makes a password request to the server, which generates unique password string that it stores and transmits to the client. The client script than applies the new password on the client. TrustedSec recommends deploying SHIPS to servers, workstations, or any other windows-based systems. The passwords will now be unique per individual server and workstation.

For organizations where client and server support roles are segregated to different groups of employees, multiple instances of the SHIPS server can be run on a single host. Simply change the listing port on one of server instances and configure each to authorize the appropriate users. TrustedSec recommends using the alternate listening port for the instance supporting server infrastructure. In most cases accommodating requests on the alternate port from servers will be easier than frequently more mobile clients, with regard to firewalls or proxies.

When users with permission to access account passwords wish to retrieve them, they simply log into the SHIPS admin server and do a lookup of the machine name. The web application will display the current password associated with the device. SHIPS authorization can be tied to external systems such as LDAP


Client Password Server is implemented as a standalone Ruby application. The application is web based, however, http handling is provided by WEBrick, an in-process webserver included in the standard library. This application has minimal external dependences, gems sqlite and optionally ruby-ldap. The ruby-ldap dependency is not required if installation of ruby-ldap is a problem on your platform, LDAP integration will not be available if omitted. Keeping external dependencies minimized allows the application to be installed on a host that may have existing web services running and alongside applications that may use large frameworks such as RAILS without the need for a separate Ruby environment. It also helps ensure the application can be stood up quickly in a disaster recovery scenario.

Clients perform password updates using a single https request. The request and response are kept to a minimal size to facilitate large numbers of clients across WAN links while keeping impact and data utilization low. Remote clients can be supported as well as this request may be handled securely over the Internet and be passed by proxies if the client script implementation such as the VBS client provided for Windows clients supports it. SHIPS has both a Linux and Windows version built into it.

Support personnel access the information using a web interface. Functions such as creating, removing, and clearing passwords on computer objects may also be accessed via a web service call that does not require sessions or cookies for transactions with scripts.

Security considerations:

  • The server can be configured to run as an un-privileged user.
  • It is necessary to ensure the directory permissions of the server files are correct, for example, do not allow access to the database file by users who should not have access to the local account passwords. Guidance on file permissions is provided in the installation section.
  • The server will validate the computer name exists in the database or external directory before issuing a password and storing the response. This provides basic protection from a DOS attack where the attacker would attempt to fill the password database.
  • The server issues a nonce value to each machine along with the password, and requires the correct value be submitted with future password requests, preventing attempts to corrupt the password database. This weakly authenticates the client. It may still be possible for an attacker to brute force the nonce making a large number of requests; this method was selected to keep client scripts simple while still providing some protection.
  • When deploying the client script, the directory in which the script resides and the directory where the history file (stores suggested next update time, and nonce) is stored should be writeable only by groups who would otherwise have access to change the administrator password on the machine, Administrators. If file permissions allow a non-administrative user to alter the client script, this
    could create a local privilege escalation path; use care deploying client scripts.
  • From a recovery standpoint, if the password database is ever lost or damaged it should automatically rebuild correctly as clients check in to update their passwords. The server will see the machine as a new client but valid in the directory and will issue a new password. The database can be otherwise be backed up by simply copying the SQLite file.

Shared Host Integrated Password System: SHIPS Shared Host Integrated Password System: SHIPS Shared Host Integrated Password System: SHIPS Shared Host Integrated Password System: SHIPS

Clone Shared Host Integrated Password System:

git clone

Source && Download

Shared Host Integrated Password System: SHIPS download Shared Host Integrated Password System Shared Host Integrated Password System: SHIPS Shared Host Integrated Password System: SHIPS Shared Host Integrated Password System: SHIPS