Có cách nào kẻ tấn công có thể sử dụng mkdir để thỏa hiệp một hệ thống không?


22

Tôi đang thiết lập một tài khoản người dùng bị hạn chế cho người dùng ricardo, một người dùng rắc rối trên hệ thống của tôi. Tôi muốn cấp cho anh ta quyền tạo thư mục bằng cách sử dụng sudo, điều mà đôi khi anh ta cần phải làm. Tôi đang xem xét quy tắc này trong /etc/sudoerstệp của mình :

ricardo   ALL=(root) NOPASSWD: /bin/mkdir

Chỉ sử dụng quy tắc này, có cách nào ricardo có thể cố ý hoặc vô tình thỏa hiệp hệ thống?


2
Nếu bạn có một hệ thống tập tin với số lượng inode tĩnh, anh ta có thể sử dụng hết tất cả các nút của bạn.
jordanm

2
@schaiba Anh ấy thích mày mò và xem liệu anh ta có thể khai thác hệ thống không và không phải lúc nào cũng đọc các trang nam nhiều như anh ta nên.
Ricardo Altamirano

8
Một nền giáo dục người dùng phù hợp, kết hợp với không có sudo tại thời điểm hiện tại, sẽ là điều nên làm từ tôi.
schaiba

2
Như @schaiba nói, bạn có thể sử dụng những người dùng như vậy bằng cách dạy họ và giao cho họ trách nhiệm (dưới sự giám sát chặt chẽ). Tôi đã chứng kiến ​​các cuộc chiến giữa sysdamins và người dùng, vì những người đầu tiên đã cố gắng khóa hệ thống quá nhiều. Người dùng vượt trội so với các hệ thống từ 10 đến 1, và thậm chí sau đó ( không có truy cập Internet ngày nay!) Sự thất bại của các sysdamins thật nhục nhã. Không bao giờ có được vào một vị trí như vậy!
vonbrand

2
Đó là trường hợp của một ricardo quá nhiều. Hoặc ít nhất, do đó, đánh bại BOFH ...
Deer Hunter

Câu trả lời:


21

Tôi nghi ngờ một cuộc tấn công như thế này sẽ hoạt động, trong đó «cái gì đó» là một mô-đun hạt nhân sẽ cố tải sau khi rootfs được gắn kết:

$ sudo mkdir -m 777 /lib/modules/`uname -r`/a
$ cp evil.ko /lib/modules/`uname -r`/a/«something».ko

Cũng lưu ý rằng bạn có thể sử dụng các tên khác, tùy thuộc vào các bí danh được khai báo trong mô-đun. Tôi đoán nó sẽ không được tải cho đến khi depmod được chạy, điều này sẽ xảy ra vào lần tới khi có bản cập nhật kernel, vì vậy, mkdirnó thậm chí sẽ không hiển thị gần đây trong nhật ký sudo.

Có rất nhiều thứ trong / etc đọc tất cả các tệp trong một thư mục, đôi khi được đệ quy. Thậm chí tệ hơn, một số trong những thư mục đó không tồn tại theo mặc định và cách duy nhất để biết về chúng là đọc manpage, init script, v.v. cho chương trình sử dụng chúng. Một số, thậm chí tệ hơn, là những thứ không tương thích ngược, và thậm chí có thể không được ghi lại nữa.

chỉnh sửa: Suy nghĩ của một vài thư mục, trong /usr/local:

  • /usr/local/lib/perl/5.14.2(khác nhau tùy thuộc vào phiên bản Perl, hãy thử perl -Vtìm hiểu). Tạo một Filethư mục con trong đó, và đặt một Find.pmtrong đó. Bây giờ bất cứ khi nào bất cứ ai sử dụng File::Find, họ sẽ sử dụng phiên bản của kẻ tấn công. Tương tự, làm tương tự với Getopt::Long. Các tiện ích hệ thống thường được viết bằng Perl, vì vậy điều này có thể cho root. (Thử ack-grep --color -a 'use.+::' /usr/sbin | less -R)
  • Tôi nghĩ Python, Ruby, v.v ... có các thư mục tương tự. Các tiện ích hệ thống cũng được viết bằng Python.
  • Phá hoại nhiều thứ mà ai đó biên dịch với các thư mục con của /usr/local/include.

Ồ, nhưng nếu <evil user> có thể sao chép các mô-đun vào nơi kernel sẽ tải chúng, trò chơi kết thúc trước khi bắt đầu.
vonbrand

1
@vonbrand <evil user> thông thường không thể, nhưng đã sử dụng anh ta sudo mkdirđể tạo một thư mục mới nơi anh ta có thể.
derobert

20

Bằng cách chạy mkdirvới quyền root, người dùng có thể chặn các tiến trình / người dùng khác tạo các tệp và thư mục mới bằng cách tạo các thư mục có tên giống nhau (và / hoặc quyền sai) trước đó.

Đây có thể là an ninh có liên quan đặc biệt là với log- và lock- tập tin.

Như jordanm lưu ý, số lượng tối đa của inodes cũng có thể được sử dụng hết mà có thể chặn toàn bộ hệ thống.

Bằng cách thêm người dùng vào các nhóm cụ thể (hoặc sử dụng ACL ), bạn sẽ có thể giải quyết các vấn đề mà không cần cấp bất kỳ quyền nào thông qua sudo.


Điểm tuyệt vời. Có lẽ tôi sẽ rời mkdirkhỏi danh sách các lệnh ricardo được phép sử dụng.
Ricardo Altamirano

Nếu nó là để làm cạn kiệt các nút, một đơn giản for((i = 0;; i++)); do touch $i; donesẽ làm tốt (bashism, xin lỗi; nhưng bạn có ý tưởng).
vonbrand

@vonbrand Ngoại trừ đó không phải là root, vì vậy nó sẽ bị chặn bởi hạn ngạch. Tất nhiên, các sudolệnh khác mà OP đang xem xét cũng có thể cho phép hết các nút; OP cần phải biết về vector DoS đó.
derobert

11

Bạn nên chuyển hướng anh ta đến một nhà tù chroot. Hoặc thậm chí tốt hơn, với một VM nhỏ, rằng anh ta có thể gặp sự cố một lần một giờ. Tất cả bạn cần làm là cung cấp một bản sao mới.


Tôi rất khuyến khích điều này. Cung cấp cho anh ta quyền truy cập root trên VM của riêng mình.
emory

đến một chroot ^ H ^ H ^ H ^ H ^ Hounty prison ...
Deer Hunter

6

Có khả năng do có thể tạo thư mục với quyền truy cập ghi. Với mkdir -m 777 blahnhững ricardongười sử dụng có thể viết bất cứ điều gì họ thích vào thư mục mới. Bạn sẽ cần một quá trình trên hệ thống đã chạy như một người dùng khác sẽ lặp lại một cây thư mục để tải cấu hình, tập lệnh hoặc mô-đun. Sau đó, người dùng có thể có thể thêm những thứ của riêng họ sẽ được tải hoặc chạy. Điều đầu tiên tôi có thể nghĩ đến là nếu bạn chạy một máy chủ web có thể thực thi php hoặc cgi. Sau đó, bạn có thể chạy các tập lệnh như người dùng đó. Tôi đang vật lộn để đưa ra nhiều ví dụ thực tế hơn, đặc biệt là rootnhững ví dụ nhưng tôi chắc chắn họ sẽ làm được.

ssh là một ví dụ về một daemon bẫy loại kịch bản này. Nếu bạn đã tạo một .sshthư mục cho người dùng chưa có và đặt authorized_hoststệp của riêng bạn vào vị trí. sshdthông báo rằng các quyền của thư mục quá mở và bỏ qua khóa chung.

Bạn chắc chắn có thể gây phiền toái cho chính mình khi tạo các thư mục nơi các tệp được dự kiến ​​sẽ xuất hiện (như tệp tmp tạm thời hoặc tệp hoán đổi) mà rất nhiều chương trình sẽ không xử lý tốt.

Bạn có thể tạo nhiều nhóm nhưng không có vẻ gì là bạn làm gì với họ. Bạn có thể có thể mang một hệ thống đến đầu gối ít nhất. Phải mất khoảng 10000 cgroup trên một hộp với 256M để kẻ giết OOM lấy ra sshd.

Nếu bạn kiểm soát -mtùy chọn mkdirvà UMASK của sudomôi trường, tôi nghĩ rằng nó trở lại chỉ là một mối phiền toá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.