Защита от хакеров корпоративных сетей

Приоткрывая завесу

Инструментарий su (silent user): глупый пользователь, права суперпользователя для новичков

Вероятно, инструментарий su является беззубым тигром в мире безопасности программного обеспечения. Так же как и инструментарий с командной строкой, который, как ожидалось, должен был позволить кому-то переключить и изменить разрешения пользователя, инструментарий su позиционируется как наиболее перспективная альтернатива непосредственному подключению к необходимой учетной записи. Даже почтенная система OpenBSD совершает подобную ошибку:

$ ssh root@10.0.1.220

root@10.0.1.220’s password:

Last login: Fri Dec 28 02:02:16 2001 from 10.0.1.150

OpenBSD 2.7 (GENERIC) #13: Sat May 13 17:41:03 MDT 2000

Welcome to OpenBSD: The proactively secure Unix-like operating

system.

Please use the sendbug(1) utility to report bugs in the system.

Before reporting a bug, please try to reproduce it with the

latestversion of the code. With bug reports, please try to

ensure thatenough information to reproduce the problem is

enclosed, and if aknown fix for it exists, include that as well.

Terminal type? [xterm]

Don’t login as root, use su

Этот совет, как и его предназначение, смешен. Идея заключается в том, что пользователю в процессе своей повседневной деятельности следует обращаться к своей обычной учетной записи. А при необходимости выполнения каких-либо функций администратора ему предлагается соответствующим образом проинсталлировать и настроить свою командную оболочку (которая, как правило, не имеет достаточных полномочий для администрирования системы), для того чтобы можно было запустить программу, которая запросит пароль суперпользователя. В результате командная оболочка пользователя приобретет статус доверенного программного средства.

Было бы прекрасно, если можно было бы подстраховаться на случай, когда командная оболочка пользователя действительно соберется выполнить su. Поразмышляйте над этим. Существует бесчисленно много возможностей для нанесения ущерба командной оболочки, не позволяя ей выполнить запуск su. Злоумышленник может пойти и другим путем, используя один из автоматических и невидимых конфигурационных файлов. bashrc/.profile/.tcshrc. Каждый из них может определять загрузку альтернативных программ до того, как будет загружена подлинная программа su. Альтернативные программы могли бы перехватывать трафик клавиатуры во время ввода пароля суперпользователя и записывать его в файл или пересылать перехваченные данные по сети. Если существует водораздел между учетной записью обычного пользователя и суперпользователя, то какой смысл упоминать о нечто, что ранее доверием не пользовалось, но может быть модифицировано для придания ему статуса доверяемого при помощи ресурса, целиком принадлежащего «вражеской территории» и контролируемого там? Это точная аналогия назначения лисы, ответственной за сохранность кур в курятнике. Объекту, которому не доверяют, предоставляют ключи от области, безопасность которой должна быть обеспечена при любых условиях. И при этом предполагают, что ничего плохого не произойдет. Разве это не смешно?

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

К несчастью, особенно это касается случая предоставления многим пользователям совместного доступа к машине, с правами суперпользователя, когда очень важно знать, кто и когда подключился к машине и что было взломано за это время. Инструментарий su хорош тем, что в нем реализована очень ясная и понятная процедура регистрации подключений, которая показывает, кто именно прошел путь от получения более низкого уровня безопасности к более высокому. Создание в учетной записи суперпользователя индивидуальных входов авторизованных ключей authorized_keys недостаточно, потому что на самом деле никак не регистрируется, какой именно ключ был использован для получения доступа к какой-либо учетной записи. (Этот недостаток планируется исправить позднее.) Потребность в подобной отчетности настолько велика, что она может перевесить преимущества концепции наложения ограничений на учетные записи отдельных пользователей, которая не может рассматриваться как реальная система безопасности. Другими словами, учетная запись суперпользователя есть нечто, к чему читатель всегда может получить доступ. К тому же читатель может захотеть получить возможность предотвратить конфликтную и непроизвольную работу в режиме командной строки, защищающую от затирания данных сервера!

ssh user@host -t “/bin/su –l user2”

Хотя приведенная команда приводит к самой важной записи пользователя, но это слишком долгий путь для решения задачи аутентификации. Окружение остается в таком же непорочном состоянии, что и процесс, владельцем которого является суперпользователь и который породил это окружение. Работая в таком непорочном окружении, инструментарий su предоставляет функции TTY и сообщает о переключении к другому пользователю. Поскольку это непорочное окружение функции, то, безусловно, это та программа su, которая в действительности выполняется, и ничто иное.

Обратите внимание, что только /bin/sh доверено поддерживать чистоту окружения команды. Например, bash загрузит свои конфигурационные файлы даже в случае ее применения для выполнения команды. Рассмотренный метод потребуется команде chsh (смена командной оболочки) для обеспечения своей безопасности. Но для пользователя это не означает необходимости переключиться от bash к /bin/sh, используя. profile конфигурацию в своей домашней директории. Пользователь может поместить команду exec bash – login – i и получить доступ к bash во время интерактивного подключения, пока ему доступно безопасное окружение для удаленного выполнения команд.

Существует другая важная проблема, о которой мало что известно. SSHD загружает файл ~/.ssh/environment даже для переадресованных команд, устанавливая параметры пользовательского окружения. Поэтому в первую очередь могут быть атакованы параметры окружения, предназначенные для хранения пути запуска удаленного инструментария su. Переназначая путь к некоторому поврежденному двоичному файлу, владельцем которого выступает пользователь, может оказаться уязвимым ввод чего-либо в командной строке. Отключить синтаксический разбор файла ~/.ssh/environment непросто. Обычно гораздо легче определить абсолютный путь к su – /bin/su, хотя иногда путь /usr/bin/su лучше не взламывать. Другой основной способ атаки предусматривает предварительную загрузку библиотеки, изменяющую функции, от которых могло бы зависеть выполнение данного приложения. Поскольку инструментарий su является приложением класса setuid, то система будет автоматически игнорировать любую предварительно загруженную библиотеку.