Agents groups case sensitivity issue

[jctello]

Wazuh version	Component	Install type	Install method	Platform
3.9.5-3937	Groups	Manager/Agent	Packages	-

Issue

If two groups are created that only differ by casing (upper/lower case letters) agents added to either group are seen in both via the agent_groups or the Wazuh Kibana App.

Steps to reproduce

1. Create group. /var/ossec/bin/agent_groups -a -g abc
2. Create another group with same name except some letters have opposite capitalization. /var/ossec/bin/agent_groups -a -g ABC
3. Add an agent to either group. /var/ossec/bin/agent_groups -a -i 1 -g ABC
4. Verify list of agents in the other group (result agent claims to be part of that group). /var/ossec/bin/agent_groups -l -g abc

Additional information

• Only the files created in the shared folder of the groups that are explicitly added are distributed.
• Agents may be added to a group affected by this bug by using the agent_groups utility, but will be correctly identified as already added to the group to which it was explicitly added.
• After this files will be correctly distributed if placed in the shared folder of a matching.
• Groups that are created afterwards also matching the name except for casing will also appear to have the agent among it (in this case for example Abc).
• Trying to remove the agent from a group it appears in but hasn't been added to will result in the error Agent does not belong to the specified group
• This makes it impossible to add the agent to the other groups from the Wazuh Kibana App (since it cannot be graphically added if it is already in the group).
• Running the API request for a group affected by this bug will list the agent but within the groups listed for this agent this group will not appear (GET /agents/groups/Abc)
• Using the API for adding this agent to a group will not trigger this bug (doing PUT /agents/1/group/ABC will not show any results when using GET /agents/groups/Abc)
• Doing this via the API will fix the query for the other methods until an agent is added to any of the groups using the agent_groups utility or the Wazuh Kibana App.

[jctello]

This still happens as of Wazuh v4.2.5, this behavior is inherited by the Wazuh API and in consequence the Wazuh Dashboard plugin as it can be observed in this video:

https://user-images.githubusercontent.com/36071202/175339803-e1046323-6c12-485d-ada0-cbd4e51b65b6.mp4

In the video two groups are created groupA and GroupA, one agent is added to groupA and it is observed to be part of GroupA which as a total of 0 agents. Removing the agent from GroupA results in error and trying to delete GroupA also results in error.

[mcarmona99]

The error is also happening in the 4.4 branch.

After investigating, I have seen that the problem is in the _process_filter method of core/agent.py. Summarizing, the SQL LIKE query operator is case-insensitive which makes the API/CLI return agents belonging to specified groups that do not belong to those groups in truth.

            if q_filter['operator'] == '=':
                self.query += f"(',' || {self.fields[field_name]} || ',') LIKE :{field_filter}"
                self.request[field_filter] = f"%,{q_filter['value']},%"

Query done:

SELECT disconnection_time as 'disconnection_time',group_config_status as 'group_config_status', ... FROM agent WHERE ((',' || `group` || ',') LIKE '%,abc,%')   ORDER BY id ASC LIMIT 500 OFFSET 0

This query will search for partial strings in the group column. By default, the query will match these strings case-insensitive (as I said above).

We would need to change the _process_filter function to make the query match the strings case-sensitive.

A solution could be using GLOB instead of LIKE. When using GLOB, we also need to change the regex. The new solution proposed in _process_filter:

            if q_filter['operator'] == '=':
                self.query += f"(',' || {self.fields[field_name]} || ',') GLOB :{field_filter}"
                self.request[field_filter] = f"*,{q_filter['value']},*"

API requests after the change:

GET /groups/ABC/agents

{
  "data": {
    "affected_items": [
      {
	...
        "group": [
          "default",
          "ABC"
        ],
        "id": "001",
	...
      }
    ],
    "total_affected_items": 1,
    "total_failed_items": 0,
    "failed_items": []
  },
  "message": "All selected agents information was returned",
  "error": 0
}

GET /groups/abc/agents

{
  "data": {
    "affected_items": [],
    "total_affected_items": 0,
    "total_failed_items": 0,
    "failed_items": []
  },
  "message": "No agent information was returned",
  "error": 0
}

This seems to be a good solution. We should investigate others and study performance implications.

[davidjiglesias]

We have started discussions about whether the appropriate solution might be to remove the case sensitivity altogether.

[davidjiglesias]

After further discussions, we decided to make the groups case insensitive. @wazuh/binary-beasts @vikman90.

Although it is a breaking change and so we should decide if we include it in v5.0.0 or it is discarded.

[jctello]

we should decide if we include it in v5.0.0 or it is discarded.

Ok, I advice against considering discarding this as it is a bug that leads to unexpected behaviors that damage the user experience and potentially break collection of security relevant information.