Демонстрація вразливості на Ubuntu 9.04

Щодо заняття з ІТ-безпеки, я хочу продемонструвати студентам ескалацію привілеїв. Для цього я ознайомився зі exploit/linux/localсписком у рамках Metasploit Framework, знайшовши (серед інших) exploit/linux/local/sock_sendpageсерпень 2009 року.

Я створив віртуальну машину з 32-бітної Ubuntu Server 9.04 ( http://old-releases.ubuntu.com/releases/9.04/ubuntu-9.04-server-amd64.iso ) з квітня 2009 року uname -rдає мені 2.6.28-11-generic. За описом експлуату

Вважається, що всі версії Linux 2.4 / 2.6 з травня 2001 року постраждали: 2.4.4 до 2.4.37.4 включаючи; 2.6.0 до включно 2.6.30.4

Тож здається, що сервер Ubuntu, який я встановив, повинен бути придатним для демонстрації. Однак мені не вдалося змусити його працювати.

Я додав (звичайного) користувача на сервер і SSH доступ працює. В рамках Metasploit Framework я можу створити сеанс SSH, використовуючи auxiliary/scanner/ssh/ssh_login. Однак, коли я запускаю подвиг, я отримую

[*] Writing exploit executable to /tmp/mlcpzP6t (4069 bytes)

[*] Exploit completed, but no session was created.

Я не отримую жодної додаткової інформації, навіть коли встановлено DEBUG_EXPLOITзначення true. /tmpтакож написано з сесії Metasploit SSH:

$ sessions -c "touch /tmp/test.txt"
[*] Running 'touch /tmp/test.txt' on shell session 1 ([redacted])

$ sessions -c "ls -l /tmp"
[*] Running 'ls -l /tmp' on shell session 1 ([redacted])

total 0

-rw-r--r-- 1 [redacted] [redacted] 0 2016-03-28 09:44 test.txt

Я також спробував налаштувати WriteableDirдомашній каталог користувача на сервері, але без змін. Що я тут пропускаю? Чи не вразлива ця версія сервера Ubuntu (яку я навмисно не оновлювала!)?

Випуск 9.04 підтримувався до 23 жовтня 2010 р. Про виявлену вразливість повідомлялося в серпні 2009 р. Здається, розумним є те, що, оскільки випуск був ще актуальним та підтримуваним на той час, ISO був виправлений, а те, що ви завантажили, - це версія, яка є більше не вразливі.

Крім того, ви, здається, досить добре продемонстрували, що він не вразливий. Зрештою, ви спробували подвиг, і, схоже, це не вдалося.

Чому б не спробувати новіший подвиг? Щось на зразок CVE-2013-2094, що також повинно вплинути на Ubuntu , наприклад.

Це не відповідає вашому конкретному запиту, швидше дає вам більше можливостей приватного ессексуалу, щоб показати студентам ...

Ви можете також розглянути наступні дві помилки-конфігурації адміністратора, які можуть призвести до priv esc на 'nix (Є багато інших способів пропустити конфігурацію вікна' nix, що може дозволити priv esc, тому, будь ласка, врахуйте це пригніченням апетиту) ….

1. бінарні файли suid та guide, що належать кореневій / кореневій групі ( find / -uid 0 -perm -4000 -type f 2>/dev/nullта find / -uid 0 -perm -2000 -type f 2>/dev/null), і перевірити, чи є вони в усьому світі, щоб дозволити користувачеві з низькими правами змінювати їх; папку, в якій вони існують, можна записати вашим низькодоступним користувачем - для можливого введення бібліотечного шляху. Що стосується бібліотек, які вони використовують - чи можна змінити: перевірте значення будь-яких заголовків DT_RPATHта DT_RUNPATHELF у бінарних файлах за допомогою однієї з наступних команд:

   • objdump -x ...
   • readelf -a ...
   • scanelf (від PaX)
   • elfdump (від Сонця)
   • readelf -a binary | grep PATH

2. sudoers недоліки

   • NOPASSWD - Місцевий зловмисник може використовувати цей доступ для ескалації своїх привілеїв в операційній системі, коли користувач забуває заблокувати екран

   • Відсутній виконуваний файл у Sudoers - Деякі виконувані файли у /etc/sudoersфайлі не існують. Якщо виконувані файли створені, їх можна запустити через sudo як root, що дозволить ескалацію привілеїв.

   • Записи осиротілих судурів - /etc/sudoersфайл може містити ряд осиротілих записів, для яких у /etc/passwdфайлі немає відповідного облікового запису . Якби користувач був створений з одним із осиротілих імен, він би надав користувачеві засоби для ескалації привілеїв до повного доступу до кореня.

   • Деякі програми не повинні мати судоподібні vi, використовувати :eабо Ctrl o використовувати :wдля доступу /etc/shadow.

   • Неправильно продумана / погана команда, що використовується у файлі sudoers - я часто бачу httpdв sudoers - тому спробуйте, як користувач із низьким приватним доступом із доступом до sudo, виконати саме цю команду ( sudo -lабо sudo -llпокаже, що може зробити користувач): sudo /usr/bin/httpd -t /etc/shadowі подивіться на помилку.

   • Перевірка файлів команд і файлів, згаданих у sudoers, є слабкою - дивіться мій попередній параграф про бінарні файли suid та guide, що належать root