¿No hay reproductor de audio debajo? Escuchar directamente en Soundcloud.

DOUG.  Parches a mano, dos días cero de Microsoft y "Cuidado con ese archivo, Eugene".

Todo eso, y más, en el podcast de Naked Security.

[MÓDEM MUSICAL]

Bienvenidos al podcast, todos.

Soy Doug Aamoth; él es Paul Ducklin.

Pablo, ¿cómo estás hoy?

PATO.  ¿Hacías alusión a El rosa floyd?

DOUG.  *EL* Pink Floydsi!

PATO.  Creo que ese es el nombre con el que se les conocía originalmente.

DOUG.  ¿Oh enserio?

PATO.  Dejaron caer el "The" porque creo que se interpuso en el camino.

El Pink Floyd.

DOUG.  ¡Eso es un hecho divertido!

Y por suerte, tengo más Hechos graciosos para ti…

Sabes que comenzamos el show con Esta semana en la historia de la tecnología, y tenemos un dos-fer hoy.

Esta semana, el 17 de julio de 2002, Apple lanzó “iCal”: un software de calendario que presentaba el intercambio de calendarios basado en Internet y la capacidad de administrar múltiples calendarios.

El “17 DE JULIO” se destacó de manera destacada en el ícono de la aplicación, lo que incluso llevó al 17 de julio a convertirse en el Día Mundial del Emoji, establecido en 2014.

¡Es un efecto en cascada, Paul!

PATO.  A pesar de. en su iPhone, notará que el ícono cambia a la fecha de hoy, porque eso es muy útil.

Y notará que otros proveedores de servicios pueden o no haber elegido fechas diferentes, porque "por qué copiar a su competencia", de hecho.

DOUG.  Muy bien, entremos en ello.

Hablaremos de nuestra primera historia.

Se trata de Zimbra y aventuras en secuencias de comandos entre sitios.

Buen viejo XSS, Paul:

Advertencia de Zimbra Collaboration Suite: ¡Parche este día 0 ahora mismo (a mano)!

PATO.  Sí.

Ahí es donde esencialmente puede piratear un sitio web para incluir JavaScript falso sin entrar en el servidor.

Realiza alguna acción, o crea algún enlace a ese sitio, que engaña al sitio para que incluya contenido en su respuesta que no solo menciona, por ejemplo, el término de búsqueda que escribió, como My Search Term, pero incluye texto adicional que no debería estar allí, como My search <script> rogue JavaScript </script>.

En otras palabras, engaña a un sitio para que muestre contenido, con su propia URL en la barra de direcciones, que contiene JavaScript que no es de confianza.

Y eso significa que el JavaScript que inyectó a escondidas en realidad tiene acceso a todas las cookies establecidas por ese sitio.

Para que pueda robarlos; puede robar datos personales; y, lo que es más importante, probablemente pueda robar tokens de autenticación y cosas por el estilo para permitir que los ladrones vuelvan a entrar la próxima vez.

DOUG.  Bien, entonces, ¿qué hizo Zimbra en este caso?

PATO.  Bueno, la buena noticia es que reaccionaron rápido porque, por supuesto, fue un día cero.

Los ladrones ya lo estaban usando.

Así que en realidad adoptaron el enfoque ligeramente inusual de decir: “Tenemos el parche en camino. Lo obtendrás bastante pronto.

Pero ellos dijeron, bastante pensativos, "Entendemos que es posible que desee tomar medidas más temprano que tarde".

Ahora, desafortunadamente, eso significa escribir un script propio para parchear una línea de código en un archivo en la distribución del producto en todos los nodos de su buzón.

Pero es una solución muy pequeña y simple.

Y, por supuesto, debido a que es una línea, puede cambiar fácilmente el archivo a lo que era si causa problemas.

Si tenía muchas ganas de adelantarse a los ladrones, podría hacerlo sin esperar a que cayera el lanzamiento completo...

DOUG.  ¡Y qué sentido de logro también!

Ha pasado un tiempo desde que pudimos arremangarnos y parchear a mano algo como esto.

Es como arreglar el fregadero un sábado por la mañana… simplemente te sientes bien después.

Entonces, si fuera un usuario de Zimbra, estaría saltando por todo esto solo porque me gusta tener en mis manos... [RISAS]

PATO.  Y, a diferencia de reparar el fregadero, no había que gatear en armarios estrechos y no había riesgo de inundar toda su propiedad.

La solución fue clara y bien definida.

Una línea de código cambió en un archivo.

DOUG.  Muy bien, si soy un programador, ¿cuáles son algunos pasos que puedo seguir para evitar secuencias de comandos entre sitios como este?

PATO.  Bueno, lo bueno de este error, Doug, es que casi actúa como documentación para el tipo de cosas que debe tener en cuenta en las secuencias de comandos entre sitios.

El parche muestra que hay un componente del lado del servidor que simplemente tomaba una cadena y la usaba dentro de un formulario web que aparecería en el otro extremo, en el navegador del usuario.

Y puede ver que lo que hace el programa *ahora* (este software en particular está escrito en Java)... llama a una función escapeXML(), que es, si lo desea, la forma única de tomar una cadena de texto que desea mostrar y asegurarse de que no haya caracteres XML o HTML mágicos que puedan engañar al navegador.

En particular: menos de (<); mas grande que (>); signo comercial (&); comillas dobles ("); o comillas simples, también conocidas como apóstrofe (').

Esos se convierten en sus códigos HTML seguros y de formato largo.

Si puedo usar nuestro cliché estándar de Naked Security, Doug: Desinfecta tus insumos es el resultado final aquí.

DOUG.  Oooh, me encanta ese!

Excelente. Movámonos a Pink Floyd, obviamente... hemos estado esperando todo este show.

Si Pink Floyd fueran investigadores de ciberseguridad, es divertido imaginar que podrían haber escrito una canción de éxito llamada “Cuidado con ese archivo, Eugene.en cambio, Pablo. [Pink Floyd produjo una famosa canción llamada Cuidado con esa hacha Eugenio.]

Google Virus Total filtra la lista de direcciones de correo electrónico espeluznantes

PATO.  Ciertamente.

"Cuidado con ese archivo" es un recordatorio de que, a veces, cuando carga un archivo en un servicio en línea, si elige uno incorrecto, puede terminar redistribuyendo el archivo en lugar de, por ejemplo, cargarlo para un almacenamiento seguro.

Afortunadamente, no se hizo mucho daño en este caso, pero esto fue algo que sucedió en el servicio Virus Total de Google.

Los oyentes probablemente sabrán que Virus Total es un servicio muy popular en el que, si tiene un archivo que sabe que es malware y quiere saber cómo lo llaman muchos productos diferentes (para saber qué buscar en sus registros de amenazas), o si piensa: "Tal vez quiero llevar la muestra de forma segura a tantos proveedores como sea posible, lo más rápido posible"...

…entonces subes a Virus Total.

El archivo está destinado a estar disponible para docenas de empresas de ciberseguridad casi de inmediato.

Eso no es lo mismo que transmitirlo al mundo o cargarlo en un depósito de almacenamiento en la nube en línea con fugas, pero el servicio *está* destinado a compartir ese archivo con otras personas.

Y desafortunadamente, parece que un empleado dentro de Virus Total subió accidentalmente un archivo interno que era una lista de direcciones de correo electrónico de clientes al portal de Virus Total, y no al portal que se suponía que debían usar.

Ahora, la verdadera razón para escribir esta historia, Doug, es esta.

Antes de reír; antes de señalar con el dedo; antes de decir: "¿En qué estaban pensando?"...

..deténgase y hágase esta pregunta.

“¿Alguna vez he enviado un correo electrónico a la persona equivocada por error?” [LA RISA]

Esa es una pregunta retórica. [MÁS RISAS]

Todos lo hemos hecho…

DOUG.  ¡Es retórico!

PATO.  …algunos de nosotros más de una vez. [RISA]

Y si alguna vez ha hecho eso, ¿qué es lo que garantiza que no cargará un archivo en el *servidor* incorrecto por error, cometiendo un tipo de error similar?

Es un recordatorio de que hay muchos deslices, Douglas, entre la copa y el labio.

DOUG.  Muy bien, aquí tenemos algunos consejos para las buenas personas, comenzando con, diría, uno de nuestros consejos más impopulares: Cierra la sesión de las cuentas en línea siempre que no las estés usando.

PATO.  Sí.

Ahora, irónicamente, eso podría no haber ayudado en este caso porque, como puede imaginar, Virus Total está diseñado específicamente para que cualquiera pueda *cargar* archivos (porque están destinados a ser compartidos por el bien de todos, rápidamente, con las personas que necesitan verlos), pero solo los clientes confiables pueden *descargar* cosas (porque se supone que las cargas a menudo contienen malware, por lo que no están destinadas a estar disponibles para cualquiera).

Pero cuando piensa en la cantidad de sitios en los que probablemente permanece conectado todo el tiempo, eso solo hace que sea más probable que tome el archivo correcto y lo cargue en el lugar equivocado.

Si no ha iniciado sesión en un sitio e intenta cargar un archivo allí por error, recibirá un aviso de inicio de sesión...

…¡y te protegerás de ti mismo!

Es una solución fantásticamente simple, pero como usted dice, también es escandalosamente impopular porque es modestamente inconveniente. [RISA]

DOUG.  ¡Sí!

PATO.  A veces, sin embargo, tienes que tomar uno para el equipo.

DOUG.  No transferir toda la responsabilidad a los usuarios finales: Si está en el equipo de TI, considere poner controles sobre qué usuarios pueden enviar qué tipo de archivos a quién.

PATO.  Desafortunadamente, este tipo de bloqueo es impopular, si te gusta la razón del otro lado de la moneda de por qué a las personas no les gusta cerrar sesión en las cuentas cuando no las están usando.

Cuando aparece TI y dice: "Sabes qué, vamos a activar las partes de prevención de pérdida de datos [DLP] de nuestro producto de punto final de seguridad cibernética"...

…la gente dice: “Bueno, eso es un inconveniente. ¿Qué pasa si se interpone en el camino? ¿Qué pasa si interfiere con mi flujo de trabajo? ¿Qué pasa si me causa molestias? ¡No me gusta!

Entonces, un montón de II
Los departamentos T pueden terminar siendo un poco tímidos para interferir potencialmente con el flujo de trabajo como ese.

Pero, Doug, como dije en el artículo, siempre tendrás una segunda oportunidad de enviar un archivo que no se enviaría la primera vez, negociando con TI, pero nunca tendrás la oportunidad de cancelar el envío de un archivo que se suponía que no se enviaría en absoluto.

DOUG.  [RISAS] ¡Exacto!

Muy bien, buenos consejos allí.

Nuestro ultima historia, pero ciertamente no menos importante.

Paul, no tengo que recordártelo, pero deberíamos recordárselo a los demás...

…la criptografía aplicada es difícil, la segmentación de seguridad es difícil y la búsqueda de amenazas es difícil.

Entonces, ¿qué tiene que ver todo eso con Microsoft?

Microsoft golpeado por la temporada de tormentas: una historia de dos días semicero

PATO.  Bueno, recientemente ha habido muchas noticias en los medios acerca de que Microsoft y sus clientes fueron entregados, golpeados, investigados y pirateados por un grupo de ciberdelincuencia conocido como Storm.

Y una parte de esta historia gira en torno a 25 organizaciones que tenían a estos delincuentes dentro de su negocio de Exchange.

Son una especie de día cero.

Ahora, Microsoft publicó un informe bastante completo y bastante franco sobre lo que sucedió, porque obviamente hubo al menos dos errores por parte de Microsoft.

La forma en que cuentan la historia puede enseñarle mucho sobre la caza de amenazas y sobre la respuesta a las amenazas cuando las cosas salen mal.

DOUG.  Bien, parece que Storm ingresó a través de Outlook Web Access [OWA] usando un montón de tokens de autenticación usurpados, que es básicamente como una cookie temporal que presentas que dice: "Esta persona ya inició sesión, es legítima, déjala entrar".

¿Derecha?

PATO.  Exacto, Doug.

Cuando sucede ese tipo de cosas, lo que obviamente es preocupante porque permite a los delincuentes eludir la fase de autenticación fuerte (la parte en la que tiene que escribir su nombre de usuario, escribir su contraseña, luego hacer un código 2FA, o donde tiene que presentar su Yubikey, o tiene que pasar su tarjeta inteligente)...

…la suposición obvia, cuando sucede algo así, es que la persona en el otro extremo tiene malware en una o más de las computadoras de sus usuarios.

El malware tiene la oportunidad de echar un vistazo a cosas como el contenido del navegador antes de que se cifre, lo que significa que puede extraer tokens de autenticación y enviarlos a los delincuentes donde pueden abusar de ellos más tarde.

Microsoft admite en su informe que esta fue su primera suposición.

Y si es cierto, es problemático porque significa que Microsoft y esas 25 personas tienen que andar corriendo tratando de cazar amenazas.

Pero si esa *no* es la explicación, entonces es importante averiguarlo desde el principio, para no perder el tiempo ni el de los demás.

Luego, Microsoft se dio cuenta: "En realidad, parece que los delincuentes básicamente están acuñando sus propios tokens de autenticación, lo que sugiere que deben haber robado una de nuestras claves de firma de tokens de Azure Active Directory supuestamente seguras".

Bueno, ¡eso es preocupante!

*Entonces* Microsoft se dio cuenta de que "estos tokens aparentemente están firmados digitalmente por una clave de firma que se supone que solo debe usarse para cuentas de consumidores, lo que se llama MSA o cuentas de Microsoft".

En otras palabras, el tipo de clave de firma que se usaría para crear un token de autenticación, por ejemplo, si usted o yo estuviéramos iniciando sesión en nuestro servicio Outlook.com personal.

¡Oh no!

Hay otro error que significa que es posible tomar un token de autenticación firmado que se supone que no funciona para el ataque que tienen en mente, y luego entrar y jugar con el correo electrónico corporativo de las personas.

Entonces, todo eso suena muy mal, que por supuesto lo es.

Pero hay una ventaja...

…y esa es la ironía de que debido a que se suponía que esto no funcionaría, porque se supone que los tokens de MSA no funcionan en el lado corporativo de Azure Active Directory de la casa, y viceversa, nadie en Microsoft se había molestado en escribir código para usar un token en el otro campo de juego.

Lo que significaba que todas estas fichas rebeldes se destacaban.

Así que había al menos una bandera roja gigante y visible para la caza de amenazas de Microsoft.

Afortunadamente, solucionar el problema, porque es un problema del lado de la nube, significa que usted y yo no necesitamos apresurarnos y parchear nuestros sistemas.

Básicamente, la solución es: rechazar la clave de firma que se ha visto comprometida, para que ya no funcione, y mientras estamos en eso, solucionemos ese error que permite que una clave de firma de consumidor sea válida en el lado corporativo del mundo de Exchange.

Es una especie de "Bien está lo que bien acaba".

Pero como dije, es un gran recordatorio de que la caza de amenazas a menudo implica mucho más trabajo de lo que podría pensar al principio.

Y si lee el informe de Microsoft, puede imaginar cuánto trabajo se dedicó a esto.

DOUG.  Bueno, con el espíritu de atrapar todo, escuchemos a uno de nuestros lectores en el Comentario de la semana.

Puedo decírtelo de primera mano después de hacer esto durante la mayor parte de diez años, y estoy seguro de que Paul puede decírtelo de primera mano después de hacer esto en miles y miles de artículos...

…los errores tipográficos son una forma de vida para un blogger de tecnología y, si tiene suerte, a veces termina con un error tipográfico tan bueno que no se atreve a corregirlo.

Tal es el caso de este artículo de Microsoft.

El lector Dave cita a Paul escribiendo “lo que parecía sugerir que alguien había pellizcado a una compañía que cantaba [sic] key”.

Luego, Dave continúa la cita diciendo: "Singing keys rock".

¡Exactamente! [RISA]

PATO.  Sí, me tomó un tiempo darme cuenta de que es un juego de palabras... pero sí, "clave de canto". [RISAS]

¿Qué obtienes si arrojas una caja de saxofones en un campamento militar?

DOUG.  [RISAS]

PATO.  [TAN SECO COMO SEA POSIBLE] La bemol mayor.

DOUG.  [RISA Y GEMIDO COMBINADOS] Muy bien, muy bien.

Dave, gracias por señalarlo.

Y estamos de acuerdo en que las teclas cantadas rockean; firmar claves menos.

Si tiene una historia interesante, un comentario o una pregunta que le gustaría enviar, nos encantaría leerlo en el podcast.

Puede enviar un correo electrónico a tips@sophos.com, puede comentar cualquiera de nuestros artículos o puede contactarnos en las redes sociales: @nakedsecurity.

Ese es nuestro programa de hoy; muchas gracias por escuchar

Para Paul Ducklin, soy Doug Aamoth, les recuerdo, hasta la próxima, que...

AMBAS COSAS.  ¡Mantente seguro!

[MÓDEM MUSICAL]