태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

위기의 인터넷은 본궤도에.. 4월의 교훈

-bloter.net 기고컬럼입니다.

국내외적으로 유사한 해킹 사례가 거의 동시에 발생을 하고 국내는 물론 세계적으로 이슈가 된 사례는 흔치 않다. 국내의 금융사와 국제적 IT기업이라고 할 수 있는 소니에 대한 해킹과 피해 사례는 앞으로의 대응에 있어서 많은 시사점을 던져준다.

정확하게는 앞으로의 대응 보다는 지금 당장의 대응이 더 시급한 측면을 가지고 있다. 일전 언론사 기고 컬럼에서 홈페이지 해킹과 악성코드 유포 및 대응방식에 대한 경고를한 적이 있다.

1. 신규 공격코드를 이용해 SQL Injection 자동화 공격도구로 취약한  서비스들에 대해 직접적인 공격이 발생 된다.

2.  서비스를 통해 악성코드가 유포된다.

A. 유관기관에서는 악성코드 신고 접수 시에 악성코드 유포하는 도메인에 대한 차단을진행한다.

B. 백신업체에서는 악성코드의 패턴을 이용해 대응하는 백신을 제작하거나 업데이트 한다.

C. 신규 취약성을 이용할 경우에는 패치를 설치 하라고 언급이 되고 패치가 나오지 않을경우에는 그냥 기다린다.

D. 악성코드가 웹을 통해 감염이 되고 주변 네트워크로도 확산이 되는 것과 같은 특이한상황의 경우 별도의 방안들을 강구하도록 한다.  ( ARP Spoofing)

3. 악성코드의 변형이 유포  경우 – 2 항에 있는 A,B,C 항목은 계속 반복이 된다.


2011년 현재도 악성코드의 유포와 대응에서 사용되고 있는 일반적인 시나리오라고 할 수 있다. 이 시나리오 상에서 이미 사전단계로 생략하고 넘어가는 부분은 이미 공격이 성공하여 악성코드를 유포할 때에는 내부망에 있는 Database에 관한 정보는 다 유출된 것과 마찬가지이고 내부로 침입 할 수 있는 통로는 이미 열려져 있는 것과 마찬가지라는 점이다.     ( http://p4ssion.com/261 마이너리티 리포트 참고)


무엇이 문제?

일반적으로 웹서버에 대한 공격에 성공을 하게 되면 언제든 간편하게 들어 올 수 있도록 통로를 만들어 둔다. 이를 백도어라고 부른다.  백도어를 통한 피해사례는 아직 끝나지 않은 현대캐피탈의 사례에서 확인이 가능하다.

소니의 사례라고 다를까? (소니의 사례는 외신에서 언급한 기사를 참고)

현대캐피탈은 보안인증을 받았고 미국에서 사업을 하고 있는 소니의 경우는 PCI-DSS라는 기본적인 보안 절차를 모두 준수할 정도로 두 회사 모두 보안에 신경을 쓰고 역점을 두었음에도 불구하고 결론적으로 최악의 해킹 피해를 당했다고 볼 수 있다. 금융회사의 내부 고객 정보가 유출이 되고 신용카드 내역을 저장한 데이터와 모든 고객정보가 유출되는 사례들은 발생 할 수 있는 최악의 사례라고 보아야 한다. 소니의 경우 정보유출로 인해 피해를 입는 고객에게는 일인당 최대 100만불 (11억원)의 피해보상을 한다는 보도도 있었으며 앞으로의 향방이 더욱 큰 관심을 끌고 있다.

거대기업을 침몰시킬 수도 있는 단초가 인터넷에 노출된 별로 중요하지 않은 웹서버 하나를 통해서도 제공 될 수 있다는 증거로서 목격 하게 될 것이다.

4월에 대표적인 해킹 피해를 입은 두 회사 모두 피해의 지점은 동일하다. 외부에 노출된 웹서버들을 통해 내부망으로 침입이 된 사례이며 웹서비스에 대한 상시적인 보안관리와 문제점 해결을 위한 노력이 모든 외부 노출 서비스 부분에 대해 이루어 지지 않을 경우 막대한 피해와 자칫하면 몰락으로도 이어질 수 있는 사례라 할 수 있다.


문제부분

일반적으로 IT 서비스를 운용하는 회사에서는 여러 종류의 서비스를 활용하고 있다.  예전과 같은 Client/ Server 모델이 아닌 웹을 활용한 정보교환과 업무 활용이 일반적인 상황에서 외부에 노출된 웹 서비스들은 항상 위험을 내포하고 있다.

대표적으로 URL 상에서 SQL ( 데이터베이스 질의 언어) 구문을 입력하여 데이터베이스의 자료를 빼내거나 조작하는 유형의 취약성인 SQL Injection의 경우가 가장 큰 예로 들 수 있는데 직접적으로 내부망에 침입하고 자료를 빼내어 갈 수 있다는 점에서 가장 치명적인 문제라고 할 수 있다. 해결 방안으로는 특수문자의 입력을 막거나 길이제한을 모든 URL 상의 인자들에 대해서 적용을 해야 하는데 사람이 개발하는 이상 항상 빈틈은 있게 마련이다. 또한 웹서비스 운영 Application 자체의 취약성을 이용한 공격들도 일반적인데 이 문제의 경우 정기적인 진단으로도 충분히 문제 해결을 할 수 있으나 잦은 변경이 있는 웹페이지의 경우에는 정기 진단으로 하기에는 변화의 폭이 커서 어려움이 있다.

보안을 강화하고 중요시 하는 기업들의 경우에는 정기적인 진단과 점검을 일상적으로 수행한다. 여기에서 발생하는 문제는 예산과 인력, 시간상의 문제로 인해 우선순위를 정해서 점검을 하게 마련이다. 항상 1순위는 대표 사이트 및 고객이 직접 접근 하는 사이트 및 정보가 저장되는 사이트가 된다. 그 뒤의 순위는 업무용 시스템이나 중요도에서 ( 고객 접근 관점의 중요도) 떨어지는 시스템들이 된다. 여기에서 근본적인 문제가 발생 된다. 지금까지는 사용자들이 많은 즉 정문에 대해서만 이중, 삼중의 진단과 도구들이 설치가 되었다고 봐야 한다. 그러나 공격자들도 정문만을 이용할까?

지금의 공격자들이 보유한 공격도구의 상태는 전문화 되어있고 대규모적인 공격이 가능하도록 되어 있다.  즉 모든 범위에 대해서 단 한가지의 문제점을 찾는 것이 일반적으로 되어 있다는 것이다.  외부에 노출된 모든 부분에 대해 문제점이 있는지를 수시로 점검하고 문제가 발견되면 직접 침입을 시도하게 된다.  지금까지 보안점검을 받던 기업에서는 중요성 있는 서비스와 우선순위에 대한 기준점을 모두 바꾸어야만 가능한 상황에 처해 있다.


해결방안?

외부에 노출된 모든 서비스를 1순위로 놓아야 하고 그 이후 내부에 있는 서비스들에 대해서 선별적으로 순위를 조정 하는 것이 바람직하다. 그리고 한 가지 더 중요한 것은 일년에 몇 차례 하기도 힘든 전체 서비스에 대한 보안 점검을 상시적으로 해야만 현재 기업들과 인터넷이 처한 문제점을 해결 할 수 있는데 사실상 한계가 존재 할 수 밖에 없다.  단 몇 시간 만에도 코드상에 변경이 일어날 수 있는 웹 서비스에 대해 정기진단으로 가능 할 수 있을까 하는 의문을 가져야 한다.

이제 보안 진단과 서비스에 대한 시각과 패러다임을 바꾸어야만 생존이 가능하며 기업의 서비스를 안전하게 유지 할 수 있는 상황에 직면해 있다. 그 누구도 안전하지 않은 상황.. 특히 IT기업 및 인터넷을 활용한 비즈니스가 일반적인 기업이라면 대단한 경각심과 준비를 하지 않으면 안될 것이다. 보안기업들 조차도 웹 서비스가 해킹을 당해 정보가 유출 되는 마당에 안전할 곳은 대체 어디인가?

몇 년 전 경고한 위기의 인터넷은 이제 본 궤도에 올랐다. 4월은 시작이였을 뿐이다.

- 바다란 세상 가장 낮은 곳의 또 다른 이름.

Posted by 바다란

댓글을 달아 주세요