Điểm:69

Làm cách nào để kiểm tra xem Log4j đã được cài đặt trên máy chủ của tôi chưa?

lá cờ gq
Uri

Tôi đã đọc về các lỗ hổng bảo mật liên quan đến Log4j.

Làm cách nào để kiểm tra xem Log4j đã được cài đặt trên máy chủ của tôi chưa? Máy chủ cụ thể của tôi sử dụng Ubuntu 18.04.6 LTS.

Tôi đã cài đặt nhiều gói của bên thứ ba và có thể một số gói chứa nó.

Có lệnh chạy trên máy chủ của tôi để kiểm tra xem Log4j đã được cài đặt chưa?

lá cờ ch
Lưu ý rằng đây là một thư viện Java, vì vậy nếu bạn không chạy bất kỳ ứng dụng Java nào (và theo phần mở rộng, nếu bạn chưa cài đặt Java), thì bạn vẫn an toàn.
mfinni avatar
lá cờ cn
Không đúng - các ứng dụng có thể đi kèm với JRE của riêng chúng, bạn không cần phải cài đặt Java trên hệ thống của mình để chạy các ứng dụng Java.
Điểm:48
lá cờ ua

Hãy thử kịch bản này để có được một gợi ý:

echo "kiểm tra lỗ hổng log4j..."
OUTPUT="$(xác định vị trí log4j|grep -v log4js)"
nếu [ "$OUTPUT" ]; sau đó
  echo "[CẢNH BÁO] có thể dễ bị tổn thương, những tệp đó chứa tên:"
  tiếng vang "$OUTPUT"
fi
OUTPUT="$(dpkg -l|grep log4j|grep -v log4js)"
nếu [ "$OUTPUT" ]; sau đó
  echo "[CẢNH BÁO] có thể dễ bị tấn công, các gói đã cài đặt dpkg:"
  tiếng vang "$OUTPUT"
fi
nếu [ "$(lệnh -v java)" ]; sau đó
  echo "java đã được cài đặt, vì vậy hãy lưu ý rằng các ứng dụng Java thường gói các thư viện của chúng bên trong các tệp jar/war/ear, vì vậy vẫn có thể có log4j trong các ứng dụng đó."
fi
echo "Nếu bạn không thấy đầu ra nào phía trên dòng này, thì bạn đã an toàn. Nếu không, hãy kiểm tra các tệp và gói được liệt kê."

Đảm bảo cơ sở dữ liệu định vị của bạn được cập nhật với cập nhậtb.

Hoặc kiểm tra tốt hơn và chạy tập lệnh nâng cao từ GitHub cái mà cũng tìm kiếm bên trong các tệp Java được đóng gói. Chạy trên một dòng với

wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q -O - | đánh đập   

Tôi không chắc liệu có thể có các Chương trình Java đã biên dịch chạy trên máy chủ mà không cần cài đặt java hay không?

Hoặc thậm chí các phiên bản đã biên dịch mà các tệp nguồn thậm chí không còn được tìm thấy bên trong kho lưu trữ được đóng gói nữa?


cũng có nhiều phát triển về GitHub, nơi bạn tìm thấy các cuộc tấn công và biện pháp đối phó.


Điều này mất nhiều thời gian cho tôi. Tôi đang tìm người mà tôi có thể chuyển quyền sở hữu kho lưu trữ trên GitHub

lá cờ in
Điều này có cùng cảnh báo với câu trả lời do Tero Kilkanen cung cấp. Và chỉ vì Java không nằm trên đường dẫn không đảm bảo rằng nó chưa được cài đặt.
Uri avatar
lá cờ gq
Uri
Điều này làm việc cho tôi. log4j không được cài đặt trên máy chủ của tôi. Mặc dù có thể tôi đã cài đặt một ứng dụng sử dụng nó nhưng khả năng là rất thấp.
lá cờ ch
Giới thiệu về các Chương trình Java đã biên dịch: vâng, có thể có với GraalVM/Quarkus/Micronaut/Spring Native, v.v. Tuy nhiên, tôi không chắc liệu Log4J có tương thích với các bản dựng gốc hay không.
user3067860 avatar
lá cờ ng
@Uri Khả năng _rất, rất cao_ là bạn đã cài đặt một ứng dụng sử dụng log4j. Log4j rất, rất phổ biến trong thế giới Java và Java là một ngôn ngữ rất, rất phổ biến.
lá cờ in
Tôi thấy thú vị khi tìm kiếm các trường hợp có lỗ hổng cho phép thực thi các tập lệnh từ xa ngẫu nhiên bằng một dòng lệnh bash chạy tập lệnh từ xa ngẫu nhiên.
lá cờ ua
Chắc chắn, không bao giờ đặt mã không được kiểm tra vào trình bao - hãy đọc trước tập lệnh mà không có ` | bạt`!!!
lá cờ id
> Tôi không chắc liệu có thể có các Chương trình Java được biên dịch chạy trên máy chủ mà không cần cài đặt java hay không. Chắc chắn có thể. Bạn đã bao giờ nghe nói về JRE đi kèm chưa?
Gerrit avatar
lá cờ cn
Lunasec có thông tin tuyệt vời. Họ cũng đã xuất bản hàm băm của các lớp nhị phân log4j dễ bị tổn thương để bạn có thể quét các tệp .jar và .war để tìm chúng. https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/
lá cờ tr
định vị có thể đang sử dụng dữ liệu lỗi thời, trước tiên bạn nên thực hiện cập nhậtb
Gerrit avatar
lá cờ cn
Nếu một ứng dụng biên dịch các lớp tại runtine từ nguồn không được đánh dấu hoặc nó bị xáo trộn về mặt thương mại hoặc tải các lớp bằng trình nạp lớp từ xa thì bạn sẽ phải sử dụng canarytokens hoặc thứ gì đó tương tự và hy vọng rằng bằng cách làm mờ đầu vào, bạn sẽ tìm thấy bất kỳ phiên bản log4j nào.
lá cờ ua
** Điều này mất nhiều thời gian đối với tôi. Tôi đang tìm người mà tôi có thể chuyển quyền sở hữu kho lưu trữ trên GitHub**
lá cờ es
Lưu ý rằng chỉ tìm tên tệp có chứa `log4j` sẽ cho một số kết quả sai, cụ thể là log4j 1.x hoặc `log4j-over-slf4j`, không liên quan gì đến lỗ hổng này trong Log4j 2.x (cụ thể hơn là `log4j-core` giữa các phiên bản 2.0 và 2.15).
Điểm:26
lá cờ in

Không có lệnh nào chắc chắn sẽ cho bạn biết điều đó. Một số ứng dụng gửi các thư viện mà chúng sử dụng trực tiếp dưới dạng tệp jar, một số ứng dụng sẽ chứa chúng trong kho lưu trữ.

Và thậm chí sau đó bạn không biết phiên bản nào được xuất xưởng và nó được sử dụng như thế nào. Cách duy nhất để đảm bảo bạn giảm thiểu CVE là đọc các thông báo bảo mật và ghi chú phát hành ứng dụng của bạn và làm theo lời khuyên của họ.

Điểm:10
lá cờ jp

Hãy thử các lệnh này:

  • dpkg -l | grep liblog4j

  • dpkg -l | nhật ký grep4

  • tìm / -tên log4j-core-*.jar

  • định vị log4j | grep -v log4js

lá cờ cn
`log4js` ở dòng cuối cùng có phải là lỗi đánh máy không?
grofte avatar
lá cờ us
Tôi nên làm `find / -name log4j-core-*.jar 2>/dev/null` hay sử dụng sudo/root?
lá cờ cn
@JanDorniak Tôi không nghĩ vậy. Ý tưởng của họ là tìm tất cả các đề cập đến `log4j`, nhưng loại trừ `log4js`.
lá cờ cn
@GrzegorzOledzki thiếu ngủ.... Tôi nhớ `-v`
dustbuster avatar
lá cờ nf
Tôi đã làm điều này `find / -name *log4j*` và tôi đã sử dụng trình soạn thảo làm công cụ kiểm soát: `find / -name *composer*` và nó đã tìm thấy mọi tệp có tên đó trong đó.
Điểm:5
lá cờ in
yun

Tôi đã viết tập lệnh Python này để tìm các phiên bản Log4j2 dễ bị tấn công trên hệ thống của bạn: https://github.com/fox-it/log4j-finder

Nó hoạt động bằng cách quét đĩa và bên trong các tệp Lưu trữ Java theo cách đệ quy và tìm kiếm các tệp xấu đã biết.

Gerrit avatar
lá cờ cn
Cá nhân đề nghị này. Dễ dàng kiểm tra mã và hoạt động đệ quy trên kho lưu trữ.
lá cờ bm
Mặc dù nó rất đẹp nhưng nó chạy mãi mãi trên máy của tôi. Không biết có bình thường không
Gerrit avatar
lá cờ cn
Bạn đã thử chạy if với -v và/hoặc cây thư mục giới hạn chưa? Nếu bạn có một số ổ đĩa mạng được đính kèm, nó có thể gây ra sự cố.
Điểm:4
lá cờ cn

log4jscanner

Được Google xuất bản theo Giấy phép Apache-2.0, log4jscanner là trình quét hệ thống tệp có lỗ hổng log4j và gói Go để phân tích các tệp JAR.

Điểm:3
lá cờ br

Cố gắng syft. Nó tạo ra một hóa đơn nguyên liệu phần mềm (SBOM), sau đó bạn có thể tìm kiếm các phiên bản log4j cũ (thậm chí hoạt động với hình ảnh docker).

Cái gì đó như syft dir:/opt/foo-application | grep log4j tìm kiếm trong triển khai thông thường. syft dir:/ | grep log4j nên hoạt động cho toàn bộ máy chủ của bạn.

Truyền hình ảnh docker của bạn cũng hoạt động:

# syft -q jacobalberty/unifi:5.13.29 | grep log4j
kho lưu trữ java log4j-api 2.12.1
kho lưu trữ java log4j-core 2.12.1
kho lưu trữ java log4j-slf4j-impl 2.12.1
tomcat-embed-logging-log4j 8.5.2 java-archive

Tạo một tập lệnh để chuyển tất cả các hình ảnh docker của bạn sang syft không quá khó, nhưng bạn có thể tìm thấy một số cảm hứng trong các tập lệnh đó của tôi: https://github.com/debuglevel/syft-grype-utils

lá cờ cn
Hãy xem Grype -- https://github.com/anchore/grype -- bởi cùng một người. Nó nhúng Syft và liệt kê các lỗ hổng đã biết bằng CVE, do đó sẽ trực tiếp cho bạn biết liệu hệ thống của bạn có lỗ hổng hay không.
Điểm:3
lá cờ cn

Xin lỗi vì đã tham khảo tài liệu bên ngoài, tôi hy vọng điều này có thể chấp nhận được trong hoàn cảnh hiện tại.

Thông tin mà Lunasec.io đưa ra về hàm băm của các tệp Java .class nhị phân dễ bị tấn công:

https://github.com/lunasec-io/lunasec/blob/master/tools/log4shell/constants/vulnerablehashes.go

Cũng xem blog của họ: https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/

Bạn có nên có ra lệnh băm (một trên mỗi dòng) của các lớp bị nghi ngờ trong một tệp băm và có một tệp jar chủ đề.jar và có giải nén, tìm thấysha256sum các lệnh, sau đó bạn có thể so sánh với các giá trị băm đã biết với:

JARFILE=subject.jar; DIROUT=$(mktemp -d); giải nén -qq -DD "$JARFILE" '*.class' -d "$DIROUT" && find "$DIROUT" -type f -not -name "*"$'\n'"*" -name '*.class ' -exec sha256sum "{}" \; | cắt -d" " -f1 | sắp xếp | uniq > "$JARFILE"-băm; rm -rf -- "$DIROUT"

comm -12 băm chủ đề.jar-hashes

Nếu liên lạc có đầu ra, sau đó có một hàm băm phù hợp.

Gerrit avatar
lá cờ cn
@rubo77 mình vừa làm xong.
lá cờ ua
cảm ơn vì PR tại https://github.com/rubo77/log4j_checker_beta/pull/6
lá cờ bm
chúng ta có thể sử dụng trực tiếp https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes/blob/main/sha256sums.txt này không? Cảm ơn bạn đã PR
Gerrit avatar
lá cờ cn
Không, đó là các giá trị băm của tệp jar, bạn cần có giá trị băm của tệp .class để kiểm tra lớp. Tôi có thể đề xuất cái này: https://github.com/nccgroup/Cyber-Defence/blob/master/Intelligence/CVE-2021-44228/modified-classes/sha256sum.txt
Gerrit avatar
lá cờ cn
Tôi nên chỉ ra rằng việc kiểm tra dấu vân tay ở cấp độ đầu tiên khá vô ích đối với việc kiểm tra các tệp WAR. Bạn nên giải nén chúng trước. TAI cũng có thể, nhưng gấp đôi. Một số tệp jar cũng có thể chứa các tệp jar khác làm tài nguyên. Tất nhiên, WAR và EAR cũng có thể được giải nén trên cùng một hệ thống tệp.
Điểm:2
lá cờ gb

John Hammond cùng với một số người khác đã xuất bản dịch vụ chuyển hướng LDAP được lưu trữ để bạn có thể bỏ qua tất cả các trò tai quái. https://log4shell.hutress.com/

Chỉ đường rất đơn giản - Nó tạo ID ứng dụng khách cho bạn (có trong URL, cũng như một phần của chuỗi đưa vào) mà bạn có thể đăng lên bất kỳ Biểu mẫu/yêu cầu/hoặc dẫn xuất nào của yêu cầu web.

Nói chung, nếu bạn đang chạy bất cứ thứ gì "không hoạt động với cái này vì nó là quyền truy cập cục bộ" thì bạn vẫn ổn vì không có phương tiện nào để chuyển tiếp qua ứng dụng dựa trên java của bạn.

Lưu ý - Tôi tin rằng phần lớn mối quan tâm nên được đặt ở phần cứng quản lý mạng L2/L3; Đặc biệt nếu bạn đang giao dịch với một ISP hoặc nội dung của bạn được cung cấp qua dịch vụ Lưu trữ.

Elysiumplain avatar
lá cờ gb
Thậm chí đừng để tôi bắt đầu tiêm phần mềm tống tiền bị trì hoãn từ một dịch vụ lưu trữ pwnd chỉ phục vụ phần mềm độc hại được nhúng trong nội dung được yêu cầu.
lá cờ cu
Nguồn có sẵn ở đây. Chạy toàn bộ dịch vụ trên máy của riêng bạn: https://github.com/huntresslabs/log4shell-tester
Điểm:1
lá cờ br

Tất cả các nỗ lực ở đây để giải quyết các lỗ hổng trong log4j đều thất bại. Bạn không thể dựa vào định vị lệnh vì nó chỉ tìm trong một tập hợp các đường dẫn được định cấu hình (/etc/updatedb.conf trên Debian).

Phần mềm có thể tự cài đặt ở những vị trí không được cấu hình trong đã cập nhậtb.conf và hoàn toàn bị bỏ lỡ bởi công việc định kỳ cập nhật cơ sở dữ liệu định vị.

Ngoài ra, người ta cũng phát hiện ra rằng các nhà cung cấp phần mềm (như đàn hồi) đã đóng gói lại JndiLookup.class dễ bị tấn công (ví dụ: elaticsearch-sql-cli-7.16.1.jar) ở những nơi chưa được biết đến trước đây khiến các giải pháp không hoàn chỉnh được xây dựng xung quanh các hàm băm, tên hoặc đường dẫn tệp đã biết.

@shodanshok đang đi đúng hướng ở đây nhưng thay vì tìm kiếm log4j một cách rõ ràng, hãy xem mọi '.jar' trên hệ thống là điều cần thiết.

Cái này đầy đủ hơn, yêu cầu gói zip. và phần mở rộng câu trả lời của shodanshok. Điều này sẽ chỉ hiển thị các vị trí mà JndiLookup.class mã được tìm thấy. Một dòng khác có thể được thêm vào để loại bỏ các lỗ hổng này nhưng tôi muốn để điều đó tùy theo quyết định của quản trị viên. Liên kết đàn hồi ở trên cho thấy cách:

cho jar trong $(find / -name '*.jar'); làm
   giải nén -l "$jar" | grep 'JndiLookup.class' &>/dev/null && echo "Đã tìm thấy lỗ hổng trong $jar"
xong

Ví dụ:

# cho jar trong $(find / -name '*.jar'); làm
> giải nén -l "$jar" | grep 'JndiLookup.class' &>/dev/null && echo "Đã tìm thấy lỗ hổng trong $jar"
> xong
Đã tìm thấy lỗ hổng trong /usr/lib/unifi/lib/log4j-core-2.13.3.jar
Đã tìm thấy lỗ hổng trong /home/minecraft/.m2/repository/org/spigotmc/minecraft-server/1.15.2-SNAPSHOT/minecraft-server-1.15.2-SNAPSHOT.jar
Đã tìm thấy lỗ hổng trong /home/minecraft/.m2/repository/org/spigotmc/minecraft-server/1.15.1-SNAPSHOT/minecraft-server-1.15.1-SNAPSHOT.jar
...

Hãy cảnh giác khi chạy phần mềm này trên hệ thống có hệ thống tệp mạng được gắn kết vì hiệu suất có thể bị ảnh hưởng. Trong những trường hợp đó, bạn cần chạy các lệnh trên chính máy chủ tệp.

Điểm:1
lá cờ ca

Kiểm tra các gói đã cài đặt là không đủ, vì log4j có thể được cài đặt thủ công bởi một số ứng dụng khác.

Đối với các máy chủ Linux, tôi đang sử dụng như sau: tìm / -iname "*log4j*.jar"

Đối với các máy chủ Windows, người ta có thể sử dụng một cái gì đó tương tự như thế: dir C:\*log4j*.jar /s (thay đổi C: đến D: và như vậy cho các đĩa khác).

Tên tệp thường sẽ hiển thị phiên bản thư viện, nhưng để kiểm tra kỹ, bạn có thể mở tệp kê khai và đọc các trường phiên bản/triển khai.

Xin lưu ý rằng ở trên là không đủ để bắt nhúng log4j (ví dụ: trong các tệp jar khác). Đối với những điều này, người ta phải grep chuỗi có liên quan, nhưng điều này khá tốn thời gian và tài nguyên, vì vậy tôi khuyên bạn nên thực hiện tìm kiếm tệp làm bước đầu tiên (nhưng chưa hoàn chỉnh).

lá cờ ua
Có điều gì bị thiếu trong tập lệnh từ https://github.com/rubo77/log4j_checker_beta trong câu trả lời được chấp nhận không?
shodanshok avatar
lá cờ ca
@ rubo77 không, nhưng không phải ai cũng biết chạy tập lệnh github ngẫu nhiên trên máy chủ quan trọng của nhiệm vụ.
lá cờ ua
nó không phải là ngẫu nhiên, hãy nhìn vào nó, nó không xảy ra nhiều trong kịch bản và nó rất dễ hiểu
Điểm:0
lá cờ cn

lsof kiểm tra các tệp đang mở, được đăng bởi Florian Roth trên Twitter:

phụ trợ ps | egrep '[l]og4j'
lsof | grep log4j

hai lệnh khác nữa, nhưng đây là các lệnh tìm kiếm thường trú, trong bộ nhớ

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.