SSL/TLS: история уязвимостей
•Download as PPTX, PDF•
0 likes•2,143 views
SSL/TLS: история уязвимостей
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to SSL/TLS: история уязвимостей
Similar to SSL/TLS: история уязвимостей (20)
More from Positive Hack Days
More from Positive Hack Days (20)
SSL/TLS: история уязвимостей
- 1. SSL/TLS: история уязвимостей Лепихин Владимир Учебный центр «Информзащита»
- 3. Предпосылки (2) 3 TLS Connection 1 TLS Connection 2 Multifunction Man-in-the-Middle gateway
- 5. Two main types of handshakes in TLS 5 Протокол Согласование ключей Аутентификация RSA handshake RSA RSA DH handshake DH RSA/DSA
- 6. DH handshake 6 Client Hello { … Client Random … } Server Hello { … Server Random Server Certificate Server DH parameter … } ClientKeyExchange { … Client DH parameter … } Premaster secret Premaster secret
- 7. Server DH parameters (RFC 5246) 7
- 8. Тяжёлое наследие прошлого 8 Client Hello { … Client Random … CipherSuite TLS_DHE_EXPORT…. }
- 9. Вариант атаки 9 Client Hello TLS_DHE_... Client Hello TLS_DHE_EXPORT... Server Hello TLS_DHE_... Server Hello TLS_DHE_EXPORT... Server Certificate Server DH parameter (dh_p512,… ) master secret Вычисление master secret Server Hello Done ClientKeyExchange ServerFinished
- 10. Что это было? TLS Logjam – очередной вариант атаки на SSL/TLS https://weakdh.org/ 10
- 11. Как всё начиналось? 11 … - 1994 Версия 1.0 Внутренняя разработка компании Netscape Communications Февраль 1995 Версия 2.0 Ноябрь 1996 Версия 3.0 1999 TLS 1.0 RFC 2246 2006 TLS 1.1 RFC 4346 2008 TLS 1.2 RFC 5246
- 12. Схемы атак на SSL/TLS 12
- 14. Атаки на SSL Часть 1 «Обычный» человек посередине (атаки на механизм аутентификации) Часть 2 BEAST CRIME …
- 15. «Обычный» человек посередине (HTTPS) TLS Connection 1 TLS Connection 2 HTTP HTTPS
- 16. «Обычный» человек посередине (HTTPS) TLS Connection 1 TLS Connection 2 Основная проблема: «выдержать» проверку сертификата клиентом
- 17. Пример 1: проверка CN TLS Connection 1 TLS Connection 2 CN (Common Name) www.example.com
- 18. Пример 1: проверка CN TLS Connection 1 TLS Connection 2 CN = www.example.com0.evil.com www.example.comevil.com *0.evil.com - ?
- 19. Пример 2: OCSP Запрос OCSP tryLater (3)
- 20. Ещё варианты SSL Rebinding SSL Cache poisoning http://www.google.com https://ssl.com foo.js
- 21. SSL Strip HTTP HTTPS 1. Переход в результате «редиректа» 2. Переход по ссылке
- 22. Multifunction Man-in-the-Middle gateway 22 Linux Mallory apache sslstrip transparent proxy configuration …
- 23. Пример: mallory&sslstrip 23 Sslstrip Log Mallory DB SQLite DB Поиск&Парсинг
- 25. Всё, что нужно знать о шифровании Алгоритмы шифрования Симметричные Асимметричные Симметричные шифры Потоковые Блочные Симметричные алгоритмы и режимы шифрования ECB CBC OFB DES DES-ECB DES-CBC DES-OFB AES AES-ECB AES-CBC AES-OFB BF BF-ECB BF-CBC BF-OFB
- 26. Cipher Block Chaining В режиме CBC добавляется механизм обратной связи: результаты шифрования предыдущих блоков влияют на шифрование текущего блока. В первом блоке используется вектор инициализации (IV), передаваемый по сети в открытом виде 26 Сообщение (пакет, record)
- 27. Вектор инициализации в TLS (RFC 5246)
- 28. Расшифрование Пример: расшифрование 1-го блока 28 Ciphertext Block cipher decryption Key IV Plaintext
- 29. BEAST Browser Exploit Against SSL/TLS Attack (BEAST) 29
- 30. Шаг 1: перехват сообщения Ci = Encrypt (Key, Password XOR Ci-1) 30 Password Pi Сi
- 31. Шаг 2: формирование сообщения Первый блок P1 = Ci-1 XOR IV XOR Password С1 = Encrypt (Key, Р1 XOR IV) С1 = Encrypt (Key, Ci-1 XOR Password) = Ci 31 Password Pi Сi P1 С1
- 32. POST запрос POST /default/login.asp?folder=18 HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content-Length: 78 login=user1&passwd=12345&Authorize.x=25&Authorize.y=6 P O S T / d e f a u l t / l o g i n . a s p ? f o l d e r = 1 8 H T T P / 1 . 1 r n C o n t Граница блока
- 33. CRIME Compression Ratio Info-leak Made Easy (CRIME) 33
- 34. POST запрос POST / HTTP/1.1 Host: example.com User-Agent: Mozilla /5.0…. Cookie: sessionid =1234567890abcdefgh <body> Length (encrypt(compress(header + body))
- 35. Модифицированный POST запрос POST / HTTP/1.1 Host: example.com User-Agent: Mozilla /5.0…. Cookie: sessionid=1234567890abcdefgh <body> POST /sessionid =0 HTTP/1.1 Host: example.com User-Agent: Mozilla /5.0…. Cookie: sessionid=1234567890abcdefgh <body>
- 36. Модифицированный POST запрос POST / HTTP/1.1 Host: example.com User-Agent: Mozilla /5.0…. Cookie: sessionid=1234567890abcdefgh <body> POST /sessionid =1 HTTP/1.1 Host: example.com User-Agent: Mozilla /5.0…. Cookie: sessionid=1234567890abcdefgh <body>
- 37. Фрагментированный запрос POST /Padddddddddding HTTP/1.1 Host: example.com User-Agent: Mozilla /5.0…. Cookie: sessionid=1 234567890abcdefgh <body>
- 38. TIME – продолжение темы Timing Info-leak Made Easy (TIME) 38 GET /somefile.html HTTP/1.1 User-Agent: Mozilla /5.0…. HTTP/1.1 200 OK Content-Length: 340 Content-Type: text/html Last-Modified: Wed, 10 Jul 2002 09:42:51 GMT Server: Microsoft-IIS/6.0 <HTML> <HEAD> …..
- 39. Критерии сравнения 39 Техника плавающего окна для ТСР
- 40. BREACH Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext (BREACH) 40 GET /somefile.html HTTP/1.1 User-Agent: Mozilla /5.0…. HTTP/1.1 200 OK Content-Length: 340 Content-Type: text/html Last-Modified: Wed, 10 Jul 2002 09:42:51 GMT Server: Microsoft-IIS/6.0 <HTML> <HEAD> …..
- 41. LUCKY 13 41 Payload MAC Padding Шифртекст
- 42. «Очередной» блок 42 Блок Ci POST /path Cookie: name=value...rnrnbody ‖ 20byte MAC ‖ padding Шифруемое сообщение (запрос) P O S T / p a t h C o o k i e : Граница блока
- 43. Примеры заполнителей 43 G E T 5 5 5 5 5 Граница блока P O S T 4 4 4 4 P R O T O C O L S 7 7 7 7 7 7 7 P R O T O C O L 8 8 8 8 8 8 8 8
- 45. Расшифрование Происходит с использованием предыдущего блока 45 Ciphertext2 Block cipher decryption Key Ciphertext1 Plaintext предыдущий текущий Кто здесь? Ciphertext1 XOR Plaintext
- 46. Ещё раз по-другому 46 Вычисление Р1 - РN P1 = Decrypt (Key, Ci) XOR Ci-1 Проверка и удаление заполнителя Проверка и удаление МАС Расшифрованное сообщение
- 47. Формирование Ciphertext1 Меняем последний байт 47 Ciphertext2 Block cipher decryption Key Plaintext текущий Кто здесь? 256 попыток Ciphertext1 … … … … … 0х00
- 48. Формирование Ciphertext1 Меняем последний байт 48 0x1 Ciphertext2 Ciphertext1 (IV) Plaintext Кто здесь? Decrypt Меняем Корректный заполнитель
- 49. The POODLE Attack 49 Padding Oracle On Downgraded Legacy Encryption CVE-2014-3566 В отличие от BEAST и Lucky 13, не имеет workaround
- 50. The POODLE Attack 50 Многие реализации TLS в целях обратной совместимости поддерживают SSL 3.0 Как правило, в процессе TLS Handshake выбирается максимальная поддерживаемая обеими сторонами версия Многие TLS-клиенты используют так называемый «downgrade dance»: если связь не устанавливается, делается новая попытка, но уже по более старому протоколу SSL 3.0 TLS 1.2 Fail OK
- 51. The POODLE Attack 51 Нарушитель может намеренно «помешать» установлению соединения и создать условия для выбора SSL 3.0 Далее могут быть использованы уязвимости SSL 3.0, в частности, padding oracle attack
- 52. Небольшое дополнение: SSL Renegotiation Attack
- 53. SSL Renegotiation Attack TLS Handshake 1 1 2 TLS Handshake 2 3 GET /example.com/sendmoney 4 renegotiation 5 6 GET /example.com/sendmoney
- 54. Возвращаясь к Logjam: FREAK 54 FREAK (Factoring Related Attack on Keys)
Editor's Notes
- Основное назначение протокола SSL – защита данных двух взаимодействующих приложений, например, браузера и сервера HTTP. Изначально SSL был ориентирован на защиту протоколов прикладного уровня (http, telnet, ftp), клиентские и серверные части которых используют интерфейс сокетов, отсюда и возникло название протокола. В настоящее время протокол имеет более общее название – Transport Layer Security (TLS). Это означает, что реализуемые протоколом TLS защитные механизмы работают на транспортном уровне, а если точнее, между прикладным и транспортным уровнем стека TCP/IP. За последние несколько лет было обнаружено несколько «громких» уязвимостей в протоколе TLS, что породило некоторый всплеск интереса к этой теме. Цель данного доклада – систематизация информации по уязвимостям SSL/TLS. Как будет видно далее, все они являются последствиями одних и тех же слабостей. До недавнего времени использование этих слабостей было почти невозможно на практике. Но при наличии некоторых условий теория может «обернуться» практикой. Результаты сканирования и попытка создания универсального шлюза.
- Универсальный «человек посередине». Он должен контролировать работу всех протоколов из состава TLS/SSL
- …и приветствия. Скучно, правда? Тем не менее, в процессе рассказа будут происходить отсылки на описание протокола TLS. В частности, предлагается обратить внимание на сообщения, выделенные жирным шрифтом. Эти сообщения делают процедуру согласования параметров шифрования различной.
- Какие бывают хэндшейки? Как правило, согласование параметров шифрования основано на асимметричной криптографии. RSA хэндшейк использует только один вариант асимметричного шифра – RSA. DH хэндшейк использует два варианта (алгоритма), но в то же время делает процесс выведения ключей независящим от закрытого ключа сервера (forward secrecy). Бывают и другие варианты…, например, Elliptic Curve Diffie-Hellman (ECDHE cipher suites).
- Сервер вычисляет свою часть DH, подписывает своим ключом и отсылает клиенту. Из Premaster secret потом выводится сеансовый ключ Parameters (группа Диффи-Хэллмана) обычно имеют фиксированные значения. Размер dh_p 2048 считается безопасным.
- Server DH parameter – поподробнее. Значения зависят от выбранного чуть ранее набора параметров защиты трафика. Клиент предлагает варианты, а сервер выбирает один из предложенных. Обратим внимание на параметр – dh_p.
- Из-за экспортных ограничений иногда в процессе согласования параметров защиты их выбор может быть «невелик». Если же клиент в списке наборов укажет TLS_DHE_EXPORT, размер параметра dh_p будет равен 512. При этом о «понижении» клиенту не сообщается.
- Как это может быть использовано? Злоумышленник подменяет предлагаемые клиентом параметры шифрования на более слабые (с экспортными ограничениями). На вычисление master secret «человеку посередине» требуется примерно 10 мин (вычисление дискретного логарифма) Далее он может отвечать на запросы клиента
- Протокол Secure Sockets Layer (SSL) был разработан и реализован компанией Netscape Communications в 1994 году. Широкую известность получила версия 2, появившаяся в феврале 1995 года. Впоследствии она была подвергнута существенной переработке, и в конце 1996 года появилась версия 3, которая и стала основой современных реализаций протоколов SSL/TLS. Строго говоря, SSL версии 1.0 изначально был встроен в браузер Mosaic, а версия 2.0 появилась в конце 1994 года, когда создатели Mosaic сформировали собственное предприятие, названное Netscape Communications и представили новый браузер, названный Netscape Navigator.
- Цель практически всех атак на SSL/TLS – нарушение конфиденциальности. Для этого нарушитель должен иметь доступ к трафику. Иногда он должен иметь возможность влиять на трафик. Следовательно, возможные места включения злоумышленника – в разрыв или пассивное прослушивание.
- Таким, образом, лучший инструмент атак на SSL – «многофункциональный» шлюз.
- Или хотя бы просто проверку
- sslsniff
- В ответе OCSP подписывается только фрагмент данных
- В принципе уже достаточно для осуществления идеи универсального человека посередине
- Часть 2 Существует два основных типа симметричных алгоритмов: Блочные шифры Потоковые шифры Блочные шифры оперируют блоками открытого текста и шифртекста, потоковые – битовыми или байтовыми потоками открытого текста и шифртекста. Блочный шифр при использовании одного и того же ключа всегда «превращает» один и тот же блок открытого текста в один и тот же блок шифртекста. Потоковый шифр при каждом шифровании превращает один и тот же бит или байт открытого текста в различные биты или байты шифртекста. Режим шифрования – это совокупность базового шифра, обратной связи какого-либо типа и нескольких простых операций. Имеется три основных режима шифрования: Режим электронной кодовой книги (Electronic Codebook, ECB). Ещё один термин: режим простой замены. Режим сцепления блоков шифртекста (Cipher Block Chaining – CBC). Режим обратной связи по шифртексту (Cipher Feedback – CFB). Ещё один термин: гаммирование с обратной связью. Режим обратной связи по выходу (Output Feedback – OFB)
- В режиме CBC добавляется механизм обратной связи: результаты шифрования предыдущих блоков влияют на шифрование текущего блока. Получается, что каждый блок шифртекста зависит не только от шифруемого блока открытого текста, но и от всех предыдущих блоков открытого текста. В режиме CBC перед шифрованием очередного блока над открытым текстом и предыдущим блоком шифртекста выполняется операция XOR. Блоки имеют небольшой размер (как правило, 16 байт). In CBC mode, to make each message unique, an initialization vector (IV) is used in the first block. An IV is a random string that is XORed with the plaintext message prior to encryption. Each block of plaintext is XORed with the previous cipher text block before being encrypted. In other words, each cipher text block depends on all plaintext blocks processed up to that point as shown in the figure below. It’s important to note that here IV is not a secret; it only adds randomness to the output. IV is sent along with the message in clear text format.
- It was noticed that TLS 1.0, when dealing with multiple packets, allows the following packets to use an IV that is the last cipher text block of the previous packet. In other words, an attacker who can see the encrypted traffic can note the IV used for session cookie (Why? Because the cookie’s location is predictable). Simply put, an active attacker will be able to gather the IVs for each record just by sniffing the network. So if the attacker can “guess” a plaintext message, he can make a guess at the session cookie and see if the cipher text matches. [Note that, since this is a MITM attack, the attacker can mix his traffic with the victim traffic to see the results].
- Расшифрование происходит в обратной последовательности
- Цель атаки – в перехваченном сообщении определить фрагмент открытого текста
- Предположим, нам известно, что блок Ci перехваченного зашифрованного сообщения содержит известный открытый текст Pi (Password, Cookie…). Также нам известно, что последний блок сообщения используется как вектор инициализации для следующего сообщения. Итак, мы знаем: Pi содержит пароль (его мы не знаем) Вектор инициализации для следующего сообщения
- Формируем сообщение таким образом, что его первый блок P1 = Ci-1 XOR IV XOR Password. Ci-1 берём из предыдущего сообщения, IV нам известен, а Password – это наше предположение. Если наше предположение относительно пароля верное, то первый зашифрованный блок нового сообщения C1 будет равен ранее перехваченному Ci. И наоборот: если предположение неверное, равенства не будет. Так мы можем проверять наши предположения. Но сообщение нужно передать по тому же защищенному каналу связи. На практике при размере блока в 16 байт полный перебор предполагает слишком большое число вариантов. То есть перебор возможен, если часть символов блока известна.
- Получив сообщение для отправки, SSL разбивает его на блоки, при необходимости сжимает, вычисляет код аутентичности MAC, шифрует, добавляет заголовок и передает. Сжатие является необязательной функцией SSL. Атака CRIME основана на изменении размера сжатых сообщений, что происходит, например, при добавлении аутентификационных данных куки. Тот факт, что сжатие происходит до шифрования, а информация не подвергается дополнительной рандомизации, позволяет злоумышленнику расшифровать сообщение и, если украдены куки, произвести несанкционированную авторизацию в системе.
- Хотя само сообщение недоступно для нарушителя, его длина известна. Также нарушителю известно, что сообщение содержит sessionid=???
- Нарушитель модифицирует запрос таким образом, что фрагмент sessionid= встретится в тексте 2 раза. Отработает сжатие, повторяющийся фрагмент будет удалён.
- Совпадение лучше.
- Можно также воспользоваться тем фактом, что при превышении 16 Кбайт TLS record будет перед сжатием фрагментировать сообщение и сжимать фрагменты отдельно.
- TIME – это продолжение темы использования сжатия. Только для ответа НТТР. Сжатие для TLS может быть отключено, но для HTTP оставлено. CRIME attack has two major practical drawbacks. The first issue is that CRIME attack is Solely aimed at HTTP requests. However, most of the current web does not compress HTTP requests. The few protocols that did support HTTP requests compression (SSL compression and SPDY) had dropped their support following the attack details disclosure, by thus rendering the CRIME attack irrelevant. The second is the attack threat model: CRIME attacker is required to control the plaintext AND be able to intercept the encrypted message. This attack model limits the attack to mostly MITM (Man In The Middle) situations.
- Вместо просмотра размера пакетов, для нарушителя достаточно измерять время отклика, а эта процедура может быть перенесена на сторону клиента.
- Атака предполагает наблюдение за размером ответных сообщений
- Заполнитель не учитывается при формировании МАС
- During decryption of the message, the padding is checked first. If there is a valid padding, only then the MAC is checked; otherwise the server throws an error stating whether that an invalid padding or MAC error has occurred. The padding oracle attack uses CBC decryption to determine the plaintext by modifying the previous ciphertext block. An attacker can modify the encrypted message based on these error messages, and after repetitive requests can eventually get the message decrypted by the server without the encryption key В процессе расшифрования сообщения вначале проверяется заполнитель. Если всё в порядке, то проверяется МАС. В противном случае сервер сообщает об ошибке (invalid padding или MAC error). В процессе атаки (padding oracle attack) нарушитель пытается определить plaintext путём модификации отправляемых сообщений. Основываясь на получаемых сообщениях об ошибках, производится дальнейшая модификация сообщений. После серии попыток может оказаться возможным расшифрование сообщения без знания ключа
- Обратим внимание на момент до использования предыдущего блока. Ciphertext1 XOR Plaintext
- 256 попыток для 1-го байта
- 256 попыток для 1-го байта
- «downgrade dance» - это свойство ПО, а не особенность протокола.
- «downgrade dance» - это свойство ПО, а не особенность протокола.
- SSL renegotiation is helpful when the routine SSL session is already established and the client authentication has to take place. For example, say you are browsing an online shopping site which uses SSL, i.e., HTTPS. Initially, you browse through the site anonymously, add items to the cart, etc. But when you decide to purchase you will be asked to log in to the site, so now the SSL connection needs to be adjusted to allow the authentication. Whatever information is gathered prior to this authentication (e.g., items added to the cart) has to be maintained even after the authentication. So the new SSL session that has to be established uses the already existing connection. Note that renegotiation can be requested either by the client or by the server at any time. For the client to request renegotiation the client sends a “Client Hello” message in the already-established encrypted channel and the server responds with a “Server Hello” and then the negotiation follows the normal handshake process. The server can initiate the renegotiation by sending the client a “Hello Request” message. When the client receives the request, the client sends the “Client Hello” message and the handshake process takes place.
- A vulnerability was discovered in the SSL renegotiation procedure that allows an attacker to inject plaintext into the victim’s requests. For instance, it allows an attacker who can hijack an HTTPS connection to add their own requests to the conversation the client has with the web server. Note that the attacker cannot decrypt the client-server communication. Using the renegotiation attack, an attacker can inject commands into an HTTPS session, downgrade a HTTPS connection to a HTTP connection, inject custom responses, perform denial of service, etc. That explains to some extent how serious the problem is. It is easier to understand how the attack is accomplished through the following example.