최근 해킹사고가 늘고 있다.
서버보안 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의 다른 명령어들을 덮어쓰고자 시도하여 무수히 많은 보안 위반 감사 로그를 다음 화면과 같이 남겼다.
운영체제의 주요 파일들에 대한 위/변조 시도가 모두 차단되자 해커는 서버의 상태를 확인해보고자 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이 설치되고 최소한의 보안 정책이 적용되어 있었기 때문이다.