Archive for Vulnerabilidades

Las principales vulnerabilidades web

Cuando se va a atacar un sistema, lo último que se quiere es que salten todas las alarmas. Es por eso que usar fuentes online son una buena herramienta. Se puede utilizar hacking de buscadores para localizar URLs con paso de parámetros, para comprobar si éstos están correctamente validados, para buscar correos electrónicos u otra información que pueda extraerse de un determinado sitio: ficheros de backup o de configuración que hayan quedado indexados, etc.

Un buscador muy utilizado es Shodan. Este buscador almacena toda la información pública que puede obtener de aquellos dispositivos que están expuestos a Internet. Entre otras cosas, podemos encontrar dispositivos con sus claves por defecto (routers, cámaras ip, etc), direcciones IP con los puertos que tienen abiertos, servicio y versión del mismo que corre en cada uno, certificados SSL, con sus respectivas suites de cifrado, etc. Una vez indexada una determinada IP en Shodan, evita tener que hacer una comprobación directa sobre el sistema, de manera que permite a un atacante conocer si un sitio web está correctamente actualizado, sin necesidad de lanzar un escaneo de puertos, que pueda delatarle a él.

Read more

Ransomware en MongoDB

Introducción

En las últimas semanas se han producido varios ataques de ransomware contra servidores de bases de datos MongoDB, concretamente se calculan que más de 20.000 bases de datos se han visto afectadas en todo el mundo dando lugar a cerca de 680 TB de fuga de información.

El problema está en la gran cantidad de servidores publicados y en este caso que vamos a comentar, indexados por Shodan. Vale con una simple búsqueda utilizando ciertos filtros de Shodan para descubrir los servidores de MongoDB publicados en Internet.

Shodan en acción

Podemos usar el filtro “product” como vemos a continuación.

product:mongodb

Donde obtenemos 38.845 resultados tal y como se puede ver en la imagen.

Ransomware en MongoDB

Otra opción es usando el filtro “port” indicando el número de puerto correspondiente por defecto a las instancias de MongoDB, el 27017.

port:27017

Obteniendo aproximadamente unos 500 resultados más, 39.311, posiblemente como consecuencia de haber aplicado “seguridad por oscuridad“, ocultando nombre de producto, versiones, etc.

Read more

OWASP Mobile Security Project

Introducción

OWASP (Open Web Application Security Project) nos provee de una serie de recursos basados sobre todo en guías y herramientas para que nuestros proyectos web sean lo más seguros posibles, tanto desde el punto de vista de desarrollo seguro como de la evaluación de la seguridad de éstos.

Para los desarrolladores ofrece una gran cantidad de recursos para ayudar a llevar a cabo un ciclo de vida de desarrollo de software seguro (S-SDLC, Secure Software Development Life Cycle).

Para los auditores de seguridad ofrece una gran cantidad de recursos como guías y herramientas para evaluar la seguridad de las aplicaciones móviles.

OWASP Objetivos

OWASP Mobile Security Project

Pues bien, tanto los desarrolladores de aplicaciones móviles como los auditores de éstas, pueden aprovecharse también de recursos de este tipo para poder alcanzar el objetivo de la máxima seguridad posible. Para ello OWASP nos propone su Mobile Security Project.

owasp-msp-logo

La imagen anterior es el logotipo oficial del proyecto OWASP Mobile Security Project.

OWASP ProcesosAl igual que en las aplicaciones web, para conseguir el nivel máximo de seguridad posible es imprescindible que todos los factores se alineen; personas, procesos y tecnología.

Recursos OWASP Mobile Security Project

A continuación nombraremos algunos de los recursos disponibles en este proyecto.

Top 10 Mobile Risks: Tal y como podemos encontrar con el Top 10 de riesgos en aplicaciones web, también tenemos este recurso disponible en el proyecto MSP.

Developer Cheat Sheet: Una “chuleta” con consejos para el desarrollador para evitar errores que puedan dar lugar a vulnerabilidades en su aplicación.

App Security Testing Cheat Sheet: Una “chuleta” para el auditor con información interesante para llevar a cabo la evaluación de la seguridad de la aplicación.

Secure Mobile Development: Recurso para el desarrollador que le ayudará durante el ciclo de desarrollo de software seguro (S-SDLC).

Security Tesing Guide: Similar a la Testing Guide para aplicaciones web, también podemos encontrar una guía de test para ayudar al auditor durante sus tareas de evaluación de los controles de seguridad de la aplicación.

Tools: OWASP nos propone un arsenal de herramientas que nos ayudarán tanto para el desarrollo seguro así como para testear los distintos controles de seguridad. Disponibles para las diferentes plataformas (Android, iOS o Windows Phone).

Top 10 Mobile Controls: Definidos conjuntamente por la ENISA y OWASP, nos indica el top 10 de los controles de seguridad a evaluar.

owasp-msp-resources

En próximos artículos en el blog hablaremos de los distintos recursos que acabamos de comentar. Como siempre, esperamos que sean de vuestros interés y esperamos vuestro feedback.

¡Saludos!

@miguel_arroyo76

 

 

Hacking vía Satélite

Vamos a jugar un poco con decodificadores de televisión vía satélite con el objetivo de ver algunos fallos de seguridad, pero antes de nada vamos a dar varias nociones para aquellas personas que no conozcan el tema.

Normalmente la persona que quiere ver la televisión de pago vía satélite necesita una antena parabólica (por la cual recibimos la señal de datos), un decodificador de satélite (capaz de decodificar la señales del satélite) y una tarjeta de abonado (que contiene las claves para descifrar la señal de datos cifrada). Hasta aquí todo correcto, verdad? pero antes de nada vamos a añadir una:

NOTA LEGAL

  • El objetivo de este artículo es conocer la seguridad de los receptores de comunicación vía satélite.
  • Rechazamos el uso de cualquier técnica ilegal como Card Sharing o IKS.
  • Ningún sistema sufrió daño alguno mientras se realizaron las pruebas de concepto.
  • No me hago responsable del mal uso que podáis dar a la información aquí mostrada.

Read more

Skipfish, Escaner Web

Hoy en día existen infinidad de aplicaciones, scripts, frameworks, etcétera para auditar sistemas, ya sean de infraestructura de red, Web, Web basado en OWASP, Wireless, etc… Suelen aparecer software con versiones gratuitas, gratuitas con limitaciones y versiones de pago con diferentes de modalidades.

Las de pago las vamos a obviar porque evidentemente, se necesita una inversión bastante potente en muchas de ellas y para algo “casero” pues no es demasiado lógico gastarse miles de euros.

Las versiones libres o scripts subidos a la red (GitHub por ejemplo), suelen tener la ventaja que son personalizables y puedes editarlos a tu gusto, que es lo que se estila para adaptar los resultados a gusto o necesidad de auditores o meros curiosos.

Hoy nos vamos a centrar en mostrar un escaner Web bastante potente que tiene sus pros y contras pero que es otra herramienta más que puede ayudarnos enormemente en labores de buscar agujeros de seguridad en plataformas Web ya sean en pre-producción o producción. Hablamos de Skipfish

skipfish2

Read more

Seguridad en las impresoras

Introducción

Cuando hablamos de seguridad en las empresas y qué activos proteger, enseguida se nos vienen a la cabeza los distintos vectores de ataque de nuestros sistemas de información y cómo protegernos de esos posibles ataques. Pero, ¿qué ocurre con la seguridad en las impresoras?

Seguridad perimetral, seguridad en las comunicaciones, seguridad en el puesto de trabajo, seguridad en los dispositivos móviles… son algunos de los ejemplos de protección de activos de la empresa.

Pero estamos pasando por alto un tema importante de seguridad en este planteamiento, y se trata de las impresoras. ¿Existen posibles vectores de ataque a este tipo de dispositivos? Si es así, ¿cuáles podrían ser? Quizás el problema radique en que vemos a la impresora como una “simple” máquina cuya función es imprimir lo que desde un ordenador enviamos.

Si nos detenemos en qué es una impresora, enseguida entenderemos que, además de la electrónica y mecánica pura de una impresora, está dotada de una serie de puertos, interfaz de red, controladores, disco duro y un pequeño ordenador, con su BIOS y con su sistema operativo, que maneja estos recursos.

OK, ahora más o menos nos hacemos una idea, pero ¿qué riesgos hay realmente? Vamos a dividirlos en varios apartados:

Vectores de ataque

Confidencialidad del documento impreso

En entornos corporativos es muy normal que se utilicen impresoras de red que está ubicadas en un lugar remoto de la oficina. ¿Qué ocurre si mandamos a imprimir un documento con información sensible? Desde que nos levantamos del puesto de trabajo hasta que recogemos el documento de la bandeja de la impresora, ¿quién ha podido ver o fotocopiar ese documento?

Las impresoras suelen incluir una funcionalidad llamada impresión privada, que permite proteger con un PIN la impresión del documento. Éste queda en cola hasta que el usuario, después de enviar el documento a imprimir, introduce su PIN de seguridad en la impresora para que ésta imprima el documento.

Vulnerabilidades

La impresora ejecuta una serie de servicios que se publican en unos puertos, por ejemplo para su administración. Hoy en día es bastante habitual que las impresoras puedan ser gestionadas vía Web, por lo tanto disponen de su propio servidor Web que permite esta administración.

El software que gestiona dicho servicio puede estar afectado por algún tipo de error que pueda dar lugar a una vulnerabilidad que podría ser aprovechada por un posible atacante y explotada para, por ejemplo, provocar una denegación del servicio.

Modificación de firmware

Las impresoras para mejorar sus funcionalidades o corregir posibles errores de sus software, permite la actualización de su firmware. Este firmware normalmente está disponible en la Web del fabricante. Un posible ataque podría ser la alteración de este firmware para tomar el control de la impresora de forma remota, capturar tráfico o para lanzar ataques a otros dispositivos de la red.

Robo de información

Ya existen muchas impresoras que incluyen un disco duro para el almacenamiento de información, como pueden ser trabajos, históricos de impresiones, documentos escaneados, etc. Al final ese disco duro podría ser extraído de la impresora, y si no hay un cifrado en la información de éste, se podría consultar sin ningún problema información sensible de los trabajos realizados en la impresora.

Indexación de impresoras en Internet

Muchas impresoras, por razones extrañas, son publicadas directamente en Internet. Esta publicación da lugar a que motores de indexación de dispositivos como Shodan acaben añadiendo a su base de datos información de la impresora como puede ser su banner del servidor Web, dirección IP pública, servicios publicados, localización… Si además, la administración Web no ha sido protegida de forma adecuada, se podría dar el caso de que algún atacante tuviera fácilmente acceso a ella.

Instalación de aplicaciones maliciosas

Por último, y no menos importante, es la mención a la posibilidad de instalar aplicaciones en las impresoras. Aplicaciones que pueden ser potencialmente peligrosas y pueden ser usadas de forma maliciosa para controlar la impresora con fines fraudulentos, como puede ser la captura de tráfico de la red o acceder a trabajos de ésta. Se han dado casos muy curiosos como la instalación del juego Doom en una impresora. Otro vector de ataque a tener muy en cuenta.

Conclusión

Con los posibles vectores de ataque que acabamos de comentar, creemos que son lo suficientemente relevantes para que a dispositivos como impresoras le demos la importancia que realmente tienen, y se apliquen una serie de políticas de seguridad para mitigar o reducir los posibles riesgos que estos vectores puedan suponer para la empresa. Resumiendo, no nos podemos olvidar de la seguridad en las impresoras.

Auditando Aplicaciones en Android

Vamos a ver algunos ejemplos de controles que se llevan a cabo en un Pentesting de Aplicaciones en Android. Lo más importante en un proceso de auditoría será el hacer uso de una metodología, de tal forma que podamos llevar a cabo una serie de pasos de manera ordenada.

Os propongo que hagamos uso de la metodología OWASP, concretamente en su apartado de OWASP Mobile Security Project podemos encontrarnos con muchos recursos: herramientas, guía de desarrollo seguro, plantilla de controles, guía de testing de Apps… Centrándonos en esta última podemos dividir nuestra auditoría en tres partes: recopilar información, análisis estático y análisis dinámico. Read more

Web Hacking : Una línea para manejarlos a todos

¿Podría darte una línea de código acceso a un sitio Web completo? ¿Qué información obtendría un atacante si consiguiera llegar al nivel más bajo de tu página Web? es decir, a tu BBDD o SSOO. Dependiendo del objetivo de la misma podría encontrar seguramente información sobre la identidad de los usuarios, transacciones bancarias, compras online, usuarios, contraseñas y mucho más.

¿Cuánto vale tu información? Debemos de establecer unos controles de seguridad mínimos a nuestro sitio Web, llevar a cabo una serie de auditorías de seguridad que garanticen el buen funcionamiento de la misma. No sólo tener en regla la política de cookies y poco más, sino os puede ocurrir como la Web con la que me encontré hace unas semanas a la hora de preparar una charla. Antes de nada os muestro un disclaimer.


Aviso Legal y Descargo de Responsabilidad

  1. El objetivo de lo mostrado a continuación tiene fines educativos para aprender a mejorar la seguridad de nuestros sitios Web.
  2. No nos hacemos responsables del mal uso que se le pueda dar a las herramientas mostradas.
  3. Toda la auditoría Web mostrada a continuación se ha llevado a cabo con permisos de sus administradores según lo acordado en documento legal.

Vamos a llevar a cabo la auditoría de un sitio Web siguiente la metodología OWASP, concretamente seguiremos la OWASP Testing Guide V4. Los diferentes puntos que abarca dicha metodología los podéis ver detalladamente en el enlace anterior. A continuación nombramos los aspectos generales a tratar.

Read more

Investigación de ataque a un WordPress

Introducción de un ataque a un WordPress

Hoy he tenido el placer de participar, por tercer año consecutivo, como ponente en la V WordPress Meetup Córdoba y al igual que en años anteriores, he disfrutado mucho, no solo durante mi charla (Investigación de ataque a un WordPress) sino durante toda la jornada, con charlas muy interesantes en dos tracks diferentes. ¡Lástima haberme perdido algunas de las charlas! Pero en dos tracks a la vez no se podía estar.

En cuanto a mi charla, se trataba de explicar un caso real de un ataque a un WordPress y dar algunos consejos prácticos y sencillos para poder hacer algunas labores de investigación en caso de sufrir un ataque.

La Web investigada había sufrido un ataque mediante el cual los atacantes habían conseguido subir una puerta trasera, en forma de una C99 Shell, aprovechando una vulnerabilidad de tipo “Remote Arbitrary File Upload” en un plugin del WordPress.

vulnerability-wordpress

Como consecuencia, el servidor comprometido pasó a formar parte de la StealRat Botnet enviando una gran cantidad de spam con contenido variado; venta de productos farmacéuticos, venta de viagra y pornografía. Este envío masivo de spam originó que el servidor entrara en listas negras de reputación IP así como en servicios de bloqueo por spam.

Read more

Fuzzing a una aplicación con zzuf

Introducción: ¿por qué fuzzing?

Cuando nos encontramos haciendo tareas de ingeniería inversa a una aplicación, una de las tareas más monótonas es la de enviar stuff (“cosas“) a un punto de entrada de la aplicación para ver cómo responde. En función de nuestro objetivo (descubrir buffer overflow, format string…), el tipo de stuff que enviemos variará, no sólo en su contenido si no también en su cantidad, sobre todo si lo que buscamos es provocar un buffer overflow. Y cuando hablamos de cantidad, lo ideal es hacer fuzzing en lugar de hacerlo con peticiones manuales.

En el caso de los desbordamientos, más que el tipo de contenido lo que se busca es la cantidad, y aquí tenemos varias opciones de enviar “cosas” a la aplicación; de forma manual, mediante ejecución de instrucciones Python / Perl desde la consola, creándonos nuestro propio script o utilizar herramientas ya desarrolladas para este tipo de tareas; fuzzers.

En este artículo veremos distintas opciones, para finalmente presentar y ver algunos ejemplos de zzuf, el fuzzer del que vamos a hablar en este post.

Escenario

Para explicar el funcionamiento de un fuzzer, y de zzuf concretamente hemos preparado el siguiente escenario; una aplicación remota vulnerable a buffer overlflow (basado en stack), accesible a través del puerto TCP/9999.

Ese puerto a la escucha es nuestro único punto de entrada. Podríamos escanear el puerto, descubrir versión del servicio y buscar si hay alguna vulnerabilidad desconocida. En caso negativo, no nos queda otra que enviar cosas al puerto y ver cómo responde la aplicación.

Fuzzing - Netcat a vulnserver

En este caso, haciendo netcat al puerto conseguimos acceso a la aplicación, donde nos indica que podemos obtener ayuda escribiendo el comando HELP.

Peticiones manuales a la aplicación

Obviamente nuestra intención es otra, es encontrar qué tipo de información tenemos que enviarle y en qué cantidad. La explotación de la vulnerabilidad de buffer overflow no entra en el contexto de este artículo, lo explicaremos más adelante en otro, pero se puede ver marcado en amarillo una serie de comandos de la aplicación. Estos comandos son los usaremos para enviar nuestro stuff e intentar provocar el BO (buffer overflow).

Fuzzing - Netcat a vulnserver

Como decíamos en la introducción al artículo, podemos hacer peticiones manuales. En la imagen anterior al comando HELP le hemos añadido una serie de caracteres, primero dígitos y a continuación acompañados de varios caracteres “A“. La respuesta de la aplicación es que ese comando no está implementado. Podríamos seguir probando con más cantidad, con otros comandos, pero como os podéis imaginar esto llega a ser bastante tedioso y monótono si lo hacemos manualmente. Read more