The OpenNET Project / Index page

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

Раскрыты детали новой атаки на различные реализации TLS

10.02.2019 10:33

Исследователи из компании NCC Group раскрыли сведения (PDF) о новой атаке по сторонним каналам, позволяющей через анализ остаточных данных в процессорном кэше восстановить содержимое, передаваемое через каналы связи, зашифрованные при помощи протоколов TLS и QUIC. С некоторыми оговорками атака затрагивает и протокол TLS 1.3.

Атака может применяться для перехвата зашифрованных сеансов при условии выполнения кода атакующего на одном CPU с жертвой (например, на многопользовательских системах или при возможности изолированного выполнения кода атакующего на системе жертвы) и наличия контроля за сетевым шлюзом (например, через организацию подключения клиента к фиктивной точке доступа).

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

Так как утечки состояний на основе активности сервера уже давно блокированы в реализациях криптографических библиотек, в новой атаке для определения корректности блоков предлагается анализировать следы работы библиотек в процессорном кэше. Для атаки применимы различные техники извлечения остаточных данных из процессорного кэша, такие как Flush+Reload, Prime+Probe и методы на основе манипуляций с блоком предсказания переходов. Атака является достаточно эффективной и позволяет восстановить все 2048 бит шифротекста RSA за время, не превышающее 30 секунд.

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

Для атаки на клиентские браузеры может применяться метод, напоминающий атаки BEAST и POODLE, и требующий запуска подконтрольного атакующему JavaScript-кода в браузере жертвы (например, через подстановку кода в любой незашифрованный HTTP-ответ при наличии контроля за транзитным шлюзом). JavaScript-код используется для отправки на защищённый сайт, с которым работает жертва, фиктивных запросов с изначально известными контрольными метками, которые используются атакующим для воссоздания отдельных шифрованных блоков. Так как для успешной атаки необходимо проанализировать тысячи проверочных запросов, которые не удаётся отправить в рамках установленного в браузерах таймаута (обычно 30 секунд), предложен метод распараллеливания подобных запросов через их отправку к различным TLS-серверам, на которых используется сертификат с одним и тем же открытым ключом.



  1. Главная ссылка к новости (https://www.nccgroup.trust/us/...)
  2. OpenNews: Новый метод атаки на TLS, затрагивающий 27 из 100 крупнейших сайтов
  3. OpenNews: Новая техника атаки на SSL/TLS, которой подвержены 33% HTTPS-сайтов
  4. OpenNews: Новая атака SLOTH, затрагивающая протоколы TLS 1.2, SSH и IKE/IPsec с MD5 и SHA-1
  5. OpenNews: Новая атака на TLS, позволяющая откатиться к уязвимым методам шифрования
  6. OpenNews: Атака NetSpectre, приводящая к утечке содержимого памяти по сети
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/50121-tls
Ключевые слова: tls, attack
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (20) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:48, 10/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    Тема LibreSSL не раскрыта
     
     
  • 2.22, Аноним (22), 15:06, 14/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А что там раскрывать, кривой форк от левых чуваков
     

  • 1.2, Аноним (2), 11:53, 10/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >>для атаки необходимо выполнение кода на том же CPU и контроль за сетевым шлюзом
    >>Для атаки на клиентские браузеры может применяться метод, требующий запуска подконтрольного атакующему JavaScript-кода в браузере жертвы через подстановку кода в любой >>незашифрованный HTTP-ответ при наличии контроля за транзитным шлюзом

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

     
     
  • 2.3, Аноним (3), 12:13, 10/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С контролем транзитного трафика проблем как раз меньше всего - для выуживания паролей и номеров кредитных карт устраивается ловля на подставную WiFi точку доступа. А для более серьёзных применений у спецслужб есть административный рычаг. Труднее с выполнением кода на стороне клиента, но до недавних пор через JavaScript вполне можно было проводить атаки по анализу кэша. Теперь разве что для атаки спецслужб на облака описанный метод применим.
     
  • 2.4, Аноним (4), 13:55, 10/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    а смысл возиться с расшифровкой трафика если имея доступ к тачке можно снимать уже расшифрованные сообщения из самих программ?
     
     
  • 3.7, аноним3 (?), 16:11, 10/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    это сделали ради развлечения))) и эго потешить.
     
  • 3.9, Коммунист (?), 17:09, 10/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А кто сказал, что у твоего кода будут локальные привилегии на прослушивание сетевого трафика? В уязвимости главное то, чтобы твой код исполнялся на одном CPU, даже если он из-под отдельного пользователя или в песочнице браузера.
     

  • 1.5, Аноним (5), 14:22, 10/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    > шифротекст, зашифрованный

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

     
     
  • 2.6, Sw00p aka Jerom (?), 14:30, 10/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    там же запятая)
     

  • 1.8, Ilya Indigo (ok), 16:40, 10/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если я правильно понял, для защиты на вэб-сервере и на почтовом сервере нужно использовать только серт на эпилептических кривых и разрешить только TLS 1.3?
     
     
  • 2.10, A.Stahl (ok), 17:29, 10/02/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >на вэб-сервере и на почтовом сервере нужно использовать только серт на эпилептических кривых

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

     
     
  • 3.19, InuYasha (?), 11:33, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    FU****
    Извиняюсь, промахнулся, хотел +1 поставить.
    А по теме - устойчивость эллиптических кривых еще не совсем доказана.
     
     
  • 4.20, Аноним (20), 11:34, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В АНБ почему-то не то что не спешат их использовать, а спешат их НЕ использовать... для себя.
    Вот и думай - почему.
     
  • 2.12, axredneck (?), 19:33, 10/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    причем обязательно на идиопатических, потому что фотосенсибили... (язык сломаешь) короче, фото-эти-самые уязвимы, так как недостаточно кривые.
     

  • 1.14, Аноним (14), 21:59, 10/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот это
    да
     
  • 1.15, Аноним (15), 01:06, 11/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Помнится, кто-то недавно в комментах к другой новости очень громко кричал, что TLS 1.3 не нужен и совсем-совсем не улучшает безопасность. И отказывался предоставить доказательства, типа как же я предоставлю доказательства отсутствия чего-то.
     
     
  • 2.16, Аноним (-), 03:09, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    К чему такие глупые коментарии на техническом ресурсе? Не можете что-то дельное сказать - не говорите ниче. Хочется высказаться - валите в соцсети или заведите блог.
     

  • 1.17, Аноним (17), 04:00, 11/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > требующий запуска подконтрольного атакующему JavaScript-кода в браузере жертвы (например, через подстановку кода в любой незашифрованный HTTP-ответ при наличии контроля за транзитным шлюзом)

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

     
     
  • 2.21, Аноним84701 (ok), 17:46, 11/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    -----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-----

     

  • 1.18, ыы (?), 08:48, 11/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    следующим этапом развития процессоров- вероятно станет выделение процессора на каждую задачу в монопольном режиме. Ядер сейчас в процессорах- как грязи...и дальше будет больше... так чего мелочится? к том уже разные задачи требуют мягко говоря разной процессорнной мощности. зачем занимать сложное ядро простой задачей? соответственно ядра в процессорах будут тоже разными - 1000 простых ядер, 100 чуть более сложных, 10 сложных... вангую новый виток .искомерятельных тредов...
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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