Introducing Prometheus

A few years back I created a simple Ruby script that would read a firewall configuration and create a list of ACL tables. This was part of a larger project used to automate the writing of audit reports. Eventually, I decided to make this a standalone script that would read configuration files from multiple firewalls and produce a nice HTML report, which includes a list of vulnerabilities as well as an overview of the configuration. I am proud to say that Prometheus is finally ready.

Prometheus is intended help system administrators, auditors, and information security consultants easily review firewall configuration files to identify vulnerabilities in the access control entries (rules). Prometheus also checks for vulnerabilities in the remote administration configuration. Eventually, Prometheus will parse more firewalls, check for more vulnerabilities, and will provide an overview of larger portions of the firewall configuration.

If you would like to check out Prometheus you can find it at https://github.com/averagesecurityguy/prometheus.

Five Steps to Improve Internal Network Security

This is the slide deck for my upcoming presentation at the Chattanooga Information Security Professionals meeting.

Pentesting a Small Company

It's been a month since my last blog post. Usually I don't wait so long between posts but life has been busy with work and personal stuff. Staying busy doesn't give me much time to think but now that things have calmed down I want to write about something that has troubled me for a while. How do you pentest a small company? Well the immediate answer is you pentest them the same way as any other company, but I'm not sure. Before I get into the details let me define a small company. The typical small company I pentest has fewer than 100 internal devices, five to ten external IP addresses and maybe 30 to 40 employees.

A typical pentest relies on finding and exploiting a few vulnerabilities in a large data set. When the data set is significantly reduced as with a small company the job becomes much harder. So my struggle is this, if I perform a pentest on small company and I am not successful at penetrating the network have I failed as a pentester or has the company succeeded in their security program? Does the answer change if the company doesn't have a security program? My fear is that someone with a better skill set would have found the vulnerability I missed and that vulnerability might allow for a complete compromise of the network. So the question is this, as a pentester, how do you know when you have done enough? At what point can you say, "Even though I didn't compromise the network I am satisfied with the state of the client's information security?"

My typical small company pentest consists of the following:

• Identify employee names and email addresses for use in bruteforce attacks.
• Build a password list based on employee names, company names, and keywords associated with the company.
• Scan the network for open ports and services.
• Review all services for vulnerabilities, either with a scanner or manually.
• Exploit vulnerabilities if possible.
• Conduct password attacks on appropriate services.

If I am still unable to break into the network after doing these things, I want to feel comfortable with the security posture of the client but I can't help but feel like I'm missing something. So tell me what am I missing? What else can I do to ensure my clients are getting a thorough test and to ensure I can feel comfortable with the client's security posture?

Feedback

@ITSecurity posted the following on twitter, "You ask, "when can you say, even though I didn't compromise the client I'm satisfied with the state of the security?" I think you take a logic leap in trying to make that determination. It's really up to your client to decide if they're satisfied with their security based on your report. In my mind you are there to help them make an informed decision by demonstrating a risk within the agreed upon parameters."

I had not thought about the problem from this perspective. The truth is, I am restricted by the parameters placed on me by the client. If I am diligent to do all that I can within the parameters, focusing particularly on common attack methods, then my client can have some assurance that their security posture is sound. To some degree, it is up to the client to know what they want tested and to expand the parameters appropriately. It is also up to us as pentesters to show the client ways they can expand the parameters to get a more thorough test.

Security Breakers vs Fixers

This is a response to RyanKo's blog post "Will the ‘real’ IT security researcher please stand up?" posted at hp.com. The gist of the article is that there are too many security researchers who do nothing but break things and offer no methods for fixing them. He illustrates the problem with this quote, "If a fire breaks out, which kind of people would you prefer? The ones who incessantly scream: “Look, there is a fire!” or the ones who actually put out the fire and then gather together to design the place to be more fire safe in the future?"

I would argue that he is describing three different people with three different skill sets. We need people yelling fire and getting folks out of the building (researchers and exploit writers), people to put out the fire (incident handlers), and people to find ways to prevent fires in the future (development teams). These are very different skills and most people will not posses two of these skills much less all three. Instead of disparaging the security researcher, embrace her skill set and give her a way to contribute to the solution.

By the way, most security researchers are finding flaws related to unsanitized input (buffer overflows, XSS, SQLi, etc.). These flaws are a result of fundamental problems in the development process and unless you are prepared to offer every security researcher a job doing development work at your company then you are contributing to the researchers inability to create a "quantum leap to prevent similar events from happening."

Hunting for Artifacts with Metasploit

A while back my boss, @BillDeanCCE, was looking for a way to check a machine for evidence of a compromise. He wanted to find files in specific locations with specific md5 checksums and wanted to find specific registry keys matching a particular value. I spent some time mulling this over and finally created a metasploit post module to do it.

First, obtain a meterpreter or shell session and load the module using use post/windows/gather/enum_artifacts.

Next, specify a configuration file containing the artifacts you want to find. The configuration file is written using YAML syntax and should be in the following format:

---
test_evidence:  # What the artifacts below are related to.
 files:
  - name: c:\ntdetect.com                  # File to find.
    csum: b2de3452de03674c6cec68b8c8ce7c78 # MD5 checksum.
  - name: c:\boot.ini
    csum: fa579938b0733b87066546afe951082c

 reg_entries:
  - key: HKEY_LOCAL_MACHINE\SYSTEM\Select  # Registry key
    val: Current                           # Value
    data: 1                                # Data
  - key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ACPI
    val: DisplayName
    data: Microsoft ACPI Driver

Finally, run the enum_artifacts post module and it will search the computer in the specified session for any of the artifacts in the configuration file. Any matches are stored in the loot for later processing.

A default configuration file is included with Metasploit and located at data/post/enum_artifacts_list.txt. Currently, the configuration file contains only a couple of test artifacts, which were used to ensure the module worked properly. I would like to see the community get together and add artifacts to this file, artifacts that could allow pentesters to identify malware infections, installed software, or any number of other things.

If you have any questions or comments about this module or suggestions for improvements, please let me know.