Marcus1337
VIP Members
-
01/04/2021
-
62
-
76 bài viết
Khai thác SSRF đến RCE
Chào các bạn,
Đã lâu rồi mình không "cho ra lò" bài chuyên môn nào, chắc các bạn đợi lâu lắm nhỉ
Hôm nay mình sẽ comeback với 1 bài viết phân tích lỗ hổng. Mong rằng bài viết này sẽ cung cấp nhiều thông tin bổ ích cho các bạn. Chúng ta cùng bắt đầu nhé.
Trong bài viết này, mình sẽ cùng các bạn phân tích về lỗ hổng SSRF (Server Side Request Forgery). Tuy nhiên, mình sẽ không đi quá sâu mà chỉ phân tích và làm ví dụ nhỏ để các bạn hiểu được cơ bản về SSRF. Nếu cần tìm hiểu kỹ càng hơn, các bạn nên đọc thêm và làm thêm các lab cụ thể, ví dụ như bài viết mình giới thiệu ở đây nhé.
Về định nghĩa hàn lâm thì SSRF (Server Side Request Forgery) hay còn gọi là tấn công yêu cầu giả mạo từ phía máy chủ cho phép kẻ tấn công thay đổi tham số được sử dụng trên ứng dụng web để tạo hoặc kiểm soát các yêu cầu từ máy chủ dễ bị tấn công.
Nếu định nghĩa này quá sách vở và khó hiểu thì để mình giúp các bạn dễ hình dung thông quá ví dụ trực quan này nhé:
Nguyễn Văn Tèo là một lãnh đạo cấp cao trong giới yang hồ. Tèo được bảo vệ nghiêm ngặt 24/7, không ai có thể tiếp cận được. Tuy nhiên ông Tèo lại đam mê săn sale online nên luôn có một anh shipper đẹp trai, trung thành tên Tí có quyền lấy hàng đưa vào cho tất cả thành viên trong băng đảng trong đó có Tèo. Lúc này đầu vào ta có sẽ gói hàng, Tí là người trung gian, mục tiêu người nhận cuối cùng là Tèo.
Một ngày đẹp trời như bao ngày, anh Tí lại đi phát hàng săn sale. Tuy nhiên trong giỏ hàng có 1 gói hàng dành riêng cho Tèo. Nhưng không ngờ rằng món hàng bình thường ông Tèo đặt đã bị đánh tráo thành một quả bom nổ chậm. Vì tin tưởng anh shipper ruột nên ông Tèo mở luôn gói hàng mà không kiểm tra. Và Bùm... Ông Nguyễn Văn Tèo, hưởng dương 53 tuổi.
Rõ ràng câu chuyện ở đây là khi anh Tí bị lợi dụng, thì việc ám sát ông Tèo chẳng cần vượt qua bất kỳ lớp bảo vệ nghiêm ngặt nào nữa.
Cũng giống như ví dụ ở trên, với SSRF, kẻ tấn công sẽ đóng vai trò là người gửi. Server máy chủ là nạn nhân bị lợi dụng như anh shipper đẹp trai. Và ông Tèo chính là những máy chủ có quyền truy cập đến.
Như vậy, ta có thể thấy điều kiện cần để xảy ra lỗi SSRF là xuất hiện điểm đầu vào từ người dùng và server sẽ dùng tham số đầu vào này để tạo request đến một server dịch vụ khác. Còn điều kiện đủ là server không validate tham số hoặc validate sai dẫn đến đầu vào từ phía người dùng có thể kiểm soát được đầu ra khi web server phát sinh request. Do đó để kiểm tra và phát hiện lỗi SSRF cần chú ý đến 2 điều kiện này.
SSRF sẽ lợi dụng quyền của webserver để phát sinh request tiếp. Nên mức độ ảnh hưởng của lỗi SSRF trên các hệ thống khác nhau là khác nhau. Nó phụ thuộc vào từ web server đó có quyền truy cập được đến những đâu? Cũng giống như ví dụ ở trên, nếu Tèo chỉ có duy nhất quyền chuyển tiếp gói hàng đến một nhân viên khác kiểm tra thì mức độ nguy hiểm sẽ thấp hơn nhiều.
Tất nhiên lý thuyết cũng chỉ là lý thuyết. Để làm rõ hơn ta sẽ cùng nhau làm một ví dụ trên root-me về trường hợp SSRF → RCE.
Website này sẽ nhận đầu vào là 1 url và trả về cho ta kết quả khi truy cập đến url đó.
Dạng input này thường nhìn vào sẽ có 2 khả năng lỗi hay xảy ra nhất là Command Injection khi url truyền vào được truyền vào lệnh curl để tạo 1 command request của hệ thống. Khả năng thứ 2 đó là SSRF
Điều kiện cần client có thể gửi tham số url và server dựa vào tham số đó truy cập đến website lấy response và trả lại cho mình. Thế nên mình chỉ cần kiểm tra điều kiện đủ là mình có thể khiến cho server truy cập đến mọi địa chỉ mình truyền vào hay không? ( Kiểm tra việc server validate điều kiện).
Về việc nên truyền tham số là gì và các dạng tấn công các bạn có thể đọc thêm ở đây
Ta sẽ thử truyền vào payload file:///etc/passwd để thử đọc file có trên web server bằng cách sử dụng giao thức đọc file
Ta đọc được kết quả của file passwd chứng tỏ server không validate tham số url đầu vào và thực hiện mọi request dựa vào tham số url mà client gửi lên do đó sẽ có lỗi SSRF. Việc còn lại là mình cần làm là xem mình có thể lợi dụng được gì để khai thác lỗi này lên mức cao hơn hay không?
Đầu tiên ta sẽ xem ở trên con web server này đang mở những cổng dịch vụ gì. Về cơ bản sẽ có rất nhiều cổng dịch vụ chỉ mở chạy local, hoặc bị chặn với firewall nên bình thường với vai trò client chúng ta sẽ không truy cập trực tiếp được đến mấy dịch vụ đó. Tuy nhiên ở đây với SSRF nên lợi dụng web server ta có thể truy cập được đến các port local. Ta sẽ sử dụng intruder để làm việc đó:
Nguyên lý của intruder trên là ta sẽ tạo request lần lượt tới các port local từ 1→ 65535 sau đó lọc response trả về để khẳng định port đó mở hay đóng. Ví dụ response có từ Connection refused thì port đó đang đóng các response không có chữ đó thì là các port mở.
Sau khi chạy intruder thì ta tìm được các port 22, 25, 80, 6379 đang mở trên server
Port 6379 là cổng đang chạy redis. Mà hên cái nữa là Redis có thể bị lợi dụng để khai thác RCE chi tiết theo bài viết ở đây https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery.
Ở đây có 1 chú ý ở payload exploit redis ở trên các bác sẽ thấy bắt đầu bằng gopher://xxxxxx mà không phải là http(s)://xxxxxx tại sao thế? Ở đây khi thực hiện 1 request thì cơ bản 1 máy tính cần biết 2 thứ là giao thức và địa chỉ. Giao thức là cái để nói cho máy tính biết là giao thức thực hiện ở request đó là gì để máy tính tiến hành bọc lại gói tin bằng giao thức tương ứng, còn đích đến là cho máy tính biết cần request đến đâu. Thì khi khai thác các lỗi liên quan đến ssrf mình cần biết là lựa chọn các giao thức thích hợp để đạt được mục đích của mình. Như ở ví dụ trên mình đọc file /etc/password thì mình sẽ dùng giao thức file : file:/etc/passwd ở payload còn nếu dùng http://etc/passwd chắc chắn mình sẽ không thu được gì? Về list scheme uri thì sẽ có rất nhiều các bác có thể đọc thêm ở đây . Tuy nhiên trong SSRF thường sẽ sử dụng các giao thức phổ biến được note rõ ở bài viết này các bác đọc thêm nhé.
Ở đây có 1 giao thức khá đặc biệt được dùng cho exploit redis ở trên là Gopher:// . Sử dụng giao thức này, bạn có thể chỉ định ip, cổng và bytes để kết nối. Về cơ bản với protocol Gopher:// bạn có thể khai thác một SSRF để giao tiếp với bất kỳ máy chủ TCP nào .
Ở ví dụ này khi khai thác redis ta sẽ dùng giao thức gopher để kết nối đến port 6379 và gửi payload exploit đến cổng này.
Các bạn có thể tạo payload bằng tay. Còn trong trường hợp này, mình bị thần lười đánh gục nên mình sẽ chọn dùng "mì ăn liền" https://github.com/tarunkant/Gopherus.git. - công cụ hỗ trợ tạo payload để exploit redis qua SSRF.
Và đây là kết quả:
Đây là một bài khá đơn giản về SSRF khi đầu vào tham số url không bị validate và service khai thác lên root có thể tìm thấy dễ dàng. Tuy nhiên, trong thực tế, đối với SSRF nhiều khi mình phải tìm cách bypass các hàm validate url để có thể tạo request theo ý mình. Và một cái khó nữa là sau khi có SSRF cần làm gì để nâng lên các lỗi cao hơn tận dụng tốt lỗi SSRF?
Đã lâu rồi mình không "cho ra lò" bài chuyên môn nào, chắc các bạn đợi lâu lắm nhỉ
Hôm nay mình sẽ comeback với 1 bài viết phân tích lỗ hổng. Mong rằng bài viết này sẽ cung cấp nhiều thông tin bổ ích cho các bạn. Chúng ta cùng bắt đầu nhé.Trong bài viết này, mình sẽ cùng các bạn phân tích về lỗ hổng SSRF (Server Side Request Forgery). Tuy nhiên, mình sẽ không đi quá sâu mà chỉ phân tích và làm ví dụ nhỏ để các bạn hiểu được cơ bản về SSRF. Nếu cần tìm hiểu kỹ càng hơn, các bạn nên đọc thêm và làm thêm các lab cụ thể, ví dụ như bài viết mình giới thiệu ở đây nhé.
Về định nghĩa hàn lâm thì SSRF (Server Side Request Forgery) hay còn gọi là tấn công yêu cầu giả mạo từ phía máy chủ cho phép kẻ tấn công thay đổi tham số được sử dụng trên ứng dụng web để tạo hoặc kiểm soát các yêu cầu từ máy chủ dễ bị tấn công.
Nếu định nghĩa này quá sách vở và khó hiểu thì để mình giúp các bạn dễ hình dung thông quá ví dụ trực quan này nhé:
Nguyễn Văn Tèo là một lãnh đạo cấp cao trong giới yang hồ. Tèo được bảo vệ nghiêm ngặt 24/7, không ai có thể tiếp cận được. Tuy nhiên ông Tèo lại đam mê săn sale online nên luôn có một anh shipper đẹp trai, trung thành tên Tí có quyền lấy hàng đưa vào cho tất cả thành viên trong băng đảng trong đó có Tèo. Lúc này đầu vào ta có sẽ gói hàng, Tí là người trung gian, mục tiêu người nhận cuối cùng là Tèo.
Một ngày đẹp trời như bao ngày, anh Tí lại đi phát hàng săn sale. Tuy nhiên trong giỏ hàng có 1 gói hàng dành riêng cho Tèo. Nhưng không ngờ rằng món hàng bình thường ông Tèo đặt đã bị đánh tráo thành một quả bom nổ chậm. Vì tin tưởng anh shipper ruột nên ông Tèo mở luôn gói hàng mà không kiểm tra. Và Bùm... Ông Nguyễn Văn Tèo, hưởng dương 53 tuổi.
Rõ ràng câu chuyện ở đây là khi anh Tí bị lợi dụng, thì việc ám sát ông Tèo chẳng cần vượt qua bất kỳ lớp bảo vệ nghiêm ngặt nào nữa.
Như vậy, ta có thể thấy điều kiện cần để xảy ra lỗi SSRF là xuất hiện điểm đầu vào từ người dùng và server sẽ dùng tham số đầu vào này để tạo request đến một server dịch vụ khác. Còn điều kiện đủ là server không validate tham số hoặc validate sai dẫn đến đầu vào từ phía người dùng có thể kiểm soát được đầu ra khi web server phát sinh request. Do đó để kiểm tra và phát hiện lỗi SSRF cần chú ý đến 2 điều kiện này.
SSRF sẽ lợi dụng quyền của webserver để phát sinh request tiếp. Nên mức độ ảnh hưởng của lỗi SSRF trên các hệ thống khác nhau là khác nhau. Nó phụ thuộc vào từ web server đó có quyền truy cập được đến những đâu? Cũng giống như ví dụ ở trên, nếu Tèo chỉ có duy nhất quyền chuyển tiếp gói hàng đến một nhân viên khác kiểm tra thì mức độ nguy hiểm sẽ thấp hơn nhiều.
Tất nhiên lý thuyết cũng chỉ là lý thuyết. Để làm rõ hơn ta sẽ cùng nhau làm một ví dụ trên root-me về trường hợp SSRF → RCE.
Website này sẽ nhận đầu vào là 1 url và trả về cho ta kết quả khi truy cập đến url đó.
Dạng input này thường nhìn vào sẽ có 2 khả năng lỗi hay xảy ra nhất là Command Injection khi url truyền vào được truyền vào lệnh curl để tạo 1 command request của hệ thống. Khả năng thứ 2 đó là SSRF
Điều kiện cần client có thể gửi tham số url và server dựa vào tham số đó truy cập đến website lấy response và trả lại cho mình. Thế nên mình chỉ cần kiểm tra điều kiện đủ là mình có thể khiến cho server truy cập đến mọi địa chỉ mình truyền vào hay không? ( Kiểm tra việc server validate điều kiện).
Về việc nên truyền tham số là gì và các dạng tấn công các bạn có thể đọc thêm ở đây
Ta sẽ thử truyền vào payload file:///etc/passwd để thử đọc file có trên web server bằng cách sử dụng giao thức đọc file
Ta đọc được kết quả của file passwd chứng tỏ server không validate tham số url đầu vào và thực hiện mọi request dựa vào tham số url mà client gửi lên do đó sẽ có lỗi SSRF. Việc còn lại là mình cần làm là xem mình có thể lợi dụng được gì để khai thác lỗi này lên mức cao hơn hay không?
Đầu tiên ta sẽ xem ở trên con web server này đang mở những cổng dịch vụ gì. Về cơ bản sẽ có rất nhiều cổng dịch vụ chỉ mở chạy local, hoặc bị chặn với firewall nên bình thường với vai trò client chúng ta sẽ không truy cập trực tiếp được đến mấy dịch vụ đó. Tuy nhiên ở đây với SSRF nên lợi dụng web server ta có thể truy cập được đến các port local. Ta sẽ sử dụng intruder để làm việc đó:
Nguyên lý của intruder trên là ta sẽ tạo request lần lượt tới các port local từ 1→ 65535 sau đó lọc response trả về để khẳng định port đó mở hay đóng. Ví dụ response có từ Connection refused thì port đó đang đóng các response không có chữ đó thì là các port mở.
Sau khi chạy intruder thì ta tìm được các port 22, 25, 80, 6379 đang mở trên server
Port 6379 là cổng đang chạy redis. Mà hên cái nữa là Redis có thể bị lợi dụng để khai thác RCE chi tiết theo bài viết ở đây https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery.
Ở đây có 1 giao thức khá đặc biệt được dùng cho exploit redis ở trên là Gopher:// . Sử dụng giao thức này, bạn có thể chỉ định ip, cổng và bytes để kết nối. Về cơ bản với protocol Gopher:// bạn có thể khai thác một SSRF để giao tiếp với bất kỳ máy chủ TCP nào .
Ở ví dụ này khi khai thác redis ta sẽ dùng giao thức gopher để kết nối đến port 6379 và gửi payload exploit đến cổng này.
Các bạn có thể tạo payload bằng tay. Còn trong trường hợp này, mình bị thần lười đánh gục nên mình sẽ chọn dùng "mì ăn liền" https://github.com/tarunkant/Gopherus.git. - công cụ hỗ trợ tạo payload để exploit redis qua SSRF.
Và đây là kết quả:
Đây là một bài khá đơn giản về SSRF khi đầu vào tham số url không bị validate và service khai thác lên root có thể tìm thấy dễ dàng. Tuy nhiên, trong thực tế, đối với SSRF nhiều khi mình phải tìm cách bypass các hàm validate url để có thể tạo request theo ý mình. Và một cái khó nữa là sau khi có SSRF cần làm gì để nâng lên các lỗi cao hơn tận dụng tốt lỗi SSRF?
Happy Hacking
Chỉnh sửa lần cuối: