Missunderstanding about "multiple answers" attack strategy

Hi! I have been using Singularity of Origin for some time and I was wondering whether you can help me answer some technical questions I did not succeed in solving so far.

I have been using the "Multiple answers" attack strategy multiple times and as indicated in the Wiki, one should set the "Target host" field to 0.0.0.0 on Unix and MacOS systems and to 127.0.0.1 on Windows systems. Is there a reason for this? I know that 0.0.0.0 "allows us to access the localhost on Linux and macOS systems" but why isn't 127.0.0.1 used on all systems?

Also, I am running these versions of Chrome (136.0.7103.59 ), Chromium (135.0.7049.95) and Firefox (137.0.2) on a machine with a Debian distribution and it seems like PNA is not enforced in any of these browsers when using 127.0.0.1 as the "Target host" and "First then second" rebinding strategy. This is different compared to what was reported before. Do you know whether there is a reason for this?

127.0.0.1 did not work with Unix-like hosts when using the "Multiple Answers" DNS rebinding strategy, but 0.0.0.0 did (check slide 38 of our 2019 State of DNS Rebinding DEF CON presentation).

Last time I checked, accessing 0.0.0.0 from a browser on Windows did not work, so you're required to target a specific address such as 127.0.0.1 or another valid IP address. 127.0.0.1 did work when using the "Multiple Answers" DNS rebinding strategy on Windows but we haven't retested in quite a while.

0.0.0.0 allows targeting services bound to any interface on a Unix-like (Linux, macOS, etc.) host on a given port. This is especially useful if you don't know which address(es) a service is listening on e.g., 127.0.0.1, 192.168.x.x, etc and/or as a way around the above limitation on Unix-like machine.

In general, you choose "Multiple Answers" when you can, because it's a fast DNS rebinding strategy (e.g., split-second to a few seconds). However, it doesn't work in all attack scenarios.

I believe Private Network Access (PNA) is currently on hold. Last I checked, only Chrome was attempting to implement it. Even when PNA is deployed, the Inline Frame Attack Method bypasses it, and you may have used that.Inline Frame works with all DNS rebinding strategies, including "Multiple Answers".

Thank you for the additional explanation! I would like to point out only one more thing that I discovered and I wanted to make sure I understand this correctly.

When using the rebinding strategy Hook and Control on some local service which requires authentication, the attacker does not get access to a full interactive session because he does not know the valid credentials. This is expected! However, what I am now confused about is that webSocketHook function is supposed to deal with session synchronization and according to your slides "httpOnly cookies are received and transmitted for us". But the target browser will not be able to send the httpOnly cookies to the attacker's browser because they are not accessible by getCookies, right? As a consequence, session synchronization is broken when the target service uses httpOnly cookies to store session data or other information, such as login tokens, as it is the case of the service under study.

Update: I double checked and it seems like cookies are origin bound. This would mean that the payload running under the rebound origin will not send fetch() API requests to the target service including httpOnly cookies set for let's say localhost:8080 because the requests are issued for something like s-...-e.d.rebind.it. But this would mean that no session synchronization is achieved.

But the target browser will not be able to send the httpOnly cookies to the attacker's browser because they are not accessible by getCookies, right?

For the purpose of hooking a web browser via DNS rebinding, we do not need to send those HttpOnly cookies to the attacker's browser. As explained on p. 57 of our DEF CON presentation, "Dealing with Split Brains: Syncing the state between the attacker and target’s browsers", the application running in the hooked browser cannot read HttpOnly cookies via JavaScript, and therefore our controlling browser cannot read them either. That's fine: the controller merely instructs the hooked browser to issue actions against the target application (e.g., GET, POST). The hooked browser automatically includes its own HttpOnly cookies in those requests.

Update: I double checked and it seems like cookies are origin bound. This would mean that the payload running under the rebound origin will not send fetch() API requests to the target service including httpOnly cookies set for let's say localhost:8080 because the requests are issued for something like s-...-e.d.rebind.it. But this would mean that no session synchronization is achieved.

If the attacker already has valid credentials, they can log in through the hooked browser and issue authenticated fetch() requests to the target service, regardless of whether the cookies are HttpOnly. What you cannot do is hijack someone else's existing session without another vulnerability to bridge the origin boundary. Yes, http://attacker.com:8080/ and http://localhost:8080/ are distinct origins, and browsers enforce that distinction.