Критическая уязвимость позволяет перехватывать весь сетевой трафик пользователей Windows06.07.2016 13:03

28b55b9d5cda42cca98f332b3b05449b.png

Исследователи из ИБ-подразделения компании Tencent под названием Xuanwu Lab обнаружили серьезную ошибку в реализации протокола NetBIOS, использующейся в Windows. Критическая уязвимость получила название BadTunnel — она позволяет злоумышленникам полностью контролировать сетевой трафик жертвы.

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


BadTunnel позволяет злоумышленникам контролировать не только HTTP и HTTPS-запросы, но и всю сетевую активность операционной системы. Например, вмешиваться в загрузку системных обновлений и процесс получения списков сертификатов. Уязвимы все версии ОС Windows.

По словам обнаружившего уязвимость исследователя Яна Ю (Yang Yu), перенаправление трафика жертвы может осуществляться с помощью поддельного WPAD-файла (Web Proxy Auto Discovery) или ISATAP-сервера.

Разбор возможной атаки


Эксперты Positive Technologies описали возможную атаку с применением уязвимости BadTunnel. Для ее осуществления необходимо убедить жертву открыть хотя бы один UNC или URI путь — это может быть адрес вредоносного сайта, адрес папки или документа. В этом случае будет использоваться NetBIOS over TCP/IP, а не стандартные сокеты.

Путь должен содержать в себе ip-адрес сервера атакующего, например:

При обработке этого адреса первоначально будут отправлены запросы на порты 139 (NetBIOS Session) или 445 (Microsoft-DS Active Directory, Windows shares). Если эти порты будут закрыты, то жертва отправит NetBIOS Name Service (NBNS) NBSTAT сообщение на 137 порт, тем самым открывая UDP-тоннель и позволяя злоумышленнику слать запросы прямиком жертве, минуя NAT и Firewall.

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

Через некоторое время после того, как уязвимый компьютер примет фиктивный ответ на WPAD запрос — он начнёт искать настройки прокси по адресу WPAD. После их нахождения происходит подключение и злоумышленник получает полный контроль над трафиком жертвы.

Почему это возможно


Эксперты Positive Technologies так объясняют возможность проведения описанной атаки:
  1. Поле Transaction ID в NBNS-запросах не рандомизируется, а инкрементируется, поэтому атакующий может его подобрать.
  2. NBSTAT и NB-запросы инкрементируются вместе (один счётчик).
  3. NBSTAT-сообщения по умолчанию могут уходить во внешнюю сеть.
  4. Broadcast-запросы могут получать ответы из внешней сети.
  5. NBNS использует исключительно 137 порт и UDP (и на клиенте, и на сервере), который не поддерживает сессий и состояний.

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


Использование таких средств, как межсетевые экраны или NAT не может предотвратить атаки с применением уязвимости BadTunnel. По словам Яна Ю, причина этого кроется в том, что протокол UDP не устанавливает соединения, а используется для создания туннеля.

Microsoft опубликовала бюллетени безопасности MS16–063 и MS16–077, устраняющие ошибку в последних версиях Windows.
Суть этих обновлений заключается в том, что теперь периодическое определение имени WPAD выключено по умолчанию, а NBSTAT запросы из домашней сети также по умолчанию заблокированы. Эти изменения регулируются ключами реестра и делают невозможным установление UDP тоннеля для проведения атаки с использованием BadTunnel.

Однако уязвимость сохранилась в устаревших и ныне не поддерживаемых версиях ОС. В их числе Windows XP и Windows Server 2003. Пользователям этих систем для того, чтобы обезопасить себя, необходимо заблокировать порт UDP 137.

По словам Яна Ю, это не первая уязвимость, приводящая к возможности атак перехвата WPAD. Подобные случаи фиксировались в 1999, 2007, и 2012 году, когда произошел всплески активности червя Flame.

Существующие Proof-of-Concept скрипты не учитывают информацию об Transaction ID в NBSTAT запросе и основываются на огромном потоке поддельных ответов на запрос со всеми возможными значениями поля Transaction ID от 0 до 65535. Однако для успешного проведения атаки достаточно минимального количества поддельных пакетов.

Экспертами Positive Technologies был разработан ряд сигнатур для IDS Suricata, позволяющих обнаружить стадии подмены NetBIOS имён и установления UDP тоннеля, блокирующие попытки подмены адреса WPAD и ISATAP и сигнализирующие о возможной попытке атаки. Они доступны в официальном Twitter и github-аккаунте.

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

  • 6 июля 2016 в 12:45

    +1

    ↑

    ↓

    Наконец-то Microsoft закопают стюардессу.
    By default, WPAD resolution for auto proxy detection will not use NETBIOS. Therefore, if proxy detection depends on NETBIOS alone for WPAD resolution, it may fail. We recommend that you use the DHCP option or DNS for WPAD resolution instead of NETBIOS. To change this new default behavior, create the following registry entry.

    Note This registry entry only applies for Windows 8.1 and earlier versions of Windows.
    SUBKEY: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
    Value Name: AllowOnlyDNSQueryForWPAD
    Type: DWORD
    Value: 0
    Default value of the flag: 1

  • 6 июля 2016 в 12:53 (комментарий был изменён)

    –1

    ↑

    ↓

    Желтизной аж воняет от текста, прямо стекает на пол.
    Стыдно так писать, складывается впечатление что текст не от специалистов, а от журнализдов-гуманитариев.

    «BadTunnel позволяет злоумышленникам контролировать не только HTTP и HTTPS-запросы, но и всю сетевую активность операционной системы.»
    не позволяет.

    WPAD — механизм автоконфигурации прокси серверов.
    Оно используется по дефолту в IE и WinHTTP API на базе которого работает WindowsUpdate и может быть ещё что то.
    Многие приложения и браузеры вообще не умеют WPAD или не используют или оно с ними не совместимо.
    Те для SSH клиентов оно вообще никак, никаким боком.

    Пользователям нужно отключить службу WebProxy auto discavery, и в настройках ИЕ снять галочку с автоматического поиска прокси серверов.
    Админам же давно нужно было настроить автодискавери через DHCP ибо более приоритетен, а на вебсервере отдавать wpad.dat с содержимым: «function FindProxyForURL (url, host) { return «DIRECT»; }» и типом миме: «application/x-ns-proxy-autoconfig», вот так можно в nginx сделать:
    # wpad.dat
    # dnsmasq.conf: dhcp-option=252, http://your.server.here: port/wpad.dat
    location ^~ /wpad.dat {
    more_set_headers 'Content-Type: application/x-ns-proxy-autoconfig';
    add_header Cache-Control 'max-age=30, must-revalidate';
    return 200 'function FindProxyForURL (url, host) { return «DIRECT»; }';
    }
    (кавычки вокруг DIRECT — обычные должны быть)

    А 137, 139 и 445 в инет давно зарезать, некоторые провайдеры у нас так и делают, чтобы мусор от клиентов в сеть не летел.

© Habrahabr.ru