Using Security Tools to Compromize a Network

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 I will be teaching next: Reverse-Engineering Malware: Malware Analysis Tools and Techniques - SANS London September 2020	Xme 537 Posts ISC Handler Jan 7th 2017
Subscribe	Jan 7th 2017 3 years ago
When we were converting from coax security cameras to IP cameras I was able to get the physical security folks to be more receptive to the IT security group than to their vendor by giving them a few examples of how security cameras were compromised in order to commit fraud. There are a couple of good casino examples floating around. In one case the crooks used the hi-def cameras to view the cards of other players and then relayed that information to their person playing the high-stakes game. 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
Quote	Jan 7th 2017 3 years ago
Thanks for the article Xavier. 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	k4l4m4r1s 7 Posts
Quote	Jan 8th 2017 3 years ago
I've seen admin level passwords were stored in plain text in config files in home directories. I'm horrified every time I see things like this. It is hardly surprising when a pen tester can work their way through the network. Pidgin was used for chat within one company for whom I worked. Your user password was stored in plain text if you let pidgin retain it. These users had elevated privileges in many cases. There are still numerous services/tools I encounter that require user/password storage, thus providing avenues into systems. I encounter them constantly. 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.	devwatchdog 9 Posts
Quote	Jan 10th 2017 3 years ago

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

I will be teaching next: Reverse-Engineering Malware: Malware Analysis Tools and Techniques - SANS London September 2020

Xme

537 Posts
ISC Handler

Jan 7th 2017

When we were converting from coax security cameras to IP cameras I was able to get the physical security folks to be more receptive to the IT security group than to their vendor by giving them a few examples of how security cameras were compromised in order to commit fraud. There are a couple of good casino examples floating around. In one case the crooks used the hi-def cameras to view the cards of other players and then relayed that information to their person playing the high-stakes game.

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

Thanks for the article Xavier.

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

k4l4m4r1s

7 Posts

I've seen admin level passwords were stored in plain text in config files in home directories. I'm horrified every time I see things like this. It is hardly surprising when a pen tester can work their way through the network. Pidgin was used for chat within one company for whom I worked. Your user password was stored in plain text if you let pidgin retain it. These users had elevated privileges in many cases. There are still numerous services/tools I encounter that require user/password storage, thus providing avenues into systems. I encounter them constantly.

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.

devwatchdog

9 Posts