find 명령어에 대한 보안 관점에서의 고찰

Posted by taeho Tae-Ho
2013.10.26 14:20 서버보안

서버에 로그온 하여 일을 하는 많은 엔지니어들이 사용하는 명령어 중에 find 만큼 옵션이 다양하고 유용한 명령어도 드물다. 더군다나 보안 관련 업무를 수행한다면 find 명령어의 유용함과 필요성은 더 커질 수 밖에 없다. 


자격증 시험 중에서도 이 명령어가 매우 중요하게 다루어지는 시험이 있다. 바로 "정보보안기사"다. 2012년 까지는 SIS 라고 불리던 시험이 국가공인자격증으로 업그레이드가 된 시험이 바로 정보보안기사 시험인데 1회 시험에 find 명령어가 14점 배점으로 한문제가 출제될 만큼 보안 담당자나 엔지니어라면 필수적으로 알아야 하는 명령어라고 할 수 있다.


그런 의미에서... 보안관점에서 find 명령어에 대해 정리해본다.


1. setuid/setgid 파일 찾기.


setuid와 setgid는 일반 사용자 계정에서 root 계정이나 시스템소프트웨어의 관리자 계정으로 잠시 권한을 변경할 때 사용되는 파일의 퍼미션이다. 


다음과 같이 퍼미션이 설정되어 있다.


-rwsr-sr-x 1 root root     315416 Feb 27  2009 crontab


s로 설정된 부분이 setuid 비트와 setgid 비트다.(퍼미션에 대한 이해가 부족하다면 더 공부하고 오세요. ^^)


위의 crontab 파일과 같이 setuid 비트와 setgid 비트가 설정된 파일을 찾을 땐 다음의 옵션을 주어 실행하면 된다.


-perm 은 퍼미션을 기준으로 찾겠다는 의미다.

-4000은 퍼미션이 최소한 ( - ) 4000 인 파일을 찾겠다는 의미다.


"4" 는 setuid를 의미하고 000 은 퍼미션을 의미한다. 즉 setuid가 설정된 모든 퍼미션의 파일을 찾겠다는 의미다. 일반적으로 퍼미션은 755 , 700, 500 등과 같이 표시하니 "4000"은 "최소한 000 보다 큰 퍼미션의 setuid 비트가 설정된 파일" 이라는 의미다.


파일퍼미션과 특수퍼미션)

먼저 파일의 퍼미션 각 자리는 각각 8진수로 읽는다. 즉 퍼미션 rwx는 2진수 111로서 7로 읽는다. 즉 각자리에 r이나 w, x가 표시되어 있는 자리는 1로 - 로 표시된 자리는 0으로 대체하는 것이다.이 규칙에 따르면 rwx는 111로 7이 되고 r-x는 101이므로 5, r-- 는 100 이므로 4가 된다. 따라서 어떤 파일의 소유자 퍼미션이 7, 그룹 퍼미션이 5, 어덜(other) 퍼미션이 0 이면 750 로 표시하고 rwxr-x--- 로 쓴다.

여기에 setuid와 setgid 그리고 sticky 비트까지 3개의 특수한 퍼미션을 또 8진수로 표시하여 일반퍼미션의 앞에써준다. 즉 8진수를 다시 2진수로 풀어 각 비트를 표현하게 되는데 setuid는 4, setgid는 2, sticky 비트는 1의 자리를  on, off 하는 것으로 표현한다.


즉 001 이면 1의 자리만 설정된 것으로 보고 sticky bit 가 설정된 것이고

    010 이면 2의 자리 즉 setgid 비트가 설정된 것으로...

    100 이면 4의 자리 즉 setuid 비트가 설정된 것으로 표시한다.

    111은 setgid, setuid, sticky bit가 모두 설정된 것으로 표시하고 7 이라 읽는다.


결론적으로 파일퍼미션이 755이고 setuid와 setgid가 모두 붙어 있으면... 6755 가 되고

rwsr-sr-x로 표시된다. setuid와 setgid는 실행 퍼미션과 함께 와야 하므로 x 자리에 s로 s로 표시하는 것으로 대체한다. 


만약 find 명령을 이용해 setuid, setgid 두개의 비트가 설정된 파일을 찾겠다면 다음과 같은 명령을 사용하면 된다.


-6000 은 setuid 4와 setgid 2 그리고 최소 퍼미션 000 으로 조합된 것으로 이해하면 된다.


그렇다면.. setuid와 setgid 중 어느 하나라도 설정된 파일을 모두 찾으려면 어찌해야 할까?

다음과 같이 -o 옵션으로  묶어주면 된다.



2. 파일의 최종 수정일자 찾기


보안의 관점에서 파일이 마지막으로 수정된 날짜는 무척 중요한 의미를 갖는다. 처음 서버에 운영체제를 설치할 때 생성되고 이후에 패치를 적용한 적이 없는데 운영체제의 특정 파일이 수정되었다면 그 파일은 운영체제의 명령어를 가장한 루트킷일 가능성이 높다.  또한 운영체제의 보안에 취약한 설정파일이 최근에 변경되었다면 또한 해킹의 시도일 가능성이 높다.


이때 사용할 수 있는 옵션은 모두 세개가 있다.

-mtime  :  파일의 내용이 수정된 날의 수다. (일자)

-ctime  :  파일의 속성이 수정된 날의 수다. (퍼미션, 모드 등)

-atime  :  마지막 접근(읽기, 디렉토리에 접근 포함)한 날의 수다.


위의 옵션중에서가장 중요한 것은 -mtime 이다. 즉 파일이 언제 수정되었느냐 하는 것을 기준으로 찾는 것이다. 홈페이지 파일들에 대한 수정일자, 운영체제 파일이 마지막으로 수정된 것이 언제냐를 판단하는 것이다.


만약 오늘부터 과거 10일 이내에 수정된 파일을 찾고자 한다면 다음과 같은 명령으로 찾을 수 있다.



위의 명령에서 -mtime 뒤의 숫자가 바로 "10일 이내" 라는 의미다. 

-10 은 지금 현재부터 10일 이내... 즉 오늘부터 어제, 그제, 그그제~~ 해서 10일이다.

10 은 오늘부터 딱~10일 전에 수정된 것.

+10 은 10일 이전부터 더 오래전에 수정된 것 이라는 의미다.


지금까지 보안 관점에서 find 명령으로 할 수 있는 것 중 가장 대표적인 두가지, setuid 파일과 변경된 파일을 찾는 명령을 알아 보았다. 이 두가지 방법으로 운영체제의 위변조 탐지, 홈페이지 소스의 위변조 탐지, 주요 설정파일의 변경여부 등을 검증할 수 있으므로 숙지하고 있는 것이 좋겠다.


그리고 정보보안 기사 시험을 준비한다면 반드시 외우자.


신고
이 댓글을 비밀 댓글로

홈페이지 변조 차단의 근본적인 방안은 바로 시큐어오에스(SecureOS)다.

Posted by taeho Tae-Ho
2013.09.04 09:55 서버보안

지난 6월 하순 발생한 대규모 공공기관의 홈페이지 변조 사건(2013년 6월)관련 정보에 대해 구글링하던 중 몇몇 홈페이지 변조 방지 솔루션의 소개페이지들을 보게 되었다. 하지만 자사의 솔루션이 "최고"라는 자부심을 갖는 것은 좋지만 서버운영체제와 웹서버 그리고 HTTP 프로토콜에 대해 전문 지식이 없는 고객에게 응용프로그램 수준에서의 홈페이지 보안만이 홈페이지 위변조를 방어할 수 있다는 잘못된 정보를 제공하는 경우를 많이 볼 수 있었다. 그저 안타까울 뿐이다.


네트워크 보안 솔루션과 응용프로그램수준의 웹보안이 필요 없다는 것은 아니다. 추운 겨울 옷을 입을 때도 얇은 옷을 여러겹 끼워 입는 것이 보온효과가 더 크다는 상식처럼 보안 시스템도 다계층 보안 시스템을 구축해야 효과가 크다. 


DDOS, DOS, 포트스캔, TCP/IP 취약성 공격 등 네트워크 기반 공격은 네트워크 보안솔루션이 방어하는 것이 맞다. 그리고 XSS와 같은 소스파일이 직접적인 위변조가 없는 공격은 RedCastle과 같은 SecureOS가 방어할 수 없다. 또한 SecureOS도 자체 방화벽 기능을 제공하지만 어디까지나 운영체제의 네트워크 커널 기반에서 동작하기 때문에 네트워크 방화벽 처럼 IP 레이어의 플래그에 따른 다양한 통제 기능을 제공하지는 않는다. 그저 내부네트워크를 통해 침투하거나 접근하는 행위에 대해서 통제하기에 적합한 수준의 방화벽 기능을 제공하기 때문이다.


하지만 웹서비스를 위해 서버에 저장되어 있는 소스파일이나 바이너리의 변조, 웹쉘의 실행을 차단하는 데는 SecureOS 만큼의 효과를 내는 것은 네트워크 기반의 솔루션으로는 구현이 어렵다고 보는 것이 맞다.


그 이유는 바로 웹페이지의 호출과정을 정확하게 이해하면 알 수 있다.

위의 그림에서 처럼 사용자 PC의 브라우저에서 호출되는 웹페이지 소스는 운영체제의 커널을 통해 읽혀지게 된다. 하지만 웹페이지 소스는 웹서버만 읽고 수정할 수 있는 것이 아니다. 서버에 다른 방법으로 접속한 사용자도 웹서버를 거치지 않고 접근하여 수정(변조)할 수 있고 웹서버의 취약점을 뚫고 침투한 해커도 2중, 3중의 우회방법을 통해 웹페이지의 소스를 변조할 수 있다.


하지만 아무리 2중, 3중의 우회경로를 통해 웹페이지 소스를 수정하더라도 최종적으로는 운영체제의 커널을 거치게 된다. 웹서버가 운영되는 서버에서 운영체제의 커널을 거치지 않고 파일을 수정할 수 있는 경우는 없다. 운영체제의 커널을 거치지 않고 파일 입출력을 하는 경우가 있기는 하나 특별한 파일시스템 구조로 파일시스템이 구성되어 있어야 하며 웹서버 용도의 서버에서는 특별한 파일시스템을 구성하는 경우가 없다.


RedCastle SecureOS를 서버에 설치하게 되면 웹페이지 소스에 접근하는 모든 접근을 커널 수준에서 모니터링하고 통제하기 때문에 정해진 소스파일 업데이트 작업만 허용하고 나머지 접근은 모두 차단할 수 있다.


예를 들면 "192.168.100.10 번 IP에서 FTP로 webadmin 계정으로 접속했을 때만 생성/수정/삭제가 가능하고 이외의 모든 생성/수정/삭제는 차단한다" 와 같은 정책에 의해 통제를 할 수 있게 된다. (다만 소스가 있는 경로는 모두 파악하여 리스트업 해야한다.)


이러한 정책을 적용하면 웹의 어떤 취약성을 뚫고 침입하여 소스파일을 변조시도하더라도 모두 차단이 되는 것이다. 소스의 변조를 막기 위해 별도의 라이브러리를 설치하고 소스를 일일히 수정하거나 새로운 취약성이 발견되어 보안 솔루션의 패턴을 업데이트해야하는 수고를 하지 않아도 되는 것이다. 또한 관리자가 Telnet 접속하거나 터미널 서비스로 접근하여 VI 명령어나 Notepad 명령어로 수정하는 행위도 차단이 된다.


DDOS 공격에 의한 서버 다운과 홈페이지 변조 중 어느 사고가 더 심각한 사고인가?


청와대 홈페이지가 공격을 당한 이후 뉴스기사가 떴다.



음...아주 완벽하게 홈페이지를 변조했다. (대단한 넘들.... -.-) 그런데 뉴스에서 참 희한한 기사를 읽을 수 있었다. 이런 기사가 바로 여론을 호도하는 좋은(?) 사례다. 어떻게 서버 다운이 없었다는 것을 더 "안전"한 것 처럼 이야기 할 수 있는지 이해가 안된다. 77대란 때 어느 국회의원의 "인터넷에 접속하는 모든 PC에 백신설치를 의무화하자"는 발언이 생각난다.


사실 서버에 저장된 파일이 외부의 공격에 의해 변조되었다는 것은 매우 심각한 상황이다. 만약 외부의 공격에 의해 파일이 변조되었다면 해당 서버는 운영체제부터 새로 설치하는 것이 바람직하다. 왜냐하면 파일의 수정이 이루어졌다는 것은 서버의 디스크 어디에 어떤 공격도구가 생성되어 숨겨져 있을지 모르는 상황과 같기 때문이다. 


하지만 DDOS 공격은 서버 내에 해커가 침투한 상황은 아니다. 단지 서비스를 하지 못하도록 외부에서 네트워크를 차단하는 형태의 공격이다. 홈페이지 파일의 변조는 "강도가 집 내부에 침입하여 물건을 훔쳐간 것"과 같고 DDOS 공격은 "집 밖에서 누가 돌멩이를 집으로 던져 유리창이 깨진 것" 에 비유할 수 있다. 과연 두 가지 해킹 중 어떤것이 더 심각한 문제일까? 당연히 홈페이지 변조가 더 치명적인 보안사고다. 하지만 공무원은 변조 보다는 장애가 더 큰 문제인 것처럼 이야기하고 있다. 매우 심각한 보안 인식의 문제가 드러난 발언이다. 


홈페이지 위변조 공격은 지금도 어디에선가 계속 시도되고 있고 발생하고 있다. 다만 쉬쉬하며 감추기 때문에 알려지지 않을 뿐....

신고
Tags
이 댓글을 비밀 댓글로

Telnet , SSH 접속 사용자에 대한 행위 추적 기능에 대한 고찰

Posted by taeho Tae-Ho
2013.06.17 15:51 서버보안

Windows, Linux, Unix 등 서버엔 많은 관리자나 엔지니어들이 접속하여 관리를 수행한다. 여기서 "접속"이라 함은  일반적인 웹서비스나 일반 업무 프로그램을 통한 접속이 아니라  telnet, ssh, terminal service 등 서버의 관리를 위해 운영체제에서 기본적으로 제공하는 접속 환경을 말한다.

SSH 혹은 telnet을 통해 Unix/Linux 서버에 접속하면 아래와 같은 화면이 표시된다.

이때부터 서버의 관리는 그 옛날 DOS시절보다 더 복잡한 명령어를 실행하거나 설정함으로써 이루어진다. 서버의 보안관리상의  문제는 여기서 부터 발생한다. 

1. 누가(사람) 언제 어디서 접속하였는가 ?

2. 어떤 계정으로 접속하였는가 ?

3. 어떤 명령을 실행하였는가?

4. 명령 실행 후 어떤 결과가 화면에 표시되었는가?

5. 어느 파일을 수정하였는가 ?

6. 명령 실행 혹은 파일 수정 후 어떤 에러가 발생하였는가?

위의 6가지에 대한 감사(Audit)를 수행하기 위해서는 운영체제의 기본 기능만으로 구현할 수는 없다. Unix와 Linux 그리고 Windows는 훌륭한(?) 운영체제지만 보안을 특별히 고려한 운영체제라고 보기는 어렵다. 서버의 보안을 강화하기 위해 특별한 기능을 기대하지는 않는 것이 좋다.

그렇다면 위의 6가지 감사 이슈를 충족하기 위해서는 어떤 방법을 취할 수 있을까? 역시 가장 확실한 방법은 서버보안SW를 적용하는 것이 가장 확실하다 하겠다.

SecureOS는 다음의 두가지 사용자 및 관리자의 행위추적 기능을 제공한다.

1. 커널수준에서 수행되는 "사용자 추적"

2. 응용수준의 입출력디바이스에 대한 모니터링을 수행하는 "TTY 모니터링"

몇몇 서버보안 제품들과 서버 감사로그 수집솔루션에서는 TTY모니터링 기능만을 제공하지만 레드캐슬은 커널수준의 사용자 추적과 TTY 모니터링을 모두 제공하고 있기 때문에 보다 상세하고 강력한 감사기능을 지원하고 있다.

1. 커널수준의 사용자 추적

말 그대로 커맨드라인에서 입력된 명령행이 exec() 시스템콜에 의해 커널에 전달된 시점에서 로그인한 사용자 세션을 식별하여 세션별로 수집/저장하는 행위추적 기능이다. exec() 시스템콜을 가로채어 감사로그를 저장하기 때문에 커맨드라인에서 직접 입력한 명령어 뿐만 아니라 실행된 명령어 혹은 스크립트가 내부적으로 실행하는 exec() 시스템콜도 가로채어 감사로그를 기록할 수 있다.

이는 화면에는 보이지 않고 백그라운드로 실행되는 명령어도 감사로그 기록이 가능하다는 의미다. 때문에 보다 정확하고 상세한 감사로그를 남길 수 있다. 예를 들어 외부 엔지니어가 작업상의 편의를 위해 미리 스크립트를 만들어 가져온 뒤 서버에 업로드하고 한꺼번에 실행하는 경우 커널수준의 사용자 추적에서는 그 스크립트 안에서 실행되는 명령어까지도 빠뜨리지 않고 감사기록을 남길 수 있다는 것을 의미한다.

또한 TTY 모니터링과는 다르게 보안SW가 구동중이면 우회하거나 무력화할 수 없으며 화면의 입출력을 가로채는 동작이 없기 대문에 여러 명령행의 "붙여넣기" 혹은 DBA들이 자주 사용하게 되는 길다란 ~ SQL문의 "붙여넣기" 시에도 영향을 주지 않는다.

커널기반 사용자 추적 조회 화면 (Windows / Linux / Unix 공통)

이 커널기반의 사용자 행위 추적 기능은 타 서버보안SW 혹은 감사로그 수집 솔루션에서 지원하지 못하고 있는 기술이다.

2. TTY기반의 사용자 추적

TTY란 Telnet, SSH, rlogin 접속 시 운영체제가 사용자 세션에게 부여하는 가상의 터미널디바이스 이름이다. TTY는 옛날 타자기(TeleTYpewriter)의 입출력을 컴퓨터 상에 접목시키기 위해 만들어진 것으로서 사용자가 접속할 때 1개씩 부여되고 키보드의 입력과 화면의 출력이 사용자가 접속할 때 부여된 터미널디바이스(즉 TTY)를 통해 이루어진다.

대부분의 서버보안 제품 및 TTY모니터링을 지원하는 로그통합관리 제품들은 동일한 방식 즉 TTY를 모니터링하는 기법을 사용하여 사용자 추적을 수행한다. 이 기술은 커널 수준이 아닌 응용프로그램 수준에서 동작하며 운영체제의 기본적인 설정 중 일부를 변경해주어야만 동작한다. 즉 어떤 파일을 변경하면 되는지를 알면 root 권한을 얻었을 때 해당 설정을 수정하며 감사기록이 남지 않도록 할 수 있다는 이야기다.

그럼에도 불구하고 TTY 모니터링 기법은 중요한 장점을 갖고 있는데 그것은 바로 명령 수행의 결과로 출력되는 내용까지도 감사기록으로 남길 수 있으며 온전한 입력과 출력을 모두 로깅하기 때문에 "동영상" 처럼 재생시켜 볼 수 있다는 장점이 있다.

Windows 서버에 대한 사용자 행위 추적(GUI수준)

 Unix / Linux 서버에 대한 TTY 수준의 행위추적 (GUI수준)

개인정보보호법이 발효된 이후 시스템에 대한 보안 점검 시 "관리자의 행위에 대한 감사로그"를 남기고 있느냐가 무척 중요한 이슈로 떠오르고 있다. 이에 대해 완벽하게 대응하기 위해서는 TTY수준(GUI수준)에서의 행위 감사와 TTY수준의 행위 감사가 무력화 되었을 경우를 대비한 커널수준의 사용자 추적 두가지가 모두 필요하다.


신고
이 댓글을 비밀 댓글로

320 사태에 대한 나름대로의 분석 [보안사고사례분석]

Posted by taeho Tae-Ho
2013.03.27 15:20 서버보안

I.       사건 개요

2013 320일 오후 12시 경 방송사와 금융기관의 내부 네트워크에 연결된 모든 PC를 공격하여 PC의 디스크 파괴를 통해 업무 전산망을 마비시키는 대형 보안사고가 발생하였음.

l  발생일시 : 2013 320일 오후 12 ~ 14

l  공격대상기업 : 3개 방송사(공중파 2, 케이블 1) 3개 금융기관(1금융권)

l  공격대상자원 : 기업 내부의 업무전산망에 연결된 모든 PC

l  공격방법 : PC에 악성코드를 유포하여 PC내의 디스크 파괴

l  공격결과 : 기업 내부의 업무 전산망 마비로 인한 업무 마비 및 중요 데이터 파괴

 

II.     사건 분석

320일 발생한 보안사고는 다음과 같은 절차에 의해 수행된 것으로 보임.

l  공격 대상 기업의 내부 전산망에 위치한 PC용 백신의 관리서버(A사 및 H사 개발 및 판매)기업 내의 모든 업무용 PC에 파일을 배포하고 실행할 수 있는 취약성이 있다는 점을 해커가 인지함.

l  APT 공격을 통해 6개 기업의 백신 관리서버(업데이트용)에 백신 업데이트 파일로 위장한 악성코드 파일 설치

l  백신의 관리서버가 업데이트 파일로 위장한 파일을 하위의 업무용 PC에 배포

l  업데이트 파일로 위장한 악성코드 파일을 실행 à 악성코드 감염

l  정해진 시간 (320일 오후 12 ~ 14)에 백신 프로그램을 강제 종료시키고 하드디스크 의 MBR 및 데이터 파괴 시작 (Windows Vista / 7 은 데이터영역도 파괴, XP는 일부 파괴)

l  하드디스크 파괴 후 PC 종료 메시지를 표시한 뒤 PC 강제 종료

l  PC 부팅 안됨.

 

상기 공격 과정을 도식으로 표시하면 다음과 같다.

KBS MBC YTN 해킹

상기 도식을 통해 다음과 같은 중요한 사실을 확인할 수 있다.

l  APT 공격을 통해 기업의 내부 전산망에 위치한 백신관리서버(업데이트 배포서버)에 관리자 계정의 권한을 해커가 획득하였음.

l  해커가 상용 솔루션인 백신관리서버 솔루션의 동작구조를 이해하고 있으며 공격의 설계에 필요한 이 솔루션의 파일배포 취약점을 파악하고 준비하였음.

l  백신업데이트 파일로 위장한 악성코드가 PC에 배포된 뒤 백신 프로그램을 강제 종료하였음.

l  백신이 PC의 디스크를 파괴하는 신규 악성프로그램을 탐지 및 차단하지 못하였음.

 

320일 발생한 이번 보안 사고는 2년 전 이즈음 발생한 농협의 전산망 마비사태와 큰 유사성을 갖고 있다. 그 유사성은 바로 해킹에 악용된 취약점이 상용 시스템 관리 솔루션의 취약점을 악용하여 최종 공격을 수행하는 명령코드를 최종 공격 대상 기기로 보내 실행했다는 점이다.

농협 전산 사고의 경우 업계에서 많이 사용되는 서버 장애 관리 및 모니터링 솔루션의 관리자 권한을 APT 공격을 통해 획득한 뒤 수백 대의 서버에서 동시에 디스크를 파괴하는 명령을 실행한 것으로 추측되며 이번 사고도 백신 업데이트 관리 솔루션이 설치된 서버의 관리자 권한을 획득하여 내부 전산망의 PC의 디스크를 파괴한 것으로 보이는 매우 중대한 공통점이 있다.

 

III.       대응 방안

앞에서 살펴보았듯 전산망이 마비되는 대형 보안사고는 대부분 APT 공격을 통해 자행되는 경향을 보인다.

특히 하나의 침투대상의 관리자권한을 APT 공격을 통해 확보하면 다수의 하위 공격 대상 장비로 공격을 실행하는 악성코드를 유포할 수 있는 중앙 집중 관리 시스템을 해킹하려는 시도가 증가할 것으로 예상된다.

이러한 공격을 차단하기 위해서는 중앙 집중 관리를 위해 도입된 솔루션별 관리서버에 대한 보안 강화가 필요하다.

이번 사고 사례에서도 알 수 있듯 중앙집중관리 솔루션들은 필수적으로 다수의 서버 혹은 PC에 에이전트(Agent)라 불리는 S/W를 설치하게 된다. 그리고 이 에이전트를 통해 서버나 혹은 PC의 다양한 정보를 수집하고 관리한다. 다음과 같이 매니저-에이전트의 구성을 갖는다.

 

농협사태와 320대란에 악용된 상용솔루션들의 매니저-에이전트 구성에서 보안취약성은 바로 매니저가 설치된 서버에 있다. 그리고 두 사건 모두 해커들은 매니저의 취약성을 파고 들었고 해당 취약성에 대한 공격이 성공하면서 모두 대형 보안 사고로 이어졌음에 주목해야 한다.

매니저가 설치된 서버에 대한 보안을 강화하기 위해서는 RedCastle SecureOS를 이용하여 다음과 같은 정책을 적용하여야 한다.

l  Windows의 주요 운영체제 폴더에서 새로운 파일의 생성/수정/삭제의 차단

è  악성프로그램/코드 및 운영체제 파일의 바이러스 감염 차단을 위해 필수적인 정책

l  Windows의 주요 설정 파일에 대한 수정 차단

è  파밍공격차단 및 악성프로그램의 자동 실행 차단 등

l  위협명령어(net.exe, taskkill.exe, cmd.exe, shutdown.exe, nc.exe, telnet.exe, ftp.exe)에 대한 실행 차단

è  악성코드가 주요 서비스 및 백신 강제종료 차단, 해킹시도를 위한 명령어 실행 차단

è  악성코드 유포 및 외부 연결 시도 차단

l  웹브라우저 실행 차단

è  악성 코드 감염을 유도하기 위한 웹 호출 차단

l  방화벽을 이용한 Outgoing 세션 연결시도 차단

è  서버로부터 외부로의 취약한 서비스포트로의 외부접속 차단

l  방화벽을 이용한 netbios 연결 및 Microsoft-DS, SQL Server 서비스 접속 시도 차단

è  공유 접근 및 DB 접속을 통한 관리서버 해킹 시도 차단

l  터미널서비스 접속 제한

è  관리자 이외의 PC에서 원격접속시도 차단

l  관리솔루션이 설치된 폴더 및 관리솔루션의 관리하에 있는 폴더에 대한 타 계정/IP 등에서의 접근 제한

è  원격접속 등을 통해 접근하였을 경우 접근을 제한하여 APT 공격으로 관리 솔루션이 해킹되는 것을 예방.

 

VI.       결론

2년전 발생한 농협과 3 20일 발생한 대형 보안사고를 통해 관리 솔루션의 도입이 대형 보안사고를 유발하는 커다란 취약성이 될 수 있음을 확인하였다. 하지만 관리 솔루션을 도입하지 않고 대형 다수의 시스템을 관리하는 것은 사실상 어렵다.

그렇다면 결론은 관리 솔루션 취약성의 공격으로 인한 대형 보안사고를 예방하기 위해서라도 관리 서버에 대한 보안을 강화하는 방법 밖에는 없다고 볼 수 있다. 특히 APT 공격을 통해 관리서버에 존재하는 관리자 계정의 권한이 탈취될 수 있다는 가정하에 공격을 저지할 수 있는 방법을 찾아야 하며 그에 대한 해답을 제공할 수 있는 보안강화 수단은 RedCastle과 같은 서버보안SW밖에는 없다고 볼 수 있다.


저작자 표시 비영리 변경 금지
신고
이 댓글을 비밀 댓글로
    • 하얀삼치
    • 2013.04.07 22:56 신고
    정보 감사히 봤습니다. 감사합니다.

[서버보안정책가이드] 2. Unix / Linux 수퍼유저(root) 및 어플리케이션 관리자 계정 권한 분리 정책

Posted by taeho Tae-Ho
2013.03.22 20:02 서버보안

Unix와 Linux 서버의 운영체제에서 보안을 위해 가장 주의해야하는 것은 바로 수퍼유저 계정, 즉 root 계정의 권한 탈취다. 만약 해커가 root 권한을 탈취한다면 해커는 서버에서 하고자 하는 모든 것을 할 수 있다.

해커가 root의 패스워드를 모르는데 어떻게 root 권한을 탈취할 수 있는가?

Unix와 Linux 운영체제는 보안에 신경쓰지 않고 개발한 연구용 운영체제다. 그러다 보니 개발 과정에서 일반 사용자 계정에서 root 권한을 필요로 할 경우 root 의 패스워드 없이 root 권한을 얻을 수 있는 다음과 같은 기능을 넣었다.

- 파일 퍼미션의 setuid bit에 의해 다른 계정의 권한을 임시로 얻는 기능
- 프로그램 내에서 setuid() 함수를 실행하여 현재 실행중인 프로세스의 소유자를 변경할 수 있는 기능
- 일단 root 권한을 얻으면 패스워드 없이 타 계정으로 권한을 변경할 수 있는 기능

해커들은 이 setuid 기능을 이용해 언제든 root 권한을 얻을 수 있는 백도어를 만들어 서버에 설치한다. setuid bit를 이용하여 백도어를 만드는 것은 프로그래밍 지식이 없는 초보자도 손쉽게 만들 수 있을 만큼 쉽지만 시스템 운영자의 입장에서는 엄청나게 위험하고 일단 설치되면 찾아내기가 쉽지 않다. rootkit 이라 불리는 것들이 백도어라 생각하면 된다.

redcastle secureos


SETUID 이외의 root 권한 탈취 방법

앞에서 설명한 setuid 이외의 root 권한의 탈취 방법은 대부분 운영체제 혹은 애플리케이션의 취약성으로 인해 발생하는 것들이다.

예를 들어 보면

1. root 권한으로 실행 중인 A라는 프로그램이 있다.

2. 이 프로그램은 주기적으로 /tmp 디렉토리에 B라는 이름의 스크립트를 생성하고 실행하고 삭제한다.
   (당연히 B라는 스크립트는 root 계정의 권한으로 실행된다.)

3. 서버를 해킹하려는 악의적인 목적을 가진 내부자가 root 이외의 계정으로 접속하여 /tmp에 B라는 동일한 이름의 공격스크립트 혹은 공격 프로그램을 지속적으로 만들고 지우는 스크립트를 만들고 실행한다. (B라는 스크립트 혹은 프로그램을 분석하여 A가 실행하는 어떤 한 명령이라도 대체 가능하다면 약간 변형하여 가능한 공격이다.)

4. 어느 순간엔가는 A가 실행하는 B라는 스크립트가 정상적인 B라는 스크립트가 아니고 공격자가 만들어둔 B라는 스크립트일 가능성이 있고 실제로 root 권한으로 공격스크립트가 실행될 수 있다.

5. 해커는 끈기있게 공격스크립트인 B가 실행되기를 기다리고 B가 root 권한으로 실행되는 순간, root 권한을 얻어 의도한 공격을 할 수 있다. (이 공격은 root 권한을 얻는 것일 수도 있으며 어떤 것인지는 공격자의 의도에 달려있다.)

이런 형태의 공격은 사실 서버에 어떠한 계정으로라도 접속할 권한만 있다면 손쉽게 가능한 공격기법이다. 하지만 그 위험성을 인지하고 있는 운영자는 그리 많지 않은 것이 현실이다. 그리고 버퍼오버플로와 같이 어려운 기술이 필요하지 않기 때문에 더 큰 위협이 된다. 운영체제에 대한 초보적인 지식만 있다면 얼마든지 실행가능한 공격이기 때문이다.

그만큼 Unix와 Linux는 내부자의 공격에 너무도 취약한 운영체제다.


** root 권한의 분리 정책

root 계정은 모든 것을 할 수 있는 수퍼유저다. 이 root 권한을 여러 계정 혹은 자연인 기반의 다른 사용자에게 나누어주는 것을 root 권한의 분리라고 한다. 이 root 권한의 분리는 여러가지 기법에 의해 가능하다.

1. 어느 IP/MAC주소에서 root로 로그인 했는가에 따라 서로 다른 파일 접근 권한을 부여
2. 개인 계정을 만들고 어느 개인계정에서 root로 로그인했는가에 따라 서로 다른 파일접근 권한 부여
3. 자연인기반(PKI인증서기반) 인증을 수행하여 어느 자연인이 root로 로그인 했는가에 따라 서로 다른 파일접근 권한 부여

이러한 기술을 이용하면 root 계정 뿐만 아니라 oracle, weblogic 등 중요한 어플리케이션 관리자 계정에 대해서도 권한을 세분화하여 파일 접근 권한을 부여할 수 있다.

가장 많이 사용되고 안전한  root 권한 분리 기법은 앞의 세가지 중 2번이다. 1번의 경우 IP 및 MAC의 변조에 의해 실제 로그인한 자연인을 식별할 수 없고 변조되더라도 책임을 물을 수가 없기 때문이다. 또한 3번의 경우 인증서 만료 및 인증서 휴대 문제가 있기 때문에 권장되지 않는다.

root 권한이 필요한 운영체제의 주요 설정 파일 및 시스템 변경을 일으킬 수 있는 주요 명령어에 대해 직접 root로 로그인한 계정에서는 접근(읽기, 실행, 수정, 삭제 등등)하지 못하도록 하고 특정 관리자의 개인계정으로 로그인하여 root 계정으로 전환(su - root 수행)한 경우에만 실행이 가능하도록 정책을 수립하고 적용한다.


** 어플리케이션 관리자 권한 분리 정책

root 계정 뿐만 아니라 오라클, 웹로직, 제우스, 티맥스 등 주요 어플리케이션의 관리자 계정도 권한을 분리할 필요가 있다. weblogic 계정으로 실행되는 WAS 서버(java로 실행되는)의 자체 취약점 및 JSP 등의 취약성으로 인해 WAS가 뚫리게 되면 해커는 weblogic 계정의 권한을 획득하게 된다.
만약 Webshell 등을 업로드 하고 실행한다면 해커는 서버에 telnet 접속을 한것 과 같이 weblogic 권한으로 실행 및 접근 가능한 모든 파일에 대한 접근 권한을 갖게 되는 것이다. 이때 주요 명령어와 같이 시스템 해킹에 사용될 수 있는 파일이나 weblogic 소유자로 되어 있는 jsp 파일 및 대부분의 class 파일에 접근하여 홈페이지 위변조 및 java 스크립트, iframe 삽입 등을 시도할 수 있으므로 이에 대한 통제가 필요하다.

그래서 weblogic, jeus, tmax, oracle 등의 계정으로 직접 로그인한 경우 root의 경우처럼 권한을 대폭 축소할 필요가 있는 것이다. 당연히 해커가 알지 못하는 개인계정으로 접속하여 weblogic, jeus, tmax, oracle 계정으로 이동(su - oracle 등)한 경우에만 접근이 가능하도록 어플리케이션 관리자 계정의 권한을 분리하도록 정책을 수립하여야 한다.

** root 및 어플리케이션 관리자 계정의 권한 통제는 서버 보안, 그중에서도 내부통제의 핵심

농협의 초~대형 보안 사고의 경우 내부 사용자에 의한 보안 사고일 가능성이 크다. 실수에 의해 운영체제의 주요 파일이 삭제되거나 GS칼텍스의 개인정보 유출과 같은 대형 데이터 유출사고의 경우가 바로 그런 경우다.
그리고 그때 보안사고가 자행되는 계정은 root 혹은 oracle, weblogic, tmax 등 서버의 주요 관리자 계정이 될 가능성이 크다. 따라서 내부통제를 강화하기 위해서는 root 및 관리자 계정의 권한을 여러 사용자에게 분리하여 부여하여야 한다. 

저작자 표시 비영리 변경 금지
신고
이 댓글을 비밀 댓글로

[서버보안정책가이드] 1. Unix / Linux 운영체제의 계정 통제 정책

Posted by taeho Tae-Ho
2013.03.22 20:02 서버보안

최근 발생한 현대캐피탈과 농협 그리고 이번 KBS, MBC, YTN, 신한은행, 농협의 치명적인 보안사고로 인해 금융산업분야 뿐만 아니라  비지니스를 위해 혹은 전산시스템이 비즈니스 그 자체인 많은 기업과 공공기관에 초비상이 걸렸다. 덕분에 나도 너무 많이 바빠진 사람중의 하나가 되었다.

 

하지만 Unix/Linux 운영체제는 자체적인 보안기능이 매우 부족하다. Unix/Linux가 애초부터 보안을 염두에 두고 개발한 운영체제가 아니기 때문에 운영체제 자체적으로 엄청나게 많은 관리적/기술적 취약성을 갖고 있다. 기술적 취약성 중 일부는 운영체제의 설정을 변경하여 보완할 수도 있지만 근본적으로 한계를 갖고 있으며 관리적 취약성은 운영체제 차원에서는 대응할 수 있는 방안이 없다.

 

그래서 공공기관 및 금융부문에서는 RedCastle과 같은 SecureOS S/W를 서버에 설치하여 Unix/Linux 운영체제의 기술적/관리적 취약성을 보완하고 있다. 하지만 보안강화를 위해 RedCastle에 보안정책을 넣어달라는 요청은 많은데 비해 어떤정책을 수립 할 것인가에 대해서는 아무런 생각이 없는 경우가 대부분이다.

 

그래서 Unix/Linux 서버의 운영자 및 보안부서의 IT 담당자분들께 도움이 될만한 서버보안 정책 가이드라인을 제시해본다.


 

I.              계정 통제 정책

 

흔히 계정통제라고 하면 여러 서버에 동시에 계정을 생성하고 패스워드를 일괄 변경하는 것을 생각하기 쉽다. 하지만 서버보안에서 계정통제라 함은 다음을 의미한다.

 

l  계정은 몇 개를 어떤기준에 의해 생성할 것인가

l  각 계정별 로그인 통제는(계정/서비스/IP/시간의 조합에 의한 로그인 통제) 어떻게 할 것인가

l  서버에 로그인한 사용자가 다른 계정으로의 Switch User를 하는 행위에 대해 어떻게 통제할 것인가

l  계정을 이용한 행위 감사(Audit)는 어떻게 할 것인가

 

흔히 계정관리와 혼동하는 패스워드의 일괄 변경은 기본적인 보안정책 즉 서버마다 패스워드를 다르게 설정하여야 한다는 아주 기본적인 보안정책에 위배된다. 이는 하나의 패스워드가 유출되면 전체 서버의 패스워드가 유출되는 끔찍한 결과를 차단하기 위해 권고되는 패스워드 관리 정책이다.

 

금번 농협의 보안사고에서도 단 몇 개의 root 패스워드가 내부자에 유출되었을 것이지만 피해는 275대의 서버에서 발생한 것처럼 어쩌다~ 한번 발생한 사고가 너무도 큰 피해를 유발하게 될 수 있다.

 

1)    계정은 몇 개를 어떤기준에 의해 생성할 것인가
 

서버에 TELNET, FTP, SSH 로그인을 수행하는 개인들은 서버에 혼자만 사용할 개인의 계정을 만들고 서버에 로그온할 때는 자신의 계정을 이용해 로그온 할 것을 권고한다.

 

이것을 굉장히 어려운 일이라거나 서버의 장애를 유발할 것이라는 막연한 두려움을 가진 관리자들이 너무도 많다. 서버의 운영체제는 다수의 사람들이 동시에 접속할 것을 전제로 만들어진 Multi-User, Multi-Tasking 운영체제다. 계정을 100~200 개 생성해도 계정이 많다는 이유로 서버가 느려지거나 장애가 유발되지는 않는다. 그 사람들이 동시에 접속하여 부하가 큰 명령을 동시에 실행하지만 않는다면 말이다


몇개의 계정을 100명이 사용하는 것이나 100개의 계정을 100명이 사용하는 것은 동일한 부하를 유발한다고 생각하면 맞다.

 

시스템관리자, DB관리자, 어플리케이션 관리자 등 수많은 사람들이 Root, oracle, weblogic, jeus, tuxedo 등 공용계정을 공유하여 사용하는 것은 장애 혹은 보안사고 발생 시 원인분석을 어렵거나 불가능하게 만드는 주요 원인이다. 때문에 개인계정을 생성하여 스스로의 관리 책임하에 서버에 로그온 하는 것이 올바른 계정 생성 정책이다.

 

자신만의 계정으로 로그인 한 뒤 root, oracle 등과 같은 수퍼유저 및 애플리케이션 관리자 계정으로 SU하여 사용하도록 하여야 한다.

 

 

2)    계정의 로그인 통제는 어떻게 할 것인가

 

Root, oracle, tmax, weblogic, tuxedo Super-User의 계정과 애플리케이션 관리자 계정등 공용계정으로의 직접 로그인은 차단하여야 한다.

 

Super-user 계정인 root로 여러 사람이 직접 telnet 로그인하는 것을 허용하게 되면 문제 발생 시 도대체 누가 로그인하여 작업했는지에 대한 추적이 불가능해진다. 때문에 서버에 로그온 하여 작업을 수행해야 하는 개인들은 모두 개인계정을 만들어 사용하고 root 이하 공용계정으로는 직접 로그온 하지 못하도록 통제하여야 한다.

 

추가적으로 각 개인별로 사용하는 IP에 대해서만 로그온 할 수 있도록 IP 통제까지 수행한다면 보안성은 대폭 개선될 수 있다.

 

 

3)    서버에 로그인한 사용자가 다른 계정으로의 Switch User를 하는 행위에 대해 어떻게 통제할 것인가

 

계정의 이동(Switch User)통제는 시스템운영에 상당히 민감한 영향을 끼칠 수 있다. 그리고 체계가 잡히지 않은 중구난방~식의 SU 통제는 시간이 지날수록 문제를 유발시킬 가능성이 커지기 때문에 SU를 통제할 때에는 시스템을 운영하는 전산부서 전체에 적용할 수 있도록 정책을 확실하게 수립하는 것이 좋다.

 

계정이동통제(SU) 정책 수립 시 기본 지침은 다음과 같다.

 

-       Super User root 계정으로의 SU를 허용할 개인계정을 그룹핑한다.

-       Oracle, Weblogic 등 애플리케이션 별로 SU를 허용할 계정을 그룹핑한다.

 

위의 두 지침에 의해 계정들이 그룹핑 되면 다음의 기본 SU통제 지침을 적용한다.

 

-       root oracle, weblogic 등 애플리케이션 관리자 계정간의 SU는 차단한다.

-       앞에서 그룹핑된 각 그룹에 속한 내부 사용자간의 SU는 허용한다.

-       서로 다른 그룹간의 SU는 차단한다.

  

 

4)    계정을 이용한 행위 감사(Audit)는 어떻게 할 것인가

 

계정에 대한 행위감사는 사용자가 서버에 telnet, ssh, rlogin 등의 방법으로 서버에 로그온 한 시점부터 로그아웃 시점까지의 모든 명령어 수행에 대해 기록을 남겨야 한다. 운영체제에서 제공되는 Shell History는 모든 명령어 입력에 대해 감사기록을 남겨주지만 세션에 대한 구분 및 하나의 계정으로 여러명이 접속하였을 때 각각의 원래 사용자를 식별하지 못하는 문제가 있기 때문에 큰 의미는 없다.

 

RedCastle과 같이 모든 세션을 식별하여 SU하기 전과 SU한 이후까지도 연결고리가 끊기지 않고 추적이 가능하도록 해야 하며 커널레벨과 TTY레벨의 추적 모두가 가능하도록 하면 최고의 사용자추적(행위감사)이 가능하다.


이상 네가지 기본적인 서버의 계정통제 정책을 적용하면 체계적인 계정관리가 가능하고 Unix/Linux 운영체제에서 제공되는 기본기능인 su 를 통해 타 계정의 권한을 탈취하는 악의적인 행동을 방지할 수 있다.

 

물론 이 계정통제 만으로 Unix/Linux 서버를 운영하는 전산시스템의 내부보안을 강화하는 것에는 한계가 있다. 추가적으로 파일접근통제 정책을 적용해야 제대로 된 서버보안 정책을 적용했다고 할 수 있다.

 

기회가 되면 파일접근통제에 대한 정책가이드도 올려보도록 하겠다.

 

현대캐피탈과 농협의 보안사고 여파로 인해 요즘살이 다 빠질 지경이다.. ^^


저작자 표시 비영리 변경 금지
신고
이 댓글을 비밀 댓글로

밤사이 밝혀진 방송사 해킹사고의 취약점은 안랩의 백신관리서버 였다.

Posted by taeho Tae-Ho
2013.03.21 08:17 서버보안

밤사이 부지런한 분석가들로 인해 KBS, MBC, YTN 그리고 일부 금융사 해킹으로 인한 전산시스템 다운의 원인이 밝혀진듯 하다. 원인은 각 사에서 사용하는 PMS 서버에 PC로 배포할 프로그램으로 위장하여 침투하고 정해진 시간에 일거에 동작하여 장애를 유발 시킨 지응적인 APT 공격으로 밝혀지는 듯 하다.

PMS (Patch Management System)  ??? 그리고  PMS의 취약점은 ??

Windows에는 제어판의 프로그램 추가/제거 기능이 있고 이 기능은 Windows 자체의 버그패치와 보안패치 그리고 windows 자체의 프로그램 설치와 제거를 할 수 있는 일종의 모듈관리 기능을 갖고 있다. 하지만 일반인 수준의 사용자들은 Windows 자체의 버그패치나 보안 패치를 잘 하지 않는다는 점에 착안하여 여러 보안 업체들이 Windows가 설치된 PC의 패치를 항상 최신으로 유지하기 위해 자동화된 시스템을 개발하여 PMS라는 이름으로 판매하고 있다.

또한 안랩 APC의 경우 윈도의 패치관리는 물론 V3 백신의 업데이트도 함께 수행하고 있다.

자동화하기 위해서는 중앙에 한대 혹은 그 이상의 패치를 배포하는 서버가 있어야 하고 패치 배포서버로 부터 파일을 받아 설치해주는 에이전트(Agent)라 불리는 프로그램이 PC에 설치되어야 한다. 

이번 해킹을 기획한 해커집단은 이 PMS가 갖고 있을 수 밖에 없는 근본적인 취약성을 공격한 것이다. 해커가 PMS 서버에 침투하여 악성프로그램을 모든 PC에 배포할 정상적인 패치파일로 위장할 수만 있다면 특정 기업이나 기관의 대부분의 PC에 악성프로그램을 배포하고 실행하여 장악할 수 있게 되는 것이다.

kbs 해킹

< APC로부터 피해를 입은 PC로 배포된 악성코드의 분석 화면 >

농협 사태와의 비교

이번 사고에서 가장 큰 역할을 한 것은 안랩의 APC 라는 PMS 및 백신업데이트 솔루션이다. 지난 번 농협의 사고 때 악용되었던 IBM의 시스템관리 솔루션이 떠오르는 것은 과연 우연일까 ? 어찌 보면 공격의 대상이 서버에서 PC로만 바뀌었을 뿐 특정 기업의 중앙 집중관리 솔루션이 공격의 대상인 것은 동일한 그림이다.

농협의 경우 IBM에서 공급한 유닉스 서버의 시스템관리솔루션에 의해 수백대의 서버에서 동일한 명령이 실행되어 디스크를 포맷(유사한)하는 공격인 것으로 알려졌다. 한 때 IBM과 방통위와의 격한 싸움(?)이 날뻔 했다는 소문도 있었다. 

이번 사고에서 악용된 솔루션은 PMS와 백신업데이트 서버다. 수백대의 PC에 파일을 배포하고 동시에 실행하는 솔루션이다. 

양쪽 모두 중앙집중관리를 위한 솔루션이라는 점이 공통점이다.


결국은 또 서버 공격이었다.

농협사태를 비롯해 최근 발생하는 해킹사고의 1차 침투 대상은 바로 서버다. 하지만 아직도 많은 전산전문가라는 사람들은 백신타령만 한다. 백신은 PC 보안의 첨병이다. 하지만 사고를 예방하기 위해 PC의 보안만 강조하는 것은 너무도 무책임한 처사다. 

하지만 서버에 대한 보안은 참 어렵다. 전산전문가들과 보안 전문가들 조차도 손대기 어려운 것이 바로 서버의 보안이다. 왜냐하면 우리나라의 IT 업무 풍토상 서버에 보안을 강화하면 개발자나 서버 관리자가 소위 "죽는 소리"를 한다. 일이 힘들어진다고 생각하기 때문이다.

물론 서버에 보안을 적용하는 첫단계는 매우 힘든 것이 사실이다. 서버의 계정에 대한 관리 정책 수립과 권한에 대한 분리, 개발자들의 업무 패턴, 솔루션 관리에 대한 체계 수립, 위험 명렁어에 대한 실행권한 체계 수립 등 보안정책으로 수립되어지고 지켜져야할 것이 꽤나 많기 때문이다.

하지만 이러한 보안관리 체계가 수립되지 않으면 대형 보안사고는 계속 터질 수 밖에 없다.


잔소리) Windows 서버의 보안체계의 문제점

보안쪽 일을 하는 기술자의 입장에서 Windows는 솔직히 썩 권장하고 싶지 않은 운영체계다. Windows의 기초 설계 개념에 보안이 그리 중요시되어 있지 않았다는 것이 눈으로 보일정도이고 제공하는 보안 기능도 그때 그때 필요에 따라 추가한 냄새(?)가 진하게 나기 때문이다. 

보안의 기본인 계정에 대한 권한 분리가 Windows의 기본설계에 제대로 반영되어 있지 않다보니 Windows 운영체계에서 실행되는 많은 솔루션들도 자연스레 보안을 무시하고 개발하게 된다. 예를 들면 백신이나 보안솔루션들이 cmd.exe를 너무도 빈번하게 실행하는 점과 많은 SW들이 system 이라고하는 Windows의 최고 권한의 계정권한으로 실행된다. 이는 해당 솔루션이 해킹을 당하면 Windows의 최고 관리자 권한이 바로 탈취된다는 점에서 무척 위험한 설계라고 할 수 있다.


신고
이 댓글을 비밀 댓글로

[보안사고사례] KBS, MBC, YTN 의 전산망 마비 사태

Posted by taeho Tae-Ho
2013.03.20 18:22 서버보안

2013년 3월 20일... 또 보안사고 역사에 길이(?) 남을 만한 보안사고가 발생했다. 조금은 특이한 형태의 공격인 듯 한데 KBS, MBC, YTN 3개 방송사의 내부 전산망이 일시에 다운이 된 사고다.

그런데 이 표현 "방송사 내부 전산망이 일시에 다운"이라는 표현은 참으로 무지한 표현이다. "전산망" 이라함은 "서버와 서버 혹은 서버와 PC를 연결하는 Network"를 일컫는 표현이다. DDOS와 같은 공격에 장애가 발생할 경우 "전산망" 공격이라는 표현이 옳은 표현이겠지만 이번의 경우는 "전산망 다운"이라고 부르면 안된다고 생각된다.

"KBS, MBC, YTN" 공격의 특징

여기 저기서 들려오는 소문과 객관적 사실들을 정리해보면 

1. KBS 아나운서의 트위터 : 오후 2시경 갑자기 PC가 리부팅 한다고 메시지를 띄운 뒤 종료된 뒤 부팅이 안됨.

2. 농협에 갔던 1인(잘아는 지인) : 갑자기 긴급 상황이라며 PC나 노트북에 연결된 랜선을 모두 뽑아달라고 농협 직원이 요청.

3. YTN,MBC, KBS 관계자 (뉴스기사) : 수백대의 PC가 종료된 뒤 다시 켜지지 않음.

4. 모 VAN사 (MS에 문의결과) : PC의 Windows에 부팅파일들이 삭제되는 공격으로 보인다고 답변.

내가 확인할 수 있던 몇몇 상황을 보면 이번 사고는 DDOS와 같은 서버와 네트워크를 마비시키는 공격이 아닌 보다 심각한 상황을 만들기 위해 오래전부터 방송3사 (KBS, YTN, MBC)의 내부 PC들을 공격하기 위해 준비를 한 것으로 보인다. 사실 이 준비단계가 쉬운것은 아니다.

그리고 농협의 경우 직접 공격을 당하지 않았음에도 사고 발생 한시간 남짓만에 PC에 연결된 랜선을 뽑아달라고 요청한 것으로 보아 원인을 이미 알고 있었던 것으로 보인다.



백신이 왜 막지를 못했는가?

PC의 악성코드 감염과 관련된 이슈가 나올 때마다 나올 법한 백신 이슈는 이번에도 잠잠할까?? 의문이다. 왜냐하면 이번 사고를 포함해서 DDOS 공격 등 대형 보안사고의 경우 어김없이 PC에 감염되는 악성코드에 대한 이야기가 표면으로 떠오르기 때문이다. 그럼에도 불구하고 백신에 대한 책임론은 그리 크게 부각되지 않는다. 이런 사고가 발생할 때마다 오히려 백신을 설치하라는 이야기가 더 많이 나오곤 한다. KBS, MBC, YTN 모두 V3 백신이 설치되어 있음에도 PC의 악성코드 감염을 막지 못했는데도 말이다. 역설적이지 않은가???

백신은 새로나온 악성코드는 잡아내지 못하는 너무나 큰 단점이 있다. 이는 백신 자체가 블랙리스트 방식을 취하고 있기 때문이다. 블랙리스트 방식은 "위험한 파일의 패턴" 목록을 갖고 있고 PC내에서 프로그램이 실행될 때마다 "위험한 파일"인지를 이 패턴 목록과 비교하여 차단하는 형태를 말한다.반대의 경우는 화이트리스트 방식이라고 한다. 


예방 대책은 없는가?

 지금까지의 블랙리스트 방식의 백신은 해결책이 되지 못한다. 전혀 새로운 개념의 백신이 필요할 듯 싶다. 인공지능형 백신?? 그런건 아직 실현불가능하다. 어느정도 해결 가능한 아이디어가 있긴 하지만 블로그에 풀기에는 그 무게가 너무 무겁다. 언젠간 그런 제품이 나오지 않을까를 기대해본다.


가장 중요한 "해킹 경로"는 ?

사고 발생 7시간여가 되어가는 지금.. 정확한 해킹경로는 밝혀지지 않고 있다. 하지만 몇몇 해킹가능성이 의심되는 경로가 발표되고 있다. 경로는 불분명하지만 공격 대상은 명확하다. 바로 업무용 "PC"다. 즉 Windows xp/7 등의 OS가 설치되어 있는 PC..그중에서도 Disk 파괴다. 

언론에 언급되는 MBR은 Master Boot Record 의 약자로서 C: 드라이브의 물리적인 가장 앞부분.. Windows가 부팅되는데 가장 필수적인 매우 작은 영역이다. 이곳이 지워지거나 파괴되면 PC는 부팅되지 않으면 일반적인 Windows의 설치 방법으로는 복구가 되지 않을 수도 있다.

그렇다면 해커는 어떻게 PC까지 악성코드를 감염시켰을까?

몇몇 흘러나오는 이야기를 정리하면...

1. 안랩에서 제공하는 PMS (Patch Management System)을 통해 업무용 PC에 배포되었을 거라는 이야기가 있다. 하지만 현실적으로 이런 방식으로는 여러 방송사와 기관을 동시에 해킹하기는 쉽지 않다.

2. URL 해킹이라는 이야기...  솔직히 난 URL해킹이라는 해킹기법은 처음 들어본다. 언론에서 URL해킹 이라는 이야기를 하지만 솔직히... 뭘 의미하는지 이해할 수 없다. URL을 변조하는 공격은 DNS의 주소를 바꿔치기한다는 이야기인지 모르겠다. 바꿔쳤다고 해도 외부에서 웹서버도 아닌 내부 네트워크에 있는 PC까지 URL 바꿔치기로 접근한다는 것은 불가능하다. 뭘 모르는 사람의 말도 안되는 이야기를 언론에서 떠는 것 같다.

3. 고전적 기법의 악성코드 유포.  가장 가능성이 높을 것 같다. 이메일을 통해 첨부파일로 감염을 시키거나 다른 웹사이트.. 예를 들면 방송국 근무자들이 많이 드나드는 웹사이트를 먼저 해킹하여 Java Script 해킹기법 등을 통해 악성코드를 유포하도록 웹페이지를 변조 한 뒤 공격대상인 3개 방송국에 만족할 만한 숫자의 PC를 확보한 순간 일제히 PC를 공격하도록 했을 가능성이 있다.

아직은 정확한 조사결과가 나오지 않아서 잘 모르겠지만 어떤 결과가 나오든 명확한 것은 DDOS에만 관심을 쏟다가 제대로 해킹다운 해킹을 당했다는 것이다. 

DDOS는 사실 단지 서비스를 못할 뿐이다. 중요한 정보가 유출된 것도 아니고 기관 내부의 PC나 서버의 데이터가 훼손된 것도 아니다. 피해는 상대적으로 적을 수 밖에 없다. 하지만 이번 사고처럼 내부의 수백대의 PC가 망가지거나 농협의 경우처럼 서버의 파일이 손상되거나 정보가 유출되면 그 피해는 엄청날 수 밖에 없다. 이번 해킹사고는 정말 중요하게 생각해야할 것이 무엇인지를 보여주는 매우 중요한 사고 사례다.

 






신고
이 댓글을 비밀 댓글로

APT 공격 방어를 위해 공인인증을 연동한 서버 접근제어 구현

Posted by taeho Tae-Ho
2012.08.12 17:52 서버보안

보안 강화의 어려움

보안 업계에서 일하면서 느끼는 것 중 하나가 유독 보안업계에는 서버나 네트워크 혹은 업무 시스템의 개발과 구축 경험을 가지지 않은 "보안 전문가"가 많다는 것이다. 그러다 보니 "보안"을 문서나 말로만 하는 사람들이 많고 실제 서비스 운영이나 업무 영역의 소프트웨어를 개발하는 실무자들과 트러블이 많아진다. 우리나라 IT 분야의 특성 상 보안 업무는 개발이나 운영 그리고 IT 시스템을 사용하는 비지니스 업무 담당자들로부터 "방해꾼"의 오명을 뒤집어 쓰는 경우가 많다. 당연히 보안 실무자들의 업무 수행은 어려워질 수 밖에 없다.

가뜩이나 "보안을 강화하면 현업 업무가 불편하고 어려워진다" 는 인식이 강한데다 현업 업무 담당자들이나 업무 시스템 개발자, 운영자들이 볼 때는 현업 업무도 모르면서 입으로만 "보안강화"를 외친다는 인식을 갖게 될 수 밖에 없다.

이러한 인식을 불식시키기 위해서는 보안 정책을 강화하고 실 업무에 적용할 때 현업 업무 담당자들의 애로와 고충을 귀기울여 듣고 어려움을 해소시켜주려는 노력을 해야하며 보안을 강화하는 것이 업무를 불편하게 하는 것이 아니라 업무 프로세스를 정립하는 과정의 일부분임을 이해시키는 설득의 과정이 필요하다. 또한 보안 컨설턴트들은 개인의 간판을 중요시 할 것이 아니라 서버나 네트워크 장비의 특성과 업무단의 어플리케이션 개발에 대한 경험은 물론 웹서버, 미들웨어, 클러스터, 데이터베이스, 백업S/W, 시스템 관리 S/W 등의 다양한 솔루션들에 대한 이해와 운영 경험을 갖는 것을 더 중요시해야 할 것이다.

APT 공격 방어를 위한 공인인증 서버 접근제어 기법

아래의 동영상에서는 APT 공격을 방어하기 위한 일환의 하나로 공인인증서를 소유하고 공인인증을 받아야만 서버에 Telnet, FTP를 통해 접속할 수 있도록 하는 서버 접근제어 기법을 보여준다.

최근 APT 공격의 과정 중 하나로 내부 사용자의 노트북이나 PC를 장악하고 서버에 침투하는 경우가 많다. 만약 USB등의 매체에 공인인증서를 갖고 있으며 서버에 접근할 때 해당 공인인증서를 통해 인증을 받아야만 서버에 Telnet, FTP 접속을 가능하게 한다면 상당부분 APT 공격을 통해 서버에 접근할 수 있는 권한을 얻는 것을 차단할 수 있다.

또한 공인인증을 받기 위해 내부에 인증서버를 둔다면 인증서버의 감사로그를 통해 자연인 누가 어느 서버에 접속을 시도하고 성공했는지를 검증할 수 있을 뿐만 아니라 서버에 접근한 뒤 파일 접근 감사로그에서도 서버 계정 뿐만아니라 해당 계정을 사용한 자연인 누가~ 어느 파일에 접근 위반을 발생하였는지도 실시간으로 확인할 수 있다.


신고
이 댓글을 비밀 댓글로

[2 factor 인증] 공인인증서/OTP/ARS를 이용한 자연인 기반의 서버 접근제어(텔넷, SSH, FTP 등) 기법

Posted by taeho Tae-Ho
2012.06.23 22:45 서버보안

2011년에 발생한 굵직 굵직한 보안사고를 자세히 살펴보면 두가지 형태의 보안사고로 나뉘는 것을 알 수 있다.

첫째는 개인정보를 획득하기 위해 인터넷에 공개된 웹서버를 공격하여 서버에 침투한 뒤 개인정보를 탈취하는 형태의 전통적인 해킹이고....
 
둘째는 다양한 기법을 이용하여 내부의 PC를 거점으로 확보하고 그 PC를 이용하여 내부의 서버에 침투하는 해킹을 수행하는 APT 공격이다.

그 중에서도 두번째의 APT 공격은 사회공학적 기법의 해킹 기술부터 최신 해킹기술을 총 망라하여 지속적으로 해킹을 시도하는 무척이나 지능적인 공격기법이다. APT 공격의 특징은 직접 서버를 공격하지 않는데 있다. 외부에서 내부망에 존재하는 수많은 PC들 중 보안에 취약한 특정 PC를 해킹하고 해킹된 PC를 이용해 서버에 접근하는 것이다. 오랜시간 동안 점진적으로 서버의 주요 데이터에 접근하는 기법으로서 내부망에서 PC를 사용하는 개발자나 관리자 그리고 외부 상주인력 등의 PC가 1차 거점이 되는 형태다.

이러한 해킹의 경우 웬만한 보안 솔루션으로는 서버로의 접근(로그인)을 차단하는 것이 쉽지 않다. 이중..삼중 보안 대책을 강구하는 것이 그나마 통제할 수 있는 방법이다.

그 방법의 일환으로 공인인증서를 이용한 서버 접근제어 기법에 대해 설명하고자 한다. (OTP/ARS도 가능함)

서버의 계정과 자연인의 Mapping

서버에 telnet, ftp, ssh 접속 시 공용 계정을 직접 이용하는 것이 일반적이다. 최근에는 모든 개발자와 관리자, 엔지니어가 개인 계정을 생성하고 그 개인계정을 통해 접속하도록 통제하는 경우도 있지만 사실 모든 시스템에 적용되어 있지는 않고 서버에 많은 계정을 만드는 것은 보안에 취약하다는 선입견으로 인해 공용 계정으로 많은 사람들이 접속하는 경우가 대부분이다.

하지만 이러한 경우 개발자나 관리자, 엔지니어의 보안적 관점에서의 마인드는  빵점~이 될 수 밖에 없다. 사고를 쳐도.. 누가 사고를 쳤는지 패스워드 유출 등의 사고가 발생할 수 있는 취약점을 만들었는지를 확인하지 못하기 때문이다.

이럴 때 다음과 같이 자연인 기반의 계정(서버에 존재하지 않고 인증서버에만 존재하는 계정)과 서버의 계정을 연결시켜주어 실제 로그인 시 누가 로그인했는지 식별할 수 있도록 해준다.

인증서버에서 보안관리자가 자연인과 서버의 계정을 매핑시켜주는 것은 해당 자연인이 서버에 공인인증서를 이용하여 인증을 받고 telnet, ftp, ssh 로그인을 할 수 있다는 것을 의미한다. 즉.. 맵핑되지 않은 계정이나 서버에는 패스워드를 알고 있더라도 로그인이 불가함을 의미한다. 이것 만으로도 보안성이 크게 강화된다.
 
자신이 사용할 공인인증서 등록

인증서버에 계정이 생성되고 서버의 실 계정과 맵핑이 되면 서버에 로그인할 때 사용할 공인인증서를 등록하여야 한다. 다른 인증서는 사용할 수 없으며 자신이 등록한 공인 인증서만 사용할 수 있다.

인증서 등록 시 주민번호 확인

인증서 등록 시 비밀번호 확인

사용할 인증서 등록이 완료되면 이제부터 서버에 공인인증을 통해 로그온 할 수 있다.


서버 로그온

서버에 telnet, ftp, ssh 접속 시 ID와 패스워드를 입력하고 난 뒤 공인인증서를 요구하는 창이 실행된다. 이 창은 BCQRE의  Trust Web으로 구현되어 있으며 인증서 창을 띄워주는 Cert Daemon을 PC에 설치하여야 하며 이 Cert Daemon은 항상 Window Tray에서 실행되어 있어야 한다.

2 factor 인증

이 때 사용되는 Telnet, FTP, SSH 클라이언트 프로그램은 어떠한 것을 사용해도 관계 없다. 개발자, 관리자의 손에 익고 편리한 툴을 그대로 사용하면 되기 때문에 업무 수행에 지장을 주거나 하지는 않는다.

이 공인인증 방식의 보안 효과는 탁월하다.

자연인을 공인인증서에 의존하여 식별하기 때문에 root 계정으로 로그인하여도 실제 로그인한 자연인이 누구인지를 해당 텔넷 세션이 종료될 때까지 추적하며 보안 정책 위반 시 실제 위반한 사람이 누구인지를 정확하게 추적할 수 있으며... 자연인 기반의 파일 접근통제도 가능하다.

게다가 주요 명령어 실행 시 한번 더 공인인증서 인증을 받아야만 실행할 수 있도록 파일 접근 통제도 강화할 수 있다.

공인인증서 이외의 인증수단은 무엇이 있는가?

최근 공인인증서에 대한 취약성이 이슈가 되고 있다. 사용자PC의 하드디스크에 공인인증서를 저장하게 될 경우 인증서 비밀번호만 탈취하면 공인인증서 인증을 무력화 할 수 있는 취약성이 존재하기 때문이다. USB에 저장하여도 APT 공격에 의해 PC가 해커에게 장악될 경우 USB가 꼽혀있는 시간 동안 인증서를 복사하여 하드디스크로 옮길 수 있다.

그렇기 때문에 최근에는 공인인증서 뿐만 아니라 OTP(One Time Password)와 ARS(전화) 인증 중에서 선택하여 2차 인증 수단으로 사용할 수 있다.

OTP의 경우 하드웨어 토큰방식과 스마트폰의 앱 방식을 모두 사용할 수 있고 ARS의 경우에는 사용자의 스마트폰이나 관리자에게 전화를 걸어 인증코드를 입력하여야 접속이 가능하도록 구현이 가능하다.

이렇게 다양한 2차 인증 수단을 제공하는 보안 솔루션이 바로 RedCastle과 AuthCastle이다.


관련 포스트 보기 : APT 방어 시스템 구축 방안과 네트워크 기반 APT 방어 솔루션에 대한 오해

신고
이 댓글을 비밀 댓글로