What is same site scripting and what are some exploit scenarios?

Question

I know it is an issue with how DNS is configured , but is it really dangerous if the attacker couldn't access your network?

Answer 1

Based on the link from Julian's answer, it's pretty straightforward. It does seem a little dangerous but nothing critical.

How the web works

Imagine you have a website. Browsers send HTTP traffic to that website. This traffic includes session cookies. The site should be TLS protected, or your session cookies are going over the internet in cleartext, for anyone to read. You also need to protect your session cookies (and any other sensitive cookies) with the 'secure' flag to prevent them from being sent over http traffic, or your browser will just send them to any server that intercepts your cleartext http requests. And you can use HSTS to prevent usage of http to your server.

When the browser tries to communicate with the web server, it communicates via IP -internet protocol. Internet protocol doesn't use host names, but rather uses ip addresses - 4 decimal separated values such as 127.0.0.1. the browser uses dns* to learn the ip address for the hostname to which you want to connect. The web server has an associated dns server whose job it is to respond to 'what ip address is this host'. Every named host on the internet is supported by a dns server. Assuming dns is secure**; the browser gets the server's real ip address from the real dns server.

The class of misconfiguration in question

But what happens if the dns server is misconfigured and returns the wrong ip address? If the desired server is www.example.com at 1.1.1.1 and the server sometimes returns 6.6.6.6, which may belong to evil.com, what does the browser do? The browser connects to 6.6.6.6, evil.com.

Now, this isn't so bad at first blush. Remember how the traffic is TLS protected? Well, TLS lets the browser detect that 6.6.6.6 is not example.com because 6.6.6.6 does not have the private key that goes with example.com's certificate. The browser rejects the connection attempt to evil.com.

Ah, but what if TLS isn't used to connect to 6.6.6.6? In that case, there is a risk. The cookies don't get sent, because you remembered to use the secure flag on your cookies. However, the same domain policy that protects pages served from one domain against pages served from another domain breaks down - these servers are both in the same domain. In theory, malicious JavaScript on 6.6.6.6 should be able to interact with the page served by 1.1.1.1. This is bad. There may be other attacks that suddenly start working as well.

Thankfully, this misconfiguration shouldn't happen in practice. The DNS server owned by example.com has no reason to serve evil.com's IP address as though it represents example.com. Typos causing this are unlikely. Even if a typo did occur, users would notice outages before the attacker would likely have the time to make use of the window of opportunity.

The specific misconfiguration in question

But what if there were a common misconfiguration? The security focus message lists one: forgetting to put a period at the end of the definition for localhost. Due to the way the server parses the configuration file, localhost then becomes interpreted as a hostname within the current domain instead of a fully qualified domain in and of itself. Going back to example.com: if example.com defines localhost incorrectly, we get a resolvable ip address for localhost.example.com.

This routable address for localhost.example.com, which exists within the example.com domain, is assigned a loopback ip address. The loopback address is a special address that computers know means 'myself'. When you try to connect to the loopback address, you are always connection to the machine sending the message, by definition. In fact, most operating systems will not even send the message to the network when the loopback address is used - then traffic stays entirely on the local machine.

Impact

Just like evil.com could attack your usage of example.com in the original misconfiguration, your computer can now attack your usage of example.com. The main thing that really seems to lower the risk is that the attacker has to be on the same machine as you are. If they're not, they can't open a network port over which to serve HTTP traffic to your browser from the local machine.

If the attacker is not on your local machine, they cannot make use of this specific misconfiguration.

Example

Let's take an example to try and help understand how this works. Victoria, our victim, is logged with shell access to vicki.com, IP 2.2.2.2. Mallory, our attacker, is also logged into vicki.com with shell access. Evelyn, our other attacker, controls evil.com at 6.6.6.6.

Vicki opens her web browser within her vicki.com shell, and browses to example.com, which has a misconfigured DNS entry to include localhost in the example.com domain. Vicki clicks around and does stuff, and eventually, for whatever reason follows a link to localhost.example.com.

Mallory prepared for this eventuality. He is running an HTTP server on vicki.com, with malicious JavaScript. Vicki's browser loads Mallory's malicious page and executes the JavaScript payload. Mallory's JavaScript can now access vicki's account in example.com and do anything that vicki could d, as vicki. If vicki could read a private message that was sent just to her now so can mallory. If she could delete a user account, now so can mallory. Mallory, quite literally, the same level of access to Vicki's account that Vicki does - until she closes her browser*** . Mallory has, quite literally, delivered a cross site scripting payload using a different attack vector.

Note that Evelyn didn't do anything here and that evil.com didn't come into play. Same site scripting requires the attacker to be on the exact same machine that you are on. Evelyn doesn't have that type of access to vicki.com. evil.com doesn't have that kind of access to vicki.com.

Note, also, that Vicki had to load localhost in her browser. Servers don't normally include links to localhost, so there would likely have to be some social engineering to get vicki to load that malicious page.

Risk: medium

Between a misconfiguration, the attacker already being on your system, and the need for social engineering to accomplish the attack, this isn't all tht serious. If I had to score it with CVSSv2, I'd give it 6.0(AV:L/AC:H/Au:S/C:C/I:C/A:C), assuming that vicki is an administrator of example.com, and her web access includes full administrative access. NVD ranges for cvss would call those medium (https://nvd.nist.gov/cvss.cfm)

About the name 'same site scripting'

Like many names in the security field, this is a bit of a misnomer. It's not really the same site that's performing the xss attack. It's the same domain, but the site happens to be the local machine, not the website in question. This is also not an xss/JavaScript injection issue, but a DNS misconfiguration that bypasses the same domain policy and allows non-injected JavaScript from the local host to run in the context of pages served by the misconfigured domain.

It would have been more accurate to name it something like 'Same-Domain Policy Bypass via DNS Misconfiguration', but that's not nearly as sexy.

End notes

* I intentionally omit all details of using the system's resolver to keep this answer a reasonable length and avoid losing the reader in the details.

** We know it's not totally secure, but just pretend it is so that the answer can focus on the question asked

*** Assuming no other vulnerabilities that allow Mallory to persist his access.

Answer 2

Although I can't pretend to understand all the details of this, it does appear that this is dangerous.

See the original post here.

While superficially this may appear to be harmless, it does in fact allow an attacker to cheat the RFC2109 (HTTP State Management Mechanism) same origin restrictions, and therefore hijack state management data.

---

The result of this minor misconfiguration is that it is impossible to access sites in affected domains securely from multi-user systems. The attack is trivial, ...

Answer 3

I know that this may not be what you are looking for since you mention DNS, but IMHO, same-site scripting (SSS), by interpolation from the definition of XSS (cross-site scripting), is a class of attack whereby a malicious user injects javascript code on the HTML page of a website targeting the same domain. Any website that is vulnerable to XSS will also be vulnerable to SSS.

SSS is usually manifested in the form of SSRF (same-site request forgery) attacks that are harder to detect and at the same time much more effective than a CSRF (cross-site request forgery).

For example, one user, Alice, logs in to perform online banking on sillybank.com. The bank website has a public profile page where customers who never sleep can view individual profile of other customers. Suppose another customer, Joker, crafted the following on his profile page:

Name: Joker
About: Thank you for your $1,000 donation.

<script>
 $.post("/transfer", {amount:1000, to:"joker"}); // jQuery method
</script>

Since Alice is already authenticated when she logs in to the website, her session token in the cookie will be used by the bank to identify her when she perform any operation (deliberately or otherwise) on the website, such as a fund transfer.

Common methods (such as referrer checking) to safeguard against a CSRF attack would not work as all requests are made from the same origin. The above attack requires a flaw in the website that allows user to insert arbitrary javascript. However, even without javascript, SSRF is equally devastating with GET request on <img> tags such as:

<img src="/transfer?amount=1000&amp;to=joker">

provided that sillybank.com allows GET request for fund transfer. Any website that is vulnerable to CSRF will also be vulnerable to SSRF.