Blog sobre seguridad informática, privacidad, anonimato, hacking ético, programación y sistemas operativos en general.

Mostrando las entradas con la etiqueta auditoria de seguridad. Mostrar todas las entradas
Mostrando las entradas con la etiqueta auditoria de seguridad. Mostrar todas las entradas

miércoles, 23 de agosto de 2017

Parte 1: Cross Site Scripting (XSS): Robo de cookies y modificación de un sitio web (persistente y reflejado).


El Cross Site Scripting (XSS) es un tipo de vulnerabilidad que normalmente se presenta en páginas web, la cual permite al atacante inyectar y ejecutar códigos maliciosos en el servidor o CMS remoto. El XSS es una de las vulnerabilidades más comúnmente encontradas en sitios web y la principal razón de su existencia es que el administrador de una página confia en lo que el usuario introduce desde el teclado y le brinda información de acuerdo a su consulta, entonces el usuario puede introducir scripts específicos con código malicioso y de esta manera obtener información que el desee para un posterior ataque.

* ¡EL XSS ES PELIGROSO!

Aunque es una de las vulnerabilidades más conocidas y que muchas veces pasa desapercibida, el XSS es realmente una vulnerabilidad peligrosa, permite en ciertos casos cambiar el dominio del sitio web, redireccionarlo, robar credenciales del administrador y comprometer los datos que contenga el sitio web. ¡Todo depende de tus conocimientos y tu ingenio!

* ¿Que puede realizar el atacante por medio de esta vulnerabilidad?

1. Cambiar configuraciones.
2. Robo de cookies.
3. Robar tokens para hacer un CSRF (Cross Site Request Forgery) más fácil.

Como dijimos, debes ser creativo para explotar un XSS.

* TIPOS DE XSS.

1. Reflejado: Es el tipo de XSS menos peligroso y solo permite una modificación parcial del sitio web, para que otros lo vean el usuario debe enviar un link "especial" con el contenido a inyectar. Aquí un ejemplo de un código PHP vulnerable a XSS reflejado:

<?php
if(!array_key_exists("nombre",$_GET) | |$_GET['nombre'] == NULL || $_GET['nombre']==''){
$isempty=true;
}
else{
echo '<pre>';
echo 'Hola!' . $_GET['nombre'];
echo '</pre>';
}
?>

Como podemos ver el parámetro nombre no está definido correctamente ya que este devuelve un "echo" a el usuario, de manera que podemos ingresar un código JS del tipo <script>alert(/xss/)</script> y este lo ejecutará como tal.

2. Persistente: Este tipo de ataque es almacenado en el servidor y por lo tanto es visible a cualquier persona que ingrese al sitio web atacado. Este tipo de vulnerabilidad se presenta cuando los datos recolectados desde el teclado del usuario son guardados en el servidor y que son vistos normalmente en cualquier página que returne el mismo. Un ejemplo claro son los "chan's" o "boards" donde un usuario escribe un comentario que puede ser visto por otros usuarios. Aquí un ejemplo de un código PHP vulnerable a XSS persistente:

<?php
if(isset($_POST['btnSign']))
{
$mensaje=trim($_POST['mtxMensaje']);
$nombre=trim($_POST['txtnombre']);
// Entrada del mensaje
$mensaje = stripslashes($mensaje);
$mensaje = mysql_real_escape_string($mensaje);
// Entrada del nombre
$nombre = mysql_real_escape_string($nombre);
$query = "INSERT INTO guestbook (comentario,nombre) VALUES (
'$mensaje','$nombre');";
$result=mysql_query($query) or die('<pre>'.mysql_error().'</pre>');
}
?>

Las entradas de nombre y mensaje no están declaradas de manera correcta, ya que guardan los datos que reciben en la tabla guestbook y cuando el servidor returna esos datos al cliente este puede ejecutar código JS (JavaScript) malicioso que quedará almacenado en el servidor.


3. XSS basado en DOM (Document Object Model o Modelo de Objetos del Documento): Este tipo de XSS es una variante del XSS persistente. El DOM es un conjunto estandarizado de objetos para representar páginas web con JavaScript, lo cual permite abrir otra página web con código malicioso JavaScript incrustado, afectando el código de la primera página en el sistema local. Cuando el XSS es local, ningún código malicioso es enviado al servidor. El funcionamiento toma lugar completamente en la máquina del cliente, pero modifica la página proporcionada por el sitio web antes de que sea interpretada por el navegador para que se comporte como si se realizara la carga maliciosa en el cliente desde el servidor. Esto significa que la protección del lado del servidor que filtra el código malicioso no funciona en este tipo de vulnerabilidad.

A continuación usaremos la aplicación DVWA para realizar las demostraciones.

* XSS Reflejado.


Esto ocurre el introducir en el espacio "What's your name?" el cual es vulnerable a XSS Reflejado el siguiente texto: <script>alert("Esto+es+un+ejemplo+de+XSS+reflejado+by+SecHackLabs!")<%2Fscript>

* XSS Persistente.


Como vemos, este apartado funciona como un foro donde cada usuario deja su nombre y su mensaje. Pero ahora veamos que pasa si insertamos un nombre cualquiera y en mensaje algo como <script>alert("Aquí hay un XSS persistente!");</script>


Pues obtenemos un XSS persistente, el cual permanecerá ahí aunque recarguemos la página desde otro dispositivo y otra red.

* XSS DOM Based.

Supongamos que el siguiente código es usado para mostrarle a un usuario la opción de elegir su lenguaje preferido. Un lenguaje por defecto también es proporcionado en caso de que no haya elección alguna por parte del usuario, aquí una demostración:

<select>
<script>
document.write("<OPTION value=1>"+document.location.href.substring
(document.location.href.indexOf("default=")+8)+"</OPTION>");
document.write("<OPTION value=2>Spanish</OPTION>");
</script>
</select>

La página es invocada de una manera similar a esta: http://www.Xsitio.com/page.html?default=English

Un atacante puede usar esta web para enviársela a una víctima de la siguiente manera: http://www.Xsitio.com/page.html?default=<script>alert(document.cookie)</script>

El código JS original no esperaba que el parámetro Default tuviera código HTML como tal, por lo tanto este lo ejecuta dentro la página (DOM) y el navegador devuelve la página resultante al ejecutar la sentencia alert(document.cookie) que el atacante envió.
En el próximo post explicaremos técnicas avanzadas sobre cómo bypassear protecciones anti-XSS, firewalls y filtros, así como también dejaremos un par de scripts los cuales nos facilitarán llevar a cabo un robo de sesión, cookies, entre otros.

Dejen sus recomendaciones en los comentarios. Síguenos en Facebook, Twitter y unete a nuestra charla en Riot. También puedes dejar su donación a nuestra cuenta Paypal.

miércoles, 12 de julio de 2017

Tutorial de WPScan con nuestra herramienta WebHackSHL. "Parte I"


Este tutorial en la categoría de WordPress hacking muestra cómo escanear sitios web y blogs de WordPress para posibles vulnerabilidades y enumerar los usuarios de WordPress. Enumeración de usuario es el primer paso en el ataque de fuerza bruta con el fin de tener acceso a una cuenta de WordPress y se utiliza para recuperar una lista de nombres de cuenta. También le mostrará cómo ocultar los nombres de usuario de WPScan para que pueda evitar la enumeración de usuario y fácil intentos de fuerza bruta. Concluiremos este tutorial con una demostración de cómo bruta contraseñas de raíz utilizando la fuerza WPScan en Kali Linux o ArchLinux. WPScan es un cuadro negro WordPress escáner de vulnerabilidades y una herramienta indispensable para cualquier desarrollador web de WordPress para escanear en busca de vulnerabilidades y resolver problemas antes de que sean explotados por los hackers. Junto con Nikto, una gran herramienta de evaluación de servidor web, esta herramienta debe ser parte de cualquier prueba de penetración dirigidas a un sitio web de WordPress o blog.

Comenzaremos el test con nuestra herramienta WebHackSHL

$ cd WebHackSHL

$ sudo python2 webhackshl.py


Le damos y para que activen el servicio tor.



En este menú seleccionamos la letra "d".

Aquí seleccionamos la opción que mas le guste entre la "e" o "f".
Nos pide guardar la información de test para posterior revisión.
Desea Guardar el logs de la informacion? y/n : Introduce tu Respuesta y/n :

 En esta parte colocaremos el host a realizar el test.
 Introduce el host al que deseas hacerle el scan:
Nos piden actualizar la base de dato de WPScan y comenzara el test y nos dará los datos vulnerables de nuestro WordPress.
Hasta aquí la primera parte de este post para los siguiente tutorial les enseñare a saber cuales son los datos vulnerables y como explotarlos.

martes, 6 de junio de 2017

Servicios de auditoría de seguridad para garantizar la protección de vulnerabilidades de aplicaciones Web



En estos días, los sitios web son el blanco de constantes ataques, que pueden ser iniciadas desde cualquier lugar en todo el mundo. En resumen, la seguridad Web consiste en garantizar niveles adecuados de los aspectos fundamentales tales como la confidencialidad, integridad, disponibilidad y no la reputación con respecto a los datos o la información almacenada en las computadoras.

Auditoría de seguridad Web es reconocido como uno de los temas más de moda en tecnologías de la información. Debido al creciente número de hackers y spammers cada día, la seguridad web se está convirtiendo en una preocupación primordial y reto para las organizaciones. 

Existen vulnerabilidades en la Web si la seguridad de aplicaciones web no se tiene cuidado. Esto significa que no sólo toda su base de datos de información sensible está en riesgo, pero su sitio web también puede convertirse en el lugar de lanzamiento de las actividades delictivas como el phishing o se puede utilizar para transferir contenido ilegal.

Algunos de los métodos utilizados por los hackers para atacar sitios web son:

1: Inyección SQL
El proceso de inserción de sentencias SQL en alguna consulta a través de la interfaz de usuario de la aplicación web, que luego es ejecutado por el servidor.

2: Cross Site Scripting (XSS)
Cuando un usuario inserta HTML o script del lado del cliente en la interfaz de usuario de una aplicación web, que es visible para otros usuarios también.

3: Vulnerabilidad
Se identifica como una falla en la aplicación web, causada debido a los errores en la aplicación o la presencia de virus.

Beneficios de la Auditoría Seguridad del sitio web:

Detección Temprana Etapa: Reducción del coste, el riesgo y la complejidad mediante la detección y solución de vulnerabilidades de seguridad de aplicaciones temprano en el ciclo de vida del software de desarrollo.


· Seguro SDLC: Posibilidad de insertar los controles de seguridad en cada etapa del SDLC.
· Altos estándares de seguridad: Aumenta la confianza del usuario final en la seguridad de aplicaciones web mediante el cumplimiento de los estándares de seguridad más altos.
· Equipo de expertos: mejorar los conocimientos especializados para sus equipos de seguridad.
La finalidad de la prueba de seguridad es descubrir las vulnerabilidades de la aplicación web para que los desarrolladores puedan eliminarlos y hacer que la aplicación web y segura de datos del acceso no autorizado.

¿Cuál es exactamente el SDLC?

Organizaciones en desarrollo aplicaciones tienen en el lugar un proceso por el que cada aplicación está diseñado, desarrollado, probado, y desplegado. Esta secuencia de etapas que definen estos procesos se denomina el ciclo de vida de desarrollo de software, a menudo referido como el SDLC.

SDLC de una organización ayuda a dar forma a la manera en que sus aplicaciones se construyen y se definen los procesos exactos de cada aplicación debe ir a través, así como los hitos de una aplicación necesita para golpear antes de ir a la siguiente etapa del SDLC.

¿Qué es exactamente un seguro SDLC?

Un seguro SDLC es un proceso que tiene puntos de contacto con la seguridad en todas las etapas, así como los hitos de seguridad. Ir seguro de SDLC más allá de la estructura actual SDLC con el fin de asegurar que las aplicaciones que se despliegan son seguras después de la liberación, sin crear un retraso en el SDLC originales.

Las mayores ventajas de las organizaciones que adoptan un seguro SDLC es la creación de una alta calidad, producto de seguro

Tanto SDLC y protegido SDLC normalmente giran en torno a cinco etapas, donde en cada etapa del SDLC (Requisitos, diseño, desarrollo, prueba y despliegue) existen procesos de seguridad que hay que hacer durante ese tiempo: La evaluación de riesgos, el modelado de amenazas y la revisión del diseño, el análisis estático, las pruebas de seguridad y revisión de código, y finalmente la evaluación de la seguridad y la configuración segura.

Análisis estático para un SDLC 
análisis de código estático (SCA) es una de las fuerzas impulsoras detrás de la filosofía seguro SDLC  después de que los requisitos han sido claramente definido y aclarado a los desarrolladores.

Una de las mayores ventajas del uso de análisis de código estático en todo el SDLC es que la prueba puede ser totalmente automatizado, lo que permite a los desarrolladores implementar prácticas de codificación segura y desinfectar todo el proceso de desarrollo con el mínimo esfuerzo. los plazos de lanzamiento de productos pueden ser fácilmente satisfechas sin reducir la calidad o la liberación de los problemas de seguridad de riesgo.

En un SDLC, herramientas de análisis de código estático se pueden encontrar de forma rápida y desarrolladores de ayudar a proteger contra SQL Inyecciones, Cross-Site Scripting (XSS), Cross-Site Request Falsificación (CSRF) y otros ataques maliciosos. Sin un SDLC seguro mediante análisis de código estático, no hay garantía de que una aplicación está en libertad sin vulnerabilidades de seguridad.

Las mejores prácticas para el establecimiento de un seguro SDLC para la Seguridad desarrollo de aplicaciones:

Crear una política de romper la acumulación cuando se descubre una vulnerabilidad media o de alto nivel. No ponga su aplicación y la organización en riesgo - asegurarse de que las aplicaciones que estés liberando están libres de vulnerabilidades de alto riesgo.

Entender su negocio y proteger a los que con seguridad las aplicaciones. Si conoces los riesgos a que se enfrenta su empresa entonces es más fácil desarrollar software que protege contra esos riesgos. Desarrollo de aplicaciones de seguridad puede ofrecer la prevención de riesgos en la forma de frenar un enfoque de mercado (como la aplicación de los frenos en un coche) o acelerarlo (como empujar el acelerador) el truco es saber qué se necesita y cuándo.

Conocer la tecnología de su aplicación.  Es necesario tener en cuenta la tecnología a través de su plataforma. El idioma de su entorno puede ser dictado por preocupaciones de seguridad - por ejemplo, código de la ONU gestionados pueden ofrecer una mayor susceptibilidad a desbordarse ataques que los entornos de código administrado. Es necesario examinar los anfitriones, la segregación de la red y la infraestructura de clave, además del entorno de codificación y garantizar que no haya agujeros obvios (o no evidentes).

El cumplimiento es clave.  Asegúrese de que los requisitos de cumplimiento se cumplen a través de su seguro SDLC asegurando todas las pruebas, revisiones de código y pen-pruebas se incluyen dentro de su proceso. El SDLC seguro va más allá de la seguridad para incluir también de gobierno, los reglamentos y el cumplimiento marco de privacidad según lo requiera su entorno.

Educar a los desarrolladores.  Es esencial que los desarrolladores a entender la importancia de los conceptos de seguridad en aplicaciones tales como la confidencialidad, integridad, disponibilidad, autenticación y autorización.

Integración en el entorno de desarrollo. Más allá de los desarrolladores de enseñanza acerca de las prácticas de codificación segura y cuál es su papel en el SDLC seguro será, es igualmente importante para asegurar las herramientas que decide y uso se adapta bien para el entorno de desarrollo, la integración con el mayor número de procesos establecidos como sea posible.

Análisis de código fuente es su amigo. Entornos ágiles que buscan actualizar a un SDLC seguro son el lugar perfecto para análisis de código fuente para ser implementado. Una herramienta de análisis de código fuente sólida ofrece las ventajas de la lectura de códigos incrementales, la exploración de múltiples idiomas, una información rápida y asistencia desarrollador en la mitigación de vulnerabilidades en su código. Con el análisis de código fuente en su tubería, las aplicaciones pueden ser asegurados antes incluso de estar en la producción - a pesar de post-producción, la seguridad sigue siendo muy importante.

Mantener el aprendizaje. La seguridad es un campo en evolución. Desarrollo de aplicaciones de seguridad requiere un ciclo constante de revisión, la educación y la aplicación. Las mejores prácticas de hoy puede no ser las mejores prácticas mañana. Lo más importante es que es vital que todos los miembros de su equipo reconoce que la seguridad es tarea de todos y comprometerse a su parte en esto.

¿Por qué las empresas deben integrar las herramientas de pruebas de seguridad en un SDLC  para aplicaciones seguras?

Amenazas Web son uno de los mayores riesgos potencialmente devastadora que las empresas con una cara presencia en la web hoy en día. El malware es la principal amenaza para las empresas, y los costos asociados con la defensa desde y recuperarse de los ataques de malware se extiende en los mil millones de dólares cada año. Sin embargo, la seguridad de la red se ha vuelto increíblemente eficiente en los últimos años, lo que ha causado a los atacantes dirigen su atención a otras zonas vulnerables - especialmente la capa de aplicación. El código de aplicación con fallas de seguridad puede ser explotado para tener consecuencias devastadoras, no deseados en una organización y sus clientes. Las brechas de datos cuestan a las empresas millones de dólares al año, pero las herramientas de pruebas de software ofrecen una línea útil de defensa contra este tipo de ataques maliciosos.