Puesta en marcha: Abuso de Power Apps para comprometer los servidores on-prem

Los servicios Power Platform de Microsoft ofrecen una plataforma de código bajo/sin código (LCNC) que incluye analytics de datos (Power BI), desarrollo de sitios web (Power Pages), asistentes virtuales (Power Virtual Agent) y una especie de desarrollo de "aplicación completa" (Power Apps). Estas plataformas pueden ofrecer a los usuarios empresariales con menos conocimientos técnicos la posibilidad de crear soluciones que, tradicionalmente, requerirían un desarrollador con más conocimientos técnicos y experiencia en programación.

Si bien las plataformas LCNC pueden ser una herramienta poderosa para los usuarios empresariales, los desarrolladores de la plataforma deben tener cuidado de que la seguridad esté integrada en cada paso. Es posible que los usuarios empresariales sin experiencia formal en programación no tengan el mismo nivel de concientización de seguridad que un desarrollador de software moderno. Esto puede aumentar la probabilidad de que se introduzcan errores de configuración del usuario en estas plataformas LCNC.

En esta entrada en el blog, veremos cómo, en 2022, el equipo de simulación de adversarios de X-Force Red combinó una configuración errónea de usuario común en ese momento con un problema de omisión de seguridad aún presente en la plataforma Power Apps de Microsoft. Esto permitió a X-Force Red violar un perímetro externo reforzado y obtener la ejecución de código en un servidor SQL on premises, lo que finalmente resultó en un compromiso total de Active Directory.

En 2022, el comportamiento predeterminado de Power Apps significaba que cuando una aplicación de Power Apps se compartía con los usuarios, también se compartiría cualquier conexión asociada. Esto facilitó mucho que los usuarios compartieran accidentalmente conexiones con todos los usuarios de una organización, cuando quizá solo pretendían compartir la aplicación frontend. Según Microsoft, este comportamiento se modificó en enero de 2024, lo que reduce considerablemente la probabilidad de que los usuarios compartan conexiones de forma accidental.

Sin embargo, en 2022, X-Force Red identificó una conexión SQL mediante una "puerta de enlace de datos on premises" para conectarse a un servidor SQL on-prem que se había compartido ampliamente de esta manera. Si bien las consultas SQL nativas no son compatibles con los servidores SQL on-prem en los flujos de Power Apps, X-Force Red identificó que la acción "Transformar datos mediante Power Query" podría usarse para ejecutar consultas SQL nativas en servidores on-prem. Esto permitió a X-Force Red pasar al servidor SQL on-prem y, en última instancia, lograr todos los objetivos del compromiso.

Este error se informó recientemente al Microsoft Security Response Center (MSRC) y le han asignado una gravedad baja, por lo que ahora estamos publicando los detalles.

Power Apps permite a los usuarios crear "aplicaciones" y "flujos" mediante una GUI de soltar y arrastrar que es típica de las plataformas LCNC. Las aplicaciones se pueden utilizar para crear aplicaciones front-end que generalmente se utilizan para extraer datos de algún lugar y mostrarlos al usuario. A continuación, se muestra una aplicación de demostración "Budget Tracker" proporcionada por Microsoft que toma datos de una hoja de cálculo de Excel y los muestra al usuario.

El otro lado de Power Apps, Flows, resultará familiar para cualquiera que haya utilizado antes otro servicio LCNC como Azure Logic Apps. Los flujos permiten a los usuarios crear un programa similar a un diagrama de flujo y suelen utilizarse para extraer datos, procesarlos y enviarlos a algún lugar. A continuación, se muestra un flujo muy básico que realiza una solicitud HTTP y luego analiza el JSON resultante.

Power Apps tiene un conjunto de "conectores" que permiten a los usuarios realizar tareas como ingerir datos o enviar correos electrónicos, sin recurrir al uso de muchas acciones de solicitud HTTP. Muchos de estos conectores son solo bibliotecas prediseñadas de solicitudes HTTP, pero abstraen todos los detalles técnicos del usuario. En lugar de tener que construir una solicitud HTTP a Graph API para obtener información sobre un usuario de Entra ID, simplemente puede conectar un conector de Entra ID y usar la acción "Obtener usuario".

Power Apps ofrece conectores para muchos servicios populares, incluidos servicios de Microsoft y ofertas de terceros. Puede tomar archivos de SharePoint, convertir un documento a PDF con Adobe PDF Services o reiniciar máquinas virtuales en Azure, solo por nombrar algunos. Cuando cree una conexión, se le dará una instrucción para proporcionar material de autenticación según el servicio al que se esté conectando. Para casi todo lo relacionado con Microsoft, simplemente se autenticará con su cuenta de O365.

Nota: En el resto de esta publicación, usaré "conector" para describir la biblioteca de acciones en Power Apps (por ejemplo, el conector Entra ID) y "conexión" para referirme a un conector que ha creado y autenticado un usuario (por ejemplo, la conexión de Entra ID autenticada como john.smith@contoso.com) y se puede utilizar para crear nuevas acciones.

Mientras exista esta conexión, su autenticación estará asociada a ella. Cualquier usuario con acceso a esa conexión puede crear nuevas acciones que utilizarán su autenticación. Por ejemplo, si crea una conexión de Entra ID, otro usuario con acceso a esa conexión podría crear una acción "Agregar usuario al grupo", que utilizará su autenticación, incluso si ese usuario no tiene los permisos necesarios de Entra ID para agregar un usuario a un grupo. Anteriormente escribí en un blog sobre cómo abusar de esto en Azure Logic Apps, y encontré un exploit útil de escalada de privilegios en Azure Logic Apps que abusaba de esta funcionalidad.

Hasta 2024, era mucho más probable que este tipo de ataque ocurriera en Power Apps. Antes, cuando compartías una aplicación que utilizaba una conexión, la conexión asociada también se compartía. Puede consultar la información al respecto en esta página de Microsoft, que no se ha actualizado desde 2022. Sin embargo, según esta página de 2024, esto ya no es así. Ahora, necesitará que la conexión se comparta con su cuenta, lo cual es un error de configuración mucho menos probable. Este podría ser el resultado de la charla de BlackHat 2023 “All You Need Is Guest” de Michael Bargury, una excelente conversación que también abordó cómo enumerar y volcar información de Power Apps.

¿Qué sucede si necesita acceder a datos que no están disponibles en Internet? ¿Qué sucede si necesita acceder a los datos desde un servidor SQL on premises? Microsoft ya ha pensado en esto y ha creado gateways de datos on premises. Los gateways se instalan en un host on premises y esencialmente actúan como un proxy que permite que los conectores de Power Apps hablen con los recursos on premises. Para acceder a un servidor SQL on premises, puede instalar un gateway en el SQL Server (o en otro servidor, o incluso en su estación de trabajo si está haciendo TI en la sombra) y luego usar el conector SQL para realizar consultas contra el servidor.

Hay seis tipos de autenticación admitidos para conectarse a un servidor SQL, aunque no todos funcionarán para servidores SQL on premises. Para on premises, es probable que utilice la autenticación de SQL Server o la autenticación de Windows, proporcionando sus credenciales o credenciales de SQL local.

Una vez que haya creado su conexión u obtenido acceso a una compartida, puede realizar una gran cantidad de acciones contra SQL Server. El que llamará la atención de la mayoría de los lectores es “Ejecutar una consulta SQL (V2)”.

Si no está familiarizado con las implicaciones de poder ejecutar consultas SQL nativas, entonces le sugiero que lea este blog de mi compañero de equipo, Sanjiv Kawa, sobre su herramienta SQLRecon. Obviamente, si puede ejecutar consultas SQL en un servidor, puede volcar todos los datos a los que tiene permisos de acceso, y esto podría ser preocupante si los datos confidenciales se almacenan en la base de datos. Sin embargo, si tiene acceso privilegiado al servidor SQL, puede ejecutar código en el sistema operativo subyacente. Aquí hay algunas maneras en que puede hacerlo:

• El procedimiento xp_cmdshell almacenado
• Procedimientos de automatización OLE
• Ejecución de ensamblajes .NET CLR
• Trabajos de agentes SQL

En última instancia, esto depende de los privilegios del usuario que creó la conexión, pero si alguna vez ha pasado por un servidor SQL para lograr un objetivo, entonces sabe lo comunes que son las cuentas con privilegios excesivos. Incluso si el usuario conectado no tiene los privilegios para ejecutar código, también puede verificar la suplantación de identidad, los enlaces a otros servidores SQL o las credenciales almacenadas en texto sin formato en bases de datos.

Sin embargo, en última instancia, todo esto no tiene sentido, ya que la acción “Ejecutar una consulta SQL (V2)” no es compatible con los gateways.

Otras acciones, como “Obtener filas (V2)”, que sacarán las filas de una tabla especificada, funcionan bien. Simplemente no podemos ejecutar consultas arbitrarias en el servidor. Supongo que esto se debe a que Microsoft consideró la posibilidad de abuso y decidió que exponer las inseguridades de los servidores SQL Server on premises a usuarios externos de O365 es malo.

Si examina todas las acciones disponibles para el conector SQL, verá la acción "Transformar datos con Power Query". A pesar del nombre, Power Query no es miembro de la familia de servicios de Power Platform. Más bien, es un motor de transformación de datos que puede encontrar dentro de otros servicios/aplicaciones, como Excel. Como motor de transformación de datos, Power Query está diseñado para tomar datos y transformarlos sin modificar los datos de origen.

Después de crear una acción “Transformar datos usando Power Query” con una conexión válida, se mostrará un menú con todas las tablas en cualquier base de datos a la que esté conectada. En mi servidor SQL de prueba, solo hay una tabla vacía llamada "Personas".

Seleccionar "Transformar datos" nos llevará a la siguiente pantalla, que es un editor de Power Query. Power Query emplea el lenguaje de fórmulas M, un lenguaje de transformación de datos desarrollado por Microsoft. Los documentos de referencia para el lenguaje M documentan el "Acceso a las funciones de datos", una lista de funciones que se pueden usar para ingerir datos en Power Query. Cuando abrimos nuestro editor de Power Query en la consulta predeterminada, vemos que la función "Sql.Databases" se utiliza para obtener información de la base de datos conectada.

Después de navegar por la versión en PDF de 1394 páginas del lenguaje M, noté que la función "Sql.Database" (tenga en cuenta la "S" que falta) tiene un parámetro opcional llamado "Query". Este parámetro se describe como “Una consulta SQL utilizada para recuperar datos”.

Si introduce el siguiente código de Power Query en el editor, se muestra una advertencia que dice que "Las consultas nativas pueden ser inseguras y alterar la base de datos".

Bueno, “alterar la base de datos” es mi segundo nombre, así que después de pulsar “Continuar”, somos recompensados con la salida de una consulta SQL nativa.

En resumen, así es como puede abusar de esto para comprometer un servidor SQL on premises con nada más que acceso a una licencia de Power Apps:

1. Un usuario crea una aplicación que utiliza una conexión on-prem SQL y la comparte con todos, ya sea a propósito o sin darse cuenta.
2. Un atacante crea un nuevo flujo y agrega una acción "Transformar datos con Power Query" utilizando la conexión SQL existente.
3. Si el usuario conectado es un administrador de SQL o tiene privilegios de suplantación, o hay enlaces SQL privilegiados o credenciales de texto sin cifrar en las bases de datos, o si ha obtenido otras credenciales de texto sin cifrar privilegiadas, ahora puede cambiar a un servidor SQL on premises.

Según estos documentos de Microsoft que se actualizaron por última vez en 2022, si comparte una aplicación que emplea datos de un gateway, entonces el gateway también será compartido. A partir de las pruebas en mi inquilino, este ya no parece ser el caso. Dicho esto, si tiene acceso a un gateway, puede crear nuevas conexiones a través de este, lo que significa que ya no está limitado por las conexiones existentes. Esto significa que debe tener credenciales de texto plano comprometidas para cuentas de AD o SQL y conocer los nombres de host de los servidores SQL, aunque no es raro encontrarse con esta información en SharePoint/Confluence.

También puede usar otros conectores que utilizan gateways, como la acción "Sistema de archivos". Esto también requiere que tenga credenciales y nombres de host válidos, pero significa que puede leer/escribir archivos en hosts internos.

Si obtiene acceso a una cuenta con acceso a Power Apps, tendrá que verificar todos los entornos a los que tiene acceso. Puede ver esto seleccionando el menú desplegable “Entorno” en la esquina superior derecha. En cada entorno, deberás seleccionar “… Más” y luego “Descubrir todo”. Esto lo llevará a una página donde puede navegar a todo en Power Apps.

Desde allí, puede seleccionar "Conexiones" para ver las conexiones a las que tiene acceso y "Gateways" para ver los gateways a los que tiene acceso. También puede ver quién es el propietario de las conexiones, así que puede comprobar si el usuario tiene privilegios o no.

Además, en el lado izquierdo de la pantalla están los botones "Flujos" y "Aplicaciones". Deberá pulsar “Compartido conmigo” para poder ver todo y comenzar a buscar credenciales de texto sin formato o información confidencial. Las acciones de flujo HTTP son particularmente adecuadas para encontrar contraseñas y claves de API.

Los administradores deben considerar limitar qué usuarios pueden instalar gateways o deshabilitarlos por completo si no hay un caso de uso comercial para ellos. Puede hacerlo en la plataforma de administración de Power Apps, y seleccionar "Datos", marcar la casilla "Administración de inquilinos" y luego seleccionar "Administrar instaladores de gateway". A partir de ahí, puede habilitar la configuración “Restringir que los usuarios de su organización instalen gateways” y agregar usuarios que necesiten instalar gateways. Consulte la documentación de Microsoft para obtener más información.

Considere evaluar periódicamente las conexiones en su entorno y asegurarse de que los usuarios no compartan ampliamente conexiones confidenciales.

En este blog, examinamos cómo un usuario con acceso a un conector de servidor SQL que utiliza un gateway de datos on premises puede ejecutar consultas nativas en el servidor y, potencialmente, pasar de O365 a recursos on premises. El comportamiento que anteriormente hacía de esto un error de configuración común se cambió en 2024, pero con el acceso correcto, un atacante aún puede encontrarse en condiciones de abusar de esto. Con el lanzamiento de este blog, esperamos que los defensores auditen su entorno para identificar puertas de enlace y conectores sobrecompartidos para evitar futuros ataques dirigidos a Power Apps.

10/2/2025: se presentó el caso original ante el MSRC

11/2/2025: el MSRC afirma que se trata de un problema de ingeniería social y cierra el caso

12/2/2025: se presentó el segundo caso ante el MSRC

24/2/2025: el MSRC evalúa la vulnerabilidad con gravedad baja