[이미지 = iclickart]

인코그니토 모드는 ‘프라이빗 브라우징(private browsing)’이라고도 알려져 있는 기술로, 사용자들이 원치 않는 쿠키가 저장되는 일이나 온라인 추적이 이뤄지는 것을 걱정하지 않고 인터넷 서핑을 할 수 있도록 해준다. 

크롬 76 이전 버전에서는 인코그니토 모드에서 파일시스템 API(FileSystem API)가 꺼져있는 것이 디폴트였다. 그러므로 웹사이트들은 파일시스템 API를 추적해 사용자가 인코그니토 모드를 사용하고 있는 건지 아닌지 파악할 수 있었다. 그래서 구글은 크롬 사용자들이 인코그니토 모드를 켜더라도 파일시스템 API가 활성화되도록 만들었다.

그러나 이것만으로는 웹사이트가 사용자의 인코그니토 모드 사용 여부를 파악하는 걸 근절시킬 수가 없었다. 개발자인 제스 리(Jesse Li)는 인코그니토 모드에서 파일시스템 API가 활성화되도록 했어도, 크롬이 해당 API와 관련된 데이터를 디스크가 아니라 메모리에 저장한다는 사실을 발견했다.

“우리가 ‘메모리’를 사용한다는 것에는 일장일단이 있습니다. 일단 메모리는 임시 저장소이기 때문에 데이터가 금방 사라집니다. 따라서 프라이버시를 보호한다는 측면에서는 좋은 점입니다. 그러나 공간이 작아서 많은 데이터를 저장할 수는 없죠. 속도는 디스크보다 훨씬 빠릅니다.” 즉, 파일시스템 API로 데이터가 작성되는 속도만 측정해도 사용자가 인코그니토 모드를 사용하고 있는지 아닌지 파악할 수 있다는 것이다. 

“그렇다는 건 웹사이트 운영자가 반복적으로 대형 문자열을 파일시스템에 반복적으로 기록하고, 걸리는 시간을 측정하는 일종의 벤치마킹을 하면 인코그니토 모드 사용 여부를 판단할 수 있게 된다는 겁니다. 생각보다 간단한 일이죠.” 제스 리는 이런 식의 벤치마크를 약 100번 정도 반복했다. 그 결과 디스크에 작성되는 것과 메모리에 작성되는 것 사이에 약 3~4배의 시간차가 있음을 알게 됐다. 그는 개념증명 코드를 깃허브에 올려두었다(https://github.com/veggiedefender/chrome-filesystem-timing).

그러나 이런 식의 공격에는 한 가지 제한 사항이 있다. 공격을 받는 장비의 하드웨어 설정과 성능에 따라 효율이 달라진다는 것이다. 심지어 배경에 다른 프로세스가 진행되고 있을 때도 효율이 급격히 떨어진다. 특정 상황에서는 긍정 오류가 발생하기도 한다(즉, 결과가 부정확할 수 있다는 뜻). 

그럼에도 문제는 심각해질 수 있다. 특히 “이런 류의 취약점은 소프트웨어 패치로 해결하기가 무척 어렵다”는 것이 큰 문제다. “구글이 인코그니토 모드나 일반 모드의 저장소를 전부 같은 곳으로 설정해두면 해결이 되긴 하는데, 이게 회사 입장에서는 쉽지 않은 결정일 수 있습니다.”

크롬 개발자들은 이미 작년부터 이러한 공격 시나리오가 가능하다는 경고를 해왔었다. 그러면서 “메타데이터만을 메모리에 보관하고, 나머지 파일은 암호화 해서 디스크에 보관하는 방법”을 권장했다. “이렇게 하면 메모리 저장과 디스크 저장의 차이점을 파악하기 위해 시간을 재는 공격 방법을 사용하기가 어려워집니다.” 당시 개발자들이 발표했던 내용이다.

그러나 제스 리는 그러한 방법 역시 불완전하다고 말한다. “왜냐하면 사이트 운영자가 메타데이터가 메모리에 저장되는 것을 파악하기만 하면 인코그니토 모드 사용 여부를 판단할 수 있게 되거든요.”
 

3줄 요약

1. 사용자를 늘 추적하고 싶은 웹사이트 운영자들. 크롬의 인코그니토 모드도 계속해서 파악 중.

2. 파일시스템 API의 데이터 작성 속도가 빠르면? 인코그니토 모드.

3. 인코그니토 모드와 정상 모드에서의 데이터 저장소가 동일할 경우 문제 해결 가능. 구글이 할지는 모르겠음.​

[국제부 문가용 기자(globoan@boannews.com)] 

[출처 : 보안뉴스(www.boannews.com),https://www.boannews.com/media/view.asp?idx=82066&page=1&mkind=1&kind=1]