▲

GN⁺: Go 인프라 악용

 (reverse.put.as)
2P by neo 3달전 | favorite | 댓글 1개

문제점

  • 어젯밤, Go의 체크섬 데이터베이스 내용을 탐색하던 중 흥미로운 결과를 발견함.
  • sqlite> select path, count(path) from modules group by path order by count(path) desc; 명령어를 실행한 결과:
    • github.com/homebrew/homebrew-core|39438
    • github.com/Homebrew/homebrew-core|30896
    • github.com/concourse/concourse|25372
    • github.com/openshift/release|24065
    • github.com/cilium/cilium|22138
  • Homebrew는 Ruby를 사용하기로 알려져 있어, Go와의 연결이 의문스러웠음.
  • GitHub 언어 통계도 이를 확인해줌.
  • Go와 관련된 파일(go.mod 또는 Go 소스 파일)을 찾기 위해 저장소를 복제했지만, 아무것도 발견되지 않음.

연구

  • 새로운 날이 시작되었고, 호기심이 답을 요구함.
  • Git 저장소가 Go 코드와 관련이 없다면, 어떻게 Go 체크섬 데이터베이스에 나타나는지 궁금했음.
  • proxy.golang.org가 기본 모듈 프록시이고, sum.golang.org가 체크섬 데이터베이스임을 알게 됨.
  • Go의 문서를 읽어보니, 모듈 버전이 아직 로그에 기록되지 않은 경우 체크섬 데이터베이스가 원본 서버에서 모듈을 가져오려 시도함을 알게 됨.
  • 새로운 Go 모듈 저장소가 체크섬 데이터베이스와 프록시에 추가되는지 확인하기 위해 lookup 엔드포인트를 호출해봄.
  • 새로운 Go 모듈을 만들고 GitHub 계정에 업로드한 후, lookup 명령을 두 가지 형태로 시도했으나 모두 오류가 발생함.
  • 올바른 의사 버전을 생성하고 체크섬 데이터베이스에 다시 쿼리하여 모듈이 다운로드되었는지 확인함.
  • 프록시를 쿼리하고 모듈 zip을 다운로드하여 임의의 데이터를 Go 인프라에 저장할 수 있음을 증명함.

남용 가능성

  • 개발자 머신과 CI/CD 서버에서 다운로드 제한을 우회하는 데 사용될 수 있음.
  • 악성 소프트웨어가 페이로드를 저장하고 필요할 때 프록시에서 이를 가져올 수 있음.
  • proxy.golang.org에 대한 서비스 거부(DoS) 공격이 가능할 수 있음.
  • 명령 및 제어(C2) 시스템을 쉽게 구현할 수 있음.

결론

  • 체크섬 데이터베이스 프로세스가 어떻게 작동하는지 이해하게 되었음.
  • 현재로서는 Go 인프라에서 심각한 문제는 아니지만, 남용될 가능성이 있음.
  • 비-Go 프로젝트가 데이터베이스에 있는 이유에 대한 추가적인 질문이 남아 있음.
  • 이 연구를 통해 많은 아이디어를 얻었으며, 더 탐구할 계획임.

GN⁺의 의견

  1. 보안 취약점: 이 기사는 Go의 체크섬 데이터베이스가 임의의 데이터를 저장할 수 있는 보안 취약점을 지적하고 있음. 이는 악성 코드가 쉽게 배포될 수 있는 경로를 제공할 수 있음.
  2. 개선 필요성: Go 인프라의 보안과 무결성을 강화하기 위해 체크섬 데이터베이스와 프록시 서버의 접근 제어를 개선할 필요가 있음.
  3. 다른 언어와의 통합: Go 체크섬 데이터베이스에 비-Go 프로젝트가 포함되는 이유를 명확히 하고, 이를 방지하기 위한 추가적인 검증 절차가 필요함.
  4. 개발자 교육: 개발자들이 이러한 보안 취약점을 인지하고, 이를 방지하기 위한 최선의 방법을 이해할 수 있도록 교육이 필요함.
  5. 대체 솔루션: 비슷한 기능을 제공하는 다른 언어의 체크섬 데이터베이스와 프록시 서버를 비교하고, Go의 인프라 개선에 참고할 수 있음.
▲
neo 3달전  [-]
Hacker News 의견

해커뉴스 댓글 모음 요약

  • 온라인 서비스의 악용 가능성

    • 모든 온라인 서비스는 결국 명령 및 제어, 저작권 침해, CSAM 호스팅에 악용될 가능성이 있음. 트위터, 텔레그램, PGP 키 인프라 등도 이미 이런 사례가 있음.

  • 구글의 파일 호스팅 문제

    • 구글은 악성 파일 호스팅 문제를 자주 다루기 때문에, Go 팀이 GCP와 드라이브와 협력했을 가능성이 있음. 이는 구글이 이미 허용하는 다른 엔드포인트와 크게 다르지 않음.

  • GitHub와의 비교

    • GitHub에 파일을 업로드하는 것과 큰 차이가 없다는 의견. GitHub도 계정만 있으면 임의의 데이터를 저장할 수 있음.

  • PyPI의 비파이썬 프로젝트

    • PyPI에는 비파이썬 프로젝트도 있으며, 사용자가 라이브러리 코드를 컴파일할 수 없을 때를 대비해 휠(컴파일된 바이너리)을 배포할 수 있는 기능이 필요함. C와 Golang으로 작성된 코드도 가능함.

  • Golang 프록시와 체크섬 로그

    • Golang 프록시와 sumdb를 이용해 임의의 URL 체크섬을 투명하게 기록하는 아이디어를 시도해본 경험이 있음.

  • 도메인 탐색

    • 특정 도메인을 탐색했을 때 예상했던 내용이 대부분 포함되어 있었음.

  • 알려진 문제

    • Golang의 알려진 문제에 대한 링크를 공유함.

  • CUE의 모듈 시스템

    • CUE의 모듈 시스템이 출시 중이며, Go의 MVS를 좋아하지만 OCI 인프라 기반으로 구축됨. 의존성 관리 시스템에 관심이 있다면 관련 링크를 참고할 수 있음.

  • 웹 캐시 문제

    • W3C가 웹의 모든 것을 캐시 가능하게 만들었지만, 일반 목적의 프록시 캐시가 거의 없는 이유가 궁금함. 발행자가 불필요하게 짧은 "Cache-Control: max-age" 또는 "Vary: Cookie" 응답을 보내는지, 너무 많은 ISP가 트랜짓 비용을 지불하는지 의문임.

  • 프록시 캐시 문제

    • 프록시가 비-Go 저장소를 캐시하는 것이 낭비일 수 있지만, Go 저장소를 캐시하게 만들면 임의의 데이터를 저장할 수 있음. 큰 문제가 아니라고 생각함.
답변달기