We always encourage a penetration test to be as much of as an accurate representation of the true state of operations as possible, without stepping things up just before the test begins. If the only goal is to look good on a pen test, that is not a very sustainable strategy. However, there may be various reasons you'd want to have a "clean" pen testing report. Working with a security provider (such as RedTeam Security) that allows for remediation assistance and re-testing during the initial execution phase can help tremendously toward that end. Nevertheless, maintaining and continually striving for a secure environment and seeking quality penetration testing services that comprehensively/effectively tests the security posture of that environment should always be the end goal.
Here are a few ways to nip the low hanging fruit in the bud and help increase your standing during a penetration test:
This one goes without saying. Missing patches make up one of the most identified issues during a penetration test. If patches are not applied reasonably soon after they have been made available, bad actors (and RedTeam Security consultants) will discover and exploit them. And we will usually discover them quickly! Hunting for missing patches happens early in the pen testing process and is one of the most successful ways in compromising systems. Now, not all vulnerabilities lead toward full system compromise; some just wreak havoc. But when in doubt, apply.
Hint: be sure to upgrade systems/apps using SSL to the latest supported TLS version!
It seems like more often than not, we come across a system or application whose owner just plain forgot about. While these are generally not high in number, they account for some of the most vulnerable and high-target systems out there. Forgotten systems do not get sysadmin love and attention, therefore they fester and boil with all sorts of vulnerabilities derived from running with unsupported operating systems (MS03-026, MS08-067), unnecessary services, and more. Run a quick ping sweep or simple Nmap scan of your network to compare against your system inventory. Power off, disable karate chop any forgotten/rogue systems and services.
Yes, weak and default passwords are still a thing. Yes, any quality pen testing service provider will check for default passwords and do some level of password strength testing, among other authentication and authorization techniques. We haven't met a single person who is okay with having a finding for using a blank ‘sa' password on their report. Nowadays, password managers make this process easier. Password changes don't take long to carry out, so this can be a nice quick win and save an embarrassing moment.
Administrative interfaces (ie: Cisco devices, Tomcat, ColdFusion) should be made available only to administrators. All too often we see web GUIs, video conferencing logins, application backdoors, FTP services, private APIs, remote control interfaces, telnet and SSH services without access control lists in place to limit connectivity. These are high value targets for attackers. We strongly recommend leveraging switch and router ACLs and/or firewall rules to restrict connectivity to only those with authorization to even connect to them.
Hint: using Windows RDP unrestricted over the Internet without any other mitigating controls is almost never a good idea.
Okay, this one barely qualifies as a ‘quick' win. But it is definitely a win. A big one at that! What do we mean by validating input and output? Applications that accept input from the user (nearly all do), should have protective measures in place to clean up input before actually doing something with it, such as saving it. The most common web application security weakness is the failure to properly validate input from the client or environment. This weakness leads to almost all of the major vulnerabilities in applications, such as Interpreter Injection, locale/Unicode attacks, file system attacks and buffer overflows. Basically, data from the client should never be trusted for the client has every possibility to tamper with the data (accidentally or intentionally).
Again, the effort involved is probably not something you'd consider quick. But by leveraging guidance and implementing it within at least a single high-value, high-target application, it would go a long way in improving the overall security standing in the report.
The purveyors of ‘security through obscurity' will tell you that spoofing your banner is useless and evil. That's true if that practice is the only technique employed to protect systems. The truth is, hackers (and security consultants alike) use banners to gather information about assets such as the manufacturer, model, etc. They use this information, typically as truth, to analyze and craft plans of attack. Now, determined attackers can use alternate methods to try to find out if the banner has been falsified or not and therefore attack the system from a different angle. But this setback increases additional hurdles and friction into the process for hackers who, statistics show, are neither overly determined nor are they targeting you. In other words, most compromises are opportunistic. So with just a bit of legwork, it could frustrate a good number of would-be attackers and cause them to move along. As alluded to previously, security through obscurity tactics are okay to use, but only if combined with multiple layers of defense.