Closed Bug 1431925 Opened 7 years ago Closed 7 years ago

External service interaction (DNS)

Categories

(Websites :: Other, defect)

Product:
Websites
Component:
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: haydar1979, Unassigned)

References

(
URL
)

Details

(Keywords: reporter-external, sec-low, wsec-other, Whiteboard: [reporter-external] [web-bounty-form] [verif?])

Attachments

(1 file)

Firefox Report
50.46 KB, text/html
Details
Hi I am Haydar Sezer Tekeli, Issue details It is possible to induce the application to perform server-side DNS lookups of arbitrary domain names. The payload lnc1eddcyz2xaiezk0ocmbqbr2xulmnadx3ls.burpcollaborator.net was submitted in the HTTP Host header. The application performed a DNS lookup of the specified domain. References. http://blog.portswigger.net/2015/04/introducing-burp-collaborator.html https://portswigger.net/kb/issues/00300200_external-service-interaction-dns PoC. Request. GET / HTTP/1.1 Host: lnc1eddcyz2xaiezk0ocmbqbr2xulmnadx3ls.burpcollaborator.net Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close Response. HTTP/1.0 400 Bad Request Server: AkamaiGHost Mime-Version: 1.0 Content-Type: text/html Content-Length: 206 Expires: Sat, 20 Jan 2018 13:23:49 GMT Date: Sat, 20 Jan 2018 13:23:49 GMT Connection: close <HTML><HEAD> <TITLE>Invalid URL</TITLE> </HEAD><BODY> <H1>Invalid URL</H1> The requested URL "&#91;no&#32;URL&#93;", is invalid.<p> Reference&#32;&#35;9&#46;517f3d5&#46;1516454629&#46;7c558e </BODY></HTML>
Flags: sec-bounty?
Hi Haydar, Can you please elaborate on this issue? I am aware of the external service interaction behaviour/bugs (HTTP/DNS), however there is not enough information in your bug report for me to replicate this particular behaviour. For example, it seems like you are reporting this issue for 'https://detectportal.firefox.com'; what's the exact request you are making to this URL to trigger this behaviour? Can you please refer here: https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/#step-by-step-exploit and provide more details? Thank you.
Note for other web bug bounty members: The bug reporter contacted me privately asking if he could elaborate on this issue in Turkish. If this happens please leave this bug with me.
Attached file Firefox Report —
Firefox Report file
Thank you Haydar. I was able to reproduce this issue. However I am not quite sure if it's a security bug. Server-side DNS lookups are rarely an issue by themselves, they are usually an indication that other server side requests could be performed. However this does not seem to be the case in this instance. The error message comes from an Akamai server, most likely because "detectportal.firefox.com" sits behind Akamai. The DNS query/interaction comes from an IP address which belongs to your ISP's IP block. > $ $ whois 213.243.23.5 > % IANA WHOIS server > % for more information on IANA, visit http://www.iana.org > % This query returned 1 object > % Information related to '213.243.16.0 - 213.243.31.255' > > % Abuse contact for '213.243.16.0 - 213.243.31.255' is 'netadmins@dsmart.com.tr' > > inetnum: 213.243.16.0 - 213.243.31.255 > netname: DOL > descr: Dogan Iletisim Elektronik Servis Hizmetleri A.S. > country: TR What's most likely happening here is an Akamai server is attempting to resolve the value specified as the 'Host' header, using a local ISP's DNS server; however this DNS server is not functioning properly therefore Akamai is returning an error. So this could be a misconfiguration on Akamai. I'll loop in the contact for this website anyway to ensure if this makes sense and to see if anything needs fixing. atoll: Can you please weigh in on this? (Apologies if you are not to correct contact in advance).
Flags: needinfo?(rsoderberg)
Sure. First, I'm going to try to restate this bug into a single question: Q: Is Akamai safely initiating DNS lookups for arbitrary user input? Breaking this down, there are three questions below you'll need answered. If the answer to all of the questions below is "No", then I believe this is a secure practice and we would have no further work to do. # 1) Safely? Does any risk exist to Mozilla and/or Visitors as a result of their automatic actions when serving cached replies for our site? 2) Arbitrary? Does Akamai permit site visits with RFC-invalid Host: headers? Do they refuse to transmit invalid hostname characters in their DNS lookups? Do they only do A/AAAA/PTR lookups, as some MTAs do? 3) User input? Is Akamai's behavior compatible with our organizational goals re: user privacy protection? # I might advance this product's next RRA to 'soon', and evaluate this bug (and the answers to the above questions) in that meeting, so that you can discuss the bug with a concrete example on-hand to consider. If the RRA agrees that this is a risk worth noting, then that decision must propagate to all RRAs for Akamai-cached product. If not, then no further work is necessary, and as a side effect we'll have an up-to-date RRA for the site. The service owner for this site – most likely one of Mozilla's ___Ops divisions – can put you in touch with their Akamai contacts here at Mozilla, if necessary. (The person assigned that responsibility can vary based on the Ops group.)
Flags: needinfo?(rsoderberg) → needinfo?(culucenk)
Thanks atoll. Some very valid points. For what it's worth, I have tried the same scenario against a Mozilla asset that's behind CloudFlare. CloudFlare also reports an DNS error in the response, however a DNS lookup request does not arrive to the host specified in the Host header. ulfr: What's your take on this? Based on the evidence thus far I am fairly convinced that this particular instance is not a bug for "detectportal.firefox.com"; however the behaviour may warrant further investigation with Akamai.
Flags: needinfo?(culucenk) → needinfo?(jvehent)
I agree this is not a bug with detectportal.firefox.com (which, btw, is simply a text file served over http to detect captive portals). If the issue is with akamai/cloudflare, I'd suggest reporting it to them. We're merely users of their services.
Flags: needinfo?(jvehent)
:cag, can you fork off the Akamai conversation task and its results into a separate bug, and report back here when it's concluded?
Flags: needinfo?(culucenk)
Forked another discussion to further investigate this behaviour. When we have a conclusion, I will update this bug.
Flags: needinfo?(culucenk)
As far as I can tell, this issue does not have security implications. Closing as sec-low. Please reopen if necessary.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Keywords: sec-low, wsec-other
Resolution: --- → WONTFIX
Flags: sec-bounty? → sec-bounty-
See Also: → 1463339
Group: websites-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: