HTTPS상의 압축에 따른 취약점 공격: CRIME과 BREACH

제가 SSL/TLS는 잘 몰라서 틀린점이 있을 수 있습니다. 그리고 편의를 위해 개략적으로만 설명합니다.

CRIME의 기본 아이디어는 다음과 같습니다..

(편의를 위해 공격자: attacker, 악의적인 사이트: evil.com, 피해자: victim, 공격대상 사이트: target.com 의 용어를 사용)

  1. TLS상에 주고받는 데이터를 해독할 수는 없지만 주고받는 데이터의 크기는 알 수 있다고 가정.
  2. attacker가 사용자가 대상 사이트에 전송하는 데이터에 임의의 값을 삽입할 수 있다고 가정. 이 단계는 의외로 쉽게 할 수 있는데, 예를들어 evil.com 에서 [img src=’target.com/xyz.png’]와 같은 HTML을 페이지에 넣고 victim이 evil.com을 방문하게 하면 됩니다.
  3. attacker는 target.com에 전송되는 victim의 cookie를 알고 싶어하는데, 이 cookie값이 abcde라고 하겠습니다.
  4. victim이 img src 태그를 보면 브라우저는 이미지 태그에 대한 요청을 target.com으로 보냅니다. 이 때, http request에는 xyz.png 라는 이미지 주소가 들어가겠죠. 그런데 이 주소와 #3에 설명한 cookie값은 한덩어리로 묶어서 압축됩니다. 즉 xyz.png와 abcde의 두개 문자열이 들어있는 http request는 한덩어리의 텍스트로 취급되어 압축됩니다. 그런데 attacker가 파일명을 ayz.png로 바꾸면 무슨일이 생길까요.. ayz.png와 abcde에는 ‘a’가 반복됩니다. 따라서 ayz.png, abcde를 압축한 결과의 바이트수는 xyz.png, abcde를 압축한 바이트 수보다 작습니다.
  5. 따라서 attacker는 img src의 주소를 계속 바꾸면서 http request의 바이트 크기가 최소가되는 지점을 찾아 cookie를 알아냅니다.

CRIME의 아이디어는 TLS상의 compression이 enable되어있는 경우가 드물기때문에 효과적이진 않았습니다.

BREACH는 http request가 아닌 http response에 초점을 맞춥니다. 공격자가 준 입력이 http의 response에 나타난다면 공격자는 입력을 바꿔가면서 http response의 크기를 재서 response에 있는 문자열을 예측해낼 수 있습니다. 예를들어 CSRF Token 탈취를 생각해 볼 수 있겠죠. http상의 gzip 압축은 자주 사용됩니다. 따라서 response를 사용한 공격 가능성은 더 많은 사람들에게 영향을 줍니다.

Similar Posts:

Post a Comment

Your email is never published nor shared.