Компания
263,23
рейтинг
17 апреля 2014 в 21:12

Разработка → OpenVPN успешно скомпрометирован через Heartbleed

Страсти по недавно обнаруженной Heatbleed уязвимости в OpenSSL не утихают. Вчера на портале news.ycombinator.com появилось сообщение о том, что исследователям удалось совершить несколько успешных атак на сервер OpenVPN и скомпрометировать приватный ключ, который используется сервером для расшифровки отправленного клиентом трафика.

We have successfully extracted private key material multiple times from an OpenVPN server by exploiting the Heartbleed Bug. The material we found was sufficient for us to recreate the private key and impersonate the server.

As you may know, OpenVPN has an SSL/TLS mode where certificates are used for authentication. OpenVPN multiplexes the SSL/TLS session used for authentication and key exchange with the actual encrypted tunnel data stream. The default TLS library for OpenVPN is OpenSSL.




Ранее разработчики OpenVPN уже предупреждали пользователей, что продукт использует библиотеку OpenSSL и является уязвимым для этой атаки. Но до вчерашнего дня не было никакой публичной информации о том, что атака действительно может быть успешно реализована. Исследователи продемонстрировали возможность подделать удаленный сервер через полученный приватный ключ, а также расшифровать с помощью него данные, проходящие между настоящим сервером VPN и самим пользователем.

Для проведения атаки использовалась следующая тестовая конфигурация сервера: ОС Ubuntu 12.04 (виртуализация через KVM) OpenVPN 2.2.1 и OpenSSL 1.0.1-4ubuntu5.11.

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

The attack vector that is present on the Access Server with the vulnerable OpenSSL libraries is not present on the Connect Clients, so the risk is minimal. Only the server that your client connects to could possibly exploit this vulnerability, and even then it is unlikely because we use Perfect Forward Security and TLS-auth on top of the SSL connection. The security of the data channel itself is not particularly at risk, only the web services on the server themselves are. And even then, since we use a privilege separation model, the web services run in a completely different process than the OpenVPN daemons handling the data connections, and therefore the private keys for your OpenVPN connections are not likely to be at any risk. Even so, we don't want to take chances and are going to release 2.0.7 soon, which will incorporate updated clients as well.
Автор: @esetnod32
ESET NOD32
рейтинг 263,23

Комментарии (39)

  • +2
    Да уж. Эта бага еще не раз аукнется…
  • +25
    Таким образом, в моём рассказе про пересылку зашифрованных gpg'ой файлов через scp внутри openvpn туннеля осталось ещё два уровня защиты. И минус 33% паранойи.
    • 0
      а должно было стать +200%
      • 0
        Я называю «паранойей» ту часть технологий, которую считаю избыточной. То есть -33% означает, что та же самая комбинация технологий кажется на треть менее неоправданно усложнённой.
  • +4
    Интересно, а роутеры с поддержкой OpenVPN тоже уязвимы? Например, тот же DD-WRT.
    • +2
      OpenWRT точно уязвим. Советуют взять OpenSSL из транка.
    • +1
      Shibby Tomato уже выпустил обновление. Правда только через неделю после обнаружения уязвимости, но всяко лучше чем многие вендоры.
      • 0
        Да, 117 версия. Оригинальный Томато собран на 0.9.х версии и по идее можно оставить как есть. Многие первые Линксисы на нем живут сейчас.
  • +1
    Или я чего-то не так понял, или сам ovpn не подвержен?

    The security of the data channel itself is not particularly at risk, only the web services on the server themselves are.… the private keys for your OpenVPN connections are not likely to be at any risk
    • +1
      Этот абзац справедлив только при использовании аутентификации по средствам TLS (опция --tls-auth).
      • 0
        Напомню, что эта опция является рекомендуемой и openVPN ругается, если TLS-auth не активна.
        • 0
          Рекомендуемая — да, ругается — даже warning'ов не видел…
          • 0
            Упс, прошу прощения, перепутал с openvpn.net/howto.html#mitm, конкретно строка к логах:

            Thu Apr 17 23:31:36 2014 us=718071 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
  • 0
    Объясните пожалуйста, если у меня есть openvpn сервер что нужно сделать чтобы избежать проблем? пересобрать бинарник openvpn? или перегенировать ключи?
    • +1
      Обновить библиотеку OpenSSL, начать использовать tls-auth.
      • 0
        Если нет возможности моментально начать использовать tls-auth. Как минимизировать риски?
        • +1
          Это всё тот же баг, что обсуждается уже не первый день — обновите Вы уже наконец на всех серверных и клиентских машинах библиотеку OpenSSL, до последней версии (в старых кстати бага тоже не проявляется).
          • 0
            Так я просто не могу понять как обновление библиотеки OpenSSL мне поможет, если OpenVPN собран все равно со старой. Нужно обновить OpenSSL и пересобрать OpenVPN?
            • +7
              Ох тыж… А про динамические библиотеки Вы видимо не слышали?
              • +1
                Каюсь, я не совсем понимаю как устроено все в мире UNIX, я думал что если бинарник собран с одной версией OpenSSL, значит где-то в бинарнике используются функции из этой версии OpenSSL, а по вашему он берет системную OpenSSL? зачем тогда запрашивать этот самый OpenSSL при сборке если можно подгрузить существующий в системе на момент запуска?
                • 0
                  Извините, я просто не готов это всё разжёвывать…
                  Читаем про dll(для Windows), so(Linux). Читаем про опции компиляции --with-XXX.
                  • 0
                    И на том спасибо
                    • 0
                      Для людей далеких от программирования:

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

                      Alukard, спасибо за ссылку.
                      • 0
                        Единственная вещь — люди, изготавливающие сборки всякого разного софта под windows, да и вообще — всякие «запускающиеся легко» сборки разного софта, любят статическую компиляцию. С впиливанием библиотек в exe-ник, да…
                  • 0
                    Вот здесь: forums.openvpn.net/topic15519.html пишут:
                    Unless you can compile the openvpn source with openssl v101g this problem will remain, upgrading openssl will have no effect on openvpn.

                    Так что всеже я не зря волновался
                    • 0
                      Там сугубо про Windows-версию идёт речь. Мы точно её обсуждаем в этом треде?

                      Yes, generally it is affected. It depends on the OPENSSL version used. On linux the openssl is a separate package, so you can update it with the new fix posted on the official openssl web site. But the OpenVPN Windows client is bundled with the openssl library, so you should either wait for official OpenVPN update or try to update the openssl library only.
            • –1
              Скорее всего (если только вы не используете какой-нибудь богомерзкий Генту, да ещё и в гамаке и ластах со статической компиляцией библиотект), ваш линукс динамически линкует пакетированный OpenVPN с пакетированным же OpenSSL. Соответственно, обновление пакетов и перезагрузка (для верности, фиг его знает как оно там символы из сторонних библиотек кеширует в райнтайме) — и дело в шляпе.
              • +1
                В дженту по умолчанию динамическая линковка, так, что логика также нужно обновить lisopenssl
  • 0
    А что, в этом контексте, происходит с ssh-туннелями? Тоже беда? Или все спокойно и это наше «всё»? Кто в курсе — просветите, плз.
    • –1
      wiki
      Протокол SSH-1, в отличие от протокола telnet, устойчив к атакам прослушивания трафика («снифинг»), но неустойчив к атакам «человек посередине». Протокол SSH-2 также устойчив к атакам путем присоединения посредине (англ. session hijacking), так как невозможно включиться в уже установленную сессию или перехватить её.
      • +4
        Казалось бы, причем здесь это?
    • +7
      ssh, насколько я понимаю, в типовых своих конфигурациях, не оказался задет. Если бы был задет ещё и ssh, то это был бы тот самый конец света, про который бухтели древние сисадмины Майя.
      • 0
        > Если бы был задет ещё и ssh

        Вот после сабжевых новостей я уже особо и не удивлюсь, если и там что-то «внезапно» найдут :(
      • +1
        OpenSSH не использует OpenSSL.
        • +2
          Но это не значит что в нем нет подобного по масштабам бага. Тьфу-Тьфу-Тьфу
  • 0
    Мой VPN-провайдер уже давно пофиксился.

    А ваш?
    • +3
      А мой пофиксился в первые часы после «релиза». Ну т.е. я прочитал новость посреди ночи и полез на серваки фиксить.
  • –3
    А может быть… может быть, вся эта шумиха с Heartbleed — это попытка сместить внимание заинтересованной общественности в сторону от чего-то действительно важного? Уж очень звучание термина напоминает работу маркетологов.
  • 0
    Тут интересное совпадение: сначала этот блид, а потом сразу вот это — uinc.ru/news/sn21630.html

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

Самое читаемое Разработка