Từ bên Tây về bên ta

Trong bài viết trước, tôi đã phân tích cơ chế cập nhật của Avast Antivirus và những điểm yếu đã bị khai thác thành công. Về cơ bản, logic update của hầu hết các hãng Antivirus đều theo mô hình sau:

1. Kiểm tra version mới nhất (trên server) và version hiện tại trong máy

2. Kiểm tra các file cần cập nhật thông qua manifest (có chứa danh sách file và checksum)

3. Tiến hành tải các file binary mới nhất.

4. Tiến hành áp dụng bản cập nhật. Quá trình này có thể bao gồm validate các file binary trước khi tiến hành cập nhật. Điều này tùy thuộc vào thiết kế của từng hãng.

Như đã phân tích và chứng minh: Một điểm yếu về logic ở bất cứ bước nào cũng có thể bị khai thác. Impact của từng điểm yếu, hay của cả attack vector sẽ tùy thuộc vào vị trí điểm yếu.

Tuy nhiên, hãy tạm gác lại vấn đề lỗ hổng và logic lại và nói về “chuyện nước nhà”. So với thế giới, Việt Nam là một nước có nhiều chương trình Antivirus nếu xét về số lượng phát triển. Tính đến hiện tại, Việt Nam đang có CMC Antivirus và BKAV Antivirus là 2 phần mềm vẫn đang được phát triển và D32 Antivirus không còn được phát triển. Ngoài những cái tên vừa kể, Việt Nam còn có một số chương trình Antivirus khác được phát triển nội bộ để bảo vệ những hệ thống “ai cũng biết là cái gì đấy”.

Nói như vậy để thấy rằng quy mô phát triển về Antivirus của Việt Nam không hề kém cạnh so với thế giới. Tạm chưa nói đến câu chuyện chất lượng sản phẩm, quy mô về số lượng chương trình Antivirus của Việt Nam đang đứng trên top thế giới (Kết quả sử dụng Grok Deep Search để phân tích số vendor trên Virus Total):

• Việt Nam có số lượng tương đương với Hàn Quốc (AhnLab, Alyac), Ba Lan (Arcabit, ClamAV), "Israel (CheckPoint, CyNet), Czech (Avast, AVG)

• Số Antivirus của Việt Nam nhiều hơn các nước như Romania, Slovakia, Phần Lan, Tây Ban Nha, Nhật Bản; ít hơn Mỹ, Trung Quốc, Đức, Nga, Ấn Độ.

Như vậy, quy mô phát triển của Việt Nam thuộc vào nhóm “đỉnh” của thế giới. Vậy, mức độ bảo mật của những sản phẩm này liệu có tương đương về quy mô không? Muốn biết kết quả phân tích thế nào, xem hạ hồi phân giải.

CMC và câu chuyện bug bounty đầu đời

Trong bài viết trước, tôi đã đề cập đến việc phát hiện attack surface của Avast Antivirus vào khoảng quý 2 năm 2023. Vào thời điểm đó, tôi đã phân tích sơ bộ kiến trúc file và cho rằng kiến trúc file khá phức tạp nên tạm hoãn nghiên cứu. Câu chuyện tạm dừng lại cho đến khi tôi “tình cờ” cài CMC Antivirus để phân tích vào giữa tháng 10 năm 2023. Chỉ với một vài phân tích sơ bộ, tôi phát hiện ra CMC AV có attack surface giống với Avast. Vì vậy, tôi quyết định phân tích sâu hơn về cơ chế cập nhật của CMC AV.

Cập nhật thông qua giao thức HTTP

Note: Phiên bản được phân tích và báo cáo là CMC Antivirus version v1.1.2022 build 117, Revision 131577. Bản báo cáo đã gửi CMC không bao gồm quá trình phân tích. Vì vậy, screenshot trong phần này sử dụng bản CMC Antivirus version v1.7.2020 build 76. Phiên bản này được tải tại taimienphi.com. Trang chủ của CMC không còn lưu giữ bản cài đặt của phiên bản này.

Trong quá trình phân tích sơ bộ các file của CMC AV trên hệ thống, tôi để ý đến file update.xml trong C:\Program Files (x86)\CMC\Antivirus\. Dựa theo thông tin trong file, tôi phỏng đoán chương trình CMC thực hiện cập nhật tới server nav.cmclab.net thông qua port 80.

Để kiểm chứng, tôi tiến hành cài đặt Burpsuite và cài đặt proxy cho CMC để intercept gói tin

Thực vậy, CMC sử dụng protocol HTTP để tiến hành kiểm tra cập nhật.

Như vậy, threat actor có thể sử dụng DNS Spoofing và ARP Spoofing để redirect luồng traffic cập nhật sang máy chủ giả mạo (chi tiết tiến hành tương tự đối với Avast for Linux trong bài trước).

Giả mạo dữ liệu cập nhật trên server

Note: Domain nav.cmclab.net hiện đã không còn hoạt động.

CMC Antivirus thực hiện kiểm tra dữ liệu từ http://nav.cmclab.net:80/cu/bhl.cmc. Khác với mô hình đã phân tích đã miêu tả ở đầu bài, thiết kế của CMC kết hợp bước 1 và 2. Nói cách khác, file bhl.cmc bao gồm cả thông tin version, tên file và checksum.

Logic của server CMC AV như sau:

• File bhl.cmc là file manifest chứa version number, một vài thông tin về cấu hình cập nhật và thông tin của các file được cập nhật.

• Giá trị Count là số lượng file được khai báo trong file manifest. File đó có các giá trị liên quan là:

  • f, s, m: bao gồm lần lượt tên file, size của file và MD5 của file đó

  • z1, zm1: bao gồm size và checksum của file đó đã được nén thành file zip.

  • File được tải về bao gồm:

    • File manifest .md5 chứa giá trị checksum.

    • File nén zip có extension là .czu chứa file binary cần cập nhật.

      

      

• Chương trình tiền hành tải file .czu và .md5 vào trong C:\Program Files (x86)\CMC\Antivirus\ và tiến hành giải dữ liệu trong file .czu vào trong thư mục này.

  

• Updater tiến hành cập nhật phiên bản mới (có thể có quá trình verify binary, ví dụ như chữ ký số, trước khi áp dụng file mới).

Như vậy, threat actor đã kiểm soát được dữ liệu cập nhật của client. Cần lưu ý rằng, khác với Avast, CMC không hề có đoạn checksum nằm ở footer để kiểm tra tính toàn vẹn của file manifest. Như vậy, threat actor có thể dùng file PE giả mạo chứa mã độc. Chương trình update sẽ replace file hiện tại bằng file giả mạo. Tuy nhiên, quá trình này có thể gặp phải cơ chế verify binary của CMC khiến cho file giả mạo không được sử dụng. Trong quá trình nghiên cứu, tôi đã tìm ra một lỗ hổng khác mang tính “phim ảnh” hơn. Lỗ hổng này khiến cho các file giả mạo ghi đè file gốc mà không thông qua quá trình apply update file của updater.

Lỗ hổng path traversal trong giải nén zip

Trong lúc phân tích, tôi đã có một linh cảm rằng lỗ hổng zipslip tồn tại trong CMC ngay khi nhìn thấy file .czu là một file zip.

Zipslip là một lỗ hổng path traversal nằm trong thư viện zip được phát hiện vào năm 2018. Trong quá trình giải nén, thư viện zip không tiến hành validate giá trị khiến inner file có thể được giải nén vào vị trí nằm ngoài destination folder.

Ý tưởng khai thác zipslip hình thành mà theo hướng 100% blackbox. Trong quá trình nghiên cứu, tôi không dịch ngược đoạn code update. Tuy nhiên, thực hiện kiểm chứng lỗ hổng này rất đơn giản:

Tạo file zipslip và giá trị trong manifest rồi tiến hành cập nhật ở phía client

Như vậy, lỗ hổng zipslip được khai thác thành công. Threat actor có thể chain lỗ hổng này cùng các điểm yếu khác để khai thác DNS Spoofing, giả mạo dữ liệu cập nhật nhằm chiếm quyền điều khiển hệ thống từ xa.

Bonus: Path traversal trong giá trị file name trong manifest.

Quá trình cập nhật của CMC Antivirus còn sử dụng giá trị của file name để xử lý đường dẫn. Qua kiểm chứng, CMC Antivirus cũng có lỗ hổng path traversal thông qua việc xử lý giá trị này. Đầu tiên, phía server thực hiện tạo file nhằm khai thác path traversal.

Ghi giá trị có chứa relative path vào trong giá trị tên file.

Phía client tiến hành cập nhật và các file .md5, .czu được tải về đã bị ghi ra ngoài thư mục updates.

Inner file được giải nén vẫn nằm trong thư mục updates

Xâu chuỗi tấn công: Chiếm quyền điều khiển hệ thống từ xa với quyền cao nhất

Từ các phân tích trên, tôi đã có 3 dữ kiện:

1. Sử dụng giao thức không bảo mật → Tấn công DNS Spoofing.

2. Không có cơ chế xác thực tính toàn vẹn và tin cậy của dữ liệu → Giả mạo dữ liệu update.

3. Path traversal trong quá trình giải nén file → Ghi file trái phép ngay trong quá trình updater đang kiểm tra checksum.

Để cuộc tấn công đạt impact cao nhất, tôi tiến hành kiểm tra target để lựa chọn binary có quyền cao nhất được CMC thực thi

Như trong screenshot, có rất nhiều binary đang được thực thi dưới quyền cao nhất của Microsoft Windows là NT AUTHORITY\SYSTEM. Trong quá trình demo, tôi đã lựa chọn mục tiêu là file CMCLog.exe.

Note: Vài thông tin bổ sung.

1. Nếu file cmccore.exe được ghi đè, phần GUI của CMC sẽ yêu cầu người dùng reboot để áp dụng bản cập nhật mới. Sử dụng file này, trên lý thuyết, sẽ có impact cao hơn vì người dùng sẽ reboot ngay, khiến mã độc được thực thi gần như ngay lập tức.

2. Các file mã độc không chỉ có quyền cao nhất của hệ thống (trong trường hợp overwrite file được sử dụng bởi SYSTEM) mà còn được bảo vệ bởi Self-Defense của CMC AV.

Lúc này, threat actor chỉ cần xâu chuỗi các mảnh ghép để tạo thành một cuộc tấn công hoàn chỉnh.

Cuộc tấn công được tiến hành như sau:

1. Tạo server giả mạo bao gồm binary chứa mã độc khai thác lỗ hổng zip slip
   Đầu tiên, threat actor tạo mã độc với msfvenom

   

   Tiếp đến là tạo file .czu và manifest khai thác zipslip

   

   

   Phía threat actor thực hiện tạo listener tự động migrate process vào tiến trình lsass.exe

   

   

2. Thực hiện tấn công Spoofing với ARP Spoof và DNS Spoof

   

   

3. Phía victim bị lây nhiễm mã độc khi thực hiện cập nhật. File mã độc đã được ghi đè thành công.

   

   Sau khi victim khởi động lại máy, mã độc được kích hoạt và threat actor chiếm được quyền điều khiển từ xa với quyền hệ thống.

   

Báo cáo và phản hồi từ phía CMC

Báo cáo được hoàn thành và gửi cho CMC vào ngày 21 tháng 10 năm 2023. Thông qua một “nguồn tin nội bộ”, tôi nhận được tin một số chuyên gia trong CMC không tin rằng POC là khả thi (LoL).

Dĩ nhiên là với tinh thần “sự thật là trên hết”, tôi không hề ngại setup một cuộc tấn công thực tế dưới sự chứng kiến trực tiếp của các chuyên gia bên phía CMC.

Study case:

1. Researcher bỏ ra rất nhiều thời gian để nghiên cứu phương thức hoạt động của phần mềm, cũng như attack vector. Mức độ hiểu rõ của researcher thậm chí có thể sâu hơn cả developer.

2. Nếu nghi ngờ POC là giả, hãy yêu cầu video POC hoặc trao đổi trực tiếp để nắm rõ thông tin về điểm yếu.

3. Tự dựng để reprocedure POC nếu có thể. Nếu POC có thể reprocedure được, điều đó đồng nghĩa với việc POC là thật, và tính ổn định của exploit là cao.

Nhưng nếu ai đó nghĩ toàn bộ câu chuyện đã xong thì… Bạn hẳn là người truyền năng lượng tích cực cho các đồng nghiệp =))

Đây là reply khá hài hước khi mà phiên bản được báo cáo chính là phiên bản chính thức trên trang chủ. Dĩ nhiên, đối với researcher mà nói, đây là một chiêu bài deny bug cực kỳ buồn cười. Để chứng minh, đây là tin nhắn vào gần nửa năm sau, khi mà “fixed done” sắp được fix.

Quay lại thời điểm report, lý do một vài chuyên gia bên phía CMC tin tưởng như vậy là cho rằng CMC có sẵn cơ chế chống giả mạo dữ liệu cập nhật.

Study case:

1. Cần phải có người nắm rõ kiến trúc logic của hệ thống cũng như chương trình.

2. Xác minh lại logic nếu cần thiết (phía vendor nắm quyền điều khiển server không hiểu rõ logic update bằng một người dùng cURL? LoL).

3. Matter of fact: Phiên bản official + Lỗ hổng → Exploit. Sự liên quan duy nhất ở phiên bản beta là: lỗ hổng có tồn tại trong cả phiên bản mới không?

4. Exploit chain bao gồm nhiều điểm yếu, lỗ hổng khác nhau. Vá được một điểm yếu (ví dụ protocol) mặc dù có thể tránh được attack vector đầy đủ, nhưng điểm yếu khác vẫn còn tồn tại.

Sau một khoảng thời gian trao đổi gián tiếp tương đối “sóng gió”, cuối cùng CMC đã công nhận lỗi vào ngày 21/10/2023. Phần thưởng bounty là một phần quà nhỏ mang giá trị tinh thần được giao đến tay vào ngày 24/10/2023.

Note: Việc public một vài đoạn chat không mang tính thù hằn cá nhân hay bêu xấu một đơn vị, tổ chức nào. Đối với cá nhân tôi, đây là một study case thực tế mà chắc chắn không ít researcher hay developer gặp phải. Nhìn thẳng sự thật, cải thiện bản thân, nâng cấp sản phẩm là những điều cần thiết trong ngành. Phía CMC đã làm được điều đó.Well done CMC ദ്ദി*!*

Và câu chuyện hãng B

Một vài câu chuyện lịch sử

Nếu nói đến Antivirus của Việt Nam mà không nhắc đến hãng B thì là một thiếu xót cực kỳ lớn. Chỉ nói riêng góc độ bảo mật của hãng B thì đã có những drama “to tổ bố” xảy ra:

• Vào ngày 2 tháng 2 năm 2012, máy chủ Webscan của hãng B bị hack và bị để lại file hacked.html. Ngày hôm sau, người tấn công bị bắt.

• Từ ngày 4 đến ngày 6 cùng tháng, website của hãng B bị tấn công từ chối dịch vụ khiến dịch vụ không thể truy cập.

• Vào ngày 14 tháng 2 năm 2012, một nhóm hacker tự xưng là LuLzSec Việt Nam, trích dẫn câu slogan của Anonymous, tấn công vào hệ thống của B và đánh cắp được nhiều dữ liệu nhạy cảm bao gồm cả mã nguồn B và các tài liệu đào tạo.

  

• Ngày 8 tháng 3 năm 2012, dữ liệu khách hàng và nhân viên của B được công bố. (Hiện tại một số dữ liệu được công bố vẫn có thể tải về từ một nguồn công bố LoL).
  Cần nói thêm rằng, vào thời điểm 2012 thì phong cách hacktivism là một “tiêu chuẩn” trong cộng đồng đi “hack dạo”. Đó là kết quả của sự ảnh hưởng từ các nhóm lớn trên thế giới như Anonymous và LuLzSec*. Vì vậy, đối với quan điểm thời bấy giờ, việc để lại một file* hacked.html không mang chủ đích gây hại mà chỉ mang tính cảnh báo. Vào thời điểm đó, các chương trình bug bounty mới chỉ manh nha phát triển.

• Ngày 4 tháng 8 năm 2021, một user tên chunxong tuyên bố đã hack được vào hệ thống nội bộ B và rao bán source code. Hacker này còn công bố cả đoạn chat trong phần mềm chat nội bộ của hãng này. Hãng B đã có một nỗ lực rất lớn khi cho một số nhân viên comment trên forum được công bố, khẳng định rằng chunxong là cựu nhân viên, có quyền truy cập vào nội bộ và leak ra dữ liệu. Việc hãng B bị tấn công bởi lỗ hổng bảo mật, leo thang và thâm nhập sâu là không hề xảy ra.

  

• Ngày 15 tháng 8, chunxong tuyên bố không thể live stream tấn công vào máy chủ bị dính lỗ hổng vì B đã tắt server. Tuy nhiên, hacker này đã public thông tin về một trong số các lỗ hổng (SQL Injection bypass login) cũng như video POC đã record từ trước (ngày 8 tháng 8 - Nguồn: tinhte). Ngoài ra, hacker cũng tuyên bố tìm ra 0-day trong sản phẩm B-Home / B-IS cũng như public source code có lỗ hổng của VPN đã bị khai thác.
  Theo tôi, lỗ hổng SQL Injection bypass login chỉ là một lỗ hổng “khởi đầu” cho vụ tấn công. Chắc chắn, dịch vụ VPN phải có lỗ hổng OS Command Injection hoặc có chức năng điều khiển từ xa các server trong mạng nội bộ thì hacker mới có thể đánh cắp được thông tin nội bộ (chưa kể đến các kỹ thuật tunneling, evasion, ..).

• Tháng 9 năm 2021, hãng B lại tiếp tục bị công bộ lộ dữ liệu người dùng (theo hãng này là do misconfigure hệ thống cloud).

• Ngày 12 tháng 1 năm 2022, một video POC được đăng tải cho thấy Bphone (thông qua tính năng chống trộm của B Mobile Security) đã giả mạo SMS và bypass khóa màn hình thành công.

Như vậy, bên cạnh việc không có chương trình bug bounty, hãng B này còn có bề dày lịch sử bị khai thác lỗ hổng và thái độ không mấy thiện chí với người tìm ra lỗ hổng. Hãng này còn hay có phản xạ “lèo lái lươn lẹo” vấn đề để giảm nhẹ (hoặc chối bỏ) impact của bug.

Lan man như vậy để thấy rằng hãng này cũng dính nhiều lỗ hổng bảo mật như ai. Và chính bản thân hãng, bên cạnh việc không có bounty program, còn có thái độ khá tiêu cực với việc bị phát hiện lỗ hổng.

Lại là lỗ hổng trong cơ chế update

Như vậy, luồng logic cập nhật có thể tóm tắt như sau:

1. Kiểm tra version number
   - Thử truy cập địa chỉ http://google.com.vn 3 lần trước khi lấy giá trị latest version từ server cập nhật (｢•-•)｢ ʷʱʸ?

2. Kiểm tra checksum thông qua manifest
   - Lưu manifest về máy
   - Tính toán checksum để tìm ra file cần cập nhật

3. Tải file binary và tiến hành cập nhật
   - Tải file từ server được định nghĩa trong giá trị ServerName trong file manifest.
   - Áp dụng bản mới nhất

Như vậy, logic cập nhật của BKAV cũng có luồng logic tương đồng với các chương trình khác.

Để tấn công, threat actor có 2 điểm mấu chốt:

1. Đảm bảo truy cập tới http://google.com.vn không gây ra lỗi khi tấn công DNS Spoofing.

2. Server update giả mạo chạy với protocol HTTPS.

Ở trong những lần trước (CMC AV và Avast Linux), server giả mạo chỉ cần chạy HTTP là đủ. Nghĩa là threat actor có thể chạy apache2 hoặc nginx trên localhost. Nhưng với trường hợp này, việc tạo cert trên để chạy dịch vụ tại localhost là không thành công. Như vậy, câu hỏi đặt ra là: làm sao có một server cho phép lưu file binary, chạy HTTPS sẵn với cert hợp lệ, và miễn phí.

Trong lúc tìm solution, tôi đã tìm đến các giải pháp từ deploy cert trên máy local cho đến hosting miễn phí. Sau cỡ gần một ngày vấp phải cả chục dead end, tôi nhận ra một giải pháp rành rành ngay trước mắt:

Đúng vậy: Free, cho phép upload file và gần như không limit. Repo tôi đã tạo để test: https://github.com/dmknght/TestPwnBkav.

Như vậy, ta đã có đủ mảnh ghép để… tìm hiểu tiếp.

Từ thông tin manifest, tôi tiến hành map file name vào URL và tải file binary từ phía server. File lưu trên server được nén dạng .cab. Đây là một thuật toán nén được hỗ trợ sẵn trên Windows. Còn Linux? Đó là một câu chuyện khác: trên repo của Linux vào thời điểm nghiên cứu chỉ tồn tại công cụ giải nén file cab là cabextract. Một số công cụ hỗ trợ nén Cab trên mạng, như tôi đã tìm, đều không được maintain cả chục năm và không dùng được.

Với chừng ấy khó khăn khi dựng exploit, tôi đã nghĩ đến chuyện bỏ cuộc. Nguyên nhân rất đơn giản: công sức bỏ ra là quá lớn so với kết quả đạt được.

Tuy nhiên, động lực “phải hack được hãng B” đã khiến tôi tiếp tục hoàn thành exploit. Giải pháp để tạo file .cab để upload lên server đơn giản là… đưa file vào trong máy ảo Windows và dùng công cụ trên Windows để nén lại.

Vậy là khó khăn tiếp theo đã được khắc phục thành công. Vào lúc đó, tôi đã tưởng rằng mình hoàn thành exploit cho đến khi…

Tính năng update của BKAV Home không có giao diện để người dùng lựa chọn cập nhật. Toàn bộ logic cập nhật được quản lý bởi dịch vụ BkavHomeUpdateService.exe. Thông qua phân tích log update, tôi thấy quá trình cập nhật có thể trigger vào khoảng 15 phút sau khi update. Thời gian delay có thể đến… vài tiếng cho tới lần cập nhật tiếp theo. Để debug, tôi đã liên tục… uninstall và install lại BKAV Home (LoL).

Điều này tiếp diễn cho đến khi tôi RE file update service và tìm ra một chi tiết “mấu chốt”: Service thực hiện query giá trị registry dwNextCheckUpdate

Kết quả query được gọi lên bởi một vòng lặp

Thử nghiệm tấn công

Như vậy, tới đây ta đã có đầy đủ các mảnh ghép để thực hiện vector tấn công. Đầu tiên, cần tạo 2 server khác nhau phục vụ cho fake update:

1. Tạo malicious binary
   - Tải file gốc từ BKAV, sử dụng metasploit để inject meterpreter. Lưu checksum của file này để tạo manifest.

   - Sử dụng Windows để nén .cab.

   - Upload file lên github.

2. Server chứa file binary
   - Tạo 2 file extension .aspx chứa manifest. 2 file này chỉ cần chứa dữ liệu text hợp lệ.

   

   

   

Tiếp theo, ta có thể lựa chọn:

1. Tấn công ARP Spoofing và DNS Spoofing để thử nghiệm full attack vector. Tuy nhiên, cần lưu ý bước service thử truy cập URL http://google.com.vn/.

2. Để tiết kiệm thời gian nhằm debug thiết kế trên 2 server, ta có thể set hosts ở client để client truy cập vào server manifest mong muốn.

Cuối cùng, tiến hành sửa giá trị registry dwNextCheckUpdate ở phía client và đợi service thực hiện quá trình update. Threat actor chiếm quyền kiểm soát hệ thống với server update giả mạo.

Vào thời điểm viết bài, lỗ hổng vẫn chưa được fix (vì có được report lên hãng đâu :D ). Điều đó đồng nghĩa với việc tại thời điểm này, đây vẫn là một 0-day.