Як Matasano зламали?
Це неможливо відповісти з інформації в пості до Повного розкриття інформації. Однак міркувати завжди цікаво, оскільки вони дають трохи інформації -
# ./th3_f1n4l_s0lut10n www.matasano.com
[-] Підключення до 69.61.87.163:22 ..
[/] Шукаю дійсного некорінного користувача .. adam
******** R3D4CT3D h4h4h4h4 ********
Вони виконують свій двійковий " th3_f1n41_s01ut10n" сервер Matasano, який підключається до ssh-порту. Він знаходить дійсного некорінного користувача через невідомі засоби, а решта результатів редагується.
# ./th3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com
[*] Слухач Connectback 209.112.118.10:3338 ..
[!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8 г 19 жовтня 2007]
Бінарний файл запускається знову за допомогою знайденого імені користувача, яке входить у систему та підключається назад до їх сервера на порту 3338 (сподіваюся, що це не зареєстровано у їх імені ...).
adam_at_www: ~ $ uname -a
Linux www 2.6.20.1-1-686 # 1 SMP нд 4 березня 12:44:55 UTC 2007 i686 GNU / Linux
**** h4h4h4hh4h4h4 l3tz us3 m0r3! 0D4Y! H4H4H4H4H4H4H4 ****
Це може означати, що вони мають 0 днів проти цього ядра, що є досить старим, якщо врахувати запаси цієї компанії.
adam_at_www: ~ $ cd / tmp
*********** B0R1NG ***********
root_at_www: ~ # кішка / тощо / тінь
Уопс - раптом користувач тепер корінь. Вони мають місцевий експлуатування привілеїв в / tmp, який може бути 0-денним, про який вони згадували.
Отже, тут відбувається щонайменше два подвиги - експлуатація OpenSSH для отримання дійсного некорінного користувача в системі та вхід у систему як цього користувача, а потім ескалація локальних привілеїв.
Враховуючи, що OpenSSH має декілька відомих проблем безпеки з версії 4.5:
Від сторінки безпеки в OpenSSH :
- OpenSSH до версії 5.2 вразливий до слабкості протоколу, описаної в CPNI-957037 "Атака відновлення Plaintext проти SSH". Однак, виходячи з обмеженої кількості доступних відомостей, здається, що описана атака нездійсненна в більшості обставин. Для отримання додаткової інформації зверніться до рекомендацій cbc.adv та приміток до випуску OpenSSH 5.2.
- OpenSSH 4.9 і новіші версії не виконуються
~/.ssh/rcдля сеансів, команда яких переосмислена директивою sshd_config (5) ForceCommand. Це була задокументована, але небезпечна поведінка (описана в примітках до випуску OpenSSH 4.9).
- OpenSSH 4.7 і новіші версії не відступають від створення надійних файлів cookie аутентифікації X11, коли не довіряється генерування файлів cookie (наприклад, через навмисне вичерпання ресурсів), як описано в примітках до випуску OpenSSH 4.7.
Я думаю, що це старе ядро Linux і старший демон SSH зробили для них. Крім того, він працював на їх веб-сервері, який доступний в Інтернеті, що, на мою думку, досить впевнено. Люди, які ввірвалися, очевидно, хотіли збентежити їх.
Як попередити ці напади?
Цьому можна було попередити ініціативне адміністрування - переконатися, що будь-які сервіси, пов’язані з Інтернетом, є виправленими, а також обмеження кількості людей, які можуть підключитися, а не дозволяти людям з'єднуватися з будь-якого місця. Цей епізод поєднує урок про те, що безпечне адміністрування системи є важким, і вимагає відданості бізнесу, щоб забезпечити час ІТ для того, щоб все виправляти - насправді це не те, що відбувається легко, принаймні у менших компаніях.
Найкраще використовувати підхід "брекет-діапазон" - використання автентифікації з відкритим ключем, створення білого списку на ssh-демон, двофакторну автентифікацію, обмеження IP та / або введення всього за VPN можливі маршрути для його блокування.
Думаю, я знаю, чим завтра буду займатися на роботі. :)