5 ms·

Can someone explain the redirect/cookie-stealing part of this? I read through the post explaining request smuggling, and then re-read their exploit description,

Can someone explain the redirect/cookie-stealing part of this? I read through the post explaining request smuggling, and then re-read their exploit description, and the request smuggling part all makes sense. However, I don't fully understand the significance of the 301 in relation to the browser sending the attacker's server the cookie with the request. If the back-end server is already proxying whatever request it receives from the front-end proxy server, why was it necessary to first get it to redirect an HTTP 1.1 header to an https request? The only thing I could think of was that maybe it has something to do with getting the unencrypted cookie, but according to their description, the forwarded request with the cookie doesn't happen until after the redirect to https anyway. I know I'm missing something obvious here.

tptacek 7y ago
What's subtle is that the middlebox is being tricked into parsing the body of an HTTP request as the envelope, or vice versa. The requests hitting the backend are being scrambled. The browser is doing what it can to ensure cookies only go to the right domain, but the servers are chopping those careful requests up and sending them to random places.
- jorams 7y ago
  > the servers are chopping those careful requests up and sending them to random places. I understand that the backend is parsing different requests than the frontend, but I don't see how the cookies ever get sent to the attacker's domain. I understand three requests as moving like this: 1. attacker -> frontend -> backend (partially) -> frontend -> attacker 2. victim -> frontend -> backend (including a bit of 1) -> frontend -> victim 3. (after 301) victim -> malicious server The second request results in a 301, causing the victim's client to make a new request to the target of the 301. This new request does not include cookies, because it is to a different domain. What am I misunderstanding? When do the cookies get sent to the malicious server?
  - tptacek 7y ago
    Alongside a legitimate request with cookies, there is queued an evil request that uses mismatched Content-Length and chunked encoding headers to graft the body of the evil request to the envelope of the legitimate request. The evil body becomes the envelope for the entire legitimate request, and the evil envelope generates the redirect. Skip down to the "Explanation of malicious request" section.
    - jorams 7y ago
      I get that the evil body essentially gets prefixed to the legitimate request, making the server generate the redirect, but this redirect is returned to the victim. The victim then makes a request to the malicious server, and this request should not contain cookies because the origin is different. How do the cookies get to the attacker?
    - JangoSteve 7y ago
      All of your explanation (which is appreciated) just further describes the request smuggling, not how that ends up sending the slack cookies to the hackers server. If you take all of this together, it's all leading to Slack's back-end server returning to the user's client a 301 response that tells the user's browser to send a new request to the hacker's domain. However, when the browser does this, it's to a different domain, so typically the slack cookies would not get sent with that request, unless I'm missing something. The "Explanation of malicious request" section doesn't explain this, either. All it explains is that all this effort was to get Slack's server to send a 301 response to the user's browser pointing to the hacker's server, but then it glosses over any information about how the cookies are getting sent with a single sentence, "and all cookies (including 'd') get redirected there too.... :(" My question is, how? Is something going on where Slack's back-end servers are explicitly setting response headers that allow their cookies to be sent to the hacker's domain? Is there some additional vulnerability that's allowing the browser to send the cookie across domains on a 301 redirect?
      - justicz 7y ago
        If you zoom in on the last image in the report, you see that the victim's client is not a web browser, but Slack's Electron-based client. Perhaps that client is willing to send Slack cookies cross-domain after a redirect for an auth'd request? Edit: looks like terom above me had the same idea before I did
- bawolff 7y ago
  Are you're saying its the slack's frontend server that is processing the 301, and not the user's web browser? And that slack's front-end server is configured as such that when it gets a 301 it just resends the entire request (including all headers) to the redirect destination? Edit: this seems likely to not be what he was saying and also not the case.
kbenson 7y ago
The hackerone write up which this submission points to actually goes into explicit detail on what happens step by step, along with nice infographics. The TL;DR is that you can make the front-end see something like GET /my/supplied/url\nX:X at the end of your request, but the back-end see it as the beginning of the next request, (and the X:X turns the real GET/POST whatever info a custom header of X:XGET /real/request/url), and Slack returns that request with cookies for that person, but to a domain controlled by you when it comes back. The diagrams included in the post and the accompanying text do a better job of explaining it than I am, I think.
- bawolff 7y ago
  I'm also similarly confused. The post explains request smuggling really well, but doesn't really explain how that equals getting the victim's cookies. This is my understanding of the bug: * Attacker sends malformed request to slack servers. Request gets split in two. First part results in something sent back to attacker, next part of request is treated as a prefix to the next legit (victim's) http request made * Slack backend server responds to victim's request treating it as having part of the attacker's request prefixed. The merged request results in a 301 http redirect response, redirecting the victim to an attacker controlled domain. * Victim's browser gets the 301, and follows the redirect. When following the redirect, the cookie header is somehow sent to the attacker's site <-- Part i don't understand here I don't understand why the victim's browser would send the cookie header when following a redirect to a different domain. I don't understand how causing the victim to follow a cross-domain redirect would allow the attacker to extract the victim's cookie.
  - JangoSteve 7y ago
    Yes, this was precisely my question. I agree with you that the post does a great job of explaining the how request smuggling works, and how they used it to trick Slack's server into responding to the user's client with a 301 redirect to the hacker's server. But then, when they got to the part where the cookies are sent, they just said, "and the cookies are sent" with no further explanation. That's the part I'm stuck on. Is there some browser behavior I'm not remembering where it sends sensitive cookies across domains just because one redirected the browser to the other?
terom 7y ago
The collab_2.png screenshot shows `User-Agent: ... Slack/4.1.2 ... Electron/6.0.10 ...`, so it's their own desktop app doing the https://slackb.com/.. https://slackb.com/... HTTP 301 -> https://*.burpcollaborator.com https://*.burpcollaborator.com request. Perhaps their client implements its own quirky redirect-following, which keeps the the original `Cookie: ...` headers in the redirected request? I find it hard to believe that any browser would keep the original `Cookie: ...` headers in a redirected request to a different origin.
- londons_explore 7y ago
  Some proxies follow redirects... It enables devs to do things like "redirect request to the old server", and the client never needs to know (which is important for maintaining compatibility with an old api) In that case, I'd expect all cookies etc. to be forwarded.
- JangoSteve 7y ago
  Interesting! That's definitely something I missed, thank you. I still wouldn't expect an Electron app to subvert basic browser sandboxing by default, particularly where they wouldn't have expected to need to redirect users to other domains with cookies intact. It seems like they'd need to go out of their way to enable that. I wonder if it has to do with the sign-in tokens they send or otherwise allowing the user to move between the browser and the app within their account. For example, when you're in the app and click "Manage Users" and it sends you to a management dashboard in the browser. or when you click a link with an auth token in the browser and it launches you into the app.

tptacek 7y ago

What's subtle is that the middlebox is being tricked into parsing the body of an HTTP request as the envelope, or vice versa. The requests hitting the backend are being scrambled. The browser is doing what it can to ensure cookies only go to the right domain, but the servers are chopping those careful requests up and sending them to random places.

jorams 7y ago
> the servers are chopping those careful requests up and sending them to random places. I understand that the backend is parsing different requests than the frontend, but I don't see how the cookies ever get sent to the attacker's domain. I understand three requests as moving like this: 1. attacker -> frontend -> backend (partially) -> frontend -> attacker 2. victim -> frontend -> backend (including a bit of 1) -> frontend -> victim 3. (after 301) victim -> malicious server The second request results in a 301, causing the victim's client to make a new request to the target of the 301. This new request does not include cookies, because it is to a different domain. What am I misunderstanding? When do the cookies get sent to the malicious server?
- tptacek 7y ago
  Alongside a legitimate request with cookies, there is queued an evil request that uses mismatched Content-Length and chunked encoding headers to graft the body of the evil request to the envelope of the legitimate request. The evil body becomes the envelope for the entire legitimate request, and the evil envelope generates the redirect. Skip down to the "Explanation of malicious request" section.
  - jorams 7y ago
    I get that the evil body essentially gets prefixed to the legitimate request, making the server generate the redirect, but this redirect is returned to the victim. The victim then makes a request to the malicious server, and this request should not contain cookies because the origin is different. How do the cookies get to the attacker?
  - JangoSteve 7y ago
    All of your explanation (which is appreciated) just further describes the request smuggling, not how that ends up sending the slack cookies to the hackers server. If you take all of this together, it's all leading to Slack's back-end server returning to the user's client a 301 response that tells the user's browser to send a new request to the hacker's domain. However, when the browser does this, it's to a different domain, so typically the slack cookies would not get sent with that request, unless I'm missing something. The "Explanation of malicious request" section doesn't explain this, either. All it explains is that all this effort was to get Slack's server to send a 301 response to the user's browser pointing to the hacker's server, but then it glosses over any information about how the cookies are getting sent with a single sentence, "and all cookies (including 'd') get redirected there too.... :(" My question is, how? Is something going on where Slack's back-end servers are explicitly setting response headers that allow their cookies to be sent to the hacker's domain? Is there some additional vulnerability that's allowing the browser to send the cookie across domains on a 301 redirect?
    - justicz 7y ago
      If you zoom in on the last image in the report, you see that the victim's client is not a web browser, but Slack's Electron-based client. Perhaps that client is willing to send Slack cookies cross-domain after a redirect for an auth'd request? Edit: looks like terom above me had the same idea before I did
bawolff 7y ago
Are you're saying its the slack's frontend server that is processing the 301, and not the user's web browser? And that slack's front-end server is configured as such that when it gets a 301 it just resends the entire request (including all headers) to the redirect destination? Edit: this seems likely to not be what he was saying and also not the case.

kbenson 7y ago

The hackerone write up which this submission points to actually goes into explicit detail on what happens step by step, along with nice infographics. The TL;DR is that you can make the front-end see something like GET /my/supplied/url\nX:X at the end of your request, but the back-end see it as the beginning of the next request, (and the X:X turns the real GET/POST whatever info a custom header of X:XGET /real/request/url), and Slack returns that request with cookies for that person, but to a domain controlled by you when it comes back. The diagrams included in the post and the accompanying text do a better job of explaining it than I am, I think.

bawolff 7y ago
I'm also similarly confused. The post explains request smuggling really well, but doesn't really explain how that equals getting the victim's cookies. This is my understanding of the bug: * Attacker sends malformed request to slack servers. Request gets split in two. First part results in something sent back to attacker, next part of request is treated as a prefix to the next legit (victim's) http request made * Slack backend server responds to victim's request treating it as having part of the attacker's request prefixed. The merged request results in a 301 http redirect response, redirecting the victim to an attacker controlled domain. * Victim's browser gets the 301, and follows the redirect. When following the redirect, the cookie header is somehow sent to the attacker's site <-- Part i don't understand here I don't understand why the victim's browser would send the cookie header when following a redirect to a different domain. I don't understand how causing the victim to follow a cross-domain redirect would allow the attacker to extract the victim's cookie.
- JangoSteve 7y ago
  Yes, this was precisely my question. I agree with you that the post does a great job of explaining the how request smuggling works, and how they used it to trick Slack's server into responding to the user's client with a 301 redirect to the hacker's server. But then, when they got to the part where the cookies are sent, they just said, "and the cookies are sent" with no further explanation. That's the part I'm stuck on. Is there some browser behavior I'm not remembering where it sends sensitive cookies across domains just because one redirected the browser to the other?

terom 7y ago

The collab_2.png screenshot shows `User-Agent: ... Slack/4.1.2 ... Electron/6.0.10 ...`, so it's their own desktop app doing the https://slackb.com/.. https://slackb.com/... HTTP 301 -> https://*.burpcollaborator.com https://*.burpcollaborator.com request. Perhaps their client implements its own quirky redirect-following, which keeps the the original `Cookie: ...` headers in the redirected request? I find it hard to believe that any browser would keep the original `Cookie: ...` headers in a redirected request to a different origin.

londons_explore 7y ago
Some proxies follow redirects... It enables devs to do things like "redirect request to the old server", and the client never needs to know (which is important for maintaining compatibility with an old api) In that case, I'd expect all cookies etc. to be forwarded.
JangoSteve 7y ago
Interesting! That's definitely something I missed, thank you. I still wouldn't expect an Electron app to subvert basic browser sandboxing by default, particularly where they wouldn't have expected to need to redirect users to other domains with cookies intact. It seems like they'd need to go out of their way to enable that. I wonder if it has to do with the sign-in tokens they send or otherwise allowing the user to move between the browser and the app within their account. For example, when you're in the app and click "Manage Users" and it sends you to a management dashboard in the browser. or when you click a link with an auth token in the browser and it launches you into the app.