Ntop security breach?

[gorlilla]

I am running pfsense 2.4.4 and had the ntop package enabled through package manager ( ntopng-3.6.d201800910,1).

I have been experiencing issues over the last couple of days with logging into ntop (user credentials can be submitted; however the page will just reload instead of moving forward). I had attributed this to a strong password using symbols based on some details in an older git issue, so reset the password through pfsense panel this time using a slightly less strong, strong password. Everything appeared to be ok at that point.

Today, I was back to the same problem of looping logins and was scratching my head since i thought i had fixed my bad password issue.

I am also in the process of configuring some suricata rulesets so have been monitoring alerts like a hawk trying to prune the rules. I noticed the following alert:

1/17/2018
22:17:26	1	TCP	Potential Corporate Privacy Violation	***.***.***.***
  	51321	178.62.197.130
  	80	1:2006380
    	ET POLICY Outgoing Basic Auth Base64 HTTP Password detected unencrypted

That rule means that credentials were passed from INSIDE my network to an OUTSIDE resource and is very unlikely a false-positive.

It seems that my credentials for ntop were transmitted in plain text to ntop -- which is likely the reason it failed. The IP responded briefly on http 80 with a 301 redirect to https presenting what appears to be a valid LetsEncrypt certificate issued to ntop.cloud.org hosted through digitalocean.

curl -i 178.62.197.130
HTTP/1.1 301 Moved Permanently
Date: Sun, 18 Nov 2018 04:13:51 GMT
Server: Apache
Location: https://178.62.197.130/
Content-Length: 0
Content-Type: text/html; charset=UTF-8

I cannot think of any reason that ntop would pass my credentials to their cloud service, let alone unencrypted.

anyone have input? I have currently uninstalled the ntop package until i have more time to look into this.

[jimp]

I have not seen that happen here but are you sure it passed on your credentials? IIRC the ntopng process will try to fetch some external resources and it's entirely possible they have those password protected using some other stored credentials.

You might install it again and capture outbound traffic going to that server, then load it up in wireshark and see what it's doing.

It probably is not doing anything nefarious, but a packet capture would tell you that definitively.