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:
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.
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.
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!
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.
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.
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”