私たちは、他の多くのサービスと同様に、プロジェクトでOpenSSLライブラリを使用しますが、メールを含むほとんどのサーバーはリスクの対象外でした。 私たちのプロジェクトの多くでは、OpenSSL 1.0.0を使用していますが、これは攻撃に対して耐性があることが判明しました。
それにもかかわらず、私たちはリラックスすることを急いでいませんでした-最初に、残りのプロジェクトをチェックアウトする必要がありました。 脆弱性を悪用するNmapのNSEスクリプトがひざまずいて書かれ、30分以内にOpenSSLの脆弱なバージョンを備えたマシンのリストを受け取りました。
バナーシステムのサーバーといくつかのコンテンツプロジェクトは、攻撃に対して脆弱であることが判明しました。 少しパニックし、4月8日の14:00までに、この脆弱性は修正されました。
Heartbleedはこれらのプロジェクトの個人データ、ユーザーログイン、またはパスワードへのアクセスを許可しませんでしたが、攻撃者はランダムなユーザーのログインセッションを受け取り、SSL証明書を危険にさらす可能性があります。
私たちはすぐにSSL証明書を扱い始めました。 すべての重要な証明書はすでに再発行されており、置き換えられる予定です。残りの証明書の置き換え作業は継続されます。
ユーザー認証セッションに関しては、ここで保護されました。 ミッションクリティカルなプロジェクトでは、いわゆるセッション分離が実行されます。 その本質は次のとおりです。攻撃者でさえ、何らかの方法でユーザーの認証セッションを取得すると、その助けを借りて他のポータルプロジェクトにアクセスできなくなります。
おそらくCodenomiconの予測が実現し、Heartbleedは実際に多くのサービスがセキュリティシステムを強化する機会になるでしょう。 私たちにとって、このストーリー全体が教育不安の役割を果たしました。私たちは、脅威メッセージに迅速に対応し、すべての抜け穴を迅速に閉じるように訓練しました。 さて、そして、おそらく、攻撃者に「パサランはいらない！」と言ってください。