jueves, 21 de mayo de 2015

cursos libres de seguridad informatica

El material parece que es de hace 2 ó 3 años, pero los conceptos son válidos todavía.
Copio y pego el índice por interesa.
General Knowledge – Start here. This knowledge will help you better understand how to go about learning the rest of the courses.
1.1 Purpose
1.2 Hacking
1.3 Programming
1.4 Networking Basics
Password Hacking – All types of password hacking attacks.
Modules
0. Introduction
1. Passwords
2. Password Cracking
3. Password Hash
4. Online vs. Offline
5. Attack Types
a. Dictionary
b. Bruteforce
c. Hybrid
d. Rainbow Tables
e. Salts
6. Alternative
7. Speed
8. Secure Passwords
Examples
1. Hash Types
2. Cracking Windows Passwords
3. Create Rainbow Tables
4. Database Dump
5. Web Form
6. Distributed Cracking
Network Hacking – Learn how to hack networks by going through the five phases starting with Reconnaissance.
1. Reconnaissance
DNS (Domain Name System)
Network Reconnaissance
DNS Cache Snooping
2. Network Scanning
3. Network Mapping
4. Metasploit
Metasploit Intro
Metasploit Basics
Reconnaissance Scanning
Vulnerability Scanners Part 1
Vulnerability Scanners Part 2
Vulnerability Scanners Part 3
5. Nessus
6. ARP Spoofing
Intro to ARP Spoofing
ARP Spoofing Examples
ARP Spoofing with DSNIFF
Web Hacking – Learn about all the different types of attacks against web applications, the most popular form of hacking today.
0. Web Hacking
1. Phishing
Tabnabbing
Tabnabbing Examples
2. Cross Site Scripting (XSS)
Reflected Cross Site Scripting (XSS)
Session Hijacking
Session Hijacking Examples
Stored Cross Site Scripting (XSS)
3. Cross Site Request Forgery (CSRF)
4. SQL Injection
SQL Injection Intro
Mysql Intro
Mysql Injection
Information Schema
5. Clickjacking
Facebook Hacking Course
1. Introduction
2. Phishing
What is phishing?
Creating The Phishing Page
Uploading Files
Uploading Situation
3. Social Engineering
What is Social Engineering?
Telephone Example
Telephone Example Analysis
Email
Spoofing
4. Malware
Introduction
Creating a Keylogger
Binding
Crypting
Keylogger Infecting
Trojans
Trojan Infecting
Spreading
5. Anonymizing
Anonymous Signup
Link Shortener
More Techniques
More Techniques Part 2

Packet Sender algo mas que TCP

Cuando trabajas en redes, desarrollas alguna aplicación cliente/servidor, cuando quieres probar la seguridad de algún servicio mandándole paquetes mal formados, pruebas de estrés, etc, tener las herramientas adecuadas te harán la vida mucho más fácil.

Quizás para los distintos escenarios que he enumerado anterioremente haya herramientas especializadas en cada caso, pero en esta entrada quería comentar Packet Sender.

Packet Sender es una utilidad multiplataforma (Windows, Mac y Linux) que nos permite la definición y el envío de paquetes TCP y UDP. Ésta nos permite definir la dirección IP destino, el puerto, el tipo (TCP o UDP) y el contenido del paquete en sí.
También nos ofrece la posibilidad de crear conexiones TCP persistente (envío de paquetes usando la misma conexión), podemos guardar los paquetes que hemos creado, incluso el tráfico generado. Además lleva integrado un servidor UDP y otro TCP, con el podemos hacer nuestras pruebas.

La aplicación es muy simple, pero muy juguetona. Además podemos interactuar con ella desde la línea de comandos pasándole los parámetros que queramos o si no le pasamos ningún parámetro en la llamada, nos ofrece una interfaz gráfica que nos lo pone todo mucho más fácil.

Como decía antes hay versiones para Windows, Mac OS X y Linux.

La aplicación es Open Source y su código fuente está disponible en Github.

También existe una versión de esta utilidad para Android y iOS, pero ambos proyectos han sido abandonados en detrimento de la versión de escritorio.

A mi personalmente siempre me ha encantado netcat y también ipsend, desde mi punto de vista son mucho más potentes, pero quizás menos amigables.

AIMSICD un proyecto con futuro

Antes de hablar de AIMSICD y StingRays, tenemos que hablar de IMSI-Catcher.

IMSI (International Mobile Subscriber Identity) Catcher es una tecnología de escucha o monitorización del tráfico generado por teléfonos móviles. Es básicamente una torre false de telefonía móvil que se sitúa entre un teléfono y una torre legítima. Lo que se conoce como un man in the middle.

Este tipo de dispositivos es conocido que los usan las fuerzas del orden y agencias de inteligencia en los EEUU, aunque parece que también se usan afuera de las fronteras del país estadounidense.

StingRay es el nombre de un IMSI-Catcher creado por la empresa Harris Corporation, inicialmente para las fuerzas armadas y agencias de inteligencia. Dicho producto fue tan conocido que es StingRay el nombre con el que se referencia a cualquier dispositivo IMSI-Catcher.

Aunque en la definición de IMSI-Catcher hablamos de torre de telefonía, los StingRays pueden llegar a ser bastante pequeños. De hecho, se suelen instalar en coches, aviones o incluso llevar en la mano.

Las fuerzas del orden los suelen usar en protestas o mifestaciones, para no sólo monitorizar el posible tráfico, sino que también podrán saber quién estuvo presente (si vas a una manifestación no te lleves el móvil).

Aquí tienes una lista de charlas/cobertura en las que se ha tocado este tema:
YouTube: StingRay Warrantless Wiretap
DEF CON 18 – Practical Cellphone Spying
StingRays: Biggest Technological Threat
NSA-Killings with IMSI-Catcher drones
Meet the machines that steal your data
Espionage on Norwegian Politicians
Secret U.S. Spy Program on Planes
IMSI-Catcher Live Demonstration
28c3: Defending mobile phones
How easy it is to clone phones

Ahora que ya sabemos que son los StingRays, hablemos de AIMSICD.

AIMSICD (Android IMSI-Catcher Detector), es un proyecto que está orientado en la detección de StingRays y como su nombre índica, es para sistemas Android.

Esta aplicación NO evita que puedas ser interceptado, lo que hace es que te avisa si detecta que tu teléfono se ha conectado a un StingRay.

Los métodos de detección que usa son:
Consistencia de la información de la torre
Previene la instalación silenciosa de aplicaciones
Chequea cambios en la célula y localización del código de área
Cambios en la fuerza de la señal
Detección de SMS silenciosos
Detecta cambios de la estación base

La aplicación no está en Google Play, pero te la puedes descargar en formato zip o tar. Si prefieres el código fuente, lo tienes en Github.

El proyecto está en fase Alpha ahora mismo, con lo que no es 100% fiable.

conferencia

una serie de truquillos

vamos a dar una serie pequeño trucos el primero sera sobre el trafico de tor el siguiente te ayudara a la hora de auditar web

vamos a implementar el bloqueo en un firewall CSF, pero el proceso es el mismo para cualquier firewall que admita comandos remotos.

La idea es usar https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=TUIP para saber que nodos tienen salida hacia mi ip.

wget -q https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=TUIP -O -|sed '/^#/d' |while read IP
do
/usr/sbin/csf -td ${IP} 24h TOR
done

Ejecutando el script en una tarea programada una vez al día, podemos banear la lista de nodos que tienen acceso a nuestra ip pública.

vamos a hablar de un pequeño truco interesante que te puede servir si estás auditando

En Apache existe un módulo denominado mod_negotiation con la opción de Multiviews que se supone ayuda en la experiencia de navegación. Si un usuario accede a http://dominio/fichero.tx y no introduce la última t (txt). Tanto para directorios como para ficheros, el servidor Apache le muestra una sugerencia. como podemos usarlo,. Con esta función, podemos pedir solo el nombre del fichero, y si existe, Apache nos propone la extensión. Esto reduce mucho el proceso de fuzzing para averiguar los directorios y ficheros sensibles.

W3AF en modo consola o GUI.
w3af>>> plugins
w3af/plugins>>> discovery content_negotiation, webSpider
w3af/plugins>>> back
w3af>>> target
w3af/config:target>>> set target
http://dominio/
w3af/config:target>>> back
w3af>>> start

Metasploit.

Para hacer una prueba con Metasploit, introduzco en el fichero de palabras dos ficheros que se de ante-mano que existen, para que no tarde mucho el proceso de todo el fichero.

/opt/metasploit/apps/pro/msf3/data/wmap/wmap_files.txt

Binary Ninja una herramienta a nuestro servicio

Binary Ninja es un conjunto de herramientas enfocada al análisis y descubrimiento de vulnerabilidades en ficheros binarios.

Incluye entre otros:
Editor hexadecimal
Editor de texto
Desensamblador (con gráfico de flujo)
Terminal integrado
Compilador de shellcodes

La mayor parte del código está escrito en Python, más algúna implementación nativa en C++11. Es multiplataforma y open source bajo GPLv2, a excepción de las librerías de desensamblado que tienen licencia MIT.

Actualmente hay disponible una versión prototipo, disponible en github.

Requiere:
Python 2.7
PySide
Librería pycrypto

La lista completa de características, más las planeadas para versiones futuras las puedes encontrar aquí. Una vez tienes instaladas las dependencias, puedes ejecutar el fichero ninja.py.

Técnicas de explotación de Objective-C

por excelencia, Phrack, acaba de publicar un nuevo documento titulado Modern Objective-C Exploitation Techniques.

El documento trata sobre la explotación de aplicaciones escritas en Objective-C basada en la corrupción de la memoria. El autor de dicho trabajo, ya publicó en su día otro artículo en el número 66 de Phrack sobre cómo entender y abusar Objective-C en tiempo de ejecución The Objective-C Runtime: Understanding and Abusing, cuya lectura es recomendada previo a ésta.

El índice de esta nueva publicación es el siguiente:
Introduction
Dangling Objective-C Method Calls
32-bit dangling objc_msgSend()
32-bit Shared Region
Uncommon 32-bit Libraries
64-bit dangling objc_msgSend()
64-bit Shared Region
Uncommon 64-bit Libraries
Single Gadget Exploitation Strategies
Return SEL Gadget
Self Modifying ROP
Arbitrary Write Gadget
Tagged Pointers
Tagged NSAtom
Tagged NSString
Tagged NSNumber
Additional Tagged Types
Blocks
Sample Block Code
Exploitation
Future Research — Non Pointer ISA
Conclusion
References
Appendix – Source Code

miércoles, 20 de mayo de 2015

instalar parallel tools sobre kali

1. Install Kali

2. Download libc-bin, libc6, locales

$ wget "http://ftp.tw.debian.org/debian/pool/main/g/glibc/libc-bin_2.19-18_amd64.deb"

$ wget "http://ftp.us.debian.org/debian/pool/main/g/glibc/libc6_2.19-18_amd64.deb"

$ wget "http://ftp.cn.debian.org/debian/pool/main/g/glibc/locales_2.19-18_all.deb"

3. Install libc package

$ dpkg -B -i libc-bin_2.19-18_amd64.deb libc6_2.19-18_amd64.deb locales_2.19-18_all.deb

3. Download another packages

libtirpc1_0.2.5-1_amd64.deb nfs-common_1.2.8-9_amd64.deb libgssapi-krb5-2_1.12.1+dfsg-19_amd64.deb libkrb5-3_1.12.1+dfsg-19_amd64.deb libkrb5support0_1.12.1+dfsg-19_amd64.deb libkeyutils1_1.5.9-5+b1_amd64.deb libk5crypto3_1.12.1+dfsg-19_amd64.deb

4. Install all of it.

$ dpkg -i libtirpc1_0.2.5-1_amd64.deb nfs-common_1.2.8-9_amd64.deb libgssapi-krb5-2_1.12.1+dfsg-19_amd64.deb libkrb5-3_1.12.1+dfsg-19_amd64.deb libkrb5support0_1.12.1+dfsg-19_amd64.deb libkeyutils1_1.5.9-5+b1_amd64.deb libk5crypto3_1.12.1+dfsg-19_amd64.deb

5. Install parallel tools

Action -> Install Parallels Tools

6. Copy script from cdrom

$ mkdir /mnt/tool

$ cp /media/cdrom/* /mnt/tool

7. Change mode installer

$ cd /mnt/tool

$ chmod +x install install-gui

8. Run installer

$ ./install

9. Done

virus base datos

lugar donde podemos tomar pruebas para realizar una auditoria de lo que puede hacer
http://vxvault.net/ViriList.php

buenas practicas en contenedores

Docker es una plataforma abierta que permite construir, portar y ejecutar aplicaciones distribuidas, se basa en contenedores que corren en Linux y funcionan tanto en máquinas físicas como virtuales simplemente usando un runtime. Está escrito en Go y usa librerías del sistema operativo así como funcionalidades del kernel de Linux en el que se ejecuta. Consta de un engine con API RESTful y un cliente que pueden ejecutarse en la misma máquina o en máquinas separadas. Es Open Source (Apache 2.0) y gratuito.

Los contenedores existen desde hace muchos años, Docker no ha inventado nada en ese sentido, o casi nada, pero no hay que quitarles mérito, están en el momento adecuado y aportan las características y herramientas concretas que se necesitan en la actualidad, donde la portabilidad, escalabilidad, alta disponibilidad y los microservicios en aplicaciones distribuidas son cada vez más utilizados, y no sólo eso, sino que también son mejor entendidos por la comunidad de desarrolladores y administradores de sistemas. Cada vez se desarrollan menos aplicaciones monolíticas y más basadas en módulos o en microservicios, que permiten un desarrollo más ágil, rápido y a la vez portable. Empresas de sobra conocidas como Netflix, Spotify o Google e infinidad de Start ups usan arquitecturas basadas en microservicios en muchos de los servicios que ofrecen.

Te estarás preguntando ¿Y no es más o menos lo mismo que hacer un chroot de una aplicación? Sería como comparar una rueda con un coche. El concepto de chroot es similar ya que se trata de aislar una aplicación, pero Docker va mucho más allá, sería un chroot con esteroides, muchos esteroides. Por ejemplo, puede limitar y controlar los recursos a los que accede la aplicación en el contenedor, generalmente usan su propio sistema de archivos como UnionFS o variantes como AUFS, btrfs, vfs, Overlayfs o Device Mapper que básicamente son sistemas de ficheros en capas. La forma de controlar los recursos y capacidades que hereda del host es mediante namespaces y cgroups de Linux. Esas opciones de Linux no son nuevas en absoluto, pero Docker lo hace fácil y el ecosistema que hay alrededor lo ha hecho tan utilizado.

Adicionalmente, la flexibilidad, comodidad y ahorro de recursos de un contenedor es mayor a la que aporta una máquina virtual o un servidor físico, esto es así en muchos casos de uso, no en todos. Por ejemplo, tres servidores web para un cluster con Nginx en una VM con una instalación de Linux CentOS mínima ocuparía unos 400MB, multiplicado por 3 máquinas sería total de uso en disco de 1,2 GB, con contenedores serían 400MB las mismas 3 máquinas corriendo ya que usa la misma imagen para múltiples contenedores. Eso es sólo por destacar una característica interesante a nivel de recursos. Otro uso muy común de Docker es la portabilidad de aplicaciones, imagina una aplicación que solo funciona con Python 3.4 y hacerla funcionar en un sistema Linux con Python 2.x es complicado, piensa en lo que puede suponer en un sistema en producción actualizar Python, con contenedores sería casi automático, descargar la imagen del contenedor y ejecutar la aplicación de turno.

Solo por ponernos en situación de la envergadura Docker, unos números alrededor del producto y la compañía (fuente aquí):
95 millones de dólares de inversión.
Valorada en 1.000 millones de dólares.
Más de 300 millones de descargas en 96 releases desde marzo de 2013
Pero un contenedor no es para todo, ni hay que volverse loco “dockerizando” cualquier cosa, aunque no es este el sitio para esa reflexión. Al cambiar la forma de desarrollar, desplegar y mantener aplicaciones, también cambia en cierto modo la forma de securizar estos nuevos actores.

Docker aporta seguridad en capas, aísla aplicaciones entre ellas y del host sin usar grandes recursos, también se pueden desplegar contenedores en máquinas virtuales lo que aporta otra capa adicional de aislamiento (estaréis pensando en VENOM pero eso es otra película que no afecta directamente a Docker). Dada la arquitectura de Docker y usando buenas prácticas, aplicar parches de seguridad al anfitrión o a aplicaciones suele ser más rápido y menos doloroso.

Buenas Prácticas de Seguridad:

Aunque la seguridad es algo innato en un contenedor, desde Docker Inc. están haciendo esfuerzos por la seguridad, por ejemplo, contrataron hace unos meses a ingenieros de seguridad de Square, que no son precisamente nuevos en el tema. Ellos, junto a compañías como VMware entre otras, han publicado recientemente un extenso informe de sobre buenas prácticas de seguridad en Docker en el CIS. Gracias a este informe tenemos acceso a más de 90 recomendaciones de seguridad a tener siempre en cuenta cuando vamos a usar Docker en producción. En la siguiente tabla podemos ver las recomendaciones de seguridad sugeridas, algunas son muy obvias pero un check list así nunca viene mal:

1. Recomendaciones a nivel de host
1.1. Crear una partición separada para los contenedores
1.2. Usar un Kernel de Linux actualizado
1.3. No usar herramientas de desarrollo en producción
1.4. Securizar el sistema anfitrión
1.5. Borrar todos los servicios no esenciales en el sistema anfitrión
1.6. Mantener Docker actualizado
1.7. Permitir solo a los usuarios autorizados controlar el demonio Docker
1.8. Auditar el demonio Docker (auditd)
1.9. Auditar el fichero o directorio de Docker - /var/lib/docker
1.10. Auditar el fichero o directorio de Docker - /etc/docker
1.11. Auditar el fichero o directorio de Docker - docker-registry.service
1.12. Auditar el fichero o directorio de Docker - docker.service
1.13. Auditar el fichero o directorio de Docker - /var/run/docker.sock
1.14. Auditar el fichero o directorio de Docker - /etc/sysconfig/docker
1.15. Auditar el fichero o directorio de Docker - /etc/sysconfig/docker-network
1.16. Auditar el fichero o directorio de Docker - /etc/sysconfig/docker-registry
1.17. Auditar el fichero o directorio de Docker - /etc/sysconfig/docker-storage
1.18. Auditar el fichero o directorio de Docker - /etc/default/docker

2. Recomendaciones a nivel de Docker Engine (daemon)
2.1 No usar el driver obsoleto de ejecución de lxc
2.2 Restringir el tráfico de red entre contenedores
2.3 Configurar el nivel de logging deseado
2.4 Permitir a Docker hacer cambios en iptables
2.5 No usar registros inseguros (sin TLS)
2.6 Configurar un registro espejo local
2.7 No usar aufs como driver de almacenamiento
2.8 No arrancar Docker para escuchar a una IP/Port o Unix socket diferente
2.9 Configurar autenticación TLS para el daemon de Docker
2.10 Configurar el ulimit por defecto de forma apropiada

3. Recomendaciones a nivel de configuración de Docker
3.1 Verificar que los permisos del archivo docker.service están como root:root
3.2 Verificar que los permisos del archivo docker.service están en 644 o más restringidos
3.3 Verificar que los permisos del archivo docker-registry.service están como root:root
3.4 Verificar que los permisos del archivo docker-registry.service están en 644 o más restringidos
3.5 Verificar que los permisos del archivo docker.socket están como root:root
3.6 Verificar que los permisos del archivo docker.socket están en 644 o más restringidos
3.7 Verificar que los permisos del archivo de entorno Docker (/etc/sysconfig/docker o /etc/default/docker) están como root:root
3.8 Verificar que los permisos del archivo de entorno Docker (/etc/sysconfig/docker o /etc/default/docker) están en 644 o más restringidos
3.9 Verificar que los permisos del archivo /etc/sysconfig/docker-network (si se usa systemd) están como root:root
3.10 Verificar que los permisos del archivo /etc/sysconfig/docker-network están en 644 o más restringidos
3.11 Verificar que los permisos del archivo /etc/sysconfig/docker-registry (si se usa systemd) están como root:root
3.12 Verificar que los permisos del archivo /etc/sysconfig/docker-registry (si se usa systemd) están en 644 o más restringidos
3.13 Verificar que los permisos del archivo /etc/sysconfig/docker-storage (si se usa systemd) están como root:root
3.14 Verificar que los permisos del archivo /etc/sysconfig/docker-storage (si se usa systemd) están en 644 o más restringidos
3.15 Verificar que los permisos del directorio /etc/docker están como root:root
3.16 Verificar que los permisos del directorio /etc/docker están en 755 o más restrictivos
3.17 Verificar que los permisos del certificado del registry están como root:root
3.18 Verificar que los permisos del certificado del registry están en 444 o más restringidos
3.19 Verificar que los permisos del certificado TLS CA están como root:root
3.20 Verificar que los permisos del certificado TLS CA están en 444 o más restringidos
3.21 Verificar que los permisos del certificado del servidor Docker están como root:root
3.22 Verificar que los permisos del certificado del servidor Docker están en 444 o más restringidos
3.23 Verificar que los permisos del archivo de clave del certificado del servidor Docker están como root:root
3.24 Verificar que los permisos del archivo de clave del certificado del servidor Docker están en 400
3.25 Verificar que los permisos del archivo de socket de Docker están como root:docker
3.26 Verificar que los permisos del archivo de socket de Docker están en 660 o más restringidos

4. Imágenes de Contenedores y Dockerfiles
4.1 Crean un usuario para el contenedor
4.2 Usar imágenes de confianza para los contenedores
4.3 No instalar paquetes innecesarios en el contenedor
4.4 Regenerar las imágenes si es necesario con parches de seguridad

5. Runtime del contenedor
5.1 Verificar el perfil de AppArmor (Debian o Ubuntu)
5.2 Verificar las opciones de seguridad de SELinux (RedHat, CentOS o Fedora)
5.3 Verificar que los contenedores esten ejecutando un solo proceso principal
5.4 Restringir las Linux Kernel Capabilities dentro de los contenedores
5.5 No usar contenedores con privilegios
5.6 No montar directorios sensibles del anfitrión en los contenedores
5.7 No ejecutar ssh dentro de los contenedores
5.8 No mapear puertos privilegiados dentro de los contenedores
5.9 Abrir solo los puertos necesarios en un contenedor
5.10 No usar el modo “host network” en un contenedor
5.11 Limitar el uso de memoria por contenedor
5.12 Configurar la prioridad de uso de CPU apropiadamente
5.13 Montar el sistema de ficheros raíz de un contenedor como solo lectura
5.14 Limitar el tráfico entrante al contenedor mediante una interfaz específica del anfitrión
5.15 Configurar la política de reinicio 'on-failure' de un contenedor a 5
5.16 No compartir PID de procesos del anfitrión con contenedores
5.17 No compartir IPC del anfitrión con contenedores
5.18 No exponer directamente dispositivos del anfitrión en contenedores
5.19 Sobre-escribir el ulimit por defecto en tiempo de ejecución solo si es necesario

6. Operaciones de Seguridad en Docker
6.1 Realizar auditorías de seguridad tanto en el anfitrión como en los contenedores de forma regular
6.2 Monitorizar el uso, rendimiento y métricas de los contenedores
6.3 Endpoint protection platform (EPP) para contenedores (si las hubiese)
6.4 Hacer Backup de los datos del contenedor
6.5 Usar un servicio centralizado y remoto para recolección de logs
6.6 Evita almacenar imágenes obsoletas, sin etiquetar correctamente o de forma masiva.
6.7 Evita almacenar contenedores obsoletos, sin etiquetar correctamente o de forma masiva.

Hackerone una plataforma que cambia todo

Hoy quiero hablar HackerOne, una plataforma que facilita la comunicación entre el equipo de seguridad de una empresa con profesionales o con principiantes en la seguridad informática también llamados hackers. Gracias a HackerOne se han corregido miles de fallos y actualmente se ha pagado 2.49 Millones de Dólares

bajo es eslogan de

Find it First. No Compromises.

Entre las empresas que podemos encontrar hay algunas muy famosas como Twitter, Yahoo!, Dropbox y la propia HackerOne inclusive. Además, hay un programa financiado por organizaciones preocupadas por la seguridad de los demás llamado Internet Bug Bounty, que básicamente está enfocado al reporte de bugs que afectan a todo Internet.

Funcionamiento de HackerOne

Del dinero que se paga por los bugs descubiertos un 20% se lo lleva HackerOne, como broker de reporte. A cambio de ese 20% HackerOne se hace responsable de que al hacker le llegue todo el dinero, evitando los formularios de impuestos y demás quebraderos de cabeza. Por lo que tu equipo no tiene que preocuparse en que loshackers sean pagados y puede centrarse en trabajar. A día de hoy estas son las estadísticas de la web:

Supongo que estaréis pensando, ¿solo hay 83 empresas registradas? En realidad no, además de programas públicos en los que cualquiera puede participar también hay programas en los que solo se puede acceder por invitación, ya sea porque quieren tener controlados el número de usuarios, estén probando HackerOne o simplemente no quieran aparecer en la lista de programas.

Muchas de las empresas dan recompensas que van desde los 10 a 20.000 dólares y ese dinero lo puedes pasar a una cuenta de Paypal, un monedero de BitCoins o donarlo a una organización de caridad. La edad mínima para cobrar un premio es de solo 13 años.

dejo una captura de pantalla en la que se muestra un reporte realizado aHackerOne por un usuario. Como podéis observar la interfaz es simple. Si ponemos el cursor encima de un nombre de usuario veremos información básica sobre el: el número de bugs encontrados - sólo los aceptados -, las veces que le han dado las gracias y la reputación que tiene.

Gestión de la reputación en HackerOne

La reputación es calculada en base al número de reportes aceptados, los no aceptados por duplicados o porque el bug no existe.

Ganas reputación si:

● Tu reporte es cerrado como “Resuelto”: +7 (Si te han premiado aumenta)
● Tu reporte es cerrado como “Duplicado ( Resuelto) “ Solo se aplica si se envio antes de que el otro reporte fuera solucionado.
● Tu reporte es cerrado como “No se va a resolver” +1
● Tu reporte es cerrado como “Duplicado (No se va a resolver) “ +1

Pierdes reputación si:

● Tu reporte es cerrado como “No aplicable” 5
● Tu reporte es cerrado como “Duplicado (No aplicable)” 5
● Tu reporte es cerrado como “Necesita más información” 1

Si tienes mucha reputación obtendrás algunos privilegios como poder ser invitado a programas antes de que estén disponibles al público por otro lado, si tu reputación baja se limitará el número de reportes que podrás enviar en un periodo de tiempo.

Ventajas de utilizar HackerOne como plataforma de reporte de bugs

Para mi las ventajas de usar HackerOne son estas:

● Evita el papeleo a los equipos de seguridad
● Permite que cualquier persona reporté siendo reconocido por su trabajo y premiado por ello.
● Fomenta la búsqueda de fallos que puedan afectar a todo Internet
● Servicio gratuito que asegura la seguridad de los reportes y anonimato de los usuarios.

aquí están los mejores de acuerdo a su reputación

Top de los mejores

El Ataque de estancamiento

!Usted se encuentra en peligro¡

Diffie-Hellman es un algoritmo criptográfico popular que permite a los protocolos de Internet para acordar una clave compartida y negociar una conexión segura. Es fundamental para muchos protocolos incluyendo HTTPS, SSH, IPsec, SMTPS y protocolos que se basan en TLS.

Hemos descubierto varias debilidades en cómo se ha desplegado Diffie-Hellman:
Ataque contra el estancamiento del Protocolo TLS. El ataque atasco permite que un atacante man-in-the-middle de rebajar las conexiones TLS vulnerables a la criptografía de grado de exportación de 512 bits. Esto permite al atacante leer y modificar los datos pasados por la conexión. El ataque es una reminiscencia del ataque FREAK , pero se debe a una falla en el protocolo TLS en lugar de una vulnerabilidad de ejecución, y ataca a un intercambio de claves Diffie-Hellman más que un intercambio de claves RSA. El ataque afecta a cualquier servidor que soporte DHE_EXPORT sistemas de cifrado, y afecta a todos los navegadores web modernos. 8,4% de los Top 1 Millón dominios eran inicialmente vulnerables.

Amenazas de adversarios a nivel estatal. Millones de HTTPS, SSH y servidores VPN todos usan los mismos números primos de Diffie-Hellman. Los médicos creían que esto era seguro siempre y cuando se generaron nuevos mensajes de intercambio de claves para cada conexión. Sin embargo, el primer paso en el campo de número de tamiz-el algoritmo más eficiente para romper un Diffie-Hellman conexión sólo depende de esta primera. Después de este primer paso, un atacante puede romper rápidamente las conexiones individuales.
Hemos llevado a cabo este cálculo en contra de la más común prime 512 bits utilizado para TLS y demostrar que el ataque atasco se puede utilizar para rebajar conexiones a 80% de los servidores TLS apoyo DHE_EXPORT . Estimamos además que un equipo académico puede romper un 768-bit de primera y que un Estado-nación podemos romper un primo de 1024 bits. Rompiendo el, más común prime 1024 bits única empleada por los servidores web permitiría escucha pasiva en las conexiones a 18% de los Top 1 Millón dominios HTTPS. Un segundo prime permitiría descifrado pasiva de conexiones a 66% de los servidores VPN y el 26% de los servidores SSH. Una lectura atenta de filtraciones publicadas NSA demuestra que los ataques de la agencia sobre las VPN son consistentes con haber logrado tal ruptura.

Reporte Técnico

se ha publicado un informe técnico, Imperfect Forward Secrecy: Cómo Diffie-Hellman se produce un error en la práctica , que tiene información específica sobre estos ataques, los detalles sobre la forma en que se rompió el grupo de 512 bits más común Diffie-Hellman, y las medidas de que se ve afectada.

Este estudio fue realizado por científicos de la computación en INRIA Nancy-Grand Est, Inria Paris-Rocquencourt, Microsoft Research, la Universidad Johns Hopkins, la Universidad de Michigan y la Universidad de Pennsylvania: David Adrian , Karthikeyan Bhargavan , Zakir Durumeric , Pierrick Gaudry , Matthew Green , J. Alex Halderman , Nadia Heninger , dibujó Springall , Emmanuel Thomé , Lucas Valenta ,Benjamin VanderSloot , Eric Wustrow , Santiago Zanella-Beguelin y Paul Zimmermann

¿A quiénes afecta?

Sitios web, servidores de correo, y otros servicios-TLS dependientes que apoyan DHE_EXPORT cifras están en riesgo de ataque estancamiento.Utilizamos la exploración en todo el Internet para medir quién es vulnerable.

Los sitios web que utilizan uno de los pocos grupos de 1024 bits Diffie-Hellman compartidos pueden ser susceptibles a la escucha pasiva de un atacante con recursos del Estado-nación. Aquí, se muestra cómo varios protocolos se verían afectados si un solo grupo de 1024 bits se rompieron en cada protocolo, suponiendo un cliente típico actualizada (por ejemplo, la versión más reciente de OpenSSH o hasta a la fecha de instalación de Chrome)
Qué tengo que hacer?

Si ejecuta un servidor ...

Si usted tiene un servidor web o correo, debe desactivar el soporte para la exportación de cifrado y generar un único grupo Diffie-Hellman de 2048 bits. Hemos publicado una Guía para la Implementación de Diffie-Hellman para TLS con instrucciones paso a paso. Si utiliza SSH, debe actualizar tanto sus instalaciones de servidor y cliente a la versión más reciente de OpenSSH, que prefiere elíptico-Curve Diffie-Hellman de intercambio de claves.

Si utiliza un navegador ...

Asegúrese de tener la versión más reciente de su navegador instalado, y comprobar si hay actualizaciones frecuentes. Google Chrome (incluyendo navegador de Android), Mozilla Firefox, Microsoft Internet Explorer y Safari de Apple son todas las correcciones que despliegan para el ataque estancamiento.

Si usted es un administrador de sistemas o desarrollador ...

Asegúrese de que ninguna biblioteca TLS que utiliza son hasta a la fecha y que usted rechaza Diffie-Hellman Grupos más pequeños a 1024 bits.

Los investigadores de seguridad recomiendan a todos los administradores de servidores deben desactivar el soporte para las suites de cifrado de exportación DHE_EXPORT que permiten a las conexiones Diffie-Hellman ser degradados, y generar claves de 2048 bits. En un servidor se puede probar de la siguiente manera:
nmap --script ssl-enum-ciphers -p | grep EXPORT

Logjam Tools

mas información

Descarga

martes, 12 de mayo de 2015

archivos MRU

MRU. ¿Qué son?

Los archivos MRU, por sus siglas en inglés Most Recently Used [files] son de gran ayuda en un análisis forense a la hora de averiguar cuáles fueron los últimos ficheros que se manipularon en un espacio de tiempo determinado. Si bien es verdad que para sistemas Windows hay, desde hace muchísimo tiempo, innumerables herramientas que facilitan la labor de extracción, parseo y presentación de este tipo de información (en su mayoría del registro de Windows), no hay tantas para sistemas Linux de escritorio.Aunque no es un escenario frecuente, puede darse el caso de que el perito/analista forense se tenga que enfrentar a una máquina Linux con KDE, Gnome o cualquiera de los múltiples escritorios disponibles. Por ello decidí empezar a escribir MRUTools, y al hacerlo descubrí algunos hechos que no saltan inmediatamente a la vista.
No hay una forma ‘estándar’ de almacenar esta información. Cada aplicación que posee esta funcionalidad, e incluso cada escritorio, lo hace de una forma distinta, si bien algunas aplicaciones integradas, o de uso mayoritario en un escritorio particular se atañen a ciertas ‘reglas’.
Como consecuencia del punto anterior, en muchos casos no basta con ‘eliminar’ las referencias a estos ficheros desde la opción que da el escritorio (lo cual me ha brindado alguna que otra sorpresa al ejecutarlo en mi propia máquina).

Al lío: Buscando información en KDE

Usando el viejo método de ensayo-error, abrimos un fichero de prueba con Kate, el editor de textos por defecto en KDE: prueba.txt

Como no sabemos a priori dónde almacena esta información, podríamos ir a la documentación de KDE y buscarlo, pero siendo un poco impacientes, ejecutamos un grep en nuestro $HOME y obtenemos lo siguiente:

Vaya, la cosa se pone interesante. Aparecen varias referencias a nuestro fichero de prueba. Tomamos nota de las ubicaciones para inspeccionarlas más a fondo:
$HOME/.kde/share/apps/RecentDocuments
$HOME/.kde/share/apps/kate/katerc
$HOME/.kde/share/apps/kate/metainfos

Si investigamos el contenido de estas ubicaciones, vemos que:
El escritorio KDE almacena la información de los ficheros que abrimos desde él en una carpeta llamadaRecentDocuments. Cada fichero abierto (más info: ver xdg-open) genera una entrada en este directorio (hasta un máximo de diez, después van rotando) con una estructura definida (¡y parseable! :D).
Parece que cada aplicación independiente que tenga funcionalidad de ‘Recent Files…’ también posee su propio listado de ficheros. Lo interesante aquí es que si pulsamos botón derecho en el menú de KDE ‘Usados Recientemente’ y hacemos click en ‘Limpiar documentos recientes’, éstas entradas efectivamente desaparecen del menú (se vacía el contenido del directorio $HOME/.kde/share/apps/RecentDocuments), pero si ejecutamos de nuevo el grep anterior…

Efectivamente, las referencias a ficheros abiertos permanecen de forma independiente por cada aplicación (por lo que he podido comprobar ocurre en varias como VLC, Dragon Player y como estamos viendo aquí, Kate). MRUTools surge de la idea de automatizar el proceso de extracción, parseo y presentación de este tipo de información:

Ejemplo y Timeline

Evidentemente al ejecutar la herramienta en un entorno real obtenemos gran cantidad de datos que por sí solos no aportan una visión general de la situación. Es necesario estructurar los datos, por ejemplo en una línea temporal. Para ello nos viene muy bien el proyecto Timeline.

Esta herramienta escrita en Python se adapta perfectamente a nuestras necesidades. Tras leer la documentación disponible en su web y entender cómo funciona, adaptamos MRUTools para que exporte un fichero XML que Timeline sea capaz de entender. Y el resultado final, tras ejecutarlo en una máquina real ejecutando KDE es el siguiente:

Un gran punto a favor de Timeline es que nos permite visualizar de forma interactiva los eventos que hayamos generado, mostrando de una forma muy gráfica y ordenada la salida de MRUTools.

Conclusiones

A partir de los resultados obtenidos hemos podido comprobar que los archivos MRU son de mucha ayuda en un análisis forense, y además, cada aplicación mantiene los suyos, lo que dificulta el borrado de huellas. No es una fuente del todo fiable, ya que como (casi) todo lo digital, puede ser manipulable, pero eso lo dejamos para otra entrega.
Autor del articulo @asuarezbm

WordPress roban tus usuarios y contraseñas

Si tienes un servidor WordPress en alguno de tus sistemas, además de tener un cuidado extremo con las actualizaciones de seguridad - especialmente con el bug de XSS persistente que se ha estado explotando estos días - debes comprobar que que no esté troyanizado por algún bug anterior y esté robando los usuarios y contraseñas de todos los accesos desde la misma página de login.

Eso es lo que han detectado en ZScaler, donde han comprobado como hay una campaña de infección para servidores WordPress que están inyectando un ficheroJavaScript en la página de login, tal y como se puede ver en la imagen siguiente de un sitio infectado.

El fichero JavaScript inyectado, lo que está haciendo es interceptar los valores introducidos en el formulario de login y robar el usuario y las contraseñas para enviarlos a un servidor controlado por los atacantes. El código está ofuscado, pero al final está interceptando el submit del formulario de login, concatenando todos los valores enviados y codificándolos en Base64 para enviarlos a un servidor web remoto.

Esto es algo que ya hicimos nosotros cuando montamos la JavaScript Botnet usando un Proxy Anónimo y que utilizamos para hacer ataques dirigidos contra sitios infectando la caché de las víctimas con páginas de login con ficherosJavaScript troyanizados y que hoy en día se puede hacer fácilmente con BeEF. Aquí tienes la conferencia de Owning Bad Guys {and Mafia} using JavaScript Botnets donde se explica y se hace esta demostración de cómo de robar las contraseñas de un sitio con un JavaScript que intercepta el login de una web.

Si tienes un servidor WordPress revisa en detalle su seguridad, comprueba que el contenido externo que está cargando tu web es el que debe cargar y que no hay ningún fichero JavaScript remoto en la página de login.