DNS lookout vulnerability

Hello. We were performing burp security test on lucee application and we are not sure how to fix this vulnerability. Does anybody have an idea?

Issue detail

It is possible to induce the application to perform server-side DNS lookups of arbitrary domain names.

The payload gwguxkwie3en9tnimomd2l67cyir6hualybl19q.burpcollaborator.net:443 was submitted in the HTTP Request-Line of a CONNECT request.

The application performed a DNS lookup of the specified domain.


CONNECT gwguxkwie3en9tnimomd2l67cyir6hualybl19q.burpcollaborator.net:443 HTTP/1.1
Pragma: no-cache
Cache-Control: no-cache, no-transform
Connection: close


HTTP/1.0 200 Connection Established
Proxy-agent: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1k

OS: Linux (4.18.0-348.20.1.el8_5.x86_64) 64bit
Java Version: 11.0.15 (Red Hat, Inc.) 64bit
Tomcat Version: Apache Tomcat/9.0.78
Lucee Version:

Hi, just for my understanding… What is what you want exactly? Should cfhttp block such domains by default? If this is what you are expecting, I wouldn’t want it at all, because:

  1. It’s an DNS issue. Thus this should be treated treated at another level (at DNS itself, a firewall or anywhere else), but not cfhttp.
  2. You are giving control of cfhttp away.

For anyone who does cfhttp in a mass manner, would rather do it with an alternative that is not implemented in cfhttp. I’d rather use a tool that looksfor whitelisted/blacklisted/registered domains before performing cfhttp or any type of request.

1 Like

You have hostnamelookups enabled?

It should be off, unless you explicitly need it


HostnameLookups Off

For more information, here’s an article regarding the Burp Suite extension that is being used.

Is the problem 1) that a DNS lookup is occurring or 2) that the DNS lookup is using static source ports?

DNS-wise, what is your OS (& Java) configured to use when resolving host names?

… sometimes web applications are using large public DNS resolvers like Google, Cloudflare or Cisco, which are generally more secure and most likely not vulnerable. If you seem to have found a vulnerability in one of them, it’s most likely a false positive!

1 Like

That - in and of itself - is not any kind of vulnerability and shouldn’t be treated like one. You can’t even begin to send email to a user supplied email address without performing a dns lookup and doing that does not make any application insecure.

You might have a dns resolver that is insecure or your application might implement an insecure security model, but merely doing the lookup is not an indication of any kind of problem.

1 Like

As I uderstand, that is all about DNS-Cache Poisioning and similar attack vectors…Thus, it should be addressed to the team in charge of the DNS Infrastructure of your environement. The Kaminsky Attack is pretty old and sent a a strong message to DNS infrastructure maintainers around the world. If you setup an DNS IP in your network interface, make sure it comes from a reliable source and watch out to keep your servers clean from anything that might interfere your OS DNS queries.

You may be overlooking a critical issue here: it appears that your Apache server is configured to allow forward proxy functionality, specifically through the CONNECT method. When setting up Apache for your Lucee application, it should be configured as a reverse proxy. However, it seems that you have inadvertently enabled the forward proxy mode, akin to Squid. Consequently, any client (at least the host running Burp) can utilize your web server as a TCP proxy to access any target. In the worst-case scenario, this capability could enable an attacker to establish connections to your internal infrastructure, such as databases or private applications. This is likely not your intended configuration.

I recommend thoroughly reviewing your Apache HTTP Server configuration files. Specifically, locate the ProxyRequests directive and ensure that it is disabled, as it is unnecessary for serving a Lucee application.

1 Like

Thank you. If Apache is set up as reverse proxy, can we use access=“remote” attribute of function?

Sure, the reverse proxy mode purpose is exactly that: to provide the outside world access to your application, including your lucee function with access=“remote”

1 Like