Jang
Jang
Jun 20 · 7 min read

Recently, I ‘ve found a new RCE gadget in weblogic server 12.2.1.3.0, here is the PoC:

Just kidding =)))

— — — — — — — — — — — — — — —

*Story có thể dài dòng văn tự, xàm xí vcđ và có thể gây ức chế cho người đọc nên nếu bạn đang tìm kiếm PoC thì vui lòng Ctrl+F “The gadgets” để đỡ mất thời gian!

__The story__

Câu chuyện bắt đầu vào một ngày nọ, mình đi recheck các web server đã từng được pentest của team.

Trong đó có cái hệ thống <redacted> sử dụng rất rất nhiều weblogic để chạy các services.

Tầm này năm ngoái thì đồng nghiệp mình có tìm và report cả mớ RCE trên mấy con server này, lúc đó thì có vẻ như bên vận hành đã patch rất nghiêm túc vì sau đó bọn mình có test lại thì đều thấy đã fix hết lỗi cũ!

Nhớ ko nhầm thì mình đã từng đọc được ở đâu đó 1 câu dạng: weblogic như cái nồi lẩu có đủ các loại lỗi trên đời trong đó, từ XXE, LFI, … đến Deserialize, RCE …

Vì thế mình vẫn tin lần recheck này chắc chắn sẽ không thể về tay trắng được!

Hệ thống này hơi đặt biệt 1 chút là mình không có access trực tiếp tới nó, mà phải đi đường vòng qua 1 con server khác nằm cùng LAN với mấy con đó thông qua tunnel bằng HTTP.

Do vậy lúc này không thể xách acunetix vào mà scan được =))), con tunnel hẹo thì bỏ mợ =))).

Mình quyết định đi làm manual, đi đào bới trên oracle update patch xem có gì có thể ăn được ko!

Lòng vòng 1 chút trên twitter của @pyn3rd (ông này hình như có thù oán với weblogic), thì thấy cái PoC của CVE-2018–3245:

https://twitter.com/pyn3rd/status/1054944706285764608

Sau khi test thì đúng là PoC này vẫn chạy trên hầu hết các target mình đang test.

Chỉ có điều là nó hoạt động 50%!

CVE-2018–3245 thực chất là phiên bản bypass bản patch của CVE-2018–2893.

Trong quá khứ, weblogic đã từng bị deserialize to RCE thông qua giao thức T3,những bản patch để fix lỗi này đa số đều thực hiện theo kiểu “blacklist filter” nên chuyện bị bypass trong ngày 1 ngày 2 là chuyện cũng khá dễ hiểu ở đây!

Và như đã từng được feed back từ các report trước thì T3 kiểu như là core protocol của cả hệ thống chạy weblogic này nên việc chặn nó là không được phép ¯\_(ツ)_/¯ .

Nói tiếp về vụ 50%, CVE-2018–3245 là biến thể của gadget “JRMIClient” cũ để bypass update patch.

Gadget này theo mình hiểu đơn giản là sau khi deserialize nó sẽ tiếp tục load cái gadget thứ 2 qua RMI và deserialize tiếp lần 2.

Kiểu như này nè:

50% ở đây có nghĩa là gadgets JRMIClient bypass thành công, nhưng 50% còn lại là cái gadget chính mình cần deserialize lại không thể deserialize thành công.

Lý do thì cũng dễ hiểu vì hầu hết các server này đều đang chạy version mới nhất của weblogic (12.2.1.3.0) nên tất cả các library chứa những “known gadgets” đều đã được update tới latest version để tránh bị lợi dụng.

Trên môi trường PoC của author có sử dụng Jdk7u21 nên hoàn toàn có thể RCE ngon lành, còn với target của mình thì tất cả đều là jdk8 trở lên :<.

Khi send payload sẽ như này nè:

Có request gadget thứ 2 nhưng deserialize lỗi

Hmm..

Lúc này lại trở về bài toán khó, mặc dù biết là hệ thống tiềm tàng lỗ hổng (điều kiện cần) nhưng lại không thể kiếm được cái gadget nào đó chạy được (điều kiện đủ) và report cho bên vận hành hệ thống.

Vì thực tế mà nói, một hệ thống đang chạy bình thường, không đời nào người vận hành động vào nó chỉ vì một lời cảnh báo sáo rỗng của một trung tâm khỉ ho cò gáy nào đó!

Cần phải có gì xác thực hơn, ví dụ như RCE chẳng hạn …

Để tránh những thiệt hại có thể xảy ra với hệ thống này, mình tiếp tục công việc mà mình vốn dĩ phải làm để bảo vệ hệ thống này: đập phá nó =))).

__The gadgets___

Và đó là nguyên do thúc đẩy mình tìm ra cái gadget dropshell này!

Trước đó trong mấy cái giải CTF từng chơi qua thì mình cũng đã từng phải làm công việc tìm gadgets này rồi.

Nhưng với thực tế thì nó khác xa CTF quá nhiều =)).

Để tìm gadget trên weblogic này, mình check process đang chạy weblogic => tìm classpath của nó => và copy tất cả lib trong classpath của nó ra folder riêng để dễ làm việc.

Chỉ có điều hơi củ chuối 1 chút, là bên trong 1 số lib của weblogic nó lại có classpath trong meta file, Intellij lại không tự động index đống class này nên đã làm mình mất khá nhiều thời gian để manual copy từng đống classpath con vào 1 folder riêng!

Việc tìm gadget này thì đương nhiên ko thể làm bằng tay đối với hơn 250MB library này được =))).

Mình dùng tool gadgetinspector (https://github.com/JackOfMostTrades/gadgetinspector) của 1 thanh niên nào đó để tìm gadgets trong đống lib này.

Trong quá trình sử dụng tool này thì mình nhận ra nó không được tối ưu lắm, và mình đã phải modify khá nhiều để có thể tìm ra được cái gadget dropshell này!

Về cái tool này có lẽ sẽ có một post khác viết về nó, nhưng là vào 1 ngày khác!

Và thực tế là mình chỉ sử dụng phần “Sink” mà tool tìm được, còn phần source thì vẫn còn nhiều cải tiến nữa để hoạt động ngon hơn.

Output của tool thì được rất nhiều gadget, nhưng trong số đó false positive có đến 90% :<

Đây là gadget hữu ích mà tool đã tìm được:

Tuy nhiên phần source thì lại hơi vô dụng vì không thể đáp ứng được các điều kiện phía trên để hoàn thiện chains

Phần chain bị thiếu ở đây là làm sao để lead được tới: SimpleCache$StoreableCachingMap.put(<String>, <bytes>)

Sau khi loanh quanh một hồi, mình quyết định sử dụng lại 1 phần nhỏ của gadget CommonsCollections6!

CommonsCollections6 chứa phần chain còn lại đang bị thiếu, đó là LazyMap:

Ở đây variable map có thể control, và return của factory.transform(key) cũng có thể control tùy ý nếu như sử dụng factory phù hợp!

Variable factory ở đây là object trong họ nhà Transformer:

Search implementations một hồi thì phát hiện ra class ConstantTransformer có implement interface TransformerSerializable

Method transform của ConstantTransformer chỉ thực hiện return variable iConstant:

Và trên hết, đó là ConstantTransformer không overwrite method readObject() để chặn deserialize như InvokerTransformer (thanks God :)) ) .

Kết hợp tất cả lại ta được một cái gadget đẹp toẹt vời như sau:

PoC drop shell:

https://www.youtube.com/watch?v=qQAsxd_EeIE

Về các target bị ảnh hưởng,

Sau khi xử xong mấy con trong hệ thống, mình có thử search shodan chơi chơi.

Tỉ lệ drop shell thành công cũng hơi may rủi 60%, Và chỉ hoạt động trên weblogic 12.2.1.3.0 vì 1 tính năng ngớ ngẩn nào đó team dev thêm vào ¯\_(ツ)_/¯.

Còn nguyên do drop shell bị fail thì mình vẫn chưa biết vì chưa gặp lỗi đó trên môi trường lab để fix :<

Proof tí ko ae lại bảo bịp ;) :

Timeline:

  • 05/06/2019. Định report cho vendor nhưng lười mail
  • 13/06/2019. Soạn dở mail nhưng drop vì thấy chả có bug gì để report
  • 20/06/2019. Public bài này vì cảm thấy hôm nay trời đẹp

Hy vọng có ae thiện lành nào đó cảm thấy nghiêm trọng thì report dùm mình vs, Xin chân thành cảm ơn!

Cảm ơn mọi người đã đón đọc!

_Jang_

nightst0rm

NightSt0rm is a group of IT security researchers, enthusiasts , who share the same interests. We are focusing on Hacking, Cryptography, Malware analyst & Computer forensics.

Jang

Written by

Jang

nightst0rm

NightSt0rm is a group of IT security researchers, enthusiasts , who share the same interests. We are focusing on Hacking, Cryptography, Malware analyst & Computer forensics.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade