Как взломали Матасано?

10

от: http://seclists.org/fulldisclosure/2009/Jul/0388.html

Если я понимаю это лучше всего из постов с: http://news.ycombinator.com/item?id=723798 ребята из Matasano оставили sshd в Интернете доступным - какие-либо предлагаемые решения для этого (с точки зрения программирования)?

user14898
источник
Что ж, если логи верны, то это проблема конфигурации открытых служб и не имеет никакого отношения к программированию.
Минет

Ответы:

34

Как взломали Матасано?

На это невозможно ответить из информации в посте к Полному раскрытию. Однако всегда интересно спекулировать, так как они дают немного информации -

# ./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, являются возможными путями его блокировки.

Я думаю, что знаю, что буду делать на работе завтра. :)

Cawflands
источник
2
Требовать действительный открытый ключ для входа в систему через OpenSSH. Не дурак, но помогает. Хороший пост, кстати.
Андриоид
Хороший вопрос, добавил :)
Cawflands
1
Стоит отметить, что строка версии OpenSSH далека от надежного руководства относительно того, были ли исправлены vunerabilites, из-за различных исправлений бэкпортинга версий Linux. Кроме того, ни одна из ошибок здесь, вероятно, не позволит пользователю войти в систему без каких-либо довольно серьезных других взломщиков.
Цянь
3

Люди любят создавать FUD из-за этого, но кажется, что они знали, что пользователь adam уже был там, и также знали его пароль (возможно, с помощью грубой силы или других методов). Тем не менее, они хотят выглядеть круто и создавать эту суету во всем.

Еще одна интересная вещь - это то, что пользователь adam не регистрировался в этом ящике более года:

(вывод lastlog)

 adam             pts/1    ool-4350ab48.dyn Sat Jul 26 20:45:18 -0400 2008

Поэтому он, вероятно, какое-то время хранил этот пароль (возможно, плохой).

* Если бы у них действительно был инструмент для обнаружения имен пользователей через SSH, они могли бы использовать всех остальных пользователей для получения удаленного доступа, но они использовали наиболее распространенное имя пользователя в этом поле (легко догадаться).

sucuri
источник
2

Почему вы пытаетесь решить эту проблему с точки зрения программирования?

Вместо этого вы должны решить это с точки зрения умного сервера-администратора. В комментариях по ссылкам, которые вы разместили, есть несколько замечательных предложений, таких как использование белого списка.

Я также хотел бы добавить это, потому что вы спрашиваете здесь, вы, скорее всего, ни в коем случае не эксперт по безопасности, и все, что вы могли бы написать, только добавило бы больше дыр. Это действительно не вопрос программирования вообще.


источник
одно предложение было в белом списке?
которая до сих пор не является проблемой программирования, это проблема конфигурации
blowdart
@Sneakyness Я ни в коем случае не эксперт по безопасности - но спасибо за то, что указал на это - я задаю эти вопросы, чтобы я мог учиться - и спасибо за попытку помешать мне написать что-то, о чем я хотел бы узнать - будь то это вопрос о программировании или не о программировании - я оставлю это на усмотрение экспертов по безопасности, чтобы ответить - вы включены (я предполагаю, что вы один из них, основываясь на вашем образовательном комментарии)
user14898
2

Защитите свое программное обеспечение от 0-дневных атак ... что невозможно.

Возможно, один хороший подход - заявить, что ваше программное обеспечение не взломано, что заставит whitehats попробовать его и полностью раскрыть все, оставляя меньше дыр. У Oracle 10 было это требование, и на следующий день было найдено 9 новых дыр. Это довольно безопасно сейчас.

Скорее всего, хакер злоупотребил конфигурацией совершенно хорошего софта

Эрик
источник
Наши уверены, что это был даже нулевой день?
Джош Брауэр
2

я просто поражаюсь, что на этой машине было так много пользователей со снарядами. вот так они и завладели, все остальное - красная селедка, предназначенная для отвлечения. один из них, скорее всего, получил свой ssh-клиент на другом компьютере-оболочке, и тогда игра была окончена. дать каждому учетную запись оболочки и сделать мир sshd доступным просто лениво и глупо.


источник