beomil ideas

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

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

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

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

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

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

Posted in Linux