DeleteByQuery fails when the settings include kibana_access: rw

Users Feedback
1

The blue team is able to delete by query, but the same task fails for the red team. The most likely difference in the configuration is that the red teams config includes: “kibana_access: rw”.

Audit log

    "_source": {
          "path": "/*index-name*/_delete_by_query",
          "final_state": "FORBIDDEN",
          "action": "indices:data/write/delete/byquery",
          "type": "DeleteByQueryRequest",
          "req_method": "POST",
          "user": "red1"
        }

RoR Settings

 - name: "::BLUE-TEAM::"
   actions: ["*"]
   indices: ["*"]
   kibana_index: ".kibana"
   ldap_auth:
     name: "ldap1"
     groups: ["blue-team"]
   verbosity: error
   
 - name: "::RED-TEAM::"
   kibana_access: rw
   actions: ["*"]
   indices: ["*"]
   kibana_index: ".kibana"
   kibana_hide_apps: ["readonlyrest_kbn", "timelion"]
   ldap_auth:
     name: "ldap1"
     groups: ["red-team"]
   verbosity: error

I am not a java programmer, but I noticed some differences in the wildcard use in the code below line 53 of
https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin/blob/master/core/src/main/java/tech/beshu/ror/acl/blocks/rules/impl/KibanaAccessSyncRule.java

Does the wildcard “indices:data/write/delete*” include “indices:data/write/delete/byquery”? Some lines have the wildcard symbol after a forward slash. That’s a rhetoric question and I do not need an answer, it’s just a hint to the possible cause.

RoR version: 1.17.4
ElasticSearch version: 5.6.9

2

You can see what rule is responsible for the “FORBIDDEN” in the history field of the audit log record.

3

I am not sure of which field contains that data. Is it “block”: “default”? That is from the relevant audit log entry.

4

“acl_history”: “[[::LOGSTASH::->[auth_key->false]], [::RW::->[kibana_access->true, indices->true, kibana_hide_apps->true, auth_key->true]], [kibana->[auth_key->false]], [::RO::->[auth_key->false]]]”,

5

The team with the problem has this entry in the acl_history.

[::RED-TEAM::->[ldap_authorization->true, kibana_access->false]]

If you need the full audit log, I can send that in a private message.

6

OK so the issue is really the kibana_access as it says authorization is ok and kibana access did not match (false).
I created a unit test case, but it passes. Need to go the end-to-end way. Could you provide the body of your POST request? Or even better a curl command to reproduce it?

7

The behaviour of the error is listed below.

  1. User logs into kibana

  2. In Dev Tools, run the following query.
    GET index-name/_search
    { “query”: { “term”: { “host”: “LAPTOP1” } }}

result is OK

  1. In Dev Tools, run the following query.
    POST index-name/_delete_by_query
    { “query”: { “term”: { “host”: “LAPTOP1” } }}

result is not OK.

A popup, login dialog appears, but filling in the correct user name and password fails to complete the query successfully and the login popup reappears. Additionally, the RoR audit log shows forbidden in the final_state.

Request details for step 3 (obtained using fiddler)

POST https://kibana.example.com/api/console/proxy?path=*index-name*%2F_delete_by_query&method=POST HTTP/1.1

Response details for step 3 (obtained using fiddler)

{"error":{"root_cause":[{"reason":"forbidden"}],"reason":"forbidden"},"status":401}

  1. Repeating step 3 with kibana_access: rw removed from the configuration results in a successful execution of the delete_by_query command.
8

Hi,

having the entire line of of RoR log would help more
like enumeration of rules execution, which one matched or not.

[2019-04-25T10:14:05,692][INFO ][tech.beshu.ror.acl.ACL   ] e[35mFORBIDDEN by default req={ ID:1443731273-57561534#60194141, TYP:UpdateRequest, CGR:L_e.....
[2019-04-25T10:14:49,268][INFO ][tech.beshu.ror.acl.ACL   ] e[36mALLOWED by { name: 'elk....
9

This bug investigation + fix is in the current sprint, will be taken care really soon. Sorry for the wait.

1 Like
10

Hey, let’s have a step back. I think this is expected. the “kibana_access” is a rule to be used to allow the minimum set of actions on the minimum set of indices to support a complete Kibana session.
This clearly (to me!) excludes rogue attempt to delete data from the dev tools console.

As you experimented, removing the kibana_access rule would simply relax this constraint and allow any request to be sent through the dev tools (or from curl).