self study

- 메모리 분석이 중요한 이유

  ● 악성 파일의 흔적을 찾기 위해서는 메모리 영역에서 분석해야 하기 때문

  ● 개인정보보호 프로그램이 악성코드 판별 기능이 없어서 악성코드조차 보호를 하는 경우가 발생하기 때문

  ● 안티포렌식 기술로 인한 무결성이 저해되기 전 메모리 복구를 하여 정보를 얻어내는것이 중요하기 때문

- 메모리 덤프

  ● 하드웨어를 이용한 메모리 덤프

  ● 소프트웨어를 이용한 메모리 덤프

  ● OS Crash 덤프

  ● 하이버네이션

- 가상 메모리 구조

  ● 가상 메모리란 가상의 기억공간으로 물리적으로 존재하지 않는 메모리다. 프로세스 생성 시 고정된 크기의 가상 메모리가 할당이           되는데 해당 프로세스는 이 가상 메모리를 이용하여 해당 작업을 수행한다. 여기서 가상 메모리는 32bit, 64bit 컴퓨터마다 고정 용량       이 다르다. 또한 가상 메모리 주소와 물리 메모리 주소도 다르며 가상 주소는 물리 메모리 주소와 맵핑되며 부족한 부분은 디스크 주       소를 사용한다.

그림 1) 가상 메모리와 기억 장치의 주소 맵핑(http://upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Virtual_memory.svg/200px-Virtual_memory.svg.png)

  ● 가상 메모리 구조를 간단히 보면 사용자 영역, 커널 영역이 있으며 디테일한 것은 서적이나 구글링을 통해 확인. 이 책엔 디테일한 구조가 나타나 있지만 구글링을 통해 찾지 못했음... 참고로 [그림 2]에서 위가 높은주소, 아래가 낮은주소를 뜻함.

그림 2) 가상메모리 구조

(http://blog.naver.com/psychoria?Redirect=Log&logNo=40113053480)

  ● 가상 메모리와 물리 메모리 맵핑은 TLB -> 가상주소와 물리주소 맵핑 -> 있다면 TLB에 업데이트 시키고 물리주소의 데이터 가져옴

    -> 없다면 가상메모리 주소 자체가 invalid거나 page-out상황

그림 3) 가상 메모리 물리 메모리 맵핑 과정

(http://sweeper.egloos.com/m/2988646)

그림 4) 가상주소로 물리주소 찾는 과정

 - EPROCESS, KPROCESS(PCB), PEB

  ● 위 단계와 아래 단계에서 모르는 용어가 몇 개 나와 이를 공부하고자 용어들을 간단하게 정리하려고 한다.

  ● EPROCESS

   ◇ 프로세스가 생성되면 해당 프로세스의 정보를 가진 EPROCESS라는 구조체가 커널 메모리에서 생성된다. 프로세스 관리를 이해하        기 위해 여러 객체를 포함하고 있으며 시스템 공간에 존재하기 때문에 WinDbg에서 확인할 수 있다.(그림 5의 맨 왼쪽 위치)

  ● KPROCESS(Process Control Block(PCB))

   ◇ EPROCESS의 하부 구조체로 해당 프로세스의 정보를 가지고 있다. 커널 동기화 객체, Dispatcher 객체, CR3 레지스터 값(Context        Switching시 Page Directory 물리 주소 저장소), 쓰레드 리스트 헤더, 프로세스 생성&종료 시간.... 등(그림 5의 오른쪽 위에 위치)

   ◇ 중요한 필드가 무엇인지 잘 몰라서 추후 공부하겠음....

  ● PEB(Process Environment Block)

   ◇ 유저 모드에서 수정되는 정보를 저장하는 구조체이고 프로세스 실행에 필요한 정보들을 담고 있다. 밑에 다시 설명

그림 5) EPROCESS, KPROCESS(PCB), PEB

(https://t1.daumcdn.net/cfile/tistory/1168DE0C4B7BB72130)

 - 프로세스

  ● 메모리 분석 시 프로세스를 찾는 것이 중요하다.  EPROCESS에는 많은 필드들이 있고 이들을 모두 분석한다면 아마....EPROCESS       의 필드 중 몇 가지 필드에 대해 설명하겠다.

㉠ PEB(Process Environment Block)

   ◇ 프로세스의 환경설정 값을 가지고 있고 프로세스가 로드한 모듈이나 이미지 로더, 힙 매니저 등 데이터를 담고 있다. 

       커널영역의 EPROCESS에 있는 PEB는 유저영역의 PEB의 주소를 가지고 있고, 유저영역의 PEB는 실제 프로세스 관련 데이          터들을 담고 있다.(그림 5 에서 동그라미를 제외한 부분이 커널 영역, 동그라미 친 부분이 유저영역)

 PEB가 커널영역과 유저영역에 둘 다 있는 이유는 데이터를 유연하게 접근하기 위해 유저영역에 둔 것이다. 

㉡ ActiveProcessLink

   ◇ 이 필드는 해당 시스템의 프로세스들 간의 연결을 담당하는 역할을 하고 이중연결리스트로 되어 앞뒤로 프로세스 walking을          할 수 있다. 예를들어 cmd.exe와 notepad.exe가 시스템에 올라와 있고 WinDbg로 cmd.exe의 ActiveProcessLink로 따라가게        된다면 notepad.exe의 EPROCESS의 PCB 필드를 가리키고 있다.

그림 6) ActiveProcessLink 역할 구조

(http://m.ahnlab.com/kr/site/securityinfo/secunews/secuNewsView.do?seq=17602)

 ※ PSActiveProcessHead는 ActiveProcessLink의 첫 시작점이다. 따라서 환형구조를 이루고 있다.

   ◇ DKOM(Direct Kernel Object Manipulation)

그림 7) DKOM을 통한 프로세스 은닉 구조

(http://codeengn.com/archive/Reverse%20Engineering/Hooking/DKOM%EC%9D%84%20%EC%9D%B4%EC%9A%A9%ED%95%9C%20%EC%9D%80%EB%8B%89%20%EA%B8%B0%EB%B2%95%20%5Balonglog%5D.pdf)

 ActiveProcessLink에서 은닉하고자 하는 프로세스의 링크를 없애는 것이다. 그림 7을 보면 더욱 이해가 편할 것이다. 프로세스를 은닉하는 이유는 프로세스를 은닉함으로써 분석을 어렵게 하고, 빠른 대응을 하지 못하게 함이 아닐까 생각한다.

  ● Process Enumeration

   ◇ Win API : CreateToolHelp32SnapShot()-> Process32First() -> Process32Next() -> NtGetSystemInformation() 호출

  -> NtGetSystemInformation()이 조작되면 Process 목록을 모두 출력하지 못하는 상황 발생

   ◇ 작업관리자, pslist(Volatility)

  -> 악성코드에 의해 OS는 잘못된 정보들을 얻어올 수 있음

   ◇ 리스트 워킹 : ActiveProcessLink를 따라다니며 모든 프로세스 목록을 얻음

   ◇ EPROCESS Scanning(패턴매칭) : EPROCESS가 공통적으로 가진 필드들을 조사하는 방법

   ◇ CSR PROCESS List 활용 : CSRSS.EXE 프로세스 생성시 내부적으로 프로세스 목록을 가지고 있다.

  -> 하지만 system, smss, csrss 프로세스는 나타나지 않는다.

   ◇ Thread List 활용 : Thread가 속한 Process를 얻을 수 있다.

- Live Response

 ● 활성화된 시스템에서 휘발성 정보를 수집하는 것을 말함.

 ● 시스템이 꺼지게 되면 휘발성 정보는 날아가기 때문에 OOV(Order Of Volatility)를 고려하여 정보를 수집한다.

- OOV(Order Of Volatility) [RFC 3227](http://www.ietf.org/rfc/rfc3227.txt)

 ● 레지스터, 캐시

 ● 네트워크 연결 정보

 ● 프로세스 목록, 커널 통계정보, 메모리

 ● 임시 파일, 열린 파일 목록

 ● 로그, 사용자 정보

 ※ 꼭 정해진 순서는 없다. 상황에 따라 정보를 수집해야 한다.

- Live Response 조사시 유의할 점

 ● 로카르트의 교환법칙

   ◇ 두 객체가 접촉하면 반드시 무언가가 교환된다.

   ◇ 이 법칙은 Live Response 시 정보를 수집하기 위해 프로그램을 실행한다던지 로그인을 한다던지 등의 행위들에 따라 시스템에 영        향을 줄 수 있다. 이러한 행위 때문에 중요한 정보들을 잃을 수 있으므로 시스템에 영향을 최소화 하는 방식으로 Live Response를        수행해야 한다.

   ◇ 메모리, 네트워크, 프로패치 파일, 시스템의 레지스트리(접근시간 변경), 시스템의 DLL(접근시간 변경), 로그파일 등 영향을 미칠         수 있다.

 ※ 관리자 권한을 얻기 위해 다시 시스템에 로그인 하는 것은 잘못된 방법이다. 이유는 로그오프하고 다시 로그인을 하게 되면 해당 세션의 휘발성 정보를 잃게 된기 때문이다. 오 놀라워라.... 따라서 이 분은 윈도우에서 runas와 같이 리눅스에 sudo?나 su?처럼 일시적으로 관리자 권한을 얻어 프로그램을 실행시킬 수 있는 명령어를 추천했다.

- Live Response 휘발성 정보 수집

 ● 시스템 시간

   ◇ 해당 시스템의 시간 정보를 수집하고 윈도우 명령어를 통해 레지스트리에 기록이 남지 않도록 할 수 있다.

 윈도우 명령어 : date /t & time /t

 출력 : 2013-10-19

    오후 8:56

 ● 네트워크 연결 정보

   ◇ 방화벽이 있다면 방화벽 로그를 수집해야 한다. 방화벽엔 휘발성인 세션로그와 커스터마이징 할 수 있는 로그가 따로 있다. 세션로

 그는 방화벽에 붙은 세션정보를 일시적으로 볼 수 있기 때문에 먼저 수집하는 것이 좋다. 그리고 커스터마이징 할 수 있는 로그 차  단로그를 많이 쓴다고 알고 있다.(예전 일할 때 차단로그를 주로 사용) 방화벽에 의해 허용 및 차단 로그를 모두 저장하게 된다면 방  화벽 부하가 크기 때문에 서비스의 문제가 생길 수 있어서 차단된 로그만 저장한다고 알고 있다. 룰에 의해 차단된 로그를 확인하여  의심할 만한 정보를 수집할 수 있을 것이다. 또한 해당 시스템의 네트워크 정보를 알아보기 위해 netstat 윈도우 명령을 이용하여 네  트워크 정보를 수집한다. 옵션이 너무 많아 스스로 보는것이 중요하다 생각한다.

 ● 프로세스 목록

   ◇ 프로세스 목록을 수집하여 해당 시스템에서 어떠한 행위가 일어났는지 확인해 봐야한다. tasklist 명령이나 SysInternalSuite에서 제공하는 Pslist를 많이 사용한다. PID, PPID를 통해 의심이 될만한 정보를 찾는 경우도 있고, 숨겨진 프로세스를 찾아내야 하는 경우도 있다.

 ● 핸들 정보

   ◇ 핸들에 경우 개인적으로 공부를 해보았다. 핸들이 무엇이고 이 핸들을 통해서 무엇을 알아야 하는지가 중요하다 생각했다.

 핸들은 응용프로그램이 시스템 자원(커널 오브젝트)에 접근할 수 있도록 하게 하는 것을 말한다. 응용프로그램은 시스템 자원에 직  접 접근이 불가능하기 때문이다. 윈도우에서 내부적으로 오브젝트를 직접 접근할 수 있도록 테이블을 만들어 이 테이블의 인덱스  값을 이용하도록 했다. 그리고 이를 확인하기 위해서는 커널 디버깅을 통해서 확인할 수 있는데 밑에 슬라이드에서 자세한 내용이  나와있다.

 (http://www.slideshare.net/JoosaengKim/windows-handle-2-24604055)

 그리고 핸들이 실제로 가리키고 있는 오브젝트는 레지스트리에 기록이 되어 있어서 SysInternalSuite에서 만든 Handle.exe를 통해  레지스트리 정보 수집을 할 수 있다.

[그림 1] 응용프로그램과 커널오브젝트 관계도 

(http://www.hauri.co.kr/customer/security/colum_view.html?intSeq=107&page=1)

   ◇ 커널 오브젝트는 다른 프로세스와 공유가 가능하기 때문에 이를 악용하면 다른 정상적인 프로세스를 제어하는 악성코드가 발생할        수 있다. 이것 뿐만아니라 다른 측면에서도 필요한 정보일 수도 있는데 이 부분은 점차 공부하면서 알아보도록 하겠다.

 ● DLL 목록

   ◇ http://blog.naver.com/PostView.nhn?blogId=process3&logNo=20017834792

   ◇ http://blog.naver.com/PostView.nhn?blogId=bolin1479&logNo=80154007392

   ◇ http://mayu.tistory.com/9

   ◇ http://www.reversecore.com/40

   ◇ DLL이 무엇이고 DLL Injection 관련한 내용이 있는 사이트를 링크시켜 놓았다. DLL Injection이나 7.7 DDoS와 같이 서비스로 등록하여 실제 구동되는 DLL파일 등 DLL 관련하여 침해사고가 발생되곤 한다. DLL과 관련된 침해사고라면 프로세스에서 사용되는 DLL 목록을 수집해야 한다. DLL 목록을 수집하기 위해 SysInternalSuite에서 만든 ListDlls.exe 도구가 있다.

 ● 로그온 사용자 정보

   ◇ 원격에서 로그온 한 사용자, 로컬 로그온 사용자 정보를 확인해야 한다.

 명령어 : net session(원격 로그온 사용자)

 SysInternalSuite : psloggedon(원격&로컬 사용자), Logonsession(원격&로컬 사용자, 해당 사용자가 실행한 프로세스 목록 출력)

 ● 파일 핸들

   ◇ 보류...공유폴더까지....

 ● 히스토리

   ◇ 명령 프롬프트에서 사용된 명령어들을 수집하는 것이다. 참고로 명령 프롬프트가 닫히면 그 전 정보들은 사라진다.

 ● 윈도우의 서비스 정보

   ◇ 악의적인 서비스가 등록 되었는지 확인해야 한다. 서비스 목록을 얻기 위해 SysInternalSuite의 Psservice.exe를 사용한다.

 ● 시작 프로그램 목록 정보

   ◇ 시스템이 부팅할 때 자동적으로 시작되는 프로그램이 있는데 악성코드 경우 이를 많이 활용한다. 레지스트리에 등록되어 있는데 이를 출력하기 위해 사용되는 툴은 SysInternalSuite의 autorunsc.exe가 있다.

 ● NetBios 정보

   ◇ NetBios는 근거리 데이터 통신을 위한 것으로 TCP/IP 기반으로 통신이 이루어진다. 상대방과 데이터를 교환할 경우 600초 동안 테이블 형태로 생성이 되고 이를 Cached NetBios Name Table이라고 한다. 또한 NetBios에서 세션모드, 데이터그램 모드가 있으며 세션모드는 연결성립, 메시지 처리를 하고 데이터그램 모드는 응용 프로그램이 통신 에러의 발견 및 회복을 수행, 브로드캐스트 지원을 한다.

침해사고 시 근거리 네트워크 정보를 수집할 수 있다.

 명령어 : nbtstat [옵션]

 ● 프로세스 메모리

   ◇ 프로세스의 가상 메모리를 뜻하며 해당 프로세스가 어떤일을 하는지 분석할 수 있도록 덤프를 떠야한다. MS사에서 제공하는              userdump.exe가 있고, 단 해당 프로세스가 정지하고 있어야 정확한 덤프가 가능하다는 점이 단점이다.

- 마지막으로

 ● 이 뿐만아니라 여러가지 방법으로 여러가지 정보를 더 얻을 수 있다고 생각한다. 아직 부족한 실력이라 책을 중점적으로 다루면서 공부를 했지만 다소 아쉬운 점이 많다. 현재 배치스크립트를 아주 간단하게나마 작성했는데 집에가서 문제를 한 번 풀어보면서 실습을 해봐야겠다...

디지털 포렌식의 세계라는 책을 가이드로 시작해보려 합니다. 간단하게 정리해보려 합니다.

- 디지털 포렌식 증거처리 절차

 ● 사전준비 -> 증거수집 -> 증거이송 -> 증거분석 -> 정밀검토 -> 문서화

- CoC(Chain of Custody)

 ● 사건의 증거가 수집한 상태에서 법정에서까지 변경이 되지 않았음을 보이기 위한 절차적인 방법

(A chain of custody is the accurate documentation of the movement and possession of a piece of evidence, from the time it is taken into custody until it is delivered to the court)

- E-Discovery

 ● 전자 포맷의 문서를 재판에서 사용될 증거로 수집하여 제출하는 것을 말함

- EDRM(Electronic Discovery Reference Model)

 ● E-Discovery의 참조모델이다. 점진적으로 각 단계를 수행하고 필요시 다시 전 단계로 돌아가 수행하기도 함.

[그림 1] EDRM (www.edrm.net)

  1. 정보관리(Information Management) : 증거개시가 요청되기 전 미리 필요한 정보를 준비하는 단계

  2. 식별(Identification) : 사건과 관계된 가능성이 있는 증거들을 식별하는 단계

  3. 보존(Preservation) : 증거들의 훼손 및 변조되지 않도록 보증하는 단계

  4. 수집(Collection) : E-Discovery 절차에 따라 무결성을 유지된 채 증거를 수집하는 단계

  5. 처리(Processing) : 수집된 증거들에 대해 필요시 결합하고, 더욱 적합한 검토와 분석을 할 수 있도록 데이터를 처리하는 단계 

  6. 검토(Review) : ESI의 타당성과 권한을 평가하는 단계(일반적으로 법률 관계자가 수행함)

  7. 분석(Analysis) : 증거들에 대해 컨텐츠, 문맥 등을 추출하여 평가하는 단계

  8. 제작(Production) : 증거들을 적합한 전달 과정을 이용하여 소송 당사자들에게 제작&제출하는 단계

  9. Presentation : 소송 당사자들에게 증거에 따른 사건 전황에 대해 보여주는 단계

- 디지털 포렌식 준비도(Digital Forensic Readiness)

 ● 신뢰할 수 있는 증거 수집 환경의 능력을 최대화하고 사고 대응 비용을 최소화하기 위한 제도

보안기사 관련 글들이 많다.

굳이 제것을 볼 필욘 없지만 오늘은 늦은 관계로...

- 보안기사 일정

1회

원서접수 : 5.27~5.31

필기시험 : 7.6

필기합격 예정발표 : 7.19(아놔)

응시자격 서류제출 및 실기시험 원서접수: 7.22~7.26

실기시험 : 8.24

합격자 발표 : 9.13

2회

원서접수 : 9.23~9.27

필기시험 : 10.26

필기합격 예정발표 : 11.1(발표 얼마 안 나고 바로 시험보는건 SIS때랑 똑같네 증말)

응시자격 서류제출 및 실기시험 원서접수: 11.4~11.8

실기시험 : 12.7

합격자 발표 : 12.27

- 합격 결정 기준

필기시험 : 각 과목당 40점 이상 전 과목 평균 60점

실기시험 : 100점 만점 기준 60점 이상

- 시험과목

필기시험 : 시스템보안, 네트워크 보안, 어플리케이션 보안, 정보보안 일반, 정보보안관리 및 법규

실기시험 : 정보보안 실무

- 필자가 공부하려고 하는 책

제작년 1급 필기를 따기 위해 공부했던 책

1. 한빛3총사

2. 리눅스 서버 보안관리 실무

3. 네트워크 보안 에센셜

4. 후니가 쓴 시스코 네트워킹

5. 전자상거래 보안

6. 웹 어플리케이션 보안

7. 정보보호 핵심지식

8. 정보보안과 암호화

9. 시험범위 법 관련 프린트

10. SIS 모음집이었는데... 그건 단순히 어떤걸 공부해야 하는지 잡아줄 뿐 ...

11. 보안인닷컴 운영자이신 전주현님께서 만드신 보안기사 책...

이정도로 생각하고 있는데...SIS때랑 달라져서 무엇을 빼고 보완 해야할 지 모르겠지만

보안기사 책 중심으로 필요한 부분들은 찾아보면서 해야겠다.

Shuffle job log 분석

- FIle Output Format Counters

Bytes Written - output의 데이터 크기

- Map-Reduce FrameWork

Reduce input groups - 리듀스에 도착한 그룹들을 말하며, 하나의 그룹은 하나의 키로 이루어진 그룹을 말함

Reduce input records - 리듀스에 도착한 그룹으로 볼 수 있으나, 키는 같아도 value값에 따라 나누어진 record이기 때문에 input group보다 수가 많거나 같을 수 있다.

ex)  a    4                                

b    5                        -> 각 스플릿 결과에 따라 나온 결과들이기 때문에 키가 같을 수 있다. Reduce input records는 4가 되고, 이를 키들로 

c    6                            묶게 되면 Reduce input groups가 된다.

a    2

Spilled Records - shuffle&sort  후 버퍼에 남아있거나 버퍼 임계값이 넘쳐 local disk에 쓰여진 temporary output으로 각 map task들이 스플릿을 처리한 output의 record들의 수를 말함.(어찌보면 Reduce input records와 수가 같다.)

Physical Memory (bytes) snapshot - ?

Virtual Memory (bytes) snapshot - ?

매우 단순할 것 같다 ? 답은...하지만 왜이리 찾기가 힘드노...

우연히 여기 방문하셔서 보신다면 댓글 부탁점....