fbpx

Elastic 資安漏洞 ESA-2023-25 說明與建議處置

歐立威科技整理 Elastic 官方針對 ESA-2023-25 漏洞的影響與建議處置,更多關於本次漏洞的最新訊息請參考原廠討論串 Kibana 8.11.1 Security Update (ESA-2023-25)

ESA-2023-25 漏洞事件描述

2023 年 11 月 15 日,Elastic 發現當系統發生錯誤時,Kibana 可能將 kibana_system_user 的憑證、API 金鑰和 Kibana 終端使用者憑證記錄至日誌檔案。該漏洞主要發生於使用者與不健康的 Elasticsearch 集群互動,尤其是 Elasticsearch 回傳 circuit breaker 或 no_shard_exception 時。在 Elastic Cloud 環境下,受此漏洞影響的集群比例相對較低,僅佔不到總數的 5%。針對此漏洞,Elastic 發佈了 Kibana 8.11.1 版作為響應措施。

ESA-2023-25 漏洞影響範圍

受影響的版本

介於 Kibana 8.0.0 與  8.11.1 之間的版本

不受影響的版本

Kibana  8.11.1

Elastic 針對不同部署環境的響應措施

Elastic Cloud 

Elastic 已於 Elastic Cloud 環境中實施以下緩解措施

    • 清除監控環境所有日誌檔案中的機敏資料。

    • 透過部署新緩解措施,確保監控環境與客戶的監控集群不再紀錄機敏資料。

使用自建監控集群的 Elastic Cloud 使用者,建議仔細檢視受影響的日誌檔案,如果發現機敏資料被紀錄於日誌檔,應立刻將其清除並更新任何可能洩漏的憑證。

另外,為了保險起見,強烈建議將受本次安全漏洞影響的 Kibana 升級至 8.11.1 版,以增加系統安全性。

自建(Self Managed)

針對本次安全漏洞,使用自建 Kibana、ECE 或 ECK 的使用者應優先將 Kibana 升級至8.11.1. 版。另外,自建 Kibana 使用者應檢視日誌是否紀錄機敏資料,若發現機敏資料,應立即將其清除,並對任何可能洩漏的憑證進行更新。

無法升級 Kibana 的使用者,請參考 「Preventing Ingest of Sensitive Information」,了解可行的緩解措施。

如何發現日誌檔中的機敏資料?

以下將介紹不同部署環境的使用者該如何發現日誌檔中的機敏資料。

自建監控集群的 Elastic Cloud 使用者

有 Kibana 日誌監控集群的 Data View 上輸入:

headers" AND "x-elastic-product-origin" AND "authorization

條件式來識別受影響的日誌段落。

自建 Kibana 並啟用 Elastic Stack 監控功能的使用者

如果使用 Elastic Stack 來接收 Kibana 的日誌資料,可透過以下條件式查詢受影響的日誌段落,在有 Kibana 日誌監控集群的 Data View 上查詢:

message: ("headers" AND "x-elastic-product-origin" AND "authorization")

    • 如果使用 Filebeat Collection 導入 Kibana 日誌:則 index 名稱為 filebeat-{version},其中 {version} 為 Kibana 安裝的版本。

自建 Kibana 但沒有啟用 Elastic Stack 監控功能的使用者

不是使用 Elastic Stack 來接收 Kibana 日誌的使用者,可以在本機儲存目錄中的日誌文件查詢同時包含 header、x-elastic-product-origin 和 authorization 的日誌段落。

ECE 使用者

在 ECE 環境中,使用以下查詢語法能識別受影響的日誌段落:

message: ("headers" AND "x-elastic-product-origin" AND "authorization")

查詢相關集群上受影響的日誌段落。

ECK 使用者

如果啟用 Stack Monitoring,可以使用以下語法查詢受影響的日誌段落,在有 Kibana 日誌的監控集群上查詢:

message: ("headers" AND "x-elastic-product-origin" AND "authorization")。

    • 如果使用 Filebeat Collection  導入 Kibana 日誌:則 Index 名稱為 filebeat-{version} ,其中  {version} 為 Kibana 版本。

憑證(Credentials)洩漏處理流程

如果發現日誌檔紀錄憑證等機敏資料,建議採用以下處理流程

產品 建議處理方式
Elastic Cloud Elastic 能夠更新 kibana_system 中的憑證。終端使用者的憑證可以透過 Kibana 的 「Management > User」 介面或使用 Change Password API 進行更新。
Archive
Docker 
RPM/DEB
Native User 可以透過以下方式更新kibana_system 憑證,如果使用服務帳戶令牌(service acount token),就必須將已紀錄的令牌刪除重新創建
另外,終端使用者的憑證可以透過 Kibana 的 「Management > User」 介面或使用 Change Password API 進行更新。
ECE found-internal-kibana4-server 憑證能透過 advanced editor 更新
1.進入 advanced editor
2.找到「.resources.kibana[0].plan.cluster_topology[0].kibana.system_settings」
3.將「elasticsearch_password」設定為隨機字串
4.提交
另外,終端使用者的憑證可以透過 Kibana 的 「Management > User」 介面或使用 Change Password API 進行更新。
ECK Kibana system user 憑證能透過以下兩種方式方式進行更新
在 Kibana Namespace 中刪除 $KIBANA_NAME-kibana-user secret,並重啟 ECK Operator
在 Kibana Namespace 中刪除$KIBANA_NAME-kibana-user 和$NAMESPACE-$KIBANA_NAME-kibana-user secrets
另外,終端使用者的憑證可以透過 Kibana 的 「Management > User」 介面或使用 Change Password API 進行更新。

預防機敏資料被記錄於日誌檔案

無法升級 Kibana 的使用者能透過下方流程防止機敏資料被 Elasticsearch 日誌集群收集。

建立 Ingest Pipeline 刪除機敏資料

下方流程適用依照指南啟用監控功能的使用者,無論使用 Elastic Stack 收集 Kibana 日誌、使用 ECE,還是在 ECK 上啟用監控功能,使用者都可以透過下方 Ingest Pipeline 步驟來刪除相關集群中的機敏資料。

1.首先,建立一個 pipeline:

PUT _ingest/pipeline/redact-esa–2023-25
{
 "description": "Prevent Insertion of Sensitive Information into Log File (ESA-2023-25)",
  "processors": [
   {
     "dot_expander": {
       "description": "Expand 'event.original'",
       "field": "event.original"
     }
   },
   {
     "set": {
       "field": "message",
       "value": "[redacted]",
       "if": "ctx.message != null && !ctx.message.toLowerCase().contains('[redacted]') && ctx.message.toLowerCase().contains('headers') && ctx.message.toLowerCase().contains('x-elastic-product-origin') && ctx.message.toLowerCase().contains('authorization')"
     }
   },
   {
     "set": {
       "field": "event.original",
       "value": "[redacted]",
       "if": "ctx.event?.original != null && !ctx.event.original.toLowerCase().contains('[redacted]') && ctx.event.original.toLowerCase().contains('headers') && ctx.event.original.toLowerCase().contains('x-elastic-product-origin') && ctx.event.original.toLowerCase().contains('authorization')"
     }
   }
 ]
}

2.確認 Kibana 日誌檔案被收集到哪些索引和資料流

3.檢查索引和模板上的 index.default_pipeline 設定來確認這些索引是否設定了預設 pipeline。

a.如果索引沒有設定預設 Pipeline:

    • 設定模板,並指定使用 redact-esa-2023-25 pipeline

    • 更新索引設定,以符合使用 index.default_pipeline: redact-esa-2023-25 的條件

b.如果索引有設定預設 pipeline

    • 確認設定中 Pipeline 的名稱

    • 呼叫此 API GET /_ingest/pipeline/{pipeline_name}

    • 將 processor redact-esa-2023-25 加入預設 Pipeline 中。

{
  "pipeline": {
    "name": "redact-esa-2023-25"
  }
}

上述流程為 API 的使用範例,自訂 Pipeline 也能透過 Ingest Pipeline 的介面進行編輯。

更多內容請參考:Transform data with custom ingest pipelines 

其他補充

下方將介紹不同部署策略如何預防機敏資料被記錄於日誌檔案

自建 Kibana 但沒有啟用 Elastic Stack 監控功能的使用者

未使用 Elastic Stack 收集 Kibana 日誌資料的使用者,則應限制日誌目錄的存取權限。

ECE 相關集群除錯流程

如果依照上述步驟將 redact-esa–2023-25  pipeline 建立於相關集群,

在預設情況下,ECE 會附帶一個用於 cluster-logs-* 索引的模板,並且:

    • 沒有 settings.default_pipeline

    • 透過 Get 指令確認沒有其他模板

使用者可以透過 “GET _template/cluster-logs-*” 檢查 “default_pipeline” 是否存在,並使用“GET _template/” 比對  “index_patterns”  字段。如果存在多個模板,請尋求技術支援。

或者,你也可以創建新模板並指定  ingest pipeline

PUT _template/cluster-logs-esa–2023-25-redaction
{
  "index_patterns" : ["cluster-logs-*"],
  "order" : 99,
  "settings": {"default_pipeline": "redact-esa–2023-25"}
}

下次執行索引時,message 欄位會回傳 「redacted」,這時就能依照下方步驟將日誌檔案中的機敏資料刪除。

刪除儲存於日誌檔案的機敏資料

相同的 Ingest Pipeline 能夠與 Update By Query API 結合,從而刪除日誌檔案中的機敏資料。這個方式適用於所有 Elastic 的部署方式,例如:使用 Elastic Cloud 並啟用自訂監控群集、自建 Kibana、 ECE 和 ECK。

用下方 Pipeline 重複查詢所有具有機敏資料的 Kibana 日誌索引,並重複此操作。

POST {environment-specific-logging-index}/_update_by_query?pipeline=redact-esa–2023-25&allow_no_indices=false&wait_for_completion=false&expand_wildcards=all&conflicts=proceed
{
  "sort": [
    {
      "@timestamp": {
        "order": "desc",
        "unmapped_type": "boolean"
      }
    }
  ],
  "query": {
    "bool": {
      "filter": [
        {
          "bool": {
            "should": [
              {
                "match_phrase": {
                  "message": "headers"
                }
              }
            ],
            "minimum_should_match": 1
          }
        },
        {
          "bool": {
            "should": [
              {
                "match_phrase": {
                  "message": "x-elastic-product-origin"
                }
              }
            ],
            "minimum_should_match": 1
          }
        },
        {
          "bool": {
            "should": [
              {
                "match_phrase": {
                  "message": "authorization"
                }
              }
            ],
            "minimum_should_match": 1
          }
        }
      ]
    }
  }
}

最後,使用 GET /_tasks/{taskId from above request} 來檢查 update_by_query 是否順利執行。


本文章為歐立威科技整理原廠官方文件與網路資源,並非即時更新,僅供使用者參考,使用者應自行審慎評估自身環境及官方最新建議以採取最佳行動,若需要任何技術支援歡迎聯絡我們

Related Posts