Обнаружена опаснейшая уязвимость в Windows DNS Server +35





Исследователи в области кибербезопасности из компании Check Point раскрыли новую критическую уязвимость, которая затрагивает версии Windows Server 2003–2019 с оценкой критичности 10 из 10 по шкале CVSS.


17-летний программный недостаток приводит к удаленному выполнению кода (CVE-2020-1350), названному Check Point «SigRed» и может позволить удаленному злоумышленнику, не прошедшему проверку подлинности, получить права администратора домена над целевыми серверами и получить полный контроль над ИТ-инфраструктурой организации.


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


В отчете, опубликованном в блоге компании, исследователь Check Point Саги Цадик подтвердил, что этот недостаток имеет ужасный характер, позволяя атакующим начать атаку, которая может распространиться с одного уязвимого компьютера на другой без какого-либо вмешательства человека. Т.е. уязвимость носит явный "wormable"-характер.


После того, как Check Point ответственно сообщила о своих выводах Microsoft, производитель Windows подготовил исправление для этой уязвимости и выпустил его, начиная с сегодняшнего дня, в рамках своего июльского исправления во вторник, которое также включает в себя обновления безопасности для 122 других уязвимостей.


В Microsoft заявили, что не нашли никаких доказательств того, что эта ошибка активно использовалась злоумышленниками, и посоветовали пользователям немедленно устанавливать исправления.


«Windows DNS Server — это основной сетевой компонент. Хотя в настоящее время неизвестно, чтобы эта уязвимость использовалась в активных атаках, важно, чтобы клиенты применяли обновления Windows для ее устранения как можно скорее».

Детали


Переадресованный запрос происходит, когда DNS-сервер не может разрешить IP-адрес для данного доменного имени (например, www.google.com ), в результате чего запрос перенаправляется на официальный DNS-сервер имен (NS).


image


Чтобы использовать эту архитектуру, SigRed включает в себя настройку записей ресурсов NS домена («deadbeef.fun») для указания на вредоносный сервер имен («ns1.41414141.club») и запрос целевого DNS-сервера для домена, чтобы последний анализировал ответы от сервера имен для всех последующих запросов, связанных с доменом или его поддоменами.


Таким образом злоумышленник может вызвать ошибку целочисленного переполнения в функции, которая анализирует входящие ответы для перенаправленных запросов («dns.exe!SigWireRead»), чтобы отправить ответ DNS, содержащий запись ресурса SIG размером более 64 КБ, и вызвать контролируемое переполнение кучи примерно исходя из небольшого выделенного буфера.


Ошибка выявлена в функции, ответственной за выделение памяти для записи ресурса («RR_AllocateEx»), чтобы генерировать результат размером более 65 535 байт, что вызывает переполнение целых чисел, которое приводит к гораздо меньшему выделению, чем ожидалось.


Но с одним сообщением DNS, ограниченным 512 байтами в UDP (или 4096 байтами, если сервер поддерживает механизмы расширения) и 65 535 байтами в TCP, исследователи обнаружили, что ответа SIG с одной только длинной сигнатурой было недостаточно, чтобы вызвать уязвимость.


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


SigRed может быть запущен удаленно через браузер в ограниченных сценариях (например, Internet Explorer и браузеры Microsoft Edge не на основе Chromium), позволяя злоумышленнику злоупотреблять поддержкой DNS-серверов Windows в функциях повторного использования соединений и конвейерной обработки запросов, чтобы «переправить» DNS-запрос внутри полезной нагрузки HTTP-запроса к целевому DNS-серверу при посещении веб-сайта под их контролем.


DNS-клиенты («dnsapi.dll») не подвержены этой ошибке, что заставляет исследователей подозревать, что Microsoft управляет двумя совершенно разными базами кода для DNS-сервера и DNS-клиента и не синхронизирует исправления ошибок между ними.


Исправление


Учитывая серьезность уязвимости и высокие шансы на активную эксплуатацию, пользователям рекомендуется срочно обновить уязвимые DNS-серверы Windows для снижения риска.


В качестве временного обходного пути, максимальная длина сообщения DNS (через TCP) может быть установлена в значение «0xFF00», чтобы исключить вероятность переполнения буфера:


reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters" /v "TcpReceivePacketSize" /t REG_DWORD /d 0xFF00 /f && net stop DNS && net start DNS

Теги:




Комментарии (21):

  1. OleksiyT
    /#21846732

    Никогда такого не было и вот опять (с)

    • TIMOHIUS
      /#21847942 / +3

      xxx: У нас дыра в безопасности!
      yyy: Ну хоть что то у нас в безопасности.

      • /#21848634 / +3

        Хабр уже не торт, никто в каментах не упомянул решето.

        • amarao
          /#21849040

          Всем пофигу. Ну пофиксили в COBOL-64 ошибку переполнения DNS в Windows, и?

  2. osipov_dv
    /#21847408 / +1

    Учитывая серьезность уязвимости и высокие шансы на активную эксплуатацию, пользователям рекомендуется срочно обновить уязвимые DNS-серверы Windows.

    ага, сперва захватываем права, потом фиксим :)

  3. Tufed
    /#21847992 / +2

    2003 и 2008 сервера чем обновить?
    Ах, да, они же не поддерживаются больше.

  4. jok40
    /#21848340

    reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters” /v “TcpReceivePacketSize” /t REG_DWORD /d 0xFF00 /f net stop DNS && net start DNS
    В команде нужно или удалить кавычки или заменить их на нормальные, а также после '/f' дописать '&&':

    reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters" /v "TcpReceivePacketSize" /t REG_DWORD /d 0xFF00 /f && net stop DNS && net start DNS

    • LukaSafonov
      /#21848536

      Исправил, спасибо!

      • NRinat
        /#21849174 / +2

        Ну серьезно, почему вы не протестировали то, что предлагаете своим коллегам выполнить?
        Ведь вы же занимаетесь безопасностью. Как можно не протестировать то, что предлагаете другим.
        Вы же, надеюсь, знаете про байки про команду rm в Linux.
        Думаю, что посты связанные с безопасностью должны проверяться по 10 раз минимум, а лучше по 17 раз… как в российской пословице.

        • vitaly_il1
          /#21849872 / +1

          Коллеги должны читать первоисточники, а не Хабр :-)

  5. NRinat
    /#21848354

    Jok40, я такой же коммент добавил, только почему-то не видел на момент публикации коммента, что вы это уже написали.
    Не вижу, к сожалению, возможности удалить свой дубль.
    )))

  6. poige
    /#21848364 / +2

    > и вызвать контролируемое переполнение кучи
    > примерно
    > исходя из небольшого выделенного буфера.

    O_o

  7. /#21848422

    Как раз вижу в логах DNS сервера событие 7050:
    The DNS server recv() function failed. The event data contains the error.
    Это с этим связано?

  8. wwladimir
    /#21848424 / +1

    Непрохо было бы и источники информации дать.
    Ну хотя бы это https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability

  9. v1000
    /#21849660 / -1

    17-летний программный недостаток
    интересное совпадение, как раз в это время им оставляли сообщение на эту тему

    image

  10. /#21850324 / -1

    вангую: на сл.неделе новость будет про еще более опасную и древнюю уязвимость

  11. Baxus
    /#21850326

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

  12. /#21850328

    Я не был поражен Microsoft. Спасибо!

  13. soniq
    /#21850416 / +2

    Чтобы использовать эту архитектуру, SigRed включает в себя настройку записей ресурсов NS домена («deadbeef.fun») для указания на вредоносный сервер имен («ns1.41414141.club») и запрос целевого DNS-сервера для домена, чтобы последний анализировал ответы от сервера имен для всех последующих запросов, связанных с доменом или его поддоменами.


    Ух! Умеют же люди писать!