내부 인증 서비스가 설정하는 보안 핵심 헤더에,
최종 사용자가 git push -o로 넣는 임의 문자열도 함께 들어가게 만든 셈임
지나고 나서 말하긴 쉽다지만, 그래도 이건 너무 황당함
AI 보강 리버싱 방식이 지금 LLM 에이전트의 강점을 잘 보여줌
코드로 많이 학습된 모델이라 복잡한 시스템 내부를 이해하는 속도를 엄청 끌어올릴 수 있음
보안 연구는 보통 1) 복잡한 내부 동작을 파악하는 일과 2) 그 안에서 취약점을 찾는 일이 겹쳐 있는데,
종종 진짜 내부 메커니즘만 드러나면 취약점 자체는 의외로 쉽게 보이기도 함 CVE-2026-3854는 내부를 알아도 바로 obvious한 유형은 아니었지만,
더 전통적이거나 접근 쉬운 공격 표면에 노출됐으면 이 커맨드 인젝션은 금방 발견됐을 거라고 봄
원래는 AI가 C++ 리버스 엔지니어링이나 C++를 단순한 C로 대량 포팅하는 데 강점이 있다는 신호가 있었음
그런데 요즘은 그 흐름이 좀 흐트러졌거나, C++ 문법 복잡성으로 생기는 dev/vendor lock-in을 지키려는 쪽 때문에 일부러 방해받는 느낌도 듦
Wiz에서 일하는 사람 있나 싶을 정도로 결과물이 꽤 괜찮아 보임
제품도 극단적인 성장과 기능 비대화를 겪고도 아직 꽤 잘 버티고,
보안팀도 정말 흥미로운 걸 자주 찾아냄
Unit 8200 출신이 많음
너무 노이즈가 많아서, 우리는 critical만 보려고 osv-scanner와 trivy를 돌리는 커스텀 파이프라인만 씀
거기 있진 않지만 우리 회사에서 써보면 완전히 무해한 행동에도 자꾸 경고를 띄움
그런데 정작 CLI로 DC 조회하고 자격 증명 리셋하는 식의 좀 수상한 작업엔 조용해서 허탈함
babeld가 push 요청을 전달할 때 내부 요청의 X-Stat 헤더에 push options를 넣고,
그 값은 사용자가 git push -o로 넣는 임의 문자열임
그런데 세미콜론을 sanitize하지 않은 채 값을 그대로 복사해서, ;가 X-Stat 필드 구분자이기 때문에 원래 필드를 탈출해 공격자가 새 필드를 만들 수 있게 됨
정말 가장 단순한 실수를 그대로 해버린 수준이라, 과일이 너무 낮게 달려서 땅속에 묻힌 수준처럼 보임
GHES는 사실상 수년째 거의 방치 상태나 다름없음
패치 레벨 릴리스 하나 적용하는 데도 몇 시간 다운타임이 필요하고,
지원되는 HA 업그레이드 방식도 없어서 성실한 고객조차 최신 버전을 바로 따라가기 어려움
불만을 제기하면 다들 GitHub Enterprise Cloud로 옮기라고 하지만,
요즘 같은 때에 그걸 선뜻 택할 사람이 얼마나 될지도 의문임
그래도 GHES는 github.com의 일일 장애 중엔 멈추지 않는다는 점은 있음
온프렘 고객 상당수는 VPN 뒤에 GHES를 두고 있고,
운영 영향이 적은 날짜를 잡아서 업그레이드하려는 듯함
다만 퍼블릭 인스턴스라면 즉시 업데이트해야 함
기사에 나온 정보와 공개된 GitHub Enterprise 소스만으로도 재현법을 짜내는 건 어렵지 않아 보임
엔터프라이즈에선 정기 일정 밖에서 업데이트했다가 다 터뜨리고 책임질 수도 있고,
그냥 일정대로 가면서 별일 없길 바랄 수도 있는데 대개 후자가 선택됨
보안을 매우 진지하게 본다는 이유로 github.com을 못 쓰는 환경에선,
온프렘 제품이 1년에 한 번 업데이트돼도 이상하지 않음
큰 설치 환경에선 업그레이드 과정이 얼마나 취약한지가 핵심임
데이터 규모가 큰 엔터프라이즈 소프트웨어는 사소한 것 하나로 설치가 깨지고 운영팀이 롤백하는 일이 흔했음
예전 SharePoint 업그레이드는 거의 주사위 굴리는 느낌이었음
이번 건도 Wiz의 대형 성과이고,
AI 도구가 RE와 침해 경로 발견을 얼마나 밀어주는지 보여주는 분기점처럼 느껴짐
그래서 소스를 공개하지 말아야 AI가 덜 뚫는다는 주장에도 금이 감
보안은 결국 security through obscurity에 기대면 안 된다는 데이터 포인트가 하나 더 쌓인 셈임
다들 GitHub를 대체하자고 하지만, 그럼 뭘 쓰겠냐는 고민이 남음
GitHub 정도 되는 곳도 이제 와서 RCE가 나오는데 다른 대안이 더 낫다고 쉽게 장담하긴 어려움
그나마 현실적인 답은 self-hosted Forgejo를 원본 포지로 두고,
GitHub는 무료 CI를 쓰는 동안만 미러로 활용하는 방식 같음
시크릿은 별도 secret-hosting provider에 맡기면 됨
우리는 6개월 전에 GitHub에서 Forgejo self-hosted로 옮겼는데 아주 잘 돌아감
Forgejo가 이렇게 반응 빠르고 GitHub가 이렇게 느려졌다는 게 아직도 믿기지 않음
내부용 프로젝트와 대외 공개용 프로젝트를 이제 확실히 분리함
내부용은 private Forgejo 인스턴스에 두고, 공개용은 GitHub에 올리되 Forgejo로 미러링함
Forgejo가 사실상 단일 바이너리에 설정도 쉬워서 놀랐고,
내부 서비스가 전부 Forgejo를 바라보게 해둬서 GitHub를 떠나야 해도 마찰이 적음
VPN 뒤 self-hosted GitLab도 충분히 괜찮음
올인원 Docker 이미지와 GitLab runner 몇 개면 소규모~중간 규모 팀엔 충분하고,
정말 필요하지 않으면 Kubernetes 버전까지 복잡하게 갈 이유는 없음
소스 코드에서 AI가 취약점을 찾는 것도 인상적이었는데,
바이너리 실행 파일에서까지 해내는 건 정말 놀라움
좋은 쪽으로도 나쁜 쪽으로도 잠재력이 아주 큼
그리고 또 한 번, 데이터를 명령으로 취급하면 안 된다는 교훈이 드러남
사용자 입력은 전부 sanitize해야 함
Transformer는 원래 번역을 위해 설계된 구조임
그래서 source-to-source나 text-to-source에 강한 건 익숙한 얘기였고,
asm 버전을 이해하는 데도 잘 맞는 건 아주 놀랍기만 한 일은 아닐 수 있음
그래도 인상적인 건 여전함
이게 실제로 악용됐는지 판별할 수 있을지 궁금함
내가 보기엔 이 취약점은 익명 사용자도 악용 가능해 보임
HTTP/git protocol 로그로 악용 여부 자체는 어느 정도 확인할 수 있겠지만,
실제로 무엇에 접근했고 누가 했는지까지는 남기지 못했을 가능성이 큼
익스플로잇이 git 서버에서 독립 실행될 수 있었다면, 정의상 로깅을 피해갈 수 있기 때문임
Hacker News 의견들
내부 인증 서비스가 설정하는 보안 핵심 헤더에,
최종 사용자가
git push -o로 넣는 임의 문자열도 함께 들어가게 만든 셈임지나고 나서 말하긴 쉽다지만, 그래도 이건 너무 황당함
AI 보강 리버싱 방식이 지금 LLM 에이전트의 강점을 잘 보여줌
코드로 많이 학습된 모델이라 복잡한 시스템 내부를 이해하는 속도를 엄청 끌어올릴 수 있음
보안 연구는 보통 1) 복잡한 내부 동작을 파악하는 일과 2) 그 안에서 취약점을 찾는 일이 겹쳐 있는데,
종종 진짜 내부 메커니즘만 드러나면 취약점 자체는 의외로 쉽게 보이기도 함
CVE-2026-3854는 내부를 알아도 바로 obvious한 유형은 아니었지만,
더 전통적이거나 접근 쉬운 공격 표면에 노출됐으면 이 커맨드 인젝션은 금방 발견됐을 거라고 봄
그런데 요즘은 그 흐름이 좀 흐트러졌거나, C++ 문법 복잡성으로 생기는 dev/vendor lock-in을 지키려는 쪽 때문에 일부러 방해받는 느낌도 듦
Wiz에서 일하는 사람 있나 싶을 정도로 결과물이 꽤 괜찮아 보임
제품도 극단적인 성장과 기능 비대화를 겪고도 아직 꽤 잘 버티고,
보안팀도 정말 흥미로운 걸 자주 찾아냄
osv-scanner와trivy를 돌리는 커스텀 파이프라인만 씀그런데 정작 CLI로 DC 조회하고 자격 증명 리셋하는 식의 좀 수상한 작업엔 조용해서 허탈함
babeld가 push 요청을 전달할 때 내부 요청의 X-Stat 헤더에 push options를 넣고,그 값은 사용자가
git push -o로 넣는 임의 문자열임그런데 세미콜론을 sanitize하지 않은 채 값을 그대로 복사해서,
;가 X-Stat 필드 구분자이기 때문에 원래 필드를 탈출해 공격자가 새 필드를 만들 수 있게 됨정말 가장 단순한 실수를 그대로 해버린 수준이라, 과일이 너무 낮게 달려서 땅속에 묻힌 수준처럼 보임
이미 악용되기 전에 잡아낸 취약점인데도
BREAKING, unauthorized access, millions of repositories 같은 표현으로 괜한 공포를 키울 필요가 있나 싶음
https://x.com/wiz_io/status/2049153209982140718
GitHub는 국가 지원 공격자가 아니라 Wiz의 퍼징에 걸린 쪽이라 운이 좋았던 셈임
88%의 GHES 인스턴스가 7주 전에 나온 치명적 보안 패치를 아직도 적용하지 않았다는 건 꽤 심각해 보임
https://docs.github.com/en/enterprise-server@3.19/admin/release-notes#3.19.3
패치 레벨 릴리스 하나 적용하는 데도 몇 시간 다운타임이 필요하고,
지원되는 HA 업그레이드 방식도 없어서 성실한 고객조차 최신 버전을 바로 따라가기 어려움
불만을 제기하면 다들 GitHub Enterprise Cloud로 옮기라고 하지만,
요즘 같은 때에 그걸 선뜻 택할 사람이 얼마나 될지도 의문임
그래도 GHES는 github.com의 일일 장애 중엔 멈추지 않는다는 점은 있음
운영 영향이 적은 날짜를 잡아서 업그레이드하려는 듯함
다만 퍼블릭 인스턴스라면 즉시 업데이트해야 함
기사에 나온 정보와 공개된 GitHub Enterprise 소스만으로도 재현법을 짜내는 건 어렵지 않아 보임
그냥 일정대로 가면서 별일 없길 바랄 수도 있는데 대개 후자가 선택됨
온프렘 제품이 1년에 한 번 업데이트돼도 이상하지 않음
데이터 규모가 큰 엔터프라이즈 소프트웨어는 사소한 것 하나로 설치가 깨지고 운영팀이 롤백하는 일이 흔했음
예전 SharePoint 업그레이드는 거의 주사위 굴리는 느낌이었음
이번 건도 Wiz의 대형 성과이고,
AI 도구가 RE와 침해 경로 발견을 얼마나 밀어주는지 보여주는 분기점처럼 느껴짐
보안은 결국 security through obscurity에 기대면 안 된다는 데이터 포인트가 하나 더 쌓인 셈임
다들 GitHub를 대체하자고 하지만, 그럼 뭘 쓰겠냐는 고민이 남음
GitHub 정도 되는 곳도 이제 와서 RCE가 나오는데 다른 대안이 더 낫다고 쉽게 장담하긴 어려움
https://news.ycombinator.com/item?id=46961345
https://news.ycombinator.com/item?id=47712656
GitHub는 무료 CI를 쓰는 동안만 미러로 활용하는 방식 같음
시크릿은 별도 secret-hosting provider에 맡기면 됨
Forgejo가 이렇게 반응 빠르고 GitHub가 이렇게 느려졌다는 게 아직도 믿기지 않음
내부용은 private Forgejo 인스턴스에 두고, 공개용은 GitHub에 올리되 Forgejo로 미러링함
Forgejo가 사실상 단일 바이너리에 설정도 쉬워서 놀랐고,
내부 서비스가 전부 Forgejo를 바라보게 해둬서 GitHub를 떠나야 해도 마찰이 적음
올인원 Docker 이미지와 GitLab runner 몇 개면 소규모~중간 규모 팀엔 충분하고,
정말 필요하지 않으면 Kubernetes 버전까지 복잡하게 갈 이유는 없음
소스 코드에서 AI가 취약점을 찾는 것도 인상적이었는데,
바이너리 실행 파일에서까지 해내는 건 정말 놀라움
좋은 쪽으로도 나쁜 쪽으로도 잠재력이 아주 큼
그리고 또 한 번, 데이터를 명령으로 취급하면 안 된다는 교훈이 드러남
사용자 입력은 전부 sanitize해야 함
그래서 source-to-source나 text-to-source에 강한 건 익숙한 얘기였고,
asm 버전을 이해하는 데도 잘 맞는 건 아주 놀랍기만 한 일은 아닐 수 있음
그래도 인상적인 건 여전함
이게 실제로 악용됐는지 판별할 수 있을지 궁금함
HTTP/git protocol 로그로 악용 여부 자체는 어느 정도 확인할 수 있겠지만,
실제로 무엇에 접근했고 누가 했는지까지는 남기지 못했을 가능성이 큼
익스플로잇이 git 서버에서 독립 실행될 수 있었다면, 정의상 로깅을 피해갈 수 있기 때문임