host_m 5 мар 2021 в 12:10

Битсквоттинг сайта Windows.com

7 мин

16K

Блог компании VDSina.ruИнформационная безопасность*Администрирование доменных имен*DNS*

Перевод

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

Когда вы пытаетесь получить доступ к сайту по его домену, этот домен хранится в памяти вашего компьютера, устройства и т.д. в структуре, выглядящей примерно так:

01110111	01101001	01101110	01100100	01101111	01110111	01110011
w	i	n	d	o	w	s

Теперь представим, что компьютер перегрелся, произошла вспышка на Солнце или космический луч (вполне реальная штука) инвертировал в компьютере значение одного бита.

01110111	01101000	01101110	01100100	01101111	01110111	01110011
w	h	n	d	o	w	s

О нет! Теперь в памяти хранится значение whndows.com, а не windows.com! Что же произойдёт, когда придёт время создания подключения к этому домену?

nslookup whndows.com

*** can’t find whndows.com: Non-existent domain

Домен не резолвится в IP-адрес!
Оказалось, что из 32 возможных доменных имён, находящихся в одной замене бита от windows.com, 14 имён были доступны для покупки! Это довольно редкий случай — обычно такие имена покупаются компаниями, например, Microsoft, чтобы предотвратить их использование в целях фишинга. Итак, я их купил. Все. Примерно за 126 долларов.

(Если вы являетесь верифицируемо ответственным лицом, то я с радостью передам вам владение этими доменами. В противном случае я придержу их и продолжу сливать деньги.)

windnws.com
windo7s.com
windkws.com
windmws.com
winlows.com
windgws.com
wildows.com
wintows.com
wijdows.com
wiodows.com
wifdows.com
whndows.com
wkndows.com
wmndows.com

Теперь нам нужно, чтобы эти домены на что-то указывали. Я арендовал VPS, сконфигурировал IPv4/IPv6 и создал подстановочные DNS-записи, чтобы указывать на них.

Подстановочные DNS работают следующим образом: я создаю запись, сообщающую, что whndows.com указывает на 123.123.123.123, и когда кто-нибудь запрашивает abs.xyz.whndows.com, он получит в качестве ответа ту же DNS-запись 123.123.123.123. Поскольку в этом исследовании мы имеем дело с инвертированием битов, это позволяет мне перехватывать любые DNS lookup поддомена windows.com, в которых инвертировано несколько битов.

Настроив DNS, мы используем tshark для выполнения перехвата пакетов через публичный интерфейс нашего VPS и подождём, пока не произойдёт что-нибудь интересное.

Ниже приведена краткая выжимка интересных вещей, которой можно поделиться без возможности идентификации пользователей.

Чтобы отличить оппортунистическое сканирование от ситуации инвертирования битов, я использовал GreyNoise.io. Это отличный продукт!

NTP UDP port 123 time.windows.com

UDP-пакеты, предназначенные для порта 123, пытаются задать время на часах компьютера с помощью Network Time Protocol (NTP).

time.windows.com — это стандартный NTP-сервер, настроенный для всех машин под Windows и они регулярно сверяют по нему время. Если им не удаётся получить время, то они пробуют снова, и снова, и снова.

В сумме, на протяжении 14 дней мой сервер получил 199 180 подключений NTP-клиентов с 626 уникальных IP-адресов.

NTP-клиент для ОС Windows не имеет внутренней верификации аутентичности, поэтому злоумышленнику ничего не стоит сообщить всем этим компьютерам, что сейчас время после 03:14:07 вторника 19 января 2038 года и посеять хаос, поскольку ячейка памяти, хранящая время в формате 32-битного числа со знаком, переполняется.

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

С помощью фильтра tshark ntp.xmt мы можем извлечь Transmit Timestamp, то есть текущее по мнению компьютера время на момент обновления времени.

tshark -r capture.pcap -T fields -e ntp.xmt -2 -R ntp.xmt | sort -u

Sep 28, 1984 19:41:12.638290998 EDT
Sep 28, 2012 11:59:42.976403314 EDT
Sep 28, 2029 21:50:47.552079831 EDT
Sep 28, 2100 18:13:09.180229791 EST
Sep 29, 1975 08:36:52.200231052 EDT
Sep 29, 1980 23:44:14.142299217 EDT
Sep 29, 2036 11:54:11.410350275 EDT
Sep 29, 2038 06:18:34.082394858 EDT
Sep 29, 2046 16:00:00.102963544 EST
Sep 29, 2050 06:39:18.880921186 EST
Sep 29, 2074 07:31:58.701524704 EST
Sep 30, 1999 00:29:32.120677896 EDT
Sep 30, 2009 02:54:33.318870579 EDT
Sep 30, 2049 00:14:59.396552253 EST
Sep 30, 2075 13:56:14.492526678 EST
Sep 30, 2081 01:56:58.477295064 EST

HTTP TCP port 80 sg2p.w.s.windows.com

Для настоящего домена sg2p.w.s.windows.com отсутствуют активные DNS-записи.

Однако, судя по User-Agent и времени запросов, можно понять, что эта активность напрямую связана с тем же приложением, которое сгенерировало показанный ниже трафик для client.wns.windows.com и skydrive.wns.windows.com

GET / HTTP/1.1
Host: sg2p.w.s.windo7s.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Accept: */*

HTTP TCP port 80 client.wns.windows.com

Похоже, они напрямую связаны с сервисами Windows Push Notification Services (WNS), позволяющими сторонним разработчикам отправлять toast-, tile-, badge- и raw-обновления с собственного облачного сервиса. DNS-запись — это CNAME для wns.notify.trafficmanager.net.

DNS-записи:

client.wns.windows.com.        IN    CNAME   wns.notify.trafficmanager.net.
wns.notify.trafficmanager.net. IN    A       52.177.166.224

HTTP-запрос:

GET / HTTP/1.1
Host: client.wns.wkndows.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Accept: */*

HTTP TCP port 80 skydrive.wns.windows.com

Словом Skydrive до смены имени назывался OneDrive.

DNS-записи:

skydrive.wns.windows.com.      IN      CNAME   client.wns.windows.com.
client.wns.windows.com.        IN      CNAME   wns.notify.trafficmanager.net.
wns.notify.trafficmanager.net. IN      A       52.179.224.121

HTTP-запрос:

GET / HTTP/1.1
Host: skydrive.wns.windo7s.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Accept: */*

HTTP TCP port 80 time.windows.com

Понятия не имею, откуда пришёл этот запрос и почему HTTP запрашивается с сервера, который должен быть NTP-сервером. WHOIS по IP, сделавшему этот запрос, показан ниже:

inetnum:        123.112.0.0 - 123.127.255.255
netname:        UNICOM-BJ
descr:          China Unicom Beijing province network
descr:          China Unicom
country:        CN
admin-c:        CH1302-AP
tech-c:         SY21-AP
mnt-by:         APNIC-HM
mnt-lower:      MAINT-CNCGROUP-BJ
mnt-routes:     MAINT-CNCGROUP-RR
mnt-irt:        IRT-CU-CN

GET / HTTP/1.1
Host: time.wiodows.com
Connection: close
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Accept-Encoding: gzip
Accept-Language: zh-cn,zh-tw
Accept: */*

Вскоре после этого запроса произошла ещё более странная ситуация! Baidu — это один из крупнейших китайских поисковых движков. Не забывайте, что я сконфигурировал свои DNS-сервера для резолвинга в режиме подстановки. Существует очень малое количество способов, которыми Baiduspider мог бы узнать о существовании time.wiodows.com. Особенно учитывая, что ранее к этому домену был выполнен только один запрос (показанный выше).

GET / HTTP/1.1
Host: time.wiodows.com
Connection: close
User-Agent: Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)
Accept-Encoding: gzip
Accept-Language: zh-cn,zh-tw
Accept: */*

HTTP tcp port 80 windows.com/stopcode

При возникновении синего экрана смерти в Windows пользователю предлагается посетить https://www.windows.com/stopcode. Естественно, если компьютер завис, он не может просто открыть ссылку. Большинство людей, скорее всего, просто отсканировали бы QR-код, но те, кто ввёл адрес с опечаткой, оказались здесь.

GET /stopcode HTTP/1.1
Host: wildows.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 5.0.1; ALE-L21) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.111 Mobile Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

Особенно любопытен следующий запрос. Из-за характера запроса я укажу некоторые подробности обобщённо или полностью отцензурирую, потому что не совсем понятно, что происходит.

IP из диапазона 113.96.0.0 — 113.111.255.255 (CHINANET-GD) делает запрос с телефона под Android.

GET /topode HTTP/1.1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 7.1.2; M6 Note Build/N2G47H; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/77.0.3865.120 MQQBrowser/6.2 TBS/045223 Mobile Safari/537.36 MMWEBID/9551 MicroMessenger/7.0.14.1660(0x27000E37) Process/tools NetType/4G Language/zh_CN ABI/arm64 WeChat/arm64 wechatdevtools
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US
Host: wintows.com
Via: 1.1 TENCENT64.site (squid/3.5.20)
X-Forwarded-For: <Department of Defence IP>
Cache-Control: max-age=259200
Connection: keep-alive

Похоже, какой-то пользователь из Китая использует squid для инъецирования HTTP-заголовков в каждый запрос, исходящий из его сети, в том числе и со своего мобильного телефона. На его компьютере возникает синий экран смерти, поэтому пользователь пытается поискать код STOP-ошибки на windows.com/stopcode с телефона. Он вводит URL с ошибкой и оказывается на моём сервере, где я вижу, что он инъецирует HTTP-заголовок для X-Forwarded-For, пытающийся представить запрос так, как будто он отправлен с IP, принадлежащего Министерству обороны США.

Когда я поискал исходный IP на GreyNoise, то узнал следующее: «Этот IP-адрес оппортунистически сканировал Интернет и совершил полное TCP-соединение. Спуфинг зафиксированной активности невозможен. GreyNoise определил, что этот IP-адрес сканирует Интернет через следующие порты: 443 / TCP».

Наблюдая за тем, что мой трафик получается по 80 / TCP, могу предположить, что это не предусматривалось.

HTTP TCP port 80 windows.com/?fbclid

Как и можно было ожидать, кто-то в Facebook обязательно должен был опечататься в адресе windows.com, из-за чего создалась ссылка с уникальным токеном ?fbclid=xyz. Краулер Facebook пытается запросить адрес, то же самое делает и Bing, если он на другом языке, после чего пытается перевести его.

GET /?fbclid=IwAR28VIBcDUlzO4XQOk9R-EWYLsnjUf-SrrKKZyAdOvrV2Mtv5JoJVO3PSUQ HTTP/1.1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534+ (KHTML, like Gecko) BingPreview/1.0b
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Host: wintows.com
Connection: keep-alive

Подведём итог

Нас не должно удивлять, что сервис NTP, работающий на всех машинах c Windows в мире, использующий в стандартной конфигурации time.windows.com, генерировал больше всего трафика, вызванного инвертированием битов. Я по-прежнему получаю кучу трафика. Больше всего меня удивило то, сколько трафика я получал от доменов, ошибочно указанных пользователями при вводе URL.

Выводы:

Битсквоттинг домена с большими объёмами трафика — по-прежнему очень практичная в реализации атака.
Интегрированные в ОС автоматизированные сервисы создают много битсквоттингового трафика.
Пользователи по-прежнему часто делают опечатки в именах доменов.

На правах рекламы

VDSina предлагает VDS с посуточной оплатой. Возможно установить любую операционную систему, в том числе из своего образа. Каждый сервер подключён к интернет-каналу в 500 Мегабит и бесплатно защищён от DDoS-атак!

Теги:

Хабы: