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

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

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

Защита резервных копий: пока всё просто

Система резервного копирования iOS – воистину вне конкуренции. Нечто подобное в плане локальных бэкапов мы видели в BlackBerry 10, но эта система мертва, а до «облака» дело у BlackBerry так и не дошло. (Кстати, в ОС BlackBerry 10 резервные копии шифровались всегда, а ключ – всегда хранился в облаке – или в BlackBerry ID пользователя, или в корпоративной сети). Вполне прилично было сделано резервное копирование в «облако» и в Windows Phone 8.1, а также в Windows 10 Mobile – но и эти системы ныне мертвы, а локальных бэкапов в них никогда не было.

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

В чём проблема?

Я часто пишу статьи на тему информационной безопасности. Иногда получается понятно для неспециалиста, иногда, вероятно, не очень. «Что-то я вообще не понял посыла статьи […] в чем проблема?», «имхо, проблема с icloud, слегка притянута за уши», ну и бессмертное – «я не стал заморачиваться, мне нечего скрывать». Отлично, давайте посмотрим, стоит ли вам что-либо скрывать.

Celebgate: «проблема с iCloud слегка притянута за уши»

С момента выхода нашего первого продукта для извлечения данных из iCloud прошло более пяти лет. Ключ от продукта Elcomsoft Phone Password Breaker (сейчас у него другое название), который на тот момент мы продавали исключительно правоохранительным органам, был украден и попал в руки хакерской группировки.

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

Защита от взлома кода блокировки экрана

Основной рассказ о системе безопасности iOS ещё впереди. Сейчас же я хочу акцентировать внимание на одной достаточно спорной особенности iOS, которая ставит безопасность всех данных пользователя как в устройстве, так и в облачной учётной записи в зависимость от одного единственного фактора: кода блокировки экрана. Если известен код блокировки экрана, из iPhone можно извлечь практически все данные, включая пароли от учётных записей. Защита резервных копий паролем? Нет, не слышали: она как бы есть, но сбросить её, зная код блокировки – дело нескольких секунд. Отвязать украденный телефон от iCloud? Если известен код блокировки – вообще без проблем; пароль от iCloud меняется в несколько секунд, причём старый пароль от Apple ID не нужен. Двухфакторная аутентификация? Прекрасно, обязательно включите её! Вот только если код блокировки известен, всё устройство целиком становится тем самым вторым фактором. Скромно упомяну такие вещи, как база данных паролей пользователя в iCloud, его сообщения SMS и iMessage, а также данные «Здоровья», которые наши программы могут расшифровать при помощи кода блокировки (при необходимости сбросив предварительно пароль от «облака» при помощи всё того же единственного кода блокировки).

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

Наверное, я никогда не устану говорить о преимуществах физического анализа. Здесь и доступ ко всему содержимому файловой системы, и расшифровка всех записей из Связки ключей (а это – пароли, включая, кстати, пароли к кошелькам криптовалюты и «секретным» чатам). Тут извлечение данных из всех приложений (а не только тех, разработчики которых разрешили резервное копирование) и доступ к скачанным сообщениям электронной почты, чатам и перепискам в самых разнообразных приложениях, включая хорошо защищённые (помашем рукой пользователям Telegram и Signal).

Как добраться до самого интересного? Разумеется, нам нужен низкоуровневый доступ к данным, который невозможен без получения прав суперпользователя. А как получить права суперпользователя? Если вы – не работник полиции или спецслужб из США, Израиля или ЕС, то вариант один: установкой джейлбрейка. Сегодня я расскажу о рисках и последствиях физического анализа устройств, связанных с использованием джейлбрейка для извлечения данных.

В прошлой статье я рассказал о режиме ограничения доступа к аксессуарам в устройствах под управлением iOS. В статье я акцентировал внимание на особенности iOS, которая ставит безопасность данных пользователя в зависимость от единственного «непреодолимого» защитного рубежа: кода блокировки экрана. Практически все защитные меры так или иначе завязаны на код блокировки. Apple периодически (по сложному расписанию) отключает в iPhone биометрику, заставляя пользователя вводить пасскод для разблокировки экрана. Включил или перезагрузил телефон – нужен код блокировки. Использовал режим SOS – код блокировки. Телефон не использовался несколько часов – снова код блокировки. Подключаешь к компьютеру – и опять введи код блокировки. Хочешь установить пароль на резервную копию? Начиная с iOS 13 и здесь нужен код блокировки.

Казалось бы, пользователю достаточно установить длинный и сложный код блокировки, чтобы полностью обезопасить устройство. Однако такое поведение ничем не отличается от гипотетической системы безопасности здания, в котором охраняется только вход – при этом двери в кабинеты всегда нараспашку, на компьютерах в офисах нет никаких паролей, а к внутренней сети с любого устройства можно получить неограниченный доступ, просто подключившись к сети Wi-Fi (конечно же, тоже совершенно открытой).

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

Когда я исследую безопасность ПО, то одним из пунктов проверки является работа с динамическими библиотеками. Атаки типа DLL hijack («подмена dll» или «перехват dll») встречаются очень редко. Скорее всего, это связано с тем, что и разработчики Windows добавляют механизмы безопасности для предотвращения атак, и разработчики софта аккуратнее относятся к безопасности. Но тем интереснее ситуации, когда целевое ПО уязвимо.

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

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



Под катом будет несколько вариантов создания таких библиотек — как в виде кода, так и утилитами.

Умный дом представлен широком набором устройством. Во второй части цикла публикаций о безопасности IoT будут рассмотрены умные ТВ приставки, умная кухня, голосовые помощники и освещение. Ссылка на 1 часть.

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

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

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

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

Миниатюрная камера Ring

Изданию The Intercept стало известно о крупном провале производителя камер безопасности Ring (принадлежит Amazon). Оказывается, эта компания предоставила своим разработчикам в Киеве полный доступ к папке на Amazon S3, где хранится отснятый материал со всех устройств. Более того, видеоданные на тот момент не были зашифрованы, а разработчикам дали ещё и базу данных, которая соотносит имена пользователей и видеофайлы.

Привет, Хабр! Меня зовут Ахмадеев Ринат, я Sr. PHP developer.

Представляю вашему вниманию конспект доклада Make passwords great again! Как победить брутфорс и оставить хакеров ни с чем от Алексея Ермишкина из Virgil Security с HighLoad++ 2018.

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

В докладе рассматриваются способы защиты паролей начиная от хешей и заканчивая более современными подходами, такими как Facebook's password Onion, Sphinx и Pythia. В самом конце рассматривается новый Simple Password-Hardened Encryption Services (PHE).

Мне так понравился доклад, что я подготовил конспект. Всем рекомендую к ознакомлению.

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

Привет, Хабр! Представляю вашему вниманию перевод с англ. статьи Pitching Flutter to your company or client (автор Wm Leler)

С момента публикации статьи What’s Revolutionary about Flutter прошло больше года (и этот материал всё ещё актуален). Когда я писал ту статью, лишь немногие мобильные разработчики слышали о Flutter, но с тех пор многое изменилось. Сейчас я не успеваю следить за потоком новых статей и видео, которые появляются в этом активном и постоянно развивающемся сообществе. Разработчики открыли для себя Flutter, и они от него без ума. Вот пример приложения от Reflectly, созданного с помощью Flutter:


Умное приложение-дневник Reflectly

Flutter — новый инструмент от Google, позволяющий разработчикам писать кроссплатформенные приложения, которые можно запускать на различных системах (например, на Android или iOS) с общей кодовой базой.

Сам инструмент написан на C и C++. Предоставляет движок для 2D рендеринга, React-подобный FRP фреймворк и набор виджетов в стиле Material Design. На данный момент распространяется версия alpha:0.0.20, но несмотря на довольно "сырую" версию, уже можно создавать продвинутый интерфейс, работать с сетью и даже с файловой системой.

После доклада Юры Лучанинова, я решил для себя попробовать Flutter. Чтобы мозг размять, и чтобы было о чем похоливарить с мужиками на кухне. Дело пошло. Я начал смотреть, потом читать, потом писать. И вроде все получается, приложения запускаются, и то что объясняют — понятно, все просто. Но не без “но” — объясняют не все. А поскольку платформа, ЯП, подходы и даже предметная область для меня новые, то подобное вызывает раздражение, ведь у тебя “не запускается”, а ты даже не знаешь что гуглить: Dart/Flutter/Window/Screen/Route/Widget?

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

В августе 2018 года Flutter стал самой запрашиваемой кроссплатформенной технологией на Stack Overflow.

В нашем блоге Артем Зайцев и Евгений Сатуров из студии Surf, сертифицированного агентства Google, расскажут, почему и как так получилось:

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

Если попробовать представить себе Android-разработчика (где живёт, как выглядит, какие технологии использует), то вряд ли в голову придут польский город Вроцлав и гугловский проект Flutter, а кроме того, возникший образ почти наверняка будет мужским. И доля Flutter в Android-разработке, и доля женщин в IT пока что скромные. Но это не значит, что так будет всегда, и не значит, что их не стоит замечать. И поскольку к нам на конференцию Mobius приедет Паулина Шклярска из Вроцлава, чтобы рассказать о Flutter, мы решили расспросить её обо всём понемногу: от кроссплатформенной разработки до польского IT-сообщества.

На конференции Google I/O ’17 Google представила Flutter — новую опенсорсную библиотеку, предназначенную для создания мобильных приложений.

Как вы, возможно, знаете, Flutter — это решение для разработки кросс-платформенных мобильных приложений с симпатичным пользовательским интерфейсом. Подход, используемый Flutter для проектирования интерфейсов, похож на тот, который применяется в веб-приложениях, поэтому, знакомясь с этой библиотекой, вы найдёте множество аналогий с технологиями HTML/CSS.

Если прислушаться к тому, что создатели библиотеки говорят о Flutter, то окажется, что эта библиотека упрощает и ускоряет разработку веб-приложений, которые радуют глаз. Звучит это хорошо, но, когда я впервые взглянула на Flutter, я не вполне поняла причину возникновения очередного кросс-платформенного решения. Существует много подобных технологий, среди них — Xamarin, PhoneGap, Ionic, React Native. Все мы знаем, что в области разработки кросс-платформенных мобильных приложений имеется достаточное богатство выбора, и то, что у разных технологий есть свои плюсы и минусы. Я не была уверена в том, что Flutter сможет предложить что-то по-настоящему новое и интересное, отличающее его от толпы конкурентов. Однако когда я познакомилась с Flutter поближе, меня ждал сюрприз.

Библиотека Flutter имеет множество возможностей, которые могут быть очень интересными с точки зрения Android-разработчиков. В этой статье я хочу рассказать вам о том, что мне в этой библиотеке особенно понравилось.

Получив задачу разработать приложение для нашей предстоящей внутренней конференции в рамках OLX Group, моя команда задумалась о том, как сократить время создания приложения для iOS и Android, потому что нам и без этого было чем заняться. Первое, что мне пришло в голову, — использовать Kotlin, т.к. он может компилироваться на других платформах. Спойлер: не все пошло так, как изначально планировалось, но мы сделали всё вовремя, попутно узнав много нового!

Итак, это рассказ о том, как мы делали приложение OLX Group Product & Tech Conference в рекордно сжатые сроки.

Эта статья написана для Android-разработчиков, которые хотят применить свои существующие знания для создания мобильных приложений с помощью Flutter. В этой статье мы рассмотрим эквивалент Activity во Flutter.