WO2023229065A1 - 리버싱 엔진과 cdr 엔진을 활용한 악성 비실행 파일 차단 방법 및 장치 - Google Patents

리버싱 엔진과 cdr 엔진을 활용한 악성 비실행 파일 차단 방법 및 장치 Download PDF

Info

Publication number
WO2023229065A1
WO2023229065A1 PCT/KR2022/007477 KR2022007477W WO2023229065A1 WO 2023229065 A1 WO2023229065 A1 WO 2023229065A1 KR 2022007477 W KR2022007477 W KR 2022007477W WO 2023229065 A1 WO2023229065 A1 WO 2023229065A1
Authority
WO
WIPO (PCT)
Prior art keywords
result
engine
file
detoxification
content
Prior art date
Application number
PCT/KR2022/007477
Other languages
English (en)
French (fr)
Inventor
양승환
Original Assignee
시큐레터 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 시큐레터 주식회사 filed Critical 시큐레터 주식회사
Priority to KR1020227017840A priority Critical patent/KR102470010B1/ko
Priority to PCT/KR2022/007477 priority patent/WO2023229065A1/ko
Publication of WO2023229065A1 publication Critical patent/WO2023229065A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/14—Protecting executable software against software analysis or reverse engineering, e.g. by obfuscation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements

Definitions

  • This disclosure relates to a method and device for blocking malicious non-executable files. More specifically, it relates to a method and device for blocking malicious non-executable files using a reversing engine and a CDR engine.
  • APT Advanced Persistent Threat
  • Non-PE non-portable executable files containing malicious code are often used rather than executable (portable executable, PE) files.
  • a non-executable file is the opposite of an executable file and refers to a file that does not run on its own.
  • Examples of non-executable files include document files such as Word files, Excel files, Hangul files, and PDF files, image files, video files, JavaScript files, and HTML files.
  • the reason why non-executable files containing malicious code are often used in APT attacks is because applications that run non-executable files have a certain degree of security vulnerability.
  • variant malicious code can be easily created by changing the file.
  • a document action is the act of executing an action in an application program involving a non-executable file. Since existing APT solutions operate based on document behavior, they determine whether it is malicious by observing changes in the sandbox (Virtural Machine, VM) after document behavior occurs. This takes a long time to analyze because it waits for all document actions to occur before determining whether they are malicious.
  • VM Virtual Machine
  • the problem that this disclosure aims to solve is to provide a method and device for blocking malicious non-executable files using a reversing engine and a CDR engine.
  • a method for a server to block malicious non-executable files using a reversing engine and a CDR engine involves reversing the non-executable files to be analyzed. performing analysis to detect at least one of vulnerabilities and content in the non-executable file to be analyzed, and storing the detection result; Performing detoxification on content in the non-executable file to be analyzed and storing the detoxification result; generating a read result for the detoxified file obtained by performing the detoxification, based on the detection result and the detoxification result; and blocking the decommissioned file based on the read result.
  • CDR engine Content Disarm and Reconstruction engine
  • a server that performs a method of blocking malicious non-executable files using a reversing engine and a CDR engine includes: a communication unit; a memory including the reversing engine and the CDR engine; processor; and a result reading unit, wherein the processor functionally controls the communication unit and the memory, and uses the reversing engine to perform reversing analysis on the non-executable file to be analyzed, Detect at least one of a vulnerability and content, store the detection result, perform detoxification on the content in the non-executable file to be analyzed using the CDR engine, and store the detoxification result. Based on the detection result and the detoxification result, the reading unit generates a read result for the detoxified file obtained by performing the detoxification, and blocks the detoxified file based on the read result.
  • FIG. 1 is a block diagram showing the configuration of an electronic device related to an embodiment of the present disclosure.
  • Figure 2 is a block diagram showing the configuration of a device for blocking malicious non-executable files according to an embodiment of the present disclosure.
  • Figure 3 is a diagram illustrating normal input and abnormal input that can be applied to an embodiment of the present disclosure.
  • Figure 4 is a diagram illustrating the execution flow of an application when a normal value is input and the execution flow of an application when an abnormal value is input.
  • Figure 5 is a flowchart illustrating a method for determining document behavior that can be applied to an embodiment of the present disclosure.
  • Figure 6 is a flowchart illustrating a method for blocking non-executable files that can be applied to an embodiment of the present disclosure.
  • FIG. 7 is a flowchart specifically illustrating the detection result storage step (S6100) of FIG. 6.
  • Figure 8 is a diagram showing an example of a detection result by a reversing engine.
  • Figure 9 is a diagram showing another example of a detection result by a reversing engine.
  • FIG. 10 is a flow chart specifically illustrating the detoxification result storage step (S6200) of FIG. 6.
  • Figure 11 is a diagram showing an example of the detoxification result by the CDR engine.
  • Figure 12 is a diagram showing another example of the detoxification result by the CDR engine.
  • FIG. 13 is a flowchart specifically illustrating the read result generation step (S6300) of FIG. 6.
  • Figure 14 is a diagram illustrating a reading result screen displayed through a terminal.
  • unit refers to a software or hardware component, and the “unit” performs certain roles. However, “wealth” is not limited to software or hardware.
  • the “copy” may be configured to reside on an addressable storage medium and may be configured to run on one or more processors.
  • part refers to software components, such as object-oriented software components, class components, and task components, processes, functions, properties, procedures, Includes subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.
  • the functionality provided within the components and “parts” may be combined into smaller numbers of components and “parts” or may be further separated into additional components and “parts”.
  • unit may be implemented with a processor and memory.
  • processor should be interpreted broadly to include general purpose processors, central processing units (CPUs), microprocessors, digital signal processors (DSPs), controllers, microcontrollers, state machines, etc.
  • processor may refer to an application-specific integrated circuit (ASIC), programmable logic device (PLD), field programmable gate array (FPGA), etc.
  • ASIC application-specific integrated circuit
  • PLD programmable logic device
  • FPGA field programmable gate array
  • processor refers to a combination of processing devices, for example, a combination of a DSP and a microprocessor, a combination of a plurality of microprocessors, a combination of one or more microprocessors in combination with a DSP core, or any other such combination of configurations. It may also refer to
  • memory should be interpreted broadly to include any electronic component capable of storing electronic information.
  • the terms memory include random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), programmable read-only memory (PROM), erasable-programmable read-only memory (EPROM), electrical may refer to various types of processor-readable media, such as erasable PROM (EEPROM), flash memory, magnetic or optical data storage, registers, etc.
  • RAM random access memory
  • ROM read-only memory
  • NVRAM non-volatile random access memory
  • PROM programmable read-only memory
  • EPROM erasable-programmable read-only memory
  • electrical may refer to various types of processor-readable media, such as erasable PROM (EEPROM), flash memory, magnetic or optical data storage, registers, etc.
  • EEPROM erasable PROM
  • flash memory magnetic or optical data storage, registers, etc.
  • Non-executable file' as used herein is the opposite of an executable file or executable file and refers to a file that does not execute on its own.
  • non-executable files may be document files such as PDF files, Hangul files, Word files, image files such as JPG files, video files, JavaScript files, HTML files, etc., but are not limited thereto.
  • FIG. 1 is a block diagram showing the configuration of an electronic device related to an embodiment of the present disclosure.
  • the electronic device 100 includes a wireless communication unit 110, an input unit 120, a sensing unit 140, an output unit 150, an interface unit 160, a memory 170, a control unit 180, and a power supply unit 190. ), etc. may be included.
  • the components shown in FIG. 1 are not essential for implementing the electronic device 100, so the electronic device 100 described herein may have more or fewer components than those listed above. there is.
  • the wireless communication unit 110 is used between the electronic device 100 and the wireless communication system, between the electronic device 100 and another electronic device 100, or between the electronic device 100 and an external server. It may include one or more modules that enable wireless communication. Additionally, the wireless communication unit 110 may include one or more modules that connect the electronic device 100 to one or more networks.
  • This wireless communication unit 110 may include at least one of a broadcast reception module 111, a mobile communication module 112, a wireless Internet module 113, a short-range communication module 114, and a location information module 115.
  • the input unit 120 may include a camera 121 or an image input unit for inputting an image signal, a microphone 122 or an audio input unit for inputting an audio signal, and a user input unit 123 for receiving information from a user.
  • Examples of the user input unit 123 include touch keys and push keys (mechanical keys). Voice data or image data collected by the input unit 120 may be analyzed and processed as a user's control command.
  • the sensing unit 140 may include one or more sensors for sensing at least one of information within the electronic device 100, information on the surrounding environment surrounding the electronic device 100, and user information.
  • the sensing unit 140 includes a proximity sensor 141, an illumination sensor 142, a touch sensor, an acceleration sensor, and a magnetic sensor.
  • gravity sensor G-sensor
  • gyroscope sensor motion sensor
  • RGB sensor infrared sensor
  • IR sensor fingerprint scan sensor
  • ultrasonic sensor sensor an optical sensor such as the camera 121
  • a battery gauge an environmental sensor (e.g., a barometer, a soil hygrometer, a thermometer, a radiation detection sensor, a heat detection sensor, a gas detection sensor, etc.)
  • an environmental sensor e.g., a barometer, a soil hygrometer, a thermometer, a radiation detection sensor, a heat detection sensor, a gas detection sensor, etc.
  • chemical sensors eg, electronic nose, healthcare sensor, biometric sensor, etc.
  • the electronic device 100 disclosed in this specification can utilize information sensed by two or more of the illustrated sensors by combining them.
  • the output unit 150 is used to generate output related to vision, hearing, or tactile senses.
  • the output unit 150 may include at least one of a display unit 151, an audio output unit 152, a haptip module 153, and an optical output unit 154.
  • the display unit 151 can implement a touch screen by forming a layered structure or being integrated with the touch sensor. This touch screen functions as a user input unit 123 that provides an input interface between the electronic device 100 and the user, and can simultaneously provide an output interface between the electronic device 100 and the user.
  • the interface unit 160 serves as a passageway for various types of external devices connected to the electronic device 100.
  • This interface unit 160 is provided with a wired/wireless headset port, an external charger port, a wired/wireless data port, a memory card port, and an identification module. It may include at least one of a port for connecting a connected device, an audio input/output port, a video input/output port, and an earphone port.
  • the electronic device 100 may perform appropriate control related to the connected external device.
  • the memory 170 stores data supporting various functions of the electronic device 100.
  • the memory 170 may store a plurality of application programs (application programs or applications) running on the electronic device 100, data for operating the electronic device 100, and commands. At least some of these applications may be downloaded from an external server via wireless communication. In addition, at least some of these applications will be present on the electronic device 100 from the time of shipment for the basic functions of the electronic device 100 (e.g., call incoming call function, call outgoing function, message receiving function, message sending function). You can. Meanwhile, the application program may be stored in the memory 170, installed on the electronic device 100, and driven by the control unit 180 to perform an operation or function of the electronic device.
  • control unit 180 In addition to operations related to the application program, the control unit 180 typically controls the overall operation of the electronic device 100.
  • the control unit 180 can provide or process appropriate information or functions to the user by processing signals, data, information, etc. input or output through the components discussed above, or by running an application program stored in the memory 170.
  • control unit 180 may control at least some of the components examined with FIG. 1 in order to run an application program stored in the memory 170. Furthermore, the control unit 180 may operate at least two of the components included in the electronic device 100 in combination with each other in order to run the application program.
  • the power supply unit 190 receives external power and internal power under the control of the control unit 180 and supplies power to each component included in the electronic device 100.
  • This power supply unit 190 includes a battery, and the battery may be a built-in battery or a replaceable battery.
  • At least some of the components may cooperate with each other to implement operation, control, or a control method of the electronic device 100 according to various embodiments described below. Additionally, the operation, control, or control method of the electronic device 100 may be implemented on the electronic device 100 by running at least one application program stored in the memory 170.
  • a server may include an electronic device 100, and the electronic device 100 may be collectively referred to as a terminal.
  • the terminal can communicate with an external server (or external cloud server) by being connected to a network.
  • FIG. 2 is a block diagram showing the configuration of a device for blocking malicious non-executable files according to an embodiment of the present disclosure.
  • the malicious non-executable file blocking device will be referred to as 'server'.
  • the server 200 may include a control unit 210, a result reading unit 220, and a communication unit 230.
  • the control unit 210 may include a processor 212 and a memory 214.
  • the processor 212 may execute instructions stored in the memory 214.
  • the processor 212 can control the communication unit 230.
  • Memory 214 may include cache memory. Cache memory can temporarily store original documents, which will be described later, for a certain period of time.
  • the processor 212 may control the operation of the server 200 based on instructions stored in the memory 220.
  • the server 200 may include one processor or may include multiple processors. When the server 200 includes a plurality of processors, at least some of the plurality of processors may be located physically spaced apart from each other. Additionally, the server 200 is not limited to this and may be implemented in various known ways.
  • the communication unit 230 may include one or more modules that enable wireless communication between a server and a wireless communication system, between a server and another server, or between a server and an external server (terminal). Additionally, the communication unit 230 may include one or more modules that connect servers to one or more networks.
  • the control unit 210 may control at least some of the components of the server to run the application program stored in the memory 214. Furthermore, the control unit 210 can operate at least two of the components included in the server in combination with each other to run the application program.
  • the server 200 may include a reversing engine and a CDR engine.
  • a reversing engine and a CDR engine will be described in detail.
  • the reversing engine is an analysis and diagnosis engine that automates the reverse engineering process for malicious non-executable files. This is called reverse engineering, and through this, the server 200 can learn about the principles and structure of the software by going up to the assembly level, a language that allows a computer to execute software without source code. Using this, the server 200 can know the structure of general software (eg, MS Office, PDF), malicious code behavior, and methods of exploiting vulnerabilities.
  • general software eg, MS Office, PDF
  • the reversing engine may perform a file analysis step, a static analysis step, a dynamic analysis step, and a debugging analysis step.
  • a file analysis step may perform a file analysis step, a static analysis step, a dynamic analysis step, and a debugging analysis step.
  • File analysis step This is the step of analyzing the appearance of the non-executable file itself (e.g., properties, author, creation date, file type). Similar to a general anti-virus program, it diagnoses whether it is malicious using only the information of the non-executable file itself. can do.
  • Static analysis step This is a step to extract and analyze data in non-executable files to determine whether they are normal or malicious. Non-executable files are not executed, but internal data is extracted and compared and analyzed according to the file structure to diagnose maliciousness. You can. This may be suitable for extracting and analyzing macros and extracting and analyzing URLs.
  • Dynamic analysis stage This is the stage where non-executable files are executed and monitored while their behavior is analyzed to determine whether they are malicious. This is to detect malicious behavior using the normal functions of the document, such as macros, hyperlinks, and DDE (Dynamic Data Exchange). It is easy to
  • Debugging analysis stage This is the stage of analyzing vulnerabilities, exploits, etc. by executing and debugging non-executable files. It not only detects malicious behavior using normal functions of the document such as macros, hyperlinks, DDE, etc., but also analyzes the body of the document. , it is suitable for detecting vulnerabilities in applications using tables, fonts, pictures, etc.
  • the reversing engine may include a debugging engine that can be used for debugging analysis.
  • the debugging engine can use the debugging mode during the viewing process of non-executable files to diagnose vulnerabilities that occur in the document input, processing, and output stages.
  • vulnerabilities refer to errors, bugs, etc. that occur when an application receives unexpected values from the code (logic) developed by the application developer.
  • an attacker can execute malicious document actions such as denial of service due to abnormal termination or remote code execution.
  • the debugging engine may include a debugger.
  • a debugger is a tool for reverse engineering and can refer to a program or process that can set a breakpoint at the assembly level for another target program.
  • Figure 3 is a diagram illustrating normal input and abnormal input that can be applied to an embodiment of the present disclosure.
  • Figure 3(a) is a diagram to explain a case where an application program receives a normal value through a non-executable file, and illustrates a case where the value of the Extended Counter Register (ECX) is normal data (00000001).
  • Figure 3(b) is a diagram to explain a case where an application program receives an abnormal value through a non-executable file, and illustrates a case where the value of the ECX register is abnormal data (000000CC).
  • Figure 4 is a diagram illustrating the execution flow of an application when a normal value is input and the execution flow of an application when an abnormal value is input.
  • Figure 4(a) shows the execution flow of the application program when the application program receives normal values through a non-executable file.
  • Figure 4(b) shows how the execution flow of the application program changes when the application program receives an abnormal value through a non-executable file.
  • the debugging engine automatically debugs the document viewing process and sets breakpoints at specific points related to vulnerabilities. Additionally, it is possible to diagnose maliciousness by checking specific values (values stored in registers or memory) related to the input value to determine whether the input value is a value that causes a vulnerability.
  • the debugging engine can determine the type of non-executable file and then start debugging by running an application to view the non-executable file.
  • the debugging engine checks whether the loaded module is the module to be analyzed. As a result of the confirmation, if the loaded module is the target of analysis, a breakpoint can be set at the specified address.
  • a malicious non-executable file may terminate the application if it does not meet certain conditions, such as the application version or operating system environment, or may have branching points that diverge to a flow in which no malicious action occurs.
  • the server 200 may be analyzed by an analyst in advance, and a breakpoint may be set at a branching point having this possibility.
  • server 200 may set conditions in association with the branch point that may continue to run the application without terminating it or lead to a flow in which malicious actions may occur.
  • the server 200 may detect vulnerabilities according to detection logic and then perform a step of storing the detection results.
  • the stored detection result may be understood as a detection result report.
  • the automated reversing engine included in the server 200 automatically performs and analyzes the above-mentioned steps, and can diagnose and block malicious non-executable files through a diagnostic algorithm researched and developed by an analyst.
  • the CDR engine provides CDR services.
  • the CDR service is a solution that disassembles non-executable files, removes malicious or unnecessary files, and creates new files by keeping the content as identical as possible to the original.
  • CDR refers to a service that disarms and reconstructs the content in a document to create a safe document and provide it to customers.
  • the file subject to detoxification may be any non-executable file. Examples of non-executable files include Word files, Excel files, PowerPoint files, Hangul files, and PDF files.
  • Content subject to detoxification may be active content. Examples of active content include macros, hyperlinks, and Object Linking and Embedding (OLE).
  • the CDR engine may perform detoxification on content in a non-executable file and store the detoxification result. The stored detoxification result may be understood as a detoxification result report.
  • the result reading unit 220 generates a reading result for the decommissioned file based on the detection result provided from the reversing engine and the decommissioning result provided from the CDR engine. And based on the reading results, the detoxified file is allowed or blocked.
  • a detoxified file refers to a file for which detoxification has been completed. The results of reading the detoxified file and/or whether the detoxified file is blocked may be transmitted to the user's terminal and output through the terminal's output unit.
  • Figure 5 is a flowchart illustrating a method for determining document behavior that can be applied to an embodiment of the present disclosure.
  • the server 200 may include a non-executable file and an application program for executing the non-executable file (eg, MS Office, Hancom Office, etc.).
  • a non-executable file e.g., MS Office, Hancom Office, etc.
  • an application program for executing the non-executable file eg, MS Office, Hancom Office, etc.
  • the server 200 executes the application process in debugging mode (S4010).
  • the server 200 may execute a document process to open a non-executable file to be analyzed for an application program in debugging mode (DEBUG_ONLY_THIS_PROCESS) using the CreateProcess API. Through this, the server 200 can receive debug events of the application process.
  • the server 200 can execute an application process by setting the “DEBUG_ONLY_THIS_PROCESS” flag using the CreateProcess API.
  • the server 200 sets a first breakpoint at a point matching document behavior based on the application process (S4020). For example, the server 200 may set a breakpoint by changing the operating (OP) code related to the process of the application program loaded in the memory 214 to “0xCC”. OP code refers to an instruction code and may be a code in which the content of work to be actually performed by the CPU is written. To this end, the server 200 can change the memory 214 using WriteProcessMemory.
  • the server 200 may have information about document actions and points at which the corresponding document actions are matched in advance.
  • the server 200 can install a breakpoint using the WriteProcessMemory API according to a predefined behavior matching breakpoint table.
  • the server 200 checks whether a non-executable file is running (S4030). More specifically, after setting a breakpoint, the server 200 checks whether other non-executable files for which analysis has been requested are being viewed. Depending on the function required by the non-executable file, the application process loads the necessary modules into the memory 214, so in order to ensure the reliability of determining the document behavior of the target non-executable file, the application program ensures that other non-executable files are not viewed. Must have status. For example, if a malicious non-executable file has been viewed, the reliability of the document behavior judgment result may be reduced.
  • the server 200 executes the non-executable file to be analyzed based on the fact that other non-executable files are not running (S4040). More specifically, the server 200 views the non-executable file that the user has requested analysis using an application program process (eg, EXCEL, WORD, PPT, etc.) appropriate for the format. For example, the server 200 can view the sample.ppt file using MS Power point.
  • an application program process eg, EXCEL, WORD, PPT, etc.
  • the server 200 determines whether a new module related to the non-executable file to be analyzed has been loaded on the memory 214 (S4050). When the non-executable file to be analyzed is executed by the application process, the server 200 checks whether a new module is loaded.
  • the server 200 can use the debugging mode to receive a debugging event when it occurs in an application process.
  • the server 200 may use the event to determine that a new module (for example, DLL memory is installed) when a LOAD DLL event occurs.
  • the server 200 may determine that a new module has been loaded into the memory 214 when the “LOAD_DLL_DEBUG_EVENT” event occurs.
  • the server 200 may load a new module suitable for the application process function into the memory 214 in order to use the necessary functions (e.g., macros, ActiveX functions, etc.) in the non-executable file to be analyzed. there is.
  • necessary functions e.g., macros, ActiveX functions, etc.
  • the server 200 sets a second breakpoint at a point matching document behavior based on the loading of the new module (S4060). If it is not determined that a new module has been loaded, the server 200 does not set a second breakpoint.
  • the server 200 monitors whether the application process is stopped at the first breakpoint and/or the second breakpoint (S4070). For example, the server 200 may check whether the application process is stopped at the breakpoint and process control is transferred to the debugger. The debugger that has taken over control can check at what breakpoint it stopped.
  • the server 200 generates document behavior information matching the first breakpoint and/or the second breakpoint based on the monitoring results (S4080). For example, the server 200 can check the address value of the breakpoint. Thereafter, the server 200 may generate information about the document action matched with the address value of the breakpoint based on the information about the corresponding document action and the point at which the corresponding document action matches, and store this information as a detection result.
  • Table 1 below is an example of document behavior matched with the address value of the stored breakpoint.
  • server 200 may perform additional actions to obtain document actions.
  • the server 200 determines whether the viewing of the non-executable file to be analyzed has ended (S4090). For example, the server 200 may determine whether the viewing of the non-executable file to be analyzed has ended in a manner such as when a preset time has passed or when a message box (Alert) or a breakpoint has not been reached for a certain period of time.
  • the server 200 may determine whether the viewing of the non-executable file to be analyzed has ended in a manner such as when a preset time has passed or when a message box (Alert) or a breakpoint has not been reached for a certain period of time.
  • the server 200 continuously monitors whether the application process is stopped at a breakpoint. Through this, the server 200 can wait for document actions to fully occur.
  • the server 200 may transmit the stored document behavior information to the terminal.
  • the terminal can communicate with the server 200 and may include a management application that can control the operation of the server.
  • the terminal can provide document behavior information to the user through a management application.
  • server 200 of the present specification may start analysis from the time the application process is executed in the stage before the sandbox is changed.
  • the analysis speed is faster than existing APT solutions.
  • Figure 6 is a flowchart illustrating a method for blocking non-executable files that can be applied to an embodiment of the present disclosure.
  • the reversing engine of the server 200 performs a reversing analysis on the input non-executable file and stores the detection results for vulnerabilities and/or malicious active content (S6100).
  • the detection result is provided to the result reading unit 220. A more detailed description of step S6100 will be described later with reference to FIGS. 7 to 9.
  • the CDR engine of the server 200 performs detoxification on the content in the input non-executable file and stores the detoxification result (S6200). At this time, step S6200 does not necessarily have to be executed after step S6100, and steps S6200 and S6100 may be performed simultaneously.
  • the detoxification result is provided to the result reading unit 220. A more detailed description of step S6200 will be described later with reference to FIGS. 10 to 12.
  • the result reading unit 220 of the server 200 generates a final reading result for the detoxified file based on the detection result provided from the reversing engine and the detoxification result provided from the CDR engine (S6300).
  • the reading results include the type of non-executable file entered, the content detected by the reversing engine (e.g. vulnerabilities, macros, hyperlinks, JavaScript), whether the detected content can be rendered harmless by the CDR engine, It may include one or more of whether the detected content has been detoxified by the CDR engine and whether the detoxified file is safe.
  • the type and/or number of information to be included in the reading result may be implemented to be changeable by the user.
  • the generated reading result may be provided to the user's terminal and may be output in the form of an audio signal and/or a video signal through an output unit of the terminal.
  • FIG. 7 is a flowchart specifically illustrating the detection result storage step (S6100) of FIG. 6.
  • Step S6110 may be understood as the document behavior determination method shown in FIG. 5.
  • the reversing engine determines whether there are results detected by the reversing analysis (S6120). For example, it determines whether there are vulnerabilities or malicious active content detected in non-executable files.
  • the CDR engine of the server 200 determines whether the detection result can be rendered harmless (S6130).
  • the determination may be made based on the type of CDR engine. This is because detoxification coverage varies depending on the type of CDR engine.
  • harmless coverage can be understood as a concept that includes one or more of a harmless file and a harmless content.
  • detoxification is not possible for content called JavaScript, but macro, Flash, object connection insertion, It is possible to detoxify content such as Active X, Embedded Document, Hyperlink, and Attachments.
  • step S6130 if the corresponding detection result cannot be detoxified in the CDR engine, a label that cannot be detoxified is recorded on the corresponding detection result (S6140).
  • step S6130 if the corresponding detection result can be detoxified in the CDR engine, a detoxification possible label is recorded in the corresponding detection result (S6150).
  • the detection result is stored (S6160).
  • the detection result may have an XML format, for example, but is not limited to the format shown.
  • the detection results by the reversing engine will be described with reference to FIGS. 8 and 9.
  • Figure 8 is a diagram showing an example of a detection result by a reversing engine.
  • the detection result is in XML format. You can see that "CVE-2017-11826.RE.300” is recorded in the “Name” item, and the value 'false' is recorded in the "isPossibelCDR” item. This means that a text vulnerability was detected in the debugging engine while running the reversing analysis, and the detected text vulnerability cannot be detoxified in the CDR engine.
  • Figure 9 is a diagram showing another example of a detection result by a reversing engine.
  • the vulnerability detection result is in XML format. And you can see that "_DownloaderMacro” is recorded in the “exploitName” item, and the value 'ture' is recorded in the "isPossibleCDR” item. This means that a malicious macro was detected in the debugging engine while running the reversing analysis, and the detected malicious macro can be rendered harmless in the CDR engine.
  • FIG. 10 is a flow chart specifically illustrating the detoxification result storage step (S6200) of FIG. 6.
  • the CDR engine determines whether content subject to detoxification exists in the input non-executable file (S6210).
  • Content subject to detoxification may be active content such as macros, hyperlinks, and object connection insertions.
  • step S6210 if content to be detoxified exists in the non-executable file, detoxification is performed on the content to be detoxified (S6220). Since content detoxification is a known technology, detailed description of it will be omitted.
  • the CDR engine determines whether content detoxification was successful (S6230).
  • step S6230 If, as a result of the determination in step S6230, the content has failed to be rendered harmless, the failure to render the content harmless is recorded in the detoxification result (S6240).
  • step S6230 If, as a result of the determination in step S6230, the content has been successfully detoxified, the successful detoxification is recorded in the detoxification results (S6250).
  • step S6210 if there is no content subject to detoxification in the non-executable file, this fact is recorded in the detoxification result (S6260).
  • Figure 11 is a diagram showing an example of the detoxification result by the CDR engine.
  • the value 'true' is recorded in the 'result' item, which means that the non-executable file is harmless.
  • the value 'SUCCESS' is recorded in the 'status' item, which means that the detoxification target content in the non-executable file was successfully detoxified.
  • CDR Process Success is recorded, which means that detoxification was successfully performed in the CDR engine.
  • the value 'NO DETECTION' is recorded in the 'status' item. And the non-executable file is also judged to be harmless, so the value 'true' is recorded in the 'result' field.
  • the detoxification result may also include 'fileType', 'inputFileName', 'inputFullPath', 'outputFileName', 'outputFullPath', 'elapsedTime', and 'cdrEntities' items.
  • the 'fileType' item is where the type of non-executable file is recorded.
  • the 'inputFileName' and 'inputFullPath' items are where the name of the non-executable file and the storage path of the non-executable file are recorded, respectively.
  • the 'outputFileName' and 'outputFullPath' items are where the name of the detoxified file and the storage path of the detoxified file are recorded, respectively.
  • the 'elapsedTime' item is where the time taken for detoxification is recorded.
  • the 'cdrEntities' item is where the properties of the data storing the detoxification results are recorded. The fact that 'Array' is written in the 'cdrEntities' field means that the detoxification results are stored in array form.
  • Figure 12 is a diagram showing another example of the detoxification result by the CDR engine.
  • the value 'false' is recorded in the 'result' item, which means that the non-executable file is not harmless.
  • the value "FAILURE” is recorded in the 'status' item, which means that detoxification failed for the content to be detoxified in the non-executable file.
  • "I/O Error Occurs” is recorded, which means that a detoxification failure error may occur due to an input/output error for the file.
  • FIG. 13 is a flowchart specifically illustrating the read result generation step (S6300) of FIG. 6.
  • the result reading unit 220 checks the detection result provided from the reversing engine (S6310) and determines whether there is a target (eg, vulnerability, malicious active content) with a label that cannot be detoxified (S6320).
  • a target eg, vulnerability, malicious active content
  • step S6320 if there is no object with a non-harmful label, the result reading unit 220 determines that there is an object with a label that can be harmless. Then, the detoxification result provided from the CDR engine is checked (S6330) to determine whether the detoxification of the object with the detoxification possible label was successful (S6340).
  • step S6340 if detoxification is successful for the object with the detoxification possible label, the result reading unit 220 generates a reading result indicating that the detoxified file is safe (S6350).
  • step S6340 if detoxification has failed for the content with the label capable of detoxification, the result reading unit 220 generates a reading result indicating that the detoxified file is dangerous (S6380).
  • the result reading unit 220 may allow or block the deactivated file based on the reading result. Specifically, if the detoxified file is read as safe, the detoxified file is allowed. Conversely, if the detoxified file is read as dangerous, the detoxified file is blocked.
  • the result reading unit 220 can provide the reading result of the detoxified file to the user's terminal and output it through the output unit.
  • Figure 14 is a diagram illustrating a reading result screen displayed through a terminal.
  • the read result screen may include the type of the input non-executable file, the detection result of the reversing engine, the detoxification result of the CDR engine, and the final read result of the detoxified file.
  • the detection results of the reversing engine may include information about the detected content and whether the detected content is malicious.
  • Examples of detected content include object vulnerabilities, text vulnerabilities, macros, hyperlinks, object link injection, and JavaScript.
  • the detoxification results of the CDR engine may include information about the detoxification target and whether detoxification was successful for the detoxification target.
  • the body vulnerability detected in the non-executable file was analyzed as malicious and was given a label that cannot be detoxified. Since detoxification is not possible in the CDR engine for detected text vulnerabilities, it can be seen that even if detoxification is successful for the detected macro, the detoxification file output from the CDR engine is read as dangerous.
  • a word file containing a hyperlink is entered as a non-executable file, you can see that the hyperlink has been detected in the reversing engine. It can be seen that the detected hyperlink was analyzed as normal, not malicious, and was given a label that could be made harmless.
  • the analysis result that the detected hyperlink is normal may be a result obtained because it is difficult to detect malicious actions using hyperlinks in the reversing engine. Therefore, by assigning a decommunicable label to the detected hyperlink, saving the detection result, and comparing the saved detection content with the decommissioning result of the CDR engine, more accurate reading results can be obtained for the decommunicated file output from the CDR engine. You can. In fact, since hyperlink detoxification was successful in the CDR engine, it can be seen that the detoxified file output from the CDR engine was read as safe.
  • the disclosed embodiments may be implemented in the form of a recording medium that stores instructions executable by a computer. Instructions may be stored in the form of program code, and when executed by a processor, may create program modules to perform operations of the disclosed embodiments.
  • the recording medium may be implemented as a computer-readable recording medium.
  • Computer-readable recording media include all types of recording media storing instructions that can be decoded by a computer. For example, there may be read only memory (ROM), random access memory (RAM), magnetic tape, magnetic disk, flash memory, optical data storage, etc.
  • ROM read only memory
  • RAM random access memory
  • magnetic tape magnetic tape
  • magnetic disk magnetic disk
  • flash memory optical data storage
  • computer-readable recording media may be provided in the form of non-transitory storage media.
  • 'non-transitory storage medium' simply means that it is a tangible device and does not contain signals (e.g. electromagnetic waves). This term refers to cases where data is semi-permanently stored in a storage medium and temporary storage media. It does not distinguish between cases where it is stored as .
  • a 'non-transitory storage medium' may include a buffer where data is temporarily stored.
  • Computer program products are commodities and can be traded between sellers and buyers.
  • the computer program product may be distributed in the form of a machine-readable recording medium (e.g. compact disc read only memory (CD-ROM)) or via an application store (e.g. Play StoreTM) or on two user devices (e.g. It may be distributed directly between smartphones (e.g. smartphones) or distributed online (e.g. downloaded or uploaded).
  • a machine-readable recording medium e.g. compact disc read only memory (CD-ROM)
  • an application store e.g. Play StoreTM
  • two user devices e.g. It may be distributed directly between smartphones (e.g. smartphones) or distributed online (e.g. downloaded or uploaded).
  • a computer program product e.g., a downloadable app
  • a machine-readable recording medium such as the memory of a manufacturer's server, an application store's server, or a relay server. It can be stored or created temporarily.
  • the method and device for blocking malicious non-executable files using the reversing engine and CDR engine as described above can be applied to the cybersecurity field.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Storage Device Security (AREA)

Abstract

본 개시의 실시예에 따른, 리버싱 엔진(Reversing engine)과 CDR 엔진(Contents Disarm and Reconstruction engine)을 활용한 악성 비실행 파일 차단 방법은, 분석 대상 비실행 파일에 대한 리버싱 분석을 수행하여, 상기 분석 대상 비실행 파일 내의 취약점 및 콘텐츠 중 적어도 하나를 탐지하고, 탐지 결과를 저장하는 단계; 상기 분석 대상 비실행 파일 내의 콘텐츠에 대하여 무해화를 수행하고, 무해화 결과를 저장하는 단계; 상기 탐지 결과 및 상기 무해화 결과에 기초하여, 상기 무해화를 수행하여 얻은 무해화 파일에 대한 판독 결과를 생성하는 단계; 및 상기 판독 결과에 기초하여, 상기 무해화 파일을 차단하는 단계를 포함한다.

Description

리버싱 엔진과 CDR 엔진을 활용한 악성 비실행 파일 차단 방법 및 장치
본 개시는 악성 비실행 파일 차단 방법 및 장치에 관한 것이다. 더욱 상세하게는 리버싱 엔진과 CDR 엔진을 활용한 악성 비실행 파일 차단 방법 및 장치에 관한 것이다.
지능형 지속 위협(Advanced Persistent Threat, APT) 공격은 공격자가 특정 타깃을 정하고 목표한 정보를 빼내기 위해 고도의 공격기법을 적용하여 지속적으로 다양한 형태의 악성 코드를 활용한다. 특히 APT 공격은 초기 침입단계에서 탐지하지 못하는 경우가 많으며, 실행(Portable Executable, PE) 파일보다는 악성 코드를 포함하는 비실행(Non-Portable Executable, Non-PE) 파일을 이용하는 경우가 많다.
비실행 파일은 실행 파일과 반대되는 개념으로써, 자체적으로 실행되지 않는 파일을 의미한다. 비실행 파일로는 워드 파일, 엑셀 파일, 한글 파일, PDF 파일 등의 문서 파일, 이미지 파일, 동영상 파일, 자바스크립트 파일, 및 HTML 파일을 예로 들 수 있다. APT 공격에 악성 코드가 포함된 비실행 파일이 많이 이용되는 이유는 비실행 파일을 실행하는 응용 프로그램이 기본적으로 어느 정도의 보안 취약성을 가지고 있기 때문이다. 뿐만 아니라, 악성 코드를 비실행 파일에 포함시키면 파일을 변경하여 변종 악성 코드를 손쉽게 만들 수 있기 때문이다.
문서 행위란 비실행 파일이 관련된 응용 프로그램의 액션을 실행하는 행위이다. 기존의 APT 솔루션들은 문서 행위 기반으로 동작하기 때문에 문서 행위 발생 후, 샌드박스(Virtural Machine, VM)의 변화를 관찰하여 악성 여부를 판단한다. 이는 문서 행위의 발현을 전부 기다린 후 악성 여부를 파악하기 때문에 분석시간이 오래 걸린다.
또한, CDR과 같은 기존 APT 솔루션들은 악성 액티브 콘텐츠를 제거할 수는 있지만, 문서의 필수 요소(예를 들어, 본문, 폰트)에서 발생하는 취약점을 제거할 수는 없기 때문에 보안 공백이 발생한다.
본 개시가 해결하고자 하는 과제는 리버싱 엔진과 CDR 엔진을 활용한 악성 비실행 파일 차단 방법 및 장치를 제공하는 것이다.
본 개시가 해결하고자 하는 과제들은 이상에서 언급한 과제로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 개시가 속하는 기술분야에서 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
본 개시의 일 실시예에 따르면, 서버가 리버싱 엔진(Reversing engine)과 CDR 엔진(Contents Disarm and Reconstruction engine)을 활용하여 악성 비실행 파일을 차단하는 방법은, 분석 대상 비실행 파일에 대한 리버싱 분석을 수행하여, 상기 분석 대상 비실행 파일 내의 취약점 및 콘텐츠 중 적어도 하나를 탐지하고, 탐지 결과를 저장하는 단계; 상기 분석 대상 비실행 파일 내의 콘텐츠에 대하여 무해화를 수행하고, 무해화 결과를 저장하는 단계; 상기 탐지 결과 및 상기 무해화 결과에 기초하여, 상기 무해화를 수행하여 얻은 무해화 파일에 대한 판독 결과를 생성하는 단계; 및 상기 판독 결과에 기초하여, 상기 무해화 파일을 차단하는 단계를 포함한다.
본 개시의 일 실시예에 따르면, 리버싱 엔진(Reversing engine)과 CDR 엔진(Contents Disarm and Reconstruction engine)을 활용한 악성 비실행 파일 차단 방법을 수행하는 서버는, 통신부; 상기 리버싱 엔진과 상기 CDR 엔진이 포함된 메모리; 프로세서; 및 결과 판독부를 포함하며, 상기 프로세서는 상기 통신부 및 상기 메모리를 기능적으로 제어하며, 상기 리버싱 엔진을 이용하여, 분석 대상 비실행 파일에 대한 리버싱 분석을 수행하여, 상기 분석 대상 비실행 파일 내의 취약점 및 콘텐츠 중 적어도 하나를 탐지하고, 상기 탐지 결과를 저장하며, 상기 CDR 엔진을 이용하여, 상기 분석 대상 비실행 파일 내의 콘텐츠에 대하여 무해화를 수행하고, 무해화 수행 결과를 저장하고, 상기 결과 판독부는 상기 탐지 결과 및 상기 무해화 결과에 기초하여, 상기 무해화를 수행하여 얻은 무해화 파일에 대한 판독 결과를 생성하고, 상기 판독 결과에 기초하여, 상기 무해화 파일을 차단한다.
기타 실시예들의 구체적인 사항들은 상세한 설명 및 도면들에 포함되어 있다.
본 개시의 실시예에 따르면, 리버싱 엔진과 CDR 엔진을 사용함으로써, CDR 엔진만을 사용했을 때 발생할 수 있는 보안 공백을 보완할 수 있다.
본 개시의 효과들은 이상에서 언급된 효과로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 아래의 기재로부터 본 개시가 속하는 기술분야에서 통상의 기술자에게 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 개시의 실시예와 관련된 전자 기기의 구성을 도시한 블록도이다.
도 2는 본 개시의 실시예에 따른 악성 비실행 파일 차단 장치의 구성을 도시한 블록도이다.
도 3은 본 개시의 실시예에 적용될 수 있는 정상 입력과 비정상 입력을 예시한 도면이다.
도 4는 정상적인 값이 입력된 경우의 응용 프로그램의 실행 흐름과 비정상적인 값이 입력된 경우의 응용 프로그램의 실행 흐름을 예시한 도면이다.
도 5는 본 개시의 실시예에 적용될 수 있는 문서 행위 판단 방법을 예시한 순서도이다.
도 6은 본 개시의 실시예에 적용될 수 있는 비실행 파일 차단 방법을 예시한 순서도이다.
도 7은 도 6의 탐지 결과 저장 단계(S6100)를 구체적으로 도시한 순서도이다.
도 8은 리버싱 엔진에 의한 탐지 결과의 일 예를 도시한 도면이다.
도 9는 리버싱 엔진에 의한 탐지 결과의 다른 예를 도시한 도면이다.
도 10은 도 6의 무해화 결과 저장 단계(S6200)를 구체적으로 도시한 순서도이다.
도 11은 CDR 엔진에 의한 무해화 결과의 일 예를 도시한 도면이다.
도 12는 CDR 엔진에 의한 무해화 결과의 다른 예를 도시한 도면이다.
도 13은 도 6의 판독 결과 생성 단계(S6300)를 구체적으로 도시한 순서도이다.
도 14는 단말을 통해 표시되는 판독 결과 화면을 예시한 도면이다.
본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 게시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있다. 단지 본 실시예들은 본 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다.
다른 정의가 없다면, 본 명세서에서 사용되는 모든 용어(기술 및 과학적 용어를 포함)는 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 공통적으로 이해될 수 있는 의미로 사용될 수 있을 것이다. 또 일반적으로 사용되는 사전에 정의되어 있는 용어들은 명백하게 특별히 정의되어 있지 않는 한 이상적으로 또는 과도하게 해석되지 않는다.
본 명세서에서 사용된 용어는 실시예들을 설명하기 위한 것이며 본 개시를 제한하고자 하는 것은 아니다. 본 명세서에서, 단수형은 출입문구에서 특별히 언급하지 않는 한 복수형도 포함한다. 명세서에서 사용되는 "포함한다(comprises)" 및/또는 "포함하는(comprising)"은 언급된 구성요소 외에 하나 이상의 다른 구성요소의 존재 또는 추가를 배제하지 않는다.
이하, 첨부된 도면을 참조하여 본 명세서에 개시된 실시예를 상세히 설명하되, 도면 부호에 관계없이 동일하거나 유사한 구성요소는 동일한 참조 번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다.
이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다. 또한, 본 명세서에 개시된 실시예를 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 명세서에 개시된 실시예의 요지를 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 명세서에 개시된 실시예를 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 명세서에 개시된 기술적 사상이 제한되지 않으며, 본 명세서의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
제1, 제2 등과 같이 서수를 포함하는 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되지는 않는다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다.
어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.
단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다.
본 명세서에서, "포함한다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
또한, 명세서에서 사용되는 "부"라는 용어는 소프트웨어 또는 하드웨어 구성요소를 의미하며, "부"는 어떤 역할들을 수행한다. 그렇지만 "부"는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. "부"는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 "부"는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로 코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들 및 변수들을 포함한다. 구성요소들과 "부"들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 "부"들로 결합되거나 추가적인 구성요소들과 "부"들로 더 분리될 수 있다.
또한, 본 명세서의 일 실시예에 따르면 "부"는 프로세서 및 메모리로 구현될 수 있다. 용어 "프로세서"는 범용 프로세서, 중앙 처리 장치 (CPU), 마이크로프로세서, 디지털 신호 프로세서 (DSP), 제어기, 마이크로제어기, 상태 머신 등을 포함하도록 넓게 해석되어야 한다. 몇몇 환경에서는, "프로세서"는 주문형 반도체 (ASIC), 프로그램가능 로직 디바이스 (PLD), 필드 프로그램가능 게이트 어레이 (FPGA) 등을 지칭할 수도 있다. 용어 "프로세서"는, 예를 들어, DSP 와 마이크로프로세서의 조합, 복수의 마이크로프로세서들의 조합, DSP 코어와 결합한 하나 이상의 마이크로프로세서들의 조합, 또는 임의의 다른 그러한 구성들의 조합과 같은 처리 디바이스들의 조합을 지칭할 수도 있다.
용어 "메모리"는 전자 정보를 저장 가능한 임의의 전자 컴포넌트를 포함하도록 넓게 해석되어야 한다. 용어 메모리는 임의 액세스 메모리 (RAM), 판독-전용 메모리 (ROM), 비-휘발성 임의 액세스 메모리 (NVRAM), 프로그램가능 판독-전용 메모리 (PROM), 소거-프로그램가능 판독 전용 메모리 (EPROM), 전기적으로 소거가능 PROM (EEPROM), 플래쉬 메모리, 자기 또는 광학 데이터 저장장치, 레지스터들 등과 같은 프로세서-판독가능 매체의 다양한 유형들을 지칭할 수도 있다. 프로세서가 메모리로부터 정보를 판독하고/하거나 메모리에 정보를 기록할 수 있다면 메모리는 프로세서와 전자 통신 상태에 있다고 불린다. 프로세서에 집적된 메모리는 프로세서와 전자 통신 상태에 있다.
본 명세서에서 사용되는 '비실행 파일'이란 실행 파일 또는 실행 가능한 파일과 반대되는 개념으로서 자체적으로 실행되지 않는 파일을 의미한다. 예를 들어, 비실행 파일은 PDF 파일, 한글 파일, 워드 파일과 같은 문서 파일, JPG 파일과 같은 이미지 파일, 동영상 파일, 자바 스크립트 파일, HTML 파일 등이 될 수 있으나, 이에 한정되지 않는다.
이하, 첨부한 도면을 참고하여 실시예에 대하여 본 명세서가 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그리고 도면에서 본 개시를 명확하게 설명하기 위해서 설명과 관계없는 부분들은 생략될 수 있다.
도 1은 본 개시의 실시예와 관련된 전자 기기의 구성을 도시한 블록도이다.
상기 전자 기기(100)는 무선 통신부(110), 입력부(120), 센싱부(140), 출력부(150), 인터페이스부(160), 메모리(170), 제어부(180) 및 전원 공급부(190) 등을 포함할 수 있다. 도 1에 도시된 구성요소들은 전자 기기(100)를 구현하는데 있어서 필수적인 것은 아니어서, 본 명세서 상에서 설명되는 전자 기기(100)는 위에서 열거된 구성요소들 보다 많거나, 또는 적은 구성요소들을 가질 수 있다.
보다 구체적으로, 상기 구성요소들 중 무선 통신부(110)는 전자 기기(100)와 무선 통신 시스템 사이, 전자 기기(100)와 다른 전자 기기(100) 사이, 또는 전자 기기(100)와 외부 서버 사이의 무선 통신을 가능하게 하는 하나 이상의 모듈을 포함할 수 있다. 또한, 상기 무선 통신부(110)는 전자 기기(100)를 하나 이상의 네트워크에 연결하는 하나 이상의 모듈을 포함할 수 있다.
이러한 무선 통신부(110)는 방송 수신 모듈(111), 이동통신 모듈(112), 무선 인터넷 모듈(113), 근거리 통신 모듈(114), 위치정보 모듈(115) 중 적어도 하나를 포함할 수 있다.
입력부(120)는 영상 신호 입력을 위한 카메라(121) 또는 영상 입력부, 오디오 신호 입력을 위한 마이크로폰(122) 또는 오디오 입력부, 사용자로부터 정보를 입력받기 위한 사용자 입력부(123)를 포함할 수 있다. 사용자 입력부(123)로는 터치키(touch key) 및 푸시키(mechanical key) 등을 예로 들 수 있다. 입력부(120)에서 수집한 음성 데이터나 이미지 데이터는 분석되어 사용자의 제어명령으로 처리될 수 있다.
센싱부(140)는 전자 기기(100) 내 정보, 전자 기기(100)를 둘러싼 주변 환경 정보 및 사용자 정보 중 적어도 하나를 센싱하기 위한 하나 이상의 센서를 포함할 수 있다. 예를 들어, 센싱부(140)는 근접센서(proximity sensor)(141), 조도 센서(illumination sensor)(142), 터치 센서(touch sensor), 가속도 센서(acceleration sensor), 자기 센서(magnetic sensor), 중력 센서(G-sensor), 자이로스코프 센서(gyroscope sensor), 모션 센서(motion sensor), RGB 센서, 적외선 센서(IR 센서: infrared sensor), 지문인식 센서(finger scan sensor), 초음파 센서(ultrasonic sensor), 카메라(121)와 같은 광 센서(optical sensor), 배터리 게이지(battery gauge), 환경 센서(예를 들어, 기압계, 토양습도계, 온도계, 방사능 감지 센서, 열 감지 센서, 가스 감지 센서 등), 화학 센서(예를 들어, 전자 코, 헬스케어 센서, 생체 인식 센서 등) 중 적어도 하나를 포함할 수 있다. 한편, 본 명세서에 개시된 전자 기기(100)는 예시된 센서들 중에서 둘 이상의 센서에서 센싱되는 정보들을 조합하여 활용할 수 있다.
출력부(150)는 시각, 청각 또는 촉각 등과 관련된 출력을 발생시키기 위한 것이다. 출력부(150)는 디스플레이부(151), 음향 출력부(152), 햅팁 모듈(153), 광 출력부(154) 중 적어도 하나를 포함할 수 있다. 디스플레이부(151)는 터치 센서와 상호 레이어 구조를 이루거나 일체형으로 형성됨으로써, 터치 스크린을 구현할 수 있다. 이러한 터치 스크린은 전자 기기(100)와 사용자 사이의 입력 인터페이스를 제공하는 사용자 입력부(123)로써 기능함과 동시에, 전자 기기(100)와 사용자 사이의 출력 인터페이스를 제공할 수 있다.
인터페이스부(160)는 전자 기기(100)에 연결되는 다양한 종류의 외부 기기와의 통로 역할을 수행한다. 이러한 인터페이스부(160)는 유/무선 헤드셋 포트(wired/wireless headset port), 외부 충전기 포트, 유/무선 데이터 포트(wired/wireless data port), 메모리 카드 포트(memory card port), 식별 모듈이 구비된 장치를 연결하는 포트, 오디오 입출력 포트(Audio Input/Output port), 비디오 입출력 포트(Vidieo Input/Output port), 이어폰 포트(earphone port) 중 적어도 하나를 포함할 수 있다. 전자 기기(100)에서는 상기 인터페이스부(160)에 외부 기기가 연결되는 것에 대응하여, 연결된 외부 기기와 관련된 적절할 제어를 수행할 수 있다.
또한, 메모리(170)는 전자 기기(100)의 다양한 기능을 지원하는 데이터를 저장한다. 메모리(170)는 전자 기기(100)에서 구동되는 다수의 응용 프로그램(application program 또는 application), 전자 기기(100)의 동작을 위한 데이터들, 명령어들을 저장할 수 있다. 이러한 응용 프로그램 중 적어도 일부는 무선 통신을 통해 외부 서버로부터 다운로드 될 수 있다. 또한 이러한 응용 프로그램 중 적어도 일부는 전자 기기(100)의 기본적인 기능(예를 들어, 전화 착신 기능, 전화 발신 기능, 메시지 수신 기능, 메시지 발신 기능)을 위하여 출고 당시부터 전자 기기(100)상에 존재할 수 있다. 한편, 응용 프로그램은 메모리(170)에 저장되고, 전자 기기(100) 상에 설치되어, 제어부(180)에 의하여 상기 전자 기기의 동작 또는 기능을 수행하도록 구동될 수 있다.
제어부(180)는 상기 응용 프로그램과 관련된 동작 외에도, 통상적으로 전자 기기(100)의 전반적인 동작을 제어한다. 제어부(180)는 위에서 살펴본 구성요소들을 통해 입력 또는 출력되는 신호, 데이터, 정보 등을 처리하거나 메모리(170)에 저장된 응용 프로그램을 구동함으로써, 사용자에게 적절한 정보 또는 기능을 제공 또는 처리할 수 있다.
또한, 제어부(180)는 메모리(170)에 저장된 응용 프로그램을 구동하기 위하여, 도 1과 함께 살펴본 구성요소들 중 적어도 일부를 제어할 수 있다. 나아가, 제어부(180)는 상기 응용 프로그램의 구동을 위하여, 전자 기기(100)에 포함된 구성요소들 중 적어도 둘 이상을 서로 조합하여 동작시킬 수 있다.
전원 공급부(190)는 제어부(180)의 제어 하에서, 외부의 전원, 내부의 전원을 인가받아 전자 기기(100)에 포함된 각 구성요소들에 전원을 공급한다. 이러한 전원 공급부(190)는 배터리를 포함하며, 상기 배터리는 내장형 배터리 또는 교체가능한 형태의 배터리가 될 수 있다.
상기 각 구성요소들 중 적어도 일부는, 이하에서 설명되는 다양한 실시 예들에 따른 전자 기기(100)의 동작, 제어, 또는 제어 방법을 구현하기 위하여 서로 협력하여 동작할 수 있다. 또한, 상기 전자 기기(100)의 동작, 제어, 또는 제어 방법은 상기 메모리(170)에 저장된 적어도 하나의 응용 프로그램의 구동에 의하여 전자 기기(100) 상에서 구현될 수 있다.
한편, 본 개시의 실시예에서 서버(또는 클라우드 서버)는 전자 기기(100)를 포함할 수 있으며, 전자 기기(100)는 단말로 통칭될 수 있다. 단말은 외부 서버(또는 외부 클라우드 서버)와 네트워크로 연결되어 통신할 수 있다.
도 2는 본 개시의 실시예에 따른 악성 비실행 파일 차단 장치의 구성을 도시한 블록도이다. 이하, 설명의 편의를 위하여 악성 비실행 파일 차단 장치를 '서버'라 칭하기로 한다.
도 2를 참조하면, 서버(200)는 제어부(210), 결과 판독부(220) 및 통신부(230)를 포함할 수 있다. 제어부(210)는 프로세서(212) 및 메모리(214)를 포함할 수 있다. 프로세서(212)는 메모리(214)에 저장된 명령어들을 수행할 수 있다. 프로세서(212)는 통신부(230)를 제어할 수 있다. 메모리(214)는 캐시 메모리(cache memory)를 포함할 수 있다. 캐시 메모리는 후술되는 원본 문서를 일정 시간 동안 임시로 저장할 수 있다.
프로세서(212)는 메모리(220)에 저장된 명령어에 기초하여 서버(200)의 동작을 제어할 수 있다. 서버(200)는 하나의 프로세서를 포함할 수도 있고, 복수의 프로세서를 포함할 수도 있다. 서버(200)가 복수의 프로세서를 포함하는 경우, 복수의 프로세서 중 적어도 일부는 물리적으로 이격된 거리에 위치할 수 있다. 또한, 서버(200)는 이에 한정되지 않고 알려진 다양한 방식으로 구현될 수 있다.
통신부(230)는 서버와 무선 통신 시스템의 사이, 서버와 다른 서버의 사이, 또는 서버와 외부 서버(단말) 사이의 무선 통신을 가능하게 하는 하나 이상의 모듈을 포함할 수 있다. 또한, 통신부(230)는, 서버를 하나 이상의 네트워크에 연결하는 하나 이상의 모듈을 포함할 수 있다.
제어부(210)는 메모리(214)에 저장된 응용 프로그램을 구동하기 위하여, 서버의 구성요소들 중 적어도 일부를 제어할 수 있다. 나아가, 제어부(210)는 상기 응용 프로그램의 구동을 위하여, 서버에 포함된 구성요소들 중 적어도 둘 이상을 서로 조합하여 동작시킬 수 있다.
본 개시의 실시예에서 서버(200)는 리버싱 엔진 및 CDR 엔진을 포함할 수 있다. 이하, 리버싱 엔진과 CDR 엔진에 대해서 구체적으로 설명하기로 한다.
리버싱 엔진(Reversing engine)
리버싱 엔진이란 악성 비실행 파일에 대한 리버스 엔지니어링 과정을 자동화한 분석 및 진단 엔진이다. 이는 역공학(Reverse Engineering)이라고 불리며, 이를 통해 서버(200)는 소스 코드가 없는 소프트웨어를 컴퓨터가 실행할 수 있는 언어인 어셈블리 단까지 들어가 소프트웨어의 원리 및 구조에 대해 알 수 있다. 이를 이용하여 서버(200)는 일반적인 소프트웨어(예를 들어, MS Office, PDF)의 구조, 악성 코드 행위, 취약점 악용 방법 등을 알 수 있다.
예를 들어, 리버싱 엔진은 파일 분석 단계, 정적 분석 단계, 동적 분석 단계 및 디버깅 분석 단계를 수행할 수 있다. 각 단계들에 대해서 간략하게 설명하면 다음과 같다.
1. 파일 분석 단계: 비실행 파일 자체의 외관(예를 들어, 속성, 작성자, 작성 날짜, 파일 타입)을 분석하는 단계로서, 일반 백신 프로그램과 유사하게 비실행 파일 자체의 정보만으로 악성 여부를 진단할 수 있다.
2. 정적 분석 단계: 비실행 파일 내의 데이터를 추출하고 분석해서 정상, 악성 여부를 판별하는 단계로서, 비실행 파일은 실행하지 않고 파일 구조에 맞게 내부 데이터를 추출하여 비교 분석하여 악성 여부를 진단할 수 있다. 이는 매크로의 추출 및 분석, URL의 추출 및 분석에 적합할 수 있다.
3. 동적 분석 단계: 비실행 파일을 실행하고 모니터링하면서 행위를 분석하여 악성 여부를 판별하는 단계로서, 매크로, 하이퍼링크, DDE(Dynamic Data Exchange) 등과 같이 문서의 정상 기능을 이용한 악성 행위를 탐지하기에 용이하다.
4. 디버깅 분석 단계: 비실행 파일을 실행하고 디버깅하여 취약점, 익스플로잇(Exploit) 등을 분석하는 단계로서, 매크로, 하이퍼링크, DDE 등과 같이 문서의 정상 기능을 이용한 악성 행위 탐지뿐만 아니라, 문서 내 본문, 표, 폰트, 그림 등을 이용한 응용 프로그램의 취약점을 탐지하기에 적합하다.
리버싱 엔진은 디버깅 분석에 사용될 수 있는 디버깅 엔진(Debugging engine)을 포함할 수 있다. 디버깅 엔진은 비실행 파일의 열람 과정을 디버깅 모드를 이용하여 문서의 입력 단계, 처리 단계, 출력 단계에서 발생하는 취약점을 진단할 수 있다. 여기서 취약점이란 응용 프로그램이 응용 프로그램의 개발자가 개발한 코드(로직)에서 예상하지 못한 값을 입력 받았을 때 발생하는 오류, 버그 등을 말한다. 공격자는 취약점을 통해 비정상 종료로 인한 서비스 거부, 원격 코드 실행 등의 악성 문서 행위를 실행할 수 있다.
디버깅 엔진은 디버거(Dibugger)를 포함할 수 있다. 디버거는 리버스 엔지니어링을 하기 위한 도구로, 다른 대상 프로그램에 대해 어셈블리 레벨에서 중단점(Breakpoint)를 설정할 수 있는 프로그램, 프로세스를 의미할 수 있다.
도 3은 본 개시의 실시예에 적용될 수 있는 정상 입력과 비정상 입력을 예시한 도면이다.
도 3의 (a)는 응용 프로그램이 비실행 파일을 통해 정상적인 값을 입력받는 경우를 설명하기 위한 도면으로, ECX(Extended Counter Register)의 값이 정상 데이터(00000001)인 경우를 예시하고 있다. 도 3의 (b)는 응용 프로그램이 비실행 파일을 통해 비정상적인 값을 입력받는 경우를 설명하기 위한 도면으로, ECX 레지스터의 값이 비정상 데이터(000000CC)인 경우를 예시하고 있다.
도 4는 정상적인 값이 입력된 경우의 응용 프로그램의 실행 흐름과 비정상적인 값이 입력된 경우의 응용 프로그램의 실행 흐름을 예시한 도면이다.
도 4의 (a)는 응용 프로그램이 비실행 파일을 통해 정상적인 값을 입력받는 경우, 응용 프로그램의 실행 흐름을 도시한 것이다. 도 4의 (b)는 응용 프로그램이 비실행 파일을 통해 비정상적인 값을 입력받는 경우, 응용 프로그램의 실행 흐름이 변경되는 모습을 도시한 것이다.
도 4의 (a)를 참조하면, 응용 프로그램이 비실행 파일을 통해 정상적인 값(예를 들어, 입력값이 정상범위인 2를 초과하지 않는 경우)을 입력받는 경우, 응용 프로그램의 실행 흐름은 개발자가 의도한 실행 흐름으로 진행된다.
반면, 도 4의 (b)를 참조하면, 응용 프로그램이 비실행 파일을 통해 비정상적인 값(예를 들어, 입력값이 정상범위인 2를 초과하는 경우)을 입력받는 경우, 응용 프로그램의 실행 흐름은 개발자가 의도하지 않은 실행 흐름으로 변경되어, 취약점이 동작될 수 있다.
디버깅 엔진은 문서 열람 과정을 자동 디버깅하여 취약점과 관련된 특정 지점에 중단점을 설정한다. 그리고 입력값과 관련된 특정값(레지스터 또는 메모리에 저장된 값)을 확인하여 입력값이 취약점을 일으키는 값인지 아닌지를 판별하여 악성 여부를 진단할 수 있다.
보다 자세하게, 디버깅 엔진은 비실행 파일의 종류를 확인한 다음, 비실행 파일을 열람하기 위한 응용 프로그램을 실행하여 디버깅을 시작할 수 있다. 비실행 파일을 열람하는 과정에서 문서 행위와 관련된 모듈이 로드 되면, 디버깅 엔진은 로드된 모듈이 분석 대상 모듈인지 확인한다. 확인 결과, 로드된 모듈이 분석 대상이라면 지정된 주소에 중단점을 설정할 수 있다.
예를 들어, 악성 비실행 파일은 응용 프로그램의 버전이나 운영체제 환경 등의 특정 조건을 만족하지 않으면 응용 프로그램을 종료하거나 아무런 악성 행위가 발생하지 않는 흐름으로 분기하는 분기 지점들을 가질 수 있다. 서버(200)는 사전에 분석가에 의해 분석되어, 이러한 가능성을 가지는 분기 지점에 중단점을 설정할 수 있다.
또한, 서버(200)는 해당 분기 지점과 연관되어, 응용 프로그램을 종료하지 않고 계속 실행하거나 악성 행위가 발생할 수 있는 흐름으로 유도할 수 있는 조건들을 설정할 수 있다.
응용 프로그램의 프로세스 실행 중 해당 중단점에서 프로세스가 멈춘 경우, 서버(200)는 탐지 로직에 따라 취약점 여부를 탐지한 후, 탐지 결과를 저장하는 단계를 수행할 수 있다. 저장된 탐지 결과는 탐지 결과 리포트인 것으로 이해될 수 있다.
서버(200)에 포함된 자동화 리버싱 엔진은 전술한 단계들을 자동으로 수행하면서 분석하여, 분석가가 연구, 개발한 진단 알고리즘을 통해, 악성 비실행 파일을 진단하고 차단할 수 있다.
CDR 엔진(Contents Disarm and Reconstruction engine)
CDR 엔진은 CDR 서비스를 제공한다. CDR 서비스는 비실행 파일을 분해해 악성 파일 또는 불필요한 파일을 제거하고, 콘텐츠는 원본과 최대한 동일하게 하여, 새로운 파일을 만드는 솔루션이다.
즉, CDR은 문서 내의 콘텐츠를 무해화(Disarm, 無害化)하고, 재조합(Reconstruction)하여 안전한 문서를 만들어 고객에게 제공하는 서비스를 의미한다. 여기서, 무해화 대상 파일은 비실행 파일 일체일 수 있다. 비실행 파일로는 워드 파일, 엑셀 파일, 파워포인트 파일, 한글 파일, PDF 파일을 예로 들 수 있다. 무해화 대상 콘텐츠는 액티브 콘텐츠일 수 있다. 액티브 콘텐츠로는 매크로, 하이퍼링크, 객체연결삽입(Object Linking and Embedding, OLE)을 예로 들 수 있다. 실시예에 따르면, CDR 엔진은 비실행 파일 내의 콘텐츠를 대상으로 무해화를 수행하여 무해화 결과를 저장할 수 있다. 저장된 무해화 결과는 무해화 결과 리포트인 것으로 이해될 수 있다.
다시 도 2를 참조하면, 결과 판독부(220)는 리버싱 엔진으로부터 제공받은 탐지 결과 및 CDR 엔진으로부터 제공받은 무해화 결과에 기초하여, 무해화 파일에 대한 판독 결과를 생성한다. 그리고 판독 결과에 기초하여 무해화 파일을 허용 또는 차단한다. 여기서, 무해화 파일이란 무해화 수행이 완료된 파일을 의미한다. 무해화 파일에 대한 판독 결과 및/또는 무해화 파일에 대한 차단 여부는 사용자의 단말로 전송될 수 있으며, 단말의 출력부를 통해 출력될 수 있다.
도 5는 본 개시의 실시예에 적용될 수 있는 문서 행위 판단 방법을 예시한 순서도이다.
도 5를 참조하면, 서버(200)는 비실행 파일 및 비실행 파일을 실행시키기 위한 응용 프로그램(예를 들어, MS Office, 한컴오피스 등)을 포함할 수 있다.
서버(200)는 디버깅(debugging) 모드로 응용 프로그램의 프로세스를 실행한다(S4010). 예를 들어, 서버(200)는 CreateProcess API를 이용하여 디버깅 모드(DEBUG_ONLY_THIS_PROCESS)로 응용 프로그램의 분석 대상 비실행 파일을 열기 위한 문서 프로세스를 실행할 수 있다. 이를 통해, 서버(200)는 응용 프로그램 프로세스의 디버그 이벤트를 수신 받을 수 있다.
보다 자세하게, 서버(200)는 CreateProcess API를 이용하여 응용 프로그램 프로세스를 “DEBUG_ONLY_THIS_PROCESS” 플래그를 줘서 실행할 수 있다.
서버(200)는 응용 프로그램의 프로세스에 근거하여, 문서 행위와 매칭되는 지점에 제1 중단점(breakpoint)를 설정한다(S4020). 예를 들어, 서버(200)는 메모리(214)에 적재된 응용 프로그램의 프로세스와 관련된 OP(operating) 코드를 “0xCC”로 변경하여 중단점을 설정할 수 있다. OP 코드란, 명령코드를 의미하며 CPU가 실제로 수행하여야 할 작업 내용이 작성되어 있는 코드일 수 있다. 이를 위해, 서버(200)는 WriteProcessMemory를 이용하여 메모리(214)를 변경할 수 있다.
서버(200)에는 문서 행위 및 해당 문서 행위가 매칭되는 지점에 관한 정보가 미리 설정되어 있을 수 있다. 예를 들어, 서버(200)는 미리 정의 되어있는 행위 매칭 중단점 테이블(Breakpoint Table)에 따라 WriteProcessMemory API를 이용하여 중단점을 설치할 수 있다.
서버(200)는 비실행 파일이 실행 중인지 여부를 검사한다(S4030). 보다 자세하게, 서버(200)는 중단점을 설정한 후, 분석이 요청된 기타 비실행 파일들이 열람되어 있는 중인지 여부를 확인한다. 비실행 파일에서 요구하는 기능에 따라, 응용 프로세스는 필요한 모듈이 메모리(214)에 적재되므로, 타켓이 되는 비실행 파일의 문서 행위 판단의 신뢰성 확보에서 응용 프로그램은 기타 비실행 파일들이 열람되어 있지 않은 상태를 가져야 한다. 예를 들어, 악성 비실행 파일이 열람되었다면, 문서 행위 판단 결과에 대한 신뢰성이 낮아질 수 있다.
서버(200)는 기타 비실행 파일이 실행 중이지 않은 것에 근거하여, 분석 대상 비실행 파일을 실행한다(S4040). 보다 자세하게, 서버(200)는 사용자가 분석을 요청한 비실행 파일을 해당 포맷에 맞는 응용 프로그램 프로세스(예를 들어, EXCEL, WORD, PPT 등)를 이용하여 열람한다. 예들 들어, 서버(200)는 MS Power point을 이용하여 sample.ppt 파일을 열람할 수 있다.
서버(200)는 메모리(214) 상에 분석 대상 비실행 파일과 관련된 신규 모듈이 로드되었는지의 여부를 판단한다(S4050). 서버(200)는 분석 대상 비실행 파일이 응용 프로그램 프로세스에 의해 실행되면, 신규 모듈이 로드되었는지 확인한다.
예를 들어, 서버(200)는 디버깅 모드를 이용하여, 응용 프로그램 프로세스에서 디버깅 이벤트가 발생하면 이를 수신할 수 있다. 서버(200)는 해당 이벤트를 이용하여 LOAD DLL 이벤트가 발생하면 신규 모듈(예를 들어, DLL 메모리 탑재)로 판단할 수 있다. 보다 자세하게, 서버(200)는 “LOAD_DLL_DEBUG_EVENT” 이벤트가 발생하면 신규 모듈이 메모리(214)에 올라온 것으로 판단할 수 있다.
예를 들어, 서버(200)는 분석 대상 비실행 파일에서 필요한 기능(예를 들어, 메크로, ActiveX 기능 등)을 사용하기 위해 응용 프로그램 프로세스 기능에 맞는 모듈을 신규로 메모리(214)에 적재할 수 있다.
서버(200)는 신규 모듈의 로드에 근거하여, 문서 행위와 매칭되는 지점에 제2 중단점을 설정한다(S4060). 만일, 신규 모듈이 로드되었다고 판단되지 않는 경우, 서버(200)는 제2 중단점을 설정하지 않는다.
서버(200)는 제1 중단점 및/또는 제2 중단점에서 응용 프로그램 프로세스가 중단되었는지 여부를 모니터링한다(S4070). 예를 들어, 서버(200)는 중단점에서 응용 프로그램 프로세스가 중단되어 프로세스 제어권이 디버거로 넘어갔는지를 확인할 수 있다. 제어권을 넘겨받은 디버거는 어떤 중단점에서 중단되었는지를 확인할 수 있다.
서버(200)는 모니터링 결과에 근거하여, 제1 중단점 및/또는 제2 중단점과 매칭되는 문서 행위 정보를 생성한다(S4080). 예를 들어, 서버(200)는 중단점의 주소값을 확인할 수 있다. 이후, 서버(200)는 해당 문서 행위 및 해당 문서 행위가 매칭되는 지점에 관한 정보에 근거하여, 중단점의 주소값과 매칭된 문서 행위에 대한 정보를 생성하고 이를 탐지 결과로 저장할 수 있다.
다음의 표 1은 저장되는 중단점의 주소값과 매칭된 문서 행위의 예시이다.
중단점 주소 문서 행위
0x12345678 문서에서 ActiveX 실행
이외에도, 서버(200)는 문서 행위를 획득하기 위해 추가 액션을 수행할 수도 있다.
S4080 단계 이후, 서버(200)는 분석 대상 비실행 파일의 열람이 종료되었는지를 판단한다(S4090). 예를 들어, 서버(200)는 기설정된 시간이 지났거나 메시지박스(Alert), 중단점을 일정시간 거치지 않았을 경우 등의 방식으로 분석 대상 비실행 파일의 열람이 종료되었는지 판단할 수 있다.
만일, 열람이 종료되지 않은 경우, 서버(200)는 응용 프로그램의 프로세스가 중단점에서 중단되었는지를 지속적으로 모니터링한다. 이를 통해, 서버(200)는 문서 행위가 충분히 발현되도록 대기할 수 있다.
이후, 서버(200)는 저장된 문서 행위 정보를 단말로 전달할 수 있다. 이를 위해, 단말은 서버(200)와 통신할 수 있고, 서버의 동작을 제어할 수 있는 관리 응용 프로그램을 포함할 수 있다. 단말은 관리 응용 프로그램을 통해, 사용자에게 문서 행위 정보를 제공할 수 있다.
기존의 APT 솔루션은 문서 행위 발현 후, 샌드박스 변화를 기반으로 문서 행위를 추출한다. 이는 샌드박스가 문서 행위가 발현될 때까지 대기해야 하기 때문에 분석시간이 길어진다. 또한, 최종적으로 마지막 부분(예를 들어, 샌드박스 변화 후)을 확인하기 때문에 본 명세서의 분석 속도보다 느리다.
또한, 본 명세서의 서버(200)는 샌드박스의 변화 전 단계에서 응용 프로그램 프로세스가 실행되는 시점부터 분석을 시작할 수 있다.
또한, 어셈블리 레벨(예를 들어, CPU 명령어 처리 단계)부터 문서 행위의 변화를 확인하기 때문에 기존 APT 솔루션보다 분석 속도(행위 추출)가 빠르다.
또한, 기존 APT 솔루션은 문서 행위가 발현할 때까지 대기하므로, 종료 시점을 알기 어렵다. 하지만 본 명세서에서 서버는 문서 행위의 종료 시점을 대략적으로 판단할 수 있으므로, 빠르게 분석이 가능하다.
도 6은 본 개시의 실시예에 적용될 수 있는 비실행 파일 차단 방법을 예시한 순서도이다.
서버(200)의 리버싱 엔진은 입력된 비실행 파일에 대한 리버싱 분석을 수행하여 취약점 및/또는 악성 액티브 콘텐츠에 대한 탐지 결과를 저장한다(S6100). 탐지 결과는 결과 판독부(220)로 제공된다. 상기 S6100 단계에 대한 보다 구체적인 설명은 도 7 내지 도 9를 참조하여 후술하기로 한다.
서버(200)의 CDR 엔진은 입력된 비실행 파일 내의 콘텐츠에 대하여 무해화를 수행하여 무해화 결과를 저장한다(S6200). 이때, S6200 단계가 반드시 S6100 단계 이후에 실행되어야 하는 것은 아니며, S6200 단계와 S6100 단계는 동시에 수행될 수도 있다. 무해화 결과는 결과 판독부(220)로 제공된다. 상기 S6200 단계에 대한 보다 구체적인 설명은 도 10 내지 도 12를 참조하여 후술하기로 한다.
서버(200)의 결과 판독부(220)는 리버싱 엔진으로부터 제공받은 탐지 결과 및 CDR 엔진으로부터 제공받은 무해화 결과에 기초하여, 무해화 파일에 대한 최종적인 판독 결과를 생성한다(S6300). 구체적으로, 판독 결과는 입력된 비실행 파일의 종류, 리버싱 엔진에 의해 탐지된 내용(예: 취약점, 매크로, 하이퍼링크, 자바스크립트), 탐지된 내용이 CDR 엔진에 의해 무해화 가능한지의 여부, 탐지된 내용이 CDR 엔진에 의해 무해화되었는지의 여부, 무해화 파일이 안전한지의 여부 중 하나 이상을 포함할 수 있다. 예시된 정보들 중에서 판독 결과에 포함시킬 정보의 종류 및/또는 개수는 사용자에 의해 변경 가능하도록 구현될 수 있다. 또한, 생성된 판독 결과는 사용자의 단말로 제공될 수 있으며, 단말의 출력부를 통해 음성 신호 및/또는 영상 신호의 형태로 출력될 수 있다.
도 7은 도 6의 탐지 결과 저장 단계(S6100)를 구체적으로 도시한 순서도이다.
리버싱 엔진은 입력된 비실행 파일을 대상으로 리버싱 분석을 수행한다(S6110). 상기 S6110 단계는 도 5에 도시된 문서 행위 판단 방법인 것으로 이해될 수 있다.
이후, 리버싱 엔진은 리버싱 분석에 의해 탐지된 결과가 있는지를 판단한다(S6120). 예를 들면, 비실행 파일에서 탐지된 취약점이나 악성 액티브 콘텐츠가 있는지를 판단한다.
S6120 단계의 판단 결과, 탐지 결과가 존재한다면, 해당 탐지 결과가 서버(200)의 CDR 엔진에서 무해화 가능한 것인지를 판단한다(S6130). 상기 판단은 CDR 엔진의 종류에 근거하여 판단될 수 있다. 왜냐하면 CDR 엔진의 종류에 따라 무해화 커버리지가 달라지기 때문이다. 여기서, 무해화 커버리지란 무해화 가능한 파일 및 무해화 가능한 콘텐츠 중 하나 이상을 포함하는 개념으로 이해될 수 있다. 구체적으로, 기존 CDR 엔진을 예로 들면, MS Office 2003 버전 및 MS Office 2007 버전 이상의 경우, 자바스크립트(JavaScript)라는 콘텐츠에 대해서는 무해화가 불가능하지만, 매크로(Macro), 플래시(Flash), 객체연결삽입, 액티브 엑스(Active X), 임베디드 도큐먼트(Embedded Document), 하이퍼링크(Hyperlink), 요소(Attachments) 등의 콘텐츠들에 대해서는 무해화가 가능하다. 그리고 아래아한글의 경우, 매크로와 하이퍼링크에 대해서는 무해화가 불가능하지만, 나머지 콘텐츠들에 대해서는 무해화가 가능하다. 그리고 어도비 아크로뱃의 경우, 매크로, OLE 객체, 액티브 엑스에 대해서는 무해화가 불가능하지만, 나머지 콘텐츠들에 대해서는 무해화가 가능하다. 상술한 바와 같은 CDR 엔진의 무해화 커버리지에 대한 정보는 서버(200)에 미리 저장될 수 있으며, 저장된 정보를 기초로 S6130 단계의 판단이 이루어질 수 있다.
S6130 단계의 판단 결과, 해당 탐지 결과가 CDR 엔진에서 무해화 불가능한 것이라면, 해당 탐지 결과에 무해화 불가능 레이블을 기록한다(S6140).
S6130 단계의 판단 결과, 해당 탐지 결과가 CDR 엔진에서 무해화 가능한 것이라면, 해당 탐지 결과에 무해화 가능 레이블을 기록한다(S6150).
레이블 기록이 완료되면, 탐지 결과를 저장한다(S6160). 탐지 결과는 예를 들어, XML 형식을 가질 수 있으나, 예시된 형식으로 한정되는 것은 아니다. 여기서, 도 8 및 도 9를 참조하여 리버싱 엔진에 의한 탐지 결과에 대해서 설명하기로 한다.
도 8은 리버싱 엔진에 의한 탐지 결과의 일 예를 도시한 도면이다.
도 8을 참조하면, 탐지 결과는 XML 형식인 것을 알 수 있다. 그리고 "Name" 항목에 "CVE-2017-11826.RE.300"이 기록되어 있고, "isPossibelCDR" 항목에 'false'라는 값이 기록되어 있는 것을 알 수 있다. 이는, 리버싱 분석 실행 중 디버깅 엔진에서 본문 취약점이 탐지되었으며, 탐지된 본문 취약점은 CDR 엔진에서 무해화 불가능하다는 것을 의미한다.
도 9는 리버싱 엔진에 의한 탐지 결과의 다른 예를 도시한 도면이다.
도 9를 참조하면, 취약점 탐지 결과는 XML 형식인 것을 알 수 있다. 그리고 "exploitName" 항목에 "_DownloaderMacro"가 기록되어 있고, "isPossibleCDR" 항목에 'ture'라는 값이 기록되어 있는 것을 알 수 있다. 이는, 리버싱 분석 실행 중 디버깅 엔진에서 악성 매크로를 탐지하였으며, 탐지된 악성 매크로는 CDR 엔진에서 무해화 가능하다는 것을 의미한다.
도 10은 도 6의 무해화 결과 저장 단계(S6200)를 구체적으로 도시한 순서도이다.
CDR 엔진은 입력된 비실행 파일 내에 무해화 대상 콘텐츠가 존재하는지를 판단한다(S6210). 무해화 대상 콘텐츠는 매크로, 하이퍼링크, 객체연결삽입 등의 액티브 콘텐츠일 수 있다.
S6210 단계의 판단 결과, 비실행 파일 내에 무해화 대상 콘텐츠가 존재한다면, 무해화 대상 콘텐츠에 대하여 무해화를 수행한다(S6220). 콘텐츠 무해화는 공지된 기술이므로, 이에 대한 구체적인 설명은 생략하기로 한다.
이후, CDR 엔진은 콘텐츠 무해화가 성공하였는지를 판단한다(S6230).
S6230 단계의 판단 결과, 콘텐츠 무해화에 실패하였다면, 무해화에 실패하였음을 무해화 결과에 기록한다(S6240).
S6230 단계의 판단 결과, 콘텐츠 무해화에 성공하였다면, 무해화에 성공하였음을 무해화 결과에 기록한다(S6250).
한편, S6210 단계의 판단 결과, 비실행 파일 내에 무해화 대상 콘텐츠가 존재하지 않는다면, 이러한 사실을 무해화 결과에 기록한다(S6260).
무해화 결과 기록이 완료되면, 무해화 결과를 저장한다(S6270). 여기서 도 11 및 도 12를 참조하여 CDR 엔진에 의한 무해화 결과에 대해서 설명하기로 한다.
도 11은 CDR 엔진에 의한 무해화 결과의 일 예를 도시한 도면이다.
도 11을 참조하면, 'result' 항목에 'true'라는 값이 기록되어 있는데, 이것은 비실행 파일이 무해함을 의미한다. 그리고 'status' 항목에는 'SUCCESS'라는 값이 기록되어 있는데, 이것은 비실행 파일 내의 무해화 대상 콘텐츠에 대하여 무해화가 성공하였음을 의미한다. 그리고 'message' 항목에는 "CDR Process Success"가 기록되어 있는데, 이것은 CDR 엔진에서 무해화가 성공적으로 수행되었음을 의미한다.
즉, 비실행 파일 내에 무해화 대상 콘텐츠가 존재하고, 상기 무해화 대상 콘텐츠에 대하여 무해화가 성공한 경우, 'status' 항목에는 'SUCCESS'라는 값이 기록된다. 그리고 무해화 대상 콘텐츠에 대하여 무해화가 성공하였으므로, 비실행 파일 역시 무해한 것으로 판단되어, 'result' 항목에 'true'라는 값이 기록된다.
만약, 비실행 파일 내에 무해화 대상 콘텐츠가 존재하지 않는 경우라면, 'status' 항목에는 'NO DETECTION'이라는 값이 기록된다. 그리고 비실행 파일 역시 무해한 것으로 판단되어, 'result' 항목에 'true'라는 값이 기록된다.
무해화 결과는, 'result', 'status', 'message' 항목 외에도 'fileType', 'inputFileName', 'inputFullPath', 'outputFileName', 'outputFullPath', 'elapsedTime', 'cdrEntities' 항목이 더 포함될 수 있다. 'fileType' 항목은 비실행 파일의 종류가 기록되는 부분이다. 'inputFileName' 항목 및 'inputFullPath' 항목은 각각 비실행 파일의 이름 및 비실행 파일의 저장경로가 기록되는 부분이다. 'outputFileName' 항목 및 'outputFullPath' 항목은 각각 무해화 파일의 이름 및 무해화 파일의 저장경로가 기록되는 부분이다. 'elapsedTime' 항목은 무해화에 걸린 시간이 기록되는 부분이다. 'cdrEntities' 항목은 무해화 결과를 저장한 데이터의 속성이 기록되는 부분이다. 'cdrEntities' 항목에 'Array'라고 기록되어 있다는 것은 무해화 결과가 배열 형태로 저장되어 있다는 것을 의미한다.
도 12는 CDR 엔진에 의한 무해화 결과의 다른 예를 도시한 도면이다.
도 12를 참조하면, 'result' 항목에 'false'라는 값이 기록되어 있는데, 이것은 비실행 파일이 무해하지 않음을 의미한다. 그리고 'status' 항목에는 "FAILURE"라는 값이 기록되어 있는데, 이것은 비실행 파일 내의 무해화 대상 콘텐츠에 대하여 무해화가 실패하였음을 의미한다. 그리고 'message' 항목에는 "I/O Error Occurs"가 기록되어 있는데, 이것은 파일에 대한 입출력 에러로 인해 무해화 실패 오류가 발생될 수 있다는 것을 의미한다.
즉, 비실행 파일 내에 무해화 대상 콘텐츠가 존재하고, 상기 무해화 대상 콘텐츠에 대하여 무해화가 실패한 경우, 'status' 항목에는 'FAILURE'라는 값이 기록된다. 그리고 무해화 대상 콘텐츠에 대하여 무해화가 실패하였으므로, 비실행 파일 역시 무해하지 않은 것으로 판단되어, 'result' 항목에 'false'라는 값이 기록된다.
도 13은 도 6의 판독 결과 생성 단계(S6300)를 구체적으로 도시한 순서도이다.
결과 판독부(220)는 리버싱 엔진으로부터 제공받은 탐지 결과를 확인하여(S6310), 무해화 불가능 레이블을 가진 대상(예를 들어, 취약점, 악성 액티브 콘텐츠)이 있는지를 판단한다(S6320).
S6320 단계의 판단 결과, 무해화 불가능 레이블을 가진 대상이 없다면, 결과 판독부(220)는 무해화 가능 레이블을 가진 대상이 있는 것으로 판단한다. 그리고 CDR 엔진으로부터 제공받은 무해화 결과를 확인하여(S6330), 무해화 가능 레이블을 가진 대상의 무해화에 성공하였는지를 판단한다(S6340).
S6340 단계의 판단 결과, 무해화 가능 레이블을 가진 대상에 대하여 무해화가 성공하였다면, 결과 판독부(220)는 무해화 파일이 안전하다는 판독 결과를 생성한다(S6350).
S6340 단계의 판단 결과, 무해화 가능 레이블을 가진 콘텐츠에 대하여 무해화가 실패하였다면, 결과 판독부(220)는 무해화 파일이 위험하다는 판독 결과를 생성한다(S6380).
이후, 결과 판독부(220)는 판독 결과에 기초하여 무해화 파일을 허용하거나 차단할 수 있다. 구체적으로, 무해화 파일이 안전한 것으로 판독된 경우에는, 해당 무해화 파일을 허용한다. 반대로 무해화 파일이 위험한 것으로 판독된 경우에는, 해당 무해화 파일을 차단한다.
이외에도, 결과 판독부(220)는 무해화 파일에 대한 판독 결과를 사용자의 단말로 제공하여, 출력부를 통해 출력되도록 할 수 있다.
도 14는 단말을 통해 표시되는 판독 결과 화면을 예시한 도면이다.
도 14를 참조하면, 판독 결과 화면은 입력된 비실행 파일의 종류, 리버싱 엔진의 탐지 결과, CDR 엔진의 무해화 결과, 무해화 파일에 대한 최종 판독 결과를 포함할 수 있다.
리버싱 엔진의 탐지 결과에는 탐지된 내용, 탐지된 내용의 악성 여부에 대한 정보가 포함될 수 있다. 탐지된 내용의 예로는 객체 취약점, 본문 취약점, 매크로, 하이퍼링크, 객체연결삽입, 자바스크립트 등을 예로 들 수 있다.
CDR 엔진의 무해화 결과에는 무해화 대상, 무해화 대상에 대한 무해화 성공 여부에 대한 정보가 포함될 수 있다.
도 14를 참조하면, 객체 취약점을 포함하는 워드 파일이 비실행 파일로 입력된 경우, 리버싱 엔진에서 객체 취약점이 탐지되었음을 알 수 있다. 그리고 탐지된 객체 취약점은 악성인 것으로 분석되었으며, CDR 엔진에 의해 무해화 가능함을 의미하는 무해화 가능 레이블이 부여되었음을 알 수 있다. 또한 해당 객체 취약점은 실제로 CDR 엔진에서 객체 무해화에 성공하였음을 알 수 있다. 이러한 리버싱 엔진의 탐지 결과와 CDR 엔진의 무해화 결과를 종합적으로 판단한 결과, CDR 엔진에서 출력된 무해화 파일은 안전한 것으로 판독되었음을 알 수 있다.
자바스크립트를 포함하는 PDF 파일이 비실행 파일로 입력된 경우, 리버싱 엔진에서 자바스크립트가 탐지되었음을 알 수 있다. 그리고 탐지된 자바스크립트는 악성이 아닌 정상인 것으로 분석되었으며, CDR 엔진에 의해 무해화 가능함을 의미하는 무해화 가능 레이블이 부여되었음을 알 수 있다. 이때, 탐지된 자바스크립트가 정상이라는 분석 결과는 리버싱 엔진에서 자바스크립트를 이용한 악성 행위를 탐지하기 어렵기 때문에 얻어진 결과일 수 있다. 따라서, 탐지된 자바스크립트에 무해화 가능 레이블을 부여하여 탐지 결과를 저장하고, 저장된 탐지 내용과 CDR 엔진의 무해화 결과를 비교하면, CDR 엔진에서 출력된 무해화 파일에 대해 좀더 정확한 판독 결과를 얻을 수 있다. 실제로, CDR 엔진에서 자바스크립트 무해화에 성공하였으므로, 리버싱 엔진의 탐지 결과와 CDR 엔진의 무해화 결과를 종합적으로 판단한 결과, CDR 엔진에서 출력된 무해화 파일은 안전한 것으로 판독되었음을 알 수 있다.
매크로 및 본문 취약점을 포함하는 엑셀 파일이 비실행 파일로 입력된 경우, 리버싱 엔진에서 매크로 및 본문 취약점이 탐지되었음을 알 수 있다. 이때, 탐지된 매크로는 악성이 아닌 정상인 것으로 분석되었으며, 무해화 가능 레이블이 부여되었음을 알 수 있다. 여기서, 탐지된 매크로가 정상이라는 분석 결과는 리버싱 엔진에서 매크로를 이용한 악성 행위를 탐지하기 어렵기 때문에 얻어진 결과일 수 있다. 따라서, 탐지된 매크로에 무해화 가능 레이블을 부여하여 탐지 결과를 저장하고, 저장된 탐지 내용과 CDR 엔진의 무해화 결과를 비교하면, CDR 엔진에서 출력된 무해화 파일에 대해 좀 더 정확한 판독 결과를 얻을 수 있다. 한편, 비실행 파일에서 탐지된 본문 취약점은 악성인 것으로 분석되었으며, 무해화 불가능 레이블이 부여되었음을 알 수 있다. 탐지된 본문 취약점에 대해서는 CDR 엔진에서 무해화가 불가능하므로, 탐지된 매크로에 대해서 무해화가 성공하더라도, CDR 엔진에서 출력된 무해화 파일은 위험한 것으로 판독되었음을 알 수 있다.
하이퍼링크를 포함하는 워드 파일이 비실행 파일로 입력된 경우, 리버싱 엔진에서 하이퍼링크가 탐지되었음을 알 수 있다. 그리고 탐지된 하이퍼링크는 악성이 아닌 정상인 것으로 분석되었으며, 무해화 가능 레이블이 부여되었음을 알 수 있다. 여기서, 탐지된 하이퍼링크가 정상이라는 분석 결과는 리버싱 엔진에서 하이퍼링크를 이용한 악성 행위를 탐지하기 어렵기 때문에 얻어진 결과일 수 있다. 따라서 탐지된 하이퍼링크에 무해화 가능 레이블을 부여하여 탐지 결과를 저장하고, 저장된 탐지 내용과 CDR 엔진의 무해화 결과를 비교하면, CDR 엔진에서 출력된 무해화 파일에 대해 좀 더 정확한 판독 결과를 얻을 수 있다. 실제로, CDR 엔진에서 하이퍼링크 무해화에 성공하였으므로, CDR 엔진에서 출력된 무해화 파일은 안전한 것으로 판독되었음을 알 수 있다.
매크로를 포함하는 워드 파일이 비실행 파일로 입력된 경우, 리버싱 엔진에서 매크로가 탐지되었음을 알 수 있다. 그리고 탐지된 매크로는 악성인 것으로 분석되었으며, 무해화 가능 레이블이 부여되었음을 알 수 있다. 그런데 탐지된 매크로에 대해서는 CDR 엔진에서 매크로 무해화에 실패하였음을 알 수 있다. 이러한 리버싱 엔진의 탐지 결과와 CDR 엔진의 무해화 결과를 종합적으로 판단한 결과, CDR 엔진에서 출력된 무해화 파일은 위험한 것으로 판독되었음을 알 수 있다.
도 14에서, 안전하다고 판단된 무해화 파일은 허용되고, 위험하다고 판단된 무해화 파일은 차단된다.
상술한 바와 같은 비실행 파일 차단 방법에 따르면, CDR 엔진에서 생길 수 있는 보안 공백을 해결할 수 있다.
이상, 본 개시의 실시예에 따른 비실행 파일 차단 방법을 설명하였다. 상술한 바와 같은 비실행 파일 차단 방법에 따르면, 리버싱 엔진과 CDR 엔진을 모두 사용함으로써, 리버싱 엔진만을 사용하는 경우에 발생할 수 있는 보안 공백 및 CDR 엔진만을 사용하는 경우에 발생할 수 있는 보안 공백을 보완할 수 있다.
한편, 개시된 실시예들은 컴퓨터에 의해 실행 가능한 명령어를 저장하는 기록매체의 형태로 구현될 수 있다. 명령어는 프로그램 코드의 형태로 저장될 수 있으며, 프로세서에 의해 실행되었을 때, 프로그램 모듈을 생성하여 개시된 실시예들의 동작을 수행할 수 있다. 기록매체는 컴퓨터로 읽을 수 있는 기록매체로 구현될 수 있다.
컴퓨터가 읽을 수 있는 기록매체로는 컴퓨터에 의하여 해독될 수 있는 명령어가 저장된 모든 종류의 기록매체를 포함한다. 예를 들어, ROM(read only memory), RAM(random access memory), 자기 테이프, 자기 디스크, 플래쉬 메모리, 광 데이터 저장장치 등이 있을 수 있다.
또한, 컴퓨터가 읽을 수 있는 기록매체는, 비일시적(non-transitory) 저장매체의 형태로 제공될 수 있다. 여기서, '비일시적 저장매체'는 실재(tangible)하는 장치이고, 신호(signal)(예: 전자기파)를 포함하지 않는다는 것을 의미할 뿐이며, 이 용어는 데이터가 저장매체에 반영구적으로 저장되는 경우와 임시적으로 저장되는 경우를 구분하지 않는다. 예로, '비일시적 저장매체'는 데이터가 임시적으로 저장되는 버퍼를 포함할 수 있다.
일 실시예에 따르면, 본 문서에 개시된 다양한 실시예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 기록 매체(예: compact disc read only memory (CD-ROM))의 형태로 배포되거나, 또는 어플리케이션 스토어(예: 플레이 스토어TM)를 통해 또는 두 개의 사용자 장치들(예: 스마트폰들) 간에 직접 배포되거나, 온라인으로 배포(예: 다운로드 또는 업로드)될 수 있다. 온라인 배포의 경우, 컴퓨터 프로그램 제품(예: 다운로더블 앱(downloadable app))의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 기기로 읽을 수 있는 기록 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.
이상과 첨부된 도면을 참조하여 본 개시에 따른 실시예들을 설명하였다. 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자는 본 개시가 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다.
상술한 바와 같은 리버싱 엔진과 CDR 엔진을 활용한 악성 비실행 파일 차단 방법 및 장치는 사이버 보안 분야에 적용될 수 있다.

Claims (7)

  1. 서버가 리버싱 엔진(Reversing engine)과 CDR 엔진(Contents Disarm and Reconstruction engine)을 활용하여 악성 비실행 파일을 차단하는 방법에 있어서,
    분석 대상 비실행 파일에 대한 리버싱 분석을 수행하여, 상기 분석 대상 비실행 파일 내의 취약점 및 콘텐츠 중 적어도 하나를 탐지하고, 탐지 결과를 저장하는 단계;
    상기 분석 대상 비실행 파일 내의 콘텐츠에 대하여 무해화를 수행하고, 무해화 결과를 저장하는 단계;
    상기 탐지 결과 및 상기 무해화 결과에 기초하여, 상기 무해화를 수행하여 얻은 무해화 파일에 대한 판독 결과를 생성하는 단계; 및
    상기 판독 결과에 기초하여, 상기 무해화 파일을 차단하는 단계를 포함하는,
    악성 비실행 파일 차단 방법.
  2. 제1항에 있어서,
    상기 탐지 결과를 저장하는 단계는,
    상기 탐지된 취약점 또는 상기 탐지된 콘텐츠에 대하여 악성 여부를 기록하는 단계;
    상기 탐지된 취약점 또는 상기 탐지된 콘텐츠가 상기 CDR 엔진의 무해화 커버리지에 포함되는 경우, 상기 탐지된 취약점 또는 상기 탐지된 콘텐츠에 대하여 무해화 가능 레이블을 기록하는 단계; 및
    상기 탐지된 취약점 또는 상기 탐지된 콘텐츠가 상기 CDR 엔진의 무해화 커버리지에 포함되지 않는 경우, 상기 탐지된 취약점 또는 상기 탐지된 콘텐츠에 대하여 무해화 불가능 레이블을 기록하는 단계를 포함하는,
    악성 비실행 파일 차단 방법.
  3. 제2항에 있어서,
    상기 판독 결과를 생성하는 단계는,
    상기 탐지 결과를 확인한 결과, 상기 무해화 불가능 레이블을 가진 취약점 또는 콘텐츠가 존재하는 경우, 상기 무해화 파일을 위험한 것으로 판독하는 단계를 포함하는,
    악성 비실행 파일 차단 방법.
  4. 제2항에 있어서,
    상기 판독 결과를 생성하는 단계는,
    상기 탐지 결과를 확인한 결과, 상기 무해화 가능 레이블을 가진 취약점 또는 콘텐츠가 존재하고, 상기 무해화 가능 레이블을 가진 취약점 또는 콘텐츠에 대하여 무해화가 성공한 경우, 상기 무해화 파일을 안전한 것으로 판독하는 단계를 포함하는,
    악성 비실행 파일 차단 방법.
  5. 제1항에 있어서,
    상기 무해화 파일에 대한 판독 결과를 단말로 전송하는 단계를 더 포함하는,
    악성 비실행 파일 차단 방법.
  6. 제1항에 있어서,
    상기 분석 대상 비실행 파일에 대한 리버싱 분석은,
    디버깅 모드(Debugging) 모드로 상기 분석 대상 비실행 파일과 관련된 응용 프로그램의 프로세스를 실행하는 단계;
    상기 응용 프로그램의 프로세서에 근거하여, 문서 행위와 매칭되는 지점에 제1 중단점(Breakpoing)를 설정하는 단계;
    상기 분석 대상 비실행 파일을 실행하는 단계;
    상기 제1 중단점에서 상기 응용 프로그램의 프로세스가 중단되었는지 여부를 제1 모니터링하는 단계; 및
    상기 제1 모니터링의 결과에 근거하여, 상기 분석 대상 비실행 파일의 문서 행위 정보를 생성하는 단계를 포함하는,
    악성 비실행 파일 차단 방법.
  7. 리버싱 엔진(Reversing engine)과 CDR 엔진(Contents Disarm and Reconstruction engine)을 활용한 악성 비실행 파일 차단 방법을 수행하는 서버에 있어서,
    통신부;
    상기 리버싱 엔진과 상기 CDR 엔진이 포함된 메모리;
    프로세서; 및
    결과 판독부를 포함하며,
    상기 프로세서는
    상기 통신부 및 상기 메모리를 기능적으로 제어하며, 상기 리버싱 엔진을 이용하여, 분석 대상 비실행 파일에 대한 리버싱 분석을 수행하여, 상기 분석 대상 비실행 파일 내의 취약점 및 콘텐츠 중 적어도 하나를 탐지하고, 상기 탐지 결과를 저장하며, 상기 CDR 엔진을 이용하여, 상기 분석 대상 비실행 파일 내의 콘텐츠에 대하여 무해화를 수행하고, 무해화 수행 결과를 저장하고,
    상기 결과 판독부는
    상기 탐지 결과 및 상기 무해화 결과에 기초하여, 상기 무해화를 수행하여 얻은 무해화 파일에 대한 판독 결과를 생성하고, 상기 판독 결과에 기초하여, 상기 무해화 파일을 차단하는,
    서버.
PCT/KR2022/007477 2022-05-26 2022-05-26 리버싱 엔진과 cdr 엔진을 활용한 악성 비실행 파일 차단 방법 및 장치 WO2023229065A1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020227017840A KR102470010B1 (ko) 2022-05-26 2022-05-26 리버싱 엔진과 cdr 엔진을 활용한 악성 비실행 파일 차단 방법 및 장치
PCT/KR2022/007477 WO2023229065A1 (ko) 2022-05-26 2022-05-26 리버싱 엔진과 cdr 엔진을 활용한 악성 비실행 파일 차단 방법 및 장치

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/KR2022/007477 WO2023229065A1 (ko) 2022-05-26 2022-05-26 리버싱 엔진과 cdr 엔진을 활용한 악성 비실행 파일 차단 방법 및 장치

Publications (1)

Publication Number Publication Date
WO2023229065A1 true WO2023229065A1 (ko) 2023-11-30

Family

ID=84238046

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/007477 WO2023229065A1 (ko) 2022-05-26 2022-05-26 리버싱 엔진과 cdr 엔진을 활용한 악성 비실행 파일 차단 방법 및 장치

Country Status (2)

Country Link
KR (1) KR102470010B1 (ko)
WO (1) WO2023229065A1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102549007B1 (ko) * 2022-11-29 2023-06-28 시큐레터 주식회사 디버깅 엔진을 이용한 매크로 탐지 방법 및 이를 위한 장치

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170041618A (ko) * 2015-10-07 2017-04-17 한국전자통신연구원 하이퍼바이저 기반의 가상머신 모니터링 장치 및 방법
KR20170056876A (ko) * 2015-11-16 2017-05-24 주식회사 마크애니 로그 분석을 기반으로 하는 보안 모니터링 방법, 장치 및 시스템
KR20180073933A (ko) * 2016-12-23 2018-07-03 한국인터넷진흥원 악성 스크립트 탐지 방법 및 장치
KR101937935B1 (ko) * 2017-07-07 2019-04-11 한국전자통신연구원 가상머신 프로세스 실행에 따른 감사 증적 저장 장치 및 방법
KR102093274B1 (ko) * 2019-05-28 2020-03-25 (주)지란지교시큐리티 콘텐트 스캐닝 에이전트, 콘텐트 스캐닝 방법 및 그 방법을 수행하는 프로그램을 기록한 컴퓨터 판독 가능 기록매체

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170041618A (ko) * 2015-10-07 2017-04-17 한국전자통신연구원 하이퍼바이저 기반의 가상머신 모니터링 장치 및 방법
KR20170056876A (ko) * 2015-11-16 2017-05-24 주식회사 마크애니 로그 분석을 기반으로 하는 보안 모니터링 방법, 장치 및 시스템
KR20180073933A (ko) * 2016-12-23 2018-07-03 한국인터넷진흥원 악성 스크립트 탐지 방법 및 장치
KR101937935B1 (ko) * 2017-07-07 2019-04-11 한국전자통신연구원 가상머신 프로세스 실행에 따른 감사 증적 저장 장치 및 방법
KR102093274B1 (ko) * 2019-05-28 2020-03-25 (주)지란지교시큐리티 콘텐트 스캐닝 에이전트, 콘텐트 스캐닝 방법 및 그 방법을 수행하는 프로그램을 기록한 컴퓨터 판독 가능 기록매체

Also Published As

Publication number Publication date
KR102470010B1 (ko) 2022-11-23

Similar Documents

Publication Publication Date Title
US7665138B2 (en) Detecting method and architecture thereof for malicious codes
WO2010062063A2 (ko) 브라우저 기반 어뷰징 방지 방법 및 시스템
CN107408176A (zh) 恶意对象的执行剖析检测
WO2023229065A1 (ko) 리버싱 엔진과 cdr 엔진을 활용한 악성 비실행 파일 차단 방법 및 장치
WO2021045428A1 (en) Method and apparatus for improving runtime performance after application update in electronic device
KR102460078B1 (ko) 무해화(disarming) 동작에서 차이점(delta) 추출 방식을 이용한 원본 파일 백업 공간을 효율화하는 방법 및 이를 위한 장치
WO2018208032A1 (ko) 고립된 사용자컴퓨팅부를 갖는 컴퓨터
WO2023229066A1 (ko) 리버싱 엔진 기반의 문서 행위를 판단하기 위한 방법 및 이를 위한 장치
WO2014042344A1 (ko) 디버그 이벤트를 이용한 악성 쉘 코드 탐지 장치 및 방법
WO2018194196A1 (ko) Elf 파일의 난독화 적용 여부의 탐지 및 보안성 평가를 위한 방법 및 시스템
WO2014185627A1 (ko) 데이터 프로세싱 시스템 보안 장치와 보안방법
WO2014200201A1 (ko) 시스템 보호를 위한 파일 보안용 관리장치와 관리방법
WO2024075868A1 (ko) 네트워크 망분리 환경에서 파일 이동시 악성파일의 유입을 알리기 위한 방법 및 이를 위한 장치
WO2024063184A1 (ko) Pdf 또는 hwp에서 link의 무해화를 위한 방법 및 장치
WO2024071451A1 (ko) Ocr 기술을 이용하여 비실행 파일의 악성 매크로를 탐지하기 위한 방법 및 이를 위한 장치
WO2010093071A1 (ko) 인터넷 사이트 보안 시스템 및 그 방법
WO2020060101A1 (ko) 보안 엘리먼트를 이용하여 서비스를 제공하는 전자 장치 및 그의 동작 방법
WO2024063171A1 (ko) 자식 프로세스의 악성 행위를 검사하기 위한 방법 및 이를 위한 장치
WO2024071461A1 (ko) 난독화 된 자바스크립트를 탐지하고 복호화하기 위한 방법 및 이를 위한 장치
CN109522714A (zh) 一种基于外挂防护软件对目标软件进行防护的方法及系统
KR102581932B1 (ko) 리버싱 엔진을 이용하여 SEH overwrite Mitigation 우회를 탐지하기 위한 방법 및 장치
WO2018043885A1 (ko) 악성코드탐지시스템 및 악성코드 탐지 방법
WO2013115603A1 (ko) 사용자 장치 및 이를 이용한 악성 코드 진단 방법
WO2024075871A1 (ko) 이메일에 첨부된 암호를 갖는 압축파일의 처리를 위한 방법 및 이를 위한 장치
KR102549124B1 (ko) 난독화 된 vbscript를 탐지하고 복호화하기 위한 방법 및 이를 위한 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22943872

Country of ref document: EP

Kind code of ref document: A1