WO2009131371A2

WO2009131371A2 - Method for securing on-line electronic transaction program

Info

Publication number: WO2009131371A2
Application number: PCT/KR2009/002091
Authority: WO
Inventors: Sang-Min Chung; Sung Jin Yang; Ho Woong Lee
Original assignee: Ahnlab., Inc.
Priority date: 2008-04-22
Filing date: 2009-04-22
Publication date: 2009-10-29
Also published as: KR100953355B1; KR20090111577A; WO2009131371A3

Abstract

A method for securing an on-line electronic transaction program includes hooking an API that creates a process handle for the program while the program is running in a computer, monitoring a trial to access information of the process handle, checking whether a process is an authorized one based on ID thereof when the process is detected to access the information of the process handle, and preventing the process from accessing the information of the process handle, if the process is recognized as being not the authorized one as the result of checking.

Description

METHOD FOR SECURING ON-LINE ELECTRONIC TRANSACTION PROGRAM

The present invention relates to a method for securing on-line electronic transaction program, and in particular, to a more reliable method for securing on-line electronic transaction program.

As Internet communication networks are growing up, people can more easily deal stocks or conduct banking businesses via on-line networks with a computer, without directly visiting suitable service spots like a bank or a stock exchange for conducting financial businesses such as various banking businesses or dealing stocks.

Such an on-line financial transaction is becoming more common as one of the most popular e-commerce services, due to its convenience as well as the rapid spread of a high speed Internet communication networks as well as personal computers capable of accessing Internet.

In case of on-line stock trading, a user can easily buy or sell stocks, based on various information provided by stock trade companies, by accessing his/her account via a stock trading program over Internet with a computer. Such an on-line stock trading over Internet is very convenient because internal and external information useful for investment can be collected at real time without a locational restriction, and also the stock trading itself is processed very quickly. Further, in case of on-line banking, a user can conveniently conducts bank businesses with his/her computer, without visiting the corresponding bank, simply after accessing an Internet website of his/her bank and inputting his account ID and passwords.

In spite of such conveniences, however, the aforementioned on-line financial trade is problematic in that client’s private information may be abnormally leaked or falsified due to various malicious codes or hacking attacks.

That is to say, an on-line stock trading program or an on-line banking program is used to be attacked by hackers or malicious codes, so that some important data and the processing procedure thereof are abnormally opened to the third parties, or user's account and trade information is falsified or abnormally modified, thereby causing heavy damages to the client.

It is a primary object of the present invention to provide a method for securing electronic transaction programs to protect the electronic transaction programs from hacking attacks and malicious codes when a user conducts financial businesses, such as dealing stocks or Internet banking, via on-line networks with a computer, such that users can safely conduct on-line financial businesses.

In accordance with a first aspect of the present invention, there is provided a method for securing an on-line electronic transaction program, including: hooking an API that creates a process handle for the program while the program is running in a computer; monitoring a trial to access information of the process handle; checking whether a process trying to access the information of the process handle is an authorized one based on ID thereof when the process is detected; and preventing the process from accessing the information of the process handle, if the process is recognized as unauthorized one as the result of checking.

In accordance with a second aspect of the present invention, there is provided a method for securing an on-line electronic transaction program, including: hooking an API that is capable of accessing a process memory having the program therein while the program is running in a computer; monitoring a trial to access the process memory; determining whether a process trying to access the process memory is an authorized one based on ID thereof when the process is detected; and preventing the process from accessing the process memory, if the process is recognized as unauthorized one as the result of checking.

In accordance with a third aspect of the present invention, there is provided a method for securing an on-line electronic transaction program, including: checking whether an API, which is used by the program while the program is running in a computer, is hooked; checking whether or not the API is restorable if the API is found as being hooked as a result of checking; and restoring the API if the API is found as being restorable, thereby securing the program from a malicious process.

In accordance with a fourth aspect of the present invention, there is provided a method for securing an on-line electronic transaction program, including: compressing executable files of the program when the program is requested to run in a computer; virtualizing codes of the program that are executed in a memory; a debugger that tries to debug the program; and an access of the debugger to the program if the debugger is an unauthorized process.

According to the method for securing electronic transactions that enables a user to conduct on-line financial businesses, while an electronic transaction program for on-line financial businesses is running in a computer, various hacking attacks or malicious code infections are prevented by using procedures such as the detection of a hooked API and restoration thereof, the prevention of debugging, and the prevention of accessing a memory. Therefore, user account and trade information that is sent or received via on-line networks is prevented from being illegally leaked or falsified, so that the reliability and security of the on-line electronic transaction can be enhanced.

Fig. 1 shows a schematic configuration view of an on-line stock trade system.

Fig. 2 is a block diagram illustrating internal processes of an electronic transaction program, in accordance with an embodiment of the present invention.

Fig. 3 depicts a flow diagram illustrating a procedure of securing an electronic transaction program, in accordance with an embodiment of the present invention.

Fig. 4 shows a flow diagram illustrating a procedure of securing an electronic transaction program, in accordance with another embodiment of the present invention.

Fig. 5 illustrates a flow diagram illustrating a procedure of securing an electronic transaction program, in accordance with further another embodiment of the present invention.

Hereinafter, exemplary embodiments of the present invention will be described with reference to the accompanying drawings.

Fig. 1 shows a schematic configuration view of an on-line stock trading system using Internet, which is one of on-line electronic transaction services. Though the embodiments of the present invention respectively refer to methods for securing the on-line stock trading program for the convenience of explanation, they can be identically applied to the other electronic transaction program, for example, an on-line banking program that uses on-line networks for enabling various financial businesses.

With reference to Fig. 1, the on-line stock trading system includes a server 100 of the stock exchange (hereinafter, the stock exchange server 100, a server 106 of a security company (hereinafter, referred to as the security company server 106, a database (DB) 108, the Internet 104, and a user terminal 102.

The stock exchange server 100 supports user's orders for selling or buying stocks, and provides stock market information for the user when the user accesses the security company server 106 using the user terminal 102 to deal stocks via on-line networks.

When a user accesses the security company server 106 via the Internet 104 and requests for allowing his/her on-line stock trade by using the user terminal 102, the security company server 106 identifies his/her status information, and then processes data to complete his/her trade orders while referring to stock market information stored in the database 108, or provides suitable stock trade information in response to his/her requests.

The user terminal 102 may be a personal computer capable of accessing the Internet 104, and has installed therein a stock trading program for enabling the on-line stock trade, which is provided by a corresponding security company. When a user runs the stock trading program, the user terminal 102 accesses the security company server 106 and downloads therefrom various stock market information, which in turn may be provided for the user's convenience in dealing stocks. Further, the user terminal 102 sends stock trade orders from the user to the security company server 106, thereby enabling the on-line stock trade.

Fig. 2 is a block diagram illustrating a security module for securing an electronic transaction while internal processes are performed on a computer for executing the electronic transaction, in accordance with an embodiment of the present invention.

With reference to Fig. 2, operations of the internal processes for the on-line stock trade and operations of the electronic transaction security module for securing private information sent or received during the operations of the processes are explained in detail.

A first process 200 serves to construct and display various user interfaces of a stock trading program executed in a computer, and processes orders from a user, who inputs them with various keys or the like related with the stock trade.

A second process 202 serves to receive a variety of information related with the stock trade, such as stock market information, and provides such information to the first process 200. Further, the second process 202 transfers the ordering information offered by the first process 200 to the security company server 106, so that the on-line stock trading can be processed. While the stock trading program is running, a first process memory 206 and a second process memory 208 stores data, which is processed according to the execution of the first and

second processes

200 and 202.

A hacking module 210 may be malicious codes inserted for hacking an electronic transaction program, such as the stock trading program, which would be executed in user's personal computer. On the execution of the stock trading program, the hacking module 210 conducts the hacking attacks by hooking information of a process handle that can access or approach the stock trading program, hooking an API (Application Programming Interface) used by the stock trading program, or debugging to find out operating ways or rules of the stock trading program.

Further, the hacking module 210 may access or approach the first process memory 206 or the second process memory 208, to which the first and

second processes

200 and 202 refer for their operations while the stock trading program is running. The hacking module 210 then may conduct hacking attacks such as penetrating or infecting the first process memory 206, which handles data resulted from the first process 200 while the first process is processing user's orders, thereby abnormally changing titles of the ordered stocks or falsifying the number thereof. Furthermore, the hacking module 210 can conduct hacking attacks such as penetrating or infecting the second process memory 208 that handles stock market data of the second process 202, thereby abnormally displaying a lower price item as a higher price item.

An electronic transaction security module 204 prevents various access trials of the hacking module 210 that approaches or accesses the stock trading program and tries to attack or abnormally get private information, thereby enabling a safe and secure on-line electronic transaction through the stock trading program.

Now, there are explained in detail various operations of the electronic transaction security module 204 to prevent the hacking module 210 from approaching or accessing the stock trading program.

When the hacking module 210 is detected to try approaching or accessing information of the process handle for the purpose of hacking the stock trading program, the electronic transaction security module 204 hooks APIs used in a user mode or kernel mode to create process handles, thereby preventing inappropriate approach or access to the process handles of the stock trading program by an unauthorized process such as the hacking module 210. Specifically, when detecting the inappropriate process approaching or accessing to the process handles, the electronic transaction security module 204 confirms ID of the inappropriate process to determine whether or not the inappropriate process is authorized to approach or access the information of the process handles.

Further, when the hacking module 210 is detected to try approaching or accessing the

memories

206 and 208 for hacking the stock trading program, the electronic transaction security module 204 hooks another APIs used in a user mode or kernel mode to approach/access or revise the memories, thereby preventing such unallowable processes as the hacking module 210 from approaching or accessing the

memories

206 and 208.

In some cases, the hacking module 210 may conduct the hacking attacks by hooking APIs used for the stock trading program. Therefore, the electronic transaction security module 204 may check in advance whether such APIs used for running the stock trading program are hooked or not. The electronic transaction security module 204, if hooked, would stop the program or warn the user about a possible hacking attack or risk, thereby preventing the hacking module such as malicious codes from abnormally modifying operation ways of the program or leaking and falsifying important data. If there is an API already abnormally modified by hooking, the electronic transaction security module 204 may also restore it into an original one, so that a normal API can be called.

Further, the hacking module 210 may conduct the hacking attacks by debugging the stock trading program. In order to prevent the reverse engineering of the program by using debugging analysis, the present invention provides various embodiments such as a method of virtualizing codes being executed in a process memory so as to prevent finding out original command though the executed codes are identified, and another method of compressing executable files used to run the program so that the configuration of the original files cannot be grasped. Moreover, in accordance with another embodiment of the present invention, there is provided a procedure of monitoring inappropriate debuggers that are not authorized to debug the program. If such debugging is detected, the user may be noticed of the possible hacking attacks or risk, or the program may be stopped so as to prevent grasping the operation ways and rules of the stock trading program.

Fig. 3 depicts a flow diagram illustrating algorithms for securing an electronic transaction program executed in a user terminal computer, in accordance with an embodiment of the present invention. Though the present embodiment refers to a method for securing the on-line stock trade program for the convenience of explanation, it can be identically applied to the other electronic transaction program or service that uses on-line networks and/or Internet browser for enabling various financial businesses. With reference to Figs. 1 to 3, the embodiment of the present invention will be explained in more detail.

If a user runs the stock trading program by inputting keys or the like, processes of the stock trading program are executed in the user's terminal 102 like a personal computer in step S300.

Then, the electronic transaction security module 204 identifies the running status of the stock trading program that should be protected, hooks APIs used to create process handles of the stock trading program in step S302, and hooks another APIs that can access or revise the

memories

206 and 208 used by the processes of the stock trading program in step S304, for the purpose of preventing an unallowable process like the hacking module 210 from inappropriately approaching or accessing the information of the process handles or the

memories

206 and 208.

That is to say, in step S302, the electronic transaction security module 204 hooks APIs used in a user mode or kernel mode to create process handles, thereby preventing inappropriate approach or access to the information of the process handles by the unallowable process, so that the unallowable process cannot get the process handle information to approach the stock trading program.

Further, in step S304, the electronic transaction security module 204 hooks another APIs used in a user mode or kernel mode to approach or revise the

memories

206 and 208 so as to identify information of another normal processes, thereby preventing abnormal processes from approaching or accessing the

memories

206 and 208 so that unallowable processes cannot access the memories or falsify contents therein.

Next, in step S306, the electronic transaction security module 204 monitors other processes that try getting the process handle or accessing a process memory for hacking the stock trading program.

If it is found in step S308 that there is a trial of another process to access the process memory or to access the process handle information useful for approaching the stock trading program that is now running in the user terminal 102, the electronic transaction security module 204 detects ID of the another process that tries to access the process handle or the process memory, and checks and determines whether the access should be authorized or not in step S310. Specifically, the ID of the process that tries to access the process handle or the process memory is compared with registered IDs of allowable processes, so as to find out whether the another process is one of the authorized processes or not.

Next, if the another process that tries to access the process handle or the process memory is found, in step S312, as one of the normal processes authorized to approach the stock trading program, the electronic transaction security module 204 proceeds to step S314 where the electronic transaction security module 204 normally allows the access to the process handle or the process memory in step 314.

On the contrary, if the another process that tries to access the process handle or the process memory is found, in step S312, as an abnormal one like the hacking module 210 that is not authorized to approach the stock trading program, the electronic transaction security module 204 advances to step S316 wherein the electronic transaction security module 204 prevents the trial to access the process handle or the process memory.

Fig. 4 shows a flow diagram illustrating a procedure of securing an electronic transaction program executed in the user terminal 102, in accordance with another embodiment of the present invention. Though the present embodiment refers to a method for securing the on-line stock trading program for the convenience of explanation, it can be identically applied to the other electronic transaction program or services that use on-line networks and/or Internet browser for enabling various financial businesses. With reference to Fig. 1, Fig. 2 and Fig. 4, the embodiment of the present invention will be explained in more detail.

If a user runs the stock trading program by inputting keys or the like, processes of the program are executed in the user's terminal 102 like a personal computer in step S400.

Then, in step S402, the electronic transaction security module 204 identifies the running status of the stock trading program and confirms whether APIs used for the program were hooked or not. That is to say, in case of running a stock trading program that enables financial dealings between a user and a security company, such a hacking module as malicious codes for hacking attacks may abnormally change some operating ways of the stock trading program, or may cause important data to be leaked or falsified. Therefore, the electronic transaction security module 204 tests whether such APIs used for the running stock trading program are hooked or not in order to prevent such hacking attacks against the stock trading program.

If it is founded in step S404 that some of APIs used for the stock trading program have been hooked by the hacking module 201, the electronic transaction security module 204 proceeds to step S406 where it determines whether the APIs hooked by the hacking module 210 can be restored.

Specifically, the electronic transaction security module 204 recognizes an API as being hooked if there is founded a command to move codes to be executed by API to an external code area, i.e., an unknown process, or if it is detected that an address of function pointed by IAT (Import Address Table), EAT (Export Address Table), SDT (Service Descriptor Table), or IDT (Interrupt Descriptor Table) of a module that stores the location of an API has been modified into what is different from a real address.

Then, if it is founded in step S408 that the hooked APIs is restorable, the electronic transaction security module 204 proceeds to a next step S410 where it makes the hooked APIs be restored into normal ones.

For restoring an API, the electronic transaction security module 204 uses an original file or data, from which original codes of the API can be identified, to load original executable codes into a process memory, and then makes the codes in the process memory be called instead of the hooked or falsified API. Alternatively, before an API is called, a corresponding code area of the API may be overwritten with original codes, so that the API can be restored.

On the other hand, if it found in step S408 that it is impossible to restore a hooked API, the electronic transaction security module 204 goes to step S412 for warning the user about a possible hacking attack, and then makes the stock trading program stop running in step S414.

Fig. 5 is a flow diagram illustrating a procedure of securing an electronic transaction program executed in a user terminal computer, in accordance with another embodiment of the present invention. Though the present embodiment refers to a method for securing the on-line stock trading program for the convenience of explanation, it can be identically applied to the other electronic transaction program that uses on-line networks and/or Internet browser for enabling various financial businesses. With reference to Fig. 1, Fig. 2 and Fig. 5, the embodiment of the present invention will be explained in more detail.

If a user runs the stock trading program by inputting keys or the like, processes of the program are executed in the user's terminal like a personal computer in step S500.

Then, in step S502, the electronic transaction security module 204 identifies the running status of the stock trading program, and transforms the configuration and contents of an original executable file used for running the stock trading program by using the method of compressing executable files, thereby preventing the hacking module 210 such as malicious codes from debugging the program. Accordingly, a direct modification or falsification of the executable files of the stock trading program is disabled, thereby preventing the hacking module 210 such as malicious codes from grasping the contents of original executable files of the stock trading program.

Next, in step S504, executable codes by which the stock trading program is executed in a process memory are virtualized in order to prevent debugging of the hacking module 210 or malicious codes. By this procedure, commands contained in the executable codes of the stock trading program are kept unidentified such that the hacking module 210 such as malicious codes cannot grasp the operating ways and rules of the program.

Subsequently, in step S506, the electronic transaction security module 204 checks a trial to debug the stock trading program that is currently running.

If it is found in step S508 that there is such a trial to debug the stock trading program that is currently running, the electronic transaction security module 204 proceeds to next step S510 where it detects ID of the debugger process that is now operating to debug the stock trading program, so as to examine whether the debugger process is one of those authorized processes for debugging.

Then, if it is detected in step S512 the debugger process is an unauthorized process such as malicious codes that is not authorized for debugging, the electronic transaction security module 204 advances to step S514 where it notices the user of the unauthorized process that is operating to debug the stock trading program, and makes the stock trading program stop running in step S516.

According to the embodiments of the present invention, there is provided the method for securing electronic transaction program that enables a user to conduct on-line financial businesses, wherein when an electronic transaction program for on-line financial businesses is running in a computer, various hacking attacks or malicious code infections are prevented by using procedures such as the detection of a hooked API and restoration thereof, the prevention of debugging, and the prevention of accessing a process memory. Therefore, information about user's account and trade that is sent or received via on-line networks is prevented from being illegally leaked or falsified, so that the reliability and security of the on-line electronic transaction can be enhanced.

While the invention has been shown and described with respect to the particular embodiments, it will be understood by those skilled in the art that various changes and modification may be made without departing from the scope of the invention as defined in the following claims.

Claims

A method for securing an on-line electronic transaction program, comprising:

hooking an API that creates a process handle for the program while the program is running in a computer;

monitoring a trial to access information of the process handle;

checking whether a process trying to access the information of the process handle is an authorized one based on ID thereof when the process is detected; and

preventing the process from accessing the information of the process handle, if the process is recognized as unauthorized one as the result of checking.
A method for securing an on-line electronic transaction program, comprising:

hooking an API that is capable of accessing a process memory having the program therein while the program is running in a computer;

monitoring a trial to access the process memory;

determining whether a process trying to access the process memory is an authorized one based on ID thereof when the process is detected; and

preventing the process from accessing the process memory, if the process is recognized as unauthorized one as the result of checking.
The method of claim 1 or 2, wherein the electronic transaction program includes an on-line stock trading program or an on-line banking program.
A method for securing an on-line electronic transaction program, comprising:

checking whether an API, which is used by the program while the program is running in a computer, is hooked;

checking whether or not the API is restorable if the API is found as being hooked as a result of checking; and

restoring the API if the API is found as being restorable, thereby securing the program from a malicious process. ?
The method of claim 4, wherein said checking whether the API is hooked includes checking whether there exists a command to move codes to be executed by API to an external code area, wherein the API is recognized as being hooked if there is such the command.
The method of claim 4, wherein said checking whether the API is hooked includes checking that an address of function pointed by IAT (Import Address Table), EAT (Export Address Table), SDT (Service Descriptor Table), or IDT (Interrupt Descriptor Table) of a module that stores the location of an API has been modified into what is different from a real address, and wherein the API is recognized as being hooked if the API address is modified.
The method of claim 4, wherein said restoring the API includes loading original executable codes in a process memory by using an original file or data from which original codes of the API can be identified, and calling the codes that independently exist in the process memory instead of the hooked or falsified API to restore the API.
The method of claim 4, wherein said restoring the API includes, before calling the API, overwriting original codes on a corresponding code area of the API to restore the API.
The method of claim 4, further comprising noticing a user of a possible hacking risk if the hooked API is not restorable.
The method of claim 4, further comprising making the program stop running if the hooked API is not restorable.
The method of claim 4, wherein the electronic transaction program includes one of a stock trading program and an on-line banking program.
A method for securing an on-line electronic transaction program, comprising:

compressing executable files of the program when the program is requested to run in a computer;

virtualizing codes of the program that are executed in a process memory;

detecting a debugger that tries to debug the program; and

preventing an access of the debugger to the program if the debugger is an unauthorized process.
The method of claim 12, further comprising noticing that there is a trial of debugging the program when the trial is detected.
The method of claim 12, wherein the electronic transaction program includes one of an on-line stock trading program and an on-line banking program.