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")
-
- 如果使用 Elastic Agent Collection 導入 Kibana 日誌:則 Index 名稱為 logs-kibana.*-default 。
-
- 如果使用 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")。
-
- 如果使用 Elastic Aagent Collection 導入 Kibana 日誌 :則 Index 名稱為 logs-kibana.*-default。
-
- 如果使用 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 中。
-
- 使用 PUT _ingest/pipeline API 來更新 ingest 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 是否順利執行。
本文章為歐立威科技整理原廠官方文件與網路資源,並非即時更新,僅供使用者參考,使用者應自行審慎評估自身環境及官方最新建議以採取最佳行動,若需要任何技術支援歡迎聯絡我們。