역량 강화: Power Apps를 악용한 온프레미스 서버 손상

Microsoft의 Power 플랫폼 서비스는 데이터 분석(Power BI), 웹사이트 개발(Power 페이지), 가상 비서(Power 가상 에이전트), 일종의 '전체 애플리케이션' 개발(Power 앱)을 포함하는 로우코드/노코드(LCNC) 플랫폼을 제공합니다. 이러한 플랫폼은 기술 수준이 낮은 비즈니스 사용자에게 기존에는 프로그래밍 경험이 있는 보다 기술적인 개발자가 필요했던 솔루션을 만들 수 있는 기능을 제공할 수 있습니다.

LCNC 플랫폼은 비즈니스 사용자에게 강력한 도구가 될 수 있지만 플랫폼 개발자는 모든 단계에서 보안이 적용되도록 주의를 기울여야 합니다. 비즈니스 사용자들은 공식적인 프로그래밍 경험이 없을 수 있으므로, 최신 소프트웨어 개발자와 동일한 수준의 보안 인식을 갖추지 못할 수 있습니다. 이로 인해 이러한 LCNC 플랫폼에 사용자 구성 오류가 발생할 가능성이 높아질 수 있습니다.

이 블로그 게시물에서는 2022년에 X-Force Red의 적대적 시뮬레이션 팀이 Microsoft의 Power Apps 플랫폼에 여전히 존재하는 보안 우회 문제와 당시의 일반적인 사용자 구성 오류를 어떻게 결합했는지 살펴볼 것입니다. 이를 통해 X-Force Red는 강화된 외부 경계를 뚫고 온 프레미스 SQL 서버에 코드를 실행할 수 있게 되었고, 결국 Active Directory가 완전히 손상되는 결과를 초래했습니다.

2022년에는 기본 Power Apps 동작에 따라 Power Apps 애플리케이션을 사용자와 공유할 때 연결된 모든 연결도 공유되었습니다. 이로 인해 사용자가 프론트엔드 애플리케이션만 공유하려고 할 때 조직의 모든 사용자와 실수로 연결을 공유하는 일이 매우 쉬워졌습니다. Microsoft에 따르면 이 동작은 2024년 1월에 변경되어 사용자가 실수로 연결을 공유하기할 가능성이 훨씬 줄어듭니다.

2022년에 X-Force Red는 이러한 방식으로 널리 공유된 온프레미스 SQL 서버에 연결하기 위해 '온프레미스 데이터 게이트웨이'를 사용하는 SQL 연결을 확인했습니다. Power Apps의 온프레미스 SQL Server에서 네이티브 SQL Query는 지원되지 않지만, X-Force는 'Power Query를 사용하여 데이터 변환' 작업을 통해 온프레미스 서버에 대해 네이티브 SQL Query를 실행할 수 있음을 확인했습니다. 이를 통해 X-Force Red는 온프레미스 SQL 서버로 전환하여 궁극적으로 모든 목표를 달성할 수 있었습니다.

이 버그는 최근 Microsoft 보안 대응 센터(MSRC)에 보고되었으며, 심각도가 낮음으로 지정되어 이제 세부 정보를 게시하고 있습니다.

Power Apps를 사용하면 사용자는 LCNC 플랫폼에 일반적인 드롭 앤 드래그 GUI를 사용하여 '앱'과 '플로우'를 만들 수 있습니다. 애플리케이션은 일반적으로 어딘가에서 데이터를 가져와 사용자에게 표시하는 데 사용되는 프론트엔드 애플리케이션을 만드는 데 사용할 수 있습니다. 다음은 Microsoft에서 제공하는 '예산 추적기' 데모 애플리케이션으로, Excel 스프레드시트에서 데이터를 가져와 사용자에게 표시합니다.

Power Apps의 다른 측면인 플로우는 이전에 Azure Logic Apps와 같은 다른 LCNC 서비스를 사용해 본 적이 있는 사람이라면 익숙할 것입니다. 플로우를 통해 사용자는 순서도와 같은 프로그램을 만들 수 있으며 일반적으로 데이터를 가져와 처리한 다음 어딘가로 보내는 데 사용됩니다. 다음은 HTTP 요청을 수행한 다음 결과 JSON을 구문 분석하는 매우 기본적인 흐름입니다.

Power Apps에는 사용자가 여러 HTTP 요청 작업을 사용하지 않고도 데이터 수집 또는 이메일 전송과 같은 작업을 수행할 수 있는 '커넥터' 제품군이 있습니다. 이러한 커넥터 중 다수는 사전 구축된 HTTP 요청 라이브러리이지만 사용자로부터 모든 기술적 세부 사항을 추상화합니다. Entra ID 사용자에 대한 정보를 얻기 위해 Graph API에 HTTP 요청을 구성할 필요 없이, Entra ID 커넥터를 연결하고 '사용자 가져오기' 작업을 사용하면 됩니다.

Power Apps는 Microsoft 서비스 및 타사 제품을 포함하여 널리 사용되는 여러 서비스에 대한 커넥터를 제공합니다. SharePoint에서 파일을 가져오거나, Adobe PDF Services를 사용하여 문서를 PDF로 변환하거나, Azure에서 가상 머신을 다시 시작하는 등의 작업을 수행할 수 있습니다. 연결을 생성하면 연결 중인 서비스에 따라 인증 자료를 제공하라는 프롬프트가 표시됩니다. Microsoft와 관련된 거의 모든 경우 O365 계정을 사용하여 인증하기만 하면 됩니다.

참고: 이 게시물의 나머지 부분에서는 Power Apps의 작업 라이브러리를 설명하는 데 '커넥터'를 사용하고(예: Entra ID 커넥터), 사용자가 만들고 인증한 커넥터(예: john.smith@contoso.com으로 인증된 Entra ID 연결)를 나타내는 '연결'을 사용하겠습니다(예: john.smith@contoso.com으로 인증된 Entra ID 연결). 새로운 작업을 만드는 데 사용할 수 있습니다.

이 연결이 존재하는 한 인증은 이 연결과 연결됩니다. 해당 연결에 액세스할 수 있는 모든 사용자는 인증을 사용하는 새 작업을 만들 수 있습니다. 예를 들어 Entra ID 연결을 생성하는 경우 해당 연결에 대한 액세스 권한이 있는 다른 사용자가 '그룹에 사용자 추가' 작업을 생성할 수 있으며, 해당 사용자가 계정을 추가하는 데 필요한 Entra ID 권한이 없더라도 해당 사용자의 인증을 사용할 수 있습니다. 사용자를 그룹으로 연결합니다. 저는 이전에 Azure Logic Apps에서 이 기능을 악용하는 사례에 대해 블로그에 쓴 적이 있고, Azure Logic Apps에서 이 기능을 남용하는 유용한 권한 상승 익스플로잇을 발견했습니다.

2024년까지만 해도 이러한 유형의 공격은 Power Apps에서 발생할 가능성이 훨씬 높았습니다. 예전에는 연결을 사용하는 애플리케이션을 공유하면 연결된 연결도 함께 공유되는 경우가 많았습니다. 이 문서는 Microsoft의 이 페이지에서 확인할 수 있으며, 2022년 이후 업데이트되지 않았습니다. 하지만 이 페이지에 따르면 2024년부터는 더 이상 그렇지 않습니다. 이제 계정과 공유할 연결이 필요하므로 구성이 잘못될 가능성이 훨씬 적습니다. 이는 2023년 BlackHat 강연 "All You Need Is Guest"의 Michael Bargury가 발표한 결과일 수 있는데, 이 강연은 Power Apps에서 정보를 열거하고 덤프하는 방법도 다룬 훌륭한 강연입니다.

인터넷에서 사용할 수 없는 데이터에 액세스해야 하는 경우 어떻게 해야 하나요? 온프레미스 SQL 서버에서 데이터에 액세스해야 한다면 어떻게 될까요? Microsoft는 이미 이 점을 고려하여 온프레미스 데이터 게이트웨이를 만들었습니다. 게이트웨이는 온프레미스 호스트에 설치되며 기본적으로 Power Apps 커넥터가 온프레미스 리소스와 통신할 수 있도록 하는 프록시 역할을 합니다. 온프레미스 SQL Server에 액세스하려면 SQL Server(또는 다른 서버, 또는 섀도우 IT를 수행하는 경우 워크스테이션)에 게이트웨이를 설치한 다음 SQL 커넥터를 사용하여 서버에 대한 쿼리를 수행할 수 있습니다.

SQL Server 연결에는 6가지 인증 유형이 지원되지만 모든 인증 유형이 온프레미스 SQL Server에서 작동하는 것은 아닙니다. 온프레미스의 경우 SQL Server 인증 또는 Windows 인증을 사용하여 AD 자격 증명 또는 로컬 SQL Server 자격 증명을 제공할 가능성이 높습니다.

연결을 만들거나 공유 연결에 대한 액세스 권한을 얻은 후에는 SQL Server에 대해 다양한 작업을 수행할 수 있습니다. 대부분의 독자의 시선을 사로잡는 것은 "SQL 쿼리 실행(V2)"입니다.

네이티브 SQL 쿼리를 실행할 수 있다는 점의 의미를 잘 모른다면, 제 팀원인 Sanjiv Kawa가 쓴 SQLRecon이라는 도구에 관한 블로그를 읽어보시길 권합니다. 물론 서버에서 SQL 쿼리를 실행할 수 있다면 액세스 권한이 있는 모든 데이터를 덤프할 수 있으며, 이는 민감한 데이터가 데이터베이스에 저장된 경우 문제가 될 수 있습니다. 그러나 SQL Server에 대한 액세스 권한이 있는 경우 기본 운영 체제에서 코드를 실행할 수 있습니다. 다음은 이를 수행할 수 있는 몇 가지 방법입니다.

• xp_cmdShell 저장 프로시저
• OLE 자동화 절차
• .NET CLR 어셈블리 실행
• SQL 에이전트 작업

이것은 궁극적으로 연결을 생성한 사용자의 권한에 따라 다르지만, 목표를 달성하기 위해 SQL Server를 통해 피벗해 본 경험이 있다면 계정에 과도한 권한이 부여되는 것이 얼마나 흔한 일인지 알 수 있습니다. 연결된 사용자에게 코드를 실행할 권한이 없더라도 사칭, 다른 SQL Server에 대한 링크 또는 데이터베이스에 일반 텍스트로 저장된 자격 증명을 확인할 수도 있습니다.

그러나 게이트웨이에서는 'SQL 쿼리 실행(V2)' 작업이 지원되지 않기 때문에 이 모든 것은 궁극적으로 의미가 없습니다.

지정된 테이블에서 행을 가져오는 '행 가져오기(V2)'와 같은 다른 작업도 정상적으로 작동합니다. 서버에서 임의의 쿼리를 실행할 수 없습니다. Microsoft가 악용 가능성을 고려하고 외부 O365 사용자에게 온프레미스 SQL Server의 안전성을 노출시키는 것은 좋지 않다고 판단했기 때문인 것 같습니다.

SQL 커넥터에서 사용할 수 있는 모든 작업을 살펴보면 'Power Query를 사용하여 데이터 변환' 작업을 찾을 수 있습니다. 이름에도 불구하고 Power Query는 Power 플랫폼 서비스 제품군에 속하지 않습니다. 오히려 Excel과 같은 다른 서비스/애플리케이션에서 찾을 수 있는 데이터 변환 엔진입니다. 데이터 변환 엔진인 Power Query는 원본 데이터를 수정하지 않고 데이터를 가져와 변환하도록 설계되었습니다.

유효한 연결을 사용하여 "Power Query를 사용하여 데이터 변환" 작업을 생성하면 연결된 데이터베이스의 모든 테이블을 보여주는 메뉴가 나타납니다. 테스트용 SQL 서버에는 "Persons"라는 빈 테이블만 있습니다.

'데이터 변환'을 선택하면 Power Query 편집기인 다음 화면으로 이동합니다. Power Query는 Microsoft에서 개발한 데이터 변환 언어인 M 공식 언어를 사용합니다. M 언어에 대한 참조 문서에는 Power Query로 데이터를 수집하는 데 사용할 수 있는 함수 목록인 "데이터 함수 액세스"가 나와 있습니다. Power Query 편집기를 기본 쿼리로 열면 "SQL Database" 함수가 연결된 데이터베이스에서 정보를 가져오는 데 사용되고 있음을 알 수 있습니다.

1,394페이지에 달하는 M 언어의 PDF 버전을 살펴본 결과, "Sql.Database" 함수("S"가 누락됨)에 "Query"라는 선택적 매개변수가 있는 것을 발견했습니다. 이 매개변수는 "데이터 검색에 사용되는 네이티브 SQL 쿼리"로 설명됩니다.

다음 Power Query 코드를 편집기에 입력하면 "네이티브 쿼리는 안전하지 않을 수 있으며 데이터베이스를 변경할 수 있습니다"라는 경고가 표시됩니다.

"데이터베이스 변경"이 중간 이름이므로 "계속"을 누르면 네이티브 SQL Query의 아웃풋이 보상으로 주어집니다.

요약하자면, Power Apps 라이선스에 대한 액세스만으로 온프레미스 SQL Server를 손상시키는 방법은 다음과 같습니다.

1. 사용자가 온프레미스 SQL 연결을 사용하는 애플리케이션을 만들고 고의로 또는 실수로 모든 사람과 공유합니다.
2. 공격자는 새 흐름을 만들고 기존 SQL 연결을 사용하여 "Power Query로 데이터 변환" 작업을 추가합니다.
3. 연결된 사용자가 SQL 관리자이거나 가장 권한이 있거나, 데이터베이스에 권한 있는 SQL 링크 또는 일반 텍스트 자격 증명이 있거나, 다른 권한 있는 일반 텍스트 자격 증명을 얻은 경우, 이제 온프레미스 SQL Server로 피벗할 수 있습니다.

2022년에 마지막으로 업데이트된 이 Microsoft 문서에 따르면 게이트웨이의 데이터를 사용하는 앱을 공유하면 게이트웨이도 공유됩니다. 제 테넌트에서 테스트한 결과, 더 이상 그렇지 않은 것 같습니다. 즉, 게이트웨이에 액세스할 수 있는 경우 이를 통해 새 연결을 만들 수 있으므로 더 이상 기존 연결에 제한을 받지 않습니다. 이것은 AD 또는 SQL Server 계정에 대한 일반 텍스트 자격 증명이 손상되고 SQL Server의 호스트 이름을 알고 있어야 한다는 것을 의미하지만, SharePoint/Confluence에서 이러한 정보를 발견하는 것은 드문 일이 아닙니다.

"파일 시스템" 작업과 같이 게이트웨이를 사용하는 다른 커넥터를 활용할 수도 있습니다. 또한 유효한 자격 증명과 호스트 이름이 필요하지만 내부 호스트에서 파일을 읽고 쓸 수 있습니다.

Power Apps 액세스 권한이 있는 계정에 액세스할 수 있는 경우 액세스 권한이 있는 모든 환경을 확인해야 합니다. 오른쪽 상단 모서리에 있는 '환경' 드롭다운을 선택하면 확인할 수 있습니다. 각 환경에서 '... 자세히'를 선택한 다음 '모두 보기'를 선택해야 합니다. 그러면 Power Apps의 모든 항목을 탐색할 수 있는 페이지로 이동합니다.

여기에서 '연결'을 선택하면 액세스할 수 있는 모든 연결을 볼 수 있고, '게이트웨이'를 선택하면 액세스할 수 있는 게이트웨이를 볼 수 있습니다. 또한 누가 연결을 소유하고 있는지 확인할 수 있으므로 사용자가 권한이 있는지 여부를 확인할 수 있습니다.

또한 화면 왼쪽에는 '플로우' 및 '앱' 버튼이 있습니다. '나와 공유됨'을 눌러 모든 내용을 확인하고 일반 텍스트 자격 증명이나 민감한 정보를 찾을 수 있습니다. HTTP 흐름 작업은 특히 비밀번호와 API 키를 찾는 데 적합합니다.

관리자는 게이트웨이를 설치할 수 있는 사용자를 제한하거나 비즈니스 사용 사례가 없는 경우 게이트웨이를 완전히 비활성화하는 것을 고려해야 합니다. Power Apps 관리 플랫폼으로 이동하여 '데이터'를 선택하고, '테넌트 관리' 확인란을 선택한 다음, '게이트웨이 설치 관리자 관리'를 선택하면 됩니다. 이 곳에서 '사용자가 게이트웨이를 설치하지 못하도록 제한' 설정을 활성화하고 게이트웨이를 설치해야 하는 사용자를 추가할 수 있습니다. 자세한 내용은 Microsoft 문서를 참조하세요.

사용자 환경의 연결을 주기적으로 평가하고 사용자가 민감한 연결을 광범위하게 공유하지 않도록 하는 것이 좋습니다.

이 블로그에서는 온프레미스 데이터 게이트웨이를 사용하여 SQL Server에 액세스할 수 있는 사용자가 서버에서 기본 쿼리를 실행하고 잠재적으로 O365에서 온프레미스 리소스로 전환하는 방법을 살펴보았습니다. 이전에는 이러한 잘못된 구성이 흔히 발생하던 동작이 2024년에 변경되었지만, 올바른 액세스 권한을 가진 공격자는 여전히 이를 악용할 수 있는 위치에 있을 수 있습니다. 이 블로그의 출시를 통해 방어 팀이 환경을 감사하여 게이트웨이와 과잉 공유 커넥터를 식별하여 Power Apps를 대상으로 하는 향후 공격을 방지할 수 있기를 바랍니다.

2025년 2월 10일: 원본 MSRC 사례 제출

2025년 2월 11일: MSRC, 소셜 엔지니어링 문제라고 밝히고 사건 종결

2025년 2월 12일: 두 번째 MSRC 사례 제출

2025년 2월 24일: MSRC, 심각도가 낮음으로 취약점 평가