WO2024252676A1 - Dispositif, procédé et programme de détection - Google Patents

Dispositif, procédé et programme de détection Download PDF

Info

Publication number
WO2024252676A1
WO2024252676A1 PCT/JP2023/021570 JP2023021570W WO2024252676A1 WO 2024252676 A1 WO2024252676 A1 WO 2024252676A1 JP 2023021570 W JP2023021570 W JP 2023021570W WO 2024252676 A1 WO2024252676 A1 WO 2024252676A1
Authority
WO
WIPO (PCT)
Prior art keywords
function
source code
software
patch
similarity
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2023/021570
Other languages
English (en)
Japanese (ja)
Inventor
玲佳 荒川
楊 鐘本
拓也 南
浩義 瀧口
高明 小山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Inc
Original Assignee
Nippon Telegraph and Telephone Corp
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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to PCT/JP2023/021570 priority Critical patent/WO2024252676A1/fr
Priority to JP2025525919A priority patent/JPWO2024252676A1/ja
Publication of WO2024252676A1 publication Critical patent/WO2024252676A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • the present invention relates to a detection device, a detection method, and a detection program.
  • the detection device of the present invention is characterized by having an acquisition unit that acquires at least one of the source code of a function of software having a vulnerability before application of a patch and the source code of the function after application of the patch, and a determination unit that uses feature vectors created from the function included in the source code acquired by the acquisition unit and the function included in the source code of the function of the software to be inspected by a set similarity calculation algorithm to calculate the similarity between the feature vectors, and determines whether the function included in the software to be inspected is vulnerable based on the similarity.
  • the present invention has the effect of being able to properly detect vulnerabilities in edited software.
  • FIG. 1 is a diagram showing an overview of a detection process performed by a detection device according to an embodiment.
  • FIG. 2 is a diagram showing software to be inspected that was used in a comparative experiment using the detection device according to the embodiment.
  • FIG. 3 is a diagram showing experimental results of a comparative experiment using the detection device according to the embodiment.
  • FIG. 4 is a diagram illustrating an example of the configuration of a detection device according to an embodiment.
  • FIG. 5 is a diagram illustrating an example of data stored in the detection device according to the embodiment.
  • FIG. 6 is a diagram illustrating a specific example of a feature vector according to the embodiment.
  • FIG. 7 is a diagram showing a specific example of the detection process according to the embodiment.
  • FIG. 1 is a diagram showing an overview of a detection process performed by a detection device according to an embodiment.
  • FIG. 2 is a diagram showing software to be inspected that was used in a comparative experiment using the detection device according to the embodiment.
  • FIG. 3 is a
  • FIG. 8 is a diagram showing a specific example of the detection process according to the embodiment.
  • FIG. 9 is a diagram showing a specific example of the detection process according to the embodiment.
  • FIG. 10 is a diagram showing a specific example of the detection process according to the embodiment.
  • FIG. 11 is a diagram showing a specific example of information output by the detection process according to the embodiment.
  • FIG. 12 is a flowchart illustrating an example of the flow of the detection process according to the embodiment.
  • FIG. 13 is a diagram illustrating an example of a computer that executes a detection program.
  • Non-Patent Documents 1 to 3 all involve three common processes. First, as a preprocessing of the source code, only the function description section is extracted from each of the three pieces of code - the software code to be inspected and the source code before and after the patch to be compared - and variable names, type names, etc. are abstracted. Next, each piece of code that has been preprocessed is converted into data such as hash values and signatures. The converted data are then compared, and if there is a certain percentage or more of match with the vulnerable code before the patch was applied, it is detected that a known vulnerability exists in the software to be inspected.
  • ReDeBug does not abstract variable names, but divides the source file into four lines, hashes the token strings within them, and stores them in a data structure called Bloom Filter. It then compares the stored bit strings and outputs a vulnerability detection result if the data matches.
  • VUDDY abstracts variable names and type names, and builds a database for each function with "key: string length of function body” and "value: hash value”. It then compares the "key” and "value” in the database and outputs a vulnerability detection result if the record in the function database of the target OSS matches the record in the function database before the patch was applied.
  • MOVERY then creates a "pre-patch signature" and a "post-patch signature” in advance for each function for which a vulnerability has been reported.
  • the "pre-patch signature” is created by taking the difference between the pre-patch state of the function at the time of the initial report and the pre-patch state at the time of the most recent report, and combining the common lines into a function-specific pre-patch signature.
  • the "post-patch signature” is created by combining the lines to which the patch has been applied.
  • MOVERY compares the lines of the software being inspected with the signature, and outputs a vulnerability detection result if the data matches.
  • function editing refers to code editing such as adding or deleting lines or changing the order, and survey results have shown that code editing occurs at a rate of over 90% when an SA developer updates the version of the SA itself, or when a developer of another software (SB) partially reuses an SA, edits it, and incorporates it into the SA.
  • SB software
  • the detection device 100 according to the present embodiment has been invented for the purpose of appropriately detecting vulnerabilities even when code edits such as those described above have been made, and has the effect of being able to appropriately detect vulnerabilities in software that has been edited.
  • FIG. 1 is a diagram showing an overview of the detection processing performed by the detection device according to the embodiment.
  • the detection device 100 is a server device that transmits and receives information via a network to, for example, an external database having data related to vulnerability information, or an external information processing device having software to be inspected, and stores vulnerability detection results, and is realized by a PC (Personal Computer), a cloud system, or the like.
  • PC Personal Computer
  • the detection device 100 acquires at least one of the source code of the function before the patch is applied and the source code of the function after the patch is applied for the function of the software having a vulnerability.
  • the detection device 100 uses feature vectors created from the function included in the acquired source code and the function included in the source code of the function of the software being inspected by a set similarity calculation algorithm to calculate the similarity between the feature vectors, and determines whether the function included in the software being inspected is vulnerable based on the similarity.
  • the detection device 100 first obtains at least one of the source code of the function before the patch is applied and the source code of the function after the patch is applied for the function of the software having a vulnerability.
  • the acquisition unit 121 of the detection device 100 obtains the latest CVE (Common Vulnerabilities and Exposures) number listed in the NVD database, and obtains at least one of the source codes of the function before or after the patch is applied from the vulnerability information linked to the CVE number.
  • CVE Common Vulnerabilities and Exposures
  • the detection device 100 extracts the portion of the acquired source code in which functions are written, and creates a feature vector for each function by applying the set similarity calculation algorithm described below to the extracted functions. The detection device 100 then determines whether the functions included in the test target are vulnerable by, for example, calculating the similarity between the feature vector of the function before or after patch application and the feature vector of the software to be tested, and comparing it with a threshold value.
  • FIG. 5(A) is a specific example of data stored in the function information storage unit 131, and shows that the source code before and after patch application are stored separately for each CVE number.
  • FIG. 5(B) is a specific example of data stored in the detection information storage unit 132, and shows that information about functions determined to be vulnerable, such as "function name: b_unpack”, “file name: sample”, “similarity (before application): 0.95312", “similarity (after application) 0.78125”, and "CVE number: CVE-2018-11219", is stored for each function.
  • control unit 120 is realized by a CPU (Central Processing Unit), MPU (Micro Processing Unit), etc., executing various programs stored in a storage device inside the device using RAM as a working area.
  • the control unit 120 is also realized by an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array).
  • the control unit 120 has an acquisition unit 121 and a determination unit 122, and may have a preprocessing unit 123 and a storage unit 124 as necessary.
  • the acquisition unit 121 acquires at least one of the source code of the function before the patch is applied and the source code of the function after the patch is applied for a function of software having a vulnerability.
  • the acquisition unit 121 may also acquire the source code of the function before the patch is applied and the source code of the function after the patch is applied.
  • the determination unit 122 compares the calculated similarity with a preset threshold value and determines that the function included in the software being inspected is vulnerable if the similarity with the function before the patch is applied is equal to or greater than the threshold value, or if the similarity with the function after the patch is applied is equal to or less than the threshold value.
  • the determination unit 122 first compares the similarity between the feature vector of the function included in the software to be inspected and the feature vector of the function before the patch is applied with a preset threshold value. After that, for functions whose similarity is equal to or greater than the threshold value, the determination unit 122 compares the magnitude of the similarity between the feature vector of the function before the patch is applied and the feature vector of the function after the patch is applied, and if the similarity between the feature vector of the function before the patch is greater, it determines that the function included in the software to be inspected is vulnerable.
  • FIG. 6 is a diagram for explaining a specific example of a feature vector according to an embodiment.
  • the seed setting value is "128”
  • a feature vector is shown in which the lowest 1 bit of each hash value is used as an element.
  • the preprocessing unit 123 creates a feature vector by recording only the lowest "1 bit" of each function with the number of seed values "128".
  • the preprocessing unit 123 creates a set of elements each consisting of a logical block included in the portion of the source code in which the function is described, as a feature vector. For example, after performing the above-mentioned process from the extraction process to the standardization process of the function description unit, the preprocessing unit 123 creates a set of elements each consisting of a logical block included in the function, as a feature vector of the function.
  • a logical block refers to a certain number of lines or control statement blocks written in the function description unit in the source code.
  • Fig. 7 to Fig. 10 are diagrams showing a specific example of the detection process according to the embodiment.
  • a specific example of the process using b-bit minhash as the inter-set similarity calculation algorithm will be described with reference to Fig. 7. Note that in the example of Fig. 7, it is assumed that the feature vector is set to be created using the lowest 1 bit.
  • the similarity is calculated using the formula "(number of matching bits/length of feature vector of b-bitminhash-1/2) x 2".
  • the number of matching bits is expressed by subtracting the number of different bits from the length of the feature vector of b-bitminhash, and the length of the feature vector corresponds to the seed value.
  • the number of different bits is calculated using an XOR operation, and 1/2 in the above formula indicates the probability of an error of 0 or 1.
  • the determination unit 122 compares "similarity S: 95%” with "similarity S': 78%”. As a result, since similarity S is a higher value, the determination unit 122 determines that the function included in the software being inspected is a vulnerable function.
  • Fig. 12 is a flowchart showing an example of the flow of the detection process according to the embodiment. Note that the order of the processing steps described in the flowchart shown in Fig. 12 may be changed.
  • the acquisition unit 121 acquires the source code of a function before and after application of a patch for a known vulnerability code (step S101).
  • the preprocessing unit 123 accepts the software to be inspected (step S102). If the software to be inspected has been accepted (step S102; Yes), the preprocessing unit 123 creates feature vectors for the source code of the function before and after application of the patch and for the source code of the function of the software to be inspected (step S103). On the other hand, if the software to be inspected has not been accepted (step S102; No), the preprocessing unit 123 waits until the software to be inspected is accepted.
  • the determination unit 122 determines whether the similarity between the feature vector before application of the patch and the feature vector of the software to be inspected is equal to or greater than a threshold value (step S104). If the similarity between the feature vector before application of the patch and the feature vector of the software to be inspected is equal to or greater than the threshold value (step S104; Yes), the determination unit 122 determines whether the similarity before application of the patch is equal to or greater than the similarity after application of the patch (step S105). On the other hand, if the similarity between the feature vector before application of the patch and the feature vector of the software to be inspected is not equal to or greater than the threshold value (step S104; No), the detection device 100 ends the process.
  • the determination unit 122 uses feature vectors created from the functions included in the source code acquired by the acquisition unit 121 and the functions included in the source code of the software to be inspected by a set similarity calculation algorithm to calculate the similarity between the feature vectors, and determines whether the functions included in the software to be inspected are vulnerable based on the similarity.
  • the detection device 100 creates a set (feature vector) whose components are data based on part of the function for each of the functions to be inspected and the functions to be compared, and calculates the similarity between the sets, thereby achieving the effect of being able to appropriately detect vulnerabilities even in software that has been edited.
  • the acquisition unit 121 of the detection device 100 acquires the source code of the function before application of the patch and the source code of the function after application of the patch, and the determination unit 122 determines that the function included in the software to be inspected is vulnerable if the similarity between the feature vector of the function before application of the patch and the feature vector of the function of the software to be inspected is equal to or greater than a predetermined threshold value and the similarity between the feature vector of the function before application of the patch and the feature vector of the function of the software to be inspected is higher than the similarity between the feature vector of the function after application of the patch and the feature vector of the function of the software to be inspected.
  • the detection device 100 compares the magnitude of similarity before and after patch application only for functions whose similarity to vulnerable functions before patch application exceeds a threshold value, thereby preventing the detection device 100 from treating functions whose similarity to vulnerable functions after patch application is higher than a certain level as functions whose vulnerabilities have already been eliminated, and erroneously detecting them as vulnerable functions.
  • the detection device 100 creates a set (feature vector) with each line of a vulnerable function included in the software being inspected as an element, and applies b-bitminhash, a fast and lightweight algorithm for calculating similarity between sets, to appropriately detect vulnerabilities.
  • the preprocessing unit 123 of the detection device 100 creates a feature vector, which is a set of elements each of which is a token included in the portion of the source code where the function is written. In this way, the detection device 100 creates a set of elements each of which is a token (word unit) for each function, thereby calculating the degree of agreement of finer elements as the degree of similarity, which has the effect of enabling highly accurate vulnerability detection.
  • the preprocessing unit 123 of the detection device 100 also creates a feature vector, which is a set whose elements are the logical blocks contained in the portion of the source code where the function is written. This allows the detection device 100 to create a set whose elements are logical blocks (a certain number of lines or control statement blocks) for each function, thereby achieving the effect of being able to perform vulnerability detection under conditions where each set has a relatively small number of elements.
  • the detection device 100 further includes a storage unit 124.
  • the storage unit 124 stores information about functions that have been determined to be vulnerable by the determination unit in the memory unit 130. This allows the detection device 100 to provide an effect of allowing the user to easily grasp the detection results, etc., of functions that have been determined to have vulnerabilities among the functions included in the software to be inspected.
  • each component of each device shown in the figure is a functional concept, and does not necessarily have to be physically configured as shown in the figure.
  • the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or part of it can be functionally or physically distributed and integrated in any unit depending on various loads and usage conditions.
  • each processing function performed by each device can be realized in whole or in part by a CPU and a program analyzed and executed by the CPU, or can be realized as hardware using wired logic.
  • Hardware Configuration 13 is a diagram showing an example of a hardware configuration of the detection device 100 according to the embodiment described above, which is realized by a computer 1000 having a configuration as shown in FIG.
  • FIG. 13 is a diagram showing an example of a computer that executes a detection program.
  • the computer 1000 has, for example, a memory 1010 and a CPU 1020.
  • the computer 1000 also has a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. Each of these components is connected by a bus 1080.
  • the memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012.
  • the ROM 1011 stores a boot program such as a BIOS (Basic Input Output System).
  • BIOS Basic Input Output System
  • the hard disk drive interface 1030 is connected to a hard disk drive 1090.
  • the disk drive interface 1040 is connected to a disk drive 1041.
  • a removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1041.
  • the serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example.
  • the video adapter 1060 is connected to a display 1130, for example.
  • the hard disk drive 1090 stores, for example, an OS (Operating System) 1091, an application program 1092, a program module 1093, and program data 1094. That is, the programs that define each process of the detection device 100 are implemented as program modules 1093 in which code executable by the computer 1000 is written.
  • the program modules 1093 are stored, for example, in the hard disk drive 1090.
  • a program module 1093 for executing processes similar to the functional configuration of the detection device 100 is stored in the hard disk drive 1090.
  • the hard disk drive 1090 may be replaced by an SSD (Solid State Drive).
  • the setting data used in the processing of the above-mentioned embodiment is stored as program data 1094, for example, in memory 1010 or hard disk drive 1090.
  • the CPU 1020 reads the program module 1093 or program data 1094 stored in memory 1010 or hard disk drive 1090 into RAM 1012 as necessary and executes it.
  • the program module 1093 and program data 1094 are not limited to being stored in the hard disk drive 1090, but may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1041 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (LAN, WAN, etc.). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070.
  • Detection device 110 Communication unit 120 Control unit 121 Acquisition unit 122 Determination unit 123 Preprocessing unit 124 Storage unit 130 Memory unit 131 Function information storage unit 132 Detection information storage unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Un dispositif de détection (100) selon le présent mode de réalisation de l'invention, comprend : une unité d'acquisition (121) ; et une unité de détermination (122). L'unité d'acquisition (121) acquiert, pour une fonction logicielle vulnérable, au moins le code source de la fonction avant l'application d'un correctif et/ou le code source de la fonction après l'application du correctif. L'unité de détermination (122) calcule la similarité entre des vecteurs de caractéristiques générés par un algorithme de calcul de similarité inter-ensembles, à partir d'une fonction incluse dans le code source acquis par l'unité d'acquisition (121) et une fonction incluse dans le code source d'une fonction incluse dans le logiciel à inspecter, respectivement, à l'aide des vecteurs de caractéristiques, et détermine si la fonction incluse dans le logiciel à inspecter est vulnérable sur la base de la similarité.
PCT/JP2023/021570 2023-06-09 2023-06-09 Dispositif, procédé et programme de détection Ceased WO2024252676A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2023/021570 WO2024252676A1 (fr) 2023-06-09 2023-06-09 Dispositif, procédé et programme de détection
JP2025525919A JPWO2024252676A1 (fr) 2023-06-09 2023-06-09

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2023/021570 WO2024252676A1 (fr) 2023-06-09 2023-06-09 Dispositif, procédé et programme de détection

Publications (1)

Publication Number Publication Date
WO2024252676A1 true WO2024252676A1 (fr) 2024-12-12

Family

ID=93795820

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/021570 Ceased WO2024252676A1 (fr) 2023-06-09 2023-06-09 Dispositif, procédé et programme de détection

Country Status (2)

Country Link
JP (1) JPWO2024252676A1 (fr)
WO (1) WO2024252676A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008046695A (ja) * 2006-08-11 2008-02-28 Kobe Univ 類似度評価プログラム、類似度評価装置及び類似度評価方法
WO2017061270A1 (fr) * 2015-10-09 2017-04-13 日本電信電話株式会社 Dispositif, procédé et programme de découverte de vulnérabilité
JP2023031614A (ja) * 2021-08-25 2023-03-09 株式会社東芝 変更度計測装置、方法及びプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008046695A (ja) * 2006-08-11 2008-02-28 Kobe Univ 類似度評価プログラム、類似度評価装置及び類似度評価方法
WO2017061270A1 (fr) * 2015-10-09 2017-04-13 日本電信電話株式会社 Dispositif, procédé et programme de découverte de vulnérabilité
JP2023031614A (ja) * 2021-08-25 2023-03-09 株式会社東芝 変更度計測装置、方法及びプログラム

Also Published As

Publication number Publication date
JPWO2024252676A1 (fr) 2024-12-12

Similar Documents

Publication Publication Date Title
US11693962B2 (en) Malware clustering based on function call graph similarity
Zhang et al. Libid: reliable identification of obfuscated third-party android libraries
Wang et al. Orlis: Obfuscation-resilient library detection for android
JP6088713B2 (ja) 脆弱性発見装置、脆弱性発見方法、及び脆弱性発見プログラム
CN108268777B (zh) 一种利用补丁信息进行未知漏洞发现的相似性检测方法
CN103473346B (zh) 一种基于应用程序编程接口的安卓重打包应用检测方法
US20170372068A1 (en) Method to identify known compilers functions, libraries and objects inside files and data items containing an executable code
US20180089430A1 (en) Computer security profiling
CN111222137A (zh) 一种程序分类模型训练方法、程序分类方法及装置
US20070152854A1 (en) Forgery detection using entropy modeling
US20130160125A1 (en) Method and system for rapid signature search over encrypted content
CN112651028B (zh) 基于上下文语义和补丁验证的漏洞代码克隆检测方法
US11960597B2 (en) Method and system for static analysis of executable files
CN117940894A (zh) 用于检测代码克隆的系统和方法
CN114936366A (zh) 基于混合分析的恶意软件家族标签更正方法及装置
Breitinger et al. Evaluating detection error trade-offs for bytewise approximate matching algorithms
JP7315023B2 (ja) ルール生成装置およびルール生成プログラム
Hubballi et al. Detecting packed executable file: Supervised or anomaly detection method?
Namanya et al. Evaluation of automated static analysis tools for malware detection in Portable Executable files
Chen et al. IHB: A scalable and efficient scheme to identify homologous binaries in IoT firmwares
WO2024252676A1 (fr) Dispositif, procédé et programme de détection
JP2022522383A (ja) 既知及び／又は未知のサイバーセキュリティ脅威の形態素解析によりデータ異常を検出するシステム及び方法
Rowe Identifying forensically uninteresting files in a large corpus.
RU101223U1 (ru) Система для быстрого обнаружения похожих объектов с использованием сверток
Akram et al. DroidSD: An Efficient Indexed Based Android Applications Similarity Detection Tool.

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: 23940773

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2025525919

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE