• 경쟁사 웹 사이트 해킹 (1) – 상황설정
• 경쟁사 웹 사이트 해킹 (2) – 접근법, 상세 정보, 연쇄 공격
• 경쟁사 웹 사이트 해킹(3) – 공격 #1: 테스트
• 경쟁사 웹 사이트 해킹(4) – 공격 #2: 유효한 공격 방법
• 경쟁사 웹 사이트 해킹(5) – 인질 웹사이트 수정하기, 그 밖의 가능성, 연쇄공격 정리
• 경쟁사 웹 사이트 해킹(6) – 인질 웹사이트 수정, 그밖의 가능성, 연쇄공격 정리

————- o ————

대응책

본 절에서는 이 같은 연쇄 공격으로부터 보호하기 위해 취할 수 있는 다양한 대응책을 살펴본다.

자사에 관한 정보를 수동적으로 찾아보는 해커에 대한 대응책

한 가지 단순한 대응책은 자사에 관한 광고를 웹에 올릴 때 신중한 태도를 취하는 것이다. 뭐든지 인터넷이 올라가고 나면 아마 다시는 완전하게 떼어 낼 수가 없다. 이것이 바로 인터넷의 특성이자 메커니즘이다. 웹에 존재하는 회사에 관한 정보를 소극적으로 획득하는 다른 방법도 있다. 넷크래프트(Netcraft)를 예로 들면, 이 웹사이트에서는 웹 서버 IP 주소, 웹 서버를 가동 중인 운영체제, 해당 운영체제의 버전, 최근 서버가 재부팅한 시각과 같은 정보를 알아낼 수 있다. 다행히도 조금만 노력하면 이러한 정보를 노출되지 않게 할 수 있다. 모든 DNS와 연락처를 비공개로 하고 어느 도메인 등록 서비스를 사용하고 있는지 공개되지 않게 설정하는 것이다. 대부분의 웹 서버 플랫폼에서는 이러한 정보가 노출되는 것을 억제하거나, 더 나은 방법으로 이를 원하는 내용으로 설정할 수 있다. 어떤 정보를 공개하기 전에 회사나 직원들이 가장 먼저 물어야 할 질문은 간단하다. “왜 이 정보를 누구나 열람할 수 있게 만들어야 하는 거죠?”

ICMP를 이용한 DDoS 공격에 대한 대응책

대상 회사는 방화벽 하드웨어 제공업체의 권고로 ICMP를 통한 DDoS 공격에 최선의 대응책을 마련해뒀다. 웹을 비롯해 모든 장비에서 외부와 접촉하는 인터페이스를 대상으로 ICMP를 비활성화하는 것이 이제는 기초적인 표준 보안 실천 지침이 된 지 꽤 됐지만, 아직까지도 얼마나 많은 회사가 이러한 지침을 따르지 않는 것을 보면 정말 놀라울 따름이다. 최근 몇 년 동안 ISP에서는 DDoS 공격의 영향력을 최소화할 방법을 수립하기 시작했지만 여전히 그러한 공격을 예방하지 못하고 있다. 이런저런 이유로 웹사이트에서 외부에서 유입되는 핑을 허용해야 한다면 스크립트 솔루션이나 방화벽 솔루션으로 특정 시간 프레임 동안 일정한 핑 수를 초과했을 때 즉시 해당 IP 주소를 차단할 수 있다. 하지만 공격자가 진정한 DDoS 공격을 감행한다면 이러한 대응책의 효과도 상당수 줄어든다.

HTTP와 기타 프로토콜을 이용한 DDoS 공격에 대한 대응책

이것은 훨씬 더 어려운 일인데, 주된 이유는 단순히 특정 프로토콜 전체를 거부하거나 차단할 수는 없기 때문이다. 웹 서버가 HTTP 요청을 허용하지 못한다면 웹 서버로 기능할 수 있을까? 인터넷이나 네트워크상으로 통신하도록 고안된 장치가 TCP를 쓸 수 없다면 어떻게 통신 채널을 구성할 수 있을까?

이러한 질문의 답으로는 여러 가지가 있다. 그중 하나는 고도로 맞춤 제작된 스택을 쓰거나 만드는 것이다. 이는 개발과 유지보수 관점에서 굉장히 비용이 많이 들고, 대개 가장 안전한 환경에만 쓰는 방법이다. 다른 답으로는 한 호스트에 특정 시간 프레임 동안 일정한 양의 대역폭이나 일정한 개수의 연결만 허용하는 비율 제한(rate limiting)과 같은 기술이 있다. 또 최근 네트워크 장비에 적용되는 비율 제한 방법으로 특정 종류의 트래픽만 제한하는 것도 있다.

블랙홀 필터링(black hole filtering)은 의심스럽거나 악성 트래픽을 모두 널(null) 인터페이스나 존재하지 않는 인터페이스로 보내는 방법이다. 이렇게 해도 DDoS 공격을 막지는 못하지만 특정한 한 종류의 트래픽이 대량으로 범람하지 못하게 하는 데는 도움이 된다.

기업 네트워크로 향하는 모든 진입점에서는 유입 및 유출 필터를 구현해야 한다. 이러한 유형의 필터는 자사 네트워크로 위장 패킷이 들어올 가능성을 최소화한다.

이러한 해법에도 문제가 하나 있다. 즉, 이런 해법들은 모두 애초부터 회사에서 웹사이트를 구축하는 이유에 배치된다는 것이다. 원래 웹의 비전은 공개, 자유, 쉬운 접근에 있었다. 우리는 그러한 웹의 비전은 완수했지만, 지금은 보안 분야 종사자에게 웹을 보호하는 일을 맡기고 있다. 이는 700개의 활짝 열린 문이 달린 맨션을 만들어 놓고 두 명의 경비원에게 경비를 맡기는 것이나 마찬가지다. 피닉스는 대상 웹사이트에서 제한하거나 허용하는 요소를 짐작해야 했지만 네트워크 경계에 있는 다양한 하드웨어, 그리고 서버 측 소프트웨어에는 기본적인 연결 제한 말고는 크게 특별한 것은 없으리라 가정했다. 다시금 ISP는 DDoS 완화와 그것의 영향력을 최소화하는 분야에서 진일보하는 중이다. 회사에서 이러한 종류의 공격을 예방하는 데 관심을 보인다면 ISP나 통신 회사와 함께 그와 같은 문제에 관해 논의해 보길 권장한다.

허가되지 않은 사이트 수정에 대한 대응책

본 장에서 알아본 시나리오에서 책임의 상당수는 인질 회사(allputerstuff.com)에 있는데, 그 까닭은 이 회사의 사이트에서 악성 인라인 프레임을 호스팅하고 있었기 때문이다. 자사 웹사이트를 협력 업체가 수정, 구축, 갱신하는 기업일 경우 보호할 웹사이트에 어떻게 접근하는가에 관한 정보 보안 조항과 설명을 요구하도록 정책이 마련돼 있어야 한다. 정보를 어떠한 디지털 형태로 저장하지 않으면 해커나 악의적인 사용자, 또는 단체로부터 해당 정보를 보호할 수 있다는 것은 흔히 볼 수 있는 오해에 불과하다.

이거 불법 아냐?: 일상을 파고드는 해킹 스토리(앤드류 휘테이커 외 지음, 이대엽 옮김)

아울러 다른 방법으로 웹사이트 변경을 검사하는 수단도 마련돼 있어야 한다. 일반적으로 통용되는 관례는 웹사이트 유지보수나 디자인을 협력 업체에서 담당하고 있다면 해당 업체에 웹사이트에 대한 모든 변경을 허가해야 한다는 것이다. 이는 보통 계약서에 명시돼 있다. 문제는 실제로 이러한 방법을 시행하는 데 있다. 한 가지 해법은 일회용 비밀번호, 즉 딱 한 번만 쓸 수 있는 미리 생성된 비밀번호 목록을 쓰는 것이다. 이 목록은 웹사이트 소유자(여러분이 근무하는 회사)에게 있어야 한다. 웹사이트를 수정하려면 협력 업체는 웹사이트 소유자에게 문의해서 목록에서 다음으로 쓸 비밀번호를 전달받아야 한다. 이렇게 하려면 협력 업체는 웹사이트를 변경하기 전에 반드시 해당 웹사이트 소유자에게 연락을 취해야 한다. 이렇게 했다면 피닉스가 웹사이트 디자인 회사의 관리인을 매수해 시도하려던 공격은 아무런 결실도 거두지 못했을 것이다.

우리는 오늘날 우리가 알고 있는 컴퓨터가 있기 전에도 범죄, 절도, 해커가 있었다는 사실을 잊곤 한다. 그리고 본 장에서 보여준 바와 같이 allputerstuff.com 웹사이트를 침해하는 일은 갖가지 기술적인 도구나 기법을 전혀 동원하지 않고도 일어났다. 사이트를 훨씬 더 안전하게 만들려면 기업 웹사이트에서 어떤 부분을 수정하더라도 강제적인 이중 요소 인증이 필요할 수도 있다. 이를 제공하지 못하는 협력 업체에서 사이트를 호스팅하고 있다면 다른 업체를 찾아보는 편이 더 바람직할지도 모른다. 페이팔(PayPal)에서 수백만에 이르는 고객이 페이팔을 이용해 결제할 때 이중 요소 인증을 쓸 수 있다면 호스팅 업체에서는 반드시 고객에게 이중 요소 인증을 제공할 수 있어야 한다.

내부 직원에 의한 침해에 대한 대응책

피닉스가 브렛의 로그인 정보를 훔치는 것에 관해 그렉에게 접근했을 때 이미 피닉스는 사무실을 자세히 살펴보고 주위에 감시 카메라도 없고, 브렛의 서류함에도 자물쇠가 장착돼 있지 않다는 사실을 알고 있었다. 일반적으로 비밀번호를 서류 형태로 보관하는 것은 바람직하지 않다. 이러한 비밀번호는 디지털 형태로 저장하고 암호화와 강력한 접근 제어를 기반으로 보호해야 한다. 이는 브렛이 그러한 비밀번호를 자기만 쓰는 PC에 보관하고 해당 PC도 잠가야 한다는 뜻이다. 게다가 브렛이 근무하는 회사에서는 아마 의무적으로 암호화된 하드디스크 정책도 구현해야 할 것이다.

보통 관리인은 아무런 제한도 받지 않고 언제든지 모든 곳에 접근할 수 있으므로 접근에 앞서 반드시 취해야 할 절차가 있어야 한다. 브렛의 사무실에 들어가기 위해 출입 카드를 써야 했다면 관리인은 별로 도움이 되지 않았을 것이다. 관리인이 출입 카드를 써야 하고 모든 접근 기록이 기록된다면 좋은 대비책이라 할 수 있다. 그렇게 되면 특정 일자의 특정 시각에 해당 사무실에 접근한 것을 손쉽게 역추적할 수 있다는 사실을 관리인도 알기 때문이다. 업무 분장과 최소 권한 원칙도 내부 보안에 매우 중요하다. 예를 들면, 하루 종일 건물 안에서 일하는 시설관리인은 업무 시간이 끝나면 야간에 일하기로 한 누군가와 교대하게 할 수도 있다. 이렇게 하면 야간에 일하는 사람들은 주간에는 어떤 일이 일어났는지 전혀 알지 못한다.

결론

본 장에서는 일부러 대상 회사를 목표로 DDoS 공격을 감행하는 데 쓰는 멋진 도구를 아무것도 소개하지 않았다. 이제 프로토콜에 대한 철저한 이해와 일상적으로 쓰는 기술을 활용하는 것만으로도 가장 효과적인 해킹을 해낼 수 있다는 사실을 깨달았을 것이다. 본질적으로 피닉스는 수천 명의 사람들이 HTTP GET 요청을 대상 웹 서버에 하게 만드는 것으로 해킹에 성공했다. 다시 말해서, 피닉스는 단지 수많은 사람이 반복적으로 대상 웹사이트에 접속하게 한 것밖에 없다는 뜻이다. 이를 단지 엄청난 양의 트래픽과 구분하기는 대단히 어려울 것이며, 더 중요한 점은 일단 공격이 시작되면 이를 중단시키기가 훨씬 더 어렵다는 것이다.

DoS와 DDoS 공격은 아주 오래 전부터 있었지만 대부분의 웹사이트는 여전히 이러한 공격에 취약하다. 이 공격에 관해 지난 몇 년 동안 고객과 이야기해본 결과 고객들은 대부분 그런 공격이 자신들에게는 일어나지 않을 것 같아 아무런 조치도 취해본 적이 없다고 했다. 전형적인 DDoS 공격은 공격자가 통제하는 웹 서버나 공격자의 컴퓨터로 직접 연결하는 트로이 목마를 수천 대의 컴퓨터에 감염시켜 컴퓨터를 인터넷 좀비로 만드는 과정을 거치거나, IRC 채널에 접속해 어쩔 수 없이 IRC 봇넷(botnet)의 일부를 구성하게 한다. 요즘은 궂은일을 대신해줄 이러한 봇(bot)을 몇 천 개에서 몇 만 개나 임대할 수 있는 채널과 사이트가 말 그대로 수백 개에 달한다. 봇은 이미 감염돼 있는 상태이고 이미 봇 마스터(bot master)의 통제하에 있으며, 공격을 개시하기만을 기다리고 있다. 준비 작업이 모두 끝나면 공격자는 단지 특정 IRC 채널에 접속해 공격을 시작하기만 하면 된다.

이 같은 문제는 분명 대부분의 사이버 전쟁에서 이뤄지는 방어가 그렇듯이 DDoS 공격에 대한 방어가 예측 가능한 방식으로 이뤄지고 쉽게 간파 당하기 때문에 앞으로도 사라지지 않을 것이다. DDoS 공격에 대한 최선의 방어는 최신 경향과 방법론을 지속적으로 습득하고 인프라 수준에서 네트워크 경계나 ISP 수준에서 최선의 노력을 기울여 대역폭과 접속이 원활하게 만드는 것이다. 또한 기본 도메인을 대신할 대체 도메인을 확보해서 언제든 예고 없이도 그러한 대체 도메인 가운데 하나로 옮길 준비를 해두는 것도 좋다. 이러한 공격에 대비하기 위해 합심해서 공동의 노력을 기울이거나 방어체계를 구축하려는 시도도 여럿 있다. 그중 몇 가지를 들어보면 Prolexic(www.prolexic.com), Radware(www.radware.com), Top Layer(www.toplayer.com)가 있다. 이러한 노력과 시도 외에도 많지만 본 장의 저자는 이 세 회사에서 직접 근무한 적이 있다.

(이것으로 “경쟁사 웹사이트 해킹” 연재를 마칩니다)

• 경쟁사 웹 사이트 해킹 (1) – 상황설정
• 경쟁사 웹 사이트 해킹 (2) – 접근법, 상세 정보, 연쇄 공격
• 경쟁사 웹 사이트 해킹(3) – 공격 #1: 테스트
• 경쟁사 웹 사이트 해킹(4) – 공격 #2: 유효한 공격 방법
• 경쟁사 웹 사이트 해킹(5) – 인질 웹사이트 수정하기, 그 밖의 가능성, 연쇄공격 정리

————- o ————

인질 웹사이트 수정하기

현 시점에서 피닉스는 가능한 테스트를 모두 마쳤다. 이제 www.allputerstuff.com을 호스팅하는 웹 서버로 접속해 실제로 홈 페이지를 변경할 차례다. 이를 위해 피닉스가 취할 절차를 살펴보자.

• www.allputerstuff.com으로 접속해서 홈 페이지를 내려 받는다.
• 내려 받은 allputerstuff 홈페이지의 HTML에 인라인 프레임을 집어넣는다. 이 인라인 프레임은 피닉스가 테스트할 때 썼던 www.google.com 대신 www.thetrughsa.org를 요청할 것이다.
• 웹 서버상의 원본 홈 페이지를 인라인 프레임이 포함된 수정 버전으로 대체한다.
• 이제 www.thetruthsa.org에서 HTTP 요청을 더는 처리할 수 없다고 나오는 것을 지켜보기만 하면 된다.

드디어 인질 웹사이트의 사본을 올릴 준비가 끝났다. 피닉스는 인터넷 익스플로러를 열고 익명 서비스를 제공하는 곳에 접속한 후 www.allputerstuff.com으로 들어갔다. 페이지가 열리자 인터넷 익스플로러의 보기 메뉴를 클릭한 다음 소스를 선택했다. 메모장 창이 열리고 해당 웹사이트의 소스 코드가 나타났다. 피닉스는 소스 코드를 수정하기 시작했다.

다음으로 전에 테스트할 때 썼던 hacked.html 파일을 열었다. 그런 다음 www.google.com을 www.thetrughsa.org로 바꾼 다음 인라인 프레임 텍스트를 복사해서 아까 메모장에 열어 둔 www.allputerstuff.com의 HTML 문서에 붙여 넣었다. 피닉스는 방금 수정한 페이지가 어떻게 보이고 인라인 프레임이 보이는지 재확인할 겸 지금 쓰고 있는 PC에서 먼저 테스트해보고 싶었다. 피닉스는 수정한 www.allputerstuff.com의 웹 페이지 파일을 바탕화면에 저장한 후 파일을 더블 클릭했다. 인터넷 익스플로러에서 새 창이 열리고 아래 그림과 같은 페이지가 나타났다.

인터넷 익스플로러에서 수정된 www.allputerstuff.com 웹사이트를 연 화면

페이지에서 이미지가 나타나야 할 곳에 빨강색 X가 나타나자 피닉스는 깜짝 놀랐다. 잠시 후 피닉스는 자기 이마를 살짝 치면서 뭐가 잘못됐는지 알아차렸다. “진정해, 피닉스. 이미지를 이 PC에 저장하지 않았으니 당연한 거잖아.” 인라인 프레임은 어디에도 나타나지 않았다. 와이어샤크에서 새로운 캡처 세션을 열어보니 아니나 다를까 www.thetruthsa.org로 향하는 HTTP 요청이 있었다.

“좋아, 성공한 것 같네.” 피닉스는 그렇게 말하고 침착해지려고 노력했다. 아드레날린이 작용하기 시작해서 피닉스의 손바닥과 이마는 이미 땀으로 젖은 상태였다. 이제 allputerstuff.com 웹 서버로 로그인해서 기본 홈 페이지를 수정한 버전으로 교체해야 한다. 책상 위에 있는 탁상시계를 흘깃 쳐다보니 오전 5시 45분이었다. “딱 좋은 시간이군.” 피닉스가 중얼거렸다. 단 몇 시간 후면 사이트에 트래픽이 올라가기 시작할 테고 오전 8시까지는 thetruthsa.org를 접속 불가능하게 만들어야 한다.

이거 불법 아냐?: 일상을 파고드는 해킹 스토리(앤드류 휘테이커 외 지음, 이대엽 옮김)

다음으로 피닉스는 FTP 클라이언트를 실행했다. 그렉이 복사해준 문서를 훌훌 넘겼다. 세 번째 페이지에서 allputerstuff.com이라는 이름이 보였다. 웹사이트 이름 바로 옆에는 사용자명과 비밀번호로 각각 bbking과 ngbTyz45opw$라 적혀 있었다. “음, 그래도 비교적 강력한 비밀번호를 썼군.” 피닉스가 속으로 생각했다. 그런 다음 FTP 클라이언트로 고개를 돌려 호스트명으로 ftp.allputerstuff.com을 입력한 후 사용자명으로 bbking을, 비밀번호로 ngbTyz45opw$를 조심스럽게 입력했다. 비밀번호까지 입력한 후 피닉스는 숨을 깊게 들이마시고 FTP 클라이언트에서 접속(Connect) 버튼을 클릭했다. FTP 클라이언트 소프트웨어에서는 바이너리 데이터를 비롯해 그밖에 FTP 서버에서 일반적으로 볼 수 있는 메시지가 접속 상태를 알리는 효과음과 함께 나타났다. 서버에 접속한 피닉스는 웹 서버의 내용을 살폈다.

“별 거 없네.” 피닉스가 말했다. “더 안전한 서버에는 온갖 좋은 건 다 들어 있을 줄 알았더니.” 이러한 생각이 피닉스의 머릿속을 스쳤다. 곧바로 피닉스는 수정한 index.html 파일을 바탕화면에서 선택해 웹 서버의 내용을 보여주는 FTP 클라이언트 창에 끌어다 놓았다. 그러자 “이 파일은 이미 존재합니다. 덮어쓰시겠습니까?”라는 메시지가 나타났다. 피닉스는 “예”라고 적힌 버튼을 클릭하고 그렇게 해서 www.allputerstuff.com의 홈 페이지는 피닉스가 수정한 버전으로 바뀌었다.

“이제 남은 건 시간 싸움이군.” 피닉스는 의자를 뒤로 젖히고 크게 하품을 한 뒤 두 팔을 쭉 뻗었다. 그러고 나서 www.thetruthsa.org로 들어가 무슨 일이 일어나지는 않았는지 확인했다. 페이지는 정상적으로 열렸다. 다시 한 번 시계를 쳐다보니 시계는 오전 6시 19분을 가리키고 있었다. “아직까진 www.allputerstuff.com에 들어간 사람이 얼마 없나 보네.” 피닉스는 아침도 먹을 겸 한 시간쯤 후에 돌아와서 상태를 확인하기로 했다.

맥도날드에서 아침 메뉴를 먹고 신문을 읽은 다음 아파트로 돌아와 시계를 보니 오전 7시 45분이었다. “좋아, 이제는 무슨 일이라도 있어야 할 텐데.” 피닉스는 웹 브라우저 캐시를 비우고 www.thetruthsa.org 웹사이트로 다시 들어갔다. 페이지가 열리긴 했지만 전보다 약간 느리게 열렸다. 거의 30초를 다 채우고 나서야 뭔가가 나타났다. 피닉스는 왜 아직까지도 사이트가 다운되지 않았는지 생각했다. “아직까지도 allputerstuff.com으로 가는 트래픽이 충분하지 않은 모양이군.” 피닉스가 중얼거렸다. 샤워한 지 이틀이 넘었다는 생각이 들자 피닉스는 욕실로 가서 뜨거운 물로 오랫동안 샤워를 했다. 시간이 좀 지난 후 욕실에서 나온 피닉스는 몸을 말리고 다시 컴퓨터 앞에 앉았다. 웹 브라우저를 열어 주소 입력란에 www.thetruthsa.org를 입력했다. 그러자 성공을 나타내는 아래 그림과 같은 화면이 나타났다.

접속 불가능한 www.thetruthsa.org

“게임 끝!” 피닉스가 말했다. 피닉스는 확실히 해둘 목적으로 새로고침 버튼을 몇 번 클릭해 보기도 하고, 다른 컴퓨터에서 해당 웹사이트로 들어가 보기도 했다. 같은 결과가 나타나는 것을 보고 피닉스의 얼굴에는 미소가 가득했다. 피닉스는 또 한 번 자신과의 대화를 시작했다. “사이트 운영자들이 무슨 일이 일어났는지 알아내고 고치는 데 얼마나 걸릴지 궁금하군. 그 사람들은 분명 무슨 일이 벌어지고 있는지 내부적으로 알아내거나 이를 중단할 만한 기술이 없을 거야. 곰곰이 생각해 보니 뭘 해야 할지 단서를 잡는 데도 일주일 정도 걸리겠는데. 내가 집어넣은 인라인 프레임은 IP가 아니라 URL로 요청하니까 서버를 다른 걸로 교체하거나 DNS 레코드를 바꿔도 소용없으니 인라인 프레임은 URL을 해석하는 대로 계속해서 페이지를 가져오겠지. 사이트 운영자들은 allputerstuff.com을 방문하는 사람이라면 누구나 HTTP 요청을 보낼 테니 공격이 어디서 비롯되는지 추적할 가능성도 희박할 테고. 그나마 가장 가능성 있는 건 보안팀의 실력이 좋은 안전한 네트워크에서 누군가가 allputerstuff.com에 접속했을 때 보안팀 사람들이 무슨 일이 벌어지고 있는지 알아내는 거겠지. 그렇지만 그 사람들이 실제로 www.thetruthsa.org에 근무하는 사람한테 이러한 사실을 알릴 가능성은 거의 없어. 그 사람들은 아마 사이트를 차단하거나, 혹은 실제로 내부 장비를 검사해보고 allputerstuff.com 자체를 차단하는 걸로 그칠 거야. 누군가가 allputerstuff.com에 연락해서 자사 웹사이트가 어떤 비영리기관을 대상으로 DDoS 공격을 하는 데 쓰이고 있다고 알려주면 문제가 아주 잘 해결되겠지. 그렇지만 설사 그렇다 쳐도 누군가가 HTML 코드를 보고 실제로 무슨 일이 일어나고 있는지 알아내야 할 거야. allputerstuff.com에서 근무하는 사람이 그냥 내가 올린 파일을 원본 파일로 대체할 수도 있지만 내가 만든 버전이 웹과 브라우저 캐시에 온통 저장돼 있으니 여전히 문제는 있고, 이 정도면 www.thetruthsa.org를 48시간 동안 다운된 상태로 만들어 달라는 의뢰인의 요구에 꽤 부합하는 셈이니 이제 의뢰인한테 전화해서 나머지 사례비를 받아야겠다.”

그 밖의 가능성

피닉스의 주된 목표는 단순히 www.thetruthsa.org를 다운시키는 것이었지만 훨씬 더 많은 방법을 동원해서 다운시킬 대상뿐 아니라 그가 침해해서 인라인 프레임을 집어넣은 웹사이트까지도 망가뜨릴 수 있었다. 피닉스가 단순히 웹사이트를 여러 곳에서 여는 인라인 프레임을 집어넣는 대신 인라인 프레임에 직접 개조한 트로이 목마를 실행하게 하는 것을 집어넣었다고 생각해보라. 아니면 인라인 프레임 소스가 피닉스가 웹상의 FTP 서버에 올려둔 키로거 엔진이라면? 애꿎은 allputerstuff.com이라는 회사만 자사 웹사이트를 방문하는 이들에게 트로이 목마를 실행하는 것으로 보이지 않을까? 실제로 이렇게 되는 것도 가능하다. 웹사이트 주인이 피닉스가 수정한 사항을 알고 있느냐와는 관계없이 그들도 부분적으로 책임을 져야 할 것이다. 하지만 문제의 핵심은 (대다수는 아니더라도) 많은 사용자를 비롯해 심지어 시스템 관리자까지도 단지 귀찮다는 이유만으로 ActiveX와 자바 애플릿을 확인도 안 하고 실행한다는 것이다. 신원 도용과 신용카드 사기 측면에서도 가능성은 무한하다.

연쇄 공격 정리

다음은 피닉스가 이 연쇄 공격을 달성하기 위해 밟은 단계다.

1. 수동적인 사전조사를 통해서도 정보를 수집할 수 있었다. 이 경우 단순 구글 검색만으로도 충분했다. 여기엔 고등학생들이 웹사이트를 만들었다는 사실과 구현에 관한 몇 가지 기술적인 세부사항이 포함된다.
2. Freak88이라는 DDoS 도구로 견고한 DDoS 공격 계획을 세웠다.
3. 사전조사를 좀 더 수행해서 대상 웹 서버에서 ICMP를 차단하고 있다는 사실을 알아냈다.
4. 합법적인 HTTP 트래픽을 써서 대상 사이트를 다운시키는 것으로 공격 계획을 수정했다.
5. 인질 역할을 할, 방대한 대역폭과 상당한 양의 트래픽을 자랑하는 회사를 찾아냈다.
6. 웹사이트 페이지의 “designed by” 광고를 토대로 인질로 쓸 웹사이트를 담당하는 웹 디자인 회사를 손쉽게 알아냈다.
7. 인질 웹사이트의 계정을 사회공학적인 관점에서 확보할 수 있을지 확인할 목적으로 웹 디자인 회사를 방문했다.
8. 보수가 형편없는 관리인을 매수해 웹 디자인 회사 내부의 기밀 문서에 접근했다.
9. 공격을 연습할 수 있는 시험 환경을 구축했다. 그러고 나서 HTML 코드에 보이지 않는 상태에서 대상 웹사이트를 여러 곳에서 요청하고 5초마다 요청을 새로고침하는 인라인 프레임을 제작했다.
10. 관리인을 통해 훔친 인증정보로 인질 웹사이트에 접근했다.
11. 인질 웹사이트의 원본을 인라인 프레임이 포함된 버전으로 교체했다.
12. 대상 사이트가 실제로 인질 웹사이트의 방문자로 인한 과도한 트래픽으로 접속 불가능한 상태가 될 때까지 대상 페이지를 열람했다.

(다음 글에서 계속 이어집니다)

• 경쟁사 웹 사이트 해킹 (1) – 상황설정
• 경쟁사 웹 사이트 해킹 (2) – 접근법, 상세 정보, 연쇄 공격
• 경쟁사 웹 사이트 해킹(3) – 공격 #1: 테스트
• 경쟁사 웹 사이트 해킹(4) – 공격 #2: 유효한 공격 방법

————- o ————

모의 해킹 실험

대부분의 성공적인 해커와 침투 테스터들이 증명하듯 어떠한 해킹이나 공격도 그것을 실제로 실행하기 전에 모의 환경에서 실험해 보는 것이 중요하다. 공격 대상 내부에 침투한 후 해킹을 배운다는 것은 대단히 어리석은 짓이다. 보통 어떤 해커가 그렇게 한다면 아마 그는 사전조사를 충분히 하지 않았을 것이다.

집으로 돌아온 피닉스는 곧바로 책상에 앉아 실제 공격을 위한 기술적인 측면을 검토하기 시작했다. “먼저 모의실험을 해봐야겠어.” 이렇게 생각한 피닉스는 윈도우 2003 서버가 가동 중인 테스트 장비로 갔다. 그러고 나서 메모장을 열어 “hacked”라는 메시지를 보여주는 간단한 HTML 페이지를 만들어 C:\inetpub\wwwroot에 저장했다. 이어서 이 페이지를 호스팅하도록 마이크로소프트 IIS(Internet Information Services) 설정을 구성하기 시작했다. 아래 그림에 나온 것처럼 시작, 관리 도구, 인터넷 정보 서비스 관리를 차례로 클릭했다.

테스트 웹사이트를 구축하기 위한 IIS 설정

다음으로 서버명 왼쪽에 있는 + 기호를 클릭했다. 그러고 나서 아래 그림에 나온 것처럼 아래에 있는 기본 웹사이트 아이콘에 대해서도 같은 식으로 + 기호를 클릭했다.

기본 웹사이트 화면

이번에는 기본 웹사이트 아이콘을 선택하고 마우스 오른쪽 버튼을 클릭한 후 등록정보를 선택했다. 등록정보 창이 나타나자 문서 탭을 선택했다. 거기서 추가 버튼을 클릭하고 앞서 저장한 HTML 파일명을 입력했다. 이어서 아래 그림처럼 해당 파일이 목록의 가장 위로 올라올 때까지 위로 이동 버튼을 반복해서 클릭했다.

선택한 HTML을 기본 웹 페이지로 설정

그러고 나서 디렉터리 보안 탭을 클릭하고 편집 버튼을 클릭했다. 편집 대화상자에서는 아래 그림처럼 익명 액세스 허용 체크박스를 클릭하고 다른 모든 설정은 기본값으로 설정했다.

익명 사용자가 웹사이트를 탐색 가능하도록 설정

기본 웹사이트가 실행되는지 확인한 후 피닉스는 다른 컴퓨터로 가서 윈도우 2003 서버의 IP 주소를 입력해 방금 설정한 웹사이트에 성공적으로 접근할 수 있는지 확인했다. 아래 그림에 나온 것처럼 제목이 “hacked”인 웹 페이지가 나타나자 피닉스는 만족스런 표정을 지었다.

테스트 웹사이트 확인

“이제 재미있는 걸 해볼 차례군.” 피닉스가 혼자 중얼거렸다. “이 방법이 제대로 통하는지 인라인 프레임을 좀 더 알아봐야겠어.” 피닉스는 파이어폭스를 열고 www.google.com으로 들어갔다. 그러고 나서 인라인 프레임의 동작 원리와 관련한 정보를 검색했다. 몇 시간 동안 튜토리얼, 포럼, 게시판을 훑어보고 나서 인라인 프레임에 관해 충분히 이해하고 나자 마음이 놓였다. 피닉스는 이제 테스트 페이지로 가서 hacked.html 페이지를 메모장에서 열어 첫 인라인 프레임을 만들기 시작했다. 우선 다음과 같은 코드를 HTML 문서에 입력했다.

<iframe
src=http://www.google.com
width=200 height=200>
</iframe>

피닉스는 앞서 입력한 코드를 곰곰이 생각해봤다. “이 코드에 근거하면 내가 hacked.html 웹 페이지를 열었을 때 hacked.html 파일에 포함된 인라인 프레임이 열리겠구나. 그리고 인라인 프레임에서는 제각기 www.google.com을 열겠지. hacked.html을 열면 각 창의 너비와 높이가 200인 구글 페이지도 10개 열릴 테고.” 이렇게 생각하고 http://10.10.10.32(테스트 서버의 IP 주소)에서 테스트 hacked.html 웹사이트를 열자 아래 그림과 같은 화면이 나타났다.

코드를 맞게 작성했을 때 나타나는 인라인 프레임

피닉스는 문서에 인라인 프레임 코드를 9번 더 붙여 넣고 나서 시험해봤다.

<html>

<head>
<meta httpequiv="ContentLanguage" content="enus">
<meta httpequiv="ContentType" content="text/html; charset=windows1252">
<title>HACKED</title>
<!—mstheme—><link rel="stylesheet" href="jour1000.css">
<meta name="Microsoft Theme" content="journal 1000, default">
<meta name="Microsoft Border" content="tlb, default">
</head>
<body>

<p><b><font size="6" color="#000080">HACKED</font></b></p>
<p>&nbsp;</p>
<p><b><font size="6" color="#000080">HACKED</font></b></p>
<p>&nbsp;</p>
<p><b><font size="6" color="#000080">HACKED</font></b></p>
<p>&nbsp;</p>

<html>
<head>
<meta httpequiv="refresh" content="20">
</head>

<iframe
src=http://www.google.com
width=200 height=200>
</iframe>

<iframe
src=http://www.google.com
width=200 height=200>
</iframe>

<iframe
src=http://www.google.com
width=200 height=200>
</iframe>

<iframe
src=http://www.google.com
width=200 height=200>
</iframe>

<iframe
src=http://www.google.com
width=200 height=200>
</iframe>

<iframe
src=http://www.google.com
width=200 height=200>
</iframe>

<iframe
src=http://www.google.com
width=200 height=200>
</iframe>

<iframe
src=http://www.google.com
width=200 height=200>
</iframe>

<iframe
src=http://www.google.com
width=200 height=200>
</iframe>

<iframe
src=http://www.google.com
width=200 height=200>
</iframe>
</html>

</body></html>

“그럼 이제 창이 10개 열리는지 확인해 봐야겠다.” 피닉스는 hacked.html 파일이 열린 메모장에서 파일, 저장 메뉴를 차례로 선택했다. 그러고 나서 웹 브라우저로 돌아가 새로고침 버튼을 클릭했다. 아래 그림과 같은 결과가 나타나자 피닉스는 만족한 표정을 지었다.

인터넷 익스플로러를 통해 HTML로 생성된 인라인 프레임. 구글 사이트가 10군데에서 열려 있음을 눈여겨보자.

“멋진데!” 피닉스가 소리쳤다. “이제 조금만 더 손보면 되겠어. 5초마다 인라인 프레임을 새로 불러오게 하는 방법을 알아봐야겠다.” 피닉스는 지금까지 읽은 걸로는 부족함을 느꼈다. 그래서 구글로 가서 인라인 프레임 새로고침에 관해 검색했다. 원하는 내용을 찾기까지는 그리 오래 걸리지 않았다. 온라인 웹 개발자 잡지에서 찾은 기사를 바탕으로 피닉스는 메모장으로 돌아가 hacked.html 문서를 열고 기사 내용에 따라 다음 메타 태그를 문서에 추가해서 인라인 프레임을 5초마다 새로 불러오게끔 만들었다.

<html>
<head>
<meta httpequiv="refresh" content="5">
</head>

피닉스는 HTML 문서를 저장하고 웹 브라우저로 돌아가 아직 열려 있는 hacked.html에서 새로고침 버튼을 클릭했다. 처음에는 모든 인라인 프레임이 새로고침되는 것을 제외하고는 아무 일도 일어나지 않았다. 하지만 정확히 5초가 지나자 모든 인라인 프레임을 다시 불러왔다. 그로부터 다시 5초가 지나자 이번에도 모든 인라인 프레임을 불러왔다. “제대로 되는구나!” 피닉스는 그렇게 소리치며 두 엄지손가락을 치켜 올렸다. 그때 어떤 생각이 피닉스의 머릿속을 스쳤다. 아무리 기술적인 식견이 없는 최종 사용자라도 컴퓨터와 컴퓨터 부품을 보여줘야 할 웹 페이지가 열리는 중간에 수많은 구글 페이지가 열리는 걸 보면 무슨 일이 일어났다는 것쯤은 알 것이다. “이걸 숨길 방법을 찾아야겠다.” 이렇게 생각한 피닉스는 가장 쉬운 방법을 시도해봤다. 메모장에서 hacked.html을 열어 각 인라인 프레임의 너비와 높이를 수정하는 것이다. 피닉스는 너비와 높이를 모두 0으로 바꾸고 다른 것은 그대로 뒀다.

<iframe
src=http://www.google.com
width=0 height=0>
</iframe>

변경사항을 저장하고 난 후 브라우저로 돌아가서 웹 페이지를 새로고침했다. 그러자 아래 그림처럼 아무런 인라인 프레임도 보이지 않은 채 페이지를 불러오는 것을 보고 성공했다고 생각했다.

인라인 프레임을 감춘 채 불러온 HTML 파일

이제 인라인 프레임이 감춰졌기 때문에 그것들을 불러오는지조차 알 수 없었다. “와이어샤크로 트래픽을 확인해봐야겠다.” 피닉스가 와이어샤크를 열고 NIC(네트워크 인터페이스 카드)를 캡처하기 시작하자 이내 아래 그림처럼 구글의 IP 주소를 향해 HTTP GET 요청이 보내지고 있음을 확인할 수 있었다.

와이어샤크로 본 트래픽. 브라우저 측에서는 보이지 않지만 인라인 프레임이 여전히 백그라운드에서 구글 웹 페이지를 불러오고 있음을 보여준다.

이거 불법 아냐?: 일상을 파고드는 해킹 스토리(앤드류 휘테이커 외 지음, 이대엽 옮김)

여기서 피닉스는 멈추고 잠시 생각에 잠겼다. “이게 실제로는 어떻게 동작할까? 인라인 프레임을 5개만 만들어서는 제대로 안 될 텐데…… 흠. 젠장, 필요하면 인라인 프레임을 100개라도 만들 수 있는데! 하지만 그렇게 하다간 실제로 사용자에게 DoS를 하게 되는 셈이지. 사실 인라인 프레임을 10개만 만들어도 그렇게 될 거 같은데. 게다가 인라인 프레임이 100개면 분명 www.google.com으로 동시에 100개의 인라인 프레임이 접속했을 때 웹 서버 측이나 해당 네트워크에 있는 누군가가 경보를 울릴 게 뻔해. 조금만 더 생각해 보면 인라인 프레임이 10개라도 실제로 똑같이 될 거 같은데. 그렇지만 전에 구글 페이지를 10개 가까이 열어서 제각기 다른 내용으로 검색해본 적도 있으니까 인라인 프레임을 10개까지 써도 괜찮을 거야.” 피닉스는 인라인 프레임 개수를 10개로 정할 때까지 이런 식의 이야기를 10여분 동안이나 혼잣말로 했다.

(다음 글에서 계속 이어집니다)

• 경쟁사 웹 사이트 해킹 (1) – 상황설정
• 경쟁사 웹 사이트 해킹 (2) – 접근법, 상세 정보, 연쇄 공격
• 경쟁사 웹 사이트 해킹(3) – 공격 #1: 테스트

————- o ————

공격 #2: 유효한 공격 방법

피닉스는 주저할 틈도 없이 수정한 공격 계획을 단계별로 적어봤다.

1. 트래픽이 많고 대역폭이 큰 웹사이트를 호스팅하는 회사를 하나 고른다.
2. 회사 홈 페이지 계정에 쓰기 권한이 있는 디자인 회사에 사회공학 기법을 써서 권한을 확보한다.
3. 트래픽이 많은 사이트의 접근 권한을 취득한 다음, 공격 대상 웹사이트(www.thetruthsa.org)를 여러 번 불러들이는 인라인 프레임 HTML 코드를 포함하게끔 홈 페이지를 수정한다.
4. 가만히 앉아서 thetruthsa.org 사이트가 전 세계 사용자가 보내는 어마어마한 양의 트래픽을 받아 다운되는 것을 지켜본다.

피닉스는 머릿속에 들어 있는 생각들을 그림으로 표현해 보기로 했다. 10분 정도 비지오에서 작업하고 나니 아래 그림과 같은 도식이 만들어졌다.

피닉스의 공격 구상

기본적으로 방문자가 인질 웹사이트(www.allputerstuff.com)에 방문할 때마다 해당 웹사이트의 홈페이지에 포함돼 있는 인라인 프레임이 방문자로 하여금 공격 대상 웹사이트를 10번 불러오게 한 후 5초마다 갱신될 것이다. 이처럼 수천에 이르는 방문자가 웹 페이지를 방문하므로 몇 푼 들이지 않고 구축한 www.thetruthsa.org와 같은 웹사이트는 금방 다운될 것이다.

피닉스가 allputerstuff.com을 인질 웹사이트로 고른 이유는 이 사이트가 굉장히 많은 광고 트래픽을 자랑하고 해마다 이 사이트에서 이뤄지는 판매 건수가 수백만에 이르기 때문이다. 또한 이 웹사이트 하단에 위치한 로고에는 “비밥 웹에서 디자인하고 유지보수함”이라는 문구가 적혀 있었다. 피닉스는 이 웹 디자인 회사가 고객 규모는 크지만 실제로 회사 규모가 작고 회사가 지방에 위치해 있다는 사실도 알고 있었다. 피닉스는 가장 먼저 비밥 웹 디자인에 근무하는 누군가에게 사회공학 기법을 써서 allputerstuff.com 웹사이트를 수정하기 위한 로그인 정보를 알아내기로 마음먹었다. 피닉스는 비밥 웹 디자인이라는 회사에 관해 알아보기 시작해서 금방 사무실 위치를 알아냈다. 그런 다음 비밥 웹사이트에 있는 “오시는 길” 페이지를 출력한 후 회사를 방문하기 위해 집을 나섰다.

인질 웹사이트에 접근하기

비밥에 도착한 피닉스는 근사한 회사 건물의 외양과 규모에 적잖이 놀랐다. “영세한 웹 디자인 회사가 이걸 감당이나 할 수 있을까?” 피닉스가 속으로 생각했다. 피닉스는 건물로 들어가 건물 안내도를 찾아봤다. 건물 안내도는 로비 중간에 있었다. 거기엔 비밥의 사무실 위치로 “비밥 웹 디자인 208호”라고 적혀 있었다. 피닉스는 사무실 위치를 입으로 소리 내서 읽은 다음 엘리베이터에 탔다. 엘리베이터 안에서 파란색 명찰과 갈색 유니폼을 걸친 어떤 나이 지긋한 아저씨가 피닉스에게 인사를 건넸다. “안녕하세요.”

“네, 안녕하세요.” 피닉스가 대답했다.

그가 말을 이었다. “저는 그렉이라고 하고 여기서 관리인으로 근무하고 있습니다. 여기서는 시설 관리나 세차 같은 일을 하고 있는데 제 명함 하나 받으세요.” 그가 집에서 만든 것처럼 보이는 명함을 피닉스에게 하나 건넸다. 피닉스는 그 명함을 받아 주머니에 집어넣었다.

“다재다능한 분이시군요.” 피닉스가 농담을 건넸다.

얼굴에 약간의 미소를 띤 채 그가 대답했다. “글쎄요, 먹고 살려면 별 수 있나요. 우리는 초과 근무도 못하는데 먹고는 살아야지요.”

“그렇죠.” 피닉스가 말했다. 그렇게 말하고 나자 종이 울리고 엘리베이터가 2층에서 멈췄다. 엘리베이터를 나서면서 피닉스는 그렉에게 인사를 건넸다. 문이 닫히려고 할 때 그가 피닉스를 불러 세웠다. “청소나 잡일거리가 있으면 잊지 말고 저한테 연락 주십시오.” 피닉스는 고개를 끄덕이고 208호로 향했다.

208호 사무실로 들어서자 20대 정도로 보이는 매력적인 한 여성이 피닉스에게 인사하고 용무를 물었다. “제가 몇 백만 달러 규모의 회사를 운영하고 있는데, 이번에 저희 회사의 전자 상거래 부문을 디자인 관점에서 앞장서줄 새로운 웹 디자인 회사를 찾고 있는 중입니다.” 피닉스가 머리도 손질하고 새로 산 양복도 갖춰 입었기 때문에 확실히 그녀에게는 피닉스가 새로 사업을 시작해서 성공가두를 달리고 있는 젊고 실력 있는 벤처기업가로 비췄다.

“그런 거라면 당연히 저희가 도와드릴 수 있습니다. 우선 잠깐 자리에 앉아 계시면 저희 수석 디자이너와 말씀을 나눌 수 있게 안내해 드리겠습니다.” 이렇게 말한 응답원의 얼굴에는 반가운 기색이 역력했고 서둘러 피닉스를 도와주기 위해 분주하게 움직이는 듯했다. “역시 돈이 사람을 움직이게 하는군,” 피닉스가 혼자 중얼거렸다. 얼마 지나지 않아 약간 살찌고 초라한 행색을 갖춘, 35세 전후로 보이는 남자가 다가와 피닉스를 사무실로 안내했다. 그런 다음 피닉스에게 음료를 대접하고 자리에 앉아 말했다. “멜린다가 어떤 걸 찾으시는지 저한테 알려주었습니다만 사실 저희는 전자 상거래 분야는 담당하지 않습니다. 저희는 웹사이트를 멋지게 만드는 일만 하고, 전자 상거래 부문은 다른 협력사에서 하고 있습니다.”

“그렇군요.” 피닉스는 수석 디자이너가 하는 말을 메모지에 받아 적는 척 하면서 이렇게 말했다. 그러고 나서 마치 전문가가 말하는 투로 이렇게 얘기했다. “그 프로세스가 어떻게 되는지 알려주시겠습니까?”

남자는 미소를 머금고 이야기하기 시작했다. “네, 말씀드렸다시피 저희는 웹사이트 디자인만 하고 있습니다. 그리고 저희 회사가 그 분야에서 최고죠. 혹시 필요하시다면 저희가 작업한 사이트의 시안을 보여드리겠습니다.” 남자는 이렇게 제안했다.

“네, 좋습니다.” 피닉스가 말했다. “그런데 가장 염려스러운 부분이 바로 응답 시간입니다. 그러니까 제가 뭔가를 바꾸고 싶다면 변경 절차는 어떻게 됩니까?” 피닉스가 물었다.

“아, 네.” 브렛이라고 하는 그 남자는 이렇게 대답했다. “다행히도 고객분이 여기 오시기 바로 전에 변경 요청을 하나 받았습니다. 그럼 저희가 변경 요청을 어떻게 처리하는지 직접 보여드리죠.”

피닉스는 얼굴에 웃음을 띠면서 대답했다. “아주 잘 됐군요.”

브렛은 문서철을 꺼내 페이지를 넘기기 시작했다. 그는 피닉스를 한번 흘깃 본 후 고객 웹사이트의 모든 로그인 정보를 여기에 보관한다고 했다. 그는 해커들이 그러한 정보를 절대 알아낼 수 없게끔 어떤 정보도 디지털로 저장하지 않는다고 했다.

“맞습니다. 당연히 그렇게 해야죠.” 피닉스가 동조했다. 수정해야 할 고객 웹사이트 정보가 담긴 페이지를 찾고 나서 브렛은 FTP 클라이언트 프로그램을 실행했다. 이내 고객 웹사이트 계정에 로그인 한 후 홈페이지의 HTML 파일들을 모두 가져와 요청사항을 반영하고 파일을 저장했다.

브렛은 피닉스를 보고 얘기했다. “어떤가요, 이게 끝입니다. 다 해서 2분 정도 걸렸나요?”

피닉스는 고개를 끄덕이고 인위적으로 감탄사를 날렸다. “아주 인상적입니다.” 브렛은 책상 뒤에 있는 서류함에 문서철을 다시 집어넣고 문을 닫았다. “잘 알겠습니다.” 피닉스가 말했다. “그럼, 제가 며칠 내로 작업을 시작할 수 있게 수석 디자이너 분이나 다른 디자이너 분께 연락드리겠습니다.”

피닉스가 일어서자 브렛은 디자이너는 자기밖에 없다고 말했다. “그렇군요, 그건 상관없습니다.” 피닉스가 말했다. “그럼 제가 직접 연락드리면 되겠군요. 혹시 명함을 받을 수 있을까요?” 브렛은 피닉스에게 명함 몇 장을 건네고 회사 정문까지 배웅했다.

이거 불법 아냐?: 일상을 파고드는 해킹 스토리(앤드류 휘테이커 외 지음, 이대엽 옮김)

“다시 한 번 감사드립니다.” 엘리베이터로 들어가면서 피닉스는 이렇게 말했다. 엘리베이터에 도착하기 전까지도 이미 피닉스의 머릿속은 브렛의 책상 뒤에 놓인 서류함의 문서철을 어떻게 입수할지 생각해 내느라 분주했다. 그 문서철에는 비밥의 모든 고객의 웹사이트 FTP에 로그인할 수 있는 정보가 들어 있다. 로비에 도착해서 피닉스는 관리인으로 일하는 그렉을 다시 만났다. 재고할 틈도 없이 피닉스는 그렉에게 잠깐 나가서 할 얘기가 있다고 했다. 밖으로 나온 피닉스는 곧바로 거래를 제안했다. “아저씨, 10분만에 3,000달러 한번 벌어 볼래요?”

그렉은 웃으면서 말했다. “원, 세상에 누가 10분 일하고 그렇게 큰돈을 벌 수 있단 말입니까?”

피닉스도 웃으면서 물었다. “2층에서 일하시죠?” 그렉은 고개를 끄덕이고 대답했다. “건물 전체가 제 담당입니다.”

피닉스는 잠시 동안 생각했다. “그럼, 잘됐네요. 2층에 있는 비밥 웹 디자인이라는 회사 아세요?”

그렉은 웃으면서 대답했다. “물론이죠. 브렛이라고 하는 잘난척하는 녀석이 그 회사를 운영하고 있지요.”

피닉스는 잠깐 멈춘 다음 다시 다른 질문을 던졌다. “혹시 야간이나 다른 사람들이 모두 퇴근한 뒤에 청소해 보신 적 있으세요?”

그렉은 주저하지 않고 대답했다. “일주일에 한 번씩 그렇게 하지요. 마침 오늘은 카펫이 깔린 층은 모두 청소해야 하는데, 그렇게 하려면 야간에 청소할 수밖에 없지요.”

피닉스는 그렉에게 거래를 제안했다. “그럼, 오늘밤 청소하실 때 브렛의 책상 뒤에 있는 서류함으로 가셔서 빨간색 문서철을 꺼낸 다음 거기 들어 있는 내용을 모두 복사해 주세요. 20페이지도 채 안 될 겁니다. 그리고 복사하고 나서 다시 집어넣고 건물을 나올 때 저한테 전화해주세요. 사본을 주시면 제가 그 자리에서 3,000달러를 드리죠.”

그렉은 곧바로 그렇게 하겠다고 했다. 그렉과 피닉스는 휴대전화 번호를 주고받고 헤어졌다. 그렉에겐 돈이 필요했고 먹고 살기가 빠듯했기에 그 정도 일에는 일말의 주저함도 없었다. 6시간이 지나 오후 9시 30분쯤 됐을 때 피닉스의 휴대전화 벨소리가 울렸다. 피닉스가 응답하자 상대편에서 그렉이 얘기했다. “필요한 걸 입수했수다.”

“잘하셨어요!” 피닉스가 소리쳤다. “아담스 스테이트에 있는 잭스 립에서 20분 후에 뵙기로 하죠.” 그렉은 알았다면서 전화를 끊었다. 피닉스는 자리에서 일어나 곧장 잭스 립으로 향했다. 거기서 입수한 고객 정보와 돈을 맞바꿨다. 피닉스는 곧장 집으로 가기로 했고, 그렉은 식당에 남아 BBQ 립을 맛보겠다고 했다. 피닉스는 그렉에게 다시 한 번 고맙다고 말하고 문을 나섰다.

(다음 글에서 계속 이어집니다)

• 경쟁사 웹 사이트 해킹 (1) – 상황설정
• 경쟁사 웹 사이트 해킹 (2) – 접근법, 상세 정보, 연쇄 공격

————- o ————

공격 #1: 테스트

피닉스는 곧바로 Freak88 툴의 매뉴얼을 읽고 사용법을 익혔다. “그럼 대상 장비에 server.exe를 심어두면 내가 제어권을 가지고 조종해서 실제로 핑을 날릴 수 있겠군. 그리고 실제로 내 장비에서 핑이 나가지는 않을 테고. 멋진데! server.exe 트로이 목마를 심어둔 장비를 조종하려면 clienttriono.exe를 써야 하는군. 좋아, 전부 알겠어.” 이제 피닉스는 이 툴이 어떻게 동작하는지 이해했으므로 곧 이 툴을 모의 환경에서 시험해 볼 것이다. 먼저 피닉스는 아래 그림에 나와 있는 것처럼 설치와 공격이 어떻게 이뤄지는지 보여주는 그림을 그렸다.

피닉스가 계획한 공격 세부사항

피닉스는 테스트용 컴퓨터를 하나 켜고 테스트 장비에 트로이 목마를 설치했다. 그러고 나서 IP 주소가 10.0.0.34인 테스트 장비에 server.exe 파일을 복사했다. 이렇게 하면 이 장비가 실제로 핑을 수행할 좀비 PC나 인질 장비가 될 것이다. 그런 다음 와이어샤크를 설치하고 희생자 역할을 할 장비를 대상으로 패킷을 캡처하기 시작했다. 이어서 피닉스는 아래 그림과 같이 와이어샤크 메뉴에서 Capture를 선택하면 펼쳐지는 목록에서 Capture Filters를 선택했다.

와이어샤크 캡처 필터 선택

피닉스는 캡처 필터를 선택하면 나타나는 대화상자에서 Filter name 란에 ICMP를 입력했다. Filter string 란에는 icmp only를 입력했다. 그런 다음 New 버튼을 클릭하자 아래 그림에 나온 것처럼 ICMP 필터가 Filter 선택 목록에 나타났다.

다음으로 좀비 PC 역할을 수행할 컴퓨터로 들어갔다. 미리 복사해둔 server.exe 파일을 C: 드라이브로 옮기고 실행한 후 공격자 장비로 되돌아가 clienttrino.exe 파일을 실행했다. clienttrino.exe 파일을 실행하니 아래 그림과 같은 대화상자가 나타났다.

와이어샤크의 새 필터 생성 대화상자

Freak88 클라이언트(혹은 컨트롤러)의 인터페이스

이번에는 아래 그림에 나온 것처럼 대화상자에 알맞은 IP 주소를 입력했다. 그림에서 볼 수 있듯이 ip of infected computer(감염 컴퓨터의 IP 주소) 란에는 10.0.0.34를 입력하고 ip of machine to attack(공격 대상 컴퓨터의 IP 주소) 란에는 10.0.0.32를 입력했다. 이렇게 설정하고 나서 connect 버튼을 눌렀다. 화면에 “Hello, who do you want to phunk today?”라는 대화상자가 나타난 것을 봐서 접속에 성공했음을 알 수 있었다.

IP 주소를 입력하고 connect 버튼을 클릭한 후의 Freak88 클라이언트의 인터페이스

이제 피닉스는 희생자 장비로 가서 와이어샤크 대화상자를 열었다. 그런 다음 아래 그림처럼 Capture 메뉴를 클릭한 후 Interfaces를 선택했다.

희생자 장비를 대상으로 와이어샤크 캡처 시작하기

그런 다음 IP 주소가 10.0.0.32인 인터페이스 바로 오른쪽에 있는 Start 버튼을 클릭했다. 이내 아래 그림처럼 캡처 창이 나타나서 해당 네트워크 카드로 오가는 모든 트래픽이 표시되기 시작했다. 이어서 피닉스는 Filter 란에 icmp(바로 몇 분 전에 만든 필터의 이름)를 입력했다.

필터가 적용되기 전의 와이어샤크 화면

그러고 나서 Filter 란의 오른쪽에 있는 Apply 버튼을 클릭했다. 버튼을 클릭하자마자 캡처된 모든 트래픽이 아래처럼 사라졌다.

ICMP 필터가 적용된 와이어샤크 화면

모든 필터 및 패킷 캡처 설정을 하고 나니 드디어 모의 공격을 감행할 준비가 끝났다. 공격자 장비로 돌아간 피닉스는 아래 그림처럼 공격자 장비의 Freak88 대화상자에서 takeumout 버튼을 클릭했다.

공격을 실행한 이후의 Freak88 클라이언트(또는 컨트롤러)의 인터페이스

“그래! 바로 이거야!” 피닉스는 방을 가로질러 희생자 PC로 가서 ICMP 트래픽을 캡처 중인 와이어샤크를 보고 이렇게 소리 질렀다. 피닉스는 캡처 화면을 보고 이 정도면 되겠다는 생각에 손가락을 튕겨 딱! 하는 소리를 냈다. “제대로 되는군” 피닉스가 중얼거렸다. 예상했던 대로 트래픽은 바로 아래 그림과 같이 좀비 PC인 10.0.0.34에서 오고 있었다.

좀비 장비에서 보낸 ICMP 트래픽을 수집 중인 와이어샤크

“훌륭해” 피닉스가 감탄조로 말했다. “실제로 다른 장비가 핑을 보내도록 명령해서 이 장비를 공격해 봐야겠다.” 직감적으로 피닉스는 공격하려고 계획 중인 웹사이트에도 핑을 수행할 수 있는지 알아보기로 했다. 명령행을 띄우고 다음과 같이 입력했다.

ping www.thetruthsa.org
  Request timed out.
  Request timed out.
  Request timed out.
  Request timed out.

피닉스는 핑을 수행한 결과를 보고 당황해서 어쩔 줄 몰랐다. 그런 다음 웹 브라우저에서 해당 웹사이트로 가서 사이트가 뜨는지 확인했다. “도대체 이게 뭐야?” 피닉스가 소리쳤다. 기분이 언짢아지기 시작했다. 피닉스는 이 웹사이트를 만들고 설정하는 것에 관한 기사를 끝까지 읽어보지 않았던 것이다. 그 기사를 다시 읽어보니 기사의 끄트머리에 이 웹사이트를 만든 학생들이 PIX(Private Internet Exchange) 방화벽을 비롯해 시스코사의 조언에 따라 웹 서버의 ICMP 기능을 비활성화했다는 내용이 적혀 있었다. “제기랄!” 피닉스가 소리쳤다. 이제 피닉스는 이 공격이 통하지 않을 거라는 사실을 깨달았다.

이거 불법 아냐?: 일상을 파고드는 해킹 스토리(앤드류 휘테이커 외 지음, 이대엽 옮김)

피닉스는 자리에 앉아 생각에 잠겼다. “아직 포기할 때가 아냐. 다른 방법을 찾아봐야겠어.” 피닉스는 골똘히 생각했다. 바로 그때 해커들이 일반적인 HTTP GET 요청을 웹사이트로 보내게 하는 인라인 프레임을 이용해 DDoS 공격을 한다는 기사가 피닉스의 머릿속을 스쳤다. 공격자는 사람들이 즐겨 찾는 사이트의 제어권을 획득한 다음 해당 사이트에 인라인 프레임을 심는다. 이렇게 하면 해당 사이트에 접속하는 방문자는 자기도 모르는 사이에 DDoS 공격에 참여하게 된다. 개념은 간단하다. 어떤 사이트에 분당 100명의 방문자가 들어온다면 사이트의 인라인 프레임이 방문자의 브라우저에서 공격 대상 사이트를 10번 불러오게 되며, 그 결과 방문자가 호스팅 웹사이트를 방문할 때마다 공격 대상 사이트는 10번의 방문을 받게 되는 셈이다. 따라서 분당 100명의 방문자가 호스팅 웹사이트를 방문한다면 공격 대상 사이트는 분당 1,000번의 GET 요청을 받게 되는 것이다. “이 정도면 되겠지?” 피닉스가 중얼거렸다. “인라인 프레임이 공격 대상 웹사이트를 불러들이는 것뿐만 아니라 프레임 자체를 계속해서 갱신하게 하는 방법이 있다면 대상 웹사이트로 가는 트래픽의 양을 엄청나게 늘릴 수 있을 텐데. 한번 해볼 만하겠어.” 피닉스가 혼자 중얼거렸다.

(다음 글에서 계속 이어집니다)

• 경쟁사 웹 사이트 해킹 (1) – 상황설정
  

————- o ————

접근법

최종적으로 대상 웹사이트를 무너뜨리기 위해 피닉스는 다양한 기법을 활용할 것이다. 다음은 이 웹사이트를 공격하는 데 이용할 기법을 정리한 것이다.

1. 해킹을 위한 접속 수단으로 보호되지 않은 무선 네트워크를 몰래 설치한다.
2. 익명 서비스를 이용해 침투 흔적을 은폐한다.
3. Freak88 DDoS 툴을 이용해 DDoS(분산 서비스 거부) 공격을 감행한다.
4. 툴을 모의 환경에서 시험해 본다.
5. Freak88의 Server.exe 트로이 목마를 이용해 보호되지 않은 다수의 컴퓨터를 감염시킨다.
6. 감염된 장비의 제어권을 탈취해 대상 웹사이트에 지속적으로 트래픽을 보낸다.

이제 공격을 시작할 준비가 끝났다. 늘 그렇듯 피닉스는 실제 공격을 하기에 앞서 개념 검증부터 시작했다. 천성적으로 편집증적인 면이 있는 그는 우발적으로 일어나는 일을 싫어하고 실제 환경에 적용하기에 앞서 먼저 모의 환경에서 시험해 보기를 좋아했다. 어떤 툴을 사용할지 생각해봤을 때 머릿속에 Freak88이라는 DDoS 툴이 떠올랐다. “이거면 충분하지.” 피닉스는 이렇게 생각한 후 구글에서 “Freak88”로 검색했다. 검색 결과로 14,000개가 나타났고 피닉스는 하나씩 살펴보기 시작했다. 4개의 링크를 살펴보고 나자 어떤 링크가 실제로 이 툴을 다운로드할 수 있는 링크인지 알 수 있었다. Download를 클릭하고 다운로드가 완료되길 기다렸다. “뭐가 들어 있는지 한번 볼까?” 피닉스가 혼자 중얼거리면서 방금 내려 받은 파일의 압축을 풀고 파일 내용을 살폈다. 아래 그림은 파일 내용을 보여준다.

Freak88 패키지의 내용. 서버, 클라이언트, 구동 시 필요한 DLL이 보인다.

상세 정보

2008년 4월 22일에 발간된 마이크로소프트의 자료에 따르면 공격자들이 웹 기반 공격을 선호하는 탓에 이메일 기반 피싱 공격은 감소하기 시작했다고 한다. 시스템 관리자가 이메일과 이메일의 첨부 파일에서 발견되는 악성 콘텐츠를 잘 처리하면서 공격자들은 크로스 사이트 스크립팅(cross site scripting)이나 SQL 주입(SQL injection), 또는 그 밖의 공격 형태와 같은 웹 기반 공격이 좀 더 성공할 가능성이 높다는 사실을 알게 됐다. 널리 다뤄지지 않은 공격 방법 가운데 하나는 인라인 프레임(inline frame)이나 CSS(Cascading Style Sheet), 또는 그 밖의 별다른 고려 없이 웹사이트 환경에 도입되는 기능들을 통해 늘어나는 취약점에 토대를 둔 것이다. 웹 보안의 큰 문제점 중 하나는 바로 현재 우리가 “업무적인 기능이 풍부한” 웹사이트라고 통칭하는 것들도 여전히 모두 HTML이라는 점이다. 2007년부터 2009년 현재까지 다수의 인라인 프레임 취약점이 발견됐다. 기본적인 인라인 프레임의 작동 방식은 여러 문제점을 내포하고 있지만 더 중요한 점은 널리 사용되는 대부분의 웹 브라우저가 기본적으로 인라인 프레임의 내용을 처리한다는 데 있다. 점점 더 많은 기업이 자사의 웹사이트를 외부 세계와의 주된 접점으로 삼는 방향으로 나아가고 있으므로 기업, 정부, 개인 웹사이트에 대한 공격이 늘어나고 이는 점점 더 복합적인 양상을 띨 것이다.

이거 불법 아냐?: 일상을 파고드는 해킹 스토리(앤드류 휘테이커 외 지음, 이대엽 옮김)

피닉스는 ICMP(Internet Control Message Protocol)와 같은 메커니즘을 활용하는 다양한 DDoS 툴을 이용해 경쟁사 웹사이트를 무너뜨릴 것이다. 방법은 간단하다. 다양한 곳에서 대상 웹사이트로 가능한 한 핑을 많이 보내서 해당 웹사이트가 응답 핑(프로토콜에 따르면 핑을 받은 사이트는 그에 대한 응답을 반드시 보내야 한다)을 보내느라 허우적대다가 다운되게 만드는 것이다. 그러나 많은 네트워크 관리자나 네트워크 기술자들은 ICMP 프로토콜을 통해 패킷이 전송되지 못하게 해서 각종 ICMP 기반 공격을 예방하므로 ICMP 공격은 점차 효과가 떨어지는 추세다. 분명 피닉스도 이러한 문제에 직면하겠지만 기타 HTML 언어에 내장돼 있는 기능을 활용해 ICMP 기반 공격과 유사한 효과를 낼 것이다.

연쇄 공격

본 절에서는 아래 내용을 비롯해 피닉스가 수행한 연쇄 공격의 각 단계와 관련된 세부 내용을 다룬다.

• 공격 #1: 테스트
• 공격 #2: 유효한 공격 방법
• 인질 웹사이트에 접근
• 모의 해킹 시험
• 인질 웹사이트 변조
• 그 밖의 가능성

본 절은 이 같은 연쇄 공격을 요약한 내용으로 마무리한다.

(다음 글에서 계속 이어집니다)

————- o ————

상황 설정

오후 4시 30분, 오늘 하루 피닉스는 상사에게서 정나미가 떨어질 대로 떨어졌다. 소지품을 모두 챙기고 회사를 그만둘 준비가 되자 피닉스는 상사에게 가서 갖은 욕을 퍼부으며 나가 죽으라고 소리쳤다. 기차역으로 향하던 피닉스의 휴대폰에서 문자 메시지가 도착했음을 알리는 소리가 났다. 휴대폰을 열자 0000000000이라는 번호로 도착한 문자 메시지엔 이렇게 적혀 있었다. “6시에 늘 만나던 곳”. 일순간에 혼란스러움과 분노와 두려움이 동시에 피닉스를 덮쳤다. 피닉스는 이 메시지를 누가 보냈는지 알고 있었다. 하지만 몇 달 전에 돕스 씨와 연락하는 데 썼던 휴대폰을 마지막으로 의뢰받은 일을 하고 난 후 얼마 지나지 않아서 버린 기억이 생생하게 떠올랐다. 잠시 피닉스는 이 남자가 도대체 어떻게 자신의 휴대폰 번호를 알아냈는지 곰곰이 생각해 보고 난 후 이내 쓸데없는 짓이라 생각했다. 돕스 씨가 항상 자신을 지켜보고 있고 앞으로도 계속 그럴 거라 말한 적이 있어서였다.

열차에 올라탄 피닉스는 커피숍으로 가서 돕스 씨를 기다릴지 아니면 메시지를 무시하고 일상적인 삶을 계속해 나갈지 고민했다. 하지만 고민은 오래가지 않았다. 일전에 돕스 씨가 위협했던 기억이 떠오르자 그가 보낸 메시지를 무시하면 별로 좋지 않은 일이 생길 거라는 생각이 곧바로 들었다. “다음 역은 매디슨/와바시 역입니다”. 인터콤에서 승무원의 안내 방송이 울려 퍼졌다. 피닉스는 자리에서 일어나 출입문에서 열차가 서길 기다렸다. 이윽고 열차에서 내린 피닉스는 승강장을 거쳐 밖으로 나간 다음 반 블록쯤 아래에 있는 커피숍으로 들어갔다. 시계를 보니 오후 5시 50분이었다. “타이밍 한번 좋구나.” 피닉스가 생각했다.

커피숍으로 들어가서 주위를 슬쩍 훑어봤지만 돕스 씨는 아무 데도 보이지 않았다. 피닉스가 커피숍에서 나가려는 찰나 구석에 앉아 있던 한 남자가 소리쳤다. “어이, 잠깐만요”. 피닉스는 그 남자가 앉아 있는 곳으로 가서 무슨 일이냐고 물었다. “돕스 씨가 당신을 알려줬습니다.” 거기에 피닉스는 이렇게 대답했다. “저는 당신이 누군지, 또 무슨 말씀을 하시는 건지 모르겠습니다.” 그 남자는 피닉스를 한번 뚫어져라 쳐다보더니 단호한 표정으로 이야기했다. “돕스 씨가 당신이 약간 초조해 하고 있을지도 모를 거라 말해주더군요. 아무튼 당신한테 체리 가(街) 5638번지의 잔디를 꼭 깎아야 한다고 말해주라고 했습니다. 그게 무슨 말인지는 모르겠지만요.” 남자는 어깨를 으쓱하며 말했다. 피닉스는 익숙한 한기가 자신의 온몸을 뒤덮는 듯한 느낌이 들고 입이 바짝 마르기 시작했다. 피닉스는 그가 말한 내용이 무슨 의미인지 잘 알고 있었고, 실제로 돕스 씨가 이 남자를 보냈다는 사실을 깨달았다. 이런 확신이 들자 피닉스는 테이블 맞은편에 앉아 머뭇거리며 남자에게 물었다. “그럼, 원하는 게 뭐요?”

이거 불법 아냐?: 일상을 파고드는 해킹 스토리(앤드류 휘테이커 외 지음, 이대엽 옮김)

그 남자는 주저하지 않고 바로 본론으로 들어갔다. “제 고객은 온라인으로 컴퓨터 부품과 주변기기를 판매하는 전자 상거래 회사입니다. 1년에 순이익이 9천만 달러 정도고요. 그런데 어떤 비영리 공익 단체가 제 고객에게 타격을 입힐 만한 정보를 일주일 뒤에 공개할 준비를 하고 있습니다. 저희는 그 단체 내부에 사람을 심어놔서 최종적으로 그 정보를 공개하는 자가 누군지 알아내도록 미리 손을 써놨습니다. 그 단체가 정보를 공개할 때쯤이면 내부에 심어둔 사람은 별 문제가 없을 겁니다. 그렇지만 정보를 공개하는 날, 그 단체의 웹사이트를 다운시키거나 접속 불가능하게 만들어야 합니다. 주식 시장이 마감돼서 거래가 종료될 때까지만 그렇게 하면 됩니다. 그 단체에서 공개하려는 정보는 일부 투자자들에게 민감하게 작용해서 저희 고객의 주가에 악영향을 끼칠 수도 있거든요. 그날만 웹사이트를 다운시켜놔도 되는 건 바로 그 다음 날에 분기 실적 보고서를 발표하기 때문입니다. 그래서 제 고객은 분기 실적 보고서를 발표하기 전까지는 주가가 곤두박질치는 걸 보고 싶어 하지 않습니다.” 이렇게 말한 그 남자는 피닉스의 응답을 기다렸다.

“그럼 제가 그날 웹사이트를 다운시켰으면 하는 겁니까?” 피닉스가 물었다.

“그렇습니다” 그 남자가 대답했다.

“아예 웹사이트를 변조하는 건 어때요?” 피닉스가 물었다.

“안 됩니다. 해당 웹사이트에 무슨 기술적인 문제가 있는 것처럼 꾸며야 합니다. 그 단체는 후원을 받는 걸로 알고 있습니다. 따라서 자체적으로 최소한의 대역폭으로 해당 웹사이트를 호스팅하고 있을 것으로 짐작하고요.”

피닉스는 잠시 생각한 후 대답했다. “알겠습니다. 그럼 그 비영리 단체 이름이 뭐죠?”

남자는 재빨리 커다란 갈색 봉투를 테이블 위에 꺼내놓고 대답했다. “이 안에 필요한 정보가 모두 들어 있습니다. 저는 당신이 실패하지 않을 거라 생각합니다. 돕스 씨도 당신이 일을 잘한다고 했고 만약 이 일에 실패하면 자기가 직접 일을 처리할 거라고 전하라고 했습니다. 이 안에는 이 일에 필요한 문서를 비롯해서 현금으로 5천 달러가 들어 있습니다. 공격 당일 날 같은 시각에 여기서 나머지 5만 달러를 추가로 드리겠습니다.”

피닉스가 “알겠습니다.”라는 말을 채 입에서 꺼내기도 전에 남자는 일어서서 출입구로 향했다.

집으로 오는 길에 피닉스는 웹사이트 공격에 관한 다양한 기법들을 머릿속에 떠올려 보면서 시나리오를 그렸다. 집에 도착할 때까지도 갈색 봉투는 열어 보지도 않았다. 거실에 있는 소파에 누워 갈색 봉투에 붙은 테이프를 떼고 봉투를 열었다. 첫 페이지에는 공격 대상에 관한 자세한 정보가 들어 있었다. 공격 대상 단체의 이름인 “The Truth(진실)”를 보고 피닉스는 키득거렸다. “멋진데?” 피닉스가 혼자 크게 중얼거렸다. 그런 다음 소파에서 일어나 봉투를 쥐고 책상으로 가서 이 회사의 웹사이트에 들어갔다. 브라우저에서 www.thetruthsa.org를 입력하자 그림과 같은 화면이 나타났다.

www.thetruthsa.org 웹 사이트

사이트는 매우 조악해 보였다. 다음으로 이 비영리 단체에 관한 사전조사를 하기로 마음먹었다. 구글을 통해 이 단체에서 고등학교 학생들에게 실습 목적으로 이 웹사이트를 구축하게 했다는 기사를 찾기까지는 얼마 걸리지 않았다. “흠” 피닉스가 중얼거렸다. “분명 이 사이트를 사전 설계할 때는 보안에 신경 쓰지 않았을 테고 대역폭도 제한돼 있을 거야.” 피닉스는 이 페이지를 즐겨찾기에 추가해 두고 일어나 침실로 향했다.

(다음 글에서 계속 이어집니다)

————- o ————

소프트웨어 컨플릭트 2.0 (로버트 L. 글래스 지음, 박재호ㆍ이해영 옮김)

이제 ‘현재 누가 소프트웨어 유지보수를 수행하는가’라는 질문으로 돌아가자. 대다수 전산 업계에서는 신참이나 개발에 능숙하지 않은 사람이 유지보수를 맡는다. 이유가 있다. 대다수 사람들이 유지보수보다 개발을 선호하기 때문이다. 유지보수는 창의력을 너무나 제한하므로 즐기기 어려운 탓이다. 그러다 보니 자연적으로 가장 능력이 떨어지고 가장 수요가 낮은 인력이 대개 유지보수를 담당하게 된다.

내 추론을 여기까지 따라왔다면, 현 실정이 올바르지 못하다는 사실을 납득하리라. 유지보수는 골칫거리가 아니라, 상당한 지적 도전이자 해결책이다. 유지보수의 효율을 최대한 높이려면, 유지보수에 인력을 투입하는 방식이 크게 변해야 한다.

해결 방안을 구체적으로 제안하겠다. ‘뜬 구름 잡기’와 같은 이론적 해결책이 아니다. 관리층이 추진하겠다고 맘만 먹는다면 달성이 가능한 방법이다.

1. 유지보수를 매력적으로 만들어라. 유지보수 업무로 사람들을 끌어올 방법을 찾아라. 어떤 회사는 유지보수 담당자에게 상여금을 지불한다. 어떤 회사는 상부 관리직으로 승진하려면 필수적으로 거쳐야 할 단계로 만든다. 어떤 회사는 업계 소프트웨어를 전체적으로 이해하는 최선의 방법으로 기존 소프트웨어를 상세하게 파악하도록 권장한다.
2. 유지보수와 품질 보증을 연결하라.
3. 유지보수 기술을 개선하겠다는 계획을 세워라. 소프트웨어 유지보수를 좀 더 효율적으로 수행하도록 도와주는 도구와 기술이 많이 나왔다(이삼십 년 전에 비하면 크게 달라졌다). 유지보수를 염려하는 관리자라면 교육/도구 선택과 구매에 우선순위를 부여해야 한다.
4. ‘책임 있는 프로그래밍’을 강조하라. 대개 유지보수 담당자는 혼자 일한다. 이런 사람의 업무 효율을 최대화하려면 자기 업무의 품질에 책임을 부여하는 방법이 최선이다. 최근 인기 있는 ‘비자아적 프로그래밍(egoless programming)’이라는 개념과 반대라는 사실에 주목한다. 비자아적 프로그래밍은 최종 소프트웨어 제품에서 프로그래머의 사적 참여를 없애고 팀 참여를 강조한다. 하지만 우수한 제품 품질을 유지하려면 개별 유지보수 담당자에게 소프트웨어 제품 품질에 대한 책임을 부여해야 한다.

이상이 소프트웨어 유지보수를 개선하는 간단한 네 단계이다. 모든 단계에서 전통적인 소프트웨어 사고방식을 바꾸어야 한다는 사실에 주목한다. 기술적인 전환은 쉽지만, 사회적인 변화나 정치적인 변화는 그리 쉽지 않다. 대다수 사람들은 전통적인 시각을 쉽게 떨치지 못한다.
하지만 사고방식을 바꾸려 한다면 반드시 떼야 할 첫 걸음이 있다. 이 수필에서 제시하는 걸음이다.

우리는 소프트웨어 유지보수를 골칫거리가 아니라 해결책으로 보아야 한다. 모두가 이 사실에 동의한다면, 소프트웨어 종사자들이 업무를 수행하는 방식에 커다란 변화의 장이 펼쳐질 것이다. 한번 생각해보라.

————- o ————

소프트웨어 유지보수가 골칫거리인가?

오늘날의 전형적인 답변은 “물론이죠.”이다.

이 전형적인 답변에 대한 전형적인 근거는 이러하다. “우리 회사가 소프트웨어 유지보수에 쏟아 붓는 예산을 보십시오. 처음부터 소프트웨어를 잘 만들었다면, 유지보수에 엄청난 돈을 낭비하지 않아도 될 텐데.”

글쎄다. 나는 이러한 전형적인 답변이 틀렸다는 입장이다. 내가 보기에는 전형적인 근거가 틀렸기 때문이다.

사실, 소프트웨어 유지보수는 골칫거리가 아니라 해결책이다!

소프트웨어를 골칫거리로 바라보는 전통적인 관점에서는 특별한 의미의 두 정보를 간과한다.

1. 다른 ‘딱딱한’ 분야에 비해서 소프트웨어 제품은 ‘부드럽다’. 즉, 쉽게 변한다.
2. 소프트웨어 유지보수는 오류 수정(17%)보다는 개선(60%) 작업 비중이 더 크다.

다시 말하면, 소프트웨어 유지보수는 골칫거리가 아닌 해결책이다. 소프트웨어 유지보수는 어느 누구도 대신 해주지 못하는 우리만 할 수 있는 작업이며, 단지 오래된 문제 위에다 덧칠하는 작업이 아니라 새로운 해결책을 제시하는 작업이기 때문이다. 만약 소프트웨어 유지보수를 골칫거리가 아니라 해결책으로 본다면, 더 나은 유지보수에 대한 새로운 통찰력을 얻을 수 있지 않을까?

나는 정말 그렇다고 주장한다.

소프트웨어 컨플릭트 2.0 (로버트 L. 글래스 지음, 박재호ㆍ이해영 옮김)

유지보수를 골칫거리로 바라보는 전통적인 시각에서는 유지보수의 주요 목표가 비용 감소라고 말한다. 이 역시 나는 잘못된 논지라고 생각한다. 유지보수를 골칫거리가 아니라 해결책이라는 관점에서 보면, 우리가 진정으로 바라는 바는 더 많은 유지보수이지 더 적은 유지보수가 아니라는 사실이 금방 드러난다. 그러므로 유지보수는 최소 비용이 아니라 최대 효율에 중점을 두어야 한다.

이제 새로운 생각을 펼칠 수 있는 지평이 열렸다. 비용 감소에서 효율 증대로 눈을 돌렸으니, 이 새로운 식견을 어떻게 활용할까?

효율을 극대화시키는 최선책은 최고 인력의 활용이다. 이 결론을 지지하는 자료는 많다. 자료 대부분은 ‘개인적 차이’를 논하는 문서에서 찾을 수 있다. 예를 들면 어떤 사람들은 소프트웨어 업무에서 다른 사람들보다 현저한 우위를 보인다.

1. 디버깅: 어떤 사람들은 다른 사람들보다 28배나 우수하다.
2. 오류 발견: 어떤 사람들은 다른 사람들보다 7배나 우수하다.
3. 생산성: 어떤 사람들은 다른 사람들보다 5배나 우수하다.
4. 효율성: 어떤 사람들은 다른 사람들보다 11배나 우수하다.

개인적 차이를 간략히 묘사한 위 목록의 결론은, 사람들 사이에 엄청난 차이가 존재하며 최고 결과를 얻는 최선의 방법은 최고 인력 투입이라는 점이다.

여기서 다음 두 가지 의문이 생긴다.

1. 유지보수 문제에 최고 인력을 투입하는 정책이 타당한가?
2. 현재 유지보수에 최고 인력을 투입하고 있는가?

첫 번째 질문이 두 번째 질문보다 대답하기 어렵다. 첫 번째 질문에 대한 내 대답은 “그렇다. 유지보수는 소프트웨어 비즈니스에서 가장 어려운 업무 중 하나다”이다. 내가 생각하는 이유를 설명하겠다.

수년 전, 소프트웨어 유지보수에 관한 책을 공동으로 집필했었다. 검토 과정에서 익명의 검토자가 유지보수에 대하여 다음과 같은 생각을 피력했었는데, 나는 오늘날까지도 이를 기억한다.

유지보수란,

• 지적으로 복잡하다. (유지보수 담당자에게 극심한 제약이 가해지는 가운데에서도 창조력 발휘가 필요한 작업이다).
• 기술적으로 어렵다. (유지보수 담당자는 개념, 설계, 코드를 동시에 다룰 줄 알아야 한다).
• 불공평하다. (유지보수 담당자는 항상 무어가 부족하다. 예를 들어 우수한 유지보수 문서가 없다).
• 성공이 없다. (유지보수 담당자는 항상 문제가 있는 사람들을 만난다).
• 지저분하다. (유지보수 담당자는 세세한 구현까지 지저분한 수준에서 일해야 한다).
• 과거에 산다. (분명 코드는 누군가 구현에 능숙해지기 전에 작성했다).
• 보수적이다. (“긁어 부스럼 만들지 말자”라는 좌우명을 따른다).

내 결론과 이 검토자의 결론은 같다. 즉, 소프트웨어 유지보수란 매우 복잡하고 어려운 업무이다.

(다음 글에서 계속 이어집니다)

• 인지적 견해: 소프트웨어 설계를 보는 다른 시각 (1)
• 인지적 견해: 소프트웨어 설계를 보는 다른 시각(2): 설계의 본질

————- o ————-

기타 연구 결과

이 외에도 짚고 넘어갈 주요한 발견 하나가 있다. 프랑스 국립 자동화 정보 연구 센터(National De Recherché en Information et en Automatique)에 근무하는 윌레미엔 비저와 같은 연구진은 “설계자들이 무(無)에서 시작하는 경우는 거의 없다”라는 사실을 발견했다. 즉, 시뮬레이션을 시작하는 첫 번째 개괄적인 모델은 앞서 유사한 문제에 사용했던 해결책에서 가져온다는 뜻이다. 돌아보면 에이다 수업에서 보잉사에서 온 젊은 친구가 내 기를 죽였던 방법이 바로 그것이었다. 그는 유사한 문제 유형을 이미 풀어보았고, 그래서 머릿속에 잠정적인 해결책이 들어있었던 것이다!(개인적인 부족을 이렇듯 멋지게 합리화하다니 놀랍지 않은가?).

지금까지는 개인이 수행하는 설계를 언급했다. 하지만 모두 알다시피, 1980년대에 이르러 설계는 팀 업무로 변화했다 .개별 설계자가 감당하기에는 문제가 너무 커졌고, 게다가 다방면에 걸친 문제를 해결하려면 여러 설계자의 다양한 기술이 필요하게 되었다.

앞서 언급한 연구진은 팀 설계도 살펴보았다. 그리고 많은 면에서 팀 설계는 개별 설계의 공유 형태라는 사실을 발견했다.

• 팀은 서로가 공유하는 정신적 모델을 만든다.
• 팀 구성원은 각자 혹은 다 같이 공유 모델을 놓고 시뮬레이션을 수행한다.
• 팀은 시뮬레이션을 평가하고 다음 단계 모델을 준비한다.
• 하지만 팀 설계와 개별 설계가 다른 면도 있었다.
• 설계 과정에서 충돌이 불가피하다. 충돌은 회피라기보다 적절히 관리해야 한다.
• 설계 과정에서 의사소통 기술이 매우 중요해진다.

아무도 책임지려는 사람이 없어서 사안이 ‘구렁이 담 넘어가듯’ 사라지기도 한다.

설계팀은 보통 3명에서 6명이다. 때로 아주 복잡한 프로젝트는 6명으로도 부족하다. 이때는 설계가 조직적인 문제로 변한다. 전형적으로 설계팀이 조직적인 계층으로 발전한다. 수석 아키텍트로 이루어진 특수 팀이 전체 설계를 조정하고, 각 설계팀은 특정 문제 영역을 맡는다.

하지만 팀이든 계층적인 구조이든 (여럿이 참여하는 설계는) 태생적인 문제가 있다. 설계가 위원회 업무로 변질되어서 온갖 단점을 드러내기도 한다(‘낙타는 위원회가 설계한 경주마’)임을 기억하는가). ‘The Mythcal Man Month’와 최근 ‘Silver Bullet’ 논문에서 프레드 브룩스는 현존 최고 제품, 즉 개념적 일관성이 있다고 우리 모두가 인정하는 제품은 개인이 설계한 작품이라는 사실을 지적한다. 물론 에이다, 코볼, IBM 메인프레임 운영체제 등 성공적인 팀 설계도 존재하지만 브룩스가 지적하듯, 이들은 성공했으나 엉성하다는 비판을 받는다.

앞으로 나갈 방향

이제 새로운 사실을 알았다. 설계를 하는 동안 마음속에서는 잘 정의된 절차를 따른다. 기존 모델이나 단순화된 새 모델에서 출발하여 모델로 시뮬레이션을 돌리고 문제를 해결할 때까지 이 과정을 반복한다. 문제가 너무 크거나 복잡할 경우에는 팀이나 심지어 조직이 설계를 수행한다. 팀과 조직은 개인이 사용하는 기술 대부분을 사용하지만, 엉성하나 꼭 필요한 팀 절차도 사용한다.

그럼 새로운 사실을 알았으니 이제 어떻게 해야 할까?

나는 세 가지 범주를 제안한다. 설계는 교육 면에서, 설계 수행 면에서, 설계 관리 면에서 이러한 발견이 의미하는 바를 고려해야 한다.

설계 교육 면에서, 단순히 방법론이나 표현법 몇 가지를 가르치는 일만으로 충분하지 않다. 설계를 정신적인 과정으로 보는 새로운 개념을 토대로 한 기반 틀 안에서 방법론과 표현법을 가르쳐야 한다.

소프트웨어 컨플릭트 2.0 (로버트 L. 글래스 지음, 박재호ㆍ이해영 옮김)

설계 수행 면에서, 설계자는 기존에 생각하던 설계 본질이 틀렸다는 사실을, 오히려 시행착오를 거쳐 가며 반복하던 엉성한 절차가 바로 설계 핵심이라는 사실을 이해해야 한다. 그래야 설계자가 죄책감을 느끼지 않고 올바른 설계 방식을 추구할 수 있다(이를 ‘죄책감 없는’ 설계 방식이라고 불러도 될까? 아니, 너무 심리학적인 용어다).

설계 관리 면에서, 관리자는 의사소통 활성화와 문제 해결에 신경 써서 설계에 기여해야 한다. 한 걸음 더 나가서 실증주의 연구자들은 설계 관리를 통해 설계 과정에서 발생하는 핵심 문제를 관리해야 한다고 제안한다.

더 나은 설계 교육, 설계 수행, 설계 관리라는 목표를 추구하고자, 연구진은 여러 도구 개념을 제안했다. 이런 도구들을 어떻게 만들지 아직 모르지만 가능만 하다면 설계 절차에 대한 이해를 크게 높여줄 것이다.

1. 정신적 절차를 지원하는 모델링/시뮬레이션 패키지
2. 아이디어 누수를 막아주는 아이디어 보관/추출 패키지
3. 핵심 요구사항을 추적하고 설계가 이를 위반할 때 경고하는 전략적 가정 다듬기 도구
4. 사안 기반의 충돌 해결 지원 도구
5. 미해결 사안 기록/추적 도구
6. 중립적인 토론 지원 도구
7. 집단적 아이디어 수집과 조정 도구

하지만 설계 절차를 지원하는 도구를 논하기는 시기상조일지도 모르겠다. 지난 30여 년간 설계가 무엇인지 안다고 생각했다가, 이제 막 진정으로 이해하기 시작했으니 말이다. 당분간은 이 사실만 납득해도 충분하겠다. 이러한 지식을 어떻게 활용할지는 나중에 걱정할 일이다.

이 새로운 발견에 붙일 이름이 필요하다. 연구자들은 이를 ‘인지적 설계 절차’라고 부른다. 마음에 드는 표현이다. 설계가 정신적 절차라는 의미를 내포하기 때문이다.

따라서 이 수필에서는 소프트웨어 설계의 인지적 측면을 다루었다.

(이상으로 “인지적 견해: 소프트웨어 설계를 보는 다른 시각”의 연재를 마칩니다.)