본문 바로가기

서버운영 (TA, ADMIN)/정보보안

[정보보안] 인증과 세션을 이용한 웹애플리케이션 공격

웹 애플리케이션에 인증하면 개인화된 브라우징을 하게 되고, 한편 세션 관리 시스템은 모든 요청과 응답내용을 추적하고 관리하여 쇼핑이나 지불 결제와 같은 다단계 행위를 할 수 있도록 돕습니다. 말하자면 같은 냄비 안에 든 두가지 콩이라고 할만합니다. 애초에 HTTP 프로토콜은 이전 상태를 추적하지 않는 프로토콜로 만들어졌기 때문에 인증이나 세션 관리 모두 고려되지 않았습니다. 하지만 인터넷이 무르익어가면서 이 두 가지 특성이 더 많이 이용됨에 따라 상황은 더욱 복잡해 졌습니다.


불행히도 인증과 세션 관리는 많은 웹 애플리케이션을 취약하게 만든 셈입니다. 그 각각을 공격하는 도구와 기술은 조금 다르지만 서로 밀접합니다.


경로 횡단 공격은 웹 서버의 디렉토리 구조에 접근할 권한이 있을 때 발생하게 됩니다. 이런 상황은 대부분 웹 서버에 파일을 올릴 수 있을 때, 공격자는 웹 애플리케이션이 처리할 악성 입력 값을 정교하게 다듬어 웹 서버 안의 민감한 디렉터리에 접근합니다.



인증과 세션 취약점


오늘날의 인터넷은 인증을 사용하고 세션을 관리하느라 애초에 설계된 것이 비틀어지고 일그러지다 종국에는 그마저도 깨뜨려졌습니다. 인증을 무력화하는 가장 흔한 방법은 프록시에 기반한 공격 도구를 이용하여 합법적은 사용자의 로그인 계정을 무작위 공격으로 훔칩니다. 이런 공격은 보통 은밀히 진행하지 않더라도 사용자가 취약한 비밀번호를 계속 사용하기 때문에 성공적인 편입니다. 여기서는 Burp 공격 툴을 기본으로 가장 많이 사용되는 취약한 비밀번호를 조합해서 공격하기로 합니다. 이런 식으로 웹 애플리케이션의 인증 메커니즘을 공격할 때 염두에 두어야할 요소는 다음과 같습니다.


애플리케이션 로그인

비밀번호 변경

보안 질문

예측 가능한 사용자 이름

예측 가능한 초기 비밀번호

만료되지 않는 비밀번호


보통 세션을 공격하는 것은 두 가지 의미가 있습니다. (1)세션 식별자가 만들어지는 복잡도 측변을 공격하는 경우와 (2)웹 애플리케이션에서 쿠키가 어떻게 사용되즌ㄴ지를 공격하는 경우가 그것입니다. 여기서 세션이 만들어지는 알고리즘을 공격하기란 매우 힘든데, 왜냐하면 해커가 수천 개의 쿠키를 간단히 만들 정도의 연산 능력을 갖고 있더라도 웹 서버에 기본 묶음으로 공급되는 세션 관리 프레임워크는 쉽게 추측되지 않은 채 쿠키를 만들 수 있기 때문입니다. 그래서 애플리케이션에 쿠키가 어떻게 사용되는지를 조사하는 게 더 현실 적입니다. 이 방법은 쿠키가 어떻게 만들어지는지 이해할 필요 없이, 다만 쿠키에 부정한 방식으로 접근하고 이용하는데 초점을 맞추면 됩니다. 즉 안전하게 만들어진 쿠키를 몰래 훔쳐 사용하는 것입니다.



경로 횡단 취약점


웹 서버가 설치되고 설정될 때를 살펴보면, 웹 서버에 있는 약간의 파일 시스템이 웹 애플리케이션이 데이터를 저장하고 사용할 수 있는 공간으로 주어집니다. 이렇게 허용된 디렉터리는 보통 웹서버의 깊숙한 곳에 자리잡은 몇 개의 폴더에 지나지 않으며, 정상 환경에서 웹 애플리케이션이 수행하는 것들로 100% 채워지는데, 프로그램, 이미지, 데이터베이스, 스타일 시트, 애플리케이션을 필요로 하는 것들이 그것입니다. 애플리케이션은 이렇게 미리 정해진 디렉터리 이외의 자원에 접근할 수 없는데 왜냐하면 그 밖의 자원은 같은 웹 서버 안에 있더라도 애플리케이션의 범위 바깥에 있기 때문입니다. 경로 횡단 공격은 이처럼 접근할 수 없는 영역의 한계를 깨뜨리고 웹 서버의 자원을 자유자재로 이용할 수 있는 능력을 뜻합니다.



무작위 인증 공격


메인 로그인 페이지 이외에도 웹 애플리케이션의 다른 여러 곳에서 인증이 일어납니다. 즉 비밀번호를 바꿀 때, 계정 정보를 갱신할 때, 비밀번호 복구 기능을 쓸 때, 보안 질문에 답할 때 등입니다. 만일 이들 중 어느 하나에 문제가 생기면 다른 모든 인증 메커니즘은 뚫리게 됩니다. 인증 취약점이 끔찍한 이유는 하나가 뚫리면 모든 계정이 일거에 노출된다는 점 때문입니다.


여기서는 DVWA를 이용하여 온라인상에서 무작위 인증 공격을 연습해 보면, 이때 보통 웹 애플리케이션의 90% 정도가 쓰는 HTML 폼 기반의 인증 방식을 이용합니다. 일부에서는 CAPTCHA나 양방향 질문과 같은 요소를 인증 절차에 포함하지만, 사용자명과 비밀번호를 입력하는 방식이 여전히 가장 대중적인 인증 메커니즘임을 부인할 수 없습니다.


이 공격은 John the Ripper를 이용하여 오프라인에서 비밀번호 해쉬 값을 깨는 것과는 많이 다릅니다. 여기서는 인증 과정 중에 웹 애플리케이션 및 데이터베이스와 상호작용하여 사용자명과 비밀번호를 직접 처리합니다. 그래서 온라인에서 무작위 인증을 해킹할 때는 애플리케이션에 연속적으로 요청을 보낸 후 응답이 되돌려질 때까지 기다려야 하므로 오프라인에서 비밀번호 해쉬를 깰 때보다 훨씬 더디게 진행되는 특징이 있습니다.



세션 공격


해커들이 세션 취약점을 공격하는 데 사용되는 가장 대중적인 세션 공격법은 다음과 같습니다.


세션 가로채기: 공격자는 이 방법으로 사용자의 세션 식별번호를 훔쳐서 해당 사용자를 가장합니다. 세션 식별자를 훔치는 방법은 여러 가지가 있으나 XSS가 가장 일반적입니다.


세션 고착화하기: 이 방법은 공격자가 애플리케이션으로부터 유효한 세션 식별자를 할당받은 후, 이 세션을 다른 사용자에게 제공합니다. 보통 사용자가 웹 URL 링크를 누르도록 하는 방법이 흔히 사용됩니다. 일단 사용자가 링크를 눌러 애플리케이션에 진입하면 공격자는 똑같은 세션 식별자로 해당 사용자인양 가장합니다. 이 방법은 웹 서버가 사용자로부터 세션을 접수하더라도 인증에 기반하여 새로운 세션을 할당하지 않는 경우에도 씁니다. 이 경우 공격자는 자신이 먼저 선택한 세션을 피해자에게 보냅니다. 이 공격법이 유효한 까닭은 세션 식별자가 여러 세션에서 재사용(또는 반복 사용)해도 서버가 이런 상황을 제한하지 않기 때문입니다.


세션 기부하기: 이방법은 세션을 고착화하는 것과 비슷하지만, 사용자의 세션 식별자를 가장하지 않고 공격자 세션 식별자를 사용자에게 보내어 은밀히 일련의 행위를 처리하게 합니다. 이러한 전형적인 사례는 사용자에게 유효한 세션 식별자를 보내어 아무 정보도 표시하지 않은 채 공격자의 프로필 페이지와 엮이게 합니다. 그 후 사용자가 (비밀번호, 신용카드 정보와 다른 쓸만한 내용을) 폼을 띄어 입력하면, 그 정보는 실질적으로 공격자의 계정에 엮이게 됩니다.


URL에 있는 세션ID: 요청과 응답의 순환구조에서 세션 식별자가 URL의 매개변수로 전달 될 때가 있습니다. 그때 공격자는 해당 URL의 사용자 영역에 앞에서 설명한 공격 방법 중 하나를 적용하여 공격합니다.



쿠키 깨뜨리기

보안 전문가로 처음 일을 시작하면 누구나 세션 만드는 알고리즘을 깨어 세션 식별자를 예측하려고 합니다. 한 예로 응용프로그램을 만들어 애플리케이션에 로그인하고, 할당된 쿠키를 가져오고, 애플리케이션에 로그아웃하는 사이클을 수백만번 반복했습니다. 그렇게 백만 개의 세션 식별자를 수집해서는 데이터베이스에서 똑같은 쿠키가 있는지 검토했으나, 그런 경우는 없었습니다. 그래서 쿠키를 생성하는 알고리즘을 깨고자 한다면, 수백년이 걸립니다. 그런 면에서 알고리즘을 깨뜨려서 웹 애플리케이션을 공격하는 것이 가장 빠른길이라고 믿는다면 이는 오산입니다.


예전엔 세션 식별자가 취약한 알고리즘으로 만들어진 적도 있지만 오래전의 일입니다. 웹 관리자가 애플리케이션 환경을 완전히 엉망으로 설정했거나, 혹은 세션을 만드는 알고리즘을 공개해서 누구나 볼 수 있도록 하지 않는 한 세션 식별자를 만들어내는 알고리즘을 공격하기란 쉽지 않습니다.



다른 쿠키 공격 방법

세션 식별자를 겨냥한 공격법은 모두 쿠키를 재사용하는 것과 관련 있습니다. 누구에게 쿠키가 발행되었는지, 해커가 그 쿠키를 어떻게 훔쳤는지, 또는 어떻게 재사용할지 여부는 상관없습니다. 다만 애플리케이션이 이전의 쿠키가 한 번 이상 재사용되어도 완전하게 기능을 하는지가 중요할 따름입니다. 즉 유효한 세션 식별자를 전해준 애플리케이션에 그 쿠키를 재사용했을 때 취약한지 확인할 수 있는 일련의 테스트를 해보면 됩니다.


(1) 애플리케이션의 내 계정 페이지와 같이 활성화된 세션이 있는 페이지에서 로그아웃한 다음, 브라우저의 뒤로 가지 버튼을 누르고 다시 그리기 했을 때 여전히 접근이 가능한가 확인합니다.

(2) 세션 식별자를 문서 파일로 복사해두었다가 로그아웃한 다음에 다시 사용해봅니다. 이전의 세션 식별자를 얻으려면 가로채기 프록시를 스면 됩니다.

(3) 애플리케이션의 타임아웃 제한을 테스트하기 위하여 유효한 세션 식별자를 얻은 다음 몇시간 동안 브라우저를 쓰지 않고 내버려둡니다. 사람들은 실제로 세션이 끝나지 않았는데도 세션이 끝났다고 경고 창을 띄워주면 습관적으로 [OK]를 누릅니다.

(4) 많은 애플리케이션은 방문한 사이트에서 심지어 로그인하기 전에도 쿠키를 발행합니다. 그 세션 식별자를 문서 파일에 복사해두고 로그인합니다. 로그인하기 전에 처음 방문했을 때 받은 식별자와 인증을 완료한 다음 발급된 세션 식별자가 서로 같은지 비교합니다. 그 둘은 분명히 달라야 하는데, 만일 서로 같다면 세션 기부하기 관련된 취약점이 있다는 뜻입니다.

(5) 서로 다른 브라우저로 똑같은 애플리케이션에 로그인해서 해당 애플리케이션이 이중 로그인을 허용하는지 확인합니다. 만일 두 세션 모두 살아있다면 세션 식별자도 같은지 비교합니다. 똑같은 게정으로 다른 곳에서 동시에 로그인했을 때 먼저 로그인한 세션에 경고가 나오는지 확인합니다.



경로 횡단 공격


경로 횡단 공격은 웹 서버 관리자와 웹 프로그래머가 권한을 확인하고 모든 웹 애플리케이션 사용자를 특정 디렉터리 안에서만 머물도록 설정해놓은 제한을 해커가 우회하려고 할 때 발생합니다. 이 공격은 종종 애플리케이션에 정상적으로 인증한 사용자가 시도하며, 정상적인 사용자가 접근할 수 있는 자원의 범위를 충분히 검토하여 향후 악의적인 요청을 보낼 때 참고로 삼습니다. 정상적인 사용자가 접근했을 때의 매개변수와 게스트 계정으로 접근했을 때를 구분하는 것은 매우 어렵습니다.