В популярном 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.
Поделиться с друзьями
-->

Комментарии (7)


  1. webhamster
    11.07.2017 17:16
    -3

    Вы знаете что с этой уязвимостью надо делать.


  1. mickvav
    12.07.2017 00:14
    +1

    А если TSIG не используется, можно выдохнуть?


  1. sotnikdv
    12.07.2017 04:02
    +8

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

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


    1. TimsTims
      12.07.2017 10:43
      -2

      Это холиварная тема, и постоянно всплывает.

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

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


      1. Regis
        12.07.2017 14:40
        +1

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


    1. lovecraft
      12.07.2017 19:13

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


  1. CentALT
    12.07.2017 10:48

    Это просто красиво.