Brightcloud IP Reputation Violations

[mrjlturner]

Gang,

Can anyone else confirm the hidden interface for npm on /aaa9? My installation had this, and was constantly being found by Brightcloud as a risk. Here's the verbiage:
Our scanners detected proxy activities from this IP address. These threats have been detected by our own sensors. Because of this, we are not able to provide the destination IP addresses or additional details about the detection. However, I can provide a sample of some URLs hosted the IP address which may have contributed to the listing: /aaa9

This was happening every few weeks. So, I ran a test today, and sure enough when I put that directory in, I was redirected to the administrative console interface. No bueno! So, I've added a "dead link" location for that URI and now it's closed. How disturbing though!

If anyone else can confirm, I'd appreciate it!

Thanks,
mrjlturner

[mrjlturner]

FYI I have confirmed this on two instances of NPM that I have running. For now, I have added a directory forward to 0.0.0.0:443 to "disable" this "hidden" directory. I'm hoping that someone can explain why it is there and what it is for?

[jc21]

I really have no clue what this question is all about. There is no such "hidden interface" in this codebase. If you search the codebase you won't find anything with aaa9 and in my own running instances, when I navigate to /aaa9 on any host that I have including the admin site, I get what I expect: a 404.

I would highly recommend bringing up a clean NPM instance, without any hosts defined and verifying this yourself. I suspect that your own hosts and possible custom nginx configuration has something causing this false positive.

I don't usually publish my own running instance for security reasons, but to debunk such claims I'm going to as proof.

• https://gateway.jc21.supernerd.pro - this is my NPM instance
• https://ci.nginxproxymanager.com - this is a host running on that NPM instance

I do not have any custom nginx config and I don't use directory/path definitions in any of my hosts.

[mrjlturner]

So when I browse to https://gateway.jc21.supernerd.pro/aaa9 with a private window on my browser, the browser redirects to https://gateway.jc21.supernerd.pro/login. It seems that almost any invalid uri does a redirect rather than returning a 404. This is the same behavior that I'm seeing with my instances and this is the directory that bright cloud has somehow picked up as being used for proxying activities that bring threat status through their service. I'm not trying to say that the project has something nefarious in it. I'm simply seeing something that is being called a threat by a security company and I can't find a reason for the functionality even existing. I wanted to put it out there in case there is a vulnerability in it somewhere that is being exploited so that we can collectively find a fix for it.

…

On Thu, Jun 23, 2022, 6:58 PM jc21 ***@***.***> wrote: I really have no clue what this question is all about. There is no such "hidden interface" in this codebase. If you search the codebase you won't find anything with aaa9 and in my own running instances, when I navigate to /aaa9 on any host that I have including the admin site, I get what I expect: a 404. I would highly recommend bringing up a clean NPM instance, without any hosts defined and verifying this yourself. I suspect that your own hosts and possible custom nginx configuration has something causing this false positive. I don't usually publish my own running instance for security reasons, but to debunk such claims I'm going to as proof. - https://gateway.jc21.supernerd.pro - this is my NPM instance - https://ci.nginxproxymanager.com - this is a host running on that NPM instance I do not have any custom nginx config and I don't use directory/path definitions in any of my hosts. — Reply to this email directly, view it on GitHub <#2127 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APDMTCEXKZHRAOETIGN2OODVQTT2RANCNFSM5ZRKR54A> . You are receiving this because you authored the thread.Message ID: <NginxProxyManager/nginx-proxy-manager/repo-discussions/2127/comments/3013914 @github.com>

[jc21]

Sorry, I mispoke about the 404 on the admin host. The admin site is a single page app. For literally any URL (except assets) it will return 200 with the exact same HTML and JS, then once the JS app is loaded it will determine if you are logged in or not, then change the address bar url to /login if not. This is by design.

It seems that this threat from brightcloud is merely a red herring. Why it's picked this particular URL is a mystery. Also a mystery why it's a threat at all considering the app still imposes an auth mechanism on literally any URL path.

My own gateway is categorized as "Proxy Avoidance and Anonymizers" and has a High Risk reputation, despite it being a mostly unused and unlisted site. It's unclear what the determining factors are, however I'm taking their opinions with a grain of salt.

You can request a change of category with Brightcloud should you require it.

[mrjlturner]

Gotcha. Yeah it hits me every few weeks and causes issues as I utilize several services that use brightcloud as front line security for their service, so I get blocked because I'm coming from a flagged IP. Thanks for the confirmation on how you've got the admin interface configured to operate. I'll probably just go the way you have gone and unpublish the admin interface. Hopefully that will resolve the issue permanently. Cheers!

…

On Thu, Jun 23, 2022, 11:12 PM jc21 ***@***.***> wrote: Sorry, I mispoke about the 404 on the admin host. The admin site is a single page app. For literally any URL (except assets) it will return 200 with the exact same HTML and JS, then once the JS app is loaded it will determine if you are logged in or not, then change the address bar url to /login if not. This is by design. It seems that this threat from brightcloud is merely a red herring. Why it's picked this particular URL is a mystery. Also a mystery why it's a threat at all considering the app still imposes an auth mechanism on literally any URL path. My own gateway is categorized as "Proxy Avoidance and Anonymizers" and has a High Risk reputation, despite it being a mostly unused and unlisted site. It's unclear what the determining factors are, however I'm taking their opinions with a grain of salt. You can request a change of category with Brightcloud should you require it. — Reply to this email directly, view it on GitHub <#2127 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APDMTCDTUAZ2O72UITWNTTTVQURSNANCNFSM5ZRKR54A> . You are receiving this because you authored the thread.Message ID: <NginxProxyManager/nginx-proxy-manager/repo-discussions/2127/comments/3014767 @github.com>

[nfriedly]

Apparently brightcloud flags anything with the word "proxy" anywhere in the page, including the default landing page for Nginx Proxy Manager and, presumably, the login page. This is an email I received from their support today:

My login page is not exposed to the internet, but I switched my NPM instance to show a 404 page for unrecognized domains. I also sent a reply explaining that this was not the kind of proxy that their customers care about.