GitLab 주요 보안 패치 릴리즈 17.3.3, 17.2.7, 17.1.8, 17.0.8, 16.11.10

Project Manager

2024년 9월 19일 · 약 13분

GitLab Community Edition(CE) 및 Enterprise Edition(EE)용 GitLab 중요 보안 패치 릴리즈: 17.3.3, 17.2.7, 17.1.8, 17.0.8, 16.11.10에 대해 자세히 알아보세요. 오늘 우리는 GitLab Community Edition(CE) 및 Enterprise Edition(EE)용 버전 17.3.3, 17.2.7, 17.1.8, 17.0.8, 16.11.10을 출시합니다.

이 버전에는 중요한 버그 및 보안 수정 사항이 포함되어 있으므로 모든 GitLab 설치를 즉시 이러한 버전 중 하나로 업그레이드하는 것이 좋습니다. GitLab.com은 이미 패치 버전을 실행하고 있습니다.

GitLab Dedicated의 경우 모든 인스턴스가 업그레이드되었으므로 Dedicated 고객은 별도의 조치를 취할 필요가 없습니다. 또한 버전 17.2.6은 GitLab Dedicated를 수정하는 데 사용되었으며 공개되지 않았습니다. 버전 17.2.7에는 동일한 변경 사항이 포함되어 있습니다

이번 패치 릴리즈에서 주요 수정사항은 다음과 같습니다.

SAML 인증 우회에 대한 패치(Critical)

GitLab 패치 릴리즈는 취약점에 대한 수정 사항을 릴리즈합니다. 패치 릴리즈에는 예정된 릴리즈와 심각도가 높은 취약점에 대한 임시 중요 패치라는 두 가지 유형이 있습니다. 예정 출시일은 한 달에 두 번 둘째, 넷째 수요일에 출시됩니다. 자세한 내용은 릴리즈 핸드북 및 보안 FAQ를 참조하세요 . 여기에서 모든 GitLab 릴리즈 블로그 게시물을 볼 수 있습니다. 보안 수정의 경우, 각 취약점을 자세히 설명하는 문제는 패치가 적용된 릴리즈로부터 30일 후에 문제 추적기에 공개됩니다 .

우리는 고객에게 노출되거나 호스트 고객 데이터가 가장 높은 보안 표준을 유지하는 GitLab의 모든 측면을 보장하기 위해 최선을 다하고 있습니다. 우수한 보안 수준을 유지하는 일환으로 모든 고객은 지원되는 버전의 최신 패치 릴리즈로 업그레이드하는 것이 좋습니다. 블로그 게시물에서 GitLab 인스턴스 보안에 대한 더 많은 모범 사례를 읽을 수 있습니다 .

권장 조치

아래 버전에 해당된다면 가능한 한 빨리 최신 버전으로 업그레이드하는 것이 좋습니다 .

제품의 특정 배포 유형(옴니버스, 소스 코드, 헬름 차트 등)이 언급되지 않으면 모든 유형이 영향을 받는다는 의미입니다.

보안 조치 사항

SAML 인증 우회

CVE-2024-45409를 omniauth-saml 완화하기 위해 버전 2.2.1 및 ruby-saml1.17.0에 대한 종속성을 업데이트합니다 . 이 보안 취약성은 SAML 기반 인증을 구성한 인스턴스에만 적용됩니다.

자체 관리 GitLab: 알려진 완화책

자체 관리형 GitLab 설치에 대한 다음 완화책은 CVE-2024-45409 의 성공적인 악용을 방지합니다 .

GitLab 자체 관리 인스턴스의 모든 사용자 계정에 대해 GitLab 2단계 인증을 활성화합니다(참고: ID 공급자 다중 요소 인증을 활성화해도 이 취약성은 완화되지 않음
GitLab에서 SAML 2단계 우회옵션을 허용하지 마세요.

자체 관리 GitLab: 악용 시도 식별 및 감지

Ruby-SAML (CVE-2024-45409)의 시도 또는 성공적인 악용 증거는 GitLab의 application_json 및 auth_json 로그 파일에서 확인할 수 있습니다.

*실패한 익스플로잇 시도

실패한 익스플로잇 시도는 라이브러리 ValidationError에서 를 생성할 수 있습니다 RubySaml. 이는 작동하는 익스플로잇을 만드는 복잡성과 관련된 다양한 이유일 수 있습니다.

아래에 두 가지 예가 나와 있지만, 오류는 다른 설명으로 나타날 수 있습니다. 검색할 일반적인 문자열은 RubySaml::ValidationErrorapplication_json 로그 내부에 있습니다.

잘못된 콜백 URL로 인해 티켓이 유효하지 않습니다.
1. 로그 이벤트 예시:
2. {"severity":"ERROR","time":"2024-xx-xx","correlation_id":"xx","message":"(saml) Authentication failure! invalid_ticket: OneLogin::RubySaml::ValidationError, The response was received at https://domain.com/users/auth/saml/incorrect_callback instead of https://domain.com/users/auth/saml/callback"}
인증서 서명 문제로 인해 유효하지 않은 티켓입니다.
1. 로그 이벤트 예시:
2. "message":"(saml) Authentication failure! invalid_ticket: OneLogin::RubySaml::ValidationError, Fingerprint mismatch"

*성공적인 탈취 시

성공적인 악용 시도는 SAML 관련 로그 이벤트를 트리거합니다. 그러나 악용 시도를 합법적인 SAML 인증 이벤트와 차별화하는 차이점이 있을 수 있습니다.

성공적인 익스플로잇 시도는 익스플로잇을 시도하는 공격자가 설정한 모든 extern_id 값을 기록합니다. 따라서 조직에서 흔하지 않은 고유한 extern_uid를 식별하는 것은 잠재적 익스플로잇의 지표가 될 수 있습니다.

Log event:
{"severity":"INFO","time":"2024-xx-xx","correlation_id":"xx","meta.caller_id":"OmniauthCallbacksController#saml","meta.remote_ip":"0.0.0.0","meta.feature_category":"system_access","meta.client_id":"ip/0.0.0.0","message":"(SAML) saving user exploit-test-user@domain.com from login with admin =\\u003e false, extern_uid =\\u003e exploit-test-user"}

익스플로잇을 만들 때, 공격자가 정상적인 로그인을 완벽하게 복제하기 위해서는 많은 SAML 어서션을 만들어야 합니다. 이러한 어서션에는 IdP(Identity Provider)에서 지정한 키와 값 필드가 모두 포함되며, 특히 이러한 속성들을 사용자 정의한 경우에는 권한이 없는 개인들에게 알려지지 않을 수 있습니다.

SAML 응답의 속성 섹션에서 잘못되었거나 누락된 정보를 찾기 위해 auth_json 로그 파일을 검토할 수 있습니다.

auth_json 로그 파일의 SAML 인증 이벤트 예
"severity":"INFO","time":"2024-xx-xx","correlation_id":"xx","meta.caller_id":"OmniauthCallbacksController#saml","meta.remote_ip":"0.0.0.0","meta.feature_category":"system_access","meta.client_id":"ip/0.0.0.0","payload_type":"saml_response": {"issuer": ["xxx"],"name_id": "xxx","name_id_format": "xxx","name_id_spnamequalifier": null,"name_id_namequalifier": null,"destination": "xxx","audiences": ["xxx"],"attributes": {"first_name": ["xxx"],"last_name": ["yyy"], "email": ["zzz"]}}

악용시도 감지

GitLab의 자체 관리 고객이 application_json 로그를 SIEM으로 전달하는 경우, Ruby-SAML (CVE-2024-45409) 취약점 악용 시도를 탐지하기 위한 탐지 규칙을 만들 수 있습니다. GitLab 팀에서 잠재적인 악용을 탐지하기 위한 두 가지 위협 탐지 규칙을 Sigma 형식으로 공유하고 있습니다

주의: 이러한 탐지 기능들은 효과적인 결과를 제공하기 위해 고객 환경에 맞게 조정되고 수정될 필요가 있을 수 있습니다. 또한 각 고객 환경의 구성이 다양하기 때문에, 고객들은 이러한 탐지 기능들에 의해 식별된 모든 이벤트의 정당성과 정확성을 검증해야 합니다.

이 탐지는 하나 이상의 extern_uid 값이 인증 이벤트에 연결된 인증된 SAML 사용자를 식별하도록 설계되었습니다. 이는 공격자가 설정한 extern_uid 필드를 사용한 악의적인 인증의 잠재적 징후일 수 있습니다.

title: Multiple extern_ids
description: Detects when their are multiple extern_id's associated with a user.
author: Gitlab Security Engineering
date: 09/15/2024
schedule: "*/10 * * * *"
pseudocode: |
  select log source application.log
  where 7d < event_time < now()
  where severity="INFO" and meta_caller_id="Groups::OmniauthCallbacksController#group_saml"
  regex(message, "saving user (?<user_email>\S+) .*extern_uid \S+ (?<extern_id>[\S]+)")
  count extern_id by user_email as total_extern_ids
  where total_extern_ids > 1
verify: Review Gitlab application logs for the source IP of the SAML authentications. If there is a singular IP for all extern_ids this could point to a false positive. Cross reference the SAML authentication source IP/s with the known user's IP from sso authentication logs.
tuning: N/A

시간 경과에 따른 동일한 사용자에 대한 다른 iDP 이벤트와 다른 IP 주소에서 GitLab SAML 인증

이 탐지는 사용자별로 그룹화된 인증 이벤트를 GitLab SAML 인증 이벤트와 다른 IdP(Identity Provider) 인증 이벤트에 대해 상호 연관시키도록 설계되었습니다. 이는 사용자 IP 주소의 변경을 식별하기 위한 것으로, 이러한 변경은 공격자의 인증 세션을 나타내는 징후일 수 있습니다.

title: Gitlab SAML IP differs from SSO IP
description: Detects when the source IP for the SAML authentication to Gitlab from application.log differs from the users known IP from SSO MFA logs.
author: Gitlab Security Engineering
date: 09/15/2024
schedule: "*/10 * * * *"
pseudocode: |
  select log source application.log
  where severity="INFO" and meta_caller_id="Groups::OmniauthCallbacksController#group_saml"
  regex(message, "saving user (?<user_email>\S+) ")
  #Create sub-query to bring in table from SSO authentication data
  select meta_remote_ip, user_email
  where user_email in
    (
    select log source authentication
    where 1d < event_time < now()
    where event_type="user.authentication.auth_via_mfa"
    group by user_email, sso_source_ip
    )
  where sso_source_ip!=meta_remote_ip
verify: False positives can arise when the user is traveling. Review SSO authentication logs to see if the geo-location is similar to the SAML authentication to Gitlab. If any discrepancies are found, reach out to the user for verification. If the user is not traveling, temporarily lock the user's Gitlab account and review their activity through Gitlab's application logs.
tuning: If the query is producing high false positives, consider using geolocation functions on IPs to compare the cities and countries that are generating the authentications.