The Common Vulnerability in the Microsoft Windows Operating System - Coursework Example

CVE-2003-0352/MS03-026 Introduction The aim of the report is to examine the common vulnerability that was exposed in 2003 in Microsoft Windows Operating system. Common Vulnerabilities and Exposures (CVE) provides the common vulnerabilities that affect a system. A system is generally more prone to security threats and attacks. CVE provides a list of vulnerabilities that usually target a network system. The common vulnerability that is discussed here is CVE-2003-0352, called as the RPC DCOM Vulnerability. Its description states that it is a “Buffer overflow in a certain DCOM interface for RPC in Microsoft Windows NT 4.0, 2000, XP, and Server 2003 allows remote attackers to execute arbitrary code via a malformed message, as exploited by the Blaster/MSblast/LovSAN and Nachi/Welchia worms”. (CVE-2003-0352, 2003) On knowing about the identification of this vulnerability in its primary product, Microsoft released a bulletin with a patch to plug the hole in the system. It did turn out to be successful and Microsoft released it through the "Microsoft Security Bulletin MS03-026”. On the release of it, Microsoft recommended all of its Windows users to immediately install the patch so that any further severe damage could be prohibited. The severity of the threat depends on the impact of the exploitation made on this vulnerability. (Microsoft Security Bulletin MS03-026 2003) The report details about the technical specifications of the vulnerability, its severity level if it is exploited in a Windows operating system, the methods and details about how it is exploited and the consequences that it could lead to a system. The report also aims to provide details on methods that could be used as mitigation processes in solving this vulnerability. A brief history As astonishment to all, the August month of 2003 saw the introduction of a new malicious code, running its scare all over the security management communities creating a severe level of the threat to Windows users. That piece of code was later called as the MS-Blaster worm. The code was the result of a then known vulnerability found in the Microsoft’s operating system- in protocols called as the RPC and DCOM. These interfaces, considered to be preforming an integral part in the success of Windows and Windows Networking domains, went on to face harsh criticisms from several quarters. (Reuvid 2004) The severity level of threats that could be experienced with this vulnerability was very critical. Most of the networking systems depended on the remote connectivity that was capable in Windows with the help of these interfaces. As a result, critical business functions that completely depended on Networking came under severe threat. The versions of Windows that were affected by this vulnerability includes 2000, NT, 2003 and even Windows XP. More severe consequences were faced by those systems, which did not have a proper firewall system. Before gaining details on the vulnerability and how it is exploited, it is mandatory to know about the protocols that have been used as the medium of access for the vulnerability exploiters. RPC and DCOM protocols RPC - Remote Procedure Call as defined by Microsoft is, "a protocol used by the Windows operating system. RPC provides an inter-process communication mechanism that allows a program running on one computer to seamlessly execute code on a remote system. The protocol itself is derived from the Open Software Foundation (OSF) RPC protocol, but with the addition of some Microsoft specific extensions”. (Microsoft Security Bulletin MS03-026, 2003) The Distributed Component Object Model also called as the DCOM protocol allows for a seamless communication across several networks for multiple software accessories. The result of which is a direct communication which is uninterrupted and can be easily established across networks that are using different transport mediums. Examples of such network transport protocols include the universally accepted Hyper Text Transfer Protocol – HTTP. (O’Shea, 2003) The link between RPC and DCOM is that whenever client machines on different networks are in need to send across requests for the activation of a DCOM object, they use the ports which are ubiquitously enabled with RPC’s. Thus the DCOM protocols listen to those requests through these ports – enabled with RPC’s. The RPC model is based on the client-server communication system where the requesting system is termed as the Client and the request executor is the Server. The complicated details of the network get separated from the functioning of RPC because it works in the application layer of the OSI model. Port number 135 is used for the transmission of RPC requests since it is enabled with the DCOM interface. Such a single point mode of communication completely simplifies the complexities involved in remote communications. In addition to that, the servicing system has no idea about where the request has been originated and thus enhancing the security by hiding the identification details. (Microsoft MSDN "The RPC Model" 2003) The causes of the vulnerability include the traffic issues of the RPC protocol in the transport layer of the OSI model. The traffic issues are, in fact, handled through the Transmission Control Protocols (TCP). TCP actually ensures that proper connection is established and a secure transfer of data is done - data that is disintegrated into small packets at the source and again reassembled to the original manner at the receiving end. TCP’s functioning is well managed within the IP protocol which ensures that the correct address of the sender and receiver is stored. (Douglas 1995) Thus all the three protocols are encapsulated one within the other as shown below: Vulnerability – rise Common vulnerabilities and Exploitations (CVE) have been on the rise for many years. In those CVEs, Buffer overflow mechanism accounted for 23% of the total CVEs that were reported that year. The RPC DCOM vulnerability came into its existence during this development process when the DCOM protocols became to be the primary methods of inter-network communications. The exact source of its origin may be during its introduction in 1996 or through any of the updates that occurred from 1996 to 2003. The CVE-2003-0352 deals with the buffer overflow attack only. (Arbaugh et. al 2000) The vulnerability’s actual origin is in the DCOM protocol. It faltered in the way it handled the messages that were malformed. There was no specific flaw in the RPC but then, since RPC acts as the tunnel to send and receive these messages between the remote machines and the local ones, it too became part of the vulnerability. When the malformed message enters into the system, it causes an overflow in the buffer thereby initiating a Denial of Service (DOS) attack on the system.. As a result, any intruder could gain access to the system through a remote machine and with a help of malformed code. Exploitation of this vulnerability can be done by sending a malformed message as explained above through the RPC enabled ports and thus allowing for gaining of administrator privileges. Deduction of the Vulnerability and MS03-026 Last Stage of Delirium, also called as LSD discovered the existence of this vulnerability in Windows Operating system, in July 2003. As an act of desperate measure to negate the effects of this vulnerability, Microsoft released the security bulletin MS03-026 on the same day along with a patch that could solve this vulnerability issue. (LSD Research Group 2003) Sites from all over the world were alerted of this vulnerability and were issued warnings about the outcomes that could happen if the vulnerability is exposed. basic level, Microsoft requested servers from different parts of the world to block traffic in some of its ports for which the functionalities of RPC are active. LSD announcement followed by Microsoft’s bulletin created an emergency panic among the internet users all over the world. An immediate survey done to identify the possible systems that could be affected with this vulnerability showed that most of the operating systems of Windows and most of the Cisco integrated products are prone to this vulnerability. (Reuvid 2004) Exploitation of the Vulnerability An exploit of the vulnerability was exposed within a week of its discovery. The name of the 'exploit' was given to be ‘dcom.c’ which opens up port number 4444 to listen to commands that are passed from the shell and also responsible for buffer overflow in the Remote Procedure Call. It was shown to affect all versions of Windows operating system from 1998 to NT to XP. The exploit was a combination of code, which uses three of the above mentioned protocols – Remote Procedure Call, Distributed Component Object Model and Transmission Control Protocol. (Porter 2003) The exploit was programmed in such a way that it sends a crafted message to the port 135 using the RPC request processing mechanism and causes an overflow in the DCOM interface. The consequence of the overflow is that it allows the instructions that were sent to the interface to be sent back to the stack which in turn enables a command being invoked in the exploited machine and thereby granting administrator access to the intruder. (Stuart. et. al 2001) Working of the Exploit The exploit works on the basis of buffer overflow process. Buffer overflow is nothing but filling up the memory by passing unwanted instructions one too many. If there is a failure on the part of the receiving application to check its incoming requests, then buffer overflow is bound to happen with a very high probability. As a result, the actual data requests that are considered to be over flown return to a stack maintained by the operating system which is then processed with high privileges. (David & Mark 2000) The high privilege access is granted to the corresponding application because of the overflow status and hence operations that are normally restricted to the application, suddenly become accessible. Consequently, admits to access are given to intruders thereby allowing them to modify user accounts and commands passed out to the shell. On analysis, it is found that this status is brought into action by the attackers using a parameter in the function written for the DCOM interface. (Porter 2003) CoGetInstanceFromFile HRESULT CoGetInstanceFromFile( COSERVERINFO * pServerInfo, CLSID * pclsid, IUnknown * punkOuter, DWORD dwClsCtx, DWORD grfMode, OLECHAR * szName, ULONG cmq, MULTI_QI * rgmqResults ); (Porter 2003) In the above function, a new object is created from a file, and the parameter ‘szname’ is used for mentioning the name of the file from which the object is to be initialized. The actual size of the parameter is 32 bytes but the loophole here is that the size of the incoming value is not validated and hence every time any value with size greater than 32 bytes arrives, it overflows the allocated space and causing the buffer to overflow. So, an attacker who tries to send high level instructions that are to be executed, he can do so by sending that instruction through this field. The initial exploit sent instructions that execute a shell command on the port number 4444. (Davis. et al 2009) The basic steps that were followed while trying out this exploit in an experimental version are given below. It is to be noted that it did not take more than 90 seconds for the entire operation to get completed. The attacker connects to the victim’s machine through port number 135 using TCP. Then the attacker sends out an RPC request where the instruction is mentioned as the file name exceeding the size of 32 bytes. This causes a buffer overflow. Having returned, causes instructions to be executed in the OS to open a listening port in number 4444. Once done, the attacker gets access to the victim’s machine. So, once an exploit is done, initial symptoms include the system trying to shut down for a multiple number of times or in few rare occasions, it becomes dead – idle state. Sometimes, the system displays a 60 second timer before shutting down indicating that an RPC request has been abruptly terminated and hence causing an emergency shutdown. Since the bulletin MS03-026 released and an exploit been discovered with a proof of concept, the security administrations and several users of the Internet waited with bated breath for worms that might take advantage of this vulnerability in the most popular operating system of the world. Two months after the identification of the vulnerability, a variant of the Exploit, called as the “MS-Blaster” came into existence affecting large number of the operating systems. Efforts have been taken and have been successful in terminating and preventing the presence of MS-Blaster worm in systems. But then, different varieties of the exploits have continued to prop up and Microsoft, on its part, as releaser several patches and have been installed in the systems through Windows automatic updates to counter attack these variations. (Reuvid 2004) Effects Some of the immediacies of this vulnerability if exploited include allowing the intruder with administrative accesses. So, the intruder becomes capable to modify the system access privileges, creation and deletion of user accounts, acceptance of installing new, probable harmful programs and the most severe of all being the mismanagement of data. Mitigation The first thing that needs to be done in mitigating this exploit is to identify whether the operating system does belong to the versions which are vulnerable. Once identified to be so, then the next step is to identify whether the patch issued in correspondence with that by Microsoft is installed or not. If the patch was installed through automatic updates without the user’s knowledge then the user can check for its presence through the registry values. In a network oriented system or a system connected in a multiple interconnected network, an investigation of the patch’s presence in the system can be done through the process of network scanning. Some of the tools that are available for this process include the eYE digital security, Microsoft scanning tool etc.(Porter 2003) As networks are known to be in dynamic status, it is mandatory to regularly check for the vulnerability status of the systems present in the network through these tools. In case of Virtual networks, it becomes all the more important for the presence of these scanning tools in the systems as there is remote access applicability. (Chris 2007) Another mitigating option is the use of antivirus software which is updated frequently to identify the variants of the exploits such as the MS-Blaster etc. Most of such software are continuously updated through internet and hence keep the systems up-to-date with the latest versions of the exploit. If all the above options turn to be futile, the final action that could be taken by the user is to disable any services offered by the DCOM interface. Other options that resolve this issue includes additional monitoring of networks, usage of systems that alert in case of any intrusions into the shell and enabling ports with a filter option. Conclusion The report has detailed about the vulnerability that was present in the Windows operating systems, the exploits that ventured into this vulnerability and the impact it had on several systems. The technical specifications of the process undergone for this exploit have been discussed and several mitigation options that were successful in terminating this exploit have been entertained. During its existence, the RPC DCOM vulnerability became a rage and created an overwhelming fear across all Windows users. Going forward, it is a very rare scenario for any of it to happen again. The exploit used have gone outdated and new exploits have come into the picture for gaining remote access to systems. But, one could never negate the fact that as long as there is an interconnecting network between systems across the world, out of which at least very few being vulnerable, there is always a possibility for this exploit to surface itself in the ever-growing hacking market. Works Cited CVE-2003-0352. CVE.com http://www.cvedetails.com/cve/CVE-2003-0352/. 18 August, 2003. Web. 18 Jan 2011. Reuvid, Jonathan. The Secure online business handbook: e-Commerce, IT functionality, & business continuity. New York: Kogan Page Publishers. 2004. Print Microsoft TechNet "Microsoft Security Bulletin MS03-026". http://www.microsoft.com/technet/security/bulletin/MS03-026.asp. Aug. 23, 2003. Web. 18 Jan., 2011. O’Shea, Kevin. Examining the RPC DCOM Vulnerability: Developing a Vulnerability-Exploit Cycle. http://www.sans.org/reading_room/whitepapers/threats/examining-rpc-dcom-vulnerability-developing-vulnerability-exploit-cycle_1220 3 Sep. 2003. Web. 18 Jan. 2011 Porter, Brian. RPC-DCOM Vulnerability & Exploit (CVE # CAN-2003-0352). SANS Institution.https://www.giac.org/certs/include.php?id=503&cert=gcih&c=6203efa1e18401f74c8870e2f54fbb3b 2 Nov. 2003. Web. 18 Jan. 2011. Douglas E. Comer. Internetworking with TCP/IP: Volume 1 – Principles, Protocols and Architecture. London: Prentice Hall. 1995. Print. Chris McNab. Network Security Assessment: Know Your Network. UK: O’Reilly. 2007. Print. Stuart McClure. Et. al. Hacking Exposed. UK: Osborne publications. 2009. Print Philip Cox & Tom Sheldon. Windows 2000 Security Handbook. UK: Osborne. 2001. Print. David A. Solomon & Mark E. Russinovish. Inside Microsoft Windows 2000. New York: Microsoft Press. 2000. Print. Internet Security Systems, Microsoft Windows 2000 Security Technical Reference. NY: Microsoft Press. 2000. Print Davis. Et al. Hacking Exposed: Malware and Rootkits. UK: Osborne. 2009. Print Microsoft MSDN "The RPC Model". http://msdn.microsoft.com/library/default.asp?url=/library/enus/ rpc/rpc/microsoft_rpc_model.asp. Aug. 25, 2003. Web. 18 Jan., 2011. Arbaugh William. et. al Windows of Vulnerability: A Case Study Analysis. http://www.cs.umd.edu/~waa/pubs/Windows_of_Vulnerability.pdf 2000. Web. 18 Jan 2011. LSD Research Group. “Buffer Overrun in Windows RPC Interface.” http://www.lsd-pl.net/special.html 16 July, 2003. Web. 18 Jan 2011. Read More