App market's ?host= query param may allow phishing

[bellaj]

Hi,

i have just discovered your project sandstorm, I think it is very interesting however while i tested it i noticed that the online demo apps.sandstorm.io has a CSRF vuln.

if you visit this url https://apps.sandstorm.io/?host=http://malicious_website.com

and you installed any app you will be redirected to the malicious website !!!

[kentonv]

I'm sorry, but I'm not seeing how this could be used maliciously. Could you please describe what kind of attack you are imagining?

It seems to me that if someone can direct you to https://apps.sandstorm.io/?host=http://malicious_website.com then they can just as easily direct you straight to http://malicious_website.com.

[sigmavirus24]

Visiting that URL (https://apps.sandstorm.io?host=http://malicious_website.com) and inspecting links to install an app, gives you something like http://malicious_website.com/install/a33e26d3b0fa40c658e2235dab438f1a?url=https://app-index.sandstorm.io/packages/a33e26d3b0fa40c658e2235dab438f1a as the link. I expect that this is what @bellaj was referencing.

[sigmavirus24]

So if I use https://apps.sandstorm.io/?host=http://httpbin.org/get?query= then I get https://httpbin.org/get?query=/install/a33e26d3b0fa40c658e2235dab438f1a?url=https://app-index.sandstorm.io/packages/a33e26d3b0fa40c658e2235dab438f1a which when clicked provides me with

{
  "args": {
    "query": "/install/a33e26d3b0fa40c658e2235dab438f1a?url=https://app-index.sandstorm.io/packages/a33e26d3b0fa40c658e2235dab438f1a"
  }, 
  "headers": {
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", 
    "Accept-Language": "en-US,en;q=0.5", 
    "Dnt": "1", 
    "Host": "httpbin.org", 
    "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:43.0) Gecko/20100101 Firefox/43.0"
  }, 
  "origin": "72.160.202.127", 
  "url": "https://httpbin.org/get?query=%2Finstall%2Fa33e26d3b0fa40c658e2235dab438f1a%3Furl=https:%2F%2Fapp-index.sandstorm.io%2Fpackages%2Fa33e26d3b0fa40c658e2235dab438f1a"
}

[kentonv]

@sigmavirus24 Right. But how is that exploitable?

To be clear, there are no secrets in that pastebin. The long hex string is the package ID of the app you chose.

[bellaj]

the simple scenario, it could be used in a phishing tentative with a client side attack, the malicious website could be hidden .. i will send you a POC when i get some free time

[kentonv]

@bellaj OK, so this is a potential phishing attack, not CSRF.

The attack goes like this:

• Attacker tells victim to check out some app on the app market, has them click on a link to it.
• Victim clicks "install" to install the app.
• Victim is now installing app to attacker's Sandstorm server, but mistakenly think it's their own server. Because the victim was sent here from the app market instead of directly by the attacker, they place more trust in it.
• Attacker's server prompts victim for some kind of secret, and victim complies, thinking it is their own server asking.

Is that correct?

While I agree that such an attack is possible, there are several mitigating factors:

• The victim would have to ignore the hostname in the address bar.
• For the attacker to make the malicious server look like the victim's server, they'd need to know various details about the victim, such as their name (to display in the upper-right). This means that the attack would have to be spear-phishing (directed at an individual), not a wide net.
• If the user tried to go anywhere in the UI, such as the "apps" or "grains" tab, the ruse would quickly fall over, as the attacker has no way of knowing what should be displayed there.
• Sandstorm currently does not prompt for any secrets during normal operation. For example, we do not use password login. So if the attacker prompted for a password, they would rouse suspicion.

Basically, I do not think this would be a very effective attack.

Normally I would nevertheless fix the issue, but in this case I'm not sure what we can do about it. The ?host= parameter is necessary to allow people to install apps to their own servers. The app market has no way of telling the difference between the user's actual server and an attacker's server.

If someone has a better idea for how to implement our UI, or can identify a more severe possible attack, please do tell.

[sigmavirus24]

Perhaps a better solution would be a trust on first use? In other words, prior to redirecting to http://malicious_website.com/install/a33e26d3b0fa40c658e2235dab438f1a?url=https://app-index.sandstorm.io/packages/a33e26d3b0fa40c658e2235dab438f1a the page could say something like:

Installing {{ app }} to {{ scheme://hostname }}
Do you wish to continue?  [ Yes ] [ Return to apps.sandstorm.io ]
[ ] Always trust in the future
Please remember that you should not be prompted for anything when installing an application to your own server.

This gives users awareness they're being redirected and that they haven't installed something to that server previously. (Obviously this would need to be coupled with a dashboard to allow users to remove hostnames from their trust list.)

[ocdtrekkie]

Eventually, I wouldn't mind my list of Sandstorm servers being tied to my logging into the market (optional, of course). Clicking a link with a different host than expected would, I presume, provide a warning.

[kentonv]

Alternatively, I suppose when you browse to the app store with a new server for the first time, it could pop up a dialog saying:

foo.example.com

Is this your Sandstorm server? [yes] [no]

Once you choose "yes" once, we'd trust it going forward (on that browser; no login needed). We could skip this dialog for Oasis and other known-good hosts.

However, I'm not sure this interstitial would provide much real protection. People would quickly get in the habit of clicking "yes".

[ocdtrekkie]

@kentonv I've seen plenty of users where such interstitials definitely cause them to stop, wait, and ask. Even seemingly innocuous ones. Also bear in mind, most users will never see said interstitial, and the rest will likely see it rarely (or maybe once). Therefore I doubt people will "get in the habit" of clicking yes.

[bellaj]

you could add in the url a hash to check if the host parameter has changed.

i think the host parameter could lead attacker to perform a csrf attack, not just a simple phishing. I will work on this next weekend to check it.

[kentonv]

@bellaj OK, I look forward to seeing what you come up with!

Note that this could be a CSRF problem if we ever POSTed to the host provided, but we don't, we only redirect the user's browser there.

you could add in the url a hash to check if the host parameter has changed.

Sorry, I don't understand this proposal. Why couldn't the hash be forged? Keep in mind that anyone is legitimately allowed to install a Sandstorm server on any hostname they wish.

[zenhack]

A wrinkle re: the claim that sandstorm doesn't currently prompt for secrets: email login. Here's an attack that could give the attacker access to a user's account:

1. Assume we've already gotten as far as redirecting the user to our malicious server, thinking they are going to install an app on their server.
2. Our server presents an email login interface, the same as displayed by sandstorm
3. When the user enters an email address, we copy that email address into the real email login dialog on their sandstorm.
4. The real sandstorm sends an authentication email. Now, one of two things happens:
   1. The user clicks the link, and logs into their sandstorm unharmed. They are confused as to why the app didn't get installed. Our attack fails in this case, but likely without blowing our cover.
   2. The user copies and pastes the authentication code into our malicious server, which then uses it to log in to the user's server as them. We've now MITM'ed the user's session. What's more, I think at this point we could use the original info in the redirect to make it look like the user is installing the app they expected to, to reduce the likelihood of setting off any alarms.

It's still clunky in a lot of ways, but much more serious that previously suggested I think.

[kentonv]

@zenhack Hmm, I think what you describe is actually a more general problem with email login that isn't particularly specific to app market redirects. I might, for example, give you a link to a rocket.chat grain on my personal sandstorm server which I've maliciously modified such that it MITMs the email login flow. Rocket.chat requires login, so you'll likely go ahead and do so, and if you don't carefully look at the email you might not notice that it's from a different host. :/

[zenhack]

Yeah, I think you're right. That's much more serious. One simple way to deal with this is to only have the link, and take out the option to type in an authentication code.

[kentonv]

@zenhack Indeed, although it's sad because in practice I almost always use the code, and the code is actually highly preferable in some cases, e.g. when I'm logging in on desktop but receiving email on my phone...

[zenhack]

Agree, not sure what to do about it though. Could try shortening the URL, but getting rid of the email address itself makes me nervous, and without that even if we made _emailLogin negligibly short it would probably still be burdensome to type the whole URL.