|
ANTON
|
2011-07-23 11:00:28, 조회 : 164, 추천 : 51 |
2003년 1월 25일 컴퓨터 대란은 DDOS공격 기법이 아니였다.
안녕 하세요 ^^ 안톤입니다.이번 1월 25일 국내 컴퓨터 대란에 대하여
주변의 정황 사항과 공격 기법그리고 취약 점에 대하여 분석후 몇자 적고자 합니다.
비록 허접 하더라도 이곳 저곳 분석 결과를 토데로 이루어 진것이니 참조만 하시기 바랍니다.
본내용은 언론과 NTQ및 보안 전문 솔루션측에있는 글과 사견을 함께 쓴것입니다.
우선 이번의 공격은 언론에서 애기하는 DDOS 공격방법이 아니였습니다.
흔히들 애기하지만 일반인들이 보기에는 DDOS 공격방법이라고 알고 있는 것으로 압니다만
전혀 그렇지 않다는 것을 말씀드리고 싶습니다.
지금부터 잡다한 애기는 피하고 본론부터 들어 가겠습니다.
사건의개요.
2003년 1월 25일 2시 20~45분경 혜화동 정보센타 DNS 공격시작 SQL웜 바이러스 대량유입
2003년 1월 25일 3시 30분경 비상 발동과 함께 구로전화국 데이타 센터로 서버 우회와 동시
한국통신 1시간내 복구 가능이라고 섯부른 결과 발표
2003년 1월 25일 4시 30분경 서버 다운!
^^ 대충 적었습니다.제가 현장에 있었던 것이 아니였기 때문에..맞나 모르것네...!^^
이번의 공격대상은 Resolution서비스 였다고 합니다.
아마 생소하게 생각하는 분들이 저 Resolution서비스가 무엇이나고 하시는 분들이 많을 겁니다.
쉽게 말씀드리자면 Resolution서비스는 SQL서버에 데이타를 저장하는 영역을 여러개로 나눌수 있는데
바로 이영역을 하나의 인스턴스라고 한다면 여러개의 DataBase를 나누어서 사용한다는 말과 같다고
볼수 있습니다.
좀더 쉽게 말씀드리자면 하나의 서버에 여러개의 DataBase를 구축하여 사용한다는 것으로
웹호스팅 업체나 일반 기업 또는 학내망의 경우 하나의 서버에 두개이상의 웹호스팅을 실시 할경우
흔히 쓰이는 방식입니다.여러분도 아시겠지만 SQL서버에 여러개의 DataBase가 존재 할때 1433포트를 이용한다는
것은 모두 알고 계시라고 봅니다.
예전에 SQL웜중 SPIDA라는 웜도 1433포트를 찿아 공격하는 방식이였죠? ^^
그런데 이번에 공격당한 포트는 1434 포트입니다.
아마 이해를 못하시는 분들이 있을 것 같아서 말씀드리는데 아니왜? SQL웜이면1433포트를 공격을 해야지
1434포트이냐?
이렇게 질문하시는 분들이 있을 것으로압니다.
자 그럼 제가 이곳에서 애기하고자하는 본론이 나온것입
니다.
바로 Resolution서비스를 응용한 취약점 입니다.
예를 들어 SQL서버에서 하나의 인스턴스를 가진 데이타 베이스가 있다고 가정합시다.
그렇다면 데이터 베이스의 인스턴스가 여러가 존재한다면 하나의 인스턴스를 호출하였을때
다른 데이터 베이스는 어디에서 호출이 되느냐 즉 하나의 서버에 특정 포트에 접속하는 방식이아닌
1434포트가 Resolution서비스가 되는 것입니다.
즉 1433포트가 읽기중이라면 다른 별개의 인스턴를 찿기 위하여 Resolution서비스가 이용이 되는 것이라고
보면됩니다.
대충 Resolution에대하여 언급하여 드렸구요.
이번 서비스 대란의 원인은 무엇인가? 여러분들의 원인적 기술분석 올라와 있더군요.
DDOS공격(서비스 거부공격) 와우 해커스에 강좌란에 가보시면 자세히 나와 있습니다.
이번 사건이 발생한 한국통신 혜화동 인터넷 센타의 DNS는 UNIX BIND를 쓰고있습니다.
언론에서 애기하였듯이 DDOS공격으로 서버가 죽었다고 발표 하였더군요.
즉 DNS의 쿼리가 순식간에 다량증가하여 트래픽을 감당못한 나머지 죽었다.
물론 외부적으로 보면 그렇게 볼수도 있습니다.
그렇지만 이번 사건의 경우 Resolution서비스의 문제임이 밝혀 졌습니다.
SQL서버에 보면 새로운 인스턴스를 추가하는 부분이 있는데 이곳에 보면 1434포트로 Resolution
을 위한 udp 패킷을 보내고 여기에 반응하도록 하는 부분이 있습니다.
그럼 여기서 새로운 인스턴스 추가 부분이 있을 것입니다.
새로운 인스턴스 추가를 누른다면 인스턴스 네임으로 나오는 여러개의 DB목록이 있는데 한참후에
올라오는 것을 볼 수가 있죠!
바로 이번 사건은 Resolution 서비스에 의해 서브넷의 범위를 벗어난 클래스 대역의 문제입니다.
서브넷 마스크 아시죠? 255.255.255.0~255 뭐 이런식으로 되어 있는 것 말입니다.
설마 잘모르신다고 하시는 분은 없을 것으로 압니다.
NTQ의 바다님의 말씀데로 라면 1434번 포트의 첫번째 바이트가 0x04이면 마운팅 쓰레드가 가동
이 마운팅 쓰레드의 감염을 시도하는 트래픽이고 1434포트는 감염된후 이루어지는 트래픽이라고 판단
이되는데 DNS의 쿼리 증가는 1434번을 통해 감염된 SQL서버가 공격 코드내에 SQL웜 살포 배포한분~
이 임의 제작한 계산된 임의주소로 단독 패킷인 0x0A를 보내면 자체 DB서버의 인트턴스를 쿼리하는 과정에
DNS의 쿼리가 급경증가하여 하늘나라로 간것이라고 합니다.
자세한 DNS쿼리 발생에 관하여서는 대략 이렇습니다.
하나의 인스턴스로 부터 Keep Alive 패킷을 받게 되면 패킷을 받은 Resolution서비스는 자신의
인스턴스를 호출하게 됩니다. 바로 SQL서버에서는 자체의 인스턴스를 구분하기 위한 정보를
가져 오게 되는 것입니다. 물론 여기에는 도메인정보와 IP도 포함이 되며 DNS쿼리가 일어나는 것입니다.
즉 무한 루프를 하고 있는 DNS쿼리를 수행하는 자체 또한 SQL 서버가 되는 것입니다.
바로 DNS를 다운시킨 직접적인 주범은 공격코드가 아닌 SQL 서버가 되는 것입니다.
마지막으로 자세한 부분은 더욱더 분석을 해보아야 하겠지만 직접 서버를 가져다 놓고 분석하지 않는한
단순한 SQL서버의 다운이라고 보기는 어렵다고 보아야 할것 같다.
여기서 한가지 사견을 밝히자면 SQL웜을 특정 공격의 유입은 홍콩측에서 이루어 졌다고 본다고한다.
물론 기본 적인 이번 사건의 소스코드는 일부분만 입수를 하였습니다.
물론 우리나라 뿐만아니라 외국도 상당한 피해를 입었다고 하더군요.
흠 저도 이러한 모든 분들께 애도를 표합니다.^^ 혹시라도 주식 사실 분이있다면 안철수나 하두리 바이러스 주식
사두시면 좋겠네요 뻐하하하...!
사건이 발생한 당일날 혹시나 도둑이 제발 저리다고 잠깐 긴장했었습니다.
동일 시간대 저도 공부차 시도중이 였는데...^^ 하루종일 얼마나 우울 하던지...별다른 결심을 하며
긴장 했었습니다.토요일날 쇼한 생각하면...ㅠㅠ 어쨌든 정확한 원인이 밝혀 졌으니 한시름 맘을 놓고
발뻣고 잘 것 같습니다.
부족한 제 의견(?) ^^ 종합의견 들어 주신것(?) 감사합니다. ^^
|
|
|
