KR102488943B1 - MS-PPT에서 Link의 무해화를 위한 방법 및 장치 - Google Patents

MS-PPT에서 Link의 무해화를 위한 방법 및 장치 Download PDF

Info

Publication number
KR102488943B1
KR102488943B1 KR1020220131354A KR20220131354A KR102488943B1 KR 102488943 B1 KR102488943 B1 KR 102488943B1 KR 1020220131354 A KR1020220131354 A KR 1020220131354A KR 20220131354 A KR20220131354 A KR 20220131354A KR 102488943 B1 KR102488943 B1 KR 102488943B1
Authority
KR
South Korea
Prior art keywords
record
usereditatom
persistdirectoryatom
server
persistoffsetentry
Prior art date
Application number
KR1020220131354A
Other languages
English (en)
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 KR1020220131354A priority Critical patent/KR102488943B1/ko
Application granted granted Critical
Publication of KR102488943B1 publication Critical patent/KR102488943B1/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/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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9566—URL specific, e.g. using aliases, detecting broken or misspelled links
    • 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/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

본 명세서는 서버가 MS-PPT 파일의 링크정보를 무해화(Disarming) 시키는 방법에 있어서, 상기 MS-PPT 파일의 Current User Stream에서 UserEditAtom 레코드의 위치를 획득하는 단계; 상기 UserEditAtom 레코드의 위치에 근거하여, PowerPoint Document Stream에서 상기 UserEditAtom 레코드를 읽는 단계; 상기 UserEditAtom 레코드에 근거하여, PersistDirectoryAtom 레코드를 읽는 단계; 상기 PersistDirectoryAtom 레코드에 근거하여, PersistOffsetEntry 배열을 획득하는 단계; 상기 PersistOffsetEntry 배열이 나타내는 레코드가 DocumentContainer 인지 여부를 판단하는 단계; 및 상기 DocumentContainer가 ExHyperlinkContainer를 포함한 것에 근거하여, 상기 링크정보를 무해화 할 수 있다.

Description

MS-PPT에서 Link의 무해화를 위한 방법 및 장치 {METHODS AND APPARATUS FOR DISARMING A LINK IN MS-PPT}
본 명세서는 MS-PPT 파일에서 Link의 무해화를 위한 방법 및 장치에 관한 것이다.
지능형 지속 위협(Advanced Persistent Threat, APT) 공격은 공격자가 특정 타깃을 정하고 목표한 정보를 빼내기 위해 고도의 공격기법을 적용하여 지속적으로 다양한 형태의 악성 코드를 활용한다. 특히 APT 공격은 초기 침입단계에서 탐지하지 못하는 경우가 많으며, 실행(Portable Executable, PE) 파일보다는 악성 코드를 포함하는 비실행(Non-Portable Executable, Non-PE) 파일을 이용하는 경우가 많다.
비실행 파일은 실행 파일과 반대되는 개념으로써, 자체적으로 실행되지 않는 파일을 의미한다. 비실행 파일로는 워드 파일, 엑셀 파일, 한글 파일, PDF 파일 등의 문서 파일, 이미지 파일, 동영상 파일, 자바스크립트 파일, 및 HTML 파일을 예로 들 수 있다. APT 공격에 악성 코드가 포함된 비실행 파일이 많이 이용되는 이유는 비실행 파일을 실행하는 응용 프로그램이 기본적으로 어느 정도의 보안 취약성을 가지고 있기 때문이다. 뿐만 아니라, 악성 코드를 비실행 파일에 포함시키면 파일을 변경하여 변종 악성 코드를 손쉽게 만들 수 있기 때문이다.
문서 행위란 비실행 파일이 관련된 응용 프로그램의 액션을 실행하는 행위이다. 기존의 APT 솔루션들은 문서 행위 기반으로 동작하기 때문에 문서 행위 발생 후, 샌드박스(Virtural Machine, VM)의 변화를 관찰하여 악성 여부를 판단한다. 이는 문서 행위의 발현을 전부 기다린 후 악성 여부를 파악하기 때문에 분석시간이 오래 걸린다.
또한, CDR과 같은 기존 APT 솔루션들은 악성 액티브 콘텐츠를 제거할 수는 있지만, 문서의 필수 요소(예를 들어, 본문, 폰트)에서 발생하는 취약점을 제거할 수는 없기 때문에 보안 공백이 발생한다.
비실행 파일에는 유해한 링크 정보가 포함될 가능성이 있기 때문에, 링크 정보를 무해화하여야 한다. 이 경우에는 비실행 파일의 레이아웃이 바뀌거나 틀어지는 문제가 발생하지 않아야 한다.
본 명세서의 목적은, MS-PPT의 전체 구조를 유지하면서 Link를 무해화 하기 위한 방법을 제안한다.
본 명세서가 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 이하의 명세서의 상세한 설명으로부터 본 명세서가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 명세서의 일 양상은, 서버가 MS-PPT 파일의 링크정보를 무해화(Disarming) 시키는 방법에 있어서, 상기 MS-PPT 파일의 Current User Stream에서 UserEditAtom 레코드의 위치를 획득하는 단계; 상기 UserEditAtom 레코드의 위치에 근거하여, PowerPoint Document Stream에서 상기 UserEditAtom 레코드를 읽는 단계; 상기 UserEditAtom 레코드에 근거하여, PersistDirectoryAtom 레코드를 읽는 단계; 상기 PersistDirectoryAtom 레코드에 근거하여, PersistOffsetEntry 배열을 획득하는 단계; 상기 PersistOffsetEntry 배열이 나타내는 레코드가 DocumentContainer 인지 여부를 판단하는 단계; 및 상기 DocumentContainer가 ExHyperlinkContainer를 포함한 것에 근거하여, 상기 링크정보를 무해화하는 단계; 를 포함할 수 있다.
또한, 상기 UserEditAtom 레코드의 위치를 획득하는 단계는 상기 Current User Stream에서 CurrentUserAtom 레코드를 읽는 단계; 및 상기 CurrentUserAtom 레코드의 offsetToCurrentEdit 필드에 근거하여, 상기 UserEditAtom 레코드의 위치를 획득하는 단계; 를 포함할 수 있다.
또한, 상기 PersistDirectoryAtom 레코드를 읽는 단계는 상기 UserEditAtom 레코드의 offsetPersistDirectory 필드에 의해 지정된 오프셋에 근거할 수 있다.
또한, 상기 PersistOffsetEntry 배열을 획득하는 단계는 상기 PersistDirectoryAtom 레코드의 rgPersistDirEntry 필드를 통해, PersistDirectoryEntry 레코드를 읽는 단계; 및 상기 PersistDirectoryEntry 레코드의 rgPersistOffset 필드에 근거하여, 상기 PersistOffsetEntry 배열을 획득하는 단계; 를 포함할 수 있다.
또한, 상기 링크정보를 무해화하는 단계는 상기 DocumentContainer의 exObjList 필드를 통해, ExObjListContainer 레코드가 있는지 판단하는 단계; 상기 ExObjListContainer 레코드의 rgChildRec 필드에 근거하여, ExObjListSubContainer 레코드를 찾는 단계; 및 상기 ExObjListSubContainer 레코드의 rh.recType 값에 근거하여, 상기 ExHyperlinkContainer를 확인하는 단계; 를 포함할 수 있다.
또한, 상기 링크정보를 무해화하는 단계는 상기 ExHyperlinkContainer의 targetAtom 레코드에 포함된 target 필드값에서 scheme 만 남기는 단계; 를 더 포함할 수 있다.
본 명세서의 또 다른 일 양상은, MS-PPT 파일의 링크정보를 무해화(Disarming) 시키는 서버에 있어서, 통신부; 메모리; 및 상기 통신부 및 상기 메모리를 기능적으로 제어하는 프로세서;를 포함하고, 상기 프로세서는 상기 MS-PPT 파일의 Current User Stream에서 UserEditAtom 레코드의 위치를 획득하고, 상기 UserEditAtom 레코드의 위치에 근거하여, PowerPoint Document Stream에서 상기 UserEditAtom 레코드를 읽고, 상기 UserEditAtom 레코드에 근거하여, PersistDirectoryAtom 레코드를 읽으며, 상기 PersistDirectoryAtom 레코드에 근거하여, PersistOffsetEntry 배열을 획득하고, 상기 PersistOffsetEntry 배열이 나타내는 레코드가 DocumentContainer 인지 여부를 판단하며, 상기 DocumentContainer가 ExHyperlinkContainer를 포함한 것에 근거하여, 상기 링크정보를 무해화할 수 있다.
본 명세서의 실시예에 따르면, MS-PPT의 전체 구조를 유지하면서 Link를 무해화를 수행할 수 있다.
본 명세서에서 얻을 수 있는 효과는 이상에서 언급한 효과로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 명세서가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 명세서와 관련된 서버 또는 클라이언트를 나타내는 도면이다.
도 2는 본 명세서에 적용될 수 있는 비정상 입력의 예시이다.
도 3은 본 명세서가 적용될 수 있는 URI 구성을 예시한다.
도 4는 본 명세서가 적용될 수 있는 MS-PPT 파일의 무해화 방법을 예시한다.
도 5는 본 명세서가 적용될 수 있는 CurrentUserAtom 레코드의 예시이다.
도 6은 본 명세서가 적용될 수 있는 UserEditAtom 레코드의 예시이다.
도 7은 본 명세서가 적용될 수 있는 PersistDirectoryAtom 레코드의 예시이다.
도 8은 본 명세서가 적용될 수 있는 PersistDirectoryEntry 레코드의 예시이다.
도 9는 본 명세서가 적용될 수 있는 ExHyperlinkContainer 레코드의 예시이다.
도 10은 본 명세서가 적용될 수 있는 DocumentContainer 레코드를 예시한다.
도 11은 본 명세서가 적용될 수 있는 ExObjListContainer 레코드를 예시한다.
본 명세서에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 명세서에 대한 실시예를 제공하고, 상세한 설명과 함께 본 명세서의 기술적 특징을 설명한다.
이하, 첨부된 도면을 참조하여 본 명세서에 개시된 실시예를 상세히 설명하되, 도면 부호에 관계없이 동일하거나 유사한 구성요소는 동일한 참조 번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다. 또한, 본 명세서에 개시된 실시예를 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 명세서에 개시된 실시예의 요지를 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 명세서에 개시된 실시예를 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 명세서에 개시된 기술적 사상이 제한되지 않으며, 본 명세서의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
제1, 제2 등과 같이 서수를 포함하는 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되지는 않는다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다.
어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.
단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다.
본 명세서에서, "포함한다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
또한, 명세서에서 사용되는 "부"라는 용어는 소프트웨어 또는 하드웨어 구성요소를 의미하며, "부"는 어떤 역할들을 수행한다. 그렇지만 "부"는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. "부"는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 "부"는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로 코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들 및 변수들을 포함한다. 구성요소들과 "부"들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 "부"들로 결합되거나 추가적인 구성요소들과 "부"들로 더 분리될 수 있다.
또한, 본 명세서의 일 실시예에 따르면 "부"는 프로세서 및 메모리로 구현될 수 있다. 용어 "프로세서"는 범용 프로세서, 중앙 처리 장치 (CPU), 마이크로프로세서, 디지털 신호 프로세서 (DSP), 제어기, 마이크로제어기, 상태 머신 등을 포함하도록 넓게 해석되어야 한다. 몇몇 환경에서는, "프로세서"는 주문형 반도체 (ASIC), 프로그램가능 로직 디바이스 (PLD), 필드 프로그램가능 게이트 어레이 (FPGA) 등을 지칭할 수도 있다. 용어 "프로세서"는, 예를 들어, DSP 와 마이크로프로세서의 조합, 복수의 마이크로프로세서들의 조합, DSP 코어와 결합한 하나 이상의 마이크로프로세서들의 조합, 또는 임의의 다른 그러한 구성들의 조합과 같은 처리 디바이스들의 조합을 지칭할 수도 있다.
용어 "메모리"는 전자 정보를 저장 가능한 임의의 전자 컴포넌트를 포함하도록 넓게 해석되어야 한다. 용어 메모리는 임의 액세스 메모리 (RAM), 판독-전용 메모리 (ROM), 비-휘발성 임의 액세스 메모리 (NVRAM), 프로그램가능 판독-전용 메모리 (PROM), 소거-프로그램가능 판독 전용 메모리 (EPROM), 전기적으로 소거가능 PROM (EEPROM), 플래쉬 메모리, 자기 또는 광학 데이터 저장장치, 레지스터들 등과 같은 프로세서-판독가능 매체의 다양한 유형들을 지칭할 수도 있다. 프로세서가 메모리로부터 정보를 판독하고/하거나 메모리에 정보를 기록할 수 있다면 메모리는 프로세서와 전자 통신 상태에 있다고 불린다. 프로세서에 집적된 메모리는 프로세서와 전자 통신 상태에 있다.
본 명세서에서 사용되는 "비실행 파일"이란 실행 파일 또는 실행 가능한 파일과 반대되는 개념으로서 자체적으로 실행되지 않는 파일을 의미한다. 예를 들어, 비실행 파일은 PDF 파일, 한글 파일, 워드 파일과 같은 문서 파일, JPG 파일과 같은 이미지 파일, 동영상 파일, 자바 스크립트 파일, HTML 파일 등이 될 수 있으나, 이에 한정되지 않는다.
아래에서는 첨부한 도면을 참고하여 실시예에 대하여 본 명세서가 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그리고 도면에서 본 개시를 명확하게 설명하기 위해서 설명과 관계없는 부분들은 생략될 수 있다.
도 1은 본 명세서와 관련된 서버 또는 클라이언트를 나타내는 도면이다.
본 명세서에서 서버(또는 클라우드 서버) 또는 클라이언트는 제어부(100) 및 통신부(130)를 포함할 수 있다. 제어부(100)는 프로세서(110) 및 메모리(120)를 포함할 수 있다. 프로세서(110)는 메모리(120)에 저장된 명령어들을 수행할 수 있다. 프로세서(110)는 통신부(130)를 제어할 수 있다.
프로세서(110)는 메모리(120)에 저장된 명령어에 기초하여 서버 또는 클라이언트의 동작을 제어할 수 있다. 서버 또는 클라이언트는 하나의 프로세서를 포함할 수 있고, 복수의 프로세서를 포함할 수 있다. 서버 또는 클라이언트가 복수의 프로세서를 포함하는 경우, 복수의 프로세서 중 적어도 일부는 물리적으로 이격된 거리에 위치할 수 있다. 또한, 서버 또는 클라이언트는 이에 한정되지 않고 알려진 다양한 방식으로 구현될 수 있다.
통신부(130)는, 서버 또는 클라이언트와 무선 통신 시스템 사이, 서버 또는 클라이언트와 다른 서버 또는 클라이언트 사이, 또는 서버 또는 클라이언트와 외부서버 사이의 무선 통신을 가능하게 하는 하나 이상의 모듈을 포함할 수 있다. 또한, 통신부(110)는, 서버 또는 클라이언트를 하나 이상의 네트워크에 연결하는 하나 이상의 모듈을 포함할 수 있다.
제어부(100)는 메모리(120)에 저장된 응용 프로그램을 구동하기 위하여, 서버 또는 클라이언트의 구성요소들 중 적어도 일부를 제어할 수 있다. 나아가, 제어부(100)는 상기 응용 프로그램의 구동을 위하여, 서버 또는 클라이언트에 포함된 구성요소들 중 적어도 둘 이상을 서로 조합하여 동작 시킬 수 있다.
본 명세서에서 서버는 리버싱 엔진 또는/및 CDR 서비스를 제공하는 CDR 엔진을 포함할 수 있다.
리버싱(Reversing) 엔진
리버싱 엔진이란, 악성 비실행 파일에 대한 리버스 엔지니어링(리버싱) 과정을 자동화 한 분석/진단 엔진이다.
예를 들어, 리버싱 엔진은 다음의 단계를 수행할 수 있다.
1. 파일 분석: 비실행 파일 자체의 외관(예를 들어, 속성, 작성자, 작성 날짜, 파일 타입)을 분석하는 단계로서, 일반 백신 프로그램과 유사하게 비실행 파일 자체의 정보만으로 악성여부를 진단할 수 있다.
2. 정적 분석: 비실행 파일 내의 데이터를 추출, 분석해서 정상, 악성 여부를 판별하는 단계로서, 비실행 파일은 실행하지 않고 파일 구조에 맞게 내부 데이터를 추출하여 비교 분석하여 악성여부를 진단할 수 있다. 이는 매크로, URL 추출 분석 등에 적합할 수 있다.
3. 동적 분석: 비실행 파일을 편집기, 리더기가 포함된 응용프로그램을 통해 읽어들이고 모니터링하면서 행위를 분석하여 악성 여부를 판별하는 단계로서, 매크로, 하이퍼링크, DDE 등 정상기능을 이용한 악성 행위를 탐지하기에 용이하다.
4. 디버깅 분석: 비실행 파일을 읽어들이고 디버깅하여 취약점, 익스플로잇 등을 분석하는 단계로서, 매크로, 하이퍼링크, DDE를 포함하여 문서 내 본문, 표, 폰트, 그림 등을 이용한 응용프로그램의 취약점을 탐지하기에 적합하다.
리버싱 엔진은 디버깅 분석에 사용될 수 있는 디버깅 엔진을 포함할 수 있다. 디버깅 엔진은 비실행 파일의 열람 과정을 디버깅하여 문서 입력, 처리, 출력단계에서 발생하는 취약점을 진단할 수 있다. 여기서 취약점이란, 응용프로그램이 응용프로그램의 개발자가 개발한 코드(로직)에서 예상하지 못한 값을 입력 받았을 때, 발생하는 오류, 버그 등을 이용하는 것으로서, 공격자는 취약점을 통해 비정상 종료로 인한 서비스 거부, 원격 코드 실행 등의 악성 행위를 실행할 수 있다.
CDR(Contents Disarm and Reconstruction)
CDR 서비스는 비실행 파일을 분해해 악성파일 혹은 불필요한 파일을 제거하고 콘텐츠는 원본과 최대한 동일하게 하여, 새로운 파일을 만드는 솔루션이다.
즉, Contents Disarm and Reconstruction(CDR)은 문서 내의 컨텐츠를 무해화(Disarm)하고 재조합(Reconstruction)하여 안전한 문서를 만들어 고객에게 제공하는 서비스를 의미하며, 무해화 대상 파일은 비실행 파일 일체(예를 들어, 워드, 엑셀, 파워포인트, 한글, PDF)를 대상으로 할 수 있으며, 무해화 대상 컨텐츠는 액티브 컨텐츠(예를 들어, 매크로, 하이퍼링크, OLE 객체 등)일 수 있다.
도 2는 본 명세서에 적용될 수 있는 비정상 입력의 예시이다.
도 2를 참조하면, 응용프로그램은 비실행 파일을 통해, 비정상적인 값(예를 들어, 입력값이 정상범위인 2를 초과하는 경우)을 입력 받는 경우, 개발자가 의도하지 않은 실행흐름으로 변경되어 취약점이 동작될 수 있다. 디버깅 엔진은 문서 열람 과정을 자동 디버깅하여 취약점과 관련된 특정 지점에 브레이크 포인트를 설정하고 입력값과 관련된 특정값을 확인하여 입력값이 취약점을 일으키는 값인지 아닌지 판별하여 악성 여부를 진단할 수 있다.
보다 자세하게, 디버깅 엔진은 비실행 파일을 확인하고 이를 열람하기 위한 응용프로그램을 실행하여 디버깅을 시작할 수 있다. 비실행 파일을 열람하는 과정에서 모듈이 로드되면, 디버깅 엔진은 해당 모듈이 분석 대상 모듈인지 확인하고, 분석 대상이라면 지정된 주소에 브레이크 포인트를 설정할 수 있다.
예를 들어, 악성 비실행 파일은 응용프로그램의 버전이나 운영체제 환경 등의 특정 조건이 만족하지 않으면 응용프로그램을 종료하거나 아무런 악성 행위가 발생하지 않는 흐름으로 분기하는 분기 지점들을 가질 수 있다. 서버는 사전에 분석가에 의해 분석되어 이러한 가능성을 가지는 분기 지점에 브레이크 포인트를 설정할 수 있다.
또한, 서버는 해당 분기 지점과 연관되어, 응용프로그램을 종료하지 않고 계속 실행하거나 악성 행위가 발생할 수 있는 흐름으로 유도할 수 있는 조건들을 설정할 수 있다.
응용프로그램의 프로세스 실행 중 해당 브레이크 포인트 지점에서 프로세스가 멈춘 경우, 서버는 탐지 로직에 따라 취약점 여부를 탐지한 후, 결과를 분석 리포트에 저장하는 단계를 수행할 수 있다.
서버에 포함된 자동화 리버싱 엔진은 전술한 단계들을 자동으로 수행하면서 분석하여 분석가가 연구, 개발한 진단 알고리즘을 통해, 악성 비실행 파일을 진단하고 차단할 수 있다.
도 3은 본 명세서가 적용될 수 있는 URI 구성을 예시한다.
도 3을 참조하면, 본 명세서에서 무해화 대상이 되는 링크정보인 URI(Uniform Resource Identifier)를 예시한다.
일반적으로 URI 구문(syntax)은 scheme, authority, path, query, 및 fragment를 포함할 수 있다.
표 1은 본 명세서가 적용될 수 있는 URI 구문의 계층적 시퀀스의 예시이다.
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
예를 들어, URI 구문은 다음의 표 1과 같은 계층적 시퀀스로 구성될 수 있다.도 3 및 표 1을 참조하면, URI에서 “/”와 관련된 규칙은 다음과 같을 수 있다.
(1) When authority is present, the path must either be empty or begin with a slash ("/") character.
(2) When authority is not present, the path cannot begin with two slash characters ("//").
따라서, URI 에서는 authority의 존재 여부에 따라, path와 관련된 “/”의 개수가 정해질 수 있다. 예를 들어, 서버는 “/”를 통해, authority를 판단할 수 있다.
만일, 무해화 작업을 통해, URI를 모두 제거하면, 오피스 문서에서 링크 표시가 사라지는 경우가 생겨 무해화 결과물이 원본과 레이아웃이 달라질 수가 있다. 이러한 문제가 발생하지 않게 하기 위해, 본 명세서에서는 링크 정보를 무해화하는 방안으로 scheme 부터 슬래시(“/”)까지만 남기도록 할 수 있다.
이를 통해 무해화 대상이 되는 문서는 레이아웃을 유지할 수 있고, 사용자는 기존 링크 정보가 어떤 형태(예: http, file, mailto 등)였는지를 직관적으로 인식할 수 있게 한다.
표 2는 본 명세서가 적용될 수 있는 무해화 결과의 예시이다.
원본 무해화 결과
foo://example.com:8042/over/there?name=ferret#nose foo://
urn:example:animal:ferret:nose urn:
https//seculetter.com https://
mailto:anesin@seculleter.com mailto:
도 4는 본 명세서가 적용될 수 있는 MS-PPT 파일의 무해화 방법을 예시한다.
도 4를 참조하면, 비실행 파일의 포맷이 MS-PPT 파일인 경우에 서버의 무해화 방법을 예시한다.
MS-PPT 파일을 비롯한 CFB 계열의 파일에 대해 압축을 해제하면, 디렉토리와 파일 구조를 확인할 수 있다. 이 때 디렉토리 형태를 스토리지(storage), 파일 형태를 스트림(stream)이라고 한다.
MS-PPT는 필드 기능 중 HYPERLINK를 사용해 링크 정보를 삽입할 수 있다.
서버는 Current User Stream 및 PowerPoint Document Stream을 통해, 개체(object)(예를 들어, 이미지, 도형 등)용 링크 정보를 무해화 할 수 있다.
예를 들어, 서버는 MS-PPT 명세(Spec)에 근거하여, Current User 스트림에서 편집 정보들의 위치를 획득하고, PowerPoint Document 스트림에 위치한 편집(edit) 정보를 읽어 hyperlink 정보인 ExHyperlinkContainer를 찾아낼 수 있다.
MS-PPT에서 편집 정보는 복수 개 존재하므로, 서버는 연속적으로 편집 정보들을 찾아서 hyperlink 정보에 접근해야 한다.
서버는 Current User Stream에서 UserEditAtom의 위치를 획득한다(S4010).
예를 들어, 서버는 Current User Stream에서 CurrentUserAtom 레코드를 읽고, CurrentUserAtom 레코드의 offsetToCurrentEdit 필드를 통해, UserEditAtom의 위치를 획득할 수 있다.
서버는 UserEditAtom의 위치에 근거하여, PowerPoint Document Stream에서 UserEditAtom 레코드를 읽어드린다(S4020).
예를 들어, 서버는 CurrentUserAtom 레코드의 offsetToCurrentEdit 필드에 의해 지정된 오프셋을 찾고, PowerPoint Document Stream의 당해 오프셋에서 UserEditAtom 레코드를 읽을 수 있다.
UserEditAtom 자체는 연결 리스트 방식으로 구성될 수 있다. 서버는 offsetLastEdit 가 0이 나올 때까지 UserEditAtom를 반복적으로 읽어드리고, 후술되는 동작을 반복할 수 있다.
서버는 UserEditAtom 레코드에 근거하여, PersistDirectoryAtom 레코드를 읽어드린다(S4030).
예를 들어, 서버는 식별된 UserEditAtom 레코드의 offsetPersistDirectory 필드에 의해 지정된 오프셋을 찾고, 당해 오프셋에서 PersistDirectoryAtom 레코드를 읽을 수 있다.
관련하여, 본 명세서에 적용될 수 있는 명세(Spec)는 다음과 같다.
[MS-PPT]: PowerPoint (.ppt) Binary File Format | Microsoft Docs (https://learn.microsoft.com/en-us/openspecs/office_file_formats/ms-ppt/6be79dde-33c1-4c1b-8ccc-4b2301c08662)
1. Introduction
이 문서는 Microsoft PowerPoint 97, Microsoft PowerPoint 2000, Microsoft PowerPoint 2002 및 Microsoft Office PowerPoint 2003에서 사용하는 PPT(PowerPoint) 파일의 이진 파일 형식을 지정한다. PPT 파일은 슬라이드, 도형, 그림, 오디오, 비디오, 텍스트 및 기타 프레젠테이션 콘텐츠를 지정하는 레코드 및 구조 모음이다. 콘텐츠는 슬라이드 쇼를 통해 시청자에게 전달될 수 있다.
각 레코드에는 레코드 타입 및 추가 데이터를 지정하는 공통 헤더가 있다. 이러한 파일 형식은 특정한 구현에 대한 관심 콘텐츠가 포함된 레코드만 파싱하고 다른 레코드들을 스킵할 수 있는 효율적인 방법을 제공한다.
2. Structures
2.1 File Streams and Storages
OLE compound 파일로서, 이 파일 포맷 규격은 [MS-CFB]에 명시된 바와 같이 저장 및 스트림의 계층 구조로 구성된다. 다음 섹션에서는 파일에서 발견되는 최상위 스토리지 및 스트림들을 나열한다.
2.1.2 PowerPoint Document Stream
이름이 "PowerPoint Document"여야 하는 필수 스트림이다.
최상위 레코드가 다음 중 하나로 지정된다 :
DocumentContainer (section 2.4.1), MasterOrSlideContainer (section 2.5.5), HandoutContainer (section 2.5.8), SlideContainer (section 2.5.1), NotesContainer (section 2.5.6), ExOleObjStg (section 2.10.34), ExControlStg (section 2.10.37), VbaProjectStg (section 2.10.40), PersistDirectoryAtom (section 2.3.4), or UserEditAtom (section 2.3.3) record.
이러한 스트림의 콘텐츠은 최상위 레코드의 시퀀스로 지정될 수 있다. 레코드 시퀀스에 대한 부분 순서 제한은 PersistDirectoryAtom 및 UserEditAtom 레코드에 지정된다.
컨테이너 레코드로 Document Container, Main Master Container (섹션 2.5.3), Handout Container (섹션 2.5.8), Slide Container (섹션 2.5.1) 및 Notes Container (섹션 2.5.6) 레코드는 각각 컨테이너 레코드와 atom 레코드의 트리의 루트이다. 컨테이너 레코드 내에서, 자식 레코드로 명시적으로 나열되지 않은 다른 레코드가 존재할 수 있다. Unknown 레코드는 RecordHeader 구조(섹션 2.3.1)의 recType 필드에 RecordType enumeration(섹션 2.13.24)에 의해 지정되지 않은 값이 포함되어 있을 때, 식별된다. 이러한 Unknown 레코드가 발견될 경우 무시되어야 하며, MAY<1>은 보존될 수 있습니다. Unknown 레코드는 레코드 헤더 구조의 끝에서 앞쪽으로 recLen 바이트를 검색하여 무시될 수 있다.
이 스트림이 기록될 때마다, user edit인 새 최상위 레코드를 기존 스트림에 추가하거나, 전체 스트림 콘텐츠를 업데이트된 최상위 레코드 시퀀스로 대체할 수 있다. 전체 스트림을 교체하지 않으면, 이전 user edit을 구성했던 기존 최상위 레코드가 현재 user edit을 구성하는 후속 추가 최상위 레코드에 의해 폐기될 수 있다.
라이브 레코드(live record)는 이 스트림의 최상위 레코드로 지정되거나, 다음 절차에 의해 식별되는 이 스트림의 최상위 레코드의 하위 레코드로 지정될 수 있다.
파트 1: persist object directory의 구성
1. Current User Stream(섹션 2.1.1)에서 CurrentUserAtom 레코드(섹션 2.3.2)를 읽는다. 이어지는 단계의 모든 검색 작업은 PowerPoint Document Stream에서 이루어진다.
2. PowerPoint Document Stream 안에서, 1단계에서 식별된 CurrentUserAtom 레코드의 offsetToCurrentEdit 필드에 의해 지정된 오프셋을 찾는다.
3. 당해 오프셋에서 UserEditAtom 레코드를 읽는다. 이 레코드를 라이브 레코드로 만든다.
4. 3단계에서 식별된 UserEditAtom 레코드의 offsetPersistDirectory 필드에 의해 지정된 오프셋을 찾는다.
5. 당해 오프셋에서 PersistDirectoryAtom 레코드를 읽는다. 이 레코드를 라이브 레코드로 만든다.
6. 3단계에서 식별된 UserEditAtom 레코드의 offsetLastEdit 필드에 의해 지정된 오프셋을 찾는다.
7. offsetLastEdit가 0x000000이 될 때까지 3 - 6단계를 반복한다.
8. 이 파일에 대해 다음과 같은 완전한 persist object directory를 구성한다 :
a. 5단계에서 이전에 식별된 각 PersistDirectoryAtom 레코드에 대해, 마지막으로 식별된 PersistDirectoryAtom 레코드로 시작하는(즉 스트림의 시작에 가장 가까운) persist object directory에 persist object 식별자 및 persist object 스트림 오프셋 쌍을 추가한다.
b. 5단계에서 식별된 순서의 역순으로 각 PersistDirectoryAtom 레코드에 대한 persist object directory에 쌍들을 계속 추가한다. 즉, 스트림의 끝에 가장 가까운 PersistDirectoryAtom 레코드에 쌍이 마지막으로 추가된다.
c. persist object directory에 새 쌍을 추가할 때, persist object 식별자가 persist object directory에 이미 있으면 새 쌍의 persist object 스트림 오프셋은 해당 persist object 식별자에 대한 기존 persist object 스트림 오프셋을 대체한다.
2.3 File Structure Types
2.3.2 CurrentUserAtom
파일을 수정할 마지막 사용자에 대한 정보와 최신 사용자 편집(user edit) 위치를 지정하는 atom record이다.
도 5는 본 명세서가 적용될 수 있는 CurrentUserAtom 레코드의 예시이다.
도 5를 참조하면, CurrentUserAtom 레코드는 다음의 필드를 포함할 수 있다:
rh (8 bytes): 이 레코드의 헤더를 지정하는 RecordHeader 구조(섹션 2.3.1).
size (4 bytes): rh 필드 뒤에 시작하고 ansiUserName 필드 앞에 끝나는 레코드의 고정 길이 부분의 길이를 바이트 단위로 지정하는 부호 없는 정수. 0x00000014이어야 한다.
headerToken (4 bytes): 파일의 암호화 여부를 식별하는 데 사용되는 토큰을 지정하는 부호없는 정수.
offsetToCurrentEdit (4 bytes): PowerPoint Document Stream(섹션 2.1.2)의 시작부터 최근 사용자 편집에 대한 UserEditAtom 레코드(섹션 2.3.3)까지의 오프셋(바이트)을 지정하는 부호 없는 정수.
2.3.3 UserEditAtom
사용자 편집에 대한 정보를 지정하는 atom record이다.
도 6은 본 명세서가 적용될 수 있는 UserEditAtom 레코드의 예시이다.
도 6을 참조하면, UserEditAtom 레코드는 다음의 필드를 포함할 수 있다:
rh (8 bytes): 이 레코드의 헤더를 지정하는 RecordHeader 구조(섹션 2.3.1).
lastSlideIdRef (4 bytes): PowerPoint Document Stream(섹션 2.1.2)의 마지막 UserEditAtom 레코드인 경우 마지막으로 본 슬라이드를 지정하는 SlideIdRef(섹션 2.2.25)입니다. 다른 모든 경우 이 필드의 값은 정의되지 않으므로 무시해야 한다.
version (16 bits): 파일을 작성한 실행 파일의 빌드 버전을 지정하는 부호 없는 정수. 0x0000이어야 하며 무시해야 한다.
minorVersion (8 bits): 스토리지 포맷의 minor 버전을 지정하는 부호 없는 정수. 0x00이어야 한다.
majorVersion (8 bits): 스토리지 포맷의 mijor 버전을 지정하는 부호 없는 정수. 0x03이어야 한다.
offsetLastEdit (4 bytes): 이전 사용자 편집을 위해, PowerPoint Document Stream의 시작에서 UserEditAtom 레코드까지의 오프셋(바이트)을 지정하는 부호 없는 정수. 이 값은 이 UserEditAtom 레코드의 오프셋(바이트)보다 작아야 한다. 값 0x000000은 이전 사용자 편집이 없음을 지정한다.
offsetPersistDirectory (4 bytes): 당해 사용자 편집에 대한 PowerPoint Document Stream의 시작에서 PersistDirectoryAtom 레코드(섹션 2.3.4)까지의 오프셋(바이트)을 지정하는 부호 없는 정수. 이 값은 offsetLastEdit보다 크고 이 UserEditAtom 레코드의 오프셋(바이트)보다 작아야 한다.
2.3.4 PersistDirectoryAtom
persist object directory를 지정하는 atom 레코드이다.
도 7은 본 명세서가 적용될 수 있는 PersistDirectoryAtom 레코드의 예시이다.
도 7을 참조하면, PersistDirectoryAtom 레코드는 다음의 필드를 포함할 수 있다:
rh (8 bytes): 이 레코드의 헤더를 지정하는 RecordHeader 구조(섹션 2.3.1).
rgPersistDirEntry (variable): persist object identifiers와 persist object를 위한 스트림 오프셋을 지정하는 PersistDirectoryEntry 구조(섹션 2.3.5)의 배열.
2.3.5 PersistDirectoryEntry
sequential persist object identifiers의 압축 테이블 및 관련된 persist objects에 대한 스트림 오프셋을 지정하는 구조.
대응되는 사용자 편집이 이 구조를 포함하는 PersistDirectoryAtom 레코드(섹션 2.3.4)에 가장 근접한 UserEditAtom 레코드(섹션 2.3.3)에 의해 지정될 수 있다.
이 구조를 포함하는 PersistDirectoryAtom 레코드로 대응되는 persist object directory를 지정할 수 있다.
도 8은 본 명세서가 적용될 수 있는 PersistDirectoryEntry 레코드의 예시이다.
도 7을 참조하면, PersistDirectoryEntry 레코드는 다음의 필드를 포함할 수 있다:
persistId (20 bits): 시작되는 persist object identifier를 지정하는 부호 없는 정수. 0xFFFE보다 작거나 같아야 한다.
cPersist (12 bits): rgPersistOffset의 항목 수를 지정하는 부호 없는 정수. 0x001보다 크거나 같아야 한다.
rgPersistOffset (variable): persist objects에 대한 스트림 오프셋을 지정하는 PersistOffsetEntry 배열(섹션 2.3.6). 배열의 항목 수는 cPersist에 의해 지정된다. 각 항목의 값은 해당 사용자 편집에서 offsetLastEdit보다 크거나 같아야 하며 대응되는 persist object directory의 오프셋(바이트)보다 작아야 한다.
2.3.6 PersistOffsetEntry
PowerPoint Document Stream(섹션 2.1.2)의 시작에서 persist object로의 오프셋(바이트)을 지정하는 부호 없는 4바이트 정수.
다시 도 4를 참조하면, 서버는 PersistDirectoryAtom 레코드에 근거하여, PersistOffsetEntry 배열을 획득한다(S4040).
예를 들어, 서버는 PersistDirectoryAtom 레코드의 rgPersistDirEntry 필드를 통해, PersistDirectoryEntry 레코드를 읽고, 여기서 rgPersistOffset를 통해, PersistOffsetEntry 배열을 획득할 수 있다.
PersistDirectoryEntry 레코드에는 PersistOffsetEntry 개수가 지정되어 있고, PersistOffsetEntry 가 연속적으로 개수만큼 저장될 수 있다.
본 명세서에서 서버는 ExHyperlinkContainer의 링크정보를 무해화하기 위해 동작한다. 이와 관련된 명세는 다음과 같다.
2.10 External Object Types
2.10.16 ExHyperlinkContainer
하이퍼링크에 대한 정보를 지정하는 컨테이너 레코드이다.
도 9는 본 명세서가 적용될 수 있는 ExHyperlinkContainer 레코드의 예시이다.
도 9를 참조하면, ExHyperlinkContainer 레코드는 다음의 필드를 포함할 수 있다:
rh (8 bytes): 이 레코드의 헤더를 지정하는 RecordHeader 구조(섹션 2.3.1).
표 3은 본 명세서가 적용될 수 있는 rh의 sub-fields의 예시이다.
Field Meaning
rh.recVer MUST be 0xF.
rh.recInstance MUST be 0x000.
rh.recType MUST be an　RT_ExternalHyperlink.
exHyperlinkAtom (12 bytes): 당해 하이퍼링크를 식별하는 데 필요한 정보를 지정하는 ExHyperlinkAtom 레코드(섹션 2.10.17).
friendlyNameAtom (variable): 당해 하이퍼링크의 사용자가 읽을 수 있는 이름을 지정하는 FriendlyNameAtom 레코드(선택 사항).
targetAtom (variable): 당해 하이퍼링크의 목적 파일의 전체 경로를 지정하는 선택적 TargetAtom 레코드.
locationAtom (variable): 당해 하이퍼링크의 목적 파일 내의 위치를 지정하는 선택적 LocationAtom 레코드.
2.10.19 TargetAtom
하이퍼링크 목적 파일의 전체 경로를 지정하는 atom 레코드이다.
TargetAtom은 다음의 필드를 포함할 수 있다:
target (variable): 목적 파일의 전체 경로를 지정하는 UnicodeString.
따라서, target 필드는 무해화의 대상이 되는 링크정보를 포함할 수 있다.
ExHyperlinkContainer를 찾아가기 위한 명세는 다음과 같다.
2.4 Document Types
2.4.1 DocumentContainer
문서에 대한 정보를 지정하는 컨테이너 레코드이다.
도 10은 본 명세서가 적용될 수 있는 DocumentContainer 레코드를 예시한다.
도 10을 참조하면, DocumentContainer 레코드는 다음의 필드를 포함할 수 있다:
rh (8 bytes): 이 레코드의 헤더를 지정하는 RecordHeader 구조(섹션 2.3.1).
documentAtom (48 bytes): 프레젠테이션 슬라이드의 크기 정보를 지정하고 슬라이드를 메모하는 DocumentAtom 레코드(섹션 2.4.2)
exObjList (variable): 문서의 외부 개체 리스트를 지정하는 선택적 ExObjListContainer 레코드(섹션 2.10.1)
2.10 External Object Types
2.10.1 ExObjListContainer
문서의 외부 개체 리스트를 지정하는 컨테이너 레코드이다.
도 11은 본 명세서가 적용될 수 있는 ExObjListContainer 레코드를 예시한다.
도 11을 참조하면, ExObjListContainer 레코드는 다음의 필드를 포함할 수 있다:
rh (8 bytes): 이 레코드의 헤더를 지정하는 RecordHeader 구조(섹션 2.3.1).
exObjListAtom (12 bytes): 목록별 속성을 지정하는 ExObjListAtom 레코드.
rgChildRec (variable): 외부 개체를 지정하는 ExObjListSubContainer 레코드 배열.
2.10.2 ExObjListSubContainer
다음 표에 지정된 rh.recType 값에 의해 유형과 의미가 지정되는 변수 타입 레코드.
표 4는 본 명세서가 적용될 수 있는 rh.recType의 예시이다.
Figure 112022107757634-pat00001
따라서, rgChildRec의 하부에 ExHyperlinkContainer 레코드가 위치할 수 있다.
다시 도 4를 참조하면, 서버는 PersistOffsetEntry 배열이 나타내는 레코드가 DocumentContainer인지 여부를 판단한다(S4050).
예를 들어, MS-PPT 파일에서 링크정보는 DocumentContainer에 포함될 수 있으므로, 서버는 PersistOffsetEntry 배열이 나타내는 레코드가 DocumentContainer인지 여부를 먼저 판단한다. 이를 위해, 레코드의 헤더가 이용될 수 있다.
서버는 DocumentContainer가 ExHyperlinkContainer 인 것에 근거하여, 링크정보를 무해화한다(S4060). 예를 들어, 서버는 DocumentContainer의 exObjList 필드를 통해, ExObjListContainer 레코드가 있는지 판단할 수 있다. , ExObjListContainer 레코드가 있는 경우, 서버는 rgChildRec 필드를 통해, ExObjListSubContainer 레코드 배열을 찾을 수 있고, ExObjListSubContainer 의 rh.recType 값을 통해, DocumentContainer에 ExHyperlinkContainer 레코드가 포함되어 있는지 확인할 수 있다.
ExHyperlinkContainer 레코드가 포함되어 있는 경우, 서버는 ExHyperlinkContainer의 targetAtom 레코드에서 target 필드에 있는 링크정보를 무해화할 수 있다.
예를 들어, 서버는 target 필드에서 scheme만 남기거나, “/” 가 존재하는 경우, scheme과 “/” 만 남길 수 있다.
또한, 서버는 널(null) 문자(\0)로 링크정보를 제거하지 않고 공백(0x20)으로 무해화를 수행할 수 있다. 널 문자를 사용하지 않는 이유는 일부 문자열에 대한 MS-CFB 명세가 null-terminated string으로 되어 있는 경우가 있기 때문이다.
다만, 서버는 FriendlyNameAtom 레코드는 수정하지 않는다. 이는 링크 대신 “표시할 텍스트”에 해당하는 영역으로 수정되면 안 된다. 예를 들어, 이미지에 대해서는 링크 주소가 그대로 다 들어가 있으나, 링크 동작 자체에는 영향을 미치지 않기 때문에 유지한다.
전술한 본 명세서는, 프로그램이 기록된 매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 매체는, 컴퓨터 시스템에 의하여 읽혀 질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 매체의 예로는, HDD(Hard Disk Drive), SSD(Solid State Disk), SDD(Silicon Disk Drive), ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장 장치 등이 있으며, 또한 캐리어 웨이브(예를 들어, 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다. 따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니되고 예시적인 것으로 고려되어야 한다. 본 명세서의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 명세서의 등가적 범위 내에서의 모든 변경은 본 명세서의 범위에 포함된다.
또한, 이상에서 서비스 및 실시 예들을 중심으로 설명하였으나 이는 단지 예시일 뿐 본 명세서를 한정하는 것이 아니며, 본 명세서가 속하는 분야의 통상의 지식을 가진 자라면 본 서비스 및 실시 예의 본질적인 특성을 벗어나지 않는 범위에서 이상에 예시되지 않은 여러 가지의 변형과 응용이 가능함을 알 수 있을 것이다. 예를 들어, 실시 예들에 구체적으로 나타난 각 구성 요소는 변형하여 실시할 수 있는 것이다. 그리고 이러한 변형과 응용에 관계된 차이점들은 첨부한 청구 범위에서 규정하는 본 명세서의 범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (7)

  1. 서버가 MS-PPT 파일의 링크정보를 무해화(Disarming) 시키는 방법에 있어서,
    상기 MS-PPT 파일의 Current User Stream에서 UserEditAtom 레코드의 위치를 획득하는 단계;
    상기 UserEditAtom 레코드의 위치에 근거하여, PowerPoint Document Stream에서 상기 UserEditAtom 레코드를 읽는 단계;
    상기 UserEditAtom 레코드에 근거하여, PersistDirectoryAtom 레코드를 읽는 단계;
    상기 PersistDirectoryAtom 레코드에 근거하여, PersistOffsetEntry 배열을 획득하는 단계;
    상기 PersistOffsetEntry 배열이 나타내는 레코드가 DocumentContainer 인지 여부를 판단하는 단계; 및
    상기 DocumentContainer가 ExHyperlinkContainer를 포함한 것에 근거하여, 상기 링크정보를 무해화하는 단계;
    를 포함하는, 무해화 방법.
  2. 제1항에 있어서,
    상기 UserEditAtom 레코드의 위치를 획득하는 단계는
    상기 Current User Stream에서 CurrentUserAtom 레코드를 읽는 단계; 및
    상기 CurrentUserAtom 레코드의 offsetToCurrentEdit 필드에 근거하여, 상기 UserEditAtom 레코드의 위치를 획득하는 단계;
    를 포함하는, 무해화 방법.
  3. 제1항에 있어서,
    상기 PersistDirectoryAtom 레코드를 읽는 단계는
    상기 UserEditAtom 레코드의 offsetPersistDirectory 필드에 의해 지정된 오프셋에 근거하는, 무해화 방법.
  4. 제1항에 있어서,
    상기 PersistOffsetEntry 배열을 획득하는 단계는
    상기 PersistDirectoryAtom 레코드의 rgPersistDirEntry 필드를 통해, PersistDirectoryEntry 레코드를 읽는 단계; 및
    상기 PersistDirectoryEntry 레코드의 rgPersistOffset 필드에 근거하여, 상기 PersistOffsetEntry 배열을 획득하는 단계;
    를 포함하는, 무해화 방법.
  5. 제1항에 있어서,
    상기 링크정보를 무해화하는 단계는
    상기 DocumentContainer의 exObjList 필드를 통해, ExObjListContainer 레코드가 있는지 판단하는 단계;
    상기 ExObjListContainer 레코드의 rgChildRec 필드에 근거하여, ExObjListSubContainer 레코드를 찾는 단계; 및
    상기 ExObjListSubContainer 레코드의 rh.recType 값에 근거하여, 상기 ExHyperlinkContainer를 확인하는 단계;
    를 포함하는, 무해화 방법.
  6. 제1항에 있어서,
    상기 링크정보를 무해화하는 단계는
    상기 ExHyperlinkContainer의 targetAtom 레코드에 포함된 target 필드값에서 scheme 만 남기는 단계;
    를 더 포함하는, 무해화 방법.
  7. MS-PPT 파일의 링크정보를 무해화(Disarming) 시키는 서버에 있어서,
    통신부;
    메모리; 및
    상기 통신부 및 상기 메모리를 기능적으로 제어하는 프로세서;를 포함하고,
    상기 프로세서는
    상기 MS-PPT 파일의 Current User Stream에서 UserEditAtom 레코드의 위치를 획득하고, 상기 UserEditAtom 레코드의 위치에 근거하여, PowerPoint Document Stream에서 상기 UserEditAtom 레코드를 읽고, 상기 UserEditAtom 레코드에 근거하여, PersistDirectoryAtom 레코드를 읽으며, 상기 PersistDirectoryAtom 레코드에 근거하여, PersistOffsetEntry 배열을 획득하고, 상기 PersistOffsetEntry 배열이 나타내는 레코드가 DocumentContainer 인지 여부를 판단하며, 상기 DocumentContainer가 ExHyperlinkContainer를 포함한 것에 근거하여, 상기 링크정보를 무해화하는, 서버.
KR1020220131354A 2022-10-13 2022-10-13 MS-PPT에서 Link의 무해화를 위한 방법 및 장치 KR102488943B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020220131354A KR102488943B1 (ko) 2022-10-13 2022-10-13 MS-PPT에서 Link의 무해화를 위한 방법 및 장치

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020220131354A KR102488943B1 (ko) 2022-10-13 2022-10-13 MS-PPT에서 Link의 무해화를 위한 방법 및 장치

Publications (1)

Publication Number Publication Date
KR102488943B1 true KR102488943B1 (ko) 2023-01-18

Family

ID=85106735

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020220131354A KR102488943B1 (ko) 2022-10-13 2022-10-13 MS-PPT에서 Link의 무해화를 위한 방법 및 장치

Country Status (1)

Country Link
KR (1) KR102488943B1 (ko)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101745873B1 (ko) * 2015-12-18 2017-06-27 고려대학교 산학협력단 악성 문서 파일 식별 시스템 및 방법
KR20210027730A (ko) * 2019-09-03 2021-03-11 (주)지란지교시큐리티 멀티미디어 파일 보안 시스템 및 방법과 컴퓨터로 읽을 수 있는 기록매체

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101745873B1 (ko) * 2015-12-18 2017-06-27 고려대학교 산학협력단 악성 문서 파일 식별 시스템 및 방법
KR20210027730A (ko) * 2019-09-03 2021-03-11 (주)지란지교시큐리티 멀티미디어 파일 보안 시스템 및 방법과 컴퓨터로 읽을 수 있는 기록매체

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Jiwoong Choi et al., "Methods to Hide Malicious Codes in PowerPoint"(2013.12.)* *

Similar Documents

Publication Publication Date Title
US10181026B2 (en) Methods, media, and systems for detecting attack on a digital processing device
Carmony et al. Extract Me If You Can: Abusing PDF Parsers in Malware Detectors.
US7636945B2 (en) Detection of polymorphic script language viruses by data driven lexical analysis
Jueckstock et al. Visiblev8: In-browser monitoring of javascript in the wild
US9230111B1 (en) Systems and methods for protecting document files from macro threats
CN104217165B (zh) 文件的处理方法及装置
WO2020014663A1 (en) Systems and methods for detecting obfuscated malware in obfuscated just-in-time (jit) compiled code
CN102867144A (zh) 一种用于检测和清除计算机病毒的方法和装置
CN103559447A (zh) 一种基于病毒样本特征的检测方法、检测装置及检测系统
KR102547757B1 (ko) HWP에서 Link의 무해화를 위한 방법 및 장치
KR102468431B1 (ko) Ms-ooxml에서 ole object 무해화를 위한 방법 및 장치
KR102488943B1 (ko) MS-PPT에서 Link의 무해화를 위한 방법 및 장치
Falah et al. Towards enhanced PDF maldocs detection with feature engineering: design challenges
KR102538664B1 (ko) Excel 계열의 문서에서 수식 기능에 있는 Link의 무해화를 위한 방법 및 장치
KR102494838B1 (ko) MS-CFB의 DocumentSummaryInformation 스트림에서 Link의 무해화를 위한 방법 및 장치
KR102468434B1 (ko) Ms excel 문서 포맷에서 dde 무해화를 위한 방법 및 장치
KR102494836B1 (ko) MS-DOC에서 Link의 무해화를 위한 방법 및 장치
KR102468428B1 (ko) PDF 또는 HWP에서 JavaScript의 무해화를 위한 방법 및 장치
US10789067B2 (en) System and method for identifying open source usage
Zhu et al. Dytaint: The implementation of a novel lightweight 3-state dynamic taint analysis framework for x86 binary programs
WO2020065778A1 (ja) 情報処理装置、制御方法、及びプログラム
CN107239703B (zh) 一种动态链接库缺失的可执行程序的动态分析方法
Leemreize Analyzing fileless malware for the. NET Framework through CLR profiling
KR102494837B1 (ko) 난독화 된 자바스크립트를 탐지하고 복호화하기 위한 방법 및 이를 위한 장치
KR102549124B1 (ko) 난독화 된 vbscript를 탐지하고 복호화하기 위한 방법 및 이를 위한 장치

Legal Events

Date Code Title Description
E701 Decision to grant or registration of patent right
GRNT Written decision to grant