Underc0de Blog: Seguridad Web

Seguridad Web

Mostrando entradas con la etiqueta Seguridad Web. Mostrar todas las entradas

Que se publique una actualización o parche de seguridad no quiere decir que la totalidad de los usuarios hagan uso de él. Esto ha pasado con un problema detectado hace unos días en Joomla, publicando los responsables una solución a este que sin embargo no ha sido adoptada por la mayoría y ahora los ciberdelincuentes están atacando los sitios web que hacen uso del CMS.

Tal y como suele suceder, tanto la parte encargada de descubrir el fallo como la parte implicada y que debe emitir una actualización se ponen de acuerdo para no publicar los detalles hasta que la actualización sesté disponible. Sin embargo, el problema ha sido doble, ya que antes de que se publicase algunos sitios web que utilizaban este gestor de contenidos ya registraron los primeros ataques aprovechando esta vulnerabilidad que permitía la inyección de código SQL y como consecuencia conseguir el control de éste.

Los expertos en seguridad han confirmado que fueron varios los sitios web afectados pero que algunos tenían configurado de forma correcta un firewall que de alguna forma neutralizó el ataque llevado a cabo.

Desde el CMS han hecho un llamamiento a los usuarios y webmasters que utilicen éste para que actualicen cuanto antes a esta nueva versión para hacer frente al problema de seguridad detectado y que está provocando más problemas de los pensados en un primer momento.

Tal y como se puede ver en el gráfico anterior, el número de ataques realizados se ha incrementado prácticamente de forma exponencial.

Muchos aún no han actualizado a la última versión de Joomla

Aunque el primer problema haya sido el apogeo de estos mucho antes de la publicación de la solución, ahora la mayor preocupación es que no se actualice a esta última versión. Y es que ya es bastante habitual encontrar que los CMS no posean la última versión publicada. Esto supone evidentemente un ahorro de tiempo para los administradores de páginas web, sin embargo, la posibilidad de que los fallos de seguridad existentes sean utilizados por ciberdelincuentes para robar información o hacerse con el control de la página es mucho más alta que manteniendo el CMS al día en lo referido a las actualizaciones.

Tras la gráfica que hemos podido ver con anterioridad, podemos observar que tras el descubrimiento de un fallo de estas características los webmasters disponen solo de 24 horas antes de que los criminales realicen ataques masivos contra los sitios web.

Fuente; redeszone.net

Vísitanos en Underc0de

Las conexiones SSL cada vez son más importantes para proteger la información que enviamos a través de Internet y evitar que esta pueda ser capturada en un punto intermedio entre nuestro ordenador de origen y el servidor de destino. Aunque muchas páginas web utilizan ya este protocolo, no todas las configuraciones son igual de seguras y aunque pensemos que nuestro tráfico está siendo protegido es posible que piratas informáticos, organizaciones u otros elementos puedan estar controlándolo.

Free SSL Test Server es una plataforma online, totalmente gratuita, que nos va a permitir comprobar la seguridad de las conexiones SSL de un servidor concreto, tanto por dominio (una web, por ejemplo) como por dirección IP.

Esta plataforma web lleva a cabo 4 tipos de tests diferentes:

Prueba de cumplimiento de las reglas NIST.
Prueba de cumplimiento de los requisitos PCI DSS.
Prueba de comportamiento frente a las debilidades y vulnerabilidades más recientes de SSL/TLS.
Prueba de diferente contenido de terceros que pueda comprometer la seguridad de las conexiones.

El uso de la plataforma es muy sencillo. Lo único que debemos hacer es acceder a su página web e introducir en ella el servidor con conexión SSL que queremos analizar. Si no queremos que nuestro análisis se guarde debemos marcar la opción que aparece debajo el cuadro de búsqueda.

Una vez elegido comenzamos el análisis, el cual puede durar un par de minutos en completarse según la carga de trabajo de los servidores de Free SSL Test Server. Una vez finalice el análisis podemos ver en la web un resumen del mismo y descargar los resultados en formato PDF para analizarlos con calma en nuestro ordenador y poder llevar a cabo las tareas de mantenimiento correspondientes.

Como podemos ver, esta plataforma nos indicará, en primer lugar, si la conexión tiene posibles vulnerabilidades conocidas, analizará todos los aspectos importantes de la conexión SSL, nos mostrará toda la información relacionada con el certificado y nos indicará si tiene debilidades o si cumple correctamente con las reglas y requisitos de las diferentes organizaciones como NIST.

La plataforma también nos permite ver los últimos análisis que se han realizado (siempre que no se haya marcado de opción de ocultar resultados durante la búsqueda) así como las notas que ha obtenido cada plataforma.

Como podemos ver, Free SSL Test Server es una completa plataforma que nos va a permitir comprobar hasta qué punto son seguras las conexiones que enviamos a través de los diferentes protocolos de Internet y, si somos los administradores de un servidor, conocer estas vulnerabilidades e intentar solucionarlas lo antes posible para garantizar la seguridad de los datos de los usuarios.

Fuente: redeszone.net

Visítanos en Underc0de

Muchas veces, al inyectar un sitio web nos topamos con passwords en texto plano: MD5 o SHA-1

Hay programadores -que quizás por ignorancia- no conocen este tipo de ataques y lo peligroso que pueden ser.

Además del SQLi, existen varias formas de poder obtener las credenciales del administrador de un sitio. Incluso si logran arrebatar la base de datos del mismo.

Algo que podemos hacer, es generar passwords seguras y en caso de que alguien logre obtener el hash, no pueda descifrarlo o le resulte en extremo complejo.

De esta forma, cada contraseña que generemos, será totalmente diferente a las demás y la única forma de averiguarla será obteniendo el algoritmo para generarla.

¿QUÉ ES UN HASH?

Un hash es una cadena de texto que se logra aplicando un proceso matemático o algorítmico con la finalidad de transformar ese texto en una nueva cadena totalmente inentendible. Una vez obtenido este hash, es difícil volver al texto original sin conocer el proceso que se aplicó para obtenerlo.

MD5 y SHA-1 son uno de los tantos tipos de hashes que existen, el motivo por el cual los menciono, es porque son los más utilizados hoy en día. Lo malo de ellos es que existen muchas formas de descifrarlos por fuerza bruta o diccionario, y de esta forma recuperar el texto plano.

Algunas reglas básicas para generar una contraseña segura pueden ser:

Usar siempre una semilla o salt.

La semilla debe ser los más aleatoria posible.

Utilizar una semilla diferente para cada password.

No almacenar la semilla en ninguna parte.

SALT

La finalidad del salt es generar un string aleatorio y añadirlo al password. De esta forma, aumentará la longitud del password y también la complejidad para descifrarlo.

El ataque de Rainbow Table (Tabla Arco Iris), solo funciona cuando las passwords han sido hasheadas con el mismo salt. Si usamos el mismo salt para todas las passwords correremos el riesgo de que puedan romperlas. Es por ello, que lo aconsejable es crear un salt distinto para cada password.

Para generar salts aleatorios en PHP, lo mejor es usar las funciones mcrypt_create_iv o openssl_random_pseudo_bytes

A continuación, un ejemplo, de su uso:

Código: PHP

<?php
$user = $_POST['user'];
$pass = $_POST['pass'];
$salt = str_replace('=', '.', base64_encode(mcrypt_create_iv(20)));
$hash = hash_hmac('SHA512', $pass, $salt);
var_dump($hash);
?>

Básicamente, lo que hace el código es recibir una password por POST, luego generamos un salt y lo unimos a la contraseña del usuario y finalmente lo ‘encriptamos’ con SHA512

Con esto podemos tener una password “segura”. Lo remarco con comillas, ya que pienso que la seguridad es un mito. No existe nada que sea 100% seguro.

A pesar de tener este nuevo hash difícil de crackear, hoy en día existen máquinas que se usan únicamente para romper contraseñas, por lo que podemos hacer esta tarea un poco más difícil añadiendo una iteración al código.

Código: PHP

<?php
function hash_password($password, $salt)
{
$hash = hash_hmac('SHA512', $pass, $salt);
for ($i = 0; $i < 5000; $i++)
{
$hash = hash_hmac('SHA512', $hash, $salt);
}
return $hash;
}
$user = $_POST['user'];
$pass = $_POST['pass'];
$salt = str_replace('=', '.', base64_encode(mcrypt_create_iv(20)));
$hash = hash_password($pass, $salt);
var_dump($hash);
?>

Como se puede ver en el código, estas 5.000 iteraciones vuelve un poco más seguro y difícil de crackear.

Con estos algoritmos, podremos tener un nivel medio de seguridad a la hora de guardar nuestras contraseñas y en caso de que alguien obtenga algún hash, no podrá descifrarlo fácilmente.

Espero que les guste!
ANTRAX

Ir a Underc0de

... Los dominios, ...suelen entregar mucha información y en ocasiones más de lo debido. A la hora de contar con servicios, dominios, sitios web y demás, muchas veces se escapan detalles como suelen ser las configuraciones en los servidores DNS, por lo que veremos de qué se trata la transferencia de zona a los DNS y cómo esto puede exponer información e infraestructuras.

... Los servidores DNS básicamente son equipos que se encargan de resolver nombres de dominio a direcciones IP. Esto permite a los usuarios acceder a servicios de manera amigable, ya que recordar las direcciones IP sería más complejo.

No obstante, suelen ser utilizados por los atacantes para recolectar información acerca de la infraestructura y subdominios de la posible víctima –aunque existen herramientas automatizadas para hacerlo, como por ejemplo Dnsnum. De esta última vemos una captura de pantalla a continuación:

Puede verse con claridad cómo con solo indicarle unos pocos parámetros (en este caso –enum para enumerar la información) ya comienza con la recolección de información, no solamente de los servidores DNS sino también haciendo búsquedas en Internet. Si bien hace todo por sí sola con solo indicarle el dominio, debe comprenderse cómo funciona por detrás.

Para obtener este tipo de información se puede utilizar el comando dig en los sistemas Linux y OS X; es una herramienta de consultas a servidores DNS, como veremos a continuación:

Vemos que al realizar la consulta, automáticamente se listan los servidores DNS que se encargan de resolver las consultas. Para realizar esta consulta se utiliza el siguiente comando:

Código: Bash

dig NS midominio.net

Una vez ejecutado el comando en un entorno Linux, mostrará la lista de los correspondientes servidores encargados de responder a las solicitudes para ese dominio.

¿Por qué un atacante querría realizar la transferencia de zona y recolección los registros de los servidores DNS?

Sucede que a través de ellos se llega a recolectar información de una red corporativa, exponiendo en ocasiones sus direcciones IP internas, servidores y equipos. Para recolectar esta información debe usarse el parámetro “axfr” (a este tipo de ataque también se lo denomina AXFR) donde el comando queda de la siguiente manera:

Código: Bash

 dig @ns1.midominio.net axfr midominio.net

El parámetro “axfr” es quien permite la transferencia de zona de dicho DNS, ya que se usa para sincronizar y actualizar datos de la zona cuando se produjeron cambios. Si bien la transferencia puede hacerse vía “axfr”, también es posible hacerla de forma incremental, denominada entonces “ixfr” -cuando se ejecuta la solicitud se obtiene la transferencia de toda la zona como respuesta. Sin la debida configuración, esto le permite a un atacante replicar la base de datos DNS, obteniendo información sensible.

Una vez hecho esto, si el ataque tiene éxito, podrá verse cómo resulta la exposición de mucha información, como veremos en la siguiente captura de pantalla:

Puede apreciarse en el ejemplo mostrado que se listan direcciones IP, servicios que seguramente son de uso interno como portales de login, servicios de correo e inclusive los portales disponibles para las versiones móviles.

¿Cómo puedo ver esta información desde Windows?

De la misma forma en que podemos obtener esta información con el comando dig desde sistemas Linux, también podemos obtenerla desde sistemas Windows con Nslookup. Veamos en la siguiente captura de pantalla cómo hacerlo:

Si bien desde Windows cambian un poco los comandos y los parámetros, puede realizarse de igual forma. En primer lugar es necesario abrir la consola de Windows (también es posible usar consola aquí); para hacerlo basta con escribir “cmd” en la barra de búsqueda en el menú Inicio y presionar la tecla Enter.

Una vez abierta la consola, como se muestra en nuestro ejemplo anterior, se puede iniciar la secuencia de comandos:

1- El primero a ejecutar es nslookup seguido de la tecla Enter; esto inicia la herramienta para realizar consultas a servidores DNS

2- El segundo es: set type=ns (aquí se especifica que el tipo de consulta en este caso Name Server); una vez presionado Enter, en la siguiente línea debe colocarse el dominio a consultar, por ejemplo com.ar

3- El tercero a ejecutar es: set type=all seguido de la tecla Enter (aquí se especifica que se realicen todas las consultas posibles)

4- El cuarto y último es: ls ejemplo.com.ar, el cual se encargará de listar la información disponible

Entonces ¿Qué hacemos para prevenir la fuga de este tipo de información?

Es muy importante comprender que toda esta información podría ser explotada por un cibercriminal para comprometer un equipo o la red completa. Sabiendo esto de antemano, disponemos de las herramientas para realizar el análisis proactivo para su prevención.

Para evitar estos dolores de cabeza de fuga de información, desde el Laboratorio de Investigación de ESET Latinoamérica recomendamos revisar los archivos de configuración en los servidores DNS.

Cabe destacar que dependiendo del software que se esté utilizando para este servicio, será donde se encuentra ubicado su archivo de configuración para permitir o denegar el o los equipos autorizados a realizar dicha transferencia.

Por ejemplo, para solucionar este problema en bind9, se debe acceder al archivo named.conf.local (ubicado por defecto en /etc/bind) y editarlo, con la finalidad de admitir la transferencia de zona solo a direcciones IP de servidores DNS secundarios de confianza. Para hacerlo debe modificarse el archivo de la siguiente forma:

Es importante tener siempre presente que este archivo puede variar su configuración y ubicación dependiendo de qué software se utilice. Recomendamos comprender cómo funciona el que se está utilizando y realizar la configuración correspondiente.

Como pudimos ver, algo que puede parecer tan simple representa un serio riesgo de seguridad. Vimos cómo utilizando herramientas propias del sistema operativo, en conjunto con malas configuraciones del otro lado, se logra recopilar una gran cantidad de información sensible.

A través de la información obtenida, el atacante puede comprender la topología de la red y de esta forma intentar vulnerarla. Por eso, es necesario trabajar de forma proactiva para detectar este tipo de situaciones y corregirlas, antes que sea aprovechado por un atacante. Aplicando las correcciones necesarias a estos problemas proactivamente podremos utilizar la tecnología de forma segura y sin tantas preocupaciones.

Fuente:welivesecurity.com

Me encontraba tratando de acceder a un hosting por X motivos, digamos que había "algo" interesante para llevarlo a uno a meterse donde no lo invitan, probablemente mas adelante le dedique un apartado en este blog a ese "algo", pero por ahora se los dejare picando. Una vez que había logrado evadir el formulario de autentificación que me llevaba a la zona del admin lo demás parecía sencillo, subir shell mediante uno de los uploads. Había dos tipos: de imagenes y de ficheros pdf.

Este ultimo no realizaba ningún tipo de control sobre la extención del archivo que se le pasaba, pero al momento de enviar la shell era redirigido hacia una respuesta 406.

Me suena a WAF!, ¿sera ModSec?

Al comienzo creí que el WAF filtraba funciones peligrosas como popen, system, shell_exec, etc, pero a medida que probaba me fui dando cuenta de que no permitía la inclusión de los tags <? ?> directamente. Cada vez que trataba de evadir las restricciones para colar mi código seguía recibiendo el cachetazo en seco del 406, cuando se me ocurrió que podía desactivar ModSec con un .htaccess fue en vano, el 406 seguía ahí. Así que ya en las ultimas a punto de desistir tuve la idea de embeber codigo php en el EOF de una imagen del tipo png, y si!, finalmente había subido exitosamente la shell!, pero al momento de llamarla no se ejecutaba!, ¿por qué?.

Por lógica no tendría que haber problema, se tendrían que visualizar los caracteres ilegibles seguidos de mi webshell, esto ya me estaba frustrando. Supuse que quizá se trataba de algún tag abierto dentro del source de la imagen, así que me puse a relojear el code para encontrarme con una cadena que llamo poderosamente mi atención.

¿Por que el WAF no saltaba?, si incluía los tags <? ?>

Extensible Metadata Platform (XMP)

XMP es un estándar ISO creado por adobe para el registro de metadatos en formato XML en archivos pdf e imágenes.

Para cerciorarme de que el WAF realmente no restringía el pasaje de la cadena <?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?> decidí subirla en limpio.

Evidentemente había logrado insertar los tags sin recibir un 406 a cambio!, por supuesto al momento de ejecutar el script aparecía un error de sintaxis debido a que lo que se encontraba entre <? ?> no se trataba de una estructura PHP valida, solo faltaba saber ¿hasta que punto controlaba el WAF la regla de la cabecera XMP?.

Jugando un poco con el string a través de ensayo y error, llegue a la conclusión de que los tags podían incluirse siempre y cuando se respete la siguiente regla.

Código: PHP

<?xpacket ?>

Entonces para disfrazar esta oportunidad y que mi script pasara desapercibido ante ModSec, se me ocurrió crear una función llamada xpacket que iba a contener la instrucción a ejecutar, en este caso descargar una webshell en el servidor.

De esta manera logre hacer a un lado las restricciones para tener una consola de comandos web limpia dentro del hosting.

Probablemente existan muchas otra maneras de saltarse el firewall web, pero esta me pareció de los mas interesante, además de que surgió de la persistencia con un toque de suerte

Autor: [Q]3rv[0]
Fuente: http://www.securitysignal.org/2015/05/enganando-el-waf-con-xmp.html

Hace unos días reportaron un XSS por POST en el formulario de contacto de Underc0de. Por suerte no era nada riesgoso, pero era una vulnerabilidad que debíamos arreglar.
En esta ocasión usaremos el código de ese formulario de contacto para reproducir la falla y para ver como probar si nuestras aplicaciones son vulnerables a los XSS por POST.

El código del formulario de contacto está acá: www.hospedando.com.mx/descargas/formulario.zip por si alguno desea realizar la prueba.

Además, necesitaremos alguna herramienta que modifique los parámetros que enviemos por POST. Yo usare Tamper Data que es un complemento de Firefox:

https://addons.mozilla.org/es/firefox/addon/tamper-data/

Una vez montado el formulario de contacto se vera algo así:

El primer paso será completar todos sus campos y abrie Tamper Data. Una vez hecho esto, damos en "Comenzar Modificación" (En el tamper data) y enviamos el formulario de contacto.
Seguido a esto, nos aparecerá una alerta en Tamper Data para modificar los datos que estamos enviados.

Damos en modificar, y revisamos los valores que está enviando del lado derecho, que son los que hemos cargado desde el formulario.

Ahora es momento de jugar con estos campos. Este formulario de contacto no filtra sus variables, asique colocaremos algún vector de XSS en sus parámetros.
En este caso, coloqué un simple alert en el campo correo.

<script>alert('XSS')</script>

Al dar en Aceptar, el sitio seguirá cargando con la nueva información suministrada...

Y como podrán apreciar, apareció el Alert con nuestro mensaje.

Espero que les sirva!

Como sabrán muchos Cloudflare actúa como proxy inverso filtrando conexiones (Puerto 80/443).
Entre las medidas de seguridad que Cloudflare tiene ante ataques de capa 7 (Nivel de aplicación web) son:

1.- Balanceador de carga (Cloudflare divide la carga entre distintos servidores en todo el mundo).
2.- Filtro de cabeceras http.
3.- Verificación de cookie

Ahora, muchos se preguntarán, ¿Cómo saltarse el modo de "Estoy bajo ataque"?

Antes que nada, informo que nada se obtiene de la suerte, para lograr saltarnos este paso primero hay que analizar a fondo de que manera actúa este mecanismo de defensa.

Para quienes ya hayan analizado un poco se podrán dar cuenta de que una función javascript es la encargada de otorgar o no el acceso a los clientes legítimos.

Algo como esto:

Código: Javascript

<script type="text/javascript">

  //<![CDATA[

  (function(){

    var a = function() {try{return !!window.addEventListener} catch(e) {return !1} },

    b = function(b, c) {a() ? document.addEventListener("DOMContentLoaded", b, c) : document.attachEvent("onreadystatechange", b)};

    b(function(){

      var a = document.getElementById('cf-content');a.style.display = 'block';

      setTimeout(function(){

        var t,r,a,f, mdyTuiL={"eD":+((!+[]+!![]+!![]+!![]+[])+(!+[]+!![]+!![]+!![]+!![]))};

        t = document.createElement('div');

        t.innerHTML="<a href='/'>x</a>";

        t = t.firstChild.href;r = t.match(/https?:\/\//)[0];

        t = t.substr(r.length); t = t.substr(0,t.length-1);

        a = document.getElementById('jschl-answer');

        f = document.getElementById('challenge-form');

        ;mdyTuiL.eD*=!+[]+!![]+!![]+!![]+!![]+!![]+!![]+!![]+!![];mdyTuiL.eD+=!+[]+!![]+!![];mdyTuiL.eD*=!+[]+!![]+!![]+!![];mdyTuiL.eD*=+((+!![]+[])+(!+[]+!![]));mdyTuiL.eD+=+((!+[]+!![]+!![]+!![]+[])+(!+[]+!![]+!![]+!![]+!![]+!![]));mdyTuiL.eD+=+((+!![]+[])+(+!![]));mdyTuiL.eD+=+((!+[]+!![]+[])+(!+[]+!![]+!![]+!![]));mdyTuiL.eD+=+((+!![]+[])+(!+[]+!![]+!![]+!![]+!![]+!![]));mdyTuiL.eD+=+((+!![]+[])+(+!![]));a.value = parseInt(mdyTuiL.eD, 10) + t.length;

        f.submit();

      }, 5850);

    }, false);

  })();

  //]]>

</script>

Vale, viéndolo de este modo es algo confuso, ustedes se preguntarán ¿Cómo esta función identifica a un cliente legítimo?
Pues la respuesta esta en el mismo javascript, generalmente un bot no puede ejecutar javascript ( a menos de que se haya configurado para hacerlo), y en el supuesto de que este sea el caso, Cloudflare tambien combina el uso de html.

Código: HTML5

<form id="challenge-form" action="/cdn-cgi/l/chk_jschl" method="get">

    <input type="hidden" name="jschl_vc" value="339b52c916b4b33d83d0737d068d6d99"/>

    <input type="hidden" id="jschl-answer" name="jschl_answer"/>

  </form>

</div>

Viéndolo de esta manera, para lograr ejecutar javascript & html tendríamos que ser un navegador web; en efecto, esa es la respuesta: solo un navegador web podría ejecutar cierta función y obtener la cookie que será la encargada de otorgarnos el acceso al host solicitado. Lástima no podemos ejecutar código html, ni javascript, así que no podremos...

Un momento...pero la tecnología avanza y los tiempos cambian así que ¿por qué no convertir nuestro bot en un navegador ?

Analizamos la función y vemos que es lo que hace exactamente:

4 variables que almacenan información básica (una de los cuales es el esquema y la longitud de host), así como un objeto de nombre aleatorio que contiene la respuesta real "desafío".

La respuesta se calcula con algunas operaciones aritméticas que se encuentra semi ofuscado dentro del código para hacernos un poco mas complicado el trabajo, y se añade a la entrada "jschl_answer" del formulario.
A la respuesta se envía entonces al directorio: "/cdn-cgi/l/chk_jschl", que valida la respuesta al "desafío" y, si tiene éxito, devuelve un código de respuesta (301) al recurso solicitado inicialmente, así como una cookie "cf_clearance".

Esto lo solucionamos con un poco de código :

Ahora, tenemos la cookie! lo que significa que de esta cookie en solicitudes posteriores no pasa por nuevos "desafios" y podremos visualizar el sitio web con normalidad.

Cada solicitud contiene diferentes operaciones aritméticas, y la coookie "cf_clearance" está restringida a una dirección IP individua; lo que quiere decir que esta cookie no se puede usar en otros ordenadores con diferente dirección IP.

Autor: inzect02

Actualizad Joomla: vulnerabilidad que permite inyección de código SQL

Muchos aún no han actualizado a la última versión de Joomla

Conexiones SSL ¿seguras o vulnerables? Compruébalo mediante test online

Passwords Seguras

¿De qué se trata un ataque transferencia de zona a los DNS?

Engañando al WAF con XMP

XSS por POST

Bypass CloudFlare (Capa 7)

Underc0de

Underc0de

Sponsors

Síguenos!

Popular Posts

Labels

Archivo del blog

Blogs amigos

Comentarios recientes

Visitas