Security scan based on dynamic taint

Software security testing is used to identify vulnerabilities in applications such as web applications. Traditional black box security testing for web-based software products performed using security testing applications is often referred to as a scanner and pretends to be an attacker. In a black box approach, the scanner generates a Hypertext Transfer Protocol (HTTP) request and evaluates the HTTP response to find all URLs that the application under test (AUT) accepts input. By investigating the AUT. The URL that AUT accepts input is the attack target area (Attack) of AUT. Sometimes called Surface). The scanner then generates an attack based on the attack surface and, in some cases, the category of vulnerabilities. The scanner applies an attack and diagnoses the presence or absence of vulnerabilities by evaluating the HTTP response of the program. In the black box approach, the scanner does not investigate any internal behavior of the AUT.

In the detailed description below, the following drawings will be referred to.

<figref num="1">It is a block diagram which shows the system which can carry out a security attack based on the vulnerability list from a dynamic taint module (Dynamic Taint Module) by an example.</figref><figref num="2A">As an example, it is a block diagram showing an application security scanner capable of attacking an application based on a list of vulnerabilities generated by a dynamic taint module.</figref><figref num="2B">As an example, it is a block diagram showing an application security scanner capable of attacking an application based on a list of vulnerabilities generated by a dynamic taint module.</figref><figref num="3">It is a figure which shows the web application interface of the application to be inspected by one example.</figref><figref num="4">As an example, it is a flow diagram which shows the method of attacking an application based on the scan strategy based on the vulnerability list generated by the dynamic taint module.</figref><figref num="5">By way of example, it is a block diagram showing a computer device capable of generating an attack against a web application based on a list of vulnerabilities.</figref>

The various embodiments described herein provide techniques for performing testing of applications such as web applications. When a company wants to know how secure a web application is, it may be in production or it may be about to start production, and companies often do penetration testing. Use security testing measures such as law (eg, use of scanners). Companies may want to use a copy of the application being manufactured as the application to be inspected (AUT). By using AUT, which will become an application in manufacturing, at the quality assurance stage, it is possible to reliably test the application used in manufacturing.

Web application security scanners are an approach to finding security vulnerabilities in applications such as web applications. In some situations, the crawler may first determine the attack surface, either manually or automatically. Depending on the application, the attack surface may be large.

The scanner then scrutinizes the attack surface list and each entry in the attack surface list to launch a huge number of attacks to determine if a vulnerability may occur. There is. Determining vulnerabilities from the attack surface is difficult. This is because scanners have limited visibility into the code that runs on your application. Due to limited visibility, a set of attacks is carried out for each attack surface entry. Also, in some situations, the attacks carried out to find a vulnerability may be a small number of attacks. That is, even if a large number of attacks are carried out, only a small number of the attacks will succeed. As a result, scanner testing is time consuming. Scanning large websites can take hours or even days to complete. Users and consumers may desire shorter inspection times.

Additional insights about the application may help the scanner make smarter decisions about what attacks should be carried out and which attacks are not worth considering. Reducing the number of attacks directly improves scan time.

Therefore, it provides an approach to speed up the scanning process by reporting potential vulnerability categories to the scanner using dynamic taint analysis. The scanner can then selectively scan the application based on the vulnerability category determined by dynamic taint analysis. Therefore, by limiting the attack surface of the scan to specific vulnerabilities determined based on dynamic taint analysis, the number of tests that must be performed can be reduced. Therefore, the entire scan can be faster than without the information from the dynamic taint analysis.

FIG. 1 is a block diagram showing a system capable of carrying out a security attack based on a list of vulnerabilities from a dynamic taint module, as an example. System 100 may include an application security scanner 102 and an application to be inspected (AUT) 104. The AUT104 may be implemented on one or more computing units such as servers (eg, Java2 Platform Enterprise Edition (J2EE) application servers, Internet information servers, etc.). In addition, the AUT104 may include a dynamic taint module 110.

The AUT104 may be encoded in any suitable web-based computer language, especially JAVA, or .NET. The AUT104 may work, among other things, within a suitable software framework such as Struts, Struts 2, ASP .NET MVC, Oracle Weblogic, and Spring MVC. The software framework contains a set of common program modules that provide general functionality, and general functionality is selectively overwritten or specialized by user code to provide specific functionality. Sometimes. The AUT104 is a Java Virtual Machine (JVM), Common Language Runtime (CLR:) to handle various requests from Scanner 102. It may be configured to run one or more instances of the Common Language Runtime) and / or other runtime environments. The various programming instructions provided by these software frameworks or common program modules in the runtime environment are sometimes referred to as container code. Custom programming instructions specific to the AUT104 are sometimes referred to as user code.

The scanner 102 is a computing device that communicates with the AUT104 through a front end, such as a web interface, to identify potential security vulnerabilities and architectural weaknesses of the AUT104, for example by performing black-box testing. Can be regarded as an executable program.

The AUT104 includes a network interface (not shown) to allow communication between the scanner 102 and the AUT104 over the network. The network interface exposes the attack surface of the AUT104. The network interface is the same interface that will ultimately be used to allow access to the AUT 104 when it becomes available for general use. Communication between the scanner 102 and the AUT 104 through the network interface may be accomplished by an application request issued by the scanner 102 to the AUT 104 (eg, by HTTP) and an HTTP response issued by the AUT 104 to the scanner 102. is there. A request destined for AUT104 may be referred to as an application request, and a response received from AUT104 may be referred to as an application response. The application requirements generated by the scanner 102 may be configured to expose potential vulnerabilities in AUT104, respond to tests imposed by AUT104, and so on.

Networks include, for example, the Internet, local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), cable networks, fiber optic networks, or combinations thereof. , May include public data networks. As some specific examples, wireless networks may include mobile phone networks, satellite communications, wireless LANs, and the like.

As one approach for performing security testing on the AUT104, the scanner 102 can receive information from the dynamic taint module 110 during the crawling phase of security testing. As an example, Dynamic Tint Module 110 is a special runtime module for monitoring security vulnerabilities during AUT104 program execution. The dynamic taint module 110 acts like a program debugger, intercepting program execution at a given program point (such as a breakpoint in the debugger) and performing security checks. .. Dynamic taint analysis first marks untrusted user input as a potential source of taint (contamination), then traces the user input, and any of the data from the user input becomes some dangerous function call. Identify security vulnerabilities by determining if they may be used. An example of a dangerous function call is a direct database query (for example, direct SQL (direct Structured). Query Language), file open, delete file, hypertext markup language response stream write function, shell command execution, direct XML (Extensible Markup Language) query, to write error messages to log files Functions, direct user directory queries, etc. The dynamic taint module 110 can be added to an application by compiling AUT104 using a special library, or by directly editing or modifying the binary code of AUT104.

During the test, the scanner 102 can send a message to activate the dynamic taint module 110 120. Upon receiving the message, the AUT104 determines if the dynamic taint module 110 is present. If the dynamic taint module 110 is present, the scanner 102 can send a message to activate the dynamic taint module 110, and / or the AUT104 is based on the scanner's previous message. , Dynamic taint module 110 can be enabled.

The scanner 102 can then perform the crawling phase 122. The scanner 120 crawls the AUT104, for example via a website interface. The dynamic taint analysis is performed while crawling. When the scanner 102 crawls an application, the scanner 102 can access one or more entry points (eg, input fields) one or more times. During the test, the scanner 102 can inspect the AUT 104 by generating an HTTP request, evaluating the HTTP response, or evaluating that there is no HTTP response in order to find the URL that the AUT 140 accepts input. In some examples, the scanner 102 follows other runtime modules installed on the AUT according to the pre-recorded web process flow provided by the end user or for automatic discovery of the attack surface. It may be used to acquire the attack surface of AUT104. Access to individual entry points may trigger the initiation of dynamic taint analysis.

The dynamic taint module 110 can provide report 124 to the scanner 102 in response to the crawling phase 122, eg, at the end of the crawling phase 122. The report may include a list of potential vulnerabilities detected during Crawling Phase 122.

In some examples, crawling and reporting 124 may be performed repetitively or incrementally. For example, the report may be received during part of the crawling phase 122. Therefore, a report may be split into multiple pieces, for example, in a web application, one report may be sent for each crawled page of a website. In addition, as another example, the report may be sent at the end of the crawling phase of the entire website.

The scanner 102 can then send a message to stop or disable the dynamic taint module 110 of the AUT 104. In some examples, the dynamic taint module 110 may be partially disabled instead of being completely disabled. For example, the scanner 102 may cause the dynamic taint module 110 to invalidate each of the taint sources other than the taint source for the target attack vector for which the scanner 102 wants to collect data. Disabling the dynamic taint module 110 allows the scanner 102 to attack the AUT 104 without executing the extra code of the dynamic taint module 110. Also, since no extra code is executed, the time to complete the test can be shortened.

At 128, the scanner 102 adjusts and / or generates a scanning strategy for the AUT 104 according to the information obtained from the report. This may be done based on the scan policy. As an example, the scanner 102 generates a strategy for making attacks related to potential vulnerabilities pre-screened by the dynamic taint module 110. Therefore, other tests are filtered (excluded), which can reduce the overall test time. In another example, the list of potential vulnerabilities in Report 124 is given a high priority in terms of attack strategy, so that more frequently occurring vulnerabilities are prioritized to appear earlier in an attack. Ranking may be given. In some specific examples, adjustment 128 may be performed dynamically or incrementally, for example, while receiving a partial report.

At 130, scanner 102 attacks AUT104 according to the attack strategy. As mentioned above, attack strategies may be related to the list of vulnerabilities in the report, or may be prioritized based on the list of vulnerabilities in the report. Therefore, it is possible to filter (exclude) meaningless or impossible attacks from the attack 130, and thus reduce the amount of time required for the entire security scan.

2A and 2B are block diagrams of an application security scanner capable of attacking an application based on a list of vulnerabilities generated by a dynamic taint module, according to various examples. The application security scanners 200a, 200b include various components that can be used to attack an application based on the list of vulnerabilities generated by the dynamic taint module. The individual scanners 200a, 200b can be accessed by notebook computers, desktop computers, servers, workstations, or any other computing device capable of performing tests. There may be. As an example, the application security scanner 200a may include a communication module 210, a crawler 212, and an adjustment module 214. As another example, the application security scanner 200b further includes an input / output interface 234 that can use the attack module 216, processor 230, memory 232, and / or input device 240 and / or output device 242.

The communication module 210 may be used to communicate with other devices, such as a device containing an application to be inspected. The application to be inspected may further include a dynamic taint module. In some specific examples, the communication module 210 may be specifically configured to communicate with a dynamic taint module. In some examples, the communication module 210 is inspected via a network interface, such as a wireless network interface or a wired network interface, over the Internet, over an intranet, or over a direct connection. It may communicate with a server that has an application. In some specific examples, the communication module 210 may be connected to other devices on the network.

The application security scanner 200 can send a message to the AUT via the communication module 210 to activate the dynamic taint module of the application under inspection (AUT). Therefore, the application security scanner 200 can cause the dynamic tain module associated with AUT to start the dynamic tain module in preparation for the crawling phase of the security test. In one example, initiating a dynamic taint module means enabling the functionality of the dynamic taint module to assist the application security scanner 200. Security tests may be coordinated by the Application Security Scanner 200.

The crawler 212 may be used to access the AUT. As an example, the crawler can acquire various attack entry points for the AUT during the crawling phase. As will be explained in detail later, when the dynamic taint module can be activated, the dynamic taint module can generate one or more reports that provide information about potential security vulnerabilities. it can. For example, the report may include a list of potential vulnerabilities for one or more potential vulnerabilities in AUT determined by the dynamic taint module during the crawling phase.

The application security scanner 200 can then generate a dynamic taint module limit. As an example, generating a limit for a dynamic taint module may mean disabling a feature. In some cases, some features may be disabled. In some specific examples, the crawling phase may start when the dynamic taint module is started and end when the dynamic taint module is restricted. As another example, the crawling phase may continue as long as the application security scanner 200 is looking for other entry points.

Adjustment module 214 can generate a scanning strategy based on the report. As an example, generating a scan strategy may involve modifying another scan strategy for that AUT based on a list of potential vulnerabilities. For example, the scanning strategy may be determined by prioritizing potential vulnerabilities during an attack carried out by attack module 216. Attacks that can be deprecated may be remnants of other scanning strategies. As another example, control module 214 may determine a scanning strategy by determining an attack with a focus on the list of potential vulnerabilities. For example, an attack may be determined for each attack entry point based on the accessible potential vulnerabilities recorded by the dynamic taint module for each entry point. Therefore, attacks on the attack entry point may be filtered based on the potential vulnerability determined by the dynamic taint module.

Attack module 216 can carry out an attack on the AUT based on the attack strategy. In some examples, attack module 216 uses one or more communication modules 210 to carry out an attack.

As an example, the dynamic taint module and / or AUT may receive a message from the application security scanner 200. The dynamic taint module may be started in response to a message. The dynamic taint module can also generate reports during the crawling phase. The report may include a list of potential vulnerabilities determined by dynamic taint analysis. The report may be sent to the Application Security Scanner 200. Upon receiving the message, the application security scanner 200 may send a second message to disable at least some of the dynamic taint modules. Upon receiving the second message, the dynamic tain module invalidates the dynamic tain module and / or a part of the dynamic tain module. Disabling the dynamic taint module enables, for example, dynamic taint analysis that may be associated with a particular attack vector that will be used by the application security scanner 200, as well as such attack vector. May include limiting or invalidating parts that are irrelevant to. As the attack vector changes, messages may be sent and received to invalidate other parts of the dynamic taint module.

As mentioned above, the dynamic taint module determines potential security vulnerabilities by intercepting AUT program execution during the crawling phase and marking one or more untrusted user inputs as the taint source. To do. Trace various user inputs to determine if each user input causes a dangerous function call. As mentioned above, a dangerous function call can include at least one of a direct database query, file open, file delete, and write function to the hypertext markup language response stream. is there. Also, examples of vulnerabilities include SQL injection (eg direct database query), path manipulation (eg file open, file delete, etc.), cross-site scripting (eg write function to HTML response stream). , Command injection (eg executing shell commands), X-path injection (eg direct XML query), log forgery (eg function for writing error messages to log files), and lightweight directories. Access Protocol (LDAP) injections (eg, direct user directory queries) can be mentioned.

Processors 230 or microprocessors, such as central processing units (CPUs), and / or electronic circuits suitable for reading and executing various instructions are those of modules 210, 214, 216, or crawlers described herein. It may be configured to perform any of these functions. In some situations, various instructions and / or other information such as scanning strategies, reports or list of potential vulnerabilities may be contained in memory 232 or other memory. The application security scanner 200b may provide additional I / O interface 234. For example, an input device 240 such as a keyboard, sensor, touch interface, mouse, microphone, etc. may be used to receive input from the environment surrounding the application security scanner 200b. In addition, information may be presented to the user using an output device 142 such as a display device. Examples of output devices include speakers, display devices, amplifiers, and the like. In addition, in some specific embodiments, some components may be used to perform other functions described herein.

Each of the modules 210, 214, 216, and / or the crawler 212 may include, for example, hardware that includes electronic circuits to implement the functions described herein. As an addition or alternative, each module 210, 214, 216, and / or crawler 212 may be implemented as a series of instructions encoded on a machine-readable storage medium of the computing unit and may be executed by processor 230. is there. In some embodiments, some modules may be implemented as hardware devices and other modules may be implemented as executable instructions.

FIG. 3 is an example diagram showing a web application interface of an application to be inspected. This exemplary diagram shows web page 300, which may be provided by AUT as an interface with a scanner. During the crawling phase, the scanner can determine the entry point for receiving user input from this page. During the crawling phase, the dynamic taint module can determine pre-screened vulnerabilities for each input field on a given page of AUT. The dynamic taint module can determine the list of potential vulnerabilities in Table 1, for example, based on the available fields on web page 300.

<tables num="1"><img id="000002" he="41" wi="159" file="JP5982575B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>

Web page 300 may have input fields for username 302, password 304, location search 306, website search 308, and additional content 310. Username 302 and password 304 can be used for the type of login, and location search 306 may be used to find the location of an object or service, such as an ATM location. Website Search 308 may be used to search the application's web pages. As an example, if the vulnerability is determined by the dynamic taint module by marking untrusted user input as taited in those fields and then tracing the functions that can be called. There is. In this example, the username 302 field may be vulnerable to SQL injection and / or LDAP injection attacks. The location search 306 field is related to the vulnerability against SQL injection attacks, while the website search 308 may be vulnerable to cross-site scripting attacks. The dynamic taint module can create a report containing a list of potential vulnerabilities and send it to the scanner. The scanner can then attack the application based on the information provided, for example by filtering and / or prioritizing various attacks based on a list of potential vulnerabilities.

FIG. 4 is an example flow diagram showing how to attack an application based on a scanning strategy based on a list of vulnerabilities generated by a dynamic taint module. Method 400 may be implemented using suitable components such as scanner 102, application security scanner 200, or arithmetic unit 500. In addition, the components for executing the method 400 may be distributed and arranged in a plurality of devices. Method 400 may be implemented in the form of various executable instructions stored on a machine-readable storage medium, such as storage medium 520, and / or in the form of electronic circuits. There is also.

At 402, the scanner initiates the crawling phase of the security test with the dynamic taint module associated with the application under inspection. The application can initialize the dynamic taint module. Initialization may include determining if the application contains a dynamic taint module and activating one or more functions of the dynamic taint module. Initialization may also include setting one or more variables or settings to a given value. The scanner can allow the application to be crawled. During the crawling phase, the dynamic taint module performs analysis on the various inputs found by the scanner. As mentioned above, this analysis may generate a report containing a list of potential vulnerabilities. The application and / or the dynamic taint module can send the report to the scanner.

At 404, the scanner receives a report from the dynamic taint module and / or application. The report may include a list of potential vulnerabilities. Then, at 406, the scanner generates a dynamic taint module limit. As an example, this limit may be generated by sending a message to an application and / or a dynamic taint module.

At 408, the scanner can generate a scanning strategy based on the report's list of potential vulnerabilities. Scan strategies may be further based on other scan strategies, such as pre-created default scan strategies or dynamically created scan strategies. As an example, a scanning strategy involves prioritizing a list of potential vulnerabilities in the event of an attack on an application. As another example, an attack strategy may consist of attacks related to a vulnerability on the candidate list of vulnerabilities. In another example, the attack strategy may include attacks related to the vulnerability. At 410, the scanner can implement an attack strategy against the application under inspection.

According to the above approach, it is possible to reduce the application scanning time without losing the results of the security vulnerability investigation. Also, in some situations, incorporating a dynamic taint module into an application security scanner can be detected by the scanner alone, such as persistent cross-site scripting (PXSS) or blind SQL injection. It may help find security vulnerabilities that cannot be detected or are difficult to detect with the scanner alone. In some examples, potential vulnerabilities may be listed as vulnerabilities. For example, instead of reporting a vulnerability as a potential vulnerability, the dynamic taint module may directly mark the PXSS or blind SQL injection reported by the dynamic taint module as a vulnerability. In addition, the scanner can read such vulnerabilities on the list of candidate vulnerabilities as vulnerabilities.

FIG. 5 is a block diagram showing an example computing device capable of generating an attack against a web application based on a list of vulnerabilities. The computer 500 includes, for example, a processor 510 and a machine-readable storage medium 520 containing instructions 522, 524, 526 for generating an attack against a web application based on a list of potential vulnerabilities. The arithmetic unit 500 may include, for example, a notebook computer, a server, a workstation, a desktop computer, or any other arithmetic unit.

Processor 510 is at least one central processing unit (CPU), at least one semiconductor-based microprocessor, and at least one graphics suitable for reading and executing various instructions stored on a machine-readable storage medium 520. It may be a processing unit (GPU), other hardware devices, or a combination thereof. For example, the processor 510 may include multiple cores on one chip, may include multiple cores across multiple chips, or may include multiple cores across multiple devices (eg,). , Computer 500 includes multiple node devices), or a combination thereof. Processor 510 can fetch, decode, and execute instructions 522, 524, and 526 to implement method 400. As an alternative or addition to reading and executing instructions, processor 510 includes at least one integrated circuit (IC), other control logic, including a number of electronic components to perform the functions of instructions 522, 524, 526. , Other electronic circuits, or combinations thereof.

The machine-readable storage medium 520 may be any electronic, magnetic, optical, or physical storage device that stores or stores various executable instructions. Thus, machine-readable storage media include, for example, random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), storage devices, and compact disk read-only memory (CD-). It may be ROM) or the like. Therefore, the machine-readable storage medium may be persistent. As described in detail herein, the machine-readable storage medium 520 may be encoded by a series of executable instructions for performing method 400. In some examples, another arithmetic unit may be used to implement the application under inspection.

Communication instruction 522 may be used to cause the dynamic taint module associated with application 530 to initiate the crawling phase of security testing by controlling the communication hardware to send messages. .. As mentioned above, the dynamic taint module can generate a list of potential vulnerabilities that may be used to generate attack strategies for scanning. During the crawling phase, the compute unit can acquire various attack entry points for the application.

Communication instruction 522 may also be executed to receive a report from the dynamic taint module. The report contains a list of potential vulnerabilities. As mentioned above, the candidate list of vulnerabilities marks one or more untrusted user inputs as the source of the taint, traces the user inputs, and determines whether individual user inputs cause dangerous function calls. It may contain potential vulnerabilities in attack entry points determined by judgment. Dangerous function calls may be determined based on analysis of the code and / or based on a given list.

The arithmetic unit 500 then generates a message to generate a limit for the dynamic taint module. The message is sent to application 530, stopping the dynamic taint module. As mentioned above, this limitation may speed up security testing by limiting the execution required for application 530 and / or the computing device running application 530.

Strategy instruction 524 may be executed to generate a scanning strategy based on a list of potential vulnerabilities. As mentioned above, as an example, a scanning strategy can prioritize various attacks related to a list of potential vulnerabilities. As another example, a scanning strategy can filter (remove) attacks that are not related to the candidate list of vulnerabilities. With either approach, the expected attack can be performed by Arithmetic Logic Unit 500 by executing attack instruction 526 using individual scanning strategies. By limiting or prioritizing attacks on applications, impossible attacks will not be used, resulting in more effective attacks in less time.