Белые списки библиотек для авторизации

«Взломать приложение часто можно не трогая его исходный код — достаточно подсунуть ему свою версию системной библиотеки. Белые списки DLL и .so файлов, это тихий, но эффективный рубеж, который не даёт подменить легитимный код на вредоносный прямо в памяти запущенного процесса. Давайте разберёмся, как это работает на практике, а не в теории.»

Как атакуют через подмену библиотек

Атака, известная как DLL hijacking или подмена shared objects в Linux, основана на особенностях загрузки зависимостей. Когда приложение запускается, операционная система ищет необходимые ему библиотеки по определённым путям. Если злоумышленник поместит в один из этих каталогов, проверяемых ранее системных, свой файл с тем же именем, будет загружен именно он. Этот вредоносный код выполнится в контексте и с привилегиями целевого приложения, что открывает путь к краже данных, установке бэкдора или эскалации привилегий.

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

Какие типы файлов нужно контролировать

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

Пошаговый процесс внедрения защиты

Внедрение системы белых списков, это методичная работа, а не разовая настройка. Пропуск этапов ведёт к ложным срабатываниям или, что хуже, к пробелам в защите.

1. Инвентаризация и создание базового списка

Первым делом необходимо понять, что именно работает в вашей системе. Используйте инструменты вроде ldd на Linux или Process Monitor/Sysinternals на Windows, чтобы собрать список всех библиотек, которые загружают ваши критические приложения. На этом этапе важно отделить стандартные системные библиотеки (например, из /usr/lib или C:WindowsSystem32) от сторонних и собственных.

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

2. Настройка технических средств контроля

На этом этапе политика применяется на практике. Механизмы различаются в зависимости от ОС:

• Windows: Используйте AppLocker или Windows Defender Application Control (WDAC, бывший Device Guard). Для DLL-файлов в AppLocker можно создавать правила на основе пути, издателя или хеша. WDAC предлагает более строгий контроль на основе политик целостности кода.

  <RuleCollection Type="Dll" EnforcementMode="Enabled">
    <FilePathRule Id="1" Name="Allowed System DLLs" Action="Allow">
      <Conditions>
        <FilePathCondition Path="%WINDIR%*" />
      </Conditions>
    </FilePathRule>
    <FileHashRule Id="2" Name="Allowed Custom Lib" Action="Allow">
      <Conditions>
        <FileHashCondition Hash="SHA256">
          <FileHash SourceFileName="C:Applibcore.dll" HashData="A1B2..." />
        </FileHashCondition>
      </Conditions>
    </FileHashRule>
  </RuleCollection>

• Linux: Применяются мандатные системы контроля доступа. SELinux или AppArmor позволяют описать, какие файлы каким процессам разрешено отображать в память и выполнять. Дополнительный контроль обеспечивают системы измерения целостности, такие как Integrity Measurement Architecture (IMA), которые могут прервать загрузку файла с неправильным хешем.

3. Тестирование в изолированном контуре

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

4. Регламентное обслуживание и мониторинг

Белый список — не монолит. Он должен обновляться при выходе новых версий ПО, установке обновлений безопасности или изменении инфраструктуры. Установите процесс, по которому любое изменение в составе ПО влечёт за собой проверку и актуализацию списка. Регулярно (не реже раза в полгода) проводите полный пересмотр политик.

От каких атак защищает этот подход

Реализованный белый список эффективно пресекает целый класс атак:

• Классический DLL/so hijacking: Прямая подмена библиотеки в каталоге поиска станет невозможной, так как хеш или подпись файла не совпадут с записью в списке.
• Side-loading: Атаки, при которых вредоносная библиотека с корректной подписью, но от непроверенного издателя помещается рядом с уязвимым приложением, будут блокироваться правилами на основе издателя.
• DLL Injection и Process Hollowing: Попытки принудительно внедрить код в работающий процесс будут остановлены, так как загружаемая библиотека не фигурирует в разрешённом списке для этого процесса.
• Внедрение руткитов и компонентов APT: Посторонние модули ядра (.ko, .sys) не смогут быть загружены, защищая самый низкий уровень системы.

Преимущества и соответствие требованиям

Помимо прямой безопасности, внедрение белых списков библиотек даёт и другие выгоды:

• Контроль целостности программной среды: Гарантия, что выполняется только код, прошедший процедуру утверждения.
• Существенное сокращение поверхности атаки: Закрывается один из самых популярных векторов начального проникновения и повышения привилегий.
• Детектирование аномалий: Попытки загрузки неавторизованных библиотек фиксируются в логах, становясь индикатором компрометации.
• Соответствие регуляторным требованиям: Данная мера прямо следует из принципа минимально необходимых привилегий и рекомендуется стандартами ФСТЭК России, а также является частью лучших практик при построении систем защиты информации.

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