Author Archive aci

Byaci

Que es Tunna y cómo funciona?

Tunna es un conjunto de herramientas que envolverá cualquier comunicación TCP a través de HTTP. Se puede usar para eludir las restricciones de red en entornos completamente protegidos por cortafuegos.

tunna

RESUMEN

TLDR: realiza un túnel de conexiones TCP a través de HTTP

En un firewall completamente cerrado, conexiones entrantes y salientes restringidas, excepto el puerto del servidor web, nos explica un experto en seguridad de datos. El webshell se puede usar para conectarse a cualquier servicio en el host remoto. Esta sería una conexión local en un puerto local en el host remoto y debería ser permitida por el firewall.

El webshell leerá los datos del puerto de servicio los envolverá a través de HTTP y los enviará como una respuesta HTTP al proxy local.

El proxy local desenvolverá y escribirá los datos en su puerto local donde se conectará el programa cliente. Cuando el proxy local recibe datos en el puerto local, los enviará a la webshell como una publicación HTTP. Webshell leerá los datos de la publicación HTTP y los colocará en el puerto de servicio y repite.

Solo el puerto del servidor web debe estar abierto (normalmente 80/443). Toda la comunicación (externa) se realiza a través del protocolo HTTP.

USO

Python proxy.py -u <remoteurl> -l <localport> [options]

Opciones

–help, -h muestra este mensaje de ayuda y sale

–url = URL, -u URL URL de la webshell remota

–lport = LOCAL_PORT, -l LOCAL_PORT puerto de escucha local

–verbose, -v Verbose tamaño del paquete de salidas.

–buffer = BUFFERSIZE, -b BUFFERSIZE * Tamaño de solicitud HTTP

 Sin opciones de SOCKS

De acuerdo con un profesional en seguridad cibernética, las opciones se ignoran si se utiliza el proxy SOCKS.

–no-socks, -n No use Socks Proxy

–rport = REMOTE_PORT, -r REMOTE_PORT puerto de servicio remoto para que webshell se conecte a –addr = REMOTE_IP, – una dirección REMOTE_IP para que se conecte webshell remoto (predeterminado = 127.0.0.1)

Opciones de Upstream proxy

Conexión de túnel a través de un Proxy local

–up-proxy = UPPROXY, -x UPPROXY Upstream proxy (http://proxyserver.com:3128)

–auth, – Un Upstream proxy requiere autenticación

Opciones avanzadas

–ping-interval = PING_DELAY, -q PING_DELAY intervalo de subproceso de ping webshprx (predeterminado = 0.5)

–start-ping, -s Inicia primero el hilo que hace ping – algunos servicios envían datos primero

–cookie, -C Solicitar cookies

–autenticación, -t autenticación básica

Limitaciones

Ejemplo: python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -v

Esto iniciará un Servidor Local SOCKS Proxy en el puerto 80000. Esta conexión se ajustará a través de HTTP y se desenvolverá en el servidor remoto.

python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -x https://192.168.1.100:3128 -A -v

Esto iniciará un Servidor Local SOCKS Proxy en el puerto 80000. Se conectará a través de un Proxy local (https://192.168.1.100:3128) que requiere autenticación del remoto webshell de Tunna.

python proxy.py -u http://10.3.3.1/conn.aspx -l 4444 -r 3389 -b 8192 -v –no-socks

Esto iniciará una conexión entre el webshell y el servicio de host remoto RDP (3389). El cliente RDP se puede conectar en el puerto localhost 4444. Esta conexión se ajustará a través de HTTP.

Requisitos previos

La capacidad de cargar un webshell en el servidor remoto

 

LIMITACIONES / ERRORES CONOCIDOS / HACKS

Este es un código POC y podría causar DoS del servidor. Se han hecho todos los esfuerzos para limpiar después de la ejecución o por error, de acuerdo a un especialista en seguridad cibernética.

Basado en pruebas locales: El buffer JSP necesita ser limitado (opción buffer):

4096 trabajó en Linux Apache Tomcat

1024 trabajó en XAMPP Apache Tomcat, muy lento.

Más que eso creó problemas con la falta de bytes en el socket remoto, por ejemplo: ruby proxy.rb -u http://10.3.3.1/conn.jsp -l 4444 -r 3389 -b 1024 -v

Sockets no habilitados por ventanas php predeterminadas (IIS + PHP). Devuelve carias en webshells fuera del código: recibir respuestas enviadas / escritas en el socket local -> corromper los paquetes.

PHP webshell para Windows: la función de bucle hace el socket remoto: función de reposo añadida. PHP webshell necesita nuevos caracteres de línea eliminados al final del archivo después de “?>”  ya que estos serán enviados en cada respuesta y confundirán a Tunna, nos dice un experto en seguridad de datos.

ARCHIVOS

Webshells:

conn.jsp Probado en Apache Tomcat

conn.aspx Probado en IIS 6 + 8 (servidor de Windows 2003/2012)

conn.php probado en LAMP + XAMPP + IIS (windows + linux)

Servidor web: webserver.py Probado con Python 2.6.5

Proxies:

proxy.py Probado con Python 2.6.5

Detalles técnicos

Decisiones de arquitectura. Los datos se envían sin formato en el cuerpo de publicación de HTTP. Las instrucciones / configuración se envían a webshell como parámetros de URL (HTTP Get). Los datos se envían en el cuerpo HTTP.

Websockets no utilizados: la mayoría de los servidores web no los admiten por defecto.

Las respuestas HTTP asíncronas no son realmente posibles. El proxy consulta constantemente al servidor (por defecto 0.5 segundos)

FASE DE INICIACIÓN

El primer paquete inicia una sesión con webshell: recupera una cookie, por ejemplo: http: //webserver/conn.ext?proxy

El segundo paquete envía las opciones de configuración de conexión a la webshell, por ejemplo: http: //webserver/conn.ext?proxy & port = 4444 & ip = 127.0.0.1

IP y puerto para que la webshell se conecte. Esta es una solicitud enhebrada: En php esta solicitud entrará en un bucle infinito para mantener viva la conexión del socket webshell. También, nos dice el profesional en seguridad cibernética, en otras webshells [OK] se recibe de nuevo.

CLIENTE TUNNA

Se creará un socket local al que se conectará el programa de cliente. Una vez que el cliente está conectado, se inicia el hilo de ping y se inicia la ejecución. Todos los datos en el socket del cliente se leen y se envían como una solicitud HTTP Post. Todos los datos en el socket webshell se envían como respuesta a la solicitud POST.

PINGING THREAD

Porque las respuestas HTTP no pueden ser asincrónicas. Este hilo hará HTTP obtenga solicitudes en el webshell en función de un intervalo (predeterminado de 0,5 segundos). Si el webshell tiene datos para enviar, también lo enviará como respuesta a esta solicitud. De lo contrario, enviará una respuesta vacía.

En general: los datos del proxy local se envían con publicación HTTP. Hay solicitudes Get cada 0,5 segundos para consultar los datos de webshell si hay datos en el lado webshell enviados como respuesta a una de estas solicitudes

WEBSHELL

Webshell se conecta a un socket en el host local o remoto. Cualquier información escrita en el socket se envía de vuelta al proxy como respuesta a una solicitud (POST / GET) Cualquier información recibida con una publicación se escribe en el socket.

NOTAS

Todas las solicitudes deben tener el parámetro de URL “proxy” configurado para ser manejado por el webshell (http: //webserver/conn.ext?proxy)

AT EXIT / AT ERROR

Elimina todos los hilos y cierra el socket local. Envía el proxy y lo cierra a webshell: elimina los hilos remotos y cierra el socket

SOCKS

El soporte de SOCKS es un módulo de complemento para Tunna. Localmente hay un hilo separado que maneja las solicitudes de conexión y el tráfico agrega un encabezado que especifica el puerto y el tamaño del paquete y lo reenvía a Tunna. De acuerdo al experto en seguridad de datos, Tunna lo envía al servidor web remoto, elimina los encabezados HTTP y reenvía el paquete al proxy SOCKS remoto. El proxy remoto SOCKS inicia la conexión y asigna el puerto recibido al puerto local. Si el proxy SOCKS remoto recibe datos del servicio, mira la tabla de asignación y encuentra el puerto al que necesita responder, agrega el puerto como un encabezado para que el proxy SOCKS local sepa a dónde reenviar los datos. Cualquier tráfico del puerto recibido se enviará al puerto local y viceversa.

 

Fuente: https://github.com/SECFORCE/Tunna

Byaci

Firecat:una herramienta de prueba de penetración y crear reverse túnel en una red

Firecat es una herramienta de prueba de penetración que te permite perforar al reverse túnel TCP de una red comprometida. Después de que se establece un túnel, puedes conectarte de un host a cualquier puerto en el sistema dentro de la red comprometida, aun si la red esta detrás de un gateway de NAT o un firewall. Esto puede ayudar de varias maneras, incluyendo el acceso al Remote Desktop de la red interna de la dirección IP del NAT(e.g. 192.168.1.10) de un servidor de red comprometido.

 

Instalación

Firecast está escrito en C y está probado en Linux, Solaris, iOs, Mac OS X y Windows XP/Vista/2k/2k3/2k8.

Para elaborar en Windows usando MinGW:

gcc –o firecat.exe firecat.c –lwsock32

Para elaborar en Unix:

gcc –o firecat firecat.c

Uso

¿Cómo funciona?

Regresa atrás una década y recordarás que era muy común encontrar anfitriones que no tuvieran un firewall del Internet. Podías comprometerlos, archivar shellcodes en un puerto, usar netcat o alguna otra herramienta para tomar el control en línea de comandos interactivos del objetivo explica Jim Gil, un experto de seguridad informática de International Institute of Cyber Security (IICS).

Hoy en día las cosas son diferentes, es muy común que los paquetes de TCP/IP de un host esta estrictamente filtrados por reglas de firewall para su ingreso.

Con frecuencia, los asuntos son más complicados puesto que el host que es la meta está detrás de un gateway NAT:

Reglas más estrictas para el firewall reduce el tamaño del ataque del objetivo, pero ataques como la inyección de SQL hacen posible ejecutar códigos arbitrarios en los servidores con firewalls muy estrictos. Sin embargo, a menos que el consultor pueda tomar control del firewall y alterar el rule set, es imposible para otros conectar directamente con la red interna de servicios.

Es ahí cuando Firecat tiene su turno. Asumiendo que puedes ejecutar comandos en un host de DMZ y que el host puede iniciar una conexión de  outbound de TCP/IP a la computadora del consultor, Firecat le posibilita conectarse a cualquier puerto en la mira del host, y a cualquier puerto en cualquier host de DMZ. Esto pasa creando un túnel reverso TCP a través del firewall y usando el túnel para intermediar conexiones arbitrarias de TCP entre el consultor y el host en el ambiente que es el objetivo.  Expertos de seguridad informática de Webimprints aconseja que además de crear túneles arbitrarios de TCP/IP a red DMZ, también se puede usar para reventar connect-back shells del host de DMZ comprometido como web o servidores SQL.

Funciona debido que el sistema objetivo es el que inicia la conexión TCP de regreso al consultor, no a la inversa. Firecat corre en modo “target” en el objetivo, y “consultant” en el sistema del consultor, creando efectivamente un túnel entre los dos puntos. Una vez que el túnel es establecido, el consultor se conecta a su daemon de Firecat local que instruye un Firecat daemon remoto para iniciar una conexión al host/port deseado detrás del firewall menciona Jim Gil, un experto de seguridad informática de International Institute of Cyber Security (IICS).Los dos Firecat daemons crean un túnel entre la información del consultor y el objetivo para crear un puente impecable y transparente entre los dos sistemas, así evitando las reglas del fierwall. Firecat funciona aun con host detrás de firewalls de NAT.

Siguiendo los pasos, y utilizando la dirección IP de los diagramas, el proceso funciona de la siguiente manera:

  1. Firecat (consultant) atiende 202.1.1.1:4444
  2. Firecat (target) conecta 202.1.1.1:4444

  1. Se establece un túnel entre ambos hosts
  2. Firecat (consultant) listens on 202.1.1.1:3389
  3. El consultor conecta al desktop remoto del cliente a 202.1.1.1:3389
  4. Firecat (consultant) le dice a Firecat (target) que una nueva sesión ha iniciado
  5. Firecat (target) conecta a 192.168.0.1:3389
  6. Firecat (target) le comenta a Firecat (consultant) que está conectado localmente
  7. Ambas instancias de Firecat comienzan el túnel de información entre el desktop del cliente del consultor y el desktop objetivo del servidor, haciendo parecer al desktop del cliente que está conectado al objetivo.

 

https://github.com/altf4/firecat

Byaci

WPA2 – si alguna vez pensaste que era seguro….

Una grave vulnerabilidad encontrada en el sistema de cifrado WPA2 ha puesto en peligro todas las conexiones inalámbricas. Mientras se espera más información, vamos a resolver las dudas más frecuentes para la mayoría de usuarios. ¿Qué ha ocurrido con las redes wifi y cómo te afecta?

¿Por qué es tan importante?

Lo más probable es que tu principal método de conexión a internet sea a través de una red wifi la mayor parte del día. Ahora suma los millones de personas que hacen lo mismo diariamente. Y, por último, piensa que alguien cerca de tu señal pueda acceder a tus datos, historial o información privada. Este es el riesgo que corren las redes tras el fallo detectado.

¿Qué demonios ha ocurrido?

Desde el año 2004, momento en el que apareció el protocolo de seguridad wifi WPA2 (wifi Protected Access 2), se vivía con el temor a un fallo que expusiera las redes inalámbricas a nivel mundial. A partir de entonces, los fabricantes comenzaron a producir una nueva generación de puntos de accesos apoyados en el protocolo, el cual utilizaba el algoritmo de cifrado AES (Advanced Encryption Standard). AES a su vez es un sistema de algoritmos que se convirtió en estándar de cifrado. Dicho de forma sencilla, con la llegada del sistema WPA2 las redes wifi han estado seguras, hasta ahora. 13 años de tranquilidad que pueden haber llegado a su fin por culpa de un nombre: KRACK. Significa Key Reinstallation Attack, y a esta hora sabemos que es el conjunto de técnicas responsables de conseguir la vulnerabilidad en WPA2. Además, la principal gravedad reside en el hecho de que no hay posibilidad de cambiar a otro protocolo que proteja las redes inalámbricas en el planeta.

¿Cómo funciona un ataque KRACK?

El experto en seguridad Mathy Vanhoef ha publicado los resultados de su investigación en la Computer and Communications Security (CCS) que se ha celebrado hoy, y en él expone cómo la seguridad del protocolo WPA2 se ve comprometida por estos ataques, llamados Key Reinstallation Attacks (KRACKs).

El objetivo del ataque es el proceso de negociación del protocolo WPA2, conocido como 4-way handshake, que se realiza cuando un cliente se quiere conectar a una red inalámbrica y se usa para confirmar que tanto el cliente como el punto de acceso tienen las credenciales correctas (la contraseña de la red WiFi). En ese proceso de negociación se genera una nueva clave con la que se cifrará todo el tráfico de esa sesión.

En un ataque de este tipo, el atacante engaña a la víctima haciendo que reutilice una clave que ya se estaba utilizando, y para ello se manipulan y sustituyen los mensajes con el handshake cifrado. Una clave solo debería ser usada una vez, pero el protocolo WPA2 no lo garantiza, lo que permite que un atacante logre acceder a esos paquetes y así tenga acceso a la información que conforman.

En el estudio detallado del ataque, titulado “Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2” (PDF), escrito por Mathy Vanhoef y Frank Piessens, se puede consultar con más detalle cómo funciona todo el proceso.

Fuente https://www.xataka.com

Byaci

IoT Vs Seguridad

Desde el año 2000 el término IoT (Internet de las cosas) fue mencionado en The Guardian, Scientific American y The Boston Globe, pero hasta el año 2005 la Unión Internacional de Telecomunicaciones (UIT) publico el primer estudio sobre el tema. Hasta 2011, se comenzó a trabajar en el estándar IoT – GSI Global Standards y concluyo hasta junio de 2015. El IoT-GSI tiene por objeto promover un enfoque unificado en el UIT-T para el desarrollo de normas y técnicas (Recomendaciones) que permitan el Internet de las cosas a escala mundial.

IoT es una tecnología que va creciendo a pasos gigantes, para el año 2020 se estima que 50 mil millones de dispositivos estén conectados, es decir, 6 dispositivos por cada persona.

Pero, ¿Se ha considerado la seguridad para estos dispositivos?; La Comisión de Estudios 17 (SG17) del UIT-T coordina la labor relacionada con la seguridad. La SG17 actualmente trabaja en la seguridad de aplicaciones y servicios para Internet de las cosas (IoT).

Por otro lado, la Iniciativa Mundial de Normalización de la UIT sobre Internet de las cosas (IoT-GSI), se basa en la labor de ciertos ámbitos como: los aspectos de los sistemas de identificación de la red (NID), las redes de sensores ubicuos (USN), las comunicaciones orientadas a las máquinas (MOC), la web de las cosas (WoT). La iniciativa IoT-GSI tiene como objetivo:

  • Crear una plataforma de trabajo común agrupando los grupos de la UIT que realizan trabajos sobre IoT.
  • Elaborar una definición y descripción general de la IoT y preparar un plan de trabajo que servirá para establecer un programa de normalización de la IoT a escala mundial.
  • Elaborar las normas detalladas necesarias para la implantación de la IoT.

A pesar de que se trabaja para crear estándares y normas sobre el uso y seguridad de IoT, siendo una tecnología en crecimiento y recién adopción por empresas y usuarios de casa, estamos más susceptibles a ciberataques, desafortunadamente IoT afecta al mundo de una manera directa y física, ya que esta tecnología se usa desde coches, electrodomésticos, aviones, wearables (uso diario); por lo que se convierten en riesgos reales para una persona. Internet de las cosas puede ser percibida como una concepción de repercusiones tecnológicas y sociales.

“Una nueva dimensión se ha agregado al mundo de las tecnologías de información y la comunicación (TIC): a cualquier hora, en cualquier lugar, ahora vamos a tener conectividad para cualquier cosa. Las conexiones se multiplican y crearán una nueva red dinámica de redes con redes, una Internet de las Cosas”, UIT.

Desde nuestra perspectiva se deben considerar varios aspectos para minimizar los riesgos de un posible ciberataque a un dispositivo con tecnología IoT. Estos aspectos pueden abarcar desde la seguridad lógica y física, para la parte lógica se recomienda poner atención en el uso de software, control de usuarios y accesos a los datos, dentro de la parte física se debe considerar la gestión de identidad sobre todo en un ambiente de IoT, donde pueden existir muchos puntos de entrada. Se puede considerar una segmentación en la red para aislar todos estos dispositivos. Contar con servicios profesionales que ayuden con asesorías para afrontar los retos de seguridad, con estrategias alineadas al negocio, procesos y políticas.

 

Referencias:

http://www.itu.int

http://www.itu.int/en/ITU-T/gsi/iot/Documents/tor-iot-gsi.pdf

Byaci

Estrategia Nacional de Ciberseguridad (México)

…”Hacia una Estrategia Nacional de Ciberseguridad” (México) plan estratégico impulsado por el Gobierno de la República Mexicana, donde colaboran diferentes sectores como: gobierno, sector privado, comunidad técnica, sociedad civil y académica.

El documento hace mención que para el año 2030 México será un país mejor preparado ante ciberataques y con una mejor cultura en ciberseguridad.

La Estrategia contemplara 4 Objetivos Estratégicos y 8 Ejes Trasversales:

Economía: Debido a el gran crecimiento y la continua evolución de las TIC, se requiere la implementación de proyectos relacionados con el desarrollo y la innovación de las tecnologías. con el fin de crear una cultura de prevención e impulsar al país como una de las economías emergentes más proliferas:

  • Concientizar de los actos de riesgo aosciados en el ciberespacio.
  • Desarrollo de proyectos de investigación e innovación, fomentando el capital humano especializado en materia de ciberseguridad.
  • Mitigación de riesgos y amenazas que puedan afectar la economía y la estabilidad del país.
  • Generación de tecnología propia.
  • Desarrollo de buenas prácticas, normas y estándares conforma a las necesidades del país y en distintos sectores.
  • Mecanismos, marco jurídico y normas técnicas para el crecimiento económico del país a través de la innovación tecnológica, manteniendo la protección las Infraestructuras Críticas de la Información.
  • Regular las operaciones que se realizan a través de Internet.
  • Métricas sobre el uso y confianza de servicios de comercio electrónico.

Sociedad: La estrategia tiene como factor primordial al factor humano y a cuidar sus derechos, es por ello, que la estrategia se enfoca en fortalecer la confianza de los usuarios que utilizan servicios en línea, así mismo la concientización de adoptar medidas de ciberseguridad y promover el manejo adecuado y seguro de las TIC.

  • Campañas que contemplen la autoprotección, autoregulación y mejores practicas.
  • Protección de adolescentes, niños y niñas a la exposición con depredadores informáticos.
  • Estimular la profesionalización de la ciberseguridad.
  • Prevención y combate de incidentes con la participación ciudadana.
  • Construir un ciberespacio seguro y confiable.
  • Lineamientos que coadyuden al bienestar de la población.
  • Procedimientos y mecanismos para la protección de las Infraestructuras Criticas de la Información e Inteligencia Especializada.
  • Un marco jurídico que contemple el enfoque de los derechos humanos, de caracter preventivo.
  • Indicadores de medición de efectividad de las campañas de concienciación y cambio cultural, así como de los incidentes de ciberseguridad.

Gobierno: La gestión pública a través de las TIC contiene gran variedad de datos e información sensible, tanto de los entes públicos, como de la población, por lo que:

  • Se requiere crear campañas para mejorar el nivel del servicio público.
  • Políticas y programas de actualización tecnológica.
  • Fortalecer la ciberseguridad en la gestión de la información relativa a la prestación de trámites y servicios a la población.
  • Prestación más eficiente, segura y confiable de los trámites y servicios para la población.
  • Criterios y controles para estandarizar los procesos de seguridad de la información y el tratamiento de datos de los entes públicos.
  • Instauración de canales de comunicación seguros ante posibles ataques.
  • Brindar certeza jurídica en la prestación de trámites y servicios a la población.
  • Proceso gradual de adopción voluntaria de los procesos referidos en el Manual Administrativo de Aplicación General en materia de Tecnologías de la Información y Comunicaciones y de Seguridad de la Información (MAAGTICSI).

Seguridad Nacional: El incremento de las amenazas globales y los delitos a nivel mundial, conllevan a fortalecer la Seguridad Nacional para preservar la integridad, estabilidad y permanencia del Estado Mexicano.

  • Campañas dedicadas a las Instancias de Seguridad Nacional, manejo de información general, personal y laboral.
  • Contar con una base de conocimientos centralizada.
  • Mecanismos de colaboración y cooperación entre dependencias vinculadas con la Seguridad Nacional para el intercambio de información e inteligencia.
  • Desarrollo tecnológico, investigación e intercambio de conocimiento a fin de fortalecer la ciberseguridad en las dependencias que cuenten con Infraestructura Crítica de la Información del Estado Mexicano.
  • Estandarización del proceso de seguridad de la información y el tratamiento de activos de información en las Instancias de Seguridad Nacional.
  • Protocolos de comunicación y cooperación entre los sectores involucrados para la ciberdefensa en situaciones de un ciberataque que afecte las Infraestructuras Críticas de la Información o Información e Inteligencia Especializada, con una posible afectación al orden y paz social.
  • Armonización de la legislación en relación a delitos en relación a delitos como ciberterrorismo, delitos que usan TIC para su comisión (ciberdelitos), ciberataques y ciberamenazas, el cual debe contemplar la investigación y sanción correspondiente.
  • Estadísticas globales para conocer las tendencias de los incidentes cibernéticos.

La ENCS ( Estrategia Nacional de Ciberseguridad) se presentara durante la Semana Nacional de Ciberseguridad del 9 al 13 de octubre de 2017.

Si deseas conocer a detalle el documento de la ENCS, puedes consultar el siguiente enlace:

https://www.gob.mx/cms/uploads/attachment/file/239446/Documento_de_trabajo_ENCS_v0.pdf

 

Byaci

¿Por qué crear una Estrategia de Seguridad?

Espionaje, hactivismo, ciberataques; son algunas de las palabras más sonadas durante el primer semestre de 2017. Ataques a nivel mundial que nos hacen replantear la idea de una estrategia de seguridad a nivel empresa, nacional y a nivel mundial.

México, el país más afectado  de América Latina por el cibercrimen, desde 2014 ha comenzado a trabajar en la creación de una Estrategia Nacional de Ciberseguridad, sin embargo, hasta el 2017 se ha iniciado el diseño de esta política. Los días 19 y 20 de abril se realizó el taller “Hacia la Estrategia Nacional de Ciberseguridad”;  donde se manifestó la importancia de los derechos humanos dentro del ciberespacio; añadiendo a esto, la OEA reafirmó su compromiso de apoyar al gobierno de México en el desarrollo de su Estrategia.

Desde nuestro punto de vista, una estrategia a nivel nacional no será eficaz, si no partimos de lo menos a lo más; si dentro de nuestras organizaciones o empresas, no contamos con una estrategia de seguridad en la información, seguiremos vulnerables a los ciberataques, que día a día aumentan en nivel de riesgo.

Por mencionar algunos incidentes recientes, el pasado 21 de julio de 2017 se dio a conocer la peor fuga gubernamental de Suecia, el error: trasladar toda su información secreta de la nación a la nube (cloud), entre la información sensible que vio la luz tenemos, nombres de pilotos, todos los carnets de conducir de Suecia, datos de protección de testigos, información personal sobre las Unidades de Fuerza, detalles de vehículos militares, entre otra información. Tras toda esta información filtrada se destaca la actitud generalmente descuidad y negligente; la sentencia a este incidente ha sido dar el salario de medio mes, debido a que fue el propio gobierno quien expuso dicha información.

Un segundo incidente que salió a la luz el pasado 8 de agosto de 2017 fue la filtración de 11,000 documentos internos sobre LexNet y Orfila (Organizaciones de España). Este incidente ha sido totalmente un descuido, la información filtrada se encontraba en un servidor con acceso desde Internet completamente abierto (sin contraseña).

“Cuando vi lo que ocurrió con LexNet la semana pasada me puse a buscar información. No sabía cómo funcionaba. Me metí en Shodan y encontré una IP de Justicia no securizada. Entré y te daba acceso a un directorio, estaba abierto y sin contraseña. Otro fallo de configuración hacía que pudieras acceder con permisos de administrador al panel de monitorización de LexNet y a carpetas con miles de documentos sobre esta plataforma y sobre Orfila. Todo eso no debería estar ahí”, explica a Teknautas una de las personas que accedió al material, un estudiante de ingeniería de 20 años. “Si yo lo he encontrado, cualquiera podría haberlo hecho”.

El 87% de las empresas en México ha tenido incidentes de seguridad de la información, el costo promedio de un incidente de seguridad es de 1 millón 581,641 dólares;  algunas de las empresas solo destinan el 3.87% del presupuesto a ciberseguridad, presupuesto reducido para proteger el activo más valioso de las Organizaciones.

De acuerdo con la experiencia, pocas empresas cuentan con una estrategia en seguridad de la información claramente definida acorde a su negocio. Una estrategia debe verse como un proceso más dentro de la Organización. Es importante que todas las áreas sean partícipes, ya que la seguridad no es un problema específico de un área. Se deben crear políticas, procesos y lo más importante implementarlas, mismas que deben ser auditadas para obtener una mejora continua en el proceso. Es importante dejar en claro que las herramientas tecnológicas son un complemento de la seguridad, contar con un firewall o un detector de intrusos minimizara el riesgo de algunos ataques, sin embargo para estas herramientas deben de existir políticas de actualización de parches, procesos de configuración, añadiendo a esto, es recomendable realizar pruebas de penetración (pentest), con la finalidad de validar y verificar la existencia de huecos de seguridad dentro de la infraestructura tecnológica. Las empresas deben evitar ser juez y parte de las validaciones o auditorias de seguridad, por lo que se recomienda contar con un proveedor, con experiencia que pueda ofrecer asesoramiento personalizado.

 

Referencias

Hacia la Estrategia Nacional de Ciberseguridad

Incidentes de Seguridad en México

LexNet y Orfila

Incidente Suecia

 

Byaci

SHELLBIND es un malware descubierto este mes que explota SambaCry

La compañía de ciberseguridad Trend Micro ha alertado de la existencia de un nuevo malware que explota la vulnerabilidad SambaCry, que afectó sobre todo a sistemas operativos Linux.

Para los que anden despistados, SambaCry fue una vulnerabilidad presente desde hace 7 años descubierta y parcheada hace dos meses y que tenía como principal objetivo a servidores NAS con el fin de realizar minado de criptodivisas. Su nombre recuerda a WannaCry, y no es para menos, ya que afectaba a Samba, una implementación software libre del protocolo SMB/CIFS utilizado por Windows para compartir archivos y otros recursos a través de red, facilitando así la convivencia de Windows con otros sistemas operativos Unix y Unix-like.

A pesar de que se lanzó un parche de forma rápida, parece que a día de hoy sigue habiendo muchos dispositivos con una instalación de Samba sin actualizar, lo que ha motivado el desarrollo de malware por parte de actores malintencionados.

Llamado SHELLBIND, el malware recientemente descubierto por Trend Micro es capaz de funcionar en varias arquitecturas además de x86 (Intel y AMD), abarcando también PowerPC, MIPS y ARM. Se distribuye a través de un fichero de Objeto Compartido (.so) que acaba en carpetas públicas compartidas, siendo después cargado a través de la vulnerabilidad SambaCry.

Una vez implementado en la máquina objetivo, SHELLBIND establece una comunicación con el servidor de mando y control del atacante, que ha sido localizado en el este de África. Además de órdenes procedentes del servidor, también permite a un atacante tomar el control de la máquina infectada.

Para empeorar la situación, encontrar máquinas expuestas al público que hacen uso de Samba es relativamente sencillo, ya que solo hay que buscar el puerto 445, uno de los dos utilizados por Samba, a través del buscador Shodan para obtener una lista de IP de potenciales víctimas para SHELLBIND. Por otro lado, se desconocen los motivos de los actores maliciosos tras este malware.

El peligro está en los dispositivos IoT

Las distribuciones Linux más conocidas suelen ser diligentes a la hora de suministrar actualizaciones que parchean vulnerabilidades críticas, por lo que el impacto de SHELLBIND tendría que ser limitado.

Sin embargo, el verdadero problema no está en las distribuciones Linux “tradicionales”, sino en el IoT, ya que los dispositivos que abarcan esta área son casi siempre actualizados por el fabricante, dejando al usuario sin margen de maniobra y desprotegido en caso de no ser diligentes a la hora de suministrar actualizaciones de seguridad.

De hecho, la desidia de muchos fabricantes ha terminado por convertir al IoT en un área poco fiable en términos de seguridad.

Aun así, prescindir de Samba sería una buena idea

¿Eres usuario de Linux o de otro sistema operativo Unix o Unix-like? En caso de no necesitar Samba, sería buena idea desinstalar el correspondiente servidor para evitar su exposición.

En caso de necesitar Samba para compartir recursos, se recomienda encarecidamente tener el servidor actualizado con los últimos parches a nivel de seguridad y los puertos 139 y 445 cerrados en el router.

Source link

Byaci

Un ciberataque a nivel mundial podría causar pérdidas de 53.100 millones de dólares

Casos como los de WannaCry y NotPetya han despertado la preocupación de muchas empresas e instituciones en torno a la ciberseguridad. Cada vez estamos más interconectados a través de Internet, y eso supone más posibilidades de recibir un cibertaque o bien dar medios para realizar uno, como por ejemplo los necesarios para la creación de una botnet.

Con la ciberseguridad en primer plano debido a la cada vez mayor capacidad de los cibercriminales y hackers para lanzar potentes ataques, el mercado de seguros británico Lloyd’s of London ha publicado un informe que intenta predecir las pérdidas máximas que puede ocasionar un potente ciberataque.

El mercado de seguros ha estimado que las pérdidas que podría causar un ciberataque a nivel mundial estarían entre los 53.100 millones y los 121.400 millones de dólares. Este daño, debido a que está totalmente basado en software, sería puramente económico, a pesar de que las cuantías parecen más bien propias de un desastre natural.

Para estimar esas cuantías tan elevadas, Lloyd’s ha planteado dos posibles escenarios de ataques:

Ataque hacker contra un proveedor de servicios en la nube: La nube está concentrando cada vez más secciones y departamentos de las empresas. Un ataque contra un proveedor de servicios en la nube podría ser llevado por activistas que podrían realizar una modificación maliciosa de un hypervisor que controla la infraestructura cloud. En caso de realizarse contra servidores cloud utilizados por empresas, el servicio acabaría interrumpido y se forzaría a detener la actividad, generando así pérdidas.

El segundo escenario sería algo muy parecido a lo visto a través de WannaCry. Windows es un sistema operativo muy utilizado, por lo que una vulnerabilidad grave que le afecte podría causar grandes daños a las empresas en caso de ser explotada. Los informes sobre las vulnerabilidades que afectan a los sistemas operativos podrían ser vendidos a través de la dark web y acabar en menos de ciberdelincuentes que crearían exploits y diseñarían ataques específicos contra empresas vulnerables para obtener un beneficio económico.
Lloyd’s ha calculado las posibles pérdidas para cada uno de los posibles escenarios. Para el primero ha estimado unas cuantías que van desde los 4.600 millones hasta los 53.100 millones de dólares, mientras que para el segundo ha estimado unas posibles pérdidas de entre 9.700 millones y 28.700 millones de dólares.

Los expertos de Lloyd’s dejan entrever en su informe que es muy difícil estimar las posibles pérdidas económicas causadas por un ciberataque de grandes dimensiones, ya que por un lado dicen que las cuantías podrían ser mucho menores si se toman todas las precauciones necesarias, sin embargo, por otro dicen que en un caso extremo de interrupción de los servicios cloud las pérdidas podrían ascender hasta los 121.400 millones de dólares.

Sobre ataques que ya se han producido, Cyence ha estimado que WannayCry ha podido provocar unos 8.000 millones de dólares en total, mientras que NotPetya habría causado daños que ascenderían a 850 millones.

Fuentes: BleepingComputer y Reuters

Byaci

HIGHRISE: ASÍ ROBABA LA CIA DATOS DE MÓVILES SIN CONEXIÓN A INTERNET

Cada semana, Wikileaks desvela con cuentagotas las diversas herramientas de hackeo de la CIA que obtuvieron a través de una fuente anónima que se las entregó. En estas podemos ver hasta dónde llegan los intentos deciberespionaje y robo de datos en beneficio propio. La última de estas herramientas, Highrise, permite robar datos de un móvil sin conexión a Internet.

HIGHRISE: LA HERRAMIENTA DE LA CIA PARA ROBAR DATOS EN ANDROID 4.0 A 4.3

Highrise, englobada dentro del programa Vault 7, es una herramienta que puede ser calificada de malware o de herramienta de hackeo. La duda existe porque ni Wikileaks ni el manual de la CIA detallan esta vez cómo funciona exactamente la herramienta, ni cómo la usaban los operativos de la CIA. A pesar de ello, con la información publicada, se puede intentar entender cuál era el funcionamiento y el objetivo de la herramienta.

cia-smartphone-highrise

En cuanto a qué móviles estaba destinada, Highrise funcionaba en su versión 2.0(fechada en el 16 de diciembre de 2013) en móviles Android 4.0 a 4.3, lo cual tiene mérito, pues Android 4.3 llevaba lanzado en el mercado apenas 5 meses, y la última versión Android 4.4 KitKat había visto la luz justo un mes y medio antes.

Una semana antes de la fecha del manual fue lanzada Android 4.4.2, por lo que esta herramienta se encontraba bastante actualizada. Es como si ahora mismo se encontrara actualizada por tiempo de lanzamiento a Android 7.1.2 Nougat, con fecha del 4 de abril. Por tanto, podemos suponer que es muy probable que tenganversiones actualizadas para las últimas versiones de Android.

LOS DATOS SE ENVIABAN A TRAVÉS DE LOS SMS

Normalmente, los malware usan la conexión a Internet para enviar los datos robados de un dispositivo hackeado a un servidor controlado por ellos. En el caso de los móviles, también existe una vía alternativa para hacer esto: los SMS.Analizar y ordenar los datos de muchos SMS conteniendo información del móvil infectado es una tarea tediosa, y aún más cuando hay que analizar varios móviles.

smartphone-hacking-tool

Con esto en mente, la CIA creó TideCheck, una simple aplicación para Androidque hace las veces un proxy SMS entre el dispositivo infectado y el servidor que recibe la información. Según se desprende del manual, los operativos tenían que instalar la aplicación en sus móviles Android para recibir la información que estaban robando de los dispositivos infectados.

HighRise-2_0-Users_Guide

El procedimiento de uso era bastante sencillo. Una vez instalada la aplicación, solicitaba una contraseña antes de ejecutarse (la contraseña era “inshallah”, que en árabe significa “Si Alá/Dios quiere”). Una vez dentro, daba tres opciones:

  • Iniciar, para ejecutar el servicio.
  • Mostrar/Editar configuración, para configurar ajustes básicos como la URL del servidor de escucha, que debía ser HTTPS. También permitía conocer la ubicación o el estado de batería del móvil infectado.
  • Enviar mensaje, que permite a un operativo de la CIA mandar manualmente mensajes cortos al servidor de escucha para cerciorarse de que la comunicación funcionaba.

Fuente:https://www.adslzone.net/2017/07/13/highrise-asi-robaba-la-cia-datos-de-moviles-sin-conexion-internet/

Byaci

SIMULADOR DE ATAQUES DDOS GENERADOS POR BOTNET.

BoNeSi es un simulador de ataques de DDoS generados por Botnet en un entorno de prueba. Está diseñado para estudiar el efecto de los ataques DDoS, en redes y sistemas. BoNeSi genera ataques de inundación ICMP, UDP y TCP (HTTP) desde un tamaño de botnet definido (diferentes direcciones IP). BoNeSi es altamente configurable y puede configurarse: tarifas, volumen de datos, direcciones IP de origen, URLs y otros parámetros.

Hay un montón de herramientas por ahí para spoof de direcciones IP con inundación UDP e ICMP, pero para la suplantación de TCP, no hay solución. BoNeSi es la primera herramienta para simular las inundaciones HTTP-GET de las redes de bot a gran escala. BoNeSi también intenta evitar generar paquetes con patrones fácilmente identificables (que pueden ser filtrados fácilmente). El TCP Spoofing consiste en que BoNeSi snifa paquetes TCP en la interfaz de red y responde a todos los paquetes para establecer conexiones TCP. Para esta función, es necesario que todo el tráfico del servidor web de destino se enrute de vuelta al host que ejecuta BoNeSi.

Recomendamos encarecidamente que se ejecute BoNeSi en un entorno de prueba cerrado. Sin embargo, los ataques UDP e ICMP se pueden ejecutar en Internet, pero se debe tener cuidado. Los ataques HTTP-Flooding no se pueden simular en Internet, ya que las respuestas del servidor web deben volver a enviarse al host que ejecuta BoNeSi.

Los desarrolladores ponen como ejemplo de rendimiento que en un AMD Opteron con 2Ghz pudieron generar hasta 150.000 paquetes por segundo. En un más reciente AMD Phenom II X6 1100T con 3.3Ghz puede generar 300.000 pps (corriendo en 2 núcleos).

Los ataques UDP/ICMP pueden llenar fácilmente el ancho de banda y los ataques HTTP-Flooding eliminan rápidamente los servidores Web. Los desarrolladores aseguran que probaron  BoNeSi contra los sistemas de mitigación de DDoS comerciales de última generación y afirman que es posible posible atacarlos y ocultar el ataque de ser detectado.

Los atributos de los paquetes y conexiones creados pueden ser controlados por varios parámetros como la velocidad de envío o el tamaño de la carga útil. Incluye una simple pila tcp para manejar las conexiones tcp en modo promiscuo. Para un trabajo correcto, hay que asegurarse de que los paquetes de respuesta se encaminan al host en el que BoNeSi se está ejecutando. Por lo tanto BoNeSi no se puede utilizar en infraestructuras de red arbitrarias. El tipo de tráfico más avanzado que se puede generar son las solicitudes http.

Con el fin de hacer las solicitudes http más realista, hay que tener estos parámetros en cuenta:

  • Puerto de origen.
  • TTL: 3..255.
  • Opciones de tcp: pose siete opciones diferentes de vida real con diferentes longitudes y probabilidades
  • Agente de usuario para la cabecera de HTTP.

Fuente: http://www.gurudelainformatica.es/2017/07/simulador-de-ataques-ddos-generados-por.html / https://github.com/Markus-Go/bonesi