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" %>