Need Help or Guidance on Potential Bug

I believe I may have stumbled upon something juicy, I just don’t know how to further exploit. When going to “subdomain.domain.com”, if you place a “.” at the end of the domain, I noticed it redirects you to “otherdomain.com”. I tried various methods to redirect it to a domain of my choosing, but all attempts failed. I continued playing around with the request in Burp and noticed something interesting:

GET /embeddable_blip?type=userAction&data=largebase64string HTTP/1.1
Host: wwwsubdomaindomain.zendesk.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: /
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://subdomain.domain.com/
Origin: https://subdomain.domain.com
Connection: close

When you decode the base64 string in the “data=” parameter, its serialized data as follows:

{“channel”:“web_widget”,“userAction”:{“category”:“api”,“action”:"$zopim.livechat.departments.setVisitorDepartment",“label”:null,“value”:{“args”:“Domain”}},“timestamp”:“2019-05-16T01:52:51.920Z”,“url”:“https://www.subdomain.domain.com/”}

This is definitely over my head as a beginner and I honestly don’t know if this is normal behavior. If so, feel free to laugh :slight_smile: I tried messing with the “url” and “args” options in the serialized data, re-encoding and replaying the request, but nothing is happening. I thought of Open Redirects and possibly RCE. I think I just may have thought in my mind that there may be something juicy, but I’m honestly not sure at this point. Either way, thank you for any points in the right direction!

1 Like

I am fairly new to hunting also - but perhaps trying a X-forward here?

Host: domain.com
X-Forwarded-Host: domainofyourchoice.com

Keep trying! It really looks like you’re on to something here.

1 Like

@at0mix, awesome, thank you for the response! I’ll try that later today. Hopefully something comes from this potential bug. Good luck in your journey!

Hello,
[This forum won’t allow me to put more than 2 things it considers links in the post, which makes it really hard to talk about DNS. :slight_smile: To get around this, I’ve changed the period in the domains to hyphens. so example-com really means example"dot"com. Sorry if this makes it hard to parse.]

I 've been puzzled by this myself on occasion. I think what you are seeing has to do with how DNS makes recursive queries. As a first step, check your /etc/resolv.conf file and I think you will see “search otherdomain-com” in there.

I think this issue is hidden from us most of the time because the various resolvers such as dig and nslookup both try to make a guess that when you say example-com you really mean example-com. with the period. So when you make a query without the period (which most of us do pretty much always), the first request assumes the dot but in some cases, if it can’t find the domain, it tries to recursively search through the search list in /etc/resolv.conf.

This explanation is pretty good:

Also, if you start nslookup, type “set debug,” and then look at all the output for the different queries, you’ll see how, in some cases, whatever is in /etc/resolv.conf’s searchlist will appear in the query. On my system, I could create what you saw by looking up “unlikelytoexist” with no period. But when I looked up unlikelytoexist. with the period, it correctly went directly to the root name servers and didn’t exhibit the behavior you describe.

The other stuff you saw is just an artifact of all this, I believe. I’m not saying the data parameter isn’t worth poking at some more–just that the contents seem to be reasonable in this context. :slight_smile:

Hope that all makes sense!

Da

1 Like

Hello @Da1, thank you very much for the response! I wish I had more time to look at bugs, I really think I’m onto something, but it’s extremely discouraging when you aren’t finding bugs. I took a break to clear my head, but I just wish I had people to connect with like on Discord or something

Hi @pisteuo.

I guess that request you published was made by the Zendesk SDK. So, it may make sense that they use the value of Referer for their own functionality. Unless I misunderstood, it seems working as expected.
About the dot at the end of a domain, that seems like an open redirect. If you make a request to http://www.victim.com. and are redirected to http://wwwvictim.com or something like that, it may be an open redirect. Domains with a dot at the end are valid, but applications may treat them differently. For instance, compare the result from https://www.google.com./ and https://www.facebook.com./. Facebook seems to redirect the user to https://www.facebook.com/ using Javascript, while Google doesn’t care.

Good luck with your hunting!

Bugcrowd created a Discord community a few weeks ago: https://discordapp.com/invite/YNwkNKr

2 Likes

@stefanofinding Thank you for the reply! Right, I was testing the . with other domains and I did notice that the applications handled them differently. I’m still asking the dumb questions as I’m so new lol. Also, much appreciated for posting the Bugcrowd Discord! I actually just added that. Thanks again!

You are welcome :slightly_smiling_face: