[Информационная безопасность, Администрирование доменных имен, DNS] Битсквоттинг сайта Windows.com (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Недавно я вернулся к мысли о возможности совершения битсквоттинга. В статье по ссылке эта тема рассматривается очень глубоко, поэтому здесь я объясню в очень общих чертах:
Когда вы пытаетесь получить доступ к сайту по его домену, этот домен хранится в памяти вашего компьютера, устройства и т.д. в структуре, выглядящей примерно так:
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-атак!
оригинал
===========
Источник:
habr.com
===========
===========
Автор оригинала: Remy
===========Похожие новости:
- [Высокая производительность, Системное администрирование, Разработка под Windows] Win 10 Tweaker — быстрая оптимизация Windows в несколько кликов. Но не всё так радужно
- [Perl, Информационная безопасность, Open source, DNS] Угон домена Perl.com (перевод)
- [Информационная безопасность, IT-компании] Microsoft заявила, что Китай взломал Exchange; государственные органы США издали срочное предупреждение
- [Настройка Linux, Информационная безопасность, Разработка под Linux] Для загрузчика GRUB2 выпустили 117 патчей, чтобы устранить опасные уязвимости
- [Информационная безопасность] Как ходить к соседям без звонков в домофон
- [Информационная безопасность, IT-инфраструктура, История IT, Софт] История программ для удалённого доступа (перевод)
- [Информационная безопасность] (не)Безопасный дайджест: потерянные миллионы и телефонные мошенники
- [Информационная безопасность, Google Chrome, Контекстная реклама, Повышение конверсии] Google больше не будет отслеживать пользователей для показа персонализированной рекламы
- [Сетевые технологии, Стандарты связи] Суверенный DNS уже здесь, а вы и не заметили
- [Настройка Linux, Информационная безопасность, Исследования и прогнозы в IT] Уязвимости неуязвимого Linux
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_administrirovanie_domennyh_imen (Администрирование доменных имен), #_dns, #_bitskvotting (Битсквоттинг), #_ataka (атака), #_bezopasnost (безопасность), [url=https://torrents-local.xyz/search.php?nm=%23_blog_kompanii_vdsina.ru_—_hosting&to=0&allw=0&o=1&s=0&f%5B%5D=820&f%5B%5D=959&f%5B%5D=958&f%5B%5D=872&f%5B%5D=967&f%5B%5D=954&f%5B%5D=885&f%5B%5D=882&f%5B%5D=863&f%5B%5D=881&f%5B%5D=860&f%5B%5D=884&f%5B%5D=865&f%5B%5D=873&f%5B%5D=861&f%5B%5D=864&f%5B%5D=883&f%5B%5D=957&f%5B%5D=859&f%5B%5D=966&f%5B%5D=956&f%5B%5D=955]#_blog_kompanii_vdsina.ru_—_hosting (
Блог компании VDSina.ru — хостинг
)[/url], #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_administrirovanie_domennyh_imen (
Администрирование доменных имен
), #_dns
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:44
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Недавно я вернулся к мысли о возможности совершения битсквоттинга. В статье по ссылке эта тема рассматривается очень глубоко, поэтому здесь я объясню в очень общих чертах: Когда вы пытаетесь получить доступ к сайту по его домену, этот домен хранится в памяти вашего компьютера, устройства и т.д. в структуре, выглядящей примерно так: 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-атак!  оригинал =========== Источник: habr.com =========== =========== Автор оригинала: Remy ===========Похожие новости:
Блог компании VDSina.ru — хостинг )[/url], #_informatsionnaja_bezopasnost ( Информационная безопасность ), #_administrirovanie_domennyh_imen ( Администрирование доменных имен ), #_dns |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:44
Часовой пояс: UTC + 5