Перейти к содержанию

Обманутый посредник

Статья из Авикипедии. Энциклопедии

Обманутый посредник (также известный как запутанный представитель) — это ситуация в компьютерной безопасности, когда программа с ограниченными правами обманом заставляет другую программу с более высокими привилегиями выполнить несанкционированные действия. Данная проблема представляет собой частный случай повышения привилегий и часто приводится в качестве примера, демонстрирующего важность применения систем безопасности, основанных на полномочиях.

В отличие от систем, использующих списки контроля доступа (ACL), которые не обеспечивают защиту от подобных атак, безопасность на основе полномочий эффективно противодействует проблеме обманутого посредника.

Исторический пример[править | править код]

Классический пример проблемы обманутого посредника возник в эпоху коммерческих сервисов разделения времени. Компилятор, доступный пользователям, позволял указывать имя файла для записи отладочной информации. При этом программа проверяла наличие у пользователя прав на запись в указанный файл.

Параллельно компилятор собирал статистику использования языковых средств, сохраняя её в файле «(SYSX)STAT» каталога «SYSX». Для этой операции компилятор обладал расширенными правами доступа ко всем файлам в данном каталоге. В этом же каталоге находился файл биллинговой системы «(SYSX)BILL».

Пользователь, запустив компилятор, указал в качестве файла для отладочной информации «(SYSX)BILL». Хотя сам пользователь не имел прав доступа к этому файлу, компилятор успешно открыл его благодаря своим привилегиям и записал выходные данные компиляции, полностью уничтожив информацию о биллинге.

Механизм атаки[править | править код]

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

Ключевым аспектом проблемы является разделение идентификации ресурса и прав доступа к нему. Когда программа запрашивает доступ к файлу, операционная система проверяет два параметра: идентификатор запрашиваемого файла и наличие у программы соответствующих разрешений. В приведённом примере программа получила от пользователя имя файла «(SYSX)BILL», но не унаследовала ограничения прав доступа пользователя. Система автоматически применила привилегии компилятора, что привело к неавторизованному повышению прав.

Для успешной атаки не обязательно, чтобы целевой файл имел определённое имя. Критическими факторами являются:

  • Отсутствие у идентификатора файла полномочий для доступа к нему
  • Неявное использование программой собственных привилегий при обращении к файлу

Современные примеры[править | править код]

    • Межсайтовая подделка запроса (CSRF)** представляет собой атаку типа «обманутый посредник», где браузер жертвы используется для выполнения несанкционированных действий в веб-приложении. Типичный сценарий предполагает, что веб-приложение аутентифицирует все запросы через файлы cookie браузера. Злоумышленник с помощью JavaScript может заставить браузер отправить аутентифицированные HTTP-запросы к целевым ресурсам.
    • Червь Samy** использовал технологию межсайтового скриптинга (XSS) для превращения аутентифицированной сессии пользователя в браузере в «обманутого посредника». Через XSS червь заставлял браузер рассылать исполняемые копии самого себя в виде сообщений на платформе MySpace, которые затем автоматически выполнялись у друзей заражённого пользователя.
    • Кликджекинг** — это атака, где сам пользователь становится обманутым посредником. Пользователь считает, что взаимодействует с безопасным веб-сайтом, но фактически его действия перенаправляются на выполнение конфиденциальных операций на другом ресурсе.
    • FTP-атака с отскоком (Bounce attack)** позволяет злоумышленнику косвенно подключаться к TCP-портам, недоступным с его машины, используя удалённый FTP-сервер в качестве обманутого посредника.
    • Обход персональных файрволов** — некоторые приложения обходят ограничения межсетевого экрана, запуская браузер с инструкциями доступа к определённым URL-адресам. Поскольку браузер имеет права на сетевое соединение, а исходное приложение — нет, файрвол может запрашивать подтверждение у пользователя. Однако пользователи часто не обладают достаточной информацией для оценки легитимности таких запросов, что приводит к привыканию и автоматическому подтверждению потенциально опасных операций.

Следует различать проблему обманутого посредника и простые ошибки в программах, приводящие к злоупотреблению полномочиями. Ключевая особенность проблемы обманутого посредника заключается в непреднамеренном изменении прав доступа при передаче объекта между программами без явных действий со стороны участников процесса.

Методы защиты[править | править код]

Некоторые операционные системы предоставляют возможность открытия файлов с правами другого клиента, однако этот подход имеет существенные недостатки:

  • Повышенные требования к безопасности серверного ПО — небрежно спроектированный сервер может не реализовать необходимые меры защиты
  • Усложнение определения корректных прав доступа, когда сервер сам выступает клиентом другого сервиса и передаёт доступ к файлу
  • Необходимость доверия клиента к серверу в вопросах непреднамеренного использования полученных прав

Наиболее эффективным решением проблемы обманутого посредника является объединение идентификатора объекта и прав доступа к нему, что реализовано в системах безопасности, основанных на полномочиях.

В контексте примера с компилятором, при использовании безопасности на основе полномочий, клиент передавал бы серверу не имя файла, а файловый дескриптор с соответствующими правами. Поскольку пользователь не обладает доступом к файлу биллинга, он не может предоставить соответствующий дескриптор. Аналогично, в случае межсайтовой подделки запроса, URL-адреса с «кросс-сайтов» включали бы собственные независимые полномочия, не связанные с правами веб-браузера клиента.

См. также[править | править код]

  • SUID в Unix
  • Внешние полномочия

Примечания[править | править код]

Литература[править | править код]

Ссылки[править | править код]

  • Norman Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review, Volume 22, Issue 4 (October 1988).

Ссылки[править | править код]