ssrf bug
Categories
(Core :: Networking: DNS, defect)
Tracking
()
People
(Reporter: xulong, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36
Steps to reproduce:
GET /success.txt HTTP/1.1
Host: detectportal.firefox.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: /
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Cache-Control: no-cache
Pragma: no-cache
Connection: close
host: i4n306v2wcht6vor4yy1oqh3muskgci08nybn.burpcollaborator.net
GET / HTTP/1.1
Host: i4n306v2wcht6vor4yy1oqh3muskgci08nybn.burpcollaborator.net
Pragma: no-cache
Cache-Control: no-cache, no-transform
Connection: close
Actual results:
The Collaborator server received a DNS lookup of type A for the domain name proxy-host.i4n306v2wcht6vor4yy1oqh3muskgci08nybn.burpcollaborator.net. The lookup was received from IP address 173.205.6.157 at 2019-..-05 03:14:18 UTC.
Expected results:
You should review the purpose and intended use of the relevant application functionality, and determine whether the ability to trigger arbitrary external service interactions is intended behavior. If so, you should be aware of the types of attacks that can be performed via this behavior and take appropriate measures. These measures might include blocking network access from the application server to other internal systems, and hardening the application server itself to remove any services available on the local loopback adapter.
If the ability to trigger arbitrary external service interactions is not intended behavior, then you should implement a whitelist of permitted services and hosts, and block any interactions that do not appear on this whitelist.
(In reply to Loong from comment #0)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36
Steps to reproduce:
GET /success.txt HTTP/1.1
Host: detectportal.firefox.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: /
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Cache-Control: no-cache
Pragma: no-cache
Connection: closehost: i4n306v2wcht6vor4yy1oqh3muskgci08nybn.burpcollaborator.net
GET / HTTP/1.1
Host: i4n306v2wcht6vor4yy1oqh3muskgci08nybn.burpcollaborator.net
Pragma: no-cache
Cache-Control: no-cache, no-transform
Connection: close
Actual results:
The Collaborator server received a DNS lookup of type A for the domain name proxy-host.i4n306v2wcht6vor4yy1oqh3muskgci08nybn.burpcollaborator.net. The lookup was received from IP address 173.205.6.157 at 2019-..-05 03:14:18 UTC.
Expected results:
You should review the purpose and intended use of the relevant application functionality, and determine whether the ability to trigger arbitrary external service interactions is intended behavior. If so, you should be aware of the types of attacks that can be performed via this behavior and take appropriate measures. These measures might include blocking network access from the application server to other internal systems, and hardening the application server itself to remove any services available on the local loopback adapter.
If the ability to trigger arbitrary external service interactions is not intended behavior, then you should implement a whitelist of permitted services and hosts, and block any interactions that do not appear on this whitelist.
(In reply to Loong from comment #1)
(In reply to Loong from comment #0)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36
Version 60.7.2, first offered to ESR channel users on June 20, 2019
GET /success.txt HTTP/1.1
Host: detectportal.firefox.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: /
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Cache-Control: no-cache
Pragma: no-cache
Connection: closehost: i4n306v2wcht6vor4yy1oqh3muskgci08nybn.burpcollaborator.net
GET / HTTP/1.1
Host: i4n306v2wcht6vor4yy1oqh3muskgci08nybn.burpcollaborator.net
Pragma: no-cache
Cache-Control: no-cache, no-transform
Connection: closeActual results:
The Collaborator server received a DNS lookup of type A for the domain name proxy-host.i4n306v2wcht6vor4yy1oqh3muskgci08nybn.burpcollaborator.net. The lookup was received from IP address 173.205.6.157 at 2019-..-05 03:14:18 UTC.
Expected results:
You should review the purpose and intended use of the relevant application functionality, and determine whether the ability to trigger arbitrary external service interactions is intended behavior. If so, you should be aware of the types of attacks that can be performed via this behavior and take appropriate measures. These measures might include blocking network access from the application server to other internal systems, and hardening the application server itself to remove any services available on the local loopback adapter.
If the ability to trigger arbitrary external service interactions is not intended behavior, then you should implement a whitelist of permitted services and hosts, and block any interactions that do not appear on this whitelist.
|
||
Comment 3•7 years ago
|
||
Hi @Loong, what can I do for now with this issue is only setting a component, if isn't the right one please fell free to change it. Additionally, please try to re-test this issue in an updated FF version, for example 68.0 and let me know if you have the same results.
Further, someone from dev's team could give us a hand.
Thanks.
|
||
Comment 5•7 years ago
|
||
(In reply to Loong from comment #0)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36
Steps to reproduce:
GET /success.txt HTTP/1.1
Host: detectportal.firefox.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: /
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Cache-Control: no-cache
Pragma: no-cache
Connection: closehost: i4n306v2wcht6vor4yy1oqh3muskgci08nybn.burpcollaborator.net
GET / HTTP/1.1
Host: i4n306v2wcht6vor4yy1oqh3muskgci08nybn.burpcollaborator.net
Pragma: no-cache
Cache-Control: no-cache, no-transform
Connection: close
Sorry, what you pasted is http headers. Please provide steps to reproduce if you have. Thanks.
Actual results:
The Collaborator server received a DNS lookup of type A for the domain name proxy-host.i4n306v2wcht6vor4yy1oqh3muskgci08nybn.burpcollaborator.net. The lookup was received from IP address 173.205.6.157 at 2019-..-05 03:14:18 UTC.
Expected results:
You should review the purpose and intended use of the relevant application functionality, and determine whether the ability to trigger arbitrary external service interactions is intended behavior. If so, you should be aware of the types of attacks that can be performed via this behavior and take appropriate measures. These measures might include blocking network access from the application server to other internal systems, and hardening the application server itself to remove any services available on the local loopback adapter.
If the ability to trigger arbitrary external service interactions is not intended behavior, then you should implement a whitelist of permitted services and hosts, and block any interactions that do not appear on this whitelist.
Could you be more specific about the "external service interactions"? What do you mean "intended behavior"? What type of attacks you think firefox should be aware of?
1.ping detectportal.firefox.com
来自 23.61.194.8 的回复: 字节=32 时间=156ms TTL=52
来自 23.61.194.8 的回复: 字节=32 时间=156ms TTL=52
来自 23.61.194.8 的回复: 字节=32 时间=156ms TTL=52
GET / HTTP/1.1
Host: detectportal.firefox.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Connection: close
Upgrade-Insecure-Requests: 1
Vulnerability point：Host
2.Issue detail
It is possible to induce the application to perform server-side DNS lookups of arbitrary domain names. The payload 1fh6ix0u6p5i00264fa7odiyqpwmkem2cp2dr.burpcollaborator.net was submitted in the HTTP Host header. The application performed a DNS lookup of the specified domain.
3.Collaborator DNS interaction
The Collaborator server received a DNS lookup of type A for the domain name 1fh6ix0u6p5i00264fa7odiyqpwmkem2cp2dr.burpcollaborator.net. The lookup was received from IP address 23.61.194.4 at 2019-..-09 10:59:05 UTC
In cases where DNS-based interactions can be triggered, it is normally possible to trigger interactions using other service types, and these are reported as separate issues. If a payload that specifies a particular service type (e.g. a URL) triggers only a DNS-based interaction, then this strongly indicates that the application attempted to connect using that other service, but was prevented from doing so by egress filters in place at the network layer. The ability to send requests to other systems can allow the vulnerable server to be used as an attack proxy. By submitting suitable payloads, an attacker can cause the application server to attack other systems that it can interact with. This may include public third-party systems, internal systems within the same organization, or services available on the local loopback adapter of the application server itself. Depending on the network architecture, this may expose highly vulnerable internal services that are not otherwise accessible to external attackers.
|
|
||
Comment 7•7 years ago
|
||
(In reply to Loong from comment #6)
1.ping detectportal.firefox.com
来自 23.61.194.8 的回复: 字节=32 时间=156ms TTL=52
来自 23.61.194.8 的回复: 字节=32 时间=156ms TTL=52
来自 23.61.194.8 的回复: 字节=32 时间=156ms TTL=52GET / HTTP/1.1
Host: detectportal.firefox.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Connection: close
Upgrade-Insecure-Requests: 1Vulnerability point：Host
So, you mean somehow the host of captive portal detection request was replaced from detectportal.firefox.com to 1fh6ix0u6p5i00264fa7odiyqpwmkem2cp2dr.burpcollaborator.net? If yes, how did you do that? By changing the value of "captivedetect.canonicalURL"?
2.Issue detail
It is possible to induce the application to perform server-side DNS lookups of arbitrary domain names. The payload 1fh6ix0u6p5i00264fa7odiyqpwmkem2cp2dr.burpcollaborator.net was submitted in the HTTP Host header. The application performed a DNS lookup of the specified domain.
So, the problem is that why we have this Host header. I have no idea where 1fh6ix0u6p5i00264fa7odiyqpwmkem2cp2dr.burpcollaborator.net is coming from. Maybe you can answer this.
1fh6ix0u6p5i00264fa7odiyqpwmkem2cp2dr.burpcollaborator.net form BURP。
It is a vulnerability verification tool。(Burp--Burp Collaborator client)
"Burp Collaborator client is a tool for making use of Burp Collaborator during manual testing. You can use the Collaborator client to generate payloads for use in manual testing, and poll the Collaborator server for any network interactions that result from using those payloads."
Reference link：
https://portswigger.net/kb/issues/00300200_external-service-interaction-dns
|
|
||
Comment 9•7 years ago
|
||
It's still unclear to me about the steps to reproduce and why do you consider doing a DNS lookup to fh6ix0u6p5i00264fa7odiyqpwmkem2cp2dr.burpcollaborator.net is a bug of firefox. I think the vulnerability you found should belong to a web application, not firefox.
Hence, this bug should be invalid.
Description
•