2010년 7월 13일 soojung 보안 버그
설마 아직도 soojung을 쓰는 사람이 있을까 싶지만… 그래도 몇 사람 쓰고 있는 것 같으니까 공지. soojung의 현 버전(0.4.14)은 너무 오래 되어서 몇 가지 문제가 있는데 그 중 하나가 soojung의 XMLRPC 라이브러리 버전이 너무 낮아서 (1.2.1) 알려진 보안 버그가 있다는 겁니다. 가급적이면 xmlrpc.php 자체를 삭제하시거나, 나는 죽어도 metaWeblog API를 써야 겠다라고 하시는 분은 수동으로 libs/xmlrpc.inc랑 libs/xmlrpcs.inc를 1.3.2 이후 버전으로 업데이트해 보시길 바랍니다. (후자는 나도 안 해 봐서 되는진 모름)
이 보안 버그를 알게 된 건 루리넷이 이 버그로 실제로 공격을 받았기 때문이다. 그렇다. 이번에는 내 실수다. orz (애초에 soojung으로 된 블로그들을 모두 메아리로 이전하고 있긴 하지만, 아직 못 옮긴 블로그는 댓글 기능만 날린 채 그대로 soojung으로 운영한 탓이다.) 다행히 몇 시간동안 일부 사이트가 이상한 오류를 내뱉은 거 빼고는 별다른 문제는 없었다.
서버에 문제가 있다는 걸 알게 된 건 서버 사용자 중 한 사람이 자기 쓰던 도쿠위키에서 세션 에러가 난다고 한 것 때문이었다. 이 때가 대략 오늘 정오 쯤이었는데, 메시지가 딱 보니 /var 파티션이 꽉 찬 거라서 “아… 저번에 로그 지웠는데 또 왜 이러냐” 하는 생각으로 로그 디렉토리를 확인해서 6개월 넘은 로그를 모두 지워줬다. (하는 김에 logrotate 설정도 고쳤다. 웬만하면 배포판 설정 안 바꾸고 싶었는데 파티션이 너무 작아서…) 그리고 df 하니까 잘 지워진 것 같아서 안심하고 있었는데 똑같은 문제가 남아 있자 다시 한 번 df, 이럴수가! /var 파티션이 그새 다시 차 버렸다!
로그 디렉토리를 다시 확인하니 error.log가 2기가 넘는 용량을 자랑하면서 버티고 있길래 “이거 누가 쟝고에서 에러 세례를 퍼 붓고 있는 건가”(최근 쟝고 어플리케이션 올려 달라는 얘기가 좀 있어서;)하면서 지웠는데 df에서는 전혀 갱신되는 기색이 없었다. 아파치를 껐는데도 똑같은 문제가 발생하니까 이건 뭔가 다른 엉뚱한, 아마도 외부에서 올라온 프로그램이 문제를 일으켰으리라 생각하고 확인해 보니까 정말로 /tmp/ns1이라는 파일이 CPU를 다 잡아 먹고 있었다. 생각해 보면 뭔가 이상하다 느꼈을 시점에서 lsof를 먼저 했어야 하는 것 같긴 한데… 서버가 사용자들의 기괴한 사용으로 엉망이 되는 일은 흔한 일이라 잠시 부주의하고 있었다. 어쨌든 일단 kill하고 아파치 다시 재시작하니 df는 정상.
분명 제로보드는 수동으로 패치하고 그 밖의 프로그램들도 꽤 주의깊게 모니터링하고 있는데 어디서 공격이 들어 온 건지 생각하면서 이 파일의 정체를 확인해 보았다. stat 결과 파일이 만들어진 시각은 오늘 새벽 3시 10분 15초였고, 웹서버 계정(www-data)으로 만들어졌으므로 뭔가 PHP 셸 같은 게 돌아가다가 실행 파일을 올린 게 확실했다. 이미 프로세스를 꺼 버린 상태였으므로 이 프로그램의 정체를 확인하기는 쉽지 않았지만, error.log의 에러 메시지(아마도 stderr로 가야 할 게 이 쪽으로 재지정된 걸로 보인다)를 볼 때 뭔가 bind를 한 뒤 recvfrom을 하려다가 포트가 막혀서 에러 메시지를 뿜어 댄 것으로 추측되었다. 그래서 error.log가 10분만에 2기가를 넘은 게지. 그래서 그냥 맘 잡고 분석하기로 하고 objdump로 간단한 디스어셈블리를 해 보니 bind하는 포트는 UDP 포트 27444였고, Trinoo slave로 확인되었다.
아파치 에러 로그는 날렸으므로 확인할 수 없었지만, 액세스 로그를 확인해 본 결과 (다즐링 님의 조언으로) 93.69.44.202라는 아이피가 http://sapzil.info/soojung/xmlrpc/server.php로 여덟 번의 POST request를 보낸 것으로 확인되었다. (본래는 xmlrpc.php여야 겠지만 mod_negotiation이 활성화되어 있어서 /xmlrpc도 먹혔다. 그냥 운이 나빴던 듯.) 이 중 일곱번째 request가 response 크기가 다른 것과 서로 달랐는데 이 response 시점이 3시 10분 24초, 그러니까 파일 생성 9초 후여서 아마 이 request가 파일을 생성하고 실행했으리라 추측했다. 확인 결과 soojung의 XMLRPC 라이브러리에 버그가 있었고, 결국 나는 그냥 xmlrpc.php를 깔끔하게 지워서 (어차피 쓰지도 않는데) 문제를 일단 해결했다. 해당하는 아이피는 프락시인 것 같은데 더 이상 추적하긴 쉽지 않고, 주소로 추정할 때 나한테 원한 산 사람이라기보다는 그냥 무작위로 URL을 넣다가 운이 나빠서 걸린 것으로 보이기 때문에 보안만 강화하는 수준으로 하기로 했다. -_-;
나중에 루트킷도 확인해 보고 이런 저런 검사를 해 보기는 했지만 별 문제는 없는 것 같아서 모니터링만 꾸준히 하는 수준으로 마무리짓기로 하긴 했지만, 남들한테 제로보드 4 제발 쓰지 말라고 읍소하고 서버에 깔려 있는 모든 소프트웨어의 목록(이를테면 미디어위키 네 다섯 개라거나…)을 기억하고 있는데도 실수하는 걸 보면, 답은 명확하다. 오래된 소프트웨어는 쓰지 말자. orz
