Incorrect password change in filebeat.yml when changing the admin password

[s-ocando]

Wazuh version	Install type	Action performed
4.3.0	All-in-one	Unattended

The wazuh-passwords-tool.sh changes the Filebeat password and sets the one that corresponds to the admin user regardless of which user is configured in Filebeat.

I found this bug when migrating from Wazuh 4.2.5, where the default user is wazuh. The wazuh-passwords-tool.sh changes the Filebeat password to the one corresponding to the admin user instead of the one corresponding to the wazuh user, and breaks the installation.

As can be seen here, the scripts wrongly assumes that the Filebeat user is always admin and the Wazuh dashboard user is always kibanaserver.

[teddytpc1]

We have to validate if the issue persists.

[CarlosALgit]

Update Report

I've deployed the Wazuh AIO with the Installation Assistant. The output is the following one:

root@ubuntu2204:/home/vagrant# bash wazuh-install.sh -a
22/05/2024 11:48:52 INFO: Starting Wazuh installation assistant. Wazuh version: 4.7.4
22/05/2024 11:48:52 INFO: Verbose logging redirected to /var/log/wazuh-install.log
22/05/2024 11:48:57 INFO: Wazuh web interface port will be 443.
22/05/2024 11:49:01 INFO: Wazuh repository added.
22/05/2024 11:49:01 INFO: --- Configuration files ---
22/05/2024 11:49:01 INFO: Generating configuration files.
22/05/2024 11:49:02 INFO: Created wazuh-install-files.tar. It contains the Wazuh cluster key, certificates, and passwords necessary for installation.
22/05/2024 11:49:02 INFO: --- Wazuh indexer ---
22/05/2024 11:49:02 INFO: Starting Wazuh indexer installation.
22/05/2024 11:49:38 INFO: Wazuh indexer installation finished.
22/05/2024 11:49:38 INFO: Wazuh indexer post-install configuration finished.
22/05/2024 11:49:38 INFO: Starting service wazuh-indexer.
22/05/2024 11:49:48 INFO: wazuh-indexer service started.
22/05/2024 11:49:48 INFO: Initializing Wazuh indexer cluster security settings.
22/05/2024 11:50:00 INFO: Wazuh indexer cluster initialized.
22/05/2024 11:50:00 INFO: --- Wazuh server ---
22/05/2024 11:50:00 INFO: Starting the Wazuh manager installation.
22/05/2024 11:50:30 INFO: Wazuh manager installation finished.
22/05/2024 11:50:30 INFO: Starting service wazuh-manager.
22/05/2024 11:50:46 INFO: wazuh-manager service started.
22/05/2024 11:50:46 INFO: Starting Filebeat installation.
22/05/2024 11:50:49 INFO: Filebeat installation finished.
22/05/2024 11:50:50 INFO: Filebeat post-install configuration finished.
22/05/2024 11:50:50 INFO: Starting service filebeat.
22/05/2024 11:50:51 INFO: filebeat service started.
22/05/2024 11:50:51 INFO: --- Wazuh dashboard ---
22/05/2024 11:50:51 INFO: Starting Wazuh dashboard installation.
22/05/2024 11:51:26 INFO: Wazuh dashboard installation finished.
22/05/2024 11:51:26 INFO: Wazuh dashboard post-install configuration finished.
22/05/2024 11:51:26 INFO: Starting service wazuh-dashboard.
22/05/2024 11:51:26 INFO: wazuh-dashboard service started.
22/05/2024 11:51:46 INFO: Initializing Wazuh dashboard web application.
22/05/2024 11:51:47 INFO: Wazuh dashboard web application initialized.
22/05/2024 11:51:47 INFO: --- Summary ---
22/05/2024 11:51:47 INFO: You can access the web interface https://<wazuh-dashboard-ip>:443
    User: admin
    Password: LF*ONmy9mw2AYvDtRuEs9r?cH2jciNnc
22/05/2024 11:51:47 INFO: Installation finished.

And then, I accessed the Wazuh web interface with the credentials displayed on the output of the installation: User: admin Password: LF*ONmy9mw2AYvDtRuEs9r?cH2jciNnc

The result is that I accessed as usual to the Wazuh Dashboard with no issues:

[CarlosALgit]

Update Report

I made more tests. I changed all the passwords with bash wazuh-passwords-tool.sh -a -au wazuh -ap Hn.u+C?ADk?xr3lJdX5UfczMpQPgj3Hz and tried to login on the web interface with all the users.

admin user

Using admin user and it's password doesn't get any issue:

kibanaserver user

Using kibanaserver user and it's password doesn't get any issue:

kibanaro user

Using kibanaro user and it's passwords doesn't get any issue:

logstash user

Using logstash user and it's passwords get no permission to access but logs in with no problem about the password:

readall user

Using readall user and it's passwords get no permission to access but logs in with no problem about the password:

snapshotrestore user

Using snapshotrestore user and it's passwords get no permission to access but logs in with no problem about the password:

wazuh user using the token

root@ubuntu2204:/home/vagrant# TOKEN=$(curl -u wazuh:HGIt*C.bS7UXbMJbYqSP7X1YcIK4zklj -k -X POST "https://localhost:55000/security/user/authenticate?raw=true") && echo $TOKEN
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   398  100   398    0     0   1555      0 --:--:-- --:--:-- --:--:--  1554
eyJhbGciOiJFUzUxMiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ3YXp1aCIsImF1ZCI6IldhenVoIEFQSSBSRVNUIiwibmJmIjoxNzE2NDU0NzgyLCJleHAiOjE3MTY0NTU2ODIsInN1YiI6IndhenVoIiwicnVuX2FzIjpmYWxzZSwicmJhY19yb2xlcyI6WzFdLCJyYmFjX21vZGUiOiJ3aGl0ZSJ9.AEESKAfIg_TGEZ1VS1LAqvQAWST9XWKlljxrWwKjVElhO9BE-iUDADvbjSmAIRTuFD80Ul2N0rykFVxWw5j8NXvcAEme2Bi3xlS9Trih5GGcA7Zatyu2GeSZHHnODjG8f-NKhNhYrVysohW66DI9ipffCOjyeWWwywzYD_ydtF9cSxWb

wazuh-wui user using the token

root@ubuntu2204:/home/vagrant# TOKEN=$(curl -u wazuh-wui:xqdMPv2i9ir?0tLK4O+JfUjd0SMT+amY -k -X POST "https://localhost:55000/security/user/authenticate?raw=true") && echo $TOKEN
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   404  100   404    0     0   1505      0 --:--:-- --:--:-- --:--:--  1501
eyJhbGciOiJFUzUxMiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ3YXp1aCIsImF1ZCI6IldhenVoIEFQSSBSRVNUIiwibmJmIjoxNzE2NDY1Mjg5LCJleHAiOjE3MTY0NjYxODksInN1YiI6IndhenVoLXd1aSIsInJ1bl9hcyI6ZmFsc2UsInJiYWNfcm9sZXMiOlsxXSwicmJhY19tb2RlIjoid2hpdGUifQ.AH1_r-UeiHQCZz88mlboag8OdxUBLsOJi2rcFuxZHGRaJeM3WY6sW1VxsdEOrjuI1VP3kChIsQXZXP3i1N2cSMGKAZVm43lk5O_3rcTMWBYAOMTzoD31OFWWteVRzJn-YE4ma6ihcsOw7gSQcJ69ONTQTZcUe7akboLIThKR-znAKfpq

[CarlosALgit]

Working on replicating the environment with Wazuh 4.2.5 installation.

[CarlosALgit]

I've been reading this documentation to understand how to upgrade the replicated environment. I've tried to follow the steps but I think I misread something so I'm currently checking errors.

[CarlosALgit]

I've replicated the environment by installing Wazuh version 4.2.5 by cloning the repository and changing the branch. Then, I've followed these three documentations to upgrade to Wazuh version 4.7.4:

• https://documentation.wazuh.com/current/migration-guide/wazuh-indexer.html
• https://documentation.wazuh.com/current/migration-guide/wazuh-dashboard.html
• https://documentation.wazuh.com/current/upgrade-guide/upgrading-central-components.html

Then, the only issue I've found is that the file /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml has not the required permissions and this generates an error when trying to login to the Wazuh Dashboard. It has been fixed by changing the user and group of the file using sudo chown -R wazuh-dashboard:wazuh-dashboard /usr/share/wazuh-dashboard/data. I logged in with the same passwords generated in the 4.2.5 installation.

[CarlosALgit]

Update Report

After the migrating process was completed, I downloaded and run the password tool with the command:

bash wazuh-passwords-tool.sh -a -au wazuh -ap wazuh

At a first attempt it printed the following error:

29/05/2024 08:49:52 ERROR: The backup could not be created

Then I ran the same command again and surprisingly it worked fine. The output was the following:

29/05/2024 08:53:18 INFO: The password for user admin is QttONFfkosNbJ?.Ir2238kFr7U4TC.u?
29/05/2024 08:53:18 INFO: The password for user kibanaserver is vKj2upT+xHJRlLh3TlcA43+7PJ7ZUn11
29/05/2024 08:53:18 INFO: The password for user kibanaro is EcG?lExBLC*?xD+yP+Oc8Sw6NJA88uHk
29/05/2024 08:53:18 INFO: The password for user logstash is e?vBr5Gk*1aHAuqB6tX+WYva56jtkBxa
29/05/2024 08:53:18 INFO: The password for user readall is 8?kxRJkljwiRNKXGuKNfwpCB9Htur4HU
29/05/2024 08:53:18 INFO: The password for user snapshotrestore is .b68A.Hc7Fx9It4jeKJ1fVFxN8S?NHA5
29/05/2024 08:53:18 WARNING: Wazuh indexer passwords changed. Remember to update the password in the Wazuh dashboard and Filebeat nodes if necessary, and restart the services.
29/05/2024 08:53:19 INFO: The password for Wazuh API user wazuh is LTKCRRT*2Zha63AJxZEB8dtX8dAq*E5l
29/05/2024 08:53:19 INFO: The password for Wazuh API user wazuh-wui is USkvg97ZWvtbyGJ*qHQ7.+?1aswuodmA
29/05/2024 08:53:19 INFO: Updated wazuh-wui user password in wazuh dashboard. Remember to restart the service.

So I went to check the file /etc/filebeat//filebeat.yml and, indeed, the password did not match the correct one for the user. I leave the file below:

# Wazuh - Filebeat configuration file
output.elasticsearch.hosts:
        - 127.0.0.1:9200
#        - <elasticsearch_ip_node_2>:9200 
#        - <elasticsearch_ip_node_3>:9200

output.elasticsearch:
  protocol: https
  username: wazuh
  password: QttONFfkosNbJ?.Ir2238kFr7U4TC.u?
  ssl.certificate_authorities:
    - /etc/filebeat/certs/root-ca.pem
  ssl.certificate: "/etc/filebeat/certs/filebeat.pem"
  ssl.key: "/etc/filebeat/certs/filebeat-key.pem"
setup.template.json.enabled: true
setup.template.json.path: '/etc/filebeat/wazuh-template.json'
setup.template.json.name: 'wazuh'
setup.ilm.overwrite: true
setup.ilm.enabled: false

filebeat.modules:
  - module: wazuh
    alerts:
      enabled: true
    archives:
      enabled: false

As we can see and compare, the username on the file is wazuh and the password is the one used for the admin user.

First approach

The first approach I am going to try to solve this problem is to try to read the user that is on the file and update the password that belongs to that user.

[CarlosALgit]

Update Report

Summary

As part of the first approach mentioned above, we researched through Wazuh's versions looking for the username used on filebeat.yml file and we found that the username used before was wazuh and that was changed from 4.3.x versions on and now the username used is the variable ${username} taken from the Filebeat keystore and it's standardized as admin.

Evidence

On Wazuh Documentation from 4.3 version onwards:

admin: is the default administrator user. It's used to log in to the web interface and for communications between Filebeat and the Wazuh indexer. If you change the admin password, you must update it in Filebeat.

On the wazuh-packages repository tag v4.2.5 there's this file: unattended_scripts/open-distro/filebeat/7.x/filebeat_unattended.yml This file contains the Filebeat configuration like this:

# Wazuh - Filebeat configuration file
output.elasticsearch.hosts:
        - 127.0.0.1:9200
#        - <elasticsearch_ip_node_2>:9200 
#        - <elasticsearch_ip_node_3>:9200

output.elasticsearch:
  protocol: https
  username: wazuh
  password: wazuh
...

And the one from version 4.3.0 onwards contains:

# Wazuh - Filebeat configuration file
output.elasticsearch:
  hosts: ["<elasticsearch_ip>:9200"]
  protocol: https
  username: ${username}
  password: ${password}
...

Second approach

So, we thought it would be better to set directly the username on filebeat.yml to admin to fix this error. To do that, we have to change this line in order to add the username.

[CarlosALgit]

Update Report

While applying the previous approach I realized that there was a scenario that had to be thought about.

As I mentioned before, starting with version 4.3.0, the username and password variables stored in the Filebeat Keystore are used in the filebeat.yml file. The Password Tool function that changes passwords checks if there is a variable in the Keystore called password and, if so, it only updates that variable to set the new password. But this could end in an error if the username or password has been changed for any reason in the filebeat.yml and instead of using the variables, plain text is used.

To solve this possible scenario, I thought that when it is detected that Filebeat Keystore is being used, update the filebeat.yml file to use the Keystore variables username and password instead of allowing plain text.