miércoles, 25 de diciembre de 2019

Viewstate without MAC Signature



by @raulrenales


Si sois usuarios de ZAP y últimamente habéis trabajado en el pentest de aplicaciones web basada en .NET es muy probable que os hayáis topado con esta vulnerabilidad, Viewstate without MAC Signature. En este post vamos a intentar hablar sobre ella y sobre las opciones de explotación que esta vulnerabilidad tiene, intentando aprender un poco como funciona el concepto de viewstate.


Comencemos por lo más sencillo ¿Qué es viewstate?

Para los que conozcáis un poco el protocolo HTTP no os descubrimos nada si os contamos que una pagina web carece de información de estado debido al diseño básico del protocolo. Esto implica que la web no almacena información de conexiones anteriores, esto conlleva a que cada petición que se realice haga regenerar la pagina desde cero, sin “guardar” las informaciones que se habían introducido anteriormente en esta misma pagina web por parte del usuario. Simplemente el diseño de HTTP no fue pensado para servir las complejas paginas que tenemos hoy en día.
Debido a este problema pronto aparecieron diferentes maneras de mantener la información de estado como Cookies, Campos ocultos, ControlState, SessionState, Cache …. Una de ellas es nuestra Viewstate.

¿Cómo funciona el viewstate?

Lo primero que debemos de entender es que ViewState tiene dos estructuras diferentes dependiendo del lado en el que nos encontremos, lado del cliente o del servidor.
En el lado del cliente el viewstate esta representado por un campo oculto que contiene un valor codificado en Base64. Este valor codificado recopila información de los controles que muestra la web, a mayor numero de controles mayor tamaño de la cadena codificada.



En el lado del servidor viewstate no es más que un diccionario del tipo Clave-Valor donde se almacena la información del estado y un Hash que es utilizado para identificar si alguien ha manipulado el viewstate en algún momento.


Tipos de ataques contra la viewstate

Un viewstate no firmado podría habilitar diferentes ataques los cuales pasamos a enumerar:

·   Suplantación de contenido: Este caso se da cuando modificamos el valor del viewstate. La posibilidad de suplantación de contenido para una página HTML surge del propósito principal de ViewState, es decir, preservar la página y controlar los valores. Si los datos de ViewState colocados en el cuerpo de respuesta HTTP no se filtran correctamente, se produce suplantación de contenido. Este problema se presenta con las siguientes configuraciones vulnerables:
o   EnableViewStateMac = false
o   ViewStateEncryptionMode = nunca | auto
o   ViewStateUserKey = EMPTY

·     Fuga de información: Si el desarrollador no encripta el parámetro VIEWSTATE, un atacante puede decodificar la estructura VIEWSTATE y extraer datos confidenciales. Si el desarrollador no verifica la integridad de los datos (MAC), un atacante puede cambiar los parámetros que pueden influir en la lógica de la aplicación web, lo que facilita la omisión de autenticación, la omisión de autorización y el abuso de la funcionalidad. Configuración vulnerable:
o   ViewStateEncryptionMode = nunca | auto
o   EnableViewStateMac = falso | verdadero

·       Facilitador de otras vulnerabilidades: Todas las demás vulnerabilidades comunes para aplicaciones web, como la inyección de SQL, OS Commanding, así como otras vulnerabilidades de tipos como la Explotación de código, la Divulgación de información, etc., pueden y deben verificarse tanto en variables de la estructura ViewState como en otras variables enviadas por GET / POST / COOKIES. Configuración vulnerable:
o   EnableViewStateMac = false
o   ViewStateEncryptionMode = nunca | auto


Un ejemplo practico

Supongamos que nos hacen responsables de un proyecto en el que tengamos que diseñar un pequeño concesionario de coches. Básicamente tenemos una serie de vehículos que están agrupados por categorías y que ponemos a disposición de los visitantes para que realicen una compra, la vista es esta:




Como vemos en la imagen, vamos presentando vehículos a los visitantes según la categoría. Esta mínima actividad estará generando un viewstate en nuestra página con los valores vistos en el Gridview.



Veamos otro ejemplo de coche que vendemos en el concesionario:



Y también observamos como el viewstate es completamente diferente:



Mediante Burp cuando estamos viendo vehículos de categoría 2, ósea el formula 1 caro, vamos a alterar el _ViewState y el _EventValidation con los obtenidos en el ejemplo 1 del coche mas barato, y el resultado será la compra de un vehículo de categoría 2 a precio de categoría 1.



Soluciones, o porque nunca deshabilitar la firma MAC.

Para ser claros, no hay motivo alguno para tener deshabilitado esta propiedad, no existen excepciones ni buenas razones. De hecho, la misma gente de Microsoft ha iniciado el camino para que esta propiedad no sea configurable y de esta manera no pueda ponerse a false en siguientes versiones.
Básicamente se debe habilitar la propiedad enableViewStateMac en la web.config:

<pages enableViewStateMac="true" />

También se puede habilitar de manera individual por página:

<%@ Page EnableViewStateMac="true" %>



Fuentes:

https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.page.enableviewstatemac?redirectedfrom=MSDN&view=netframework-4.8#System_Web_UI_Page_EnableViewStateMac