▲

GN⁺: Gitlab 비밀번호 재설정 버그로 5.3천 대 이상의 서버가 위험에 처해

 (scmagazine.com)
1P by neo 10달전 | favorite | 댓글 1개

GitLab CVE-2023-7028 취약점 미패치 서버

  • GitLab의 심각한 취약점 CVE-2023-7028이 화요일 기준으로 5,300개 이상의 서버에서 패치되지 않아, 소프트웨어 개발자의 계정 원격 탈취 가능성이 있음.
  • 이 버그는 최대 CVSS 점수 10점을 받았으며, GitLab이 1월 11일에 처음 공개하고 패치함.
  • GitLab 로그인 시스템의 취약점으로 인해 공격자가 피해자의 상호작용 없이 비인증 이메일 주소로 비밀번호 재설정 링크를 보낼 수 있음.

패치 정보 및 취약점 테스트 결과

  • GitLab 버전 16.5.6, 16.6.4, 16.7.2에 대한 보안 업데이트가 출시되었으며, 16.1.6, 16.2.9, 16.3.7, 16.4.5 버전에도 백포트됨.
  • 한 연구원이 GitLab Community Edition 버전 16.6.1에서 버그를 테스트하고 "매우 효과적이고 쉽게 이용할 수 있다"고 AttackerKB에 결과를 공유함.

취약한 인스턴스 감지 및 감소 추세

  • 패치가 가능해진 후 거의 2주가 지난 시점에서 Shadowserver Foundation에 의해 전 세계적으로 5,379개의 취약한 GitLab 인스턴스가 감지됨.
  • 미국과 독일이 각각 964개, 730개로 가장 많은 취약 인스턴스를 보유함.
  • Shadowserver의 대시보드 도구는 1월 24일에 취약 인스턴스가 4,652개로 줄어든 것을 보여줌.
  • Shadowserver 대변인은 SC Media와의 확인에서 취약 인스턴스의 감소가 긍정적인 발전이지만, 이 감소가 추세인지 단순 변동인지 판단하기 위해서는 더 많은 시간이 필요하다고 언급함.

GitLab CVE-2023-7028 타협 지표

  • GitLab Community Edition 및 GitLab Enterprise Edition의 자체 관리 인스턴스를 가진 GitLab 고객은 로그를 검토하여 CVE-2023-7028의 악용 여부를 확인해야 함.
  • gitlab-rails/production_json.log에서 /users/password 경로로의 HTTP 요청을 확인하고, params.value.email이 여러 이메일 주소를 포함한 JSON 배열로 구성되어 있는지 확인해야 함.
  • gitlabs-rails/audit_json.log에서 meta.caller.id가 PasswordsController#create이고 target_Details가 여러 이메일 주소를 포함한 JSON 배열로 구성된 항목을 확인해야 함.
  • GitLab.com 또는 GitLab 전용 인스턴스에서는 이 버그의 악용이 감지되지 않았음.
  • GitLab은 또한 2단계 인증(2FA)을 활성화할 것을 권장하며, 이는 CVE-2023-7028을 통한 계정 탈취를 방지하지만, 패치되지 않은 인스턴스 사용자는 여전히 공격자가 취약점을 이용하여 비밀번호를 재설정함으로써 계정에서 잠길 위험이 있음.

GN⁺의 의견

  • 이 기사는 GitLab의 심각한 보안 취약점과 관련된 중요한 정보를 제공함. CVE-2023-7028은 소프트웨어 개발자의 계정 보안에 직접적인 위협이 될 수 있으며, 적절한 조치가 필요함.
  • 패치가 제공되었음에도 불구하고 전 세계적으로 많은 수의 서버가 여전히 취약한 상태에 놓여 있어, 보안 인식과 적시에 업데이트를 하는 것의 중요성을 강조함.
  • 2단계 인증(2FA)의 중요성을 부각시키며, 사용자들에게 추가적인 보안 수단을 활용할 것을 권장함으로써, 보안에 대한 인식을 높이는 계기를 마련함.
▲
neo 10달전  [-]
Hacker News 의견

  • "계정 기반 웹 앱에서 '이메일 주소와 계정 연결' 기능의 위험성에 대해 말하고 싶다. 이 기능은 펜테스터들이 즉시 조작하려고 하는 것 중 하나이며, 초기 2000년대부터 취약점이 발견되었다. GitLab에서도 이런 문제가 재현되었다. GitLab은 훌륭한 보안 팀을 갖고 있지만, 이러한 버그를 피하기 어려운 것으로 보인다. 이 이야기에 관심이 있는 일반 해커뉴스 독자라면, 자신의 비밀번호 재설정 기능, 특히 이메일 연결 로직을 확인해보길 바란다."

  • "Rails 코드베이스에서 이 취약점을 발견한 커밋 링크를 공유한다: GitLab 커밋 링크"

  • "이 버그로 인해 피해를 입었다. 사용자의 이메일을 알아야 공격이 가능하지만, GitLab 사용자 ID(1부터 증가하는 숫자)에 연결된 숨겨진 이메일 주소가 있다. ID 1이나 2는 관리자일 가능성이 높으므로 좋은 목표가 된다. 이메일 형식은 '1-user@mail.noreply.<gitlabhost>'와 같다. 자동화된 공격처럼 보였으며, 2FA가 우리를 구했다."

  • "이메일을 통한 비밀번호 재설정은 올바르게 구현되었을 때조차 보안 악몽이다. 대부분의 서비스에서는 이 기능을 비활성화할 수 없으며, 대안은 종종 엔터프라이즈 SSO뿐이다. 일부 서비스에서는 SMS 토큰을 위한 전화번호를 설정할 수 있지만, 이메일과 SMS 토큰을 모두 요구하는 옵션은 본 적이 없다."

  • "로그인 폼에 비밀번호 배열을 입력하여 계정을 무차별 대입 공격할 수 있는 버그를 발견한 적이 있다. 스팸 어플라이언스에 대한 조악한 웹 인터페이스였으며, 의도된 것인지, PHP 초보자가 코드를 작성한 것인지 확실하지 않다. 당시 특수 문자가 들어간 비밀번호를 사용하던 사용자가 이를 발견했다."

  • "GitLab과 같은 내부 서비스는 신뢰할 수 있는 사용자만 접근할 수 있는 VPN 뒤에서 운영하는 것이 좋다는 점을 상기시킨다."

  • "GitLab 업데이트 자동화는 매우 쉽다. Docker+Compose에서 GitLab을 사용하고 Watchtower 등을 통해 매일 업데이트하면 된다. 7년 이상 이 방법으로 GitLab 서버를 운영하고 있으며 문제가 없었다. 주변을 둘러보면 많은 GitLab이 구버전인데, 관리자들은 무엇을 하고 있는가?"

  • "어떤 종류의 내부 서버든 공개 인터넷에 노출시키지 않겠다는 원칙을 갖고 있다. VPN을 통해서만 접근 가능하게 하여 두 번째 방어선을 구축한다."

  • "항상 SSO를 사용하고 2FA를 사용하는 것을 잊지 말아야 한다는 또 다른 상기."

  • "Ruby/Rails가 안전해야 하는 소프트웨어에 적합한 선택이라는 생각을 그만두자. GitLab이 이를 다루어야 하는 상황을 이해하지만, 앞으로는 지능적이고 숨겨진 제어 흐름을 우선시하는 언어와 프레임워크보다 더 단순한 것이 낫다는 것을 인정해야 한다. 나는 생산 Ruby 코드베이스에서 일하고 있으며, 여러 층의 추상화가 코드를 매우 확장 가능하게 만들었다고 생각하는 누군가로 인해 비슷한 문제가 발생할 가능성이 분명히 보인다."

답변달기