Ntop security breach?
gorlilla last edited by
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 220.127.116.11 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 18.104.22.168 HTTP/1.1 301 Moved Permanently Date: Sun, 18 Nov 2018 04:13:51 GMT Server: Apache Location: https://22.214.171.124/ 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.
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.