Presentation of the security principles in WAPT¶
Preamble and definitions¶
Attention
The WAPT service operates as a privileged system account.
Attention
From WAPT version 1.5, the default installation directory becomes
C:\Program Files (x86)\wapt.
Hint
the sub-components wapttray, waptservice and waptexit of the WAPT agent may be optionally deactivated according to usage context.
Perimeter to secure¶
The elements to secure and that strictly concern WAPT are:
the WAPT Server (waptserver);
the WAPT agents (wapt-get) and its sub-components (wapttray, waptservice et waptexit);
the management console (waptconsole);
the network communications between these different components;
In complement to the elements listed above, an Organization that uses WAPT will have to choose and follow a methodology that is adapted to her use case:
insure the safe provisioning of all other files that are to be incorporated into a WAPT package;
develop the WAPT package python installation script so as to avoid any exploitable security or confidentiality defect;
manage in a safe way the private keys for signing the packages;
manage in a safe way the Autorities of Certification and Revocation for the SSL and HTTPS certificates;
The safe management of these complementary elements is excluded from the perimeter of this documentation.
Description of typical users¶
The following roles must be understood to evaluate the security principles incorporated in WAPT:
User
individual/ user of a WAPT equipped end-device (Enterprise and Community);
Package Deployer
individual with the ability to sign packages that DO NOT contain python code (generally group, host and unit packages) and to upload the package to the main repository (Enterprise);
Package Developer
individual with the ability to sign any package, may it include or not include python code, and to upload the package to the main repository (Enterprise);
SuperAdmin
all priviledged account in WAPT (Community);
Local Administrator
individual with local administration right of the WAPT equipped end-devices (Enterprise and Community);
Note
Depending on the context within this documentation, an Administrator will have the meaning of a Package Deployer, Package Developer or SuperAdmin.
Note
The Users that are members of the Active Directory security group waptselfservice are considered to be Local Administrators from the point of view of WAPT security.
Description of the sensitive assets in WAPT¶
By definition, a sensitive asset is a data (or a function) that is considered as having value to an attacker.
Its value is estimated according to several security criteria (also called security needs):
availability;
integrity;
confidentiality;
authenticity;
The sensitive assets to protect are as follows:
Sensitive assets A1: communications¶
Communications between the central WAPT Server and the WAPT agents, as well as the communications between the WAPT console and the WAPT Server are a sensitive asset and they must be protected.
Note
Need for securing the communications
integrity;
confidentiality;
authenticity;
Sensitive asset A2: inventory data¶
The informations on the state of deployment of the packages, as well as hardware and software configurations of the end-devices are a sensitive asset and they must be protected.
Note
Security need of the inventory data
integrity;
confidentiality;
Sensitive asset A3: log journals¶
The logs generated by WAPT on the central server and by the agents are a sensitive asset and they must be protected.
Note
Security needs of historical logs
availability;
Sensitive asset A4: configuration values¶
The configuration values (HTTPS server keys, database access configuration, server authentication configuration) are sensitive and they must be protected.
Note
Security needs of configuration values
integrity;
confidentiality;
Sensitive asset A5: WAPT executables on the end-devices¶
The WAPT executables installed on managed clients are a sensitive asset
and they must be protected (i.e. the content of the <WAPT> directory
that includes the binaries, the configuration files and the local database).
Note
Security needs of configuration values
integrity;
Sensitive asset A6: authentication¶
Authentication to the administration console as well as the authentication of the clients on the WAPT Server are a sensitive asset and they must be protected (public key of each WAPT agent).
Note
Security need of the authentication
integrity;
confidentiality;
Description of hypotheses on WAPT’s working environment¶
By definition, the hypotheses are statements on WAPT’s usage context or its working environment.
The following hypotheses on WAPT’s working environment must be considered:
Hypothesis H1: the Administrators and the Package Deployers are trained¶
The Administrators and the Package Deployers are trained on WAPT usage. In particular, they must insure that their logins, passwords and private keys are kept secret.
Hypothesis H2: the operating systems underlying WAPT are sane¶
WAPT’s underlying operating systems implement adequate protection mechanisms that are configured according to good practice (confinement, access control, etc).
The underlying operating system are patched and up to date at the time of the installation of WAPT, they are free of viruses, trojan horses, etc.
Hypothesis H3: the binaries necessary for WAPT to operate are sane¶
All libraries and tools necessary to install WAPT are considered to be sane. Upon the WAPT agent receiving a request, the agent verifies that the request has been properly signed.
Hypothesis H4: the WAPT packages are built in a safe manner¶
The Administrator is responsible for insuring that the files to be incorporated into a WAPT package come from safe sources and are free of viruses, trojan horses, etc.
Hypothesis H5: the Users of the end-devices are not Local Administrators¶
A User must not have local administration rights on the WAPT equipped device. Otherwise, the User must be considered a Local Administrator.
In particular, a User must not have write access to WAPT’s installation directory.
Hypothesis H6: the Local Administrators are trained¶
The Local Administrator of a device must be trained to use WAPT, or at minimum he must not make changes to files located in WAPT’s installation folder.
Description of threats on WAPT’s sensitive assets¶
By definition, a threat is an action or an event susceptible to bring prejudice to the security of the WAPT equipped device.
The threat agents to be considered for evaluating security in WAPT are as follows:
Unauthorized entities: it is a human attacker or en entity that interacts with WAPT without legitimately having access to it.
Note
The Administrators and the Local Administrators are not considered to be attackers.
The threats bearing on WAPT’s sensitive assets defined above are as follow:
Description of WAPT’s security functions¶
By definition, security functions are the set of technical measures and mechanisms implemented to protect in a proportionate way the sensitive assets against identified threats.
Security function F1: access authentication¶
Security function F1A: authentication of a device on initial registration in the WAPT database¶
New in version 1.5.
Note
risks avoided
the registering of an illegitimate device in the database;
a denial-of-service attack by overloading the database;
the insertion of a fraudulent inventory in the database;
Solution implemented¶
To exist in the database and thus to appear in the management console, a device must register with the WAPT Server using the register command.
The register command may be executed automatically when installing or updating the WAPT agent if the device has a Kerberos machine account that is correctly registered in the Organization’s Active Directory domain.
If the device does not present to the WAPT Server a valid Kerberos ticket, then the register fails;
Note
The Kerberos registration method assumes that the Active Directory server is responsive at the time of launch of the register command.
Security function F1B: verification of server HTTPS certificates by the WAPT agents¶
New in version 1.5.
Note
risks avoided (notably MITM)
the sending of sensitive informations to an illegitimate and unauthorized WAPT Server;
the recovery of sensitive informations by an unauthorized entity;
the display of fake information in the management console of the Administrator;
an incorrect date to be sent upon a HEAD request, thus preventing future upgrades (request for a modified file date);
sending the WAPT console password to an illegitimate and unauthorized WAPT Server;
Solution implemented¶
For the secured version of WAPT to work correctly:
an option for verifying the server HTTPS certificate is introduced in
C:\Program Files (x86)\waptwapt-get.inion the WAPT agents that will force the verification of the server certificate by the WAPT agents;an option for verifying the server HTTPS certificate is introduced in
C:\Program Files (x86)\waptwapt-get.inion the WAPT agents that will force the verification of the server certificate by the WAPT console;
Technically, it may be implemented in two ways:
by using a certificate verification tool implemented in the configuration file of WAPT’s Nginx web server; this method is typically provided by a Certificate Authority that is trusted by your network;
by using the certificate pinning method, which consists of providing the WAPT agent a short list of trusted certificates that will be stored in
C:\Program Files (x86)\wapt\ssl\server;
Security function F1C: no listening port on the WAPT agents¶
New in version 1.5.
Note
risks avoided
an unauthorized entity using an open port fraudulently;
Solution implemented¶
The connections to the WAPT Server are initiated exclusively by the agents, and the forced immediate actions are relayed through a permanent websocket initiated by the WAPT agent (update/ upgrade/ install …).
Note
if HTTPS is activated, then the WAPT agent checks that the websocket is connecting to the rightful server.
Security function F1D: signature of inventory return states¶
New in version 1.3.12.13.
Note
risks avoided
an unauthorized entity sending a fake inventory for a device that rightfully exists in the database;
Solution implemented¶
On the first register, each device generates a key/ certificate pair that is stored in
C:\Program Files (x86)\wapt\private, only accessible in read-only mode to Local Administrators. Once the device has successfully registered, the public key is sent to the WAPT Server;When the inventory is updated, the new inventory status is sent along with the private key of the device. The new inventory is then decrypted with the public key stored in the database;
The server will refuse any inventory that is signed with a wrong key;
Security function F2: protecting the integrity of the installation process of WAPT packages¶
Security function F2A: signature of WAPT packages¶
Note
risks avoided
to avoid an unauthorized entity modifying the content or the behavior of a WAPT package;
Solution implemented¶
when an Administrator or a Package Deployer builds a WAPT package, the file
manifest.sha256is created that lists the control sums of all files in the package;a file
signature.sha256encrypted with the WAPT agent’s private key is then created in the folderWAPT; it contains the control sum of the filemanifest.sha256;the whole is then compressed and suffixed with a .wapt extension;
when a WAPT agent downloads a WAPT package, the agent checks that the file
signature.sha256has been signed with the private key that matches the certificate present in the folderWAPT;the WAPT agent then checks that the certificate or the chain of certificates in
certificate.crthas been signed with a key matching one of the certificates present in the folderC:\Program Files (x86)\wapt\ssl;the WAPT agent then generates the control sum of all the files contained in the package (except the files
signature.sha256andcertificate.crt) and verifies that it matches the filemanifest.sha256contained in the package;if one of these steps does not pass, this means that a file has been modified/ added/ removed. The execution of the
setup.pyis then canceled.the altered package is then deleted from the local cache and the event is journalized in the logs of the agent;
Note
Since the version 1.5 of WAPT, the format of the manifest file
has changed from sha1 to sha256.
Security function F2B: signature of the attributes in the control files¶
New in version 1.4.
Note
risks avoided
an unauthorized entity modifying WAPT dependencies on WAPT equipped devices by falsifying
https://waptserver/wapt/Packages;
Solution implemented¶
When a WAPT package is signed, the sensitive attributes of the package are listed inside the signed_attributes attribute of the control file.
Note
Example of a signed_attributes list:
package, version, architecture, section, priority, maintainer, description, depends, conflicts, maturity, locale, min_os_version, max_os_version, min_wapt_version, sources, installed_size, signer, signer_fingerprint, signature_date, signed_attributes,
The attributes listed in signed_attributes are signed with the private key
of the Administrator and stored in the attribute signature
of the control file.
The certificate matching the private key is stored
in WAPT\certificate.crt inside the WAPT package.
On the WAPT Server, the index Packages is regenerated
when the wapt-scanpackages command is triggered by adding
or removing a package.
The WAPT Server extracts from each package the certificate of the signer
and adds it in the Packages zip file in the directory ssl.
Each certificate is named after its hexadecimal encoded fingerprint.
When the WAPT agent launches an update, it downloads
the Packages index file that contains the signed attributes
of all available packages and the certificates of the signers.
If the signer’s certificate is approved, which means that the certificate has been signed by a Trusted Certificate Authority or that the certificate itself is trusted, AND if the signer’s certificate can verify the attributes’ signature, the package is added to the index of available packages. Otherwise it is ignored.
Security function F2C: access restriction to the installation folder of the WAPT agent¶
Note
risks avoided
an unauthorized entity modifying the behavior of a WAPT agent;
The installation folder C:\Program Files (x86)\wapt is accessible in
read-write mode:
to the Local Administrators by direct access to the installation folder of the WAPT agent on the device;
to the Administrators through the deployment of WAPT agent upgrades;
Neither the Package Deployers, nor the Users have write-access to the WAPT agent’s installation folder.
Security function F2D: total access restriction to the folder storing the key / certificate for inventory signing¶
Note
risks avoided
an unauthorized entity falsifying an inventory status update;
an unauthorized entity impersonating the identity of a WAPT equipped device;
No access right is granted to any User
to C:\Program Files (x86)\wapt\private, whomever he may be.
Only the WAPT agent has a write and read access to this folder.
Note
This method for storing the key and the certificate results from a technical design choice that says that the WAPT equipped device would embed any and all information related to itself.
Security function F3: securing the communications between the different components of WAPT¶
Security function F3A: signature of immediate action calls sent to the WAPT agents¶
New in version 1.5.
Note
risks avoided
an unauthorized entity sending falsified requests to the WAPT agents;
Solution implemented¶
The following commands are signed by the WAPT Server before being relayed to the targeted WAPT agents via their Websockets:
wapt-get install: requests the WAPT agent to install a WAPT package flagged as MISSING;wapt-get remove: requests the WAPT agent to remove a package;wapt-get forget: requests the WAPT agent to forget the existence of a previously installed WAPT package without removing the software or the configuration;wapt-get update-status: requests the WAPT agent to send its current inventory status to the WAPT Server;wapt-get upgrade: requests the WAPT agent to execute a package flagged as NEED UPGRADEwapt-get update: requests the WAPT agent to update the list of available packages;
All the attributes in the requests for immediate action are signed:
the device’s UUID;
the action (ex: install);
the arguments (ex: tis-firefox);
the timestamp of the requests;
The certificate matching the signature is passed along:
upon receiving a request, the WAPT agent verifies that the request has been properly signed;
the agent will the verify that the timestamp is within a one minute delay window;
ultimately, the agent will verify that the certificate is authorized to launch actions;