Самый простой способ воспроизвести уязвимость — использовать bcdedit /set debug on на целевой системе и перезагрузить машину/ВМ. Это делает драйвером сетевого адаптера по умолчанию kdnic.sys, который очень охотно объединяет пакеты. Если вы пытаетесь воспроизвести уязвимость на другой конфигурации, вам нужно добиться, чтобы система объединяла отправленные вами пакеты. Подробнее читайте в разделе устранения неполадок ниже.

демо

cve-2024-38063.webm

грубый RCA

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

• В определенных ситуациях Windows объединяет несколько IP-пакетов и обрабатывает их пакетно. Сначала обрабатываются заголовки расширений в каждом пакете, и только затем обрабатываются данные в каждом пакете.
• Во время обработки заголовков расширений объекты пакетов этих объединенных пакетов связываются в связный список. Каждый объект пакета содержит объект NET_BUFFER, который содержит буферизованные данные пакета. По смещению 0x30 также находится поле текущего смещения, указывающее, насколько далеко был разобран пакет. На этом этапе значение смещения обычно равно 0x28, что означает, что заголовок IPv6 разобран, но больше ничего.
• При обработке заголовка расширения «destination options» в tcpip!Ipv6pReceiveDestinationOptions ошибка разбора приводит к вызову tcpip!IppSendErrorList. Эта функция вызывает tcpip!IppSendError для каждого объекта пакета в связном списке (начиная с текущего).
• При определенных условиях (например, если пакет является одноадресным) tcpip!IppSendError имеет побочные эффекты. Он «откатывает» буферизованные данные пакета к началу и сбрасывает поле текущего смещения в ноль.
• Однако во всей этой цепочке событий только первый пакет помечается как содержащий ошибку (смещение 0x8C). Это означает, что драйвер продолжит разбирать заголовки расширений других пакетов в связном списке, даже если они были «откачены» в IppSendError.
• Обработка тех пакетов, которые были откачены, затем выполняется с неожиданными данными: буферизованные данные пакета указывают на начало пакета (т.е. заголовок IPv6), а не на заголовки расширений, и значение поля смещения равно нулю, а не 0x28.

стратегия

• Для эксплуатации уязвимости мы используем Ipv6pReceiveFragment. Функция разбирает заголовок расширения фрагмента и предполагает, что поле смещения пакета будет не менее 0x28 при вычислении длины данных без заголовков в пакете путем вычитания 0x30 из текущего значения смещения. Затем это значение сохраняется в объекте сборки, предназначенном для сборки фрагментированного пакета.
• В нашем случае функция будет вызвана для пакета, который был откачен с помощью IppSendError. Значение смещения будет равно нулю и увеличено до 8 где-то раньше в Ipv6pReceiveFragment. При вычислении размера данных без заголовков произойдет переполнение вниз, и значение станет равно 0xffd8 (вычитание выполняется в 16 битах).
• Значение длины используется только в двух местах далее:
  • Ipv6pReassembleDatagram, где оно используется для вычисления длины выходного буфера собранного пакета. Однако все вычисления выполняются в 32 битах, и есть проверка на то, что общая длина не превышает 0xFFFF, что и происходит в этом случае.
  • Ipv6pReassemblyTimeout, где оно также используется таким же образом. Однако здесь вычисления выполняются в 16 битах и происходит целочисленное переполнение. Это приводит к переполнению буфера при последующем копировании данных в буфер.

Чтобы вызвать Ipv6pReassemblyTimeout, отправитель фрагмента должен быть неактивен в течение 1 минуты. Тогда наша стратегия такова:

• Отправить поврежденные destination options, чтобы вызвать IppSendError, а затем фрагментированный пакет
• Надеяться, что два пакета будут объединены и что объект второго пакета будет иметь сброшенные данные и смещение
• Вызвать переполнение вниз в Ipv6pReceiveFragment и создать новый объект сборки с длиной данных фрагмента, представляющей собой большое 16-битное значение
• Подождать 1 минуту, не отправляя больше пакетов, чтобы сработал Ipv6pReassemblyTimeout.
• Вызвать целочисленное переполнение при вычислении размера буфера в Ipv6pReassemblyTimeout и вызвать переполнение буфера в куче.

Пакеты в скрипте рассылаются в большом количестве, чтобы повысить вероятность их объединения. Основная полезная нагрузка довольно проста:

• IPv6-пакет с заголовком расширения «destination options», содержащим поврежденные данные параметров, которые вызовут ошибку при разборе
• Фрагмент IPv6 #1, который, мы надеемся, будет объединен с первым пакетом
• Фрагмент IPv6 #2 (тот же идентификатор), который также может быть объединен с первыми двумя, но его основная цель — завершить второй фрагмент, чтобы ошибки не возникали в случае нормальной обработки

Мы также вручную устанавливаем поля hop limit и flow label в IPv6-заголовке. Напомним, что буферизованные данные пакета сбрасываются из-за уязвимости. Это означает, что при обработке фрагментированного пакета IPv6-заголовок будет интерпретироваться как данные заголовка фрагмента. Поле hop limit в IPv6-заголовке будет интерпретироваться как один из битов поля id в заголовке фрагмента. Изменяя его, мы гарантируем, что уязвимость сработает для нескольких различных фрагментов и вызовет несколько различных повреждений, увеличивая вероятность краха (поскольку это PoC). Поле flow limit IP-заголовка будет интерпретироваться как поля смещения и индикатора продолжения заголовка фрагмента. Устанавливая его в 1, мы указываем, что будет еще заголовки (следовательно, можно вызвать Ipv6pReassemblyTimeout позже) и что смещение равно нулю (поскольку это первый пакет с таким идентификатором).

примечания

• Вышеописанное — лишь одна стратегия эксплуатации проблемы, возникающей при срабатывании уязвимости. Я использовал эту стратегию, так как она была довольно прямолинейной, и я не хотел тратить время на изучение других возможностей. Не удивлюсь, если вскоре другие исследователи представят гораздо более интересные стратегии.
• Что требуется для уязвимости:
  • Поддержка IPv6 на целевой системе, возможность получать пакеты (до брандмауэра)
  • Возможность заставить целевую систему в некоторой степени объединять отправленные пакеты. Некоторые пары адаптер + драйвер делают это очень охотно, в то время как другие, похоже, более сдержаны. Возможно, существуют трюки или специальные цепочки пакетов, которые можно использовать, чтобы заставить Windows RSC объединять пакеты независимо от адаптера или состояния сети, но у меня нет доказательств этого.
• Что не требуется для уязвимости:
  • Рассылка большого количества пакетов — PoC делает это только для повышения вероятности объединения и срабатывания множественных повреждений в качестве демонстрации.
  • Высокая нагрузка на целевую систему, так как объединение может происходить во многих различных ситуациях.
  • Какие-либо специальные настройки целевой системы, кроме включенного IPv6.
  • (Скорее всего) Ожидание минуты для срабатывания повреждения — я использовал эту стратегию эксплуатации уязвимости только потому, что она была самой простой. Есть реальная вероятность, что проблемная ситуация, вызванная уязвимостью, может быть использована более прямым способом.
  • (Скорее всего) Одноадресные пакеты — я использую их, поскольку путь кода, который мы используем в Ipv6pReassemblyTimeout, требует, чтобы исходный фрагментированный пакет был отправлен как одноадресный.

устранение неполадок

Если не работает, это может быть из-за:

• Целевая система недоступна по IPv6:
  • Отключите брандмауэр Windows
  • Выполните ping -6 {ipv6_address} с хост-ПК
  • Убедитесь, что получаете ответ
  • Снова включите брандмауэр
• Целевая система не получает пакеты
  • Установите Wireshark на целевой системе и проверьте, что пакеты, отправленные скриптом, приходят
• scapy сообщает «Mac address to reach destination not found. Using broadcast.»
  • Вам нужно найти MAC-адрес целевой машины
  • Это можно сделать, выполнив команду ping из вышеуказанного и проверив ответ в Wireshark (поле eth source address)
  • Также можно использовать scapy: Ether(raw(sr1(IPv6(dst={your_dest_ip})/ICMPv6EchoRequest()))).src, но это иногда не работает
  • Как только вы получите MAC-адрес, вставьте его в поле mac_addr в скрипте и запустите скрипт
• Пакеты не объединяются на целевой системе
  • В зависимости от вашего сетевого адаптера/драйвера может быть сложно заставить Windows объединять пакеты, не прибегая к чему-то вроде затопления цели, напоминающего DDoS.
  • Вы можете попробовать изменить настройки адаптера, например, «Packet Coalescing», «Interrupt Moderation», «Interrupt Moderation Mode», «Recv Segment Coalescing», в зависимости от того, какие доступны. Например, установка «Interrupt Moderation Mode» в значение «Extreme» на моем выделенном сервере делает уязвимость воспроизводимой.

Если ничего не помогает, вы можете подключить отладчик ядра и проверить несколько вещей: - Вызывается ли tcpip!Ipv6pReceiveDestinationOptions -> tcpip!Ipv6pProcessOptions -> tcpip!IppSendErrorList? - Поставьте точку останова на tcpip!Ipv6pProcessOptions и проверьте, равен ли [rcx] нулю постоянно. Если да, то пакеты по какой-то причине не объединяются. - Поставьте точку останова на tcpip!Ipv6pReceiveFragment и проверьте, равен ли [rcx+0x30] нулю. Если нет, то уязвимость по какой-то причине не сработала.