시작하면서 이 글이 사파이어 혹은 슬래머 웜 자체에 관한 분석은 아니라는 점을 분명히 합니다. 국내/해외의 많은 해커 및 윈도우즈 전문가 분들이 이미 선행해 주셨기 때문입니다. 신속하고 심도있는 분석을 해주신 분들께 감사의 말씀을 드리고 싶습니다.
이번 사태에 대한 전체적인 분석에 대해 말이 많습니다. 웜의 주요 행태만 간략히 살펴보자면,
이것은 일단 sendto함수를 열어서 임의의 아이피로 자신과 똑같은 코드(sql서버를 overflow시켜 감염시키는)를 빠른 속도로 보낸다는 것입니다.
실제로 이 웜은 많은 트래픽을 유발합니다.물론 서버나 PC의 성능에 따라 다르겠지만, 한 테스터에 의하면 감염된 서버가 10Mbps 대역폭을 일시에 폭주시킬 수 있다고 합니다.
그러나 이 웜이 1월 25일 인터넷 대란의 직접적인 원인은 아니었습니다. 물론 이 웜이 많은 트래픽을 유발하긴 하지만 우리나라 인터넷이 마비된 것은 KT의 DNS 서버가 원인을 알 수 없는 이유로 마비되었기 때문입니다.
이때문에 사건 초기 많은 분들이 DNS와 웜이 직접적인 상관 관계를 갖고 있을 것이라는 추측을 했었습니다.
그러는 동안, 기술적인 내용을 전혀 이해하지 못하는 언론사 기자들이 오보에 가까운 기사를 실으면서 원인규명은 시간이 갈수록 점점 혼란속에 빠져들었습니다.
많은 사람이 궁금해 하는 가운데, KT의 내부상황을 모른 채 "웜이 발생하였고, 그로 인해 DNS가 마비되었다"는 "현상"만을 놓고 여러 보안 전문가들이 다음과 같이 가능한 시나리오를 작성하기 시작했습니다.
1. DNS 서버가 죽은것이 아니라, 네트워크 장비들이 웜에 의해 죽었을 것이다.
2. DNS가 MS SQL 서버에 의해 관리되었을 것이다. SQL 서버가 다운되어 DNS가 마비되었다.
3. SQL 서버들이 웜에의해 UDP를 보냄과 동시에 DNS 질의를 해 DNS를 다운 시켰을 것이다.
4. 웜이 개인 PC에 직접적인 영향을 미쳐 PC끼리 DNS 질의를 하고, 그것이 DNS를 서비스거부상태에 이르게 했을 것이다.
모두가 KT의 내부 상황을 모르는 상태에서 생각해 볼 만한 시나리오입니다.
경쟁관계에 있는 몇몇 보안회사는 실험을 하는 과정에서 2안과 3안을 택해 언론에 발표를 했습니다.
그러나 전문집단이 참여한 실험 결과 3안과 4안은 옳지 않다는 것이 확인되었습니다.
3안의 경우 SQL서버는 1434에서 접속자에 대한 안내 데스크 역활만 하는데 그것은 DNS와 상관없이 작동한다는 것을 마이크로소프트 전문가가 확인시켜 주셨습니다.
또한 4안의 경우 웜에 직접적인 영향을 받는 PC는 그리 많지 않다는 것입니다. MSDE를 설치한 PC의 경우 SQL 모듈이 포함되어 SQL과 같은 동작을 한다는 것인데, 국내에 약 1만 카피 밖에 보급되지 않았다 합니다. 따라서 2천 3백만 인터넷 사용자 대부분은 1434 포트에 대해 아무런 반응을 하지 않습니다. 결국 문제가 있는건 SQL 서버뿐이었습니다.
따라서 1안과 2안이 유력해졌습니다.
그러던 중 전문가들은 KT의 익명의 관계자로부터 "reverse query의 증가로 인해 DNS 서버가 서비스 거부상태에 이르렀다" 는 정보를 접했습니다. 전문가들은 부랴부랴 1안과 2안 모두 버려야 했습니다. 원인과 현상이 위배되는 모순이 발생하기 때문입니다.
다시 주요쟁점은 DNS에 reverse query가 계속 유발되어 DNS가 불통이 되는것에 대한 설명으로 돌아왔는데, 이는 고정 ip 뿐 아니라 고객의 유동 ip 에서도 흘러 나왔다 합니다. 또, 감염된 SQL 서버를 한 대 치료할때마다 트래픽이 감소했다고 합니다.
전문가들은 또다시 술렁이기 시작했습니다. 그러면서 점차 다음의 의견에 수긍하게 되었습니다.
- KT내의 SQL서버가 감염되어 회사 내부뿐 아니라, 외부에도 엄청난 수의 임의의 UDP 패킷을 뿌렸다고 합니다(실제 한대의 서버는 초당 10M 이상의 UDP를 생성해냄.). 이 숫자는 10 * 1000 * 1000 byte / 367 byte = 2만 7천여개 패킷... 한시간만 해도, 2만 7천 * 3600 = 9억개의 패킷, SQL서버가 단 3대만이라 했을때, 9억 x 3 = 27억개 패킷이 뿌려지는 셈입니다.
파이어월 및 IDS는 그 구현 방법에 따라 차이는 있지만 일단 수상한 패킷을 감지하면 소스 및 목적 ip에 대한 reverse query를 해 로그에 기록하거나 모니터에 표시하는데, 한 파이어월 관계자에 따르면, 이벤트 모니터나 로그에 대한 reverse query는 바로바로 하는 것이 아니라 일정한 시간에 모아서 한다고 합니다.
일단 이렇게 많은 패킷에 대한 queue가 일정시간 동안 각 장비에 쌓이면, 파이어월을 비롯한 모니터링 장비들이 SQL이 무작위로 생성한 무시무시하게 많은 packet들에 대한 연속적인 reverse query를 했을 것입니다.
그리고 한편 이들 장비의 성능도 대단히 뛰어난 측에 속해 웜을 다 막은 시점에서도 DNS에 대한 reverse query에 대한 트래픽은 줄지 않았을 거라는 사실입니다(이는 KT가 설명한 상황과 크게 다르지 않습니다.)
특히 KT의 해외 도메인에 대한 query를 요청하는 혜화지국의 DNS가 마비된 것은 감염된 SQL 서버가 목적지를 임의의 ip로 생성해 내는 과정에서 만들어진 패킷이 국내에 없는 해외 IP로 인식, 해외 도메인을 처리하는 마지막 노드인 혜화지국에 reverse query를 돌렸기 때문입니다.
대략 초당 3천개의 reverse query만 처리할 수 있는 혜화지국은 이처럼 엄청난 패킷을 처리할 수 없었을 것이고 이로 인해 서비스 거부 현상이 일어났고 결국 이것이 인터넷 마비의 대란으로 이끌었다는 것입니다.
한편, 이번 원인규명의 과정 중 SQL 서버와 PC와의 관계가 주목되었습니다. SQL서버가 PC에 영향을 주어 DNS에 대한 부하를 일으켰을 것이라는 추측에 대해
"일부 MSDE가 깔린 PC에 한해서 있을 수 있는 일이지만 영향은 크지 않다" 그리고 "국내 2천 3백만 사용자가 쓰는 평범한 일반 PC에는 감염된 SQL서버 자체가 직접적인 영향을 미칠 수 없다"는 사실이 전문가의 확인과 실험결과로 입증되었습니다.
다만, 개인용 바이러스 탐지기나 파이어월, 모니터링 도구가 설치된 PC의 경우, ISP에 설치된 IDS나 파이어월이 DNS에 주는 부하효과를 낼 수 있습니다. 그럼에도 각 업체나 기관 실험자들이 이런 가능성을 고려하지 않았다는 건 심히 유감스런 일이라 하겠습니다.
결국 몇몇 업체의 과잉경쟁에서 유발된 해프닝으로 끝났지만, 민감한 상황인 보안을 다루는 회사라면 더욱 신중을 기했어야 하지 않나 하는 아쉬움을 남기기도 했습니다.
필자는 설명드리는 논리는 여러 해커 및 전문가와의 토론을 통해 얻은 결론입니다. 하지만 우리가 발견하지 못한 어떤 갑작스런 또 다른 요인에 의해 우리가 알고 있는 진실이 바뀔 여지는 항상 존재합니다. 그것을 "옳다", "그르다"로 판단하는 것은 읽는 이의 몫입니다. 다만, 이번 인터넷 대란에 최선의 노력을 했다는것 밖에는 드릴 말씀이 없습니다.
이번 사건이 우리나라 각계각층에서 보안의 중요성을 실감하고 보안지수를 한층 높이는 계기가 되었으면 하는 바램입니다. 또한 실질적인 대응체계를 갖춰 인터넷 강국이라는 명함을 어디다 내놓아도 부끄럽지 않을 진실한 인터넷 강국이 되었으면 하는 마음 간절합니다.
- frog 1/30/2003
frog@hackerslab.com
출처 : 해커스랩
이번 사태에 대한 전체적인 분석에 대해 말이 많습니다. 웜의 주요 행태만 간략히 살펴보자면,
이것은 일단 sendto함수를 열어서 임의의 아이피로 자신과 똑같은 코드(sql서버를 overflow시켜 감염시키는)를 빠른 속도로 보낸다는 것입니다.
실제로 이 웜은 많은 트래픽을 유발합니다.물론 서버나 PC의 성능에 따라 다르겠지만, 한 테스터에 의하면 감염된 서버가 10Mbps 대역폭을 일시에 폭주시킬 수 있다고 합니다.
그러나 이 웜이 1월 25일 인터넷 대란의 직접적인 원인은 아니었습니다. 물론 이 웜이 많은 트래픽을 유발하긴 하지만 우리나라 인터넷이 마비된 것은 KT의 DNS 서버가 원인을 알 수 없는 이유로 마비되었기 때문입니다.
이때문에 사건 초기 많은 분들이 DNS와 웜이 직접적인 상관 관계를 갖고 있을 것이라는 추측을 했었습니다.
그러는 동안, 기술적인 내용을 전혀 이해하지 못하는 언론사 기자들이 오보에 가까운 기사를 실으면서 원인규명은 시간이 갈수록 점점 혼란속에 빠져들었습니다.
많은 사람이 궁금해 하는 가운데, KT의 내부상황을 모른 채 "웜이 발생하였고, 그로 인해 DNS가 마비되었다"는 "현상"만을 놓고 여러 보안 전문가들이 다음과 같이 가능한 시나리오를 작성하기 시작했습니다.
1. DNS 서버가 죽은것이 아니라, 네트워크 장비들이 웜에 의해 죽었을 것이다.
2. DNS가 MS SQL 서버에 의해 관리되었을 것이다. SQL 서버가 다운되어 DNS가 마비되었다.
3. SQL 서버들이 웜에의해 UDP를 보냄과 동시에 DNS 질의를 해 DNS를 다운 시켰을 것이다.
4. 웜이 개인 PC에 직접적인 영향을 미쳐 PC끼리 DNS 질의를 하고, 그것이 DNS를 서비스거부상태에 이르게 했을 것이다.
모두가 KT의 내부 상황을 모르는 상태에서 생각해 볼 만한 시나리오입니다.
경쟁관계에 있는 몇몇 보안회사는 실험을 하는 과정에서 2안과 3안을 택해 언론에 발표를 했습니다.
그러나 전문집단이 참여한 실험 결과 3안과 4안은 옳지 않다는 것이 확인되었습니다.
3안의 경우 SQL서버는 1434에서 접속자에 대한 안내 데스크 역활만 하는데 그것은 DNS와 상관없이 작동한다는 것을 마이크로소프트 전문가가 확인시켜 주셨습니다.
또한 4안의 경우 웜에 직접적인 영향을 받는 PC는 그리 많지 않다는 것입니다. MSDE를 설치한 PC의 경우 SQL 모듈이 포함되어 SQL과 같은 동작을 한다는 것인데, 국내에 약 1만 카피 밖에 보급되지 않았다 합니다. 따라서 2천 3백만 인터넷 사용자 대부분은 1434 포트에 대해 아무런 반응을 하지 않습니다. 결국 문제가 있는건 SQL 서버뿐이었습니다.
따라서 1안과 2안이 유력해졌습니다.
그러던 중 전문가들은 KT의 익명의 관계자로부터 "reverse query의 증가로 인해 DNS 서버가 서비스 거부상태에 이르렀다" 는 정보를 접했습니다. 전문가들은 부랴부랴 1안과 2안 모두 버려야 했습니다. 원인과 현상이 위배되는 모순이 발생하기 때문입니다.
다시 주요쟁점은 DNS에 reverse query가 계속 유발되어 DNS가 불통이 되는것에 대한 설명으로 돌아왔는데, 이는 고정 ip 뿐 아니라 고객의 유동 ip 에서도 흘러 나왔다 합니다. 또, 감염된 SQL 서버를 한 대 치료할때마다 트래픽이 감소했다고 합니다.
전문가들은 또다시 술렁이기 시작했습니다. 그러면서 점차 다음의 의견에 수긍하게 되었습니다.
- KT내의 SQL서버가 감염되어 회사 내부뿐 아니라, 외부에도 엄청난 수의 임의의 UDP 패킷을 뿌렸다고 합니다(실제 한대의 서버는 초당 10M 이상의 UDP를 생성해냄.). 이 숫자는 10 * 1000 * 1000 byte / 367 byte = 2만 7천여개 패킷... 한시간만 해도, 2만 7천 * 3600 = 9억개의 패킷, SQL서버가 단 3대만이라 했을때, 9억 x 3 = 27억개 패킷이 뿌려지는 셈입니다.
파이어월 및 IDS는 그 구현 방법에 따라 차이는 있지만 일단 수상한 패킷을 감지하면 소스 및 목적 ip에 대한 reverse query를 해 로그에 기록하거나 모니터에 표시하는데, 한 파이어월 관계자에 따르면, 이벤트 모니터나 로그에 대한 reverse query는 바로바로 하는 것이 아니라 일정한 시간에 모아서 한다고 합니다.
일단 이렇게 많은 패킷에 대한 queue가 일정시간 동안 각 장비에 쌓이면, 파이어월을 비롯한 모니터링 장비들이 SQL이 무작위로 생성한 무시무시하게 많은 packet들에 대한 연속적인 reverse query를 했을 것입니다.
그리고 한편 이들 장비의 성능도 대단히 뛰어난 측에 속해 웜을 다 막은 시점에서도 DNS에 대한 reverse query에 대한 트래픽은 줄지 않았을 거라는 사실입니다(이는 KT가 설명한 상황과 크게 다르지 않습니다.)
특히 KT의 해외 도메인에 대한 query를 요청하는 혜화지국의 DNS가 마비된 것은 감염된 SQL 서버가 목적지를 임의의 ip로 생성해 내는 과정에서 만들어진 패킷이 국내에 없는 해외 IP로 인식, 해외 도메인을 처리하는 마지막 노드인 혜화지국에 reverse query를 돌렸기 때문입니다.
대략 초당 3천개의 reverse query만 처리할 수 있는 혜화지국은 이처럼 엄청난 패킷을 처리할 수 없었을 것이고 이로 인해 서비스 거부 현상이 일어났고 결국 이것이 인터넷 마비의 대란으로 이끌었다는 것입니다.
한편, 이번 원인규명의 과정 중 SQL 서버와 PC와의 관계가 주목되었습니다. SQL서버가 PC에 영향을 주어 DNS에 대한 부하를 일으켰을 것이라는 추측에 대해
"일부 MSDE가 깔린 PC에 한해서 있을 수 있는 일이지만 영향은 크지 않다" 그리고 "국내 2천 3백만 사용자가 쓰는 평범한 일반 PC에는 감염된 SQL서버 자체가 직접적인 영향을 미칠 수 없다"는 사실이 전문가의 확인과 실험결과로 입증되었습니다.
다만, 개인용 바이러스 탐지기나 파이어월, 모니터링 도구가 설치된 PC의 경우, ISP에 설치된 IDS나 파이어월이 DNS에 주는 부하효과를 낼 수 있습니다. 그럼에도 각 업체나 기관 실험자들이 이런 가능성을 고려하지 않았다는 건 심히 유감스런 일이라 하겠습니다.
결국 몇몇 업체의 과잉경쟁에서 유발된 해프닝으로 끝났지만, 민감한 상황인 보안을 다루는 회사라면 더욱 신중을 기했어야 하지 않나 하는 아쉬움을 남기기도 했습니다.
필자는 설명드리는 논리는 여러 해커 및 전문가와의 토론을 통해 얻은 결론입니다. 하지만 우리가 발견하지 못한 어떤 갑작스런 또 다른 요인에 의해 우리가 알고 있는 진실이 바뀔 여지는 항상 존재합니다. 그것을 "옳다", "그르다"로 판단하는 것은 읽는 이의 몫입니다. 다만, 이번 인터넷 대란에 최선의 노력을 했다는것 밖에는 드릴 말씀이 없습니다.
이번 사건이 우리나라 각계각층에서 보안의 중요성을 실감하고 보안지수를 한층 높이는 계기가 되었으면 하는 바램입니다. 또한 실질적인 대응체계를 갖춰 인터넷 강국이라는 명함을 어디다 내놓아도 부끄럽지 않을 진실한 인터넷 강국이 되었으면 하는 마음 간절합니다.
- frog 1/30/2003
frog@hackerslab.com
출처 : 해커스랩