Side Channel Attack on WWW

서문

약 2개월 전 크롬 80버전이 릴리즈 되었습니다.
여러 변경이 있었지만 가장 중요한 패치는 역시 쿠키의 Samesite 옵션의 기본값이 Lax로 변경된 것이었죠.
그런데 80버전이 릴리즈되기 전까지, 다시 말해 Samesite=Lax가 되기 전까지 셀 수 없을 정도로 많은, 우리가 아는 대부분의 웹사이트에 특정 종류의 취약점이 존재했습니다.
과연 어떤 취약점이 존재했는지 알아보고, 그렇다면 Samesite=Lax 가 이 취약점으로부터 안전해지는 완벽한 대안인지 고민해봅시다.

https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html
COVID-19때문에 해당 조치가 rollback 되었습니다.
이것은 현재 리얼월드에 존재하는 위협이며, 웹사이트에서 별도로 Samesite=Lax 옵션을 주지 않았을 경우에 이 취약점이 존재할 확률이 극도로 높습니다.

본문

회원가입을 받거나, OAuth를 사용해서 사용자에게 권한을 부여하는 웹사이트가 많습니다.
그리고 각 사용자는 서로 다른 권한을 가지고 있으며, 이 권한의 종류는 아주 다양합니다.
예를 들어 A 사용자의 회원정보 수정 페이지에 접근할 수 있는 회원은 A 사용자밖에 없을 것 입니다.
B 그룹의 게시물을 열람할 수 있는 회원은 B 그룹의 구성원들뿐이겠죠.
성인 컨텐츠에 접근할 수 있는 회원은 미성년자가 아닌, 성인인증이 된 회원들일 것 입니다.

그런데 권한이 존재할 때와 존재하지 않을 때 서로 응답(Response)이 다르다면 어떨까요?
응답이 다르다 는 광대한 표현입니다.
응답 시간이 다를 수도 있고, 응답의 상태 코드가 다를 수도 있으며, 응답의 길이가 다를 수도 있습니다.

여기 취약한 웹사이트 victim.com이 있고 그 사이트의 회원인 A와 B가 있습니다.
A의 회원정보 수정 페이지가 victim.com/member/modify/42 라고 가정합시다.
A는 해당 페이지에 접근할 권한이 있습니다.
B는 그렇지 않죠.
우리는 이런 경우에 제대로 접근 통제가 되고 있다고 표현합니다.
하지만 두 회원이 공격자의 웹사이트 attacker.com에 접속했을 때 상황이 달라집니다.

attacker.com에 접속하면 client는 미리 작성된 스크립트에 의해서 img 태그를 통해 victim.com/member/modify/42 주소에 접근하게 됩니다.
해당 페이지가 정상적으로 load되면 onload 이벤트 핸들러를, load에 실패하면 onerror 이벤트 핸들러를 실행하게 됩니다.
A와 B가 해당 페이지에 접근했을 때 A는 onload 이벤트 핸들러를, B는 onerror 이벤트 핸들러를 실행하게 되겠군요.
각각에는 자신의 IP주소, 리퍼러, 유저에이전트, 접속 시간 등을 로거에 전달하는 코드가 선언되어 있습니다.

이제 공격자는 자신의 웹사이트에 접속한 익명의 사용자가 victim.com의 A사용자인지 여부를 식별할 수 있게 되었습니다.

별로 크리티컬하지 않다고 생각하나요?
그럼 다른 예시를 들어봅시다.

SNS를 비롯한 많은 웹서비스에서는 유료 광고 기능을 제공하고 있으며, 개중에는 특정 사용자군을 지목해서 광고를 할 수 있는 기능을 제공하기도 합니다.
20대, 남성, 서울거주, 관심사는 스포츠 등으로 타겟팅이 가능하죠.

공격자는 광고를 하나 냅니다.
20대가 볼 수 있는 광고를요.
30대, 40대가 볼 수 있는 광고도 하나씩 내면 좋겠네요.
마찬가지로 각각의 게시물에 접근했을 때 응답이 변했는지를 확인해봅니다.
이번에는 자신의 웹사이트에 접속한(즉 IP주소를 알 수 있는) 익명의 사용자의 나이를, 성별을, 사는 지역을, 관심사를 알아낼 수 있게 되었습니다.

한 개의 공격기법처럼 설명했지만, 사실 공격하는 방법이 무수히 많습니다.

먼저 시간 기반입니다.
가장 쉽게 떠올릴 수 있는 방법은 victim.com/member/modify/42 에 접근했을 때 응답에 걸리는 시간을 재는 방법입니다.
수정 페이지와 404 에러 페이지는 response의 길이가 다를 것이며, 당연히 응답 시간도 달라질 것 입니다.
하지만 그래봤자 수kb일 테고, 이건 좀 구려 보이죠.
조금 다르게 가봅시다.
공격자는 victim.com 에서 게시물을 작성합니다.
그 게시물을 읽을 수 있는 사람은 A사용자 한 명으로 설정합니다.
게시물의 내용은 아주아주 깁니다. 수mb단위로요.
이번에는 응답시간이 유의미하게 차이가 날 것입니다.

혹은 응답코드를 사용할 수도 있습니다.
위의 예시에서 다루었지만 img 태그의 경우에 응답코드가 404면 onerror 이벤트 핸들러가, 200이면 onload 이벤트 핸들러가 트리거됩니다.
권한이 없을 경우에 404 코드를 응답하는 서비스에서는 공격이 아주 쉬워지겠죠.

재미있는 공격방법을 한 가지 더 소개하면, anchor라는 기능이 있습니다.
#foo 에 접속했을 때 id가 foo인 객체에 focus가 되죠.
권한이 있을때만 load되는 객체가 존재할 경우에 iframe으로 해당 페이지를 불러올 때 해당 id의 anchor를 추가하면,
focus가 바뀌며 onblur 이벤트 핸들러가 트리거됩니다.
<iframe src=”victim.com/member/modify/42#username“></iframe> 같은 방식이죠.

그 외에도 많은 공격 방법이 존재하며, 웹 서비스의 구조에 따라서 맞춤형으로 새로운 공격 방법이 나올 수 있습니다.

Chrome 80

Samesite=Lax 로 기본값이 변경되며 이러한 방식의 공격은 대부분 막힌 것으로 보입니다.
하지만 크롬에서는 성능 저하를 이유로 패치되지 않은 known-issue가 존재하며, 이는 Samesite=Lax를 우회하는 열쇠가 될 수 있다고 보고 지속해서 연구를 진행 중입니다.

마무리

Privacy가 점점 중요한 화두가 되며 사용자의 아이디 패스워드 등 직접적인 개인정보를 넘어 여러 정보를 결합해서 사용자를 식별할 수 있는 경우 혹은 다른 사용자와 구별되어 특정인을 찾을 수 있는 경우 또한 개인정보로 취급되며, 보호의 대상이 됩니다.
기존의 공격방식들과 방향이 달라 생소하지만, privacy 관점에서 중요한 이슈가 될 수 있으니 많은 연구자들의 관심이 필요한 분야입니다.