웹 모의해킹에 필수적인 도구가 바로 프락시 툴이다. HTTP 프록시(Proxy)는 서버의 일종으로서 웹브라우저(IE, 에지, 크롬, 사파리 등)와 웹서버(Apache, Tomcat, NGINX 등)가 주고 받는 요청(Request)과 응답(Response)를 중간에 가로채고 분석할 수 있으며 전달되는 값을 변조할 수 있는 도구다.

때문에 HTTP Proxy 툴을 이용하면 암호화 되지 않은채 웹브라우저와 웹서버가 주고 받는 모든 정보를 가로채 볼 수 있다. 당연히 보안 취약점이 발견되면 즉각적으로 변조 공격을 수행할 수 있는 해킹도구로 악용될 수 있는 도구다.

모의 해킹을 공부할 때 또는 실제 모의 해킹을 할 때 SSL이 적용된 경우 HTTP Proxy를 설정하고 웹 서핑을 해보면 이런 오류가 발생한다. 포털사이트인 daum.net에 접속했을 때의 화면이다.

Proxy 설정했을 때 브라우저 경고창

이 오류는 크롬에서 발생시키는 경고메시지 인데... 크롬은 www.daum.net 에 요청했고 www.daum.net에서 보내준 SSL 인증서를 검증하는데 실제 수신된 곳은 www.daum.net이 아니고 HTTP Proxy 이므로 인증서와 송신서버가 달라서 발생하는 에러다.

이 문제를 해결하기 위해서는 HTTP Proxy의 인증서가 필요하다. 최근 사용하는 HTTP Prox는 버프스위트(Burp Suite) 기준으로 HTTP Proxy 인증서 설정 방법을 기록해 둔다.

먼저 PC에 등록할 Burp Suite HTTP Proxy 용 인증서를 다운받는다. 다운은 크롬 브라우저에서 http://burp 에 접속한다. 단, 프록시가 설정되어 있어야 하고 Burp Suite가 실행 중 이어야 한다.

크롬의 브라우저 창 오른쪽 상단에 있는 CA Certificate 를 클릭해 인증서 파일을 다운로드 받는다.

적당한 위치에 cacert.der 파일을 저장해 둔다. 나중에 인증서 등록 마법사에서 이 파일을 선택해 등록해야 한다.

다운로드 받은 인증서는 크롬 브라우저의 "설정" - "고급" - "개인정보 및 보안" 메뉴에 있는 인증서관리 메뉴에서 등록한다.

"인증서 관리" 메뉴가 보인다. 이 메뉴를 클릭하면 Windows의 인증서 관리 창이 실행된다.

인증서 관리창이 실행되면 "신뢰할 수 있는 루트 인증 기관" 탭이 보인다. 이 탭에 다운로드 받은 cacert.der 파일을 등록해야 한다. 하단에 있느 몇개의 버튼 중 "가져오기" 버튼을 클릭하면 인증서 가져오기 마법사가 실행된다.

인증서 가져오기 마법사에서 "가져오기" 버튼을 클릭하면 파일을 선택하는 창이 실행되는데.. 하단에서 "모든 파일(*.*)"을 선택해준 뒤 앞에서 다운로드 받은 cacert.der 파일이 있는 곳으로 이동하여 선택해 준다. 그리고 "열기" 버튼을 클릭한다.

"모든 인증서를 다음 저장소에 저장"을 선택하고 "신뢰할 수 있는 루트 인증 기관"을 선택한다.

경우에 따라 아래와 같은 보안 경고 창이 실행되는데... "예"를 클릭해 인증서를 설치한다.

인증서 등록이 되었다면 "신뢰할 수 있는 루트 인증 기관" 목록에 앞에서 등록한 인증서가 정상적으로 등록되어 있는지 확인한다.

그런 뒤 다음에 접속하고 "자물쇠 표시"를 선택해 인증서 정보를 확인하면 발급대상이 www.daum.net 인데 발급자가 PortSwigger CA로 되어 있다.

이제 SSL이 적용된 웹사이트도 HTTP Proxy가 설정된 상태에서 정상적으로 서핑할 수 있으며 HTTP Proxy를 테스트할 수 있다.

책장을 정리하다 2015년 ISACA 저널에 기고했던 글이 실린 책을 발견했다. 무언가 글을 써서 어딘가 활자로 인쇄되어 나오는 것이 어떤 느낌인지를 알려주었던 소중한 경험이었다. 당시 올렸던 글의 원문을 이제 3년 넘게 지난 시점에 블로그에 올려 본다.

특별기고

서버 운영체제 접속에 대한 이중 인증 시스템 구축 사례 분석

인증이란?

인증이라 함은 다중 사용자 시스템 또는 망운용 시스템에서 접속자의 로그인 정보를 확인하는 보안 절차를 말한다. 그 외에 전송된 메시지의 무결성과 송신자를 검증하는 과정도 인증에 해당된다. 

서버 또는 애플리케이션에서 사용자들에게 사용권(접근권한)을 부여하기 위해 접속자의 신분을 검증하는 과정을 로그인이라 하며 이 로그인 과정에 “인증” 과정이 필요함은 두말할 나위가 없다. 

사용자는 로그인에 성공하기 위해서 “식별(Identification)”과 “인증(Authentication)”의 두 단계를 통과해야 한다. “식별”은 로그인 하려는 사용자가 누구(who)인지 계정정보(ID)를 입력 받아 시스템에 접속 권한을 가진 사용자인가를 검증하는 단계이고 식별을 완료한 뒤 현재 접속하려는 사용자가 입력한 계정의 소유자가 맞는가를 비밀번호와 같은 검증 수단을 이용해 확인하는 것이 “인증” 이다. 이러한 “식별”과 “인증”과정은 접속자가볼 때 동시에 실행되는 것으로 보여야만 하며 통상적으로 “식별”과 “인증”을 모두 “인증”이라고 표현한다.

지식 기반 인증(ID/ Password)의 취약성과 새로운 인증 기술

일반적으로 대부분의 운영체제에서 기본적으로 적용되어 있는 인증방식은 보안에 가장 취약한 ID/ Password에 의존하는 지식 기반 인증이다. ID/ Password를 사용하는 인증방식은 사람의 기억력에 의존하는 짧은 문자열을 검증하는 방식이기 때문에 Password Guessing(패스워드 추측), Brute-Force Attack(무작위 대입), Password Dictionary(패스워드 사전)등의 잘 알려진 패스워드 공격에 취약하며 개인 정보 유출, 패스워드를 기록한 파일의 유출 등에 의해 서도 쉽게 공격을 받고 뚫리기도 한다. 

때문에 ID/Password 이외의 인증 수단에 대한 지속적인 연구가 이루어졌으며 [그림 1]과 같이 다양한 인증 기법이 개발되어 적용되고 있다.

이중 인증 (또는 2차 인증)

이중 인증이라 함은 인증의 보안성 강화를 위해 [그림 1]에 설명되어 있는 4가지 타입의 인증 기술 중 2가지 이상을 로그인에 인증 수단으로 적용하는 것을 의미한 다. 예를 들어 비밀번호를 사용하는 지식기반 인증을 사용하는 인증과정에 추가적으로 OTP 인증을 적용하면 이중 인증을 구현한 것이 된다. 

최근에 금융 시스템에 적용되어 널리 사용되기 시작한 QR코드나 문자 메시지를 이용한 mOTP, 그리고 ARS 또한 이중 인증을 구현하기 위한 수단으로 사용 될 수 있다. 

이중 인증 시스템을 구현함에 있어 중요한 포인트는 사용자가 접속을 시도할 때 인증 로직의 구현상 하나의 스텝에서 두 가지의 인증이 동시에 이루어져야 한다는 점이다. 만약 두 가지의 인증 단계가 각각 분리된 시스템에서 수행되거나 이중 인증이 이루어지는 시간 차가 클 경우 취약점이 발생할 수 있기 때문이다.

서버의 운영체제 계정에 대한 이중 인증 필요성

2011년 4월 발생한 N은행의 APT 공격에 이은 200여 대의 서버에 대한 DOS 공격(서버의 파일시스템 파괴), 2013년 발생한 신용카드 3사의 서버 침투에 이은 개인 정보 유출 사고는 대표적인 “전산 시스템 운영 및 유지 보수 인력에 대한 내부통제”가 미흡해서 발생한 사고라 할 수 있다. 

그리고 사고 발생의 주요 원인으로 “서버의 접속(로그 인)에 대한 통제 미흡”이 지목 받은 바 있다. 

금융감독원은 위의 두 사례를 비롯해 서버 접속에 대한 내부 통제 미흡으로 지속적인 보안사고가 발생하자 금융전산망의 서버를 APT 공격과 내부자에 의한 고의 또는 실수로 발생되는 보안 사고로부터 예방하기 위해 다음과 같이 전자금융감독규정을 개정하여 고시하였다.

새롭게 추가된 14조 9항에서는 서버의 운영체제 계정으로 로그인 할 때 ID, 비밀번호 이외의 추가 인증 시스템을 구축하라고 의무화하고 있다. 이는 기업 내부의 서버 관리자와 엔지니어들이 Telnet, SSH, FTP 등의 도구를 사용해 서버에 로그인할 때 ID, 패스워드 이외에 추가적으로 OTP, PKI, ARS 등의 실사용자 인증을 한번 더 거쳐야 한다는 것을 의미한다. 그래야만 APT 공격에 의해 해커에게 장악된 PC나 서버를 통해 다른 개인정보나 금융정보가 저장되어 있는 서버까지 해커가 침투하는 것을 차단할 수 있기 때문이다. 

이어진 10항에서는 Telnet, FTP, SSH 등의 방법을 통해 서버에 접속한 운영자와 엔지니어가 작업하는 내용을 실시간으로 모니터링 해야 하며 적법하지 않은 명령어 실행 및 파일에 대한 읽기/쓰기/수정/삭제 등을 통제하라고 하고 있다. 

이 시행규칙은 금융권에서 발생하는 개인정보 유출 사고가 서버에 운영체제 계정으로 로그인한 운영자 또는 개발자가 임의로 데이터베이스를 조회하는 명령어를 실행하고 그 결과로 출력되는 정보를 파일로 저장(생성)하여 FTP를 통해 외부로 반출했던 과정을 염두에 둔 것으로 보인다. 

그렇다면 운영체제 계정으로 서버에 접속할 때 어떤 방식으로 이중 인증을 구현할 수 있는지 그 사례와 기 술적인 방법론에 대해 살펴보자.

운영체제 계정의 이중 인증 구축 사례

서버 운영체제 계정의 로그인 시 이중 인증을 구현하 는 방식은 크게 3가지 정도로 분류할 수 있다.

1. 접속 기기에서의 추가 인증 방식

이 방식은 [그림 2]와 같이 서버에 접속할 PC에 로그인 할 때 혹은 PC에 로그인 한 뒤 서버에 접속하는 시점에 먼저 추가인증을 받는 방식이다.

이 방식은 서버의 형상을 변경하지 않고 가장 손쉽게 이중 인증을 구현할 수 있도록 해준다. 하지만 이 방식을 서버 접속에 대한 이중 인증이라고 보기는 어렵다. 접속자의 추가 인증 시점과 서버의 로그인 시점이 일치하지도 않을 뿐만 아니라 실제 서버 운영체제의 계정으로 서버에 접속할 때 수행되는 인증 과정에 별도의 인증과정이 추가되는 것도 아니기 때문이다. 또한 서버의 접속 이력 로그와 추가 인증 로그에 실 사용자의 식별정보가 전혀 기록되지 않기 때문에 서버 접속 이력과 추가 인증 감사 로그를 매칭하여 서버에 로그 인한 실사용자를 특정하는 것도 불가능하다.

2. 인증 게이트웨이 방식

두 번째 방식은 현재 가장 많은 레퍼런스를 확보하고 있는 인증 게이트웨이 방식이다.

[그림 3]에서와 같이 인증 게이트웨이 방식은 흔히 SAC(System Access Control)라는 솔루션들이 채택하는 방식이다. 이 방식은 서버에 로그인 하려는 사용자가 먼저 인증 게이트웨이에 로그인 하고 해당 사용자가 로그인 할 수 있는 서버의 목록을 보여준 뒤 접속하려는 서버를 선택하여 서버에 실제 로그인하는 방식이다. 이 방식은 게이트웨이 서버에 접속하는 대신 PC나 노트북에 에이전트를 설치하고 에이전트가 대신 인증 게이트웨이에 접속하는 형태로 변형되기도 한다. 이 방식에서 이중 인증은 게이트웨이에 로그인 할 때 이루어지는데 앞에서 설명한 것과 마찬가지로 실제 서버에 로그인할 때는 ID/Password 인증만 수행하게 된다. 심지어 인증 게이트웨이에 로그인하면 서버 로그인 시에는 ID/Password를 묻지도 따지지도 않고 자동으로 ID와 Password를 입력해주는 보안 취약점을 만들기도 한다. 다만 인증 게이트웨이가 양쪽 세션에 대한 정보를 모두 갖고 매칭시켜 주기 때문에 서버에 접속한 실제 사용자가 누구인지를 식별할 수는 있다. 

그리고 이 방식의 가장 큰 문제점은 인증 게이트웨이를 거치지 않고 우회하여 서버에 로그인하는 행위를 차단하기 어렵다는 점이다. 서버마다 “TCP Wrapper”와 같은 오픈소스 도구를 설치하기도 하지만 관리자 권한에서 너무 쉽게 해제가 가능하기 때문에 사실 큰 의미가 없다. 장시간 운영하다 보면 여기 저기 우회하여 서버에 로그인 할 수 있는 홀이 발생할 수 밖에 없다.

3. 운영체제 PAM 인증 추가 방식

세 번째 방식은 [그림 4]와 같이 서버 운영체제가 지원하는 PAM이라 불리는 인증모듈에 추가 인증 모듈을 추가하는 방식이다. 

Unix 와 Linux 운영체제는 기본적으로 PAM(Pluggable Authentication Module)이라고 하는 인증 모듈을 사용자가 개발하여 추가할 수 있는 기능을 지원한다. (Windows는 GINA / CP 모듈을 지원함) 즉 ID와 Password 인증 후 추가된 인증 모듈을 운영 체제가 호출해주는 방식이다. 이 기술은 수 십 년의 역사를 가진 Unix/Linux/Windows 함께 발전하고 안정화되었기 때문에 가장 안전하고 확실한 기술이라고 할 수 있다. 다만 추가 인증을 구현하고자 하는 모든 서버에 추가 PAM 모듈을 설치해야 하는 부담이 있다. 모든 서버의 형상을 변경해야 하는 부담이 있지만 이 방식은 서버 접속에 대한 우회 접속을 완벽하게 차단 할 수 있기 때문에 보안 관점에서 가장 권고할 만한 기술이다. 그리고 서버의 감사로그에 접속한 실제 사용자의 자연인 정보(이름, 사번 등)를 기록할 수 있으며 보안운영체제인 SecureOS 솔루션과 연계할 경우 자연인 기반의 위협 명령어 실행 통제까지도 구현이 가능하기 때문에 보안성과 확장성 측면에서 가장 우월한 위치에 있다고 할 수 있다.

장단점 및 결론

기업 내부 인력 혹은 외주 인력이 서버에 로그인 하여 어떤 행위를 하든 통제하지 못하는 현실을 감안하면 이중 인증 시스템을 구축하여 얻을 수 있는 가장 큰 장점은 서버에 기록되는 로그인 감사 로그를 보고 실제 접속한 사람이 “누구(who)”인지를 특정할 수 있고 그 사람이 “작업한 내용”을 명확하게 재연할 수 있다는 것이다. 이는 서버의 보안수준을 획기적으로 높여주는 결과를 얻을 수 있다. 사실 현재까지도 “서버”는 보안의 관심 대상에서 다소 벗어나 있는 것이 현실이다. 

서버라는 IT자원이 서비스에 핵심적인 자원이고 장애가 발생할 경우 매우 치명적인 피해를 유발할 수 있기 때문에 보안보다는 안정성과 가용성에 초점이 맞춰져 있다. 즉 “해킹이나 정보유출의 가능성이 있더라도 서비스가 우선”이라는 무언의 공감대를 깨지 못하고 있는 것이다. 하지만 해킹이나 내부 통제 취약점이 공격을 받아 서버에 침입이 발생하면 돌이킬 수 없는 치명적인 손실이 발생할 수 있다는 것을 최근 몇 차례의 보안 사고에서 경험할 수 있었다. 따라서 내부자 권한의 탈취를 통한 서버운영체제 계정으로의 불법적 접속과 접속 후 서버 내에서의 위협행위에 대한 보호대책으로서 운영 체제 접속에 대한 이중 인증 구현 및 실사용자 식별 시스템을 구축할 것을 신중히 고려하여야 한다.

2015년 봄... 인터넷을 뜨겁게 달구던 클리앙 랜섬웨어 유포사고는 랜섬웨어를 사용자들의 PC에 감염시키기 위해 웹서버를 "이용"했을 뿐이다. (사고 관련 포스트 보러가기) 그래서 사실 웹서버에는 별다른 피해가 발생하지 않는다. 이렇게 서버에 별다른 피해를 끼치지 않기에 웹서버를 이용한 악성코드 유포사고로 피해를 보는 것은 일반 사용자들 뿐이다. 서버를 운영하는 기업들이나 공공기관은 별다른 피해를 입지 않고 "욕만 한번" 먹고 그냥 넘어가기 일쑤다.

하지만 최근 랜섬웨어가 일반 사용자들의 PC 뿐만아니라 서버까지도 공격한다는 소식은 웹서버를 이용해 서비스를 제공하는 기업이나 기관의 IT부서 담당자들을 꽤나 긴장하게 할 듯 하다.

해커 입장에서는 어차피 랜섬웨어를 사용자의 PC까지 감염시키기 위해서는 일단 유포지로 선택된 웹서버에 랜섬웨어를 업로드해야 하며 이를 위해서는 웹서버의 취약점을 찾아 해킹해야 한다. 그 이야기는 업로드된 서버에서 랜섬웨어가 동작하게 하면 서버의 수많은 파일을 암호화할 수 있다는 이야기다. 해커 입장에선 더 손쉬운 공격이 될 수 있다. 

인터넷에 떠도는 웹서버의 파일이 랜섬웨어에 의해 암호화된 화면 

이런 공격은 일반적인 웹쉘 탐지솔루션이나 IPS, 웹방화벽 등으로는 차단이 불가능하다. 일단 웹서버에서 취약점이 발견되면 해커는 취약점을 악용해 랜섬웨어를 업로드하거나 직접 서버에서 소스를 컴파일해 실행파일을 생성할 수 있다. 

서버에 업로드된 랜섬웨어는 웹서버가 실행중인 운영체제 계정의 권한으로 접근이 가능한 수많은 파일을 암호화해버릴 수 있다. 당연히 암호화가 끝나면 암호화에 사용된 Key가 담긴 파일을 삭제하고 "돈내라고" 협박하는 웹페이지를 생성해 웹서버 관리자에게 보여줄 수 있다.

이런 상황은 현재까지 나도 경험해보지 못했기에 "가정"하는 상황이지만 충분히 가능한 시나리오며 여러 보안관련 사이트에서 이러한 위험을 경고하고 있는 상황이다.

종종 방문하는 SecurityPlus의 블로그에서도 관련 정보를 찾아볼 수 있다.

(http://blog.securityplus.or.kr/2016/01/blog-post_14.html)

웹서버의 취약점을 공격하여 서버에 파일을 생성하고, 명령어를 실행하며, 소스파일을 위변조하거나 암호화하는 공격을 가장 효과적으로 차단할 수 있는 보호대책은 RedCastle SecureOS를 서버에 설치하고 파일접근통제정책(File ACL)을 적용하는 것이다. 그리고 이 FileACL을 적용하기 위해서는 SecureOS 전문 컨설팅을 통해 웹서비스의 디렉토리 구조 및 보호대상 자원(파일)을 선정하고 정책을 구현하는 서비스를 받아야하기도 한다.

그와 과련된 여러 포스팅을 올렸고 해당 포스트를 보고 여러 분들이 문의를 주시곤 한다. 보안솔루션은 보안의 특성상 완벽한 해킹차단은 불가능하다. 가장 완벽한 보안솔루션도 예상치 못한 Hole이 발견되어 뚫리곤 한다. 

하지만 분명한 것은 RedCastle SecureOS는 다른 보안솔루션보다 월등한 명령어 실행 통제 및 파일 위변조 차단 성능을 보여준다는 것이다. 아래 포스트에 방어사례도 있지만 실질적인 서버 내부에서 일어날 수 있는 해킹에 대한 방어 효과는 그 어떤 보안솔루션과의 비교를 거부할만큼 월등한 성능을 보여준다.

당연히 랜섬웨어에 의해 서버에서 발생할 수 있는 파일의 암호화 공격에 가장 효과적으로 대응할 수 있는 보안솔루션이 바로 RedCastle SecureOS라고 할 수 있다.

관련 포스트 모음

IIS웹서버 해킹을 통한 악성코드 삽입 공격 방어 사례 (소스위변조공격)  -  http://blogger.pe.kr/346

웹페이지 변조(파일변조)를 차단하는 근본적인 방법  - http://blogger.pe.kr/433

웹서버 해킹 방어 사례 - 남다른 끈기를 보여준 해커 -  http://blogger.pe.kr/451

RedCastle은 SecureOS 입니다. IT인프라의 네트워크 또는 응용프로그램의 취약성을 뚫고 서버 내부로 침투한 이후, 해커의 행위를 통제할 수 있는...어찌보면 보안인프라 중에서도 최후의 보루라 할 수 있죠. 최후의 보루라는 이유는 해커가 서버 운영체제의 SuperUser 권한이나 어플리케이션 관리자 권한을 탈취한 뒤에도 방어가 가능한 유일한 보안 솔루션이기 때문입니다.

SecureOS 이외의 어떤 보안 솔루션도 root 권한...Administrator 권한을 획득한 해커의 공격을 막아낼 수 있는 솔루션은 없습니다. 물론 RedCastle도 한계는 있지만 타 보안 솔루션과 비교할바는 아닙니다.

하지만 RedCastle을 도입한 많은 기관이나 기업에서는 여전히 네트워크를 통해 서버에 접근하는 것을 차단하는데 총력을 기울이고 있습니다. 그리고 그러한 노력은 당연한 것입니다. 서버에 접근하기 전에 위험한 접근은 차단하는 것이 정답이죠. 그래서 RedCaslte에서 제공하는 서버방화벽 기능을 이용해 내외부에서의 접근을 통제하는 경우가 많습니다. 

그런데 가끔은 참 어려운 요구를 하는 경우도 있습니다. 바로 중국 때문입니다.

중국의 IP 대역

RedCastle에서 제공하는 방화벽은 SW 방화벽입니다. 그리고 서버 자원인 CPU를 사용합니다. 때문에 너무 많은 방화벽 정책을 적용하기에는 무리가 따릅니다. 그래서 개인적으로는 100라인 이내에서 정책을 적용하는 것을 권장합니다. 그럼에도 "중국"은 모두 막고 싶다는 요청을 하기도 합니다.

중국의 IP 대역은 무척 많습니다. 상상을 초월합니다. KRNIC에서 제공하는 웹페이지에 가면 각 국가별로 필터링이 가능한 IP 대역이 포함된 CSV파일을 다운받거나 조회할 수 있습니다. (KRNIC의 국가별 IP대역 현황)

그 CSV 파일을 살펴보면 다음과 같은 구조로 되어 있습니다.

각 칼럼은 쉼표(,)로 구분되어 있고 기준일, 국가코드, 시작IP, 끝IP, 프리픽스(CIDR), 할당일자 순서로 되어 있습니다.

전세계 인터넷 IP를 할당받은 모든 국가에 할당된 정보가 포함되어 있는 이 파일은 15만라인이 넘습니다. 그리고 중국의 국가코드인 CN이 포함된 라인은 5825라인입니다. 어마무시하죠. 즉 RedCastle의 서버 방화벽에 최대 5825라인이 들어갈 수도 있다는 이야깁니다. 

RedCastle에서 중국IP 차단 방화벽 정책 적용하기

대부분의 기업과 기관에서는 네트워크 방화벽에서 해외 접속을 차단합니다만... 일부 중소기업이나 작은 쇼핑몰 등에서는 값비싼 방화벽 장비를 도입할 수 없는 경우가 많습니다. 제대로 보안을 강화하자면 DMZ 앞단에 외부방화벽을... DMZ와 내부망 사이에 또하나의 방화벽을 두어야 하기 때문이죠. (물론 방화벽 한대로 할 수도 있습니다만..)

그렇기 때문에 포트스캐닝이나 불법적 접속 시도와 같은 기본적인 네트워크 보안도 수행하고 홈페이지 소스파일 위변조도 차단하고 내부 사용자에 대한 보안도 강화하기 위해 이 모두를 한꺼번에 수행할 수 있는 서버보안 제품을 도입하는 경우가 종종 있습니다.

그리고 그런 경우 웹서버 앞단에 방화벽이 없는 경우가 대부분이기 대문에 "중국IP를 모두 차단하고 싶다"는 요구가 이따금씩 발생합니다. 그러기 위해서는 앞에서 살펴본 중국 IP를 차단하는 방화벽 정책을 적용해야 하는데... 이 작업을 수동으로 하자면 끝이 없습니다. 불가능하죠. 중국의 IP 대역을 일일히 네트워크 그룹에 등록해야하고 등록된 네트워크 그룹을 이용해 차단 정책을 넣어줘야 합니다.

그래서 위의 전세계 IP 대역이 포함된 파일에서 중국의 IP 대역만 찾아 네트워크 그룹으로 등록하고 차단 정책을 만들어 주는 쉘 스크립트를 작성했습니다.

소스는 무척 짧습니다. 

cnb.sh (리눅스에서만 테스트 됨)

위의 스크립트를 구동하면 291개의 네트워크 그룹과 291개의 방화벽 정책이 생성됩니다. 이 정책을 RedCastle의 방화벽 정책이 저장되는 리포지토리에 저장하고 매니저에서 불러와 적용하면 중국IP를 차단할 수 있습니다.

그리고 위의 스크립트를 조금만 수정하면 리눅스의 iptables 명령문도 만들어 자동으로 실행되도록 할 수 있습니다.

반대로... 국내에서만 서비스되는 서버라면 우리나라의 IP 대역만 접근을 허용하고 나머지는 차단하는 정책을 적용하는 것이 더 효율적입니다. (우리나라의 IP 대역도 만만치는 않습니다. 1065개나 됩니다.)

다만...

서버의 자원을 사용하는 SW 방화벽이기 때문에 서버의 성능과 네트워크 트래픽 등을 감안하여야 한다는 점을 꼭 유념해야 합니다. (그래도 다른 서버 방화벽 보다는 가볍습니다. 그 이유는 나중에.... ^^)

정보보안 업계에서 일을 하면서 정보보안업계는 다른 IT 업종과 참 많은 것이 다르다는 것을 알게 됐지만 그 중에서도 큰 차이점은 과도하게 "기술 지향적"이라는 점이다. 쉽게 말해 "정보보안전문가 == 해커" 이라는 등식이 당연하게 받아들여 진다는 것이다. 이런 잘못된 인식은 정보보안전문가를 목표로 하는 젊은이들이 리버스엔지니어링(악성코드분석), 웹 취약점 공격, 패킷 분석 등 특정 분야의 기술습득에만 몰두하게 되는 부작용을 낳고 있다.

만약 정보보안전문가들이 악성코드를 만들어 배포하고 해킹을 시도하는 해커만큼의 기술적 수준을 갖고 있어야 한다면 해킹을 방어하는 것은 거의 불가능할 것이다. 정보보안전문가들은 해킹에 악용되는 취약점과 해당 취약점을 공격하는 악성 코드의 코드 하나하나가 아니라 해당 취약점을 내포하고 있는 SW나 System을 이해하는 것과 악성코드가 동작하는 개념, 그리고 해당 취약점을 공격하여 공격 대상 서버 혹은 시스템에서 해커가 얻는 것이 무엇이며 취약점 공격을 통해 얻은 것으로 무엇을 할 수 있는가를 찾아내는 능력을 키우는 것이 더 중요하다.

CVE로 명명되고 있는 취약점은 매우 다양하며 해커들에 의해 앞으로도 끊임없이 많이 발견될 것이고 해커들은 해당 취약점을 공격하는 악성코드를 생산해 낼 것이다. 그렇다면 과연 그러한 취약점을 일일히 하나도 빠짐없이 정보보안전문가들이 코드 하나 하나까지 분석하고 대응해야 하는 것일까? 그것은 정보보안전문가들에겐 너무도 비효율적이다 못해 잔인한 일이다. 그것은 악성코드 분석 전문가에게 맞기고 그들이 분석한 결과를 활용하는 것이 옳은 방향이다. 모두가 악성코드 분석 전문가가 될 필요는 없다.

이번 포스팅에서 다룰 내용은 바로 그런 관점에서 수많은 취약점을 이용해 해커가 하고자하는 행위인 운영체제 쉘 권한의 획득을 방어하기 위해 운영체제가 갖고 있는 Shell의 실행을 SecureOS를 통해 통제하는 것이 얼마나 효율적인 정보보안대책인지를 이야기하고자 한다.

Shell의 취약성

대부분의 운영체제는 Shell 이라고 하는 대화형 사용자 인터페이스를 제공한다. Unix와 linux는 bash(본어게인쉘)을 비롯해 sh, ksh, csh, tcsh 등 다양한 쉘(shell)을 지원한다. 그리고 Windows 운영체제의 경우에도 cmd.exe를 지원한다.(예전엔 하위 윈도 호환을 위해 command.com도 있었음)

그런데 이 쉘은 보안에 매우 취약하다. 그리고 이 취약성은 해커들에게는 다른 수많은 취약점의 공격을 통해 꼭 얻어내야 하는 성지와 같다. 운영체제 벤더인 IBM, HP, Oracle(과거의 Sun), RedHat 등은 이 취약성을 제거하는데는 관심이 없다. 그리고 앞으로도 제거에 앞장서지는 않을 것이다. 왜냐하면 Unix와 Linux의 근본 사상이 무너지는 결과도 초래할 수 있기 때문이다. 

여기에서 이야기하는 쉘의 취약성은 쉘이 갖고 있는 버그(?)로 인한 기술적 취약성이 아닌 운영체제의 근본 개념에 의해 발현되는 근본적인 취약성이다. 즉 사용자가 매우 다양한 입력 경로를 통해 쉘에게 전달하는 명령을 쉘이 완벽하게 실행해주기 때문에 발생하는 취약성 아닌 취약성이다. 즉 사용자의 명령이 키보드 입력을 통해 전달되든 파일에 저장되어 파일명으로 전달이 되든, 다른 서비스 대몬으로부터 exec 함수를 통해 전달이 되든 가리지 않고 완벽하게 실행해주기 때문에 발생되는 취약성이다. 이 취약성은 어떤 기술적 취약성으로도 분류되지 않는 아무도 인정하지 않는 취약성이다. 왜냐하면 "쉘은 원래 그렇게 만들어졌기" 때문이다. 

이 취약성은 tty 혹은 pts가 할당되거나 실제 사용자가 접속하여 키보드로 입력한 명령만을 실행하도록 하는 매우 단순한 통제 만으로도 매우 효과적인 통제를 수행할 수 있다. 그리고 이러한 방법은 기술적으로 비교적 간단하게 구현이 가능하다. 원래 쉘은 서버에 접속한 사용자에게서 명령을 입력받고 해당 명령의 파일을 찾아 실행시켜주는 역할을 수행하면 되기 때문이다. 하지만 쉘은 거기에서 그치지 않고 스크립트를 실행하거나 백그라운드로 배치 작업을 구동하는데도 이용되고 있기 때문에 현실적으로 적용이 어렵다. 이는 Windows 운영체제도 마찬가지다. 결국 제거할 수 없는 취약성인 셈이다. 

해커들은 그 점을 악용한다. 해커들은 서버에 직접 Telnet, SSH, Terminal Service 등을 통해 접속하지 않고 어떤 방법으로든 쉘의 "제거할 수 없는 취약성"에 접근할 수 있는 다른 취약점만 찾으면 서버를 해커가 마음대로 조종할 수 있다는 것을 알고 있다. 아래의 경우도 같은 경우다.

이 화면은 이슈메이커스랩이라는 화이트해커그룹에서 악성코드를 분석한 결과다. 웹브라우저에서 구동되는 플래시의 취약점을 악용해 악성코드를 다운받게 하고 다운받은 악성코드가 Windows가 설치된 PC나 서버에 저장되어 있는 문서파일들을 Windows의 기본 쉘을 실행시켜 수집하기도 한다는 분석 결과다.

여기서 정보보안전문가라면  윈도의 쉘인 cmd.exe가 실행되었음을 포착하여야 한다. 수 많은 취약점과 악성코드들이 최종적으로 PC나 서버 내에서 무언가를 실행하기 위해 cmd.exe를 실행한다. 따라서 악성코드가 cmd.exe를 실행하는 것을 차단하면 해커의 해킹의지를 효과적으로 꺾을 수 있다. 해커가 희생자 컴퓨터에 콘솔이나 정상적인 원격접속을 하지 않고 희생자 컴퓨터에서 무언가 정보를 획득하거나 원하는 명령을 실행하기 위해서는 Windows의 경우 cmd.exe를, Unix나 Linux에서는 bash나 sh와 같은 쉘을 실행하여만 한다. 

MS 오피스, 아래아한글, 어도비 PDF와 플래시, 그리고 GIF와 같은 이미지 등에서 발견되는 수많은 취약점들은 최종적으로 운영체제의 명령어나 쉘을 실행하기 위한 경유지 정도의 역할을 하는 경우가 대부분임을 알아야 한다.

따라서 PC나 서버의 운영체제에서 제공되는 쉘을 어떻게 통제하는가가 보안의 핵심 중 하나인데... 현실은 거의 통제되지 않고 있는것이 현실이다.

쉘(shell)의 통제 방안

쉘(shell)의 실행 통제는 사실 SecureOS가 없이는 불가능하다. 쉘의 실행 통제 필요성은 정보보안전문가라면 한번쯤은 필요성을 느껴보았겠지만 쉘의 실행을 통제할 수 있는 보호대책의 구현이 SecureOS로 가능하다는 것 조차도 많이 알려지지 않다.

쉘의 실행을 통제함으로써 구현 가능한 대표적인 보호대책이 바로 "웹쉘(webshell)의 실행 차단"이다. 일반적으로 웹서버의 수 많은 취약점을 통해 서버에 웹쉘을 업로드하거나 운영체제의 명령어를 실행할 수 있는 인젝션(Injection) 취약점을 악용하여 운영체제의 쉘을 실행하게 되는데 취약점에 관계없이 웹서버 프로세스를 통한 명령어의 실행을 원천적으로 차단할 수 있게 된다. (관련 포스트 보러가기 : Windows ASP 웹쉘 분석 및 차단 구현,    Unix/Linux 웹쉘 차단 구현)

웹쉘 이외에도 Windows의 쉘인 cmd.exe와 Unix/Linux의 쉘인 sh, ksh, csh 등은 실행 감사로그를 수집하여 분석하고 정상적인 주체에 의해서만 실행이 허용되어야 한다. 만약 여러 이유로 인해 실행을 통제하기 어렵다면 웹서버 대몬, DB 프로세스 등 잠재적 취약성이 있는 애플리케이션에서의 쉘 접근은 최소한 차단하도록 보호대책을 수립해야 한다. 이러한 보호 대책은 SecureOS 인 RedCastle을 통해 구현할 수 있다.

SecureOS인 RedCastle을 통해 운영체제의 쉘에 대한 실행을 통제하게 되면 쉘의 실행을 목적으로 다양한 취약점을 찾고 찾은 취약점을 공격하는 악성코드를 작성하여 침투해도 악성코드가 쉘을 실행하지 못함으로써 해커가 원하는 목적을 이루지 못하게 된다. 따라서 보안담당자는 쉘을 실행시킬 수 있는 수많은 취약점에 일일히 대응하지 않아도 되며 정기적인 보안 패치의 적용하면 된다. Zero-Day 취약점에 효과적으로 대응할 수 있는 것이다. 

운영체제의 쉘에 대한 접근 통제를 수행할 수 있는 유일한 보안 솔루션은 RedCastle SecureOS다.

사족

정보보안업계가 기술적 취약점 하나 하나에 너무 집착하게 됨으로써 흔히 정보보호담당자를 뽑을 때 해킹대회 입상자나 리버스엔지니어링과 같은 기술을 요구하는 구인광고를 보게된다. 사실 리버싱기술을 갖고 있거나 해킹대회에 입상할 정도의 실력을 가진 화이트해커라면 특정분야의 기술적 수준은 높겠지만 관리적보안이나 해당 분야가 아닌 다른 분야의 실력은 예상만큼 높지 않을 가능성이 더 많다.

오히려 운영체제와 운영체제에서 구동되는 다양한 시스템소프트웨어, 예를 들면 클러스터나 백업소프트웨어, 데이터베이스, 배치스케줄러와 미들웨어(웹로직, 제우스, 웹스피어 등)등의 역할과 특징을 이해하고 있으면서 네트워크나 데스크탑 컴퓨터의 특성을 종합적으로 이해하고 있으면서 보안의 기술적, 관리적 체계를 이해하고 있는 사람이 더 적임자라고 말하고 싶다.

기관이나 기업의 정보보호담당자는 특정 분야의 해킹기술 보다는 다양한 IT 분야의 다양한 경험과 관리적 보안에 대한 노하우를 고르게 갖고 있는 사람이 더 적합하다 하겠다. 제 아무리 보안을 전공하고 박사학위를 받았더라도  AIX, HPUX, CISCO Switch와 같은 하드웨어 인프라와 Oracle, Sybase, Weblogic, tuxedo, JEUS 등의 DB와 Java 기반 미들웨어, 게다가 NetBackup, Control-M, HACMP, MC-ServiceGuard 등의 시스템 소프트웨어를 모르는 보안 담당자가 시스템 엔지니어들을 통제하면서 제대로된 기술적 보호대책을 수립할 수 있겠는가?

십수년 전부터 구축되는 정보시스템은 네트워크, 운영체제, 웹, 미들웨어 등 다양한 솔루션들이 융합되어 하나의 시스템을 이룬다. 수십개의 솔루션이 유기적으로 연동되고 융합되어 정보를 수집하고 가공하고 저장하며 분석하고 표현해준다. 그 과정에서 발생할 수 있는 정보의 유출과 파괴는 악성코드 분석기술, 패킷 분석기술만으로는 예방하고 차단할 수 없음이 자명하다.

여러 금융기관과 대기업의 정보보호조직이 시스템과 네트워크 운용조직에 이리치이고 저리치이면서 제대로 된 기술적 보호대책을 구현하지 못하고 물리적 출입통제에 사운을 건 듯 매달리는 이유다.

정보보호전문가를 꿈꾸는 젊은이라면 "C, Java, Web은 물론 서버 및 데스크탑 운영체제, 데이터베이스, 네트워크 프로토콜, PKI 등 기반 기술은 물론 다양한 시스템소프트웨어까지 닥치는 대로" 공부해야 한다. 정보보호전문가는 IT분야 종사자의 최초의 직업이 아니라 최후의 직업이 되어야 제대로 일할 수 있다.

Unix 서버와 Linux 서버 그리고 Windows 서버 운영체제는...사실 운영체제 그 자체가 취약점 덩어리라고 할 수 있다. 하지만 대부분 운영체제 자체의 취약성은 운영체제의 필요불가피성에 뭍혀버리고 서버 외부에서 서버 내부로의 침투를 차단하는데 온갖 보안 솔루션을 동원하여 방어하고 있다.

그러나...

최근 몇년 사이에 그러한 인식은 많이 바뀌어 가고 있음을 서버보안SW를 다루면서 느낄 수 있다. 

내부망/내부자에 의해 서버 운영체제의 취약점 공격은 너무도 쉽다는 것이 농협사고와 카드3사 사고 등 초 대형 사고와 함께 알려지기 시작했고 네트워크 보안으로는 방어하기 힘든 APT 기법에 의한 해킹이 빈발하면서 서버 내부에서의 통제 강화 필요성이 대두되고 있다.

이번 포스트에서는 방화벽을 우회하여 서버에 침투할 수 있는 Revers Telnet 백도어에 대해 정리하고 방어 정책에 대해 서술한다.

Reverse Telnet의 개념

리버스텔넷에는 서버와 클라이언트에 netcat 이라는 도구가 활용된다. 그리고 특징적인 것은 일반적인 Telnet, SSH와는 정 반대의 접속 방식이 사용된다는 점이다.

일반적으로 Telnet은 다음과 같은 절차에 의해 접속이 된다.

위와 같이 일반적인 Telnet, SSH 접속을 통제하기 위해서는 사용자와 서버의 중간에 방화벽을 두어 접속을 허가할 IP만 열어주고 나머지 IP는 접속을 차단한다. 

하지만 위의 과정과 달리 사용자의 PC측에서 기다리고(Listen) 서버에서 사용자 PC측에 접속(connect)한 뒤 쉘을 연결해주는 방식을 사용할 수 있다면 방화벽을 우회할 수 있다. 즉 텔넷 클라이언트 프로그램을 서버로 만들고 텔넷 서버를 클라이언트로 만들어 접속을 하는 (역-텔넷)방식이라고 생각하면 된다. 이 기법을 사용하는 백도어가 바로 리버스텔넷(Reverse Telnet)이다.

리버스 텔넷의 개념도를 보면 다음과 같다.

리버스 텔넷의 과정

리버스 텔넷을 위해서는 공격자의 PC에 netcat 이라는 도구가 필요하다. 넷캣을 PC에 설치한 뒤 다음과 같이 실행해준다.

nc.exe가 netcat 이다. 포트를 1234로 지정한 뒤 위와 같이 실행하면 nc는 서버에 설치된 리버스텔넷 클라이언트의 접속을 기다린다.

다음은 서버에 설치된 리버스텔넷 클라이언트를 실행한다. 앞에서도 이야기 했듯 리버스 텔넷은 일반 텔넷/SSH와는 반대의 개념이다. 클라이언트가 서버에 접속하는 방식이 아니라 서버가 클라이언트에 접속하는 방식이다.

위 화면에서 실행한 리버스텔넷 클라이언트는 펄(Perl)로 만들어진 정교한 클라이언트다. 이 펄로된 소스를 살펴보면 아래와 같이 exec()함수를 이용해 /bin/sh 를 실행하는 것을 볼 수 있다. 또한 서버 운영자와 관리자를 속이기 위해 프로세스 이름도 변경하는 것을 알 수 있다.

이 리버스 텔넷 클라이언트를 실행하면 PC에서 nc 를 실행한 뒤 대기상태 였던 창에 프롬프트가 보이는 것을 확인할 수 있다.

이때부터 서버는 해커의 손아귀에서 놀아나가 된다. 접속 과정에 ID도, 비밀번호도 묻지 않는다. 리버스 텔넷 클라이언트를 실행시킨 사용자 계정의 권한을 인증과정 없이 얻게 된다는 것을 확인할 수 있다.

리버스 텔넷의 차단

현재까지 리버스 텔넷을 서버 수준에서 차단할 수 있는 보안 솔루션은 RedCastle과 같은 SecureOS가 유일하다. 만약 방화벽을 통해 차단하기를 원한다면 내부망에 서버와 사용자의 사이에 방화벽을 설치하고 사용자 PC의 입장에서 인바운드 방화벽 정책을 수립해야 한다. 하지만 인바운드 정책을 적용하는 것은 그리 쉬운일이 아니다. 

하지만 레드캐슬을 통해 서버에 리버스 텔넷을 이용한 백도어를 설치한 뒤 접속하는 행위를 통제하기 위해서는 /bin/sh, /bin/ksh, /bin/csh, /bin/bash 등 운영체제에 존재하는 모든 Shell 파일에 대한 접근을 모니터링하여 모니터링 된 프로세스(명령어) 이외에는 접근을 차단하도록 정책을 적용하면 리버스 텔넷으로 인한 불법적인 서버 시스템의 접근을 쉽게 차단할 수 있다.

이 리버스 텔넷은 특별히 어려운 도구 없이 서버에 백도어를 심어놓을 수 있는 매우 쉬운 방법이다. 서버의 크론탭이나 부팅 스크립트 혹은 서비스를 구동/중지하는 스크립트에 몇라인만 숨겨 놓으면... 두고 두고 백도어로 사용할 수 있다. 

IT 운영 부서나 개발 부서의 내부자는...마음만 먹으면 언제든 리버스 텔넷을 응용한 백도어를 서버에 심어두고 패스워드 없이 시스템에 로그인할 수 있는 것이다.

명령어 실행 및 파일 접근 통제

정보보안이라고 하면 흔히 악성코드나 모의해킹 그리고 취약성 분석 등을 떠올리기 마련이지만..사실상 해커들이 그러한 공격기법들을 통해 얻으려 하는 것은 매우 단순하다. 

바로 "정보"다.

그리고 해커들이 원하는 정보는 99%가 "파일" 혹은 "데이터베이스"에 저장되어 있기 마련이다. 그렇다면 이 "정보"를 획득하기 위해 사용되는 "명령어" 또는 정보가 담겨있는 "파일"에 대한 접근(실행/읽기)을 완벽하게 통제하면 모든 것은 해결된다. 해커들은 "정보"를 획득하는데 사용되는 "파일"이나 "명령어"를 실행할 권한을 얻기 위해 그 생쑈~를 하는 것이다.

벌써 많은 사람들의 기억에서 잊혀져가고 있는 농협의 200대가 넘는 서버 해킹사고와 다수의 카드사에서 발생한 엄청난 양의 금융정보 유출 사고가 대표적인 서버 보안 사고다. 그리고 그 두 사고의 핵심 이슈는 "내부자에 의한 명령어 실행 통제"와 "데이터 파일 접근 통제"다.

하지만 그러한 사고가 발생한지 수 년이 지났지만 아직도 우리나라의 정보보호 수준은 "네트워크에서의 접근통제"와 같이 정보에 접근하는 길목을 지키는 네트워크 보안과 PC를 장악하기 위해 전파되는 악성코드 분석에 포커스가 맞춰져 있다. 그나마 변화한 것은 금융감독원의 IT금융감독규정에 "운영체제 계정으로 접속 시 2차 인증 의무화" 와 같이 이제 서버 운영체제에 대한 보안에 관심을 갖는 정도다. 그리고 그 조차도 아직 제대로 구현되지 않은 금융기관이 태반인 것이 현실이다.

그리고 더 나아가 서버 내 운영체제 및 데이터베이스 그리고 애플리케이션의 중요한(위험하다고 표현할 수 있는) "명령어"의 실행에 대한 통제는 꿈도 못꾸고 있는 것이 현실이다. 하지만 보안사고가 발생할 경우 최종적으로 정보유출 및 피해를 발생시키는 취약점은 바로 "서버 내의 명령어와 파일"의 존재다.

그래서 서버 내의 명령어와 파일에 대한 접근 통제는 보안의 최후 방어선 이라고 할 수 있다.

서버 로그인 시 이중 인증(2차 인증)

일부 금융기관과 공공기관은 서버에 운영체제의 계정으로 접속할 때 2차 인증을 구현하고 있다. 아래 화면처럼 운영체제의 ID와 패스워드 인증을 완료하면 2차 인증을 위한 접속자의 사용자 정보와 OTP 번호를 입력하는 것과 같이 2차 인증을 수행한다.

OTP를 통한 2차 인증(이중인증)

하지만 대부분의 2차 인증 솔루션들은 여기까지가 한계다. 사실 Unix(HPUX, Solaris, AIX)와 Linux 그리고 Windows 운영체제 수준에서 2차 인증을 지원해주는 솔루션은 몇개 되지 않는다. 대부분은 서버팜의 앞단에 게이트웨이를 두고 게이트웨이에 접속할 때 2차 인증을 해준 뒤 실제 서버에 로그인할 때는 2차 인증을 해주지 못하는 솔루션이 태반이다. 당연히 우회 접속의 길이 열려 있어 보안에 취약할 수 밖에 없다.

그리고 대부분의 2차 인증 솔루션은 단순히 인가된 OTP 기기를 사용하면 실사용자가 누구든 관계 없이 OTP기기와 OTP번호만 확인하고 서버에 접속을 허가한다. 하지만 OTP기기를 빌려주거나 분실하였을 때 다른 사용자의 OTP 기기를 사용지 못하도록 통제할 필요가 있다.

2차 인증 기반 명령어 통제

그렇다면 2차 인증을 받고 서버에 접속한 사용자는 신뢰할 수 있는가? 농협사태와 카드사 사고는 "단순한 2차 인증 만으로는 부족하다"는 것을 시사한다. 서버에 접속할 권한을 부여받은 사용자라 할지라도 서버에 접속한 뒤 특정 명령어를 사용하기 위해서는 추가적인 "허가" 절차가 구현되어야 한다.

명령어 사용에 대한 추가적인 "허가" 절차가 실시간이든 아니면 사전에 "작업 신청"을 통해 사용할 명령어에 대한 사용 신청을 하고 "결재(승인)"을 받아야하든 어떤 방식으로든 구현되어야 하는 것이다.

최종적으로 2차 인증 기반 명령어 통제 시스템은 다음과 같이 구현될 수 있다.

2차 인증(실사용자 기반) 명령어 통제 시스템

그리고 위의 2차 인증 기반 명령어 통제 시스템은 다음과 같은 절차에 의해 통제가 이루어진다. 당연히 작업 신청에 의해 사용되어야 하는 명령어나 파일은 서버보안SW에 의해 실행이나 접근이 통제되고 있어 운영자나 개발자 그리고 외부 엔지니어가 서버에 접속해도 실행이나 수정/삭제가 불가능한 상태다.

1. 작업자의 명령어 사용 신청 (작업 신청)
2. 승인자의 작업 승인
3. 작업 시작 시간에 명령어 통제 정책 스케줄링을 통한 권한 부여
4. 작업 시작 시간에 작업자의 2차 인증을 통한 서버 접속
5. 2차 인증 수행
6. 명령어 사용 및 파일 접근(생성/수정/삭제 등)
7. 작업 종료 시간에 권한 회수

REDBC의 AuthCastle과 RedCastle

레드비씨의 서버보안 솔루션은 명령어 사용과 중요 파일들에 대한 접근을 통제하는 현존하는 가장 강력한 보안 솔루션이다. 서버 내의 자원은 특성상 네트워크 수준에서는 통제 불가능하다. 클라이언트의 키보드 입력 가로채기, 패킷 스니핑의 방법으로는 너무도 다양한 파일이나 명령어에 대한 접근 기법을 모두 통제할 수 없다. 
오로지 운영체제의 커널에서 동작하는 참조모니터 만이 가장 확실한 통제 수단을 제공해 준다. 
레드비씨는 2차 인증 솔루션인 AuthCastle과 서버내의 자원에 대한 현존하는 가장 완벽한 접근통제를 가능하게 해주는 RedCastle을 통해 단순한 명령어 및 파일 접근 통제는 물론 2차 인증과 연동한 실사용자 기반의 명령어 통제 및 파일 접근통제를 지원하며 워크플로(결재 절차) 지원을 통해 서버에서의 작업관리와 작업 승인에 기반한 명령어 실행 권한 자동 부여 및 권한 회수를 지원하는 서버보안 솔루션을 제공하는 국내 유일의 보안 솔루션 기업이다.

클리앙의 랜섬웨어 유포 사고

4월의 하순으로 접어드는 어느 날... 국내에서 꽤나 큰 커뮤니티인 클리앙에서 접속자들의 PC에 랜섬웨어가 유포되는 해킹사고가 발생했습니다. 랜섬웨어는 커뮤니티의 웹서버 중 하나를 해킹하여 소스를 수정하는 "웹서버 소스 파일 위변조 공격"으로 커뮤니티에 접속한 사용자 PC에 해커들이 미리 준비해 둔 다른 웹서버에서 랜섬웨어를 다운로드 받도록 하는 "드라이브 바이 다운로드(Drive By Download)" 기법으로 유포되었습니다.

커뮤니티 웹서버에 접속하여 PC로 다운로드 된 악성코드는 어도비(Adobe)의 swf 파일을 로드하여 실행할 수 있는 취약점인 CVE-2015-0311 취약점을 이용하여 swf (어도비 플래시파일)로 배포되어 인터넷익스플로러를 통해 실행되는 형태로 만들어져 있습니다. (출처 : Wins의 분석보고서 참조)  

가상머신을 이용한 탐지 시스템 무력화 기법 사용

Wins의 분석보고서를 보면서 특기할 만한 점을 발견하였는데...악성코드의 소스에 말로만 듣던 가상머신을 이용하는 샌드박스 기법의 악성코드 탐지를 무력화하는 코드가 들어있다는 점이었습니다.이번에 배포된 크립토라커(CryptoLocker)는 PC에 다운로드되어 실행될 때 자신이 실행되는 PC의 환경이 가상머신인지 아닌지를 확인하는 코드를 포함하고 있습니다. 이는 해커들도 나름대로 최신 보안솔루션에 대해 대응하고 있다는 것을 뜻하며 근본적인 대응책을 마련하지 않는 이상 PC를 대상으로 하는 악성코드의 배포를 차단하는 것은 불가능하다는 의미를 갖고 있습니다. 

저도 최근에 제가 근무하는 회사의 본부장님 PC를 점검해드리면서 감염된 트로이목마가 -네이버에서의 백신SW 다운로드 차단, -설치되어 있는 V3와 같은 백신의 엔진 업데이트 차단과 같이 백신을 무력화하는 기법을 구현한 것을 확인하였습니다.

커뮤니티의 광고서버가 랜섬웨어 유포지로 이용된 이유

이번 클리앙 사고를 비롯해 신문사 웹사이트나 포털 그리고 쇼핑몰 등 많은 보안사고에서 악성코드 유포지로 이용될 가능성이 높은 서버 중 하나가 바로 광고서버입니다. 클리앙의 이번사건의 경우도 공지를 보면(지금은 내려갔지만) 광고서버의 소스파일이 변조되어 악성코드를 유포했다는 내용이 있었습니다.

이렇게 광고서버가 악용되는 이유는 매우 단순합니다. 광고는 커뮤니티의 어느 페이지를 가더라도 웹브라우저에 보인다는 점입니다. 즉 모든 접속자가 무조건 한번이상 악성코드를 다운로드 받게 된다는 것이죠. 그래서 웹서버와 함께 광고서버의 소스 보호를 위한 서버보안 구현이 중요한 것입니다.

피해상황

이번에 클리앙에서 유포된 랜섬웨어는 CryptoLocker(크립토락커)라는 랜섬웨어 입니다. 이 크립토락커에 감염되면 문서파일, 이미지파일 등을 위주로 파일을 암호화합니다. 그리고 다음과 같은 화면을 보여줍니다.

무척 서툰 한글이기는 하지만 분명히 한국의 네티즌을 타겟을 했다는 것을 알 수 있습니다. 비트코인과 같은 가상화폐 또는 현금을 입금하라고 합니다. 그래야만 암호화된 파일을 복원해주겠다고 협박합니다. 어떤 분은 실제로 돈을 입금하고 복호화 키를 받아 문서와 이미지들을 복원했다는 분도 있습니다. 실제인지는 알 수 없으나 대부분 해커가 요구하는 돈을 입금해도 복원이 안되는 경우가 더 많다고 합니다.

클리앙에서 랜섬웨어가 배포된 뒤 많은 피해를 호소하는 글들이 클리앙의 게시판을 뒤덮기 시작했습니다. 제가 거의 매일 한번씩은 방문하여 글을 읽기에 수백건의 (제가 본것만) 피해글을 볼 수 있었는데... 몇년간의 자료(업무에 사용하는)가 암호화되어 복구가 불가능하다는 글을 비롯해 매우 심각한 피해를 호소하는 내용도 많았습니다. 대부분의 사람들은 파일을 복원하지 못하는 것이 현실입니다.

문제점과 대응방안

사실 네티즌 입장에서는 적극적인 대응은 불가능합니다. 웹브라우저를 사용하지 않을 수는 없으니까요.. 기껏해야 백신을 설치하고 매일 업데이트하며 웹브라우저와 어도비의 애플리케이션을 최대한 자주 업데이트하는 방법 밖에는 없습니다.

하지만 그런 방안도 제로데이 취약점을 공격하는 악성코드에는 무용지물이라는 점이 문제입니다. 해커가 제로데이 취약점을 이용해 이번과 같은 랜섬웨어를 유포하는 공격을 감행하면 네티즌의 입장에서 현재로서는 막을 방법이 없습니다.

유일한 보안 대책은 웹서버와 광고서버 등 해커들이 악성코드를 유포시키는데 악용하는 서버의 보안을 강화하는 것입니다. 클리앙의 웹서버는 대형 IDC에 위치하고 있을 것이고 IDC에서 기본적인 Firewall이나 침임탐지 및 차단 시스템을 운영하고 있을 것입니다. 하지만 네트워크 수준에서 동작하는 보안 장비로 웹 해킹을 방어하기에는 역부족이기 때문에 해커의 해킹시도에 뚫렸고 소스파일이 변조되어 Drive By Download 형태로 커뮤니티의 웹서버에 접속한 사용자의 PC에 악성코드와 랜섬웨어를 배포하는데 악용될 수 밖에 없었을 것입니다.

이러한 공격을 방어할 수 있는 유일한 방법은 웹서버와 광고서버를 운영하는 주체가 서버 운영체제의 커널 수준에서 파일의 변조를 통제하여 웹 소스파일과 광고 소스파일에 대한 위변조를 실시간으로 차단하는 방법 밖에는 없습니다. 대부분의 웹서버와 광고서버는 Windows Server 운영체체 또는 Linux Server 운영체제 그리고 HPUX, AIX와 같은 서버 용 운영체제를 사용합니다. 그렇기 때문에 운영체제의 커널 수준에서 웹 소스파일과 광고 소스파일의 생성과 수정 권한을 통제하면 이번과 같은 웹 해킹을 통한 악성코드 유포를 차단할 수 있습니다. 해커가 웹 소스파일을 변조하기 위해 웹서버의 취약점을 공격해 파일의 수정 권한을 얻더라도 사전에 허가되지 않은 경로를 통한 소스 파일의 수정을 차단할 수 있습니다.

최근에 웹 소스의 위변조를 차단하는 솔루션들이 여럿 출시되고 판매되고 있지만 대부분 주기적으로 소스파일의 무결성을 검사하여 변조가 확인되면 별도로 보관하고 있던 파일로 다시 복구하는 형태가 주를 이루고 있습니다. 하지만 이런 형태의 방어는 제대로 된 방어라 볼 수 없습니다. 게다가 언제, 누가, 어떤 경로를 통해 변조를 시도했는지 확인할 수 없는 "사후 조치" 수준을 벗어날 수 없습니다.

RedCastle을 통한 웹 소스의 위변조를 실시간으로 차단하는 방안이 가장 효과적인 대응방안인 이유입니다.

웹 서버를 통해 악성코드가 악성코드가 네티즌의 PC로 유포되었는데... 정작 책임을 져야할 서버 측에서는 대응을 제대로 하지 않고 피해자인 네티즌 PC의 보안 패치 업데이트 타령만 하는 것은 너무 무책임한 것은 아닌지 생각해 봐야하지 않을까 싶습니다.

보안 운영체제라 부르는 Secure-OS를 이용한 서버의 보안 강화와 관련된 이슈는 아직까지 보안 시장에 무르익지 않고 있습니다. 하지만 2011년 농협 보안사고와 다수의카드사 개인정보 유출 사고에서와 같이 대형 보안 사고는 대부분 "서버 운영체제에 개발자 혹은 관리자 권한"으로 접속한 내부 사용자 권한을 가진 사람들에 의해 발생하고 있기 때문에 실제 정보가 저장되고 가공되며 서비스 되고 있는 서버 내부에서의 위협에 대한 통제 방법론에 대한 이슈는 분명 지속적으로 이슈가 제기될 것입니다.

서버 내부의 개발자와 관리자에 대한 행위 통제는 불가능 한가?

당연히 가능합니다. 

하지만 많은 IT 종사자는 물론 보안 전문가들도 IBM, HP, Oracle(구 Sun Microsystems)와 같은 상용 유닉스 운영체제와 리눅스 운영체제 그리고 MS의 Windows 운영체제 내의 해킹에 악용되는 중요한 관리자 명령어와 자체 취약점에 대해 "어떻게 통제할 것인가"에 대한 통제 방법을 알지 못하고 있습니다. 

그 이유는 엄청난 양의 정보가 실제로 저장되고 처리되는 서버 운영체제에 대한 지식과 그 서버 운영체제 상에서 실행되고 서비스 되는 데이터베이스관리시스템(DBMS) 그리고 미들웨어, 웹서버 등의 "서비스" 애플리케이션의 상호 연동에 대해 제대로 이해하고 SecureOS를 통해 보호정책을 수립하고 적용할 능력을 갖고 있지 못하기 때문입니다. 게다가 네트워크 보안과는 달리 "보호정책"을 적용할 경우 즉각적으로 "서비스 개발과 운영 및 관리의 불편함이 높아진다고 생각하기 때문에 서버 내부의 보안을 강화할 엄두를 내지 못하고 있는 형편입니다. 

서버 내부의 보안을 강화해야 한다는 것에는 동의하지만 어떤 보안솔루션을 도입하고 "보호 정책"을 실제로 어떻게 적용해야할지를 알지 못하고 있는 것입니다.

서버 내부의 파일과 명령어를 해킹으로부터 보호하기 위해서는 어떤 솔루션이 필요한가 ?

네트워크에 추가되는 장비(어플라이언스) 형태의 보안장비로는 서버 내부의 파일과 명령어을 해커의 위협으로 부터 보호할 수 없습니다. 윈도서버에서 자주 발생하는 악성코드 "파일"의 감염은 서버백신이나 서버 앞단에 설치된 침입차단 시스템이 제역할을 하지 못하기 때문에 불법적인 파일의 "생성"을 차단하지 못하는 것을 반증합니다.

웹의 취약점 공격을 받아 웹쉘이 업로드 되거나 소스파일이 변조되어 java script 공격코드가 삽입되며 인젝션 공격을 받아 해커가 서버에 공격파일을 업로드하고 실행할 수 있는 것 또한 침입차단 시스템이나 웹방화벽이 제 역할을 수행하지 못하기 때문입니다.

종종 홈페이지가 변조되어 백방으로 수소문한 끝에 RedCastle을 도입하거나 타 보안 제품을 운용하다가 파일에 대한 접근통제 정책을 제대로 구현하지 못해 RedCastle의 설치를 요청하는 경우를 볼 수 있습니다. 이런 경우 도입하려는 솔루션이 다음의 조건을 충족하는지 검토하여야 합니다

서버 내의 파일과 명령어에 대한 생성/수정/삭제/실행을 통제하고자 할 때 검토 사항

명령어 통제 및 파일 접근 통제의 핵심 기술 - 참조모니터(Reference Monitor)

서버보안SW(보안OS)는 커널 수준에서 동작하는 참조모니터로 구현되어야 합니다. 왜냐하면 파일에 대한 읽기/수정/생성/삭제/실행 등의 접근은 매우 다양한 방법에 의해 이루어지며 우회 접근도 가능하기 때문에 모든 파일에 대한 접근이 실제로 이루어지는 시스템콜 수준에서 통제하지 않을 경우 제대로 된 파일접근통제, 명령어 실행 통제가 이루어질 수 없기 때문입니다.

명령어의 실행과 파일의 생성/읽기/수정/실행/삭제에 대한 통제를 가능하게 하는 운영체제 커널 수준에서의 참조모니터는 국내 위키에서 찾아 볼 수 없을 만큼 정보가 부족합니다. (영문 위키 : 참조모니터(Reference Monitor) 

참조 모니터의 역할은 그 이름에서도 알 수 있듯이 객체(파일, 프로세스, 계정 등의 자원)에 주체(프로세스(명령어 포함), 계정)가 접근(읽기/쓰기/실행/수정/삭제 등등)할 때 발생하는 모든 시스템콜(이벤트) 및 행위를 모니터링 하는 것입니다. 여기서 "모든"이 중요합니다. "모든" 행위를 가로채 검사(Validation)하지 못하면 우회가 가능하게 되고 우회 경로가 결국 취약점이 될 수 있습니다.

다만 "모든" 이벤트를 가로채는 것은 결코 쉽지 않기 때문에 얼마나 많은 이벤트를 검사할 수 있느냐가 보안 솔루션의 능력을 가늠한다고 볼 수 있습니다. 그런면에서 알려진 "공격패턴"을 기반으로 알려진 공격 기법에 의한 침해만 방어하는 대부분의 보안 솔루션들은 사실.... 제대로 개발된 보안 솔루션이라 하기엔 부끄러운 것이 사실입니다. 

서버보안SW(보안OS)의 참조모니터에 대해서는 다음의 두 장의 그림으로 설명을 대체합니다. 글로 설명하자면 너무 길어지고 커널에 대한 제 지식이 많이 부족하기 때문에 그림으로 그 역할을 설명합니다.

1. 서버보안SW의 참조모니터(보안커널)가 운영체제 커널에 로딩되기 전의 Pure OS의 구조입니다.

2. 서버보안SW가 서버에 설치되어 참조모니터(보안커널)가 운영체제 커널에 로딩된 후의 OS 구조 입니다.

RedCastle은 서버 운영체의 커널 수준에서 동작하는 현존하는 가장 완벽한 참조모니터를 구현한 서버 보안 솔루션(SecureOS) 입니다.

최근 웹서버의 소스 변조 공격이 또 다시 붐~처럼 휘몰아 치고 있는 듯 하다. 

얼마 전 지속적인 웹 소스파일 변조 공격을 받고 있어 몇 주 째 사투(?)를 벌이고 있던 한 웹사이트 운영 업체의 요청으로 RedCastle SecureOS를 설치하고 해커와 한판 전쟁을 치르게 되었다. 이 해커는 다른 일반적인 소스 변조를 시도하는 사례와는 달리 한 두 가지의 공격을 차단되어도 포기하지 않고  계속 새로운 공격을 시도하고 있었다.

대부분의 경우는 웹 소스의 변조 시도가 차단되면 포기(?)하고 물러나는 것이 일반적인데 이 해커는 집요하게 새로운 공격을 감행하여 차단을 우회하려 시도하거나 운영체제의 파일들을 변조하려 하는 등 포기하지 않는 끈질김을 보여주었다.

2014년 11월의 어느 날...

급박한 요청을 받고 RedCastle을 설치한 뒤 Baseline Policy와 변조되는 소스파일에 대한 보호 정책을 적용하니 곧바로 다음과 같은 공격이 들어오는 것을 확인할 수 있었고 웹 소스파일 위변조 차단 정책에 의해 변조 공격은 차단되었다.

RedCastle을 설치하고 변조가 발생하는 경로의 파일들에 대해 위변조 차단정책과 웹서버 대몬의 운영체제 명령어 접근을 차단하는 정책을 적용하자 wscript.exe 프로세스가 cmd.exe를 실행하고 cmd.exe가 웹 소스파일을 변조하는 것을 알 수 있었다. 당연히 이 공격은 1차로 적용한 웹 소스파일 변조 차단 정책에 의해 차단되었다.

이후에도 위 감사로그 처럼 cmd.exe를 통해 계속 웹 소스파일 경로의 특정 파일을 변조하려 시도하고 있었다. 시도가 차단되니 1초에도 수십번씩 반복적으로 변조를 시도하고 있었다.

이러한 공격은 매우 흔한 경우로서 해커가 웹쉘을 업로드하는데 성공했거나 웹쉘처럼 운영체제의 명령어를 웹 인젝션 취약점을 통해 실행하여 관리자 권한을 탈취하는데 성공했다는 것을 의미한다.

그 후 보호정책이 걸려있지 않은 경로를 통해 우회 변조 및 새로운 파일들에 대한 변조가 발생하여 계속 보안 정책을 강화해야 했고 계속 소스 변조에 실패한 해커는 만 이틀이 안되어 사용자들에게 다운로드 되는 일부 프로그램을 변조하려 하는 새로운 시도가 있었다. 예전의 웹하드 업체의 다운로드 전용 프로그램을 변조하는 것과 같은 공격을 시도한 것이다.

위 화면은 뷰어 프로그램으로 보이는 접속자의 PC에 다운로드 되는 프로그램파일을 웹서버를 통해 변조하려 한 시도다. 주체 프로세스가 w3wp.exe (IIS 웹서비스 대몬)이고 변조 대상이 되는 객체 파일이 xlviewer.exe 라는 것을 알 수 있다.

해커는 이쯤에서 서버에 보호대책이 구현되어 있다는 것을 눈치 챘던 것으로 보인다. RedCastle의 파일들을 변조하고 매니저와 통신을 수행하는 프로세스를 강제로 종료시키기도 했다. 일반적으로 RedCastle의 존재를 알아차리는 해커는 없었다. 그런데 이번 해커는 조금 달랐다. 만만치 않은 친구(?)라는 것을 알 수 있었고 즉각적으로 RedCastle을 재설치하고 자체 보호 정책을 활성화 시켰다. 이후에도 RedCastle을 무력화 시키려 시도하였으나 차단되자 아래 처럼 다시 웹 소스파일과 설정파일을 변조하려 시도한다. 하지만 보호정책이 적용되어 있는 경로의 소스파일은 일반적인 방법으로는 수정이 불가능하다.

주체 프로세스는 역시 w3wp.exe 고 변조 대상 파일은 Web.config 파일이다. 이전엔 wscript.exe와 cmd.exe를 통해 변조를 시도했지만 실패하자 조금 다른 패턴을 통해 변조를 시도하였고 이 변조 공격 또한 차단되었다. 

웹 서버 소스에 대한 변조가 완벽하게 차단되자 해커는 다음 날 새로운 무기를 들고 나왔다. 다른 백도어와 악성코드 파일을 서버에 업로드하고 실행시키려 시도한 것이다.

iis6.txt 가 cmd.exe를 실행하려 시도하는데 경로가 RECYCLER 이다. 바로 휴지통이다. 휴지통은 일반적으로 악성코드에 감염될 것이라고는 잘 생각하지 않는다. 하지만 해커들은 사람들이 잘 들여다 보지 않는 곳에 악성코드를 업로드하고 실행시키는 경우가 종종 있다. 아래 화면처럼 말이다. 휴지통에 선명하게 보이는 c.exe 파일. 바로 악성코드다.

다음과 같이 반복적으로 계속 실행을 시도한다.

c.exe 말고도 주체로 보이는 iis6.txt 가 cmd.exe를 실행시키는 것 뿐만아니라 c.exe 자체가 운영체제의 net.exe 명령을 실행하기도 한다. net.exe는 해커들이 시스템의 관리자 권한을 획득할 경우 즐겨 사용하는 명령 중 하나다.

휴지통에 업로드하고 위 화면에서와 같이 실행을 시도한 파일들..

앞에서 봤던 iis6.txt 파일도 보인다.

Virustotal 사이트에서 확인하자 c.exe가 악성코드로 탐지된다. 안타깝게도 ALYac 에서는 아직 악성코드로 탐지해 내지 못한다. 블랙리스트 방식의 보안 솔루션의 한계를 여실히 보여주는 대목이다.

이후에도 해커는 지속적으로 공격을 시도한다.

이젠 C:\Temp 폴더에도 c.gif 라는 파일을 업로드한 뒤 find.exe 명령을 실행한다. 그외에도 다양한 방법으로 cmd.exe를 실행하려 하거나 csc와 같은 컴파일러를 실행하려 하기도 한다. 당연히 이러한 Violation 로그를 발생시키며 차단된다.

이후에도 해커는 미련을 버리지 못하고 간간히 웹 소스의 변조를 시도한다. 웹의 취약점을 이용해 Web.config 파일을 계속 수정하려 시도한다. 하지만 변조는 RedCastle에 의해 차단되고 아래 처럼 감사로그가 기록된다.

해커는 이제 마지막으로 새로운 공격을 감행한다. 앞의 포스트에 올린 sethc.exe 취약점을 공격한 것이다. sethc.exe를 변조하고 sethc.exe를 통해 다른 파일을 실행하거나 파일을 수정/삭제하려 시도하였다.

이쯤에서 해커는 더 이상의 해킹이 어렵다고 판단했는지 더 이상의 공격을 하지는 않고 있다.

하지만 아쉬운 점은 많은 공격 사례가 그렇듯 해커가 어떻게 침투했는지 그 경로를 파악하지 못했다는 점이다. 워낙 소스파일 경로가 복잡하고 수 많은 파일들이 존재하긴 했지만 해당 웹사이트 운영자와 개발자는 해커가 어떤 취약점을 통해 침투했는지를 파악할 엄두를 내지 못하고 있었다. (사실 가장 중요한 것이 악용된 취약점을 찾는 것인데...)

자세한 결과는 알지 못하지만 다른 웹 쉘 탐지 솔루션과 보안 컨설팅 업체에 분석을 요구했으나 해커가 설치한 일부 변조된 운영체제의 백도어 파일(앞의 sethc.exe와 같은)을 찾아낸 것과 웹쉘로 의심(?)되는 파일을 찾아 지운 것 이외에는 만족할 만한 성과를 거두지는 못한 듯 하다. 

이렇게 해커가 공격에 활용하는 취약점을 찾아 수정하지 못한 채 취약점을 통한 다양한 공격을 실질적으로 방어할 수 있는 보안 솔루션은 RedCastle SecureOS 이외에는 없다. 취약점을 찾는 동안 쉼없이 변조되는 소스파일들을 변조될 때 마다 알럿을 발생시켜 복구하는 수동적인 방식으로는 대응이 불가능하다. 일단 RedCastle SecureOS로 변조를 최후단에서 차단하면서 취약점을 찾는 과정을 거치는 것이 정답이라 할 수 있겠다.

그나마 취약점을 찾지 못해 웹 소스파일 변조 공격과 공격도구의 업로드 및 실행이 지속되는 동안 RedCastle을 통해 방어할 수 있었고 그로 인해 해커가 공격을 멈춘 것에 만족해야 했다. 결국 그 고객사는 RedCastle을 도입했고 현재 스스로 운용 중이다. 이따금씩 정책 관련 문의가 오고는 있으나 현재는 공격이 들어오지는 않고 있는 듯 하다. 

하지만 공격이 들어오더라도 실시간으로 차단하고 감사로그를 실시간으로 보여주기에 예전 처럼 무방비 상태로 공격을 당하고만 있지는 않을 것이다.

윈도 운영체제는 태생적으로 갖고 있는 문제들로 인해 아직도 매우 취약한 운영체제로 분류됩니다. 현재 진행형인 보안사고 사례에서 재미있는(?) 윈도 운영체제의 취약성을 알게 되어 소개하고자 합니다. 윈도서버에 매우 손쉽게 백도어를 생성할 수 있는 방법 중 하나입니다.

유닉스나 리눅스가 갖고 있는 쉘카피백도어와 비슷한 백도어 생성기법 중 하나입니다. sethc.exe는 C:\Windows\system32 디렉토리에 있는 시스템 파일입니다.(이 파일의 용도 설명은 생략합니다.)  그리고 이 명령어는 Shift 키를 다섯번 연속으로 누르면 실행되는 다음 화면을 보여주는 명령어 입니다.

아마 많은 분들이 "아하~~이 화면..."이라고 생각하실 겁니다. 맞습니다. sethc.exe는 바로 이 화면을 보여주는 명령어 입니다. 그리고 아래 화면처럼 작업관리자에서 확인할 수 있습니다. 그런데 웃긴 것은 로그아웃 된 상태에서도 shift 키를 다섯 번 누르면 실행된다는 사실입니다.

해커들은 여기서 힌트를 얻은 것으로 보입니다. 만약 sethc.exe 파일을 삭제하고 cmd.exe를 복사하여 sethc.exe로 바꿔치기 하거나 해커들이 실행되기를 원하는 악성코드파일로 변조하면 어떨까?? 라는 생각을 하게 된 것입니다. 그리고 해커들은 더 나아가 sethc.exe가 shift 키 5회 연속 눌림이 아닌 다른 방법으로도 원격에서 호출할 수 있다는 것과 sethc.exe가 관리자 계정의 비밀번호를 변경할 수 있는 취약점이 있다는 것도 찾아냈습니다. (정말 존경스러울 만큼 대단한 열정을 갖고 있습니다.. -.-)

Windows 2003 서버는 물론이고 Windows7도 이 아이디어가 그대로 현실로 적용됩니다. Windows 2008 이상의 서버는 운영체제의 변조를 막아주긴 합니다만 관리자 권한을 얻으면 얼마든지 해제할 수 있기 때문에 실상 큰 도움은 되지 않습니다. 오늘 현재 해커의 공격을 받고 있는 서버도 이 sethc.exe가 변조된 것을 확인했으니까요.

그래서 위 화면을 캡쳐한 Windows 2008에서 테스트를 해봤습니다. sethc.exe를 다른이름으로 변경해놓고 cmd.exe를 sethc.exe로 복사하여 두고 로그오프된 상태에서 Shift 키를 5회 연속으로 눌러봤습니다. 로그인을 하지 않고도 cmd.exe를 호출할 수 있었습니다. 로그인하지 않은 채 cmd.exe를 사용할 수 있는 완벽한 백도어인 셈입니다.

이 취약점은 운영체제 파일들에 대한 변조(수정,삭제,생성,리네임)등을 관리자 권한으로도 하지 못하도록 통제하지 않으면 제거할 수 없는 매우 크리티컬한 취약점이라고 할 수 있습니다. 방법은 RedCastle과 같은 SecureOS를 통해 관리자 권한으로도 해제할 수 없는 운영체제 파일의 수정/변조 차단을 적용하는 것입니다.

아래 동영상을 확인하세요. 로그오프 상태에서 15초 지점에서 Shift키를 5회 연속으로 눌렀고 로그인 한 뒤 55초 지점에서 또 shift키를 5회 연속으로 눌러줬습니다. 두 번 모두 cmd.exe가 실행되는 것을 확인할 수 있습니다.

너무 쉽죠??? 그만큼 Windows 운영체제는 보안에 취약합니다. 위 화면에 표시된 대로 접근성 센터에 가서 이 기능을 꼭 꺼주시기 바랍니다. 

해킹 공격 중에 DOS(혹은 DDOS) 다음으로 많이 발생하는(어쩌면 반대일 수도) 공격이 바로 웹쉘을 통한 웹서버 공격입니다. 해커들이 웹서버를 공격할 때 가장 즐겨 사용하는 공격도구이자 취약점이 바로 웹쉘입니다.

웹쉘은 Unix/Linux는 물론 Windows 서버까지 운영체제를 가리지 않고 존재합니다. 또한 JSP, ASP 등 웹서버에서 구동되는 언어 또한 가라지 않고 다양한 웹쉘이 존재합니다. 게다가 파일탐색기, 파일업로드, 파일의 생성/수정/삭제는 물론 서버 내의 명령어 실행까지 가능한 토탈패키지 형태의 웹쉘도 존재하고 기존의 운영중인 웹페이지의 소스에 한 두줄을 추가(변조)하여 해커가 원하는 한 가지 기능만 수행하도록 하는 탐지가 거의 불가능한 웹쉘도 존재합니다.

하지만 웹쉘의 공통적인 기능은 "웹서버 대몬 서비스를 통해 서버내에서 명령(명령어 혹은 파일수정 등)을 실행한다"는 것입니다.

윈도 서버에서 동작하는 웹쉘을 하나 선정하여 살펴보도록 하겠습니다.

아래 화면은 해커에 의해 업로드 된 웹쉘을 웹브라우저에서 호출한 화면입니다.

이 웹쉘은 SQL인젝션, 파일업로드, 리버스텔넷, 탐색기 기능을 갖춘 토탈패키지형 웹쉘입니다. 물론 꽤나 오래된 웹쉘이라 일부 기능은 테스트한 윈도2008 서버에서는 동작하지 않는 기능도 있습니다만... 해커가 필요로 하는 명령어 실행 기능은 매우 잘 동작합니다.

웹쉘을 통해 서버의 IP 및 네트워크 정보를 확인하기 위해 ipconfig 명령을 실행한 화면입니다. 

웹쉘을 통해 서버내의 명령을 실행하는 것은 앞의 포스트에서 여러차례 언급했 듯 서버보안SW인 RedCastle을 통해 완벽하게 차단할 수 있습니다.

 (관련 글 목록 보기)   /  웹쉘을 통한 웹페이지 변조 및 차단 방안 보러가기

이 웹쉘이 어떻게 동작하는지는 위반로그(차단로그)를 확인하면 알 수 있습니다.

웹쉘이 RedCastle의 정책에 의해 차단되면 "Execute violation" 위반이 발생합니다. 누군가가 cmd.exe를 실행한 것입니다.

아랫부분의 주체정보의 프로세스를 보면 "w3wp.exe"가 주체이고 객체정보의 프로세스는 "cmd.exe"인 것을 알 수 있습니다. 즉 w3wp.exe(IIS웹서버 대몬)가 cmd.exe를 실행한 것입니다. 아마도 이 웹쉘은 아래 화면처럼 cmd.exe에게 ipconfig.exe를 실행하도록 할 것입니다.

대부분의 웹쉘은 위 화면과 같이 cmd.exe 명령어 뒤에 /C와 같은 옵션을 주고 최종적으로 실행할 명령어를 포함하는 명령문을 만들어 웹서버(w3wp.exe)를 통해 실행합니다. 때문에 IIS 웹서버 대몬인 w3wp.exe가 cmd.exe를 읽거나 실행하지 못하도록 하면 웹서버에 업로드 된 웹쉘이 운영체제의 명령어를 실행하는 것을 완벽하게 차단할 수 있습니다.

이 웹쉘의 소스를 살펴보면 아래와 같이 cmd.exe에 실행할 명령을 조합하여 전달하는 것을 알 수 있습니다.

이 웹쉘에서는 CMD라는 wscript 객체를 만들고 run이라는 메소드를 이용해 실행할 명령을 전달하였지만 이외에도 웹서버 대몬을 통해 명령어를 실행하는 방법은 매우 다양하기 때문에 네트워크 수준에서 HTTP 프로토콜을 통해 웹브라우저와 웹서버간에 오가는 웹쉘의 트래픽을 분석하여 차단하는 것은 현실적으로 거의 불가능합니다.

그렇기 때문에 웹쉘을 효과적으로 차단하기 위해서는 서버내에서 웹서버 대몬이 운영체제의 영역에 접근하는 것을 차단하는 것이 가장 확실한 방법입니다.

얼마 전에 리눅스 운영체제의 기본적인 쉘(shell)인 bash의 취약점이 발견되어 인터넷을 통해 널리 알려졌습니다.

하지만 이번에 발표된 취약점의 특징은 하트블리드 취약점과는 달리 네트워크 프로토콜의 결함이 아닌 리눅스에서 가장 널리 사용되는 쉘(shell)인 bash (bourne-again shell)의 취약점입니다

저는 처음에 자세한 내용이 아닌 트위터나 페이스북에 올린 한두 줄의  bash 취약점 소식을 듣고... "쉘이 원래 명령어를 실행하기 위한 도구인데...버그일 수는 있지만 취약점일까??" 싶었습니다. 한동안 이리저리 신경 쓸 일이 많아 오늘에야 자세한 내용을 살펴보니 참 황당한 bash의 버그였고 해킹에 악용된다면 웹쉘이 업로드된 수준의 위험을 갖는 취약점이었습니다.

쉘이 어떤 것인지 궁금하신 분은 다음의 포스트를 참고하세요.

관련 포스트 : 쉘을 이해하자. http://blogger.pe.kr/300

하지만 자세한 내용을 살펴보니... RedCastle SecureOS를 이용해 기본적인 정책만 적용해 두었다면..적어도 웹서버와 같이 인터넷에 개방되어 있는 서버에서도 걱정하지 않아도 되는데...라는 생각이 들었습니다.

먼저 bash 취약점에 대해 간단히 설명하면....

인터넷에 이런 문장이 떠돕니다. 하지만 그 의미를 정확히 이해하고 있는 사람은 얼마나 될까 싶습니다. 

간단히 설명하면 먼저 bash에는 (환경)변수라는 것이 있습니다.프로그래밍에 기본적으로 등장하는 변수와 개념이 같다고 보면 됩니다. 하지만 bash에서는 그 활용도가 조금 더 넓습니다. bash에서는 환경변수에 값이 아닌 함수를 등록하고 bash -c  [변수명] 과 같은 방법으로 변수에 등록된 함수를 실행시킬 수 있습니다.

위의 문장은 변수에 함수를 등록하는 과정을 수행하는 것인데 조금 이해하기 쉽게 바꿔서 써보면 다음과 같이 쓸 수 있습니다.

위와 같이 풀어쓰면 한 줄로 쓴는 것보다 조금 이해하기 쉽습니다. 

C나 java 등의 언어로 코딩을 조금이라도 해본 엔지니어라면 함수안에서 실제 수행될 코드는 중괄호 사이 {  } 라는 것을 이해할 것입니다.그런데 함수의 정의가 끝난 뒤에 두 라인의 명령이 있습니다. 사실 이런 경우는 에러가 나면서 실행이 안되어야 합니다. 하지만 bash에서 함수를 실행하기 위해 파싱하는 과정에서 중괄호의 끝인 } 와 ' 사이에 있는 명령(echo)과 ' 뒤의 명령(bash -c)을 실행시켜버리는 버그가 있는 것입니다.

과연 이 버그를 해커들이 어떻게 활용할 수 있을까를 생각해보면 웹쉘처럼 악용할 수 있습니다. 운영중인 웹서버에서 bash에 접근할 수 있는 있는 취약점을 찾을 수 있다면 해커는 서버에서 Telnet, SSH로 접속한 것과 같이 웹서버가 실행중인 계정으로 자신이 원하는 명령어를 얼마든지 원격에서 실행할 수 있습니다. 궂이 웹쉘을 서버에 업로드 하고 그 경로를 찾는 과정을 거치지 않아도 웹쉘과 같은 효과를 얻을 수 있는 것이죠.

위의 명령을 조금...아주 조금만 바꿔보면 다음과 같이 패스워드 파일을 읽는 것도 가능합니다.못할게 없습니다. 심지어 서버에다 스크립트를 만들어 실행하거나 웹의 소스를 위변조하거나 서버를 다운시키는 공격도 가능합니다.

PS나 웹방화벽, 웹쉘차단 솔루션 등이 있더라도 웹서버에서 이번에 발표된 bash 취약점을 통해 운영체제의 명령어와 중요 설정파일 및 데이터 파일에 접근하지 못하게 방어하는 것은 현실적으로 불가능합니다. bash 자체를 패치하지 않는다면 말이죠.

하지만 정말 심각한 문제는 이 취약점에 원격에서 웹서버 혹은 기타 네트워크 기반의 서비스를 수행하는 애플리케이션을 통해 접근할 수 있을 때 발생합니다. 서버에 Telnet, SSH 접속한 것과 동일한 수준의 명령실행이 가능하니까요. 생각만 해도 끔직한 사고가 발생하게 됩니다.

하지만 제가 예전에 포스팅했던 "웹쉘(webshell)의 위험성과 서버보안SW(RedCastle SecureOS)를 이용한 차단방법"에서 언급된 보안 정책을 적용해두었다면 걱정하지 않아도 됩니다.

왜냐하면 이 bash 취약점을 악용하기 위해서는 웹서버 대몬(httpd, java, htmls 등)이 bash에 접근해야 하는데  RedCastle SecureOS가 보안정책에 따라 그 접근을 원천적으로 차단해주기 때문입니다.

IPS와 웹방화벽, 웹쉘차단 솔루션과 같이 보안정책이 아닌 블랙리스트 방식의 차단 룰에 의한 접근통제는 새로운 취약성에 적절하게 대응할 수 없기 때문에 취약점이 나오면 호들갑을 떨면서 새로운 패턴업데이트를 기다려야 합니다.

위의 테스트는 레드햇 엔터프라이즈 리눅스 6.4 에서 테스트했습니다. 이하 모든 리눅스에 bash 취약점이 있는 것이지요.

최근 "302 리다이렉션 공격"이라는 해킹이 유행하고 있는 듯 합니다. 마치 새로운 대단한 공격 기법인 것처럼 호들갑을 떨지만 이것은 새로운 공격 기법은 아닙니다. 홈페이지를 변조하거나 웹 브라우저가 요청한 웹페이지에 대해 특정 자바스크립트 코드를 삽입하여 클라이언트 PC의 웹 브라우저가 악성코드를 다운로드 받게 하는 하는 수많은 공격 기법과 전혀 다를 바가 없는 일반적인..흔하디 흔한 공격 기법 입니다.

다만 302 리다이렉션은 수많은 네트워크 보안솔루션들을 우회하기 위해 등장한 변종 기법이라는 점입니다. 홈페이지의 소스파일의 위/변조를 원천적으로 차단하면 보다 강력한 보안이 이루어질 텐데 네트워크 수준에서...또는 웹 서버의 설정을 변경하여 외부URL을 포함하거나 외부 서버에 있는 파일의 다운로드 링크의 동작을 차단하다 보니 해커들이 이젠 아예 접속한 클라이언트 PC의 브라우저를 다른 웹페이지로 완전히 전환(리다이렉션 : Redirection) 시켜버리기 시작한 것입니다.

이전과 같이 클라이언트 PC를 악성코드에 감염시키기 위한 공격의 과정에서 웹서버의 소스파일을 변조하는 공격이 선행된다는 점에는 변함이 없습니다. 즉, 웹 소스 파일의 위/변조를 원천적으로 차단하지 않는 한 이러한 변형 공격 기법은 지속적으로 등장할 것입니다. (당연히 기본적으로 시큐어 코딩은 적용되어야 합니다.)

원리는 다음과 같습니다.

302 Redirection Attack

HTTP 프로토콜에서 지원하고 있는 응답코드 302가 브라우저의 주소를 다른 주소로 Redirect 하게 되는데 이 원리를 이용하여 악성코드를 다운로드 받는 URL로 강제로 전환 시켜 버리는 기법이 바로 302 리다이렉션 공격 입니다.

이 302 리다이렉션이 특별히 위험한 이유는 파밍 공격처럼 사용자가 자신이 실행하고 접속한 사이트를 보여주는 웹 브라우저가 다른 곳으로 전환(리다이렉션)되었다는 것을 전혀 인지하지 못할 수 있기 때문입니다. 이는 해커가 사용자가 접속한 웹페이지에 다음과 유사한 형태의 리다이렉션 코드(java script 혹은 meta 태그)를 추가(변조)하였기 때문입니다.

위에서 Location.href 를 지정하는 부분이 바로 302 리다이렉션을 유도하는 부분입니다. 해커가 원본 웹페이지 소스에 추가한 짧은 3줄의 Java Script 코드는 웹페이지에 숨어있다가 웹페이지에 접속한 사용자의 웹브라우저로 전달되고 웹 브라우저는 위의 Location.href 를 만나는 순간..... 사용자에게 "묻지도 따지지도 않고" 브라우저를 지정된 웹페이지로 이동(리다이렉션)시켜 버립니다.때문에 사용자는 그 사실을 모를 가능성이 높습니다.

이러한 302 리다이렉션을 사용자의 웹브라우저에서 막을 수 있는 방법은 현재로서는 없습니다. 가장 좋은 방법이 웹서버의 소스파일 위변조를 차단하는 것이며 웹 소스 변조를 통해 시도하는 302 리다이렉션과 다른 공격들을 원천적으로 방어할 수 있습니다. 그리고 시큐어코딩을 통해 웹페이지 소스 수준에서의 취약성을 제거한다면 대부분의 웹서버는 해킹으로부터 안전할 수 있습니다. 물론 DDOS와 같은 서비스 거부 공격은 예외겠지만 말입니다.

관련된 글 보기

웹서버 소스 위변조 방어를 위한 SecureOS 적용에 대한 포스트 보기

해커들이 해킹을 통해 침투하고자 하는 컴퓨터는 딱~ 두종류로 요약된다. 개인의 비밀스런 정보가 저장되어 있는 Windows 운영체제가 설치된 개인용 컴퓨터와 기업의 기밀정보(고객 개인정보 포함)가 저장되어 있는 서버다. 이 두 컴퓨터에 침입하기 위한 공격 기법은 이루 셀 수 없을 정도로 다양하다. 

그중에서 최근 해커들에게 각광받고 있는 공격기법이 바로 웹서버 해킹을 통해 웹페이지의 소스를 변조하여 공다팩(Gongda pack)이라 불리는 익스플로잇 공격도구를 개인용 컴퓨터에 감염시키는 해킹기법 이다.

공다팩이 무엇인지 살펴보면...

"Dadong" 이라는 독특한 스크립트 난독화된 익스플로잇 툴킷으로서 Windows 컴퓨터에 감염되어 Microsoft의 Windows, Office 등 제품의 취약점과 Acrobat, Flash 등 서드파티 애플리케이션의 취약점을 공격하거나 외부에서 공격도구를 다운로드하여 감염된 컴퓨터를 파괴하거나 해커가 제어할 수 있도록 하는 공격용 자바(Java)스크립트" 라고 정의할 수 있다. 

공다팩을 디코딩하여 Java Script를 확인해보면 "gongda"라는 이름의 변수를 많이 사용하기 때문에 Gongda pack 이라는 이름으로 불리는데 사용자 컴퓨터의 브라우저가 IE 인지 아닌지를 체크하며 버전에 따라 모바일 브라우저인지 PC용 브라우저인지까지 체크하여 세밀한 공격을 수행하기도 한다.

이 포스트에서는 공다팩이 웹 브라우저에서 어떻게 동작하는지는 설명하지 않는다. 이 포스트에서는 웹서버가 공다팩을 유포하도록 해킹이 되는 것을 막기 위한 방안을 제시하는 것이 목적이기 때문이다.

일부 웹방화벽이나 IPS 혹은 백신에서 현재까지 알려진 공다팩이 다운로드 되는 것을 차단해주기도 하지만 변형된 공다팩이 매우 다양하고 조금만 변형되어도 인지하지 못하는 경우가 많기 때문에 공다팩에 감염되는 개인용 컴퓨터가 있는 조직에서 근본적인 방어는 불가능하다. 

공다팩에 의한 피해를 줄이는 가장 좋은 대응책은 공다팩의 최대 유포 경로인 "웹서버"의 보안을 강화하는 것이다. 웹 서버를 운영하는 기업, 공공기관, 비영리단체 그리고 개인에게는 자신들의 서버가 해킹당해 악성코드를 유포하는 것을 예방해야할 책임이 있다. 그 책임을 기관이가 기업의 웹서버에 접속하는 개인에게 지우는 것은 너무도 무책임한 처사라 할 수 있다.

공다팩 스크립트의 구조와 동작방식 보러가기

● 공다팩(gongda pack) 유포의 가장 흔한 방법과 그 의미

공다팩은 대부분 해킹되어 변조된 웹서버에 의해 유포된다. 공다팩을 유포하는 웹서버의 해당 웹페이지에는 다음과 같이 dadong's 0.44 와 같은 난독화 도구를 통해 내용을 확인할 수 없도록 인코딩 되어 있다.

해커들은 위 화면과 같은 gongda pack을 웹페이지에 추가하기 위해 다양한 방법을 사용한다. 만약 당신의 웹서버의 특정 페이지의 소스에 gongda pack이 추가되어 있다면 해당 웹서버는 이미 사망선고를 받은 것과 같다. 외부의 해커가 웹서버의 소스파일을 마음대로 변조할 수 있다는 것은 이미 해커가 해당 웹서버를 완벽하게 점령한 것과 같기 때문이다.

해커들이 gongda pack을 웹서버를 통해 유포하고 있다면

• 웹서버 자체의 취약점 공격을 통한 관리자 권한 탈취
• Command Injection 취약성 공격을 통한 관리자 권한 탈취
• SQL Injection 취약성 공격을 통한 관리자 권한 탈취
• 업로드 취약성 공격을 통한 웹쉘 업로드를 통한 관리자 권한 탈취
• 게시판 등의 XSS, CSRF 취약성 공격을 통한 소스코드 삽입 공격

등 이미 다양한 취약성을 이용한 공격에 성공한 상태라는 의미가 된다. 이는 해당 웹서버에게 사망선고를 내리기에 충분한 사유다.

● 공다팩(gongda pack) 유포지로의 악용을 막기 위한 방안

냉정하게 이야기하면 네트워크에 기반한 보안 솔루션을 통해서 공다팩 유포를 차단할 수는 없다. 네트워크 보안 솔루션들은 대부분(90% 이상) 패킷을 분해하여 시그니처를 탐지하는 기법을 사용하는 제품이 대부분이다. 때문에 현재까지 알려진 시그니처가 아닌 변형된 공다팩이라면 탐지하지 못할 가능성이 매우 높다. 일부 시그니처 탐지 기법이 아닌 다른 기법을 사용하는 제품들이 있긴하지만 안정성이나 탐지의 정확성 측면에서 신뢰할 만한 제품은 없는 것이 현실이다.

가장 확실한 보호대책은 RedCastle과 같은 SecureOS 솔루션을 통해 웹서버의 소스파일에 대한 접근통제 정책을 적용하는 것이다. 

일부 서버에 적용하는 웹쉘 차단 솔루션이나 소스 위변조 방지 솔루션들이 있지만 RedCastle SecureOS에 비해 적용방법이 매우 복잡하고(소스를 수정해야 하는) 지속적인 유지 관리가 어려운 문제점이 있다.

RedCastle의 파일에 대한 접근통제정책은 운영체제의 커널의 System Call 수준에서 동작하기 때문에 네트워크 취약성이나 운영체제의 명령어 혹은 웹서버 대몬의 취약성과 소스파일의 취약성에 의한 변조시도도 완벽하게 차단할 수 있는 장점이 있다.

아래 포스트에서 그 내용을 확인할 수 있다.

관련 포스트

1. IIS 웹서버 해킹을 통한 악성코드 삽입 공격 방어 사례(소스 위변조 공격)

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

3. 웹쉘(webshell)의 위험성과 서버보안S/W(RedCastle SecureOS)를 이용한 차단 방법

해킹 여부 및 DDOS 공격 여부를 확인하기 위해 unix/linux 서버를 점검할 때 가장 먼저 살펴봐야할 것은 서버의 통신 상태다. 그리고 이때 사용하는 명령어는 netstat 명령이다. 만약 root권한의 탈취가 의심되고 운영체제 파일의 변조까지도 의심스럽다면 서버에 기본적으로 설치되어 있는 netstat 명령보다는 사고가 발생하지 않은 서버에서 netstat 명령어나 lsof 명령어 등을 업로드하여 사용하는 것이 좋겠다.

많은 엔지니어나 운영자들이 TCP 소켓의 상태 중에 3 way handshake 과정에 해당되는 LISTEN이나 SYN_SENT, SYN_RCVD, ESTABLISHED 등의 상태에 대해서는 잘 알고 있지만 FIN_WAIT1이나 FIN_WAIT2 등 통신 종료과정의 상태에 대해서는 어떤 의미인지를 잘 모르고 있는 경우가 많다.

TCP 통신의 종료과정은 일반적으로 4 way handshake라고 불리는 절차에 의해 진행된다. 일단 그 과정을 도식화 하면 다음과 같다.

이 4 way handshake 과정은 다음과 같이 진행된다.

이 4 way handshake 과정이 문제가 되는 경우가 종종 발생한다. 서버와 클라이언트의 통신에서 (이때 클라이언트는 대부분 PC가 아닌 Unix, linux 서버임) 클라이언트 쪽에 FIN_WAIT1, FIN_WAIT2 상태의 소켓이 급격하게 증가하여 소켓관련 메모리가 부족한 상황이 발생하고 더 이상의 소켓을 오픈하지 못하는 경우가 그것이다.(실제로 오래전 서버보안 프로젝트 수행 시 이 문제로 골치를 앓은 경우가 있어 확실하게 기억하고 공부를 하였음. -.-)

이러한 증상의 원인은 대부분 서버나 클라이언트 측 프로그램의 버그이거나 운영체제의 버그인 경우가 많은데 쉽게 원인을 찾지 못하는 경우가 많은 것 같다. 클라이언트에서 서버에게 FIN을 날려 통신을 끊고자 하면 서버가 ACK와 FIN을 순차적으로 클라이언트에게 보내야 하지만 어떤 이유인지 서버측에서 혼자만 소켓을 LAST_ACK나 CLOSED로 바꾸고 ACK와 FIN 전송을 모두 혹은 FIN의 전송을 하지 않는 경우로 보인다.

특히 이러한 경우가 네트워크 부하가 많은 서버에서 종종 발생하는데 세션의 확립과 종료가 대량으로 발생하는 경우가 대부분이다. 원인을 찾아 해결하면 좋겠으나 그 과정이 쉽지 않아 대부분 클라이언트 측에서 FIN_WAIT_1 상태에서 ACK를 기다리는 시간과(Timeout이 걸리면 강제로 닫음.) FIN_WAIT_2 상태에서 FIN을 기다리는 시간을 짧게 설정하여 서버로부터 정상적인 ACK와 FIN을 수신하지 못하면 강제로 소켓을 닫도록 하는 방법으로 문제를 해결하고 있다.

하지만 4 way handshake를 사용하는 한 대량의 빈번한 open과 close를 한다면 timeout의 조정만으로는 문제를 해결하지 못한다. 이때는 4 way가 아닌 3 way로의 변경을 고려해볼 필요가 있다. 4 way 종료에서 3 way 종료로 바꾸기 위해서는 close() 를 호출하는 클라이언트 측의 프로그램 소스를 변경하여야 한다. 이때 사용되는 옵션이 SO_LINGER 옵션이다. 하지만 여러 문제를 야기할 수도 있으므로 신중하게 결정해야 한다고...많은 개발자들이 이야기 하고 있다.

만약 이글을 읽는 이가 개발자라면 자세한 것은 개발자 포럼에서 SO_LINGER로 검색해봐야 할 것이다. (단, 리눅스만 이 옵션을 제공하는 것 같음..)

KT의 개인 정보 유출과 여러 신용 카드 사의 개인 정보 유출 등 끊임없이 발생하는 보안 사고는 기존의 보안 솔루션들이 보안 솔루션 답지 않게 보안 취약성을 제대로 제거해주지 못한다는 것을 의미한다.

특히 인터넷을 통한 서버로의 직접 침투는 많이 줄었지만 (사실 그리 줄지도 않았지만..발견되지 않거나 은폐될 뿐..) 정보가 저장되어 있는 서버에 접근 권한을 가진 내부 관리자 및 개발자 그리고 외주 인력에 의한 보안 사고는 오히려 더 늘고 있다. (신용카드 3사의 개인정보 대량 유출이 가장 대표적인 사례다.)

공공 기관과 기업의 전산실에서는 오래전부터 내부자의 서버 접근을 통제하기 위해 여러 방안들이 적용하고 있긴 하다. 하지만 그 내부 접근 통제의 개념과 적용 범위를 제대로 결정하지 못하고 있고 적용하고 있는 보호 대책들도 관리자 권한에서 우회나 변조가 가능하기도 하며 다수의 서버를 통합 관리하기가 쉽지 않기 때문에 보안 취약성 제거 효과를 보지는 못하고 있는 것이 현실이다.

이 포스트에서는 최근 내부 접근 권한을 가진 관리자나 개발자, 외부 엔지니어에 대한 접근 통제 및 감사 솔루션으로 각광 받기 시작한 2 Factor 인증 및 2 Channel 인증 기법에 대해 살펴보고자 한다.

2 Factor 인증과 2 Channel 인증의 차이

2 Factor 인증은 기존의 "지식기반 인증"인 ID/Password 인증에 다른 요소 즉 소유기반 인증 및 생체인증 요소를 추가한 인증 기법을 말한다.

2 Factor 인증기법을 인증 과정에 추가하면 ID/패스워드를 알고 접속하려는 사용자에게 OTP 인증 번호나 지문 등의 추가 인증을 요구함으로써 스니핑과 같은 ID/패스워드 유출에 의한 공격을 방어할 수 있다. 하지만 최근에는 APT 공격 등에 의해 단순한 2 Factor인증(이차 인증) 기법이 무력화 되는 경우가 발생하기도 한다.

특히 웹 서비스나 스마트폰 기반의 서비스는 이러한 단순한 이차인증(2 Factor 인증)만으로는 해킹을 방어하지 못하는 사례가 발생하기도 한다. 그 이유는 바로 메모리 해킹 때문이다. PC나 스마트폰에 설치된 악성코드가 사용자가 입력한 이차 인증 정보 혹은 인증 후 실 거래 발생 시 거래정보를 암호화하여 네트워크로 전송하기 직전에 거래 정보를 가로채 변조하는 고도의 프로그래밍 기술을 적용한 악성코드를 사용하기 때문이다.

그래서 등장한 개념이 바로 2 Channel 인증이다.

2 Channel 인증은 2 Factor 인증을 포함한다고 보는 것이 일반적이며 인증과 서비스를 수행하는 통신선로를 서비스 채널과 인증채널로 물리적으로 분리하는 것이 특징이다.

즉 서비스를 사용하는 PC/스마트폰의 통신 채널을 인증과 서비스에 모두 사용하는 것이 아니라 PC가 서비스 채널인 경우 ARS(전화) 혹은 스마트폰 앱 등을 통해 서비스를 사용하는 PC와는 물리적으로 다른 채널을 형성하여 2차 인증을 수행하는 것이다. 이렇게 서비스 채널과 인증 채널을 물리적으로 분리함으로써 해커에 의해 PC 혹은 스마트폰이 장악 되더라도 해커가 서비스에 접속을 할 수 없게 된다.

여기서 한걸음 더 나아간다면 금융거래나 구매 거래 시 관련 데이터를 2 채널 인증에 의해 확립된 2개의 채널로 분리하여 전송한 뒤 결제 시스템에서 조합하여 거래를 완성시키는 2 채널 서비스 구성도 검토해 볼 수 있겠다. 

SAC 솔루션의 2 Factor/Channel 인증 취약성

많은 보안 솔루션들 특히 서버 접근제어 솔루션(SAC)들이 2 팩터/2 채널 인증을 제공하고 있다. 하지만 네트워크 수준에서 2 Factor/Channel 인증을 수행할 경우 제대로 된 2 팩터/2 채널 인증을 수행할 수 없다.

위의 개념도에서 알 수 있듯 네트워크 수준에서 수행하는 서버 접근제어의 2차 인증은 사용자와 서버 접근 제어 장비까지의 구간만 2차 인증이 수행되고 실제 서버에 접근하는 접속 세션에서는 여전히 ID와 패스워드에 기반한 단순한 인증만이 수행된다.

게다가 비밀번호의 관리 편의성을 높이고 사용자가 서버의 계정에 대한 패스워드를 알지 못하게 하기 위해 서버접근제어 서버에 "복호화가 가능한" 형태로 모든 서버의 계정에 대한 비밀번호를 저장한다. 이는 "비밀번호는 복호화가 불가능한 형태로 암호화"해야 한다는 가장 기본적인 보안 규정을 어기는 중대한 보안 취약성이다. 개인정보보호법에는 사용자의 비밀번호는 복호화가 불가능한 단방향 암호화를 하도록 명시되어 있음을 유의해야 한다.

서버에 대한 2 factor 인증 및 2 channel 인증은 서버 운영체제의 자체 인증 과정에 추가하여 적용되어야만 우회 접속 및 여러 인증 취약성 공격 기법에서 자유로울 수 있다. 관리의 편의성 만을 생각한다면 모를까 제대로 된 서버 접근 통제를 하기 위해서는 필수적으로 운영체제에 추가적인 인증 모듈을 적용하여야 한다.

Unix/Linux의 경우 운영체제에서 PAM (plugable authentication module)이라는 2 factor/2 channel 인증을 적용할 수 있는 모듈을 제공하며 Windows의 경우도 GINA/CP라는 추가 인증을 적용할 수 있는 기능을 제공하고 있다. 그럼에도 불구하고 개발의 편의성, 관리의 편의성만을 쫓아 적용이 손쉬운 네트워크 기반의 2 factor/2 channel 인증기법을 적용하게 되면 관리 편의성은 증대될지 모르나 실질적인 보안 강화 효과는 그다지 기대하기 어렵다고 볼 수 있다.

또한 수 많은 서버와 네트워크 장비를 운용하며 패스워드 관리에 골치를 앓고 있는 기관과 기업의 어려움을 파고들어 제대로 된 보안 강화 솔루션이 아닌 보안 강화 효과도 별로 없는 솔루션을 공급하는 것은 상도덕에도 어긋난다고 할 수 있다.

사실 특정 보안 솔루션만으로 모든 보안 취약성을 커버할 수는 없는 것이 사실이다. 해킹은 지속적이고 지능적으로 변화하고 있으며 네트워크 기반의 보안 만으로는 더 이상 서버에 저장된 정보를 보호할 수 없다. 

개인정보를 비롯한 기관과 기업의 중요 데이터는 "서버"에 저장되어 있다. 서버의 보안을 강화하지 않고 길목인 네트워크에서 어떻게든 보안을 강화해보려는 구태의연한 보안은 이제 더 이상의 효과를 볼 수 없는 현실을 직시해야 한다. 아울러 외부로부터의 해킹이 아닌 내부 관리자/운영자/개발자들에 대한 통제를 빠르고 안정적인 "서비스 개발과 운영"을 핑계로 계속 미룰 경우 지금과 같은 해킹 대란은 계속 발생하고 보안 예산의 낭비는 계속될 수 밖에 없다.

유닉스/리눅스 운영체제는 태어난지 수십년이 지난 지금(2014)도 그 자체로 취약성 덩어리라 해도 과언이 아니다. 다만 네트워크기반의 다른 보안솔루션들의 집중적인 보호(침입차단)를 받고 있고 자체적으로는 사용자인증(로그인)과 기본적인 사용자간의 권한분리(계정을 통한 분리)를 통해 최소한의 보안을 유지하고 있는 것이다. 하지만 말 그대로 "최소한"의 보안이다.

유닉스/리눅스 운영체제를 공부하다 보면 수도 없이 많은 보안 취약성을 발견하게 된다. 그 취약성은 개방성을 기반으로 개발된 운영체제이기 때문이기도 하지만 사실...별다른 보안개념을 적용하지 않고 개발된 운영체제이기 때문이기도 한다.

그중에서 오늘 소개할 것은 심볼릭링크 취약성과 쉘의 취약성이다. (심볼릭링크는 윈도의 단축아이콘과 유사하다.)

이따금씩 서버보안 S/W의 시연이나 BMT를 진행하다보면 일부 취약성 공격의 방어에 대한 시연을 요청하는 경우가 있다. 대부분 웹쉘 방어 혹은 웹 소스 위변조 차단에 대한 시연을 진행하는데 이번엔 심볼릭링크 취약성까지 시연해야 하는 경우가 생겼다. 사실... 버퍼오버플로나 포맷스트링 등은 이론적으로만 이해하고 있고 실습(?)을 해보지는 않았다. 사실 해당 취약성을 내포한 애플리케이션을 코딩(C로)하고 테스트하는 과정은 썩 단순하지는 않다. 이따금씩 하는 코딩 실력으론 어려운게 사실이다.

하지만 레이스컨디션은 너무도 쉽고 단순한 쉘스크립트로도 실습이 가능하다. 아주 오래전 한참 코딩에 빠져있을 때 원조 모의해킹 실습사이트(이름은 생각나지 않음)에 들어가 모의해킹을 통해 레벨을 올라가는 도전을 해본적이 있다. 당시 15레벨인가가 명예의전당이었던것 같은데 당시에 8레벨인가가 레이스컨디션 공격을 해야하는 문제였었다. 난 8레벨 획득을 끝으로 더이상 도전하지 않았다. 9레벨에 가려면 인라인어셈블리까지 해야했기 때문이었다. (어셈블리는 인간의 언어가 아니라고 난 생각한다. ^^)

이제 본론으로 넘어가자.

1. 심볼릭링크 취약성을 가진 쉘스크립트

심볼릭링크 취약성은 다양한 프로그램에서 갖고 있다. 특히 임시파일을 생성하고 생성한 임시파일에 쓰기를 하거나 실행을 하는 경우 발생할 수 있다. 특히 root계정으로 실행되면서 임시파일을 생성하고 그 임시파일이 다른 작업을 수행하는 경우 심각한 2차 취약성을 만들거나 시스템에 장애 혹은 정보유출 등으로 이어질 수 있다.

위의 vulrace.sh 는 무한루프를 돌면서 /tmp 디렉토리에 1.sh라는 파일을 만들고 메시지 한줄을 화면에 출력하는 echo문을 저장한 뒤 그 생성한 파일(1.sh)에 실행퍼미션을 부여하고 그 파일을 실행한다.(설명이 복잡한가?) 그리고 실행이 종료되면 임시파일(1.sh)을 삭제한다.

이 과정에서 취약성은 바로 /tmp/1.sh를 삭제하고 다음번 루프에서 echo명령으로 임시파일을 생성하고 실행하는 사이에서 발생한다. 임시파일인 1.sh를 생성하기 전에 누군가가 root 권한으로 실행되기를 바라는 파일로 1.sh라는 심볼릭링크를 먼저 생성하면 이 프로그램(vulrace.sh)은 1.sh라는 정상 임시파일을 만들지 못하고 심볼릭링크인 1.sh에 echo문을 실행하게 된다. 즉 1.sh가 가리키고 있는 엉뚱한 파일에 echo문이 추가되고 실행되는 것이다. 이 엉뚱한 파일이 무엇이냐에 따라 공격의 내용이 달라지게 된다. 그 엉뚱한 파일은 root 권한으로 실행되게 된다. vulrace.sh가 root 권한으로 실행되었으므로...

위의 예제에서는 해당 취약성 공격 성공률을 높이기 위해 sleep 1을 넣어 공격이 쉽게 성공하도록 하였다.

2. 엉뚱한 파일 (쉘카피백도어)

이제  1.sh로  심볼릭링크가  걸릴 스크립트, 즉 공격자가 root권한으로 실행하고자 하는 "엉뚱한 파일"을 만들 차례다. 이 엉뚱한  파일은 쉘카피백도어를 만드는 스크립트를 예를 든다. 따로 설명은 안하겠다. 악용될 경우 심각한 문제를 유발할 수 있기 때문이며... 이 예제를 악용하여 발생하는 문제는 해당 사용자에게 있음을 분명히 밝혀둔다. 하지만 이 정도의 예제는 인터넷을 통해 얼마든지 접할 수 있고 매우 고전적인 방법이지만 최신 운영체제에서도 적용 가능한 기법이다.

이 스크립트가 root 계정에 의해 실행될 경우 /tmp/ 디렉토리에 backdoor라는 루트쉘이 생성된다. 이후 일반계정에서 이 생성된 /tmp/backdoor를 실행할 경우 root 권한을 획득하게 된다.

vulrace.sh가 실행하는 1.sh로 attack.sh 를 심볼릭링크를 걸면된다. (방법은 뒤에서~~)

3.  취약한 스크립트 실행과 공격 성공

심볼릭링크 취약성을 가진 vulrace.sh를 root 계정에서 실행하면 vulrace.sh가 생성하는 /tmp/1.sh에 의해 심볼릭링크 취약성이 있다는 메시지가 출력된다. 이 메시지를 출력하는 것은 정상적인 /tmp/1.sh 이다.

중간의 Attack Success...!! 메시지는 엉뚱한 파일(attack.sh)를 가리키는 /tmp/1.sh 라는 심볼릭링크가 실행되었을 때 attack.sh가 실행되어 출력되는 메시지다. 해커가 /tmp 디렉토리에 1.sh라는 심볼릭링크를 생성하고 vulrace.sh가 해당 심볼릭링크를 실행한 것이다.

4. 공격과 결과

공격은 아래 화면의 ln 명령에 의해 이루어진다. 즉 해커가 root 권한으로 실행하고자 하는 내용을 담은 스크립트를 /tmp/1.sh 로 심볼릭링크를 생성하는 것이다. 

그리고 공격이 성공하면 attack.sh가 하고자 했던 /tmp/backdoor 가 생성된다.

root 소유자이고 소유자의 setuid가 생성되어 있다.

일반계정인 taeho에서 /tmp/backdoor를 실행하면 root 권한을 얻을 수 있다.

p.s 만약 tmp 디렉토리에서 chown  명령이 에러가 발생한다면 tmp 디렉토리에 sticky bit 가 설정되어 있기 때문이다. 샘플 소스의 디렉토리를 /tmp가 아닌 다른 경로로 설정한 뒤 테스트하면 된다.

5. 레이스컨디션 공격 방어 방법

이 심볼릭링크가 갖는 취약성 공격을 방어하기 위해서는 서버 내에서 실행되는 모든 스크립트와 실행파일에 대해 하나하나 모두 검증해야 한다. 

1. 임시파일을 생성하고 실행하거나 수정하는 어떤 프로그램들이나 쉘스크립트가 있는가?

2. 만약 있다면...(100% 존재하며 모두 파악하는 것은 거의 불가능함) 임시파일을 생성하기 전에 생성할 임시파일이 이미 존재하는지 확인하고 존재한다면 프로그램을 중단하도록 소스코드 수정 --> 사실상 불가능함

3. 심볼릭링크를 사용하지 못하도록 함. (역시 사실상 불가능함)

그렇다면 방법이 없는가?

방법은 있다. 

바로 RedCastle SecureOS를 설치하면 된다. RedCastle SecureOS는 Race Condition 공격을 100% 차단 할 수 있다. RedCastle SecureOS는 운영체제의 커널수준에서 심볼릭링크의 생성을 모니터링하여 root계정에서 실행된 명령어 혹은 대몬프로세스가 일반소유자의 파일로 연결되는 심볼릭링크를 실행하는 것을 차단해준다. 

이러한 보호는 SecureOS의 핵심보듈인 커널수준에서 구현된 참조모니터에 의해 구현되기 때문에 예외없이 모든 심볼릭링크 취약성 공격에 대해 방어가 가능하다.

미국에서 헐값에 뿌려진 웨스턴디지털의 NAS인 My Book Live.. 웹 인터페이스가 없다 뿐이지 성능은 꽤나 잘나온다. FTP 속도도 MBL을 집의 IPTIME 공유기에 연결해두고 FTP를 이용해 외부에서 다운로드와 업로드를 해봤는데.. 오..집에 들어오는 SK Broadband의 광랜 속도인 100Mbps가 거의 Full~로 나온다.

FTP 속도가 10MB가 거의 나오니 bps로 환산하면 100 Mbps다. 만족할만한 성능을 보인다. 그리고 그때 MBL의 CPU 사용율은 top 명령으로 확인해보면 40%~50% 정도 사용한다. 두세명이 붙으면 개인당 속도는 접속자로 나눈 만큼 제대로 보여준다.

하지만 외부 USB나 SD카드 등을 연결할 수 있는 포트가 전혀 지원되지 않기 때문에 오로지 NAS로 사용할 수 있을 뿐이고 내장된 HDD 이외의 저장소를 사용할 수 없는 단점이 있다. 당연히 운영체제나 애플리케이션의 문제로 공장초기화를 한다던가 부팅이 안된다던가 할 때는 HDD를 뜯어내어 다른 컴퓨터에 연결한 뒤 복구 이미지를 이용해 초기화를 해야하는 문제가 있다. 만약 문제가 생긴다면 얼마전에 포스팅한 "벽돌이 된 My Book Live를 VMWare를 이용해 공장초기화하는 방법" 포스트를 참고하기 바란다.

MBL은 SSH를 지원해서 리눅스를 다룰줄 안다면 무한한 활용을 할 수 있다. 토렌트머신으로도 딱이고 Apache2와 PHP5가 이미 설치되어 있기에 Mysql을 설치하면 다른 게시판도 사용할 수 있다.

그러자면 일단 ssh를 활성화해야하고 보안을 위해 root 계정의 비밀번호를 변경해야 하며 ssh의 기본포트인 TCP/22를 다른 포트로 변경해주어야 한다.

리눅스의 초보자를 위해 그 과정을 설명하고자 한다. 다른 일반 리눅스와 리눅스를 채용한 다른 NAS도 동일하다고 생각된다.

먼저 My Book Live의 ssh 서비스 활성화를 해야한다. 아래 화면처럼 MBL의 관리 웹페이지 주소인 /UI 다음에 /ssh를 입력하고 엔터~~를 치면 ssh 설정 화면이 보인다. 계정은 root이고 초기 비밀번호는 welc0me다. 어디서 많이 보던 비밀번호다. 

다음은 SecureCRT나 Putty 같은 ssh 접속이 가능한 프로그램을 설치해야 한다. SecureCRT의 경우 설치 후 아래 화면처럼 접속화면을 실행하고 설정한다. SSH2로 설정하고 Hostname에는 MBL의 IP주소를 입력한다. 아래 화면에선 iptime에서 제공하는 DDNS를 설정했기 때문에 IP주소가 아닌 DNS주소가 입력되었다.

포트는 아직 변경하기 전이므로 기본포트인 22번을 입력한다.

Connect 버튼을 누르면 아래 화면처럼 ID와 Password를 입력하는 창이 실행된다.

Username에는 root, password에는 MBL의 root 기본패스워드인 welc0me를 입력한다. 

아래 화면이 뜨기전에 ssh 키관련 창이 먼저 보이는 경우가 있는데... Accept one 혹은 옆의 ...always..를 눌러도 관계 없다.

비밀번호가 맞으면 아래화면처럼 접속이 된다.

먼저 passwd 명령을 입력하여 root의 비밀번호를 변경한다. 패스워드는 최소 8자 이상...숫자와 특수문자를 반드시 포함하여 생성하는 습관을 들이자...!!

root의 비밀번호를 설정하였다면 다음은 ssh의 기본포트를 변경할 차례다.

아래 화면처럼 /etc/ssh 디렉토리로 이동하자. (리눅스나 유닉스에서는 폴더라는 말을 쓰지 않는다. 디렉토리라고 불러주자..!! 정확한 용어의 사용은 오류를 예방하는 기본이다..!!)

ls 명령을 실행하면 sshd_config 파일이 보인다. 이 파일의 내용을 수정하여야 한다.

자..아래 명령처럼 vi 명령을 sshd_config 라는 파일을 지정하여 실행한다.

vi 화면이 실행되면 다른 키를 누르지말고.... 커서키를 이용하여 아래처럼 Port 22 의 앞의 2에 커서를 둔다.

다른 키를 누르면 커서가 엉뚱한 곳으로 이동하거나 파일의 내용이 수정된다. vi 사용법을 모른다면 vi가 실행된 뒤 다른 키를 누르지 말고 곧바로 커서키를 이용하여 아래 처럼 커서를 이동시킨다.

(만약 커서키가 제대로 동작하지 않는다면 키보드에서 j , k , l , ;  네개의 키를 눌러보라. 이 네개의 키가 좌, 우, 상, 하 로 커서를 움직이는 키다. 커서키는 안돼도 이 네개의 키는 될 것이다.)

위 화면처럼 앞의 2에 커서를 둔 뒤 키보드에서 c 키와 w 키를 차례대로 눌러준다.(change word 명령) 그러면 명령모드에서 입력모드로 바뀌면서 아래 처럼 커서가 위치한 곳의 하나의 워드(word)인 22가 지워지고 새로운 워드(word)의 입력을 기다린다. 

아래 처럼 9275 를 입력한다. tcp/9275 번을 22번 대신 사용하겠다는 의미다.

다른 번호를 맘내키는 대로 입력해도 된다. 단 다른 프로그램이 사용하는 포트를 지정하면 안된다. 예를 들면 21번이나 110, 25, 80 등은 안된다. 가급적이면 1024보다 큰 숫자를 입력하라

숫자를 입력했다면... ESC 키를 한번 살포시 눌러준다. 입력모드에서 명령모드로 나가게 된다. (화면에 보이진 않지만.... 그래서 vi를 어려워하는 초보자가 많다.)

ESC키를 눌러서 명령모드로 왔다면 이제 키보드에서 : 를 눌러준다. 그리고 w와 q를 눌러준다. (w : write 저장,  q : quit 나가기) 그리고 엔터키를 친다~~!!

아래 화면처럼 sshd_config 파일이 저장되었다고 나오고 vi가 종료되고 다시 # 프롬프트로 돌아간다.

이제 포트를 변경했으므로 ssh 서비스를 재구동해야 한다. 몇가지 방법이 있지만 여기에선 가장 원초적인 방법을 설명한다. 아래 화면처럼 cd 명령으로 /etc/init.d 디렉토리로이동한다. 

그리고 ./ssh restart 명령을 실행하여 sshd 대몬서비스를 재구동 한다.

그리고 netstat 명령으로 변경한 TCP포트로 sshd 대몬이 잘 구동되어 있는지 확인한다.

당연히 22번 포트를 변경하기 전에 netstat 명령으로 변경할 포트를 다른 프로세스가 사용하는지 확인은 필수다.

이제 SecureCRT나 putty에서 변경한 포트로 ssh 접속이 잘 되는지 확인해보자..

단, 이전에 로그인한 창은 그대로 두고 새로운 창으로 접속테스트를 해보자. 설정이 잘못되었거나 예상치 못한 문제가 생기면... 원복할 수 있도록 이전에 로그인한 ssh 창은 그대로 두자.

잘 접속이 된다면 성공이다.

만약 MBL을 리부팅해도 ssh 포트는 변경된 포트로 잘 동작할 것이다.

간혹 홈페이지의 소스파일 중 하나인 Javascript 파일이 변조되는 해킹공격을 당해 긴급하게 서버보안SW적용을 요청하는 기업들이 있다. 대부분 보안에 신경을 쓰지 않은 채 웹서버를 구축하거나 홈페이지를 개발하는 경우가 대부분이지만 간혹 이름만 대면 다 아는 그런 기업도 종종 있는 편이다. 

얼마 전 긴급하게 요청이 온 기업도 이름만 대면 다 아는 기업이었다. 공교롭게도 방화벽, IPS(웹방화벽), 웹소스변조방지 등 여러 제품을 도입하여 프로젝트를 진행하는 도중에 지속적으로 소스파일이 변조하여 자바스크립트를 삽입하는 공격이 발생하고 있었지만 도입된 솔루션들이 무용지물인 상황인 듯 했다. 급하게 엔지니어를 보내 RedCastle을 설치하고 홈페이지 소스파일들이 위치한 경로에 다음과 같은 정책을 적용했다.

정책은 아주 간단하다. 소스파일 경로 아래의 모든 파일에 대해 아래 화면처럼 IIS 웹서버 (w3wp.exe)가 읽기만 가능하고 수정을 하지 못하도록 하는 정책이다. (물론 운영체제를 보호하는 baseline policy는 적용하였음)

정책을 적용하고 얼마 지나지 않아 javascript 파일에 대해 변조 공격이 들어왔고 정책에 의해 차단되었다.

변조가 시도되는 파일은 감사로그에 정확하게 기록되었다.

해커는 몇차례 반복하여 Javascript 파일를 변조하려 시도하였고 그 시도는 번번히 RedCastle에 의해 차단되었다. 

인터넷을 통해 온라인 주문을 실시간으로 처리하거나 대 고객 서비스 업무를 수행하는 웹서버는 언제는 위와같은 홈페이지 소스 위변조 공격을 당할 수 있다. 하지만 공격당했다는 사실 조차 모르는 경우가 비일비재하다.  

왜냐하면 해커가 변조한 그 웹서버가 "공격 대상"이 아니라 그 웹서버에 웹브라우저를 통해 접속한 일반 사용자의 PC가 공격대상이기 때문에 서버에 쉽게 알아챌만큼 큰 피해를 단시간내에 주지는 않기 때문이다. 즉 일반 사용자의 PC에 악성코드를 다룬로드 받도록 java script 파일에 악성코드를 심어 놓는 것이 해커가 웹서버의 소스를 변조하는 목적이기 때문인 경우가 많다. 만약 더 이상 서버의 활용도가 없다면 그땐 큰 피해를 주고 유유히 빠져나갈 가능성도 배제할 수는 없다.

이렇게 외부에서 웹소스나 웹서버의 취약점을 공격하여 소스파일을 직접 변조하려는 시도는 오히려 다른 공격보다 위험도 측면에서 나은 경우일 수 있다. 만약 실제로 소스파일이 변경되지 않았는데 웹브라우저로 접속해보았을 때 변조된 Javascript가 소스보기로 보면 소스가 변경되어 보인다면 상황은 더욱 심각할 수 있다.

이런 경우는 정말 심각한 경우다. 이미 웹서버가 있는 네트워크에 해커가 침투하여 거점을 마련하고 스니핑과 스푸핑 공격에 성공한 경우이거나 SQL인젝션 등을 통해 다른 서버나 PC에 이미 침투하였을 가능성이 높기 때문이다. 만약 그렇다면 피해는 서버 한두대에 그치지 않을지도 모르는 심각한 상황이라고 봐야한다.

IIS웹서버의 소스에 악성코드가 삽입되어 있다면 최대한 빨리 취약성을 제거해야 한다. 하지만 취약성 하나를 제거한다고해서 소스위변조가 다시는 일어나지 않는다는 보장은 없다. 취약성이라는 것은 언제든 새로운 것이 발견되거나 새로 추가한 페이지에 존재할 수 있기 때문이다. 

그렇기 때문에 가장 최선의 방법은 공격패턴이나 취약성 공격에 대응하는 패턴기반의 웹방화벽이나 IPS가 아닌 정책기반의 서버보안SW인 RedCastle을 설치하여 소스 파일의 위변조를 커널 수준에서 통제하는 것이 최선의 해결책이다. 

결국 그 고객사는 경쟁사 제품을 걷어내고 RedCastle을 도입하였다.

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

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

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

1. setuid/setgid 파일 찾기.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

지난 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 공격은 "집 밖에서 누가 돌멩이를 집으로 던져 유리창이 깨진 것" 에 비유할 수 있다. 과연 두 가지 해킹 중 어떤것이 더 심각한 문제일까? 당연히 홈페이지 변조가 더 치명적인 보안사고다. 하지만 공무원은 변조 보다는 장애가 더 큰 문제인 것처럼 이야기하고 있다. 매우 심각한 보안 인식의 문제가 드러난 발언이다. 

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