サーバーのバッファオーバーフローの脆弱性を悪用するシェルコードを書いています。これを行うには、サーバーに送信するポートバインディングシェルコードを用意してから、(Linux端末から)コマンドtelnet serverAdress 4444を実行します。ここで、4444は開いたポートです。コマンドの実行に使用できるシェルが返されることを期待しています。しかし、私はいつもコマンドで終わる
bin/sh:ttyにアクセスできません。ジョブ制御がオフになっています
サーバーコードを変更することはできません。シェルコードはこのウェブサイトから取得したので正しいと思います( http://www.tsirogiannis.com/exploits-vulnerabilities-videos-papers-shellcode/ linuxx86-port-binding-shellcode-xor-encoded-152-bytes / )。私の研究から、これは私の端末が実行されているモード(インタラクティブモードと呼ばれるものなど)に関係している可能性があるようです。
関係するすべてのコンピューターはLinuxマシンであり、私が使用しているマシンはUbuntuの最新バージョンを実行しています。
このジョブ制御エラーが何を意味し、どのようにそれを修正できるかについてのアイデアはありますか?
削除するだけ/dev/console
cd /dev
rm -f console
ln -s ttyS0 console
/etc/inittab
コンテンツを編集/変更
::askfirst:/bin/sh
に:
ttyS0::askfirst:/bin/sh
シェルのコマンドを変更できる場合は、次を試してください:sh +m
の代わりにsh
。それは私には完璧に働きました。
つまり、shはttyではなくソケットに書き込んでいるため、Ctrl + ZやCtrl + Cなどの高度なコマンドは使用できません。このため、shはバックグラウンドプロセス(command &
)および関連するbg/fg/disown/jobsコマンド。ただし、自身をフォークして入力を閉じるプロセスは引き続き機能することに注意してください。
バックグラウンドジョブがターミナルからデータを読み取ろうとすると、シェルがそれを停止し(SIGSTOPなど)、プロセスを一時停止したことを通知します。シェルがこれを行わない場合、競合状態が発生し、書き込む内容がバックグラウンドプロセスまたはシェルで終了する可能性があります。これは、Shellセッションで面白くて腹立たしい混乱を引き起こします。
仮想端末を作成するより複雑なシェルコードを使用するか(ただし、一度発生するとシェルコードではなくなります)、または醜いハックには制限があることに注意してください。
Debian Mateでも同じ問題がありました。 /ディレクトリがインストールされているdev/sda1のライブUSBからfsckを実行するだけです。
私が誰かを助けたことを願っています