writeup — 脆弱性発見の研究プロジェクト
この記事は英語の原文から機械翻訳されたものです。誤りが含まれている可能性があります。

これは、DePaul大学のFilipo Sharevski博士のもと、Adversarial Cybersecurity Automation Labで私が主導した研究プロジェクトの一部です。対象デバイスは、著名な企業が製造する量産グレードのRFIDリーダーでした。

免責事項:

これはデバイスの出荷時ファームウェアでのみテストしました。そのファームウェアのバージョンは明記しません。新しいファームウェアでも動作した可能性はありますが、執筆時点では思い出せません。

セットアップ

まず、デバイスはPoEまたは自身の電源で起動します。起動すると、緑色の点灯が準備完了を示します。攻撃側のマシンは、USBまたはイーサネット経由で同じネットワーク上にいるだけで構いません。USBを使うとデバイスはリンクローカルネットワーク上に置かれます(以下のデモではこれを使用します)。

Secure Shell(SSH)サービスが有効になっていること(デフォルトで有効)、かつデフォルトユーザー rfidadm(デフォルトパスワードは change)に対してパスワード認証なしで動作していることを確認してください。有効になっていない場合はWebインターフェースから有効化できます。

USB提供のネットワークとDCアダプタによる電源供給

侵入する

nmapを使って利用可能なサービスを確認します:

sudo nmap -Pn 169.254.10.1

-Pn フラグは、pingが存在しなくてもそれを無視して対象をスキャンするだけのものです。

nmapスキャン結果はSSHが開いていることを示す

SSHが起動していることを確認したら、ログインします:

ssh [email protected]

パスワードは不要です。rfidadm としてログインできます。

SSHログイン

権限昇格

システム内を調べ、linpeasを使ったところ、現在のユーザー rfidadm が読み取り・書き込み・実行の権限を持ついくつかのスクリプトを見つけることができました。これは /mnt/platform/scripts/InitThredboScript.sh にある起動スクリプトでした。このスクリプトは起動のたびにシステムレベルの権限(root)で自動的に実行されます。これを利用して、ルートパーティションが読み取り専用に設定される前にさまざまなものを変更できます。

スクリプトを開きます

vi /mnt/platform/scripts/InitThredboScript.sh

そして178行目に移動し、以下のsedコマンドを追加します。 この行はテスト済みで動作しますが、他の行でも動作する可能性が高いです。

viコマンド

sed -i 's/false/bash/' /readerconfig/passwd

スクリプトの内容

このsedコマンドは基本的に検索と置換で、/etc/passwdファイル(このデバイスではこのファイルを /readerconfig/passwd というパスにマッピングしています)内の文字列 false を探し、それを bash に置き換えます。通常、ユーザーはその文字列を false に設定してアカウントを無効化しますが、bash に設定するとログインできるようになります。これは本質的に、ログイン後に起動される実行ファイルです。falsebash に置き換えることで、rootログインを許可することになります。

rootアカウントにもパスワードが設定されていません。このおかげでこの手順は非常に簡単になります。したがって、再起動後に、先ほど編集したスクリプトが再び実行されるようトリガーされます。

再起動後のデバイス

再起動後、再び rfidadm としてSSHでログインし、次を実行します:

su root

これでrootになりました。あなたはこのデバイスを掌握しました!

su root - 完全な権限昇格

どうしてこんなことに!?

このデバイスは、ファームウェアにいくつかの疑問の残る選択を伴って出荷されていました。

  1. デフォルトユーザーにパスワードなしでSSHがデフォルトで有効化されている
  2. デフォルトユーザーが起動スクリプトへの書き込みアクセス権を持っている。1つのスクリプトだけでなく、同じ攻撃が可能と思われる他のスクリプトもいくつか存在した。
  3. その起動スクリプトや他の重要なスクリプトがすべてrootとして実行される

さらに、/readerconfig/passwd への変更は永続的なので、この脆弱性を修正するファームウェア3.10.30に更新しても、加えた変更は元に戻りません。

対策

もしあなたがベンダーなら、私が推奨するのは次のとおりです:

  • SSHを無効にした状態で出荷する
  • デフォルトユーザーを制限する。/mnt/platform/scripts 内のものや起動時の実行ファイルへの書き込みアクセスを一切与えない。理想的には、このユーザーをchroot jailに閉じ込める。フルシステムアクセスは不要である。
  • /etc/shadow! を入れてrootアカウントを完全にロックする
  • /etc/passwd/etc/group/etc/shadow を隠す(chroot jailで可能)
  • デバイスごとに一意でランダム生成されたパスワードをデフォルトユーザーに割り当てる

使用したツール:

  • linpeas
    • Linuxシステム上で手近な弱点を見つけるのに優れたツール
  • nmap
← Back
Comments
×