Security professionals are used to seeing a high turnover of threats, with new vulnerabilities disclosed weekly and regular rounds of patches to contend with.
While newer vulnerabilities often make up the lion’s share of exploits in a given year, there is a consistent undercurrent of attacks that take place through flaws that should have been fixed long ago.
Last year, Fortinet revealed research that 90 percent of organisations “recorded exploits for vulnerabilities that were at least three years old.” In addition, around 60 percent of firms saw attacks using decade-old exploits.
Microsoft has also released similar research that found old threats die hard: as one commentator put it, “threats don’t change as fast as we think they do”.
Most of the ‘senior citizen’ classes of vulnerabilities impact internal network environments, like the ones you can find in most offices today.
An example is SMB signing, which is configuration setting which is disabled by default on all versions of Windows, except on Domain Controllers.
An internal intruder with physical network access or a remote intruder via a compromised workstation could perform an attack known as “SMB Relay” against these systems to impersonate users without even knowing their passwords.
The example above is not difficult to overcome and can be remediated through enabling SMB signing. This is a configuration change that can be done centrally within a typical Active Directory environment and would be considered a basic change (though, as always, test and plan prior to making any adjustments).
One reason these kinds of threats persist is that organisations have often been around for a long time, and thus so have elements of their infrastructure and networks. They are also likely to have a mix of new and old technology, which may have had several IT owners throughout its life.
In these cases, the problems generally stem from legacy configurations. Particularly old or inherited infrastructure elements may not come with much documentation of changes or configuration decisions made over the years - or of its interdependencies with other systems.
Therefore, organisations may be reluctant to pursue major changes, leaving the box vulnerable to exploitation in the process.
One way to identify these kinds of veteran vulnerabilities is through regular penetration testing (or pen testing).
A Pen tester’s job is to safely simulate an attack against a company - and to determine risks that may be present in the company’s infrastructure that could allow such an attack to occur in real life.
Typically, a potential client will engage with a Pen tester once a year, or sooner if they make a significant change to the environment and want assurance that it is secure.
The Pen tester discusses with the client their needs and concerns, structures a test around those needs and presents the client with the testing scope.
The duration of an engagement is dependent on a few factors, such as the nature of the workload. For a web application, the major factor towards calculating the duration would be the application functionality and its complexity.
A pen test typically runs over the course of a few days, with a report delivered to the client on the issues that were found, each issues’ potential impact to the organisation, and recommendations on how to correct the problem.
Lastly, the consultant will walk the client through the assessment and report to answer any technical questions they may have and to provide an unbiased opinion.
Its then left to the client to review the results of the exercise to ensure they understand the findings and what is required from them to remediate any issues.
However, once fixes are implemented, it is good practice to engage with the original tester to test and validate that the fix is effective.
While internal staff may contribute to the penetration testing activity, it isn’t common to run these kinds of tests in-house.
This is partly because the specialist skillset of a Pen tester is rarely held in-house, and also because the test is often about understanding how someone with limited prior knowledge of a system might attempt to exploit the system.
In addition, independence can also be an obvious issue – if you ask a developer to pen test an app he or she wrote, they may not be as forthcoming with announcing bad results.
Finally, it goes without saying that online threats and vulnerabilities are something almost every business that operates in an online environment will have to contend with on a daily basis. The key to doing so effectively is to first ensure any ‘old vulnerabilities’ are ticked off the list; so that your efforts can be placed on addressing the new ones.
Author: Chris Berry, Principal Consultant, Aura Information Security