Привет, это техотдел Роскомсвободы. Мы решили запилить свой канал об информационной безопасности, приватности, анонимности и свободе слова в России и в мире. Здесь мы хотим писать о событиях, которые нас интересуют, с технической точки зрения и с техническими подробностями, и хотим, чтобы этот канал полюбили айтишники. Если у вас есть идеи и отзывы по формату и темам, пишите в личку, будем обсуждать.

Поехали!

«Бывший сотрудник с доступами смог скачать логи почтового сервера»

Леонид Волков в эфире "Дождя" прокомментировал, как случилась утечка базы имейлов подписчиков сайта "Свободу Навальному!". Волков говорит, что данные украл бывший сотрудник, у которого после увольнения не забрали доступ к логам почтового сервера, и атакующие собрали имейлы из почтовых логов, а других персональных данных там просто не было.

Почтовый сервер - это сервис Mailgun, который использовался на сайте для рассылки имейлов подписчикам, и который позавчера комментировал РБК, что сломали не их. "Наша команда выяснила, что для доступа к данным с нашей платформы были использованы действительные API-ключи и учетные данные пользователя."

То есть версии, например, такие:

• атакующий влез в контрольную панель Mailgun при помощи валидной учетки;
• атакующий забрал логи с Mailgun по API при помощи валидного ключа;
• админы сайта куда-то еще в другое место выгружали эти логи и их украли уже оттуда;
• данные логировали на сервере еще до отправки через Mailgun.

Пока непонятно. Будем ждать более подробного отчета об инциденте, который обещает Волков. Из других технических подробностей известен самой размер базы (529 тысяч адресов имейл с диапазоном дат с 22 марта по 2 апреля 2021 года) и домен, с которого атакующие рассылали сообщения подписчикам сайта (navalnyfail.online, зарегистрирован на reg.ru 15 апреля этого года, MX-запись у них на сегодня - emx.mail.ru, это доменная почта на Mail.ru).

А еще "Дождь" пишет, что их корреспондент сегодня ночью получил от организаторов слива второе письмо, где были его личные данные: дата рождения, ФИО и адрес регистрации. Возможных объяснений много (например, персональные данные к имейлу нашли по открытым источникам и разослали нескольким "важным" людям типа корреспондентов "Дождя"), но информации для надежной гипотезы мало.

"Коммерсантъ" сегодня пишет, что открытые данные российских компаний "оказались" в открытом доступе, потому что эти компании держали их на публичных досках Trello. А по факту эти компании или их сотрудники сами положили свои данные в открытый доступ, когда поменяли выбранную в Trello по умолчанию настройку доски "Рабочее пространство" на "Публичную", а потом Google это все проиндексировал, потому что у него работа такая. А ребята из Infosecurity, которые поговорили с "Коммерсантом", похоже, почитали этот старый материал секьюрити блогера Брайана Креббса или этот совсем старый материал на Медузе и тоже решили попробовать искать в Гугле что-то типа:

inurl:trello.com 'название компании и другие интересные ключевые слова'.

Что тут сказать, если у вас есть секреты, не выкладывайте их в открытый доступ. В Trello у каждой доски есть настройка "Изменение видимости", и, если вы держите в этом сервисе конфиденциальные данные, сегодня отличный день, чтобы ее проверить.

Разработчик защищенного мессенджера Signal Мокси Марлинспайк выпустил второй пост о том, как устроена программа израильской фирмы Cellebrite, которая поддерживает извлечение данных из Signal. Он рассказывает, что шел по улице, а тут программно-аппаратный комплекс Cellebrite прямо перед ним упал с грузовика, а он его нашел и исследовал. Ну и в посте он над израильтянами издевается, потому что в их программе дырявый ffmpeg 2012 года и, предположительно, использованный без разрешения код Apple.

А еще он объясняет, что "поддержка Signal" Cellebrite-ом - это не удаленный взлом шифрования или доступ к данным, то есть израильтяне вообще ничего не взломали, и эту штуку не может использовать ваш сотовый оператор или провайдер где-нибудь у себя. Их программа, которая называется Physical Analyzer, анализирует незашифрованный файл резервной копии смартфона на Android или IOS, то есть для работы ей вначале нужен физический доступ к разблокированному телефону или незашифрованному бэкапу. Если есть такой доступ, говорит Мокси, можно было бы просто открыть Signal на этом телефоне и делать скриншоты чатов, и программа Cellebrite просто автоматизирует эту работу - достает данные Signal из бэкапа сразу в красивом читаемом виде, потому что каким-нибудь правоохранителям это удобно.

Мокси, должно быть, было очень неприятно, когда СМИ в декабре прошлого года начали писать, что израильские хакеры взломали Signal. Теперь он рассказывает пользователям Signal, чего действительно стоит опасаться, а чего нет, и заодно портит репутацию Cellebrite в глазах потенциальных клиентов.

С начала недели новый вирус-вымогатель Qlocker шифрует данные на сетевых хранилищах NAS производителя QNAP.

История интересна тем, что это - реальный вымогатель "из говна и палок": программисты в его создании, похоже, вообще не участвовали. Его авторы прочитали описание уязвимости на официцальном сайте, поняли, как она устроена, сравнив последнее вышедшее обновление безопасности с предыдущей версией, нашли чем-нибудь типа поисковой системы Shodan.io IP-адреса устройств QNAP, к которым есть доступ из интернет (на сегодня их там 9000+), "натравили" на эти адреса скрипт (уязвимость это sql-инъекция, поэтому в принципе мог подойти стандартный sqlmap), и, если взлом удался (а значит, если пользователь еще не установил последнее обновление), положили на устройства текстовый файл с требованием заплатить, и запустили шифровать данные стандартным архиватором 7zip с паролем!!!

Несмотря на простое устройство вымогателя, на сегодня уже больше 500 человек заплатили им выкуп по 0.01 BTC, то есть в общем это около $260 000. А вчера QNAP выпустил инструкцию, как расшифровать данные, и она такая же нехитрая, как и сам вымогатель. Пользователям предлагается при помощи стандартной в linux команды ps найти на устройствах процесс, который шифрует файлы, и скопировать пароль из найденной строки типа:

"/usr/local/sbin/7z a -mx=0 -sdel -pCcrP7PCP1euF0MBjD2C866YYi388m9jD"

Эта история - пример очень распространенного сейчас способа взлома: злоумышленники следят за вышедшими обновлениями ПО, выясняют, что изменилось, и атакуют тех, кто не обновился. Мораль простая: чем быстрее вы установили обновления безопасности, тем меньшее время вы уязвимы. Ну и да, бэкапить важные данные по-прежнему обязательно, а устройства, к которым есть доступ из интернет, иногда ломают.

Пару недель назад компания Traced.app выпустила отчет о сайтах и приложениях, которые позволяют отслеживать, когда у других пользователей открыт Whatsapp, и таким образом за ними следить. Речь идет не о "большом Брате", а скорее о слежке за супругами и партнерами, и о том, что называется "сталкинг". А сегодня на Хабре вышел перевод материала, как написать такую систему самому.

Идея там такая: в Whatsapp есть настройка, кому пользователь хочет показывать свое время последнего посещения. А еще есть статус Онлайн, который виден всей сети, и чтобы его проверять, вообще не нужно быть в контактах у пользователя. У Whatsapp в FAQ написано, что это не баг, а фича: "Имейте в виду, что скрыть статус «в сети» невозможно." И Whatsapp никак не мешает одним пользователям массово проверять статус других: исследователь, который написал оригинал статьи с Хабра, в течение месяца непрерывно проверял онлайн статус 5000 пользователей с одного аккаунта, и ничего.

В результате можно загуглить что-то вроде Whatsapp status check, скачать готовую программу на смартфон или пойти на сайт, вбить туда телефон пользователя, и потом накапливать информацию о том, в какие промежутки времени у того было открыто окно Whatsapp, а потом делать выводы, когда он лег спать, вышел с работы и так далее. А еще есть готовые приложения, которые за деньги умеют делать то же самое для пары пользователей, чтобы можно было подтвердить гипотезу, переписываются ли они между собой. В отзывах пишут, помогло уличить кого-то там в измене. Защитники приватности говорят, что это способ слежки и надо такие аппы и сайты запрещать, и жалуются в Google и Whatsapp, но приложения по прежнему есть в магазинах и по-прежнему работают.

Современные способы слежки часто основаны как раз на анализе метаданных, то есть не содержания разговоров, а дополнительной служебной информации, например о том, кто, когда, с кем говорил. У мессенджеров чаще обсуждают шифрование, но у Whatsapp и Signal математика шифрования вообще одинаковая, а метаданные они защищают и противодействуют слежке по-разному: у Signal вообще нет статуса онлайн и информации о времени последнего посещения.

Два дня назад закончилась история ботнета и малвари Emotet, перехваченного у хозяев в результате международной спецоперации. В январе киберполицейские перехватили у хозяев ботнета центры управления их сетью, а потом разослали обновление, которое 25 апреля в полдень удалило малварь со всех зараженных компьютеров. А сегодня владелец известного сервиса проверки взломанных аккаунтов https://haveibeenpwned.com Трой Хант пишет, что ФБР отдало ему 4.3 миллиона имейлов, логинов и паролей, которые использовались для распространения этой малвари, либо хранились сохраненными в браузерах на зараженных машинах, чтобы он помог уведомить владельцев аккаунтов.

В отличие от основного массива данных на HaveIBeenPwned, эти данные совсем свежие, там могут могут быть даже январские пароли, поэтому в общую выдачу на сайте они не попадают и по API не выдаются. Но можно проверить себя через их сервис подписки https://haveibeenpwned.com/NotifyMe, где надо сначала подтвердить, что email - реально твой, либо проверить пользователей своих доменов через интерфейс для админов https://haveibeenpwned.com/DomainSearch.

Обычно безопасникам Dehashed.com интереснее, чем HaveIbeenPwned: у первых все за денежку, но Dehashed выдают в поисковой выдаче сами пароли или их хеши. Но тут особенный случай: январская утечка, данные собраны малварью из браузеров, поэтому пароли могут быть от разных сервисов, и пока проверить можно только на HaveIBeenPwned или на сайте полиции Нидерландов.

В общем, самое время подписаться на рассылку обновлений о своих email адресах https://haveibeenpwned.com/NotifyMe, если вы еще не подписаны.

Коммерсантъ сегодня пишет, что сайты десятков российских банков на стандартной CMS "1С-Битрикс" имеют уязвимость, которая позволяет злоумышленникам использовать ссылки с открытыми редиректами типа https://bank.ru/redirect.php?goto=https://rublacklist.net Безопасники из компании StopPhish взяли с сайта ЦБ список из 358 банков, прошлись скриптом по всем сайтам, из них 140 работают на "1С-Битрикс", а 27 поддерживают открытые редиректы. Идея в том, что злоумышленники могут делать такие ссылки, рассылать их пользователям, и пользователи будут по ним переходить на фишинговые сайты, потому что их научили сначала проверять домен в ссылках, а домен правильный.

Вот здесь казахские айтишники обсуждали эту же проблему у казахского банка в 2015 году. А история с редиректами касается не только банков, а всех сайтов на этой CMS, которых в российском интернете около 13.4%. В админке "1С-Битрикс" есть настройка "Защита редиректов", у кого она отключена, у того такие редиректы работают, причем в последней версии она включена по умолчанию. На форумах пишут, что пару лет назад по умолчанию все было выключено, клиенты жаловались, а техподдержка предлагала включать.

Ну что, если вы пользователь - проверяйте ссылки не только до перехода по ним, но и после)) Если вы админ "1С-Битрикс" и редиректы для вас вообще проблема - лезьте в админки проверять, и, кстати, убедите клиентов продолжать покупать обновления безопасности, которые у Битрикс платные по подписке. А если вы безопасник - это история о том, как безопасность продукта определяется не возможностями его настраивать, а тем, как разработчик выбрал настройки по умолчанию пять версий назад.

Bi.zone, дочка Сбербанка в сфере кибербезопасности, поговорила с РБК о статистике, как у их российских клиентов ломают аккаунты. На первом месте (46%) перебор паролей по словарю и последствия использования одинаковых паролей в разных сервисах, а на втором (34%) - фишинг, то есть вместе эти два способа дают 80% инцидентов.

Проценты немного странные, потому что всего четыре способа атак (атаки на пароли 46% + фишинг 34% + уязвимости ПО и сервисов 17% + инсайдерские атаки 3%), вместе дают 100%. Но это все-таки РБК, так что похоже, что в основе этого материала лежит настоящая статистика инцидентов, а не просто марекетинговая брошюра. Тогда это - ценная информация о том, что сейчас наиболее вероятно "в среднем по больнице". А дальше есть немного пользователей, которые понимают про себя, что их ситуация особенная и их угрозы другие. И есть очень и очень много пользователей, для которых в этом материале говорится примерно следующее:

Хочешь примерно в четыре раза снизить риск взлома своих аккаунтов?
• Используй для важных аккаунтов сложные уникальные пароли (снижает риск почти вдвое).
• Разберись, что такое фишинг и настрой двухфакторную (снижает риск на треть).

Google собирается автоматически включать двухфакторную аутентификацию в уже зарегистрированных аккаунтах, в которых она не включена, и которые для этого "правильно сконфигурированы".

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

• у пользователя должны быть компьютер и смартфон, которые привязаны к одному и тому же аккаунту,
• смартфон должен быть либо Android (и тогда он умеет показывать их дефолтный Google Prompt/Уведомления от Google) либо iPhone c установленными приложениями, которые умеют показывать эти уведомления (то есть Поиск Google, Gmail или Google Smart Lock)
• и привязанный телефонный номер на который можно прислать одноразовые коды - Google обычно хочет два способа двухфакторной.

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

Это называется "феодальная безопасность" и ее в усложняющемся мире все больше (на английском про нее много пишут, а на русском мало, но вот, например). Идея в том, что пользователи не умеют хорошо защищать себя сами, и поэтому доверяют компаниям свои секреты и разрешают на себе зарабатывать, а компании в ответ берут на себя ответственность обеспечивать их защиту.

Исследователь безопасности nusenu выложил исследование о том, как выходные узлы сети Tor атакуют трафик пользователей. Если вкратце, единственный "нарушитель безопасности" в некоторые моменты контролирует до 27.5% выходных узлов всей сети Tor, потом эти узлы блокируют, а он добавляет новые и их количество на пике снова доходит до примерно 25%. В среднем за последний год таких выходных узлов в сети было примерно 14%. Этот кто-то использует email “Андрей Гвоздев <[email protected]>” и зарегистрирован в базе данных RIPE с московским адресом.

"Плохие" выходные узлы занимаются тем, что пытаются расшифровывать SSL трафик пользователей при помощи стандартных утилит mitmproxy и sslstrip. В предыдущем исследовании nusenu рассказывал, что атакующий делает это в основном для того, чтобы заменять адреса bitcoin кошельков для вывода на биржах криптовалюты. То есть пользователь заходит на биржу через Tor browser, ему достается "плохой" выходной узел, который пытается расшифровать его SSL соединение, пользователь соглашается с предупреждением браузера, что с его SSL что-то не так, или просто заходит на криво настроенный сайт биржи в http-режиме, покупает крипту, а она потом уходит в другое место.

В августе в прошлой версии исследования nusenu предложил, что могла бы поменять сама сеть Tor, чтобы защитить пользователей от таких узлов. Убедить разработчиков ему пока не удалось, а со всеми операторами бирж насчет настройки HSTS тоже не договоришься, поэтому сейчас он советует пользователям защищаться самим. Список рекомендаций исследователь не дает, обещает отдельный пост, но стандартные способы защиты от подобных атак это:

• Проверяйте, что сайт открывается в https.
• Не игнорируйте предупреждения браузера о том, что с сертификатом сайта что-то не так.
• Используйте расширения для браузера типа HTTPS Everywhere.

Лаборатория Касперского пишет, что на 36% компьютеров в России до сих пор стоит Windows 7. Если это правда, то это просто трэш, это миллионы машин, которые уже год не получают обновления безопасности через Windows Update. Понятно, что большая часть этих машин спрятаны за NAT своих роутеров хотя бы от удаленных атак, но вот навскидку поисковая система Шодан видит 3000 компьютеров из RU с торчащим в интернет протоколом удаленного управления RDP. А люди на "семерках" еще же файлы запускают!

Наверное есть какие-то способы (как был BypassESU) автоматом продолжать получать платные Microsoft-овские обновления безопасности для "семерки", которые будут выходить до 2023 года, или выкачивать обновления из Microsoft-овского каталога и ставить их руками. Но скорее всего большая часть из этих 36% - это просто непатченные машины, и из них куча странных "сборок" и компьютеров с отключенными обновлениями. А истории с уязвимостями типа EternalBlue и Bluekeep показывают, что выживает тот, кто может вовремя обновиться, а у пользователей "семерки" простой возможности делать это больше нет.

Понятно, зачем Microsoft сделал обновления почти неотключаемыми в Windows 10, и перешел на систему с крупными обновлениями два раза в год вместо новых версий.

На нашем сайте вышел материал о том, что ФСБ предлагает создать международную систему хранения ключей шифрования мобильных приложений, чтобы бороться с терроризмом.

Немного контекста: эта идея время от времени всплывает у нас в России, но это не только российская история. На английском эта проблема называется key escrow, и в последние пару десятилетий она обсуждается не только политиками в России, Великобритании и США, которые считают, что надо, чтобы гражданские опять не могли шифроваться от государства, как в старые добрые времена. Криптографы тоже думают, а как такое вообще сделать, и на сегодня хорошего практического решения просто нет.

Отношение сообщества к проблеме описывает коммент известного криптографа Мэтью Грина по поводу очередной такой инициативы в США в 2018 году: "Немногие из нас поддерживают идею масштабной системы хранения ключей шифрования потому, что мы думали об этом и мы считаем, что это не сработает. Мы взвесили модель угроз, модель использования и качество современного "железа" и ПО. Мы считаем, что не существует системы обнаружения кражи ключей, нет системы их обновления, криптографические модули ужасно небезопасны (и в компаниях [которые их производят] сплошь работают бывшие разведчики), и возможны инсайдерские атаки. Мы не готовы помещать данные нескольких миллиардов человек в такую систему, которая с большой вероятностью может отказать" (ссылка).

Даже если криптографы придумают достаточно хорошее решение, у подобных идей нет никакого опыта успешной имплементации, а есть только куча фейлов. Например, в середине 90-х американцы пробовали внедрить технологию, которая называлась Клиппер Чип, и ничего не вышло. Казахстан последние лет пять пробует внедрить "национальный сертификат безопасности" (а это система гораздо проще, это просто атака "человек-в-середине" на SSL), и тоже пока на уровне страны не получается. И так далее.

В общем, государства давно мечтают забрать у людей криптографию, но пока это просто мечты.

В России по решению суда сегодня заблокирован 4pda.ru, у нас на сайте вышел материал с подробностями. Сейчас открывается через VPN или на новом домене 4pda.to. Ответчиком в судебном процессе был не сам 4pda, а сервис по защите от DDoS-атак Cloudflare, которым в режиме обратного прокси пользуется 4pda и еще примерно 7.6 миллионов сайтов, поэтому владелец самого ресурса не был стороной в деле и не мог обжаловать решение. Типа пользователи заходили на IP-адреса Cloudflare, поэтому сервис создавал технические условия распространения.

У сайтов есть несколько традиционных вариантов решения проблемы блокировки и 4pda сделал вполне рациональный выбор:

• Спрятаться "за спиной" кого-нибудь большого, кого не станут блокировать, как, например, сделал Грани.ру со своим зеркалом на Appspot. (https://grani-ru-org.appspot.com/).
• Разделить разные части сайта на разные домены, как, например, сделал белорусский портал Tut.by, который вынес все обсуждения на отдельный домен Talks.by, а то вдруг пользователи что-нибудь напишут, а потом весь сайт заблокируют за распространение.
• Рассчитывать, что пользователи сами найдут способ обходить блокировки и будут приходить через Tor, VPN и прокси-сервера.
• Регистрировать новый домен и сообщать об этом пользователям, как это сегодня сделал 4pda.

Помните, как недавно Signal "бодался" с израильской компанией Cellebrite, которая производит программно-аппаратные комплексы для анализа изъятых телефонов?

Теперь Matt Bergin представил (pdf) на конференции Black Hat Asia результаты своего анализа функционала того же продукта Cellebrite UFED для сбора доказательств со смартфонов и концепт утилиты LockUp, которая может этому противодействовать. Программно-аппаратные комплексы Cellebrite разных версий исследователь купил на ebay, они там продаются. А его утилита отслеживает попытки считать данные через через USB-шнурок теми способами, которыми это делает Cellebrite, и сбрасывает смартфон к заводским настройкам.

Утилита не предназначена для серьезного использования, она написана в качестве идеи для других людей, которые пишут софт для повышения безопасности смартфонов. В этой истории интересно другое. Если Мокси Маклинспайк из Signal подавал историю с уязвимостями Cellebrite как "вы нас ломаете, мы вас взломаем", то Matt Bergin явно делает акцент на том, как недостатки конкретного продукта Cellebrite делают результаты анализа непригодными для использования в суде, хотя американские суды их сейчас принимают. Понятно, что правоохранители и дальше будут изымать смартфоны и им нужно будет скачивать с них файлы и анализировать, и понятно, что сейчас Cellebrite постарается "допилить" недостатки своего продукта. В прошлый раз после известного поста Signal исправления вышли чуть ли не в течение недели (хотя те, предыдущие проблемы были гораздо проще, там были просто старые версии библиотек). Суть в том, что хакеры берут на себя функцию общественного контроля, чтобы кто-то в обществе понимал, что вообще делают правоохранители и как, и например, чтобы при помощи этих продуктов нельзя было недоказуемо подложить или изменить файлы на телефоне.

Опубликована новая красивая атака на анонимность пользователей браузеров от команды FingerprintJS.

В чем идея: базовый способ следить за тем, куда пользователь ходит в интернете, - это отслеживающие cookie. Кроме этого у сайтов есть возможность собирать кучу технической информации из браузера пользователя и создавать из нее "цифровой отпечаток", который получается уникальным, потому что разной информации много (проверить себя можно здесь). Но как сайт может понять, что Chrome и Firefox принадлежат одному и тому же пользователю? Для этого исследователи из FingerprintJS придумали взять 32 популярных приложения, у которых есть свои собственные ссылки типа skype://, steam://, zoom://, и открывают их со стороны "плохого" сайта в новых окнах javascript-ом по очереди. Если приложение установлено, браузер рисует окошко с вопросом, надо ли его открывать, и сайт это фиксирует. В результате сайт понимает, какие из 32 приложений установлены у пользователя (если пользователь этому активно не противодействует, например, запрещая javascript), и этого часто достаточно для сопоставления разных браузеров, пишут, точность 90% с маленьким хвостиком. FingerprintJS сдали результаты своего исследования разработчикам популярных браузеров, скоро те что-нибудь придумают.

Атаку тестировали и она пока что работает в этих браузерах.

• Chrome 90 (Windows 10, macOS Big Sur)
• Firefox 88.0.1 (Ubuntu 20.04, Windows 10, macOS Big Sur)
• Safari 14.1 (macOS Big Sur)
• Tor Browser 10.0.16 (Ubuntu 20.04, Windows 10, macOS Big Sur)
• Brave 1.24.84 (Windows 10, macOS Big Sur)
• Yandex Browser 21.3.0 (Windows 10, macOS Big Sur)
• Microsoft Edge 90 (Windows 10, macOS Big Sur)

Демка здесь: https://schemeflood.com/, работает только на десктопе, можете себя проверить.

Компания Cloudflare думает, чем бы заменить свою CAPTCHA, потому что она всех достала, занимает 32 секунды, каждый пользователь интернет в среднем решает ее раз в 10 дней, у Cloudflare - 7.6 миллиона сайтов-клиентов, в общем годы времени и геморроя. В их официальном блоге вышел пост, где предлагается использовать вместо капчи USB ключи U2F, работающие по протоколу FIDO, типа пользователь пришел на страницу с челленджем, вместо CAPTCHA нажал на кнопку своего USB ключа и таким образом доказал, что он не робот. Тестовая страница выложена на https://cloudflarechallenge.com/, если у вас есть U2F ключ, сходите протестировать. Другие сервисы, например Google и Facebook, уже используют такие ключи как способ двухфакторной аутентификации, поэтому у людей на руках они уже есть, а еще поддержку FIDO начинают встраивать прямо в устройства, например, в телефоны.

Похоже, что Cloudflare опубликовала эту идею, чтобы таким образом обсудить ее с исследователями безопасности, которые "шарят" в проблеме, и исследователи отвечают, что это плохая идея. Вот отличный пример аргументированного ответа. Основной тезис в том, что стандарт U2F просто не решает проблему, которую сносно решает CAPTCHA, - как отличить человека от робота. U2F - отличное решение, но другой проблемы - как доказать сервису, что у пользователя есть доступ к физическому объекту, ключу. Кроме этого:

• Нажатия ключа легко автоматизировать, например, при помощи Arduino.
• Можно сделать так, чтобы всплывающее окно U2F не показывалось в браузере, чтобы легче было автоматизировать процесс.
• Один ключ можно нажимать 30 раз в минуту. В посте приводится базовый расчет стоимости "фермы" из ключей, которые будут обходить такой аналог CAPTCHA с производительностью 20 000–40 000 попыток в минуту.
• При использовании ключей возникает небольшая проблема приватности: партии по 100 000 (или меньше) ключей используют один и тот же сертификат, а поскольку со стороны сервера, как правило, сидит Cloudflare, пользователь перестает быть таким же анонимным, как после решения CAPTCHA.

И так далее. В общем, идея избавиться от CAPTCHA - правильная, а решение пока что так себе.

Ардуинка нажимает ключи U2F, доказывая Cloudflare, что она не робот.

В Беларуси заблокирован мегапопулярный там портал tut.by, в редакцию приходили силовики, у нас об этом вышел материал с подробностями. Основной сайт не работает, работающее сейчас зеркало - https://www.tutby.news/.

В этой истории есть интересный момент: сервера Tut.by держал на площадке "Белтелекома" в Минске. Почему? Помимо очевидного ответа про скорость доставки контента до пользователей, есть еще один ответ: существует указ президента Беларуси №60 от 2010 года, по которому сайты, обслуживающие "деятельность по реализации товаров, выполнению работ, оказанию услуг на территории Республики Беларусь", то есть, которые, например, крутят белорусскую рекламу и берут за нее деньги, должны быть физически размещены в Беларуси. Это позволяет государству действовать не как в России, где сайты можно хостить за рубежом, а потом РКН блокирует их для россиян "снаружи-внутрь", а наоборот - позволяет государству блокировать "изнутри-наружу", из Беларуси для всех.

По факту мелкие сайты этот указ игнорируют, хитрые сайты держат в Беларуси обратные прокси-сервера, а фактический хостинг где-нибудь в Германии, где он бывает быстрее и дешевле, а крупные сайты часто выбирают подчиняться и держать хостинг в Беларуси. При блокировке последним приходится сложнее, поэтому надо заранее готовиться и держать под рукой рабочее зеркало. Судя по тому, как быстро Tut.by его поднял сегодня, их техслужба к этому сценарию была готова.

Google представил Android 12 c новыми функциями защиты приватности. Главное, что там появилось:

• Privacy Dashboard - список того, какие приложения получали доступ к геолокации, камере и микрофону за последние 24 часа.
• Системная иконка уведомления, когда приложение использует доступ к камере и микрофону.
• Возможность предоставлять приложению не точную, а примерную геолокацию.
• Окно запроса, когда одно приложение хочет читать буфер обмена другого.

Ничего революционного, но все потенциально полезное.