방화벽, IPS, IDS 등의 성능이 우수해지고 시스템의 접근 권한이 강화되자 공격자들은 이제 보안이 허술한 웹으로 눈을 돌리기 시작했다. 웹 취약점을 이용한 해킹이 지속적으로 증가하는 것도 이 때문이다. 따라서 이번호에는 최근 이슈가 된 해킹 방식인 iframe을 이용한 관리자 권한 취득에 대해 알아보고 그에 대응할 수 있는 방법을 살펴 보도록 한다.
최근 웹 공격의 화두는 SQL Injection이나 Cross Site Scripting(XSS)이었다. 그러나 얼마 전 잠시 이슈가 되었던 OO보드 취약점은 iframe을 통해 정상적인 관리자의 권한을 이용하는 공격이었다. 이는 iframe이나 IMG html tag를 게시판이나 혹은 제목에 쓸 수 있도록 한 것이 그 원인으로 작용했다.
문득‘iframe이나 IMG html tag를 이용하도록 허용하는 것이 과연 큰 문제를 일으킬 수 있을까?’라는 의문이 생길 수 있다. 물론 대부분의 경우 이를 허용한다고 해서 반드시 문제를 야기하는 것은 아니다. 그러나 보안상의 위협이 될 잠재적인 결함이 존재하는 것은 틀림없는 사실이므로 이를 해결하는 데 적잖은 관심을 기울여야 한다.
보안의 현 주소
필자는 IDC에서 근무하고 있기 때문에 많은 서버와 서버 관리자, 그리고 프로그래머들을 접하게 된다. 필자의 경험에 비춰보면, 대부분의 관리자와 프로그래머들이 프로젝트 일정에 쫓기다보니 많은 경우 보안을 고려한 코딩과 관리가 우선순위에서 밀리게 된다. 하다못해 입력 값을 검증하는 코드를 삽입하며 웹 프로그램을 짜는 개발자들도 거의 찾아보기 힘들다.(안타까운 현실이지만, 필자 역시 이 대다수의 경우에 속한다)
사소하게만 느껴지는 html tag의 허용 문제가 얼마나 큰 결과를 가져오는지 다음의 시나리오를 통해 알아보도록 한다. 여기서 등장하는 기업과 인물은 모두 가상으로 만들어진 것이다.
background
H사는 리눅스 기반의 중소 규모 의류 쇼핑몰을 운영하고 있는 회사다. 이 업체는 게시판(OO보드)을 통해 주문과 고객 상담을 하고 있고, 게시판에서의 친절한 답변과 성실한 관리로 고객들로부터 좋은 평가를 받고 있다.
H사의 게시판 담당자인 김 대리는 오전과 오후로 나눠 하루 두 번씩 게시판에 올라온 각종 문의사항을 처리한다. 서버는 웹을 위한 80 포트를 제외하고는 모두 방화벽을 통해 접근하도록 접근 제어가 이뤄지고 있다.
accident
김 대리는 게시판에 올라온 주문사항과 문의사항을 점검하는 것으로 하루 일과를 시작한다. 이날도 김 대리는 아침 출근과 함께 늘 하던 대로 게시판에 접속해 밤새 올라온 주문들을 정리하고, 문의사항에 대해 답변을 달았다. 이와 더불어 일부 고객들은 쪽지를 통해 쇼핑에 대한 문의와 소감들을 적어 보내오므로 <화면 1>과 같이 쪽지도 확인했다.
<화면 1> 고객들이 보낸 쪽지 보관함
일사천리로 쪽지 확인까지 마친 김 대리는 오전 게시판 모니터링을 마치고, 주어진 다른 업무를 진행했다.
오전 업무를 마칠 무렵, 회사에 갑자기 많은 전화가 걸려오기 시작했고 전화 내용은 대부분 게시물에 대한 고객으로부터의 항의였다. 평소 성실하게 게시판을 운영해 왔다고 자신했던 김 대리였기 때문에 무척 당황스러웠다. 어찌된 영문인지를 확인하기 위해 게시판에 접속한 김 대리는 잠시 후 깜짝 놀라고 말았다. 게시판의 일부 주문 내용이 사라졌을 뿐 아니라, 누군가가 관리자 권한으로 접속해 고객 문의에 <화면 2>처럼 욕설이 담긴 엉뚱한 답변을 달아 놓은 것이었다. 고객의 입장에서 볼 때 관리자 권한으로 글이 작성돼 있는 만큼 회사로 항의 전화를 거는 것은 지극히 당연한 일이었다.
이 일로 인해 H사는 그동안 쌓아왔던 좋은 이미지와 고객들의 신뢰에 큰 타격을 었고, 책임자인 김 대리는 막막한 기분에 휩싸이게 됐다.
<화면 2> 관리자 권한을 침해당한 모습
위의 시나리오는 물론 가상으로 구성한 것이지만, 리눅스뿐 아니라 윈도우 시스템 환경에서도 tag확인 취약점을 이용해 얼마든지 일어날 수 있는 일이다. 비단 게시판뿐만 아니라, get 방식으로 변수를 넘기는 admin page에서도 충분히 발생할 수 있는 상황이다. 그럼 위와 같은 일이 어떻게 일어날 수 있었을까? 김대리는 과연 무엇을 잘못한 것일까?
여기서 굳이 김 대리의 잘못을 하나 꼽아 보자면, 게시판에서 입력받는 값을 검증할 코드를 작성하지 않은 점을 들 수 있다. 물론, 직접 게시판을 만들 재주나 여력이 없어 공개용 게시판을 사용한 것이라도 책임을 완전히 면하기는 어렵다. 공개용 게시판의 패치 여부를 잘 살펴보지 않은 부주의를 탓할 수도 있기 때문이다. 이처럼 공개용 게시판은 이름 그대로 소스 코드가 공개돼 있어 공격자의 적이 되기 쉽다.
특히 OO보드와 같이 사용이 편리하고 인기 있는 게시판의 경우라면, 더더욱 공격자의 표적이 되기 쉽다. 게다가, 이 취약점에 의해 공격을 당했을 때는 Zeroday Attack이 되므로 누구의 잘못이라고 말하기 어렵다. 또한 게시판 제작자 역시 자유롭게 이를 사용할 수 있도록 공개한 것이기에, 제작자 역시 근본적으로는 어떠한 책임도 지지 않는다.
Zeroday Attack
이미 널리 알려진 용어로 패치가 발표되기 이전에 공격 코드 및 공격 방식이 공개되는 것을 의미한다. Zeroday Attack은 이용자가 적은 응용프로그램에서는 종종 나타나곤 있지만, 그 수가 적어 파급효과는 그다지 크지 않다. 그러나 만일 많은 이들이 이용하는 윈도우에 대한 Zeroday Attack이 이뤄지게 된다면 지난‘1.25 사태’보다 훨씬 큰 혼란을 일으키게 될 것이다.
iframe 삽입 공격
그러면 어떻게 H사가 해킹을 당했는지 살펴보자. 앞의 시나리오에서 해킹이 이뤄진 곳은 바로 쪽지 메시지를 확인하는 과정이었다.(물론 게시물을 읽는 과정에서도 가능하다) 얼핏 보기에는 <화면 1>과 같은 일반적인 메시지 쪽지였지만, 제목 부분에 html tag를 사용할 수 있도록 되어 있어 <화면 3>처럼 ‘<iframe>’을 삽입할 수 있다. 즉 관리자가 쪽지를 확인했을 때 게시판 관리자 권한으로 get 방식을 써서 특정 페이지에 값을 전달하고, 관리자 패스워드를 변경해 게시판을 장악한 것이다.
tag에 나타난 것처럼 width와 height를 0으로 설정하면 frame 없이 일반 텍스트만 보여 김 대리가 전혀 눈치 챌 수 없었다. iframe의 소스에 사용된 URL과 각 변수 및 변수 값들은 OO보드의 특성을 알고 있고 Proxy tool을 이용한다면 어렵지않게 찾을 수 있다.
<화면 3> <iframe> 삽입
*모방을 통한 해킹을 방지하기 위해서 일부 코드를 모자이크 처리하였다.
iframe tag뿐 아니라, 이미지를 불러오는 img tag 역시 이와 같은 방법으로 이용될 수 있다. href tag를 통한 웹페이지 접근 방식은 속도를 개선하기 위해 web proxy를 운영한다. 이 경우 한번 불러온 페이지에 대해서는 서버에 직접 접근 없이 값을 가져오기 때문에 웹페이지에 값을 분명하게 전달하지 못할 수 있다. 그러나 img tag는 Real 서버에서 직접 이미지를 가져와야 하므로 Real 서버에 대한 확실한 접근을 보장한다.(이런 특징 탓에 과거에는 메일을 보낼 때 1×1의 작은 투명 이미지를 삽입하고, 이를 통해 메일 수신 여부를 확인하는 기능을 구현하기도했다)
이를 이용한 방법은 iframe 방식과 크게 다르지 않다. iframe tag 대신에 img tag로만 바꿔주면 되기 때문이다. 이처럼 간단한 방식의 해킹만으로도 한 회사에 막대한 피해를 끼칠 수 있음을 잊어서는 안될 것이다.
또한 H사의 경우처럼 방화벽만 있으면 모든 보안이 다 수행된다고 여겨서도 안 된다. 서비스를 위해 누구나 접근 가능하도록 any로 열어 놓는 80(web) 포트 등에는 언제나 보안에 해가 될 위험이 도사리고 있음을 기억하자. 이렇게 any로 열린 포트는 방화벽의 영향을 전혀 받지 않는다. 물론 이는 별도의 웹 방화벽이나, Apache의 ModSecurity를 이용하지 않았을 경우를 전제한다.
ModSecurity
ModSecurity는 Apache 웹 서버에 모듈 형태로 올려 이용할 수 있는 오픈소스 웹 방화벽이다. 서버에서 직접 운영되는 만큼, 외부 트래픽에 대한 영향이 없고 성능 또한 우수하다는 평가다. 이와 관련한 기술 문서는 한국정보보호진흥원의 boho.co.kr에서 제공하고 있다.(www.boho.co.kr -> 정보자료실 -> 기타정보보호 자료실 -> ModSecurity를 이용한 SQL Injection 공격 차단) 관심있는 독자들은 해당 기술문서를 참조해 적용해보길 바란다.
3가지 해결책
그럼 이와 같은 공격에 대해서는 어떻게 대응해야 할까? 다음의 세 가지 방법을 살펴보도록 한다.
첫 번째로 고려할 수 있는 것은 앞서 이미 언급한 바와 같이 최신 패치를 써서 혹시나 있을지 모를 서비스나 애플리케이션 상의 문제점을 없애는 것이다. 그러나 별도의 패치가 제공되지 않는 경우라면 다음의 방법들에 보다 주목할 필요가 있다.
두 번째로는 굳이 필요하지 않은 곳에서는 iframe이나 img tag 등의 html tag가 적용되지 못하도록 필터링 하는 방법이다. 리눅스에서 php를 사용하는 경우에는 <화면 4>와 같은 방법을 이용한다. html tag를 쓴 변수의 값이 적용되기 이전에 미리 html tag를 제거해주고, iframe이나 img란 단어가 나오면 xxxxxx, 혹은 xxx 등으로 변경해 iframe과 img tag에 의한 공격을 예방할 수 있다.
<화면 4> 리눅스에서 php를 이용하는 경우
<화면 4>에서 eregi_replace를 이용한 것은 iframe의 차단을 피하기 위해 대소문자를 섞어 쓰는 등의 변형된 공격을 막기 위한 것이다. eregi는 대소문자를 구별하지 않아 대소문자를 섞어 구현되는 우회 공격 방법을 예방해준다.
다음의 <화면 5>와 <화면 6>은 각각 <화면 4>의 필터링을 테스트하는 화면과 그 출력 결과다.
<화면 5> 필터링 테스트
<화면 6> 출력 결과
<화면 6>의 출력 결과 가운데 1번은 ‘< iframe>’으로 ‘<’ 다음에 한 칸을 비워 html tag 규칙에 맞지 않게 입력한 코드를 예로 든 것이다. 이 경우 html tag 제거 함수인 strip_tags 함수를 우회할 수 있었지만 <화면 4>의 eregi_replace 함수로 인해 iframe 문자열이 xxxxxx로 변경됐다. 또한 <화면 6>의 2번은 <화면 5>와 같이 html tag 규칙을 따른 html tag가 strip_tags 함수를 통해 말끔히 제거된 결과를 보여준다.
데이터를 입력받아 실제 데이터로 적용하기 전에 이처럼 간단한 코드를 삽입해 준다면, 악의적인 입력 값에 의한 공격과 피해를 크게 줄일 수 있다.
마지막으로 세 번째 방법은 admin page와 같은 중요 페이지를 다른 포트를 이용해 분리해주거나, 혹은 특정 IP만 접근하도록 설정하는 것이다. 또한 접근이 어렵도록 하기 위해 인증 기능을 포함시켜 ID와 패스워드를 요구할 수도 있다.
<화면 7>은 test.co.kr을 위해 웹(80) 포트가 아닌 8080 포트를 지정해 사용하는 방법을 나타낸다. 이와 함께 test.co.kr의 홈 디렉토리인 /home/test에 접근할 수 있는 IP를 211.239.xxx.xxx로 지정하는 방식도 함께 적용됐다. test.co.kr 도메인은 관리자만이 접근해야 하는 admin page를 담고 있는 중요 사이트. 따라서 앞으로는 이 사이트에 접근하기 위해 웹브라우저에 ‘http://test.co.kr:8080’을 입력해야 하고, 아울러 IP가 211.239.xxx.xxx인 사용자 PC에서만 이 사이트로 접근할 수 있다.
<화면 7> 8080 포트 지정과 IP 제한
지금까지 구체적인 시나리오를 통해 iframe을 이용하는 공격과 그 대응 방법에 대해 알아봤다.
나비효과, 잊지 말아야
많은 이들이 알다시피‘나비효과’란 개념이 있다. 이는 MIT의 로렌츠 교수가 발표한『브라질에 있는 나비 한 마리의 날개 짓이 텍사스에 토네이도를 일으킬 수 있을까?』라는 논문에 등장한 것으로, 대부분의 크나큰 일도 알고 보면 아주 미미한 출발점을 지닌다는 의미다.
이 나비효과는 프로그래밍 과정에도 그대로 적용된다. 설마하고 넘어간 한 줄의 코드가 끝내 회사를 문 닫게 할 엄청난 사건의 발단이 될 수 있다는 점을 마음속에 깊이 새기길 바란다. 같은 맥락에서 지금 자신이 맡아 수행하는 한 줄의 코딩이 회사의 미래를 좌지우지 할 중요한 일이라 여기고 각자의 일에 보다 큰 자부 심을 가졌으면 한다.
마지막으로, 본문에 언급된 OO보드에 보안상의 특별한 문제가 있음을 말하려 한 것이 아님을 강조하고 싶다. iframe과 같은 간단한 tag만으로도 충분한 해킹이 이뤄질 수 있고, 이를 통해 보안의 필요성을 상기시키려는 의도로 OO보드를 언급한 것이다. 이에 대한 오해가 없기를 바라며 이 글을 마친다.
From 마이크로소프트 [2006년 5월호]
제로보그 5 가 곧 나올예정입니다..
그냥 게시판형식이 아닌 사이트빌더 형식으로 말이죠..
기대되는 작품중 하나라죠..^^
댓글,
