2021-10-19 09:15 (화)
쉘쇼크 사태 통해 시스템관리자가 되새겨야 할 교훈
상태바
쉘쇼크 사태 통해 시스템관리자가 되새겨야 할 교훈
  • 홍석범
  • 승인 2014.10.06 18:31
이 기사를 공유합니다

운영중인 애플리케이션은 최소한의 권한으로 운영되고 있는지 확인해야
아직 쉘쇼크의 폭풍이 가시지 않았지만, 주요 시스템에는 패치를 완료하거나 패치 계획을 내 놓는 등 이제 어느 정도 안정화 단계에 접어 들고 있다. 그러나 단순히 bash 패치를 완료했다고 끝나는 것이 아니라 금번 쉘쇼크 사태를 통해 시스템 관리자라면 다시 한번 되새겨 보아야 할 몇 가지 교훈이 있다.

첫째, 시스템에서는 아직도 알려지지 않은 취약성이 더 많을 수 있다는 것이다.

시스템 관리자들은 부지불식간 리눅스나 BSD등 *NIX계열은 안전하다는 생각, 또는 알려진 취약성에 대한 패치는 완료했으니 안전하다는 생각을 가지고 있을지 모르겠다. 하지만 금번과 같은 bash 취약성은 시스템 관리자에게는 가히 충격적이라고 할 수 있을 정도로 너무나 단순한 방법을 통해 내부 시스템에 접근 가능한 취약성이었다. 또한 보안전문업체인 Symantec(시만텍)에 의하면 Zero-day(제로데이) 공격이 사용되고, 이후 벤더나 보안 커뮤니티에 이 취약성이 공개되어 패치가 나올 때까지의 시간은 평균 10개월이 소요된다는 충격적인 통계 자료를 발표한 바 있다.

관련글: www.forbes.com/sites/andygreenberg/2012/10/16/hackers-exploit/

[그림] 취약성 공개 전후 공격 발생 시간에 대한 통계 (많은 공격이 실제  CVE 취약성 공개전부터 시작되었음을 알 수 있다)

따라서, 금번 bash 취약성이 공개되기 이전부터 이미 공격자들은 취약한 시스템에 대한 공격을 하고 있었을 수도 있고 아직 CVE에 공개되지 않은 다른 Application(애플리케이션)의 취약성을 이용해 은밀하게 공격을 하고 있을 수도 있다는 것이다.

둘째, 강력한 접근 통제는 보안의 기본 중 기본이다.

금번 취약성은 대부분 공개되어 있는 HTTP 서비스를 통해 공격하고 있지만 언론을 통해 NAS, DHCP나 OpenVPN등 다른 서비스에 대한 공격도 일부 모니터링 되고 있는 것으로 알려져 있다. 앞에서 언급한 바와 같이 만약 SSH나 FTP등 통상적으로 많이 사용하고 있는 Application 서비스에 알려지지 않은 취약성이 있다면 이미 이를 통해 공격이 진행되고 있을 수 있을 것이다. 그러나, 어쩔 수 없이 외부에 공개하여야 하는 서비스 이외의 다른 서비스(데몬)에 대해서는 iptables나 tcp wrapper, IPSEC 또는 방화벽 등을 통해 반드시 허용해야 할 곳(소스IP) 이외에 대해서는 엄격한 접근 통제를 한다면 공격자의 입장에서 취약성을 이용하여 공격할 수 있는 가능성이 그만큼 줄어들게 되므로 설사 미 패치 상태라 하더라도 발생 가능한 Risk를 최소화할 수 있을 것이다.

셋째, 모든 Application의 실행권한은 최소한으로 유지한다.

금번 bash의 취약성을 이용해 원격에서 아래와 같이 공격을 하게 되면,

$ curl -k -H 'User-Agent: () { :;}; echo hack>/tmp/hack' http://example.com/cgi-bin/vul.cgi

해당 서버쪽에는 아래와 같이 nobody 권한으로 파일이 생성된다.

$ ls -la /tmp/hack
-rw-r--r--  1 nobody nobody 5 Sep 26 14:52 /tmp/hack 

물론, 이는 파일 생성에 대한 간단한 예제이며 shutdown이나 rm –rf 와 같이 공격자가 원하는 특정 명령어를 실행할 수도 있을 것이다. 여기에서 이 파일은 웹서버가 생성한 것이므로 웹서버(HTTPD)의 실행권한인 nobody 로 생성된 것이다. 그러나 만약 웹서버가 nobody가 아닌 root 권한으로 작동하고 있었다면 당연히 root 권한으로 파일이 생성될 것이고 공격자는 원격에서 인증 없이도 root 권한으로 명령어를 실행 할 수도 있을 것이다.

또한 여기에서는 웹서버를 예로 들었지만 취약성은 데몬 자체에 있을 수도 있고 데몬이 참조하는 다른 Application에도 있을 수 있기 때문에 모든 Application의 실행 권한을 최소화하여야 발생 가능한 risk(리스크) 역시 최소화 할 수 있을 것이다. 혹 현재 운영중인 Application은 최소한의 권한으로 운영되고 있는지 각자 확인해 보기 바란다. 아울러 한 시스템에서 여러 데몬이 운영중 일 경우에는 nobody 등과 같은 하나의 계정으로 모두 작동하는 것 보다는 각 Application 마다 각자 다른 권한을 가진 별개의 계정으로 실행하는 것이 만약의 문제 발생시 피해를 줄일 수 있을 것이다.

 [글. 홍석범 씨디네트웍스 시스템 UNIT 부장 / antihong@gmail.com]