Suscribete a Mi Canal en YOUTUBE ==> da CLIC AQUÍ

Canal netamente académico donde se enseñará como atacan los ciberdelincuentes y como protegerse de estos ataques.

No me hago responsable del mal uso de los conocimientos adquiridos. Por Favor, Siempre ÉTICOS !

viernes, 19 de agosto de 2016

RetroScope: herramienta forense para recuperar las últimas imágenes de un dispositivo Android.

Imagina que un criminal tiene una conversación en Telegram con uno de sus contactos para facilitarle la dirección de recogida de cierta mercancía. Justo antes de enviar el mensaje que está escribiendo con la dirección, se da cuenta de que la policía le sigue y no lo manda, incluso borra todos los logs y cierra la sesión. Al rato la policía entra y confisca su smartphone y una hora después incauta la mercancía... ¿Cómo es posible que la policía supiera la dirección si no llegó a mandar el mensaje con la información?

Seguro que habéis pensado que el smartphone estaba troyanizado antes y las fuerzas de seguridad usaban un keylogger, pero no es el caso...

La policía usó la herramienta RetroScope, volcó la memoria del dispositivo y fue capaz de reconstruir las imágenes anteriores de forma similar a como se hizo en el siguiente video:

Url del video: https://www.youtube.com/watch?v=bsKTmZEgxiE

¿Impresionante verdad? La herramienta fue publicada por investigadores de la universidad Purdue de Indiana el pasado USENIX Security Symposium del 10-12 de agosto y usa el framework de renderizado de Android para recuperar las últimas imágenes de la memoria volátil con el comando redraw. Durante las demos fueron capaces de recuperar de 3 a 11 últimas imágenes de 15 aplicaciones diferentes. Sin duda un nuevo paradigma en la investigación forense de dispositivos móviles.

Proyecto: https://github.com/ProjectRetroScope/RetroScope

_______________________________
Tomado de: http://www.hackplayers.com/2016/08/retroscope-forense-imagenes-android.html?m=1
Se Respetan Derechos de Autor.

domingo, 14 de agosto de 2016

Denegación de servicio en Cisco IOS XR.

Cisco ha confirmado una vulnerabilidad en routers Cisco ASR 9001 Aggregation Servicescon Cisco IOS XR que podría permitir a un atacante remoto sin autenticar provocar condiciones de denegación de servicio.

El problema, con CVE-2016-6355, reside en el tratamiento inadecuado de paquetes fragmentados específicamente creados dirigidos al dispositivo afectado. Un ataque exitoso podría provocar una fuga de memoria en el procesador de rutas del dispositivo que provocaría la caída de los paneles de control de protocolo y la consiguiente condición de denegación de servicio.

El problema afecta a Cisco IOS XR versions 5.1.x, 5.2.x y 5.3.x, en routers Cisco ASR 9001 Aggregation Services.

Se ha solucionado en la versión de Cisco IOS XR 5.3.3, con las siguientes Software Maintenance Updates (SMUs):

asr9k-px-5.3.2.CSCux26791.pie para versiones 5.3.x

asr9k-px-5.2.4.CSCux26791.pie para versiones 5.2.x

asr9k-px-5.1.3.CSCux26791.pie para versiones 5.1.x

Más información:

Cisco IOS XR Software for Cisco ASR 9001 Aggregation Services Routers Fragmented Packet Denial of Service Vulnerability

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160810-iosxr

_________________________________

Tomado de: http://unaaldia.hispasec.com/2016/08/denegacion-de-servicio-en-cisco-ios-xr.html?m=1

Se Respetan Derechos de Autor.



viernes, 12 de agosto de 2016

Mitigación de ataques DDoS Syn Flood con iptables-SYNPROXY.

Ya hemos visto a lo largo de estos años, entradas anteriores con algunas contra-medidas para intentar detener ataques DDoS, diferentes scripts bash como DDoS Deflate y FloodMon para mitigar ataques de flood, módulos Anti-DDoS para servidor web Nginx, usar CloudFlare para proteger el tráfico web, y mitigaciones (sobretodo basadas en iptables y el kernel de Linux) contra ataques basados en UDP y ahora le toca el turno a las inundaciones basadas en TCP usando SYNPROXY (iptables/netfilter)


Ataques Denegación de Servicio (DoS) basados en TCP
  • SYN Flood
  • SYN-ACK Flood
  • ACK & PUSH ACK Flood
  • ACK Fragmentation Flood
  • RST/FIN Flood
La mayoría de los ataques TCP flooding son:

  • Ataques usando 3-Way HandShake (3WHS)


SYN-DDoS – es el conjunto de escenarios de ataques DDoS que explotan las peculiaridades de la realización del protocolo TCP (Transmission Control Protocol, protocolo de control de transmisión). El establecimiento de una conexión TCP transcurre en tres etapas, que recuerdan el proceso de dar un apretón de manos: El cliente envía un paquete con la bandera SYN. El servidor, al recibir el paquete SYN, responde con un paquete con encabezados SYN y ACK. Después, el cliente envía un paquete ACK, con lo que confirma la conexión. Durante el proceso de SYN-flood el atacante envía un paquete con la bandera SYN, pero no exige un paquete de respuesta con las banderas SYN+ACK para establecer la conexión, lo que obliga al servidor de la víctima a gastar recursos en el procesamiento de estas solicitudes y el envío de paquetes de respuesta.

TCP-DDoS – es el conjunto de escenarios de ataques que de la misma manera que SYN-flood, explotan las peculiaridades de la realización del protocolo TCP, pero al mismo tiempo establecen conexión con el servidor de la víctima. En los ataques de tipo TCP-flood, después de la realización del procedimiento del “apretón de manos” (handshake), la parte atacante envía datos “basura” de gran tamaño y de una forma muy lenta por la conexión establecida. Esto recarga el servidor y no le permite dar recursos a las conexiones legítimas.



Mitigación de inundaciones (Flood) SYN con iptables - SYNPROXY


SYNPROXY es una novedad de iptables que se ha añadido en la versión del kernel 3.12 de Linux e iptables 1.4.21. CentOS 7 ha portado la característica y está disponible por defecto en su kernel 3.10. 

El propósito de synproxy es comprobar si el host que envió el paquete SYN en realidad establece una conexión TCP completa o simplemente no hace nada después del envío del paquete SYN. Si no hace nada, se descarta el paquete con un impacto mínimo en el rendimiento.




Configurar synproxy puede ser complicado sin una guía paso a paso, ya que se necesitan algunos ajustes previos.

Podemos usar un script bash de configuración:

Ajuste de la configuración del kernel

Debido a la característica de "synproxy" utiliza syncookies y syncookies utilizan marcas de tiempo, lo tenemos que habilitar en nuestra configuración del kernel. Puedes editar tu fichero /etc/sysctl.conf para reflejar estos ajustes o aplicarlos directamente con:

sysctl -w net/ipv4/tcp_syncookies=1
sysctl -w net/ipv4/tcp_timestamps=1

Por otra parte tenemos que ajustar la configuración del conntrack, ya que una parte importante de la función "synproxy" es la de no realizar un seguimiento de las conexiones TCP que no estén constituidos por completo, debido a que necesita una gran cantidad de recursos. La siguiente configuración excluirá paquetes ACK de seguimiento de conexiones y los marcará como no válido.

sysctl -w net/netfilter/nf_conntrack_tcp_loose=0

Si ese comando anterior devuelve un error, tratar de aplicarlo más tarde, cuando el módulo conntrack del  núcleo está realmente activo.

Ahora sentido el aumento de tamaño conntrack hash y el ajuste conntrack_max, ya que si tienes un sitio con mucho tráfico, se recomienda realizar el ajuste de entrada del conntrack para aumentar el límite de 64 K conn predeterminado. Sin embargo, es crucial para el rendimiento que también recuerda a aumentar el tamaño conntrack hash.

echo 2500000 > /sys/module/nf_conntrack/parameters/hashsize
sysctl -w net/netfilter/nf_conntrack_max=2000000

Estos son sólo dos de los ajustes más importantes, hay un montón de otras configuraciones del kernel que pueden ser ajustadas con el fin de aumentar el rendimiento de la red para soportar muchas conexiones / paquetes


Recuerde que debe establecer sus propios límites y calcular el uso de la memoria. En este ejemplo, 2 millones de entradas veces 288 bytes = max 576,0 MB de uso de la memoria potencial. Para el hash, cada lista de hash "cabeza" es sólo 8 bytes por 1 millón es sólo 8 MB de memoria asignada fija (importaría L3 cache-size de la CPU al elegir el tamaño de hash).



Mientras que las reglas de iptables que hemos proporcionado otras veces ya bloquean la mayoría de los ataques basados en TCP, el tipo de ataque todavía puede complicarse si es lo suficientemente sofisticado ataque de inundación SYN. Es importante tener en cuenta que el rendimiento de las reglas siempre será mejor si nos encontramos con un cierto patrón o firma a bloquear, tales como la longitud del paquete (longitud -m), TOS (-m tos), TTL (TTL -m) o cadenas y los valores hexadecimales (cadena -m y u32 -m para los usuarios más avanzados). Sin embargo, en algunos casos raros, no es posible o al menos no es fácil de archivar. Por lo tanto, en estos casos, se puede hacer uso de synproxy.


Aquí están las reglas de iptables synproxy que ayudan a mitigar las inundaciones SYN que traspasan otras reglas:

iptables -t raw -D PREROUTING -p tcp -m tcp --syn -j CT --notrack
iptables -D INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -D INPUT -m conntrack --ctstate INVALID -j DROP 


La primera regla insertamos, excluye paquetes SYN del seguimiento de conexiones, porque eso sería utilizar una gran cantidad de recursos y, obviamente no es lo que queremos. Le decimos a la tabla "raw" maneja las conexiones sin seguimiento, el objetivo "CT" es sinónimo de "conntrack" y la opción "--notrack" los excluye de seguimiento. Es para asegurarse de que las conexiones que necesitan protección no crean nuevas entradas conntrack para paquetes SYN. 

La segunda regla se aplica a los paquetes SYN (sin seguimiento (UNTRACKED) según la regla anterior) y los paquetes ACK (inválidos por "nf_conntrack_tcp_loose = 0") y los reenvía al destino synproxy, que los verifica los syncookies (en paralelo, lo que no era posible anteriormente) y establece las conexiones TCP completas.

La tercera y última regla que añadimos elimina (DROP). 


Estas reglas se aplican a todos los puertos. Si desea utilizar synproxy sólo en determinados puertos TCP que están activas (recomendado - También se debe bloquear todos los puertos TCP que no están en uso utilizando la tabla mangle y la cadena PREROUTING), puede simplemente añadir -- dport 80 a cada una de las reglas si quieren utilizar synproxy en el puerto 80 solamente.

Para verificar que synproxy está trabajando, puedes hacerlo con:

watch -n1 cat /proc/net/stat/synproxy

Si los valores cambian cuando se establece una nueva conexión TCP con el puerto que utiliza el synproxy, es que entonces funciona.



________________________________________________________
Tomado de:  http://blog.elhacker.net/2016/04/mitigacion-de-ataques-DDoS-syn-flood-con-synproxy.html
Se Respetan Derechos de Autor.

Chrome dejará de usar Flash a partir de Diciembre de 2016 !

¡Adiós, Flash! Chrome usará HTML5 por defecto a partir de diciembre !

Era una noticia que ya se venía anunciando desde hace meses: antes de que acabara el año, Chrome empezaría a bloquear el contenido Flash en páginas web, dando siempre prioridad al formato HTML5. Y el equipo del navegador web de Google acaba de hacer oficial la fecha en la que este cambio empezará a surtir efecto: diciembre de este año.
El anuncio se ha producido en un comunicado publicado en el blog de Chrome, donde el equipo de Chrome reconoce el importante papel que Flash ha jugado en el desarrollo web, la creación de los estándares web actuales y la adopción de elementos multimedia como vídeo, animación y juegos en la Web. Sin embargo, la tecnología avanza y es hora de que Flash se retire para dar paso a un sustituto más seguro y más rápido:HTML5.
"El HTML5 es mucho más ligero y rápido", dice el comunicado de Chrome. "Los creadores de contenido lo usan para acelerar el tiempo de carga y ahorrarte batería en el dispositivo móvil". Por eso, comenzando por la versión 53 del navegador prevista para septiembre de este año, Chromeempezará a bloquear contenido Flash. "Verás una mejora en eficiencia y tiempo de respuesta en muchas páginas web", aseguran.
Tres meses y dos versiones más tarde, en Chrome 55 (previsto para diciembre de este año), el contenido en HTML5 pasará a ser oficialmente el activado por defecto en el navegador para todo tipo de contenido multimedia en la web. Se mantendrá la capacidad de ejecutar Flash, eso sí, pero sólo para aquellas páginas web que únicamente soporten Flash. Y en esos casos, además, se pedirá al usuario que lo active manualmente la primera vez que visita esa página.
El comunicado de Chrome asegura que será una transición sin sobresaltos, y que el único cambio que notará el usuario es una experiencia de navegación más rápida y más segura.
Este cambio no es más que el paso final de Chrome para dejar de usar Flash totalmente, después de haber empezar a bloquear todo el contenido Flash que no era relevante, y luego bloquear la publicidad en este formato.

______________________________________________________
Tomado de: http://www.genbeta.com/navegadores/adios-flash-chrome-usara-html5-por-defecto-a-partir-de-diciembre
Se Respetan Derechos de Autor.

lunes, 1 de agosto de 2016

Denegación de servicio en Cisco Wireless LAN Controller !

Cisco ha anunciado el descubrimiento de un problema en sus dispositivos Wireless LAN Controller (WLC) que podría permitir a usuarios sin autenticar provocarcondiciones de denegación de servicio.


El problema se debe a un tratamiento insuficiente del tráfico de paquetes "wireless management frames". Un atacante remoto no autenticado podrá enviar tráfico manipulado que provoque la caída del dispositivo afectado.

La vulnerabilidad, con la referencia CVE-2016-1460, afecta a los dispositivos con versiones de software 7.4(121.0) y 8.0(0.30220.385). Cisco no ofrece actualizaciones para corregir este problema.

Más información:

Cisco Wireless LAN Controller Denial of Service Vulnerability

______________________________________________________
Se Respetan Derechos de Autor.

QRLJacking: secuestro de código QR.


Un sitio web que implementa el sistema de autenticación SQRL muestra un código QR en la pantalla de la computadora y cualquier persona que quiera iniciar sesión sólo escanee ese código con una aplicación de teléfono móvil. Una vez escaneado, el sitio inicia la sesión de usuario sin necesidad de escribir ningún dato adicional. Este código se renueva cada 20 segundos. Por ejemplo, en WhatsApp web, se presenta la siguiente pantalla:
Como las contraseñas pueden ser robadas con un keylogger, con un ataque Man in the Middle (MitM) o por fuerza bruta aún, los códigos QR son considerado seguros ya que se genera al azar un código secreto, que nunca es revelado a nadie.

QRLJacking: Secuestro de código QR

El investigador de seguridad egipcio Mohamed Abdelbasset Elnouby (@SymbianSyMoh) ha creado una prueba de concepto que demuestra una técnica que se puede utilizarse para hackear cuentas de servicios que usan la característica "Inicio de sesión con código QR". Denominado QRLJacking, la técnica es un "vector de ataque simple-pero-desagradable" que afecta a todas las aplicaciones que basan su inicio de sesión con códigos QR.

Básicamente se basa en un phishing, donde el atacante tiene que convencer a la víctima de escanear el código QR brindado por el atacante:
  • El atacante ingresa al sitio que utiliza el código QR (por ejemplo WhatsApp web). El sitio muestra el código generado.
  • El atacante clona/copia del código QR de inicio de sesión en una página de phishing creada por él.
  • El atacante envía la página de phishing a la víctima.
  • Si es convencido, la víctima escanea el código QR con la aplicación móvil objetivo.
  • La aplicación móvil envía el token secreto al servicio web para completar el proceso de autenticación.
  • Como resultado, el atacante inicia la sesión cliente y gana el control sobre la cuenta de la víctima.
  • Para llevar a cabo un exitoso, un atacante debe refrescar continuamente (cada N segundos) el código generado en la página falsa.
Este escenario se puede replicar en WhatsApp, WeChat, AirDroid, Weibo, Yandex, Alibaba y cualquier otro proyecto que utilice código QR como método de autenticación.
    Para más detalles se puede ingresa a la página del ataque QRLjacking en OWASP o Github o se puede ver el video.

    _________________________________________________________________________________
    Tomado de: http://blog.segu-info.com.ar/2016/08/qrljacking-secuestro-de-codigo-qr.html#qrljacking-secuestro-de-codigo-qr
    Se Respetan Derechos de Autor.