waqur: (Default)
Новое исследование показывает, что неразличимые на слух ультразвуковые команды (20 кГц+) могут быть использованы для контроля голосовых ассистентов Siri, Cortana, Alexa и Google Now:

https://www.theverge.com/2017/9/7/16265906/ultrasound-hack-siri-alexa-google
https://techcrunch.com/2017/09/06/hackers-send-silent-commands-to-speech-recognition-systems-with-ultrasound/

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

Таким образом, метод достаточно широкий, он не ограничивается машинно-обучаемыми системами распознавания голоса и может быть использован для вставки постороннего голоса даже в самую обычную аудиозапись, включая аналоговую.
waqur: (Default)
Оказывается, Intel Management Engine, о котором было в предыдущих сериях, может быть отключён.

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

Эти машинночитаемые XML-файлы схем настроек ME-контроллера примечательны тем, что они упоминают некую опционально включаемую фичу под названием HAP (High Assurance Platform). Достаточно одного запроса в Гугл, чтобы понять, что эта самая аббревиатура HAP как-то связана с программой по созданию высокодоверенной платформы, которую курирует U.S. National Security Agency.

Ребята, которые всё это раскопали, первым делом с помощью SPI-программатора для флеш-памяти (напомню, у основного процессора и ME-контроллера общая флеш-память) установили соответствующий бит, чтобы посмотреть, что из этого будет. После загрузки платформы, интеловская утилита MEInfo начала показывать странный статус "контроллер ME был отключён альтернативным способом", а дальнейшая проверка показала, что устройство перестало отвечать на команды и запросы операционной системы. При этом платформа стартует нормально и нормально работает (то есть не перезагружается по watchdog-таймеру спустя 30 минут, как при "грубом" отключении Intel ME путём удаления его разделов из флеш-памяти).

http://blog.ptsecurity.com/2017/08/disabling-intel-me.html

Интел в официальном ответе довольно обтекаемо подтверждает, что у компании есть высокопрофильные заказчики с узкоспециализированными требованиями, например подрядчики правительства США, и что иногда в платформу могут вноситься модификации, нужные этим заказчикам для их внутренних целей, и что для всех остальных пользователей по этим модификациям официальная техническая поддержка не предоставляется.
waqur: (Default)
Интересная статья о реверс-инжиниринге микрокода процессоров AMD K8 и K10:
https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-koppe.pdf

В отличие от Intel, компания AMD первое время не подписывала и не шифровала обновления микрокода для своих процессоров (хотя и применяла обфускацию микроинструкций). Опираясь на отрывочную информацию из патентов обоих компаний, на послойное сканирование ПЗУ микроопераций процессора электронным микроскопом, а также на хитрый способ подмешивания случайного шума в таблицу микроопераций с помощью программных обновлений микрокода, эта команда исследователей смогла установить соответствие между макроинструкциями и интервалами адресов в таблице микроопераций, а далее разобраться в формате и номенклатуре самих микроопераций, внутренних регистров процессора и т.п. Для повторяемости экспериментов по изменению поведения макроинструкций была реализована небольшая ОС (которая задействует все аппаратные возможности процессора), а сам процесс фаззинга был автоматизирован с помощью Raspberry Pi.

Напоследок они реализовали образцы разного вредоносного микрокода, например слив внутреннего состояния генератора псевдослучайных чисел криптографической библиотеки, такой как OpenSSL. Было показано, что закладка в микрокоде может быть активирована удалённо, например передачей через Javascript хитрых констант в инструкцию целочисленного деления. Чтобы не нарушать логические и арифметические правила, результаты своей работы вредоносный микрокод может сливать через вариацию времени исполнения макроинструкций, что тоже было продемонстрировано авторами статьи.
waqur: (Default)
Игру Dishonored 2 таки взломали, красавчики :)

Защищена с помощью Denuvo, выпущена ещё в ноябре прошлого года, Game of the Year в нескольких номинациях, один из лидеров продаж в Steam, дорогая ($60), до сих пор взломать никому не удавалось. Как и многие другие игры последних лет, защищённые с помощью Denuvo, это был крепкий орешек, ведь в основе технологии защиты Denuvo лежит VMProtect.

Однако новая группа под названием SteamPunks (да-да, это дебютный их релиз на крэкерской сцене) всех сделала с особым цинизмом — выпустила не просто патч или лоадер, а целый генератор ключей. :D Никогда не думал, что Dishonored 2 взломают таким способом — скорее, были предположения, что кто-то выпустит хитрый лоадер режима ядра, который захватывает хост в гипервизор и виртуализирует инструкцию CPUID вместе с перехватом доступа к серийному номеру жёсткого диска и MAC-адресу сетевой карты, которые дают вклад в HWID. Ну а далее все будут сидеть на едином ключе, как в старые добрые времена Windows 98 :)

Но кейген? "SteamPunks absolutely delivered" — пишут англоязычные сайты, и они чертовски правы. Неужто Стимпанки подобрали приватную часть мастер-ключа? Наверное, это как-то связано с дефектами генератора псевдослучайных чисел, которым был сгенерирован мастер-ключ. Мало энтропии в засевочном числе или что-то подобное. Более 15 назад похожая история была с ASProtect (см. стр 89/83 этой книги).

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

Во всём этом невозможно так сходу разобраться, потому что к радости разработчиков Dishonored 2 и крэкеров из конкурирующих групп, кейген защищён от реверс-инжиниринга. VMProtect'ом, разумеется. Чем же ещё. LOL.
waqur: (Default)
ArsTechnica пишет об интересном случае маскировки C&C (command and control) сервера вредоносного ПО (такого как вирусы-вымогатели). Обычно для таких вещей хакеры используют чужие взломанные серверы, и в конечном итоге попадаются, но в этот раз всё интереснее.

Сервер подключён к несимметричному спутниковому интернету (дешёвая односторонняя связь, только downlink) и прослушивает одновременно все частоты диапазона KuBand с помощью PCI-E платы со специальными драйверами для Linux. Такой себе односторонний promiscuous mode на спутнике. Раньше это называлось "спутниковая рыбалка". Провайдер спутникового интернета отображает на этот линк все IP-адреса из выделенного ему диапазона (и чтоб было совсем дёшево, не применяет VPN). Клиентская часть вредоноса шлёт зашифрованный пакет с полезной нагрузкой, предназначенный C&C серверу, на случайный IP-адрес из диапазона, и, насколько я понимаю, на случайный UDP-порт. Далее пакет (например содержащий приватную часть RSA-ключа экземпляра вируса-шифровальщика, зашифрованную публичным RSA-ключом C&C-сервера) вылавливается C&C-сервером из общего потока в порядке рыбалки. Обратная связь не требуется.

https://arstechnica.com/security/2015/09/how-highly-advanced-hackers-abused-satellites-to-stay-under-the-radar/

Где физически находится C&C-сервер в пределах покрытия спутника (круга радиусом 1000 километров) — правоохранители не могут выяснить до сих пор. Очевидно, не нужно иметь назначенный IP-адрес из этого диапазона (или даже быть клиентом оператора спутникового интернета), чтобы исполнять такие вещи.
waqur: (Default)
На днях в прошивке Intel Management Engine нашёлся баг, который позволяет обойти аутентификацию в их корпоративных решениях для удалённого управления серверами и рабочими станциями. Короче говоря, можно удалённо рулить сервером или ноутбуком без предоставления пароля/ключа, если в публичный интернет открыты TCP-порты 16992/16993.

Intel ME известен корпоративным пользователям под большим набором маркетинговых имён (AMT, ISM, SBT, IPMI, vPro) и представляет собой выделенный 32-битный сопроцессор, позволяющий, к примеру, удалённо войти в BIOS или удалённо пробросить ISO-образ с последующей переустановкой операционной системы. С аппаратной точки зрения, Intel ME является посредником между сетевым интерфейсом и процессором, и к тому же имеет прямой доступ ко всей оперативной памяти системы: https://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub

Подозрения о том, что Intel ME — это бэкдор для NSA и других аналогичных организаций, существуют давно. Для каждого из этих подозрений существует правдоподобное оправдание от Intel, и теория заговора.

1) Intel ME присутствует даже в чипсетах сугубо клиентских материнских плат и ноутбуков, и даже там он постоянно включён, и отключить его никак нельзя (в системе с неактивным Intel ME сработает watchdog timer чипсета через 30 минут после загрузки, или около того). Plausible deniability от Intel сводится к технологии Intel Anti-Theft, и к управлению вентиляторами. Conspiracy theory сводится к тому, что даже на клиентских системах есть пароли и AES-ключи, которые можно собирать из оперативной памяти. Или от процессора, который выполняет AES-NI инструкции, и, в принципе, знает ключи.

2) Встроенное программное обеспечение для Intel ME хранится в флеш-памяти в сжатом и зашифрованном виде, а выделенный для Intel ME регион в ОЗУ — прозрачно шифруется самим сопроцессором (хотя и программно недоступен для центрального процессора), так что даже охлаждение планок памяти жидким азотом и чтение на другой системе не позволит заглянуть внутрь. Plausible deniability от Intel сводится к наличию DRM-технологий (Protected Audio/Video Path) на этой платформе, а также к тому, что она может быть содержать программную реализацию TPM (Trusted Platform Module). Conspiracy theory сводится к тому, что код, собирающий всякие интересные артефакты из ОЗУ, должен быть защищён от любопытных глаз исследователей.

3) Intel ME имеет доступ к фреймбуферу (видит и может менять то, что отображается пользователю на экране). Для этой функции ему порой нужна поддержка со стороны ОС (если видеокарта не встроенная, а дискретная). Plausible deniability от Intel: Active Management Technology (удалённое управление), а также Protected Transaction Display (ввод PIN-кода для интернет-банка мышиными кликами по рандомизированной экранной PIN-клавиатуре, так чтобы хостовый CPU и вирусы, выполняющиеся на нём, не знали цифр, которые отображаются на экране). Также нужно для DRM (показывать дешифрованное видео прямо на экран, в обход CPU). Conspiracy theory: подглядывание за пользователем.

4) Intel ME и сетевой контроллер остаются включёнными даже тогда, когда основной процессор выключен (режим питания soft-off). Plausible deniability от Intel сводится к технологии Wake-on-LAN. Conspiracy theory сводится к тому, что пока компьютер "как бы выключен", этот сопроцессор может спокойно передавать "куда следует" секретики, собранные за день.

5) Intel ME включается в разрыв между сетевым контроллером и процессором. Plausible deniability от Intel сводится к технологии System Defense (низкоуровневой неотключаемый файерволл для дебилов, которые снесут или отключат файерволл в ОС и нахватаются вирусов), а также всё к тому же AMT и vPro. Также существует технология Intel EEE (Energy Efficient Ethernet), которая позволяет, например, открыть слушающий TCP сокет и отправить CPU спать до появления первого клиентского подключения. Conspiracy theory сводится к тому, что таким способом собранные данные можно сливать не "в наглую" (например, передавая трафик на неизвестный IP-адрес, который кто-то запишет wireshark'ом или tcpdump'ом и устроит скандал) а похитрее (например, в виде колебаний задержек при отправке исходящих пакетов, которые можно измерить на оборудовании вашего интернет-провайдера). При этом, можно предположить, что колебания задержек входящих пакетов на исходящих TCP-сессиях могут быть использованы для встречной передачи команд контроллеру Intel ME.

Подытожим:

1) Я не до такой степени параноик, чтобы менять встроенную прошивку на coreboot, рискуя превратить материнскую плату в бесполезный кусок текстолита; к тому же я не уверен, что это как-то поможет. Однако я не пользуюсь встроенными сетевыми контроллерами от Intel с 2015 года, чего и вам советую. Выбирайте дискретную сетевую карту поэкзотичнее, прошивка Intel ME — это примерно 2 мегабайта, а ведь там ещё должен поместиться весь этот SSL, VNC-сервер, DRM, файерволл и предполагаемый шпионский хлам (а также урезанная версия Java). Да и попытка пообщаться с сетевой картой требует перепрограммирования регистров её контроллера и контроллера DMA, что не останется незамеченным для CPU. Ну разве когда CPU в режиме soft-off, но тогда и сетевая карта в soft-off.

2) Сам факт нахождения первых уязвимостей в Intel ME позволяет предположить, что кто-то всерьёз заинтересовался этим вопросом, возможно расшифровал прошивку Intel ME. Способы есть. Вполне естественно, что люди интересуются, ведь если кто-то заложил в платформу такие вкусняшки — не пропадать же им втуне. Да и в конечном итоге неважно, написан ли соответствующий софт или нет; важно лишь, что железо позволяет.

Обсуждение на Hacker News:
https://news.ycombinator.com/item?id=14241241

Update от 2017-08-29: существует способ отключить Intel ME:
https://waqur.dreamwidth.org/130735.html
waqur: (Default)
Как проникнуть в защищённую сеть организации, которая изолирована от интернета?

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

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

Те, кто имел дело с самоделкинской платой Arduino Leonardo, знают, что она умеет эмулировать любое USB-устройство. Например, флешку. Или клавиатуру (разумеется, без клавиш — такую, которая сразу после подачи питания начинает что-то виртуально "набирать", например WinKey+R, "cmd", Enter, "format C:", Enter, Y, Enter). Или USB-хаб, куда виртуально подключены флешка и клавиатура. Так что подавление выполнения файла autorun.inf не поможет.

Но как же быть с Mac OS и Linux? Ну, например, можно попытаться включить Num Lock через PowerShell (о чём винда уведомит клавиатуру), и если не получилось — то это, наверное, не Windows. А если не получилось через setleds(1) — тогда это, наверное, не Linux.

https://www.elie.net/blog/security/what-are-malicious-usb-keys-and-how-to-create-a-realistic-one
waqur: (Default)
Одна вещь, которую я никогда не понимал в контексте теории борьбы с эксплоитами, основанными на stack corruption в коде, написанном на C/C++ и других небезопасных языках — это почему не используется расщепление стека надвое:

1. Доверенный стек: там обязательно должны быть адреса возврата из функций, параметры вызываемых функций; а также там могут быть локальные переменные, на которые не берётся указатель.

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

Не хватает регистров? Но мы ведь уже давно пишем не для 8-битных микроконтроллеров: в процессорной архитектуре x86-64 вдвое больше регистров, чем в x86, а ещё они вдвое шире. "Второй RSP" отлично поместился бы в каком-нибудь R13. Доверенный стек может быть исполняемым, недоверенный — всегда нет. Это бы решило проблемы несовместимости DEP (Data Execution Prevention) с GCC Nested Functions и всякими прочими closures из других языков. Очевидно, что глобальная оптимизация (которая называется в разных компиляторах по-разному: LTO, LTCG, IPO) могла бы существенно сократить количество случаев, когда нужен недоверенный стек.

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

Вместо этого индустрия вот уже лет десять или двадцать полагается на благие пожелания в вольной художественной форме, такие как MISRA C, или городит какие-то ASLR (которые не всегда работают), W^X, DEP, разные попытки противодействия ROP (например G-free и CFG), принудительные автоматические обновления, Rust и прочие глупости, которые проблему в общем-то и не решают, а так, царапают по поверхности.

SAM 1.3

2017-02-01 09:21 pm
waqur: (Default)
В Windows 10, начиная с Anniversary Update (10.1608), фирма Microsoft для чего-то поменяла способ шифрования хэшей в хайвах SAM.

Когда-то очень давно (во времена NT 3.51 и NT 4.0), пароли пользователей просто хэшировались алгоритмами MD4 и LMHash и в таком виде писались в хайв реестра под названием SAM.

В Service Pack 3 к NT 4.0 появилось нововведение под названием SYSKEY. Теперь хэши не просто хранились в SAM, а ещё и шифровались ключом под названием PEK. PEK генерировался случайно при установке Windows и тоже сохранялся в SAM-хайве, но не в открытом виде, а в зашифрованном. Шифрование PEK'а и хэшей происходило с помощью криптоалгоритма RC4, проверка валидности PEK'а делалась с помощью комбинации RC4 и MD5. Для расшифровки PEK нужен был ключик из хайва SYSTEM. Его в открытых источниках обычно называют SYSKEY, а Microsoft его именует Boot Key. Он хранится немного витиеватым способом (по частям в именах классов разных ключей реестра, связанных с подсистемой LSA), но извлекается без особых проблем. В общем, security through obscurity.

RC4-шифрование хэшей и PEK'ов по технологии SYSKEY просуществовало в неизменном виде во всех последующих версиях Windows (2000, XP, 2003 Server, Vista, 7, 2008 Server, 8, 8.1, 2012 Server, 10 RTM, 2016 Server), аж пока в Windows 10 Anniversary Update не произошли изменения.

Что бы вы думали? Они внедрили PBKDF2 вместо MD4, чтобы затруднить подбор паролей полным перебором на видеокартах? Перенесли вычисление Boot Key в TPM? В безопасный анклав Intel SGX? В Yubikey? Реализовали какую-то безумную систему проверки пароля с использованием zero knowledge proof, основанную на новейших достижениях криптографической мысли, таких как zk-SNARKs?

Фиг там, это же Microsoft. Они просто заменили RC4 на AES, а MD5 на SHA256 в своей security-through-obscurity схеме шифрования PEK'ов и хэшей (ну и попутно подняли версию формата данных 1.2 с 1.3, что сломало работу всяких утилиток для сброса пароля в винде, тысячи их). Разумеется, MD4 при всём при этом остался вечно живой, как Ленин.

Выглядит как формальная подготовка к какой-то правительственной сертификации. Убрать с начальственных глаз имена криптоалгоритмов и хэш-алгоритмов, к которым можно придолбаться с чисто формальной точки зрения. Ну спасибо, конечно, про RC4 мы давно догадывались, хотя в данном конкретном случае случае (SYSKEY — PEK — хэши паролей из SAM) что AES, что RC4, что XOR-наложение гаммы из линейного конгруэнтного ГПСЧ обеспечивают абсолютно идентичный уровень безопасности.

Bitmessage

2016-10-15 09:36 pm
waqur: (Евро)
Bitmessage — первый шифрочятик, который способен шифровать метаданные (кому, от кого, когда, сколько байт).
https://en.wikipedia.org/wiki/Bitmessage

Технически, в DHT-сети содержится пул сообщений за последние 48 часов, зашифрованных публичными ключами. Хэш публичного ключа = сетевой адрес получателя сообщения. Приватные ключи, необходимые для расшифровки, локально хранятся у клиентов и не передаются в сеть. Для DDoS'оустойчивости применяется proof-of-work на хэшах, наподобие биткойновского.

UPD. Идея хорошая, но есть проблемы с реализацией — память течёт, и приложение периодически падает (32-битная версия) или заставляет систему грызть своп и всё равно падает (64-битная версия). Вдобавок ко всему, ещё и на Питоне. Если было написано на чистом Си — можно было бы применить Intel Inspector XE, а так хз, что там течёт — рантайм Питона, Питоновские библиотеки, или сама программа. Не наши проблемы, пусть автор сам разбирается во всём этом великолепии :)
waqur: (Евро)
Apple анонировала новую фишку под названием Differential Privacy.
Раньше ваш телефон просто сливал всю интересную инфу в яблочное облако и в NSA, а теперь он будет ещё и подмешивать туда случайный шум, цитирую "to obscure an individual’s identity", т.е. "чтобы размыть вашу идентичность". Заодно новая версия iOS и шпионить будет больше, залезая в те места, куда раньше не совалась.

Хитрый ход. Во-первых, уж если хакеры с сайта Hacker News повелись как дети, то народ с гуманитарным образованием тем более свято уверует, что добавление случайного шума размывает идентичность (на самом деле нет — растёт энтропия потока данных, а значит два разных пользователя становятся различимее друг от друга). Во-вторых, нечто, выглядящее как случайный шум, может быть на самом деле шифртекстом (не зная ключа, нельзя сказать наверняка). В этом "как бы шуме" можно не только передавать идентификаторы пользователей и устройств, но и устроить такой себе стеганографический вариант SSL, посредством которого передавать историю браузера, приложений, ключевые слова, пароли, номера кредитных карт и т.п. Разумеется, можно развлекаться и по-другому: например, сливать внутреннее состояние /dev/urandom, позволяющее легко подобрать сессионные ключи https-сессий браузера или https-сессий подсистемы автоматической установки обновлений. Главное в этом деле — найти правдоподобную отмазку для пользователя, почему "энтропия течёт", а всё остальное — дело техники. И эта отмазка — в сабже.

Всё-таки умело яблочники обувают лохов. Инновационно. Сейчас эту "лучшую индустриальную практику в сфере privacy", разумеется, возьмут на вооружение в Microsoft и в Google.

LOL

2016-06-09 08:51 pm
waqur: (Евро)
Microsoft добавила сбор "телеметрии" уже даже в компилятор:
https://www.infoq.com/news/2016/06/visual-cpp-telemetry
waqur: (Евро)
Российские органы госбезопасности хачат Telegram'овскую двухфакторную аутентификацию, основанную на одноразовых SMS-паролях, простым принуждением телеком-оператора к перехвату потока SMSок, входящих на заданный номер.

https://www.bellingcat.com/news/2016/04/30/russia-telegram-hack/

Ну просто эталонный пример для людей, не понимающих правой части неравенства

слабый пароль < двухфакторная аутентификация < сильный пароль
waqur: (Евро)
В мессенджер WhatsApp добавили end-to-end шифрование. Таких шифрованных мессенджеров сейчас уже стало много: Signal, Telegram и другие. Однако EFFовцам понравилось, что используется double ratchet для борьбы с последствиями компрометации сессионных ключей, а также взаимное фотографирование QR-кодов для противодействия MITM-атакам (очевидно, что нельзя полагаться на PKI в борьбе со state adversary; а передаваемые голосом контрольные слова в стиле ZRTP SAS неприменимы в контексте текстовых мессенджеров):
https://www.eff.org/deeplinks/2016/04/whatsapp-rolls-out-end-end-encryption-its-1bn-users

Остающиеся замечания (выношу из обсуждения):
(1) утечка метаданных (кто, с кем, когда, как долго общался) на центральный узел
(2) приложение хочет доступ к адресной книге телефона
(3) возможность изгонять пользователей из всей системы (централизованно банить)
(4) в связи с установкой из магазина приложений, нет гарантий, что ваша копия мессенджера бинарно-идентична другим пользователям (а не пропатчена лично для вас, например в связи с NSL).
waqur: (Евро)
Вся эта история с противостоянием Apple и ФБР по поводу взлома телефона террориста из Сан-Бернардино с самого начала казалась мне какой-то пиар-туфтой.

Если ФБР ничего не мешает изъять жёсткий диск, защищённый TrueCrypt'ом, сделать с него копию или несколько копий, и далее на специальном оборудовании дрючить мастер-блок шифрованного тома полным перебором паролей,

тогда в чём проблема снять дамп постоянной флеш-памяти телефона, перенести его в эмулятор, и перебирать внутри эмулятора все эти PIN-коды, и после каждой такой "полной и окончательной блокировки телефона в эмуляторе" возвращаться к начальному состоянию эмулятора?

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

К тому же, непонятно зачем было ФБРовцам якобы требовать от Apple разработать системное обновление, снимающее ограничение на количество попыток ввода PIN-кода, если они могли просто истребовать мастер-ключ для подписи системных обновлений вместе с полными исходными кодами iOS через national security letter или search warrant with gag order и далее нанять каких-то индусов для разработки этого самого обновления. Никто бы и не пикнул.

Как по мне, всё это больше похоже на какой-то "цирк на дротi", придуманный пиарщиками, с целью поднять имидж компании Apple в пост-Сноуденском мире. Типа, валяйте, хомячки, закупайтесь ябблофонами и делитесь всеми вашими секретиками. По-моему, самоочевидно, что не может быть и речи о криптографической защите пользовательских данных на платформе, где существует мастер-ключ для подписи автоматически устанавливаемых обновлений, или где для доступа к данным пользователи вводят низкоэнтропийные пароли.
waqur: (Евро)
Maciej Cegłowski, выступая на Strata+Hadoop World conference в New York City, сравнил тенденцию пост-Сноуденского мира к повсеместному сбору и накоплению персональных данных (в социальных сетях, браузерах, ОС и т.д.) с всеобщим увлечением радиоактивностью в начале XX века.

http://idlewords.com/talks/haunted_by_data.htm

We're very much in the 'radium underpants' stage of the surveillance economy. — резюмировал автор.
waqur: (Евро)
Похоже, новая Windows 10 менее популярна у юзеров, чем предполагалось. Пришлось мелкомягким включить её принудительное пропихивание через Windows Update:
http://arstechnica.com/information-technology/2015/09/microsoft-is-downloading-windows-10-to-pcs-even-if-you-dont-reserve-a-copy/

Шестигиговый апдейт качается как критическое обновление, по принципу "сначала скачали, а потом спросили юзера, надо ли оно вообще". Неважно, что у некоторых пользователей платный интернет-трафик. Неважно, что не у всех пользователей достаточно места на диске C:. Добровольно-принудительно. :)
waqur: (Евро)
Windows 10 имеет такую privacy policy, что её или запретят в России, или сделают обязательной для всех.

Every 30 minutes Windows 10 sends all typed text to Microsoft
https://news.ycombinator.com/item?id=10053420

Windows 10 phones home when you search your start menu, even with Bing disabled
https://news.ycombinator.com/item?id=10037753

Even when told not to, Windows 10 doesn't stop talking to Microsoft
https://news.ycombinator.com/item?id=10053352

«Ваша конфиденциальность очень важна для нас». Читаем Заявление о конфиденциальности корпорации Майкрософт
http://habrahabr.ru/post/264885/
waqur: (Евро)
Оказывается, из wow64-эмулятора, в котором выполняются 32-битные приложения на 64-битной винде, можно сбежать. Процессор входит в long mode и покидает его с помощью инструкции "jmp на следующую команду" с префиксом 0x66. Код, выполняющийся в 64-битном режиме, имеет доступ к виртуальной памяти за 4-м гигабайтом, а также к регистрам R8-R15 и к старшим частям обычных регистров. В частности, во всех wow64-процессах в регистре R12 постоянно хранится указатель на TIB64 (64-битный Thread Information Block), откуда можно перейти на PEB64 (64-битный Process Environment Block), там хранится голова двусвязного списка всех загруженных в адресное пространство модулей, так можно вычислить базу, по которой загружена 64-битная ntdll.dll, распарсить её таблицу экспорта, и таким макаром получить указатель на функцию LdrGetProcedureAddress и остальные.

Энтузиасты соорудили даже соответствующую библиотеку: https://github.com/rwfpl/rewolf-wow64ext

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

Layout структур TIB и PEB зависит от версии Windows, так что в целом это достаточно непереносимая технология. Это для смелых, сродни прямому доступу к полям KUSER_SHARED_DATA. Строго говоря, очередной хотфикс или сервиспак, который затрагивает файл kernel32.dll или ntdll.dll, может всё сломать.
waqur: (Евро)
Авторы нового расширения к Google Chrome под названием "Password Alert" придумали интересную идею.
http://googleblog.blogspot.com/2015/04/protect-your-google-account-with.html

1) Поскольку среднестатистическому пользователю всё равно невозможно объяснить, что:
1.1) при вводе паролей нужно смотреть только на URL и полностью игнорировать дизайн сайта
1.2) и что в URL'е вида http://mail.google.com.lulzhaha.ws/... домен второго уровня вовсе не google.com,
2) а также поскольку антифишинговые списки могут не успеть загрузиться в браузер в случае направленной zero-day attack на конкретно этого пользователя с использованием индивидуального для него домена, например mail.google.com.foobar-454317.dyndns.org

Предлагается такое решение:

Показывать предупреждение, если пользователь пытается набирать пароль к своему Google Account на web-странице, домен которой не имеет отношения к компании Google.

Гениально! Заодно поощряется практика выбора разных паролей для разных сайтов.

Ещё требуется усовершенствование реализации, усовершенствование ТЗ (безусловный запрет на передачу данных, как при подделке https-сертификата, а не предупреждение пользователю-дураку, которое он не прочтёт или не поймёт), а также обобщение на другие сайты за пределами Гугла, однако самая концепция очень новая и интересная. И действующий прототип уже есть.

September 2017

S M T W T F S
     12
34567 89
10111213141516
17181920212223
24252627282930

Синдикация

RSS Atom

Автор стиля

Развернуть

No cut tags
Page generated 2017-09-21 03:26 am
Powered by Dreamwidth Studios