Я є root. Розбираємось у підвищенні привілеїв OS Linux

Перший квартал 2020 року я провів за підготовкою до іспиту OSCP. Пошук інформації в Google та безліч «сліпих» спроб забирали у мене весь вільний час. Особливо непросто виявилося розібратися в механізмах підвищення привілеїв. Курс PWK приділяє цій темі велику увагу, проте методичних матеріалів завжди недостатньо. В Інтернеті є купа мануалів із корисними командами, але я не прихильник сліпого дотримання рекомендацій без розуміння, до чого це призведе.

Мені хочеться поділитися з вами тим, що вдалося дізнатися за час підготовки та успішного складання іспиту (включаючи періодичні набіги на Hack The Box). Я відчував сильне відчуття подяки до кожної крихти інформації, яка допомагала мені пройти шлях Try Harder більш усвідомлено, зараз мій час віддати належне ком'юніті.

Я хочу дати вам мануал з підвищення привілеїв в OS Linux, що включає розбір найбільш частих векторів і суміжних фішок, які вам обов'язково знадобляться. Найчастіше самі механізми підвищення привілеїв досить нескладні, проблеми виникають при структуруванні та аналізі інформації. Тому я вирішив почати з оглядової екскурсії і далі розглядати кожен вектор в окремій статті. Сподіваюся, заощаджу вам час на вивчення теми.

Я є root. Розбираємось у підвищенні привілеїв OS Linux

Отже, чому підвищення привілеїв взагалі можливе 2020-го, якщо методи добре відомі вже дуже давно? Насправді при грамотному поводженні користувача із системою підвищити привілеї в ній справді не вдасться. Основна глобальна проблема, яка породжує такі можливості, полягає в небезпечної конфігурації. Наявність у системі застарілих версій ПЗ, що містять уразливості, також є окремим випадком небезпечної конфігурації.

Підвищення привілеїв через небезпечну конфігурацію

Насамперед давайте розберемося з небезпечною конфігурацією. Почнемо з того що ІТ-фахівці часто користуються мануалами та ресурсами на кшталт stackoverflow, багато з яких містять небезпечні команди та конфіги. Яскравий приклад - новина про те, що код, що найбільше копіюється зі stackoverflow, містив помилку. Досвідчений адмін побачить одвірок, але це — в ідеальному світі. Навіть грамотні фахівці при підвищеного робочого навантаження здатні припускатися помилок. Уявіть, що адмін займається підготовкою та погодженням документації на черговий тендер, паралельно вникає в нову технологію, яку належить впровадити у наступному кварталі, при цьому періодично вирішує завдання підтримки користувачів. І тут йому нарізають завдання швидко підняти пару віртуалок і розкотити на них послуги. Як ви думаєте, яка ймовірність того, що адмін просто не помітить одвірок? Потім фахівці змінюються, а милиці залишаються, при цьому компанії завжди прагнуть мінімізувати витрати, у тому числі на ІТ-шників.

Псевдооболонка та jailbreak

Системна оболонка, отримана на стадії експлуатації, часто буває обмеженою, особливо якщо ви придбали її через злом користувача веб-сервера. Наприклад, обмеження оболонки можуть завадити застосувати команду sudo з виведенням помилки:

sudo: no tty present and no askpass program specified

Після отримання оболонки я рекомендую створити повноцінний термінал, наприклад, за допомогою Python.

python -c 'import pty;pty.spawn("/bin/bash")'

Ви запитаєте: "Навіщо мені тисяча команд, якщо я можу скористатися однією, наприклад, для передачі файлів?" Справа в тому, що системи бувають налаштовані по-різному, на черговому хості може бути не встановлений Python, але є Perl. Майстерність у тому, щоб мати можливість робити у системі звичні речі без звичних інструментів. Повний перелік можливостей можна знайти тут.

Низькопривілейований шелл можна отримати, використовуючи команди 1 и команди 2 (Дивно, що навіть GIMP).

Перегляд історії команд

Linux збирає історію всіх виконаних команд у файлі ~/.bash_history. Якщо сервер активно використовується, і його історія не очищається, існує велика можливість знайти в цьому файлі облікові дані. Чистити історію банально незручно. Якщо адміністратор змушений вибирати десятиповерхові команди через, звичайно, йому буде зручніше викликати цю команду з історії, ніж вводити заново. Плюс багато хто не знає про цей «хак». Якщо в системі є альтернативні оболонки на кшталт Zsh або Fish, вони ведуть свою історію. Щоб вивести історію команд у будь-якій оболонці, достатньо набрати команду історії.

cat ~/.bash_history
cat ~/.mysql_history
cat ~/.nano_history
cat ~/.php_history
cat ~/.atftp_history

Існує shared hosting, коли сервер використовується для хостингу декількох сайтів. Зазвичай за такої конфігурації для кожного ресурсу створюється свій користувач з окремою домашньою директорією та віртуальний хост. Так от, при неправильному налаштуванні в кореневій директорії веб-ресурсу можна виявити файл .bash_history.

Пошук паролів у файловій системі та атаки на суміжні системи

Конфігураційні файли різних сервісів можуть бути доступні для читання вашого поточного користувача. Вони можна зустріти облікові дані у відкритому вигляді — паролі доступу до бази даних чи суміжні сервіси. Один і той же пароль може бути використаний як для доступу до бази даних, так і для авторизації користувача root (credential staffing).
Буває так, що знайдені облікові дані належать сервісам інших хостах. Розвиток атаки на інфраструктуру через скомпрометований хост нічим не гірший за експлуатацію інших хостів. Суміжні системи також можна знайти за допомогою пошуку IP-адрес у файловій системі.

grep -lRi "password" /home /var/www /var/log 2>/dev/null | sort | uniq #Find string password (no cs) in those directories
grep -a -R -o '[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}' /var/log/ 2>/dev/null | sort -u | uniq #IPs inside logs

У випадку, якщо на скомпрометованому хості є веб-програма, доступна з Інтернету, краще виключити його логи з пошуку IP-адрес. Адреси користувачів ресурсу з Інтернету нам навряд чи будуть корисні, а ось адреси внутрішньої мережі (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) і те, куди вони заходять, судячи з логів, можуть становити інтерес.

Судо

Команда sudo дає користувачеві можливість виконати команду в контексті root за допомогою власного пароля або без його використання. Багато операцій в Linux вимагають привілеїв root, проте робота з-під root вважається дуже поганою практикою. Натомість краще застосовувати вибіркове дозвіл на виконання команд у контексті root. Однак багато інструментів Linux, включаючи стандартні типу vi, можна використовувати для підвищення привілеїв легітимними способами. Для пошуку відповідного способу рекомендую подивитися тут.

Перше, що потрібно зробити, отримавши доступ до системи, – виконати команду sudo -l. Вона виведе дозвіл на використання команди sudo. Якщо користувач отримує без пароля (наприклад, apache або www-data), вектор підвищення привілеїв через sudo малоймовірний. При використанні sudo система запросить пароль. Через команду passwd встановити пароль також не вийде, вона запросить поточний пароль користувача. Але якщо sudo все ж таки доступний, то, по суті, необхідно шукати:

  • будь-які інтерпретатори, кожен може спанити shell (PHP, Python, Perl);
  • будь-які текстові редактори (vim, vi, nano);
  • будь-які переглядачі (less, more);
  • будь-які можливості роботи із файловою системою (cp, mv);
  • тули, які мають вихід у bash, інтерактивний або у вигляді команди, що виконується (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid/Sgid

В Інтернеті є безліч мануалів, які радять зібрати всі suid/sgid команди, проте рідкісна стаття дає конкретику, що робити із цими програмами. Варіанти підвищення привілеїв, які не враховують застосування експлоїтів, можна знайти тут. Також ряд файлів, що виконуються, має специфічні вразливості під версію ОС, наприклад.

В ідеальному світі потрібно пропустити всі встановлені пакети хоча б через пошуковіплати. На практиці подібне варто робити з найбільш популярними програмами типу sudo. Також завжди є варіант використовувати та підтримувати розробку автоматизованих інструментів, які підсвітлять цікаві, з точки зору підвищення привілеїв, файли з виставленими бітами suid/sgid. Перелік таких інструментів я наведу у розділі статті.

Доступні на запис скрипти, що запускаються Cron або Init, у контексті Root

Завдання cron можуть виконуватись у контексті різних користувачів, у тому числі root. Якщо в cron виставлено завдання з посиланням на файл, що виконується, і він доступний вам для запису, його легко можна підмінити шкідливим і виконати підвищення привілеїв. При цьому за промовчанням файли із завданнями cron доступні для читання будь-якому користувачеві.

ls -la /etc/cron.d  # show cron jobs 

Схожим чином справи з init. Відмінність у тому, що завдання cron виконуються періодично, а init — при старті системи. Для експлуатації потрібно перезавантаження системи, при цьому частина сервісів може і не піднятися (якщо вони не були прописані в автозавантаження).

ls -la /etc/init.d/  # show init scripts 

Також можна пошукати файли, доступні для запису будь-якого користувача.

find / -perm -2 -type f 2>/dev/null # find world writable files

Метод досить відомий, досвідчені системні адміністратори акуратно користуються командою chmod. Однак на теренах Мережі в переважній більшості мануалів описано виставлення максимальних прав. Підхід недосвідчених системних адміністраторів «аби заробило» створює можливості підвищення привілеїв у принципі. Якщо є можливість, краще пошукати в історії команд небезпечне використання chmod.

chmod +w /path 
chmod 777 /path

Отримання доступу до оболонки інших користувачів

Дивимося список користувачів /etc/passwd. Звертаємо увагу на тих, хто має оболонку. Можна побрутувати цих користувачів - не виключено, що через отриманого користувача врешті-решт вдасться підвищити привілеї.

Для підвищення безпеки рекомендую завжди дотримуватись принципу мінімальних привілеїв. Також є сенс приділити час перевірці небезпечних конфігурацій, які могли залишитися після траблшутингу, — це «технічний обов'язок» системного адміністратора.

Самописний код

Варто уважно подивитися на файли, що виконуються в домашній директорії користувача та веб-сервера (/var/www/, якщо не задана інша). Ці файли можуть виявитися абсолютно небезпечним рішенням і містити неймовірні милиці. Звичайно, якщо ви маєте якийсь фреймворк у директорії веб-сервера, немає сенсу шукати в ньому zero-day в рамках пентесту, проте знайти і вивчити кастомні доробки, плагіни та компоненти рекомендується.

Для підвищення безпеки краще по можливості відмовитися від облікових даних у самописних скриптах, а також від потенційно небезпечного функціоналу, наприклад, читання /etc/shadow або маніпуляцій з id_rsa.

Підвищення привілеїв через експлуатацію вразливостей

Перш ніж намагатися підвищити привілеї через експлуатацію, важливо розібратися з передачею файлів на цільовий хост. Крім звичних засобів на зразок ssh, ftp, http (wget, curl) є цілий «зоопарк» можливостей.

Для підвищення безпеки системи регулярно оновлюйте її до актуальних стабільних версії, а також намагайтеся використовувати дистрибутиви, розраховані на Enterprise. Інакше рідко, але бувають ситуації, коли apt upgrade робить систему непрацездатною.

Експлуатація сервісів, запущених у контексті користувача root

Деякі сервіси Linux працюють від привілейованого користувача root. Їх можна знайти з допомогою команди ps aux | grep root. При цьому сервіс може не анонсуватися до мережі та бути доступним локально. Якщо він має публічні експлоїти, їх можна сміливо застосовувати: падіння сервісу у разі невдачі набагато менш критично, ніж падіння ОС.

ps -aux | grep root # Linux

Найбільш вдалою нагодою можна вважати роботу зламаного сервісу в контексті користувача root. Експлуатація сервісу SMB дає привілейований доступ до SYSTEM в системах Windows (наприклад, через ms17-010). Однак у системах Linux таке трапляється нечасто, тому можна провести чимало часу над підвищенням привілеїв.

Експлуатація вразливостей ядра Linux

Це шлях, яким слід іти в останню чергу. Невдала експлуатація може призвести до падіння системи, а у разі ребуту деякі сервіси (у тому числі ті, через які вдалося отримати початковий shell) можуть не піднятися. Буває, що адміністратор банально забув застосувати команду systemctl enable. Плюс це викликає багато невдоволення вашими роботами, якщо експлуатація не була погоджена.
Якщо вирішили використовувати вихідні коди з exploitdb, обов'язково прочитайте коментарі на початку скрипту. Крім іншого, там зазвичай написано, як слід правильно компілювати цей експлоїт. Якщо самому ліньки чи за термінами потрібно було «вчора», можна пошукати репозиторії з уже скомпільованими експлоїтами, наприклад. Проте слід розуміти, що у такому разі ви отримаєте кота у мішку. З іншого боку, якби програміст розбирався до байта, як влаштований комп'ютер і використовуваний ним софт, він би за все життя не написав і рядки коду.

cat /proc/version
uname -a
searchsploit "Linux Kernel" 

Metasploit

Для того, щоб зловити та обробити з'єднання, завжди краще використовувати модуль exploit/multi/handler. Головне - виставити правильний payload, наприклад generic/shell/reverce_tcp або generic/shell/bind_tcp. Оболонку, отриману в Metasploit, можна покращити до Meterpreter за допомогою модуля post/multi/manage/shell_to_meterpreter. Маючи Meterpreter, ви можете автоматизувати процес постексплуатації. Наприклад, модуль post/multi/recon/local_exploit_suggester перевіряє платформу, архітектуру та необхідні для експлуатації сутності та пропонує модулі Metasploit для підвищення привілеїв на цільовій системі. Завдяки Meterpreter, підвищення привілеїв іноді зводиться до запуску потрібного модуля, проте злом без розуміння того, що відбувається під капотом, не є «тру» (вам ще звіт писати).

Tools

Інструменти автоматизації локального збору інформації збережуть вам велику кількість сил і часу, проте самі по собі не здатні повністю виявляти шлях підвищення привілеїв, особливо у разі вразливості ядра. Інструменти автоматизації виконають за вас усі необхідні команди для збору інформації про систему, але важливо також зуміти проаналізувати отримані дані. Сподіваюся, моя стаття буде вам у цьому корисна. Звичайно, інструментів існує набагато більше, ніж я наведу нижче, проте вони все роблять приблизно те саме — тут, швидше, справа смаку.

Linpeas

Досить свіжа тула, перший коміт датується січнем 2019 року. На даний момент мій улюблений інструмент. Суть у тому, що він підсвічує найцікавіші вектори підвищення привілеїв. Погодьтеся, зручніше отримати експертну оцінку на такому рівні, аніж розбирати монолітні сирі дані.

LinEnum

Другий мій улюблений інструмент, він також збирає та систематизує дані, отримані в результаті локального перерахування.

Linux-exploit-suggester (1,2)

Цей експлоїт проаналізує систему на наявність відповідних умов експлоїтів. По суті, зробить ідентичну роботу модулю Metasploit local_exploit_suggester, але запропонує не модулі Metasploit, а посилання на вихідні коди exploit-db.

Linuxprivchecker

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

Іншим разом я докладно розберу підвищення привілеїв в ОС Linux через suid/sgid.

Джерело: habr.com

Додати коментар або відгук