Критическая уязвимость механизма аутентификации BIND позволяет похищать и изменять DNS-записи серверов



    В популярном DNS-сервере BIND обнаружена критическая уязвимость. Ее эксплуатация позволяет злоумышленнику получить корректную подпись для произвольных данных и с помощью этой подписи вносить в него изменения или получать список всех DNS-записей сервера (dns zone transfer attack).

    В чем проблема


    Уязвимость CVE-2017-3143 обнаружена в реализации протокола аутентификации для BIND DNS под названием TSIG. Также протокол TSIG используется рядом других DNS-сервисов вроде PowerDNS, NSD и Knot DNS.

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

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

    Согласно RFC 2845, ответный дайджест вычисляется от трех полей из запроса:

    • дайджест (MAC) из запроса вместе с полем длины;
    • записи из запроса (обновления), но без записи TSIG;
    • сама запись TSIG, но без дайджеста.

    Таким образом, эксплуатация уязвимости происходит в несколько этапов:

    1. Злоумышленник посылает DNS запрос с обновлением зон и записью SOA, где вместо дайджеста помещает данные RR записей, которые он намерен вставить в базу сервера. Например, запись TXT в одну из подконтрольных серверу зон с текстом “Injected”. Длина такого дайджеста должна быть больше той, которая подразумевается используемым алгоритмом хеширования, например, с длинной больше 32 байт для алгоритма HMAC-SHA256.
    2. Сервер, вместо ответа с пустым полем MAC (дайджест) в записи TSIG, возвращает данные от атакующего, включая запрос с обновлением зон и запись TXT, подписанные секретным ключом сервера.
    3. Используя полученную подпись, злоумышленник посылает тот же запрос с обновлением зон, что и на шаге 1, но дополнительные записи, вместо поля MAC записи TSIG, находятся в секции Zones после записи SOA, а поле MAC теперь содержит корректный дайджест из шага 2. Для эксплуатации, значение поля Time Signed записей TSIG должно быть одинаковым, чтобы при проверке сигнатуры уязвимый сервер использовал одни и те же данные.
    4. Сервер, после успешной проверки присланного запроса, применяет данные к базе, о чем можно узнать из лога:

    14-Jun-2017 07:48:55.003 client 172.17.42.1#50445/key tsig_key: updating zone 'example.com/IN': adding an RR at 'i.can.inject.records.in.the.zone.example.com' TXT "injected"

    Согласно опубликованной исследователями информации, наличие уязвимости подтверждено для следующих версий BIND:

    • BIND 9.9.10
    • BIND 9.10.5
    • BIND 9.11.1

    По данным компании ISC, под лицензией которой распространяется программное обеспечение BIND, также уязвимы версии:

    • с 9.4.0 до 9.8.8
    • с 9.9.0 до 9.9.10­P1
    • с 9.10.0 до 9.10.5­P1
    • с 9.11.0 до 9.11.1­P1
    • с 9.9.3­S1 до 9.9.10­S2
    • с 9.10.5­S1 до 9.10.5­S2

    Представители Synaktiv в своем материале также представили код PoC-эксплоита для данной уязвимости.

    Как защититься


    Специалисты ISC опубликовали патч для устранения описанной ошибки безопасности. Кроме того, эксперты Positive Technologies создали сигнатуру для IDS Suricata, которая позволяет выявлять и предотвращать попытки эксплуатации уязвимости CVE-2017-3143 по сети, в архиве также пример трафика при эксплуатации данной уязвимости:



    Также для обнаружения уязвимостей специалисты нашей компании рекомендуют использовать специализированные средства вроде системы мониторинга защищенности и соответствия стандартам MaxPatrol 8.
    • +26
    • 10,6k
    • 7
    Positive Technologies 235,03
    Компания
    Поделиться публикацией

    Вакансии компании Positive Technologies

    Комментарии 7
    • –3
      Вы знаете что с этой уязвимостью надо делать.
      • +1
        А если TSIG не используется, можно выдохнуть?
        • +8
          А эти synactiv не могли сначала связаться с разработчиками бинда и мажорными дистрибутивами, передать им детали и опубликовать сообщение без раскрытия деталей. А раскрыть PoC уже после патча или по прошествии нескольких дней-недели?

          Ну вот нахрена так делать? Окей, я еще понимаю продажу 0day в даркнете, но это вот нахрена было так делать?
          • –2
            Это холиварная тема, и постоянно всплывает.

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

            И с той, и с другой стороны есть свои логичные аргументы, и всё зависит от целевой аудитории используемой уязвимости(программы).
            • +1

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

            • 0
              Не ругайтесь, уже всё запатчили четыре дня назад https://www.debian.org/security/2017/dsa-3904
            • 0
              Это просто красиво.

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

              Самое читаемое