2011년, 2월 6일 룰즈섹이 HBGary 웹 사이트를 해킹했다.[1] 이 때문에 HBGary의 CEO는 사퇴하고 보안회사였던 HBGary의 명성과 신뢰는 한없이 떨어졌다. 피해도 상당했다. 익명의 그룹 룰즈섹은 HBGary를 해킹한 후, 약 6만 개 이상의 메일을 공개하였으며 자신들이 해킹한 사실을 숨기지 않고 오히려 드러냈다. 룰즈섹은 거기서 그치지 않고 그들 주변에 맴돌면서 회사의 보안 의식을 조롱했다.[2] 어쩌다 이러한 상황까지 온 것일까. 가장 큰 문제는 보안 시장에서 어느 정도 자리매김을 하고 있던 보안회사가 막상 자신들은 보안의 취약한 부분들을 대수롭지 않게 넘겼다는 것이다. 오늘은 그들이 간과했었던 부분들과 그리고 왜 그들은 다른 이들보다 더 비판을 받았었는지 에 대해 이야기해보려 한다.
완벽한 보안이라는 것은 없다. 단지, 조금이라도 해킹의 속도를 늦추게 할 뿐이다. 그렇다면 완벽한 보안이란 것이 존재하지 않는데 왜 HBGary의 해킹이 유달리 문제가 되는 것일까. 그 원인은 총 4가지로 볼 수 있다. 먼저 첫 번째, HBGary Federal의 웹 사이트인 hbgaryfederal.com은 취약하게 구현된 CMS로 구동되고 있었다는 것이다. CMS(Content Management System)는 웹사이트를 구성하고 있는 다양한 콘텐츠를 효율적으로 관리할 수 있도록 도와주는 시스템으로 뉴스나 블로그, 뉴스 사이트 등에서 많이 볼 수 있는 구조다.[3][4] 이 CMS 구조는 쉽게 콘텐츠를 관리할 수 있어 많이 사용하는데 문제는 hbgaryfederal.com의 CMS가 제대로 구현되어 있지 않았다는 점이다. 이 때문에 hbgaryfederal.com의 CMS는 SQL Injection 공격에 그대로 노출되었다.[5]
hbgaryfederal.com의 CMS는 데이터를 SQL 데이터베이스에 저장하고, 원하는 특정한 데이터를 불러올 땐 정해진 쿼리를 통해 데이터베이스에서 검색하여 데이터를 가져온다.[6] 예를 들어, CMS 구조로 이루어진 뉴스 사이트에서 기사를 검색하여 보기 위해서는 그 기사 글 ID 번호에 해당하는 매개 변수가 필요하다. 이러한 매개 변수는 일반적으로 웹 사이트의 주소 값을 통해 그대로 노출되어 CMS에 전달된다. 이때, 매개 변수를 처리하는 코드에 결함이 있는 경우 SQL Injection 공격이 가능하다.
특히나, 당시 여러 웹 사이트는 일반적으로 하드 코딩된 쿼리를 이용하여 웹 페이지 주소에서 매개 변수를 주어 데이터베이스에 전달했다. 이때, 종종 매개 변수의 유효성을 확인하지 않고 이 작업을 수행하는데 이러한 취약점은 시스템을 SQL Injection 공격에 그대로 노출되었다. 즉, 룰즈섹은 특수하게 조작된 매개 변수를 CMS에 전달하였고, 데이터베이스는 들어오는 매개 변수의 유효성을 검증하지 않아 룰즈섹이 조작한 쿼리를 그대로 실행한 것이다. SQL Injection 공격을 통해 룰즈섹은 hbgaryfederal.com 데이터베이스에 접근하여 사용자 이름, 이메일, 암호 해시 목록을 가져왔다.[7][8]
암호 해시 목록은 사용자의 암호를 수학적으로 암호화하여 처리된 암호만 저장된 목록으로 해 시화된 암호를 알아낼 수 있는 유일한 방법은 가능한 모든 암호를 한 번씩 시도해보며 찾는 방법뿐이다.[9] 하지만 레인보우 테이블이라는 것이 만들어지면서 이러한 공격에 조금 더 빠르게 암호를 찾아낼 방법이 있긴 하다. 레인보우 테이블이란 일반적으로 가장 많이 쓰이는 암호의 해시 값을 미리 계산하여 만든 목록으로 이를 이용하여 확률이 가장 높은 것부터 대입하며 암호를 찾는 것이다.[10] 그렇다 하더라도 해시 알고리즘이나 암호의 복잡도에 따라 암호를 찾아내는 난이도가 극명하게 달라진다. 그래서 사람들이 최대한 대문자, 소문자, 숫자, 특수문자 등을 섞어 길게 암호를 설정하라는 이유도 여기에 있다. 최대한 길고 복잡하게 해야지 패스워드 크래킹 공격에 그나마 오랫동안 방어를 할 수 있다.
문제는 hbgaryfederal.com의 CMS에서 해시 알고리즘으로 MD5를 사용했다는 것이다. MD5, 이는 보안회사 HBGary가 왜 그렇게 쉽게 뚫렸는지 보여주는 두 번째 원인이다. MD5는 해시 계산은 빠르지만, 해시 당 128 비트의 출력을 생성하여 복잡도는 다른 해시 알고리즘에 비해 높은 편은 아니다.[11] 또한, MD5 해시 알고리즘은 가장 많이 쓰이기도 하고 잘 알려졌어 레인보우 테이블로도 많이 만들어져 있고 구글에서 검색까지 될 정도다.[12][13][14] hbgaryfederal.com의 CMS에서 가져온 해시 암호 목록은 MD5로 해 시화된 암호로 레인보우 테이블 기반 공격에 매우 취약했다. 더욱이, HBGary Federal CEO인 Aaron Barr의 암호는 매우 간단한 조합으로 만들어져 있었기 때문에 레인보우 테이블에서 발견되기 쉬웠다고 한다.[15]
문제는 이번 HBGary 해킹사건과 연관이 깊은 HBGary Federal의 Aaron과 Ted가 아주 일관되게 암호를 사용했다는 점이다.[16] 이것이 다른 사람들이 HBGary 해킹 사건을 냉정하게 바라보게 된 세 번째 원인이다. 그들은 이메일, 트위터, LinkedIn을 포함하여 여러 곳에서 같은 암호를 사용했다. 과정에 대해 좀 더 이야기하자면 HBGary는 SSH 접근 권한을 가진 리눅스 계열의 support.hbgary.com 서버와 웹 서버를 가지고 있었다. 각각의 서버는 접근에 대한 사용자 인증에 사용되는 비밀번호를 가지고 있었으며, 이 두 개의 서버에 로그인할 수 있는 직원 중 한 명이 Ted였다.[17] 문제는 그의 support.hbgary.com 서버 접근 권한 암호가 CMS에서 사용된 부실한 암호를 그대로 사용하고 있었다는 점에서 룰즈섹이 시스템에 바로 접근할 수 있는 원인이 되었다.
SSH는 인증을 위해 암호를 사용할 필요가 없다. 혹여 암호가 유출될 경우를 대비하여 이를 방지하기 위해 다른 곳에서는 SSH 인증에 암호를 사용하지 않고 대신 공개키 암호화를 사용한다. 각 사용자는 개인키과 공개키를 가지고 있으며 이를 이용해서 인증한다. 이러한 개인키는 암호처럼 쉽게 노출되지도 않고 클라이언트 시스템에 계속 숨겨져 있기 때문에 쉽게 재사용할 수 없어 훨씬 더 안전한 옵션이긴 하다. 예를 들어, 한 세트의 키는 여러 서버에서 인증하는데 사용될 수 있지만 웹 사이트에 로그인하는 데는 사용할 수가 없다는 것이다.[18]
룰즈섹은 암호를 유추하여 Ted 계정을 통해 로그인할 수 있었지만, 그는 일반 사용자였기 때문에 무작정 모든 것을 할 수 있었던 것은 아니다. 삭제는 물론 파일도 볼 수 없을 것이고 자신들이 로그인했다는 흔적도 지우지도 못했었을 것이다. 이러한 점은 해커들이 자유롭게 움직이는데 제한이 되기 때문에 보통은 권한 상승을 하려 한다. 룰즈섹도 마찬가지로 HBGary 서버에 침투하여 권한상승을 하기 위해 알려진 취약점을 통해 권한상승을 했다.[19] 이렇게 룰즈섹은 HBGary의 시스템에 확실하게 접근할 수 있게 되었고 그렇게 찾은 것이 기가 바이트 급의 백업 데이트와 연구 자료들이었다.
Ted의 계정이 서버에 접근하기 위해 사용되었다면 Aaron의 계정은 좀 더 큰 문제를 만들어냈다. Aaron이 룰즈섹에 해킹당한 암호는 Google Apps에서도 사용하고 있었으며, 그의 Google 메일함에도 접근할 수 있었다. 하지만 그의 계정은 단순한 사용자가 아닌 회사의 CEO며 메일의 관리자이기도 했다.[20] 이는 다른 계정에 더 높은 접근 권한을 줄 수도 있고 사용자의 암호를 재설정할 수 있으며 다른 계정에도 접근할 수 있다는 것이다. Aaron의 계정은 Greg Hoglund의 메일 계정으로 접근할 수 있는 통로가 되었다.
룰즈섹이 Greg Hoglund의 rootkit.com에 접근할 때에는 약간의 사회공학 기법이 들어갔다. 본래 표준 보안절차 때문에 루트 계정에서 직접 SSH 접근은 불가능하다. 이 때문에 룰즈섹이 접근하기 위해서는 로그인할 때 일반 사용자의 계정이 필요했다. 룰즈섹은 Aaron의 계정을 통해 Greg의 이메일함에 접근을 하였고 거기에서 2개의 정보를 획득했다. 첫째, Greg의 Rootkit.com 사이트를 실행하는 컴퓨터의 루트 암호는 88j4bb3rw0cky88" 또는 "88Scr3am3r88"라는 점과 두 번째로 Nokia의 수석 보안 전문가 Jussi Jaakonaho가 루트 접근 권한을 가지고 있다는 것이다.[21] 룰즈섹은 이러한 점을 이용하여 자신들을 Greg라고 속인 후, Rootkit.com에 접근할 수 있는 통로를 Jussi에게 열어달라는 메일을 보냈다.[22] 이때, 룰즈섹은 교묘하게 계정과 암호를 알고 있었다는 점을 Jussi에게 알려주어 좀 더 자신들을 믿도록 하였다. Jussi는 그렇게 룰즈섹에 속아 Rootkit.com으로 연결되는 통로를 열어주었고, 룰즈섹은 Rootkit.com에 접근할 수 있었다. 이런 중요한 기능에 접근 권한을 단순히 메일로만 상대방을 확인하여 쉽게 사회공학 기법에 걸려들어 갔다는 점은 HBGray 해킹 사건이 더 커진 네 번째 원인이 되었다.
룰즈섹은 Greg로 로그인하여 루트 권한으로 전환한 다음, rootkit.com의 사용자 데이터베이스를 다운로드하여 사이트에 가입된 모든 회원의 이메일 주소와 암호 해시 정보를 탈취했다. 더불어 rootkit.com 역시 hbgaryfederal.com의 CMS 시스템처럼 MD5로 암호가 해시화 되어 있어 암호를 추적하는데 어렵지 않았을 것으로 추측한다. 그렇게 룰즈섹은 rootkit.com 사이트를 다운시켜버리고 자신들이 해킹을 통해 가져온 자료와 정보를 공개해버렸다.[23]
정리하자면, HBGary는 SQL Injection에 취약한 시스템을 사용했을 뿐만 아니라 비밀번호 암호화에 사용된 해시 알고리즘도 취약한 알고리즘을 사용했다. 더불어, 권한 있는 사용자의 같은 암호의 사용은 HBGary 해킹사건을 더 크게 만들었고, 최신 패치 되지 않은 서버나 암호 기반 인증을 허용한 서버도 문제가 되었다. 심지어 이메일을 통해 권한을 주어준 것 역시 주목해서 봐야할 점이라는 생각이 든다.
본래 해커들은 일반적으로 해킹을 하기 전에 그 시스템에 침입하여 최대한 많은 정보를 모으고 그 정보를 이용하여 시스템을 손상하거나 원하는 정보를 가져온다. 제로 데이나 사회공학 기법을 사용할 필요가 없는 것이다. 그러한 점에서 룰즈섹은 HBGary 해킹이 상당히 효과적으로 공격이 들어간 해킹임을 알 수 있다. 우리가 HBGary 해킹 사건에서 주목해야 할 점은 우리는 분명 위에 있는 원인을 모두 다 알고 있다는 점이다. SQL Injection을 방어하기 위한 필터링 기법이나 같은 암호 사용의 위험성, 취약한 암호화 기법, 사회공학 기법 등 우리가 알고 있고 인지하고 있었다는 것이다. 중요한 것은 알고 있느냐가 아니라, 알고 있는 것을 잘 기억하고 보안을 잘 수행하고 있느냐가 중요한 것이 아닐까란 생각이 든다.
=> 룰즈섹, HBGary 해킹 ②
