출처:http://elven.kr/archives/649
개인정보 유출사고에 대해 각종 언론과 미디어 매체를 통해 많이 접해보셨을 것입니다.
2010년부터 대량의 유출사고가 빈번히 발생하고 있으며,
안전하다고 여겨졌던 금융권 역시 내부 직원에 의해 개인정보가 유출되면서 큰 혼란이 야기되었습니다.
개인정보 유출사고가 끊이지 않는 가장 큰 이유는 해당 정보를 이용한 거래 시장이 활성화되고 있기 때문입니다.
스팸·보이스피싱·텔레마케팅 등에서 개인정보가 차지하는 비중이 높다보니
자연스럽게 이를 사고 파는 불법 유통 비즈니스가 활성화 되었으며,
이는 곧 판매자로 하여금 더 많은 자원을 확보하기 위한 목적으로 수많은 개인정보 유출사고를 발생시키고 있습니다.
또한 시스템의 개인정보를 탈취하는 과정에 있어, 이전처럼 높은 전문성이 요구되지 않게 된 것도 사고 급증의 이유가 될 수 있습니다.
다양한 형태의 공격 도구가 일반인들이 쉽게 접근할 수 있도록 배포되고 있어,
전문지식이 없는 일반인도 해당 도구를 이용하여 손쉽게 공격을 할 수 있게 되었습니다.
개인정보 유출사고의 경우 정보를 유출당한 개인도 많은 피해를 입지만,
피해업체의 가치와 신뢰도에도 상당히 영향을 미쳐 회사를 문닫게 할 수 있을 만큼 중대한 사안입니다.
개인정보보호가 이슈화됨에 따라 많은 가이드와 문서들이 배포되고 있습니다.
허나 정책 및 관리 등 이론적인 내용이 상당수를 차지하고 있고,
실제 사고 분석 내용을 다룬 내용은 극히 드문 것으로 알고 있습니다.
이에 현업에 근무하시는 분들에게 조금이나마 도움이 되었으면 하는 바램으로,
지난 수년 간 발생한 다양한 개인정보 유출 사고건에 대해 분석한 내용을 정리해보았습니다. 
1. 개인정보 유출사고 분석 케이스
사례의 경우 직접 분석을 수행하였던 건에 대해서만 그 내용을 기술하였으며,
사고재발방지를 위한 정보 공유 목적으로 업체명, IP 등 민감 정보는 본문에서 제외하였습니다.
(1) A사 개인정보 유출사고
Point 특정 소프트웨어 업데이트 서버 해킹을 통한 APT 공격
1) 공격자는 A사에서 사용하는 특정 소프트웨어의 업데이트 서버를 해킹
2) 업데이트 서버 내 정상 업데이트 파일을 악성코드로 변경하여 감염시킬 대상을 선별하는 수법으로 A사 사내망 PC 다수 감염
3) 악성코드에 감염된 사내망 PC를 원격으로 조종하여 G서버(가칭)로 원격터미널 접속 수행
– G서버를 통해서만 DB 서버망에 접근할 수 있음
4) 추가 공격 행위를 통해 DB 서버에서 회원정보를 덤프한 후, FTP를 통해 G서버에 회원 정보 덤프 파일 3개 생성
– 중간 과정의 경우 A사 네트워크 구성과 관련된 민감 내용으로 생략
5) 감염된 사내망 PC에서 FTP를 통해 G서버에 접속, 회원정보 덤프 파일 다운로드
6) 또한 해당 PC를 이용, FTP를 통해 외부 경유지 R서버로 회원정보 덤프파일을 유출
7) 공격자는 R서버를 통해 회원정보 유출
(2) B사 개인정보 유출사고
Point 악성코드에 감염된 사내망 PC를 통한 DB망 침투
1) 공격자는 악성코드에 감염된 B사의 사내망 PC 다수를 이용하여 공격을 수행
– 해당 PC 분석 결과 원격제어 및 계정정보 유출, 키로거 등의 기능을 포함한 악성코드가 다수 설치되어 있었음
설치된 악성코드 중 일부
2) 악성코드에 감염된 사내망 PC를 원격으로 조종하여, K서버(가칭)로 원격터미널 접속 수행
– K서버를 통해서만 DB 서버에 접근할 수 있음
3) K서버 접속 후 해당 서버 내 악성코드 설치, 스케쥴 등록 등의 추가 공격 수행
4) 이후 해당 서버를 통해 회원정보가 저장되어 있는 DB서버로 접속
5) DB 서버에서 회원정보를 덤프한 후 사내에 위치한 X서버로 전송 – 1차 경유지
6) 사전에 해킹한 W서버(외부에 위치)로 회원정보 파일 전송 – 2차 경유지
7) 공격자는 W서버에서 회원정보 덤프파일 다운로드
(3) C사 개인정보 유출사고
Point 홈페이지 관리 모듈 내 파일 업로드 취약점을 이용한 웹셸 업로드
1) 공격자는 C사의 홈페이지 관리자 계정을 탈취
2) 이후 관리 페이지 모듈 내 취약점을 탐색, 홈페이지 템플릿 관리 모듈에서 파일 업로드 취약점 확인
3) 해당 취약점을 이용하여 총 9개의 웹셸을 업로드
C사 개인정보 유출사고 개요도
4) 마지막으로 업로드한 editor.jsp 웹셸의 기능을 이용, DB 테이블 조회 후 회원정보 파일 유출
(4) D사 개인정보 유출사고
Point 원격 접속 허용된 DBMS를 통한 웹셸 업로드
1) 공격자는 D사에서 운영하는 웹서버 내 DBMS를 통해 웹셸을 생성
– 사용중인 DBMS의 경우 원격 접속이 가능하도록 설정되어 있었으며, SQL 구문 INTO 등을 통해 서버 내 파일 생성 가능
2) 웹셸 등을 이용하여 서버 내 웹 소스코드를 추출 및 분석하여 DB 접속 계정과 패스워드 정보 획득
3) 이후 DB에서 회원정보를 자동으로 추출하여 파일로 저장할 수 있는 스크립트 파일 생성
4) 해당 스크립트를 이용하여 회원정보를 덤프파일로 생성 후 유출함
(5) E사 개인정보 유출사고
Point 특정 서비스에 대한 접근 제어 정책 부재, 외부 침투 경로 제공
1) 공격자는 E사에서 운영중인 웹서버를 스캔, 동기화 서비스인 ‘Rsync’를 사용중인 것을 확인
– 서비스 중인 Rsync의 경우 접근제어 정책이 설정되어 있지 않아 외부에서 접속 가능
– 윈도우 내 가상 리눅스 환경을 구축, 해당 시스템에서 Rsync를 실행한 관계로 SSH를 통한 인증 등 사용자 인증 부재
Rsync 방화벽 설정내역
2) 해당 서비스를 통해 웹 소스코드 다운로드 및 웹셸 업로드 수행
– 관련 로그는 아래와 같으며 민감 정보의 경우 <->로 마스킹 처리
3) 공격자는 다운로드 받은 소스코드에서 DB 접속 정보를 획득함
4) 웹셸을 통해 DB 조회/덤프 프로그램 다수 업로드
공격자 업로드 프로그램 중 일부
5) 웹 소스코드에서 취득한 DB 접속 정보와 업로드한 DB 조회/덤프 프로그램을 이용, 회원 정보 유출
(6) F사 개인정보 유출사고
Point 홈페이지 관리 모듈 취약점을 이용한 웹셸 업로드
1) 공격자는 F사에서 고객 관리를 위해 사용하는 홈페이지의 관리자 ID 및 패스워드를 탈취
2) 관리페이지 내 특정 모듈의 취약점을 이용하여 웹셸 업로드, DB를 조회할 수 있는 별도 페이지를 생성함
공격자 생성 DB 조회 페이지
3) 공격자는 해당 웹페이지를 이용하여 회원정보를 열람 및 유출
(7) G사 개인정보 유출사고
Point 홈페이지 게시판 내 파일 업로드 취약점을 이용한 웹셸 업로드
1) 공격자는 G사 홈페이지 게시판 내 파일 업로드 취약점을 이용하여 웹셸을 업로드
2) 해당 웹셸을 이용하여 홈페이지 파일을 변조, 리버스 셸을 수행할 수 있는 파일을 업로드 후 호출
3) 이후 공격자는 systemtab 취약점을 이용하여 관리자 권한을 탈취, connect.inc 파일에 저장된 DB 접속 정보를 획득
4) 획득한 정보를 통해 DB에 접속, 회원정보를 덤프한 후 웹셸을 이용하여 유출
유출된 회원정보 중 일부 내용
(8) 추가내용
Point 사내망 PC에 저장된 서버 접속 관련 정보를 이용한 DB 침투
o 개인정보 유출사고에 있어 상당 부분의 비율을 차지
1) 공격자는 악성코드에 감염된 PC에서 서버 접속 정보가 저장된 파일을 탐색
– 해당 작업의 경우 수동으로 이루어지는 것이 아닌, 공격자가 생성한 별도 프로그램을 이용하여 자동 탐색
– 상당수의 관리자가 편의를 위해 관리중인 서버의 IP 및 접속 계정 정보 등을 파일로 보관
– 이러한 파일의 경우 대부분 패스워드가 설정되어 있지 않은 상태로 노출되어 있음
2) 공격자는 탐색 작업을 통해 획득한 파일 내 기재된 서버로 접속
– 파일 내 DB 서버 접속 정보가 없을 경우 DB 서버와 연계되어 있는 서버를 탐색 후 DB 접속 정보 획득
– 파일 내 DB 서버 접속 정보가 있을 경우 바로 접속하거나 혹은 관리자 PC 통해 접속하여 개인정보 유출
2. 사고 주요 원인
개인정보 유출사고가 발생하는 원인은 다양합니다.
개인정보 관리 소홀에서부터 해킹에 취약한 운영 시스템 환경 등 다양한 경로를 통해 사고가 발생하고 있습니다.
아래는 다수의 피해 업체를 분석한 결과 어떠한 점이 사고의 원인으로 작용하였는지를 정리한 내용입니다.
1) 관리 및 정책 이슈
– 정보보호 관련부서의 분산으로 전사적인 정보보호 통합 관리 능력 부재
– 개인정보의 기술적 보호조치 의무 미준수
– 외주 업체에 필요 이상의 정보 접근 권한 부여
– 특정 그룹에서만 DB 서버로 접속이 이루어져 하나 , 사내 모든 PC에서 DB서버로 접속이 허용
– 퇴사자 대상 DB 접속 권한 삭제 작업 지연
– 최고경영자의 보안 인식 부재로 인한 보안 인력 및 장비 등 부족
2) 사내 보안 이슈
– DB 접속 가능한 관리자 PC가 외부망에 연결, 외부 공격 위험에 상시 노출
– 관리자 PC의 입·출력 장치에 대한 엄격한 통제가 이뤄지지 않음
– 설치된 주요 소프트웨어에 대해 정기적인 업데이트가 수행되지 않아 취약점에 노출
– 기업 구성원이 기업용 프로그램을 사용하지 않고 공개용 프로그램을 사용
– PC 또는 외부저장매체 내 개인정보 리스트 및 주요 서버 접속 정보 저장
– 개인정보가 저장된 파일의 암호화 부재
3) 운영 시스템 이슈
– 취약 패스워드 사용 혹은 시스템 별 동일 패스워드 사용
– 상시 보안관제 미흡으로 유출시점에 즉시 대응 이루어지지 못함
– 주요 시스템 내 운영 서비스 대상 접근 통제 정책 부재
– 정기적으로 서비스에 대한 취약점 점검을 수행하여야 하나 실제 이행되고 있지 않음
– 개발 시 보안 고려하지 않아 상당수의 취약점이 존재함
이외에도 많은 원인이 존재할 수 있으나 나열한 문제점만이라도 예방/대응책을 잘 수립하시어 운영하신다면
개인정보 유출사고의 발생 가능성을 상당부분 감소시킬 수 있는 효과를 거둘 수 있을 것입니다.
3. 유출 여부 관련 이슈사항
개인정보 유출사고에 있어 사고 원인만큼이나 가장 중요한 포인트는 개인정보 유출 여부입니다.
일반적으로 공격자가 사내망의 시스템을 통해 DB 서버에 접속하여
필요한 정보를 추출한 후 파일로 내려받는 작업을 수행하게 되는데요.
이렇게 피해 시스템에 저장된 파일의 경우
1) 공격자가 성공적으로 가져갔는지,
2) 보안 솔루션 및 관리 정책에 의해 가져가지 못했는지
에 대한 내용이 추후 사고 처리에 있어 중요한 관건이 될 수 있습니다.
실제 DB에 비인가된 접근 및 열람이 발생하였더라도,
이 정보가 외부로 유출되었다면 이는 행정처벌 및 민사소송 등에서 크게 불리하게 작용됩니다.
유출 여부에 대한 몇가지 예를 들어보도록 하겠습니다.
1) 피해시스템의 로그 등을 통해 외부에서 파일을 가져간 것이 확인되었을 때
1-1) 피해시스템 내 유출파일이 존재하며 로그 분석 등을 통해 확인된 공격자 PC 및 서버에서
동일한 내용의 파일이 발견되었을 경우 유출
1-2) 피해시스템 내 유출파일이 존재하며 웹 로그에 기록된 유출 파일명과 사이즈 등이
시스템에 저장된 파일의 정보와 일치할 경우 유출
1-3) 피해시스템 내 유출파일이 삭제되었으나 파일명과 사이즈를 원상태로 복구할 수 있으며
웹 로그에 기록된 유출 파일명과 사이즈 등이 삭제된 파일의 정보와 일치할 경우 유출
1-4) 피해시스템 내 유출파일이 삭제되었으나 일부 데이터만 복구할 수 있으며
웹 로그에 기록된 유출파일명과 사이즈 등을 삭제된 파일의 정보와 일치시킬 수 없을 경우 유출 확인불가
2) 유출 파일로 추정되는 파일을 외부에서 다운로드 한 기록을 확인하였으나
해당 파일의 내용을 확인할 수 없을 경우 유출 확인불가
3) 특정 시점에 DB 서버 혹은 피해 서버에서 외부로 나가는 패킷량이 급증한 것을 확인하였으나
이와 관련된 로그 자료가 없는 경우 유출 확인불가
일반적으로 유출 파일에 대해 웹 로그와 DB 로그, 방화벽로그 그리고 트래픽 모니터링 결과 등을 활용하여 유출 여부를 확인하는데요,
이러한 방법외에도 공격자가 사용한 도구를 통해 유출 여부를 확인해볼 수 있습니다.
A라는 DB서버와 연결된 웹서버 B가 있다고 가정해봅니다.
웹서버 B를 통해서만 DB서버 A에 접근할 수 있다고 할 때,
공격자는 우선적으로 B서버를 공격하여 A서버의 DB에 접근할 수 있는 정보를 획득합니다.
이후 B서버에 DB를 조회하고 덤프할 수 있는 프로그램을 업로드하는 과정을 거치게 되는데요,
이 때 DB 덤프를 위해 흔히 사용되는 도구로 Adminer 과 EmpireBak이 있습니다.
각 도구의 특징은 다음과 같습니다.
Adminer : GUI 기반의 DB 열람/백업 도구로 DB 백업 명령 실행 시 해당 페이지를 호출한 시스템에 DB 덤프 파일이 저장됨
EmpireBak : GUI 기반의 DB 열람/백업 도구로 DB 백업 명령 실행 시 해당 도구가 설치된 시스템에 DB 덤프 파일이 저장됨
도구별로 특징이 비슷해 보이나, 유출 여부를 확인하는 관점에서 볼 경우 한가지 큰 차이점이 있습니다.
바로 DB에서의 덤프 명령 실행을 통한 덤프 파일의 저장위치입니다.
Adminer의 경우 해당 도구를 호출한 시스템 – 즉 B서버로 접속한 공격자의 시스템에 덤프 파일이 바로 저장되며
EmpireBak의 경우 해당 도구가 업로드된 시스템 – 도구가 실행중인 B서버에 덤프 파일이 저장됩니다.
추가로 각 도구를 사용하여 DB를 덤프하였을 때 아래와 같이 웹 로그에 기록됩니다.
만약 B서버 분석을 통해 웹로그에서 위와 같이 특정 도구를 이용한 덤프 로그가 확인될 경우,
사용된 도구가 EmpireBak이라면 B서버 내 덤프 파일이 저장 되어 추가적인 분석이 필요하나
Adminer를 사용하였다면 바로 공격자 PC에 정보가 저장되기에 유출된 것으로 판별할 수 있을 것입니다.
4. 추가로..
지금까지 제가 설명드린 내용의 경우 대부분 기술적 내용으로, 그 중에서도 분석쪽에 국한되어 있는데요
추가적으로 더 많은 정보를 원하실 경우
개인정보와 관련하여 온라인 및 오프라인에 그 내용을 다룬 서적 및 문서가 많기에 참고하시기 바라며,
실제 운영하시는 시스템과 정책 상 문제점이 없는지 점검해보시는 것을 권고드립니다.
감사합니다. 
'프로젝트 관련 조사 > APT' 카테고리의 다른 글
| Arcsight SIEM 활용 방안 (0) | 2015.11.24 |
|---|---|
| 해킹사고 증상과 취약점 (0) | 2015.10.21 |
| APT 공격 예방 (0) | 2015.10.08 |
| APT 탐지 프레임워크 (0) | 2015.10.01 |
| APT 공격 평가 (0) | 2015.10.01 |