웹 무른모의 위기와 SQL 인젝션...
2009/12/24 22:45
아래 칼럼 하나를 소개합니다. SQL 인젝션을 비롯한 웹 무른모에 대한 공격에 대해 경고를 하는 전상훈 님의 칼럼입니다.
[칼럼] 98년의 크리스마스
글에서 잠시 언급되었는데, Unu 라는 루마니아의 해커가 있습니다. 올 한 해동안 굵직한 보안 업체들의 웹사이트들을 해킹하고 공개해왔던 해커지요. 카스퍼스키, 시만텍, 엔프로젝트 등... 보안 관련된 곳만 집중적으로 노리고 있습니다. 최근에는 인텔을 공격했네요. Unu 가 주로 쓰는 기법이 SQL 인젝션입니다.
SQL 인젝션은 SQL 쿼리문에 특정 패턴의 코드를 삽입하여서 엑세스 권한을 얻거나 DB를 열람할 수 있는 기법입니다. 이전 글 "SQL Injection 하나면 절반은 먹고 갈까?" 에서 얘기했었지만, 웹에서는 이것이 정말 골칫거리입니다. 서비스를 위해서는 DB를 안 쓸 수 없고, 그러자니 SQL 문을 써야 하는데, 그러면 결국 SQL 삽입 공격에 의한 정보 유출을 피하기가 힘듭니다. 물론, 서비스 구축 단계에서 미리 이것을 염두에 두고 설계한다면, 피해를 입을 확률을 확연히 줄일 수 있겠지요.
몇몇 분들은 SQL 인젝션을 잡기술로 치부하곤 합니다. 분명히 이 공격기법에는 더 이상 새로운 기술이 나오지 않고 있습니다. 단지 이전까지 나왔던 방법들을 반복하고 있을 뿐이죠. 하지만 피해가 줄지 않는 것도 사실입니다. 오히려 피해 규모는 점점 커지고 있죠. 웹 무른모들의 SQL 인젝션에 관한 취약점들도 계속 공개되고 있습니다. Exploit Database 에는 SQL 삽입 공격에 대한 취약점들이 거의 매일 올라오고 있고, 어느 날은 10개도 넘는 취약점이 한꺼번에 공개되기도 합니다. 이 중에는 아직 고쳐지지 않은 것들도 상당수 있구요.
전상훈 님은 Unu 를 단순히 스크립트 키드로 말씀하셨지만, 저는 그가 스크립트 키드라고 하더라도 그가 해킹해서 공개하고 리포팅하는 의도를 존중합니다. 보안에 대해 전문적인 지식을 가진 보안 업체들의 웹사이트를 해킹함으로써 우리가 얼마나 안일했는지를 경고해주니까요. 보안 업체가 그 정도인데, 일반 웹 사이트들, 웹 무른모들은 어떨까요? 전상훈 님의 칼럼에서도 언급되었듯이 규모가 상상을 초월합니다. 이미 저는 물론이고, 지금 이 글을 보시는 분들의 개인정보는 노출되었다고 보는 게 옳습니다.
한국인터넷진흥원(KISA)에서는 이 때문에 캐슬(CASTLE)을 보급하고 있습니다. 이 캐슬을 서버에 설치하면 SQL 인젝션 같은 공격이 웹 무른모나 웹 사이트에 적용되기 전에 캐슬에서 먼저 처리되도록 하는 또 하나의 웹 무른모입니다. 일종의 웹 방화벽이라고 볼 수 있지요. 저도 예전에 캐슬 덕을 본 적이 있고, 몇몇 서비스 제공자에게 캐슬을 추천하고 있습니다. 효과는 분명히 있거든요. 하지만 캐슬을 한 번 거쳐서 데이터가 서비스에 전달되는 시간적인 간격이 단점으로 지적되고, 공격을 방어해주는 방법이 패턴에 의한 사전 방어라는 것도 지적되고 있습니다. 새로운 패턴에는 취약할 수 밖에 없지요.
그렇다면, 앞으로의 웹은 어떻게 흘러갈까요? 너무나 심하게 오염되어서 치외 격리 공간으로 지정될까요? 아니면 캐슬보다 더 뛰어난 방법으로 정화가 되어서 청정 구역이 될까요? 현실만을 본다면 전자의 경우가 확률이 더 높을 것 같습니다. 그리고 이것이 앞으로 보안을 공부하는 이들의 숙제가 아닐까요?
"0x01 까막눈의 보안소식" 분류의 다른 글
| 부경대 CERT-IS 인트로 영상 ver.2010 | 2010/12/10 |
| IP 주소와 MAC 값이 개인정보라고 생각하시나요? | 2010/10/24 |
| 까보소 :: 지금은 DLL 하이재킹 파티 중... | 2010/08/26 |
| 퍼징(fuzzing)을 이용하여 보안 취약점을 점검해본 적이 있나요? | 2010/08/22 |
| 까보소 :: 스마트폰 보안... 호들갑? | 2010/08/17 |
Trackback Address:http://hisjournal.net/blog/trackback/298
유명 사이트.. 보안.. 은행.. 정부... 침입은 할 수 있지만, 하지 말아야하기 때문에 하지 않는 것이라 생각입니다. 하더라도 조용히 해야한다고 생각이 되는데....(그냥 제 생각)
하지만 Unu는 하지 말아야할 것을 하면서, 그걸 또 공개하는 것이 조금 이상하다고 생각 드네요 ^^ (소심한 생각)
하지 말아야 해서 모두가 하지 않을거라고는 생각하지 않습니다. 누군가는 악용할 가능성이 분명히 있으니까요. 그렇기 때문에 그 전에 이렇게나마 취약점을 알려주는 게 미래 지향적인 관점에서 더 유익하다고 봐요. 물론, 일방적으로 공개하는 것에 대해서는 저도 이게 맞는건지 의구심이 들고, 저렇게 태연하게 블로깅을 할 수 있다는 사실도 신기합니다.
웹 방화벽으로는 한계가 있을 수 밖에 없습니다.
==============================================================
가장 큰 이유로 IPS나 웹방화벽은 성능상의 이유로 패턴매칭을 텍스트 서치
가 아닌 바이너리 서치를 한다는 점입니다.
쉽게 말해 대소문자 처리를 하지 못하는데 예를들어 패턴에 SELECT 를 넣
으면 SELECT 는 잡아 내지만 select 는 잡아내지 못한다는 점입니다.
직접 특수문자가 아닌 일반 영문자 까지 URL 인코딩 한 경우에는 더더욱 탐
지율이 떨어지게 됩니다.
DB는 대소문자를 구분하지 않습니다.
또한 웹서버는 자동으로 URL 디코딩을 합니다.
따라서 아래의 문자열들은 모두 DB에서 동일하게 인식됩니다.
공격자 웹서버 DB
SELECT SELECT
SelecT SelecT
select select
%53%45%4C%45%43%54 SELECT select
%53%65%6C%65%63%54 SelecT
%73%65%6C%65%63%74 select
S%45LECT SELECT
s%45lect sElect
IPS나 웹방화벽은 패킷이 웹서버에 도착하기 전에 먼저 검사를 합니다.
일반적으로 바이너리 패턴매칭을 한다면 SELECT 문자열 만으로도 대소문자.
URL인코딩 문자 등을 조합한 패턴은 수만가지가 나올 수가 있습니다.
==============================================================
위의 자료는 http://blog.dasom.pe.kr/attachment/ek060000000021.pdf 에서 발취한 것입니다. 글쓴이의 결론은 개발 소스 상에서 필터링하는 것이지요.
즉, 캐슬이나 WAF로는 한계가 있다는 뜻입니다.
참, 저와 공감되는 생각을 가지신 분을 보니 반갑습니다.
PS: 옆 링크중에 초보웹은 주소가 틀렸습니다. 수정하셔야 할거 같아요.
오웃! 좋은 가르침도, 잘못된 링크 알려주신 것도 정말 고맙습니다.