As vulnerability assessments continue from quarter to quarter, some vulnerabilities seem to appear, disappear, and reappear again. Some appear that were never seen before, despite the fact the affected software has been in use for over a year. If you’re in charge of remediating these vulnerabilities, you may be left scratching your head in puzzlement. Was the vulnerability remediated? Was it reintroduced to the environment? Did the scanning tool fail to catch it in a particular quarter? The short answer is yes. The long answer?
Vulnerabilities can appear and disappear for a variety of reasons. Sometimes vulnerabilities will disappear due to being remediated, even if the remediation is unintentional. For example, a code-related vulnerability from last quarter doesn’t appear in this quarter’s scan. When you congratulate the development team on fixing the issue, they say “What? Sorry, we haven’t gotten around to fixing that one yet.” What happened? The server team applied a patch to the OS of the server the application was running on; the patch added new security functionality that unintentionally also fixed the code-related vulnerability, but no one realized it happened. Next quarter, the server team has rolled back the patch due to issues with a separate legacy application, and the vulnerability appears again. The next quarter, the server team turns off the affected server for maintenance during the time it was supposed to be scanned, so once again, the vulnerability disappears from the report, and all seems well. The next quarter, the server is turned back on, the development team adds new functionality to the application that requires additional services to be run on the server, the vendor’s scanning tool receives a huge plugin update with hundreds of new checks, and one of the new checks leads the security consultant to manually discover a high-severity issue which allows the complete compromise of the server. All of a sudden, a huge blob of risk has fallen in your lap, your boss’s left eye is twitching more than it usually does, and you have no idea how to rationalize what happened, much less explain it in an easy to consume manner. What do you do? Use the abbreviated cheatsheet below, which illustrates the most common sources of vulnerabilities’ disappearing and reappearing acts:
Source
Vulnerability
Trackable?
How?
Disappears
Appears
Intentional remediation of vulnerabilities
X
Yes
Ask owner
Unintentional remediation of vulnerabilities
X
No
-
The availability of services during scanning
X
Maybe
Review logs, ask owner
The addition of services since the last scan
X
Yes
Review systems, ask owner
Updates to plugins/tool set
X
Yes
Ask vendor
Manually discovered results
X
Yes
Ask vendor
Vulnerabilities can be hard to track, but with a bit of elbow grease and a convenient table provided by a reliable, intelligent resource (cough), you can hopefully be well on your way to eradicating the mystery of the vulnerability disappearing and reappearing act.
According to Gartner, 75% of the attacks are coming though web applications and not through the network. This means greater emphasis needs to be placed on application security. However, this does not appear to be happening.
Application security vulnerabilities are increasing
For the first half of 2009, Cenzic identified about 3,100 total vulnerabilities, which is an increase of over 10 percent from the second half of 2008. (http://www.cenzic.com). Another revealing piece of data: WhiteHat Security has stated that in 83% of the 1,300 websites they scan have had at least one serious vulnerability (http://www.whitehatsec.com). Of the projects NetSPI has done in the application security area, 83% of these projects also had serious findings (serious vulnerabilities are those of HIGH, CRITICAL, or URGENT severity as defined by PCI DSS naming conventions).
What can happen if you do not fix the problems?
The first real risk is the theft of your data or your customers’ data. If applications are not done right, SQL Injection can allow a person (or persons) access to your database. Think TJX and all of the problems they had. Another risk is to your company’s reputation.Given the right situation, a user could be redirected to a site that is not under your control. It could be a porn site or even a site that looks like yours; it just exists to steal your users’ credentials. Your reputation will take years to repair, and the cost to your company may be insurmountable.
What can you do?
Many of the problems can be fixed by training. These do not have to be external training courses; they could just be brown bag lunches that cover specific secure coding techniques. A good place to start is the OWASP web site (http://www.owasp.org ). This site gives good information on detecting and preventing these vulnerabilities.
Perform code reviews and application vulnerability assessments on a regular basis. Code reviews need to be performed every time the code changes. Application vulnerability assessments need to be done at least annually.
By doing code reviews, and vulnerability assessments, you are helping both your company and your customers.
The worst kind of vulnerability in your environment is the one you don’t know exists. The “FCKeditor Arbitrary File Upload” issue seems to be just such a vulnerability. The purpose of this blog entry is to increase awareness of this issue and provide companies with sources for remediation options.
The “FCKeditor Arbitrary File Upload” vulnerability provides attackers with a method to upload arbitrary files (such as web-based shells), and execute commands on affected servers. However, privileges are limited to those assigned to the web server service account or user. The issue was originally identified being exploited in the wild during July of 2009. Since that time it has become a common finding during NetSPI ASV assessments and penetration tests. Unfortunately, many vulnerability scanners still don’t find this issue. As a result, many companies are unaware that it exists in their environment, even though they subscribe to vulnerability scan services.
However, this doesn’t have to be an invisible threat. Be sure to contact your vulnerability scanning vendor to make sure that they have a plug-in to identify this issue. In the meantime, I’ve provide some links that contain more information about the vulnerability and how to fix it in your environment.
Should you rely on just one solution to identify all of your vulnerabilities? Most of us rely upon just one anti-virus scanner, right? Every vulnerability scanner claims to be better than its competitors, but how could this be? Where is the Consumer Reports on this subject? I think there is a mix of reasons why this subject has not been picked up by the likes of Gartner or Forrester—it’s quite technical and hard to understand, and the audience may be too small. I have inquired of two independent security test labs recently as to whether or not vulnerability scanning products were ever tested and compared against one another, with the results then published. The short answer is no. Products are often benchmarked against standard criteria, and results are privately reported according to whether or not they meet the minimum criteria.
There have been some rogue studies on the subject, and I have conducted extensive testing myself. I can confirm that certain products are better than their competitors, but not in all areas. Because there are not well-defined standards or readily available test results, security practitioners are left using a vulnerability scanner that performs like a piano with many keys out of tune. In our own testing we have seen variations of up to 60% among leading products. In addition, their comprehensiveness and accuracy depend on what operating systems, applications, and configuration settings you have and whether or not your scanner vendor agrees that a particular vulnerability is important enough to test for.
In a decade-old product space, we have not seen complete maturity of either the space or the products themselves. During this time there have been a number of acquisitions of product vendors, and some of those acquired products no longer exist. At the same time, new and exciting products and vendors continue to emerge. The requirements of a scanner have evolved from OS level service checks to include web application vulnerabilities, authenticated configuration testing, and zero day attacks. Within the typical server environment, there are so many vulnerabilities identified time and time again, that many organizations find it difficult to embrace the idea that there may be actually more vulnerabilities out there that go undetected.
If your security team is a capable one, I encourage you to incorporate both commercial and open source tools, and even consider the introduction of more than one commercial product. If you outsource this service, ask your vendor what products it tests with and whether or not it can consolidate all findings from all vendors into one comprehensive report. In lieu of product comparison benchmarks, this approach may be your best option to ensure you are not leaving large areas of vulnerabilities undiscovered. Keep in mind, if you hire a product vendor to perform your assessment, its professional services team may not be able to use a different vendor’s product within its own solution.
For those of you concerned with the thought of too many vulnerabilities, check back in a couple weeks, as I plan to discuss some techniques for vulnerability prioritization and remediation.
NetSPI is embarking on an initiative to provide opinions and insight to security practitioners in the form of periodic blog entries covering four specific subject areas, one of which is Application Security. Entries in this blog category will be provided by members of NetSPI’s Application Security team and will include commentary on application security testing products, analysis of recent exploits, and our perspective on developing trends in application security.
The team, which consists of developers and pentesters with extensive experience across several industries, will draw on a wealth of experience: we test hundreds of applications for security vulnerabilities every year. The work done by the team includes application vulnerability assessments, penetration tests, architecture reviews, code analyses, and SDLC evaluations. This experience has given us a great perspective on where application controls are missing or fail, as well as the root cause of failures.
Our goal for this blog is to contribute content on application security that will not only be of interest, but that will have real value for you in protecting information assets. We welcome your suggestions and feedback.
