SSH lạ, Bảo mật máy chủ, tôi có thể đã bị hack


30

Tôi không chắc mình đã bị hack hay chưa.

Tôi đã cố đăng nhập thông qua SSH và nó sẽ không chấp nhận mật khẩu của tôi. Root đăng nhập bị vô hiệu hóa vì vậy tôi đã đi cứu và bật đăng nhập root và có thể đăng nhập với quyền root. Với quyền root, tôi đã cố gắng thay đổi mật khẩu của tài khoản bị ảnh hưởng với cùng mật khẩu mà tôi đã cố đăng nhập trước đó, passwdtrả lời là "mật khẩu không thay đổi". Sau đó tôi đã thay đổi mật khẩu thành một thứ khác và có thể đăng nhập, sau đó thay đổi mật khẩu trở lại mật khẩu ban đầu và tôi lại có thể đăng nhập.

Tôi đã kiểm tra auth.logthay đổi mật khẩu nhưng không tìm thấy gì hữu ích.

Tôi cũng đã quét virus và rootkit và máy chủ trả về điều này:

Ngao:

"/bin/busybox Unix.Trojan.Mirai-5607459-1 FOUND"

RKHunter:

"/usr/bin/lwp-request Warning: The command '/usr/bin/lwp-request' has been replaced by a script: /usr/bin/lwp-request: a /usr/bin/perl -w script, ASCII text executable

Warning: Suspicious file types found in /dev:"

Cần lưu ý rằng máy chủ của tôi không được biết đến rộng rãi. Tôi cũng đã thay đổi cổng SSH và kích hoạt xác minh 2 bước.

Tôi lo lắng rằng tôi đã bị hack và ai đó đang cố lừa tôi, "mọi thứ đều ổn, đừng lo lắng về điều đó".


10
Đồng ý với Michael. Có vẻ như Mirai sử dụng đoán mật khẩu mạnh mẽ để thỏa hiệp các máy chủ linux - incapsula.com/blog/malware-analysis-mirai-ddos-botnet.html . Sử dụng xác thực khóa công khai sẽ tốt hơn thay đổi cổng SSH cho mục đích bảo mật IMHO.
Josh Morel

3
@JoshMorel Tôi sẽ đi xa hơn và nói rằng việc thay đổi cổng SSH là bất lợi cho bảo mật. Nó không giúp bảo vệ bất cứ điều gì, nhưng những người làm sai cảm thấy an toàn hơn. Vì vậy, bằng cách cảm thấy an toàn hơn mà không thực sự an toàn hơn, họ trở nên tồi tệ hơn trước. Ngoài ra, tôi muốn nói pubkey auth không chỉ đơn giản là tốt hơn, mà là phải.
marcelm

10
"... nó không chấp nhận mật khẩu của tôi ... nó trả lời" mật khẩu không thay đổi "... sau khi thay đổi mật khẩu thành thứ khác tôi có thể đăng nhập, tôi đã thay đổi mật khẩu trở lại như cũ và tôi vẫn có thể để đăng nhập." - Tất cả những gì có thể được giải thích bằng cách bạn tạo lỗi chính tả trong mật khẩu của bạn (hoặc có khóa mũ) trước khi bạn đến người dùng cứu hộ.
marcelm

2
việc phát hiện trojan busybox bằng clamav cũng xảy ra với tôi, sáng nay lần đầu tiên, trên ~ 100 hệ thống; Tôi đang bỏ phiếu sai tích cực. Tôi đoán clamav đã cập nhật cơ sở dữ liệu sig của họ để có sự khởi đầu tích cực sai này xuất hiện qua đêm tối qua
JDS

2
Ngẫu nhiên, băm sha256 của busybox của tôi trên các hệ thống này là 7fa3a176871de12832ca8a78b646bc6be92f7f528ee81d1c35bf12aa99292b1c. Đây là các hệ thống Ubuntu 14.04 và thời gian hoạt động trên thùng bận là 2013-11-14
JDS

Câu trả lời:


30

Giống như J Rock, tôi nghĩ rằng đây là một dương tính giả. Tôi đã có kinh nghiệm tương tự.

Tôi đã nhận được một báo động từ 6 máy chủ khác nhau, khác biệt về mặt địa lý trong một khoảng thời gian ngắn. 4 trong số các máy chủ này chỉ tồn tại trên một mạng riêng. Điểm chung của họ là cập nhật Daily.cld gần đây.

Vì vậy, sau khi kiểm tra một số heuristic điển hình của trojan này mà không thành công, tôi đã khởi động một hộp mơ hồ với đường cơ sở sạch đã biết của tôi và chạy Freshclam. Cái này lấy

"Daily.cld được cập nhật (phiên bản: 22950, ​​sigs: 1465879, f-level: 63, builder: neo)"

Sau đó đã clamav /bin/busyboxtrả lại cùng một cảnh báo "/ bin / busybox Unix.Trojan.Mirai-5607459-1 FOUND" trên các máy chủ gốc.

Cuối cùng, đối với biện pháp tốt, tôi cũng đã làm một hộp lang thang từ chính thức của Ubuntu hộp và cũng có cùng "/ bin / busybox Unix.Trojan.Mirai-5.607.459-1 Found" (Lưu ý, tôi đã phải lên bộ nhớ trên hộp lang thang này từ 512MB mặc định hoặc clamscan không thành công với 'kill')

Đầu ra đầy đủ từ hộp mơ hồ Ubuntu 14.04.5 mới.

root@vagrant-ubuntu-trusty-64:~# freshclam
ClamAV update process started at Fri Jan 27 03:28:30 2017
main.cvd is up to date (version: 57, sigs: 4218790, f-level: 60, builder: amishhammer)
daily.cvd is up to date (version: 22950, sigs: 1465879, f-level: 63, builder: neo)
bytecode.cvd is up to date (version: 290, sigs: 55, f-level: 63, builder: neo)
root@vagrant-ubuntu-trusty-64:~# clamscan /bin/busybox
/bin/busybox: Unix.Trojan.Mirai-5607459-1 FOUND

----------- SCAN SUMMARY -----------
Known viruses: 5679215
Engine version: 0.99.2
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 1.84 MB
Data read: 1.83 MB (ratio 1.01:1)
Time: 7.556 sec (0 m 7 s)
root@vagrant-ubuntu-trusty-64:~#

Vì vậy, tôi cũng tin rằng đây có thể là một dương tính giả.

Tôi sẽ nói, rkhunter không đưa cho tôi tài liệu tham khảo: "/ usr / bin / lwp-request Cảnh báo", vì vậy có lẽ PhysiOS Quantum đang gặp nhiều vấn đề.

EDIT: chỉ nhận thấy rằng tôi chưa bao giờ nói rõ ràng rằng tất cả các máy chủ này là Ubuntu 14.04. Các phiên bản khác có thể thay đổi?


1
Tôi sẽ thay đổi xác thực SSH của mình cho một pubkey và tôi sẽ cố gắng theo dõi các kết nối mạng, nhưng thành thật mà nói nó thực sự tồi tệ hơn vì tôi thậm chí còn sao chép và dán mật khẩu và nó vẫn từ chối nó. Tôi nên làm gì với / usr / bin / lwp-request?
PhysiOS

1
Tôi cũng nhận được thông báo này sáng nay trên máy chủ Ubuntu 14.04. Tôi đã so sánh ( sha1sum) /bin/busyboxtệp của máy chủ của tôi với cùng một tệp trên máy ảo cục bộ được tạo từ hình ảnh Ubuntu và chúng giống hệt nhau. Vì vậy, tôi bỏ phiếu sai tích cực quá.
agregoire

3
@PhysiOSQuantum Không có gì. Đó cũng là một kết quả dương tính giả - lwp-request là một công cụ liên quan đến mô-đun Perl ( metacpan.org/pod/LWP ), do đó, nó hoàn toàn bình thường đối với nó là một tập lệnh.
duskwuff

45

Chữ ký ClamAV cho Unix.Trojan.Mirai-5607459-1 chắc chắn là quá rộng, do đó có thể là dương tính giả, như J Rock và cayleaf ghi nhận.

Ví dụ: bất kỳ tệp nào có tất cả các thuộc tính sau sẽ khớp với chữ ký:

  • đó là tệp ELF;
  • nó chứa chuỗi "watchdog" chính xác hai lần;
  • nó chứa chuỗi "/ Proc / self" ít nhất một lần;
  • nó chứa chuỗi "busybox" ít nhất một lần.

(Toàn bộ chữ ký phức tạp hơn một chút, nhưng các điều kiện trên là đủ cho một trận đấu.)

Ví dụ: bạn có thể tạo một tệp như vậy với:

$ echo 'main() {printf("watchdog watchdog /proc/self busybox");}' > innocent.c
$ gcc -o innocent innocent.c
$ clamscan --no-summary innocent
innocent: Unix.Trojan.Mirai-5607459-1 FOUND

Bất kỳ bản dựng busybox nào (trên Linux) thường sẽ khớp với bốn thuộc tính tôi liệt kê ở trên. Đây rõ ràng là một tệp ELF và nó chắc chắn sẽ chứa chuỗi "busybox" nhiều lần. Nó thực thi "/ Proc / self / exe" để chạy các applet nhất định. Cuối cùng, "watchdog" xảy ra hai lần: một lần dưới dạng tên applet và một lần bên trong chuỗi "/var/run/watchdog.pid".


20
Tôi có thể đọc chữ ký đó ở đâu và những người khác từ ClamAV, vì tò mò?
Délisson Junio

2
Tôi biết ai đó thông minh hơn tôi sẽ có thể giải thích tại sao đó là dương tính giả. Cảm ơn!
cayleaf

3
@ Délisson Junio: Tạo một thư mục trống, cd vào đó và chạy sigtool --unpack-current dailyđể giải nén Daily.cvd (hoặc sigtool --unpack-current mainđể giải nén main.cvd). Nếu bạn grep các tệp kết quả cho "Unix.Trojan.Mirai-5607459-1", bạn sẽ tìm thấy chữ ký, xuất hiện trong Daily.ldb. Định dạng chữ ký được giải thích trong Signatures.pdf (đi kèm với gói clamav-docs trong Ubuntu).
du mục

6

Điều này vừa xuất hiện cho tôi hôm nay cũng như trong lần quét ClamAV của tôi cho / bin / busybox. Tôi tự hỏi nếu cơ sở dữ liệu cập nhật có lỗi.


2
Quét / bin / busybox trên mọi Ubuntu 14.04 LTS với cơ sở dữ liệu ClamAV mới nhất. Nó trở lại bị nhiễm bệnh. Đây là một dương tính giả, IMO.
J Rock

2
Tôi đã gửi một báo cáo tích cực sai cho ClamAV. Tôi cũng thấy rằng các tệp nhị phân của người chơi vmware hiển thị là bị nhiễm cùng một trojan. Có khả năng họ đã bao gồm mã busybox.
J Rock

4

Tôi đã cố đăng nhập thông qua SSH và nó sẽ không chấp nhận mật khẩu của tôi. Root đăng nhập bị vô hiệu hóa vì vậy tôi đã đi cứu và bật đăng nhập root và có thể đăng nhập với quyền root. Với quyền root, tôi đã cố gắng thay đổi mật khẩu của tài khoản bị ảnh hưởng bằng chính mật khẩu mà tôi đã cố đăng nhập trước đó, passwd trả lời với "mật khẩu không thay đổi". Sau đó tôi đã thay đổi mật khẩu thành một thứ khác và có thể đăng nhập, sau đó thay đổi mật khẩu trở lại mật khẩu ban đầu và tôi lại có thể đăng nhập.

Điều này nghe có vẻ như mật khẩu đã hết hạn. Đặt mật khẩu (thành công) bằng cách đặt lại đồng hồ hết hạn mật khẩu. Bạn có thể kiểm tra / var / log / safe (hoặc bất cứ thứ gì tương đương với Ubuntu) và tìm hiểu lý do tại sao mật khẩu của bạn bị từ chối.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.