Pull to refresh
17
0
Oleksandr Kazymyrov @okazymyrov

User

Send message

Создаем пустой файл 0.txt и выполняем команду copy /b task_applocker.exe+0.txt notepad.exe, при этом мы получаем файл notepad.exe — по сути, копию task_applocker.exe c другим хешем.

А на каких системах это работает? Звучит как баг в AppLocker. Я протестировал calc.exe с нулевым 0.txt на Microsoft Windows 10 Enterprise 10.0.19044 N/A Build 19044. SHA256 совпали (проверял через 7z). Есть пример 2 одиноковых файлов с разными хешами?

Получение TLS ключей:
Он получил судебное предписание выдать ключи TLS, отказался выполнить распоряжение, в итоге уничтожил ключи и стёр файлы.… Имея ключ SSL, спецслужбы могут получить доступ к защищённому каналу между клиентом и сервером, что компрометирует имена и пароли пользователей.


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


Другими словами, Lavabit использовал дополнительный уровень шифрования на стороне клиента, а все зашифрованные сообщения инкапсулировал в SSL/TLS (ещё раз зашифровывал).

В связи с чем, я вы сказал, что основной целью ФРБ было:
ФБР и министерство юстиции не признавались, что доступ к серверам Lavabit им требовался с единственной целью — прочитать почту одного этого человека.

Но вдруг появляется необходимость внести изменения в хук, который уже живет в 20 проектах… Или внезапно нужно переносить разработку с Windows на Linux, а хук на PowerShell'е… Что делать?

А как такое решение: завести 21-й проект для хуков? Локальных хук будет лишь подгружать «главный» скрипт из репозитория. Этот главный скрипт определяет ОС и загружает другой скрипт, выполняющий непосредственно проверку.
Пример сценария с которым я сталкивался в реальной жизни. Есть мобильное устройство, на котором установлено приложение для оказания финансовых услуг. Предполагается, что первая инициализация приложения происходила через доверенную сеть пользователя, в результате которой сгенерирован секретный ключ на стороне клиента и сервера. Доступ к этим ключам получить не представляется возможным. Доступ к самому приложению не возможен из-за пароля, выбранного пользователем, и блокируется после нескольких попыток ввода неправильного пароля. Предполагается, что приложение переодически пересылает 1 цент на фиксированный счёт. Незащищенный паролем мобильный телефон был украден.

Цель злоумышленника перевести деньги на свой счёт и/или изменить количество переводимых денег.

Сценарий атаки без HMAC. Устанавливаем один из прокси-серверов с возможностью MitM, например mitmproxy или OWASP ZAP. Устанавливаем корневой сертификат на телефон. Далее перехватываем запрос, изменяем его. Profit.

Сценарий атаки c HMAC.
Проделывает тоже самое, что и в предыдущем пункте. Только теперь, для того, чтобы изменит сообщение нужно подделать и HMAC, среди данных передаваемого запроса к серверу содержится метка времени. Любая рассинхронизация с сервером более чем на 1 минуту приводит к автоматическому отфильтровыванию сообщения. Хэш (HMAC) берётся от всех полей заголовка http запроса и данных.
Ну тогда вы уже ответили на вопрос в своём комментарии. Всё зависит от того где и как использовать, и от входных данных конечно же.
Я говорю про свой конкретный сценарий.

Я всё же настаиваю, чтобы вы описали Ваш конкретный сценарий в отдельной статье, и объяснили почему проверка целостности данных, при помощи HMAC, лишняя и не имеет смысла.

Конкретно в сфере финансов — такой подход оправдан.
По вашему, сопровождать shared secret keys чем-то легче?

При симметричной криптографии всё можно засунуть в один сервер. А при безопасной реализайии ИВК, нужно отдельная инфраструктура со своими требованиями. Это не просто взяли сгенерировали кучу самоподписанных сертификатов и раздали их доверенным пользователям.
Вы предлагаете мне строить второй уровень шифрования (именно шифрования) поверх HTTPS?

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

«HTTPS скомпроментирован» как автоматическую компроментацию всего приложения

А вы не сталкивались с больших компаниями, у которых есть свои ЦС, и которые фильтруют любой трафик, включая HTTPS (и это прописано в политике ИБ)?
Ну, например, можно целиком все сообщение подписывать ЭЦП, или вообще подписывать и шифровать.

В теории действительно более безопасней. А вы пробовали это реализовать на практике? Основная проблема будет в управлении ключами. Необходимо будет создавать и сопроваждать инфраструктуру открытых ключей. У какждого метода есть свои плюсы и минусы. Тот же SRP может быть использован, в некоторых случаях, в качестве замены на мобильных устройствах.
Эээ, я всегда считал, что если у нас установлено https-соединение, то получающая сторона может быть уверена, что получает именно те данные, которые отправила передающая сторона. Я где-то не прав?

Нет, почему же, Вы правы. Давайте попробую объяснить немного по другому. Конфеденциальность и целостность данных может происходить на уровне браузера (установлено HTTPS соединение) и на уровне пользователя (сервер проверяет, что данные не были изменены до/после/во время HTTPS сессии). Если HTTPS какием-то образом скомпроментирован, то должен оставаться ещё один уровень безопасности.

Хотя даже я слукавил. Основная цель HTTPS — это проверка того, что вы общаетесь с нужным сервером/клиентом (для защиты от атаки человек посередине). А конфеденциальность и целостность это уже побочные услуги, так сказать в дополнение.

Если сделать предположение, что HTTPS отсутствует (или может быть выполнена атака), то общение с сервером всё ровно должно происходить в защищённом режиме. Или должно быть доказано, что при таких условия злоумышленнику понадобится больше времени для компроментации информации, чем время жизни самой информации.
Чем реализация в статье плоха, с точки зрения ИБ, если не принемать во внимание атаку по времени?
Вопром в том, какие у этого метода преимущества по сравнению с соседними, которые заодно обеспечивают, например, и конфиденциальность.

HTTPS сам по себе обеспечивает лишь конфиденциальность данных, иногда ещё и целостность, при передаче браузер<->сервер (или сервер<->сервер). Но о самих данных он ничего не знает (прсто байтики информации). Ему будет всё ровно «sum=10» или «sum=1000». Проверку целостности «sum» и пытается выполнить автор при помощи HMAC.

Или вы говорите про какие-то другие «соседние методы»?
Оффтоп. Вы уже так много материала написали по поводу данной статьи, что можно все комментарии собрать и оформить в виде отдельной статьи со своим видением ситуации.

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

А вообще, автор рассматривает один из методов (причём не самый плохой) обеспечения целостности данных, а не универсальный методо защиты от всех существующих и потенциальных атак. Он ничего не упоминает об обеспечении конфеденциальности или неотказуемости (это к ЕЦП).
Приведу цитату из всё той же статьи:
Выглядит вполне безопасно, так ведь? Вы уверены?

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


Из которых самый простой — это просто закрыть дырку (не отдавать зависимое от времеи сравнение).

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

Теми, кто тестирует эти системы. :)

… потому что в описываемых автором платежных сценариях по этому https дальше полетят данные моей кредитной карты.

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


Предположения:
  • 1024 — количество запросов;
  • 256 — количество символов в байте;
  • 256 — количество байт в хэш-значении.


Метка времени — это хорошо, но в данном случае ее нет.

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

(Я правильно понимаю, что вы считаете тайминг-атаку пренебрежимой опасностью?)

Я считаю атаку по времени ещё одним видом атаки, от которой существуют свои методы защиты.
Вопрос начинался с
в чем выигрыш от использования HMAC (по сравнению ...


При тестировании веб-приложений в финансовом секторе (о котором не раз упоминал автор) предпалагается, что HTTPS соединение может быть прослушано. Далее ответ на ваш вопрос в предыдущем комментарии.
Для рассматриваемого случая необходимо выполнить минимум 1024*256*256= 226 запросов. Пусть один запрос равен 1 КБ, тогда вам необходимо передать 65 ГБ информации к серверу (столько же на получение), чтобы вычислить HMAC для одного фиксированного сообщения на основе атаки по времени.

Вы можете сами расчитать вероятность того, что ни однин слой безопасности вас не отфильтрует (примеры). К тому же в нормальных приложениях используется метка времени, что даёт дополнительную защищаету от данной атаки.
(1) Вы же сами дали ответ на свой вопрос в своём комментарии. В абзаце описании атаки с увеличением длины сообщения вы найдёте ответы, если рассматривать схемы построеные с применением классической схемы Меркла-Дамгарда, коим и является SHA-2.
Да, действительно в теории так и есть. Но что же происходит в реальной жизни?

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

Information

Rating
Does not participate
Location
Норвегия
Date of birth
Registered
Activity