2012년 1월 12일 제로보드 4
내가 어제 제로보드 4 까는 트윗을 올렸는데 하루 사이에 리트윗이 100명을 넘었다. 워매… 무서워… 근데 이거 문맥이 없으면 왜 이러는지 이해하기 어려우니까 조금 더 자세히 얘기해 보자.
사건
그제와 어제 학교 내 리눅스 머신 수십대가 루트킷에 감염되었다는 것이 확인되어서 하루 내내 홍역을 치뤘다. 이 루트킷은 (다행인지 불행인지) 동일한 공격자가 심어 놓은 것인데, 나중에 알려진 것들을 종합하면 대강 다음과 같은 경로로 전파된 것 같다.
- 웹 서버를 돌리는 몇몇 서버가 제로보드 취약점으로 웹셸이 뚫렸다.
- 웹셸은 보통 웹 서버 계정(www-data, www 등)으로 돌아 가지만, 추가적인 취약점을 사용해서 루트 권한을 얻을 수 있다.
- 이렇게 얻은 루트 권한을 가지고 SSH 서버를 갈아 치우면 SSH 접속 시 아이디와 암호를 평문으로 기록할 수 있다. (SSH가 아무리 암호화를 한다고 해 봤자 SSH 서버 자체가 기록을 하면 아무 소용이 없다!)
- 이제 이 아이디와 암호를 가지고 다른 서버에 접속을 시도해 본다. 성공하면 3번 과정을 반복한다.
이 과정을 거쳐서 공격당한 기계들 중에 꽤 사용자가 많은 서버(대표적으로 아라…)가 있다는 게 알려지자 공격자가 이걸 가지고 서버 관리자들을 놀려 먹으려고 IRC에 등장했는데(…) 이 과정에서 1번에 사용된 취약점이 다른 게 아니라 내가 2005년에 발표한 그 취약점이라는 게 확인된 것이다. -_-; (CVE-2005-1820) 내가 다니는 학교에 있는 서버가 내가 발견한 취약점으로 뚫리는 것 만큼 허무한 일이 어디 있을까.
물론 공격자가 최초 공격 이후 거점을 넓혀 나갈 수 있었던 이유는 제로보드 취약점이 아니라 사람들이 여러 기계에서 똑같은 아이디에 똑같은 암호를 썼다는 이유였다. 실제로 이 사건 이후 일부 서버는 SSH keyboard-interactive를 완전히 못 쓰게 하려는 시도도 하고 있는 것 같다. 하지만 그렇다고 제로보드 취약점에 당한 서버의 책임이 무마되는 건 아니다.
역사
이 문제의 취약점은, 링크에서도 알 수 있듯이 사실 2003년에 처음으로 발견한 것이다. 게다가 이건 정확한 메커니즘은 전혀 모른 채1/만 들어 가면 에러가 난다(…)는 것을 알고서 실험하던 도중에 발견한 것이다. 당시 나는 철 모르던(?) 학생이었고, 이 취약점의 중요성에 대해서 별로 인식하지 못 한 채 일부 서버에 몸소 실험을 해 보는 무모한 짓까지 몇 번 시도했을 정도였다. 발견한 지 한참 뒤에서야 공개적으로 발표하게 된 것은 이런 면도 어느 정도 작용했을 것 같다.
내가 공개를 한참 미뤄야 했던 다른 이유로는 타이밍이 잘 안 맞았다는 점도 있다. 제로보드 4는 4.1이 2002년에 나온 이래 이렇다 할 변경이 거의 이루어지지 않은 것으로 악명이 높았는데, 특히 내가 버그를 발견했을 적의 최신 버전인 4.1 pl4(2003년 8월)는 무려 1년 반 가까이 갱신이 되지 않았다. 대학교 입시에 바빠지기 시작할 2004년 초반 즈음에 어떻게 할까를 고민했었는데, “어차피 나 말고도 이 버그 발견할 사람들이 충분히 있을텐데 나중에 확인해 보자”라는 생각으로 일단 묻어 두고 있었다(그리고 그 때만 해도 나는 누구한테 메일을 보내서 문제를 알리는 데 익숙하지도 않았다). 그래서 2004년 말에 4.1 pl5가 나왔을 때, 이 버그가 전혀 고쳐지지 않은 것에 상당히 놀랐다. 그리고 불안감이 엄습해 왔다. pl5가 나와서 사람들이 패치를 하는 이 시즌에 문제가 해결되지 않으면 그 다음 pl6까지 기다리기 전에 문제가 커진다! 그래서 개발자 연락 없이 곧바로 버그를 공개하게 된 것이다. 참 배짱도 좋았다.
후에 확인해 보니, 내가 발견한 preg_replace 기법은 생각보다 잘 알려지지 않은 기법이었던 것 같다. 이 버그는 흔히 정규식을 동적으로 생성해서 검색 하이라이팅을 하거나 하는 코드에서 주로 발생하는데, 도대체 누가 검색어에 널 문자 같은 걸 넣겠냐는 말이다. 많이 찾아 본 건 아니지만 CVE에서 이 기법을 사용한 취약점은 2005년 이후로 급증했는데, 그 첫 타자가 제로보드 취약점이었다(…). 게다가 실제로 발견한 시기를 생각해 보면 내가 아마도 이 문제를 인식한 초기 그룹에 속하지 않으려나 싶기도 하다. 정말로 어쩌다가지만.
“이 때가 아니면 제로보드 취약점은 안 고쳐진다”라는 생각을 했던 사람은 나 말고도 더 있던 모양이어서, 내 발표 직후에 나온 제로보드 4.1 pl6에는 문제의 취약점 말고도 다른 취약점 하나가 고쳐졌다. 그리고 몇 달 안 지나서 pl7에서 또 다른 취약점이 고쳐졌고, 드디어 사람들이 제로보드가 보안 취약점 덩어리라는 걸 인식하게 되었다. 제로보드의 새 버전이었던 zb5(지금은 접혔다)가 개발 도중에 급하게 나온 이유도 비슷한 이유라고 생각한다. 개발자조차도 제로보드 4에 미래가 없다고 생각할 정도여서 뭔가로 갈아 타긴 해야 하는데, 그 뭔가가 필요한 시점이 갑자기 찾아 왔던 것이다. 다행히도 한 두 해 사이에 급격한 전환이 이루어져서, 더 이상 새로운 사이트를 만드는 데 제로보드 4를 쓰는 사람은 없었다.
현재
제로보드 4는 4.1 pl9를 마지막으로 업데이트가 중단되었으나, 제로보드 4를 아직도 사용하는 웹사이트들은 여전히 남아 있다. 심지어 내 웹 서버 한 구석에도 전환이 어려워서 알려진 보안 버그만 패치된 채로 돌아 가는 제로보드 4가 하나 남아 있다.2
내가 취약점을 발표한 지 무려 7년이 지났건만, 이렇게 아직도 남아 있는 제로보드 4는 상당한 보안 문제를 유발하고 있다. 해외 공격자들이 제로보드 4가 호구쉬운 공격 타겟임을 알게 되자 제로보드 4 소스를 하나 하나 분석해 가면서 모든 방법으로 공격을 시도하기 시작했고, 이는 점차 자동화되어서 이번 사건처럼 제로보드 4가 깔려 있는 서버가 관리자 모르게 또 다른 서버를 공격하기 위한 용도로 사용되는 경우도 매우 흔하다. (하긴 제로보드 4를 패치 없이 방치하는 서버는 관리를 포기했다고 봐야 할 지도 모르겠다.)
내가 이렇게 말한다고 방치된 서버에 정신을 쏟을 사람이 얼마나 있을진 모르겠다. 하지만 적어도 나는 7년 전에 발견한 취약점이 아직도 현역으로 돌고 있는 걸 보고 좋아할 사람은 아니다. 제로보드 4를 피치 못 한 이유로 계속 써야 한다면 적어도 pl9를 쓰고, 웹 서버 설정을 최대한 제약해서 가능한 문제를 최대한 줄여야 한다. 이럴 만한 능력도 없는데 제로보드 4를 쓴다는 것은 자기 뿐만 아니라 남들까지 위험에 빠뜨리겠다는 생각이라고밖에 할 수 없다.
2012년 3월 28일 덧붙임: 문제의 공격자는 결국 경찰에 붙잡혔다. 17세 네덜란드 소년이라고.
