company_banner

Почему после обнаружения Heartbleed мы не предлагаем пользователям Почты Mail.Ru менять пароли

    Короткий ответ на вопрос, озвученный в заголовке: потому, что этого не требуется. Heartbleed, одна из самых критичных уязвимостей в истории OpenSSL, не ударила по нашим пользователям. Чуть более подробный ответ – под катом.



    Мы, как и многие другие сервисы, используем библиотеку OpenSSL в наших проектах, однако бОльшая часть наших серверов, включая почтовые, оказались вне зоны риска. На многих наших проектах мы используем OpenSSL 1.0.0, которая оказалась неуязвима к атаке.

    Тем не менее, мы не спешили расслабляться – сначала нужно было проверить остальные проекты. На коленке был написан NSE-скрипт к Nmap, эксплуатирующий уязвимость, и уже через полчаса мы получили список машин с уязвимыми версиями OpenSSL.

    Уязвимыми для атак оказались серверы нашей баннерной системы и несколько контент-проектов. Немного паники, и к 14:00 8 апреля уязвимость была запатчена.

    Хотя на этих проектах Heartbleed не давала возможности получить доступ к личным данным, логинам или паролям пользователей, злоумышленники всё же могли получить авторизационные сессии (cookie) случайных людей, а так же потенциально скомпрометировать наши SSL-сертификаты.

    Разбираться с SSL-сертификатами мы начали немедленно. Все критичные сертификаты уже перевыпущены и будут заменены, работа по замене остальных продолжается.

    Что же касается авторизационных сессий пользователей, то и тут мы были защищены. На наших критически важных проектах работает так называемое разделение сессий. Суть его в следующем: если даже злоумышленник так или иначе завладеет авторизационной сессией пользователя, то с её помощью он не сможет получить доступ к другим проектам портала.

    Может быть, прогноз Codenomicon сбудется, и Heartbleed действительно станет для многих сервисов поводом усилить систему безопасности. Для нас вся эта история сыграла роль учебной тревоги – мы потренировались быстро реагировать на сообщение об угрозе и оперативно закрывать все лазейки. Ну и, пожалуй, говорить злоумышленникам «no pasarán!».
    Mail.Ru Group 437,22
    Строим Интернет
    Поделиться публикацией
    Комментарии 74
    • НЛО прилетело и опубликовало эту надпись здесь
      • +45
        Почта критично — на нее приходят подтверждение о смене паролей на многих сервисах. Завладеть основной почтой человека — все равно что получить доступ ко всем сервисам, привязанным к этой почте.
        • +2
          Что ещё раз напоминает про важность двухфакторной аутентификации на таких важных сервисах.

          UPD: извините, сморозил глупость — двухфакторная аутентификация не спасёт от угнанной сессии. Извините ещё раз.
          • 0
            Двухфакторная аутентификация позволит потом восстановить доступ к угнаной почте, например.
        • +2
          Не понимаю, при чем здесь РайффайзенБанк. У них сейчас SMS либо ридер, генерирующий одноразовые пароли, без которых ничего перевести невозможно. А по ссылке выше последнее сообщение от 02.12.2013.

          P.S. мне от них пока ничего связанного с внеочередной сменой пароля не приходило.
      • 0
        Интересно было бы посмотреть примерный список тех, кого удалось слить с использованием данной уязвимости. Судя по слухам — всё очень печально.
        • +1
          Мне кажется, что из известных сервисов больше всех пострадал Yahoo. Их медлительность при патчинге стали активно ретвитить, провоцируя людей заряжать скрипты на login.yahoo.com

          Про остальных — не знаю. Но даже на текущий момент, люди не особо задумываются о том что уязвимость не в HTTPS, а в OpenSSL. А значит все Jabber порты, SMTPS, SMTP/TLS и т.п. уязвимы наравне с вебом.
          • 0
            Насчёт jabber — не всегда. Если Jabber-сервер Ejabberd, то всё ок.
          • +1
            Хах! Еще даже не все российские банки залатали дыру, о чем тут дальше говорить.
          • +61
            Почему после обнаружения Heartbleed мы не предлагаем пользователям Почты Mail.Ru менять пароли


            Потому что mail.ru не страшны взломы и угоны сертификатов — они и так подписывают своими сертификатами вредоносное ПО (пруф 1, 2).
            • +1
              Насколько мне известно, это были неблагонадёжные партнёры и от них уже давно избавились.
              И я склонен верить тому, что впредь такого не повторится :)
              • +42
                Суть понятия «сертификат» как раз в том, чтобы знать, кто отвечает за подписанный бинарник, чтобы «неблагонадёжный партнёр» не мог выдать своё ПО за чужое. Подписано сертификатом Mail.ru? Отвечает Mail.ru.
                • –16
                  Сертификатиом подписывается только наш бинарник, который занимается загрузкой и установкой. Устанавливаемый бинарник нашим сертификатом не подписывался. Примерно то же самое, что Install Shield или Akamai'евский загрузчик обвинять в том, что он устанавливает вредоносное ПО.
                  • +13
                    Ну дурачка-то не включайте. Сколько раз примерно вы видели подписанный инсталлшилд, устанавливающий вредоносное ПО? Для чего в винде есть галка «всегда доверять полученному от %companyname%»?
                    • +3
                      Зачем на чужой смотреть, давайте прямо сейчас свой сделаем.

                      Идем в папку c:\program files\InstallShield Installation Information / c:\program files (x86)\InstallShield Installation Information (она скрытая)
                      Cмотрим по папочкам.
                      Ищем setup.exe с электронными подписями. У меня есть на выбор с подписями от:

                      InstallShield Software Corporation
                      Macrovision Corporation
                      Realtek Semiconductor Corp
                      CyberLink

                      Могу подарить любой.
                      Из любого из них можно сделать троянца, например подменив неподписанный _setup.dll. Проверил, целостность не проверяется.

                      P.S. Я не спорю хорошо это или плохо, более того, негативно отношусь к дистрибуции посредством партнерских программ. И еще более того, 20 лет участвую в опенсорсных проектах. Но это же технический чятег, да, я могу указать кому-то на техническую неточность?
                      • 0
                        Из любого из них можно сделать троянца, например подменив неподписанный _setup.dll. Проверил, целостность не проверяется.

                        Что вы имеете в виду под проверкой целостности? Проверку именно виндой в момент запуска установщика или проверку самим установщиком этой библиотеки?
                        • +2
                          Ни там ни там.

                          Вот PoC с тремя разными setup.exe с разными подписями:
                          cloud.mail.ru/public/8b9e46cd16ff/virus.zip
                          запускает безопасный «вирус» переименованный в data1.cab.
                          Сорсы приложены.
                          Т.е. воспроизведите действие обычного пользователя — загрузите, откройте в проводнике. Он предложит извлечь, после чего запускайте любой из сетапов.

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

                            Вам не кажется, что это сродни перекладыванию с больной головы на здоровую? Система проверяет подпись того файла, который запускается пользователем. Потому что именно это действие пользователь санкционировал лично. Все прочие исполняемые файлы, в том числе подсасываемые установщиком библиотеки, должны проверяться на целостность самим установщиком, ибо только он знает, какие библиотеки ему нужны.

                            Почему именно так? Да потому что библиотеки в проекте могут идти из разных ресурсов, и условиями лицензий на их использование может быть запрещена любая их модификация, а цифровая подпись требует модификации бинарника. Как следствие, если ОС обяжет подписанный ехе-шник использовать только подписанные dll-ки, у части разработчиков возникнут проблемы.

                            Поэтому идеологически верно контролировать целостность используемых тобой библиотек самостоятельно. По крайней мере если ты действительно хочешь обеспечить безопасность пользователю своего продукта.
                            • 0
                              Я не знаю, какое решение теоретически правильное, я показываю что тот механизм проверки целостности, который есть, сейчас на практике не работает и тривиально обходится, PoC выше.

                              То, что Вы предлагаете при текущей организации загрузки приложения в Windows не сработает. Производитель EXE файла не знает какие именно библиотеки будут подгружены итоге в адресное пространства процесса. Системные библитеки могут подгружать другие библиотеки. Для того, чтобы все это контролировать надо писать свой динамический линковщик взамен системного и перехватывать системные вызовы на загрузку библиотек. Т.е. подменять функционал системы. При этом вирмейкеру достаточно для маскировки любого одного приложения, которое так делать не будет. Вот это как раз перекладывание с больной головы на здоровую — реализовывать системный функционал в каждом исполняемом файле.
                              • 0
                                О системных библиотеках никто и не говорит. Они не идут в комплекте поставки приложения, и их целостность — уже забота той стороны, которая эти библиотеки в систему запустила.

                                А вот проверять целостность тех библиотек, которыми ты самолично комплектуешь свой продукт — подход более чем уместный. Ваш PoC выше не прокатит, если использовать именно такой подход. Как не прокатит и установка говнософта с помощью подписанного Mail.ru инсталлятора, потому как инсталлятор должен будет сам знать, какой _setup.dll с ним используется.
                                • 0
                                  Нет, это прокатит только для библиотек, которые грузятся в процессе выполнения приложения через LoadLibrary. Но не прокатит для библиотек, которые подключаются через динамическую линковку при старте приложения (а их большинство), т.к. динамическую линковку в Windows выполняет не само приложение и библиотека будет загружена раньше, и DllMain выполнен раньше, чем начнет работу код приложения и будет возможность проверить целостность библиотеки. Скорее всего, есть какой-нибудь способ проверить уже загруженную библиотеку до того, как сработает DllMain, но все равно это пляски с бубном и наколенные решения. Гораздо проще и правильней подписать свои библиотеки и на уровне системы не разрешать загрузку неподписанных.
                                  • 0
                                    О чем вы там спорите? Очевидно же, что файлы, загружаемые системным загрузчиком (динамически прилинкованные), должны проверяться им же, а файлы, загружаемые самим приложением — должны проверяться приложением.
                                    • 0
                                      Как вариант, да.
                                      А почему не очевиден вариант проверять все, что грузится через LoadLibrary?
                                      • 0
                                        Антивирусники так делают… и при этом система загибается. Слава богу, додумались «кешировать» результаты проверки — для каждой версии базы вирусов неизмененные файлы проверяются лишь один раз.

                                        Но блин, я один раз встречал приложение, которое модифицирует исполняемые файлы в процессе работы и делает это часто с последующим запуском. Это был какой-то видеоконвертер, который создавал «оптимизированный» файл обработчика чуть ли не под каждый кадр. Фух, теперь вспоминаю как страшный сон.
                                        Антивирусу это не понравилось и каждый раз надо было нажимать какие-то кнопки для продолжения.
                                        • 0
                                          Не путайте сигнатурную проверку с проверкой подписи. У них немного разная скорость работы.
                        • 0
                          Из любого из них можно сделать троянца, например подменив неподписанный _setup.dll. Проверил, целостность не проверяется.


                          В этом и проблема. Да, в данном случае Загрузчик IS не проверяет, что он устанавливает. Так же, как и загрузчик mail.ru. Возможно, это старая версия IS лохматых времен, а новые проверяют, а Realtek и прочие не озаботились апгрейдом.

                          Но есть и различие с загрузчиком mail.ru. Устанавливаемый контент находится не внутри загрузчика, а скачивается по определенному URL. У mail.ru ЕМНИП была процедура проверки загружаемого приложения (отдельный вопрос, насколько она была честной и тщательной, но была). Но результаты этой проверки не фиксировались в виде цифровой подписи самого контента. Достаточно подменить файл по этому URL и троян-даунлоадер готов.
                      • +5
                        То, что установка идет через прокси, сути не меняет. Единственная цель всей этой схемы — беспрепятственное попадание левого ПО на комп неискушенного пользователя. «Левого» в данном случае означает, что автор поделки не тратился на сертификат, его никто не проверял, что он не мошенник и не вирмейкер. То есть доверия к нему никакого. А ваша схема создает у пользователя иллюзию, что ему можно доверять. Это обман пользователя, как ни крути. Это примерно то же самое, что вывешивать сверху каждого письма зеленую плашку с текстом «Проверено антивирусом , все OK», когда на самом деле никакой проверки не производится.
                        • +1
                          Последние кавычки читать как «Проверено антивирусом AVname, все OK».
                          • –6
                            Я чуть выше написал. Если пользователь из недоверенного источника готов скачать исполняемый файл и его запустить, то помочь ему очень сложно. Если это будет не setup.exe, а zip-файл в котором будет дистрибутив чего-то с setup.exe, причем с вполне доверенной подписью — что-то изменится?
                            • 0
                              Если пользователь из недоверенного источника готов скачать исполняемый файл и его запустить, то помочь ему очень сложно.

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

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

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

                                Мне кажется, для десктопных систем надо полностью отказаться от установки приложений мимо подписанных пакетов установки и не разрешать запускать приложения или менять их среду выполнения другими способами, что-то похожее есть в мобильных системах Пока этого нет в десктопных системах, но к этому все и идет.
                                • 0
                                  Вы несете какой-то бред. Достаточно сделать установщик состоящий из одного исполняемого файла и подписать его. Этот файл должен содержать все необходимые данные для установки. Модифицировать его, сохранив при этом валидность подписи будет практически невозможно. В случае с даунлоадерами они должны скачивать только подписанные пакеты установки и проверять их подпись. Вот и все, хватит уже отмазываться. Вы просто не хотите обеспечить (да собственно я уверен, что и цель такую не ставили) защиту пользователя от «левого» софта.
                                  • 0
                                    Я полностью с Вами согласен и чуть ниже написал то же самое. Чтобы это работало на практике, в десктопной системе не должно быть способа загрузить и выполнить приложение другим способом.

                                    Но «должен» и то как сейчас на практике распространяется софт — это ведь разные вещи, да?
                                  • –1
                                    Да и ник у вас соответствующий что тут говорить.
                          • +1
                            О да. Это безусловно меняет дело. Я надеюсь, что вам по жизни будут попадяться врачи с таким же убеждением как у вас. Они будут делать вам прививки и говорить, что мы оказываем вам медицинскую услугу «инъекция» а что мы вводим — это не наша ответственность, это к производителю вакцины, мы у них не спрашивали что это, нам сказали так нужно. Ну и почаще вам продавцов недвижимости, которые отвечают только за «подписание» договора, а что вы там получите, чтоб их не волновало. Ну и в магазине вам продавцов, которые отвечают только за правильно пробитый чек, а что там в пакете они насовли — чтоб ваша ответственность была, вы же покупаете. Почаще вам людей встречать, которые четко отделяют свою зону ответственности и чтоб она не подпадала под типичные ваши ожидания. Чтоб вам нужно было каждую закорючку проверять и кропотливо искать тех, кто возьмет на себя обязательства в полном объеме и так как вы ожидаете.
                    • +12
                      Не особо информативная статья. Заголовок
                      Почему после обнаружения Heartbleed мы не предлагаем пользователям Почты Mail.Ru менять пароли
                      и ответ
                      На наших критически важных проектах работает так называемое разделение сессий.

                      Ни короткого объяснения что это такое или как оно работает. Получилось: "- Почему ..? — Потому."
                      • +4
                        В скором времени мы обязательно расскажем об этом подробнее )

                        Но если просто, то на данный момент, для каждого домена третьего уровня выставляется отдельная Secure и HTTPOnly авторизационная кука, вместо одной общей. При этом сохраняется единая авторизация, и снижаются риски эксплуатации XSS и угона сессии на каком-нибудь богом забытом проекте компании, куда ещё не дошли руки безопасников.
                        Примерно по такой-же схеме работает авторизация на Google.com
                        • +2
                          разделение же, а значит один сервис проекта — одна сессия. Получив сессию почты можешь нагадить только в почте, все остальные сервисы в рамках проекта будут обломайтунг.
                          • –3
                            Все очевидно же. Разделение сессий — это когда ни у кого не дошли руки сделать единую сессию…
                            • +2
                              А может это всё же означает персональный sid для каждого домена/проекта? И в случае смены IP (= кражи сессии) sid «перевыпускается» центральным auth-сервисом, на котором вы логинитесь? При взломе auth-сервиса это не спасает, но зато это весьма ограниченный участок, который можно за счёт этого сделать высоко надёжным. Некоторые крупные проекты примерно так и работают, судя по редиректам.
                              • 0
                                Да, вы правы, всё так и есть.
                              • 0
                                Единая сессия, всегда ведёт к большим проблемам в безопасностью, поэтому что это самый очевидный, самый лёгкий, но самый небезопасный путь. И большинство компаний начинают именно с единой сессии.

                                Как пример уязвимостей доступных к эсплуатации с единой сессией:
                                1) XSS на проекте a.domain.com, ведёт к компрометации b.domain.com. Хотя на b.domain.com — багов не было.
                                2) Кража кук в открытой сети на проекте a.domain.com(который не умеет https) ведёт к компрометации b.domain.com(который умеет и любит HTTPS). Потому что невозможно выставить Secure флаг для авторизационных cookie — a.domain.com работать перестанет.
                                и т.п.
                            • 0
                              > злоумышленники всё же могли получить авторизационные сессии (cookie) случайных людей, а так же потенциально скомпрометировать наши SSL-сертификаты.
                              Они просмотрели весь трафик через свои сервера чтобы узнать это?
                              • +4
                                Потенциально, в кусках памяти этих веб-серверов, которые можно было читать при помощи уязвимости, могли встречаться некритичные куки пользователей и приватные ключи наших сертификатов.
                                Мы решили не рисковать и отозвать их.
                              • +2
                                А вы не подумали, что при взломе сторонних сервисов где указана почта, первым делом хакеры проверяют совпадет ли пароль от сервиса с паролем от почты?
                                К примеру, из этой вчерашней тестовой выборки из 10 аккаунтов игрового сервера целых 3 аккаунта mail.ru были скомпроментированы.
                                habrahabr.ru/post/218661/#comment_7480907

                                А надо сказать, что огромная куча сторонних сайтов уязвима и сейчас.
                                Так что как минимум предупредить красным шрифтом стоит.
                                • +1
                                  Спасибо, действительно, не подумали. Сейчас займёмся )
                                  P.S. А может есть где-нибудь общая база знаний последствий атаки? Чтобы понять кто мог потенциально пострадать?
                                  • –4
                                    facepalm.jpg
                                    • +3
                                      Ну, если вы расскажете нам где пачками брать аккаунты с других сервисов, мы будем вам безмерно благодарны :) Да и не только мы.
                                    • +2
                                      Что значит «последствий»? Дело еще не закончено. Осталось прочекать все хосты в интернете — нет ли на них уязвимостей. Ну и потом мониторить, чтобы таковые не появлялись.
                                      • +1
                                        Но дампами то на паблик никто делиться не будет (
                                        Всё что найдём нашего на других сервисах или в паблике — конечно проверим.
                                      • +4
                                        Вам надо предупредить об абсолютной недопустимости использовать пароль от почты где-либо еще в связи с этой уязвимостью.
                                        Если пароли уже совпадают, то предложить срочно сменить.
                                        • +2
                                          > предупредить об абсолютной недопустимости

                                          Это не работает.
                                          1) Мозг человека физически не может генерировать криптостойкие и различные пароли. Ну пять, ну семь хороших паролей для самых нужных мне сервисов я могу держать в памяти. Для регистрации же на каком-нибудь говнофоруме используется какой-нибудь «любимый» пароль типа 111111.
                                          2) Заранее очень сложно определить — нужен ли данный сервис мне, чтобы ради регистрации придумывать стойкий пароль и как-то его сохранить у себя.
                                          3) Возрастной порог вхождения в интернет уменьшается — сперва условный «первоклассник» заводит себе почту, а потом уже начинает курить… тьфу! читать маны и узнает о необходимости иметь хорошую защиту

                                          > Если пароли уже совпадают, то предложить срочно сменить.

                                          У mail.ru нет возможности определить — совпадает ли пароль пользователя на почте с паролем на каком-либо сервисе.
                                          • 0
                                            > предупредить об абсолютной недопустимости

                                            Это не работает.
                                            1) Мозг человека физически не может генерировать криптостойкие и различные пароли. Ну пять, ну семь хороших паролей для самых нужных мне сервисов я могу держать в памяти. Для регистрации же на каком-нибудь говнофоруме используется какой-нибудь «любимый» пароль типа 111111.

                                            Противоречивая какая то информация. Если я могу запомнить два пароля, то уже могу использовать один — для почты, а другой — для всего остального. А уж тем более 5 или 7 :)

                                            Ну и очередной повод обзавестись менеджером паролей для хранения учетных данных на всяких не очень часто посещаемых сервисах.
                                            • 0
                                              Вы говорите «как должно быть», я с этим не спорю, но рассказываю «как есть на самом деле».
                                              Человек сперва заводит себе почту, потом узнает о криптостойкости и много-много времени спустя приходит к использованию менеджеров паролей. Во всех книжках, во всех местах на всех сайтах написано, что не надо использовать один и тот же пароль на разных ресурсах. От того, что мы с вами повторим это еще раз для посетителей хабра — ничего не изменится. Здешняя аудитория об этом и так знает (надеюсь)

                                              Если mail.ru произведет рассылку по пользователям и/или повесит алерт о желательности смены пароля (придется вешать всем) — по большому счету тоже мало что изменится. Бегущий генерал вызывает в военное время панику, а в мирное время — смех. Еще раз повторю — я не считаю, что это делать не надо. Я говорю, что это не спасет.
                                              • 0
                                                Я бы не говорил, что это «не работает», я бы сказал, что у этого способа «низкая эффективность». Можно сколько угодно напоминать пользователям о том, что нужно иметь разные пароли для разных сервисов, но пока пользователь сам до этого не дозреет — эти напоминания ни к чему не приведут. Но на тех, кто «дозрел», напоминание все же может повлиять.

                                                По большому счету — ничего не изменится, но если считать конкретных людей, которых эта рассылка может подтолкнуть к действиям — то, вполне возможно, польза будет. Не «спасение», ни в коем разе. В этом случае вполне подходит фраза о том, что «спасение утопающего — дело рук самого утопающего».
                                          • +5
                                            Вы правы, это плохо, т.к. на многих сервисах е-мейл является логином, если пароль там совпадает с паролем от почтового ящика — это катастрофа. Мы стараемся об этом предупреждать пользователя при любой удобной возможности, я говорю это в каждом комментарии в СМИ по поводу безопасности. К сожалению, заставить людей довольно сложно.
                                            • +1
                                              Если вы имеете ввиду разные ресурсы mail.ru, то у нас централизованная система аутентификации, почти для всех ресурсов mail.ru пользователь авторизуется в одном месте и нет необходимости хранить и защищать много паролей в разных местах. Что во многом спасло нас от этой атаки.

                                              А вто то, что пользователь использует один и тот же пароль в разных сервисах — это действительно проблема, о ней мы стараемся говорить при каждом удобном случае. Вот здесь, например: http://habrahabr.ru/company/mailru/blog/169801/ достаточно подробно объясняется почему не надо так делать.
                                              • 0
                                                могу добавить что из примерно 10 проверенных с сайта который для меня важен — в одном случае логин и пароль пользователя с mail.ru подошел к почте… дальше… было решено не смотреть. так что проблема вполне себе реальная.
                                            • –17
                                              Добавьте, пожалуйста, кармы до 5, не могу опубликовать статью о вредоносном скрипте в Google Analytics (Да простит меня НЛО)
                                              • –7
                                                Ok, можете минусовать мне карму. Вот сам топик: storage.sashok724.net/temporary/habratopic.html
                                                Если кто хочет — выложите. Правда, интересно, у одного ли меня такая проблема.
                                                • 0
                                                  Google Analytics здесь не причём.
                                                  • 0
                                                    Ваш топик интересен. Но расследование не доведено до конца. Похоже на зловредный прозрачный прокси. Проверьте, не взломан ли роутер.
                                                  • +1
                                                    Такие просьбы пишут только друзьям в личку, и то НЛО за такое может забанить даже «топовых» пользоватей и за благие намерения.
                                                    • –3
                                                      Я уже понял… Но друзей на Хабре у меня пока что нет.
                                                    • –3
                                                      Всем еще раз спасибо, в отрицательной карме доступен Recovery Mode ;)
                                                    • –1
                                                      Disclaimer: Мнение автора комментария может не совпадать с мнением его работодателя.
                                                      Вы уж простите, не удержался.

                                                      Твой позорный недуг в подвиг определим. © ДМБ

                                                      • +2
                                                        Привет Эльдар :) Вас там бьют в Яндексе за несогласие с мнением партии?
                                                        В чём же наш позорный недуг?
                                                        • –1
                                                          мне нечего о нем рассказать т.к. я к нему не имею никакого отношения.
                                                          • 0
                                                            Скорее это моя личная профессиональная деформация:

                                                            www.ssllabs.com/ssltest/analyze.html?d=e.mail.ru

                                                            странно видеть, как люди пиарятся на отключении TLS в 2014 году ;)
                                                            Peace.
                                                            • +1
                                                              У нас не возникало нужды переходить на TLS 1.2, можешь считать что стабильность — это наше всё.
                                                              В ближайшее время, безусловно, проапгрейдимся, если новых багов не найдут)
                                                        • 0
                                                          Теперь этот баг будет поводом для ПР? 8)
                                                          • –5
                                                            >Хотя на этих проектах Heartbleed не давала возможности получить доступ к личным данным, логинам или паролям пользователей

                                                            Это вы так думаете что не давала. А кто знает что там на самом деле. Сертификаты то вы перевыпустили! Короче mail.ru в своем стиле-как всегда «заботится» о пользователях.

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

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