작성일 : 11-11-09 12:20
[보안뉴스] [기고] DB암호화 제품(TDE)의 보안 문제점 분석-3
 글쓴이 : happy
조회 : 1,109  

[기고] DB암호화 제품(TDE)의 보안 문제점 분석-3
2011-11-08
검증 1: 메모리에 테이블 전체를 평문으로 로딩하는 취약성 검증


투명한 암호화를 지향하는 TDE류의 제품 특성상 Disk에 저장된 테이블을 서비스하기 위해서는 모두 테이블 혹은 테이블스페이스 전체를 복호화하여 메모리에 로딩하게 되는데, 메모리를 덤프하면 복호화된 평문 테이블을 유출할 수 있는 위험이 있다.


즉, DB백업본에는 암호화가 되어 저장되지만 가동 중인 온라인 상태의 DB에서는 암호화가 메모리에 평문으로 저장됨으로써 암호화의 효과가 상실되는 것이다. 이 점을 실험을 통해 검증해 보자.


기준 : DB가 동작하는 내내 메모리에서 DB가 사용하는 영역중 데이터 처리를 위해 사용되는 영역(통상 Buffer Cache 영역)에서 암호문으로 유지 되어야 한다.


검증 방법 : MSSQL TDE와 Oracle 11g TDE를 각각 이용하여 하나의 테이블을 암호화한 다음 메모리를 덤프하여 평문상태의 주민번호가 있는지 확인한다.


[MSSQL 2008의 TDE]

먼저 TDE를 설정한다(Master DB의 마스터 키는 데이터베이스에 있는  인증서와 비대칭키의 개인키를 보호 하는데 사용되는 대칭키 임).


① 마스터 키 및 인증서 생성.

 

② 암호화 키 생성 및 알고리즘 지정.

 

③ “TEST_TDE” 테이블에 대한 TDE 암호화 사용 선언.

이로써 “TEST_TDE” 테이블이 MSSQL의 TDE를 이용하여 암호화 할 준비가 완료 되었다. 그럼 이제 확인 해 보자.

 

④ 사용자 DB “TEST_TDE”에 대하여 TDE 설정이 완료된 화면.

 

⑤ 이제 이 테이블에 데이터를 넣어 보자.

TDE로 암호화된 테이블에 입력한 주민번호 (800801-1167834)가 조회가 된다.

 

⑥ 이제 메모리 덤프를 해서 암호화 테이블이 메모리에 평문으로 저장되어 서비스되고 있는지 확인해 보자. 메모리 덤프는 ‘sqldumper.exe’를 이용하여 덤프하고, 덤프된 파일을 에디터로 열어 주민번호를 검색해 본다.

 

⑦ 메모리 덤프 결과파일 열기.

 

⑧ 입력한 주민번호(800801-1167834)를 탐색기를 이용하여 찾아보자.

 

⑨ 주민번호(800801-1167834)가 평문으로 메모리에 저장되어 있는 것을 확인할 수 있다.

 

[ 결과 ] MSSQL 2008의 TDE는 메모리에 평문으로 암호화 테이블을 저장하고 있으며 dump를 통해 유출이 될 수 있음이 확인됨.


[Oracle 11g의 TDE]

먼저 10건의 고객정보가 들어있는 테이블을 대상으로 TDE로 암호화 설정한 후 정확한 검증을 위해 SGA의 Buffer Cache를 Flush 하고, TDE로 암호화 한 테이블만이 Buffer Cache에 올라 온 상태에서 평문 상태의 주민번호가 나타나는지 확인한다.


① 암호화 테이블스페이스 구성.

TDE_TEST’라는 테이블을 알고리즘은 AES-128을 적용하고, 테이블스페이스 단위로 암호화 하도록 구성하였다.

 

② ‘TDE_TEST’ 테이블의 내용은 아래와 같이 이름과 주민번호 및 기타 정보들이 들어있다.

 

③ Oracle이 사용하고 있는 SGA를 덤프하여 식별자로 ‘KNAME_’으로 평문상태의 데이터를 찾아보자. SGA를 덤프하는 유틸리티인 ‘findsga(문서 끝 소스 참조)’를 이용하여 SGA가 OS상에 위치하는 곳(Key value) 과 크기(size)를 지정하고 찾고자 하는 문자열(KNAME_)을 입력한다.

< 중 간 생 략 >

평문 상태로 저장된 주민번호가 추출되는 것이 확인 된다. 여러분의 DB는 어떤지 궁금하면 Appendix의 ‘findsga’ 소스를 이용하여 확인해 보자.


[ 결과 ] Oracle 11g의 TDE도 메모리에 평문으로 암호화 테이블을 로딩하고 있으며, SGA를 메모리 덤프하여 유출 되는 것이 확인됨.

[글_조돈섭 이글로벌시스템 이사(alex@cubeone.co.kr)]