리서치 블로그를 엽니다

지금까지 우리가 찾은 것들은 대부분 벤더의 제보 티켓 안에서만 존재했습니다. 참조 번호 하나와 상태 배지 하나. 그 안에서 실제로 무슨 일이 있었는지는 우리만 알고 있었습니다. 이 블로그는 그 기록을 꺼내 두는 자리입니다.

무엇을 공개하는가

우리가 쓰고 싶은 건 결론이 아니라 과정입니다. 어떤 자리를 왜 의심했고, 처음 세운 가정이 어떻게 틀렸고, 무엇을 바꿨을 때 뚫렸는지. 취약점 하나에 도달하기까지 버린 시도가 보통 성공한 시도보다 훨씬 많고, 다음 사람에게 쓸모 있는 정보는 대개 그쪽에 있습니다.

그래서 글은 다음을 담습니다.

왜 그 자리를 봤는지 — 코드 감사든 트래픽 관찰이든, 표면을 좁힌 근거
재현 절차 — 패치된 버전과 취약한 버전에서 각각 어떻게 동작하는지
막힌 경로 — 통할 것 같았는데 통하지 않은 시도와 그 이유
변형 분석 — 같은 패턴이 다른 자리에도 있는지

공개 원칙

패치 전에는 쓰지 않습니다. 벤더가 수정을 배포하고 공개에 동의한 뒤에만 글이 올라갑니다. 접수만 된 제보는 참조 번호도 적지 않습니다.
PoC는 재현 가능한 범위까지만. 결함이 존재한다는 걸 보이는 데 필요한 만큼만 싣습니다. 그대로 돌리면 남의 계정을 털 수 있는 완성된 도구는 올리지 않습니다.
남의 데이터는 싣지 않습니다. 실제 토큰, 실제 사용자 식별자, 테스트 중에 본 타인의 데이터는 전부 지우거나 대체합니다.

세 번째가 제일 자주 문제가 됩니다. 라이트업에 붙일 스크린샷 한 장에 남의 이메일 주소가 같이 찍혀 있는 경우가 흔합니다. 그래서 공개 전 검토를 따로 두고 있습니다.

앞으로 다룰 것

웹 애플리케이션의 인증·인가 경계, 모바일 클라이언트와 백엔드 사이의 API 계약, 데스크톱 애플리케이션의 IPC와 권한 경계, Windows / Linux 커널, 그리고 오픈소스 코드 감사. 홈의 표면 목록과 같습니다. 여기에 리서치 방법론 글이 섞입니다 — 특히 LLM을 파이프라인에 끼운 뒤 무엇이 실제로 좋아졌고 무엇은 그대로였는지.

큐에는 아직 벤더 패치를 기다리는 건들이 남아 있습니다. 순서는 우리가 정하지 않습니다. 벤더가 공개하는 순서대로 올라옵니다.