이 도메인이 dynadot에서 등록된 것을 whois로 확인할 수 있음
따라서 abuse@dynadot.com으로 신고하는 것이 가치 있을 것으로 보임
많은 오픈소스 프로젝트에서 이 도메인을 사용하고 있음을 언급하면서 코드 검색 결과도 다시 한번 공유함
GitHub 내부적으로 대량으로 자동 수정을 제안하고 배포할 수 있는 도구가 필요함
실제로 깃허브 코드 검색 결과가 상당한 규모임을 언급함
CI 작업에서 오타가 나면 큰 문제를 일으킬 수 있겠다는 우려를 표함
보안상 가치가 떨어지는 TLD(최상위 도메인)는 되도록 사용을 지양하자는 조언을 함
귀엽게 보이려는 시도보다는 보안이 우선임
악성 도메인 등록 해제가 .com만큼 신속하지 않을 수 있으므로, 미국 verisign이 관리하는 .com이 더 신뢰감 있다고 생각함
영국령 인도양 지역이나 콜롬비아, 앵귈라 등에 의존하는 건 부적절함
.io TLD는 미국 회사인 Afilias가 관리함을 덧붙임
여기서 진짜 위험성이 토큰 재사용 문제인지 질문함
Bearer 토큰은 패스워드를 직접 주지 않는데, RFC와 Mozilla 문서를 인용하면서 실제로는 인증 토큰 자체가 아니라 인증을 위해 다시 토큰을 받는 절차가 문제가 되는 건지 궁금함
도메인 간 OAuth가 토큰을 재사용하지 않는다면, 결국 가짜 도메인에서는 토큰을 받지 못하는 것 아닌지 의문임
블로그 저자이자 OCI 유지관리자로서 답변함
Bearer 토큰을 받기 위한 요청에서 비밀번호나 PAT를 기본 인증 헤더에 base64로 인코딩해서 보내지만, 사실상 평문으로 전송됨
요청을 받으면 www-authenticate 헤더가 발생하고, 인증 토큰을 받아 레지스트리 접근을 검증하며, 이후 토큰은 만료되지만
공격자가 실제 토큰을 탈취하는 게 아니라, Bearer 토큰을 받기 위한 자격 증명 자체를 요청하게 되는 구조임
Hacker News 의견
GitHub Container registry가 세분화된 토큰 대신 기존의 클래식 토큰만 지원하고 있어 심각함을 강조함
관련 문서와 이슈 링크도 첨부함
공식 문서
커뮤니티 토론
로드맵 이슈
이 문제 때문에 클래식 PAT을 완전히 끌 수 없는 상황임
추가적인 보완책으로는 세션 유효기간을 짧게 두고 엔터프라이즈 SSO로 재인증을 강제하는 방법이 있지만, 실제 필요한 단일 클래식 PAT에는 번거로운 선택임
누군가가 선의로 오타 도메인을 전부 사서 Microsoft에 넘기면 좋겠음
Microsoft가 레지스트리 이름을 바꿔야 한다고 생각함
이름이 너무 헷갈려서 나도 오타를 친 적이 많음
도메인 이슈를 여러 번 읽고 나서야 문제를 파악할 수 있었을 만큼, 꽤 설득력 있는 공격 벡터임
몇 번이나 시도하다 실패하고 심지어 컴퓨터를 다시 시작해도 동일 문제가 발생함
참고할 만한 사례로 stackoverflow 답변과 Docker 포럼 토론도 있음
ghrc.io 관련 코드 검색 결과를 링크로 제시함
기사에서 c와 r이 바뀐 것을 직접 지적해주기 전까지 문제를 알아차리지 못했음
이런 오타는 하루에 거의 10번도 넘게 내는 유형임
여기서 문제는 GitHub의 도메인명이 엉망이라는 것임
컨테이너 레지스트리 이름이 정말로 별로임
과거 Hacker News 토론 링크를 공유함
이 도메인이 dynadot에서 등록된 것을 whois로 확인할 수 있음
따라서 abuse@dynadot.com으로 신고하는 것이 가치 있을 것으로 보임
많은 오픈소스 프로젝트에서 이 도메인을 사용하고 있음을 언급하면서 코드 검색 결과도 다시 한번 공유함
GitHub 내부적으로 대량으로 자동 수정을 제안하고 배포할 수 있는 도구가 필요함
실제로 깃허브 코드 검색 결과가 상당한 규모임을 언급함
CI 작업에서 오타가 나면 큰 문제를 일으킬 수 있겠다는 우려를 표함
보안상 가치가 떨어지는 TLD(최상위 도메인)는 되도록 사용을 지양하자는 조언을 함
귀엽게 보이려는 시도보다는 보안이 우선임
악성 도메인 등록 해제가 .com만큼 신속하지 않을 수 있으므로, 미국 verisign이 관리하는 .com이 더 신뢰감 있다고 생각함
영국령 인도양 지역이나 콜롬비아, 앵귈라 등에 의존하는 건 부적절함
여기서 진짜 위험성이 토큰 재사용 문제인지 질문함
Bearer 토큰은 패스워드를 직접 주지 않는데, RFC와 Mozilla 문서를 인용하면서 실제로는 인증 토큰 자체가 아니라 인증을 위해 다시 토큰을 받는 절차가 문제가 되는 건지 궁금함
도메인 간 OAuth가 토큰을 재사용하지 않는다면, 결국 가짜 도메인에서는 토큰을 받지 못하는 것 아닌지 의문임
Bearer 토큰을 받기 위한 요청에서 비밀번호나 PAT를 기본 인증 헤더에 base64로 인코딩해서 보내지만, 사실상 평문으로 전송됨
요청을 받으면 www-authenticate 헤더가 발생하고, 인증 토큰을 받아 레지스트리 접근을 검증하며, 이후 토큰은 만료되지만
공격자가 실제 토큰을 탈취하는 게 아니라, Bearer 토큰을 받기 위한 자격 증명 자체를 요청하게 되는 구조임