버그헌팅 #3 웹 취약점

 

아이돌 취약점은 주로 접근제어와 관련이 있다. 동일한 권한 수준을 가진 다른 사용자에 엑세스하거나, 공격자가 더 높은 권한을 가진 사용자에 접근하는 취약점에 관한 것이다. 공격자가 uid를 바꿔 다른 사람의 정보를 볼 수 있는 게 전형적인 아이돌 취약점이다. 파라미터가 숫자값일 때 특히 이런 경우가 발생한다. 그렇기에 파라미터가 단순 숫자값인 것을 피해야 할 것이다.

 

그런데 모든 아이돌 취약점이 동일한 방식으로 찾아낼 수 있는 것이 아니다. 문자열로 아이돌 취약점을 트리거하는 경우도 있다. http 메서드 변경이나 컨텐츠 타입 변경의 방식으로도 가능하다. 혹은 기대하는 값을 변경하는 방법도 있다. 그렇기에 다양한 시나리오가 있다는 점도 간과해서는 안 될 것이다.

 

다음은 이번 보안기사 시험에도 등장한 XSS다. 정말 널리 알려져있는 공격이고, 매번 보안 이슈에서 빠질 수 없는 공격이다. 매우 오래된 공격임에도 불구하고 최근까지도 나타나고 있다는 점에서 항상 유의해야 할 공격이다. 일반적으로는 위의 3개 주요 XSS에 대해서만 알지만, 다른 더욱 고도화된 XSS에 대해서도 알아두는 것이 좋을 것이다.

 

반사형 XSS의 핵심은 사용자의 액션에 의해 트리거된다는 점이다. 공격자는 이메일 등을 통해 사용자에게 악성 URL을 공유하고, 사용자는 전달받은 URL을 클릭해 서버에 요청하게 된다. 웹 서버는 응답을 하게 되고, 그 응답에는 악성 스크립트가 실행된다. 그리고 사용자의 개인정보가 탈취되어 공격자에게 전달되는 것이다.

 

저장형 XSS는 웹서버에 악성 스크립트가 저장되어 사용자가 해당 사이트를 찾아갈 때마다 문제가 생기는 것이다. 공격자는 보안이 취약한 웹사이트를 찾아내고, 그곳의 게시판에 사용자의 정보를 빼낼 수 있는 게시글을 작성하는 것이다. 그리고 사용자가 그 글을 읽으려 클릭하면, 악성 스크립트가 사용자에게 전달되어 실행된다. 그렇게 사용자의 민감정보가 공격자에게 유출되는 것이다. 

 

DOM 기반 XSS는 자바 스크립트의 취약점을 이용해 DOM 객체를 이용하는 과정에서 발생한다. 공격자는 메일, 메시지 등을 통해 악성 URL을 일반 사용자에게 전달한다. 사용자는 URL를 클릭할 때 문제가 발생하게 되는 것이다. 악성 URL 클릭 후 HTML 문서 요청을 하는 과정에서 사용자의 브라우저에서 악성 스크립트가 실행된다. 반사형 XSS와 DOM 기반 XSS이 마치 비슷한 것처럼 보이지만, 둘의 가장 큰 차이는 DOM 기반 공격에서는 서버의 스크립트 사이드 공격 흔적이 남지 않는다는 것이다. 모든 공격이 사용자의 브라우저 상에서 일어나기 때문에 서버에 기록이 남지 않는다는 것이다.

 

XSS를 다뤘다면, 당연히 친구처럼 등장하는 게 CSRF다. XSS와 CSRF의 가장 큰 차이는 공격자가 사용자의 의지와 무관하게 사용자가 요청한 것처럼 위장하여 공격을 수행하는 것이다. 사실 위의 그림 같은 경우는 요즘에는 인증방식이 강화되어서 힘들지만, 이런 공격이 여전히 가능하다는 것은 알아두어야 한다.

 

또 뺄 수 없는 게 SQL 인젝션이다. SQL 인젝션에 대해서도 진짜 수도 없이 공부한 것 같다. 서버단 검증, 선처리 질의문 사용, 특수문자의 일반문자 치환, HTML 태그 허용시 화이트 리스트 정책 적용 등.. 이거는 적어도 몇 년은 잊지 못할 것 같다. 

 

다음은 File Inclusion 취약점이다. 디렉토리 트래버설과 좀 유사하지만 차이가 있다. 우선 LFI, Local File Inclusion이라는 개념에 대해 알아야 하는데, 로컬에 있는 파일을 읽는 기능이다. LFI 취약점을 통해 시스템에 있는 임의의 파일을 읽을 수 있는 것이다. LFI 공격을 다양하게 응용할 수 있어서 더욱 문제가 된다. 근데 LFI 말고 RFI 라는 것도 있다. Remote, 원격 파일과 관련된 공격이다. 공격자는 원격 서버에서 호스팅되는 파일을 웹 애플리케이션에 포함시키고, 실행시킬 수 있게 되는 것이다. 악성코드를 포함한 파일, 쉘 코드를 미리 준비해놓고는 취약한 웹서버에서 이를 포함하도록 만드는 것이다. 

 

다음으로 SSRF 공격이 있다. 이 공격은 공격자가 서버로 하여금 임의의 외부 요청을 전송하도록 만드는 방식이다. 이는 서버가 다른 시스템과 상호작용하도록 조작될 수 있음을 의미한다. SSRF가 HTTP 요청에만 국한되지 않는다는 게 문제가 된다. SSRF는 다양한 환경과 조건에서 발생할 수 있다. 데이터베이스에 연결 요청, SMB, SSH 커넥션, 컬 명령어의 파라미터 요청 등으로 발생할 수 있다. 넓은 범위에서 발생하기에 이것도 대비하는 것이 필요하다.

 

그런데 이런 취약점들이 있다는 건 알겠는데, 그럼 어떻게 대비를 해야 할까? 시나리오를 만들어야 한다는 것이다. 가능한 공격 시나리오를 최대한 떠올리고, 그것을 토대로 대책을 세울 수 있어야 한다. 물론 조직에서 정말 보안에 신경쓰지 않는 한, 다양한 취약점을 모두 막기는 제한이 있을 것이다. 다만, 담당자로서 모든 시나리오를 확인하고, 취약점에 대한 대비는 해놓아야 한다. 여기서 항상 신경써야 하는 것은 취약점 체이닝이다. 실제로 공격자들이 애용하는 방식이기 때문이다. 공격자는 하나의 취약점만 노리지는 않는다. 취약점이 여러 개 있으면 그걸 가능한 많이 이용해 먹는 게 당연히 공격자 입장에서는 좋지 않겠는가. 그래서 취약점을 열거해 놓고, 가장 강력한 것에 대해서만 시나리오를 구성하여 대책을 세울 것이 아니라, 취약점 체이닝을 통한 조합도 고려해야 할 것이다.

 

그런데 담당자 혼자, 소수로서는 한계가 있기 마련이다. 그때 도움을 받는 게 바로 자동화 도구다. 도구를 이용하고 활용하는 것은 조직의 취약점 및 위험에 대해 이해하기 위해 필수일 것이다. 

 

SQL 인젝션 취약점을 확인하기 위해 가장 많이 사용되고 내게도 익숙한 것이 바로 SQL MAP이다. 자동화 SQL 인젝션 및 데이터베이스 탈취 도구로, MySQL, 오라클, MSSQL, Postgre SQL 등 다양한 데이터베이스를 지원한다. 탐지, 인젝션, 탈취까지 자동화를 지원하고, 옵션 설정에 따라 파일 시스템, 운영체제 엑세스까지 가능하다. 

 

위의 옵션은 SQL 옵션 중에서도 취약점을 찾는 데에 있어 특히 도움이 되는 옵션이 이를 고려하면 좋을 것이다.

 

다음으로 JWT 크랙 도구가 있는데, JWT는 두 개체 사이에서 정보를 안전하게 전달하는 방법 중 하나다. JSON 구조의 콘텐츠를 Base64URLSafe로 인코딩한 다음, 비밀키 또는 공개/개인키 쌍을 사용하여 서명한다. 기본적으로 HS256 알고리즘을 많이 사용하긴 하지만, 다른 알고리즘도 사용 가능하긴 하다. HS 256은 대칭키를 SHA 256으로 해시한 HMAC으로 원문을 서명했다는 의미다. 때문에 원문을 조작하려면 크랙이 필요하다. JWT 크랙 도구에는 jwtrack, jwt_tool 등이 있다.

 

다음로 해시캣 도구가 있다. 여러가지 해싱 알고리즘으로 해싱된 문자열의 원문을 찾기위해 사용되는 크래킹 도구다. 효율적인 크래킹을 위해 다양한 공격 방식을 갖고 있는데, 사전 공격(사전에 존재하는 비밀번호), 콤비네이터 공격(두 단어를 합친 비밀번호), 마스크 공격(이전에 누출된 비밀번호 패턴을 이용한 생성 규칙으로 만든 비밀번호), 규칙 기반 공격(단어를 수정, 잘라내기, 확장한 비밀번호) 등이 있다.