+38 (044) 361-14-80 +38 (0482) 428-755      Пн - Пт, с 11.00 до 18.00

 Новости информационной безопасности

Срд, 09 Янв 2019 10:30:10


В официальном каталоге приложений Google Play нашли 85 зараженных адварью приложений, маскировавшихся под разные игры и пульты для ТВ.
Подробнее...

Специалисты компании Trend Micro сообщили, что недавно из официального каталога приложений Google Play было удалено сразу 85 зараженных адварью приложений, маскировавшихся под разные игры, пульты для ТВ и решения для стриминга бразильских, канадских, испанских и южноафриканских телеканалов.

В общей сложности вредоносные приложения были установлены более 9 000 000 раз. Так, только приложение под названием Easy Universal TV Remote насчитывало свыше 5 000 000 скачиваний.

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

Все 85 приложений представляли собой классическую adware, то есть демонстрировали нежелательную и очень навязчивую рекламу. Так, при первом же запуске приложения на разных этапах выводили на дисплей полноэкранную рекламу, побуждая пользователя нажимать для продолжения на различные кнопки. Если такое поведение не отталкивало пользователя, и он всё же добирался до главного меню, здесь его ждал новый «сюрприз»: нажатие на любой пункт меню вновь и вновь провоцировало появление полноэкранных рекламных баннеров, а затем приложения вообще «падали» и скрывали свои иконки с рабочего стола.

После «падения» приложения, тем не менее, продолжали работать в фоновом режиме, незаметно для своей жертвы. В итоге каждые 15-30 минут на экране устройства опять появлялась раздражающая реклама.

Полный список вредоносных приложений можно найти в специальном дополнении (PDF) к отчету специалистов.

Отмечу, что это не первое сообщение о малвари в Google Play в этом году. В первых числах января эксперты Trend Micro нашли в каталоге приложений спайварь MobSTSPY, которая маскировалась под клоны Flappy Bird (например, Flappy Birr Dog) и более утилитарные приложения, вроде фонариков. Такие вредоносные приложения успели скачать более 100 000 человек.

Срд, 09 Янв 2019 09:30:36


Для подписчиков
Впервые исходники новой загадочной ОС Google всплыли в Сети в августе 2016 года. К маю 2017-го они обросли кое-какой документацией и обзавелись альфа-версией интерфейса. Сегодня «Фуксия» — хорошо документированная и активно развиваемая, но не ОС, а нечто гораздо большее.
Подробнее...

Содержание статьи

Впервые исходники новой загадочной ОС Google всплыли в Сети в августе 2016 года. К маю 2017-го они обросли кое-какой документацией и обзавелись альфа-версией интерфейса. Сегодня «Фуксия» — хорошо документированная и активно развиваемая, но не ОС, а нечто гораздо большее.

В далеком-далеком 2008-м

Когда в 2007 году стало известно о работе Google над мобильной операционной системой, немногие поняли, зачем это нужно. Тогда существовали вполне успешная Symbian, Windows Mobile, стремительно развивался мобильный Linux (MeeGo). Android не вписывался в ряды существующих ОС, да и было не совсем понятно, зачем он вообще нужен «Гуглу».

Истинная цель стала известна только в 2008 году с появлением первого смартфона на Android. Тогда уже существовала iOS (а точнее, iPhone OS), и в целом Android был на нее похож, но имел одно очень интересное и важное отличие — бесшовную интеграцию с сервисами Google. Купивший телефон человек вводил свой email и пароль в ходе начальной настройки — и вуаля, на телефон начинали сыпаться уведомления о новых письмах, событиях в календаре, приходили сообщения в Google Talk, система синхронизировала адресную книгу с облаком.

Для Google Android был способом завлечения и закрепления пользователей в собственной экосистеме. Если ты покупал телефон на Android, ты вряд ли стал бы тратить время на настройку остальных аккаунтов и установку дополнительных приложений. Гораздо проще один раз ввести пароль от Gmail и пользоваться стандартным софтом «Гугла».

В дальнейшем Google все больше интегрировала себя в телефоны пользователей. Появилась возможность доступа к вкладкам Chrome, открытым на стационарном компе, появилась интеграция с Google Drive, голосовой поиск, был запущен Google Now, который автоматически выводил на экран подсказки в зависимости от местоположения юзера, его предыдущих поисковых запросов, событий в календаре и других действий. Позже Google Now был расширен до Now On Tap, который показывал подсказки в зависимости от отображаемой на экране информации, а на смену ему в итоге пришел Google Assistant — своего рода единая система поиска и подсказок.

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

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

Fuchsia на PixelBook. Фото: Ars Technica
Fuchsia на PixelBook. Фото: Ars Technica

Google в каждом кармане

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

Главный экран Fuchsia. Фото: 9To5Google
Главный экран Fuchsia. Фото: 9To5Google

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

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

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

Браузер Fuchsia. Фото: 9To5Google
Браузер Fuchsia. Фото: 9To5Google

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

Просто представь: ты открываешь браузер, заходишь на сайт одного из ресторанов, затем добавляешь событие в свой календарь и говоришь: «Окей, Google, пригласи Ирину на ужин». И Google Assistant понимает, о чем речь. Он находит в списке сущностей событие календаря, просматривает предшествующие ему сущности, связывает все вместе и отправляет Ирине сообщение с приглашением в такой-то ресторан в такое-то время.

Продолжение доступно только подписчикам

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

Подпишись на «Хакер» по выгодной цене!

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Уже подписан?
Срд, 09 Янв 2019 08:30:45


Известный брокер уязвимостей, компания Zerodium, объявил о повышении цен на различные эксплоиты. Например, на удаленном джейлбрейке для iOS можно заработать до 2 млн долларов, а уязвимости в мессенджерах могут принести до 1 млн долларов.
Подробнее...

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

Если ранее за устойчивый удаленный джейлбрейк для iOS предлагали 1,5 млн долларов США, то теперь размер выплаты увеличился до 2 млн. Напомню, что обязательным условием для такого джейлбрейка является отсутствие какого-либо взаимодействия с пользователем, то есть всё должно происходить автоматически. Если же минимальное взаимодействие с пользователем всё же требуется, такой эксплоит будет оценен в 1,5 млн долларов США.

Кроме того, вдвое увеличились выплаты за RCE-уязвимости нулевого дня и эксплоиты для них в мессенджерах WhatsApp и iMessage, а также приложениях для работы с SMS/MMS на различных платформах. Ранее на эксплуатации таких багов можно было заработать до 500 000 долларов США, а теперь до 1 млн долларов. Интересно, что при этом 0-day уязвимости в Signal, Telegram и Facebook Messenger по-прежнему стоят 500 000 долларов США.

«Мессенджеры в целом и WhatsApp в частности порой являются единственным каналом связи, который используют цели, а из-за end-to-end шифрования наши правительственные заказчики испытывают сложности при перехвате таких коммуникаций. В итоге иметь возможность удаленно компрометировать такие приложения, не компрометируя при этом весь телефон, это более стратегический и эффективный подход», — комментирует основатель Zerodium Чауки Бекрар (Chaouki Bekrar).

Новую версию изменившегося «прайс-листа» компании можно увидеть ниже.

Компания Zerodium, основанная в 2015 году Чауки Бекраром (Chaouki Bekrar), одним из создателей Vupen, является одним из наиболее известных брокеров уязвимостей на рынке. Тогда как Vupen преимущественно занималась разработкой собственных эксплоитов, Zerodium имеет не только собственную команду девелоперов, но также активно приобретает эксплоиты и уязвимости у третьих сторон.

Бизнес модель Zerodium (из-за которой компания неоднократно подвергалась жесткой критике) такова, что компания сохраняет информацию о найденных самостоятельно и купленных у третьих лиц 0-day в тайне, при этом перепродавая их крупным компаниям, правительственным организациям и силовым структурам. К примеру, АНБ или военным.

Срд, 09 Янв 2019 07:30:54


Интересный подарок к праздникам сделали пользователям GitHub разработчики Приватные репозитории (не более чем для трех участников) станут доступны бесплатным пользователям.
Подробнее...

Разработчики GitHub и компания Microsoft, которой с недавних пор принадлежит сервис, анонсировали интересный «подарок» для пользователей, озаглавив свое сообщение «новый год, новый GitHub». Пользователям станут доступны бесплатные приватные репозитории, а также появится удобный продукт для компаний и групповой разработки.

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

Также был анонсирован GitHub Enterprise — новый унифицированный продукт для Enterprise Cloud (ранее GitHub Business Cloud) и Enterprise Server (ранее GitHub Enterprise). Организации, которым нужна гибкость в использовании GitHub в облачной или автономной конфигурации, теперь могут получить доступ к обоим по одной цене.

Пнд, 07 Янв 2019 09:30:40


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

Содержание статьи

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

Почитать

Новый метод рутинга

Kernel Assisted Superuser (KernelSU) — The Final Frontier for SafetyNet and an Essential Developer Tool — небольшая статья о KernelSU, новом способе рутинга Android путем прямого патчинга ядра.

В последнее время одним из основных методов получения прав root на Android стал Magisk. Он использует так называемый systemless-способ рутинга, когда вместо модификации раздела system поверх него подключается виртуальный раздел, содержащий бинарный файл su, необходимый приложениям для получения прав root. Такой метод позволяет избежать проблем с обновлениями, а также эффективно скрывать наличие прав root на устройстве.

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

Метод KernelSU, предложенный разработчиком zx2c4, базируется на совершенно другой идее. Вместо подключения виртуального раздела или физического размещения файла su в разделе system он использует модифицированное ядро, чтобы заставить приложения «думать», что в системе действительно есть файл /system/bin/su. Ядро перехватывает все обращения к этому файлу и, если приложение пытается с его помощью запустить команды, автоматически исполняет их с правами root.

Работая прямо в ядре, KernelSU имеет гораздо больше возможностей для скрытия и обхода различных ограничений Android, в том числе правил SELinux.

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

Небезопасный IPC в софте для Android

Security Code Smells in Android ICC — большое исследование безопасности приложений, использующих механизмы межпроцессного взаимодействия Android. Авторы взяли около 700 открытых приложений из репозитория F-Droid и проанализировали, есть ли в их коде проблемы в использовании IPC.

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

  • SM01: Persisted Dynamic Permission. В Android есть механизм, позволяющий предоставить другому приложению временный доступ к какому-либо URI своего ContentProvider’а. Это делается с помощью метода Context.grantUriPermission(). Если приложение вызывает его, но не вызывает Context.revokeUriPermission(), чтобы отозвать доступ, — есть проблемы.
  • SM02: Custom Scheme Channel. Любое приложение может зарегистрировать собственную URI-схему, такую как myapp://, вне зависимости от того, использует ли такую схему другое приложение. Как следствие, пересылать важные данные, используя кастомные URI-схемы, крайне небезопасно.
  • SM03: Incorrect Protection Level. В Android есть система разрешений и любое приложение может создать свое собственное разрешение для доступа к своим данным. Но есть проблема: если указать неправильный уровень защиты разрешения (protection level), оно может не сработать. Если разработчик хочет, чтобы пользователь видел диалог запроса разрешений, он должен использовать уровень защиты dangerous или signature, если данное разрешение должно получать только приложение с той же цифровой подписью.
  • SM04: Unauthorized Intent. Любое приложение в Android может зарегистрировать себя в качестве обработчика определенных типов интентов (intent). По умолчанию этот обработчик будет открыт всему миру, но его можно защитить с помощью системы разрешений и строгой валидации входных данных.
  • SM05: Sticky Broadcast. Любое приложение может послать другому приложению интент. Более того, оно может послать широковещательный интент сразу всем приложениям, и он будет обработан первым приложением, способным его принять. Но есть также возможность послать широковещательный sticky-intent, который после обработки одним приложением все равно будет доставлен другим приложениям. Чтобы этого не происходило, не стоит использовать такие интенты, а от широковещательных интентов лучше отказаться вообще.
  • SM06: Slack WebViewClient. Компонент WebView позволяет приложениям показывать веб-страницы внутри своего интерфейса. По умолчанию он никак не фильтрует открываемые URL, чем можно воспользоваться, например, для фишинга. Разработчикам стоит либо использовать белый список адресов, либо выполнять проверку с помощью SafetyNet API.
  • SM07: Broken Service Permission. Приложения могут предоставлять доступ к своей функциональности с помощью сервисов. Злоумышленник может использовать эту возможность для запуска кода с повышенными полномочиями (полномочиями сервиса). Чтобы этого избежать, сервис должен проверять полномочия вызывающего приложения с помощью метода Context.checkCallingPermission().
  • SM08: Insecure Path Permission. Некоторые приложения предоставляют доступ к своим данным с помощью ContentProvider’а, который адресует данные, используя UNIX-подобные пути: /a/b/c. Программист может открыть доступ к своему ContentProvider’у, но отрезать доступ к некоторым путям (например, к /data/secret). Но есть проблема: разработчики часто используют класс UriMatcher для сравнения путей, а он, в отличие от Android, сравнивает их без учета двойных слешей. Отсюда могут возникнуть ошибки при разрешении и запрете доступа.
  • SM09: Broken Path Permission Precedence. Сходная с предыдущей проблема. При описании ContentProvider’а в манифесте разработчик может указать, какие разрешения нужны приложению для доступа к определенным путям. Но в Android есть баг, из-за чего он отдает предпочтение более глобальным путям. Например, если приложение дает доступ к /data всем подряд, но использует специальное разрешение для доступа к /data/secret, то в итоге доступ к /data/secret смогут получить все.
  • SM10: Unprotected Broadcast Receiver. Фактически аналог проблемы SM04, но распространяющийся исключительно на BroadcastReceiver’ы (специальные обработчики интентов).
  • SM11: Implicit Pending Intent. Кроме интентов, в Android есть сущность под названием PendingIntent. Это своего рода отложенные интенты, которые могут быть отправлены позже и даже другим приложением от имени создавшего интент приложения. Если PendingIntent широковещательный, то любое приложение сможет перехватить его и послать интент от имени этого приложения.
  • SM12: Common Task Affinity. Об этой проблеме мы уже рассказывали в «Хакере». Суть в следующем: в Android все экраны приложения (activity) объединяются в таск, который представляет собой своего рода стопку экранов. В то же время в Android есть средство, которое позволяет одному приложению всунуть свой экран в стопку другого приложения. Для этого буквально достаточно указать имя этого приложения в атрибуте android:taskAffinity у активности, которую нужно внедрить. А чтобы защититься, разработчик должен указать в этом атрибуте пустую строку.
Общая распространенность ошибок
Общая распространенность ошибок

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

Вредоносные библиотеки

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

Все началось с того, что автор решил подключить к проекту библиотеку AndroidAudioRecorder и обнаружил, что сразу после старта приложение крашится, выбрасывая исключение java.lang.SecurityException: Permission denied (missing INTERNET permission?). Это означает, что приложение не может получить доступ к интернету, так как отсутствует необходимое для этого разрешение.

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

Получалось, что разработчик намеренно обманывал пользователей библиотеки, распространяя альтернативную сборку библиотеки, которая отличается от официальных исходников. Или… кто-то залил в репозиторий фейковую библиотеку.

Суть истории. Существует репозиторий Java-пакетов jCenter, привязанный к системе дистрибуции Bintray. Android Studio использует jCenter как дефолтовый репозиторий для новых проектов: он уже включен в список репозиториев в build.gradle наряду с репозиторием Google. Однако многие разработчики предпочитают размещать свои библиотеки в репозитории JitPack, который умеет автоматически генерировать и выкладывать в репозиторий библиотеки из GitHub-репозитория (это удобно и просто).

Библиотека AndroidAudioRecorder также была выложена в JitPack, так что автор статьи перед ее использованием добавил JitPack в build.gradle. Но оказалось, что в jCenter тоже была выложена эта библиотека с внедренным в нее зловредным кодом. А так как jCenter в списке репозиториев идет первым, система сборки взяла библиотеку именно из него, а не из JitPack.

Один из способов решения этой проблемы — разместить jCenter в конце списка репозиториев в build.gradle.

Кусок зловредного кода
Кусок зловредного кода

Разработчику

Советы по использованию короутин в Kotlin

Kotlin Coroutines patterns & anti-patterns — хорошая подборка советов и антисоветов о короутинах Kotlin.

Заворачивай вызовы async в coroutineScope или используй SupervisorJob для работы с исключениями

val job: Job = Job()
val scope = CoroutineScope(Dispatchers.Default + job)

// Может выбросить исключение
fun doWork(): Deferred<String> = scope.async { ... }

fun loadData() = scope.launch {
    )try {
        doWork().await()
    } catch (e: Exception) { ... }
}

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

Чтобы избежать этого, достаточно использовать SupervisorJob:

val job = SupervisorJob() // <--
val scope = CoroutineScope(Dispatchers.Default + job)

// Может выбросить исключение
fun doWork(): Deferred<String> = scope.async { ... }

fun loadData() = scope.launch {
    try {
        doWork().await()
    } catch (e: Exception) { ... }
}

Используй Main Dispatcher в корневой короутине

Если тебе необходимо постоянно вызывать короутины Main Dispatcher (например, для обновления экрана), используй Main Dispatcher как основную короутину.

Большая часть следующего кода выполняется в рамках Main Dispatcher:

val scope = CoroutineScope(Dispatchers.Default)

fun login() = scope.launch {
    withContext(Dispatcher.Main) { view.showLoading() }
    networkClient.login(...)
    withContext(Dispatcher.Main) { view.hideLoading() }
}

Так почему бы не переписать код так, чтобы основная часть была в Main Dispatcher:

val scope = CoroutineScope(Dispatchers.Main)

fun login() = scope.launch {
    view.showLoading()    
    withContext(Dispatcher.IO) { networkClient.login(...) }
    view.hideLoading()
}

Избегай использования async/await там, где это не нужно

Код, подобный этому:

launch {
    val data = async(Dispatchers.Default) { /* code */ }.await()
}

лучше заменить на такой:

launch {
    val data = withContext(Dispatchers.Default) { /* code */ }
}

Этот код не порождает новые короутины, более производителен и нагляден.

Избегай завершения Scope Job

Представим такой код:

class WorkManager {
    val job = SupervisorJob()
    val scope = CoroutineScope(Dispatchers.Default + job)

    fun doWork1() {
        scope.launch { /* do work */ }
    }

    fun doWork2() {
        scope.launch { /* do work */ }
    }

    fun cancelAllWork() {
        job.cancel()
    }
}

fun main() {
    val workManager = WorkManager()

    workManager.doWork1()
    workManager.doWork2()
    workManager.cancelAllWork()
    workManager.doWork1()
}

Его проблема в том, что повторно короутина через метод doWork1 не запустится, потому что корневая для нее задача уже завершена.

Вместо этого следует использовать функцию cancelChildren:

class WorkManager {
    val job = SupervisorJob()
    val scope = CoroutineScope(Dispatchers.Default + job)

    fun doWork1(): Job = scope.launch { /* do work */ }

    fun doWork2(): Job = scope.launch { /* do work */ }

    fun cancelAllWork() {
        scope.coroutineContext.cancelChildren()
    }
}

fun main() {
    val workManager = WorkManager()

    workManager.doWork1()
    workManager.doWork2()
    workManager.cancelAllWork()
    workManager.doWork1()
}

Постарайся не писать suspend-функции с неявным диспетчером

Представь такую функцию:

suspend fun login(): Result {
    view.showLoading()
    val result = withContext(Dispatcher.IO) {  
        someBlockingCall() 
    }
    view.hideLoading()

    return result
}

Запустив ее с разными диспетчерами, ты получишь совершенно разные результаты:

launch(Dispatcher.Main) {     // Все нормально
    val loginResult = login()
    ...
}

launch(Dispatcher.Default) {  // Падение
    val loginResult = login()
    ...
}

CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.

Правильный вариант:

suspend fun login(): Result = withContext(Dispatcher.Main) {
    view.showLoading()
    val result = withContext(Dispatcher.IO) {  
        someBlockingCall() 
    }
    view.hideLoading()

    return result
}

Избегай использования GlobalScope

Если ты в своем коде постоянно делаешь

GlobalScope.launch {
    // code
}

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

В Android с этим еще проще. Короутины можно ограничивать активностями, фрагментами, View, ViewModel:

class MainActivity : AppCompatActivity(), CoroutineScope {

    private val job = SupervisorJob()

    override val coroutineContext: CoroutineContext
        get() = Dispatchers.Main + job

    override fun onDestroy() {
        super.onDestroy()
        coroutineContext.cancelChildren()
    }

    fun loadData() = launch {
        // code
    }
}

Как максимально сократить размер приложения

Build your Android app Faster and Smaller than ever — статья о том, как сделать приложения компактнее и собирать их быстрее. Вторая часть статьи (про скорость сборки) не особо полезна и интересна, поэтому остановимся только на способах уменьшения размера APK. Итак, как сделать приложение меньше?

  • Удалить неиспользуемые ресурсы: Refactor
Сбт, 29 Дек 2018 19:30:37


Эксперты 0DayAllDay изучили системы наблюдения Guardzilla и обнаружили, что пользователи могут иметь доступ к сохраненным видеозаписям друг друга.
Подробнее...

Эксперты 0DayAllDay изучили системы наблюдения Guardzilla и раскрыли информацию о критической уязвимости (CVE-2018-5560) в продуктах компании. Перед этим  исследователи уведомили вендора о проблемах и выждали положенные 60 дней. В отчете сказано, что наладить контакт с представителями Guardzilla так и не удалось, поэтому бреши по-прежнему не исправлены. Интересно, что с представителями Guardzilla удалось связаться журналистам издания TechCrunch, и те заявили, что не получали от исследователей никаких уведомлений и назвали все обвинения ложными.

Основная проблема устройств Guardzilla заключается в том, что системы домашнего видеонаблюдения содержат жестко закодированные учетные данные от облака Amazon S3, которое используется для хранения видеоматериалов. Эти учетные данные были обнаружены во время статического анализа кода прошивки, они дают неограниченный доступ к бакетам AS3, связанным с аккаунтом.

Специалисты пришли к выводу, что все пользователи систем видеонаблюдения Guardzilla All-In-One (и потенциальные злоумышленники) могут иметь доступ к сохраненным видеозаписям друг друга. Дело в том, что наборы ключей оказались одинаковыми для всех камер и предоставляли доступ более чем к 10 разным бакетам. По шкале CVSSv3 эта проблема оценивается в 8,6 баллов из 10 возможных.

Узнав значения AccessKeyIdG и secretAccessKeyG, атакующий получает возможность подключиться к AS3 и, по мнению экспертов, особенный интерес для злоумышленников могут представлять бакеты free-video-storage, free-video-storage-persist, premium-video-storage, а также premium-video-storage-persist.

Исследователи пишут, что тестировали только модель GZ501W, но полагают, что уязвимости могут распространяться и на другие продукты компании.  Хуже того, эксперты обнаружили в устройствах Guardzilla множество других известных проблем, связанных с использованием устаревшей версии OpenSSL  (1.0.1g).

Сбт, 29 Дек 2018 19:00:47


Специалистам удалось найти бреши в устройствах производства Trezor и Ledger. Среди выявленных проблем: атаки по стороннему каналу, атаки на цепочку поставок, уязвимости на уровне прошивки и чипа.
Подробнее...

На конференции Chaos Communication Congress был представлен доклад о проблемах в аппаратных кошельках Trezor и Ledger. Авторами исследования выступают Дмитрий Недоспасов (Dmitry Nedospasov), Томас Рот (Thomas Roth) и Джош Датко (Josh Datko). Они обнаружили сразу несколько брешей в безопасности кошельков: атаки по стороннему каналу, атаки на цепочку поставок, уязвимости на уровне прошивки и чипа.

Многие производители подобных устройств оснащают свои продукты и их упаковку защитными наклейками, которые свидетельствуют о том, что упаковку не вскрывали и само устройство тоже. Специалисты начали свою презентацию с простой демонстрации: при помощи обычного фена без труда избавились от  стикеров на коробке Trezor One и USB-порту кошелька, не оставив следов. Главное — следить за температурой и не нагревать стикеры и гаджеты слишком сильно.

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

Затем эксперты рассказали, что в кошельках Trezor можно подменить микроконтроллер. «Как только вы это сделаете, сможете поместить свой скомпрометированный загрузчик на устройства Trezor», — объясняет Датко. Во время презентации специалисты пропустили этот этап, но рассказали аудитории, что в лабораторных условиях им удалось подключиться к аппаратному дебаггеру и получить свободный доступ к чипу, что позволило перепрошить компоненты, используя вредоносный код.

Кошелек Ledger, в свою очередь, оснастили простейшим аппаратным имплантатом, который позволяет одобрять транзакции без участия пользователя. На это эксперты потратили всего $3,16: установили на устройство RF-переключатель, который можно контролировать удаленно, с помощью радиочастот (как минимум с расстояния в 11 метров, имея передатчик 50W).

Что до софтверной составляющей кошельков, исследователям удалось отреверсить механизм обновления прошивки на Ledger Nano S и найти баг, который позволяет записать на устройство кастомную прошивку. Производитель предусмотрел защиту от таких атак: подлинность образа прошивки проверяется с использованием криптографической функции. Однако после окончания проверки в память записывается константа 0xF00BABE, и проверка производится только раз, а не при каждом запуске устройства. В итоге исследователи пришли к выводу, что для обхода защитного механизма, достаточно поместить по определенному адресу ячейки памяти 0xF00BABE. Проделав это, они смогли запустить на скомпрометированном устройстве игру «Змейка», используя две имеющиеся кнопки для управления движением на крохотном дисплее кошелька.

На Ledger Blue удалось осуществить атаку по стороннему каналу (side-channel attack). Изучая аппаратную часть устройства, Томас Рот заметил, что кошелек оснащен длинным проводником, который ведет себя как антенна, и сигнал усиливается, если устройство подключено к USB-кабелю. Прибегнув к помощи SDR-оборудования, специалисты перехватили и проанализировали эти радиоволны. Так, Рот разработал фреймворк, который автоматически записывал сигнал во время ввода PIN-кода и использовал ИИ модель для преобразования этих данных в понятную человеку информацию. В итоге специалистам удалось добиться 90% точности таких «предсказаний».

Еще одну проблему удалось выявить в кошельке Trezor One, который работает с микроконтроллером STM32F205, который, по сути, управляет работой всех компонентов. Дело в том, что в 2017 году в этой модели микроконтроллеров обнаружили уязвимость перед внесением неисправностей (fault injection). В прошлом году специалистам не удалось понять, распространяется ли эта проблема на аппаратные кошельки, но на CCC эксперты рассказали, что изучив процедуры загрузки и обновления, они выявили, что из RAM можно извлечь приватный ключ или seed-ключ. Такая атака предоставит злоумышленнику доступ к криптовалюте и позволит перевести средства на другой кошелек.

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

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

Сбт, 29 Дек 2018 11:30:11


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

Содержание статьи

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

WARNING

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

Поисковики

Tor Browser встречает нас встроенным поисковиком DuckDuckGo. С точки зрения приватности — отличный выбор, но ищет DDG исключительно по открытому интернету, так что в наших изысканиях он не пригодится.

DuckDuckGo, привет!
DuckDuckGo, привет!

Впрочем, в даркнете своих поисковиков чуть ли не больше, чем в клирнете. Среди самых популярных: Ahmia, Candle и Torch. Были еще хорошие поисковики под названием Grams и Fess, но по неизвестным причинам они сейчас недоступны. Каждый из них выдает разные результаты по одним и тем же запросам, так что лучше иметь в закладках все три ресурса.

INFO

В этой статье мы сконцентрируемся на том, что доступно в .onion, так что если хочешь переходить по ссылкам, то тебе понадобится Tor Browser.

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

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

Torch: найдется все?
Torch: найдется все?

Поисковик Ahmia отличается тем, что он доступен как в даркнете, так и в клирнете. Релевантность выдачи при этом (субъективно) не очень высокая: как и Torch, он часто выдает ссылки, которые никак не относятся к теме поиска.

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

Каталоги — карты Tor

Начинать изыскания я рекомендую с каталогов ссылок. Там тоже, конечно, попадется мусор и устаревшие ссылки, но выбора не так много. Из англоязычных самый известный ресурс — это The Hidden Wiki, на русском — «Годнотаба». Помимо этого, существует еще не один десяток сборников ссылок — см., например, OnionDir и Oneirun.

«Годнотаба» мониторит годноту в Tor
«Годнотаба» мониторит годноту в Tor

WARNING

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

Даркнет образовательный

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

Flibusta  для любителей читать
Flibusta — для любителей читать

Даркнет — друг торрентов

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

RuTor как гарант вечной жизни Torrent
RuTor как гарант вечной жизни Torrent

У торрент-трекеров и поисковиков вроде RuTor и The Pirate Bay в обязательном порядке есть ссылки в onion, которые дают пользователям возможность не обращать внимания на запреты и ограничения.

Онлайн-магазины, в которых не принимают карты

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

WARNING

Производство, сбыт, пересылка наркотических и психотропных веществ преследуется по закону (статьи 228-231 УК РФ). Автор и редакция не несут ответственности за материалы, опубликованные по ссылкам. Переходя по ним, ты действуешь на свой страх и риск.

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

Словарь терминов

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

Продолжение доступно только подписчикам

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

Подпишись на «Хакер» по выгодной цене!

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Уже подписан?
Сбт, 29 Дек 2018 10:30:17


Власти Южной Кореи сообщили, что неизвестные хакеры похитили информацию о 997 перебежчиках, покинувших КНДР и нашедших пристанище в Южной Корее.
Подробнее...

Власти Южной Кореи сообщили, что неизвестные хакеры похитили информацию о 997 перебежчиках, покинувших КНДР и нашедших пристанище в Южной Корее. Дело в том, что был скомпрометирован один из 25 центров поддержки для таких беглецов.

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

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

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

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

Сбт, 29 Дек 2018 08:30:54


Специалисты в очередной раз предупредили о небезопасности двухфакторной аутентификации посредством текстовых сообщений и объяснили, чем опасно использование Twitter через SMS.
Подробнее...

Эксперты компании Insinia Security в очередной раз продемонстрировали всю опасность использования SMS-сообщений в качестве второго фактора для аутентификации и объяснили, чем чревато использование функциональности Twitter через SMS.

Возможно, многие уже успели забыть об этой функциональности (или никогда не знали о ней), но Twitter по-прежнему можно использовать посредством SMS-сообщений, что было довольно популярно на заре появление сервиса. Главное условие: чтобы эту функциональность поддерживал ваш оператор связи.

Специалисты Insinia Security напоминают, что спуфинг телефонных номеров в наши дни не такая уж сложная задача. К примеру, летом текущего года разработчики Instagram были вынуждены ввести поддержку новых методов двухфакторной аутентификации, так как злоумышленники стали массово «угонять» SIM-карты пользователей, а затем и привязанные к ним учетные записи, и чужие личности полностью. Завладеть чужим телефонным номером можно множеством разных способов, начиная от банальной социальной инженерии, и заканчивая техниками вроде Ghost Telephonist, показанной на конференциях DEF CON и BlackHat в прошлом году.

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

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

Исследователи продемонстрировали данную атаку на примере аккаунтов нескольких добровольцев: журналиста издания The Independent Саймона Калдера, радио- и телеведущего Имонна Холмса, документалиста, журналиста и телеведущего Льюиса Теру. Через спуфинг телефонных номеров и SMS-сообщения эксперты разметили от имени этих людей записи, гласившие, что учетная запись была временно взломана Insinia Security.

К сожалению, данную проблему никак нельзя назвать новой. К примеру, совсем недавно о ней также писали специалисты фирмы AntiSocial Engineer, и о небезопасности Twitter через SMS в своем блоге высказался известный ИБ-эксперт Ричард де Вер (Richard De Vere). Де Вер пишет, что о проблеме давно известно и злоумышленникам, которые не стесняются атаковать таким образом известные бренды. Хуже того, эксперт отметил, что в сети можно найти статьи об опасности этой функциональности, датированные 2007 и 2009 годами. Внимательные читатели вспомнят, что де Вер демонстрировал атаку на Twitter журналистам издания Computer Weekly в минувшие выходные. Именно этот способ эксперт тогда использовал для компрометации учетной записи издания.

Основная сложность на данный момент заключается в том, что множество людей по-прежнему привязывает к Twitter свои номера телефонов, он не для того, чтобы пользоваться сервисом через SMS. Дело в том, что двухфакторная аутентификация в Twitter возможна либо посредством текстовых сообщений, либо через специальное приложение (например, Google Authenticator), либо посредством аппаратного USB-ключа.

Напомню, что еще в 2016 году Национальный Институт стандартов и технологий США (The National Institute of Standards and Technology, NIST) представил интересный документ, согласно которому, использование SMS-сообщений для осуществления двухфакторной аутентификации является «недопустимым» и «небезопасным». Об этом в целом давно говорят специалисты по безопасности, ведь вариантов атак здесь может быть много. К примеру, атакующие могут эксплуатировать уязвимости в SS7 и перехватить сообщения; осуществить так называемый SIM swap, то есть перевыпустить SIM-карту жертвы на себя; и наконец, SMS-сообщения может перехватить даже малварь, проникнувшая на устройство.

К сожалению, невзирая на опасность, большинство пользователей по-прежнему предпочитают 2ФА через SMS-сообщения, как наиболее простую. То есть перед многими пользователям встает выбор: отвязать телефонный номер от учетной записи и остаться без 2ФА (но защитить себя от вероятного взлома аккаунта через спуфинг номера), или же оставить телефонный номер привязанным к аккаунту, но оставаться под угрозой взлома Twitter. Специалисты Insinia Security полагают, что разработчики Twitter стоит в принципе упразднить 2ФА через SMS-сообщения, иначе опасная ситуация будет сохраняться и далее.

Ссылка на источник