Создатели вредоносного ПО научились обходить улучшенное шифрование паролей в Chrome 80



    Алгоритм AES-256 для шифрования файлов cookie и паролей в браузере Google Chrome 80 не стал серьёзным препятствием для разработчиков вредоносного ПО. Как сообщает портал BleepingComputer, разработчики инфостилеров, или ПО, которое извлекает данные из браузеров, выпустили обновления с поддержкой нового Chrome.

    Версия Google Chrome 80 вышла в начале февраля. Как сообщали в Google, в браузер было добавлено более надёжное шифрование с использованием алгоритма AES-256. До Chrome 80 файлы cookie и пароли шифровались с помощью DPAPI. Этот инструмент по-прежнему действует, AES-256 был добавлен как еще один уровень защиты для дополнительной безопасности.

    Как отмечает BleepingComputer, добавление AES-256 помешало работе известного ПО для извлечения данных AZORult. Торговая площадка Genesis, специализирующаяся на продаже вредоносного ПО, распространяла первоначальную версию AZORult и, по информации BleepingComputer, понесла большие потери, когда вышла версия Google Chrome 80. Если в 2019 году на площадку ежедневно добавлялось около 18 тыс. новых украденных цифровых отпечатков, то в феврале 2020 их число сократилось в 30 раз — до около 600 новых записей в день. Однако авторы одной из новых сборок AZORult заявили о поддержке новой версии Chrome.

    Кроме того, вскоре после выпуска Chrome 80 вышли обновления для ещё нескольких инфостилеров, которые адаптировались к новому механизму. Как пишет BleepingComputer, авторы ПО KPot через четыре дня после выхода Chrome 80 сообщили о том, что инфостилер способен обойти новый алгоритм Chrome.



    Авторы Raccoon, ПО, которое может извлекать данные из многих приложений, включая все популярные веб-браузеры, объявили, что им также удалось обойти новый уровень безопасности в Chrome 80.



    «Несмотря на то, что добавление шифрования AES-256 в Chrome вызвало колебания в мире вредоносных программ, нарушение их работы было недолгим для большинства вредоносных инструментов. Активность вредоносных программ этого типа вряд ли скоро снизится», — отмечает BleepingComputer.

    Кроме того, портал сообщает о появлении нового ПО, авторы которого отдельно подчёркивают поддержку Chrome 80. Среди них BleepingComputer отмечает Redline, ПО, анонсированное на одном из российских форумов.



    «Важно отметить, что Redline очень нова. Вполне вероятно, что авторы использовали обновление Chrome в качестве точки старта продаж», — указывают в BleepingComputer.

    Ранее компания Google выпустила обновление для Google Chrome 80, которое исправляет три критические уязвимости, получившие оценку в 8.8 по шкале CVSS 3.0. Также в феврале разработчики Google сообщили о сокращении вдвое временного разрыва между выходом патчей и их реализацией в программном обеспечении. Если раньше между исправлением ошибок в библиотеке с открытым исходным кодом и доставкой исправленной библиотеки в Google Chrome проходило больше месяца, то с февраля этот промежуток сократился до 15 дней.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 22

      +1
      Не прошло и 80-ти версий, как Гугл внедрил новое шифрование))
        +11

        Но ведь любое такое шифрование без мастер-пароля (ихи хотя бы выдачи паролей из хранилища после подтверждения через UAC/sudo) — это заведомая профанация. Некоторые свободные проекты даже намеренно хранили пароли открытым текстом, чтобы не создавать у пользователя ложное ощущение защищённости!
        Стыдно, гугл! Фу таким быть.

          0
          Ну открытым текстом совсем плохо, шифровать стоит. Как минимум под windows раньше использовали CryptUnprotectData, а он привязан к пользователю и завязан на авторизацию
            +1

            Да, открытый текст уязвим к уж совсем простым нетаргерированным атакам уровня grep -R password /, поэтому такая практика сошла на нет.

          0

          Забавно что первых два комментария противоречат друг другу.

            +3
            По-моему, криптостойкость всех алгоритмов примерно одинакова (на уровне плинтуса), если ключ для дешифровки зашит в само приложение.
              +1
              Вот лишь бы написать… При чем тут AES-256? Ему что, ключ не нужен?
                +1
                Меня печалит, что для просмотра пароля в хроме я должен вводить пароль пользователя, а программа, запущенная с правами этого пользователя — получает всё легко и просто.
                Сторонние менеджеры паролей хотя бы делают усложнение в процессе получения паролей.
                  +15

                  Раньше на Хабре бывали технические детали...

                    +1
                    Так ведь были люди, которые их читали…
                      +1
                      пара тех. деталей:

                      в chrome мастер-паролем является пароль учетки пользователя в ОС. добавлять настоящий мастер-пароль вроде не планируют.

                      в firefox мастер-пароль есть, алгоритм шифрования aes. 10 лет лиса использовала уязвимый (в теории) способ генерации хеша мастер-пароля. проблему исправили лишь пару месяцев назад вместе с переходом на новое хранилище ключей (key4.db).
                        0
                        Каким образом хром знает мой пароль?
                          0
                          пароль используется косвенно. вы заходите в свой профиль, используя пароль. в этом профиле chrome (или винда в случае dpapi) хранит «нечто», что служит ключом для шифрования данных браузера.

                          я не специалист в области криптографии, так что в деталях могу ошибаться.
                            –1
                            CryptUnprotectData
                            Usually, the only user who can decrypt the data is a user with the same logon credentials as the user who encrypted the data. In addition, the encryption and decryption must be done on the same computer.
                        0
                        Хм. Я, наверное, слегка туповат, но считал что мои пароли (в фаирфоксе в данном случае) лежат зашифрованные мастер-паролем без которого их не расшифровать (ну либо под системными правами прочитать прямо из памяти). Я заблуждался?
                          0

                          А вы этот пароль вводите? Если нет, то нет никакого мастер-пароля.

                            0
                            Конечно ввожу, иначе о чем речь.
                            0

                            В теории — всё верно, браузер с заданным и достаточно сложным мастер-паролем способен хранить пароли достаточно безопасным образом. Но на практике лучше в браузере пароли не сохранять в принципе, а использовать для хранения паролей отдельное приложение вроде KeePass. Причин для этого несколько: пароли бывают не только для сайтов, браузер бывает не только один, специализированное приложение обычно лучше выполняет свою работу, у браузеров не лучшая репутация в плане хранения паролей из-за упомянутых в статье инструментов кражи этих паролей из браузеров, есть вероятность что вредоносный плагин к браузеру или вредоносный JS загрузивший в фреймах формы логина со сторонних сайтов с автозаполнением форм смогут украсть пароли либо через штатные фичи браузера либо через уязвимости браузера. В целом браузер — гигантское сложнейшее приложение выполняющее код присылаемый сторонними сайтами и имеющее бесконечную историю уязвимостей — не лучшее место, где стоит хранить свои пароли.

                              0
                              Почему вы решили что вредоносное ПО так же не ворует пароли условного KeePass?
                              Почему вредоносный JS из фрейма не сможет украсть вставленный, условным KeePass, пароль в форму?
                                0

                                Пароли из KeePass украсть несколько сложнее, мне лично неизвестно о существовании утилит для кражи паролей из KeePass, а Вам? Что до JS и фреймов, то у KeePass нет такого автозаполнения, нужно нажать ручками, плюс ещё при первом обращении разрешить доступ конкретному сайту к конкретному паролю(ям).

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

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


                                    В целом, я не утверждаю, что при использовании KeePass пароль невозможно перехватить. Я говорю, что украсть все пароли пользователя (как делают утилиты упомянутые в статье) через браузер практически нереально (по сути для этого нужен либо кейлоггер для перехвата мастер-пароля либо возможность читать память самого KeePass — т.е. по сути полный контроль над компом юзера), и что намного сложнее украсть даже один пароль незаметно для пользователя.


                                    Самый реальный вариант для кражи паролей при использовании KeePass — если у пользователя установлено вредоносное расширение для браузера, пользователь выдал ему достаточно прав (а браузер сейчас политику в отношении прав расширений ужесточают) и оно перехватывает все отправляемые формы. Но такой способ будет работать с любыми подходами, хоть KeePass, хоть пароли запомненные браузером, хоть пароль который всегда вводится вручную, так что обсуждать его в контексте статьи бессмысленно. И украдено будет не так много паролей — на каком проценте сайтов, где Вы зарегистрированы, Вы логинитесь хотя бы раз в неделю?

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое