Предотвращение бинарных атак в Linux

Если пользовательская учетная запись на компьютере Linux скомпрометирована, очевидно, что все файлы, принадлежащие этому пользователю, скомпрометированы.

К сожалению, если у скомпрометированного пользователя также есть привилегии sudo, кажется, что бинарная посадка может использоваться для тривиального получения пароля sudo и, следовательно, для эскалации атаки на root привилегии (плохие).

Есть ли хорошая защита от этой атаки или общепринято, что root будет скомпрометирован, если sudo будет использоваться?


Предыдущий вопрос по связанной заметке: zsh – полностью расширяет двоичный путь на <tab>

Это не решает проблему, потому что, даже если ваш файл .rc оболочки принадлежит root, его можно удалить локальным пользователем и заменить на тот, который содержит вредоносную переменную PATH, или можно было бы заменить комбинацию клавиш для открытия терминала злобным.

  • Переход на суперпользователь при запуске скрипта оболочки
  • В чем разница между «du -sh *» и «du -sh ./*»?
  • Как получить папку с наибольшим числом
  • Как я могу защитить эти два сценария, используемые в SSH authorized_keys дальше?
  • Как создать файлы истории с датой, автоматически присоединенной?
  • Почему 'if ' ветвь всегда выбрана, даже если $ 1 не 1?
  • Чтение дескрипторов файлов
  • Как запустить два процесса и узнать, когда они заканчиваются в bash
  • 3 Solutions collect form web for “Предотвращение бинарных атак в Linux”

    Невозможно полностью предотвратить такие атаки, по крайней мере, без какой-либо серьезной реинжиниринга системы и тяжелой нагрузки на пользователя.

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

    Атака останется видимой для других пользователей, пока злоумышленник не перейдет к другим учетным записям. Таким образом, вы можете сделать процесс, выполняемый как root, проверять файлы в вашей учетной записи и сообщать о любых изменениях. Проблема в том, что вы будете совершать много законных изменений; маловероятно, что вы сможете заметить нелегитимное изменение среди шума.

    Существует способ скрыть ущерб вашей учетной записи, который требует любой эскалации привилегий, чтобы пройти через полностью доверенный пользовательский интерфейс. Это означало бы, что:

    • Аутентификация как root должна проходить только с процессами, которые не принадлежат пользователю и не могут контролироваться пользователем. В частности, нет интерфейса X11.
    • У вас должен быть способ идентифицировать приглашение для входа в качестве подлинного: в противном случае злоумышленник может высмеять доверенный пользовательский интерфейс. Для этого есть два подхода.

      • Имейте безопасный ключ внимания , который пользователь не может отскочить от другой функции. Нажмите SAK для отображения приглашения на вход на терминале, который не находится под контролем пользователя. Это может быть настроено на некоторых устройствах, но я не знаю о полнофункциональном решении, которое подверглось серьезному обзору безопасности.
      • Попросите систему аутентифицировать себя для пользователя, снова через пользовательский интерфейс, над которым пользователь не имеет контроля. Аутентификация может быть статической, например, показывая вам изображение ваших детей; это легко для вас проверить, но также легко обмануть в целенаправленной атаке. Аутентификация может быть динамической, при этом система показывает вам одноразовый пароль, который вы проверяете в отдельной доверенной системе; для этого требуется, чтобы у вас была такая система (обычно это токен OTP).

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

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

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

    В противном случае, я думаю, вы ответили на свой вопрос – если у меня есть ключи от курятника, а мистер Фокс получит мои ключи, тогда я смогу съесть всех цыплят. Нет никакого решения.

    Однако есть, по крайней мере, инструменты, такие как ossec или ossec чтобы предупредить вас о том, когда установлен руткит. См. Это для некоторых деталей .

    Tripwire / AIDE / Samhain работают подходы для HIDS (системы обнаружения вторжений на основе хоста). Некоторые из них могут быть объединены с центральными серверными частями, чтобы сигнатуры не находились на локальном компьютере (например, Beltane для Samhain).

    Другой подход, который я использую на своей рабочей станции, – где я часто меняю файлы, – проверить, все ли файлы ОС по-прежнему согласованы.

    Я делаю это, выполняя полный rpm -Va – помещаю вывод в файл и сравнивая этот вывод со следующим прогоном. Таким образом, я буду записывать двоичные изменения, которые не являются частью изменений OS-patch (я также включаю проверку gpg).

    Для обоих методов есть способы обойти их …

    Linux и Unix - лучшая ОС в мире.