[Перевод] Битсквоттинг сайта Windows.com
Недавно я вернулся к мысли о возможности совершения битсквоттинга. В статье по ссылке эта тема рассматривается очень глубоко, поэтому здесь я объясню в очень общих чертах:
Когда вы пытаетесь получить доступ к сайту по его домену, этот домен хранится в памяти вашего компьютера, устройства и т.д. в структуре, выглядящей примерно так:
Теперь представим, что компьютер перегрелся, произошла вспышка на Солнце или космический луч (вполне реальная штука) инвертировал в компьютере значение одного бита.
О нет! Теперь в памяти хранится значение
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 -uSep 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-CNGET / 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(0×27000E37) 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:
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-атак!
