Cửa ẩn: CVE-2024-23897 - con đường dẫn tới cuộc tấn công ransomware nhắm vào các ngân hàng Ấn Độ

Cửa ẩn: CVE-2024-23897 - con đường dẫn tới cuộc tấn công ransomware nhắm vào các ngân hàng Ấn Độ

Vào ngày 1 tháng 8 năm 2024, hoạt động thanh toán bán lẻ tại các ngân hàng Ấn Độ bắt đầu bị gián đoạn. Ngay sau đó, nhiều nguồn tin lớn đồng loạt đưa tin rằng Brontoo Technology Solutions – một đơn vị hợp tác với C-Edge Technologies (liên doanh giữa TCS – Tata Consultancy Services và SBI – State Bank of India) – đã trở thành nạn nhân của một cuộc tấn công ransomware, theo thông tin từ NPCI (National Payments Corporation of India). C-Edge chủ yếu cung cấp các dịch vụ công nghệ cho khối ngân hàng hợp tác (cooperative banks) và các ngân hàng nông thôn khu vực.

Hình 1: Nguồn – Bài đăng của NPCI trên nền tảng X (Twitter)

Nghiên cứu của CloudSek xác nhận rằng nhóm RansomEXX là thủ phạm đứng sau cuộc tấn công.

Nhóm này là một tổ chức khét tiếng chuyên thực hiện các cuộc tấn công ransomware nhắm vào doanh nghiệp, cơ quan chính phủ, ngân hàng, y tế và nhiều lĩnh vực khác. Chúng hoạt động từ năm 2018, ban đầu xuất hiện dưới tên Defray777, và đến năm 2020 thì mới được biết đến rộng rãi với tên gọi hiện tại. Nhiều nhận định cho rằng nhóm này có thể đang hoạt động từ khu vực Đông Âu hoặc Nga.

Hình 2: Nguồn – Bài đăng của NDTV Profit

Vào tháng 3 năm 2024, một cuộc tấn công ransomware nghiêm trọng có liên quan đến nhóm RansomEXX đã nhắm vào Bộ Quốc phòng Peru. Sự kiện này cho thấy khả năng xâm nhập vào các cơ quan chính phủ trọng yếu của nhóm, nhấn mạnh việc chúng tập trung vào các tổ chức cấp cao và những hậu quả tiềm ẩn khi ransomware tác động đến hạ tầng thiết yếu. Thông tin chi tiết hơn về vụ tấn công có thể dễ dàng tra cứu trực tuyến.

Phân tích cuộc tấn công

Brontoo Technology Solutions đã gửi báo cáo lên Cert-In (Indian Computer Emergency Response Team), trong đó chỉ ra rằng cuộc tấn công bắt nguồn từ một máy chủ Jenkins bị cấu hình sai, mở đầu cho toàn bộ chuỗi sự cố. Qua phân tích sâu hơn, kẻ tấn công đã lợi dụng lỗ hổng CVE-2024-23897 để giành quyền truy cập trái phép ban đầu vào hệ thống của nạn nhân.

CVE-2024-23897 là một lỗ hổng trong Command Line Interface của Jenkins, cho phép kẻ tấn công tìm cách truy cập trái phép vào các hệ thống mục tiêu. Mẫu ghi chú đòi tiền chuộc (ransom note) mà nhóm này sử dụng có hình dạng như ảnh bên dưới:

Hình 3: Mẫu ghi chú đòi tiền chuộc

CVE-2024-23897: Phân tích kỹ thuật chuyên sâu

Jenkins là một máy chủ tự động hóa mã nguồn mở cho phép các nhà phát triển trên toàn cầu xây dựng, kiểm thử và triển khai phần mềm. Lỗ hổng này lợi dụng Command Line Interface (CLI) của Jenkins. Để truy cập CLI này, có thể sử dụng SSH (Secure Shell), WebSocket hoặc HTTP thông qua CLI client.

Lỗ hổng cho phép người dùng chưa xác thực đọc được vài dòng đầu tiên của bất kỳ tệp nào trên hệ thống tập tin. Nguyên nhân là do việc kiểm tra đầu vào không đầy đủ với các chuỗi do người dùng cung cấp khi xử lý các lệnh CLI. Lỗ hổng tồn tại vì tính năng phân tích lệnh (command parser) tích hợp sẵn chưa được tắt theo mặc định. Nếu khai thác thành công, lỗ hổng có thể dẫn tới rò rỉ các tệp và dữ liệu nhạy cảm, khả năng thực thi lệnh trái phép, và tạo điều kiện cho một cuộc tấn công ransomware. Phiên bản mà Juniper Threat Labs sử dụng để minh họa cuộc tấn công được mô tả bên dưới:

Hình 4: Cấu hình Jenkins dễ bị tổn thương

Sau khi thực thi POC (Proof of Concept) trong phòng thí nghiệm, chúng tôi quan sát thấy hai yêu cầu POST được gửi tới endpoint /cli. Một yêu cầu được dùng để tải lệnh lên (upload) và yêu cầu còn lại để tải lệnh về (download).

Yêu cầu tải lên được sử dụng để gửi lệnh, như minh họa bên dưới:

Hình 5: Yêu cầu POST (Upload)

Trong trường hợp này, chúng tôi cố gắng gửi lệnh /etc/group tới endpoint /cli. Tương tự, một yêu cầu download được sử dụng để thực thi lệnh và lấy về kết quả đầu ra của lệnh, như minh họa trong hình bên dưới:

Hình 6: Yêu cầu POST (Download)

Như thấy trong hình trên, lệnh được gửi trong yêu cầu đầu tiên đã được thực thi, và kết quả đầu ra được nhận trong yêu cầu thứ hai dưới dạng root:x:0: - đây là dòng đầu tiên của tệp /etc/group.

Sau khi rà soát endpoint /cli, chúng tôi tiến hành tìm kiếm và lần ra jenkins-core-2.235.1.jar. Sau khi decompile các tệp, chúng tôi tiếp tục tìm kiếm đoạn mã cụ thể xử lý các yêu cầu POST tới endpoint /cli, và bingo - nó nằm trong CliCrumbExclusion.java, nơi gọi CliCrumbExclusion.process(). Đoạn mã này xác minh và đảm bảo rằng '/cli' có mặt trong đường dẫn URI, rồi hàm chain.doFilter() tiếp nhận và xử lý yêu cầu dẫn tới hàm CLIAction.getTarget(), như minh họa bên dưới:

Hình 7: Đoạn mã decompile từ CliCrumbExclusion.java

Từ đoạn mã đã decompile ở trên, có thể thấy hàm này kiểm tra rằng phương thức yêu cầu (Req.method) phải là POST và tham số remoting phải có giá trị false. Điều này cũng trùng khớp với dữ liệu thu được trong phần bắt gói tin bằng Wireshark ở bên dưới.

Nếu các điều kiện trên thỏa mãn, đoạn mã sẽ ném ra một ngoại lệ PlainCliEndpointResponse().

Hình 8: Đoạn mã decompile (phần 1)

Sau đó, ngoại lệ này sẽ được bắt lại và hàm FullDuplexHttpService() được thực thi. Quá trình kiểm tra kết nối upload và download sẽ được khởi động, như minh họa trong hình bên dưới.

Hình 9: Đoạn mã decompile (phần 2)

Cuối cùng, phương thức FullDuplexHttpService.generateResponse() được gọi. Tại đây, giá trị của session được lưu vào biến uuid, sau đó tham số trong header “Side” sẽ được kiểm tra. Dựa trên giá trị của header này, hệ thống sẽ xác định yêu cầu (request) và phản hồi (response) tương ứng.

Sau khi tiếp tục phân tích sâu hơn trong mã nguồn, chúng tôi truy vết đến phần tham số của lệnh (command arguments), được lưu trong biến args và sẽ được phân tích thông qua phương thức CmdLineParser.parseArgument(). Khi các tham số này được phân tích hoàn chỉnh, câu lệnh sẽ được thực thi.

Hình 10: Đoạn mã decompile (phần 3)

Nếu có bất kỳ ngoại lệ (exception) nào phát sinh, chúng sẽ được xử lý bởi hàm CliCommand.logFailedCommandAndPrintExceptionErrorMessage(), và trong thông báo lỗi, chúng ta có thể quan sát được đầu ra của lệnh đã gửi.

Những điểm rút ra chính và tác động đến ngành

Các bài học và tác động rộng hơn đối với lĩnh vực công nghệ – an ninh mạng từ sự cố này có thể tóm lược như sau:

Tầm quan trọng của việc cập nhật và vá lỗi thường xuyên

Cuộc tấn công vào C-Edge Technologies nhấn mạnh sự cấp thiết của việc các tổ chức phải nhanh chóng triển khai các bản vá và cập nhật bảo mật. Lỗ hổng Jenkins (CVE-2024-23897) bị khai thác trong sự cố cho thấy phần mềm lỗi thời có thể trở thành "cửa ngõ" cho tội phạm mạng xâm nhập.

Quản lý cấu hình nghiêm ngặt

Những sai sót cấu hình – như trường hợp máy chủ Jenkins trong sự cố này – là các lỗi bảo mật hoàn toàn có thể phòng tránh. Doanh nghiệp cần xây dựng và tuân thủ các quy trình quản lý cấu hình chặt chẽ, đảm bảo hệ thống luôn được thiết lập an toàn và kiểm tra định kỳ.

Áp dụng mô hình Zero Trust

Mô hình bảo mật truyền thống dựa trên vành đai (perimeter-based) không còn đủ hiệu quả. Việc triển khai kiến trúc Zero Trust – nơi không một thực thể nào, dù bên trong hay bên ngoài hệ thống, được tin cậy mặc định – sẽ giúp tăng cường phòng thủ bằng cách liên tục xác thực danh tính và mức độ tin cậy của người dùng và thiết bị.

Chuẩn bị tốt cho ứng phó sự cố

Một kế hoạch ứng phó sự cố mạnh mẽ là điều thiết yếu. Khả năng phản ứng nhanh và hiệu quả trước các cuộc tấn công ransomware sẽ giúp giảm thiệt hại, hạn chế thời gian gián đoạn và cải thiện khả năng khôi phục. Các tổ chức cần thường xuyên cập nhật và diễn tập các quy trình IR (Incident Response).

Tăng cường bảo mật chuỗi cung ứng

Vụ việc nhằm vào C-Edge Technologies cho thấy những hệ lụy nghiêm trọng từ lỗ hổng của bên thứ ba. Các tổ chức phải đánh giá và giám sát thực hành bảo mật của các đối tác trong chuỗi cung ứng, đồng thời yêu cầu họ tuân thủ các tiêu chuẩn an ninh chặt chẽ.

Kết luận

Các khách hàng sử dụng Juniper Networks SRX Series Next-Generation Firewall (NGFW) có kèm giấy phép IDP (Intrusion Detection and Prevention) đã được bảo vệ khỏi lỗ hổng này thông qua chữ ký sau:

HTTP: CTS: JENKINS-RCE-CLI-PARS

Đối với toàn bộ khách hàng Juniper, khuyến nghị nên nâng cấp các máy chủ Jenkins dễ bị tấn công lên phiên bản đã vá hoặc phiên bản ổn định mới nhất để ngăn chặn các cuộc tấn công ransomware tương tự. Khuyến cáo chính thức từ Jenkins cho CVE này có thể được tham khảo trực tiếp.

Dịch vụ Cloud ATP của Juniper Networks đã xác định loại ransomware này với mức độ đe dọa là 10, tức là rủi ro ở mức nghiêm trọng (critical).

Hình 11: Mã băm (hash) 4cae449450c07b7aa74314173c7b00d409eabfe22b86859f3b3acedd66010458

Hình 12: Mã băm (hash) ad635630ac208406cd28899313bef5d4e57dba163018dfb8924de90288e8bab3

Cuộc tấn công ransomware vào Brontoo/C-Edge cho thấy chỉ một lỗ hổng Jenkins (CVE-2024-23897) kết hợp với cấu hình sai cũng đủ mở đường cho tin tặc xâm nhập hệ thống tài chính quy mô lớn. Sự cố này nhấn mạnh tầm quan trọng của việc vá lỗi kịp thời, quản lý cấu hình chặt chẽ, giám sát chuỗi cung ứng và áp dụng mô hình Zero Trust để giảm thiểu rủi ro tấn công tương tự trong tương lai.

Hẹn gặp lại bạn trong các bài viết tiếp theo!

CÔNG TY CỔ PHẦN DỊCH VỤ CÔNG NGHỆ DATECH

• Địa chỉ: Số 23E4 KĐT Cầu Diễn, Tổ 7, Phú Diễn, Bắc Từ Liêm, Hà Nội

• Điện thoại: 0243 201 2368

• Hotline: 098 115 6699

• Email: info@datech.vn

• Website: https://datech.vn