Publicaciones Etiquetadas ‘Seguridad’

Primer ForoCEH Monterrey

El  pasado jueves 8 de Agosto tuve la oportunidad de asistir al primer #ForoCEH, un evento exclusivo para profesionales de seguridad certificados en Ethical Hacking.

Pues bien, este #ForoCEH pretende reunir a los profesionales de seguridad informática para tratar temas de actualidad, sobre como día a día se van viendo los nuevos ataques, las nuevas técnicas, las nuevas herramientas, entre otras cosas, pero sobre todo armar una toda una comunidad de apoyo entre todos.

Este evento fue patrocinado por Codigoverde (twitter @codigoverde)  en el cual tuvimos 2 charlas muy amenas, la primera por parte de David Schekaiban (a.k.a @dstmx ) y la segunda por David Taboada ( a.k.a @katalink).#ForoCEH1-06

En la primera, @dstmx nos platicaba de la seguridad ofensiva y de como debemos ir viendo la seguridad en nuestras empresas. Como bien decía “No todo se soluciona con cajitas”, hoy en día el Firewall, el IPS, el antivirus, solamente forman parte de la tecnología para proteger, pero ya no son la suite completa de seguridad. Actualmente los ataques son tan sofisticados y dirigidos que ya no es necesario burlar una caja de seguridad, sino que ahora se trata de inyectar el ataque a traves las personas, los dispositivos móviles, o cualquier cosa que esté conectada a una red.

#ForoCEH1-04También nos mostraba las tendencias que se mencionaban a finales del año pasado y que se han ido cumpliendo; también nos platicaba de cuales eran las tendencias para fines de año y el 2014.

Otra cosa que nos platicó fue sobre su conferencia en #CPMX4 y las estadísticas que nos mostró de como eran engañados personas de todos los ambitos profesionales es increible. Realmente el uso de la ingeniería social funciona muy bien y no requiere de mayor esfuerzo.

 

En la segunda plática David Taboada nos platicaba sobre el IFAI y la protección de los datos personales, otro tema de mucho interés que se está viviendo en México, pues ya hemos visto en las noticias, periódicos y revistas las multas que se han aplicado por no cumplir con esta ley.

Finalmente tuvimos un par de dinámicas en las cuales nos presentamos y platicamos un poco de que es lo que hacemos, como nos ha ayudado la certificación en la vida diaria, a las empresas que valor les otorga, entre otros datos curiosos que salieron en las pláticas.

#ForoCEH1-08

En lo personal, este evento se me hizo muy interesante y me gustaría que se repitiera en varias ocasiones a lo largo del año, ya que el tener relación con personas del mismo ambito y que día a día buscamos proteger a nuestras empresas de los Hackers podría aportar mucho a esta gran comunidad.

 

 

 

Fase II: De la ejecución. De los procedimientos. Parte III.

Fallas y problemas.

Aparentemente.

Todo procedimiento se encuentra ante la constante amenaza de un fallo. Es un hecho: cualquier tarea, proceso, procedimiento, sistema o esquimal, desde el momento de su concepción, está destinado a fallar. La calidad del control que sea aplicado a un entorno es lo unico que evita que todo se vaya al carajo desde el momento mismo en que algo, cualquier cosa, es creada. Por si fuera poco, eventualmente, tendremos que reparar los fallos.

A pesar de que todos los fallos normalmente son manejables y reparables (con su debido tiempo), es imperativo llegar al fondo de las cosas, al por qué de la situación, al saber quién ejecutó el “borratodo.sh” o “eliminasystemroot.exe o por qué cuando pones un patron irregular de 14 caracteres en un campo de 15 caracteres tu página web te redirige a google con una busqueda de RTFM. De la misma frustrante manera, cualquier fallo debe ser reportado inmediatamente y debe ser sujeto a un diagnóstico. Éste debe presentarse de manera clara y detallada con el objetivo de poder establecer un procedimiento estándar de resolución de, al menos, ese problema en particular.

A continuación les presento un procedimiento que se puede utilizar para realizar un diagnóstico adecuado de un problema de un sistema informático. Estos pasos pueden ser tomados como referencia para cerrar el campo de influencia del origen de lo que se encuentra provocando el problema. Para realizar el procedimiento hemos reunido a una considerable cantidad de eminencias de la informática actual que no dudarían en descuartizar un servidor para llegar al fondo de las cosas. Fueron ellos quienes nos han inspirado a realizar un procedimiento no invasivo de un inconveniente informático presentado en un entorno heterogeneo.

Este documento será integrado a la metodología PEA tan pronto sea liberado. El documento se encuentra en constante modificación, por lo que será conveniente mantenerse al tanto de las ediciones futuras (sí: lean todos los artículos y regresen todos los dias a dar F5).

Úsenlo a discreción.

—————– sketch ———————

Manual de procedimientos no invasivos
para diagnostico de inconvenientes informáticos
de un ambiente operativo heterogeneo.

Fecha.

Cliente: Nombre y/o descripción del cliente.

Introducción general.

Descripción breve del problema, preferentemente una vez encontrando la solución. Normalmente una o dos oraciones descriptivas de lo que sucede y de qué manera sucede (qué pasa, qué lo ocasiona y cómo evoluciona).

Solución.

Se describe de manera general la forma de solucionar el inconveniente, preferentemente, a manera de redacción. En caso de que sea secuencial, asegurarse que ningún paso dependa de otro que no sea contemplado y que cada paso sea claro y aplicable por cualquier persona. En lo posible, incluir en este mismo paso la evidencia de cómo solventar el inconveniente.

Causado por.

Normalmente llamado “causa raíz”, debe incluir el entorno en el que se genera el inconveniente presentado. El por qué y cómo sucede el incidente o se genera el problema. En caso de sospechar que no se trate de la causa raíz, indicarlo de manera explícita y clara.

Descripción del caso.

Descripción detallada y extendida del caso. Mientras más detalles se obtengan, muchísimo mejor. La descripción debe presentarse a manera de redacción, preferentemente con las palabras del usuario. Se pretende hacer un borrador de las ideas proporcionadas por el cliente, para posteriormente aclararlas a manera de redacción técnica, con los equivalentes proporcionados por el mismo cliente. Se deben incluir, pero no limitarse a: Direcciones IP, nombres de usuario, medio de acceso (internet, VPN, DMZ, etc.), tipo de suscripción, descripción de suscripción, si ha comprado más recursos, si ha sido funcional alguna vez y todo lo que tenga que ver con el procedimiento del cliente o de quien ha encontrado el problema.

Síntomas.

Se debe describir de manera secuencial los síntomas que el cliente ha presenciado, además de ir agregando adicionales conforme se vayan encontrando durante la revisión. Los síntomas deben ser estrictamente tautologías.

Correcto:

1.- El servidor se encuentra sin responder pings.
2.- La suscripción se quedó a la mitad del aprovisionamiento después de ejecutar la tarea.
3.- El equipo se encuentra desconectado de la red.
4.- Es imposible agregar un registro DNS debido a que se recibe un error.
5.- Es imposible completar el procedimiento de manera adecuada.

Incorrecto:

1.- No se puede conectar al servidor.
2.- Las tareas no se completan.
3.- El equipo no está conectado a la red.
4.- No se puede agregar un registro DNS. Marca error.
5.- El procedimiento no se puede completar bien.

Antecedentes del cliente.

Los antecedentes deben incluir, de manera indizada, los eventos descritos por el cliente. De la misma manera, deben ser secuenciales y se deben ir agregando registros conforme vayan siendo encontrados, preferentemente de manera cronológica desde la creación de la suscripción o de haber encontrado el inconveniente. Es indiferente si los antecedentes son descritos mediante tautologías o mediante oraciones estructuradas, siempre y cuando definan un estado en la existencia de la suscripción del cliente.

Datos recabados.

Todo lo relacionado con el procedimiento de verificación. Es imperativo complementar cualquier dato encontrado, indistintamente de si se trata de algo esperado o de un error propiamente hablando. La documentación debe ser de manera secuencial basada en los componentes de un servicio cualquiera y debe generarse en el siguiente orden: Hardware, Software, Redes, Aplicación y Usuario. Los datos a recabar deben incluir el inicio y el fin de la existencia de la suscripción reportada así como los datos de los lapsos en que se hayan mencionado inconvenientes.

Hardware:

Rendimiento CPU.
Rendimiento RAM.
Rendimiento Disco.
Rendimiento Red.
Modificaciones a la configuración del equipo.
Límites de dispositivos físicos.

Redes:

Carga de los dispositivos de interconectividad.
Rutas estáticas.
Consumo de ancho de banda y si existen límites.
Disponibilidad de la red (ping).
Alcance de la red (traceroute).
Modificación a componentes del equipo (adición / remoción de interfaces de red).
Modificación a componentes del sistema operativo (Adición / remoción de rutas estáticas, entradas ARP).
Modificación a componentes de la aplicación (Rutas, direcciones IP, usuarios y contraseñas inmersos en el código).
Límites de recursos de los componentes físicos y lógicos.

Software de bajo nivel (Sistema operativo):

Registro de Eventos / mensajes del sistema.
Tiempo de ejecución continua.
Cantidad de IOPS (en caso de ser disponible).
Necesidad / demanda de Interfaces de Red.
Modificaciones a la configuración del sistema operativo.
Límites de dispositivos lógicos / recursos asignados.

Software de medio / alto nivel (Aplicación):

Requisitos de la aplicación.
Límites de la aplicación.
Datos inmersos en el código.
Validación de errores por parte de la aplicación.
Registro de eventos.
Validación de rendimiento.
Validación de procedimiento de aseguramiento de calidad del desarrollador.
Validación de compatibilidad de la arquitectura de la aplicación con la arquitectura de su entorno.

Usuario final:

Forma de utilizar la aplicación.
Documentación previa.
Experiencia previa.
Tiempo de uso de la aplicación.
De qué manera aprendió a utilizar la aplicación.
Si el usuario es sysadmin.
Si el usuario cuenta con conocimientos avanzados de su aplicación.
Si se han presentado errores adicionales durante el uso de la aplicación.
Si los inconvenientes han sido solventados de fondo.
Si cuenta con procedimientos extraoficiales para mantener el funcionamiento de su aplicación.

Todos los datos deben ser recabados aun cuando la relación que muestren con el inconveniente presentado pueda ser difusa o ligera. Solo se deberán eliminar una vez que se haya descartado completamente de manera práctica que carecen de relación con el problema reportado. Normalmente esto se puede definir como “lluvia de ideas”.

Es posible iniciar de manera inversa, es decir, se puede comenzar diagnosticando el inconveniente a nivel usuario y bajar hasta llegar a los componentes del equipo.

Veredicto (y recomendaciones).

Descripción extendida de las causas del inconveniente generado. Recomendaciones para evitar que este inconveniente se presente nuevamente, en caso de que las mismas existan.

Referencias.

Todo aquel documento que sustente las recomendaciones del veredicto y las recomendaciones realizadas sobre el problema. Normalmente incluidas en forma de URL, pueden ser fuentes diversas oficiales o extraoficiales, siempre que solventen el inconveniente. Las fuentes pueden ser: blogs, bases de conocimiento, artículos sin sabor, manuales técnicos, pruebas de rendimiento, etc.

—————– sketch ———————

Referente a la Metodología PEA.

[Howto] Crear certificado de seguridad autofirmado

Hola lectores!

La semana pasada me llegó un requerimiento para generar un archivo CSR (Certificate Signing Request) para la creación de un certificado de seguridad, y pues bien, hoy me doy a la tarea de explicar paso por paso la creación del mismo incluyendo las llaves y todo lo que se tiene que generar.

¿Para qué nos sirve un certificado de seguridad?

Los certificados de seguridad son una medida de confianza adicional para las personas que visitan y hacen transacciones en su página web, le permite cifrar los datos entre el ordenador del cliente y el servidor que representa a la página. El significado más preciso de un certificado de seguridad es que con él logramos que los datos personales sean encriptados y así imposibilitar que sean interceptados por otro usuario. Ahora es muy común ver en nuestros exploradores el protocolo de seguridad https; mediante éste, básicamente nos dice que la información que se envía a través de Internet, entre el navegador del cliente y el servidor donde está alojada la página, se encripta de forma que es casi imposible que otra persona reciba, vea o modifique los datos confidenciales del cliente.

En el mundo de Internet, toda comunicación cifrada el certificado debe ser firmado por una Entidad Certificadora Autorizada (CA) que nos garantiza que el servidor donde está alojada la página es quien dice ser. En algunas ocasiones, es necesario crear certificados auto-firmados para realizar pruebas o para montar servidores internos.

Con un servidor Unix/Linux y con el programa OpenSSL es muy fácil y rápido crear este tipo de certificados.

Pues bien, ahora que ya leímos algo de teoría pasemos a la creación del certificado:

  1. Generar la llave privada.Una de las tantas bondades de OpenSSL es el poder generar una llave RSA privada y un archivo CSR, pero también nos sirve para crear los certificados autofirmados que por lo regular son utilizados para uso interno o para realizar pruebas.
    El primer paso es crear la llave privada RSA. Esta clave es de 1024 bits que se cifra utilizando 3-DES y se almacena en formato PEM para poder ser leído en formato ASCII.

    openssl genrsa -des3 -out server.key 1024



  2. Generar un CSR.
    Ahora que tenemos creada la clave privada procedemos a generar un archivo CSR (Solicitud de firma de certificado, por sus siglas en inglés).  Este archivo tiene 2 utilidades, la primera, enviarlo a una entidad certificadora como Verisign o Thawte, quienes validarán la identidad del solicitante y generarán un certificado firmado; y la segunda, es la de auto firmar el CSR, que es lo que explicaremos más adelante.
    Durante la generación del archivo CSR, se solicitarán ciertos datos informativos que serán los atributos X.509 del certificado.
    Uno de los campos que se solicitan el es “Common Name”, en este campo es muy importante poner el nombre del dominio del servidor que va a ser protegido por SSL. Como ejemplo, si el sitio va a ser https://secure.csimx.net, en el campo se pondría secure.csimx.net.
    El siguiente comando muestra como generar el archivo CSR

    openssl req -new -key server.key -out server.csr

  3. Borrar la contraseña de la clave.
    Un desafortunado efecto secundario de la transmisión de una clave privada con contraseña (passphrase) es que Apache o el servidor web en cuestión te pedirá la frase cada vez que se inicie el servidor web. Esto no siempre es conveniente, sobretodo si el servidor se reinicia automáticamente. Las propiedades mod_ssl  de Apache incluye la capacidad de utilizar un programa externo en lugar de escribir la frase a mano, sin embargo, esto no es necesariamente la opción más segura. Es posible eliminar el cifrado 3-DES de la clave para que no sea necesario escribir una clave. Eso sí, si la clave privada ha dejado de estar cifradas, ¡es fundamental que este archivo sólo pueda ser leído por el usuario root!. Si un tercero obtuviera la clave privada sin cifrar, el certificado correspondiente deberá ser revocado. Para quitar la frase de paso de la clave, utiliza el siguiente comando:

    cp server.key server.key.org
    openssl rsa -in server.key.org -out server.key

     

  4. Crear el certificado autofirmado.
    Si todo lo anterior se llevó a cabo, en este punto podemos crear el certificado autofirmado. Este certificado marcará error en el navegador del cliente ya que la entidad certificadora es desconocida y no confiable.El siguiente comando muestra como generar el certificado con una validez de 1 año.

    openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

  5. Instalar la clave privada y el certificado en el Apache.
    Cuando se instala Apache con mod_ssl, se crean diversos subdirectorios de configuración dependiendo donde y como se configuró e instaló apache.

    cp server.crt /usr/local/apache/conf/ssl.crt
    cp server.key /usr/local/apache/conf/ssl.key

  6. Configurar los Virtual Hostscon SSL.

    SSLEngine on
    SSLCertificateFile /etc/apache2/conf.d/ssl.crt/server.crt
    SSLCertificateKeyFile /etc/apache2/conf.d/ssl.key/server.key
    SetEnvIf User-Agent “.*MSIE.*” nokeepalive ssl-unclean-shutdown
    CustomLog logs/ssl_request_log \
    “%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \”%r\” %b”

  7. Reiniciar apache.

    service apache2 restart

  8. Probar.

    https://secure.csimx.net

 

 

Visto en www.hackplayers.com

Conceptos de Seguridad que debes conocer

Alguna vez haz escuchado cosas raras como ¿Agujero de Seguridad? o ¿Malware? o ¿Análisis de Vulnerabilidades? ¿PenTest? etc??

Bueno, vamos a presentar unos cuantos conceptos que siempre debes tener en la mente:

  1. ¿Qué es un análisis de vulnerabilidades?
    Un análisis de vulnerabilidades es un estudio en busca de debilidades que se realiza a una infraestructura y/o aplicación de manera controlada y con pleno concentimiento del cliente.
    El objetivo principal es asegurar que no está expuesta a un atacante y así poder mantener la disponibilidad, confidencialidad e integridad de la información.
  2. ¿Qué es Malware?
    Es un software malicioso que su objetivo es dañar y/o infiltrarse en equipos computacionales sin el concentimiento de su propietario.
  3. Qué es un agujero de seguridad?
    Es una debilidad en un sistema que puede ser aprovechado por un atacante para violar la seguridad del mismo.
  4. ¿Qué es un troyano?
    Es un tipo de malware que se presenta al usuario como un programa legítimo pero que al ejecutarlo causa daños en los equipos y sistemas. En la mayoría de los casos abre puertas traseras permitiendo a un atacante manipular y tomar control del equipo.
  5. ¿Qué es un certificado de seguridad?
    Es un tipo de seguridad que brinda confianza al usuario cuando realiza transacciones por internet, normalmente económicas o con información sensible. Está diseñado para cifrar toda la información que pasa ente el cliente y el servidor y que no sean interceptados por algún otro usuario. Podemos identificar este tipo de servicio en nuestro navegador cuando la barra de navegacion tiene https:// como son los bancos, Facebook, gmail, entre otras páginas.
  6. ¿Qué es una auditoría de seguridad?
    Es un estudio realizado por profesionales de seguridad informática que pretende el análisis de sistemas para evaluar, identificar, enumerar y describir las diferentes vulnerabilidades que pudieran presentarse en una revisión de servidores, redes y equipos de computo.
  7. ¿Qué son las APT – Advanced Persistent Threat (Amenaza Avanzada Persistente)?
    Son un tipo de malware que se encargan de atacar principalmente entornos corporativos o políticos. La principal característica y por lo que sobresale, es por su alta capacidad de esconderse/ocultarse, por lo que es muy difícil deshacerse de ellas.
  8. ¿Qué es una prueba de Penetración?
    Es una evaluación activa de las medidas de seguridad de la información. El objetivo del PenTest es detectar puntos débiles que pueden ser utilizados por un atacante para violar la seguridad de los sistemas. Durante el PenTest se busca explotar las debilidades simulando ser un atacante para obtener información relevante pero SIN DAÑAR la información, sistemas e infraestructura.

Gracias por leernos, espero dejarles un poco más claro estos conceptos y que les sean de utilidad más adelante.

 

Saludos! }x)

[Distro] Security Onion IPS / IDS

Hola a Tod@s!

¿Alguna vez les han pedido o han tenido la necesidad de analizar el tráfico que pasa por su red?

Existe una gran gama de herramientas para sniffear o capturar paquetes para analizarlos y saber que pasa con ellos.

Pero, ¿Qué pasa cuando estamos sufriendo un ataque que no sabemos de donde procede ni que contienen los paquetes que nos envían?

Para eso, contamos con esta herramienta llamada Security Onion, un IPS open source basado en Xubuntu que trae preinstaladas herramientas para la captura y el análisis de tráfico.

Security Onion es una distribución diseñada especialmente para detectar intrusiones y tener un monitoreo de seguridad de la red. Tiene ya instaladas herramientas como Snort, Suricata, Sguil, Squert, Snorby, Bro, NetworkMiner, Xplico, entre otras más.

Y ¿Cómo se usa?

Su uso es muy sencillo, simplemente se ejecuta el asistente que permite construir reglas de sensores distribuidos para tu empresa en un par de minutos.

Comparto algunas pantallas de como se ve el tráfico y de algunas de las herramientas.

Escritorio y Accesos directos

Desktop

Snorby Login

Snorby

 

Snorby Overview

Snorby2

Snorby Detail

Snorby3

Squert OverviewSquert2

Espero que esta herramienta les sea de utilidad.

Gracias por leernos y no olviden dejar sus comentarios.

 

 

Escritorio Limpio

Hola a Tod@s

¿Cuantas veces nos hemos topado en las empresas con la política tan molesta del famoso Escritorio Limpio?

Vamos a hablar un poco de esto, y el porque es tan importante tener en orden nuestro escritorio, y la existencia de esta política.

Observen detalladamente la siguiente imagen, ¿qué es lo que se puede observar?

 Clean-Desk

La mayoría de los escritorios contienen documentos con información sensible y/o confidencial que no debería ser vista o que no caiga en manos equivocadas. Como bien podemos observar, se encuentra la pantalla desbloqueada, la agenda abierta, el iPhone celular sobre la agenda, una carpeta con algo subrayado, post-its pegados en el monitor y un porta papeles.

Teniendo un poco de cuidado y unos buenos hábitos podemos cuidar este pequeño aspecto de fuga de información.

A continuación expondré algunos de los errores de seguridad que se comenten muy a menudo.

1. Computadora desbloqueada.

unlock computer

Cuando te levantas de tu escritorio, ¿Bloqueas tu equipo de cómputo?

Como se puede ver en la imagen, un empleado dejó su equipo desbloqueado con su correo abierto y con correos de hardcode, códigos, etc.

 

2. Postit con información sensible, comúnmente passwords.

Password-PostIt

Otro error muy común es dejar postit pegados en los monitores con los passwords, ya que como muchos sabemos, las molestas políticas piden que tengamos un password diferente para cada servicio, y como nuestras mentes son unas inútiles están todo el día ocupadas en nuestras labores, no podemos memorizar todos los passwords. Y que mejor que para no olvidarlos, dejarlos ahí a la vista de todos, brindando a los “hackers” accesos no autorizados.

 

3. Documentos Confidenciales.

4229866-confidential-documents-with-a-sealed-envelope-concept

¿Cuantas veces vamos al lugar de nuestro jefe y lo primero que vemos es sobre su escritorio documentos que dicen confidencial, o secreto? ¿Cuantas veces se levanta él de su lugar, deja abierta su oficina y los papeles encima?

 

4. Documentos olvidados en las impresoras.

Retractable_printer_3

¿Cuantas veces mandamos imprimir documentos y se nos olvida pasar por ellos a la impresora?

En este ejemplo, un empleado mandó imprimir los mapas y prototipos con todas sus características del diseño el auto que van a lanzar al mercado.

 

5. Documentos en el bote de basura sin triturar.

RecycleBin_Paper

Papeles de información confidencial directos en el bote de basura. Podemos apreciar que se encuentran estados de resultados financieros en el bote de basura, que no están triturados ni rotos.

 

6. Teléfonos móviles sobre el escritorio.

timebridge-iphone-app

El teléfono móvil se quedó sobre el escritorio encendido con la agenda abierta, donde muestra el tema de la reunión, los participantes, el lugar y la hora.

 

7. Llaves.

lead_keys-420x0

Estas llaves pueden abrir puertas de los datacenter, archiveros con información importante, o algún otro lugar donde se encuentren documentos o algún medio de almacenamiento de información como discos duros, cintas de respaldo, entre otros.

 

8. Tarjetas de acceso.

Identification_Access_Card_by_LordDavid04

El dejar olvidada la tarjeta de acceso sobre tu escritorio puede ocasionar que personas no autorizadas tengan acceso a las instalaciones en horario fuera de oficina, o acceso no autorizado a lugares restringidos a los cuales solo tu y algunas otras personas pueden acceder.

 

9. Pizarrones con información escrita.

whiteboard3

Los pizarrones deben ser usados para llevar a cabo las juntas y reuniones, y al finalizar estas, deben ser borrados. Este pizarrón muestra algunos nombres de responsables y algunos códigos que pueden ser de acceso, o algún password o token.

 

Y tú, ¿Cumples con la política de seguridad?

Saludos!

TheHarvester: Recopilando Informacion

Hola a todos,

En esta entrada quiero hablar un poco sobre la recopilación de información.

Para que nos sirve empezar a juntar información de nuestro objetivo? Es una respuesta sencilla, al realizar un reconocimiento de nuestra víctima nuestro objetivo empezamos a conocer que servidor es, que servicios tiene ejecutando, que versiones tiene instaladas, etc. pero con esta entrada lo más importante es conocer un poco mas allá de la infraestructura, es por eso que quiero adentrarme un poco en la herramienta TheHarvester.

Como ya les comentaba el primer paso de un pentest o prueba de penetración es recopilar información sobre nuestro objetivo servicio o servidor a evaluar.

Existen diversas herramientas que nos ayudan a reconocer un servidor, pero en esta ocasión les vengo a hablar de una herramienta bastante útil y que nos facilita esta tarea, pues la información que recopila viene desde subdominios, nombres de usuario, nombres de hosts, hasta cuentas de correo electrónico.

TheHarvester es una herramienta desarrollada en python que se encuentra ya instalada en Backtrack bajo el directorio /pentest/enumeration/theharvesterPara ejecutarla simplemente nos dirigimos al directorio ya mencionado y ejecutamos el siguiente comando:

python theharvester.py

Con este sencillo comando nos muestra la ayuda y algunos ejemplos de las diferentes opciones con las que cuenta.

Algunos de los ejemplos son los siguientes:

./theharvester.py -d microsoft.com -l 500 -b google

./theharvester.py -d microsoft.com -b pgp

./theharvester.py -d microsoft -l 200 -b linkedin

Para este ejemplo usaré el dominio alestra.com.mx

theharvester

Como se puede apreciar en la imagen anterior, la herramienta muestra cierta información que puede ser considerada como sensible, que, buscando un poco mas por Internet podría ir realizando un diagrama con los nombres, puestos, teléfonos, etc de las direcciones de correo electrónico encontradas.

En la siguiente imagen se puede apreciar que el correo pertenece  Sergio Prado y el número telefónico

theharvester2

Espero que les sea de ayuda esta breve introducción a la herramienta.

Como siempre, muchas gracias por leernos y no olviden dejar sus comentarios.

[Distro] BackBox una distribución para hackers

BackBox es una distribución basada en Debian creada especialmente para Hackers Profesionales de Seguridad. Esta distribución de Linux cuenta con herramientas suficientes para una perfecta solución de seguridad.

BackBox cuenta con módulos de Pen-Testing, Respuesta a incidentes, Cómputo Forense, y herramientas para la recolección de información.

La versión 3 de BackBox, que es la  más reciente,  incluye las últimas actualizaciones de software para el análisis de vulnerabilidades y pruebas de penetración. Es una de las versiones mas ligeras y rápidas de Linux en materia de seguridad.

BackBox ayuda a simplificar lo complejo de la seguridad, tiene facilidad de administrar y evaluar la seguridad de una organización de una manera muy sencilla, ya que con pocos recursos y el mínimo del tiempo se puede probar los agujeros de seguridad en la red.

Por ser una herramienta de código abierto, es muy sencillo agregar y/o modificar las herramientas y scripts ya instaladas, incluso puedes desarrollar e integrar herramientas hechas por ti o por algún tercero, para complementar tu distribución.

Puedes descargar la última versión de la herramienta desde su página oficial en formato iso o en torrent para equipos de 32 bits, o si tienes un equipo de 64 puedes decargarla de estos enlaces iso o torrent.

Pronto les pondré una guía de instalación 😀

 

Y como siempre, gracias por leernos y no dejen de recomendarnos.

Detecta Firewall de Aplicación con waffit

Hola a tod@s,

En esta ocasión les vengo a platicar de una herramienta que nos permite identificar si un sitio se encuentra detrás de algún firewall de aplicación. Como bien el título de la entrada lo dice, la herramienta se llama waffit.

Waffit también conocida como Wafw00f (Web Application Firewall Detection Tool) es un script desarrollado en python que permite identificar y realizar un reconocimiento de sitios web que se encuentran protegidos por Firewalls de Aplicación ó WAF (Web Application Firewall, por sus siglas en inglés)

El proyecto a pesar de ser funcional se encuentra en fase de desarrollo y se puede acceder a su google code desde aquí.

Así mismo se encuentra ya instalado en el sistema BackTrack r3.

La manera de ejecutar el script es muy simple, desde backtrack solo hay que dirigirse al directorio /pentest/web/waffit y dentro de este directorio se ejecuta el siguiente comando:

./waffw00f.py <url>

Y nos regresa el fabricante del Firewall de Aplicación.

Adicional trae diferentes opciones por si queremos hacer un escaneo mas detallado:

-h, –help                                                Show this help message and exit
-v, –verbose                                        Enable verbosity – multiple -v options increase verbosity
-a, –findall                                            Find all WAFs, do not stop testing on the first one
-r, –disableredirect                          Do not follow redirections given by 3xx responses
-t TEST, –test=TEST                         Test for one specific WAF
-l, –list                                                    List all WAFs that we are able to detect
–xmlrpc                                                 Switch on the XML-RPC interface instead of CUI
–xmlrpcport=XMLRPCPORT        Specify an alternative port to listen on, default 8001
-V, –version                                         Print out the version

 

La herramienta detecta gran cantidad de fabricantes de WAF como se puede observar:

Can test for these WAFs:

Profense
NetContinuum
Barracuda
HyperGuard
BinarySec
Teros
F5 Trafficshield
F5 ASM
Airlock
Citrix NetScaler
ModSecurity
DenyALL
dotDefender
webApp.secure
BIG-IP
URLScan
WebKnight
SecureIIS
Imperva

 

Espero que les sea de utilidad esta herramienta.

Muchas gracias por leernos y no dejen de recomendarnos.

Saludos!

Falsa ley de privacidad UCC-1-308-1-103 en Facebook

Últimamente se ha estado observando en los muros de facebook un texto que se hace pasar por una ley donde mencionan que queda prohibido el uso de la información personal escrita en los muros y perfiles de esta famosa red social.

Analizando un poco más a detalle la ley  el texto  UCC-1-308-1-103 y buscando un poco en Internet sobre ella podemos ver que NO APLICA para proteger datos personales, fotografías, etc. Las leyes UCC o Uniform Commercial Code (por sus siglas en inglés) son para el derecho mercantil y no son de derecho de autor y/o privacidad.

Esto no deja de ser más que una  estúpida cadena que se propaga por las redes sociales sin ningún fin, sin que nadie gane nada, sin que nadie se muera.

Al momento en que se registraron en Facebook, ustedes cedieron todos sus derechos a la empresa cuando aceptaron los términos y condiciones de la red social, así que el estar copiando y pegando una “Ley de privacidad en los muros” no sirve de nada.

A continuación les dejo una imagen de lo que dice la famosa “Ley de privacidad”

No sigan replicando este tipo de cosas en sus muros, todo es inútil.

Espero dejen sus comentarios para conocer las ideas, sugerencias, formas de pensar de cada uno de ustedes.

Volver a arriba
 

Powered by FeedBurner

Enter your email address:

Delivered by FeedBurner