Как взломали Матасано?
На это невозможно ответить из информации в посте к Полному раскрытию. Однако всегда интересно спекулировать, так как они дают немного информации -
# ./th3_f1n4l_s0lut10n www.matasano.com
[-] Подключение к 69.61.87.163:22 ..
[/] Ищу действующего пользователя без полномочий root .. adam
******** R3D4CT3D х4х4х4х4 ********
Они запускают свои двоичные th3_f1n41_s01ut10nфайлы "" на сервере Матасано, который подключается к порту ssh. Он находит действительного пользователя без полномочий root с помощью неизвестных средств, а остальная часть вывода редактируется.
# ./th3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com
[*] Прослушиватель обратного вызова на 209.112.118.10:3338 ..
[!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8g 19 октября 2007]
Двоичный файл запускается снова с использованием найденного имени пользователя, который входит в систему и подключается к своему серверу через порт 3338 (надеюсь, что это имя не зарегистрировано в их имени ...).
adam_at_www: ~ $ uname -a
Linux www 2.6.20.1-1-686 # 1 SMP Sun 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: ~ # cat / etc / shadow
Упс - вдруг пользователь теперь root. У них есть локальный эксплойт для повышения привилегий в / tmp, который может быть 0-дневным, на который они ссылались.
Таким образом, здесь происходит как минимум два эксплойта - эксплойт OpenSSH для получения действительного пользователя без полномочий root в системе и входа в систему под этим пользователем, а затем повышение локальных привилегий.
Учитывая, что OpenSSH имеет несколько известных проблем безопасности, начиная с версии 4.5:
Со страницы безопасности OpenSSH :
- OpenSSH до версии 5.2 уязвим к слабости протокола, описанной в CPNI-957037 «Атака восстановления открытого текста по SSH». Однако, исходя из ограниченной доступной информации, представляется, что описанная атака в большинстве случаев невозможна. За дополнительной информацией обращайтесь к рекомендациям cbc.adv и примечаниям к выпуску OpenSSH 5.2.
- OpenSSH 4.9 и новее не выполняются
~/.ssh/rcдля сессий, команда которых была переопределена с помощью директивы ForceCommand sshd_config (5). Это было документированное, но небезопасное поведение (описано в примечаниях к выпуску OpenSSH 4.9).
- OpenSSH 4.7 и новее не отступают от создания доверенных куки-файлов аутентификации X11, когда не удается создать ненадежные куки-файлы (например, из-за преднамеренного исчерпания ресурсов), как описано в примечаниях к выпуску OpenSSH 4.7.
Я думаю, что это старое ядро Linux и старый демон SSH сделали для них. Кроме того, он работал на их www-сервере, который доступен в Интернете, что, на мой взгляд, вполне уверенно. Люди, которые ворвались, очевидно, хотели смутить их.
Как предотвратить эти атаки?
Это могло бы быть предотвращено путем упреждающего администрирования - обеспечения исправления любых подключенных к Интернету служб и ограничения количества людей, которые могут подключаться, вместо того, чтобы разрешать людям подключаться из любого места. Этот эпизод усваивает урок, заключающийся в том, что безопасное системное администрирование сложно и требует от бизнеса преданности делу, чтобы у ИТ-специалистов было время исправлять ошибки - на самом деле это не так легко, по крайней мере в небольших компаниях.
Лучше всего использовать подход с поясом и скобками - использование аутентификации с открытым ключом, внесение в белый список в ssh-демоне, двухфакторная аутентификация, ограничения IP и / или размещение всего, что находится за VPN, являются возможными путями его блокировки.
Я думаю, что знаю, что буду делать на работе завтра. :)