Quantcast
Channel: hackplayers
Viewing all 1671 articles
Browse latest View live

Convierten un cuadricóptero casero en un Halcón Milenario

$
0
0
En RCGroups.com, un foro de referencia para aficionados al radio control, el francés Olivier C ha creado un curioso skin para su cuadricóptero 'Prophecy 335' que lo transforma en un auténtico "clon" del Halcón Milenario... 

Cuatro rotores a 335mm, un poco de fibra de carbono, poliestireno, una tira led para simular el propulsor y un resultado increíble...  Sólo mira el siguiente vídeo:

¿Te gustaría volar uno? Pues visita el foro donde encontrarás todo el detalle de su construcción y háztelo tu mismo (DIY):

Prophecy 335: http://www.rcgroups.com/forums/showthread.php?t=2263855
Millenium Falcon 335: http://www.rcgroups.com/forums/showthread.php?t=2331840

La verdadera cara del hacking (literalmente hablando)

$
0
0
Los hackers tienden a ser anónimos, sin rostro, sin nombre... pero ¿qué aspecto tendría la cara de un hacker si mezcláramos las fotos de los hackers más notorios del momento?.

Eso es lo que se preguntaba la gente de Secure Thoughts, un sitio web dedicado a la ciberseguridad y a la privacidad en Internet, que han compilado y combinado hasta 50 caras de hackers llegando a este resultado:



En ese GIF se combinan rostros como los de Barrett Brown, un portavoz de Anonymous que fue condenado recientemente a más de cinco años de prisión por el robo de datos de la firma de inteligencia Stratfor, y Gary McKinnon, quien, en 2002, fue acusado de la mayor brecha a sistemas militares de todos los tiempos.

También se incluye: Robert Tappan Morris, acreditado con la creación del primer gusano informático, y, sí, también está Héctor Monsegur alias Sabu, que colaboró con el FBI para reducir su condena ¿os suena de la película "Blackhat"?...

Ah!, y Secure Thoughts no se ha olvidado de los rostros femeninos. Este sería también el resultado:

¿Cómo de hackeable eres? Calcula tu puntuación 'Pwned'

$
0
0
Curioso artículo en el Huffington Post en el que se presenta un pequeño cuestionario con el que los usuarios pueden evaluar el riesgo de ser hackeados. Lo hemos adaptado un poquito pero más o menos puedes obtener una puntuación (no excesivamente científica) para ver las posibilidades de ser jodido pwned :

1.- ¿Qué tan fuertes son sus contraseñas? (10 puntos): A menudo las personas cometen errores básicos con sus contraseñas, como elegir aquellas que son fácilmente adivinables/crackeables (por ej: 'password123'), mantener las contraseñas por defecto, la reutilización de la misma contraseña en varias cuentas, etc. Puntuate a ti mismo:
+2 si escribes contraseñas complejas (caracteres, combinación de letras, números y símbolos)
+4 si utilizas contraseñas únicas para cada cuenta
+4 si usas autenticación de dos factores (cuando esté disponible)

2.- ¿Haces copia de seguridad de tus datos? (10 puntos): Los ciberdelincuentes usan cada vez más "ransomware" para victimizar a los consumidores. Dado que estos ataques hacen que los archivos personales (documentos, fotos, vídeos, música, etc.) sean inaccesibles y los PCs inservibles, la mejor manera de protegerse contra ello es mediante copias de seguridad periódicas de los datos a un disco duro externo, unidad flash o una cuenta en la nube. Elige una de estas puntuaciones:
+10 si haces copias de seguridad de los datos al menos una vez a la semana
+5 si haces copias de seguridad de los datos al menos una vez al mes
+1 si haces copias de seguridad con otra periodicidad mayor
+0 si no haces copias de seguridad

3.-¿Qué sistema operativo utilizas? (5 puntos): Debido a que la mayoría de las personas en todo el mundo utilizan PCs basados en Windows en lugar de OS X o sistemas basados en Linux, los ciber-delincuentes suelen escribir malware diseñado específicamente para este sistema operativo. Como resultado, los usuarios que usan Macs o dispositivos Linux estarán generalmente menos expuestos (aunque no significa que sean inmunes) al malware que los usuarios de Windows. Puntuate a ti mismo:
+5 Si utilizas un dispositivo con Linux
+3 Si utilizas un dispositivo con OS X
+0 Si utilizas un dispositivo con Windows

4.-¿Utilizas antivirus? (5 puntos):  Es cierto, un antivirus no es una bala de plata - y va a "tragarse" una gran cantidad de malware peligroso. Pero los usuarios todavía tenemos que tenerlo y mantenerlo actualizado, porque sin AV todavía existe un mayor riesgo de infección. Puntuate a ti mismo:
+5 si utilizas un producto antivirus en todos sus dispositivos (ya sea Windows, Mac o Linux) con firewall personal
+3 si utilizas un producto antivirus en todos sus dispositivos (ya sea Windows, Mac o Linux) sin firewall personal
+0 si no utilizas antivirus

5.- ¿Cómo navegas por Internet? (10 puntos): la mayoría de los ataques vienen ahora a través del navegador de Internet (descargas drive-by, cross-site scripting, man-in-the-browser, etc.), así que es importante que los usuarios naveguen por la web con cuidado. Eso significa:
+3 si usas plugins que bloqueen scripts (ScriptSafe, NoScript, Adblock Plus, etc.)
+2 si nunca haces clic en los anuncios pop-up o alertas
+2 si nunca visitas una página de registro de un enlace enviado por correo electrónico
+3 si usas navegadores separados para ir de compras y navegar por la web

6.-¿Utilizas un PC dedicado para acceder al banco? (10 puntos) - En algún momento, casi todos los ordenadores que navegan por la web se infectan con malware y, en el peor de los casos, se trata de un troyano bancario. Si los usuarios deben proteger una cosa, esa es su cuenta bancaria online. La mejor manera de hacer esto es tener un equipo dedicado (como un netbook barato o Chromebook) que sólo se utilice para acceder online al banco. Puntuate a ti mismo:
+10 si tienes un portátil dedicado que sólo utilizas para la banca en línea
+0 si no

7.- ¿Utilizas redes Wi-Fi públicas? (10 puntos): Si usas WiFis públicas estás pidiendo a gritos ser hackeado. Hay una serie de herramientas de hacking gratuitas o de bajo coste que hacen que sea fácil para casi cualquier persona hackear una conexión Wi-Fi abierta. Puntuate a ti mismo:
+0 si utilizas WiFi públicas por lo menos una vez al año
+10 Si nunca las usas, 10.
-5 Si nunca usas WiFi públicas pero utilizas WiFi protegida por contraseña en tu casa y tus vecinos tienen cobertura

8.- ¿Visitas sitios peligrosos? (10 puntos): Esto no es un juicio personal, pero si frecuentas sitios web para adultos o sitios de intercambio de archivos donde los usuarios comparten películas y música pirateadas, estás aumentando el potencial de exponerte. Puntuate a ti mismo:
+0 si visitas estos sitios, 0
+10 si nunca lo haces

¿El resultado? 

A menos que obtuvieras 60 puntos o más, no estás seguro en absoluto y es el momento de cambiar tus costumbres. 
Y si puntuaste 35  o menos, ten cuidado porque eres un blanco muy fácil para los hackers y lo único que te mantiene a salvo es pura suerte. De hecho, es probable que ya puedas haber sido comprometido de una manera u otra, y que lo sepas o no.

Detectar el uso de Mimikatz en la red ("Honey Hash Tokens")

$
0
0
La opción /netonly del comando runas se utiliza para lanzar un programa como un usuario que existe en una máquina remota. El sistema acepta el nombre y la contraseña para ese usuario remoto y crea un token de autenticación en la memoria de su proceso LSASS sin ninguna interacción con el host remoto.

¿Qué pasa si ejecutamos el siguiente comando en nuestro equipo Windows?

runas /user:microsoft.com\administrator /netonly cmd.exe
 
El comando que se ejecuta en realidad no tiene ningún acceso elevado en la máquina y la contraseña no es válida, evidentemente no es una amenaza para Microsoft. Windows no intenta autenticarse en el dominio Microsoft.com para iniciar el proceso. Asume que las credenciales son correctas, calcula el hash y lo almacena en la memoria para su uso futuro.

Más adelante, si se intenta acceder a un recurso en ese dominio, automáticamente se "pasará el HASH" al sistema remoto para entrar. Pero hasta que se intente acceder al host remoto, las contraseñas se quedan almacenadas en memoria.


¿Qué significa eso? Pues que podemos "inundar" nuestro sistema de credenciales falsas para ponérselas en bandeja memoria a un atacante. Por ejemplo:

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # sekurlsa::logonPasswords full

Authentication Id : 0 ; 3420125 (00000000:002c38b2)
Session           : NewCredentials from 0
User Name         : usuario
Domain            : dominio
SID               : S-1-5-21-2342468007-2769232512-6969471351-1000
        msv :
         [00000003] Primary
         * Username : administrator
         * Domain   : microsoft.com
         * NTLM     : d139627ea1a54be9b04f2158a4d10b93
         * SHA1     : 2c19cfd8f7a112f29a7183e8ed4db7e68e714049
        tspkg :
        wdigest :
         * Username : administrator
         * Domain   : microsoft.com
         * Password : falsa
        kerberos :
         * Username : administrator
         * Domain   : microsoft.com
         * Password : falsa
        ssp :
        credman :

Es es el resultado de nuestros "Honey Hash Tokens" (ver también honeytoken). Cualquiera que utilice mimikatz, meterpreter, procdump.exe u otra herramienta para robar las contraseñas en memoria podrá llevarse a engaño. Evidentemente herramientas que obtienen los hashes en disco como hashdump no funcionarán.

Pero ahí está la idea: elegir un nombre de usuario creíble y que parezca que tenga privilegios elevados en el dominio, generar las credenciales falsas en la memoria de los servidores que están más en el punto de mira (por ejemplo los de la DMZ) y preparar alertas en la red para avisarnos de intentos de uso de estas cuentas falsas.

¡Buena caza!

Fuente: Detecting Mimikatz Use On Your Network

JASBUG! es el momento de actualizar todos los equipos de una red con Directorio Activo

$
0
0
En el pasado, la seguridad de la red se diseñó en torno a "mantener el interior seguro desde el exterior", en lugar de la idea más general "proteger cada ordenador de todos los demás". En estos días la defensa de la red como un perímetro definido rígidamente no es lo suficientemente buena, ya que muchos atacantes vienen de dentro.

JASBUG, bautizado así porque fue descubierto (y reportado hace meses) por la firma de seguridad JAS Global Advisors, es más que un bug un fallo de diseño remanente desde desde Windows Server 2003 que puede permitir la ejecución remota de código (RCE) suplantando los ficheros que el servidor envía a un cliente: software de confianza por malware. 

Este martes Microsoft ha publicado correcciones del core de su sistema para solventar estas vulnerabilidades críticas (CVE-2015-0008), concretamente dos que implican directivas de grupo y objetos de directiva de grupo (GPO):

MS15-014 - Una vulnerabilidad en SMB

 
Al iniciar sesión en una red con Directorio Activo, el servidor le enviará las actualizaciones según su directiva de grupo, por lo que el administrador de sistemas tiene la oportunidad de establecer una configuración estandarizada y segura en cada PC de su red. Sin embargo cuando la actualización falla, existe un fallo en SMB mediante el cual es posible desactivar los requisitos de firmado SMB, por lo que el cliente no comprobará que ya no está recibiendo los ficheros del servidor y un atacante podrá modificar la tabla ARP del switch para que acceda a su equipo y obtenga un fichero malicioso, todo esto sin que la víctima se percate.



La corrección es sencilla, cuando falle la actualización de directiva se cerrará la misma sin dejártela abierta sin firmado SMB.

MS15-011 - Una vulnerabilidad en la directiva de grupo

MS15-011 es similar, pero mucho más difícil de arreglar. Un atacante podría también hacer la misma suplantación pero mediante una especie de Catch-22: para averiguar si la firma SMB está activada, un cliente tiene que revisar una directiva de grupo del servidor de Active Directory y, mientras lo comprueba, el firmado SMB es irrelevante. El servidor valida el cliente a través del proceso de inicio de sesión, pero el cliente no valida el servidor (esto, en pocas palabras, es el fallo de diseño).

Para corregirlo Microsoft ha tenido que 1/ añadir una función para implementar el firmando SMB durante el proceso de directiva de grupo, para que su cliente pueda validar el servidor antes de confiar en sus datos de directiva de grupo y 2/ habilitar esta nueva característica en cada cliente.

Aunque ambas vulnerabilidades podrían explotarse a través de Internet, su escenario típico es mediante un ataque MITM en una red interna (LAN) con un Directorio Activo corporativo, por lo que los administradores de Microsoft deberían darse prisa en aplicar los parches publicados por Microsoft ayer...


pd. y no sólo los administradores... los usuarios domésticos también deben aplicar las actualizaciones ya que en este boletín de febrero se solventan otras vulnerabilidades a tener en cuenta: Internet Explorer, Windows Driver, Ms Office...

Fuentes:
- JASBUG Fact Sheet
- MS15-011 & MS15-014: Hardening Group Policy
- The "JASBUG" Windows vulnerability - beyond the hype, what you need to know
- 15-Year-Old JasBug Vulnerability Affects All Versions of Microsoft Windows

I evento gratuito de OWASP Madrid

$
0
0
OWASP Madrid Chapter arranca su andadura. Lo hace con una jornada de conferencias abierta que tendrá lugar el próximo 26 de marzo a las 18:30 en el Campus de Leganés de la UC3M.

La entrada es GRATUITA, pero el aforo es limitado por lo que será necesario inscribirse al evento y llevar impresa la entrada. Date prisa porque ya quedan menos de 100 plazas!:

https://www.ticketea.com/i-evento-owasp-madrid/  

Los detalles de la agenda son los siguientes:
Charlas:
  • Presentación OWASP Madrid
  • From vulnerable source to shell in two hours (La charla estará comprendida de dos partes)
    • Introducción a la seguridad en código por Ángel García Moreno @_Ell0_: Se explicarán conceptos de seguridad en código, enseñando fallos comunes, y también se mostrarán ejemplos prácticos. En concreto se utilizará un fallo conocido de Drupal, framework de PHP famoso por su seguridad.
    • Explotación de un fallo de seguridad por Daniel Martínez @dan1t0: En esta charla que continuará donde termine la anterior se explotará el fallo mostrado por Ángel, dumpeando información de la BBDD, troyanizando y controlando el servidor remoto. Se mostrará como poder usar este fallo para atacar a otros usuarios.

Busca exploits desde la línea de comandos con Pompem

$
0
0
Pompem es una herramienta de código abierto, diseñada para automatizar la búsqueda de exploits en las principales bases de datos. 

Desarrollado en Python, tiene un sistema de búsqueda avanzada, facilitando así el trabajo de pentesters y hackers éticos. En su versión actual, realiza búsquedas en bases de datos: Exploit-db, 1337day, Packetstorm Security...

También existe una versión web de Pompem (sintaxis PHP): WebPompem

Instalación

Pompem funciona con cualquier versión de Python '2.6.x' y '2.7.x'. Para instalarlo crearemos un entorno de Python aislado en una distribución Kali e instalaremos las dependencias necesarias:

root@kali:~# pip install virtualenv

root@kali:~# virtualenv .env
New python executable in .env/bin/python
Installing setuptools, pip...done.

(.env)root@kali:~# git clone https://github.com/rfunix/Pompem.git Pompem-dev

(.env)root@kali:~# cd Pompem-dev/


(.env)root@kali:~/Pompem-dev# pip install -r requirements.txt
Collecting BeautifulSoup==3.2.1 (from -r requirements.txt (line 1))
  Downloading BeautifulSoup-3.2.1.tar.gz
Collecting requests==2.2.1 (from -r requirements.txt (line 2))
  Downloading requests-2.2.1-py2.py3-none-any.whl (625kB)
    100% |################################| 626kB 344kB/s
Installing collected packages: requests, BeautifulSoup

  Running setup.py install for BeautifulSoup
Successfully installed BeautifulSoup-3.2.1 requests-2.2.1


Uso

Para obtener una lista de opciones básicas:

(.env)root@kali:~/Pompem-dev#
(.env)root@kali:~/Pompem-dev# python pompem.py -h

Options:
  -h, --help                      show this help message and exit
  -s, --search   text for search
  --txt                           Write txt File
  --html                          Write html File
  --update                        upgrade to latest version
  -g, --get                       Download exploit files


Ejemplos de uso:

python pompem.py -s Wordpress
python pompem.py -s Joomla --html
python pompem.py -s "Internet Explorer,joomla,wordpress" --html
python pompem.py -s FortiGate --txt
python pompem.py -s ssh,ftp,mysql
python pompem.py -s "joomla" -g
python pompem.py --update


Página del proyecto: https://github.com/rfunix/Pompem

Pescando WPA2 con Linset

$
0
0
Atacar redes wireless se ha convertido desde hace tiempo en un deporte, una diversión o un hobby.

Y cuando digo deporte, diversión o hobby es literal el uso que quiero dar a esta frase: hay "gente despreciable" a los que cuando se les acaban los temas de conversación incluso se juegan las cañas a ver quien es el primero en fundir la "seguridad" de un AP en menos tiempo.

En una de estas competiciones absurdas, fue sorprendente la rapidez (con bastante churro...) con la que unos de estos "borrachos despreciables" se hizo con el premio gordo.

La curiosidad me embargó y, como curioso soy un rato, me abalancé a su portátil..

Es aquí donde conocí la herramienta que os presento hoy:
 

El concepto no es nada nuevo, ya conocíamos que este vector de ataque existía, lo que realmente me sorprendió (aparte de lo bien pensada y realizada la aplicación) es su efectividad,  realmente me resultó extraño, la candidez de muchos usuarios. 

Para el que no conozca el script lo puede bajar y echar un vistazo desde:
 
git clone https://github.com/vk496/linset.git linset/

Tras ésto, lo único que hay que hacer es darle permisos y arrancar el script
... y ejecutarlo:
 
./linset
 

Linset se cargará y en el caso de que no tengamos todas las dependencias cumplidas, nos avisará de este hecho.

Linset, tras seguir nuestras indicaciones, se encargará sola de escanear e informarnos de los clientes conectados a las redes víctima, de configurar y arrancar un dhcp, hostapd y de tirar a los usuarios del AP legítimo:
 

...dándoles como única opción nuestro FAKE AP, a través de cual para conectarlos a Internet les pedirá mediante una bonita y engañosa webpage su contraseña wpa..

Aparte de este ataque tiene otro que trabaja sobre el handshake por fuerza bruta o diccionario, que poco difiere de otros scripts.. 

un saludo.

Ejercicios para aprender ingeniería inversa y exploiting

$
0
0
El francés Wannes Rombouts aka @wapiflapi tiene un proyecto en GitHub con un montón de ejercicios diseñados para solucionarse con NX + ASLR sin depender de que libc se utiliza. La idea es que sólo debe interactuar con stdin/stdout como si fuera un servicio remoto, argv y env no son necesarios para la explotación. Ya tenemos diversión para no dormir en unas cuantas noches:

https://github.com/wapiflapi/exrs

pd. Premio para cualquier amante del reversing que publique en el blog el writeup de uno de los ejercicios ;)

Casi 250.000 routers de Telefónica en España son vulnerables porque tienen las mismas claves SSH

$
0
0
Hoy en el blog de Shodan leía una interesante entrada de John Matherly en el que, mediante el siguiente script, observaba que en Internet existen numerosos fingerprints SSH duplicados:
import shodan

api = shodan.Shodan(YOUR_API_KEY)

# Get the top 1,000 duplicated SSH fingerprints
results = api.count('port:22', facets=[('ssh.fingerprint', 1000)])

for facet in results['facets']['ssh.fingerprint']:
    print '%s --> %s' % (facet['value'], facet['count'])

Realmente esto no es nada nuevo ya que desde hace unos cuantos años se sabe que algunos fabricantes comenten el error de no borrar las claves SSH antes de salvar (y luego distribuir) la imagen de los firmwares de sus dispositivos embebidos, que luego no regeneran las claves en el primer boot. Incluso hay proyectos que recopilan las claves duplicadas: https://code.google.com/p/littleblackbox/.

Pero lo sorprendente es que hay un fingerprint que se repite en un país y con un proveedor en gran número con respecto al resto:

https://www.shodan.io/search?query=fingerprint




Se trata de España y de Telefónica que distribuye casi 250.000 routers para fibras domésticas o FFTH modelo Comtrend VG-8050 con un firmware que contiene un servidor SSH ligero (dropbear 0.46) con las mismas claves ssh:

SSH-2.0-dropbear_0.46
Key type: ssh-rsa
Key: AAAAB3NzaC1yc2EAAAADAQABAAAAgwCKj10BLi11/oSbukFArKJZTXvBvw+AUGfie6fdE7psCNwC
LM5bYnJgjQZMP/VOhJkxkA539e2mM4fW9U4ECAUwgvlF9AZGhcmn0kF0jIjMUDgCV8kFIS85OuBU
/ayyswdYp6bxp3zn0tGAh0Ty8ikf7CgWU5c+PCbpygbBxMDfZM9P
Fingerprint: dc:14:de:8e:d7:c1:15:43:23:82:25:81:d2:59:e8:c0

Esto significa que hay casi 250.000 usuarios en España que son vulnerables. Muchos de ellos corren por defecto ssh con las credenciales también por defecto 1234/1234 (estos directamente están jodidos vendidos) y todos ellos son susceptibles a ataques MiTM en el que cualquiera podría descifrar sus comunicaciones.

 
El firmware vulnerable es (al menos) el SB01-S412TLF-C07_R03 de 2014 y, que yo sepa, la última versión es la C08_R08. Así que si eres usuario de Telefónica pregunten a su soporte Movistar y ¡actualicen!

Cómo dumpear las claves SSH desde el firmware de un router

$
0
0
Algunos me preguntáis como sacar las claves ssh de los routers en referencia a la entrada de anoche. Os veo venir... pero bueno, veremos rápidamente como hacerlo extrayendo la imagen del firmware de un router ;)

En esta ocasión sin embargo vamos a dejar al *pobre* Comtrend VG-8050 y vamos a ir a por el D-Link Dsl-2750u (la belleza de la derecha). En concreto vamos a echar un vistazo a una de las versiones de firmware que también viene con un demonio Dropbear 0.46 con "premio": la ME_1.11 de octubre de 2013:

http://www.dlinkmea.com/partner/media/product_item_downloadables/1351-DSL2750U-U1_FW1.11.rar

Después de descargar los menos de 7mb que ocupa el rar, lo descomprimimos y analizamos la imagen con Binwalk, el estándar de facto para el análisis de firmwares:

root@kali:~/firmwares# file GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img 
GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img: data

root@kali:~/firmwares# binwalk GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 5402908 bytes
1722624       0x1A4900        Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 5080877 bytes,  1142 inodes, blocksize: 262144 bytes, created: Thu Oct 24 07:46:30 2013

Como veis el filesystem es SquashFS, uno de los más ampliamente utilizados en sistemas con Linux embebido, y está comprimido con LZMA en lugar del estandar zlib (algo que también suelen hacer):
root@kali:~# binwalk --dd='squashfs:squashfs' GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 5402908 bytes
1722624       0x1A4900        Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 5080877 bytes,  1142 inodes, blocksize: 262144 bytes, created: Thu Oct 24 07:46:30 2013

root@kali:~/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted# file 1A4900.squashfs
1A4900.squashfs: Squashfs filesystem, little endian, version 4.0, 5080877 bytes, 1142 inodes, blocksize: 262144 bytes, created: Thu Oct 24 07:46:30 2013

El siguiente paso es extraer la imagen y, para ello, vamos a instalar y utilizar la utilidad unsquashfs-2.1 de Jeremy Collake:

apt-get install liblzo2-dev 
git clone https://github.com/devttyS0/sasquatch
make

root@kali:~/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted# ./sasquatch/sasquatch 1A4900.squashfs
SquashFS version [4.0] / inode count [1142] suggests a SquashFS image of the same endianess
Parallel unsquashfs: Using 1 processor
Trying to decompress using default lzma decompressor...
Successfully decompressed with default lzma decompressor
1083 inodes (1113 blocks) to write

[=============================================================\] 1113/1113 100%

created 679 files
created 59 directories
created 123 symlinks
created 281 devices
created 0 fifos

Ahora veremos el filesystem colgando del directorio squashfs-root, por lo que sólo tenemos que ir a pescar nuestras claves...

root@kali:~/firmwares/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted# cd squashfs-root/etc/dropbear/
root@kali:~/firmwares/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted/squashfs-root/etc/dropbear# ls -las
total 16
4 drwxr-xr-x  2 594 594 4096 Oct 24  2013 .
4 drwxr-xr-x 10 594 594 4096 Oct 24  2013 ..
4 -rwxr-xr-x  1 594 594  459 Oct 24  2013 dropbear_dss_host_key
4 -rwxr-xr-x  1 594 594  427 Oct 24  2013 dropbear_rsa_host_key

... y con la herramienta dropbearkeymostrar la clave pública:

root@kali:~/firmwares/_GAN9.9T113A-B-DL-DSL2750U-R5B0024-Dubai.EN_2T2R_text_for_lan_update.img.extracted/squashfs-root/etc/dropbear# dropbearkey -y -f dropbear_rsa_host_key
Public key portion is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgwCAmPVBs6DX2/2G6NcLwFI6jP055kbQzxGNNaYngPhR3TT9MMiGnR2waCQYrZq0n7D+RKu9tEiYU05tPiaMqm5z4qHq2OePKIL4jFhcTJk8p0yz1IpPp9FJjvZ6Daw4Mvr+r+RNNnSTn7Iq7bIxWyNgXnQc7Lx7IPmm8JDqskFEtOC7 root@kali
Fingerprint: md5 63:05:01:4f:cd:09:6d:ad:ed:95:ae:89:19:2c:b8:bc

Finalmente sólo nos queda buscar el fingerprint correspondiente:

Link shodan


y tenemos otros 40.000 equipos cuyas comunicaciones podremos descifrar :)

Recupera todas tus contraseñas en local con LaZagne

$
0
0
El proyecto LaZagne de Alessandro Zanni tiene como objetivo desarrollar una herramienta de código abierto capaz de recuperar un montón de contraseñas almacenadas en el equipo de forma local. Cada software almacena sus contraseñas utilizando diferentes técnicas (texto plano, utilizando apis, algoritmos personalizados, etc.). Esta herramienta ha sido desarrollada para encontrar las contraseñas de los programas más comunes y, por el momento, es compatible con 22 aplicaciones de Windows y 12 de Linux:


Su uso es muy sencillo, simplemente ejecutamos laZagne.exe con el parámetro correspondiente: {all, browsers, chats, mails, adminsys, database, svn, wifi, windows}:
 

Para más información visita la página del proyecto: https://github.com/AlessandroZ/LaZagne.

11 formas de seguir tus movimientos a través del navegador web

$
0
0
Hay distintas formas de rastrear a los usuarios cuando acceden a un sitio web en particular. Algunas de ellas son más "siniestras" que otras. La mayoría de las aplicaciones web requieren algún tipo de seguimiento de sesión para mantener el estado del usuario. Esto normalmente se realiza fácilmente utilizando cookies bien configuradas (aunque esto no entra dentro del alcance de esta entrada). Una sesión está destinada a ser efímera y no persistirá por mucho tiempo.

Por otro lado, algunos métodos intentan realizar el seguimiento del usuario durante un largo tiempo, y, en particular, intentan hacer que sea difícil evadir el seguimiento. Esto se hace a veces para fines publicitarios, pero también se puede hacer para detener ciertos ataques como ataques de fuerza bruta o para identificar atacantes que vuelven a un sitio. En el peor de los casos, desde una perspectiva privada, el seguimiento se realiza para seguir un individuo a través de distintos sitios web.

Con los años, los navegadores y plugins han proporcionado un número de maneras de limitar este seguimiento. Estas son algunas de las técnicas más comunes de cómo se hace el seguimiento y la forma en que el usuario puede evitar (algunos):

1 - Cookies

Las cookies tienen el propósito de mantener el estado entre diferentes peticiones. Un navegador enviará una cookie con cada solicitud, una vez que se establece para un sitio en particular. Desde el punto de vista de la privacidad, la fecha de caducidad y el dominio de la cookie son los ajustes más importantes. La mayoría de los navegadores rechazan las cookies de cuentas de un sitio diferente, a menos que el usuario permita que estas cookies se establezcan. Una cookie de sesión correcta no debe usar fecha de caducidad, ya que debe expirar tan pronto como se cierra el navegador. La mayoría de navegadores permiten revisar, controlar y eliminar las cookies. En el pasado, se propuso una cabecera "Cookie2" para las cookies de sesión, pero esta cabecera se desaprobó y el navegador dejó de soportarlo.

https://www.ietf.org/rfc/rfc2965.txt
http://tools.ietf.org/html/rfc6265


2 - Las cookies de Flash (objetos compartidos locales)

Flash tiene su propio mecanismo de persistencia. Estas "flash cookies" son archivos que se pueden dejar en el cliente. Estos no se pueden establecer en nombre de otros sitios ("Cross-Origin"), pero una secuencia de comandos SWF puede exponer el contenido de un LSO (Local Shared Object) a otros scripts que pueden ser utilizados para implementar el almacenamiento cross-origin. La mejor manera de evitar que las cookies flash de seguimiento es desactivar flash. La gestión de las cookies de flash es complicada y por lo general requiere plugins especiales.

https://helpx.adobe.com/flash-player/kb/disable-local-shared-objects-flash.html

3 - Dirección IP

La dirección IP es probablemente el mecanismo de seguimiento más básico de todas las comunicaciones basadas en IP, pero no siempre es fiable ya que las direcciones IP de los usuarios pueden cambiar en cualquier momento, y varios usuarios a menudo comparten la misma dirección IP.
Se puede utilizar varios productos o sistemas VPN como Tor para evitar el seguimiento de la dirección IP, pero por lo general esto tiene un impacto en el rendimiento. Algunas extensiones modernas de JavaScript (RTC en particular) se pueden utilizar para recuperar la dirección IP interna de un usuario, que puede ser utilizado para resolver ambigüedades introducidas por NAT. Pero RTC no está implementado en todos los navegadores. IPv6 puede proporcionar métodos adicionales para identificar la dirección IP de los usuarios ya que es menos probable que salgan con NAT.

http://ipleak.net

4 - Agente de usuario

La cadena de agente de usuario enviada por un navegador casi nunca es única por defecto, pero a veces el spyware modifica el User-Agent para agregar valores únicos a ella. Muchos navegadores permiten ajustar el User-Agent y, más recientemente, los navegadores comienzan a reducir la información en el User-Agent o incluso hacen algo dinámico para que coincida con el contenido previsto. Los plugins anti-spyware a veces modifican el User-Agent para indicar soporte para funciones específicas.

5 - Fingerprinting del navegador

Un navegador web casi nunca es una pieza monolítica de software. En su lugar, los navegadores web interaccionan con varios plugins y extensiones que el usuario puede haber instalado. Estudios anteriores han demostrado que la combinación de versiones de plugins y opciones de configuración seleccionadas por el usuario tienden a ser increíblemente únicas y esta técnica se ha utilizado para obtener identificadores únicos. No hay mucho que se pueda hacer para evitar esto, aparte de reducir al mínimo el número de plugins que se instalan (pero que puede ser un indicador en sí mismo).

https://panopticlick.eff.org

6 - Almacenamiento local

HTML 5 ofrece dos nuevas formas de almacenar datos en el cliente: almacenamiento local y almacenamiento de las sesiones. El almacenamiento local es más útil para el almacenamiento persistente en el cliente, y facilita el seguimiento de los usuarios. El acceso a almacenamiento local se limita al sitio que envió los datos. Algunos navegadores implementan características de depuración que permiten al usuario revisar los datos almacenados. El almacenamiento de sesión es limitado a una ventana particular y se quita tan pronto como se cierra la ventana.

https://html.spec.whatwg.org/multipage/webstorage.html

7 - Contenido en caché

Los navegadores cachean el contenido de la caché en base a las cabeceras de caducidad proporcionadas por el servidor. Una aplicación web puede incluir contenido único en una página y, a continuación, utilizar JavaScript para comprobar si el contenido se almacena en caché o no con el fin de identificar a un usuario. Esta técnica se puede implementar utilizando imágenes, fuentes o prácticamente cualquier contenido. Es difícil defenderse a menos que rutinariamente (por ejemplo, con el cierre del navegador) se elimine todo el contenido. Algunos navegadores permiten no almacenar en caché ningún contenido en absoluto. Pero esto puede causar problemas de rendimiento importantes. Recientemente Google ha sido visto usando fuentes tipográficas para el seguimiento de los usuarios, pero la técnica no es nueva. El caché de JavaScript se puede utilizar fácilmente para establecer los ID de rastreo único.

http://robertheaton.com/2014/01/20/cookieless-user-tracking-for-douchebags/
http://fontfeed.com/archives/google-webfonts-the-spy-inside/

8 - Fingerprinting de canvas

Esta es una técnica más reciente y, en esencia, una forma especial de fingerprinting de navegador. HTML 5 introduce un API "Canvas" que permite a JavaScript dibujar una imagen en su navegador. Además, es posible leer la imagen que se ha creado. Pues resulta que, configuraciones de fuentes y otros parámetros son lo suficientemente únicos para dar lugar a imágenes ligeramente diferentes cuando se utiliza el mismo código de JavaScript para dibujar la imagen. Estas diferencias pueden ser utilizadas para derivar en un identificador de navegador. No hay mucho que se pueda hacer para evitar que esto suceda ya que ningún un navegador permite desactivar la función de canvas.

https://securehomes.esat.kuleuven.be/~gacar/persistent/index.html

9 - Inyección de cabeceras Carrier

Verizon propuso recientemente la inyección de cabeceras específicas en las peticiones HTTP para identificar a los usuarios. Como esto se hace "al vuelo", sólo funciona para HTTP y no para HTTPS. A cada usuario se le asigna un ID específico y el ID es inyectado en todas las peticiones HTTP como cabecera X-UIDH. Verizon ofrece un servicio de pago para que un sitio web pueda utilizarlo para recuperar información demográfica sobre el usuario. Pero sólo por sí mismo, la cabecera se puede utilizar para realizar un seguimiento de usuarios, ya que permanece ligada al usuario durante un tiempo prolongado.

http://webpolicy.org/2014/10/24/how-verizons-advertising-header-works/

10 - Redirecciones

Esto es un poco una variación en el seguimiento de "contenido en caché". Si un usuario es redireccionado mediante un código "301" ("Redirección permanente"), entonces el navegador recordará la redirección e irá a la página de destino de inmediato, sin visitar la página original en primer lugar. Así, por ejemplo, si se hace clic en un enlace para "isc.sans.edu", se podría redirigir a "isc.sans.edu/index.html?id=sometrackingid" y la próxima vez que vaya a "isc.sans.edu", el navegador automáticamente irá directo a la segunda URL. Esta técnica es menos fiable que otras ya que los navegadores difieren en cómo redireccionan caché.

https://www.elie.net/blog/security/tracking-users-that-block-cookies-with-a-http-redirect

11 - Recreación/Sincronización de Cookies

Algunos de los métodos anteriores tienen contramedidas bastante simples. Con el fin de hacer más difícil que los usuarios eviten el seguimiento, los sitios suelen combinar diferentes métodos y "recrean" las cookies. Esta técnica es a veces llamada "Evercookie". Si el usuario elimina, por ejemplo, la cookie HTTP, pero no el flash de la cookie, el flash de la cookie se utiliza para volver a crear la cookie HTTP en la próxima visita del usuario.

https://www.cylab.cmu.edu/files/pdfs/tech_reports/CMUCyLab11001.pdf

Fuente: 11 Ways To Track Your Moves When Using a Web Browser

Clonar un portal Moodle (y más) en dos patadas con wget

$
0
0
Andaba yo viendo una manera efectiva y rápida para clonar un sitio web, buscando la mejor herramienta tipo Teleport Pro o HTTrack, cuando un compi me comentó que wget es bastante potable incluso para spidering/crawling. Y tanto que sí. Basta echar un vistazo al manual de la herramienta para darse cuenta de que wget no sólo vale para descargar un simple fichero, si no que tiene muchísimas opciones y parámetros que se pueden adaptar según el sitio web que quieras duplicar.

Sirva de ejemplo el de esta entrada con el que es posible crear un mirror de cualquier portal que use Moodle, ya sabéis, un sistema de gestión de cursos de formación. Imaginaros lo rápido que obtendríamos una copia de un curso en concreto que nos interesara para poder consultarlo offline cuando nos vamos de viaje...

Primero obtenemos la cookie ya que, evidentemente, la autenticación en Moodle se realiza mediante un formulario de login:

wget --load-cookies my-cookies.txt \
--post-data='username=YOUR_USERNAME&password=YOUR_PASSWORD&testcookies=1'
--save-cookies=my-cookies.txt --keep-session-cookies http://moodlesite.com/

Luego, con dicha cookie, comenzamos con el mirror mediante los siguientes parámetros:

wget --load-cookies my-cookies.txt --keep-session-cookies --save-cookies my-cookies.txt\
--referer=http://moodlesite.com/login/index.php -m -E -k
--reject logout*,*cal_m*,*cal_y*,post.php*,*subscribe*,help.php*,enrol.php*
--exclude-directories=/calendar http://moodlesite.com/course/view.php?id=XXX
-m: activa el mirroring. Es equivalente a ‘-r -N -l inf –no-remove-listing’
-E: si un fichero de tipo ‘application/xhtml+xml’ o ‘text/html’ es descargado y la URL no termina con la regexp ‘\.[Hh][Tt][Mm][Ll]?’, esta opción pondrá el sufijo ‘.html’
-k: después de que la descarga se complete, convierte los enlaces para hacerlos accesibles de forma local.
--exclude-directories: directorios que el crawler saltará.
--reject: indica los ficheros que wget no salvará al disco

Y básicamente esto sería lo suficiente para empezar y hacer un mirror de un portal Moodle. Luego podríamos hacer menos "ruido" modificando el user-agent, usando un proxy (Tor!), añadiendo pausas entre descargas, etc. Así que toca empezar a cocinar algunas pruebecillas:

wget -r -l 0 -U Mozilla -t 1 -nd -D playboy.com -A jpg,jpeg,gif,png "http://www.playboy.com" -e robots=off

Libro: Detectando malicia (Detecting Malice, Fraud Loss Prevention eBook)

$
0
0
Cada día se cometen fraudes en sitios web y este libro ayuda a detectar si algo oscuro está ocurriendo en el tuyo...

Detectando Malicia, en inglés Detecting Malice, es un libro escrito por Robert "RSnake" Hansen (ha.ckers.org) para ayudar a los administradores web, los desarrolladores, el personal de operaciones y los managers de productos de seguridad en la construcción y el mantenimiento de un estado de seguridad elevado.

La comprensión de la intención del usuario es la clave para reducir los ratios de fraude en las aplicaciones web modernas. Desde pymes al gobierno, este libro abarca muchos ámbitos diferentes de fraude y cómo detectarlo en muchas capas diferentes.

Desde DNS y TCP al contenido embebido y el fingerprinting del navegador se utilizan para identificar a los usuarios que tienen más probabilidades de llegar a ser peligrosos antes de que el ataque suceda. Una gran cantidad de técnicas y ejemplos están disponibles en las más de 300 páginas de este interesante libro.


Tabla de contenidos:
 Detecting Malice: Preface
    User Disposition
    Deducing Without Knowing
    Book Overview
    Who Should Read This Book?
    Why Now?
    A Note on Style
    Working Without a Silver Bullet
    Special Thanks
  Chapter 1 - DNS and TCP: The Foundations of Application Security
    In the Beginning Was DNS
    Same-Origin Policy and DNS Rebinding
    DNS Zone Transfers and Updates
    DNS Enumeration
    TCP/IP
    Spoofing and the Three-Way Handshake
    Passive OS Fingerprinting with pOf
    TCP Timing Analysis
    Network DoS and DDoS Attacks
    Attacks Against DNS
    TCP DoS
    Low Bandwidth DoS
    Using DoS As Self-Defense
    Motives for DoS Attacks
    DoS Conspiracies
    Port Scanning
    With That Out of the Way...
  Chapter 2 - IP Address Forensics
    What Can an IP Address Tell You?
    Reverse DNS Resolution
    WHOIS Database
    Geolocation
    Real-Time Block Lists and IP Address Reputation
    Related IP Addresses
    When IP Address Is A Server
    Web Servers as Clients
    Dealing with Virtual Hosts
    Proxies and Their Impact on IP Address Forensics
    Network-Level Proxies
    HTTP Proxies
    AOL Proxies
    Anonymization Services
    Tor Onion Routing
    Obscure Ways to Hide IP Address
    IP Address Forensics
    To Block or Not?
  Chapter 3 - Time
    Traffic Patterns
    Event Correlation
    Daylight Savings
    Forensics and Time Synchronization
    Humans and Physical Limitations
    Gold Farming
    CAPTCHA Breaking
    Holidays and Prime Time
    Risk Mitigation Using Time Locks
    The Future is a Fog
  Chapter 4 - Request Methods and HTTP Protocols
    Request Methods
    GET
    POST
    PUT and DELETE
    OPTIONS
    CONNECT
    HEAD
    TRACE
    Invalid Request Methods
    Random Binary Request Methods
    Lowercase Method Names
    Extraneous White Space on the Request Line
    HTTP Protocols
    Missing Protocol Information
    HTTP 1.0 vs. HTTP 1.1
    Invalid Protocols and Version Numbers
    Newlines and Carriage Returns
    Summary
  Chapter 5 - Referring URL
    Referer Header
    Information Leakage through Referer
    Disclosing Too Much
    Spot the Phony Referring URL
    Third-Party Content Referring URL Disclosure
    What Lurks in Your Logs
    Referer and Search Engines
    Language, Location, and the Politics That Comes With It
    Google Dorks
    Natural Search Strings
    Vanity Search
    Black Hat Search Engine Marketing and Optimization
    Referring URL Availability
    Direct Page Access
    Meta Refresh
    Links from SSL/TLS Sites
    Links from Local Pages
    Users' Privacy Concerns
    Determining Why Referer Isn't There
    Referer Reliability
    Redirection
    Impact of Cross-Site Request Forgery
    Is the Referring URL a Fake?
    Referral Spam
    Last thoughts
  Chapter 6 - Request URL
    What Does A Typical HTTP Request Look Like?
    Watching For Things That Don’t Belong
    Domain Name in the Request Field
    Proxy Access Attempts
    Anchor Identifiers
    Common Request URL Attacks
    Remote File Inclusion
    SQL Injection
    HTTP Response Splitting
    NUL Byte Injection
    Pipes and System Command Execution
    Cross-Site Scripting
    Web Server Fingerprinting
    Invalid URL Encoding
    Well-Known Server Files
    Easter Eggs
    Admin Directories
    Automated Application Discovery
    Well-Known Files
    Crossdomain.xml
    Robots.txt
    Google Sitemaps
    Summary
  Chapter 7 - User-Agent Identification
    What is in a User-Agent Header?
    Malware and Plugin Indicators
    Software Versions and Patch Levels
    User-Agent Spoofing
    Cross Checking User-Agent against Other Headers
    User-Agent Spam
    Indirect Access Services
    Google Translate
    Traces of Application Security Tools
    Common User-Agent Attacks
    Search Engine Impersonation
    Summary
  Chapter 8 - Request Header Anomalies
    Hostname
    Requests Missing Host Header
    Mixed-Case Hostnames in Host and Referring URL Headers
    Cookies
    Cookie Abuse
    Cookie Fingerprinting
    Cross Site Cooking
    Assorted Request Header Anomalies
    Expect Header XSS
    Headers Sent by Application Vulnerability Scanners
    Cache Control Headers
    Accept CSRF Deterrent
    Language and Character Set Headers
    Dash Dash Dash
    From Robot Identification
    Content-Type Mistakes
    Common Mobile Phone Request Headers
    X-Moz Prefetching
    Summary
  Chapter 9 - Embedded Content
    Embedded Styles
    Detecting Robots
    Detecting CSRF Attacks
    Embedded JavaScript
    Embedded Objects
    Request Order
    Cookie Stuffing
    Impact of Content Delivery Networks on Security
    Asset File Name Versioning
    Summary
  Chapter 10 - Attacks Against Site Functionality
    Attacks Against Sign-In
    Brute-Force Attacks Against Sign-In
    Phishing Attacks
    Registration
    Username Choice
    Brute Force Attacks Against Registration
    Account Pharming
    What to Learn from the Registration Data
    Fun With Passwords
    Forgot Password
    Password DoS Attacks
    Don’t Show Anyone Their Passwords
    User to User Communication
    Summary
  Chapter 11 - History
    Our Past
    History Repeats Itself
    Cookies
    JavaScript Database
    Internet Explorer Persistence
    Flash Cookies
    CSS History
    Refresh
    Same Page, Same IP, Different Headers
    Cache and Translation Services
    Uniqueness
    DNS Pinning Part Two
    Biometrics
    Breakout Fraud
    Summary
  Chapter 12 - Denial of Service
    What Are Denial Of Service Attacks?
    Distributed DoS Attacks
    My First Denial of Service Lesson
    Request Flooding
    Identifying Reaction Strategies
    Database DoS
    Targeting Search Facilities
    Unusual DoS Vectors
    Banner Advertising DoS
    Chargeback DoS
    The Great Firewall of China
    Email Blacklisting
    Dealing With Denial Of Service Attacks
    Detection
    Mitigation
    Summary
  Chapter 13 - Rate of Movement
    Rates
    Timing Differences
    CAPTCHAs
    Click Fraud
    Warhol or Flash Worm
    Samy Worm
    Inverse Waterfall
    Pornography Duration
    Repetition
    Scrapers
    Spiderweb
    Summary
  Chapter 14 - Ports, Services, APIs, Protocols and 3rd Parties
    Ports, Services, APIs, Protocols, 3rd Parties, oh my…
    SSL and Man in the middle Attacks
    Performance
    SSL/TLS Abuse
    FTP
    Webmail Compromise
    Third Party APIs and Web Services
    2nd Factor Authentication and Federation
    Other Ports and Services
    Summary
  Chapter 15 - Browser Sniffing
    Browser Detection
    Black Dragon, Master Reconnaissance Tool and BeEF
    Java Internal IP Address
    MIME Encoding and MIME Sniffing
    Windows Media Player “Super Cookie”
    Virtual Machines, Machine Fingerprinting and Applications
    Monkey See Browser Fingerprinting Software – Monkey Do Malware
    Malware and Machine Fingerprinting Value
    Unmasking Anonymous Users
    Java Sockets
    De-cloaking Techniques
    Persistence, Cookies and Flash Cookies Redux
    Additional Browser Fingerprinting Techniques
    Summary
  Chapter 16 - Uploaded Content
    Content
    Images
    Hashing
    Image Watermarking
    Image Steganography
    EXIF Data In Images
    GDI+ Exploit
    Warez
    Child Pornography
    Copyrights and Nefarious Imagery
    Sharm el Sheikh Case Study
    Imagecrash
    Text
    Text Stenography
    Blog and Comment Spam
    Power of the Herd
    Profane Language
    Localization and Internationalization
    HTML
    Summary
  Chapter 17 - Loss Prevention
    Lessons From The Offline World
    Subliminal Imagery
    Security Badges
    Prevention Through Fuzzy Matching
    Manual Fraud Analysis
    Honeytokens
    Summary
  Chapter 18 - Wrapup
    Mood Ring
    Insanity
    Blocking and the 4th Wall Problem
    Booby Trapping Your Application
    Heuristics Age
    Know Thy Enemy
    Race, Sex, Religion
    Profiling
    Ethnographic Landscape
    Calculated Risks
    Correlation and Causality
    Conclusion
  About Robert Hansen
Web del libro:http://www.detectmalice.com/

Configurar SSL en Tomcat parte 1 - preparar el keystore

$
0
0
Al publicar un servidor Tomcat en Internet es recomendable permitir sólo HTTPS y acceder a él mediante un certificado digital firmado por una CA.
El proceso para activar SSL en Tomcat se divide en dos partes: 1/ crear un keystore funcional y 2/ configurar los conectores y aplicaciones para usar SSL. En esta primera entrada de una serie de dos, veremos las primera parte acerca del keystore.

Las claves que Tomcat usará para las transacciones SSL se almacenan en un fichero protegido por contraseña llamado "keystore". El formato de este fichero es el estándar de Java o JKS ("Java KeyStore") y es creado por la utilidad keytool que incluye el JDK. Para ello podemos hacerlo de dos formas:

- importando una clave existente:

keytool -import -alias prueba -file certificado.cer -keystore mi_keystore.jks -storepass changeit

-  o creando un nuevo keystore desde 0:

keytool -genkey -alias prueba -keyalg RSA -keysize 2048 -keystore mi_keystore.jks

Enter keystore password:

What is your first and last name?
  [Unknown]:  www.prueba.com
What is the name of your organizational unit?
  [Unknown]:  IT
What is the name of your organization?
  [Unknown]:  COMPANIA
What is the name of your City or Locality?
  [Unknown]:  Madrid
What is the name of your State or Province?
  [Unknown]:  Madrid
What is the two-letter country code for this unit?
  [Unknown]:  SP
Is CN=www.prueba.com, OU=IT, O=COMPANIA, L=Madrid, ST=Madrid, C=SP correct?
  [no]:  yes

Enter key password for
        (RETURN if same as keystore password):

       
Una vez que tengamos preparado el keystore, el siguiente paso será crear el fichero CSR (Certificate Signing Request) que enviaremos a la CA de turno para que nos devuelva el certificado SSL definitivo, que es el que presentaremos a terceros durante el handshake SSL. El comando es:
       
keytool -certreq -keyalg RSA -alias prueba -file certreq.csr -keystore mi_keystore.jks
       
Después de la CA nos genere y envíe el certificado (tras previo pago si no tenemos SANs/wildcard) procederemos a instalarlo, aunque previamente tendremos que importar su certificado raíz para respetar la "cadena de confianza" SSL:

keytool -import -alias root -keystore mi_keystore.jks -trustcacerts -file root_certificate

Y finalmente:

keytool -import -alias prueba -keystore mi_keystore.jks -file certificado.cer

Configurar SSL en Tomcat parte 2 - configurar el conector y la aplicación web

$
0
0
Para configurar SSL en Tomcat en la entrada anterior veíamos como preparar el keystore e instalar un certificado firmado por una CA. Ahora veremos cómo configurar el conector (por defecto AJP) y la webapp correspondiente para usar SSL.

Empezaremos editando el fichero de configuración del servidor "$CATALINA_BASE/conf/server.xml" y añadiremos un conector (o descomentaremos los existentes):

<Connector connectionTimeout="20000"port="80" protocol="HTTP/1.1"redirectPort="443" server="prueba"/>
 ...

 <Connector
    SSLEnabled="true" acceptCount="100" clientAuth="false"
    disableUploadTimeout="true" enableLookups="false" maxThreads="25"
    port="443"keystoreFile="mi_keystore.jks"keystorePass="mi_contraseña"
    protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https"
    secure="true" sslProtocol="TLS" />
   
Fijaros que hemos especificado la ruta del keystore creado anteriormente y la contraseña correspondiente. Al reiniciar Tomcat el servidor debería ser ya accesible mediante https://servidor/prueba.

Después forzaremos que la aplicación web funcione con SSL.
Para ello añadiremos el siguiente código en el fichero $CATALINA_HOME/webapps/prueba/WEB-INF/web.xml justo antes del cierre del tag </web-app>:

<!-- redireccion a https -->
  <security-constraint>
        <web-resource-collection>
                <web-resource-name>Automatic SSL Forward</web-resource-name>
                <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <user-data-constraint>
                <transport-guarantee>
                        CONFIDENTIAL
                </transport-guarantee>
        </user-data-constraint>
  </security-constraint>


</web-app>
 
Evidentemente podemos modificar el patrón de URLs para especificar qué páginas queremos proteger y cuáles no.
Por ejemplo, si queremos que sólo se use SSL cuando se visitan las páginas del path /usuarios:

<security-constraint>

    <web-resource-collection>
        <web-resource-name>Members Folder</web-resource-name>
        <url-pattern>/usuarios/*</url-pattern>
    </web-resource-collection>

    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>

</security-constraint>

O si queremos que se use HTTPS para todo excepto para /img (favicon) y /css:

<security-constraint>
        <web-resource-collection>
            <web-resource-name>HTTPSOnly</web-resource-name>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <user-data-constraint>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>HTTPSOrHTTP</web-resource-name>
            <url-pattern>*.ico</url-pattern>
            <url-pattern>/img/*</url-pattern>
            <url-pattern>/css/*</url-pattern>
        </web-resource-collection>
        <user-data-constraint>
            <transport-guarantee>NONE</transport-guarantee>
        </user-data-constraint>
    </security-constraint>

Un fallo en la web de GoPro revela las contraseñas WiFi de las cámaras de sus usuarios

$
0
0
Las cámaras GoPro tienen fama de ser ligeras y ultra-resistentes. La gente las usa para el ciclismo de montaña, motociclismo e incluso para los deportes acuáticos.
La popular 'action cams' pueden controlarse desde el smartphone a través de una aplicación que te permite grabar, acceder a tus fotos o subirlas a las redes sociales. Para hacerlo, el usuario tiene que conectarse a un punto de acceso inalámbrico creado por la propia cámara mediante una contraseña definida por el usuario...

Ilya Chernyakov, un investigador de seguridad en Israel, intentaba recuperar la contraseña de la cámara de un amigo mediante el procedimiento del fabricante:

"Si necesitas 'resetear' la configuración de la wifi, tienes que seguir las instrucciones dadas en el sitio web de Gopro. Es un procedimiento bastante sencillo, 'Siguiente', 'Siguiente', 'Finalizar' y obtienes un enlace a un fichero ZIP. Hay que descargar el fichero, y copiarlo a la tarjeta SD, para finalmente reiniciar la cámara." explicó en su blog.


La sorpresa fue que el fichero ZIP contiene la configuración de la cámara("settings.in"), incluyendo las credenciales para acceder a la red wifi de la cámara en texto plano:



Después, comprobó que el enlace de descarga era accesible sin autenticación y que el ID de cada usuario estaba en la URL (en negrita a cont.) y era fácilmente predecible:

http://cbcdn2.gp-static.com/uploads/firmware-bundles/firmware_bundle/8605145/UPDATE.zip

Luego mediante un sencillo script en Python pudo obtener el fichero zip de unos 1.000 IDs y comprobar que, efectivamente, existe un fallo en la web de GoPro que expone las contraseñas WiFi de los usuarios:



Evidentemente nadie podrá acceder a la cámara de otro usuario si no está cerca, pero un atacante podría utilizar estas credenciales en otros sitios (¿os suena la fea costumbre de reutilizar las contraseñas?) o preparar ataques de diccionario "quirúrgicos".

Chernyakov notificó el fallo a GoPro, por lo que previsiblemente corregirán el fallo en breve.

"
Considero que la forma más rápida de mitigar el riesgo que sería reemplazar el número en el enlace por un GUID o algún otro tipo de valor generado que dificulte 'adivinar' otros enlaces válidos", dice Chernyakov, añadiendo que sería también una buena idea borrar la información de los servidores una vez se ha descargado el fichero. 

Libro: Hacking and Penetration Testing with Low Power Devices

$
0
0
Este libro de Philip Polstra editado por Syngress es una guía práctica que muestra cómo realizar pruebas de intrusión usando pequeños dispositivos de baja potencia que pueden ocultarse fácilmente y ser alimentados por baterías.

Concretamente se utiliza una distribución de pentesting y forense llamada The Deck, que funciona en BeagleBoard-xM, BeagleBone y BeagleBone Black y está optimizada para tener un consumo eléctrico muy bajo y que viene con distintos módulos para coordinar ataques mediante un ejercitó de dispositivos interconectados por 802.15.4 (MeshDeck), hacer investigación forense de dispositivos USB (4Deck) o delivery y pentesting de drones (AirDeck).

Tabla de contenidos:
Meet the Deck
A Brief Introduction to the Beagle Family
Installing a Base Operating System
Filling the Toolbox
Powering the Deck
Input and Output Devices
Building an Army of Devices
Keeping your Army Secret
Adding Air Support
Future Direction


ElServier:http://bit.ly/1pyT6wd
Amazon:http://amzn.to/1t4nQuc

μTorrent instala de forma silenciosa software de minería de bitcoins

$
0
0
Los usuarios que hayan instalado o actualizado el popular cliente de BitTorrent uTorrent 3.4.2 Build 28913 (mediados de enero - 6 de marzo) se han llevado también una desagradable sorpresa: también instala sin avisar un software de minado Bitcoins:

"Los usuarios del servicio de intercambio de archivos uTorrent se quejan de que la última actualización de software está instalando silenciosamente una pieza de software no deseada llamada Epic Scale, que es básicamente un software de minería de Bitcoins"


Realmente Epic Scale es un pequeño grupo de desarrolladores que juran y perjuran que destinan sus beneficios a la caridad (Watsi y Proyecto Inmunidad), porque están empezando y quieren tener una gran impacto. También quieren colaborar con investigaciones como la del UCSF para ayudar con los cálculos de genoma y algunos más. 

Eso está muy bien pero ¿no han pensado preguntar a los usuarios de μTorrent si quieren o no instalarlo?. Evidentemente lo han pensado, pero han decidido no hacerlo porque este famoso cliente de torrents tiene la nada despreciable cifra de 150 millones de usuarios al mes...

Además y para más inri el desinstalador no elimina (intencionadamente) completamente la aplicación y derivan a los usuarios a seguir unas instrucciones... en fin...


Fuente: http://www.reddit.com/r/technology/comments/2y4lar/popular_torrenting_software_%C2%B5torrent_has_included/
Viewing all 1671 articles
Browse latest View live