Tấn công một công ty bằng cách bypass WAF của công ty thông qua một thiết bị bảo mật khác

Tấn công một công ty bằng cách bypass WAF của công ty thông qua một thiết bị bảo mật khác

[full_width]

Cách hack công ty bằng cách phá vỡ WAF của công ty thông qua việc lạm dụng một thiết bị bảo mật khác và giành được tiền thưởng lỗi

Này đợi đã! Tiền thưởng lỗi và thiết bị bảo mật mạng có điểm gì chung? Thường thì không có gì! Ngược lại, các thiết bị bảo mật cho phép thực hành vá lỗi ảo và tích cực tham gia để giảm số tiền thưởng lỗi cho các nhà nghiên cứu, nhưng đây là một câu chuyện ngược lại: tiền thưởng lỗi đã được trả cho chúng tôi nhờ một thiết bị bảo mật được định cấu hình sai. Chúng tôi sẽ không tiết lộ tên của công ty bị ảnh hưởng (ngoại trừ đó là Fortune 500) cũng không phải là một trong những thành phần dễ bị tổn thương. Tuy nhiên, chúng ta sẽ nói về kỹ thuật được sử dụng, bởi vì nó đơn giản đến mức đáng kinh ngạc.

Sự quan sát

Tất cả đã bắt đầu bằng cách duyệt những gì tại thời điểm đó chúng ta thậm chí còn chưa biết là mục tiêu có giá trị, chúng ta hãy gọi nó là https://targetdomainHồi. Gần như tình cờ, chúng tôi nhận thấy rằng một tên miền phụ chịu trách nhiệm xác thực trên trang web đó đã tiết lộ một số tài nguyên CSS và Javascript được quy cho một thành phần Java nổi tiếng là dễ bị tổn thương đối với RCE (Thực thi mã từ xa).

Điều kỳ lạ là bằng cách duyệt qua điểm cuối bị ảnh hưởng (một cái gì đó giống như Hồi, ) chúng tôi đã nhận được phản hồi HTTP 404 từ máy chủ, điều này khiến chúng tôi nghi ngờ sự hiện diện của Tường lửa ứng dụng Web. Tại sao điểm cuối cụ thể đó không thể truy cập được nếu tài nguyên trang trí nó (như tệp .css và .js ) là? Điều này rõ ràng khiến chúng tôi tin rằng chúng tôi đã ở trước một WAF. Sau một vài yêu cầu, tất cả đều bị chặn, chúng tôi đã xác nhận một số loại quy tắc WAF thực sự ngăn chúng tôi đạt đến điểm cuối mục tiêu.https://auth.targetdomain/vulnerable_endpoint?param=malicious_RCE_payload

Điều kỳ lạ của người Viking

Bằng cách duyệt một trong những ứng dụng được lưu trữ (tức là ), chúng tôi được mời xác thực với Chế độ . Trong quá trình xác thực, chúng tôi nhận thấy một điều kỳ lạ khác. Tại một thời điểm nhất định, chúng tôi được chuyển hướng đến một URL như:https://targetdomain/appnamehttps//auth.targetdomain

https//targetdomain/?cfru=aHR0cHM6Ly90YXJnZXRkb21haW4vYXBwbmFtZQ==

với aHR0cHM6Ly90YXJnZXRkb21haW4vYXBwbmFtZQ==mã số rõ ràng là một chuỗi mã hóa base64. Tải trọng cơ sở64, sau khi giải mã, cho thấy không có gì khác là URL mà chúng tôi ban đầu đã yêu cầu quyền truy cập trước khi bắt đầu xác thực, đó là siêu hiệu ứng .https://targetdomain/appname

Nhưng thực sự thì cfruthông số đó là gì? Một số nghiên cứu nhanh trên mạng cho thấy nó là một phần của công nghệ lọc web Bluecoat, một thiết bị máy chủ proxy khét tiếng. Vì vậy, điều này cho chúng tôi biết thêm một chút về cơ sở hạ tầng từ xa. Các yêu cầu HTTP chúng tôi gửi đến mục tiêu chéo ít nhất một thiết bị WAF và máy chủ proxy Bluecoat trước khi đến máy chủ ứng dụng web và máy chủ ứng dụng, như được xây dựng lại bên dưới.

Ý tưởng

Một bóng đèn đã sáng lên trên đầu chúng tôi khi chúng tôi phát hiện ra rằng cfruthông số này có thể truy cập công khai, cụ thể là không yêu cầu xác thực cổng thông tin để chuyển tải trọng của chúng tôi đến nó. Do đó, chúng tôi đã bắt đầu mã hóa các URL cơ sở64 của các tên miền bên ngoài dưới sự kiểm soát của chúng tôi và cung cấp cfrutham số trong sách ăn liền với các chuỗi này. Hy vọng là để kích hoạt một số loại SSRF. Những gì chúng tôi nhận được ở cuối là tốt hơn nhiều.

Thật không may, tại thời điểm cụ thể đó, chúng tôi đã không nhận lại bất kỳ yêu cầu HTTP nào. Tuy nhiên, trong các máy tiếp xúc với internet của chúng tôi, chúng tôi có thể thấy quá trình phân giải DNS được bắt đầu từ mục tiêu tên miền của Wikipedia. Có vẻ như các kết nối gửi đi TCP từ trang web mục tiêu đã bị cấm. Điều duy nhất được ủy quyền là, như đã nói, lưu lượng DNS. Sau đó, thay vì cố gắng để kích hoạt yêu cầu SSRF đến máy chủ bên ngoài chúng ta chuyển sự chú ý của chúng tôi để các tên miền phụ bên trong ( , , , vv ...).https://auth.targetdomainhttps://blog.targetdomainhttps://www.targetdomain

Chúng tôi bắt đầu mã hóa một vài trong số các URL này vào cfrutham số của Cameron và gần như ngay lập tức nhận thấy sự kỳ lạ khác. Đối với một số URL, chúng tôi nhận được chuyển hướng HTTP 302 trở lại. Đối với một số người khác, chúng tôi không. Trong trường hợp sau này, thay vào đó, phần thân HTTP trong phần trả lời chứa mã HTML của tài nguyên được yêu cầu, như thể Bluecoat đã chuyển tiếp yêu cầu đến tài nguyên đích và trả lại nội dung của nó cho chúng tôi bằng cách hoạt động như một proxy web. Quan trọng nhất, hành vi này cũng được quan sát thấy khi chúng tôi mã hóa trong cfrutham số của Cảnh sát, tên miền phụ chịu trách nhiệm xác thực cổng thông tin ( ), cụ thể là hành vi mà chúng tôi tin là đang lưu trữ một thành phần Java dễ bị RCE.https//auth.targetdomain

Bước ngoặt

Đây là bước ngoặt! Chúng tôi đã đưa ra giả định sau đây. Nếu tài nguyên

https://auth.targetdomain/vulnerable_endpoint?param=malicious_RCE_payload

được duyệt trực tiếp, yêu cầu HTTP của chúng tôi ngay lập tức gửi đến WAF, nơi có cấu hình quy tắc nhận ra nỗ lực độc hại (tải trọng độc hại được chỉ ra bởi siêu hiệu param) và gửi lại lỗi HTTP 404, thực tế là chặn cuộc tấn công.

Nhưng nếu chúng ta mã hóa trong cơ sở64 thì URL

https://auth.targetdomain/vulnerable_endpoint?param=malicious_RCE_payload

tạo ra chuỗi base64 sau

“ aHR0cHM6Ly9hdXRoLnRhcmdldGRvbWFpbi92dWxuZXJhYmxlX2VuZHBvaW50P3BhcmFtPW1hbGljaW91c19SQ0VfcGF5bG9hZA==“

và truyền nó cho cfrutham số của bản thân như sau?

https//targetdomain/?cfru=aHR0cHM6Ly9hdXRoLnRhcmdldGRvbWFpbi92dWxuZXJhYmxlX2VuZHBvaW50P3BhcmFtPW1hbGljaW91c19SQ0VfcGF5bG9hZA==

Trong trường hợp của chúng ta:

1. Yêu cầu vượt qua WAF mà không có gì để phàn nàn.
2. Sau đó, nó đã đến thiết bị Bluecoat, lần lượt giải mã cfruthông số Base64 và đưa ra yêu cầu GET cho máy chủ nội bộ https://auth.targetdomain/vulnerable_endpoint?param=malicious_RCE_payload.
3. Điều này lần lượt kích hoạt lỗ hổng.

Chơi lô tô!

Và chơi lô tô! Chúng ta có thể thấy đầu ra của tải trọng độc hại của chúng tôi (không có gì khác ngoài hostnamelệnh của Wap () được thực hiện thông qua DNS (các kết nối TCP gửi đến máy chủ lưu trữ của chúng tôi trên internet thực sự đã bị chặn như đã nói trước đó).

Hơn nữa, chúng tôi đã chơi một chút với tải trọng độc hại của mình để có đầu ra của các lệnh được tiêm được trả lại trực tiếp như một phần của tiêu đề HTTP trong phản hồi của máy chủ.

Phần kết luận

Có ít nhất hai sai lầm có thể được phát hiện ở đây:

• Thiết bị bluecoat hoạt động như một yêu cầu Chuyển tiếp trực tuyến, thay vì trả lời bằng chuyển hướng HTTP như đã xảy ra đối với các URL khác (điều đó sẽ khiến các yêu cầu khách tiếp theo bị WAF bắt và chặn).

• Không có quy tắc nào được triển khai ở cấp WAF đã giải mã cfruthông số cơ sở 64 trước khi chuyển nó sang thiết bị Bluecoat, để phân tích xem nội dung của yêu cầu có khớp với một trong các quy tắc chặn được triển khai trong chính WAF hay không.

Tốt cho chúng ta! Chúng tôi đã thông báo lỗ hổng cho nhà cung cấp ngay lập tức và họ quyết định nhận ra cho chúng tôi một tiền thưởng lỗi tốt đẹp!

Điểm mấu chốt ở đây là vá lỗi ảo là ổn nếu bạn cần thêm một chút thời gian trước khi sửa một lỗ hổng nghiêm trọng. Nhưng nếu bạn sử dụng nó thay cho bản vá thực sự, thì đó chỉ là câu hỏi về thời gian trước khi bạn bị hack.

Nếu bạn muốn biết thêm về các kỹ thuật khai thác tương tự và các thủ thuật hack web khác, hãy xem các khóa học Blackhat Las Vegas của chúng tôi vào ngày 1-2 tháng 8 và 3-4 tháng 8 năm 2020, bởi vì đây sẽ là một trong những chủ đề được đề cập ở đó.

Nguồn: https://www.redtimmy.com/web-application-hacking/how-to-hack-a-company-by-circumventing-its-waf-through-the-abuse-of-a-different-security-appliance-and-win-bug-bounties/?fbclid=IwAR2p0AxD3OvdV7k6WEhomAVgx0e73qQrIAdOBGdh6S7oz_zalbfg2_OjRU0