Тема безопасности сервера Windows не раз поднималась, в том числе и в этом блоге. Тем не менее мне хотелось бы еще раз освежить в памяти старые методы защиты и рассказать о малоизвестных новых. Разумеется, будем использовать по максимуму встроенные средства.

Итак, предположим, что у нас есть небольшая компания, которая арендует терминальный сервер в удаленном дата-центре.

При проектировании любой защиты следует начинать с модели угроз — от кого или чего, собственно, будем защищаться. В нашей типовой конфигурации я буду строить оборону от внешних злобных хакеров, от некомпетентных (а может, и немного злонамеренных) пользователей. Начнем с внешнего периметра обороны— фаервола.

За тобой как за огненной стеной

Во времена Windows 2003 встроенный фаервол представлял собой жалкое зрелище, и в случае невозможности применения сторонних средств приходилось использовать IPSec. Пример такой настройки разобран, например, в материале Secure Windows Servers using IPSec Firewall.

Сейчас, с появлением WFP (Windows Filtering Platform) дела стали получше. В принципе, с этим фаерволом так или иначе сталкивался, наверное, каждый системный администратор Windows, поэтому настройка удаленного доступа к серверу только с определенных IP не должна вызывать затруднений. Я обращу внимание на некоторые «фишки», которые используются редко.

По умолчанию фаервол блокирует все входящие соединения, кроме явно разрешенных, но исходящие разрешает все, кроме явно запрещенных. Политику эту можно изменить, открыв управление фаерволом через wf.msc и выбрав «Свойства».

Настройка фаервола.

Теперь, если мы захотим запретить пользователям терминального сервера выходить с этого сервера в интернет — у нас это получится.

Стоит отметить, что при настройке правил доступа к серверу (входящие подключения) явно создавать правила для исходящего трафика не нужно. В терминах iptables — established и related всегда разрешены.

Для ценителей командной строки настройку фаервола можно производить в контексте netsh advfirewall. Почитать про команды можно в материале «Брандмауэр Windows 7 в режиме повышенной безопасности», я же добавлю, что блокировка входящих и исходящих подключений включается командой:

netsh advfirewall set currentprofile firewallpolicy blockinbound,blockoutbound

Еще одной особенностью фаервола windows является то, что любая программа или настройка меняет его правила без уведомлений. Например, отключили вы все правила на нашем дедике, рядом появился второй, вы сделали между ними локальную сеть, настроили общий доступ и… внезапно у вас включается smb для всех и вся со всеми вытекающими последствиями.

Выхода, по сути, два с половиной (напомню, мы пока говорим только про встроенные средства): регулярно проверять, не изменились ли правила, и использовать старый добрый IPSec или — как по мне, самый разумный вариант — настраивать фаервол групповой политикой. Настройка производится в Конфигурация компьютера — Конфигурация Windows — Параметры Безопасности — Монитор брандмауэра Защитника Windows в режиме повышенной безопасности.

Настройка фаервола групповой политикой.

Также при помощи фаервола windows можно реализовать простой fail2ban. Достаточно включить аудит неудачных попыток входа и при нескольких неудачах подряд блокировать IP источника. Можно использовать самописные скрипты, а можно уже готовые средства, о которых я писал в статье «Как дать шифровальщикам потопить компанию».

Если же встроенного фаервола не хватает и хочется использовать что-то более серьезное, то можно установить стороннее ПО. Жаль, что большинство известных решений для Windows Server — платные. Другим вариантом будет поставить перед сервером роутер. Понятно, что такая установка подойдет, если мы используем colocation, а не аренду сервера где-то далеко-далеко за рубежом. Если же зарубежный дата-центр — это наш выбор, то можно использовать виртуализацию — например, встроенный Hyper-V — и установить в виртуалку привычный GNU\Linux или FreeBSD.

Возникает вопрос: как сделать так, чтоб виртуалка имела прямой выход в интернет, а сервер — нет? Да еще чтобы MAC-адрес сервера не светился хостеру и не требовал тем самым покупки еще одного IP-адреса.

Осторожно! Дальнейшие действия лучше проводить через IP-KVM!

Для этого виртуальную машину нужно снабдить двумя сетевыми адаптерами. Один — для непосредственного подключения к интернету, для него мы сделаем виртуальный коммутатор типа «внешний» и снимем галочку, разрешающую операционной системе взаимодействие с этим коммутатором. Этой самой галочкой мы лишим сервер прямого доступа в интернет (настройку виртуальной машины-фаервола лучше произвести заранее), и его MAC не будет светиться хостеру.

Настройка внешнего виртуального коммутатора.

Другой виртуальный коммутатор следует сделать типа «внутренний» для взаимодействия виртуальной машины и сервера. На нем уже нужно настроить локальную адресацию. Так получится создать виртуальный роутер, стоящий перед сервером и защищающий его.

Заодно на этой виртуальной машине можно настроить любимый VPN до офиса или удаленных сотрудников, не заморачиваясь с ролью «Маршрутизация и удаленный доступ» или со встроенным IPSec, как я рассказывал в статье «Как я базы 1С в Германии прятал». Главное, не забыть проверить автозапуск этой виртуальной машины при старте системы.

Подключаться к такому серверу можно при помощи обычного RDP или использовать HTML5 клиенты с двухфакторной аутентификацией. Стоит на случай брутфорса озаботиться и решениями fail2ban, и блокировкой учетной записи на некоторое время при нескольких неудачных попытках авторизации подряд.

Снаружи сервер мы более-менее защитили, перейдем к защите внутренней.

Защита внутренняя: остановить и не пущать

Конечно, для защиты сервера изнутри очень хочется поставить какой-нибудь антивирус — мало ли что пользователи сервера накопируют или накачают из интернета. Но на практике антивирус на сервере может принести больше вреда, чем пользы. Поэтому я обычно использую механизмы блокировки запуска ПО не из белого списка — в частности, механизм SRP (software restriction policies), о котором я тоже упоминал в статье «Как дать шифровальщикам потопить компанию».

Остановлюсь чуть подробнее на одном подводном камне, о котором часто забываем при включении SRP со стандартными настройками, когда блокируется все, кроме папок Windows и Program Files. Действительно, это отфильтровывает почти всех зловредов. Но не очень работает со злонамеренностью сотрудников, ведь в системных папках есть подпапки с правом на создание объектов пользователями. Например, можно посмотреть на папку C:\Windows\Temp.

Разрешения на папку, которая попадет в белый список.

И такая папка не одна. Можно, конечно, проводить аудит системных папок самостоятельно, а можно довериться людям, которые это уже сделали. Например, специалист Stefan Kanthak в своем блоге (по ссылке есть тестовый вирус EICAR, антивирус может сработать) в довольно агрессивной манере проходится по антивирусам и методам защиты Windows и заодно предлагает уже собранный пакет настроек SRP, который будет блокировать и такие подозрительные папки. По запросу автор предоставляет и программу для конвертирования этих настроек реестра в файлы локальных политик.

Если вы предпочитаете использовать механизм AppLocker c более гибкими настройками, то вам может помочь решение AaronLocker.

Редакция не рекомендует использовать и устанавливать скрипты и прочие программы из интернета без предварительного их изучения.

Если AppLocker появился уже довольно давно, а возраст SRP перевалил за 15 лет, то относительно свежей альтернативой является WDAC (Windows Defender Application Control). Действительно, со времен Security Essentials встроенный «антивирус» обзавелся многими интересными возможностями. Например, WDAC — модуль, который отвечает за политики доступа к приложениям и библиотекам. Ранее он являлся частью Device Guard (защита компьютера, в том числе с применением технологий виртуализации), и немного про его настройку рассказывалось в материале «Принцип работы S Mode в Windows 10 и настройка Device Guard своими руками». Подробнее со всеми тонкостями можно ознакомиться в официальной документации, мне же остается добавить несколько минусов, отличающих его от классических решений вроде SRP и AppLocker:

• Графической настройки нет, все через командлеты PowerShell.
• Нет настроек в срезе пользователя, только для компьютера.
• Настройка делается довольно непривычно — подготавливается файл в формате xml, который затем приводится к бинарному, и распространяется по компьютерам.

Зато возможна настройка в срезе приложения: например, если вы хотите дать доступ к cmd.exe вашему скрипту, а не стороннему вирусу — это можно реализовать. Да еще и политику можно применить до загрузки системы, при помощи UEFI.

Блокировка хрома через WDAC.

В целом из-за тягостной настройки сложилось впечатление, что WDAC больше позиционируется не сам по себе для управления компьютерами, а как средство, позволяющее интегрироваться с централизованными MDM-системами вроде Microsoft Intune. Но при этом разработка старых добрых SRP прекращена в Windows 10 1803.

Если говорить про Защитник Windows, нельзя не упомянуть про Credential Guard и Remote Credential Guard.

Первое средство использует опять же виртуализацию, запуская компонент LSA (Local Security Authority) в изолированном от операционной системы процессе, что сильно усложняет процесс кражи хешей паролей и билетов Kerberos. Подробнее про технологию можно почитать в официальной документации. Для работы процессор должен поддерживать виртуализацию, а также в системе должна быть включена безопасная загрузка (Secure Boot) и модуль TPM для привязки учетных данных к оборудованию. Включить Credential Guard можно через групповую политику Конфигурация компьютера — Административные шаблоны — Система — Device Guard — Включить средство обеспечения безопасности на основе виртуализации.

Включение Credential Guard.

Второе средство служит для защиты передаваемых учетных данных (особенно админских!) для удаленного подключения, например, по тому же RDP. Ранее для этих целей предлагался механизм Restricted Admin Mode, но он ограничивал подключение только одним сервером. Подключившись к серверу, нельзя было просто так использовать ресурсы сети, права администратора применялись только к одному серверу а-ля системный аккаунт Local System.

Remote Credential Guard позволяет передавать учетные данные с локальной машины удаленному серверу без явного ввода пароля, что, помимо расширенной безопасности, даст и удобство подключения к серверам (SSO). Почитать подробнее можно в документации, ну а я добавлю, что для работы механизма достаточно включить его поддержку на сервере — например, через реестр командой:

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0

А потом подключаться к серверу командой:

mstsc.exe /remoteGuard

Теперь учетные данные в безопасности, а сервер достаточно защищен. Правда, в материале я осознанно не касался вопросов защиты от злонамеренного хостера, но тут все сводится в общем-то к одному — к шифрованию дисков.

Автор статьи: Tri-Edge

by @CyberLifes2020

Эдвард Сноуден — бывший сотрудник ЦРУ и осведомитель, автор книги “Личное дело”. Он президент совета директоров Фонда «Свобода прессы».

«Если интернет-трафик не зашифрован, любое правительство, компания или преступник, могут заметить это. Они украдут его копию и ваши данные сохранятся у них навсегда».

В каждой стране мира горит свет, полки забиты товарами, дамбы закрыты, а транспорт движется. Все это благодаря компьютерной безопасности. США проводили глобальную оценку угроз разведывательного ведомства США. Вот уже более пяти лет первое место в докладе

«Оценка всемирных угроз»Разведывательного сообщества США занимает уязвимость наших компьютеров и компьютерных сетей — выше, чем угроза терроризма и угроза войны. Ваш баланс на карте, оборудование местной больницы и президентские выборы в США в 2020 году, помимо прочего, зависят от компьютерной безопасности.

Сейчас мы переживаем величайший в истории кризис компьютерной безопасности. И все же, правительство США вместе с правительствами Великобритании и Австралии пытаются подорвать важность шифрования. Шифрование — единственный метод для надежной защиты информации в мире. Если они преуспеют в своем деле, наша общественная инфраструктура и частная жизнь будут под угрозой.

Проще говоря, шифрование это метод защиты информации. Он является основным способом обеспечения безопасности цифровой связи. Интернет становится все более враждебным. При этом он запоминает все — каждое ваше электронное письмо, каждое слово введенное в строку поиска, каждую глупость, которую вы делали в интернете. Ранее в этом месяце США, наряду с Великобританией и Австралией, призвали Facebook создать «черный ход»

в их зашифрованных мессенджерах. Он бы дал любому человеку с ключом от этого черного хода неограниченный доступ к личным перепискам. Это было бы роковой ошибкой. Facebook до сих пор не хочет этого делать.

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

Я кое-что знаю об этом, потому что какое-то время я управлял частью глобальной системы массового наблюдения Агентства национальной безопасности США. В июне 2013 года я работал с журналистами, чтобы показать миру эту систему изнутри.

Без шифрования я не смог бы написать историю о том, как все это произошло. Только так я смог безопасно перевезти рукопись своей книги “Личное дело” через границу. При том, что сам я ее пересечь не могу. Шифрование помогает всем выполнять свою работу — репортерам, диссидентам, активистам, работникам НПО и информаторам, врачам, юристам и политикам. Речь идет не только о самых опасных и репрессивных странах мира, но и о каждой отдельно взятой стране.

Когда я разгласил информацию в 2013 году, правительство США не только пассивно отслеживало интернет-трафик, когда он пересекал сеть. Они нашли способы привлекать американские технологические компании к сотрудничеству. Порой они проникали в их внутренние сети. В то время лишь небольшая часть веб-трафика была зашифрована. Шесть лет спустя Facebook, Google и Apple сделали шифрование основной частью своих продуктов по умолчанию. В результате около 80% веб-трафика сегодня зашифрованы. Даже бывший директор национальной разведки США Джеймс Клэппер считает, что разоблачение массового наблюдения продвинуло коммерческое внедрение шифрования. В результате Интернет становится более безопасным местом. Слишком безопасным, по мнению некоторых правительств.

Генеральный прокурор Дональда Трампа Уильям Барр утвердил одну из самых первых программ массового наблюдения, не задумываясь о том законно ли это. Теперь он заявляет о намерении остановить прогресс последних шести лет или даже вернуться к начальной точке. WhatsApp, мессенджер, принадлежащий Facebook, уже использует сквозное шифрование (E2EE). В марте компания объявила о своем намерении включить E2EE в Facebook Messenger и Instagram. Барр запускает публичную кампанию, чтобы не позволить Facebook подняться на следующую ступеньку цифровой безопасности. Все началось с открытого письма, подписанного Барром, министром внутренних дел Великобритании Прити Патель, министром внутренних дел Австралии и министром внутренней безопасности США. В письме требовали, чтобы Facebook отказался от своих предложений по шифрованию.

Если кампания Барра будет успешной, миллиарды сообщений окажутся в состоянии постоянной незащищенности. Пользователей нарочно поставят в уязвимое положение. Личные переписки будут доступны не только следователям в США, Великобритании и Австралии, но и в спецслужбах Китая, России и Саудовской Аравии. Я уже не говорю о хакерах во всем мире.

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

E2EE гораздо лучше старых систем безопасности. В этой системе ключи, которые разблокируют любое сообщение, хранятся только на определенных устройствах в конечных точках связи. Если вы отправите сообщение, ключ сохранится на телефонах отправителя или получателя сообщения. Посредники, владеющие различными интернет-платформами, ничего не смогут сделать. Соответственно эти ключи нельзя украсть в случае массовых утечек корпоративных данных. Подобные утечки происходят часто и вредят нашей безопасности. E2EE позволяет таким компаниям, как Facebook, Google или Apple, защищать своих пользователей от пристального внимания. Пользуясь этой системой, компании гарантируют, что они больше не будут владеть ключами к нашим личным беседам. Их уже нельзя будет назвать всевидящим оком. Слепой курьер и то будет знать о вас больше чем эти корпорации.

Мы живем в странном мире. Facebook — потенциально опасная компания. Компания, которая публично говорит о том, что хочет внедрить технологию, которая обезопасит пользователей. При этом Facebook ограничивают свои собственные возможности на благо других людей. А правительство США люто протестует против этого. Все потому что правительству из-за прихоти Facebook станет сложнее следить за частной жизнью людей.

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

На самом деле правительства США, Великобритании и Австралии хотят отказаться от сквозного шифрования не из-за общественной безопасности, а скорее из-за власти. Мы отправляем и получаем множество сообщений. E2EE дает нам и устройствам, которые мы используем, особый контроль над ними. У компаний и у других третьих лиц, через которые проходят эти сообщения, больше нет контроля. Из-за этого государственный надзор должен стать более целенаправленным и методичным, а не беспорядочным и универсальным.

Это изменение влечет за собой только один риск — способность стран шпионить за населением в массовом масштабе. Им придется использовать способ посложнее бумажной работы. Правительству стоит ограничить количество личных записей и конфиденциальных сообщений, которыми владеют компании. Так мы вернемся к классическим методам расследования. Эти методы не только эффективны, но и уважают права человека, в отличии от тотального надзора. В таком случае мы будем в безопасности. Мы будем свободны.

Перевод: Диана Шеремьева

by @Cyberlifes

Отрывок из книги «Постоянная запись»; как молодой человек, работавший системным администратором, обнаружил посягательства на свободу и решил предать гласности обширную американскую систему слежки за гражданами

Когда мне было 22, я устроился на работу в американскую разведку, политических взглядов у меня не было. Как у большинства молодых людей, у меня был набор чётких взглядов, которые на самом деле были не совсем моими (хотя я и отказывался это признавать) – это был противоречивый набор унаследованных принципов. В моей голове существовала каша из ценностей, с которыми меня воспитывали, и идеалов, встреченных мною в интернете.

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

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

Но эти эпитеты по-настоящему не описывают реальности: класс карьерных чиновников (кстати, возможно, представителей одной из последних прослоек, принадлежащих к среднему классу США), которых никто не выбирал и не назначал, и которые работали на правительство либо в составе независимых агентств (ЦРУ, АНБ, налоговая, федеральная комиссия связи, и т.п.), либо в составе исполнительных департаментов (министерств юстиции, обороны, финансов, госдепа и т.д.).

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

А ещё это были люди, ответившие на вызов, когда страна оказалась на военном положении. Я сделал это после 9/11, и обнаружил, что патриотизм, привитый мне моими родителями, очень легко трансформируется в пылкий национализм. Какое-то время, особенно после того, как я пошёл в армию, моё мироощущение напоминало дуализм простейших видеоигр, в которых добро и зло определяются очень чётко и неоспоримо.

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

В начале 2000-х интернет едва только вышел из периода формирования, и, по-моему, он предлагал более аутентичное и полное воплощение американских идеалов, чем даже сама Америка. Место, где все были равны? Да. Место, посвящённое жизни, свободе и поиску счастья? Да. Да, да, да.

Делу помогало то, что почти все главные документы, формировавшие интернет-культуру, описывали её в терминах, похожих на американскую историю: существовали дикие, открытые рубежи, принадлежавшие всем, кто был достаточно смел, чтобы обосноваться там; но эти рубежи очень быстро начали колонизировать правительства и корпорации, пытавшиеся регулировать их в целях получения власти и прибыли. Крупные компании, просившие большие деньги за железо, ПО, за междугородние звонки, которые нужны были тогда для выхода в интернет, и за сами знания, которые были наследием всего человечества, и по-хорошему, должны были быть бесплатными, до невозможности напоминали мне британскую империю, чьи жёсткие налоги зажгли огонь независимости [в США].

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

В школе мне нужно было выучить предисловие к Конституции США. Теперь эти слова в моей памяти накрепко сплелись с "

декларацией независимости киберпространства

"

Джона Перри Барлоу

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

Такая технологическая меритократия могла давать как вдохновение, так и смирение – как понял я, устроившись на должность работника умственного труда. Децентрализация интернета подчеркнула децентрализацию компьютерной компетентности. Я мог быть лучшим компьютерщиком в семье, или в Вашингтоне, но на такой работе приходилось сравнивать свои навыки с навыками всех жителей страны и даже мира. Интернет показал мне всё количество и разнообразие существующих талантов, и чётко дал понять, что для процветания мне придётся выбрать специализацию.

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

Я интересовался компьютерами и программами, а, следовательно, и объединяющими их сетями. Но больше всего меня интриговала их работа на более глубоком уровне абстракции – не как отдельных компонентов, но как общей системы.

Я много думал на эту тему, когда ездил на машине к Линдси и в местный колледж. За рулём я всегда размышлял, а передвижение домой и на работу по опоясывающей Вашингтон дороге было долгим. Разработчик ПО, или программист, уп��авляет местами отдыха на съездах с дорог, и убеждается, что франшизы всех точек по продаже фаст-фуда и автозаправок соответствовали друг другу и ожиданиям пользователя; специалист по железу строит инфраструктуру, прокладывает дороги; специалист по сетям отвечает за управление трафиком, дорожные знаки и светофоры, чтобы довести толпы пользователей до нужных им целей.

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

Системщики бывают двух видов. Один получает в распоряжение существующую систему целиком и поддерживает её, постепенно повышая эффективность и исправляя поломки. Эта должность называется системный администратор, или сисадмин. Второй анализирует задачу, например, как лучше хранить данные, или как организовывать поиск по базам данных, и придумывает решения, комбинируя существующие компоненты или изобретая совершенно новые.

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

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

Поскольку системы работают по инструкциям, или правилам, такой анализ в итоге сводится к поиску того, какие правила не сработали, как именно и почему – к попытке определить те точки, где намерение, стоящее за правилом, не было адекватно выражено через его формулировку или применение. Отказала ли система потому, что какая-то информация не дошла до адресата, или потому, что кто-то использовал систему не по назначению, и получил доступ к запрещённому ресурсу, или он использовал разрешённый ресурс слишком рьяно? Остановил ли один компонент работу другого, или нарушил ли её? Не отняла ли одна программа, или компьютер, или группа людей больше ресурсов у системы, чем положено?

В течение моей карьеры мне было всё сложнее отделять вопросы о технологиях, за которые я отвечал, от вопросов к моей стране. И я всё больше раздражался из-за того, что у меня получалось чинить первое, но не второе. Я закончил работать в разведке с убеждением в том, что операционная система моей страны – её правительство – решило, что лучше всего работает в сломанном состоянии.

Оригинал: https://www.wired.com/story/edward-snowden-in-his-own-words-why-i-became-a-whistle-blower/

Перевел: https://habr.com/ru/users/SLY_G/

by @Cyberlifes

Примечание: автор переведённой статьи не специалист по информационной безопасности, и это его первый экскурс в мир SQL-инъекций. Он просит быть «снисходительными к его наивности».

Предупреждение: автор переведённой статьи не станет раскрывать сайт с этой уязвимостью. Не потому, что он сообщил о ней владельцу и связан узами молчания, а потому что хочет приберечь уязвимость для себя. Если вы вычислите этот сайт, пожалуйста, держите рот на замке (цыц).

Знаете, вот так иногда открываешь какой-нибудь сайт в инструментарии для разработчика, исследуешь без какой-либо цели минифицированный код и сетевые запросы. И вдруг замечаешь, что-то здесь не так. Совсем не так. Вот и я занимался подобным со страницей пользовательского профиля на одном из сайтов и подметил, что, когда включаешь и выключаешь уведомления о получении, страница шлёт сетевой запрос:

/api/users?email=no

И я подумал: интересно, не допустили ли они какую-нибудь глупость? Может быть, мне попробовать SQL-инъекцию?

Я поискал в сети по запросу “xkcd little bobby tables”, чтобы освежить в памяти, как делать SQL-инъекции — мне они не нравятся, — и принялся за работу.

В сетевой вкладке Chrome я скопировал запрос (Copy > Copy as fetch) и вставил результат во фрагмент, чтобы можно было воспроизвести запрос:

fetch('https://blah.com/api/users', {
  credentials: 'include',
  headers: {
    authorization: 'Bearer blah',
    'content-type': 'application/x-www-form-urlencoded',
    'sec-fetch-mode': 'cors',
    'x-csrf-token': 'blah',
  },
  referrer: 'https://blah.com/blah',
  referrerPolicy: 'no-referrer-when-downgrade',
  body: 'email=no', // < -- The bit we're interested in
  method: 'POST',
  mode: 'cors',
});

Вся остальная статья посвящена возне со строкой body — она является транспортом для отправки инструкций серверу.

Сначала я попытался изменить свою фамилию, задав значение в колонке lastName, ориентируясь просто на её название:

{
  // ...
  body: `email=no', lastName='testing`
}

Ничего интересного не произошло. Затем я проделал то же самое с last_name, потом попытал счастья с surname — и опа! — страница заменила мою фамилию на “testing”. Это было очень захватывающе. Я всегда считал SQL-инъекции чем-то вроде книжной легенды. Тем, что на самом деле не открывает миру код, который вставляет вводимые пользователем данные прямо в SQL-выражения.

Немного филососфии

Для всех непосвящённых объясню, что означает обнаруженный мной результат.

Я считаю, что на сервере происходит нечто подобное:

const userId = someSessionStore.userId;
const email = request.body.email;

const sql = `UPDATE users SET email = '${email}' WHERE id = '${userId}'`;

Уверен, что их сервер написан на PHP, но я не владею этим языком, так что буду писать примеры на JavaScript. Кроме того, я не особо-то разбираюсь в SQL-запросах. Понятия не имею, называется ли таблица user, или users, или user_table, да это и не важно.

Если мой пользовательский ID 1234, и я отправляю email=no, тогда SQL получается таким:

UPDATE users SET email = 'no' WHERE id = '1234'

А если заменить no на строку no', surname = 'testing, тогда SQL будет валидным, но хитрым:

UPDATE users SET email = 'no', surname = 'testing' WHERE id = '1234'

Как вы помните, я отправляю запросы из фрагмента кода в инструментах для разработчика, при этом нахожусь на странице профиля. Так что с этого момента можно считать поле surname на этой странице (HTML-элемент <inрut>) маленьким stdout, в который можно записывать информацию, задавая для моего пользовательского аккаунта значение в колонке surname в базе данных.

Затем мне стало интересно, удастся ли скопировать данные из другой колонки в колонку surname?

Я не понимал, что делать, как быть с SQL, да к тому же не знал, какая БД используется на сервере. Так что после каждого шага я тратил минут по 20 на поиски в сети, а потом ещё 20 минут чесал в затылке, потому что регулярно вставлял свои кавычки ' не туда, куда нужно. Странно, что я не порушил всю базу данных. Копировать данные из одной колонки в другую оказалось чуть сложнее, потому что я хотел отправить такой запрос (предполагалось, что должна быть колонка password):

UPDATE users SET email = 'no', surname = password WHERE id = '1234'

Обратите внимание, что в коде вокруг password нет кавычек. Как вы помните, суперсовременный конструктор запросов должен выглядеть так…

const sql = `UPDATE users SET email = '${email}' WHERE id = '${userId}'`;

… то есть при попытке передать no', surname = password

получившаяся строка не будет валидным SQL-запросом. Вместо этого мне нужно было, чтобы инъектируемая строка целиком стала второй частью запроса, а всё, что идёт после неё, игнорировалось бы. В частности, мне нужно было передать WHERE и; в конце SQL-выражения, а также комментарий #, чтобы информация справа от него игнорировалась. Да, я ужасно объясняю.

Короче, я отправил новую строку:

{
  // ...
  body: `email=no', surname = password WHERE username = 'me@email.com'; #`
}

А в базу данных будет отправлена такая строка:

UPDATE users SET email = 'no', surname = password WHERE username = 'me@email.com'; 
# WHERE id = '1234'

Обратите внимание, что БД проигнорирует

WHERE id = '1234', поскольку эта часть идёт после комментария # (кажется, запрет на комментирование в SQL-запросах является хорошим способом защиты от неряшливого кода).

Я надеялся, что мой пароль P@ssword1 появится в текстовом виде в поле фамилии, но вместо этого я получил 00fcdde26dd77af7858a52e3913e6f3330a32b31.

Меня это разочаровало, хотя и не удивило, и я продолжил попытки скопировать хэш моего пароля в колонку пароля другого пользователя.

Поясню для новичков: когда где-то создаёшь аккаунт и отправляешь новый пароль P@ssword1, он превращается в хэш наподобие 00fcdde26dd77af7858a52e3913e6f3330a32b31 и сохраняется в базе данных. Глядя на этот хэш, никто не сможет определить ваш пароль (или так рассказывают).

Когда в следующий раз вы будете логиниться и вводить пароль Password@1, сервер его снова хэширует и сравнит с хэшем, который хранится в базе данных. Так он подтвердит соответствие, даже не сохраняя ваш пароль.

Это означает, что если я хочу задать кому-нибудь пароль P@ssword1, я должен задать в колонке password у этого пользователя значение 00fcdde26dd77af7858a52e3913e6f3330a32b31.

Легкотня. Я открыл другой браузер, создал нового пользователя с другой почтой и в первую очередь проверил, могу ли задать ему данные. Обновил ему свойство body:

{
  // ...
  body: `email=no', surname = 'WOOT!!' WHERE username = 'user-two@email.com'; #`
}

Выполнил код, обновил страницу этого пользователя, и, офигеть, сработало! Теперь у него была фамилия “WOOT!!” (девичья фамилия моей бабушки).

Затем я попробовал задать этому пользователю пароль:

  // ...
  body: `email=no', password = '00fcdde26dd77af7858a52e3913e6f3330a32b31' WHERE username = 'user-two@email.com'; #`
}

И знаете, что?!?!?

Не сработало. Теперь у меня не было доступа ко второму аккаунту.

Оказалось, я допустил две ошибки, на вычисление которых ушло несколько часов. Специалисты по инфобезопасности, читающие эту статью, уже поняли, о чём речь, и, вероятно, ржут над дураком, который пишет свои «эксплойты», перечисленные на первой странице «Хакинг для самых маленьких».

Нуууууу, в конце концов я поискал в сети по запросу “password hash” и заметил, что многие хэши длиннее моего 00fcdde26dd77af7858a52e3913e6f3330a32b31. Похоже, он где-то обрезается.

Я попытался вписать кусок текста в поле surname, и обнаружил лимит в 40 символов (хорошо, что они задали атрибут maxlength для <inрut>, чтобы соответствовало ограничению в базе данных).

Теперь меня интересовали только первые 40 символов хэша, который мог быть гораздо длиннее. Поискал по запросу “sql substring”, и вскоре отправил на сервер такой запрос:

 
{
  // ...
  body: `email=no', surname = SUBSTRING(password, 30, 1000) WHERE username = 'me@email.com'; #`
}

Начал с 30, чтобы убедиться, что первые 10 символов перекрываются последними 10 символами 00fcdde26dd77af7858a52e3913e6f3330a32b31. Или последними 9. Или 11.

Лирическое отступление

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

 {
  // ...
  body: `email=no', password = '00fcdde26dd77af7858a52e3913e6f3330a32b3121a61bce915cc6145fc44453' WHERE username = 'user-two@email.com'; #`
}

И знаете, что?!?!

Ну, вы уже догадались, ведь я упомянул про две ошибки.

Я по-прежнему не мог залогиниться во второй аккаунт, но уже был близок к этому (хорошо бы мне знать об этом в тот момент).

Поискал по запросу “best practices database password” и узнал/вспомнил о такой штуке, как «соль».

Применение соли означает, что если ты создаёшь хэш для P@ssword1 для одного пользователя, то для другого пользователя тот же пароль даст другой хэш (используется другая соль). Конечно же, один хэш пароля не будет работать для двух пользователей, соли-то разные.

Вроде бы умно, но в то же время глупо. Во всех примерах в таблице просто была ещё одна колонка под названием salt. Разве это не означает, что мне нужно скопировать данные из двух колонок, а не одной? Разве это не выглядит как второй замок, к которому подходит тот же ключ?

Я изменил запрос в надежде скопировать значение из колонки, которая может называться salt, в колонку surname:

 {
  // ...
  body: `email=no', surname = salt WHERE username = 'myemail@email.com'; #`
}

В поле фамилии оказался беспорядочный набор символов, хороший знак. Для получения того, что оказалось 64-символьной солью, я снова использовал SUBSTRING.

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

fetch('https://blah.com/api/users', {
  credentials: 'include',
  headers: {
    authorization: 'Bearer blah',
    'content-type': 'application/x-www-form-urlencoded',
    'sec-fetch-mode': 'cors',
    'x-csrf-token': 'blah',
  },
  referrer: 'https://blah.com/blah',
  referrerPolicy: 'no-referrer-when-downgrade',
  body: `email=no', password = '00fcdde26dd77af7858a52e3913e6f3330a32b3121a61bce915cc6145fc44453', salt = '8b7df143d91c716ecfa5fc1730022f6b421b05cedee8fd52b1fc65a96030ad52' WHERE username = 'user-two@gmail.com'; #`,
  method: 'POST',
  mode: 'cors',
});

Сработало! Теперь я мог залогиниться во второй аккаунт с паролем от первого аккаунта.

Разве это не безумие?

* * *

Было много проб и ошибок, но когда я выберу настоящего пользователя, я сначала получу его соль и хэш и сохраню у себя. Затем заменю его подсоленный хэш на свой, как описано в статье, залогинюсь и моментально заменю соль и хэш на оригинальные значения. Мне нужно лишь на долю секунды изменить чужой пароль, пока я логинюсь, так что меня почти наверняка не обнаружат.

В теории, конечно. Я бы никогда так не сделал.

* * *

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

Но я не могу не спрашивать себя, было ли это всего лишь удачей новичка. Это в буквальном смысле первый сайт, на котором я попробовал SQL-инъекцию, и всё было словно приготовлено для меня, словно я сдавал экзамен по хакингу для малышей.

Описанный мной сайт невелик, у него мало пользователей (34 718). Это платный сервис, так что для матёрых хакеров он не представляет интереса. И всё же меня поразило, что такое возможно.

Короче, теперь я подсел на всю эту тему с информационной безопасностью. Для меня в ней объединились два любимых занятия: написание кода и хулиганство. Так что погуглив “information security salaries Australia”, думаю, я нашёл себе новую работу.

Спасибо, что прочитали!

Перевод: https://habr.com/ru/users/barsoo4ok/

Оригинал: https://medium.com/@david.gilbertson/my-first-exploit-a-site-that-allows-setting-any-users-password-a07b1142af2c

by @Cyberlifes

При слове «криптография» некоторые вспоминают свой пароль WiFi, зелёный замочек рядом с адресом любимого сайта и то, как трудно залезть в чужую почту. Другие вспоминают череду уязвимостей последних лет с говорящими аббревиатурами (DROWN, FREAK, POODLE...), стильными логотипами и предупреждением срочно обновить браузер.

Криптография охватывает всё это, но суть в ином. Суть в тонкой грани между простым и сложным. Некоторые вещи просто сделать, но сложно вернуть обратно: например, разбить яйцо. Другие вещи легко сделать, но трудно вернуть обратно, когда отсутствует маленькая важная решающая часть: например, открыть запертую дверь, когда «решающая часть» является ключом. Криптография изучает эти ситуации и способы их практического использования.

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

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

• Базовые стратегии: брутфорс, частотный анализ, интерполяция, понижение и кросс-протоколы.
  
• «Брендовые» уязвимости: FREAK, CRIME, POODLE, DROWN, Logjam.
  
• Продвинутые стратегии: атаки оракула (атака Воденэ, атака Келси); метод встречи посередине (meet-in-the-middle), атака «дней рождения», статистическое смещение (дифференциальный криптоанализ, интегральный криптоанализ и т. д.).
  
• Атаки по сторонним каналам и их близкие родственники, методы анализа сбоев.
  
• Атаки на криптографию с открытым ключом: кубический корень, броадкаст, связанное сообщение, атака Копперсмита, алгоритм Полига — Хеллмана, числовое решето, атака Винера, атака Блайхенбахера.

Эта конкретная статья охватывает вышеупомянутый материал вплоть до атаки Келси.

Базовые стратегии

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

Некоторые из этих атак в основном потеряли актуальность и не применялись уже много лет. Другие — старожилы, они всё ещё регулярно подкрадываются к ничего не подозревающим разработчикам криптосистем в 21 веке. Можно считать, что эпоха современной криптографии началась с появления IBM DES — первого шифра, который выдержал все атаки в этом списке.

Простой брутфорс

Схема шифрования состоит из двух частей: 1) функция шифрования, которая принимает сообщение (открытый текст) в сочетании с ключом, а затем создаёт зашифрованное сообщение — шифротекст; 2) функция дешифрования, которая принимает шифротекст и ключ и создаёт открытый текст. И шифрование, и дешифрование должны быть легко вычисляемы с ключом — и трудно без него.

Предположим, что мы видим шифротекст и пытаемся расшифровать его без какой-либо дополнительной информации (это называется атакой «только шифротекст»). Если мы каким-то волшебным образом найдём правильный ключ, то можем легко проверить, что он действительно правильный, если результат является разумным сообщением.

Обратите внимание, что здесь два неявных предположения. Во-первых, что мы знаем, как выполнить расшифровку, то есть, как работает криптосистема. Это стандартное предположение при обсуждении криптографии. Сокрытие деталей реализации шифра от злоумышленников может показаться дополнительной мерой безопасности, но как только злоумышленник выяснит эти детали, данная дополнительная безопасность незаметно и необратимо потеряна. Таков принцип Керчхоффса: попадание системы в руки врага не должно причинять неудобств.

Во-вторых, мы предполагаем, что правильный ключ является единственным ключом, который приведёт к разумной расшифровке. Это также разумное предположение; оно выполняется, если шифротекст намного длиннее ключа и хорошо читаем. Как правило, так и бывает в реальном мире, за исключением огромных непрактичных ключей или других махинаций, которые лучше оставить в стороне (если вам не нравится, что мы отмахнулись от объяснений, пожалуйста, см. теорему 3.8 здесь).

Учитывая вышеизложенное, возникает стратегия: проверить каждый возможный ключ. Это называется брутфорсом, и такая атака гарантированно работает против всех практических шифров — в конечном итоге. Например, брутфорса достаточно, чтобы взломать шифр Цезаря, древний шифр, где ключом является одна буква из алфавита, что подразумевает чуть более 20 возможных ключей.

К сожалению для криптоаналитиков, увеличение размера ключа хорошо защищает от брутфорса. По мере роста размера ключа количество возможных ключей увеличивается экспоненциально. С современными размерами ключей простой брутфорс совершенно не практичен. Чтобы понять, что мы имеем в виду, возьмём самый быстрый известный суперкомпьютер на середину 2019 года: Summit от IBM, с пиковой производительностью порядка 1017 операций в секунду. Сегодня типичная длина ключа составляет 128 бит, что означает 2128 возможных комбинаций. Для перебора всех ключей суперкомпьютеру Summit потребуется время, которое примерно в 7800 раз превышает возраст Вселенной.

Считать ли брутфорс историческим курьёзом? Вовсе нет: это необходимый ингредиент в поваренной книге криптоанализа. Редко встречаются настолько слабые шифры, что их можно взломать только умной атакой, без применения силы в той или иной степени. Многие успешные взломы используют сначала алгоритмический метод, чтобы ослабить целевой шифр, а затем запустить брутфорс.

Частотный анализ

Большинство текстов — это не тарабарщина. Например, в англоязычных текстах много букв 'e' и артиклей 'the'; в двоичных файлах — много нулевых байтов в качестве заполнителя между фрагментами информации. Частотный анализ — любая атака, которая использует этот факт.

Каноническим примером шифра, уязвимого для этой атаки, является простой шифр подстановки. В этом шифре ключ представляет собой таблицу с заменой всех букв. Например, 'g' заменяется на 'h', 'o' — на j, Поэтому слово 'go' превращается в 'hj'. Этот шифр трудно поддаётся простому брутфорсу, так как существует очень много возможных таблиц подстановки. Если вас интересует математика, эффективная длина ключа составляет около 88 бит: это . Но частотный анализ обычно быстро справляется с задачей.

Рассмотрим следующий шифротекст, обработанный простым шифром подстановки:

XDYLY ALY UGLY XDWNKE WN DYAJYN ANF YALXD DGLAXWG XDAN ALY FLYAUX GR WN OGQL ZDWBGEGZDO

Поскольку Y встречается часто, в том числе в конце многих слов, мы можем предварительно предположить, что это буква e:

XDeLe ALe UGLe XDWNKE WN DeAJeN ANF eALXD DGLAXWG XDAN ALe FLeAUX GR WN OGQL ZDWBGEGZDO

Пара XD повторяется в начале нескольких слов. В частности, сочетание XDeLe явно предполагает слово these или there, поэтому продолжаем:

theLe ALe UGLe thWNKE WN heAJeN ANF eALth DGLAtWG thAN ALe FLeAUt GR WN OGQL ZDWBGEGZDO Далее предположим, что L соответствует r, A — a и так далее. Вероятно, придётся сделать несколько попыток, но по сравнению с полным брутфорсом эта атака восстанавливает исходный текст в кратчайшие сроки:

there are more things in heaven and earth horatio than are dreamt of in your philosophy

Для некоторых решение таких «криптограмм» — увлекательное хобби.

Идея частотного анализа более фундаментальная, чем кажется на первый взгляд. И он применим к гораздо более сложным шифрам. На протяжении всей истории различные конструкции шифров пытались противостоять такой атаке с помощью «полиалфавитной подстановки». Здесь в процессе шифрования таблица замены букв изменяется сложными, но предсказуемыми способами, которые зависят от ключа. Все эти шифры в своё время считались трудными для взлома; и всё же скромный частотный анализ в итоге все их одолел.

Самым амбициозным полиалфавитным шифром в истории и, наверное, самым известным, был шифр «Энигмы» во Второй мировой войне. Он был относительно сложным по сравнению с предшественниками, но в результате долгой и упорной работы британские криптоаналитики взломали его с помощью частотного анализа. Конечно, они не смогли разработать элегантную атаку, как показанная выше; им пришлось сравнивать известные пары открытых и зашифрованных текстов (так называемая «атака на основе открытых текстов») и даже провоцируя пользователей «Энигмы» на шифрование определённых сообщений с анализом результата («атака на основе подобранного открытого текста»). Но это не облегчило судьбу побеждённых армий врагов и потопленных подводных лодок.

После этого триумфа частотный анализ исчез из истории криптоанализа. Шифры современной цифровой эпохи созданы для работы с битами, а не буквами. Что ещё более важно, эти шифры разработаны с мрачным пониманием того, что позже стало известно как закон Шнайера: любой может создать алгоритм шифрования, который сам не сможет взломать. Недостаточно, чтобы шифровальная система казалась сложной: чтобы доказать свою ценность, она должна пройти безжалостный обзор безопасности от многих криптоаналитиков, которые сделают всё возможное, чтобы взломать шифр.

Предварительные вычисления

Возьмём гипотетический город Преком Хайтс с населением 200 000 человек. В каждом доме города находятся ценные вещи в среднем на $30 000, но не более, чем на $50 000. Рынок безопасности в Прекоме монополизировала компания ACME Industries, которая производит легендарные дверные замки класса Coyote (tm). Согласно экспертному анализу, замок класса Coyote способна сломать только очень сложная гипотетическая машина, создание которой требует около пяти лет и $50 000 вложений. Город в безопасности?

Скорее всего, нет. В конце концов, появится достаточно амбициозный преступник. Он будет рассуждать так: «Да, я понесу большие авансовые расходы. Пять лет терпеливого ожидания, и $50 000. Но по окончании работы у меня будет доступ ко всему богатству этого города. Если я правильно разыграю свои карты, то эта инвестиция многократно окупится».

Аналогично и в криптографии. Атаки против конкретного шифра подвергаются безжалостному анализу затрат и выгод. Если соотношение благоприятно, атака не произойдёт. Но атаки, которые действуют сразу против многих потенциальных жертв, почти всегда окупаются, и в этом случае лучшая практика проектирования — предположить, что они начались с первого дня. У нас есть по сути криптографическая версия закона Мёрфи: «Всё, что реально может сломать систему, сломает систему».

Простейший пример криптосистемы, уязвимой к атаке с предварительными вычислениями, — шифр с постоянным алгоритмом без использования ключа. Так было в случае с шифром Цезаря, который просто сдвигает каждую букву алфавита на три буквы вперёд (таблица закольцована, поэтому последняя буква в алфавите шифруется третьей). Здесь опять проявляется принцип Керчхоффса: как только система взломана, она взломана навсегда.

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

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

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

Интерполяция

Перед вами знаменитый детектив Шерлок Холмс, выполняющий атаку с интерполяцией на незадачливого доктора Ватсона:

Я сразу догадался, что вы приехали из Афганистана… Ход моих мыслей был таков: «Этот человек по типу — врач, но выправка у него военная. Значит, военный врач. Он только что приехал из тропиков — лицо у него смуглое, но это не природный оттенок его кожи, так как запястья у него гораздо белее. Лицо измождённое, — очевидно, немало натерпелся и перенёс болезнь. Был ранен в левую руку — держит её неподвижно и немножко неестественно. Где же под тропиками военный врач-англичанин мог натерпеться лишений и получить рану? Конечно же, в Афганистане». Весь ход мыслей не занял и секунды. И вот я сказал, что вы приехали из Афганистана, а вы удивились.

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

Проиллюстрируем на простом примере, как работает интерполяция. Предположим, что мы хотим прочитать личный дневник нашего врага, Боба. Он шифрует каждое число в своём дневнике с помощью простой криптосистемы, о которой узнал из рекламного объявления в журнале «Насмешка над криптографией». Система работает следующим образом: Боб выбирает два числа, которые ему нравятся: и . С этого момента, чтобы зашифровать любое число , он вычисляет . Например, если Боб выбрал и , то цифра зашифруется как .

Предположим, 28 декабря мы заметили, что Боб что-то царапает в своём дневнике. Когда он закончит, мы незаметно возьмём его и посмотрим последнюю запись:

Дата: 235/520

Дорогой дневник,

Сегодня был хороший день. Через 64 дня у меня свидание с Алисой, которая живёт в квартире 843. Я действительно думаю, что она может быть 26!

Поскольку мы очень серьёзно намерены проследить за Бобом на его свидании (в этом сценарии нам по 15 лет), то критически важно узнать дату, а также адрес Алисы. К счастью, мы замечаем, что криптосистема Боба уязвима для атаки интерполяции. Мы можем и не знать и , но мы знаем сегодняшнюю дату, поэтому у нас есть две пары «открытый текст — шифротекст». А именно, мы знаем, что шифруется в , а — в . Что и запишем:

Поскольку нам 15 лет, мы уже знаем о системе двух уравнений с двумя неизвестными, чего в данной ситуации достаточно для нахождения и без особых проблем. Каждая пара «открытый текст-шифротекст» накладывает ограничение на ключ Боба, и двух ограничений вместе достаточно, чтобы полностью восстановить ключ. В нашем примере ответ и (при х, так что 26 в дневнике соответствует слову 'the one', то есть «та самая» — прим. пер.).

Интерполяционные атаки, конечно, не ограничиваются такими простыми примерами. Каждая криптосистема, которая сводится к хорошо понятному математическому объекту и списку параметров, подвергается риску интерполяционной атаки — чем более понятен объект, тем выше риск.

Новички часто жалуются, что криптография — это «искусство проектирования как можно более уродливых вещей». Вероятно, во многом виноваты атаки интерполяции. Боб может или использовать элегантный математический дизайн, или сохранить конфиденциальность свидания с Алисой — но увы, обычно нельзя получить и то, и другое. Это станет предельно ясно, когда мы в конце концов перейдём к теме криптографии с открытым ключом.

Кросс-протокол/понижение

В фильме «Иллюзия обмана» (2013) группа иллюзионистов пытается обманом выманить всё состояние коррумпированного страхового магната Артура Тресслера. Чтобы получить доступ к банковскому счёту Артура, иллюзионисты должны либо представить его имя пользователя и пароль, либо заставить его лично появиться в банке и принять участие в схеме.

Оба варианта очень трудны; ребята привыкли выступать на сцене, а не участвовать в операциях спецслужб. Поэтому они выбирают третий возможный вариант: их сообщник звонит в банк и выдаёт себя за Артура. Банк задаёт несколько вопросов для проверки личности, таких как имя дяди и имя первого питомца; наши герои заранее легко выуживают у Артура эту информацию с помощью ловкой социальной инженерии. С этого момента отличная безопасность пароля больше не имеет значения.

(Согласно городской легенде, которую мы лично проверили и подтвердили, криптограф Эли Бихэм однажды столкнулся с кассиром банка, который настаивал на установке секретного вопроса. Когда кассир спросил имя бабушки по материнской линии, Бихэм начал диктовать: «Заглавная X, маленькая y, три…»).

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

В некоторых сложных случаях недостаточно просто связаться с сервером по более слабому протоколу, а требуется невольное участия легитимного клиента. Это можно организовать с помощью так называемой атаки на понижение (downgrade). Для понимания этой атаки предположим, что у наших иллюзионистов более сложная задача, чем в фильме. Предположим, что у сотрудника банка (кассир) и Артура возникли некие непредвиденные обстоятельства, в результате чего произошёл такой диалог:

Взломщик: Алло? Это Артур Тресслер. Я хотел бы восстановить свой пароль.

Кассир: Отлично. Пожалуйста, взгляните в свою персональную книгу секретных кодов, страница 28, слово 3. Все следующие сообщения будут зашифрованы с помощью этого конкретного слова в качестве ключа. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

Взломщик: Эй-эй, погоди, погоди. Это действительно необходимо? Мы не можем просто говорить как нормальные люди?

Кассир: Не советую этого делать.

Взломщик: Я просто… слушай, у меня был паршивый день, ясно? Я VIP-клиент и не в настроении копаться в этих дурацких кодовых книгах.

Кассир: Хорошо. Если вы настаиваете, мистер Тресслер. Что вам угодно?

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

(Пауза).

Кассир: Так, понятно. Пожалуйста, укажите свой пин-код для крупных транзакций.

Взломщик: Мой что?

Кассир: По вашей личной просьбе транзакции такого размера требуют ввода пин-кода для крупных транзакций. Этот код выдали вам при открытии счёта.

Взломщик:… Я его потерял. Это действительно необходимо? Разве вы не можете просто одобрить сделку?

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

Наши герои откладывают операцию. Они прослушивают несколько крупных транзакций Тресслера, надеясь услышать пин-код; но каждый раз разговор превращается в зашифрованную тарабарщину, прежде чем там звучит что-то интересное. Наконец, в один прекрасный день приводят план в действие. Они терпеливо ждут момента, когда Тресслер должен совершить крупную транзакцию по телефону, он подключается к линии, а затем…

Тресслер: Здравствуйте. Я хотел бы оформить удалённую транзакцию, пожалуйста.

Кассир: Отлично. Пожалуйста, взгляните в свою персональную книгу секретных кодов, страница…

(Взломщик нажимает на кнопку; голос кассира превращается в неразборчивый шум).

Кассир: — #@$#@$#*@$$@#* будет зашифрован с этим словом в качестве ключа. AAAYRR PLRQRZ MMNJK LOJBAN…

Тресслер: Простите, я не совсем понял. Ещё раз? На какой странице? Какое слово?

Кассир: Это страница @#$@#*$)#*#@()#@$(#@*$(#@*.

Тресслер: Что?

Кассир: Слово номер двадцать @$#@$#%#$.

Тресслер: Серьёзно! Да хватит уже! Вы со своим протоколом безопасности — это какой-то цирк. Я знаю, что ты можешь просто нормально поговорить со мной.

Кассир: Я не советую…

Тресслер: А я тебе не советую впустую тратить моё время. Не хочу больше слышать об этом, пока не исправите проблемы со своей телефонной линией. Можем мы оформить эту сделку или нет?

Кассир:… да. Хорошо. Что вам угодно?

Тресслер: Я хотел бы перевести $20 000 в компанию Lord Business Investments, номер счёта…

Кассир: Минутку, пожалуйста. Это большая сделка. Пожалуйста, укажите свой пин-код для крупных транзакций.

Тресслер: Что? А, точно. 1234.

Вот атака на понижение. Более слабый протокол «просто говорите прямо» предполагался как опция на крайний случай. И всё же мы здесь.

Вы можете задать вопрос, кто в здравом уме будет проектировать реальную систему типа «безопасно, пока не попросить об обратном», какая описана выше. Но так же, как вымышленный банк идёт на риск, чтобы сохранить клиентов, которые не любят криптографию, так и системы в целом часто склоняются к требованиям, которые безразличны или даже откровенно враждебны к безопасности.

Именно такая история произошла с протоколом SSLv2 в 1995 году. Правительство США давно начало рассматривать криптографию как оружие, которое лучше держать подальше от внешних и внутренних врагов. Фрагменты кода по отдельности одобряли для экспорта из США, часто при условии намеренного ослабления алгоритма. Компании Netscape, разработчику самого популярного браузера Netscape Navigator, дали разрешение на SSLv2 только с изначально уязвимым ключом RSA 512 бит (и 40 бит для RC4).

К концу тысячелетия правила смягчили и доступ к современному шифрованию стал широко доступным. Тем не менее, клиенты и серверы в течение многих лет поддерживали ослабленную «экспортную» криптографию из-за той же инерции, из-за которой сохраняется поддержка любой устаревшей системы. Клиенты полагали, что могут встретить сервер, который не поддерживает ничего другого. Серверы делали то же самое. Конечно, протокол SSL диктует, что клиенты и серверы никогда не должны использовать слабый протокол, когда доступен лучший. Но та же предпосылка действовала для Тресслера и его банка.

Эта теория нашла применение в двух громких атаках, которые одна за другой потрясли безопасность протокола SSL в 2015 году, обе обнаружены исследователями Microsoft и INRIA. Сначала в феврале разгласили детали атаки FREAK, а через три месяца — ещё одной подобной атаки под названием Logjam, которую мы обсудим более подробно, когда перейдём к атакам на криптографию с открытым ключом.

Уязвимость FREAK (также известная как "Smack TLS") проявилась, когда исследователи проанализировали реализации клиента/сервера TLS и обнаружили любопытную ошибку. В этих реализациях, если клиент даже не просит использовать слабую экспортную криптографию, но сервер всё равно отвечает такими ключами — клиент говорит «Ну ладно» и переходит на слабый набор шифров.

В то время все считали экспортную криптографию устаревшей и запретной для использования, поэтому атака стала настоящим шоком и затронула многие важные домены, включая сайты Белого дома, налогового управления США и АНБ. Хуже того, оказалось, что многие уязвимые серверы оптимизировали производительность, повторно используя одни и те же ключи, а не создавая новые для каждого сеанса. Это позволило после понижения протокола провести ещё и атаку с предвычислением: взлом одного ключа оставался относительно дорогим ($100 и 12 часов на момент публикации), но практическая стоимость атаки на соединение значительно снизилась. Достаточно один раз подобрать серверный ключ — и взломать шифры для всех последующих соединений с этого момента.

И прежде чем двигаться дальше, нужно упомянуть одну продвинутую атаку…

Атака оракула

Мокси Марлинспайк наиболее известен как отец кросс-платформенного криптомессенджера Signal; но лично нам нравится одно из его менее известных нововведений — принцип криптографической обречённости (Cryptographic Doom Principle). Слегка перефразируя, можно сказать так: «Если протокол выполняет любую криптографическую операцию над сообщением из потенциально вредоносного источника и ведёт себя по-разному в зависимости от результата, он обречён». Или в более резкой форме: «Не бери у врага информацию на обработку, а если пришлось, то хотя бы не показывай результат».

Оставим в стороне переполнения буфера, инъекции команд и тому подобное; они выходят за рамки этого обсуждения. Нарушение «принципа обречённости» приводит к серьёзным взломам криптографии из-за того, что протокол ведёт себя в точности так, как положено.

Для примера возьмём выдуманную конструкцию с уязвимым шифром подстановки, а затем продемонстрируем возможную атаку. Хотя мы уже видели атаку на шифр подстановки с помощью частотного анализа, это не просто «другой способ сломать тот же шифр». Наоборот, атаки оракула — гораздо более современное изобретение, применимое к множеству ситуаций, когда частотный анализ терпит неудачу, и мы увидим демонстрацию этого в следующем разделе. Здесь простой шифр выбран только для того, чтобы сделать пример более понятным.

Итак, Алиса и Боб общаются с помощью простого шифра подстановки, используя ключ, известный только им. Они очень строго относятся к длине сообщений: их длина ровно 20 символов. Поэтому они согласились, что если кто-то хочет отправить более короткое сообщение, то должен добавить какой-то фиктивный текст в конец сообщения, чтобы оно было ровно 20 символов. После некоторого обсуждения они решили, что будут принимать только следующие фиктивные тексты: a, bb, ccc, dddd и т. д. Таким образом, известен фиктивный текст любой необходимой длины.

Когда Алиса или Боб получает сообщение, они сначала проверяют, что сообщение имеет правильную длину (20 символов), а суффикс — правильный фиктивный текст. Если это не так, то отвечают соответствующим сообщением об ошибке. Если длина текста и фиктивный текст в порядке, получатель читает само сообщение и отправляет зашифрованный ответ.

В процессе атаки злоумышленник выдаёт себя за Боба и отправляет поддельные сообщения Алисе. Сообщения — полная ерунда — у злоумышленника нет ключа, и поэтому он не может подделать значимое сообщение. Но поскольку протокол нарушает принцип обречённости, злоумышленник всё равно может заманить Алису в ловушку, так что она раскроет информацию о ключе, как показано ниже.

Взломщик: PREWF ZHJKL MMMN. LA

Алиса: Неверный фиктивный текст.

Взломщик: PREWF ZHJKL MMMN. LB

Алиса: Неверный фиктивный текст.

Взломщик: PREWF ZHJKL MMMN. LC

Алиса: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Взломщик понятия не имеет, что только что сказала Алиса, но отмечает, что символ C должен соответствовать a, поскольку Алиса приняла фиктивный текст.

Взломщик: REWF ZHJKL MMMN. LAA

Алиса: Неверный фиктивный текст.

Взломщик: REWF ZHJKL MMMN. LBB

Алиса: Неверный фиктивный текст.

После ряда попыток…

Взломщик: REWF ZHJKL MMMN. LGG

Алиса: Неверный фиктивный текст.

Взломщик: REWF ZHJKL MMMN. LHH

Алиса: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

Опять же, взломщик понятия не имеет, что только что сказала Алиса, но отмечает, что H должен сопоставляться с b, поскольку Алиса приняла фиктивный текст.

И так далее, пока злоумышленник не узнает значение каждого символа.

На первый взгляд, метод напоминает атаку на основе подобранного открытого текста. В конце концов, злоумышленник подбирает шифротексты, а сервер послушно их обрабатывает. Основное различие, которое делает эти атаки жизнеспособными в реальном мире, состоит в том, что злоумышленнику не требуется доступ к фактической расшифровке — достаточно ответа сервера, даже такого безобидного, как «Неправильный фиктивный текст».

Хотя эта конкретная атака поучительна, не следует слишком зацикливаться на специфике схемы «фиктивного текста», конкретной используемой криптосистеме или точной последовательности сообщений, отправленных злоумышленником. Основная идея заключается в том, как Алиса реагирует по-разному, основываясь на свойствах открытого текста, и делает это без проверки того, что соответствующий зашифрованный текст действительно получен от доверенной стороны. Таким образом, Алиса позволяет злоумышленнику выжать секретную информацию из её ответов.

В этом сценарии можно многое изменить. Символы, на которые реагирует Алиса, или саму разницу в её поведении, или даже используемую криптосистему. Но принцип останется тем же, и атака в целом останется жизнеспособной в той или иной форме. Базовая реализация этой атаки помогла обнаружить несколько ошибок безопасности, которые мы скоро рассмотрим; но прежде следует усвоить некоторые теоретические уроки. Как использовать этот выдуманный «сценарий Алисы» в атаке, которая способна работать на реальном современном шифре? Возможно ли это вообще, даже в теории?

В 1998 году швейцарский криптограф Даниель Блайхенбахер (Daniel Bleichenbacher) ответил на этот вопрос утвердительно. Он продемонстрировал атаку оракула в широко используемой криптосистеме с открытым ключом RSA, при использовании определённой схемы сообщений. В некоторых реализациях RSA сервер отвечает разными сообщениями об ошибках, в зависимости от того, соответствует открытый текст схеме или нет; этого было достаточно, чтобы провести атаку.

Четыре года спустя, в 2002 году, французский криптограф Серж Воденэ (Serge Vaudenay) продемонстрировал атаку оракула, почти идентичную той, что описана выше в сценарии Алисы — за исключением того, что вместо выдуманного шифра он взломал целый респектабельный класс современных шифров, которые люди действительно используют. В частности, атака Воденэ нацелена на шифры с фиксированным размером ввода («блочные шифры»), когда они используются в так называемом «режиме шифрования CBC» и с определённой популярной схемой заполнения, в основном эквивалентной той, что в сценарии Алисы.

Также в 2002 году американский криптограф Джон Келси (John Kelsey) — соавтор Twofish — предложил различные атаки оракула на системы, которые сжимают сообщения, а затем шифруют их. Наиболее заметной среди них была атака, которая использовало то, что часто можно вывести исходную длину открытого текста от длины зашифрованного текста. В теории это позволяет провести атаку оракула, которая восстанавливает части исходного открытого текста.

Далее мы приводим более подробное описание атак Воденэ и Келси (дадим более подробное описание атаки Блайхенбахера, когда перейдём к атакам на криптографию с открытым ключом). Несмотря на все наши усилия, текст становится несколько техническим; поэтому, если вышеизложенного для вас достаточно, пропустите следующие два раздела.

Атака Воденэ

Чтобы понять атаку Воденэ, сначала нужно немного подробнее поговорить о блочных шифрах и режимах шифрования. «Блочный шифр» — это, как уже упоминалось, шифр, который принимает ключ и ввод определённой фиксированной длины («длина блока») и выдаёт зашифрованный блок той же длины. Блочные шифры широко используются и считаются относительно безопасными. Ныне вышедший на пенсию DES, который считают первым современным шифром, был блочным. Как упоминалось выше, то же самое верно и для AES, широко используемого сегодня.

К сожалению, блочные шифры имеют одну вопиющую слабость. Типичный размер блока составляет 128 бит, или 16 символов. Очевидно, что современная криптография требует работать с входными данными большего размера, и именно здесь появляются режимы шифрования. Режим шифрования — по сути хак: это способ каким-то образом применить блочный шифр, который принимает входные данные только определённого размера, к входным данным произвольной длины.

Атака Воденэ ориентирована на популярный режим работы CBC (Cipher Block Chaining, режим сцепления блоков шифротекста). Атака рассматривает базовый блочный шифр как волшебный неприступный чёрный ящик и полностью обходит его безопасность.

Вот диаграмма, которая показывает, как работает режим CBC:

Обведённый плюс означает операцию XOR (исключающее «ИЛИ»). Например, второй блок шифротекста получен:

1. Выполнением операции XOR на втором блоке открытого текста с первым блоком шифротекста.
   
2. Шифрованием полученного блока с помощью блочного шифра, используя ключ.

Поскольку CBC так интенсивно использует бинарную операцию XOR, давайте воспользуемся моментом, чтобы вспомнить некоторые её свойства:

• Идемпотентность:
• Коммутативность:
• Ассоциативность:
• Самообратимость:
• Побайтовость: байт n из = (байт n из ) (байт n из )

Как правило, эти свойства подразумевают, что если у нас есть уравнение, включающее операции XOR и одно неизвестное, его можно решить. Например, если мы знаем, что с неизвестным и известными и , то мы можем полагаться на вышеупомянутые свойства выше, чтобы решить уравнение для . Применив XOR с обеих сторон уравнения с , мы получаем . Через мгновение всё это станет очень актуальным.

Между нашим сценарием Алисы и атакой Воденэ есть два незначительных различия и одно главное отличие. Два незначительные:

• В сценарии Алиса ожидала, что открытые тексты заканчиваются символами a, bb, ccc и так далее. В атаке Воденэ жертва вместо этого ожидает, что открытые тексты заканчиваются N раз байтом N (то есть шестнадцатеричным 01 или 02 02, или 03 03 03 и так далее). Это чисто косметическое различие.
  
• В сценарии Алисы было легко сказать, приняла ли Алиса сообщение, по ответу «Неправильный фиктивный текст». В атаке Воденэ требуется больший анализ и важна точная реализация на стороне жертвы; но для краткости возьмём за данность, что этот анализ всё ещё возможен.

Главное различие:

• Поскольку мы используем не одну и ту же криптосистему, связь между контролируемыми злоумышленником байтами шифрованного текста и секретами (ключ и открытый текст), очевидно, будет другой. Поэтому злоумышленнику придётся использовать иную стратегию при создании шифротекстов и интерпретации ответов сервера.

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

Предположим, дан шифротекст CBC из 247 блоков, и мы хотим его расшифровать. Мы можем отправлять на сервер поддельные сообщения, как раньше могли отправлять поддельные сообщения Алисе. Сервер будет для нас расшифровывать сообщения, но не будет показывать расшифровку — вместо этого, опять же, как и в случае с Алисой, сервер сообщит только один бит информации: у открытого текста допустимое заполнение или нет.

Учтите, что в сценарии Алисы у нас были следующие отношения:

Назовём это «уравнением Алисы». Мы контролировали шифротекст; сервер (Алиса) сливал расплывчатую информацию о полученном открытом тексте; и это позволило нам вывести информацию о последнем факторе — ключе. По аналогии, если мы сможем найти такую связь для сценария CBC, то могли бы извлечь некоторую секретную информацию и там.

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

Назовём это «уравнением CBC».

В сценарии Алисы, контролируя шифротекст и наблюдая за утечкой информации о соответствующем открытом тексте, мы смогли организовать атаку, которая восстановила третий член уравнения — ключ. В сценарии CBC мы также контролируем шифротекст и наблюдаем утечки информации по соответствующему открытому тексту. Если аналогия имеет место, мы сможем получить информацию о . Предположим, мы действительно восстановили , что тогда? Ну, тогда мы можем сразу вывести весь последний блок открытого текста просто введя (который у нас есть) и полученный в уравнение CBC.

Теперь используем свойство побайтовости XOR:

Мы знаем первый и третий член. И мы уже видели, что это позволяет восстановить оставшийся член — последний байт из :

Это также даёт нам последний байт конечного блока открытого текста через уравнение CBC и свойство побайтовости.

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

у нас появилась новая способность. Теперь при подделке шифротекстов мы можем управлять последним байтом соответствующего открытого текста. Опять же, это связано с уравнением CBC и свойством побайтовости:

Поскольку мы теперь знаем второй член, то можем использовать наш контроль над первым для управления третьим. Мы просто вычисляем:

Раньше мы не могли этого сделать, потому что у нас ещё не было последнего байта. Как это нам поможет? Предположим, что теперь мы будем создавать все шифротексты так, что в соответствующих открытых текстах последний байт равен 02. Теперь сервер принимает заполнение только в том случае, если открытый текст заканчивается на 02 02. Поскольку мы исправили последний байт, это произойдёт только в том случае, если предпоследний байт открытого текста также равен 02. Мы продолжаем посылать поддельные шифротекстовые блоки, изменяя предпоследний байт, пока сервер не примет заполнение для одного из них. В этот момент мы получаем:

И мы восстанавливаем предпоследний байт точно так же, как восстановили последний. Продолжаем в том же духе: исправляем последние два байта открытого текста на 03 03, повторяем эту атаку для третьего с конца байта и так далее, в конечном итоге полностью восстанавливая.

Что насчёт остального текста? Обратите внимание, что значение на самом деле является . Мы можем поставить любой другой блок вместо , и атака всё равно будет успешной. Фактически, мы можем попросить сервер сделать для любых данных. В этот момент игра окончена — мы можем расшифровать любой шифротекст (ещё раз взгляните на диаграмму расшифровки CBC, чтобы убедиться в этом; и обратите внимание, что вектор IV общедоступен).

Этот конкретный метод играет решающую роль в атаке оракула, с которой мы столкнёмся позже.

Атака Келси

Близкий нам по духу Джон Келси излагал принципы, лежащие в основе многих возможных атак, а не только подробные детали конкретной атаки на конкретный шифр. Его статья 2002 года — это исследование возможных атак на зашифрованные сжатые данные. Вы думали, что для проведения атаки недостаточно одной только информации, что данные были сжаты перед шифрованием? Оказывается, достаточно.

Этот удивительный результат обусловлен двумя принципами. Во-первых, существует сильная корреляция между длиной открытого текста и длиной шифротекста; для многих шифров точное равенство. Во-вторых, когда выполняется сжатие, существует также сильная корреляция между длиной сжатого сообщения и степенью «шумности» открытого текста, то есть доли неповторяющихся символов (технический термин — «большая энтропия»).

Чтобы увидеть принцип в действии, рассмотрим два открытых текста:

Открытый текст 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Открытый текст 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

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

Шифротекст 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Шифротекст 2: DWKJZXYU

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

Келси далее указывает, что при определённых необычных обстоятельствах этот принцип также можно использовать для проведения атаки оракула. В частности, он описывает, как злоумышленник может восстановить секретный открытый текст, если может заставить сервер шифровать данные формы (открытый текст, за которым следует , пока он контролирует и может как-то проверять длину зашифрованного результата.

Опять же, как и в других атаках оракула, у нас есть соотношение:

Опять же, мы контролируем один член (

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

Чтобы проиллюстрировать, как такая атака может работать, используем вымышленную схему сжатия, которую мы только что придумали: TOYZIP. Он ищет строки текста, которые уже появлялись ранее в тексте, и заменяет их тремя байтами-заполнителями, которые указывают, где найти более ранний экземпляр строки и сколько раз он там встречается. Например, строка helloworldhello может быть сжата в helloworld[00][00][05] длиной 13 байт по сравнению с оригиналом 15-ти байт.

Предположим, взломщик пытается восстановить открытый текст формы

password=..., где сам пароль неизвестен. В соответствии с моделью атаки Келси, взломщик может попросить сервер сжать, а затем зашифровать сообщения формы (открытый текст, за которым следует ), где

— произвольный текст. Когда сервер закончил работу, он сообщает длину результата. Атака идёт следующим образом:

Взломщик: Пожалуйста, сожми и зашифруй открытый текст без каких-либо заполнений.

Сервер: Длина результата 14.

Взломщик: Пожалуйста, сожми и зашифруйте открытый текст, к которому добавлено password=a.

Сервер: Длина результата 18.

Взломщик отмечает: [оригинал 14] + [три байта, которые заменили password=] + a

Взломщик: Пожалуйста, сожми и зашифруй открытый текст, к которому добавлено password=b.

Сервер: Длина результата 18.

Взломщик: Пожалуйста, сожми и зашифруй открытый текст, к которому добавлено password=с.

Сервер: Длина результата 17.

Взломщик отмечает: [оригинал 14] + [три байта, которые заменили password=c]. Это предполагает, что оригинальный открытый текст содержит строку password=c. То есть пароль начинается с буквы c

Взломщик: Пожалуйста, сожми и зашифруй открытый текст, к которому добавлено password=сa.

Сервер: Длина результата 18.

Взломщик отмечает: [оригинал 14] + [три байта, которые заменили password=с] + a

Взломщик: Пожалуйста, сожми и зашифруй открытый текст, к которому добавлено password=сb.

Сервер: Длина результата 18.

(… некоторое время спустя…)

Взломщик: Пожалуйста, сожми и зашифруй открытый текст, к которому добавлено password=со.

Сервер: Длина результата 17.

Взломщик отмечает: [оригинал 14] + [три байта, которые заменили password=co]. По той же логике взломщик делает вывод, что пароль начинается с букв co

И так далее до тех пор, пока не будет восстановлен весь пароль.

Читателю простительно думать, что это чисто академическое упражнение и такой сценарий атаки никогда не возникнет в реальном мире. Увы, как мы вскоре увидим, в криптографии лучше не зарекаться.

Брендовые уязвимости: CRIME, POODLE, DROWN

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

CRIME

Если атака нацелена на браузер и сеть жертвы, что-то будет проще, а что-то — сложнее. Например, увидеть трафик жертвы легко: достаточно сидеть с ней в одном и том же кафе с WiFi. По этой причине потенциальным жертвам (т. е. всем) обычно рекомендуется использовать зашифрованное соединение. Будет посложнее, но всё равно возможно, выполнение HTTP-запросов от имени жертвы на какой-то сторонний сайт (например, Google). Злоумышленник должен заманить жертву на вредоносную веб-страницу со скриптом, который сделает запрос. Веб-браузер автоматически предоставит соответствующую сеансовую куку. Это кажется удивительным. Если Боб зашёл на

evil.com, неужели скрипт на этом сайте может просто попросить Google отправить пароль Боба по электронной почте на

attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (

Cross-Site Request Forgery, CSRF), и он был популярен примерно в середине 90-х. Сегодня, если

evil.com попробует такой трюк, Google (или любой уважающий себя сайт) обычно ответит: «Отлично, но ваш токен CSRF для этой транзакции будет… ммм…

три триллиона и семь. Пожалуйста, повторите это число». Современные браузеры применяют нечто под названием «политика одинакового происхождения» (same-origin policy), согласно которой скрипты на сайте A не получают доступа к информации, отправленной веб-сайтом B. Поэтому скрипт на

evil.com может отправлять запросы к google.com, но не может прочитать ответы или на самом деле завершить транзакцию.

Мы должны подчеркнуть, что если Боб не использует зашифрованное соединение, все эти защиты бессмысленны. Взломщик может просто прочитать трафик Боба и восстановить сеансовую куку Google. С этой кукой он просто откроет новую вкладку Google, не выходя из собственного браузера, и выдаст себя за Боба, не встречаясь с досадными политиками same-origin policy. Но, к сожалению для взломщика, такое встречается всё реже. Интернет в целом давно объявил войну незашифрованным соединениям, и исходящий трафик Боба, вероятно, зашифрован, нравится ему это или нет. Кроме того, с самого начала внедрения протокола трафик также сжимался перед шифрованием; это была обычная практика для уменьшения задержки.

Здесь в игру вступает CRIME (Compression Ratio Infoleak Made Easy, простая утечка через коэффициент сжатия). Уязвимость, которую показали в сентябре 2012 года исследователи безопасности Джулиано Риццо (uliano Rizzo) и Тай Дуонг (Thai Duong). Мы уже разобрали всю теоретическую базу, которая позволяет понять, что они сделали и как. Взломщик может заставить браузер Боба отправлять запросы в Google, а затем прослушивать ответы в локальной сети в сжатом, зашифрованном виде. Поэтому у нас есть:

Здесь взломщик контролирует запрос и имеет доступ к сниферу трафика, включая размер пакетов. Вымышленный сценарий Келси воплотился в жизнь.

Понимая теорию, авторы CRIME создали эксплоит, который может украсть сеансовые куки для широкого спектра сайтов, включая Gmail, Twitter, Dropbox и Github. Уязвимость затронула большинство современных веб-браузеров, в результате чего были выпущены патчи, которые молча похоронили функцию сжатия в SSL, чтобы она вообще не использовалась. Единственным защищённым от уязвимости стал почтенный Internet Explorer, который вообще никогда не использовал сжатие SSL.

POODLE

В октябре 2014 года команда безопасности Google навела шороху в сообществе безопасности. Они смогли эксплуатировать уязвимость в протоколе SSL, исправленную более десяти лет назад.

Оказалось, что хотя на серверах работает замечательный новенький TLSv1.2, многие оставили поддержку устаревшего SSLv3 ради обратной совместимости с Internet Explorer 6. Мы уже говорили об атаках на понижение, так что можете представить себе происходящее. Хорошо организованный саботаж протокола рукопожатия — и серверы готовы вернуться на старый добрый SSLv3, по сути отменив последние 15 лет исследований в сфере безопасности.

Для исторического контекста,

вот краткое резюме истории SSL вплоть до версии 2 от Мэтью Грина:

Transport Layer Security (TLS) — самый важный протокол безопасности в интернете. [..] почти каждая транзакция, которую вы проводите в интернете, зависит от TLS. [..] Но TLS не всегда был TLS. Протокол начал свою жизнь в Netscape Communications под названием "Secure Sockets Layer" или SSL. Ходят слухи, что первая версия SSL оказалась настолько ужасной, что разработчики собрали все распечатки кода и закопали на секретной свалке в Нью-Мексико. Как следствие, первая общедоступная версия SSL на самом деле является версией SSL 2. Она довольно страшненькая, и [..] это был продукт середины 90-х, которые современные криптографы рассматривают как «тёмные века криптографии». Многие из самых отвратительных криптографических атак, о которых мы знаем сегодня, ещё не были обнаружены. В результате разработчикам протокола SSLv2 пришлось по существу нащупывать путь в темноте, и они столкнулись с множеством ужасных монстров — к их огорчению и нашей выгоде, поскольку атаки на SSLv2 оставили бесценные уроки для следующего поколения протоколов.

После этих событий, в 1996 году, разочарованная компания Netscape переработала протокол SSL с нуля. Результатом стал SSL версии 3, который

исправил несколько известных проблем безопасности своего предшественника.

К счастью для взломщиков, «несколько» не означает «все». В целом, SSLv3 предоставлял все необходимые строительные блоки для запуска атаки Воденэ. Протокол использовал блочный шифр в режиме CBC и небезопасную схему заполнения (это исправили в TLS; следовательно, возникла необходимость в атаке на понижение). Если вы помните схему заполнения в нашем первоначальном описании атаки Воденэ, схема SSLv3 очень похожа.

Но, к несчастью для взломщиков, «похожая» не означает «идентичная». Схема заполнения SSLv3 имеет вид «N произвольных байт, за которыми следует число N». Попробуйте в таких условиях выбрать воображаемый блок зашифрованного текста и пройти через все этапы оригинальной схемы Воденэ: вы обнаружите, что атака успешно извлекает последний байт из соответствующего блока открытого текста, но дальше не проходит. Расшифровка каждого 16-го байта зашифрованного текста — отличный фокус, но это не победа.

Столкнувшись с неудачей, команда Google прибегла к крайнему варианту: они переключились на более мощную модель угроз — ту, которая использовалась в CRIME. Если предположить, что злоумышленник — это скрипт, запущенный на вкладке браузера жертвы, и он может извлечь сеансовые куки, атака всё равно остаётся впечатляющей. Хотя более широкая модель угроз менее реалистична, но в предыдущем разделе мы уже видели, что эта конкретная модель осуществима.

Учитывая такие более мощные возможности взломщика, теперь атака может продолжиться. Учтите, что злоумышленник знает, где в заголовке отображается зашифрованный сеансовый файл куки, и управляет длиной предшествующего ему HTTP-запроса. Поэтому он способен манипулировать HTTP-запросом так, чтобы выровнять последний байт куки в соответствии с концом блока. Теперь этот байт подходит для расшифровки. Можно просто добавить к запросу один символ, а предпоследний байт куки останется на том же месте и пригоден для подбора тем же методом. Атака продолжается таким образом, пока файл куки не будет восстановлен полностью. Это называется POODLE: Padding Oracle on Downgraded Legacy Encryption, заполнение оракула на пониженном устаревшем шифровании.

DROWN

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

соглашусь на это только через мой труп

превращалось в

соглашусь на это

; клиент и сервер могли встретиться в интернете, установить доверие и обменяться секретами перед глазами злоумышленника, который потом легко выдавал себя и за того, и за другого. Ещё и проблема с экспортной криптографией, которую мы упомянули при рассмотрении FREAK. Это были криптографические Содом и Гоморра.

В марте 2016 года команда исследователей из разных технических областей собралась вместе и сделала поразительное открытие: SSLv2 по-прежнему используется в системах безопасности. Да, злоумышленники больше не могли понижать современные сеансы TLS до SSLv2, поскольку эту дыру закрыли после FREAK и POODLE, но они всё ещё могут подключаться к серверам и инициировать сеансы SSLv2 самостоятельно.

Вы спросите, какое нам дело, что они там делают? У них уязвимый сеанс, но это не должно влиять на другие сеансы или безопасность сервера — правильно? Ну, не совсем. Да, так и должно быть в теории. Но нет — потому что генерация сертификатов SSL накладывает определённое бремя, в результате чего многие серверы используют одни и те же сертификаты и, как следствие, одни и те же ключи RSA для соединений TLS и SSLv2. Что ещё хуже, из-за бага OpenSSL в этой популярной реализации SSL фактически не работала опция «Отключить SSLv2».

Это сделало возможной кросс-протокольную атаку на TLS, которую назвали

DROWN

(Decrypting RSA with Obsolete and Weakened eNcryption, расшифровка RSA с устаревшим и ослабленным шифрованием). Напомним, что это не то же самое, что атака на понижение; взломщику не нужно действовать как «человек в середине» и не нужно вовлекать клиента для участия в небезопасном сеансе. Злоумышленники просто сами инициируют небезопасный сеанс SSLv2 с сервером, атакуют слабый протокол и восстанавливают закрытый серверный ключ RSA. Этот ключ также действителен для соединений TLS, и с этого момента никакая безопасность TLS не спасёт его от взлома.

Но для взлома нужна рабочая атака против SSLv2, которая позволяет восстановить не только конкретный трафик, но и секретный серверный ключ RSA. Хотя это и сложная постановка, но исследователи могли выбрать любую уязвимость, которую полностью закрыли после SSLv2. В конечном итоге они нашли подходящий вариант: атака Блайхенбахера, о которой мы упоминали ранее и которую подробно объясним в следующей статье. SSL и TLS защищены от этой атаки, но некоторые случайные функции SSL в сочетании с короткими ключами в криптографии экспортного класса, сделали возможным

определённую реализацию DROWN.

На момент публикации уязвимости DROWN были подвержены 25% топ-сайтов интернета, и атаку можно было провести со скромными ресурсами, доступными даже для озорных хакеров-одиночек. Для извлечения ключа RSA сервера требовалось восемь часов вычислений и $440, а SSLv2 сменил статус с «устаревшего» на «радиоактивный».

Погодите, а что насчёт Heartbleed?

Это не криптографическая атака в том смысле, как описанные выше; это переполнение буфера.

Cделаем перерыв

Мы начали с некоторых базовых методов: брутфорс, интерполяция, понижение, кросс-протокол и предвычисления. Затем рассмотрели одну продвинутую технику, возможно, главный компонент современных криптографических атак: это атака оракула. Мы довольно долго с ней разбирались — и поняли не только принцип в основе, но и технические детали двух конкретных реализаций: атаки Воденэ на режим шифрования CBC и атаки Келси на протоколы шифрования с предварительным сжатием.

При обзоре атак на понижение и с предварительными вычислениями мы кратко изложили атаку FREAK, которая использует оба метода, поскольку целевые сайты опускаются до слабых ключей, а затем повторно используют одни и те же ключи. Для следующей статьи мы оставили (очень похожую) атаку Logjam, которая нацелена на алгоритмы с открытым ключом.

Затем мы рассмотрели ещё три примера применения этих принципов. Во-первых, CRIME и POODLE: две атаки, которые полагались на способность взломщика внедрять произвольный открытый текст рядом с целевым открытым текстом, потом изучать ответы сервера и

затем

, используя методологию атаки оракула, использовать эту скудную информацию для частичного восстановления открытого текста. CRIME пошла по пути атаки Келси на сжатие SSL, в то время как POODLE вместо этого использовал вариант атаки Воденэ на CBC с тем же эффектом.

Затем мы обратили внимание на кросс-протокольную атаку DROWN, которая устанавливает с сервером соединение по устаревшему протоколу SSLv2, а потом восстанавливает секретные серверные ключи с помощью атаки Блайхенбахера. На данный момент мы пропустили технические детали этой атаки; как и Logjam, ей придётся подождать, пока мы хорошенько не изучим криптосистемы с открытым ключом и их уязвимости.

В следующем статье поговорим о продвинутых атаках — таких как метод встречи посередине (meet-in-the-middle), дифференциальный криптоанализ и атака «дней рождения». Совершим короткий набег на атаки по сторонним каналам, а затем примемся за самую вкуснятину — криптосистемы с открытым ключом.

Оригинал: https://research.checkpoint.com/cryptographic-attacks-a-guide-for-the-perplexed/

Перевел: https://habr.com/ru/users/m1rko/

by @CyberLifes2020

SELinux или Security Enhanced Linux — это улучшенный механизм управления доступом, разработанный Агентством национальной безопасности США (АНБ США) для предотвращения злонамеренных вторжений. Он реализует принудительную (или мандатную) модель управления доступом (англ. Mandatory Access Control, MAC) поверх существующей дискреционной (или избирательной) модели (англ. Discretionary Access Control, DAC), то есть разрешений на чтение, запись, выполнение.

У SELinux есть три режима:

1. Enforcing — запрет доступа на основании правил политики.
2. Permissive — ведение лога действий, нарушающих политику, которые в режиме enforcing были бы запрещены.
3. Disabled — полное отключение SELinux.

По умолчанию настройки находятся в /etc/selinux/config

Изменение режимов SELinux

Чтобы узнать текущий режим запустите

$ getenforce

Для изменения режима на permissive запустите следующую команду

$ setenforce 0

или, для изменения режима с permissive на enforcing, выполните

$ setenforce 1

Если вам нужно полностью отключить SELinux, то это можно сделать только через файл конфигурации

$ vi /etc/selinux/config

Для отключения измените параметр SELINUX следующим образом:

SELINUX=disabled

Настройка SELinux

Каждый файл и процесс помечается контекстом SELinux, в котором содержится дополнительная информация, такая как пользователь, роль, тип и т.д. Если вы впервые включаете SELinux, то сначала нужно настроить контекст и метки. Процесс назначения меток и контекста известен как маркировка. Чтобы начать маркировку, в файле конфигурации изменим режим на permissive.

$ vi /etc/selinux/config
SELINUX=permissive

После установки режима permissive, создадим в корне пустой скрытый файл с именем autorelabel

$ touch /.autorelabel

и перезагрузим компьютер

$ init 6

Примечание: мы используем режим permissive для маркировки, поскольку использование режима enforcing может привести к краху системы во время перезагрузки.

Не беспокойтесь, если загрузка застрянет на каком-то файле, маркировка занимает некоторое время. После завершения маркировки и загрузки вашей системы вы можете перейти к файлу конфигурации и установить режим enforcing, а также запустить:

$ setenforce 1

Теперь вы успешно включили SELinux на своем компьютере.

Мониторим логи

Возможно, у вас возникли какие-то ошибки во время маркировки или во время работы системы. Чтобы проверить, работает ли ваш SELinux правильно и не блокирует ли он доступ к какому-либо порту, приложению и т. д. нужно посмотреть логи. Лог SELinux находится в /var/log/audit/audit.log, но вам не нужно читать его целиком, чтобы найти ошибки. Можно использовать утилиту audit2why для поиска ошибок. Запустите следующую команду:

$ audit2why < /var/log/audit/audit.log

В результате вы получите список ошибок. Если ошибок в логе не было, то никаких сообщений отображаться не будет.

Настройка политики SELinux

Политика SELinux — это набор правил, которыми руководствуется механизм безопасности SELinux. Политика определяет набор правил для конкретного окружения. Сейчас мы изучим как настраивать политики, чтобы разрешить доступ к запрещенным сервисам.

1. Логические значения (переключатели)

Переключатели (booleans) позволяют изменять части политики во время работы, без необходимости создания новых политик. Они позволяют вносить изменения без перезагрузки или перекомпиляции политик SELinux.

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

$ semanage boolean -l

Эта команда выдаст список доступных переключателей с их текущим состоянием (включено/on или выключено/off) и описанием. Вы можете уточнить поиск, добавив grep, чтобы найти результаты, относящиеся только с ftp:

$ semanage boolean -l | grep ftp

и найдете следующее

ftp_home_dir        -> off       Allow ftp to read & write file in user home directory

Этот переключатель выключен, поэтому мы включим его с помощью setsebool $ setsebool ftp_home_dir on

Теперь наш ftp-демон сможет получить доступ к домашнему каталогу пользователя.
Примечание: вы также можете получить список доступных переключателей без описания, выполнив getsebool -a

2. Метки и контекст

Это наиболее распространенный способ реализации политики SELinux. Каждый файл, папка, процесс и порт помечаются контекстом SELinux:

• Для файлов и папок метки хранятся как расширенные атрибуты в файловой системе и могут быть просмотрены следующей командой:
  $ ls -Z /etc/httpd
• Для процессов и портов маркировкой управляет ядро, и можно посмотреть эти метки следующим образом:

процесс

$ ps –auxZ | grep httpd

порт

$ netstat -anpZ | grep httpd

Пример
Теперь давайте рассмотрим пример, чтобы лучше понять метки и контекст. Допустим, у нас есть веб-сервер, который вместо каталога /var/www/html/ использует /home/dan/html/. SELinux сочтет это нарушением политики, и вы не сможете просматривать ваши веб-страницы. Это потому, что мы не установили контекст безопасности, связанный с HTML-файлами. Для просмотра контекста безопасности по умолчанию используйте следующую команду:

$ ls –lz /var/www/html
 -rw-r—r—. root root unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/

Здесь мы получили httpd_sys_content_t в качестве контекста для html-файлов. Нам нужно установить этот контекст безопасности для нашего текущего каталога, который сейчас имеет следующий контекст:

-rw-r—r—. dan dan system_u:object_r:user_home_t:s0 /home/dan/html/

Альтернативная команда для проверки контекста безопасности файла или каталога:

$ semanage fcontext -l | grep '/var/www'

Мы также будем использовать semanage для изменения контекста, после того как найдем правильный контекст безопасности. Чтобы изменить контекст /home/dan/html, выполните следующие команды:

$ semanage fcontext -a -t httpd_sys_content_t ‘/home/dan/html(/.*)?’
$ semanage fcontext -l | grep ‘/home/dan/html’
/home/dan/html(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
$ restorecon -Rv /home/dan/html

После того, как контекст изменен с помощью semanage, команда restorecon загрузит контекст по умолчанию для файлов и каталогов. Наш веб-сервер теперь сможет читать файлы из папки /home/dan/html, поскольку контекст безопасности для этой папки был изменен на httpd_sys_content_t.

3. Создание локальных политик

Могут возникнуть ситуации, когда вышеуказанные методы бесполезны для вас, и вы получаете ошибки (avc/denial) в audit.log. Когда такое происходит, то нужно создать локальную политику (Local policy). Все ошибки вы можете найти с помощью audit2why, как было описано выше.

Для устранения ошибок можно создать локальную политику. Например, мы получаем ошибку, связанную с httpd (apache) или smbd (samba), мы grep’аем ошибки и создаем для них политику:

apache
$ grep httpd_t /var/log/audit/audit.log | audit2allow -M http_policy
samba
$ grep smbd_t /var/log/audit/audit.log | audit2allow -M smb_policy

Здесь http_policy и smb_policy — это названия локальных политик, которые мы создали. Теперь нам нужно загрузить эти созданные локальные политики в текущую политику SELinux. Это можно сделать следующим образом:

$ semodule –I http_policy.pp
$ semodule –I smb_policy.pp

Наши локальные политики были загружены, и мы не должны больше получать никаких avc или denail в audit.log.

Это была моя попытка помочь вам понять SELinux. Я надеюсь, что после прочтения этой статьи вы будете чувствовать себя с SELinux более комфортно.

Оригинал: https://linuxtechlab.com/beginners-guide-to-selinux/

Перевел: vlstrochkov

by @Cyberlifes

В июне сообщество администраторов в Telegram захлестнула волна воровства каналов. Аккаунты мошенников разные, но почерк один — покупка канала и предварительный созвон в Skype. Чем новый способ отличается от прежних и как обезопасить себя? Сейчас расскажу.

Покупка и продажа каналов в Telegram — это не простой и не самый безопасный процесс. В связи с чем и продавец, и покупатель стараются быть максимально осторожными. Чаще всего сделки проводятся через зарекомендовавших себя гарантов.

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

Как воровали раньше?

Методы угона существуют самые разные: подделка аккаунта гаранта, проведение сделки через фальшивого гаранта, оплата через посторонний сервис мошенника. Но во многих схемах угона повторяется один момент — подделка аккаунта. Каким образом, спросишь?

Это два разных аккаунта администратора одного канала. Какие отличия в логинах ты можешь заметить? На первый взгляд они выглядят идентично. Но давай сравним оба логина, приведя их к нижнему регистру.

Теперь различия очевидны. Мошенник вместо строчной буквы l указал заглавную i. Подобный обман — с подделкой схожих символов Unicode — используют мошенники в самых разных схемах. В нашем случае — при угоне каналов.

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

После этого невнимательный продавец, не заметив подмены, выполняет все требования для продажи канала, но не получает взамен оговоренные деньги.

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

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

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

Покупатель просто переведет деньги на посторонний сервис, а позже обнаружит, что этот сайт больше не существует. Продавец, в свою очередь, может увидеть, что на сайте поступили деньги, и передать все права на канал в Telegram покупателю. При попытке вывести деньги выяснится, что сделать это невозможно.

В подобных схемах в сообществе администраторов каналов фигурировали сайты einsider.ru, sellerpay.pro и okpay.com.ru. Собственно, ни один из них на текущий момент не доступен.

Последний сервис OkPay как раз участвовал в обмане администратора канала «Slang Bang! / Слэнг Бэнг!». 27 сентября 2018 года админ не смог вывести деньги за продажу канала и понял, что сервис мошеннический. Сумма сделки составляла 1,9 миллиона рублей.

Что за новый способ угона?

Мошенники придумали способ угона, в основе которого лежит человеческая наивность и доверчивость. На первый взгляд схема не вызывает подозрений. Для начала мошенник, как обычно, пишет администратору канала сообщение с предложением купить канал. Чтобы откинуть сомнения и усыпить бдительность администратора, задает ряд уточняющих вопросов. Нормальных вопросов и при совершенно честной сделке.

• Какие условия передачи канала?
• Какие сервисы для наполнения контента использует администратор?
• Через какого гаранта будет проводиться сделка?
• Какие источники монетизации канала использует администратор?

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

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

Мошенник пытается авторизоваться со своего устройства по номеру админа. Реальному администратору приходит пятизначный код от Telegram для авторизации. И этот код злоумышленник видит во время текущей трансляции в скайпе и, следовательно, авторизовывается.

После этого вопрос только в скорости. Либо реальный администратор успеет понять, что происходит, закроет новый сеанс и выключит трансляцию в Skype, либо мошенник успеет выполнить три оставшихся действия для угона канала:

1. Удалить всех администраторов из канала.
2. Добавить свой мошеннический аккаунт в список администраторов.
3. Перейти по адресу my.telegram.org/auth и удалить аккаунт реального администратора.

Если реальный администратор не успеет среагировать, то в результате этих действий потеряет как свой канал, так и свой аккаунт.

Кто пострадал?

Число пострадавших каналов понемногу возрастает, а мошенники регулярно меняют аккаунты. На текущий момент в список угнанных каналов входят: futbolruonline (80 тысяч подписчиков), Rasimlar57 (63 тысячи), gifki_on (133 тысячи), topgif_1 (38 тысяч), rasmchalaa (63 тысячи).

В целом у таких каналов есть несколько дальнейших путей развития.

1. Обманутый администратор платит мошеннику выкуп и получает канал обратно.
2. Мошенник перепродает канал или самостоятельно перестраивает его тематику под казино или букмекерские конторы.
3. Канал забрасывается на время для дальнейшей перепродажи.

Как обезопасить себя?

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

Метка выдается по жалобам пользователей через аккаунт @notoscam после решения модераторов Telegram. Так, например, заблокировали фейковый аккаунт @Pr_BiIrot после сообщения от администратора.

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

1. Открой настройки Telegram.
2. Выбери пункт «Конфиденциальность».
3. Нажми «Настроить двухфакторную аутентификацию».
4. Укажи пароль, подсказку и email для восстановления.

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

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

Источник: xakep.ru

by @Cyberlifes

Какие риски мы берем на себя, устанавливая систему «умный дом»? Ту, что рулит лампочками и чайником с приложения на смартфоне, внутри локальной сети и удаленно. Если на умную систему завязана безопасность и управление замками (как в случае Amazon Key) — то понятно какие. Если нет, то теоретически можно представить опасность программного вывода из строя какой-нибудь кофеварки с последующим пожаром. Но лучше не фантазировать, а знать наверняка.

Специалисты команды ICS CERT из «Лаборатории Касперского» решили провести натурный тест на умном доме одного из сотрудников компании (новость, пост в блоге, техническая статья). Взлом произошел успешно: кофеварка не пострадала, но контроль над системой получить удалось, пусть и с парой (вполне реалистичных) допущений в ходе эксперимента. Одним из неприятных последствий этой атаки стала утечка персональных данных: координаты дома и, что самое печальное, геолокация смартфона. Впрочем, эксперимент закончился на позитивной ноте: производитель системы умного дома успешно закрыл уязвимости.

В технической статье довольно много места отведено относительно скучным, но важным моментам: что НЕ удалось взломать, и как проходил анализ системы умного дома на наличие потенциальных уязвимостей. Перед началом эксперимента исследователи уже знали производителя системы. Им оказалась компания Fibaro, выпускающая ассортимент собственных устройств для современного умного дома, а также обеспечивающая интеграцию с устройствами сторонних производителей. Более того, владелец дал важную подсказку — постоянный IP для входа в админку. Кстати, сама Fibaro не рекомендует открывать доступ к контроллеру по IP — только через облачную систему. В данном эксперименте эта сознательно оставленная владельцем лазейка сыграла свою роль.

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

Следующий шаг — анализ прошивки устройства и WebAPI. Обычно на таком анализе все заканчивается, и выходит новость в стиле «в устройстве обнаружен вшитый пароль». Но в случае Fibaro очевидных прорех в безопасности не было. Зато была получена полезная информация о реализации части управляющей логики на PHP. Без авторизации контроллер отдает только серийный номер устройства, и для взлома железки эта информация бесполезна. Зато, как выяснилось, она позволяет взломать облачную часть сервиса.

Доступ к облаку, в свою очередь, позволяет без авторизации получать резервные копии базы данных SQLite, содержащие все настройки устройства, и загружать свои. Теоретически обход авторизации давал возможность (до исправления уязвимости) загрузить резервные копии всех пользователей облачной системы. Анализ реальной базы атакуемого устройства обеспечил доступ к приватной информации, включая координаты дома и смартфона, на котором установлено управляющее приложение. Уже это — серьезная проблема, так как (с некоторыми ограничениями) она позволяет определить, когда владельца системы нет дома.

Помимо этого, в базе была полная информация о подключенных IoT-устройствах, а также пароль для доступа к настройкам, но захешированный с добавлением «соли». Анализ прошивки показал, что «соль» не рандомная, а прочно зашита в устройство. Теоретически очень простой пароль может быть взломан, но в данном случае не вышло. База SQLite также содержала открытые пароли для подключения к другим устройствам внутри сети: если бы эти пароли совпадали с основным, контроллер также можно было бы легко взломать.

Но опять не получилось: владелец системы оказался знаком с базовыми рекомендациями по безопасности и не использовал один и тот же пароль для разных устройств. Поэтому пришлось применить социальную инженерию. Уязвимость в облачной системе, позволяющая проводить ряд действий без авторизации, зная только серийный номер устройства (который отдается «бесплатно», если есть доступ к админке извне), сделала возможным следующий сценарий. В «облако» была загружена подготовленная резервная копия устройства, в которую был внедрен вредоносный скрипт. Сообщение о необходимости «обновить» устройство через штатные возможности облачной системы было отправлено владельцу (по электронной почте и SMS).

Так как владелец системы знал об эксперименте, он сразу понял, что это не настоящий патч. Но в целом это вполне реальный сценарий, когда пользователю через привычный канал связи приходит правдоподобное сообщение, поэтому резервная копия была установлена. Вредоносный код был выполнен с системными правами благодаря недосмотру в PHP-коде, вызывающему выполнение bash-скрипта:

Здесь параметр, задающийся пользователем (в нормальных условиях даже администратор системы не имеет прав суперпользователя на устройстве), попадает в аргумент для командной строки. Недостаточная проверка аргументов позволила выполнить с правами «рута» произвольный код и наконец-то получить полный контроль над устройством. Параллельно была найдена, но не использована возможность проведения SQL-инъекции:

Взламывать кофеварку в реальном доме исследователи не планировали, поэтому в качестве «привета» поменяли мелодию будильника. Упомянутые уязвимости и в облачной системе, и в коде контроллера были закрыты. По понятным причинам конкретные методы обхода защиты в технической статье не раскрываются — во избежание использования их настоящими злоумышленниками на устройствах, которые еще не обновились. Зато в этом эксперименте хорошо показано то, что обычно остается за рамками новостных заголовков: множество путей исследования защиты устройства, большинство из которых оканчивается ничем. В реальном опыте и производитель устройства, и его владелец смогли избежать простейших ошибок безопасности, таких как вшитые и повторно используемые пароли. Тем не менее, было выявлено достаточное количество проблем, способное привести как минимум к утечке приватных данных, а в худшем случае — к обходу систем безопасности.

Источник: habr.com

By t.me/Cyberlifes

Обратная разработка позволяет не только разобраться в существующих приложениях, но и модифицировать их. В этом смысле приложения на Android — клад для начинающего хакера и настоящий аттракцион для любителя. Сегодня мы разберем несколько приложений, чтобы потренироваться в реверс-инжиниринге и узнать о подлинных возможностях твоего смартфона.Какое приложение мы будем препарировать?

Я выбрал для своих целей VK Admin — программу для управления сообществами «ВКонтакте» со смартфона. В нем не предусмотрена темная тема, поэтому мы с тобой попробуем эту тему добавить.

Собираем и разбираем

Сначала извлечем все ресурсы приложения, используя утилиту apktool — она распаковывает и запаковывает файлы пакетов APK, которые хранятся в сжатом, бинарном виде, и дизассемблирует программный код, заключенный в них.Чтобы получить установочный пакет, можно воспользоваться Android Debugging Bridge — системой для отладки программ на устройстве. В *nix-подобных системах ADB ставится стандартно, с помощью пакетного менеджера, а в Windows — идет в составе Android Studio или Android SDK Platform Tools.В первую очередь установим приложение из Google Play Store на смартфон, подключим его к компьютеру с помощью USB, затем воспользуемся ADB для переноса пакета приложения на компьютер и извлечем его содержимое.

Для создания подписи в первый раз нужно воспользоваться утилитой keytool (входит в Java Development Kit):

Меняем цветовые схемы

Цвета в приложении можно настроить несколькими способами:

• использовать встроенные цвета, к примеру @android:color/white;
• создать палитру собственных цветов в файле colors.xml, которые затем используются в виде @color/text_primary;
• задать цвет шестнадцатеричным кодом, главное — не забывай, что цвета в приложении записаны в формате #AARRGGBB — прозрачность на первом месте;
• воспользоваться параметрами setTextColor,setBackgroundColor внутри кода Java или Kotlin.

Все эти способы жизнеспособны и постоянно используются.

colors.xml

Цветовая палитра приложения содержится в файле com.vk.admin/res/values/colors.xml. Структура файла выглядит так:

Каждый цвет, который в дальнейшем используется в статичных экранах приложения, записан здесь. Наша задача — изменить цвета, самый простой способ это сделать — инвертировать. Для записи цвета в формате hex можно отнять из 255 каждый компонент: R, Gи B, то есть 255 - R, 255 - G, 255 - B. Параметры @android:color/white и @android:color/black можно изменить вручную.

styles.xml

В файле com.vk.admin/res/values/styles.xml заданы цвета, но только некоторые. Этот файл используется самими разработчиками, когда они хотят сделать несколько цветовых схем приложения. Если же этих схем нет, работать приходится нам с тобой.

Некоторые цвета текста и фона заданы именно здесь, поэтому их нужно изменить аналогично с colors.xml.

Layout

В папке com.vk.admin/res/ находятся описания экранов приложения.

• com.vk.admin/res/layout/ — универсальное хранилище экранов для всех смартфонов. Если нет каких-то специальных указаний, то будут использованы эти ресурсы;
• com.vk.admin/res/layout-v``XX (где XX — версия SDK смартфона, зависит от версии Android на устройстве) используются для работы с самыми передовыми элементами UI;
• остальные com.vk.admin/res/layout-... задают специфичные экраны приложения для ориентации устройства, разрешения и так далее.

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

Но закончить мы пока не можем — есть некоторые экраны, цвет фона и текста которых задан не в файлах .xml, а прямо в исполняемом коде приложения. Туда нам и дорога.

Smali

Внутри приложений на Android используется собственный формат файлов — .dex, или Dalvik EXecutable, и собственная виртуальная машина, чтобы эти файлы исполнять, — Dalvik.

Как и с любым компилируемым языком, для .dex есть байт-код — smali — человекочитаемый и понятный с первого взгляда.

Машина Dalvik, в отличие от JVM, — регистровая, а не стековая. Регистры не имеют типов и могут хранить всё: числа, строки, экземпляры классов. При этом язык smali строго типизирован.

Вот небольшая последовательность инструкций, чтобы вывести содержимое регистра v0 в лог.

1. const-string v1, "MyTag" — записать в регистр v1 строку "MyTag".
2. invoke-static {v0}, Ljava/lang/String;->valueOf(I)Ljava/lang/String; — вызвать функцию String.valueOf(v0). Здесь static означает, что функция встроена в виртуальную машину; {v0} — список аргументов; L показывает, что сразу за ним идет название объекта, класса и так далее; java, lang, String; — тип строки; I — тип числа, Integer; а все вместе (->valueOf(I)Ljava/lang/String;) говорит нам о том, что вызывается функция valueOf от одного аргумента и возвращает она строку.
3. move-result-object v2 — записать результат предыдущей операции в v2.
4. invoke-static {v1, v2}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I — залогировать содержимое v2 под тегом из v1.

Если не удается понять, что значит тот или иной регистр или что делает та или иная функция, используй декомпилятор smali в Java — Jadx.

Использовать Jadx просто — нужно лишь выбрать файл и открыть его, код будет автоматически декомпилирован и показан.

Рекомендую ознакомиться с документацией по байт-коду Dalvik VM.

setBackgroundColor

Для некоторых экранов приложения используется параметр setBackgroundColor(I)V, который устанавливает цвет фона. Часто это не статичные экраны, а динамические: с поддержкой скролла, различные списки и карточки.

invoke-virtual {v1, v0}, Landroid/webkit/WebView;->setBackgroundColor(I)V

Эта строка занимается изменением. Чтобы изменить цвет, нужно его записать в регистр, а затем передать в функцию вместо настоящего.

const v12, -0x1000000
#### Эквивалент 0xFF000000 — черного

invoke-virtual {v1, v12}, Landroid/webkit/WebView;->setBackgroundColor(I)V

Теперь пройдись по всем файлам и замени цвет.

Бывают случаи на порядок проще.

const v2, -0x1
#### Здесь -0x1 == 0xFFFFFFFF — белый цвет

invoke-virtual {v1, v2}, Landroid/support/v7/widget/CardView;->setBackgroundColor(I)V

Нужно просто изменить -0x1 на -0x1000000, и приложение погрузится во тьму.

Стоит быть внимательным и пытаться разобраться в коде: иногда оптимизатор кода будет перемещать инструкции const вверх, и ты можешь их не заметить.

setTextColor

Иногда текст, который меняется в ходе работы с приложением, может менять свой цвет. За это отвечает параметр setTextColor(I)V, второй аргумент которого можно подменить на нужный, в нашем случае — белый.

#### Меняем цвет
const p1, -0x1
#### на белый

invoke-virtual {v0, p1}, Landroid/widget/TextView;->setTextColor(I)V

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

Меняем функциональность приложения

Чтобы ощутить всю мощь smali, давай попробуем изменить какую-то часть приложения. Например, обойдем проверку на внутренние покупки.

Возьмем другое приложение — ISS Detector. Оно показывает положение МКС над Землей. В нем можно купить расширения: показ комет, планет, Луны, телескопа «Хаббл».

При копировании приложения на компьютер может возникнуть проблема: в составе приложения не один и не два, а целых три файла apk!

$ adb shell pm path com.runar.issdetector
package:/data/app/com.runar.issdetector-dtgy8_hlf1y-cekrg1_W-A==/base.apk
package:/data/app/com.runar.issdetector-dtgy8_hlf1y-cekrg1_W-A==/split_config.en.apk
package:/data/app/com.runar.issdetector-dtgy8_hlf1y-cekrg1_W-A==/split_config.xxhdpi.apk

Копируем все. При переустановке приложения файлы split_config.en.apk и split_config.xxhdpi.apk потеряются, а без них приложение будет вылетать. Поэтому их нужно будет переподписать: зайти в них как в архивы ZIP, удалить папку META_INF и прогнать через стандартную процедуру утилиты jarsigner. Основной же файл мы будем препарировать с помощью apktool.

Покупками в приложении занимается интерфейс IInAppBillingService. Для него прописана обертка com.runar.issdetector.util: IabHelper, IabResult, Purchase, Security, Inventory.

В этом приложении можно не идти напролом, обманывая сервис покупок. Проще заставить приложение думать, что все уже куплено. В этом нам поможет Inventory.smali.

В особо сложных случаях такой трюк провернуть не удается, и тогда приходится подменять данные, заставляя сервис ложно сообщать о совершенных покупках. Подробнее об этом можно почитать в материале компании Securing Apps (PDF).

Открыв файл, ты увидишь поле mPurchaseMap<String; Purchase>, которое содержит в себе все покупки: номер товара, сопоставленный с покупкой, которую совершил пользователь.

.field mPurchaseMap:Ljava/util/Map;
    .annotation system Ldalvik/annotation/Signature;
        value = {
            "Ljava/util/Map<",
            "Ljava/lang/String;",
            "Lcom/runar/issdetector/util/Purchase;",
            ">;"
        }
    .end annotation
.end field

Далее в коде мы видим строку hasPurchase(String sku) -> boolean, которая проверяет, совершал ли пользователь покупку. Для этого делается проверка на существование ключа sku в mPurchaseMap.

.method public hasPurchase(Ljava/lang/String;)Z
    .locals 1

    .line 45
    iget-object v0, p0, Lcom/runar/issdetector/util/Inventory;->mPurchaseMap:Ljava/util/Map;

    invoke-interface {v0, p1}, Ljava/util/Map;->containsKey(Ljava/lang/Object;)Z

    move-result p1

    return p1
.end method

А что будет, если в любом случае отдавать true?

.method public hasPurchase(Ljava/lang/String;)Z
    .locals 1

    const p1, 0x1

    return p1
.end method

Собираем приложение и устанавливаем его.

$ adb install-multiplie com.runar.issdetector.apk split_config.xxhdpi.apk split_config.en.apk
Success

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

Источник: xakep.ru

by @CyberLifes

Корпорация Google опубликовала исследование «Насколько эффективна базовая гигиена учетной записи для предотвращения её кражи» о том, что может сделать владелец учетной записи, чтобы её не украли злоумышленники. Представляем вашему вниманию перевод этого исследования. Правда самый эффективный способ, который используется в самой Google, в отчет не включили. Пришлось мне самому написать об этом способе в конце.

Каждый день мы защищаем пользователей от сотен тысяч попыток взлома аккаунтов.

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

Фишинговая атака — попытка обмануть пользователя таким образом, чтобы он добровольно передал злоумышленнику информацию, которая будет полезна в процессе взлома. Например, путем копирования интерфейса легального приложения. Атаки с помощью автоматических ботов — массовые попытки взлома не направленные на конкретных пользователей. Обычно осуществляются с помощью общедоступного программного обеспечения и доступны для использования даже неподготовленным «взломщикам». Злоумышленники ничего не знают об особенностях конкретных пользователей — они просто запускают программу и «ловят» все плохо защищенные ученые записи вокруг. Целевые атаки — взломы конкретных учетных записей, при которых о каждой учётке и её владельце собирается дополнительная информация, возможны попытки перехвата и анализа трафика, а также применение более сложных инструментов взлома. (Примечание переводчика)

Мы объединились с исследователями из New York University и University of California, чтобы выяснить, насколько эффективно базовая гигиена учетных записей предотвращает их «угоны».

Годовое исследование о широкомасштабных и целевых атаках было представлено в среду на собрании экспертов, политиков и пользователей под названием The Web Conference.

Наши исследования показывают, что простое добавление номера телефона в вашу учетную запись Google может блокировать до 100% атак от автоматических ботов, 99% массовых фишинговых атак и 66% целевых атак, имевших место в ходе нашего расследования.

Автоматическая проактивная защита Google от «угона» учётной записи

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

Если вы вошли в свой телефон или указали номер телефона в параметрах учетной записи, мы можем обеспечить такой же уровень защиты, как и с помощью двухэтапной проверки. Мы обнаружили, что код SMS, отправленный на номер телефона для восстановления, помог заблокировать 100% автоматических ботов, 96% массовых фишинговых атак и 76% целевых атак. А запросы на устройстве с требованием подтвердить операцию, являющиеся более безопасной заменой SMS, помогли предотвратить 100% автоматических ботов, 99% массовых фишинговых атак и 90% целевых атак.

Защита, основанная как на владении определенными устройствами, так и на знании определенных фактов, помогает противостоять автоматическим ботам, а защита, основанная на владении определенными устройствами — для предотвращения фишинга и даже целевых атак.

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

Учитывая преимущества подобной защиты, можно было бы спросить, почему мы не требуем использовать её для каждого входа в систему. Ответ заключается в том, что это создало бы дополнительные сложности для пользователей (особенно для неподготовленных — прим. перев.) и повысило бы риск блокировки учетной записи. В ходе эксперимента выяснилось, что 38% пользователей не имели доступа к своему телефону при входе в учетную запись. Еще 34% пользователей не смогли вспомнить свой дополнительный адрес электронной почты.

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

Разбираемся в атаках «взломать по найму»

Там, где большинство автоматических средств защиты блокируют большинство ботов и фишинговых атак, более пагубными становятся целевые атаки. В рамках наших постоянных усилий по мониторингу угроз взлома, мы постоянно выявляем новые криминальные группы «взлома по найму», которые просят за взлом одного аккаунта за в среднем 750 долларов США. Эти злоумышленники часто полагаются на фишинговые электронные письма, которые выдают себя за членов семьи, коллег, правительственных чиновников или даже за Google. Если цель не сдается при первой попытке фишинга, последующие атаки продолжаются более месяца.

Пример фишинг-атаки «человек посередине», которая проверяет правильность пароля в режиме реального времени. После этого на фишинговой странице предлагается жертвам ввести коды аутентификации SMS для доступа к учетной записи жертвы.

По нашим оценкам, только один из миллиона пользователей подвергается столь высокому риску. Злоумышленники не нацелены на случайных людей. Хотя исследования показывают, что наша автоматическая защита может помочь задержать и даже предотвратить до 66% целевых атак, которые мы изучали, мы по-прежнему рекомендуем, чтобы пользователи с высоким уровнем риска регистрировались в нашейпрограмме дополнительной защиты. Как было замечено во время нашего расследования, пользователи, которые используют исключительно ключи безопасности (то есть — двухэтапную аутентификацию с помощью присылаемых пользователям кодов — прим. перев.), стали жертвами целевого фишинга.

Потратьте немного времени, чтобы защитить свой аккаунт

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

Как показывают наши исследования, одна из самых простых вещей, которые вы можете сделать для защиты своей учетной записи Google — это задать номер телефона. Для пользователей с высоким уровнем риска, таких как журналисты, общественные активисты, лидеры бизнеса и команды политических кампаний, наша программа Advanced Protectionпоможет обеспечить высочайший уровень безопасности. Вы также можете защитить свои учетные записи сторонних сервисов (не Google) от взломов паролей, установив расширение Chrome Password Checkup.

Интересно, что Google не следует тем советам, которые сам же даёт своим пользователям. Google использует аппаратные токены

для двухфакторной аутентификации более чем 85 000 своих сотрудников. По сообщениям представителей корпорации с момента начала использования аппаратных токенов не было зафиксировано ни одной кражи учетной записи. Сравните с цифрами, представленными в этом отчете. Таким образом видно, что использование аппаратных

токенов для двухфакторной аутентификации единственный надежный способ защиты как учетных записей, так и информации (а в ряде случаев еще и денег).

Для защиты учетных записей Google используются токены, созданные по стандарту FIDO U2F, например такой. А для двухфакторной аутентификации в операционных системах Windows, Linux и MacOS используются криптографические токены.

источник: habr.com

by @cyberlifes