/ etc / passwdで指定されたコマンド/スクリプトをバイパスする
/etc/passwdの次の行を考えてみます。
sadeq:x:1000:1000:Mohammad Sadeq Dousti,,,:/home/sadeq:/bin/custom-script.sh
最後の部分/bin/custom-script.shは、ユーザーがシステムにログインしたときに実行されるコマンド/スクリプトを示しています。現在、これは単純なBashスクリプトであり、ユーザーにメニューを表示し、実行可能なコマンドを効果的に制限します。
または、私はそう願っています！たぶん、ユーザーがcustom-script.shをバイパスしてBashに直接アクセスできる方法があるでしょう。その後、ユーザーコンテキスト内で任意のコマンドを実行できます。
上記のBashスクリプトをバイパスして他のコマンドを実行する方法はありますか？
編集：以下の単純なケースをcustom-script.shと見なします。
#!/bin/bash
echo What is your name?
read name
echo Hi $name
投稿したサンプルスクリプトを使用すると、制限付きユーザーは、たとえば、他のユーザーの名前やインストールされているプログラムなど、システムについて多くのことを学ぶことができます。例えば。
What is your name?
> /home/*
Hi /home/foo /home/bar /home/sadeq
あなたが持っている実際のスクリプトは、おそらくユーザーが実際のシェルアクセスを取得できるようになるまで、同様の方法で悪用される可能性があります。
サンドボックス環境でログインメニューを開始すると、状況を改善できる可能性があります。必ずしも100％防弾であるとは限りませんが、少なくともサンドボックスを使用すると、スクリプトの作成者が残したセキュリティホール全体が詰まります。
（おそらく意図しない）バックドアがあると仮定します。
1990年代初頭のSunワークステーションのデフォルトの/etc/passwdには、次のようなエントリが含まれていました。
games::0:0:games:/nopath:/bin/false
つまり、パスワードのない「games」という名前のアカウントです。どうやらこのアイデアを思いついた天才には想像力がなく、それにuidとgidのゼロ（つまり、ルートとホイール）を割り当てました。ホームディレクトリは意味がなく、シェルは常に失敗して終了するプログラムに設定されていたため、一般的にはそれで問題ありませんでした。さらに、ネットワークによるすべてのアクセスのデフォルト設定（telnet、rlogin、rcp、ftp）は、0のuidによるアクセスを防ぐように設定されています。適切に設定されたパスワード、ホームディレクトリ、およびシェルを使用して、rootの個別のpasswdエントリがありました。
つまり、ゲームとしてログインしようとすると、次のようになります。
- コンソールでゲームとしてログインすると、最初は成功しますが、
/bin/falseシェルが生成され、すぐに終了します。 - Telnetまたはrloginを使用すると、ログインが完全に拒否されます。成功した場合でも、
/bin/falseシェルはすぐに終了します。 - FTPとscpはシェルを使用しませんが、uidゼロへのアクセスを拒否するように構成されているため、この方法ではログインできませんでした。
- GUIログインは、ウィンドウマネージャー、クロッククライアント、端末などのデフォルトのGUIサービスを起動します。子シェルがすぐに終了するため、後者はすぐに終了します。したがって、時計以外は空の画面になります。 （これについては以下で詳しく...）
- 本当にhadとしてrootとしてログインするには、コンソールから行うか、最初にそのマシンの別のユーザーとしてrlogin/telnetを実行し、次に
su rootを実行する必要があります。どちらの方法でも、ゲームのpasswdエントリではなく、ルートのpasswdエントリを使用するため、rootが機能するように機能します。
そのため、GUIログインを行わない限り、ゲームアカウントは常に失敗するように見えました。その場合、登場したのは時計だけでした。ただし、背景を右クリックしてルートメニューを取得することもできます。この場合、ユーザーが通常は自分でカスタマイズするプログラムの工場提供のリストが表示されます。 （メニューのカスタマイズはゲームアカウントでは機能しませんでした。理由は正確には覚えていません。）ターミナルウィンドウをさらに表示しようとすると、すべて失敗します。パズルゲームがありました（そもそもアカウントの原動力となった可能性があります）。別の選択はログアウトすることでした。そして、グラフィカルなデバッグツールdbxtoolがありました。
dbxtoolは、今日のdbxと同様に、gdbシンボリックデバッガーのグラフィカルフロントエンドでした。 uidゼロなので、システム上の任意のプロセスに接続して制御できますが、Sunが提供するプログラムはシンボルなしでコンパイルされたため、これは役に立ちませんでした。シェルを起動することもできますが、これはShell環境変数（/bin/false）を使用します。ただし、環境変数を変更することもできます。つまり、次の方法でルートシェルを取得できます。
- GUIを介して、パスワードなしでゲームとしてログインします。
- 右クリックして、ルートメニューを表示します。
dbxtoolを開始します。setenv Shell /bin/sh- （オプション）
setenv HOME / !でシェルを開始する- 端末が設定されていないため、
stty saneを実行します
ほら、パスワードなしのルートシェル！
したがって、ユーザーが無効なシェルから脱出できないと想定しないでください。
スクリプトの実行をバイパスすることはできません。これはあなたのログインシェルであり、ログインするたびに開始されます。 login Shellとして、終了するたびにログオフします。しかし、ログインシェルで癖、バグ、および不整合を使用してエスケープすることができます。
できることの1つは、メニューのオプションを使用してシェルにエスケープすることです。メニューでvim、less、more、またはその他のコマンドを開始できる場合は、理論的に自由にすることができます。 sysadminの経験がある場合、これらのコマンドは制限されたバージョンを使用し、機能しません。
同様のケースがあったウォーゲームの課題を覚えています。シェルはmoreコマンドを使用して出力を単に出力するものを指し、セッションを終了しました。ただし、moreにはテキストエディターが組み込まれているため（この特定のケースではviでした）、接続元のターミナルウィンドウのサイズを変更してmoreをアクティブにしてから使用するだけで十分でした。シェルを逃れるために。
したがって、答えはスクリプトの動作によって異なります。実行している各コマンドのmanページを確認して、脆弱性を回避します。
TLDR：あなたが言及したスクリプトは安全です！
ただし、本番環境では別のバージョンを使用する可能性があることを理解するには、次の概念に注意する必要があります。
1。「読み取り」がコマンドインジェクションに対して脆弱かどうか。脆弱である場合、（name /）のような 'Bob; cat/etc/passwd 'はpasswdファイルの内容を返し、' Bob &&/bin/bash -i 'はインタラクティブなbashセッションを提供します。
そのような質問はすでに尋ねられていました。ここに：
「いいえ、脆弱ではありません」と回答する理由は次のとおりです。
「（..）最近のシェルは、変数置換の前にステートメントを解析するため、この攻撃の影響を受けません。」
したがって、あなたの例では、「read」によるユーザー入力を標準シェル内からバイパスすることはできません。
2。入力はどこで解析されますか？
「エコー」はエスケープ手法を提供しないため、あなたのスクリプトは安全です（少なくとも不明です）。ただし、f.e。で言及されているような「危険な」バイナリの使用には注意してください。ここに：
https://fireshellsecurity.team/restricted-linux-Shell-escaping-techniques/
ユーザー入力がman | less | more、awk、find、nmap、python | php | Perl、bash | shによって解析される場合、エスケープが可能であり、完全なインタラクティブを許可しますシェル（私はless、pythonでテストして見つけただけです）。
例のように、入力をエコーのみに置く場合は、問題ありません。
3。次のように、入力がシェルコマンド内でアスタリスク（*）を使用しているかどうか：tar *またはls *
それがあなたのシナリオでいつ役立つかは想像できませんが、常に言及する方が良いでしょう。これが事実である場合、以下の記述に精通してください：
https://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt
このような動作は、スクリプトをエスケープする可能性もあります。