CVE-2024-37010

CVE-2024-37010 익스플로잇: 다른 사용자의 외부 저장소 접근 및 측면 이동:

https://www.cert.ssi.gouv.fr/avis/CERTFR-2024-AVI-0753/

https://owncloud.com/security-advisories/insecure-direct-object-reference-in-external-storage

소개

Owncloud는 서버를 Google Drive와 같은 파일 저장용 클라우드로 전환합니다. 이를 통해 기업은 예를 들어 제3자가 관리하지 않는 직원용 클라우드를 제공할 수 있습니다.

관리자가 이렇게 구성한 경우, 사용자는 다른 클라우드, FTP 또는 Google Drive와 같은 외부 저장소를 연결하여 파일을 단일 클라우드에 중앙화하여 사용자의 삶을 더 편리하게 만들 수 있습니다.

외부 저장소를 생성한 후, 예를 들어 "폴더 이름" 필드를 변경하기 위해 이 양식을 업데이트할 수 있습니다. 양식이 업데이트되면 전체 양식이 JSON 형식으로 포함된 요청이 전송됩니다. 이 양식에서 'ID' 필드는 정수로서 서버가 저장소를 생성할 때 생성한 외부 저장소의 식별자입니다.

2. Idor Idor

다른 Owncloud 사용자(예: 관리자)도 ID가 "18"인 외부 저장소를 가지고 있다고 가정해 보겠습니다.

이제 특별한 권한이 없는 "normal_user" 사용자로 양식 업데이트 요청을 다시 실행하되 ID를 관리자의 외부 저장소인 18로 변경합니다.

1. 관리자 저장소 ID 입력
2. 임의의 저장소 이름 "storage_pwned" 설정
3. 확실히 하기 위해 임의의 호스트(이 경우 Burp Collaborator)도 지정합니다. 중요 참고: 호스트 변경은 필수가 아닙니다. 호스트를 변경하면 저장소 구성이 손상되어 Owncloud 서버가 원래 저장소에서 파일을 검색할 수 없게 됩니다.

요청이 전송되면 서버는 404 오류(4)를 반환하며 지정한 ID의 저장소를 찾을 수 없다고 알려줍니다(5).

그러나 관리자 계정으로 접속하면 다음과 같이 표시됩니다:

관리자의 저장소가 업데이트되었습니다.

1. 저장소 이름이 "storage_pwned"로 변경되었습니다.
2. 호스트가 Collaborator 주소로 대체되었습니다.
3. 그리고 가장 중요한 것은: 사용자 "normal_user"가 저장소에 접근할 수 있는 권한이 있는 사용자로 추가되었습니다.

다시 "normal_user"로 로그인하면 관리자의 저장소인 "storage_pwned"에 접근할 수 있게 된 것을 확인할 수 있습니다.

사용자 A는 사용자 B의 저장소를 업데이트하고 그에 대한 접근 권한을 다시 얻었습니다. 사용자 A는 사용자 B의 구성을 손상시키지 않고 후자의 파일에 접근할 수 있도록 업데이트 요청 중에 호스트를 수정하지 말아야 함을 상기시킵니다.

다음은 외부 저장소를 업데이트하는 데 사용된 코드입니다.

먼저, 요청을 보낸 사용자의 권한에 대한 검증이 없음을 알 수 있습니다. 코드는 저장소가 요청을 보낸 사용자의 것인지 확인하지 않습니다. 이것이 "normal_user"가 관리자의 저장소를 업데이트할 수 있었던 이유를 설명합니다.

둘째, 업데이트할 때마다 코드가 방금 요청을 보낸 사용자를 저장소에 연결할 권한이 있는 사용자 목록에 추가하는 것을 볼 수 있으며, 이는 업데이트 후 "normal_user"가 마술처럼 관리자의 저장소에 접근 권한을 부여받은 이유를 설명합니다.

요약

이 예제에서 한 사용자가 다른 사용자의 외부 저장소에 대한 전체 접근 권한을 얻고 그들의 개인 파일에 접근할 수 있는 방법을 살펴보았습니다. 이는 이미 상당히 중요한 취약점입니다.

3. 더 나아가서...

이 단계에서 보시다시피, 이 IDOR(안전하지 않은 직접 객체 참조)은 이미 주요 취약점입니다. 하지만 이 취약점을 계속 악용하여 미칠 수 있는 영향을 더 확대해 보겠습니다.

이를 위해 파일을 검색하기 위해 Owncloud 서버가 외부 저장소에 대해 수행하는 인증 프로세스를 이해해 봅시다. 간단한 로그인/비밀번호 쌍을 사용하는 기본 인증 시스템의 경우 클라우드 서버는 단순히

이제 공격자가 호스트를 자신이 제어하는 주소로 변경하여 이 구성을 업데이트하는 데 성공했다고 가정해 봅시다. 이는 Owncloud 서버가 이제 공격자가 제어하는 이 새 주소로 자격 증명을 보내게 됨을 의미합니다.

이것이 바로 우리의 취약점 덕분에 할 수 있는 일입니다.

다른 사용자의 저장소 ID를 지정하여 업데이트 요청을 재생할 때, 호스트를 예를 들어 우리의 Burp Collaborator로 지정하기만 하면 됩니다.

이렇게 하면 사용자가 다시 연결할 때 Owncloud 서버가 사용자의 자격 증명을 보내면서 우리의 Collaborator에 인증을 시도합니다.

마술처럼 Collaborator는 Base64로 인코딩된 자격 증명과 함께 Owncloud 서버로부터 인증 요청을 수신합니다.

따라서 우리는 관리자의 외부 저장소로부터 일반 텍스트 자격 증명을 방금 검색했습니다.

약간 추가...

외부 저장소에 대한 인증을 위해, 예를 들어 동일한 비밀번호를 사용하는 경우 자신의 Owncloud 자격 증명을 사용하여 로그인할 수 있습니다. 외부 저장소 업데이트를 요청할 때 "authMechanism" 필드에 "password::sessioncredentials"를 지정할 수 있습니다.

그러면 Owncloud 서버는 다음 연결 시 자격 증명을 일반 텍스트로 저장하고 인증을 위해 외부 저장소 장치로 전송합니다.

그래서 여러분은 다가올 일을 짐작할 수 있을 것입니다...

이는 공격자가 다른 사용자의 외부 저장소에 대해 이 메커니즘을 활성화하여 방금 우리가 한 것처럼 피해자의 Owncloud 세션의 일반 텍스트 자격 증명을 자신이 제어하는 호스트로 전송할 수 있음을 의미합니다.

4. 위험 요약

따라서 CVE-2024-37010을 통해 Owncloud 서버에 계정이 있는 공격자는 다음을 수행할 수 있습니다:

• 다른 사용자의 외부 저장소에 있는 파일에 대한 읽기/쓰기 접근 권한을 얻습니다.
• 연결된 외부 저장소 장치의 일반 텍스트 식별자를 얻습니다.
  • 외부 저장소로 이동합니다.
• 외부 저장소가 있는 사용자의 암호화되지 않은 Owncloud 계정 자격 증명을 얻습니다.
  • 계정 탈취 및 권한 상승.

타임라인

• 03/11/2024 - 취약점 발견
• 12/03/2024 - Owncloud에 보고서 제출
• 09/09/2024 - Owncloud의 공개 발표 및 CVE