El mal querido

Estándar

El día de hoy en el blog 9to5Mac, se daba a conocer que el iPhone 8 es el peor en ventas de los últimos años para la empresa de la manzana, esto es lo que se puede leer en dicho blog:

Los datos de compra provistos por el Consumer Intelligence Research Partners (CIRP) sugieren que el iPhone 8 se está vendiendo en menor cantidad que un modelo ‘S’.

La compañía dice que el iPhone 8 / Plus representó solo el 16% de todas las ventas de iPhone en el último trimestre, frente al 24% del iPhone 6S / Plus …

Dijo que los modelos “tic” del iPhone solían representar más del 40% de las ventas, incluso el iPhone 7, que representaba una iteración de diseño relativamente pequeña en su predecesor.

Parte de la razón de esto es que los fans de Apple están esperando el iPhone X y otros sugieren la poca diferenciación del iPhone 8 con respecto al iPhone 7.

Para hacer fácil la comparación estamos pegando el gráfico de CIRP que muestra la distribución de las ventas de iPhone por año desde el 2015:

Nadie sabe para quien trabaja

Estándar

Hay un viejo dicho español: “Nadie sabe para quien tabaja“, que refleja la incertidumbre de que ninguno de nosotros podemos estar seguros de quien se beneficiará por nuestro esfuerzo. Con clásicos ejemplos como el responsable y sacrificado padre que vive frugalmente para dejar un gran patrimonio a sus hijos, quienes al recibirlo lo despilfarran e incluso los bienes con tanto esfuero acumulados terminan en manos de los enemigos de quién se los ganó con empeño y sacrificio.

Pues, bien ese refrán lo podemos aplicar a lo sucedido con Coinhive, un proyecto de criptominería en el navegador que pretendía ofrecer una alternativa a la odiosa publicidad que vemos en infinitas páginas web. La idea propuesta por Coinhive es simple, intalar un script de Javascript en una página web y remover la publicidad de la misma, de esa forma en lugar de obtener financiamiento por poner anuncios en el contenido producido, se obteniene el pago a través de la capacidad de cómputo de la computadora del visitante.

La idea es atractiva y algunos generadores de contenido estaban comenzado a probarla de forma experimental para evaluar su viabilidad, pero el lunes pasado, la empresa oficialmente reconoció que había sido hackeada y que a través de los DNS de la misma, hackers habrían robado el producto de lo minado.

La historia es como sigue de acuerdo a ZDNet:

El proveedor de software de minería de criptomonedas dijo esta semana que aproximadamente a las 10 pm GMT del lunes, la firma recibió una nota de su proveedor de DNS, Cloudflare, que advirtió a Coinhive que un agente desconocido había accedido a su cuenta.

Los registros DNS de coinhive.com se han manipulado para redirigir las solicitudes de coinhive.min.js a un servidor de terceros, que contiene una versión modificada del archivo JavaScript con una clave de sitio codificada.

El código Javascript de Coinhive que es incrustado por los usuarios en sus sitios web como una forma de extraer la criptomoneda Monero, pero los atacantes pudieron secuestrar esta secuencia de comandos para garantizar que los fondos extraídos ingresaran en una billetera que controlaran ellos en lugar de billeteras de los usuarios.

“Esto esencialmente permite que el atacante” robe “hashes de nuestros usuarios”, dice Coinhive.

La secuencia de comandos utilizada para implementar la minería de criptomonedas en los dominios de sitios web es una idea nueva, aunque controvertida.

La minería para moneda virtual se está examinando como una alternativa a los anuncios de terceros como una forma de generar ingresos, y fue la prueba piloto de Pirate Bay la que propulsó la idea al centro de atención.

Debido a un error de codificación, los usuarios detectaron el minado del sitio web, ya que extraía enormes cantidades de energía de la CPU de los sistemas visitantes, en lugar de 20 a 30 por ciento como se pretendía originalmente.

Tras la reacción de los visitantes, The Pirate Bay admitió haber probado el script de minado como una “forma de deshacerse de todos los anuncios”.

Lo peor de todo es que la forma cómo este hacker tomo control de la cuenta de Cloudflare de Coinhive es de un robo de información ocurrido en el 2014, lo cual indica que por aproximandamente 3 años la empresa estuvo usando las mismas credenciales a pesar de saber que estas habían sido comprometidas:

Parece que las credenciales de la cuenta Cloudflare pueden haberse filtrado en la violación de datos de Kickstarter.

En 2014, los hackers pudieron acceder a algunas cuentas y robar nombres de usuarios de clientes, direcciones de correo electrónico, direcciones de correo, números de teléfono y contraseñas encriptadas.

Dado que las contraseñas tomadas fueron encriptadas, es posible que la contraseña de Cloudflare de Coinhive fuera particularmente débil y susceptible a un ataque de fuerza bruta.

La compañía, sin embargo, ha sido honesta en reconocer dónde radica la verdadera culpa.

“Hemos aprendido lecciones duras sobre seguridad y usamos 2FA y contraseñas únicas con todos los servicios desde entonces, pero olvidamos actualizar nuestra cuenta Cloudflare de años atrás”, dice Coinhive. “Sentimos mucho este severo descuido”.

Lamentable revés para una compañía que ofrecía una alternativa real a la monetización a través de la odiosa publicidad. Aunque este hacking no ha sido debido a la calidad de su código o una falla de la implementación o la idea, sino por el contrario a la laxa política de seguridad en el manejo de contraseñas de la empresa, esperemos que luego de este grave problema la empresa pueda sobrevivir y continuar con el desarrollo de su idea.

Google añadiría DNS over TLS para proteger a Android

Estándar

Una de las razones por las que los proveedores de servicios de Internet (ISP) o hackers pueden espiar tus comunicaciones si usas el protocol HTTPS, es por dos factores claves. El primero es la encriptación que oculta de forma irreversible el intercambio de información con el servidor web, y la segunda, es la autenticación del servidor web en sí mismo.

Pero, ¿acaso sabías? que los ISP pueden ver todas sus solicitudes a servidores DNS, lo que les permite saber qué sitios web visitas y además los hackers pueden implementar ataques de Man in the Middle a servidores DNS y dirigirte a sitios web fraudulentos.

Google está trabajando en una nueva característica de seguridad para su sistema operativo Android que podría evitar que el tráfico de Internet de los usuarios de su sistema operativo sea objeto de ataques de suplantación, redirección de tráfico o que simplemente sean espiados.

Casi todas las actividades de Internet comienzan con una consulta a un servidor DNS, lo que convierte a este protocolo en un componente fundamental de Internet. El DNS funciona como una guía telefónica de Internet, su misión es convertir las direcciones web legibles por el ser humano, como el nombre de dominio www.consejerodigital.com, en una dirección IP que es comprensible por la computadora.

Las consultas y respuestas a los servidores DNS se envían en texto plano (usando ya sea el protocolo UDP o TCP), lo que lo hace vulnerable a las escuchas ilegales y compromete la privacidad de los usuarios.

Los ISP resuelven por defecto las consultas DNS desde sus servidores. Entonces, cuando ingresas el nombre de un sitio web en tu navegador, la consulta va primero a sus servidores DNS para encontrar la dirección IP del sitio web, que finalmente expone esta información (metadatos) a tus ISP.

Aunque ya existen extensiones de seguridad para DNS, conocidas como DNSSEC, solo ofrecen integridad de datos, no privacidad.

Para tratar de resolver este problema, el Grupo de Trabajo de Ingeniería de Internet (IETF, por sus siglas en inglés) propuso el año pasado una característica experimental llamada DNS sobre TLS (RFC 7858), que funciona aproximadamente de la misma manera en que lo hace el protocolo HTTPS.

Al igual que el protocolo de encriptación Transport Layer Security (TLS) protege las conexiones HTTPS criptográficamente, DNS-over-TLS mejora dramáticamente la privacidad y la seguridad con búsquedas de DNS autenticadas de extremo a extremo.

Se ha informado en un post del blog XDAdevelopers, que Google agregará soporte “DNS over TLS” al Proyecto de Código Abierto de Android (AOSP), actualmente en una etapa experimental, para permitir a los usuarios de smartphones activar o desactivar la función “DNS over TLS” en la Configuración de Opciones de Desarrollador.

Es importante resaltar lo que agraga ese post al final como adendum referente a que no existe una formula mágica para proteger el tráfico del usuario:

Tenga en cuenta que TLS over DNS no dará lugar a la privacidad total con solo presionar un botón. Si un proveedor de servicios de DNS diferente al que decide conectarse opta por habilitar DNS over TLS, obtendrán su tráfico de DNS en lugar de su ISP. Las solicitudes de DNS se cifrarán, pero el servidor DNS sobre el protocolo TLS aún puede ver su tráfico de DNS, aunque eso solo podría ser un paso más arriba al usar los servidores de su ISP sin TLS over DNS. Al menos de esta manera, su ISP no podrá adjuntar sus consultas a la IP que le han asignado, y por lo tanto su nombre.

El handshake entre los servidores a través de la Indicación del nombre del servidor (SNI) que permite que se establezca una conexión aún puede ser visto por su ISP (y pueden registrarlo a su nombre). Para esconderte completamente, necesitarás una VPN para enrutar las consultas DNS, que de lo contrario tu ISP puede ver, a un servidor DNS over TLS. Mientras confíe en su proveedor de VPN, ahora debería estar más oculto que nunca en Android. Por lo tanto, aunque esta característica no le permite ser completamente anónimo en virtud de tener un DNS over TLS, sí le permite ocultar las solicitudes DNS de los ISP, y ocultar las solicitudes y el tráfico si está dispuesto a agregar algo extra de trabajo.

Aún no sabemos la fecha exacta de cuándo esta características estará disponible, pero es muy probable en que una próxima version Android 8.x la tengamos presente.

El departamento de Policía de NYC no tiene back-up de una importante base de datos

Estándar

En el portal de noticias tecnológicas ArsTechnica, da cuenta de que la base de datos del Sistema de Tracking de Propiedades y Evidencias no tiene copias respaldo (back-up) y que si ocurre un ataque informático, los datos se corrompen o por alguna razón las computadoras que lo contienen queda fuera de servicio la información se perdería.

Así nos presenta la noticia ArsTechnica:

Como parte de una batalla legal en curso para lograr que el Departamento de Policía de la Ciudad de Nueva York rastreara el dinero que la policía ha tomado en efectivo, un fiscal de la ciudad le dijo a un juez de Manhattan el 17 de octubre que parte de la razón por la que el NYPD no puede cumplir con tales solicitudes es que la base de datos de evidencias del departamento no tiene copia de seguridad. Si los servidores de dicha bases de datos que potencian el Sistema de Seguimiento de la Propiedad y Evidencias [PETS, por sus siglas en inglés] del NYPD, diseñados e instalados por Capgemini en virtud de un contrato de U.S.$ 25,5 millones entre el 2009 y 2012, fallarían, todos los datos sobre la evidencia almacenada, simplemente dejarían de existir.

Esto que parece digno de un país en vías de desarrollo está pasando actualmente con uno de los departamentos de policía con más presupuesto en el mundo, en una de las ciudades que ha abrazado con más entusiasmo la automatización de procesos y la modernización de toda la infraestructura pública.

Entonces, si la implementación del sistema costó $25,5 millones, por qué no hay un sistema de back-up, o uno que permita analizar o auditar los datos. Pues al parecer porque la consultora que lo creo, Capgemini, olvidó ese pequeño detalle según las autoridades:

Cuando se activó en 2012, Capgemini hizo alarde de PETS [Property and Evidence Tracking System], que se construyó utilizando la plataforma de software de planificación de recursos empresariales (ERP) de SAP, así como las bases de datos IBM DB2, como un proyecto del sector público emblemático. La compañía fue tan lejos que llegó a presentar PETS como un proyecto nominado para los premios Computerworld Honors 2012. Pero aparentemente el sistema fue diseñado sin ningún esquema para hacer una copia de seguridad de la base de datos o cualquier tipo de almacén de datos para realizar análisis de los mismos.

Fue esto hecho a propósito, pues al parecer si. Ya que el fiscal actualmente cuestiona el paradero de más de U.S. $68 millones confiscados por el Departamento de Policía de la Ciudad de Nueva York:

El reclamo fue clave para la negativa del departamento de policía a proporcionar la contabilidad de datos por aproximadamente U.S.$ 6 millones incautados en efectivo y propiedad cada año. Desde el año 2013, de acuerdo con el grupo sin fines de lucro Bronx Defenders, el NYPD tenía un balance de más de $ 68 millones en efectivo incautado.

Lo que me parece increíble siendo un residente de la Ciudad de New York, es que esto no haya trascendido a los medios de comunicación (televisión y periódicos) de la ciudad y sea por los medios especializados en tecnología que nos enteremos de esta grave negligencia que puede afectar negativamente las posibilidades de reelección del actual alcalde de la ciudad Bill De Blasio. Aunque técnicamente el sistema entró en funcionamiento en la gestión anterior, es increíble como se haya permitido que la situación continúe hasta el día de hoy.

Como diría el refrán “en todas partes se cuecen habas”.

Descubren chip especializado en procesamiento de imágenes en el Pixel 2

Estándar

En un reciente artículo publicado por ArsTechnica,  se informa que el nuevo smartphones de Google, el Pixel 2, incluye dentro del SoC una Unidead de Procesamiento de Imágenes, que debería ser activada cuándo el Android 8.1 sea liberado.

ArsTechnica dice lo siguiente:

El smartphone más nuevo de Google, el Pixel 2, está a punto de agotarse. La compañía ha estado hablando del gran juego que puede ofrecer la cámara de los Pixel 2 y llamándolo, de forma enfática, “la mejor cámara para smartphones”. Pero Google ha mantenido en secreto lo que oculata el Pixel 2 tiene un SoC (System On a Chip) personalizado diseñado por Google y dedicado exclusivamente al procesamiento de imágenes de la cámara. El SoC todavía no está activo, pero Google afirma que hará que las fotos que procese el Pixel 2 sean más rápidas y más eficientes que nunca.

Además del habitual Qualcomm Snapdragon 835 SoC, el Pixel 2 está equipado con el “Pixel Visual Core“, un segundo SoC extra que ha sido diseñado por Google con el procesamiento de imágenes acelerado por hardware en mente. En el corazón del chip hay una Unidad de procesamiento de imágenes (IPU Image Processesing Unit) de ocho núcleos capaz de más de tres billones de operaciones por segundo. Usando estos núcleos de IPU, Google dice que el procesamiento de imágenes HDR+ de la compañía puede ejecutarse “5 veces más rápido y a con menos de 1/10 de consumo de batería” que lo que actualmente hace la CPU principal.

Lo que sorprende a todos es que Google no haya mencionado el asunto para nada hasta ahora. Incluso cuándo tuvo la oportunidad durante la presentación de los Pixel el pasado 4 de octubre, no dijo ni una palabra sobre el tema. Sólo queda esperar a los reviews del portal web iFixIt, que abre todos los dispositivos y será alli dónde podremos confirmar si es que hay algo oculto en el nuevo Pixel 2.

KRACK, el nuevo ataque de reinstalación de clave crítica contra el protocolo WPA2 que deja vulnerables todos los routers Wi-Fi

Estándar

¿Crees que tu red inalámbrica es segura porque estás usando la última tecnología de cifrado WPA2?

Si es así, tenemos muy malas noticias para tí.

Los investigadores de seguridad han descubierto varias vulnerabilidades en la administración de claves en el núcleo del protocolo WPA2 (Wi-Fi Protected Access II) que podría permitir a un atacante piratear tu red Wi-Fi y escuchar todas las comunicaciones por Internet. En total son 10 la vulnerabilidades hechas públicas el día de hoy:

    • CVE-2017-13077, Reinstalación de la clave de encriptación pairwise (PTK-TK) en el handshake de cuatro vias.
    • CVE-2017-13078, Reinstalación de la llave de grupo (GTK) en el handshake de cuatro vias.
    • CVE-2017-13079, Reinstalación de la clave del grupo de integridad (IGTK) en el handshake de cuatro vias
    • CVE-2017-13080, Reinstalación de la clave de grupo (GTK) en el handshake de la clave del grupo
    • CVE-2017-13081, Reinstalación de la clave del grupo de integridad (IGTK) en el handshake de la clave del grupo
    • CVE-2017-13082, Aceptación de una solicitud de reasociación rápida de transición BSS (FT) retransmitida y reinstalación de la clave de cifrado por parejas (PTK-TK) mientras la procesa.
    • CVE-2017-13084, Reinstalación de la clave STK en el handshake PeerKey
    • CVE-2017-13086, Reinstalación de la clave de configuración de enlace directo Tunneled (TDLS) PeerKey (TPK) en el handshake TDLS
    • CVE-2017-13087, Reinstalación de la clave de grupo (GTK) mientras se procesa un marco de respuesta de modo de suspensión de gestión de red inalámbrica (WNM).
    • CVE-2017-13088, Reinstalación de la clave de grupo de integridad (IGTK) al procesar un marco de respuesta de modo de suspensión de gestión de red inalámbrica (WNM).

WPA2 es un esquema de autenticación WiFi que ya tiene 13 años y es ampliamente utilizado para garantizar conexiones Wi-Fi seguras, pero el estándar se ha visto comprometido, afectando a casi todos los dispositivos Wi-Fi, incluso en nuestros hogares y negocios, junto con las compañías de redes que los construyen.

Apodado KRACK (Key Reinstallation Attack), el ataque de prueba de concepto demostrado por un equipo de investigadores funciona en contra de todas las redes Wi-Fi modernas protegidas por WPA2 y puede ser abusado para robar información confidencial como números de tarjetas de crédito, contraseñas, mensajes de chat, correos electrónicos y fotos

Dado que las debilidades residen en el estándar Wi-Fi en sí, y no en las implementaciones o cualquier producto individual, es probable que se vea afectada cualquier implementación correcta de WPA2.

Según los investigadores, el ataque recién descubierto funciona en contra de:

  • Los protocolos WPA1 y WPA2,
  • Las redes personales y empresariales,
  • Encriptación WPA-TKIP, AES-CCMP y GCMP

En resumen, si su dispositivo admite Wi-Fi, lo más probable es que se vea afectado. Durante su investigación inicial, los investigadores descubrieron que Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys y otros, se ven afectados por los ataques KRACK.

Cabe señalar que el ataque KRACK no ayuda a los atacantes a obtener la contraseña de su red Wi-Fi; en su lugar, les permite desencriptar los datos de los usuarios WiFi sin desencriptar o conocer la contraseña real. Por lo tanto, simplemente cambiar la contraseña de su red Wi-Fi no impide (o atenúa) el ataque KRACK.

Aquí un video sobre cómo es que funciona el ataque:

 

 

Descubierto por la investigadora Mathy Vanhoef de la empresa belga de seguridad imec-DistriNet, KU Leuven, el ataque KRACK funciona explotando el handshake de 4 vías del protocolo WPA2 que se utiliza para establecer una clave para cifrar el tráfico entre el dispositivo y el access point.

Para un ataque KRACK exitoso, un atacante debe engañar a una víctima para que vuelva a instalar una clave ya en uso, lo que se logra manipulando y reproduciendo mensajes criptográficos de comunicación.

El documento que describe la vulnerabilidad, titulado Key Reinstallation Attacks: Forcing Nonce Reuse en WPA2, ha sido publicada por Mathy Vanhoef de KU Leuven y Frank Piessens de imec-DistriNet, Nitesh Saxena y Maliheh Shirvanian de la Universidad de Alabama en Birmingham, Yong Li de Huawei Technologies y Sven Schäge de Ruhr-Universität Bochum.

Los investigadores descubrieron las vulnerabilidades el año pasado, pero enviaron las notificaciones a varios vendedores el 14 de julio de este año, a la vez que notificaron al US-CERT (United States Computer Emergency Readiness Team), que envió una advertencia a cientos de proveedores el 28 de agosto.

Para solucionar estas vulnerabilidades, se debe esperar las actualizaciones de firmware de los fabricantes de routers y todo tipo de dispositivo que haga uso de WPA2.

Según los investigadores, la comunicación a través de HTTPS es segura, pero no al 100% y por lo tanto no podría descifrarse utilizando el ataque KRACK. Pero para estar más seguros, se recomienda utilizar un servicio VPN, que encripte todo el tráfico de Internet, ya sea este HTTPS o HTTP, esto obviamente reducirá su velocidad de conexión, pero le garantizará la privacidad mínima que se debe usar para operaciones comunes.

El equipo de investigadores prometió lanzar una herramienta mediante la cual puede verificar si su red WiFi es vulnerable al ataque KRACK o no.

Hasta el momento el único patch disponible es para el sistema operativo Linux en sus servicios hostapd (el daemon de punto de acceso del host) y WPA Supplicant.

Un nuevo ransomware no solo encripta tu Android sino que también cambia el PIN de bloqueo

Estándar

Los investigadores de seguridad de la empresa ESET, fabricante de software de seguridad con sede en Eslovaquia, descubrieron un nuevo ransomware de Android que no solo encripta los datos de los usuarios, sino que también no permite el acceso de los usuarios a sus dispositivos porque cambia el PIN de bloque de la pantalla. Esta nueva amenaza se llama DoubleLocker.

Además de lo anterior, DoubleLocker es el primer ransomware que hace un mal uso de las características de accesibilidad de Android, una característica que ofrece a los usuarios formas alternativas de interactuar con sus dispositivos móviles y que los troyanos bancarios de Android abusan principalmente de robar credenciales.

Los investigadores creen que el ransomware de DoubleLocker podría actualizarse en el futuro para robar credenciales bancarias, además de simplemente extorsionar dinero como rescate de los datos del smartphone.

Aquí un video creado por ESET dónde explica cómo opera este nuevo ransomware:

 

Una vez ejecutado, DoubleLocker primero cambia el PIN del dispositivo a un valor aleatorio que ninguno de los atacantes conoce ni almacena en ninguna parte y, mientras tanto, el malware encripta todos los archivos usando el algoritmo de encriptación AES.

DoubleLocker ransomware exige 0.0130 BTC (aproximadamente USD 74.38 al momento de la redacción) y presiona a las víctimas para pagar el rescate dentro de las siguientes 24 horas.

Si se paga el rescate, el atacante proporciona la clave de descifrado para desbloquear los archivos y restablece de forma remota el PIN para desbloquear el dispositivo de la víctima.

¿Cómo podemos protegernos de el ransomware DoubleLocker?

Según los investigadores de ESET, hasta ahora no hay manera de desbloquear archivos cifrados por DoubleLocker, sin embargo, para los dispositivos no rooteados, los usuarios pueden restablecer de fábrica su teléfono para desbloquear el teléfono y eliminar el ransomware de DoubleLocker.

Sin embargo, para los dispositivos Android rooteados con el modo de depuración habilitado, los usuarios afectados por DoubleLocker pueden usar la herramienta de desarrollo ADB (Android Debug Bridge) para restablecer el PIN sin necesidad de formatear su  smartphone.

Sin embargo, la mejor manera de protegerse de DoubleLocker y evitar caer víctimas de este tipo de ataques de ransomware es descargar siempre aplicaciones de fuentes confiables, como Google Play Store, Amazon Store, etc. y sólo instalar Apps de desarrolladores verificados.

Además, nunca haga click en los enlaces provistos en SMS o correos electrónicos. Incluso si el correo electrónico parece legítimo o ha sido enviado por un amigo. En lugar de hacer click en el enlace vaya directamente al sitio web de origen y verifique las posibles actualizaciones.

Lo más importante, mantenga una buena aplicación antivirus en su smartphone que pueda detectar y bloquear dichos ataques de malware antes de que pueda infectar su dispositivo. Siempre mantenga actualizado smartphone.

Nunca atribuyas a la maldad lo que puede ser explicado por la estupidez

Estándar

El título de este post es el famoso Principio de Hanlon, y creo que puede explicar muy bien el grave error que ha tenido el programa de correo electrónico Microsoft Outlook que por al menos 6 meses según se ha hecho público ha estado enviando correos encryptados a la vez que envia una copia del mismo en texto plano.

De acuerdo a la firma de consultoría de seguridad informática SEC Consult, desde al menos los últimos 6 meses, los mensajes de correo electrónico enviados en forma encriptada por Microsoft Outlook, también estaban siendo enviados con una copia no encriptada del mismo, exponiendo todas las comunicaciones secretas y sensibles de la empresa a posibles intrusos.

El protocolo S/MIME (Secure/Multipurpose Internet Mail Extensions), es un protocolo de encriptación de extremo a extremo basado en la criptografía de clave pública y que funciona igual que las conexiones SSL, lo que permite a los usuarios enviar mensajes cifrados y encriptados digitalmente.

De acuerdo con un aviso de seguridad publicado por SEC Consult a principios de esta semana, un error grave que ha recibido el código de error CVE-2017-11776, en el cliente de correo electrónico de Microsoft Outlook que hace que los mensajes de correo electrónico encriptados con el protocolo  S/MIME se envíen con sus versiones sin encriptar a la par de la versión encriptada.

Cuando los usuarios de Outlook utilizan S/MIME para cifrar sus mensajes y formatear sus correos electrónicos como texto sin formato, la vulnerabilidad permite que los correos electrónicos aparentemente cifrados se envíen en formularios de texto claro tanto como encriptados, lo cual los hace legibles para los humanos.

Los usuarios no eran conscientes de este problema de seguridad, ya que los mensajes aparecerían como cifrados en la carpeta “Enviados” de la aplicación de Outlook.

La activación de esta vulnerabilidad no requiere una participación activa de un atacante. Es más un atacante podría permanecer completamente pasivo. El impacto de esta vulnerabilidad es muy serio ya que un supuesto correo cifrado S/MIME destinado al envio de información confidencial se puede leer sin las claves privadas del destinatario. Esto resulta en pérdida total de la privacidad proporcionadas por el cifrado.

Los atacantes con acceso a las conexiones no cifradas de servidor a servidor o cliente a servidor podrían aprovechar fácilmente esta vulnerabilidad para leer las comunicaciones de correo electrónico en texto sin formato. Cómo se puede acceder a una comunicación de servidor a servidor o de un cliente a servidor, pues sencillamente escuchando todo el tráfico a través del puerto 25 que es el usado por el protocolo SMTP para envio de correos.

Por lo tanto, si utilizó el cifrado S/MIME de Outlook para correos electrónicos en los últimos 6 meses, sus correos electrónicos no se han cifrado en absoluto; en su lugar, salieron en texto plano.

Según los investigadores, el alcance de la vulnerabilidad depende de cómo se haya configurado Outlook.

En el caso de un Outlook con Exchange en la misma network.

Si está utilizando Outlook con Exchange, la versión de texto sin formato de los correos electrónicos cifrados sólo alcanzará un salto, ya que el envío de correos electrónicos al servidor de correos externo eliminará la parte de texto plano del mensaje.

Pero si el destinatario y el remitente están en el mismo dominio (servidor), la parte de texto plano también se enviará al destinatario. Pero en este caso cómo todo ocurre dentro de la misma empresa, el impacto debería ser limitado.

Si, existe una computadora infectada dentro de la red local de la empresa que colecta información, entonces habría un problema.

Outlook usando SMTP con un servidor externo.

Si está ejecutando Outlook con SMTP, la versión de texto sin formato de los correos electrónicos cifrados no sólo será recibida por el destinatario sino también por todos los servidores de correo a lo largo de la ruta que conectan el servidor de origen con el servidor de destino.

Este es el peor escenario posible de todos. Ya que técnicamente hay millones de correos electrónicos “cifrados” con una copia en texto plano distribuidos alrededor de un número no conocido de servidores SMTP alrededor del mundo.

Los investigadores de la SEC Consult descubrieron el problema en mayo y lo informaron responsablemente a Microsoft, pero no recibieron noticias del gigante de la tecnología. Lo cuál es desconcertante, ya que este es un grave error que compromete la seguridad mayormente de la base de usuarios más importante de Microsoft, los usuarios corporativos.

Microsoft lanzó un parche para corregir el error en el lanzamiento de actualizaciones de seguridad de este mes y calificó el problema como “importante”, alegando que la explotación de esta vulnerabilidad era “improbable” en estado salvaje. Lo cuál realmente nos indica lo desconectados que están de la realidad los ingenieros de Microsoft.

Por lo tanto, si Ud. utilizo el S/MIME de Outlook para encriptar sus correos electrónicos sensibles, se recomienda que actualize el sistema lo antes posible.

Creo que ahora ya pueden comprender porque a este post lo titulé con el famoso Principio de Halon.

ATMii el malware que hace escupir dinero a los cajeros automáticos

Estándar

Kaspersky Lab ha descubierto y hecho público a través de un post en su blog un malware llamado ATMii que hace realidad la peor pesadilla de un banco, hace escupir dinero a los cajeros automáticos.

Este malware se compone de dos partes: un módulo inyector que se dirige al software del cajero automico (ATM por sus siglas en inglés) y al módulo a inyectar. El código incorrecto utiliza una bibliotecas propietarias legítimas; los ciberdelincuentes pueden acceder al ATM objetivo a través de la red o físicamente a través de puertos USB disponibles en muchos ATM en nuestros días, para cargar los archivos maliciosos en los sistemas.

Travis Smith, principal investigador de seguridad de Tripwire, también señaló que el malware ATMii está muy orientado a un objetivo específico, no sólo por el hecho de que esté sólo ataca a los cajeros automáticos que tienen Windows 7 como su sistema operativo, sino también porque está dirigido a un ejecutable ATM específico (atmapp.exe), que es específico de ciertos modelos de cajeros y que al parecer fue desarrollado sin mucho cuidado.

Según lo publicado por Travis Smith:

Según el informe inicial de Kaspersky, se trata de una aplicación propietaria, por lo que es improbable que esta variante de malware tenga un gran impacto en el mercado de cajeros automáticos en todo el mundo. Incluso con un impacto mínimo, es muy fácil prevenir la ruta de infección del malware mediante la implementación de controles de base. Limitar el acceso a la red y la desactivación de los puertos USB reducirá la superficie de ataque lo suficiente como para que este tipo simple de malware no llegue a un cajero automático.

Kaspersky Lab dijo también en su blog que ATMii es otro ejemplo de cómo los cibercriminales pueden usar un pequeño pedazo de código para enriquecerse a sí mismos. Una muestra del malware ATMii fue proporcionada a Kaspersky Lab por un socio de la industria financiera en abril de este año; comparte algunas similitudes con la última versión de otro malware orientado a cajeros automáticos llamado Skimer, malware que fue reportado por Kaspersky Lab el año pasado.

Durante nuestros recientes casos de Respuesta a Incidentes relacionados con el abuso de cajeros automáticos, hemos identificado Tyupkin, Carbanak y los ataques de la caja negra“, dijo Kaspersky Lab. “La evolución de Backdoor.Win32.Skimer demuestra el interés del atacante en estas familias de programas maliciosos, ya que los cajeros automáticos son un mecanismo muy efectivo para los criminales. Kaspersky Lab ha identificado 49 modificaciones de este malware, con 37 de estas modificaciones dirigidas a los cajeros automáticos ensamblados por un solo fabricante “.

Para protegerse contra tales ataques, Kaspersky Lab recomienda a los operadores de cajeros automáticos incorporar políticas de denegación predeterminada y control de dispositivos, así como medidas técnicas para proteger el cajero automático contra el acceso físico.

Grave vulnerabilidad de iOS revela el password del Apple ID

Estándar

El empresario de herramientas de desarrollo Open Source Felix Krause, ha hecho público en su blog personal bajo el título “Privacidad de iOS: robar.password – Obtenga fácilmente la contraseña de una cuenta Apple ID, simplemente preguntando“, una grave vulnerabilidad que permite acceder al password de una cuenta Apple ID usando técnicas de phishing.

El mecanismo descrito para obtener el password sería el siguiente:

iOS le pide al usuario su contraseña de iTunes por muchas razones, las más comunes son las actualizaciones del sistema operativo iOS recientemente instaladas o las aplicaciones iOS que están bloqueadas durante la instalación.

Como resultado, los usuarios están entrenados para ingresar su contraseña de ID de Apple siempre que iOS se los solicite que lo haga. Sin embargo, esas ventanas emergentes no sólo se muestran en la pantalla de bloqueo y en la pantalla de inicio, sino también en aplicaciones aleatorias, por ejemplo cuando se quiere acceder a iCloud, GameCenter o a compras dentro de un App.

Esto podría ser abusado fácilmente por cualquier aplicación, sólo por mostrar un UIAlertController, que se ve exactamente como el diálogo del sistema.

Incluso los usuarios que saben mucho sobre tecnología tienen dificultades para detectar que esas alertas son ataques de phishing.

Aquí una gráfica que comprara ambos tipos de pop-up, el oficial y uno creado programáticamente para robar el password:

Cómo es posible protegerte contra una aplicación diseñada para robar tu password, pues Felix Krause nos recomienda lo siguiente:

  • Pulse el botón de inicio, y ver si la aplicación se cierra:
    • Si la aplicación se cierra y con ella el diálogo, entonces esto fue un ataque de phishing
    • Si el diálogo y la aplicación siguen visibles, entonces es un diálogo del sistema. La razón de ello es que los diálogos del sistema se ejecutan en un proceso diferente y no como parte de ninguna aplicación de iOS.
  • No introduzca sus credenciales en una ventana emergente, en su lugar,  desechela y abra la aplicación Settings manualmente. Este es el mismo concepto, como el de que usted nunca debe hacer clic en los enlaces en los correos electrónicos, pero en su lugar abrir el sitio web manualmente
  • Si pulsa el botón Cancelar en un cuadro de diálogo, la aplicación seguirá accediendo al contenido del campo de contraseña. Incluso después de introducir los primeros caracteres, la aplicación probablemente ya tiene su contraseña.

El investigadir Krause ha reportado el bug a Apple y esperemos que pronto esto quede solucionado para el bien de los usuarios de esta plataforma. Pero es increíble cómo en un periodo tan corto de tiempo el hasta no hace mucho considerado “sistema más seguro”, está haciendo agua por todos lados.