web-dev-qa-db-ja.com

JBossでの無制限のファイルアップロード

私は現在、すてきなUnrestricted File Uploadの脆弱性を発見したwebapp pentestに取り組んでいます。唯一の(そして大きな)問題は、これを完全に機能するリモートWebシェルにまだエスカレートできないことです。

基本的に、(change Avatar picture featureを使用して)サーバーに必要なコンテンツをアップロードできます。重要な点として、アップロードされたファイルはwhatever.com/something/avatar/2に保存されます。

基盤となるテクノロジーは、CentOSで実行されるApacheサーバーとJBossサーブレットであるようです。

機能しないJSPリバースシェルをアップロードしようとしましたが、JBossサーブレットの場合、WARファイルを使用してWebページをデプロイする必要があること、また、WARファイルを特定の/deployフォルダに配置する必要があることを確認しました。ここでの問題は、ファイルをアップロードすると、常にwhatever.com/something/avatar/2に保存されることです。

誰かがリバースWebシェルを取得するのに役立ついくつかの提案がありますか?

編集1:

ファイルをアップロードするときはContent-typeimage/jpegに設定する必要がありますが、ファイルの拡張子は好きなように設定できるため、Content-typeでのみチェックが行われます。

EDIT2:

ファイルをアップロードするためのリクエスト/レスポンス:

POST /something/profile/upload HTTP/1.1
Host: Host
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Referer: REFERER
Cookie: JSESSIONID=COOKIE
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Content-Type: multipart/form-data; boundary=---------------------------18769807824524
Content-Length: 1541

-----------------------------18769807824524
Content-Disposition: form-data; name="email"

[email protected]
-----------------------------18769807824524
Content-Disposition: form-data; name="avatarImageUpload"; filename="cmd.war"
Content-Type: image/jpeg
Hello world

HTTP/1.1 200 OK
Date: Mon, 16 Jan 2017 17:26:12 GMT
Content-Type: text/html;charset=ISO-8859-1
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Length: 54

{"success":true,"fileUrl":"/something/profile/avatar/2"}

アップロードされたファイルにアクセスするときの要求/応答-ブラウザーで応答を正しく表示するには、返されたContent-typeヘッダーを改ざんする必要があります。

GET /something/profile/avatar/2 HTTP/1.1
Host: Host
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-GB,en;q=0.5
Referer: REFERER
Cookie: JSESSIONID=COOKIE
Connection: keep-alive

HTTP/1.1 200 OK
Date: Tue, 17 Jan 2017 09:18:34 GMT
Content-Type: image/jpeg
Content-Length: 11
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

Hello world
4
AresS31

アップロードを安全にするには、主に次のようないくつかの制限が必要です。

  1. 最大アップロードファイルサイズ
  2. 1日あたりのIP /セッションあたりの最大アップロード数
  3. 1日あたりのIP /セッションあたりの最大合計ファイルバイト
  4. 1日あたりの最大合計ファイルバイト数(すべてのIP)
  5. 特定のサーバー側ターゲットディレクトリパス
  6. アップロードされたファイルの実行権限を拒否する
  7. 許容されるMIMEタイプの特定のセット
  8. メディアに埋め込まれた実行可能コードの排除[1]

拡張タイプの制限は、ネットワークではなく、デフォルトおよび優先アプリケーションの関連付けにのみ関連するため、無関係です。拡張子に関係なく、任意のタイプのコンテンツを任意のファイル名に配置できます。

ブラウザーまたはその他のクライアントアプリを備えたサーバー上のパブリック接続から発信されたドキュメントを(まったくセキュリティレベルが必要な場合)開くことはありません。

MIMEタイプは攻撃者も自由に合成できるため、セキュリティ対策は最悪の事態を想定する必要があります。したがって、上記の5-7。項目1〜4は、サーバー攻撃の脆弱性の拒否と、偶発的なストレージの過負荷または他のサイトの利用不可の原因とリスクを減らすためのものです。

メモ:

[1]実行可能コードとサーバーがサポートするスクリプト言語をスキャンするか、予測できない方法でメディアファイルをデコードおよび再エンコードすることにより、実行可能コードを排除できます。

1
Douglas Daseeco