HEIST позволяет получить зашифрованную информацию в HTTPS канале в виде открытого текста



    Расширение протокола HTTPS, которое защищает миллионы сайтов и сотни миллионов пользователей, уязвимо к новому типу атаки. Эксплоит позволяет получить зашифрованные адреса электронной почты, номера страхования и другие личные данные пользователей. Причем злоумышленнику нет необходимости вести наблюдение или контролировать интернет-соединение жертвы.

    Другими словами, эксплоит не требует использования MITM (man-in-the-middle) схемы. Вместо этого жертву атакуют при помощи невинного JavaScript файла, скрытого в рекламе или «вшитого» прямо в страницу вредоносного сайта. Вредоносный код после успешного выполнения может запрашивать ряд типов страниц, защищенных SSL или TSL протоколом и получать точный размер файлов с зашифрованными данными, которые передаются в защищенном режиме. Новый тип атаки получил название HEIST (HTTP Encrypted Information can be Stolen Through TCP-Windows).

    Работает эта атака благодаря тому, что скрипт изучает тип ответа фреймворка, который отдается клиенту (обычно это браузер), от которого пришел HTTP-запрос. Как только злоумышленник получает информацию о точном размере зашифрованных данных, он может использовать несколько ранее известных эксплоитов для получения тестовой информации, скрытой внутри зашифрованного файла.

    Если точнее, то здесь используются эксплоиты BREACH (Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext) и CRIME. BREACH позволяет получить тестовую информацию из защищенного файла всего за 30 секунд. CRIME не отстает от своего собрата. CRIME позволяет с помощью нескольких запросов побайтово подбирать содержимое cookies, наблюдая за значениями, которые выдаёт zlib. Эксплоит расшифровывает значение cookies по 4-6 запросов на каждый байт base64.

    Технология HEIST была показана и объяснена на конференции Black Hat. По словам специалистов по информационной безопасности, HEIST позволяет проводить атаки быстрее и эффективнее, чем раньше. Тем более, что теперь не нужна схема MITM. Злоумышленники получают нужную информацию практически сразу после того, как жертва посещает зараженный сайт или сайт с зараженной рекламой.

    До настоящего момента злоумышленнику необходимо было активно управлять трафиком, идущего от сервера к пользователю. HEIST позволяет убрать это ограничение. Эксплоит использует TCP характеристики как квази-криптографический вторичный канал для оценки размера HTTPS ответа. TCP разделяет большие передачи на меньшие фрагменты определенного размера, называемые фреймами. В дальнейшем фреймы группируются внутри «TCP-окон», отправляемых по одному за единицу времени. TCP отправляет новое окно только после получения подтверждения получения предыдущей группы фреймов.

    HEIST может просчитывать количество фреймов и окон, путем взаимодействия с набором недавно одобренных API. Это Resource Timing и Fetch. В результате получается определить точный размер HTTPS ответа. А дальше, как уже говорилось выше, в дело вступают BREACH и CRIME. На выходе злоумышленник получает закрытую ранее информацию. Специалисты уже представили результаты своей работы Google и Microsoft. Так что представленный на Black Hat метод не стал сюрпризом для этих компаний. Злоумышленнику достаточно узнать CSRF токен жертвы, после чего аккаунт пользователя на определенном сайте можно скомпрометировать.

    По словам авторов работы, представленной на Black Hat, пользователь может снизить вероятность успешного осуществления HEIST атаки, запретив в настройках браузера сторонние куки. С другой стороны, ряд сервисов просто не будет работать без сторонних куки.



    При демонстрации атаки удалось измерить размер зашифрованных ответов для New York Times, используя сайт targetwebsite.com.

    HEIST также эффективен против HTTP/2, обновленного стандарта HTTP. В некоторых ситуациях особенности HTTP/2 даже увеличивают эффективность работы HEIST. В частности, если используется HTTP/2, эксплоит может одновременно опрашивать несколько источников.

    Сейчас, по мнению авторов работы, комбинированная атака с использованием BREACH и HEIST является одним из наиболее простых методов компрометации пользовательских аккаунтов самых разных ресурсов.

    Другие наши публикации:
    King Servers
    77.20
    Хостинг-провайдер «King Servers»
    Share post

    Comments 42

      +3
      «Расширение протокола HTTPS, которое защищает миллионы сайтов и сотни миллионов пользователей, уязвимо к новому типу атаки.» — мне так нравится это предложение…
        +17
        Столько блаблабла, а в чём атака так и не понятно. Если вредный js подсадили, что мешает поменять что угодно?
          0
          Многие используют CDN на своих сайтах, получается владельцы CDN могут использовать эту атаку.
            +1
            Ну, не знаю. Так можно дойти и до того, что владельцы %package-manager%-registry могут атаковать проекты использующие в сборке хостящиеся либы…
            Страшно жить на белом свете становится.
              +1
              Ну исходники пакетов хоть посмотреть можно, а CDN может точечно подсовывать код конкретным клиентам и никто не узнает.
              Не даром развелось много бесплатных CDN.
                +1
                > много бесплатных CDN

                Простите, а кто кроме CloudFlare еще?
                  +1

                  googleapis, например, хостит некоторое количество библиотек.

                    0
                    Разницу между CDN и хостингом библиотек совсем не видите?
                      +1

                      Если в контексте вектора атаки "cf или google подсовывает вредоносную библиотеку вместо jquery.min.js", то не вижу.

                        0
                        Я задавал вопрос в контексте «много бесплатных CDN». Мне стало интересно вдруг я что-то пропустил. Оказывается, что бесплатных CDN, кроме CF, нет.
                          0

                          Вроде ещё incapsula предлагает free, но без tls'а.

                    +1
                    cdnjs, jsdelivr, тут есть список бесплатных и платных (они тоже к теме относятся), в прошлые года несколько рекламировались на хабре.
                      0

                      CloudFlare уже сам по себе стал очень весомой проблемой безопасности.
                      Стоит сворачивать эту лавочку по впихиванию его везде и всюду.

                        +2
                        И в чем же он «проблема безопасности»?
                        Не можете поведать? Можно отдельной статьей, думаю многим будет интересно.
                        Пока известна ровно одна проблема с CF, они плевали на незаконные даже в РФ приказы Росцензуры, ну так это кому проблема, а кому только плюс.
                          0
                          И в чем же он «проблема безопасности»?
                          В чем может быть проблема если Сбербанк в личный кабинет подключит js файл с сайта «Васи Пупкина»?
                            0

                            И это тоже. См. ниже про Video.js и внезапную гугланалитику (которая сейчас задокументирована, впрочем, после воплей в тикетах) — у них версия на CDN отличается от оригинальной ровно на гугланалитику.


                            И это далеко не самое плохое, что может внезапно прилететь от CDNа со скриптами.

                              +1
                              Если..?
                                0

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

                                  0
                                  Почему же, там и на вкладке Network в Dev tools все прекрасно видно по доменам, включая и то, что Ghostery не ловит. А резать основную массу можно и по hosts, проверяемому вручную — достаточно просто проверить, что он не подставляет никакие IP, кроме 0.0.0.0 — можно даже с автообновлением, грепая по "^0.0.0.0\ " — максимум что будет, это заблокирует лишнее
                              0

                              Тем, что он является глобальным MitM, который работает в обход шифрования и контролирует около 10% крупных сайтов и около 5% всех сайтов вообще. Вас всё ещё ничего не настораживает?


                              Статья вот: http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-have-a-problem/ — это сводка. Ссылки дальше в ней же.

                                +1
                                Ну за всё надо платить. А какой самый ценный ресурс? Правильно — информация.
                                Вы же думали что «бесплатные» сервисы существуют от переизбытка филантропии у компаний?
                                  0

                                  С чего вы решили, что я так думаю? =)
                                  Я, вроде бы, не давал повода.


                                  С youtube, например, тоже некоторые далеко не сразу замечают, что всё не так, как можно было бы подумать:


                                  Problem is, people see YouTube as video hosting service when it actually is a service that gets their video and try to make money out of it.

                                  (источник)

                        0

                        Ха. Например, если вы тянете VideoJS с их CDN — он вам подсовывает свою гугл аналитику.

                          0

                          https://www.w3.org/TR/SRI/ — если с умом подходить, то не могут. Сие уже поддерживает Chrome и Firefox, то бишь можно указать хеш файла, который ожидается, если придет что-то иное, то среагировать на сие событие.


                          Пардон, не увидел ссылку akaluth выше.

                            0

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

                            0
                            Мне тоже непонятно, зачем использовать Resource Timing и Fetch API, если вредный код уже встроен в страницу, он ведь и так может спокойно отправлять запросы с куками жертвы и CSRF токенами.
                            Вместо этого жертву атакуют при помощи невинного JavaScript файла, скрытого в рекламе или «вшитого» прямо в страницу вредоносного сайта.

                            Если речь идет о рекламе в iframe и коде, который выполняется в iframe, тогда это интереснее, но детали не описаны.
                            +2
                            То есть, я могу у себя на сайте вытаскивать куки фейсбука и смотреть, что за юзер ко мне пришел?
                            А где можно готовый эксплойт посмотреть?
                              0

                              Куки нельзя, только данные в теле ответа.

                                0
                                CRIME позволяет с помощью нескольких запросов побайтово подбирать содержимое cookies, наблюдая за значениями, которые выдаёт zlib. Эксплоит расшифровывает значение cookies по 4-6 запросов на каждый байт base64

                                До настоящего момента злоумышленнику необходимо было активно управлять трафиком, идущего от сервера к пользователю. HEIST позволяет убрать это ограничение.

                                Мне показалось, что речь идет о чтении отправляемых cookies. Мало какой сервер будет отправлять один и тот в ответ set-cookies раз за разом. О чем тогда идет речь?
                                +1
                                Я не буду использовать этот эксплойт в корыстных целях, подскажите где найти.
                                +5

                                Текст как будто перевели с помощью PROMT 97. Не сказано про главную особенность — необходимо, чтобы один из параметров запроса выводился в ответе, т.е. атакующий должен иметь возможность вставить свой текст в ответ.


                                HEIST также эффективен против HTTP/2

                                Не просто эффективен, HTTP/2 снимает ограничение выше, для эксплуатации атакующему не требуется вывод параметра в ответе.


                                В статье ничего не сказано про защиту. Проблема в том, что Fetch API позволяет отправлять запросы на сторонние сайты с авторизационными куками (режим no-cors). Сейчас прорабатывается стандарт для атрибута кук SameSite. Он позволяет задать политику использования кук только в пределах сайта, что тем самым ограничивает отправку кук со сторонних сайтов и нейтрализует данную атаку. Хром >51 уже поддерживает SameSite-куки.

                                  0
                                  Подскажите, кто знает, а как, собственно, BREACH и CRIME работают? Они запрашивают страницу много раз, и с запросом отправляют разные кусочки текста, которые сервер должен выдать обратно. А далее уже по размеру ответа после deflate-компрессии можно увидеть — есть ли уже такой кусочек текста внутри страницы (размер ответа не поменялся), или нет такого кусочка (размер ответа не поменялся).

                                  Так вот вопрос в том — есть универсальная техника, которая позволяет заставить сервер делать reflect-данных в запросе? Или же все зависит от конкретного сервера и конкретной страницы?
                                    0

                                    Такой универсальной техники нет, все зависит от приложения.

                                    +4

                                    Вот ходи теперь в интернет без блокировщиков рекламы.

                                      0
                                      Вот Доклад, если кому-то нужны технические детали.
                                        +2

                                        Если кому интересно как работает атака, но читать оригинальные 26 страниц — TL;DR — есть неплохая статья на arstechnica.com
                                        Там же есть и ссылки на описания Breach и Crime в стиле научпоп — не глубоко но подробнее чем — "Эээ, у нас проблема, назвали heist, интернет сломан, мы все умрем."

                                          0
                                          Для борьбы с утечкой информации через CDN у firefox существует расширение decentraleyes, оно блокирует все популярные CDN заменяя их локальными копиями, что также ускоряет загрузку страниц, предотвращая лишние сетевые запросы.
                                            0
                                            Благодарю за информацию об этом дополнении!
                                            0
                                            Не понятно почему social security number переводят как «номера страхования». Правильнее было бы сказать номер социальной защиты. Social Security, это не страхование а скорее государственный пенсионный и социальный фонд, а SSN это налоговый идентификатор индивидуума- играющий ту же роль что ИНН. Опасность попадания этого кода в руки злоумышленника заключается в том что этот код является одним из основных способов автризации в онлайновых государственных и финансовых сервисах. Зная ССН, полное имя и дату рождения + кое-что ещё можно получить кредит, подписывать налоговые документы и т.д.
                                              0
                                              Потому что это официальный перевод.
                                                0
                                                Спасибо!
                                                Отличный документ на эту тему.
                                                https://www.ssa.gov/pubs/RU-05-10064.pdf

                                                Служба социального обеспечения надежно охраняет ваш номер социального обеспечения.

                                            Only users with full accounts can post comments. Log in, please.