본 글은 취약점을 발견하여 알린 Daniel Svartman의 Discovering a Session Hijacking Vulnerability in GitLab 글을 바탕으로 작성한 글임을 밝힙니다.

개발자에게 소스 코드 관리란 중요한 요소다. 복사, 코드 수정의 반복으로 여러 개의 코드 파일들 속에 숨어 버린 이전 코드 찾기에 급급하고, 이전 코드와 현재 코드를 비교하여 보려고 해도 파일 관리가 안 되면 막막하기 그지없다. 소스 코드 관리의 중요성은 회사 업무에서도 나온다. 어느 한 곳에서는 회사에서 소스 코드를 관리하지 못하는 회사는 빨리 튀는 것이 상책이라는 말이 나오기도 한다. 그런 의미로 최근에는 이런 소스코드를 관리해주는 소프트웨어, 웹 저장소 등이 많이 나와 있기도 하다. 그 중 Github, GitLab은 아마도 전 세계에서 가장 많이 쓰이는 프로그램 관리 저장소이지 않을까 생각한다. 두 개의 서비스는 소스 코드를 관리해주는 것에 있어서 같은 서비스를 제공하지만, 조금은 다른 점이 있어 각자 필요에 따라 사용되곤 한다. 오늘은 개발자의 소스 코드를 관리해주는 Git과 관련된 이야기는 아니고, Github, GitLab 이 두 개의 코드 저장소 중 GitLab에서 발견된 취약점에 관해 이야기해볼까 한다.

그럼 시작 전에 우리는 컴퓨터를 하는 사람으로, 살짝 논외이긴 하지만 가벼운 마음으로 깃랩(GItLab)과 깃헙(Github)의 차이를 알아보자. 먼저 Git이란, 소프트웨어를 개발하는 프로젝트에서 소스 코드를 효율적으로 잘 관리하기 위해 등장한 도구로 이를 형상 관리 도구(Configuration Management Tool)라고 한다.^[1] Git과 비슷하게 SVN라는 것이 있는데, 둘 다 소스코드를 효율적으로 관리하는 형상 관리 도구지만 살짝 다른 점이 있다. SVN은 중앙 집중식 소스코드 관리 방식이라면, Git은 분산 소스코드 관리 방식을 사용하여 중앙에서 소스코드가 삭제되더라도 분산된 로컬 저장소에서 다시 복원할 수 있다.^[2] Git을 사용하면 소스코드를 주고받기도 쉽고, 동시에 작업 처리도 가능할뿐더러 버전 관리도 용이하여 생산성이 향상하는 데 똑똑히 한몫한다. 이뿐만 아니라 이전 소스 코드로 점프하거나 인터넷 없이도 코드 개발이 가능하다는 점에서 체계적인 프로젝트 관리를 만들어낼 수 있다.

이런 소스코드 관리 프로그램에도 여러 프로그램이 존재하는데, 그 중 GitLab과 Github은 형상 관리 도구로 많이 쓰이며 굉장히 유명한 코드 관리 프로그램들이다. 유사한 기능을 제공하는 두 개의 서비스는 상당히 비슷하지만, 이 둘에게는 분명히 다른 점이 있다. 먼저, Github은 공개되어 있는 공간이기 때문에 Open Source Project가 많이 진행되며, 만약 private repository로 사용하려면 일부 금액을 내야 하므로 개인 프로젝트를 할 때는 사용이 어려울 수도 있다. 반면, GitLab의 경우는 private repository를 사용하려  할 때 무료로 사용할 수 있고 개인 서버 설치를 할 수 있어 개인 서버에 코드를 저장하길 원한다면 GitLab을 설치하여 사용해 볼 수도 있다. 정리하자면, Github은 Open Source로 된 프로젝트를 진행할 경우 사용해볼 만하지만, Close Source 프로젝트를 진행할 때는 GitLab을 사용해보는 것이 좋을 것 같다.^[3][4][5]

GitLab에서 문제점을 발견한 것은 지난 5월이었다. 이를 발견하고 처음 공개한 Daniel Svartman은 GitLab의 취약점을 알게 된 계기가 사용자의 세션 토큰이 URL에 적나라하게 보여 문제가 있음을 알았다고 한다.^[6] 이는 세션 하이재킹 공격을 허용할 수 있는 취약점으로 토큰을 복사 및 붙여 넣기 하여 사용자의 대시보드에 접근하거나 사용자 계정 정보, 개별 프로젝트 코드 등 GitLab 플랫폼에서 실행 가능한 모든 항목에 접근할 수 있는 취약점이었다.^[7] Daniel Svartman는 이를 발견하고 이 상황이 일시적으로 보인 버그 혹은 오류였는지 확인하기 위해 다른 여러 브라우저와 시스템에서 같은 토큰을 사용하였고, 모두 같은 결과를 보이며 취약점임을 확인했다. 이와 더불어, Daniel Svartman는 GitLab에서 세션 토큰을 통해 지속해서 사용자를 인증한다는 것도 찾아냈다.^[8] 이는 한번 로그인 인증이 완료되면 사용자가 오랫동안 활동하지 않더라도 혹은 로그아웃한 경우에도 사용자 로그인 인증이 만료되지 않아 계속해서 인증되어 있는 상태를 의미한다. 즉, 다른 사용자의 토큰을 훔치면 언제라도 사용할 수 있음을 의미하며 토큰의 길이도 20자 정도에 불과해 무차별 공격에도 취약하다는 것이다. 따라서, Daniel Svartman는 이와 같은 취약점을 확인하였고, 그들이 부여한 관리자 수준의 접근을 고려했을 때 이는 실제로 우려할만한 부분임을 생각했다고 한다.^[9]

이를 확인한 Daniel Svartman는 올해 5월쯤 GitLab에게 연락을 하여 취약점에 대해 알렸다. 하지만 GitLab은 이미 이와 같은 문제로 많은 이가 연락했었다며 Daniel Svartman는 말했다. 이후 보안 패치와 관련하여 GitLab과 계속해서 연락하였고 현재는 보안 패치가 완료된 상태다. 그들이 한 패치는 먼저 개인 토큰을 RSS 토큰으로 대체하여 세션 ID가 노출되지 않도록 수정하였다. 또한, 기존에 사용하던 개인 토큰의 기능과 같지만, 역할 기반 액세스 제어를 제공하는 개인 액세스 토큰으로 확장함으로써 더 나은 보안을 제공하였다. 마지막으로 GitLab은 점차 개인 토큰을 단계적으로 사용을 제거하고 있으며 얼마 안 있어 완전하게 교체가 될 것이라며 이를 알렸다. Daniel Svartman는 GitLab에서 보안패치를 적용할 때까지를 기다렸다가, GitLab이 취약점을 보완한 후에 취약점에 대해 공개 여부를 확인받은 뒤 공개하였다고 전했다.^[10]

그렇다면 세션 하이재킹(Session Hijacking)이란 무엇일까. 먼저 세션(Session)이란, 두 대의 컴퓨터가 연결되어 활성화된 상태를 말하는데, 말 그대로 해석하면 이 활성화된 상태를 가로채는 것이다.^[11] 좀 더 정확히는 TCP 세션 하이재킹이라 하여 서버와 클라이언트가 TCP를 이용해서 통신하고 있을 때, RST 패킷을 보내 일시적으로 TCP 세션을 끊고 시퀀스 넘버를 새로 만들어 세션을 빼앗아 인증을 가로채거나 회피하는 공격이다.^[12] 즉, 세션 하이재킹은 두 시스템 간에 연결이 활성화된 상태에서 사용자의 로그인 된 상태를 가로채는 것을 말한다. 세션 하이재킹 공격은 시간이 지나면서 공격의 의미는 같지만 이를 행하는 방법은 상당히 다양해졌다.^[13][14] 예를 들어, 같은 DDoS 공격이라고 해도 그 방법이 달라진 것처럼 세션 하이재킹도 여러 방법으로 이루어진다는 것이다. 그렇다면 세션 하이재킹은 막을 수 없는 것인가. 여러 요소가 있겠지만, 필자가 생각하는 핵심은 웹을 설계할 때 만드는 여러 가지 기능 구현 방식에서 개발자가 보안적인 요소를 확인하지 않았기 때문이라고 본다. 앞서 얘기했듯이 통신의 보안을 위해 HTTPS가 만들어지고, 토큰 보안을 위해 RSS 토큰이 만들어졌다.^[15][16] 개발자가 만약 보안에 대해 신경을 썼다면 문제가 덜 하지 않았을까 생각된다. 

90년대 전설적인 해커 케빈 미트닉에 의해 처음 등장한 세션 하이재킹은 30년이 다 되어가도 여전히 계속해서 나오는 고전적인 웹 취약점이다. 특히나 오늘 얘기한 GitLab 외에도 vmware, 드리덱스 등 세션 하이재킹을 이용한 공격은 꾸준하게 나타나고 있다.^{[17][18][19][20]} 2016년에 열린 기크폰(GeekPwn) 마카오 2016 대회에서는 차오 유에라는 해커가 TCP 하이재킹에 성공하여 눈길을 끌기도 하였다.^[21] 그만큼 해커들이 꾸준하게 공격해오는 사랑받는 취약점으로 이를 이용한 범죄도 빈번하게 일어나고 있다는 것이다. 하지만 너무 자주 많이 발생하는 취약점이어서인지, 이에 대해 큰 위협감을 못 느끼는 것 같다. 따라서 이번에 발생한 GitLab 사건이 워낙 많은 사건에 묻혀 약간의 작은 소동이 아니라 웹을 다루는 다른 기업, 다른 곳에서도 이와 같은 사건을 생각하고 사실상 주의해서 봐야할 사건임을 알리고 싶다.