Lỗ hổng Apache Log4J: Bảng câu hỏi & Mẹo VRM

Apache Log4j 2, một thư viện ghi nhật ký dựa trên Java, đã bị ảnh hưởng bởi lỗ hổng zero-day vào ngày 9 tháng 12 năm 2021. Lỗ hổng này, được gọi là Log4Shell và được Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST) xác định là CVE-2021-44228, cho phép tội phạm mạng kiểm soát các hệ thống và máy chủ dễ bị tấn công.

Nhiều ứng dụng web, nền tảng đám mây mã nguồn mở và nhà cung cấp dịch vụ sử dụng Log4j. Việc sử dụng rộng rãi này có thể khiến bề mặt tấn công nội bộ của tổ chức và hệ sinh thái bên thứ ba của bạn gặp lỗ hổng Log4Shell. Để bảo mật các hệ thống và dữ liệu quan trọng một cách hiệu quả, tổ chức của bạn cần đánh giá việc sử dụng nội bộ Log4j và việc sử dụng thư viện ghi nhật ký của nhà cung cấp.

Hãy tiếp tục đọc để khám phá 11 câu hỏi mà nhóm quản lý rủi ro nhà cung cấp của bạn có thể sử dụng để xác định cách các nhà cung cấp sử dụng Log4j trong chuỗi cung ứng của bên thứ ba và điều này có thể ảnh hưởng như thế nào đến tình hình bảo mật của tổ chức bạn.

Tìm hiểu thêm về UpGuard Vendor Risk: giải pháp quản lý rủi ro nhà cung cấp #1 thế giới>

Tóm tắt lỗ hổng Log4Shell

Vào tháng 12 năm 2021, các nhà nghiên cứu bảo mật đã công bố một lỗ hổng bảo mật nghiêm trọng trong khung Apache Log4j, cho phép tin tặc độc hại xâm nhập các hệ thống dễ bị tấn công thông qua một lần chèn mã duy nhất.

Trong những ngày đầu tiên của tác động, các nhà nghiên cứu bảo mật đã xác định khoảng 10 triệu nỗ lực khai thác Log4Shell mỗi giờ. Các ngành công nghiệp khác nhau dễ bị tổn thương bởi Log4Shell vì nhiều sản phẩm và phần mềm kỹ thuật số, bao gồm các ứng dụng Microsoft và IOS, sử dụng Java.

Ngành bán lẻ bị ảnh hưởng nhiều nhất bởi lỗ hổng Log4Shell, nhưng các lĩnh vực khác, bao gồm công nghệ, dịch vụ tài chính, sản xuất và chăm sóc sức khỏe, cũng bị ảnh hưởng.

Vá lỗ hổng Log4J

Apache bắt đầu phát triển một bản vá cho Log4Shell nhanh chóng sau khi nhận ra lỗ hổng vào tháng 12 năm 2021. Tuy nhiên, Log4j vẫn có những rủi ro bảo mật đáng kể, do nó được sử dụng rộng rãi.

Bất kỳ phiên bản nào của Log4j 2 trước 2.17.1 đều dễ bị tổn thương bởi lỗ hổng Log4Shell. Để tự bảo vệ mình một cách hiệu quả khỏi lỗ hổng này, các tổ chức phải giải quyết bất kỳ phiên bản dễ bị tấn công nào của Log4j 2 đang được sử dụng trên cơ sở hạ tầng nội bộ và hệ sinh thái của bên thứ ba.

Các nhóm bảo mật có thể tuân theo giao thức sau để giải quyết lỗ hổng:

Cập nhật lên phiên bản mới nhất của Log4j 2
Chạy quét lỗ hổng bảo mật bằng máy quét
Cập nhật thuộc tính hệ thống Java
Tắt JNDI
Gửi bảng câu hỏi Apache Log4j cho các nhà cung cấp
Sử dụng xác thực đa yếu tố

Đề xuất đọc: Log4Shell: Lỗ hổng Log4J được giải thích rõ ràng

Các lỗ hổng Log4J liên quan

Trong khi Apache làm việc để giải quyết lỗ hổng Log4Shell, các nhà nghiên cứu và tác nhân đe dọa đã phát hiện ra các lỗ hổng bổ sung trong các phiên bản khác nhau của Log4j. NIST đã xác định những lỗ hổng này với các mã sau:

CVE-2021-45046: Cho phép tội phạm mạng gửi tra cứu JNDI độc hại, có trong Log4j 2.15 trở xuống

CVE-2021-45105: Cho phép tội phạm mạng triển khai các cuộc tấn công từ chối dịch vụ thông qua các tin nhắn độc hại, có trong Log4j 2.16 trở xuống

CVE-2021-44832: Lỗ hổng thực thi mã từ xa (RCE) cho phép tin tặc khai thác hệ thống bằng mã tùy ý nếu chúng có quyền nâng cao, có trong Log4j 2.17 trở xuống

11 câu hỏi Apache Log4J để hỏi nhà cung cấp của bạn

Bảng câu hỏi bảo mật là một trong những cách hiệu quả nhất mà một tổ chức có thể đánh giá tình trạng bảo mật của các nhà cung cấp bên thứ ba. Tổ chức của bạn có thể sử dụng 11 câu hỏi sau để tạo bảng câu hỏi bảo mật nhằm xác định bất kỳ phiên bản lỗi thời nào của Log4j trên toàn bộ hệ sinh thái nhà cung cấp của mình.

Khám phá thư viện bảng câu hỏi bảo mật mạnh mẽ của UpGuard>

1. Tổ chức của bạn có chạy bất kỳ phiên bản nào của Log4j 2 không?

Có
Không
[Mở trường văn bản cho nhận xét của nhà cung cấp]

2. Tổ chức của bạn đã cập nhật lên Log4j 2.17.1 theo khuyến nghị của Tổ chức Phần mềm Apache và CISA chưa?

Có, tổ chức đã cập nhật lên Log4j 2.17.1
Không, tổ chức không thể cập nhật lên Log4j 2.17.1 (vui lòng giải thích bên dưới)
Tổ chức vẫn chưa cập nhật lên Log4j 2.17.1
[Mở trường văn bản cho nhận xét của nhà cung cấp]

3. Nếu không, tổ chức của bạn hiện đang chạy phiên bản Log4j 2 nào?

Tổ chức sử dụng phiên bản Log4j 2 từ 2.7 đến 2.14.1 (chuyển sang câu hỏi 3)
Tổ chức sử dụng phiên bản Log4j 2 từ 2.0-beta9 đến 2.10.0 (chuyển sang câu hỏi 4)
Tổ chức sử dụng Log4j 2.17.1

4. Nếu tổ chức của bạn sử dụng phiên bản Log4j2 từ 2.7 đến 2.14.1, hãy thực hiện các nỗ lực giảm thiểu sau:

a) Thuộc tính hệ thống, log4j2.formatMsgNoLookups, hoặc biến môi trường, LOG4J_FORMAT_MSG_NO_LOOKUPS, đã được đặt thành true

VÀ

b) Tất cả các mẫu PatternLayout đã được sửa đổi thành %m{nolookups} thay vì chỉ %m

Tổ chức đã thực hiện biện pháp phòng ngừa a)
Tổ chức đã thực hiện biện pháp phòng ngừa b)
Tổ chức đã thực hiện các biện pháp phòng ngừa a) và b)
[Mở trường văn bản cho nhận xét của nhà cung cấp]

5. Nếu tổ chức của bạn sử dụng phiên bản Log4j2 từ 2.0-beta9 đến 2.10.0, hãy thực hiện các nỗ lực giảm thiểu sau:

a) Thuộc tính hệ thống, log4j2.formatMsgNoLookups, hoặc biến môi trường, LOG4J_FORMAT_MSG_NO_LOOKUPS, đã được đặt thành true

VÀ

b) Lớp JndiLookup đã bị rút khỏi đường dẫn: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Tổ chức đã thực hiện biện pháp phòng ngừa a)
Tổ chức đã thực hiện biện pháp phòng ngừa b)
Tổ chức đã thực hiện các biện pháp phòng ngừa a) và b)
[Mở trường văn bản cho nhận xét của nhà cung cấp]

6. Tổ chức của bạn có sử dụng kho lưu trữ GitHub của CISA để xác định các tài sản dễ bị tấn công bởi Log4Shell không?

Có
Không
[Mở trường văn bản cho nhận xét của nhà cung cấp]

7. Tổ chức của bạn đã xác định bất kỳ dấu hiệu xâm nhập (IOC) nào do lỗ hổng Log4Shell chưa?

Có (vui lòng liệt kê bên dưới)
Không
[Mở trường văn bản cho nhận xét của nhà cung cấp]

8. Lỗ hổng Log4Shell đã ảnh hưởng đến tổ chức của bạn như thế nào?

Lỗ hổng không ảnh hưởng đến tổ chức và chúng tôi không phải đối mặt với bất kỳ cuộc tấn công mạng hoặc vấn đề bảo mật nào do lỗ hổng này
Lỗ hổng này ảnh hưởng vừa phải đến tổ chức, nhưng không có hệ thống, cơ sở hạ tầng, dịch vụ hoặc dữ liệu quan trọng nào bị ảnh hưởng (vui lòng giải thích bên dưới)
Lỗ hổng này ảnh hưởng trực tiếp đến các hệ thống, cơ sở hạ tầng, dịch vụ và/hoặc dữ liệu quan trọng của tổ chức (vui lòng giải thích bên dưới)
[Mở trường văn bản cho nhận xét của nhà cung cấp]

9. Tổ chức của bạn có kế hoạch ứng phó sự cố để ứng phó với các mối đe dọa mạng không?

Có, tổ chức đã có kế hoạch ứng phó sự cố
Tổ chức đang trong quá trình hoàn thiện một kế hoạch ứng phó sự cố chuyên dụng
Không, tổ chức không có kế hoạch ứng phó sự cố
[Mở trường văn bản cho nhận xét của nhà cung cấp]

10. Tổ chức của bạn triển khai các đánh giá rủi ro chuyên sâu để đánh giá các lỗ hổng bảo mật nội bộ bao lâu một lần?

Hàng năm
Sáu tháng một lần
Khi cần thiết, hoặc chúng tôi không có nhịp đánh giá rủi ro theo lịch trình
[Mở trường văn bản cho nhận xét của nhà cung cấp]

11. Ai là đầu mối liên hệ của tổ chức bạn để giải đáp các câu hỏi và thắc mắc bổ sung?

Tên:
Tiêu đề:
Email:
Điện thoại:
[Mở trường văn bản cho nhận xét của nhà cung cấp]

Cách khắc phục rủi ro của nhà cung cấp

Nếu tổ chức của bạn triển khai bảng câu hỏi bảo mật Apache Log4j và phát hiện nhà cung cấp đang chạy phiên bản Log4j 2 dễ bị tấn công, bạn phải khắc phục rủi ro ngay lập tức. Tổ chức của bạn nên ưu tiên các nỗ lực khắc phục dựa trên mức độ quan trọng của nhà cung cấp nếu nhiều nhà cung cấp bị ảnh hưởng.

Tùy thuộc vào mức độ nhận thức bảo mật của nhà cung cấp, tổ chức của bạn có thể cần làm việc cùng với nhóm bảo mật của nhà cung cấp để triển khai các bản cập nhật và giao thức khắc phục cần thiết.

Nhóm của bạn có thể làm theo quy trình khắc phục sau khi xác định nhà cung cấp bị phơi bày:

Liên lạc với đầu mối liên hệ đã xác định và yêu cầu khắc phục
Đề xuất các quy trình giảm thiểu, chẳng hạn như xóa tra cứu JNDI, cập nhật lên phiên bản mới nhất của Log4j, sử dụng kho lưu trữ GitHub của CISA để kiểm kê các nhà cung cấp và các quy trình khác do Apache và CISA đề xuất
Truyền đạt kỳ vọng, mốc thời gian và hậu quả tư vấn cho thất bại khắc phục
Gửi bảng câu hỏi bảo mật mới để xác minh rủi ro đã được khắc phục

Đề xuất đọc: Chọn phần mềm khắc phục rủi ro của nhà cung cấp tự động vào năm 2024

UpGuard là một công ty an ninh mạng chuyên giúp các nhóm bảo mật bảo vệ các bề mặt tấn công nội bộ và bên thứ ba của họ. Hai sản phẩm của UpGuard, Rủi ro nhà cung cấp và BreachSight, cho phép các tổ chức cải thiện vệ sinh mạng của họ, đánh giá tình hình bảo mật của các nhà cung cấp riêng lẻ và triển khai các giao thức quản lý rủi ro nhà cung cấp và quản lý rủi ro mạng mạnh mẽ.

Khả năng quét lỗ hổng và đánh giá lỗ hổng bảo mật của UpGuard cho phép các tổ chức xác định các lỗ hổng khác nhau có thể ảnh hưởng đến tình hình bảo mật của họ và dẫn đến các cuộc tấn công mạng như phần mềm độc hại hoặc ransomware.

UpGuard Vendor Risk and BreachSight bao gồm các tính năng sau:

Phát hiện rò rỉ dữ liệu: Bảo vệ danh tiếng, tài sản trí tuệ và dữ liệu khách hàng của thương hiệu bằng cách phát hiện kịp thời rò rỉ dữ liệu
Giám sát liên tục: Nhận thông tin cập nhật theo thời gian thực và quản lý các rủi ro trên bề mặt tấn công của bạn, bao gồm miền, IP, ứng dụng, điểm cuối, plugin và tường lửa
Giảm bề mặt tấn công: Giảm bề mặt tấn công của bạn bằng cách phát hiện các lỗ hổng có thể khai thác và các miền có nguy cơ bị đánh máy
Hồ sơ bảo mật được chia sẻ: Tạo hồ sơ UpGuard Shared để loại bỏ rắc rối khi trả lời bảng câu hỏi bảo mật
Quy trình làm việc và miễn trừ: Hợp lý hóa quy trình khắc phục, nhanh chóng từ bỏ rủi ro và phản hồi các truy vấn bảo mật
Báo cáo và thông tin chi tiết: Truy cập các báo cáo được thiết kế riêng cho các bên liên quan khác nhau và xem thông tin về bề mặt tấn công bên ngoài của bạn
Bảng câu hỏi bảo mật của nhà cung cấp: Tự động hóa bảng câu hỏi bảo mật để hiểu rõ hơn về mối quan hệ của nhà cung cấp và tình hình bảo mật của bên thứ ba
Xếp hạng bảo mật: Đánh giá tình hình bảo mật của các nhà cung cấp riêng lẻ bằng cách sử dụng xếp hạng bảo mật dựa trên dữ liệu, khách quan và động của chúng tôi
Đánh giá rủi ro: Hợp lý hóa quy trình đánh giá rủi ro, thu thập bằng chứng và nhanh chóng yêu cầu khắc phục