krone
VIP Members
-
26/07/2016
-
141
-
259 bài viết
Phân tích lỗ hổng LFI trên Kibana
Dưới đây là phân tích về lỗ hổng tồn tại trên một vài phiên bản của Kibana trong ELK stack, lỗ hổng này được phát hiện bởi CyberArk Labs, được công bố trong CVE-2018-17246 áp dụng cho các phiên bản dưới 6.4.2 của Kibana. Lỗ hổng đã được Elastic vá ngay sau đó phiên bản 6.4.3.
Kibana là gì ?
Kibana là một open source được xây dựng bằng nodejs chạy như là một web UI. Kibana kết hợp với Elasticsearch để phục vụ cho các tác vụ tìm kiếm, phân tích big data và log stream phức tạp, khiến cho việc visualize và graphic dễ dàng hơn cho end user. Kibana có nhiều chức năng, mỗi chức năng có một plugin khác nhau, core plugin được mặc định cài đặt.
Console của Kibana là một basic plugin đi kèm trong mục "Dev Tools". Plugin này cung cấp giao diện người dùng để tương tác với API Elaticsearch REST mà không cần sử dụng cURL, cho phép người dùng viết các truy vấn JSON và nhận phản hồi thông qua giao diện web của Kibana. Console dễ bị tấn công bằng LFI attack như mô tả bên dưới đây.
Function bị lỗi ?
Burpsuite là một trong những công cụ kiểm tra thâm nhập hộp xám hiệu quả nhất có sẵn để kiểm tra các ứng dụng web vì nó cho phép các nhà nghiên cứu thấy giao tiếp chuyển từ máy khách sang máy chủ. Trong ví dụ dưới đây, chúng ta sử dụng Burp Suite của PortSwigger để ánh xạ bề mặt tấn công tiềm năng. Có một khối lượng lớn thông tin được trao đổi, nhưng một yêu cầu HTTP cụ thể đã thu hút sự chú ý của chúng tôi:
Request này tham chiếu đến máy chủ API. Có lẽ chúng ta có thể thao tác một số chức năng API để làm những tác vụ khác, nếu đúng như vậy, điều đó có nghĩa là có một phiên bản cũ hơn mà có lẽ chúng ta có thể hạ cấp một cái gì đó xuống và khai thác lỗ hổng chưa được vá?
Thử nghiệm với một số input, hoặc có thể là LFI, kết quả được theo dõi trong log của Kibana:
Parameter "apis" cho phép tấn công dạng Path Traversal, cat được các file local. File "/etc/passwd" hầu như luôn tồn tại trên các hệ thống Linux và là mục tiêu chính để kiểm tra. Để hiểu đầy đủ những gì đang xảy ra và để xem liệu trên thực tế, chúng ta có thể khai thác lỗ hổng này hay không, tốt nhất là đọc "code".
Từ nội dung của Log, ta có thể theo dõi một số file trong source của Kibana.
Và trong cùng một thư mục, tìm thấy một số điểm thú vị khác:
Vì vậy, bây giờ ta biết tham số API đó là gì - tên của tệp JavaScript mà chúng ta sẽ yêu cầu và gọi hàm asJson. Ta có thể thấy rằng không có xác nhận về nội dung của biến được gọi là tên và do đó, người dùng có thể nhập bất cứ thứ gì mình muốn.
Vì vậy, đây là - lỗ hổng, một cách để tải mã JavaScript đã có trên máy chủ. Nhưng ta có thể làm gì với nó, vì không có chức năng asJson, ta nhận được một thông báo lỗi và không có gì khác. Trong trường hợp này, ta có thể truy cập mọi mô-đun trên đĩa của máy chủ, nó sẽ được thực thi một lần và chỉ một lần, và việc thực thi sẽ được mở rộng để mã chạy có thể truy cập mọi đối tượng từ nó.
Nơi đầu tiên để tìm kiếm các tập lệnh Node.js là trong các tệp của chính Kibana. Dựa trên lời giải thích ở trên, rõ ràng việc chạy ứng dụng Node.js đòi hỏi rất nhiều tệp và nếu các tệp đó thuộc về Kibana, chúng có khả năng ảnh hưởng đến hoạt động của Kibana.
Module đầu tiên là “{KIBANA_PATH}/src/docs/docs_repo.js”:
Để load được module thứ 2, require có thể dẫn đến 3 đường dẫn. Hàm exit được gọi, nhưng nếu nó không thực sự hoạt động, nó có thể giúp ta ghi đề bộ nhớ cache:
Và sau đó thử nghiệm với cli:
Có thể coi đây là Dos buộc server Kibana phải gọi plugin "cli" trong hệ thống. Và kết cả của chúng ta có được sau đây:
Thông thường, Kibana được triển khai cùng với các ứng dụng khác (ví dụ: một ứng dụng ghi nhật ký của nó vào Elaticsearch và Kibana cho phép người dùng xem chúng). Trong các trường hợp này, đôi khi chúng ta có thể sử dụng ứng dụng để tải lên tệp JavaScript, chẳng hạn như shell reverse Node.js:
Kỹ thuật "Path Traversal" cho phép truy cập mọi vị trí trên máy chủ mà Kibana có quyền. Chỉ như thế này:
Và trong file Log:
Chúng ta có thể tạo ra một máy chủ lắng nghe để trực tiếp thực thi shell:
Tổng kết
LFI là một lỗ hổng đã biết đôi khi - và sai lầm - được coi là một lỗ hổng cũ.Thực tế là trong khi các nhà phát triển phần mềm và kiến trúc sư có thể không nghĩ về LFI, những kẻ tấn công đang ngày càng xem xét lại kỹ thuật này và săn lùng các lỗ hổng tồn tại trên các ứng dụng web phổ biến như Kibana.
Bài đăng này đã minh họa một lỗ hổng LFI quan trọng trong Kibana cho phép kẻ tấn công chạy mã cục bộ trên chính máy chủ.
Tài liệu tham khảo:
Kibana là gì ?
Kibana là một open source được xây dựng bằng nodejs chạy như là một web UI. Kibana kết hợp với Elasticsearch để phục vụ cho các tác vụ tìm kiếm, phân tích big data và log stream phức tạp, khiến cho việc visualize và graphic dễ dàng hơn cho end user. Kibana có nhiều chức năng, mỗi chức năng có một plugin khác nhau, core plugin được mặc định cài đặt.
Console của Kibana là một basic plugin đi kèm trong mục "Dev Tools". Plugin này cung cấp giao diện người dùng để tương tác với API Elaticsearch REST mà không cần sử dụng cURL, cho phép người dùng viết các truy vấn JSON và nhận phản hồi thông qua giao diện web của Kibana. Console dễ bị tấn công bằng LFI attack như mô tả bên dưới đây.
Function bị lỗi ?
Burpsuite là một trong những công cụ kiểm tra thâm nhập hộp xám hiệu quả nhất có sẵn để kiểm tra các ứng dụng web vì nó cho phép các nhà nghiên cứu thấy giao tiếp chuyển từ máy khách sang máy chủ. Trong ví dụ dưới đây, chúng ta sử dụng Burp Suite của PortSwigger để ánh xạ bề mặt tấn công tiềm năng. Có một khối lượng lớn thông tin được trao đổi, nhưng một yêu cầu HTTP cụ thể đã thu hút sự chú ý của chúng tôi:
Request này tham chiếu đến máy chủ API. Có lẽ chúng ta có thể thao tác một số chức năng API để làm những tác vụ khác, nếu đúng như vậy, điều đó có nghĩa là có một phiên bản cũ hơn mà có lẽ chúng ta có thể hạ cấp một cái gì đó xuống và khai thác lỗ hổng chưa được vá?
Thử nghiệm với một số input, hoặc có thể là LFI, kết quả được theo dõi trong log của Kibana:
Parameter "apis" cho phép tấn công dạng Path Traversal, cat được các file local. File "/etc/passwd" hầu như luôn tồn tại trên các hệ thống Linux và là mục tiêu chính để kiểm tra. Để hiểu đầy đủ những gì đang xảy ra và để xem liệu trên thực tế, chúng ta có thể khai thác lỗ hổng này hay không, tốt nhất là đọc "code".
Từ nội dung của Log, ta có thể theo dõi một số file trong source của Kibana.
Và trong cùng một thư mục, tìm thấy một số điểm thú vị khác:
Vì vậy, bây giờ ta biết tham số API đó là gì - tên của tệp JavaScript mà chúng ta sẽ yêu cầu và gọi hàm asJson. Ta có thể thấy rằng không có xác nhận về nội dung của biến được gọi là tên và do đó, người dùng có thể nhập bất cứ thứ gì mình muốn.
Vì vậy, đây là - lỗ hổng, một cách để tải mã JavaScript đã có trên máy chủ. Nhưng ta có thể làm gì với nó, vì không có chức năng asJson, ta nhận được một thông báo lỗi và không có gì khác. Trong trường hợp này, ta có thể truy cập mọi mô-đun trên đĩa của máy chủ, nó sẽ được thực thi một lần và chỉ một lần, và việc thực thi sẽ được mở rộng để mã chạy có thể truy cập mọi đối tượng từ nó.
Nơi đầu tiên để tìm kiếm các tập lệnh Node.js là trong các tệp của chính Kibana. Dựa trên lời giải thích ở trên, rõ ràng việc chạy ứng dụng Node.js đòi hỏi rất nhiều tệp và nếu các tệp đó thuộc về Kibana, chúng có khả năng ảnh hưởng đến hoạt động của Kibana.
Module đầu tiên là “{KIBANA_PATH}/src/docs/docs_repo.js”:
- {KIBANA_PATH}/src/cli_plugin
- {KIBANA_PATH}/src/cli_plugin/index.js
- {KIBANA_PATH}/src/cli_plugin/cli.js
Và sau đó thử nghiệm với cli:
Có thể coi đây là Dos buộc server Kibana phải gọi plugin "cli" trong hệ thống. Và kết cả của chúng ta có được sau đây:
Thông thường, Kibana được triển khai cùng với các ứng dụng khác (ví dụ: một ứng dụng ghi nhật ký của nó vào Elaticsearch và Kibana cho phép người dùng xem chúng). Trong các trường hợp này, đôi khi chúng ta có thể sử dụng ứng dụng để tải lên tệp JavaScript, chẳng hạn như shell reverse Node.js:
Kỹ thuật "Path Traversal" cho phép truy cập mọi vị trí trên máy chủ mà Kibana có quyền. Chỉ như thế này:
Và trong file Log:
Chúng ta có thể tạo ra một máy chủ lắng nghe để trực tiếp thực thi shell:
Tổng kết
LFI là một lỗ hổng đã biết đôi khi - và sai lầm - được coi là một lỗ hổng cũ.Thực tế là trong khi các nhà phát triển phần mềm và kiến trúc sư có thể không nghĩ về LFI, những kẻ tấn công đang ngày càng xem xét lại kỹ thuật này và săn lùng các lỗ hổng tồn tại trên các ứng dụng web phổ biến như Kibana.
Bài đăng này đã minh họa một lỗ hổng LFI quan trọng trong Kibana cho phép kẻ tấn công chạy mã cục bộ trên chính máy chủ.
Tài liệu tham khảo:
- https://nodejs.org/api/modules.html
- https://medium.freecodecamp.org/requiring-modules-in-node-js-everything-you-need-to-know-e7fbd119be8
- http://fredkschott.com/post/2014/06/require-and-the-module-system/
- https://github.com/appsecco/vulnerable-apps/tree/master/node-reverse-shell
- https://github.com/elastic/kibana/find/master
- https://portswigger.net/burp/freedownload/
- https://discuss.elastic.co/t/elastic-stack-6-4-3-and-5-6-13-security-update/155594
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17246
Chỉnh sửa lần cuối bởi người điều hành: