AWSエンジニアのためのAWS特化型求人情報サービス

【Amazon EC2】特定OSのAmazon EC2におけるSSH Terrapin Attackへの対処

2024.01.19
【Amazon EC2】特定OSのAmazon EC2におけるSSH Terrapin Attackへの対処
この記事をシェアする

はじめに

みなさまこんにちは、yyokotaです。
年が明け2024年になりましたが、みなさまいかがお過ごしでしょうか。
大きな災害や事故がありましたが、今年の残りの期間が平安なるものであることをお祈り申し上げます。

今回の話題

さて、今回のトピックですが昨年末より話題になっており、自分も興味のある「SSH Terrapin Attack」を取り上げます。
SSH接続における脆弱性を利用した攻撃で、これによりさまざまなセキュリティ上の懸念が生じています。
もちろん管理者はこの問題に対して対処をする必要があり、AWS上で構築されたサーバについても例外ではありません。
この記事では、この「SSH Terrapin Attack」について概要を説明し、そのうえでAmazon Linux 2で作成されたEC2インスタンスにおける脆弱性への対応方法を説明します。

TL;DR

  • 昨年12月末、SSHに対する新たな攻撃手法「SSH Terrapin Attack」が発見された
  • SSH接続における暗号化手法で特定のものを利用している場合に脆弱である
  • 「Strict Key Exchange」の利用、もしくは「chacha20-poly1205@openssh.com」と「*etm@openssh.com」の無効化で対処可能
  • Amazon Linux系OSでは、2024/1現在で最新OSで対応済み
  • RHEL9では未対応、対応の必要性あり

SSH Terrapin Attackとは

概要

SSH Terrapin Attackとは、SSH接続においてその安全性を低下させる攻撃手法です。
詳しい内容はJVNのページに内容が記載されていますので、これを見てみます。

通常、SSH接続時のハンドシェイク処理では、シーケンス番号順にパケットがやり取りされ、途中のパケットが削除された状態で次のパケットを受信すると、シーケンス番号が一致しないことが検出され、接続が中断されます。
Terrapin Attackでは、SSH接続のハンドシェイク通信を傍受および改ざん可能な攻撃者によりハンドシェイク中にIGNOREメッセージが挿入されると、シーケンス番号の不整合が正常に検出できなくなります。
その結果、サーバから送信されるEXT_INFOメッセージを削除することも可能になります。
EXT_INFOメッセージはSSHのセキュリティを向上させる拡張機能を含むため、EXT_INFOが削除されることにより、SSHの安全性を低下させられる可能性があります。

これだけだとちょっとわかりづらいので、実際に図にしたものを見てみましょう。

Terrapin Attackの応用例

この図では、ClientからServerへのSSH接続を試みています。

注目すべきは、3番目にMITMによってClientへ送信されるIGNOREと、6番目にMITMによって傍受されるEXT_INFOです。

この2つの操作によってどのような影響が発生するのか、Terrapin Attack: Breaking SSH Channel Integrity By Sequence Number Manipulationを参照してみると、以下の記載がありました。

EXT_INFOを落とすことによる影響

  • サーバ・クライアント間の認証が弱い形式になる
  • サーバ側が認識できる拡張機能等の情報伝達が不可能になる
  • 結果、拡張機能が利用できなくなり弱い暗号化方式や認証方式を強制されてしまう

IGNOREを送信する理由

  • 暗号化していない通信では、Sequence Numberのチェックが行われない
  • 暗号化通信の開始時、Sequence Numberさえ正しければ整合性が取れていると判断される
  • 何もしなければ、EXT_INFOパケットの挿入でサーバ・クライアント間のSequence Numberに不整合が生じる
  • ここでIGNOREを挿入することで、Sequence Numberの整合性を取ることができる

より詳細な情報を必要とする場合は、上記の論文を直接ご参照ください。

Amazon EC2は脆弱性の対象となるか？

AWSは既にこの脆弱性に対して声明を出しています。

CVE-2023-48795

この中で発表されているのが、

AWS is aware of CVE-2023-48795, also known as Terrapin, which is found in the SSH protocol and affects SSH channel integrity. A protocol extension has been introduced by OpenSSH which needs to be applied to both the client and the server in order to address this issue. We recommend customers update to the latest version of SSH.

末尾に記載されている通り、最新バージョンのSSHにアップデートすることが推奨されているようです。

影響を受けるパッケージは以下の通りです。

  • Amazon Linux 2023(libssh)
  • Amazon Linux 2023(openssh)
  • Amazon Linux 1(openssh)
  • Amazon Linux 2(openssh)

CVSSスコアは5.9で、レーティングとしてはMediumではありますが出来れば対処しておきたいところです。

  • Medium

リソースの機密性、完全性、または可用性の何らかの侵害につながるが、悪用がより困難なセキュリティ問題。これらのセキュリティ問題は、認証やデフォルト設定などの要素によって軽減される。

実際に確認してみる

実際に、EC2がTerrapin Attackへの対応が完了しているかを確認してみます。
GitHubに、SSH Terrapin Attackに対するVulnerability Scannerがリリースされていますので、こちらを使ってみましょう。

Amazon Linux 2でまずは試す

実行環境

OS: Amazon Linux 2(amzn2-ami-kernel-5.10-hvm-2.0.20240109.0-x86_64-gp2)
SSHクライアント: Teraterm 5.1

手順

  1. Amazon Linux 2を利用して新しくEC2インスタンスを作成します。
  2. スクリプト実行のために、Goのインストールが必要です。以下のコマンドを実行します。
   sudo yum install -y go
  1. 以下のコマンドを実行し、Terrapin-Scannerをインストールします。
   go install github.com/RUB-NDS/Terrapin-Scanner@latest
  1. 環境変数が設定されていないので、デフォルトで $HOME/go/bin以下にインストールされます。
  2. 以下のコマンドを実行し、Terrapin-Scannerを実行します。
   ./Terrapin-Scanner --connect localhost

結果

コマンド実行後、以下の結果が出力されました。

$ ./Terrapin-Scanner --connect localhost
================================================================================
==================================== Report ====================================
================================================================================

Remote Banner: SSH-2.0-OpenSSH_7.4

ChaCha20-Poly1305 support:   true
CBC-EtM support:             true

Strict key exchange support: true

The scanned peer supports Terrapin mitigations and can establish
connections that are NOT VULNERABLE to Terrapin. Glad to see this.
For strict key exchange to take effect, both peers must support it.

Note: This tool is provided as is, with no warranty whatsoever. It determines
      the vulnerability of a peer by checking the supported algorithms and
      support for strict key exchange. It may falsely claim a peer to be
      vulnerable if the vendor supports countermeasures other than strict key
      exchange.

For more details visit our website available at https://terrapin-attack.com

このなかの、

The scanned peer supports Terrapin mitigations and can establish
connections that are NOT VULNERABLE to Terrapin.

の一文より、このサーバはTerrapinに対して脆弱ではない事がわかりました。

Terrapin Attackに対して回避策とされているStrict Key exchange supportがtrueになっていますので、たしかに対策が行われていそうですね。さすがの対応スピードです。

RedHat Enterprise Linux 9では？

同じように、RedHat Enterprise Linux 9に対してもスクリプトを実行してみます。

実行環境

OS: RedHat Enterprise Linux 9(RHEL-9.3.0_HVM-20231101-x86_64-5-Hourly2-GP2)

結果

$ ./Terrapin-Scanner --connect localhost
================================================================================
==================================== Report ====================================
================================================================================

Remote Banner: SSH-2.0-OpenSSH_8.7

ChaCha20-Poly1305 support:   true
CBC-EtM support:             false

Strict key exchange support: false

The scanned peer is VULNERABLE to Terrapin.

Note: This tool is provided as is, with no warranty whatsoever. It determines
      the vulnerability of a peer by checking the supported algorithms and
      support for strict key exchange. It may falsely claim a peer to be
      vulnerable if the vendor supports countermeasures other than strict key
      exchange.

For more details visit our website available at https://terrapin-attack.com

VULNERABLEが出ました！

ChaCha20-Poly1305 support: trueより、この暗号化スイートが有効になっているため脆弱である判定になっているようです。

対処

暗号スイートを変更し、脆弱な暗号化方式を無効化します。

まず以下のコマンドを実行し、暗号スイートの設定を確認します。

$ cat /etc/crypto-policies/back-ends/opensshserver.config
Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr

この中にchacha20-poly1305@openssh.comがありますので、これを無効化します。

$ cat /etc/crypto-policies/back-ends/opensshserver.config
# Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr
Ciphers aes256-gcm@openssh.com,aes256-ctr

このあと、sshdを再起動します。

$ sudo systemctl restart sshd.service

その後、Terrapin-Scannerを実行してみると、、、

$ ./Terrapin-Scanner --connect localhost
================================================================================
==================================== Report ====================================
================================================================================

Remote Banner: SSH-2.0-OpenSSH_8.7

ChaCha20-Poly1305 support:   false
CBC-EtM support:             false

Strict key exchange support: false

The scanned peer supports Terrapin mitigations and can establish
connections that are NOT VULNERABLE to Terrapin. Glad to see this.
For strict key exchange to take effect, both peers must support it.

Note: This tool is provided as is, with no warranty whatsoever. It determines
      the vulnerability of a peer by checking the supported algorithms and
      support for strict key exchange. It may falsely claim a peer to be
      vulnerable if the vendor supports countermeasures other than strict key
      exchange.

For more details visit our website available at https://terrapin-attack.com

無事に、NOT VULNERABLE to Terrapinになりました！

しかし、この対処方法はあくまで暫定的であり、場合によってはOpenSSHのアップデートを検討しなければなりません。

コスト・影響・労力の大きさなどを鑑みて、慎重に検討することをおすすめいたします。

おわりに

ここまで、新たなSSHの脆弱性への攻撃手法「Terrapin Attack」について紹介し、影響があるOSでのサーバの暫定対処について述べてきました。

Amazonではいちはやくこの脆弱性に対応しAmazon Linux に対してFixを行っていますが、RHELを始めとするその他ベンダ系OS、もしくは古いOSではその保証がされません。

現在システムで利用中のEC2において脆弱性を持つ危険性がある場合には、可能な限り速やかに対応を行うことが推奨されます。

この記事をシェアする
著者：yyokota
2023/5/30 AWS All Certification 元コンサル・エンジニア見習い

関連記事