얼마 전 전 세계적으로 이슈가 된 bash 취약점에 대한 포스트를 쓴 적이 있습니다. 그런데 아무래도 이 취약점에 대한 보안 업계 사람들의 과잉 반응이 심상치 않습니다. 과연 bash 취약점의 본질을 제대로 이해하고 있는지 의구심이 들 정도입니다.
bash 취약점은 물론 심각하게 악용될 수 있습니다. 하지만 중요한 것은 원격지에서 bash 취약점을 단독으로 악용하여 서버에 접근할 수는 없다는 점입니다.
bash는 사용자에게 명령어를 입력 받아 명령어에 해당되는 파일을 사용자 대신 프로그램이 서버의 메모리에 로드되고 실행될 수 있도록 해주는 프로그램입니다. 그리고 bash는 단독으로 서버에서 실행되어 통신을 통해 명령어를 전달 받는 통신 기능이 없습니다.
즉 bash 취약점을 이용해 원격에서 직접 아래와 같은 명령을 쉘에게 전달할 수는 없습니다.
위의 명령을 변형하여 서버에서 해커가 원하는 명령을 실행하기 위해서는 서버에서 실행중인 서비스에 접속할 수 있어야 합니다. 그리고 그 서비스의 취약점을 찾아 bash 명령어든 아니면 배치작업 등에 의해 실행중인 bash에 접근할 수 있어야 합니다.
가장 단순한 형태로 bash 취약점을 원격에서 악용할 수 있는 가상의 시나리오를 그림으로 그려보면 다음과 같습니다.
즉 원격에서 해커가 서버의 bash취약점을 이용해 공격을 하려면 위 그림과 같이 일단 서버에 접근할 수 있는 서비스를 찾아야 합니다. 가장 찾기 쉬운 서비스가 바로 웹 서비스일 겁니다. 웹서버에서 bash를 호출하거나 실행중인 bash에 접근할 수 있는 웹서버의 취약점을 찾는다면 bash 취약점을 이용해 명령을 실행시킬 수 있습니다. 이 단계까지 갈 수 있다면 해커는 서버를 장악한 것과 다름없습니다. 웹쉘이 서버에 업로드 된 것과 같죠.
하지만 원격에서 위의 그림에 있는 web server 취약점 공격 없이 직접 bash에게 접근해 공격코드를 삽입할 수는 없습니다. 그런데도 불구하고 국내외의 많은 보안인들은 이점을 정확하게 설명하지 않은 채 마치 취약한 bash가 서버에 있으면 100% 해킹할 수 있는 것 처럼 과장하고 있습니다. 당장 취약점 방어가 가능한 IPS, F/W 등 보안 솔루션을 도입하라고 말입니다.
보안업계가 아닌 다른 분야에서 일을 배우기 시작한 제가 볼 때는 이런 호들갑(?)은 보안 업계에만 있는 독특한 특징입니다. 대 고객 기만처럼 느껴질 때가 많습니다. 물론 취약점을 내포한 채 시스템을 운영해서는 안되겠죠. 하지만 취약점에 대한 정확한 정보 전달 없이 그저 “이 취약점은 이만큼 위험하니 이것 저것 해야 한다” 식의 엄포를 놓는 것은 썩 바람직해 보이지는 않습니다.
그리고 그런 사람들의 공통점은 서버의 운영체제와 서비스애플리케이션, 시스템소프트웨어의 상관관계에 대해 깊은 이해가 부족하다는 점입니다.
bash 취약점은 심각한 보안 취약성 임에는 분명합니다. 하지만 서두르거나 호들갑을 떨 필요는 없습니다. 정확한 취약점 식별과 취약점 분석을 통해 위협을 제거하면 됩니다.
현재까지는 bash를 패치하는 것이 가장 확실한 방법입니다. 그래도 불안하다면 RedCastle과 같은 SecureOS를 통해 웹서버 서비스 대몬(httpd, java, htmls)이나 DB 서비스대몬 및 기타 서비스 대몬들이 bash를 읽거나 실행하지 못하도록 커널 수준에서 차단하는 것이 현재까지는 가장 확실한 보호대책입니다.
IPS, 웹방화벽 등 네트워크 기반의 보안 솔루션으로는 bash 취약점 공격을 제대로 방어할 수 없습니다.