jueves, 21 de enero de 2016

Nueva ola de ataques contra la industria energética ucraniana

El pasado 19 de enero descubrimos una nueva ola de ataques, donde una vez más las víctimas fueron una serie de empresas de distribución de electricidad en Ucrania tras los apagones energéticos de diciembre. Lo que resulta particularmente interesante es que el malware utilizado en esta ocasión no es BlackEnergy, planteando así más preguntas acerca de los autores detrás de la operación en curso. El malware se basa en un backdoor de código abierto disponible en forma gratuita: algo que nadie podría esperar de un presunto operador de malware patrocinado por el estado.

Detalles sobre el ataque

El escenario de ataque en sí no ha cambiado mucho con respecto al descrito en nuestra publicación anterior de este blog. Durante el pasado martes 19, los atacantes enviaron correos electrónicos de phishing dirigidos a las posibles víctimas. Cada correo electrónico contenía un archivo adjunto con un .XLS malicioso:

Correo electrónico de phishing dirigido, enviado el 19 de enero de 2016html-pngarchivo-XLScodigo-ejecutablepython_codigo
  • VBA/TrojanDropper.Agent.EY
  • Win32/TrojanDownloader.Agent.CBC
  • Python/Agent.N
Reflexiones y conclusiones
  1. Probablemente se trate del primer caso en que un ciberataque de malware haya provocado un corte de energía eléctrica a gran escala.
  1. Los principales medios de comunicación le atribuyeron popularmente los ataques a Rusia, a partir de los reclamos de varias empresas de seguridad de que la organización que utiliza BlackEnergy (también conocido como Sandworm o Quedagh) está patrocinada por el estado ruso.
Indicadores de sistemas comprometidos
62.210.83.213BC63A99F494DE6731B7F08DD729B355341F6BF3D


El pasado 19 de enero descubrimos una nueva ola de ataques, donde una vez más las víctimas fueron una serie de empresas de distribución de electricidad en Ucrania tras los apagones energéticos de diciembre. Lo que resulta particularmente interesante es que el malware utilizado en esta ocasión no es BlackEnergy, planteando así más preguntas acerca de los autores detrás de la operación en curso. El malware se basa en un backdoor de código abierto disponible en forma gratuita: algo que nadie podría esperar de un presunto operador de malware patrocinado por el estado.
El escenario de ataque en sí no ha cambiado mucho con respecto al descrito en nuestra publicación anterior de este blog. Durante el pasado martes 19, los atacantes enviaron correos electrónicos de phishing dirigidos a las posibles víctimas. Cada correo electrónico contenía un archivo adjunto con un .XLS malicioso:
Correo electrónico de phishing dirigido, enviado el 19 de enero de 2016
El correo electrónico incluye contenido HTML con un enlace a un archivo .PNG ubicado en un servidor remoto para que los atacantes reciban una notificación cuando el correo electrónico es entregado y abierto por la víctima deseada. Sabemos que el grupo BlackEnergy ha utilizado esta misma técnica interesante en el pasado.
Fragmento del contenido HTML del correo donde figura el archivo PNG
También resulta curioso que el nombre del archivo PNG sea la cadena de texto “enviar_a_correo_electrónico_ de_la_víctima”, codificada en base64.
Archivo XLS utilizado en los ataques
El archivo XLS malicioso habilitado para macros es similar a los que ya hemos visto en olas de ataques anteriores. Mediante el uso de Ingeniería Social, intenta engañar al destinatario para que haga caso omiso de la advertencia de seguridad de Microsoft Ofifice y ejecute la macro de todas formas. El texto del documento, traducido del ucraniano, dice:
¡Atención! Este documento se creó con una versión más reciente de Microsoft Office. Es necesario habilitar macros para mostrar el contenido del documento.
La ejecución de la macro activa un trojandownloader malicioso que intenta descargar y ejecutar el payload final desde un servidor remoto.
Fragmento de código extraído del archivo ejecutable
El servidor que aloja el payload final está ubicado en Ucrania y se cerró tras la notificación de CERT-UA y de CyS-CERT.
Esperábamos encontrar el malware BlackEnergy como payload final, pero en cambio, en este caso se utilizó un malware diferente. Los atacantes emplearon versiones modificadas de un backdoor gcat de código abierto escrito en el lenguaje de programación Python. Luego se utilizó el programa PyInstaller para convertir el script en python a un archivo ejecutable autosostenible.
Código ofuscado del backdoor GCat
Este backdoor es capaz de descargar archivos ejecutables y ejecutar comandos de shell. Las demás funcionalidades del backdoor GCat (como tomar capturas de pantalla, registrar las pulsaciones del teclado o subir archivos) fueron eliminadas del código fuente. Los atacantes lo controlan mediante una cuenta de Gmail, lo que dificulta la detección de este tipo de tráfico en la red.
Las soluciones de seguridad de ESET detectan esta amenaza como:
Desde que descubrimos estos ataques y comenzaron a aparecer las primeras publicaciones en blogs, se han ganado la atención mediática en todo el mundo. Las razones para ello son dos:
El primer punto ha sido un tema de debate en cuanto a si el malware realmente causó el corte de luz o si solo “lo hizo posible”. Si bien existe una diferencia en los aspectos técnicos de ambas opciones y como naturalmente estamos interesados en los detalles más minuciosos cuando analizamos el malware, en el plano superior en realidad no importa. De hecho, esa es la esencia misma de los backdoors maliciosos: concederles a los atacantes el acceso remoto a un sistema infectado.
El segundo punto es aún más controversial. Como ya mencionamos antes, hay que tener mucho cuidado antes de acusar a un actor específico, sobre todo si es un estado nación. Actualmente no tenemos ninguna evidencia que indique quién está detrás de estos ataques, e intentar atribuirle la culpa a alguien por simple deducción basada en la situación política actual podría llevarnos a la respuesta correcta, o tal vez no. De una forma u otra, no deja de ser mera especulación. El descubrimiento actual sugiere que también habría que contemplar la posibilidad de que se trate de una operación de bandera falsa.
En resumen, el descubrimiento actual no nos ayuda a dilucidar el origen de los ataques en Ucrania. Por el contrario, nos recuerda que debemos evitar llegar a conclusiones precipitadas.
Seguimos monitoreando la situación para conocer su desarrollo futuro. Ante cualquier duda o para enviar muestras relacionadas con este tema, escríbenos a: threatintel@eset.com
Direcciones de IP:
193.239.152.131
SHA-1 del archivo XLS malicioso:
1DD4241835BD741F8D40BE63CA14E38BBDB0A816
SHA-1 de los archivos ejecutables:
920EB07BC8321EC6DE67D02236CF1C56A90FEA7D

miércoles, 20 de enero de 2016

Hospital que todavia usa windows XP infactado con malware

A pesar de que en abril de 2014 Microsoft puso fin al soporte para Windows XP, y de que tanto la compañía como expertos de seguridad han insistido en la necesidad de migrar hacia sistemas operativos más modernos, sigue habiendo organizaciones que utilizan esa vieja distribución. Tal es el caso del hospital Royal Melbourne de Australia, que fue víctima de un malware en sus sistemas.
Su último comunicado oficial dice: “Si bien el virus fue disruptivo para la organización, debido al trabajo incansable del personal hemos sido capaces de minimizar esta interrupción a nuestros pacientes y garantizar que su seguridad se ha mantenido”. Desde ayer, “muchos programas afectados por el virus están funcionando incluyendo patología y farmacia”.
Las computadoras de varios sistemas del hospital ya han sido desinfectadas, afirma, y el equipo de IT continúa trabajando para restaurar algunas otras tan pronto como sea posible. Todas ellasutilizan Windows XP, sistema operativo lanzado en 2001 que dejó de recibir actualizaciones y soporte de Microsoft el 8 de abril de 2014. A partir de ese momento, utilizarlo implica un grave riesgo de seguridad ya que los equipos quedan expuestos a potenciales vulnerabilidades 0-day que no serían corregidas.
Y en el caso puntual de las instituciones de salud, como lo es el hospital Royal Melbourne, hay mucha información sensible que debe ser reguardada con las medidas de seguridad adecuadas – entre las cuales está contar con sistemas y aplicaciones actualizados.
Tras la intrusión del virus, según informa Softpedia, algunos departamentos del hospital debieron hacer en forma manual procesos que ya se habían automatizado con las máquinas con Windows XP, como por ejemplo el procesamiento de sangre y tejidos, o la asignación de raciones de comida. El personal recibió el alerta de no acceder a ningún enlace o sitio web que parezca sospechoso ni ingresar credenciales en páginas a las que fueran redireccionados.
Ciertamente, lo ideal sería que no hubiera organizaciones con sistemas obsoletos, pero claro que la migración requiere de una inversión que no todas están dispuestas a afrontar. En casos en que no fuera posible la actualización a versiones como Windows 7, Windows 8.1 o Windows 10, es primordial contar con copias de respaldo de la información (backup) y una solución de seguridad que ayuden a mantener los niveles de seguridad más altos posibles en el entorno.

martes, 19 de enero de 2016

malware que mejora tu seguridad.

Alguien está comprometiendo miles de routers en varios países pero con el único objetivo de fortificarlos. De momento no se sabe exactamente quién está detrás, pero se trata de una pieza de malware que Symantec ha bautizado como "Linux.Wifatch". El software malicioso comprueba que la contraseña existente no es la de por defecto y, si la es, obliga a cambiarla. También elimina otros tipos de malware conocido y fuerza la actualización de software.



Paradójico, ¿verdad? Un malware que se encarga de mejorar la seguridad de los dispositivos de IoT para que no les afecten otro tipos de malware...
"No hemos visto ninguna actividad maliciosa en absoluto", dijo Val Saengphaibul de Symantec. "Sin embargo, en el sentido jurídico, se trata de una actividad ilegal. Están accediendo a dispositivos de red sin el permiso del propietario".
De momento ya ha infectado a más de 10.000 routers basados en Linux, la mayoría en China y Brasil. ¿Serán totalmente altruistas las intenciones de este Robin Hood de los hackers?
Fuentes:Is there an Internet-of-Things vigilante out there? New ‘Vigilante’ Malware Protects Routers Against Security Threats A vigilante hacker is forcing you to change your password A vigilante hacker is changing 10,000 WiFi passwords Linux.Wifatch ‘malware’ is actually making routers more secure

lunes, 18 de enero de 2016

Escalando privilegios cuando existe una mala configuracion.

En numerosas ocasiones, algunos de los programas que instalamos en el ordenador requieren un servicio que se ejecute en segundo plano, ya sea de forma contínua o una única ejecución al iniciar el sistema. Estos servicios acostumbran a utilizarse para tareas de actualización, sincronización y demás utilidades que requieran un chequeo periódico. La mayoría de estos servicios se ejecutan con el usuario de sistema local (system) y ejecutan un binario que se encarga de la tarea a realizar.

Ayer veíamos con la técnica de Hot Potato como podíamos aprovechar las conexiones que intentan hacer estos servicios para llamar a ejecutables con sus privilegios, redireccionando las peticiones HTTP a SMB.

Sin embargo, hay una forma mucho más sencilla que es sustituyendo el ejecutable del servicio por otro que, por ejemplo, nos cree un usuario administrador. Evidentemente esto es posible sólo debido a una mala configuración, porque para hacerlo necesitamos que estén mal asignados los permisos. Sin embargo, aunque parezca mentira, en muchísimos servidores me he encontrado servicios que usan ejecutables con acceso total para todos o para el grupo de usuarios (sobretodo con herramientas propias o desarrollos a medida).

El escenario es el siguiente:


-    Tenemos acceso a una maquina con un usuario local, sin permisos de administrador.



-  Detectamos un binario que es llamado por un servicio y que tiene permisos totales para el grupo Usuarios (para el PoC, hemos modificado los permisos del Updater.exe de Skype):



Una vez en este punto, debemos crear un pequeño exe que se encargará de crear una cuenta de administrador y lo sustituiremos por el original, para que al reiniciar el servicio o la máquina se ejecute nuestro código:



La segunda línea se encargará de añadir el nuevo usuario al grupo administradores.Evidentemente en la vida real tendremos que poner una contraseña que cumpla los requisitos normales de complejidad y un nombre de usuario no existente para evitar duplicidades.


Como podemos observar, no podemos ejecutar el .exe sin permisos de administrador, pero el servicio se encargará de ejecutarlo por nosotros.
Reiniciamos la maquina y comprobamos los usuarios:




Y ya podemos acceder con el nuevo usuario con permisos de administrador.

domingo, 17 de enero de 2016

Escalado de privilegios en Windows 7,8,10, Server 2008, Server 2012 mediante Hot Potato

Hot Potato de @breenmachine son varias técnicas para escalar privilegios en Güindous. Básicamente podríamos decir que primero redirecciona todo el tráfico HTTP a local para capturar las peticiones de los servicios de la máquina, luego las responde mediante solicitudes de peticiones de autenticación NTLM que reenvía a un servidor SMB local, que finalmente crea un servicio que ejecuta un comando (un cmd.exe por ejemplo) con los privilegios correspondientes.


Así dicho de golpe parece un embrollo, así que vamos a ver paso a paso cómo hacerlo...

En una red local cualquier aplicación puede utilizar Web Proxy Auto Discovery Protocol (en adelante WPAD) para encontrar proxies para poder salir a Internet. Esa información con sus reglas y demás está en un fichero javascript wpad.dat que está en un servidor WPAP accesible mediante la URL: http://wpad/wpad.dat. Esto lo implementó Netscape en 1996 y la verdad es que después de tantos años no ha cambiado demasiado.

En el primer paso del ataque debemos hacer que nuestra máquina no envíe las peticiones HTTP a un proxy real si no a nuestro propio equipo, y eso pasa por falsificar la URL para que apunte a localhost.

1. Falsificador local Netbios

Los clientes pueden recibir la ubicación de wpad.dat mediante DHCP (opción 252) o resolviendo el nombre del servidor WPAD y haciendo un HTTP GET a la URL. Como sabéis el orden normal de resolución de nombres es el fichero host, luego la resolución DNS y finalmente un broadcast UDP mediante NetBIOS Name Service (NBNS).

Un equipo Windows por defecto no tendrá entrada 'wpad' en el fichero host así que el siguiente paso será la consulta al servidor DNS. Normalmente no suele haber ningún registro A 'wpad' pero por si acaso se utiliza una técnica llamada 'agotamiento de puertos UDP' que consiste en usar todos los puertos UDP disponibles (esto en localhost se consigue bastante rápido) para que, a la hora de intentar realizar una consulta DNS, falle porque no hay puertos UDP origen disponibles.
A continuación la tercera vía será la consulta Netbios que tendremos que falsificar para que 'wpad' nos devuelva 127.0.0.1. En principio y sin privilegios no podremos esnifar el tráfico para hacer un MiTM, así que lo que haremos será inundar el host con respuestas NBNS (ya que es un protocolo UDP). Una complicación es que el paquete NBNS tiene un campo de 2 bytes, el IDTX, que no podemos ver y que debe coincidir en la solicitud y la respuesta. Sin embargo podemos iterar sobre todos los 65536 valores posibles al hacerlo rápidamente.


2. Servidor WPAD falso

Una vez que hemos conseguido que 'wpad' resuelva 127.0.0.1, debemos levantar un servidor HTTP en local que cuando reciba una petición a "http://wpad/wpad.dat" responda algo como:

FindProxyForURL(url,host){
if (dnsDomainIs(host, "localhost")) return "DIRECT";
return "PROXY 127.0.0.1:80";}


Esto hará que todo el tráfico HTTP sea redirigido a través de nuestro servidor se ejecuta en local/127.0.0.1.

Lo curioso que además afectará a todos los usuarios de la máquina, incluyendo administradores y cuentas del sistema.

3. HTTP -> SMB NTLM Relay

Anteriormente el protocolo NTLM era vulnerable a ataques MiTM. Por ejemplo un atacante capturaba los intentos de autenticación mediante el protocolo SMB y los podía reenviar contra la propia máquina de la víctima o a otro servidor para obtener acceso mediante psexec o similar. No obstante, Microsoft ya parcheó ésto desactivando la posibilidad de usar la misma autenticación NTLM con un challenge ya en uso, algo que sin embargo sigue funcionando desde otros protocolos como HTTP (HTTP->SMB) como ya vimos recientemente en el blog.

Como en los dos pasos anteriores hemos trabajado para redireccionar todo el tráfico HTTP a través de un servidor local que controlamos, podemos hacer cosas comoredirigirlos a algún sitio que solicite la autenticación NTLM.

Con el exploit de Potato, todas las peticiones HTTP se redirigen a una redirección 302 a "http://localhost/GETHASHESxxxxx", donde xxxxx es un identificador único. Las solicitudes de "http://localhost/GETHASHESxxxxx" responden con una petición 401 para autenticación NTLM.

A continuación, las credenciales NTLM son retransmitidas a un listener SMB local que crea un nuevo servicio de sistema que ejecuta un comando definido por el usuario.

Cuando la solicitud HTTP en cuestión se origina desde una cuenta de privilegios elevados, por ejemplo, cuando se trata de una solicitud del servicio de Windows Update, este comando se ejecutará con el privilegio "NT AUTHORITY\ SYSTEM"... bingo!

Usando el exploit

Su uso depende del sistema operativo.

También es un poco extraño a veces, debido a las peculiaridades en la forma en que Windows maneja la configuración del proxy y el archivo WPAD. A menudo, cuando el exploit no funciona, es necesario dejarlo correr y esperar. Cuando Windows ya tiene una entrada de caché para WPAD o está permitiendo el acceso directo a Internet, porque no se encontró WPAD, podría tomar 30-60 minutos para que se actualice el archivo WPAD. Es necesario dejar el exploit se ejecute y tratar de probar de nuevo más tarde, una vez transcurrido este tiempo.

Las técnicas que se enumeran aquí se ordenan de menor a mayor complejidad. Las técnicas del final de la lista deberían funcionar en todas las versiones anteriores. Se incluyen vídeos y capturas de pantalla para cada uno.


Windows 7 - ver https://youtu.be/Nd6f5P3LSNM

Windows 7 puede explotarse de forma fiable a través del mecanismo de actualización de Windows Defender.

Potato.exe tiene código para desencadenar automáticamente ésteBasta con ejecutarlosiguiente:

Potato.exe -ip -cmd [cmd to run] -disable_exhaust true

Esto hará funcionar al Spoofer NBNS, falsificando "WPAD" a 127.0.0.1, y a continuación,comprobará si hay actualizaciones de Windows Defender.

Si la red tiene una entrada DNS para "WPAD" puedes intentar "-disable_exhaust false".Esto debería hacer que la búsqueda de DNS falle e intente la resolución por NBNSEsto parece funcionar bastante bien en Windows 7.


Windows Server 2008 - Ver https://youtu.be/z_IGPWgL5SY

Como Windows Server no viene con Defender, necesitamos un método alternativo. En su lugar vamos a comprobar simplemente las actualizaciones de Windows. La otra advertencia es que en algunos dominios el servidor 2K8 pregunta por WPAD.DOMAIN.TLD en lugar de sólo WPAD. El siguiente es un ejemplo de uso:

Potato.exe -ip -cmd [cmd to run] -disable_exhaust true -disable_defender true -spoof_host WPAD.EMC.LOCAL

Después de se ejecute correctamente, basta con comprobar si hay actualizaciones de Windows. Si no se activa, espera unos 30 minutos con el exploit funcionando y vuelve a intentarlo. Si aún así no funciona, intenta descargar alguna actualización.

Si en la red hay una entrada DNS para "WPAD", de igual forma que antes puedes intentar usar "-disable_exhaust false". Sin embargo, el agotamiento DNS hace que TODAS las búsquedas fallen y el proceso de actualización de Windows podría tener que hacer algunas búsquedas de DNS antes de llegar a WPAD... por lo que tendría que hacerse en el momento oportuno para que funcione en este caso.


Windows 8/10/Server 2012 - Ver https://youtu.be/Kan58VeYpb8

En las últimas versiones de Windows, parece que la actualización de Windows ya no "respeta" la configuración de proxy fijada en "Opciones de Internet" ni detecta WPAD. En su lugar, las configuración del proxy para Windows Update se controla con “netsh winhttp proxy…”

Aunque también contamos con una característica nueva de Windows, el "actualizador automático de certificados no confiables". Los detalles se pueden encontrar enhttps://support.microsoft.com/en-us/kb/2677070 y https://technet.microsoft.com/en-us/library/dn265983.aspx

Desde el artículo de TechNet "Windows Server 2012 R2, Windows Server 2012, de Windows 8.1 y Windows 8 incluyen un mecanismo de actualización automática que descarga las listas de confianza de certificados (CTL) diariamente".

Parece que esta parte de Windows todavía utiliza WPAD, incluso cuando la configuración del proxy se controle mediante winhttp.

En este caso el uso de Potato es el siguiente:

Potato.exe -ip -cmd [cmd to run] -disable_exhaust true -disable_defender true

En este punto, tendremos que esperar hasta 24 horas o encontrar otra manera de accionar esta actualización.

Si la red tiene una entrada DNS para "WPAD", consulta la documentación en Server 2008. El agotamiento de puerto podría ser complicado... 


TODO: Firma SMB?

No está claro si este ataque va a funcionar cuando SMB signing esté habilitado. El exploit actual no lo hace, pero puede ser debido a la falta de soporte en la librería CIFS usada. La razón para sospechar que puede funcionar es que todo está sucediendo en 127.0.0.1. Si las firmas se basan en host, ¿podrían coincidir?

Un nuevo ataque de red

Pensemos de nuevo en el ataque de suplantación NBNS.

Utilizando la misma técnica de fuerza bruta TxID, técnicamente podríamos realizar ataques de suplantación NBNS fuera de nuestra red local. De hecho, en teoría, siempre y cuando haya una conexión lo suficientemente rápida como para soportarlo, debemos ser capaces de realizar ataques de suplantación NBNS contra cualquier hosts de Windows con el que podemos hablar a través del puerto UDP 137.

En realidad, aunque funciona en la práctica en la red local, todavía se tiene que probar más y verificarlo a través de Internet.

Estan lanzando una versión modificada de la herramienta "Responder.py" que lleva a cabo este ataque. El siguiente video muestra el ataque a una red distribuida de la siguiente manera:

     - firewall pfSense
     - 10.0.0.0/24 -> LAN corporativa
     - 10.0.1.0/ 24 -> Servidor de red
     - Desde la red de la empresa, vamos a atacar a una máquina en la red de servidores.

Demostraciónhttps://youtu.be/Mzn7ozkyG5g


Página de GitHubhttps://github.com/foxglovesec/Potato

Fuentehttp://foxglovesecurity.com/2016/01/16/hot-potato/  

sábado, 16 de enero de 2016

Roban datos de huéspedes del Hyatt en 50 países, algunos de Latinoamérica

A fines de noviembre de 2015, la cadena de hoteles Hyatt advirtió la presencia de malware en computadoras que operan sus sistemas de procesamiento de pagos; la investigación comenzó inmediatamente y hoy se sabe que los cibercriminales lograron robar datos de tarjetas de clientes en 250 localidades de 50 países alrededor del mundo. Entre ellos, cinco son de Latinoamérica: Argentina, Chile, Brasil, México y Panamá.
Chuck Floyd, Presidente Global de Operaciones de Hyatt Hotels Corporation, firma un comunicado que explica:
La investigación identificó signos de acceso no autorizado a datos de las tarjetas de pago utilizadas en algunos lugares administrados por Hyatt, principalmente restaurantes, entre el 13 de agosto de 2015 y el 8 de diciembre de 2015.
Un pequeño porcentaje de las tarjetas en riesgo se utilizó en spas, tiendas de artículos de golf, estacionamientos, y en una cantidad limitada de recepciones de hoteles o se entregó a una oficina de ventas durante este período.
Esto significa que, si bien la compañía tomó las medidas necesarias para remediar el incidente desde el punto de vista técnico y trabajando con expertos en seguridad, los clientes cuyos datos de tarjeta hayan sido robados podrían seguir en riesgo de que se hagan compras no autorizadas en su nombre. Por tal motivo, es importante que todas las personas que se hayan hospedado en hoteles Hyatt en el período indicado revisen atentamente sus resúmenes de cuenta para advertir posibles fraudes.
Según explica Floyd, “el software maligno fue creado para recolectar datos de tarjetas de pago – nombre del titular, número de la tarjeta, fecha de vencimiento y código de verificación interno – utilizadas in situ mientras se transmitían a través de los sistemas de procesamiento de pago afectados”.
De más está decir que, con una correcta política de seguridad y medidas preventivas aplicadas con precisión, el incidente quizás podría haberse evitado. El Hyatt no es el primer hotel que falla al resguardar los datos de sus huéspedes: en noviembre de 2015, la cadena Hilton también confirmó haber sido víctima de un malware PoS en sus sistemas.
Pero ahora Hyatt dice que remedió la infección e instaló medidas de seguridad adicionales para prevenir futuros ataques. “Proteger la información de clientes es críticamente importante para Hyatt, y nos tomamos la seguridad de los datos de clientes muy seriamente”, afirma.
La empresa publicó la lista de completa de hoteles por país que se vieron afectados.
Créditos imagen: ©Daniel Piraino/Flickr

viernes, 15 de enero de 2016

el foro infierno a vuelto.

Nos referimos a que ha vuelto Hell, un foro en la Dark Web en la que se comparten datos robados, técnicas de hacking y otra información *interesante* y que se hizo famoso después de que fuera (supuestamente) descubierto y cerrado por las autoridades policiales en julio de 2015, sobretodo porque uno de sus miembros publicó datos de más de 4 millones de usuarios de Adult Friend Finder. Incluso se especuló de que su admin y fundador "ping" fue detenido, aunque luego reapareció días después. 

Ahora otro admin, "HA", ha relanzado el foro: "Hell es ahora público. Cualquiera puede compartir la URL de HELL donde mejor le parezca".

Muchos desconfían del foro y les preocupa que se trate de un frente utilizado por las autoridades policiales para atraer a usuarios notorios y cogerlos in fraganti. De momento ya han filtrado información confidencial de LifeSafer, una compañía famosa en EE.UU. por instalar alcoholímetros para controlar el arranque de los coches (¡atención borrachos!).

See recomienda usar siempre PGP. No hay reglas ni límites. Si quieres entrar (allá cada cual), en el momento de escribir este post, la URL de Tor para acceder al blog es http://legionhiden4dqh4.onion (o con tor2web http://legionhiden4dqh4.onion.to). Eso sí, no se os ocurra andar pidiendo claves de invitación para registrarse...

Fuentes:
Hell is back with Hell Reloaded on the Dark Web 
Re-Booted Hell Hacking Forum on Dark Web Hacks Car Breathalyzers Manufactures 
Darknet Hacking Forum “Hell” Returns After Shutdown

jueves, 14 de enero de 2016

Shodan: Camaras publicas en El Salvador filtros de búsqueda

Antes que nada esto noes un proceso nada complicado , cualquiera puede realizarlo lo que hemos hecho es clasificar los filtros mas potentes para buscar en nuestro país camaras de seguridad los cuales en su mayoría están aun con password y usuario por predeterminado de la cámara que en su mayoría es "admin , admin"

Shodan nos permite hacer diferentes filtros para poder encontrar los dispositivos que buscamos por ejemplo el primer filtro que usaremos sera : 

Server: GeoHttpServer country:sv
 

lo cual nos brinda un total de 8 cámaras lo cual no es una cifra muy grande pero esto nos brinda acceso a camaras que estan usando un servidor geohttpServer el cual tiene la siguiente característica : No debemos de saber la clave ni comenzar a indagar con las claves por default que pudieran ser en este caso ya que este te deja fisgonear en modo "guest"


Lo cual nos brinda una vista de unas de las calles de san salvador y existen 16 cámaras más solo en este servidor.



otro filtro que es demasiado bueno para cuando se tratan de hacer búsquedas regionales es :


port:37777 country:sv

Usar este filtro además de traerse las cámaras web conectadas a una salida por medio del puerto 80 , da un cantidad de IP's bastante grande con la cual ya podemos aplicar filtros como por "ciudad" por ejemplo si quisieras buscar solo los de "santa tecla" el filtro seria el siguiente "port:37777 country:sv city:santa tecla".



también la gran mayoría de estos cuando se les da click a las cámaras muestra la siguiente interfaz la cual por supuesto responde a la contraseña por default que posee casi todas las cámaras de seguridad "usuario:admin pass:admin" lo cual esperamos que corrijan esto ya que es algo que se debe de cambiar el primer dia.



Luego de esto llegamos a una interface con todas las funciones que da el segmento de cámaras , podemos configurarlo, grabar, tomar fotos, crear Alarmas, etc. "muy bonito los servidores que tienen ahi por cierto".



Y así existen docenas de lugares en el salvador los cuales llegaron solo a ponerles las cámaras de seguridad sin configurar absolutamente nada, casi todos responden a "admin,admin", "admin, enter" , "root,root" y otras contraseñas por default.

La lista de los demás filtros de cámaras en el salvador a continuación traen una gran cantidad de cámaras que no solo responden a los password por default sino que a veces ni un login poseen:

Server: GeoHttpServer country:sv

server: boa WWW-Authenticate: Camera country:sv

Content-Length: 2574 country:sv

port:37777 country:sv

title:'+tm01+' country:sv

netwave ip camera country:sv

netwave ip camera country:sv


axis country:sv

Pero esto no acaba Aquí también encontramos accesos a los VDR de las cámaras lo cual nos dio bastante gracia por lo siguiente.

Filtro para los VDR: 
title:"Network Video Recorder" country:sv

No entendemos que sea posible que se tomen la molestia de agregar un SSL y no cambiar la password de default admin , admin .. pero bueno son cosas con las que uno se encuentra en internet.



Luego de esto ya tenemos acceso a todo practicamente , podemos ver el espacio disponible de 308 gb podemos borrar todas las grabaciones , ver las camaras , generar eventos de grabación etc. todas las opciones están a nuestra disponibilidad , y esto creemos que es de una gasolinera  ya que hace referencias a bombas.



Pero luego de esto también nos tomamos la molestia de alertar a ciertas personas que sus camaras web no tienen la configuración adecuada ya que son demasiadas y tienen prácticamente todo de fabrica hasta la contraseña y que por favor actualizaran sus credenciales para ingresar a las camaras y nos sorprendimos que fue bien recibido eso y no se contesto de una manera hostil ya que no a todo mundo le gusta que le muestren sus errores.



Con esto terminamos esta investigación y si van a instalar camaras de seguridad por favor cambiar el password y el usuario por default que traen algunas camaras.

saludos, 



miércoles, 13 de enero de 2016

Apps Mágicas para Hackear Facebook.

Conseguir la contraseña de Facebook de una cuenta es una de las peticiones más usuales que se suele recibir de la gente que busca solucionar sus problemas invadiendo la intimidad de las personas cercanas. Hay una gran demanda para este tipo de servicios, y por ende aparece la oferta de este tipo de servicios por medio de muchas maneras, casi todas con el fin de engañar al que busca hackear Facebook. Desde engaños al uso de "págame y ya me pongo yo a conseguirte la contraseña que yo hago unos troyanos superfuertes", hasta las típicas falsas apps mágicas que se comercializan para espiar WhatsApp en las que supuestamente pones un número de teléfono y al instante te da las conversaciones que de la otra persona. 



Estas apps mágicas para espiar son algo muy utilizado en el mundo del fraude online, y en casos como las apps mágicas para WhatsApp han generado auténticos negocios como hemos visto en el pasado. 



La encontré mientras buscaba apps hablaran de SQL Injection y me llamó poderosamente la atención.  "¿Una app para hackear Facebook que está relacionada con SQL Injection? Esto hay que verlo". Tal y como se puede ver en la imagen de arriba, el crespón negro indica que la app fue retirada de Google Play hace varios meses.

Figura 3: Descripción, descargas e información de FaceHack en Google Play

El asunto del SQL Injection aparecía en la descripción, donde los autores presumen de que son unos tipos son unos mega hax0RDs con capacidades superiores a las que tienen los ingenieros de seguridad de Facebook y todos los investigadores que participan en el Bug Bounty y son capacidades de sacar las passwords usando Fuerza Bruta y bugs de SQL Injection que solo ellos tienen. Tiene gracia, pero ya que vas a meter una trola a alguien, que sea a lo grande, ¿no?. De hecho no será la primera vez que alguna gran empresa como Apple se come ataques de Brute Force en sus servidores o bugs de SQL Injection en sitios de renombre.

Aún así, publicar un par de 0days de Facebook en una app en Google Play no parece lo más inteligente para un hax0RD del nivel de estos autores, así que esta canción se canta sola, así que decidí descargarla y darle un vistazo. Primero una descompresión del APK, luego una extracción del código con dex2jar para sacar los ficheros .class y luego usando JAD y Show My Code a leer un poco el código de la app y para ver la magia.

Al extraer el código se podía ver que la parte del ataque SQL Injection la tenían en una rama completamente a parte, así que me fui a ver qué hacían por allí. La función que más me gustó fue esta de DoSomeTasks para tener entretenido al usuario de la app.



Esta función se llamaba de vez en cuando con algunos retardos de tiempo para que se viera lo duro y cansado que era el trabajo de esta pobre app tratando de sacar la contraseña de la víctima.

Figura 5: Retardos de tiempo periódicos en la app

Eso sí, la contraseña la saca, y la saca con emoción. Al estilo que buscan los periodistas cuando graban un reportaje para la tele. Visualizando la tensión poco a poco por pantalla. Primero intentando conectar una vez con mucha dificultad.



Luego intentándolo otra vez, para al final conseguirlo y poder sacar por pantalla la password de la víctima que esta app mágica va a sacar para el atacante.



Cuando sale la contraseña, se la saca de una variable que se llama StrWhat? Str?¿De dónde ha salido ese Str con una password? Había que encontrar ese Str, así que a buscar la variable por todo el programa. Y ahí está, es mágico.



Como se puede ver, lo único que hace es tirar un dado y sacar una contraseña Random para mostrársela al usuario y listo. ¡Eso sí es magia! Alguno podrá pensar que esto es una locura, pero... ¿no hacen esto los magos todos los días en los programas de consultorio de magia en la tele y son legales y pagan sus impuestos? Eso sí, por pantalla tiran comandos SQL para que se vea el SQL Injection.



Lo cierto es que el ataque de Brute Force era similar, así que fui a capón en busca de la variable Str para ver cómo lo hacía en la otra rama del ataque, para ver que era exactamente el mismo juego de magia e imaginación.



¿Y todo por qué? Pues para monetizar el uso de la app con publicidad de Mobile Core, que nose olviden que en la descripción de esta app se puede ver que tenía ya más de 10.000 descargas de usuarios que buscaban robar passwords de otros.



Por supuesto, el truco este de la app mágica para hackear Facebook existe también en versión escritorio, e incluso hay un vídeo demostrativo de FaceHacker 2014 que demuestra como se obtienen las passwords. Unos crack de los efectos especiales en vídeo. Todo esto, con lo fácil que es robar una cuenta de Facebook en 5 segundos de descuido o buscar los posts privados o borrados en el índice de Google. Vista la cantidad de gente que hay buscando cómo hackear Facebook, fortifica tu cuenta cuanto antes.