Добро пожаловать в мир послесердце кровью обливается. Мы исправили наши серверы и заменяем наши SSL-сертификаты. Но то, что наши серверы исправлены, не означает, что остальная часть интернета исправлена. У нас есть сотрудники, и они используют интернет для обмена секретами, такими как номера кредитных карт и учетные данные для входа. Они обращаются к нам за советом.
Мы можем посоветовать нашим клиентам использоватьтестовая страница Heartbleedчтобы увидеть, есть ли уязвимость на сайте, на который они хотят зайти. Если сайт возвращает положительный результат, то не обменивайтесь с ним секретами. Но если сайт делаетнетЕсли результат теста Heartnet положительный, то ситуация может быть любой из следующих:
- Сайт никогда не имел уязвимости (хорошо)
- На сайте была уязвимость, и она была устранена, но он по-прежнему использует, возможно, скомпрометированный сертификат SSL (плохо)
- На сайте была уязвимость, и он ее устранил, а также повторно сгенерировал SSL-сертификат, но без повторной генерации ключей (плохо)
- На сайте была уязвимость, ее устранили, перегенерировали ключи и заменили SSL-сертификат. (хорошо)
Есть ли возможность предоставить нашим сотрудникам возможность сообщить им об этом до того, как они введут номер своей кредитной карты в форму?хорошийсценарии изплохойодни?
Как мы можем проинструктировать наших сотрудников, чтобы свести к минимуму их воздействие на серверы, скомпрометированные Heartbleed?
решение1
По сути, нет единого способа отличить хорошие сценарии от плохих, поскольку у ваших пользователей нет полной картины используемых ими систем.
Масштаб ущерба, нанесенного ошибкой, до сих пор в значительной степени неизвестен, большая часть ущерба потенциально была нанесена в прошлом и будет продолжать влиять на интернет в течение длительного времени. Мы просто не знаем, какие секреты были украдены, когда и кем.
Например: OpenSSL-сердце Google истекает кровью уже около года. Неизвестные злоумышленники собирают данные с серверов и ищут интересные секреты — опять же, у нас нет возможности узнать, сделали они это или нет — пока не найдут учетную запись, принадлежащую кому-то с авторизованным доступом к другой системе, скажем, Twitter.com или AnyBank.co.uk или dev.redhat.com. Имея доступ к таким учетным записям, они потенциально могут продолжать копать, получать доступ к другим системам, наносить другой ущерб (видимый или нет), еще больше скомпрометировать другие учетные записи — и никто не заподозрит источник взлома. На этом этапе вы уже далеко от истекающих кровью серверов OpenSSL, и это одно из самых неприятных последствий Heartbleed. К этому добавляется риск компрометации закрытых ключей серверов.
Доверие требует много времени для создания и может быть быстро потеряно. Я не говорю, что у нас не было проблем с доверием в Интернете раньше, но Heartbleed определенно не помог. Устранение ущерба займет много времени, и понимание этого является частью понимания того, как вы можете защитить себя и своих сотрудников/клиентов/начальников и т. д. - и как вы не можете. Есть некоторые вещи, которые вы можете контролировать, чтобы ограничить свою подверженность уязвимости, и есть вещи, которые вы не можете контролировать - но они все равно повлияют на вас. Например, вы не можете контролировать, как все остальные решат отреагировать на эту уязвимость - АНБ, как сообщается, обнаружило ошибку, но промолчало. Это было довольно плохо для всех нас, но у нас не было способа защитить себя от нее.
Как пользователь Интернета вы можете и должны:
- Пониматьнасколько плохоошибка - это
- НЕ отвечайте/не переходите по ссылкам в электронных письмах, предлагающих вам сбросить пароль - вместо этого зайдите на веб-сайт компании/организации напрямую и активно сбрасывайте свой пароль. В такие моменты мошенники любят заниматься фишингом
- Проверьте свой Android-телефон на наличие Heartbleed. Естьприложениеот Lookout Mobile Security, который проверяет вашу версию OpenSSL.
Проверьте посещаемые вами веб-сайты на наличие Heartbleed (неполный контрольный список):
Использует ли сервер OpenSSL?
- Нет: Вы не затронуты напрямую (этой ошибкой). Продолжайте пользоваться сайтом, но измените свой пароль на случай, если другой сервер, прямо или косвенно затронутый ошибкой, имел доступ к вашему паролю. Это предполагает, конечно, что все такие серверы в этой сети были исправлены, выпущены новые сертификаты... и т. д.
- Да: Перейти к пункту 2.
На сервере установлена версия OpenSSL без Heartbleed? Убедитесь, что ваш check-for-heartbleed-tool действительно проверяет уязвимость, а не заголовок HTTP или какой-либо другой «индикатор».
- Нет: Не отправляйте никаких секретов на сайт, но, если возможно, отправьте сообщение вебмастеру.
- Да: Перейти к пункту 3.
Была ли в какой-либо предыдущей версии OpenSSL поддержка Heartbleed?
- Нет: Некоторые администраторы не обновились до последней версии OpenSSL, потому что она не была достаточно долго протестирована в полевых условиях. Их серверы никогда не были уязвимы для этой ошибки, но по причинам, представленным выше, вам все равно может быть лучше сменить пароль.
- Да: Сервер был уязвим, и вполне возможно, что любые данные в памяти были скомпрометированы в период между обновлением до уязвимой версии и моментом раскрытия информации (до двух или даже трех лет).
Здесь мы возвращаемся к доверию: Когда вы теряете чье-то доверие, это плохо. Особенно, если этот кто-то ваш пользователь/клиент/босс. Чтобы вернуть его доверие, вам придется начать строить заново и открыться для диалога.
Вот что может опубликовать веб-администратор, чтобы начать работу:
- Предыдущие версии OpenSSL (уязвимые/неуязвимые)
- Текущая версия и когда она была обновлена
А если предыдущая версия OpenSSL была уязвима:
- Когда был сгенерирован текущий SSL-сертификат
- Подробное описание того, как был отозван старый сертификат
- Гарантия того, что для нового сертификата был использован новый секрет
- Предложения для пользователей на основе вышеизложенной информации
Если вы пользователь, вы имеете полное право запрашивать такую информацию, и вы должны это делать ради всех пользователей сервиса. Это повысит видимость для сообщества безопасности и облегчит пользователям минимизацию их подверженности скомпрометированным серверам.