Чому скомпрометований обліковий запис root означає перебудову сервера, а не очищення.
Обліковий запис з UID 0 без запису про створення не створили, його вписали. Як знайти прихований обліковий запис root і чому компрометація root означає перебудову, а не очищення.
У цій статті 5 розділів
Кожен обліковий запис у системі Unix має свідоцтво про народження. Рядок у журналі автентифікації, який фіксує, хто його створив, коли і яким інструментом. Обліковий запис без такого рядка не був створений через жоден інструмент. Його вписали, вручну, прямо у файл користувачів. Коли такий обліковий запис ще й має UID 0, відсутній рядок є не прогалиною у ваших записах. Він є доказом.
- Прихований обліковий запис root є найважчим для виявлення бекдором, бо в Unix root є числом, а не іменем. Будь-який обліковий запис з UID 0 має повні права root. Дайте такому обліковому запису ім'я, що відрізняється на один символ від імені легітимного системного демона, і він переживе побіжний перегляд списку користувачів. Око читає його як друкарську помилку, а не як загрозу.
- Два звичайні спостереження відводять того, хто реагує на інцидент, у хибному напрямку: замасковане ім'я схоже на помилку в назві реального демона, а автоматична перевірка стану вже відзвітувала про успіх. Сигнал, що все чисто.
- Ознака, яка перекреслює обидва: у журналах взагалі немає запису про створення облікового запису. Зловмисник ніколи не користувався інструментом створення облікових записів. Хеш пароля вписали прямо у файл користувачів, причому саме у файл користувачів, а не у файл shadow, і це вже друга ознака сама по собі.
- Принцип: скануйте облікові записи з UID 0 незалежно від журналів створення, вважайте хеш у неправильному файлі знахідкою, ніколи не вважайте одну автоматичну перевірку доказом, а коли root був доступний на будь-який проміжок часу, перебудовуйте систему з перевірено чистої точки, що передує компрометації. Не чистіть на місці.
UID 0 є числом, а не іменем
Root не є обліковим записом з іменем root. Root є будь-яким обліковим записом, чий ідентифікатор користувача дорівнює 0. Ядро надає привілеї за числом, а ім'я є лише оздобленням. Тож бекдору не потрібно торкатися облікового запису root чи вгадувати пароль. Йому потрібен ще один рядок у файлі користувачів з 0 у третьому полі.
Дайте цьому рядку ім'я, що відрізняється на один символ від імені легітимного системного демона, і він зникне на видноті. Список користувачів довгий, імена криптичні за задумом, і той, хто переглядає його під час реагування, читає знайомого демона з дрібною помилкою в назві та йде далі. Маскування не є витонченим. Йому достатньо пережити один погляд.
# Root is a UID, not a name. List every account with UID 0.
awk -F: '$3 == 0 { print $1 }' /etc/passwd
# Exactly one line should come back: root. Any second line is a
# full-privilege account, whatever it calls itself.Дві причини йти далі. Обидві хибні.
Хорошого інженера реагування можуть провести повз прихований обліковий запис root два цілком розумні спостереження. Обидва з тих, на які киваєш і йдеш далі. Жодне не витримує другого погляду.
| Як це виглядає | Чим це є |
|---|---|
| Ім'я облікового запису читається як друкарська помилка в назві легітимного системного демона | Повноцінний обліковий запис з UID 0, названий так, щоб пережити один погляд, на один символ від реального демона |
| Автоматична перевірка звітує про успіх. | Одна автоматична перевірка не є доказом. |
“Одна автоматична перевірка не є доказом. Підтвердьте її незалежним скануванням.”
Обліковий запис без свідоцтва про народження
Кожен обліковий запис, створений стандартними інструментами, залишає рядок у журналі автентифікації: ким створений, коли, якою командою. Підкинутий обліковий запис не має жодного. Не видаленого рядка, а взагалі жодного рядка, бо зловмисник ніколи не користувався інструментом. Хеш пароля вписується прямо у файл користувачів вручну, і тому немає чого журналювати.
І вписується він у неправильний файл. У будь-якій сучасній системі Unix поле пароля у файлі користувачів делеговано файлу shadow. Воно містить заповнювач, ніколи не справжній хеш. Справжній хеш у файлі користувачів не є варіантом конфігурації чи спадковою дивиною, від якої можна відмахнутися. Це відбиток ручного редагування, і він є ознакою сам по собі.
Без рядка в журналі справжній час створення облікового запису доводиться відновлювати з побічних джерел: часових міток файлів і записів, які інші події залишили довкола нього. Відсутність свідоцтва про народження не заважає встановити час народження. Вона лише означає, що над цим доведеться попрацювати.
# The password field in /etc/passwd should be a placeholder (x),
# never a hash. The real hash lives in /etc/shadow.
awk -F: '$2 != "x" && $2 != "*" && $2 != "!" { print $1 }' /etc/passwd
# A name that comes back here has its hash in the wrong file.
# That is a manual edit, not a managed account.“Обліковий запис з UID 0 без запису про створення не створили. Його вписали.”
Коли оновлення випадково замикає зловмисника ззовні
Найдивніше в цьому сценарії відмови те, що з ним може зробити звичайне автоматичне оновлення. Автоматичне оновлення може перезаписати підкинутий хеш як побічний ефект і замкнути зловмисника поза його власним бекдором. Обліковий запис залишається. Доступ зникає. Бекдор може після цього лежати неактивним необмежено довго: незамкнені двері в кімнату, ключ до якої більше не повертається. Це схоже на безпеку. Але це не вона.
Бекдор, який перестав працювати, не є бекдором, який зник. Неактивний обліковий запис з UID 0 усе одно є обліковим записом з UID 0, який хтось підкинув. Компрометацією є сама присутність, а не вхід.
Ви його не чистите. Ви його перебудовуєте.
Спокуслива розв'язка: «видалити поганий обліковий запис, накласти патч, готово». Відмовтеся від неї. Доступ root на будь-який проміжок часу, навіть на проміжок, який удача пізніше з грюкотом зачинила, означає, що кожен байт на цій машині тепер під підозрою: бінарні файли, завдання cron, бібліотеки та самі інструменти, якими ви б її перевіряли. Неможливо повернути довіру аудитом у системі, інструментам аудиту якої ви більше не довіряєте.
Скануйте root незалежно від журналів.
Виведіть кожен обліковий запис з UID 0 через awk. Не покладайтеся на журнал створення, на одну автоматичну перевірку чи на те, що список користувачів виглядає нормально.
Вважайте хеш у неправильному файлі знахідкою.
Справжній хеш у файлі користувачів замість файлу shadow є ручним редагуванням. Розслідуйте його, а не шукайте йому виправдання.
Підтверджуйте кожну автоматичну перевірку незалежно.
Якщо автоматична перевірка каже «чисто», а ваше власне сканування знаходить непояснений обліковий запис з UID 0, переслідуйте знахідку, а не заспокоєння.
Визначайте час компрометації, а не час, коли ви помітили.
Відновіть найбільш ранню правдоподібну компрометацію з побічних джерел. Ваша чиста точка відновлення має передувати їй, а не виявленню.
Перебудовуйте з перевірено чистої точки.
Відновіться з завідомо справного образу, що передує компрометації, змініть кожні облікові дані, до яких могла дотягнутися машина, і перевірте ще раз. Не чистіть на місці.
Root на будь-який проміжок часу означає недовірену систему. Недовірену систему не чистять. Її перебудовують з точки, чистоту якої ви можете довести, з часу до компрометації, ніколи після.
“Root на хвилину є root до самої перебудови. Таку машину не чистять. Її перебудовують з точки, чистоту якої ви можете довести.”
Прямі відповіді
Як знайти прихований обліковий запис root у Linux?+
Виведіть кожен обліковий запис з UID 0, а не лише той, що зветься root: awk -F: '$3 == 0 {print $1}' /etc/passwd. Ядро надає root за UID, а не за іменем, тож будь-який другий рядок є обліковим записом з повними правами, як би він себе не називав. Скануйте його безпосередньо. Не покладайтеся на те, що список користувачів виглядає нормально, чи на одну автоматичну перевірку, яка звітує «чисто».
Що означає хеш пароля в /etc/passwd замість /etc/shadow?+
У будь-якій сучасній системі Unix поле пароля в /etc/passwd є заповнювачем, зазвичай x, а справжній хеш живе в /etc/shadow. Справжній хеш у /etc/passwd не є нормальною конфігурацією. Це відбиток ручного редагування файлу користувачів, і він є ознакою компрометації сам по собі.
Чому немає запису в журналі про обліковий запис, який явно існує?+
Бо його не створювали стандартними інструментами облікових записів, а саме вони пишуть журнал автентифікації. Якщо хтось редагує файл користувачів вручну, обліковий запис існує без жодного запису про створення. Обліковий запис з UID 0 без запису про створення не був створений через жоден інструмент. Його вписали.
Чи можу я просто видалити зловмисний обліковий запис і накласти патч на сервер?+
Ні. Доступ root на будь-який проміжок часу означає, що вся система недовірена: бінарні файли, cron, бібліотеки та інструменти, якими ви б її перевіряли. Видаливши обліковий запис і наклавши патч, ви залишаєтеся довіряти машині, яку більше не можете перевірити. Перебудуйте з точки відновлення, що передує компрометації, змініть облікові дані й перевірте ще раз.
Обліковий запис бекдору виглядає неактивним. Це все ще проблема?+
Так. Неактивний чи заблокований обліковий запис з UID 0 усе одно є обліковим записом з повними правами, який хтось підкинув. Компрометацією є його присутність, а не будь-який вхід. Автоматичне оновлення чи зміна конфігурації може випадково вимкнути бекдор, не усунувши самого зламу. Тригером вважайте присутність, а не активність.
Обліковий запис root, який ви не можете пояснити?
Якщо ви знайшли обліковий запис з UID 0 без запису про створення або не впевнені, що ваша остання чиста точка відновлення передує проблемі, не чистіть його на місці. Поговоріть з інженером, який відновить хронологію з побічних джерел і перебудує систему з точки, чистоту якої ви можете довести.
Поговоріть з інженеромВи дійшли до кінця.
Застосуйте прочитане на практиці
Що ви запускаєте?
Розкажіть нам про навантаження, трафік і вимоги до відновлення. Почніть з конструктора сервера або обговоріть деталі з інженером.
Написано інженерами, які будують і експлуатують інфраструктуру, про яку йдеться.Поговоріть з інженером