Страсти по недавно обнаруженной 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
