info@thehackerway.es
Facebook Linkedin Twitter Youtube
Accede

Mes: junio 2021

Categorías
Hacking

¿Cómo crear un informe de pentesting? Parte 2 de 2

En el post anterior que puedes leer aquí: ¿Cómo crear un informe de pentesting? Parte 1 de 2 comentaba algunas nociones básicas sobre la redacción de informes. En esta ocasión explicaré con un poco más de detalle en base a mi experiencia, qué otras cuestiones se deben tener en consideración para crear un informe profesional. Si quieres comentar algo que a lo mejor no he tenido en cuenta en estos artículos, por favor deja un comentario ya que estoy seguro que nos será útil a todos.

1. No dejes la redacción del informe para el último momento.

Nos ha pasado a todos. Cuando estamos inmersos en una auditoría tendemos a dedicar demasiado tiempo en ejecutar pruebas y analizar el objetivo. El problema de este enfoque es que si no tienes una gestión óptima del tiempo que dedicas a cada tarea, al final te encuentras con que debes redactar un informe en pocos días o en el peor de los casos, horas. Es bueno ir documentando las cosas que se van encontrando y hacerlo con cuidado. Como comentaba en el post anterior, incluye información que aporte y no «paja» para hacer un informe extenso.

2. Si es posible, pídele a un compañero o persona de confianza que lo lea antes de entregarlo.

Redactar no es fácil. Requiere práctica, dedicación, paciencia y acostumbrarse a hacerlo con frecuencia. Es posible que lo que escribes en tu cabeza «compila» pero luego cuando alguien más lo lee te das cuenta que a lo mejor no es tan claro el mensaje que intentas transmitir. Definir un estilo de redacción es una habilidad que cualquier persona dedicada al pentesting debe adquirir. No parece muy divertido comparado con detectar vulnerabilidades, ejecutar exploits o romper mecanismos de autenticación pero si a la hora de plasmar tu trabajo en un informe no lo haces bien porque no estás acostumbrado o lo que has escrito solo lo entiendes tu, el valor de ese informe será prácticamente nulo.
Por este motivo, es una buena idea que alguien más pueda apoyarte leyendo lo que escribes y de esa manera tener una segunda opinión, detectar errores o frases que posiblemente hacen que el documento sea más confuso de lo que debería.

3. Incluye elementos que faciliten la lectura. Calidad es mejor que cantidad.

Una imagen vale más que mil palabras. Incluye capturas de pantalla que ayuden a entender mejor lo que explicas pero con cuidado de no exponer información sensible o relacionada con el auditor. Por otro lado, tal como mencionaba en el post anterior un informe que incluye mucha información poco relevante o directamente inútil afecta su calidad. Por ejemplo, no hace falta describir con demasiado detalle las pruebas que se han ejecutado y han fallado o no han arrojado los resultados esperados. Eso al cliente en realidad no le interesa. Las ideas expresadas en el documento deben ser claras y concisas, no hay que dar demasiados rodeos ni tampoco incluir opiniones personales o conjeturas. Si no puedes demostrar que una vulnerabilidad existe o es explotable puedes plantearlo como algo que se debería revisar en un contexto de caja blanca, pero no puedes decir que es algo critico y centrar el informe en problemas que «crees» que existen en el sistema auditado sin aportar ninguna prueba de ello.

4. Incluye niveles de criticidad.

Cada defecto o vulnerabilidad debe contar con un nivel de criticidad o gravedad. Puedes utilizar el modelo de CVS e indicar que tan delicado es el descubrimiento en función de su dificultad de explotación, impacto técnico, impacto de negocio y posibles defensas que se pueden aplicar. Esto permitirá indicar qué cosas deben ser solucionadas cuanto antes (como el caso de una vulnerabilidad que permite RCE) y qué cosas probablemente no son tan criticas o que no representan un riesgo e impacto altos (como el caso de un XSS reflejado).

4. Buenas prácticas.

De cara a la redacción y elaboración de los contenidos del informe suelo seguir las siguientes «buenas prácticas» o al menos para mi lo son.

  1. Cuidado con las faltas de ortografía. Muchas veces son errores puntuales por escribir rápido, es conveniente revisar el documento completo un par de veces para depurar.
  2. Incluye detalles sobre las personas de contacto, horarios y medios de comunicación que se empleará.
  3. Si no se encuentra ninguna vulnerabilidad sobre un servicio desactualizado, es mejor hablar con la persona de contacto antes de incluir en el informe que se «recomienda actualizar dicho servicio». El motivo de esto es que pueden existir otros factores o motivaciones para conservar una versión antigua y no actualizar (incompatibilidades con otras aplicaciones, módulos que dependen únicamente de la versión en ejecución, etc.). Este tipo de detalles también se pueden dejar documentados en el informe para mayor claridad.
  4. Si en las recomendaciones se explica, aunque sea a grandes rasgos, cómo se pueden aplicar las contramedidas por parte del equipo técnico, esto aportará valor añadido al informe y tendrá mejor aceptación.
  5. En las capturas de pantalla es recomendable no filtrar información sensible del sistema/usuario que está haciendo las pruebas. Es mejor cambiar la variable de entorno «PS1» e incluir un texto genérico.
  6. En el informe no se suelen incluir exploits o rutinas de código extensas, las PoC se adjuntan como anexos del documento. Esto en el caso de que la PoC en cuestión haya sido creada por el pentester, si es un exploit público basta con poner un enlace donde se encuentre.
  7. Es preferible incluir enlaces y referencias a conceptos técnicos básicos que explicarlos en el documento de auditoría.
  8. Intentar que las capturas de pantalla tengan un tamaño de letra adecuado, que se puedan ver los comandos ejecutados sin forzar demasiado la vista.
  9. Las recomendaciones generales deberían declararse en formato de «checklist» para que sean fáciles de seguir y aplicar por parte de un técnico. Además, también es aconsejable incluir referencias en internet y los «how to» necesarios para aplicar las recomendaciones indicadas.
  10. En post-explotación no hace falta incluir todos y cada uno de los comandos ejecutados, solamente se incluirán aquellos que puedan ser relevantes o interesantes según el criterio del pentester
  11. Si bien es importante tomar capturas de pantalla no hay que abusar de ellas. Si el informe parece un «álbum de fotos» puede denotar una baja calidad en los trabajos realizados, aunque no haya sido así. Recuerda que normalmente el cliente valorará tu rendimiento en función del informe que entregues.
  12. Evitar en la medida de lo posible incluir opiniones personales, el informe debe ser lo más neutral y objetivo posible.
  13. Es recomendable incluir un historial de eventos con fechas relacionadas. En dicho historial se pueden incluir los siguientes elementos.
    1. Cambios de alcance (se ha incluido una nueva máquina, por ejemplo).
    2. Cambios organizativos (personas de contacto o en el equipo de pentesters).
    3. Disposición de los sistemas y cambios estructurales (cambios en IPs, rangos de red o dominios, cambios en servicios o aplicativos, etc.)
    4. Comentarios y/o sugerencias por parte del cliente o equipo durante el proceso de auditoría.
    5. Ataques que han producido condiciones de DoS.

5. Plantillas.

Finalmente, te dejo algunos enlaces a plantillas que te pueden ser útiles en la elaboración de tus informes.

PurpleSec

Pentest-hub

TCM Security

Offensive Security

TGB Security

Y por último, aunque no es una plantilla, existe una herramienta que he descubierto hace poco y funciona bastante bien, se trata de PWNDoc. Hablaré de ella en un próximo artículo.

Un saludo y Happy Hack!
Adastra.

Categorías
Hacking Services - Software

¿Cómo crear un informe de pentesting? Parte 1 de 2

Es una pregunta muy habitual entre profesionales que están empezando a trabajar en pentesting y aunque hay plantillas que se pueden encontrar fácilmente en internet y algunas herramientas los generan automáticamente, como profesional sigo ciertas normas a la hora de elaborar los documentos que debo entregar a los clientes tras finalizar los trabajos. En este post y en el siguiente hablaré sobre este tipo de detalles que es posible que te sean útiles.

 

0. Nociones básicas

La elaboración de informes es una de las cuestiones más importantes en cualquier auditoría y en ellos se debe reflejar de forma clara y concisa los descubrimientos y conclusiones a las que has llegado. Cualquier informe normalmente debe incluir como mínimo lo siguiente:

  • Portada
  • Índice
  • Control de versiones
  • Disclaimer y confidencialidad de la información
  • Personas involucradas
  • Metodologías utilizadas.
  • Contexto de la auditoría y nociones generales.
  • Pruebas realizadas, descubrimientos y pruebas de concepto.
  • Conclusiones y recomendaciones.
  • Anexos (pruebas detalladas, scripts, referencias en internet. etc).

La portada del documento suele ser genérica e incluye entre otras cosas, información sobre la empresa, fecha en la que se entrega el documento y detalles básicos.
En el índice es común incluir enlaces o accesos directos para que sea fácil moverse por las diferentes secciones del documento.
El control de versiones debe incluir como mínimo, una descripción de los cambios introducidos en cada modificación del documento con una fecha y autor.
En la introducción y contexto del documento, se describen detalles sobre la auditoría a realizar y su alcance, algo que evidentemente también se debe de encontrar reflejado en el acuerdo firmado con el cliente. Esta parte del documento pretende informar al lector sobre cuáles son las pruebas que se han realizado sin entrar en demasiados detalles, a modo de resumen ejecutivo.
Otro detalle importante que es necesario tener en cuenta en cualquier informe, es la sección correspondiente a las metodologías utilizadas, las cuales en todo caso dependerán de la auditoría a realizar. Es altamente recomendable implementar metodologías que ya han sido depuradas y tengan una buena aceptación por parte de la industria. Por ejemplo, algunas metodologías interesantes se listan a continuación, aunque evidentemente aplican en función del tipo de auditoría realizada:

El contenido propiamente dicho del documento debe de incluir las pruebas que se han realizado, explicando cada una de las etapas de la auditoría, herramientas y técnicas utilizadas, así como los resultados de cada una. Se trata de una sección en donde es importante incluir los detalles de la forma más clara y concisa, evitando redundancias y bloques de código o salidas de log demasiado extensas con el fin de favorecer la legibilidad del documento. En el caso de que sea necesario incluir dichos elementos, sería recomendable abordarlos en anexos independientes para que el lector los pueda revisar por separado. En este punto, probablemente lo más importante es que la información aporte valor. Es decir, no sirve de nada incluir cada una de las pruebas de concepto que se han ejecutado si no han producido los resultados esperados. Solo se debe incluir información relevante y de interés para el objeto de la auditoría. De nada sirve dedicar 2 o 3 páginas del informe explicando que se ha lanzado un exploit para el Apache (por poner un ejemplo) si dicho exploit no ha funcionado debido a que probablemente el servicio no es vulnerable. Incluye sólo información que aporte valor.

Finalmente, en la sección de recomendaciones viene bien incluir algunos puntos a tener en cuenta para mejorar la seguridad del sistema auditado, aunque también se pueden resaltar aquellas configuraciones y/o buenas practicas que se están llevando a cabo con el fin de que el cliente siga haciendo uso de ellas y alentar a su mantenimiento. Si se encuentran vulnerabilidades es muy importante incluir contramedidas o recomendaciones que sean útiles para mitigarlas o mecanismos de protección que ayuden a solucionar los problemas detectados. Ojo, el hecho de incluir esas contramedidas no es vinculante y no significa que seas tu quien las va a implementar. Te han contratado para ejecutar una auditoría y detectar problemas, implementar las soluciones es algo que debe valorar el cliente.

1. ¿Qué tipo de auditoría te han pedido?.

Se pueden crear diferentes tipos de informes dependiendo de las necesidades del cliente, las cuales han tenido que quedar reflejadas en el acuerdo. Es posible que la auditoría a realizar se centre en uno de los siguientes escenarios:

  • Pentesting perimetral/externo.
  • Pentesting interno.
  • Pentesting wireless

Dependiendo de cada caso hay que tener en cuenta factores adicionales que deben quedar reflejados en el documento, por ejemplo cuando un cliente pide un enfoque mixto y una parte de la auditoría será externa y otra parte interna.

2. Piensa en la persona que va a leer tu informe y trata de adaptarte.

Con todo lo anterior claro, lo primero que hay que tener en cuenta es que no todos los clientes son iguales y en algunos casos es necesario desarrollar 2 o más informes que reflejen las tareas realizadas. Es importante adaptarse y entender el público objetivo. Es decir, si la persona que va a leer el informe es personal técnico le interesará que esté orientado a describir las vulnerabilidades, defectos y recomendaciones que aporta el documento. En este caso será revisado por una persona que como mínimo, tiene unos conocimientos básicos y entenderá lo que cuentas pero si por ejemplo, ese mismo documento lo lee un directivo, responsable de área o personal no técnico, evidentemente lo más probable es que entienda poco o nada. Imagina por un instante que un experto en finanzas (por poner un ejemplo) te pasa un informe técnico de una auditoría financiera, crees que tendrás el criterio suficiente para decir si eso que te han enviado está «bien» o «mal»? probablemente pasarás de leerlo y se lo enviarás a alguien que sea experto en el tema. Dependiendo del alcance y lo que se haya hablado con el cliente es probable que tengas que elaborar un informe orientado al personal técnico y otro a «decision makers» o directivos/responsables, en cada caso el lenguaje que utilizas y el mensaje que transmites debe ser lo suficientemente claro para el lector objetivo.

3. Las plantillas o herramientas no hacen un buen informe.

Puedes usar plantillas disponibles en Internet o las que a lo mejor se encuentran disponibles en la empresa en la que trabajas, por supuesto que es algo perfectamente valido pero no deja de ser una base que te ayuda a ahorrar tiempo en definir un diseño y «maquetar» secciones. Puedes (y debes) adaptar la plantilla a la auditoría que estás realizando, no es algo estático que debes seguir a rajatabla. Si te hace falta añadir, quitar o mover secciones lo haces y ya está. Que la plantilla que utilices no se convierta en un problema, se ha creado precisamente para que puedas hacer el trabajo más rápido.

En el próximo post incluiré algunas plantillas útiles y otras cuestiones a tener en cuenta sobre el estilo y redacción del informe.

Un saludo y Happy Hack!
Adastra.

 

 

Categorías
FileSystem Hacking

15 ficheros de log interesantes en sistemas Linux

Los ficheros de log representan una buena forma de entender el funcionamiento del sistema y su comportamiento. Ya sea para labores de post-explotación, para analizar un incidente, para ver qué está pasando con alguna aplicación o simplemente para comprobar que todo funciona como se espera. Todos los sistemas operativos y servidores de uso habitual en internet cuentan con mecanismos de logging que permiten generar trazas en ficheros permanentes,  temporales, en el syslog o en el stdout del proceso. Hay muchas maneras de generar eventos en forma de log. En este post se verán 15 ficheros de log interesantes en sistemas Linux. Se trata de un artículo de nivel básico que servirá como complemento a los conocimientos fundamentales de este sistema operativo.

  1. /var/log/messages

    Dependiendo de la distribución de Linux utilizada, es posible que este fichero no se encuentre disponible en el sistema pero si lo está, en él se podrán apreciar los mensajes globales del sistema incluyendo trazas que generan algunos servicios durante el arranque, trazas que dejan los programas que se ejecutan por parte del demonio CROND, logs sobre procesos de autenticación llevados a cabo por los usuarios, etc.

  2. /var/log/syslog

    Como se mencionaba antes, el fichero «messages» ya no se encuentra disponible en algunas distribuciones recientes de Linux como es el caso de Debian y Ubuntu, sin embargo esta misma información se puede encontrar en el syslog. El estándar syslog es uno de los más conocidos en sistemas Linux y se caracteriza por centralizar todas las trazas que se producen en el sistema, incluyendo aquellas que registra el kernel. Hay que tener en cuenta que el protocolo syslog por defecto almacena los mensajes del sistema en este fichero, pero es posible administrar los logs de varias formas. Por ejemplo, se pueden enviar a un servidor syslog externo o directamente a un SIEM, se pueden enviar a un búfer en memoria o incluso, guardar los mensajes en diferentes ficheros en función de su criticidad ya que cada log generado tiene un tipo que permite saber que tan «grave» es el mensaje.

  3. /var/log/dmesg

    Cuando un sistema Linux arranca, enseña información muy variada sobre los dispositivos detectados en el sistema y los módulos del kernel que se encargan de gestionarlos. Dichos logs se generan en el fichero /var/log/dmesg pero dependiendo de la distribución es posible que este fichero no exista, en todo caso el comando «dmesg» permite acceder a estas trazas, las cuales son especialmente útiles para depurar y ver si los dispositivos que están conectados al ordenador se detectan correctamente.

  4. /var/log/auth.log

    Se trata de un fichero que almacena los eventos relacionados con mecanismos de autorización, por ejemplo cuando un usuario inicia sesión en el sistema. Suele incluir detalles sobre el mecanismo utilizado y el resultado (si la autenticación ha sido correcta o no).

  5. /var/log/daemon.log

    Incluye logs de algunos de los servicios que se ejecutan en segundo plano.

  6. /var/log/lastlog

    Contiene información sobre los usuarios que han iniciado sesión recientemente en el sistema. No obstante, no es un fichero que se pueda leer en formato ASCII, para acceder a sus contenidos se utiliza la herramienta «lastlog».

  7. /var/log/kern.log

    Este fichero almacena los logs producidos por el kernel. Si por el motivo que sea es necesario compilar el kernel para añadir características o modificar algún parámetro será util para depurar.

  8. /var/log/dpkg.log

    En sistemas basados en Debian, cuando se instala/desinstala software utilizando la herramienta DPKG, los logs generados se almacenan en este fichero lo cual puede ser útil para saber qué programas se han ido instalando con esta utilidad.

  9. /var/log/btmp

    Este fichero incluye trazas sobre los intentos de autenticación fallidos en el sistema. Del mismo modo que ocurre con el fichero «lastlog», no se puede leer como un fichero de texto plano ASCII, es necesario ejecutar la utilidad «last» la cual permitirá acceder a sus contenidos.

  10. /var/log/user.log

    Incluye información sobre los eventos producidos en las sesiones de los usuarios, dichos eventos incluyen conexiones o interfaces de red que se encuentran activas o errores que se van produciendo en el Desktop Manager que esté usando el usuario.

  11. /var/log/wtmp

    Contiene información sobre qué usuarios se encuentran autenticados y usando el sistema actualmente. Este fichero es el que utilizan las herramientas «who» y «w» para enseñar sus resultados.

  12. /var/log/boot.log

    Incluye exactamente las mismas trazas que enseña el sistema durante el proceso de arranque.

  13. /var/log/alternatives.log

    Los registros que genera el comando «update-alternatives» se quedan almacenados en este fichero y puede ser útil para efectos de depuración o ver qué cambios se han hecho sobre el software instalado.

  14. /var/log/cron

    Se trata de un fichero de logs en donde se guardan las trazas producidas por las tareas programadas ejecutadas por el demonio CROND.

  15. Directorios interesantes que pueden almacenar logs.

    Los ficheros listados anteriormente son comunes en sistemas Linux, sin embargo es bastante frecuente encontrar  servicios que generan sus propios ficheros de log en ubicaciones muy concretas y por supuesto, es recomendable revisar sus contenidos tanto para la administración del sistema como para detectar una posible intrusión. La ubicación exacta de cada directorio puede variar dependiendo de la distribución de Linux y de la forma en la que se haya instalado el programa, por ejemplo no es lo mismo instalar Apache HTTPD desde código fuente que con APT/YUM. En el primer caso los ficheros y directorios de configuración tendrán rutas más o menos estandar, pero si se ha instalado manualmente desde código fuente es posible indicar estos valores en el proceso de instalación. Dicho esto, algunos directorios que se deberían consultar ya que son habituales a la hora de almacenar logs son los siguientes:

    1. /var/log/httpd/ o /var/log/apache2
    2. /var/log/lighttpd/
    3. /var/log/mail/
    4. /var/log/samba/
    5. /var/log/mysqld.log
    6. /etc/rsyslog.d/ y  /etc/rsyslog.conf
    7. /var/log/audit/

Los ficheros log que se han enseñado aquí son probablemente los más interesantes desde el punto de vista de la seguridad en un sistema Linux, sin embargo no son los únicos. Hay bastantes secciones del sistema que incluyen trazas útiles y dependerá en gran medida del software instalado. ¿Qué ficheros de log echas en falta en este post? Escribe un comentario.

Un saludo y Happy Hack!
Adastra.

 

Categorías
Hacking

Hoy vengo a hablar de TU donación a #UNICEF – período de Marzo

Hace un poco más de un mes he publicado el informe de ventas del libro «25 Técnicas aplicadas a campañas de Red Team y Hacking» que como algunos sabéis, tiene un fin social y los beneficios son donados a UNICEF. En este post quiero publicar el resumen de ventas correspondiente al periodo de Marzo para que podáis ver la donación que se ha podido hacer entre todos gracias a las ventas acumuladas en dicho mes.

Como se puede apreciar en la tabla, nos da un total de 927,92 euros los cuales se han donado a UNICEF en cuanto he confirmado el pago de las regalías por parte de Amazon.

En este período aún no se encuentran reflejadas las ventas de los libros que me habéis pedido algunos de vosotros de forma directa, ya que harán parte de los períodos correspondientes a los meses de Abril y Mayo, así como las ventas de los libros a la tienda de la organización 8dot8 en Chile, ni tampoco está la venta que se efectuará en los próximos días a la organización de DragonJAR en Colombia. Cada mes escribiré un post con los avances, así podéis ver que entre todos es posible hacer algo bueno por las personas que más lo necesitan.
Esto lo hago no porque me sobre el dinero ni mucho menos, lo hago porque me parece lo correcto y creo que vivimos tiempos críticos que requieren acciones concretas por parte de cada uno.

Finalmente, agradecer una vez más a todos los que habéis comprado el libro y vuestros buenos comentarios, he intentado aportar, aunque sea un poco, en vuestro progreso a nivel profesional/académico y espero que os sintáis satisfechos con la compra. Aunque algunos ya lo hacéis, os agradeciera una pequeña ayuda difundiendo el libro entre vuestros contactos y aportando una reseña en Amazon, este tipo de detalles son útiles para impulsar las ventas. 🙂
Lo dicho, muchísimas gracias por vuestras aportaciones y conseguir que algunos niños y niñas en situaciones de extrema pobreza tengan algo para comer gracias al trabajo de UNICEF.

花有重开日，人无再少年。
言必信，行必果。

Un saludo y Happy Donation!
Adastra.

 

Categorías
Hacking

TheHackerWay, ganador en el «European Cybersecurity Blogger Awards 2021» en la categoría de «Best Technical Content»

Aunque algunos ya lo sabéis debido a que lo he publicado en LinkedIn, no quería dejar pasar la oportunidad de escribir un pequeño post sobre el reconocimiento que ha recibido este blog en la última edición del «European Cybersecurity Blogger Awards«. Se trata de un evento que se lleva realizado desde hace varios años y en esta ocasión ha sido online. Es la primera vez que THW aparece nominado, lo cual ya era una «pequeña victoria» y un reconocimiento al trabajo de un poco más de una década de posts completamente técnicos, con sus altos y bajos como todo en la vida, pero siempre constante. En alguna ocasión lo he comentado, pero para los que no lo sabéis este blog lo comencé a escribir con la idea de obligarme a mi mismo a documentar las cosas que iba aprendiendo para posteriormente, poder repasar. Aunque inicialmente escribía prácticamente todos los días, no pude mantener ese ritmo durante mucho tiempo ya que aunque el aprendizaje es una de mis prioridades vitales, no es la única y debía encontrar un equilibrio. Actualmente intento escribir al menos 2 posts semanalmente y los publico los días lunes y jueves, de esa manera mantengo este sitio en movimiento y puedo compartir algunas de las cosas con las que me he tenido que pegar, ya sea porque lo he tenido que investigar para una formación y/o pentest o simplemente porque era algo que me interesaba aprender.
El día 9 de Junio se celebró el evento online en el que se daba a conocer el ganador y por supuesto, estaba conectado y atento. Sin embargo, justo en ese momento me entro una llamada de un cliente que tenía que atender y tardo más de lo que esperaba, cuando volví ya estaban anunciando los ganadores de cada categoría pero en la que participaba este blog ya había sido anunciada y me lo perdí. Una pena, porque al menos me hubiese gustado agradecer a los organizadores y al jurado por el reconocimiento. Al día siguiente, gracias a mis amigos de HackPlayers me entere de los resultados y de la «buena nueva», que honestamente me ha sorprendido gratamente porque no me lo esperaba.


Los resultados se pueden ver en la web del evento pero en todo caso dejo la lista por aquí para que le echéis un vistazo a los otros blogs y podcasts que competían en cada categoría.

Desde aquí me gustaría dar mi enhorabuena a los autores de Derecho de la Red por conseguir un segundo puesto en la categoría de «Most Educational Content». Se trata de un blog estupendo (aunque estoy seguro que muchos ya lo conocéis) y que en mi opinión se merecía ganar, en todo caso seguiremos leyendo los posts que publicáis cada día, muchísimas gracias por compartir! 🙂

Esto es todo, El hecho de que se le dé este reconocimiento a un blog que no es tan conocido en otros países y que está redactado completamente en Castellano…  «Me llena de orgullo y satisfacción» xD

Seguiremos avanzando juntos.

Un saludo y Happy Hack!
Adastra.

Categorías
Hacking Networking

Interceptando Hashes NTLMv2 con Ntlm-Theft + Responder

Ya sea en ejercicios de Red Team o en tests de intrusión en entornos Active Directory, conseguir credenciales de acceso válidas es, en la mayoría de los casos, un proceso fundamental para avanzar al siguiente paso en un día de trabajo. Por ello, ntlm-theft es una de esas herramientas que puede marcar la diferencia en un test de intrusión o en un ejercicio de Red Team.

Primero de todo, imaginemos la situación. Se ha conseguido acceso a la red interna de la organización pero no se tienen credenciales de usuario válidas que permitan realizar movimientos laterales o verticales en nuestra misión de comprometer los activos, pero sí se dispone de direcciones email corporativas a las que poder efectuar ingeniería social.

Una de las muchísimas casuísticas posibles podría ser enviar un fichero malicioso, con un nombre que llame la atención del usuario y en un formato que sea usado en el día a día de la organización.

Es aquí dónde se puede jugar con Ntlm-Theft, ya que nos permite crear, de manera extremadamente sencilla, ficheros maliciosos que apunten a nuestra IP (servidor) dónde se envenenarán las peticiones y capturaremos los hashes NTLMv2 de cualquier usuario que abra dicho fichero.

Veamos un ejemplo creando un fichero .xlsx de Microsoft Office Excel:

Después de su creación, hagamos uso personal de la imaginación y añadamos algo creíble que no levante demasiadas sospechas. Acto seguido, demos por hecho que se ha conseguido enviar satisfactoriamente vía email.

El siguiente paso será levantar el servidor al que apunta el fichero malicioso. Esto se realizará con la herramienta Responder, que será el envenenador encargado de realizar el NTLMv2 Relay y capturar los hashes.

 

 

Ahora solo es cuestión de tiempo que el usuario abra el fichero e interceptemos la petición de autenticación, obteniendo el hash.

Importante hacer incapié en que se habilite la edición para que el ataque sea efectivo y se ejecute la acción que desencadena la apertura del fichero.

Una vez abierto, observaremos cómo interceptamos cada petición que realiza Windows para autenticarse, obteniendo el hash NTLMv2

Con el hash en nuestro haber, procederemos a intentar crackearlo para que, con suerte, nos hagamos con credenciales válidas que nos permitan continuar moviéndonos por la red.

Una vez crackeada, podemos comprobar si se tiene posibilidad de ejecución remota de comandos (si se tratase de usuario Administrador Local) con crackmapexec:

Después de comprobar que, efectivamente, se poseen privilegios de ejecución remota de comandos, intentemos acceder al sistema:

Como se puede observar, tenemos acceso al sistema con usuario con máximos privilegios.

LinkedIn: https://linkedin.com/in/jesus-rufo

Categorías
Explotación de Software Hacking Networking Programacion Services - Software Web Applications

Practica Desarrollo Seguro con OWASP Secure Coding Dojo.

El desarrollo seguro y todo lo relacionado con el S-SDLC es algo que se debería tener en cuenta en cualquier equipo que pretenda desarrollar aplicaciones de cualquier tipo. Se trata de un modelo que define cada una de las etapas del desarrollo de software con un enfoque especial en la seguridad y aporta las pautas necesarias para crear componentes de software resistentes a diferentes tipos de ataques. Existen múltiples metodologías que adaptan las ideas del S-SDLC y definen formas de trabajar por parte de todos los integrantes del equipo. Una de dichas metodologías, que es precisamente de las que mejor aceptación tiene entre expertos y profesionales de la ciberseguridad es Microsoft SDL.
Esta metodología define un conjunto de prácticas en cada fase del desarrollo y es especialmente interesante ya que parte de dos bases importantes:

1- El equipo debe tener formación en temas de seguridad.
2- Debe existir un plan de respuesta ante incidentes.

Esto a efectos prácticos se traduce en que antes de empezar a hacer cualquier cosa, el equipo debe tener los conocimientos mínimos sobre seguridad para minimizar los errores que se podrían introducir por desconocimiento y que se debe de contar con un plan de actuación ante cualquier «desastre». De esta manera se podrá actuar en consecuencia y no pillará a todo el mundo desprevenido sin saber exactamente qué hacer, que no sea necesario buscar soluciones improvisadas sobre la marcha.

Todo esto va de la mano con lo que se conoce como SecDevOps y cada vez más capta la atención de profesionales y empresas dedicadas al desarrollo. Por estos motivos surgen proyectos orientados a facilitar el trabajo de verificación de código o herramientas SAST/DAST que ayudan a identificar problemas existentes en componentes de software de una forma bastante efectiva y por supuesto, proyectos orientados al aprendizaje de estas cuestiones. En esta ocasión, se hablará de OWASP Secure Coding Dojo.

¿Qué es OWASP Secure Coding Dojo?

Se trata de un proyecto que recientemente ha sido donado por Trend Micro a la comunidad de OWASP y cuyo objetivo es el de proporcionar una plataforma de aprendizaje en temas de desarrollo seguro y buenas prácticas. Es una plataforma que está compuesta por dos componentes principales: Una aplicación web vulnerable por diseño y el portal donde se encuentra el código que implementa cada sección de la aplicación vulnerable con una explicación detallada. Es una plataforma de entrenamiento interesante que se basa en la lista de SANS Top 25 y se puede instalar o bien manualmente o utilizando Docker. A diferencia de otras plataformas similares como WebGoat, Secure Coding Dojo cuenta con algunas herramientas didácticas que están orientadas la detección de vulnerabilidades y posterior análisis de las contramedidas que se pueden implementar a nivel de código. Los desafíos que vienen incluidos por defecto se encuentran desarrollados en Java, por lo tanto todo el código que se enseña en cada una de las lecciones está orientado a rutinas de código que son habituales en Spring Framework o el uso de anotaciones habituales en Servlets. No obstante, aunque todo está en Java, las lecciones son perfectamente aplicables a cualquier otro lenguaje de programación ya que se trata de demostrar el impacto de ciertas prácticas de desarrollo que son peligrosas. Por otro lado, la plataforma cuenta con las herramientas necesarias para crear retos del tipo CTF que serían interesantes en competiciones orientadas al ataque y la defensa. Finalmente, tiene integraciones muy interesantes con Slack, Google y LDAP para controlar el acceso a la plataforma e implantarla como un entorno de entrenamiento para los empleados de una empresa o como se mencionaba antes, para los participantes en un CTF.

¿Cómo instalar OWASP Secure Coding Dojo?

Se puede instalar fácil y rápidamente utilizando Docker y Docker-Compose. Solamente hace falta clonar el repositorio disponible en Github y a continuación, generar una variable de entorno en donde se almacenarán los detalles de configuración de la herramienta. Finalmente, como resulta habitual, se levantan los contenedores utilizando el fichero YAML correspondiente ubicado en el proyecto.

Ahora, se debe acceder desde un navegador web al puerto 8081 en local y se podrá ver la página «home» del proyecto, en donde se explican lo que son los «Attacks», «Blocks» y «Rules». A continuación se puede crear una cuenta de usuario en el sistema. Este paso puede resultar un poco «incómodo» ya que la contraseña debe ser bastante segura (mínimo de 16 caracteres con números, letras y caracteres especiales). Una vez se cuenta con un usuario registrado en el sistema se puede proceder a trabajar con el entorno.

¿Cómo usar OWASP Secure Coding Dojo?

Como se mencionaba anteriormente, se trata de una plataforma compuesta por dos componentes: La aplicación vulnerable y la aplicación donde se explican los retos y se crean los equipos (si se quiere montar un CTF).

A la fecha de redactar este post hay 2 grupos de lecciones predefinidas y cuando se carga cualquiera de ellas, aparecen un listado de retos que incluyen una explicación detallada, el tipo de vulnerabilidad que comprende cada reto, el código vulnerable, un link que apunta a la aplicación web vulnerable y una sección para introducir la «flag» cuando se descubre y explota la vulnerabilidad. Una vez resuelto el reto se puede ver el código fuente correspondiente a la solución o contramedida que se debe aplicar para mitigar la vulnerabilidad.

Recursos disponibles en el proyecto Secure Coding Dojo

Uno de los recursos más interesantes de la plataforma son los «Code Blocks» ya que describen con un muy buen nivel de detalle, malas prácticas en desarrollo de software y las contramedidas que se pueden aplicar. Otro recurso útil se encuentra en el «Code Review 101» en el que el objetivo es medir tus conocimientos en temas de desarrollo seguro por medio de snippets de código y preguntas directas sobre dichos fragmentos. Se encuentra disponible en el siguiente enlace.

Si te interesa el desarrollo seguro y todo lo relacionado con buenas prácticas de codificación te recomiendo que estés atento a este proyecto no solo por lo interesante que es, sino porque probablemente la comunidad añadirá más lecciones y características en los próximos meses como ya ha ocurrido con otros proyectos. Esperemos que se convierta en un proyecto «FlagShip» de la comunidad OWASP.

Un saludo y Happy Hack!
Adastra.

Categorías
Hacking Services - Software Web Applications

Pentesting en tu navegador web con HackTools

En la medida en la que se realizan auditorías contra aplicaciones web o entornos de red, se hace cada vez más necesario contar con «chuletas» que se puedan consultar puntualmente de una forma fácil y rápida. Algunos comandos son muy fáciles de recordar pero otros puede que cuesten un poco más, especialmente si se dejan de usar durante algún tiempo. En el post sobre Generación automática de reverse y bind shells con Shellerator se explicaba cómo generar comandos validos para el establecimiento de reverse shells en diferentes plataformas y usando múltiples lenguajes/herramientas. Evidentemente es algo que viene muy bien para consultar rápidamente un comando de este tipo, pero hay muchas otras cosas que hay que tener apuntadas en esa lista de comandos y herramientas para recordar. En este sentido hay una extensión para Firefox que es francamente interesante y útil para labores de pentesting y que pueden ahorrar tiempo, se trata de HackTools.

Es una extensión que contiene diferentes secciones en las que aparece información útil a la hora de hacer un pentest. Una vez instalada, aparece un botón en el navegador el cual, al pinchar en él, se abre una ventana que tiene un menú lateral con las opciones disponibles en la herramienta.

Las primeras opciones del menú permiten crear Reverse Shells, muy parecido a lo que se ha explicado en el post sobre Generación automática de reverse y bind shells con Shellerator Admite la generación de comandos para generar reverse shells en múltiples formatos, solo hace falta indicar el host y el puerto.


Como se puede apreciar, también permite copiar el comando resultante en formato URL encoded, lo que resulta útil en algunos casos en los que se explota una aplicación web y es necesario «encodear» el comando.
También cuenta con varias reverse shells basadas en PHP, algunas de las cuales ya se han mencionado en este blog, concretamente en las series sobre 15 formas de generar una web shell
También se proporcionan comandos validos para generar una shell TTY una vez se compromete el objetivo, algo bastante útil ya que en ocasiones una webshell no permitirá la ejecución de ciertos comandos interactivos. Entre otros, se incluye la generación de shells TTY utilizando el clásico módulo «pty» de Python, con VI, Bash, Ruby, Nmap, Perl, etc.
En el menú también se puede ver una opción en la que es posible listar los comandos más comunes en sistemas Linux a la hora de llevar a cabo procesos de enumeración, los cuales evidentemente son vitales en post-explotación.


No solamente cuenta con comandos para Linux, la siguiente opción disponible en la herramienta enseña algunos comandos Powershell que pueden ser muy útiles para la enumeración de sistemas Windows.

Otra opción del menú, aunque menos completa que las anteriores, está relacionada con la transferencia de ficheros entre víctima y atacante. Concretamente se enseñan los mecanismos habituales utilizando Bash, Python, Netcat y SCP.
Por otro lado, de cara a explotar vulnerabilidades web típicas de SQL Injection, XSS y LFI, también cuenta con opciones en el menú en las que se incluyen los payloads más habituales para explotar este tipo de vulnerabilidades. En algunas secciones se indican comandos que permiten hacer un «bypass» de filtros que se suelen implementar en las aplicaciones web para impedir que un atacante pueda aprovecharse de estos problemas.
Las penúltimas 3 opciones del menú están relacionadas con codificación/decodificación de cadenas en formato Base64, aplicación de algunos algoritmos de hashing sobre cadenas (MD5, SHA1, SHA256, SHA512, SM3) y codificación/decodificación de cadenas en hexadecimal respectivamente.
Finalmente, la última opción del menú incluye un feed con los servicios online más habituales de exploits, Shellcodes, tutoriales y vulnerabilidades reportadas recientemente. A la fecha de redactar este post los servicios incluidos en el feed son ExploitDB, Cisco Security Advisories, CVE-Search y CXSecurity.

Si bien se trata de una extensión que no incluye nada nuevo, puede ser muy útil ya que se encuentra integrada en el navegador web y se puede consultar algún comando concreto con tan solo un par de clicks, lo que a la larga termina ahorrando tiempo. Espero que te resulte interesante y te animes a probarla. Recuerda que no solo está disponible para Firefox, sino que además se puede instalar en Chrome y Opera.

Un saludo y Happy Hack!
Adastra.

Facebook Linkedin Twitter Youtube Whatsapp Telegram Envelope

Nosotros

Servicios

Legal

No te pierdas nada