Using Security Tools to Compromize a Network
One of our daily tasks is to assess and improve the security of our customers or colleagues. To achieve this use security tools (linked to processes). With the time, we are all building our personal toolbox with our favourite tools. Yesterday, I read an interesting blog article about extracting saved credentials from a compromised Nessus system[1]. This in indeed a nice target for the bad guy! Why?
Such security tools deployed inside a network have interesting characteristics:
- They have credentials stored in configuration files or databases. They just need those credentials to be able to perform their tasks. A vulnerability scanner is a good example. It may have Windows credentials, SSH credentials to connect to the scanned systems and perform a local scan.
- They contain interesting data to build the topology of the network or to discover all the assets (IP addresses, VLANs, remote sites, etc)
- They are allowed to connect to ANY hosts in the network (just because they need to scan the network)
- Their IP addresses might be excluded from the log files (just because they are way too verbose)
The first blog article reminded me other bad stories with security products:
- McAfee ePolicy Orchestrator[2]
- Acunetix web scanner [3]
And the same remains valid also with monitoring tools like Nagios[4].
The security of security/monitoring tools must be addressed like any other regular asset. Access to them must be restricted, logged and they must be installed with least privileges. But hat’s what you already do, right?
[1] https://www.appsecconsulting.com/blog/extracting-saved-credentials-from-a-pwn3d-nessus-system/
[2] https://funoverip.net/2013/06/mcafee-epolicy-0wner-preview/
[3] https://osandamalith.com/2014/04/24/pwning-script-kiddies-acunetix-buffer-overflow/
[4] http://seclists.org/fulldisclosure/2016/Dec/58
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key
Reverse-Engineering Malware: Advanced Code Analysis | Singapore | Nov 18th - Nov 22nd 2024 |
Comments
The phrase that finally did it was "The worst thing that can happen to us is to have our own security tools used against us." That started them thinking about ways that could happen and the consequences.
Anonymous
Jan 7th 2017
7 years ago
One nice stuff I saw about the Nessus, SIEM, NMap and co. tools, is they usually have more access across the Internal networks and also large Internet access to perform security checks toward external devices and sites or when working with 3rd party hosted applications.
Errors or by-pass that are not always acceptable:
- A good ANY/ANY in firewalls, because the scanner has to evaluate the "Target" and not the Internal firewall infrastructure
- No logs activated by the network staff on the firewall policies concerning the scanner to avoid to flood the Firewall or the SIEM during a monthly scan,
- Threat prevention disabled to permit the update of the security tools (full of virus and malware patterns or fake signature ... or Metasploit with borderlines content)
- When it is a software installed on a server, ... there are a lot of tools also installed on the same machine (NMAP, OSSEC, OpenVas, Nikto, Perl, Python, Metasploit ...)
So good to install a Proxy server on that machine (access to the internet with control), or just compromise it because it is the best toolkit to attack other hosts for illegitimate reasons.
And yes "The worst thing that can happen to us is to have our own security tools used against us."
Js
Anonymous
Jan 8th 2017
7 years ago
I agree, Nessus would be an excellent tool to hide behind as well. If you were to time your activity with scheduled scans, your offensive activity would likely be written off as part of a normal scan. Any IDS/IPS type alerts would more than likely ignored. You could run addtional nmap scans or anything else for the most part. I'd steer clear of wandering too far outside of the expected activity from a scan, however. One host with 25K login attempts whereas all the other hosts only had a few hundred would send up flags.
Anonymous
Jan 10th 2017
7 years ago