以下の例では、GitHubで利用可能なfacebook/tac_plusリポジトリのコードを参照しています（Cisco開発キットとShrubbery Networksフォークは単なるtarボールです）。ただし、影響を受けるコードはすべてのプロジェクトで同じです。

パケットが到着すると、start_session() 関数が呼び出され、受信パケットの種類（認証、承認、アカウンティング）を判定します。ここでは、author() → do_author() によって処理される承認パケットに焦点を当て、その後 pre_authorization() を呼び出します。この関数は、TACACS+ パケット内のユーザー名に before authorization コマンドが設定されているかどうかをチェックし、call_pre_process() を介して実行します。次の設定ファイル (tac_plus.conf) は、before authorization コマンドが設定されたユーザーを示しています：

この関数は、before authorization で設定されたコマンドを取得し、substitutes 変数（例：$user、$name、$address）を受信したTACACS+パケットの値で置き換えます。ただし、これは入力検証やサニタイズなしで行われます。

結果のコマンド文字列は、my_popen() に渡され、次の execl() 呼び出しでコマンド文字列を実行します：

これにより、TACACS+ パケットのリモートアドレスフィールドを介して追加のコマンドを注入できます（RFC8907 の rem_addr、rem_addr_len を参照）。同じ方法は他の入力フィールドでも機能する可能性があります。

この脆弱性は認証プロセス中にトリガーされることに注意してください。したがって、パスワードは不要で、設定に存在するユーザー名のみが必要です。

脆弱性のトリガー

この設定でtac_plusをコンパイルして実行する方法は、以下のセクションで説明されています：

• Shrubbery Network tac_plus のセットアップ
• Facebook tac_plus のセットアップ

次のコマンドは、ターゲットデーモン上でユーザーDEFAULTを使用してtacacs_clientを実行します。脆弱性をトリガーするペイロードは、--rem-addr コマンドライン引数で設定されるリモートアドレスフィールドにあります：

これを実行すると、192.168.1.18:1337へのリバースシェル接続が発生します。ユーザー名は、tac_plus.cfg で before authorization または after authorization ディレクティブが設定されているユーザーのいずれかである必要があります。末尾のコマンドリスト（-c service=exec）は必要なコードパスに到達するために必要ですが、値は重要ではありません。

クライアントから送信されたTACACS+パケットをWiresharkで表示したスクリーンショットを以下に示します：

次のスクリーンショットは、注入されたコマンドが実行される直前のデバッグセッションを示しています：

影響を受けるLinuxディストリビューション/BSD派生

さまざまなLinuxディストリビューションが、公式パッケージで影響を受ける2つのフォークのいずれかを使用しています（主にShrubbery Networksフォーク）。以下の表は、本稿執筆時点でShrubbery NetworksまたはFacebookフォークを使用しているLinuxディストリビューションとBSD派生を示しています。このリストは網羅的ではなく、他のディストリビューション/派生も影響を受ける可能性が高いです。

この問題を再現する方法の例は、以下のセクションで確認できます：

• Shrubbery Networks tac_plus の例
• Facebook tac_plus の例