Linh tinh về Oracle Business Intelligence [part 1]
Hồi cuối năm ngoái, sau khi đã farm mòn hết cả cuốc với Weblogic thì team bọn mình quyết định lấy 1 product nữa của Oracle ra mổ xẻ, đó là Oracle Business Intelligence, hay gọi ngắn hơn là Oracle BI.
Và đây là kết quả của bọn mình (7/8 ( ͡° ͜ʖ ͡°) )
Trong số đó có:
- 2 bug của mình
- 2 bug của Đức (PeterJson)
- 3 bug của Quỳnh
Thực ra bọn mình đã report những bug này từ rất rất lâu, (gần được 1 năm), nhưng do quá trình xử lý của ZDI với Oracle quá lâu nên tới tháng 7 vừa rồi thì tất cả các bug mới được fix và có advisory. (Chấp nhận lâu hơn chút vì rice shirt rice money =)))).
Lý do bọn mình chọn target này cũng giống như những bài trước thôi, trong quá trình đi pentest đôi khi sẽ gặp những target sử dụng nền tảng này. Nếu như ăn may target này chưa từng bị đặt vào scope masscan của các researcher hunter thì những 1day/0day trở nên hữu dụng, và không phải trả về một report xấu (report CSP, SSL Version…).
Vào thời điểm bọn mình bắt tay vào làm — tháng 11/2020, là khi weblogic vừa vá một lỗ hổng cho phép RCE chỉ với 1 GET requests. Mà weblogic lại chính là nền tảng để cài đặt Oracle BI, có thể lợi dụng vào đó để tìm kiếm và kết hợp những lỗi của Oracle BI với Weblogic,
Hiểu đơn giản là phạm vi tìm lỗi bây giờ đã rộng hơn, thoải mái hơn trong việc kết hợp các chain lỗi lại. Giống như hồi mình làm CVE-2020–2555, cái mình hơn người khác đó là phạm vi tìm lỗi của mình rộng hơn, lan sang cả lib của Coherence, thứ mà những người trước đó chưa nghĩ tới, sau khi public thì có tới hơn chục lỗ hổng RCE khác liên quan tới coherence được phát hiện.
Trong bài viết này mình sẽ viết về 3 lỗ hổng XXE mà mình phát hiện cùng với những Attack Vector có thể xảy ra đối với những lỗ hổng này. Về những lỗ hổng khác, sẽ được tiếp tục tại phần sau của series này!
#SETUP
Version mình chọn để làm lab như sau:
- Weblogic: 12.2.1.3.0
- BIEE: 12.2.1.4.0
Việc setup món này cũng khá là đau đầu khi mới tìm hiểu, cần một con máy cấu hình tầm trung và một cái đầu lạnh để kiên nhẫn khi setup,
Mình có tham khảo guide này để setup: https://web.archive.org/web/20180325182933/http://www.catgovind.com/obiee/step-by-step-obiee-12c-installation-on-windows-oracle-bi-publisher-installation-and-oracle-bi-analytic-installation/ (web chính đã down)
Một lưu ý nhỏ là bắt buộc phải set IP tĩnh, nếu ip bị thay đổi sẽ dẫn tới việc cả hệ thống không chạy được nữa.
Tại thời điểm viết thì mình cũng ko nhớ nhiều lắm về những lưu ý khi setup, bạn đọc cố gắng follow và tự fix nhé =))).
Để debug BI thì cũng khá đơn giản, có thể setup từ GUI được,
Sau khi tất cả các service đều đã lên, truy cập vào weblogic console tại http://localhost:9500/console/
Chọn bi>Environment>Servers:
Tại đây sẽ show lên 2 server đang chạy, 1 là AdminServer (weblogic), và bi_server (đây chính là server của BI):
Để debug BI, chọn sửa config của bi_server, rồi vào tiếp Configuration > Server Start, click Lock & Edit để chỉnh sửa config:
Tại đây có một phần config Arguments khi start server, thêm các thông số để debug vào đây, rồi restart bi_server là port debug sẽ listen!
- Lưu ý, weblogic chạy ở một server khác so với bi_server, nên nếu muốn debug weblogic thì phải lặp lại bước setup như trên đối với AdminServer!
Môi trường lab của mình setup hơi đặc thù một chút:
- BI Server được apply patch mới nhất của Oracle vào thời điểm đó — October Patch.
- Weblogic: no patch
Lý do mình không patch weblogic là thế này:
Patch của Oracle BI sẽ được tách riêng biệt với patch của weblogic,
Nghĩa là nếu patch Oracle BI thì bạn chỉ patch mỗi BI Server mà thôi, những lỗ hổng trên weblogic vẫn sẽ còn tồn tại.
Do case này mình gặp khá nhiều trên thực tế, có thể là do sai sót của system admin khi quá tin tưởng vào Oracle.
Còn hệ thống về cơ bản vẫn an toàn là vì không ai expose port 9500 của Weblogic ra internet cho các hacker scan cả 🤷♀️.
#OCT 2020 CPU
Trong quá trình phân tích bản vá tháng 10–2020 của Oracle BI, mình có thấy họ patch vài lỗi XXE liên quan tới class “oracle.xdo.service.report.ReportTemplateService”, được handle bởi các entrypoint sau:
- /xmlpserver/ReportTemplateService.xls
- /xmlpserver/services/x/ReportTemplateService.xls
- /mobile/ReportTemplateService.xls
- /mobile/services/x/ReportTemplateService.xls
Class này nằm trong file “%ORACLE_HOME%biclientsbipubliserxdo-server.jar”
Sự khác biệt sau bản vá như sau:
Có thể thấy ngay một đoạn setEntityResolver() đã được thêm vào để ngăn chặn việc khai thác XXE.
Tuy nhiên như vậy chưa phải là hết, sau khi nghiên cứu bản vá thì mình đã tìm thêm 2 lỗi XXE tương tự, cũng tại entrypoint này luôn!
#CVE-2021–2400 SAXParser XXE
Vẫn tiếp tục luồng phân tích class “oracle.xdo.service.report.ReportTemplateService” phía trên,
Khi parse XML từ post body thành công, chương trình sẽ tiếp tục lấy element sg:replyToXML -> incomingXML.
Để thỏa mãn đoạn này thì post body có dạng sau:
Tiếp tục debug vào trong method ServiceGateway.replyToXML() -> replyToXMLWithContext()
Tại đây, nội dung của incomingXML lại tiếp tục được đưa vào DOMParser để parse thêm lần nữa, tuy nhiên do config của domparser đã chặn resolveEntity nên XXE sẽ không xảy ra tại đây!
Để thỏa mãn luồng thực thi hiện tại, incomingXML cần có data dạng như sau:
Sau khi escape XML và ghép với post body ban đầu, được payload như vậy:
Server tiếp tục đi vào nhánh ServiceGateway.respondUsingInvocationManager():
Tại đây, chương trình tiếp tục tạo một instance của SAXParser() để parse dữ liệu từ URL methodDefLocation, giá trị này hoàn toàn có thể bị điều khiển từ input data, nó chính là giá trị của attribute “template” trong phần incomingXML.
Và xem xét kỹ, tại đoạn SAXParser này hoàn toàn không có đoạn nào để ngăn chặn resolve Entity,
=> Gây ra lỗ hổng XXE, CVE-2021–2400.
Và đây là response khi server đang cố gắng load Xml file từ URL mình truyền vào:
Tóm tắt lại về flow của lỗi này:
Còn việc sử dụng XXE này để làm gì thì mình sẽ nói ở phần dưới,
#CVE-2021–2401 DOMParser XXE
Vẫn là tại ServiceGateway.replyToXMLWithContext(),
Giả sử như chương trình không đi vào nhánh responseUsingInvocationManager(), nó sẽ tiếp tục đi vào nhánh dưới, ServiceGateway.respondUsingCallable().
Để tới được nhánh này, vẫn sử dụng incomingXML data như của CVE-2021–2400, nhưng bỏ đi phần attribute “template”. Chương trình sẽ tiếp tục đi vào nhánh ServiceGateway.invokeCallable()
className tương ứng với attribute “callable” của xml
methodName tương ứng với attribute “name”,
Tại ServiceGateway.invokeCallable(), một instance mới được khởi tạo từ tham số className, và invoke method oracle.xdo.service.server.Callable.call() với object vừa khởi tạo:
Tìm trong library có 2 implementation của method này:
Đi sâu vào xem xét cách hoạt động của ReportService.call(),
Cách hoạt động này cũng không khó hiểu lắm, chỉ đơn giản là so sánh methodName vừa truyền vào rồi gọi các method tương ứng với nó! Một số method có sẵn như sau:
- validateLogin
- hasTemplateEditingRole
- getParameterInfo
- getDataForReport
- getXMLForReport
- generateReportTemplate
Như vậy tới đây, incomingXML sẽ có dạng:
Xem xét một vòng thì mình đặt sự chú ý vào phần call tới method “getXMLForReport”
Từ ReportService.getXMLForReport(), đối số thứ 2 tiếp tục được truyền vào method hashtableFromReportParametersXML():
Tại ReportService.hashtableFromReportParametersXML(), dữ liệu lại tiếp tục được đưa vào DOMParser.parse() mà không có các bước restrict về Entity, trong đó đối số cũng đã bị điều khiển tùy ý
=> Từ đó trigger được XXE với dữ liệu truyền vào.
Chain từ source -> sink của lỗ hổng này như sau:
Idea:
Rồi bây giờ làm gì với mấy cái XXE này ??
Như mình đã đề cập ở đầu bài viết, patch cho BI Server không có nghĩa là sẽ patch cả weblogic, weblogic sẽ đi theo một bản vá riêng, và server weblogic port 9500 sẽ không bao giờ expose ra internet!
Kết hợp với CVE-2020–14882, một lỗ hổng mà có thể take over weblogic chỉ với 1 GET request, từ đó ta có một kịch bản đó là lợi dụng một lỗ hổng XXE, SSRF hay gì gì đó trên BI Server để attack con server weblogic kia. ( ͡° ͜ʖ ͡°)Nói thì dài chứ mô tả bằng hình nó cũng chỉ đơn giản như vậy thôi:
PoC video: https://youtu.be/JcGjxN81Jp4
Thanks for reading!
To be continued …