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

Автор оригинала: Remy
  • Перевод


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

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

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-атак!

VDSina.ru
Серверы в Москве и Амстердаме

Комментарии 30

    +5
    Мне кажется или это не совсем битсквотинг? Вернее, такого же результата можно было добиться, зарегистрировав все возможные варианты ошибочного набора домена (а не только те, которые отличаются одним битом)? Даже больше можно было бы отловить. Раз уж к концу статьи разговор пошел именно о том, что кто-то из Facebook ошибся при вводе. Он же не в двоичной системе набирал адрес. Если я правильно понял, битсквотингом отлавливают легитимные запросы, в которых при передаче по сети был изменен бит. А не ошибки ручного набора домена.
      +4
      Некоторые запросы — да. Но для NTP time.windows.com это адрес по умолчанию, вряд ли его вбивали ручками, а если и вбивали то очень малое количество пользователей.
        0
        Возможно потому у них время и сломано, так как адрес именно вбили руками по какой-то причине.
          0
          А если ещё учесть что panic threshold в 1000 секунд никто не отменял, так ещё и ручками надо NTP заставить синхронизировать такие отклонения.
      +3
      Существует очень малое количество способов, которыми Baiduspider мог бы узнать о существовании time.wiodows.com. Особенно учитывая, что ранее к этому домену был выполнен только один запрос (показанный выше).

      ИМХО тут только один вариант: у того самого пользователя стоит поисковик/плагин Байды, который сливает производителю все запросы пользователей для последующей индексации неизвестных ему URL. Старая, но от этого не менее чудесная история, как были проиндексированы разделы различных сайтов типа ДСП, которое обеспечивалось лишь «секретным» URL ;)
        +2
        Пых. В РБ есть одна контора, которая торгует документацией(ГОСТы и т.п.). У них ссылки на скачивание купленного документа раньше выглядели как domain/secret(sic!)/filename и никак не защищались. Забавно то, что имя файла можно было получить из превью документа.
          0
          Имя, сестра, имя! Адрес, коллега, адрес! ГОСТы ж не только в РБ действуют… ;)
            0
            Уже прикрыли)) Пару лет как.
              0
              Печаль… а не успел ли кто-нибудь выкачать и выложить?
                0
                Не знаю, честно говоря. В Беларуси существует сеть бесплатных библиотек, где эти документы можно почитать в бумажном виде, так что врядли кто-то сильно загонялся.
                  0
                  В любом ЦПИ или в определенных «технических» библиотеках? Просто интересно. У нас ГОСТы в сеть выложены, но в «удобном» графическом виде с защитой от скачивания (ха-ха), но цитировать все равно неудобно. Мы тут любим текстовой PDF выкладывать, если кто добыл ;)
                    0
                    В Беларуси есть т.н. ЦСМ — Центры Стандартизации и Метрологии. У таких центров, как правило, есть свои библиотеки, куда можно прийти и почитать ГОСТы. Но, если надо сделать копию, то это уже платно)) Бесплатно у нас только штрафуют за нарушения))
            +1
            Эх, как в старые добрые времена, 20 лет назад почти весь рунет был таким
          +3
          Подстановочные DNS работают следующим образом: я создаю запись

          Это вообще-то называется wildcard домен
            0
            Видно с 2011 года ничего не изменилось.
            DEFCON 19: Bit-squatting: DNS Hijacking Without Exploitation
              +15
              Пахнет лапшой на уши. Ошибки памяти, конечно, иногда бывают. Только на одно удачное попадание windows.com -> whndows.com будет 10005000 случаев крэшей, бсодов, порч важных данных. Если бы биты флипались в памяти направо и налево, компьютеры бы вообще не загружались и не работали.
                +3
                Плюсую. То-же самое хотел сказать. Это скорей всего не ошибки памяти а опечатки при вводе адреса или опечатки в конфиге.
                Вероятность того, что прям в момент захода на сайт возникнет ошибка памяти, да не где попало а именно в том месте, где хранится введённое имя хоста — бесконечно мала. Ну ещё может быть ошибка чтения/записи диска. Ошибки TCP корректируются за счёт контрольных сумм.
                  0

                  Данные портятся не в памяти, а при передаче по сети. Многие реализацию игнорят проверку чексуммы payload-а UDP пакета, и проверяют только чексуммы IP заголовков. А получить пару порченных бит в нужном месте при передаче по сети — вполне вероятная вещь.

                    +4
                    А??? Какая такая checksum от payload?? Вы её откуда придумали? А вот у всего l2 пакета контрольная сумма есть и не только сетевые устройтсва, но и адаптер не примет пакет с неверной контрольной суммой. Есть конечная вероятность что «побьётся» битик payload и ещё битик в контрольной сумме пакета, да так, что для нового пакета сумма сойдётся, но вероятность не сильно от нуля отличается. Забудьте про ошибки при передаче по сети. И не пишите глупости.
                      0

                      RFC 768:


                      Checksum is the 16-bit one's complement of the one's complement sum of a
                      pseudo header of information from the IP header, the UDP header, and the
                      data, padded with zero octets at the end (if necessary) to make a
                      multiple of two octets.
                        +2
                        Ну а вы что написали? «многие реализации игнорят проверку чексуммы payload и проверяют только чексуммы заголовка» А теперь пишите что нету чексуммы у payload есть общая на заголовок и данные. Я с этим даже и не пытался спорить. Но ещё раз повторю — проверяют чексуммы на уровне транспорта или нет не имеет никакого значения в современном мире езернета. Битый пакет будет отброшен на уровне L2 и в IP стек не попадёт.
                          +1

                          Я написал что проверяется только чексумма IP фрейма, а она покрывает только IP заголовок.
                          Т.е. в UDP пакете мы имеем две контрольных суммы: контрольная сумма в IP заголовке и контрольная сумма в UDP заголовке.


                          На ethernet уровне, на 10gbit и 40gbit как минимум, ethernet фреймы не имеют своей собственной контрольной суммы, так что ethernet адаптер не заметит порченных битов — там где я работаю мы этим активно пользуемся, для некоторых (100% законах) трюков с отправкой пакетов на биржу "раньше всех".

                            0
                            «ethernet фреймы не имеют своей собственной контрольной суммы» это какой 802.? И 40г вы с учётом вашей специфики зря упомянули — ибо вы не должны не знать, что 40г распадается на 4 десятки. С точки зрения конечного хоста это благо, так как позволяет проще по корам трафик раскидывать, а вот для сетевухи строго наоборот, не говоря уж о том что 40г имеет задержку больше чем все остальные реализации (выше гигабита)
                  0
                  199180 подключений по NTP, попробуйте установить старенький NTP с непропатченной уязвимостью get mon list. Можно адрес даже в dns не прописывать, будет гораздо больше
                    0
                    “… В противном случае я придержу их и продолжу сливать деньги...”

                    Антиресно, за какой интервал времени товарищ отлил взад свои «126 долларов»?
                      +1

                      Вряд ли хоть один даже продал. В своё время активно эксплуатировалась тема гомоглифов в доменах. Я провел небольшой ресерч и связался через hackerone с крупнейшеми ресурсами, типа fb, tw, apple, показав им свободные для регистрации варианты их доменов с гомоглифами. Общий знаменатель ответов был такой: ну да, но нам пофиг, не будем же мы покупать все варинаты своих доменов!
                      Как будто пара тысяч долларов в год разорила бы fb, ага. Но реакция была именно такой.

                        0
                        Ну это ж не единственный способ «продолжения слива денег».
                          0

                          А зачем им их покупать? Хоть за две тыщи, хоть за два миллиона

                        0

                        Так если пользователи руками вводят, то ещё больше вариантов опечаток может быть. В разы больше

                          0
                          способов, которыми Baiduspider мог бы узнать о существовании time.wiodows.com

                          На правах паранойи: китайский компьютер с китайской оперативкой из подсети предприятия запросил время с time.wiodows.com, безопасник предприятия удивился и чекнул 80-й порт. Великий фаервол всё записал, а потом по-дружески продал данные Байде. Бывает так?

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое