인증 없이 읽히는 서버 파일, Gitea Org-Mode 렌더링 결함 점검 순서

이미지 출처: The Hacker News

사내에 Gitea를 올려 둔 팀이라면 대부분 이런 그림일 것이다. 사설망 한켠에 컨테이너 하나 띄워 두고, 사번으로 계정 만들고, 공개 저장소 몇 개는 사외에서도 보라고 리버스 프록시에 물려 둔다. 그 공개 저장소의 문서 한 장을 브라우저가 렌더링하는 순간, 서버 안쪽 설정 파일이 화면에 같이 그려질 수 있다는 게 이번 Gitea 이슈의 요지다. 로그인 없이, 계정 없이.

핵심 요약

• Gitea의 Org-Mode 마크업 렌더링 경로에서 인증되지 않은 사용자가 서버 로컬 파일을 읽어낼 수 있는 결함이 공개됐고, 심각도는 critical로 분류됨
• 핵심은 "문서 안에 다른 파일을 끌어오는" 마크업 기능이 저장소 경계 밖까지 해석된다는 점 — 웹셸도 익스플로잇 체인도 필요 없음
• 패치 적용이 1순위, 그다음이 Org 파일 렌더링 흔적 조회와 app.ini에 들어 있던 비밀값 전면 회수임

무엇이 문제였나

• Gitea는 저장소 안의 문서를 웹에서 바로 보여주기 위해 Markdown, AsciiDoc, Org-Mode 등 여러 마크업을 서버 측에서 HTML로 변환함
• 이번 결함은 그중 Org-Mode 처리 경로에 있음. Org-Mode에는 "다른 파일의 내용을 이 문서 위치에 끼워 넣어라"는 성격의 포함(include) 문법이 있는데, 이 경로가 저장소 디렉터리 안으로 제한되지 않았음
• 결과적으로 공격자는 악성 코드가 아니라 문서 한 장만 준비하면 됨. 서버가 그 문서를 렌더링하는 순간 지정된 로컬 파일을 읽어 응답에 담아 줌
• 가장 뼈아픈 건 인증 요구가 없다는 점임. 공개 저장소 열람이 열려 있거나, 익명 사용자가 볼 수 있는 미리보기 기능이 있으면 그 자체가 트리거가 됨

왜 이런 결함이 반복되는지

포함 문법을 가진 문서 포맷은 전부 같은 함정을 안고 있다고 봐도 무방함. XML의 외부 엔티티, LaTeX의 input, 템플릿 엔진의 partial, 그리고 Org-Mode의 include까지 발상이 동일함. "신뢰할 수 있는 문서"를 전제로 설계된 기능을, 아무나 올릴 수 있는 파일에 그대로 적용한 것이 근본 원인임. 문서 렌더러는 본래 개인 편집기 안에서 자기 파일을 다루라고 만든 물건인데, 이걸 멀티테넌트 웹 서비스로 옮기면 "내 파일"의 범위가 곧 서버 전체가 되어 버린다.

공격 재현은 개념만 알면 충분하다. 저장소에 Org 확장자 문서를 하나 넣고, 그 안에서 서버 파일시스템의 상대 경로를 위로 거슬러 올라가게 만든 뒤 웹 UI에서 그 문서를 열어 보는 것. 실제 페이로드를 굳이 적어 둘 이유는 없고, 방어자 입장에서 필요한 건 "요청 하나로 끝난다"는 감각뿐임.

무엇이 새어 나가면 치명적인가

• conf/app.ini — Gitea의 심장. SECRET_KEY, INTERNAL_TOKEN, LFS_JWT_SECRET, 메일 계정 비밀번호, DB 접속 문자열이 한데 들어 있음
• DB 자격증명 — 유출되면 사용자 테이블과 액세스 토큰 해시까지 열람 경로가 열림
• SSH 호스트 키와 authorized_keys — Git over SSH를 쓰는 조직이라면 중간자 공격과 신원 위조의 재료가 됨
• 컨테이너로 돌린다면 /proc/self/environ류의 경로 — 환경변수로 주입한 비밀값이 그대로 노출됨

탐지: 이미 당했는지 어떻게 보나

• 웹 서버·리버스 프록시 액세스 로그에서 .org 확장자 파일을 향한 raw/blob/미리보기 요청을 기간 역추적으로 뽑아 봄. 정상 조직이라면 Org 문서 렌더링은 빈도가 매우 낮아 신호 대 잡음비가 좋은 편임
• 같은 IP가 짧은 시간에 여러 저장소의 Org 문서를 반복 조회했거나, 신규 가입 직후 저장소를 만들고 문서 하나만 올린 뒤 조회한 패턴을 우선 확인함
• 응답 크기가 원본 문서 대비 비정상적으로 크거나, 200 응답인데 본문 길이가 들쭉날쭉한 요청을 눈여겨봄
• 저장소 생성 이벤트와 Org 파일 커밋 이벤트를 대조해, 사람이 쓴 문서가 아닌 것을 골라냄. 커밋 1건짜리 저장소는 특히 의심
• 가능하면 인스턴스 앞단에 임시로 Org 파일 요청만 별도 로깅하도록 규칙을 걸어 두고 며칠 관찰하는 것을 개인적으로 추천함

완화: 순서대로 하면 됨

• 첫째, 공식 패치가 적용된 최신 빌드로 올림. 마크업 파서 결함은 우회 필터로 막으려다 정규식만 늘어나는 경우가 잦아, 업그레이드가 가장 저렴한 해결책임
• 둘째, 당장 재기동이 어려우면 프록시 단에서 Org 확장자 문서의 렌더링 경로를 임시 차단하거나, 익명 열람을 잠시 닫아 노출면부터 줄임
• 셋째, 인스턴스가 인터넷에 직접 노출돼 있었다면 app.ini의 비밀값을 전부 새로 발급함. 패치만 하고 키를 그대로 두는 건 문을 고치고 열쇠는 밖에 둔 격임
• 넷째, 회수 범위에 사용자 액세스 토큰, OAuth 앱 시크릿, 웹훅 시크릿, 배포 키까지 포함함. CI가 Gitea 토큰을 물고 있다면 그쪽도 함께 교체
• 다섯째, 구조적으로는 Gitea 프로세스를 최소 권한 계정과 격리된 파일시스템에서 돌리도록 정리함. 설정 파일을 읽기 전용 시크릿 마운트로 분리해 두면 다음번 유사 결함의 피해 반경이 확연히 줄어듦

정리하며

이번 사건이 남기는 교훈은 의외로 단순하다. 사용자가 올린 파일을 서버가 해석하는 지점은 전부 공격면이라는 것. 이미지 썸네일 생성, 문서 미리보기, 마크다운 렌더링, 저장소 통계 — 우리가 편의를 위해 켜 둔 기능마다 파서가 하나씩 붙어 있고, 그 파서들은 대개 "착한 입력"을 가정하고 만들어졌다. 자체 호스팅 도구를 쓴다는 건 그 가정을 우리가 대신 책임진다는 뜻이기도 하다.

오늘 저녁에 30분만 내서 우리 Gitea 버전 확인하고, Org 파일 요청 로그 한 번 훑고, app.ini 키 교체 계획만 세워 두면 충분하다고 본다. 사내 개발 인프라는 뚫리면 소스코드와 배포 파이프라인이 한꺼번에 넘어가는 자리라, 이런 점검은 미루지 않는 편이 마음이 편하다. 여러분 환경에서 유효했던 탐지 규칙이나 우회 완화 방법이 있다면 댓글로 공유해 주세요. 같이 정리해 두면 다음 결함이 왔을 때 훨씬 빠르게 대응할 수 있을 겁니다.