내가 표적이 됐다: git post-checkout 훅으로 자격 증명 탈취를 노린 시도

낯선 사람이 준 다운로드 파일은 믿지 말라는 원칙은 여전히 유효함. 그래도 Git 훅에 악성 동작을 숨기는 수법은 꽤 교묘함. 저장소가 겉으로는 단순한 텍스트처럼 보여도 위험을 숨길 수 있다는 사실을 다시 일깨워 줌.
개발자 집단의 경각심이 따라잡기 전까지 Git 내부 기능을 악용하는 공격은 더 늘어날 것으로 봄. 이런 보안 점검에는 실행 권한을 주지 않은 LLM으로 모든 파일을 훑고 보고서를 받는 방법을 추천함. 프롬프트 인젝션에 취약하기 때문에 권한을 주지 않는 것이고, 조금이라도 수상한 것은 대체로 표시해 줌.

이런 Git 훅을 안전하게 통제할 수 있을까? 어디에 호스팅된 저장소든 post-checkout이 들어갈 수 있어 보임.

복제 후 Git이 체크아웃을 한다면, 검토할 틈도 없이 훅이 실행될 수 있어 더 위험하겠다고 생각함. 그런데 직접 시험해 보니 Git은 해당 파일의 체크아웃을 거부함. git clone bad-repo.got 실행 시 error: invalid path '.git/hooks/post-checkout' 오류가 나며, 복제는 성공하지만 작업 트리 체크아웃은 실패함.
따라서 항상 git으로 저장소를 복제하고, 글쓴이처럼 다른 사람이 건넨 작업 트리를 그대로 받지만 않으면 안전할 것으로 추정함. 다만 저장소 형식 자체는 훅 커밋을 막지 않으므로, 이를 차단하는 책임은 프런트엔드에 있음. got도 시험해 보니 체크아웃을 거부했지만, jj나 다른 Git 프런트엔드는 모르겠음.

최근 면접에서 집에서 하는 코딩 과제를 받았는데, 이메일로 보낸 묶음 파일에 .git까지 넣는 건 부적절해 보여 삭제했다고 전달함. 상대도 동의하면서, 가끔은 커밋 내역도 보고 싶다고 답함. 이것이 심각한 보안 위험일 수 있다는 생각은 전혀 못 했음!

git bundle create로 만든 실제 Git 번들이라면 복제해도 안전할 것임. 복제 과정에서 그런 파일은 체크아웃되지 않기 때문임. 반면 일반 ZIP이나 tar 압축 파일은 이런 공격이 가능함.

면접 코딩 과제는 GitHub 내장 VS Code 환경이나 가상 머신에서만 하기로 함. 참고로 GitHub 저장소에서 .을 누르면 내장 편집기를 열 수 있음. 악성 외부 패키지, Git 훅, VS Code 설정 파일 등 공격 경로가 많아서, 남이 보내는 프로젝트는 전부 악성이라고 간주함.

이것은 하나의 만능 도구와 그에 기반한 단일 생태계를 택한 대가임. 초기 Unix의 관심사 분리는 여전히 건전한 공학 원칙이고, 경쟁도 도움이 됨. 사용자를 빼앗는 경쟁자가 없다면 Git은 호환성 유지를 위해 이런 사안을 건드리지 않을 것임.
Mercurial이나 Fossil 등을 외면한 주체는 개발자가 아니라 GitHub와 GitLab 같은 플랫폼이었을 수도 있음. 어쩌면 JJ가 이 상황에서 벗어날 길을 보여 줄 수 있음.

Markdown 파일이 든 여러 폴더를 Dropbox로 공유했다는 대목부터 경계했어야 함. .git 디렉터리나 그 안의 훅보다 먼저 의심할 신호임.