Matasano đã bị hack như thế nào?

từ: http://seclists.org/fulldisclenses/2009/Jul/0388.html

Nếu tôi hiểu nó tốt nhất từ ​​các bài đăng từ: http://news.ycombinator.com/item?id=723798, những người Matasano có thể truy cập internet sshd - bất kỳ giải pháp đề xuất nào cho việc này (từ quan điểm lập trình)?

Matasano đã bị hack như thế nào?

Điều đó là không thể trả lời từ thông tin trong bài đăng đến Tiết lộ đầy đủ. Tuy nhiên, thật thú vị khi suy đoán, vì họ đưa ra một ít thông tin -

# ./th3_f1n4l_s0lut10n www.matasano.com
[-] Kết nối với 69.61.87.163:22 ..
[/] Tìm kiếm người dùng không root hợp lệ .. adam
******** R3D4CT3D h4h4h4h4 ********

Họ chạy nhị phân " th3_f1n41_s01ut10n" chống lại máy chủ của Matasano, kết nối với cổng ssh. Nó tìm thấy một người dùng không root hợp lệ thông qua một số phương tiện không xác định và phần còn lại của đầu ra được điều chỉnh lại.

# ./th3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com
[*] Trình nghe kết nối trên 209.112.118.10:3338 ..
[!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8g ngày 19 tháng 10 năm 2007] 

Nhị phân được chạy lại bằng tên người dùng đã tìm thấy, đăng nhập và kết nối trở lại máy chủ của họ trên cổng 3338 (hy vọng điều đó không được đăng ký trong tên của họ ...).

adam_at_www: ~ $ uname -a
Linux www 2.6.20.1-1-686 # 1 SMP Chủ Nhật 4 tháng 3 12:44:55 UTC 2007 i686 GNU / Linux
**** h4h4h4hh4h4h4 l3tz us3 m0r3! 0D4Y! H4H4H4H4H4H4H4 ****

Họ có thể ngụ ý rằng họ có 0 ngày đối với hạt nhân này, điều này khá cũ khi bạn xem xét giao dịch chứng khoán của công ty này.

adam_at_www: ~ $ cd / tmp
****** / 4 B0R1NG
root_at_www: ~ # cat / etc / bóng 

Rất tiếc - tất cả người dùng đột nhiên đã root. Họ có một khai thác leo thang đặc quyền địa phương trong / tmp có thể là 0 ngày họ đề cập.

Vì vậy, có ít nhất hai lần khai thác đang diễn ra ở đây - khai thác OpenSSH để có được một người dùng không phải root hợp lệ trên hệ thống và đăng nhập với tư cách là người dùng đó, sau đó leo thang đặc quyền cục bộ.

Xem xét rằng OpenSSH có một vài vấn đề bảo mật đã biết kể từ phiên bản 4.5:

Từ trang bảo mật của OpenSSH :

• OpenSSH trước phiên bản 5.2 dễ bị tổn thương bởi điểm yếu của giao thức được mô tả trong CPNI-957037 "Tấn công phục hồi Plaintext chống lại SSH". Tuy nhiên, dựa trên thông tin hạn chế có sẵn, có vẻ như cuộc tấn công được mô tả này là không khả thi trong hầu hết các trường hợp. Để biết thêm thông tin, vui lòng tham khảo tư vấn cbc.adv và ghi chú phát hành OpenSSH 5.2.
• OpenSSH 4.9 và mới hơn không thực thi ~/.ssh/rccho các phiên có lệnh đã bị ghi đè bằng lệnh sshd_config (5) ForceCommand. Đây là một hành vi được ghi lại nhưng không an toàn (được mô tả trong ghi chú phát hành OpenSSH 4.9).
• OpenSSH 4.7 và mới hơn không quay trở lại để tạo cookie xác thực X11 đáng tin cậy khi việc tạo cookie không đáng tin cậy không thành công (ví dụ do cạn kiệt tài nguyên có chủ ý), như được mô tả trong ghi chú phát hành OpenSSH 4.7.

Tôi đoán có nhân Linux cũ hơn và trình nền SSH cũ hơn đã làm cho họ. Ngoài ra, nó đã chạy trên máy chủ www của họ, có sẵn trên Internet, đây là một điều khá tự tin để làm theo ý kiến ​​của tôi. Những người đột nhập rõ ràng muốn làm họ xấu hổ.

Làm thế nào để ngăn chặn các cuộc tấn công này?

Điều này có thể được ngăn chặn bởi chính quyền chủ động - đảm bảo mọi dịch vụ truy cập internet đều được vá và hạn chế số người có thể kết nối thay vì cho phép mọi người kết nối từ bất cứ đâu. Phần này kết hợp bài học rằng quản trị hệ thống an toàn là khó, và đòi hỏi sự cống hiến từ doanh nghiệp để cung cấp thời gian cho CNTT để giữ cho mọi thứ được vá - trong thực tế, không phải là điều dễ dàng xảy ra, ít nhất là trong các công ty nhỏ hơn.

Sử dụng phương pháp tiếp cận vành đai và niềng răng là tốt nhất - sử dụng xác thực khóa chung, liệt kê danh sách trắng trên ssh daemon, xác thực hai yếu tố, hạn chế IP và / hoặc đặt mọi thứ phía sau VPN là các tuyến có thể khóa nó.

Tôi nghĩ rằng tôi biết những gì tôi sẽ làm trong ngày mai. :)

Mọi người thích tạo FUD hơn thế, nhưng có vẻ như họ biết rằng người dùng adam đã ở đó và biết mật khẩu của anh ta (có thể thông qua vũ lực hoặc các phương pháp khác). Tuy nhiên, họ muốn trông thật ngầu và tạo ra sự ồn ào này.

Một điều thú vị cần lưu ý là adam người dùng đã không đăng nhập vào hộp đó trong hơn một năm:

(đầu ra của Lastlog)

 adam             pts/1    ool-4350ab48.dyn Sat Jul 26 20:45:18 -0400 2008

Vì vậy, anh ta có thể giữ mật khẩu đó (có thể là một mật khẩu xấu) trong một thời gian.

* Nếu họ thực sự có một công cụ để khám phá tên người dùng thông qua SSH, họ có thể đã sử dụng tất cả những người dùng khác để có quyền truy cập từ xa, nhưng họ đã sử dụng tên người dùng phổ biến nhất trong hộp đó (dễ đoán).

Tại sao bạn sẽ thử và giải quyết điều này từ quan điểm lập trình?

Thay vào đó, bạn nên giải quyết nó từ quan điểm quản trị viên máy chủ thông minh. Có một vài gợi ý tuyệt vời trong các bình luận về các liên kết bạn đã đăng, chẳng hạn như sử dụng danh sách trắng.

Tôi cũng muốn nói thêm rằng, bởi vì bạn đang hỏi ở đây, rất có thể bạn không phải là một chuyên gia bảo mật, và bất cứ điều gì bạn có thể nghĩ để viết sẽ chỉ thêm nhiều lỗ hổng. Đây thực sự không phải là một câu hỏi lập trình.

Bảo vệ phần mềm của bạn khỏi các cuộc tấn công 0 ngày ... đó là điều không thể.

Có thể một cách tiếp cận tốt là tuyên bố rằng phần mềm của bạn không thể chạy được, điều này sẽ khiến những người da trắng dùng thử và tiết lộ đầy đủ mọi thứ, để lại ít lỗ hổng hơn. Oracle 10 đã có yêu cầu này, sau đó vào ngày hôm sau, có 9 lỗ hổng mới được tìm thấy. Bây giờ nó khá an toàn.

Rất có thể, hacker đã lạm dụng cấu hình của phần mềm hoàn toàn tốt

Tôi nghĩ rằng họ có rất nhiều người dùng có vỏ trên máy đó. đó là cách họ sở hữu chắc chắn, mọi thứ khác đều là cá trích đỏ nhằm đánh lạc hướng. một trong số họ đã nhận được ứng dụng khách ssh của họ ở cửa sau trên một số máy shell khác và sau đó là trò chơi kết thúc. cung cấp cho mọi người tài khoản shell và làm cho thế giới sshd có thể truy cập chỉ là lười biếng và ngu ngốc.