La lucha de Windows contra la ejecución de código: Éxitos y fracasos (VII): Attack Surface Reduction

Resulta complicado entender todo el entramado que está montando Microsoft alrededor de Windows 10, con medidas de seguridad cada vez más integradas y complejas. Es muy positivo, sino fuera porque algunas medidas están adquiriendo una complejidad tal que para el usuario medio (poco instruido en seguridad) le resultan poco menos que esotéricas, incompresibles y por tanto, inútiles si no están activadas por defecto (que muchas no lo están). Seguimos hablando en esta entrega del ASR y sus diferentes "recetas". No ofrecen mucha información de cómo detectan que un script se encuentra "cifrado", en realidad quieren decir que se encuentren ofuscados, como bien se desprende de su versión en inglés ("Block execution of potentially obfuscated scripts"). Para sus pruebas en ExploitGuard Demo ( herramienta ya retirada de la que hablamos en la entrada anterior), Microsoft usaba esto (aunque parezca raro): O sea que no estaba para nada ofuscado, y claro, así resulta muy difícil evaluar la efectividad. Ese es el mismo ejemplo contenido en la herramienta, pero para JavaScript: Que pretendía estar ofuscado, pero que finalmente no lo estaba. QQQ es una variable larguísima. Pero luego ni se usa y al final se llama a todo sin ofuscar. Es como un intento frustrado, pero que se coló en su herramienta finalmente. Lo cierto es que si hacemos algo relativamente sencillo en JavaScript, y lo ofuscamos: Efectivamente, eludimos la contramedida. No entendemos qué heurística sigue para poder decidir si está ofuscado, pero realmente no funciona para casos "habituales". Y según muchos otros que han probado, realmente es que parece que no funciona para nada. Evita que se lancen comandos desde el famoso PsExec (muy usado para lanzar comandos remotos) y scripts WMI. Esta receta de ASR funciona a medias, por ejemplo, en el caso de WMI es capaz de detener la ejecución de forma eficaz, como se muestra en la imagen, pero es abortado tras aplicar la contramedida. Esta contramedida también es capaz de detener el WMI cuando se encuentra dentro de las macros de Office, por tanto, si recordamos la entrada anterior, ahora sí que es efectivo para detener las macros WMI. Sin embargo, con PSEexec ocurre algo muy curioso. Simplemente parece no bloquearlo cuando se utiliza de forma "normal" (esto es cuando se intenta lanzar algo sin elevar). En cualquier caso, existen formas de realizar técnicas de movimiento lateral que eludan pasar por ASR, como por ejemplo se explica aquí y aquí. Ahora bien, en cualquier caso, si pretendemos utilizar PsExec para, por ejemplo, elevar privilegios a SYSTEM, sí que nos detiene la ejecución. Pero esto no tiene sentido, puesto que para elevar a SYSTEM previamente tenemos que partir de privilegios de administrador, y si se tienen privilegios de administrador, se podría simplemente desactivar la medida de protección previamente. Los detalles en la imagen. Aun así, existe una fórmula descrita aquí para eludir esta receta cuando funciona. Se basa en que cuando se ejecuta PsExec, se extrae un binario que se instala como servicio. Se extrae en c:Windows y se lanza un servicio llamado "PSInfo Service". Aunque parezca extraño, esta regla lo que bloquea es la creación del servicio en sí, por tanto, si se crea el servicio antes de lanzar el comando... no será capaz de bloquearlo.

En resumen, agarramos el ejecutable en c:Windows cuando se lanza PsExec, e instalamos el servicio previamente:

PSEXESVC.exe -install

Y luego lo iniciamos: sc start PSINFSVC Y ya está. Ahora el comando psexec -s -i cmd.exe funcionará incluso con la receta ASR activa.Continuaremos analizando el resto de recetas en la siguiente entrada. Consulta el resto de entregas sobre "La lucha de Windows contra la ejecución de código":