Defending Against Client-Side Attacks through a Vulnerability Management Program
Dustin Jones
In Partial Fulfillment of the Requirements for the Real World Security Practitioner Certification
Introduction
Does anyone really know the current state of their networks security posture? All the time, organizations suffer from a lack of, or weak, vulnerability management programs. To fully understand an organizations security posture we must look at what Vulnerability Management is. Attacks today go beyond the Operating System and focus more on client-side software. The biggest threats to a network are exploits written for client-side software that the vendor does not know about. These exploits are known as zero-day vulnerabilities. Client-side vulnerabilities are much more difficult to fix because the patch install process is not automated. There are methods of protection against these client-side attacks, but an organization must stay away from the five common mistakes of Vulnerability Management, such as scanning without taking action, thinking patching is vulnerability management, believing vulnerability management is only a technical problem, looking at part of the picture instead of the problem as a whole, and being unprepared for the unknown. Patch Management and self-penetration testing are a few ways to protect against common attacks. Vulnerability management, just one of many layers of defense used today, is extremely important in preventing successful client-side attacks.
What is Vulnerability Management
. One might ask themselves what exactly is vulnerability management. Vulnerability management must be understood completely in order to implement this into an organizations security configuration. Vulnerability management is just as the name implies, it is managing the vulnerabilities on a network or asset, that reside on that network; however, vulnerability management is a much larger process. This process begins with identifying what vulnerabilities exist, what steps are going to be taken to remediate those risks, and what risks are acceptable to allow data availability to clients and customers. By following these steps, you can be better equipped to handle any issues that may arise on your network and help prevent any client-side attacks.
The first step in managing vulnerabilities on a network is identifying what exists. There are many solutions that can be utilized to perform this action, from freeware, to spending thousands of dollars for a software license which allows updates to the vulnerability database. Without these updates a scan will not produce accurate results leaving newly exploited vulnerabilities on the network undetected. Scan tools can be customized to scan for only a select few vulnerabilities to the full vulnerability database. Of course the more vulnerabilities you are scanning for, the longer the process is going to take. Once your scans are complete, a detailed report can be generated that will outline how to fix each identified vulnerability, or an executive type report can be generated showing the overall status of the network. Either report can be very helpful in determining what issues are on the network and what the proper method would be to mitigate that issue.
The next step that is probably as critical as remediating the identified vulnerabilities, is auditing the report for patches that might degrade the performance of running applications. Data availability is still a requirement when remediating your systems. Having said this, if certain patches are applied they might interrupt services being provided by a system on the network. Keeping security and availability in mind, certain risks must be assumed on a network. For example, if a patch is going to interrupt services but the risk category is low an organization might leave that security flaw unpatched to keep services available to the customers. However, if the risk category is high, the same organization may need to include service disruption with the mitigation in order to ensure the network is properly patched and avoid any future issues and exploits.
The next and potentially most important step is remediating the identified vulnerabilities. This can be done utilizing a few different methods identified in the remediation report of most vulnerability scanners. Some vulnerabilities can be fixed by applying a vendor patch, while others might take manual configuration to close the attack vector. There are many services offered within the Windows Operating System that take registry key changes to remediate the vulnerability. Remediation just like anything else on a computer system must be tested prior to installing the patch in your production environment. Every organization should have a test environment that is an exact mirror of the production network they utilize every day. Once a patch passes the test and all applications and services are functioning properly, that organization can implement that patch or registry edit in the production environment with confidence that everything will continue to function properly. During the testing and evaluation phase of remediation, decisions must be made on what is an acceptable risk on the network. Some vulnerability fixes might break an application or service that is critical for that organization. Because of this, every organization should appoint an individual designated to be the approving authority for accepting risks on a network. Each risk that is accepted on a network must either have a temporary mitigation or be a vulnerability that may not cause damage to the systems that connect to that network. Some vulnerabilities might allow an attacker to perform some function that is simply annoying to a user, however if exploited, is not a real threat. These are rarely exploited and can easily be an acceptable risk.
Moving Toward Client-Side Atttacks
Exploits are moving away from security holes in the Operating Systems today and are starting to focus more and more attention on client-side software instead. The applications are a little more difficult to patch because most of them require a manual download and install. These applications also do not notify the user when an update is ready for download. Unlike Windows Update which will download and install patches automatically, software patches can be a little harder to come by. Software developers might not know about vulnerabilities within their software and that risk may go unnoticed for a long period of time with no patch being released. During the last few years, the number of vulnerabilities being discovered in applications is far greater than the number of vulnerabilities discovered in operating systems. As a result, more exploitation attempts are recorded on application programs. The most "popular" applications for exploitation tend to change over time since the rationale for targeting a particular application often depends on factors like prevalence or the inability to effectively patch.
Due to the current trend of converting trusted web sites into malicious servers, browsers and client-side applications, which can be invoked by browsers, seem to be consistently targeted. (SANS) The way this attack might happen is by an attacker placing some malicious content on a publicly trusted website. These sites could be anything from a social networking site, a website that hosts blogs, media sharing websites, or any other type of website that hosts content posted by public users. This malicious code will target the client-side software that remains unpatched. The software that is vulnerable to this exploitation code could be anything from an installed media player (Real Player, QuickTime, Windows Media Player, iTunes, etc.), a document reader such as Adobe Reader, or some component installed with an office suite (Microsoft Office tools like Excel, Word, PowerPoint). Once the malicious content is received from the website the web browser will send this code to the vulnerable software. The attacker can then install or execute a program of his choice remotely through the exploit. This program will run with the privileges of the currently logged on user. While this may seem harmless if a user does not have administrative privileges on a machine, accounts with limited access can still run programs. For example if an attackers code installs an application that listens on a certain port that should generally be blocked due to an exploit, this can give the attacker remote access to a command shell installed on the system.
Another option is utilizing applications that are capable of executing a reverse command shell. What this means is the application installed on the exploited machine connects to the attacker using secure methods that are normally allowed through a firewall. With remote access to a command shell the attacker now has many other options for exploiting that system. Some backdoor applications will communicate with the attacker using secure protocols that administrators might overlook as normal network traffic. It would seem as if the user of the exploited machine is communicating with a website running SSL or some other form of normal network traffic which is usually allowed through a firewall and would not be easily recognizable. Typically an organization will allow HTTPS traffic outbound in their firewall rules allowing network users access to secure websites. Once an attacker is in the system he can utilize his limited user privileges to install useful applications that may perform a hash passing exploit. By dumping the local SAM database an attacker will have all the information needed to authenticate using an administrative account without even knowing the password to the account. The attacker can then utilize the hash pulled from the SAM database to authenticate to other systems that might be fully patched. Once the initial access is gained the fully patched system can be used to authenticate to a domain. With the newly gained domain privileges the attacker can now collect information from the organization for use at a later date. One might wonder if this traffic would be seen by network administrators that are monitoring network traffic. Remember the attacker is using a reverse command shell with SSL encryption. While this traffic would be allowed through the firewall and appear to be normal network traffic, the system administrator will notice a large amount of encrypted data leaving the network from the exploited host. This is a key sign that something other than the logged-on user is sending data out of the organization and that asset should be removed from the network and analyzed immediately.
Zero-Day Exploits
Client-side attacks go beyond obtaining a reverse command shell by exploiting unpatched software with a website. The Holy Grail for malicious program and virus writers is the “zero day exploit”. A zero day exploit is when the exploit for vulnerability is created before, or on, the same day as the vulnerability is learned about by the vendor. (Bradley, 2010) This means that once the exploit is released into the public domain anyone has the ability to successfully exploit the vulnerability because there is no current fix. A glaring example of this was the SNMP (Simple Network Management Protocol) vulnerability announced in February of 2002. Students at Oulu University in Finland actually discovered the flaws in the summer of 2001 while working on the PROTOS project, a test suite designed to test SNMPv1 (version 1). (Bradley, 2010) SNMP is a protocol still in use today mainly for system monitoring and remote administration of network devices. SNMP is present in almost all network hardware today including routers, switches, hubs, printers, scanners, copiers, fax machines, high-end computerized medical equipment, and in almost every operating system. After making their discovery the students discreetly notified designated parties and the word went out to the vendors. All students kept the information secret but it eventually leaked out to the world that the PROTOS test suite, which was freely and publicly available, could exploit this vulnerability. The vendors and the world scrambled to create and release patches addressing the situation only after the exploit leaked out to the world. Some might wonder why the vendor took no action after being informed about this vulnerability and the seriousness of the effects if it is exploited. Everyone thought of this as a zero day exploit, when in fact the vendor was aware of the situation over 6 months before the information was leaked out to the world. Microsoft finds or is alerted to new vulnerabilities in their products on a regular basis. This does not mean they rush to put out a patch for the vulnerability. Sometimes they can take weeks or even months to release a patch for a hole found in their product. Microsoft does not put out patches for all holes identified in their products either. This is open to different interpretations and Microsoft might not think that it is a flaw in the product. There is a security organization that used to maintain a running list of Internet Explorer vulnerabilities that Microsoft knew about but had not released a patch for. There are similar sites run by attackers that are used as an information sharing and exploit trading forum. No matter how you look at this type of client-side exploit. If the exploit exists or has been developed and the vendor has no idea about it you have a zero day exploit. Although we don’t usually learn about most of the zero day exploits until a vendor performs a forensic investigation on an exploited system, or when analyzing a virus running around in the wild to see how it works.
Good ways to protect against unknown attacks is by installing a host based or network based firewall. Another method that can be utilized is an antivirus solution capable of heuristic scanning. This scan type is used to protect against unknown threats by looking for anomalous traffic or activity on a system instead of the traditional virus signature checks found in older scan engines.
Operating System versus Client-Side Software Patching
There is a big difference in patching the Operating System of a host machine and patching the software that gets installed. Operating Systems notify you when updates are ready for install if properly configured. Most software applications do not offer this option. Regular checks on software vendors support pages needs to be put into daily tasks for system administrators. Studies prove that Operating System class vulnerabilities have shown a significant decrease within the first 15 days of their lifetime. Review the below table for Operating System class vulnerability patching.
Vulnerabilities found in applications receive less attention and get patched on a much slower timeline. Some applications such as Microsoft Office and Adobe Acrobat Reader are very widely installed and so expose many systems to long term threats. The following graphs plot the number of vulnerabilities detected for Microsoft Office and Adobe Reader normalized to the maximum number of vulnerabilities detected in the timeframe. Periodic drops in detection occur during weekends when scanning focuses on servers rather than desktop machines and detection rates of vulnerabilities related to desktop software fall accordingly.
Attackers have picked up on this trend and have changed the focus of their attacks to client-side software.
These different types of attacks are being used to take advantage of these vulnerabilities. Using social engineering techniques to lure end-users to opening documents received by e-mail or by infecting websites with links to these the attacker is better able to exploit these vulnerabilities. By placing these documents on very popular websites the attackers can target many users with a single point of presence. They are not only using these popular sites, but are targeting many smaller sites with a faithful audience. Using exploits to attack the content management systems of these sites attackers, they are able to host these infected files on many sites at a time. Attacks using PDF vulnerabilities have seen a large increase in late 2008 and 2009 as it became clear to attackers how easy it is to use this method of getting control of a machine. Another application that is high on the vulnerability exploit list is Java. Java is a common applet used to run content on a website in a web browser. Java is very slow in its update cycle and remains vulnerable for long periods of time. Java updates have been identified as leaving a system vulnerable even after install because the updates are not removing older code from the machine. Attacks can still be targeted to the well-known paths and are able to continue to use older code and vulnerable Java engines. (SANS) These are just a few of the widely installed software applications that leave a system vulnerable for long periods of time.
Patch Install Options
The truth still stands that if we do not have a system in place to check vendor websites on a regular basis, vulnerabilities will exist on machines that will leave your network vulnerable for extended periods of time. There are other issues with patching these applications above and beyond finding out that a patch is available. The applications that do not have the automatic update option must be patched manually. This leaves many questions for the system administrator to answer. How will we push these patches to our vulnerable systems? What systems need to receive this patch? There are many software applications that can be installed on a network to automate patching for all non-Microsoft applications. These applications can push patches to systems based on a software audit and patch check. Other applications will push patches to all systems on a network regardless if the application is installed on the host. In this case the system will refuse the patch because that application is not installed but takes up network bandwidth in the process. A system administrator can always choose to install and push patches via a Group Policy Object (GPO). This will ensure that all systems receive a patch as soon as the system checks into the domain. It will also ensure that each user account receives the needed patches. To perform this type of function an MSI packager will be needed to format the patches into a file the Microsoft Installer can recognize. The decision and method used of course is ultimately up to the system administrator or system owner. Either way these applications must be patched in a timely manner to remove vulnerabilities from the network and prevent attackers from gaining access.
Vulnerability Scanning
There are ways to protect against common client-side application vulnerability attacks that can be implemented on any network. Vulnerability Scanning can tell a system administrator what vulnerabilities exist with currently installed software applications. Scanning software such as Tenable Nessus, eEye Retina, or Qualys can be utilized to identify vulnerabilities within, not only the operating system, but the software installed as well. Whether giving a system administrator a link to a vendor’s website for a patch download or outlining how to edit the system registry these applications provide ways to identify and protect against common attacks. At a minimum scans need to be performed weekly to test a network for new vulnerabilities that may exist. Scans should also be run at least weekly to validate that vulnerability patching has taken place and attack vectors are no longer present on the systems of that network. Vulnerability scanners can go beyond telling a system administrator what vulnerabilities exist on a networks operating systems and software, they can also test local and network security policies for compliancy with current day best practices. These applications can audit user accounts to ensure that the accounts are not set for a password to never expire or to ensure that there are not accounts that are locked out. These checks can be used to ensure that systems on the network are not using the default administrative account and have backups established. The more extensive the checks on a system, the longer the scans are going to take. Intrusive scans have been known to cause adverse effects on a system as well. If too many options are set in a vulnerability scanners configuration, they have been known to lock out web based user accounts used in certain web applications. These intrusive scans will of course give a system administrator much more information on a system allowing a stronger security posture, so the risk must be weighted.
The audits to use on a network must be determined prior to implementing vulnerability scanning within an organization. Some organizations can still operate if a web application user account gets locked out and others might lose productivity. A configuration control board can be stood up to make decisions such as this. Some of the vulnerability scanners can show vulnerability history and trends. System administrators are finding out that these trends are leaning more toward client-side vulnerabilities and moving away from the quickly patched operating systems. Qualys scanners collect anonymized data of vulnerabilities to capture the changing dynamics in the vulnerability assessment field. To get statistics based on actual data zero-day vulnerabilities were removed from the collected data. Of the thirty top vulnerabilities over half of those were not directed toward servers but client-side applications. All of these reasons make vulnerability scanning that much more important on a network. Zero-day exploits can also be scanned for, but do not offer a method of fixing this vulnerability. As patching progresses, new fixes for these zero-day vulnerabilities are loaded into the scanners database. Vulnerability scanning is a method of keeping a step ahead of the attackers by showing administrators where the holes are and helping close those holes before they are exploited.
Five Major Mistakes in Vulnerability Management
While conducting research, I have found that there are five major mistakes in vulnerability management that have been identified. These mistakes were noted in 2006 when vulnerability management began to come to the foresight of system administrators. Vulnerability management is viewed in many different ways from a security management activity, a simple process that needs to be done with the Microsoft Corporation’s monthly patch update, or a buzzword made up by vendors. The first of these mistakes is scanning without acting on the results from the scans. As discussed before vulnerability scanners are a very important piece of software at any organization. It does no good to perform vulnerability scans unless system administrators plan to act on those results and fix the findings. Scanning is not the end all of vulnerability management but is included in the process.
The second common mistake in vulnerability management is having the misconception that patching is vulnerability management. While patching is a way to repair the widespread vulnerabilities on a network it is not the only step in the process. Experts often say that once patching is complete the task is done. This is not a true statement at all regarding the vulnerability management process. As stated earlier some vulnerabilities cannot simply be fixed by updating to the most current version of a piece of software. Some fixes include tweaking and reconfiguring various system parameters. Vulnerability management was no doubt born from the need to prioritize and fix discovered vulnerabilities. Taking one day out of a month to patch vulnerabilities and not performing any actions the remaining 29 days is not managing vulnerabilities. Vulnerabilities are discovered daily and what you patch today will open a new exploit tomorrow. This is the reason there is a need for vulnerability management.
The third mistake, is believing that vulnerability management is only a technical problem. In order to be effective in vulnerability management an organization must look much deeper than the technical problems that are seen on the surface. Policies and processes must be improved as well, to implement a good vulnerability management solution. An example of a poor policy would be the lack of a minimum password length policy. This will create a weakness in the network that a simple patch will not fix. It should not be forgotten that policy weaknesses are vulnerabilities also. According to Gartner analyst, “the vulnerability management process includes policy definition, environment base lining, prioritization, shielding, mitigation as well as maintenance and monitoring.” Vulnerability management starts from the policy definition documentation that covers all an organizations assets and their users. Such documents might be followed up by defining a known good state of all the referenced assets.
The forth mistake is assessing a vulnerability without looking at the whole picture. Many times the priority of a vulnerability is set based on the vulnerability itself and do not take the time to look at the criticality of the system this vulnerability affects. For example, a Web server that resides in the organizations DMZ where it is subject to constant attacks and probes needs to be patched sooner than a test server that resides deep in the bowels of the enterprise. At the same time, a critical system that does not get attacked frequently but stores data critical to the company’s productivity should be on the high priority list for receiving patches as well. There is a simple formula that can be applied to prioritize without making mistakes. RISK = Threat x Vulnerability x Value is the formula that can be applied to help decide what systems should be patched first. Another way to help prioritize the risk is by using the Common Vulnerability Scoring System (CVSS). The CVSS takes into account various vulnerability properties, such as priority, exploitability and impact. The CVSS data still needs to be enhanced with business-value and threat data.
The fifth and final mistake is being unprepared for the unknown or “zero-day” exploits. These exploits have been previously discussed are those that can be exploited even if all current patches are installed. Additional steps that can be implemented that have not been stated previously, are network and host security monitoring that might make a system administrator aware that a system has been attacked, and implementing a proper incident response plan. All of the processes stated are part of a strategy known as defense in depth. Taking care of mitigating these common mistakes can assist an organization in proper vulnerability management. (Chuvakin, 2006)
Patch Management
Another key aspect of vulnerability management is of course patch management. There are many solutions out today that can assist system administrators in patching non Microsoft systems and software. Patching can be done in so many ways it depends on the skill of the administrator in choosing a solution. Software solutions that can push any type of patch are readily available today. Solutions such as McAfee Hercules, Big Fix, Foundstone LanGuard, and many others are available. As discussed previously a system administrator always has the option of pushing patches using a GPO in a domain situation. These patches must be properly packaged into a format recognized by the Windows Installer known as MSI. This file conversion process is not needed if one of the stated software solutions is adopted on the network. Each version of software mentioned above works off agents which are installed on each host on a network. This host will check into a server that has been pre-configured with the patches each machine will need to become compliant. The server will acknowledge the agent and send it a patch status informing that asset that patches are ready for download. According to the configuration of the solution those patches can be set to automatically download and install without user intervention. These solutions can also be set to inform a user that patches are ready for download and install letting the user choose when the install happens. This can be a good solution in an organization that has shift workers. Patches are normally set to download and install when workers are not present to prevent a denial of service to the users or an interruption in services.
The fact still remains true that without a good vulnerability management process even the best patch management solution will not protect a network from attack. Patch management is not a single solution to vulnerability management but is still a vital aspect of the process. Patch management goes hand in hand with vulnerability identification and scanning. Patch management is the activity that will mitigate the first of the common vulnerability management mistakes discussed earlier.
Penetration Testing
A less discussed method of vulnerability identification and management is penetration testing. Penetration testing differs from vulnerability scanning in the fact that you are running exploits against systems and not just identifying those vulnerabilities. Every organization should implement some form of self-penetration testing to their organization and vulnerability management process. Penetration testing allows an organization to know what attack vectors can be exploited by attackers and the level of access that can be gained. Many organizations today are beginning to get into the business of web application development. Penetration testing can be used to test the security of the application code. By utilizing SQL injection and cross site scripting (XSS) exploits a battery of tests can be run on the code of an application that is accessed frequently by the public. There are a number of organizations today that offer an automated solution for performing a penetration test on a network or client-side application. These solutions range from free products to software that might cost thirty thousand dollars for a one year license. A few notable solutions are SAINT, Core Impact, and the free solution Metasploit. All three of these solutions offer a wide range of tools used to attempt exploit of systems on a network. These exploits range from common operating system exploits to the more popular client-side exploits of today. These solutions also offer XSS and SQL injection exploits for testing web applications. These solutions give an administrator a good idea of what can be exploited on a network and what level of access can be gained. There are options built into these solutions that will allow the penetration tester to use an exploited system as a pivot point to penetrate further into the network and gain more privileged access. This is one method that can be used to identify what vulnerabilities can be given a higher patching priority because of the after effects of exploitation. This is just one more tool that can be used to assist with the vulnerability management process.
Conclusion
Vulnerability management, just one of many layers of defense used today, is extremely important in preventing successful attacks. Overall we have looked at many aspects of vulnerability management as it pertains to the client-side exploits that are growing in numbers on the network. Vulnerability management covers a broad spectrum and cannot be described as one single step. Vulnerability management is vital for any organization to implement, to ensure risks on the network are mitigated. As discussed in this paper there are many aspects of the vulnerability management process, and no one aspect is more important than the others. From policy and procedures, to proper patch management, each step needs to be taken and analyzed individually. If one of the identified steps has any weakness, the entire vulnerability management process will fail. The question of how secure is the network, is always asked and with a proper vulnerability management program, the answer can be truthfully given.
References
Bradley, T. (2010). Zero Day Exploits Holy Grail Of The Malicious Attacker. Retrieved August 24, 2010, from About.com: Internet / Network Security: http://netsecurity.about.com/od/newsandeditorial1/a/aazeroday.htm
Chuvakin, A. (2006, Jan 11). Five Mistakes of Vulnerability Management. Retrieved Sept 7, 2010, from Computer World: http://www.computerworld.com/s/article/print/107647/Five_mistakes_of_vulnerability_management
Nariane, R. (2010, August 6). Windows 7 dinged by new zero-day vulnerability. Retrieved August 24, 2010, from ZDNet: http://www.zdnet.com/blog/security/windows-7-dinged-by-new-zero-day-vulnerability/7065
SANS. (n.d.). SANS Top Security Topics. Retrieved August 23, 2010, from SANS: http://www.sans.org/top-cyber-security-risks/