В популярном 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, но без дайджеста.
Таким образом, эксплуатация уязвимости происходит в несколько этапов:
- Злоумышленник посылает DNS запрос с обновлением зон и записью SOA, где вместо дайджеста помещает данные RR записей, которые он намерен вставить в базу сервера. Например, запись TXT в одну из подконтрольных серверу зон с текстом “Injected”. Длина такого дайджеста должна быть больше той, которая подразумевается используемым алгоритмом хеширования, например, с длинной больше 32 байт для алгоритма HMAC-SHA256.
- Сервер, вместо ответа с пустым полем MAC (дайджест) в записи TSIG, возвращает данные от атакующего, включая запрос с обновлением зон и запись TXT, подписанные секретным ключом сервера.
- Используя полученную подпись, злоумышленник посылает тот же запрос с обновлением зон, что и на шаге 1, но дополнительные записи, вместо поля MAC записи TSIG, находятся в секции Zones после записи SOA, а поле MAC теперь содержит корректный дайджест из шага 2. Для эксплуатации, значение поля Time Signed записей TSIG должно быть одинаковым, чтобы при проверке сигнатуры уязвимый сервер использовал одни и те же данные.
- Сервер, после успешной проверки присланного запроса, применяет данные к базе, о чем можно узнать из лога:
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.10P1
- с 9.10.0 до 9.10.5P1
- с 9.11.0 до 9.11.1P1
- с 9.9.3S1 до 9.9.10S2
- с 9.10.5S1 до 9.10.5S2
Представители Synaktiv в своем материале также представили код PoC-эксплоита для данной уязвимости.
Как защититься
Специалисты ISC опубликовали патч для устранения описанной ошибки безопасности. Кроме того, эксперты Positive Technologies создали сигнатуру для IDS Suricata, которая позволяет выявлять и предотвращать попытки эксплуатации уязвимости CVE-2017-3143 по сети, в архиве также пример трафика при эксплуатации данной уязвимости:
Также для обнаружения уязвимостей специалисты нашей компании рекомендуют использовать специализированные средства вроде системы мониторинга защищенности и соответствия стандартам MaxPatrol 8.
Комментарии (7)
sotnikdv
12.07.2017 04:02+8А эти synactiv не могли сначала связаться с разработчиками бинда и мажорными дистрибутивами, передать им детали и опубликовать сообщение без раскрытия деталей. А раскрыть PoC уже после патча или по прошествии нескольких дней-недели?
Ну вот нахрена так делать? Окей, я еще понимаю продажу 0day в даркнете, но это вот нахрена было так делать?TimsTims
12.07.2017 10:43-2Это холиварная тема, и постоянно всплывает.
Одни утверждают, что надо сначала тихо исправить, а потом об этом сообщать, чтобы не пострадали другие(чтобы всякие скрипт-кидди не начали щас ломать всякую мелочь), вторые считают правильным всех предупредить, чтобы не пострадали другие(чтобы крупные компании знали о такой 0day, и не подвергались крупному риску).
И с той, и с другой стороны есть свои логичные аргументы, и всё зависит от целевой аудитории используемой уязвимости(программы).Regis
12.07.2017 14:40+1Обычно вопрос в том, публиковать или нет (а если публиковать, то через какой срок) если компания-разработчик не торопится исправлять уязвимость. Вопроса "а стоит ли уведомить разработчика до публикации" обычно и не стоит — нормальные "белые шляпы" это делают.
lovecraft
12.07.2017 19:13Не ругайтесь, уже всё запатчили четыре дня назад https://www.debian.org/security/2017/dsa-3904
webhamster
Вы знаете что с этой уязвимостью надо делать.