The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Раскрыты детали новой атаки на различные реализации TLS"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раскрыты детали новой атаки на различные реализации TLS"  +/
Сообщение от opennews (??), 10-Фев-19, 11:48 
Исследователи из компании NCC Group раскрыли (https://www.nccgroup.trust/us/about-us/newsroom-and-events/b.../) сведения (https://eprint.iacr.org/2018/1173) (PDF (https://eprint.iacr.org/2018/1173.pdf)) о новой атаке по сторонним каналам, позволяющая через анализ остаточных данных в процессорном кэше восстановить содержимое каналов связи, зашифрованных при помощи протоколов TLS и QUIC. Проблема в том числе затрагивает протокол TLS 1.3. Атака может применяться на многопользовательских системах для перехвата зашифрованных сеансов других пользователей, при наличии контроля за транзитным трафиком жертвы (для атаки необходимо выполнение кода на том же CPU и контроль за сетевым шлюзом, например, через организацию подключения клиента к фиктивной точке доступа).


Атака позволяет восстановить шифротекст, зашифрованный при помощи RSA-ключа, через анализ  добавочного заполнения (padding oracle), используемого для выравнивания зашифрованных данных по границе блока.
Принцип атаки основан на усовершенствованном методе, предложенном  Даниэлем Блейхенбахером (Daniel Bleichenbacher) в 1998 году, суть которого в том, что атакующий на основании разных ответов от сервера может отделить корректные и некорректные блоки добавочного заполнения (padding oracle) в режиме PKCS #1 v1.5. Манипулируя информацией о корректности блоков добавочного заполнения атакующий может путём перебора определить (https://eklitzke.org/the-cbc-padding-oracle-problem) подходящий шифротекст.

Так как утечки состояний на основе активности сервера уже давно блокированы в реализациях криптографических библиотек, в новой атаке для определения корректности блоков предлагается анализировать следы работы библиотек в процессорном кэше. Для атаки применимы различные техники извлечения остаточных данных из процессорного кэша, такие как Flush+Reload (https://www.opennet.dev/opennews/art.shtml?num=46812), Prime+Probe (https://www.opennet.dev/opennews/art.shtml?num=48091) и на основе манипуляций (https://www.opennet.dev/opennews/art.shtml?num=49608) с блоком предсказания переходов.

Проблема была выявлена в ноябре 2018 года и сообщена разработчикам библиотек, но детали раскрыты только сейчас, после публикации исправлений. Проблема затрагивает реализации TLS в библиотеках  OpenSSL, Amazon s2n, MbedTLS, Apple CoreTLS, Mozilla NSS, WolfSSL и GnuTLS.  Не подвержена атаки оказались библиотеки BearSSL и BoringSSL.
Атака является достаточно эффективной и позволяет восстановить все 2048 бит шифротекста RSA за время, не превышающее 30 секунд. В TLS 1.3 не используется обмен ключами на основе RSA, поэтому для атаки на TLS 1.3 применяется обходной манёвр, позволяющий откатить шифрованное соединение на прошлую версию протокола через спуфинг TCP-пакетов.


Для атаки на клиентские браузеры может применяться метод, напоминающий атаки BEAST (https://www.opennet.dev/opennews/art.shtml?num=31797) и POODLE (https://www.opennet.dev/opennews/art.shtml?num=40833), и требующий запуска подконтрольного атакующему JavaScript-кода в браузере жертвы (например, через подстановку кода в любой незашифрованный HTTP-ответ при наличии контроля за транзитным шлюзом). JavaScript-код используется для отправки на защищённый сайт, с которым работает жертва, фиктивных запросов с изначально известными контрольными метками, которые используются атакующим для воссоздания отдельных блоков для шифра TLS/SSL. Так как для успешной атаки необходимо проанализировать тысячи проверочных запросов, которые не удаётся отправить в рамках установленного в браузерах таймаута (обычно 30 секунд), предложен (https://github.com/mimoo/RSA_PKCS1v1_5_attacks)  метод распараллеливания подобных запросов через их отправку к различным TLS-серверам, на которых используется сертификат с одним и тем же открытым ключом.

URL: https://www.nccgroup.trust/us/about-us/newsroom-and-events/b.../
Новость: https://www.opennet.dev/opennews/art.shtml?num=50121

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Раскрыты детали новой атаки на различные реализации TLS"  +10 +/
Сообщение от Аноним (1), 10-Фев-19, 11:48 
Тема LibreSSL не раскрыта
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Раскрыты детали новой атаки на различные реализации TLS"  +/
Сообщение от Аноним (22), 14-Фев-19, 15:06 
А что там раскрывать, кривой форк от левых чуваков
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Раскрыты детали новой атаки на различные реализации TLS"  –2 +/
Сообщение от Аноним (2), 10-Фев-19, 11:53 
>>для атаки необходимо выполнение кода на том же CPU и контроль за сетевым шлюзом
>>Для атаки на клиентские браузеры может применяться метод, требующий запуска подконтрольного атакующему JavaScript-кода в браузере жертвы через подстановку кода в любой >>незашифрованный HTTP-ответ при наличии контроля за транзитным шлюзом

----------------------------------------
O'rly? Может в конечном итоге вообще требуется возможность запуска вредоносного кода из загрузочного с сектора жёсткого диска до загрузки оси, а потом ось грузить внутри виртуальной машины нападающего кода и там уже перехватывать весь сетевой трафик? Контроль же за сетевым шлюзом как никак нужен, ну. Такие забавные условия нужны: и тебе исполнение кода на CPU жертвы, и тебе контроль сетевого шлюха и нешированный простой HTTP (не HTTPS) трафик, ага.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Раскрыты детали новой атаки на различные реализации TLS"  +1 +/
Сообщение от Аноним (3), 10-Фев-19, 12:13 
С контролем транзитного трафика проблем как раз меньше всего - для выуживания паролей и номеров кредитных карт устраивается ловля на подставную WiFi точку доступа. А для более серьёзных применений у спецслужб есть административный рычаг. Труднее с выполнением кода на стороне клиента, но до недавних пор через JavaScript вполне можно было проводить атаки по анализу кэша. Теперь разве что для атаки спецслужб на облака описанный метод применим.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Раскрыты детали новой атаки на различные реализации TLS"  –2 +/
Сообщение от Аноним (4), 10-Фев-19, 13:55 
а смысл возиться с расшифровкой трафика если имея доступ к тачке можно снимать уже расшифрованные сообщения из самих программ?
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

7. "Раскрыты детали новой атаки на различные реализации TLS"  +/
Сообщение от аноним3 (?), 10-Фев-19, 16:11 
это сделали ради развлечения))) и эго потешить.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

9. "Раскрыты детали новой атаки на различные реализации TLS"  +1 +/
Сообщение от Коммунист (?), 10-Фев-19, 17:09 
А кто сказал, что у твоего кода будут локальные привилегии на прослушивание сетевого трафика? В уязвимости главное то, чтобы твой код исполнялся на одном CPU, даже если он из-под отдельного пользователя или в песочнице браузера.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Раскрыты детали новой атаки на различные реализации TLS"  –4 +/
Сообщение от Аноним (5), 10-Фев-19, 14:22 
> шифротекст, зашифрованный

Два раза зашифрованный?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Раскрыты детали новой атаки на различные реализации TLS"  +1 +/
Сообщение от Sw00p aka Jerom (?), 10-Фев-19, 14:30 
там же запятая)
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "Раскрыты детали новой атаки на различные реализации TLS"  +/
Сообщение от Ilya Indigo (ok), 10-Фев-19, 16:40 
Если я правильно понял, для защиты на вэб-сервере и на почтовом сервере нужно использовать только серт на эпилептических кривых и разрешить только TLS 1.3?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Раскрыты детали новой атаки на различные реализации TLS"  +5 +/
Сообщение от A.Stahl (ok), 10-Фев-19, 17:29 
>на вэб-сервере и на почтовом сервере нужно использовать только серт на эпилептических кривых

Да, эпилептики неуязвимы!

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

19. "Раскрыты детали новой атаки на различные реализации TLS"  –1 +/
Сообщение от InuYasha (?), 11-Фев-19, 11:33 
FU****
Извиняюсь, промахнулся, хотел +1 поставить.
А по теме - устойчивость эллиптических кривых еще не совсем доказана.
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

20. "Раскрыты детали новой атаки на различные реализации TLS"  +/
Сообщение от Аноним (20), 11-Фев-19, 11:34 
В АНБ почему-то не то что не спешат их использовать, а спешат их НЕ использовать... для себя.
Вот и думай - почему.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

12. "Раскрыты детали новой атаки на различные реализации TLS"  +2 +/
Сообщение от axredneck (?), 10-Фев-19, 19:33 
причем обязательно на идиопатических, потому что фотосенсибили... (язык сломаешь) короче, фото-эти-самые уязвимы, так как недостаточно кривые.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

14. "Раскрыты детали новой атаки на различные реализации TLS"  +/
Сообщение от Аноним (14), 10-Фев-19, 21:59 
Вот это
да
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Раскрыты детали новой атаки на различные реализации TLS"  –2 +/
Сообщение от Аноним (15), 11-Фев-19, 01:06 
Помнится, кто-то недавно в комментах к другой новости очень громко кричал, что TLS 1.3 не нужен и совсем-совсем не улучшает безопасность. И отказывался предоставить доказательства, типа как же я предоставлю доказательства отсутствия чего-то.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Раскрыты детали новой атаки на различные реализации TLS"  +1 +/
Сообщение от Аноним (-), 11-Фев-19, 03:09 
К чему такие глупые коментарии на техническом ресурсе? Не можете что-то дельное сказать - не говорите ниче. Хочется высказаться - валите в соцсети или заведите блог.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

17. "Раскрыты детали новой атаки на различные реализации TLS"  +/
Сообщение от Аноним (17), 11-Фев-19, 04:00 
> требующий запуска подконтрольного атакующему JavaScript-кода в браузере жертвы (например, через подстановку кода в любой незашифрованный HTTP-ответ при наличии контроля за транзитным шлюзом)

И потом ыксперты тут говорят, что никакой проблемы в открытом http нет. Пускай котики бегают, религия не позволяет шифровать и тратить 0.01% cpu.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Раскрыты детали новой атаки на различные реализации TLS"  +1 +/
Сообщение от Аноним84701 (ok), 11-Фев-19, 17:46 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> И потом ыксперты тут говорят, что никакой проблемы в открытом http нет.
> Пускай котики бегают, религия не позволяет шифровать и тратить 0.01% cpu.

Это потому что еще ранее Ыксперты заучили мантру "аутентификация совсем-совсем не нужна, если шифровать канал, поэтому можно и нужно сэкономить 0.001% CPU!".
В итоге, до сих пор нет нормальной авторизации/аутентификации в стандарте веба, пароли и прочее могут спокойно хранить в плейн -- зато/ведь канал передачи зашифрован!!1

разъясняю:
проблема не в отсутсвии шифрования (содержимое скрипта может узнать любой, обратившийся к тому же серверу), а в отсутсвии аутентификации, когда содержимое подменяется. HTTPS тут не более, чем костыль.
Не верящим предлагаю попробовать подменить мое сообщение:
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQTQaLRjLMt2TTkWkoZ+PeLyUDdO7wUCXGGJWwAKCRB+PeLyUDdO
799RAP9Od5K6EBPLx1h2qxCvDoAZtuPTnN1yUc7+r8Tmz+m1bAEAgP4y9YFhRjrZ
VHqKm8N8SsjAnN8XK4aaGZ1LeDinu3Y=
=vjuZ
-----END PGP SIGNATURE-----

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

18. "Раскрыты детали новой атаки на различные реализации TLS"  –1 +/
Сообщение от ыы (?), 11-Фев-19, 08:48 
следующим этапом развития процессоров- вероятно станет выделение процессора на каждую задачу в монопольном режиме. Ядер сейчас в процессорах- как грязи...и дальше будет больше... так чего мелочится? к том уже разные задачи требуют мягко говоря разной процессорнной мощности. зачем занимать сложное ядро простой задачей? соответственно ядра в процессорах будут тоже разными - 1000 простых ядер, 100 чуть более сложных, 10 сложных... вангую новый виток .искомерятельных тредов...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру