Puede que en tu empresa el problema sea que casi nadie lo esté mirando, pero la web está siendo atacada constantemente. Este fenómeno suele pasar desapercibido para la mayoría de organizaciones. En los últimos años, las noticias más visibles en el ámbito de la ciberseguridad han estado centradas en incidentes de gran impacto, como ataques de ransomware, filtraciones de datos personales o campañas avanzadas de amenazas persistentes (APT).

etiquetas: cloud web application, firewall, apt, ddos, internet, cdn, dns

» noticia original (www.elladodelmal.com)

Recientemente se ha dado a conocer una vulnerabilidad crítica de escalada de privilegios locales (LPE) que afecta a Microsoft Windows, tras la publicación pública de un exploit de prueba de concepto (PoC). Identificada como CVE-2026-20817, esta falla de seguridad reside en el servicio de Windows Error Reporting (WER). La vulnerabilidad permite a un usuario autenticado con privilegios bajos ejecutar código malicioso arbitrario con permisos de SYSTEM.

etiquetas: microsoft, vulnerabilidad, alpc, lpe, poc, exploit, wer

» noticia original (blog.elhacker.net)

Una vulnerabilidad recientemente confirmada en el demonio telnet (telnetd) de GNU Inetutils ha revivido un fallo de seguridad de 27 años, permitiendo a los atacantes obtener acceso root al explotar una sanitización incorrecta de variables de entorno, sin necesidad de autenticación. Registrada como CVE-2026-24061, la falla existe en GNU Inetutils hasta la versión 2.7 e permite eludir la autenticación remota.

etiquetas: telnet, gnu inetutils, root, vulnerabilidad, autenticación

» noticia original (blog.elhacker.net)

Uno de los sistemas clave para la seguridad de los trenes en España es el ASFA (Anuncio de Señales y Frenado Automático), un sistema que ha evolucionado a lo largo de los años, pero que aún sigue siendo un pilar fundamental en la red ferroviaria. Por ello, desde ESET, compañía líder en ciberseguridad, indican que es crucial no solo comprender el valor de sistemas como ASFA, sino también abordar los desafíos de seguridad que pueden surgir en su operación.

etiquetas: vulnerabilidad, asfa, eset, def con 2024

» noticia original (blog.elhacker.net)

Maxime BEASSE y Quentin CLEMENT, en colaboración con FrenchKey y CNS, han publicado KeyDecode, una aplicación móvil que nos demuestra qué fácil puede llegar a duplicarse una llave con tan sólo hacerle un foto. Básicamente lo que hace es medir con precisión lo que se denomina cifrado, es decir, la combinación de alturas del diente que procede verticalmente en la pluma. El resultado es un conjunto de medidas que puede permitir a un cerrajero duplicar la llave original.

etiquetas: keydecoder, app, hacking, llave, duplicar, cerrajero

» noticia original (www.hackplayers.com)

Varias agencias nacionales de ciberseguridad publicaron alertas sobre el tema, y los expertos avisaban de lo fácil que era exponer especialmente a grandes empresas que usan esa librería de forma habitual. La propia Apache Software Foundation calificó la vulnerabilidad — corregida en Log4j 2.15.0 — con un índice de peligrosidad de 10 sobre 10. | Relacionada: menea.me/251c8

etiquetas: peligrosidad de 10 sobre 10, apache, log4shell, internet

» noticia original (www.xataka.com)

Un amigo me preguntó cómo podía saber si alguien espiaba sus comunicaciones. Recordé haber visto en la serie Mr. Robot, que una posible forma es colocar un cebo.

Se me ocurrió que podía poner a disposición de todo el mundo la herramienta que hice. Pero antes de pulirla para que la pueda usar cualquiera, pensé que sería buena idea preguntar antes por aquí. No soy ningún experto en seguridad, pero creo que la herramienta funciona. Si no le veis ningún fallo, me gustaría hacerla pública de forma gratuita.

En concreto se me ocurrió lo siguiente:

1. La herramienta crea en un servidor web un archivo en php llamado index.php.
2. Este archivo es llamado a través de una URL de un solo uso creada para el usuario. Por ejemplo: www.servidor-ficticio.com/BAKFLNEGSLN-KD_ODISOOS-KE/index.php
3. El usuario inserta este enlace en sus mails y apps de mensajería, y los envía a un amigo al que previamente y en persona le ha dicho que no haga click en este enlace.
4. Solo el usuario y el amigo conocen la URL y han acordado no acceder a ella, así que si se contabiliza algún acceso a la página, es que las comunicaciones están siendo espiadas.
5. El usuario puede consultar en otra URL de un solo uso, el número de visitas a la URL del archivo cebo. En el momento que no sea 0, sabrá que le espían.
6. El contenido que vea el espía no es relevante. Puede ser una página de error, una página en blanco, una página con contenido o redirigir a otro lugar. Lo importante es que en el momento que acceda a la URL, la visita queda registrada.

¿Le veis algún fallo al sistema?

Gracias.

etiquetas: artículo

» noticia original ()

En 2011, los espías chinos robaron las joyas de la corona de la ciberseguridad, eliminando las protecciones de empresas y organismos gubernamentales de todo el mundo. Así es como sucedió.

Entre todas las horas de insomnio que Todd Leetham pasó cazando fantasmas dentro de la red de su empresa a principios de 2011, la experiencia que más se le queda grabada todos estos años es el momento en que los alcanzó. O casi lo hizo.

Fue una tarde de primavera, dice, tres días -quizás cuatro, el tiempo se había vuelto borroso- después de que empezara a seguir a los hackers que estaban hurgando en los sistemas informáticos de RSA, el gigante de la seguridad corporativa donde trabajaba. Leetham -un analista calvo, barbudo y cascarrabias al que un compañero de trabajo describió como una "máquina de encontrar hackers basada en el carbono"- había estado pegado a su ordenador portátil junto con el resto del equipo de respuesta a incidentes de la empresa, reunido en torno al centro de operaciones de la compañía, que se encontraba en un lugar acristalado, en una cacería ininterrumpida las 24 horas del día. Y con una creciente sensación de temor, Leetham finalmente había rastreado las huellas de los intrusos hasta sus objetivos finales: las claves secretas conocidas como "semillas", una colección de números que representaban una capa fundamental de las promesas de seguridad que RSA hacía a sus clientes, incluyendo decenas de millones de usuarios en agencias gubernamentales y militares, contratistas de defensa, bancos e innumerables corporaciones de todo el mundo.

RSA guardaba esas semillas en un único servidor bien protegido, al que la empresa llamaba "almacén de semillas". Servían como un ingrediente crucial en uno de los productos principales de RSA: Los tokens SecurID, unos pequeños llaveros que se llevan en el bolsillo y se sacan para demostrar la identidad introduciendo los códigos de seis dígitos que se actualizan constantemente en la pantalla del llavero. Si alguien pudiera robar los valores semilla almacenados en ese depósito, podría clonar esos tokens SecurID y romper silenciosamente la autenticación de dos factores que ofrecían, permitiendo a los hackers saltarse instantáneamente ese sistema de seguridad en cualquier parte del mundo, accediendo a cualquier cosa, desde cuentas bancarias hasta secretos de seguridad nacional.

Ahora, mirando los registros de la red en su pantalla, a Leetham le parecía que esas llaves del reino global de RSA ya habían sido robadas.

Leetham vio con consternación que los hackers habían pasado nueve horas desviando metódicamente las semillas del servidor del almacén y enviándolas a través del protocolo de transferencia de archivos a un servidor hackeado alojado en Rackspace, un proveedor de alojamiento en la nube. Pero entonces descubrió algo que le dio un destello de esperanza: Los registros incluían el nombre de usuario y la contraseña robados de ese servidor hackeado. Los ladrones habían dejado su escondite al descubierto, a la vista de todos. Leetham se conectó a la lejana máquina de Rackspace y tecleó las credenciales robadas. Y ahí estaba: El directorio del servidor aún contenía toda la colección de semillas robadas como un archivo .rar comprimido.

Utilizar las credenciales pirateadas para entrar en un servidor que pertenece a otra empresa y manipular los datos almacenados en él es, según admite Leetham, un movimiento poco ortodoxo en el mejor de los casos, y una violación de las leyes de piratería informática de Estados Unidos en el peor. Pero al ver los datos más sagrados de RSA robados en ese servidor de Rackspace, no dudó. "Iba a aguantar el tirón", dice. "De cualquier manera, estoy salvando nuestra mierda". Tecleó el comando para borrar el archivo y pulsó enter.

Momentos más tarde, la línea de comandos de su ordenador volvió con una respuesta: "Archivo no encontrado". Volvió a examinar el contenido del servidor de Rackspace. Estaba vacío. El corazón de Leetham se desplomó: Los hackers habían sacado la base de datos de semillas del servidor segundos antes de que él pudiera borrarla.

Después de perseguir a estos ladrones de datos día y noche, les había "dado un golpe en la chaqueta cuando salían corriendo por la puerta", como dice hoy. Se le habían escapado de las manos, y se habían ido al éter con la información más preciada de su empresa. Y aunque Leetham aún no lo sabía, esos secretos estaban ahora en manos del ejército chino.

La brecha de seguridad de RSA, cuando se hizo pública días después, redefiniría el panorama de la ciberseguridad. La pesadilla de la compañía fue una llamada de atención no sólo para la industria de la seguridad de la información -el peor hackeo de una empresa de ciberseguridad hasta la fecha-, sino también una advertencia para el resto del mundo. Timo Hirvonen, investigador de la empresa de seguridad F-Secure, que publicó un análisis externo de la brecha, lo consideró una demostración inquietante de la creciente amenaza que supone una nueva clase de hackers patrocinados por el Estado. "Si una empresa de seguridad como RSA no puede protegerse a sí misma", recuerda Hirvonen que pensó entonces, "¿cómo puede hacerlo el resto del mundo?".

La pregunta era bastante literal. El robo de los valores de las semillas de la compañía significaba que se había eliminado una salvaguarda crítica de las redes de miles de sus clientes. Los tokens SecurID de RSA se diseñaron para que las instituciones, desde los bancos hasta el Pentágono, pudieran exigir a sus empleados y clientes una segunda forma de autenticación más allá de un nombre de usuario y una contraseña: algo físico en su bolsillo que pudiera demostrar que lo poseían, y así probar su identidad. Sólo después de teclear el código que aparecía en su token SecurID (un código que solía cambiar cada 60 segundos) podían acceder a su cuenta.

Las semillas de SecurID que RSA generaba y distribuía cuidadosamente a sus clientes permitían a los administradores de red de esos clientes configurar servidores que podían generar los mismos códigos, y luego comprobar los que los usuarios introducían en las solicitudes de acceso para ver si eran correctos. Ahora, tras robar esas semillas, sofisticados ciberespías disponían de las claves para generar esos códigos sin los tokens físicos, abriendo una vía de acceso a cualquier cuenta cuyo nombre de usuario o contraseña fuera adivinable, ya hubiera sido robada o se hubiera reutilizado desde otra cuenta comprometida. RSA había añadido un candado adicional y único a millones de puertas en Internet, y estos hackers ahora conocían potencialmente la combinación de cada una de ellas.

El pasado mes de diciembre, cuando se hizo público que la empresa SolarWinds había sido hackeada por espías rusos, el mundo se despertó con la idea de un "ataque a la cadena de suministro": una técnica en la que un adversario compromete un punto de vulnerabilidad en un proveedor de software o hardware situado aguas arriba -y fuera de la vista- de su objetivo, un punto ciego en la visión de la víctima de sus riesgos de ciberseguridad. Los agentes del Kremlin que hackearon SolarWinds ocultaron el código de espionaje en una herramienta de gestión de TI llamada Orion, utilizada por nada menos que 18.000 empresas e instituciones de todo el mundo.

Utilizando el compromiso de la cadena de suministro de SolarWinds, la agencia de inteligencia extranjera de Rusia, conocida como el SVR, penetró profundamente en al menos nueve agencias federales de Estados Unidos, incluyendo el Departamento de Estado, el Tesoro de Estados Unidos, el Departamento de Justicia y la NASA. En otro ataque a la cadena de suministro que conmocionó al mundo unos años antes, la agencia de inteligencia militar rusa, conocida como GRU, secuestró una pieza de un oscuro software de contabilidad ucraniano para impulsar un gusano destructor de datos conocido como NotPetya, infligiendo 10.000 millones de dólares en daños en todo el mundo en el peor ciberataque de la historia.

Sin embargo, para aquellos con una memoria más larga, la brecha de RSA fue el ataque masivo original a la cadena de suministro. Los ciberespías estatales -que más tarde se reveló que trabajaban al servicio del Ejército Popular de Liberación de China- penetraron en la infraestructura de la que se depende en todo el mundo para proteger Internet. Y al hacerlo, tiraron de la manta bajo el modelo de seguridad digital de todo el mundo. "Me abrió los ojos a los ataques a la cadena de suministro", dice Mikko Hypponen, director de investigación de F-Secure, que trabajó con Hirvonen en el análisis de la empresa sobre la violación de RSA. "Cambió mi visión del mundo: el hecho de que, si no puedes entrar en tu objetivo, encuentras la tecnología que utilizan y entras ahí en su lugar".

En la década siguiente, muchos ejecutivos clave de RSA implicados en el incumplimiento de la empresa han guardado silencio, obligados por acuerdos de no divulgación de 10 años. Ahora esos acuerdos han expirado, lo que les permite contarme sus historias con nuevos detalles. Sus relatos reflejan la experiencia de ser objetivo de sofisticados piratas informáticos estatales que, de forma paciente y persistente, atacan a sus objetivos de red más valiosos a escala mundial, donde el adversario a veces entiende las interdependencias de los sistemas de sus víctimas mejor que las propias víctimas, y está dispuesto a explotar esas relaciones ocultas.

Después de 10 años de piratería informática patrocinada por el Estado y de secuestros de la cadena de suministro, la brecha de RSA puede considerarse ahora como el heraldo de nuestra actual era de inseguridad digital, y una lección sobre cómo un adversario decidido puede socavar las cosas en las que más confiamos.

EL 8 DE MARZO DE 2011, un frío día de finales de invierno, Todd Leetham terminó de fumar y volvía a la sede de RSA en Bedford, Massachusetts -un par de edificios conectados al borde de un bosque en los suburbios de Boston- cuando un administrador de sistemas le apartó y le pidió que echara un vistazo a algo extraño.

El administrador se había dado cuenta de que un usuario había accedido a un servidor desde un PC en el que no solía trabajar, y que la configuración de permisos de la cuenta parecía inusual. Un director técnico que investigaba el acceso anómalo con Leetham y el administrador pidió a Bill Duane, un veterano ingeniero de RSA, que echara un vistazo. Para Duane, que en ese momento estaba ocupado trabajando en un algoritmo criptográfico, la anomalía no parecía motivo de alarma. "Francamente, pensé que este administrador estaba loco", recuerda. "Afortunadamente, fue lo suficientemente testarudo como para insistir en que algo iba mal".

Leetham y los encargados de responder a los incidentes de seguridad de la empresa empezaron a rastrear el comportamiento aberrante y a analizar los datos forenses de cada máquina que había tocado la cuenta anómala. Empezaron a ver más rarezas reveladoras en las credenciales de los empleados, que se remontaban a días atrás. El administrador tenía razón. "Sin duda", dice Duane, "esto era la punta del iceberg".

Durante los días siguientes, el equipo de seguridad del centro de operaciones de seguridad de RSA -una sala de control al estilo de la NASA con filas de escritorios y monitores que cubren una pared- rastreó meticulosamente las huellas dactilares de los intrusos. Los empleados de RSA empezaron a trabajar casi 20 horas al día, impulsados por el escalofriante conocimiento de que la brecha que estaban rastreando seguía desarrollándose. La dirección exigía actualizaciones de sus hallazgos cada cuatro horas, de día o de noche.

Los analistas acabaron rastreando el origen de la filtración hasta un único archivo malicioso que, según ellos, había llegado al ordenador de un empleado de RSA cinco días antes de que iniciaran la búsqueda. Un empleado de Australia había recibido un correo electrónico con el asunto "Plan de contratación 2011" y una hoja de cálculo Excel adjunta. Lo abrió. Dentro del archivo había un script que explotaba una vulnerabilidad de día cero -un fallo de seguridad secreto y sin parches- en Adobe Flash, plantando una pieza común de software malicioso llamada Poison Ivy en la máquina de la víctima.

Ese punto de entrada inicial en la red de RSA, según señaló más tarde Hirvonen de F-Secure en su propio análisis, no era especialmente sofisticado. Un hacker ni siquiera habría podido explotar la vulnerabilidad de Flash si la víctima hubiera estado ejecutando una versión más reciente de Windows o Microsoft Office, o si hubiera tenido acceso limitado para instalar programas en su PC, como recomiendan la mayoría de los administradores de seguridad de las redes corporativas y gubernamentales, dice Hirvonen.

Pero fue a partir de esta entrada cuando, según los analistas de RSA, los intrusos empezaron a demostrar sus verdaderas habilidades. De hecho, varios ejecutivos de RSA llegaron a creer que al menos dos grupos de hackers estaban en su red simultáneamente -un grupo altamente cualificado explotando el acceso del otro, quizás, con o sin su conocimiento. "El primer grupo dejó un rastro en el bosque y, justo en medio de él, se ramifica el segundo rastro", dice Sam Curry, que era el director de seguridad de RSA en ese momento. "Y ese segundo ataque fue mucho más hábil".

En el PC de ese empleado australiano, alguien había utilizado una herramienta que sacaba las credenciales de la memoria de la máquina y luego reutilizaba esos nombres de usuario y contraseñas para iniciar sesión en otras máquinas de la red. A continuación, buscaron en la memoria de esos ordenadores más nombres de usuario y contraseñas, encontrando algunos que pertenecían a administradores más privilegiados. Al final, los hackers llegaron a un servidor que contenía cientos de credenciales de usuarios. Hoy en día, esta técnica de robo de credenciales es habitual. Pero en 2011 los analistas se sorprendieron al ver cómo los hackers se extendían por la red. "Fue la forma más brutal de penetrar en nuestros sistemas que jamás había visto", afirma Duane.

Las brechas tan extensas como la que se llevó a cabo contra RSA suelen descubrirse meses después del hecho, cuando los intrusos ya se han ido o están inactivos. Pero Duane dice que el incidente de 2011 fue diferente: En cuestión de días, los investigadores habían alcanzado esencialmente a los intrusos y los observaban en acción. "Intentaban entrar en un sistema, entonces los detectábamos uno o dos minutos después y entrábamos y apagábamos ese sistema o desactivábamos el acceso a él", dice Duane. "Luchábamos contra ellos con uñas y dientes, en tiempo real".

Fue en medio de esa febril persecución cuando Leetham pilló a los hackers robando lo que todavía cree que era su objetivo más prioritario: las semillas de SecurID.

Los ejecutivos de RSA me dijeron que la parte de su red encargada de fabricar los tokens de hardware de SecurID estaba protegida por un "air gap", es decir, una desconexión total de los ordenadores de cualquier máquina que entre en contacto con Internet. Pero en realidad, dice Leetham, un servidor de la red de RSA conectado a Internet estaba vinculado, a través de un cortafuegos que no permitía ninguna otra conexión, al almacén de semillas en la parte de fabricación. Cada 15 minutos, ese servidor extraía un determinado número de semillas para poder encriptarlas, grabarlas en un CD y entregarlas a los clientes de SecurID. Ese enlace era necesario, ya que permitía a la parte comercial de RSA ayudar a los clientes a configurar su propio servidor, que podía comprobar el código de seis dígitos de los usuarios cuando se tecleaba en un aviso de inicio de sesión. Incluso después de enviar el CD al cliente, esas semillas permanecían en el servidor del almacén de semillas como copia de seguridad en caso de que el servidor SecurID del cliente o su CD de configuración se corrompieran de algún modo.

Ahora, en lugar de las habituales conexiones cada 15 minutos, Leetham vio registros de miles de solicitudes continuas de datos cada segundo. Es más, los hackers habían estado recogiendo esas semillas no en uno, sino en tres servidores comprometidos, retransmitiendo las peticiones a través de la única máquina conectada. Habían empaquetado la colección de semillas en tres partes, las habían trasladado al lejano servidor de Rackspace y luego las habían recombinado en lo que parecía ser la base de datos completa de todas las semillas que RSA tenía almacenadas en el depósito de semillas. "Me quedé en plan: 'Wow'", dice Leetham. "En cierto modo lo admiré. Pero al mismo tiempo: 'Oh, mierda'".

Cuando Leetham se dio cuenta de que la colección de semillas probablemente había sido copiada -y después de haber hecho su intento, demasiado tardío, de borrar los datos del servidor de los piratas informáticos-, la enormidad del suceso le golpeó: La confianza que los clientes habían depositado en RSA, quizá su bien más preciado, estaba a punto de desaparecer. "Esto es un evento de extinción", recuerda haber pensado. "RSA está acabada".

Era tarde por la noche cuando el equipo de seguridad se enteró de que el almacén de semillas había sido saqueado. Bill Duane tomó la decisión: Cortarían físicamente todas las conexiones de red de RSA que fueran necesarias para limitar los daños y detener cualquier otro robo de datos. Esperaban, en particular, proteger cualquier información de los clientes que estuviera relacionada con las semillas y que pudiera ser necesaria para que los hackers las explotaran. (Algunos miembros del personal de RSA también me sugirieron que las semillas se habían almacenado en un estado encriptado, y que el corte de las conexiones de red pretendía evitar que los hackers robaran la clave necesaria para desencriptarlas). Duane y un director de informática entraron en el centro de datos y empezaron a desenchufar los cables de Ethernet uno por uno, cortando las conexiones de la empresa con sus instalaciones de fabricación, las partes de su red que gestionaban los procesos empresariales básicos, como los pedidos de los clientes, e incluso su sitio web. "Básicamente cerré el negocio de RSA", dice. "Inutilicé la empresa para detener cualquier posible liberación adicional de datos".

Al día siguiente, el director general de RSA, Art Coviello, estaba reunido en la sala de conferencias contigua a su despacho, preparando una declaración pública sobre la brecha en curso. Coviello había estado recibiendo actualizaciones desde que se descubrieron las intrusiones. A medida que el alcance de la brecha crecía, canceló un viaje de negocios a Brasil. Pero se mantuvo relativamente optimista. Después de todo, no parecía que los piratas informáticos hubieran violado los datos de las tarjetas de crédito u otra información sensible de los clientes. Supuso que echarían a los piratas informáticos, publicarían su declaración y seguirían con sus negocios.

Pero en medio de la reunión, recuerda, una ejecutiva de marketing que estaba en la mesa con él miró su teléfono y murmuró: "Oh, vaya".

Coviello le preguntó qué pasaba. Ella se mostró reticente. Él le quitó el teléfono de la mano y leyó el mensaje. Decía que Bill Duane iba a subir al despacho de Coviello; quería poner al día al director general en persona. Cuando subió, le dio la noticia: Los hackers habían llegado a las semillas de SecurID. "Me sentí como si me hubieran disparado una bala de cañón en el estómago", dice Coviello.

En las horas que siguieron, los ejecutivos de RSA debatieron cómo hacer pública la noticia. Una persona del departamento legal sugirió que no era necesario decírselo a sus clientes, recuerda Sam Curry. Coviello dio un puñetazo en la mesa: Insistió en que no sólo admitirían la infracción, sino que se pondrían al teléfono con cada uno de sus clientes para discutir cómo podrían protegerse. Joe Tucci, director general de la empresa matriz, EMC, sugirió rápidamente que se hiciera cargo de los más de 40 millones de tokens SecurID. Pero RSA no disponía de tantos tokens; de hecho, la brecha le obligaría a cerrar la fabricación. Durante las semanas siguientes al hackeo, la empresa sólo pudo reanudar la producción con una capacidad reducida.

Cuando el esfuerzo de recuperación se puso en marcha, un ejecutivo sugirió que lo llamaran Proyecto Fénix. Coviello rechazó inmediatamente el nombre. "Mentira", recuerda haber dicho. "No vamos a resurgir de las cenizas. Vamos a llamar a este proyecto Apolo 13. Vamos a aterrizar la nave sin que se produzcan daños".

A las 7:00 de la mañana siguiente, el 17 de marzo, el jefe de ventas de RSA en Norteamérica, David Castignola, terminaba de hacer ejercicio temprano en la cinta de correr de su gimnasio local en Detroit. Cuando cogió el teléfono, vio que había perdido nada menos que 12 llamadas, todas de esa misma mañana, y todas del presidente de RSA, Tom Haiser. Los mensajes de voz de Haiser decían que la RSA estaba a punto de anunciar una importante brecha de seguridad. Tenía que estar en el edificio.

Unas horas y un vuelo de última hora después, Castignola corrió literalmente a la sede de RSA en Bedford y subió a la sala de conferencias del cuarto piso. Enseguida se dio cuenta de los rostros pálidos y demacrados de los empleados que llevaban más de una semana lidiando con la crisis. "Cada pequeño indicador que recibía era: Esto es peor de lo que puedo imaginar", recuerda Castignola.

Esa tarde, Coviello publicó una carta abierta a los clientes de RSA en el sitio web de la compañía. "Recientemente, nuestros sistemas de seguridad identificaron un ciberataque extremadamente sofisticado en progreso", decía la carta. "Aunque en este momento estamos seguros de que la información extraída no permite un ataque directo exitoso a ninguno de nuestros clientes de RSA SecurID, esta información podría utilizarse potencialmente para reducir la eficacia de una implementación actual de autenticación de dos factores como parte de un ataque más amplio", continuaba la carta, minimizando un poco la crisis.

En Bedford, Castignola recibió una sala de conferencias y la autoridad para pedir tantos voluntarios de la empresa como necesitara. Un grupo rotativo de casi 90 empleados comenzó el proceso de semanas de duración, día y noche, de organizar llamadas telefónicas individuales con cada cliente. Trabajaron a partir de un guión, guiando a los clientes a través de medidas de protección como añadir o alargar un número PIN como parte de sus inicios de sesión de SecurID, para hacerlos más difíciles de replicar para los hackers. Castignola recuerda que, cuando caminaba por los pasillos del edificio a las 10 de la noche, oía llamadas en los altavoces de todas las puertas cerradas. En muchos casos, los clientes gritaban. Castignola, Curry y Coviello hicieron cada uno cientos de esas llamadas; Curry empezó a bromear diciendo que su título era "jefe de disculpas".

Al mismo tiempo, la paranoia empezaba a apoderarse de la empresa. La primera noche tras el anuncio, Castignola recuerda que pasó por un armario de cableado y vio un número absurdo de personas saliendo de él, muchas más de las que imaginaba que podrían caber. "¿Quiénes son esas personas?", preguntó a otro ejecutivo cercano. "Es el gobierno", respondió vagamente el ejecutivo.

De hecho, cuando Castignola aterrizó en Massachusetts, tanto la NSA como el FBI habían sido llamados para ayudar en la investigación de la empresa, al igual que el contratista de defensa Northrop Grumman y la empresa de respuesta a incidentes Mandiant. (Casualmente, empleados de Mandiant ya habían estado en el lugar antes de la brecha, instalando equipos de sensores de seguridad en la red de RSA).

El personal de RSA comenzó a tomar medidas drásticas. Preocupados por la posibilidad de que su sistema telefónico estuviera en peligro, la empresa cambió de operador, pasando de los teléfonos de AT&T a los de Verizon. Los ejecutivos, que no se fiaban ni siquiera de los nuevos teléfonos, celebraban reuniones en persona y compartían copias en papel de los documentos. El FBI, temiendo un cómplice en las filas de RSA por el aparente nivel de conocimiento que los intrusos parecían tener de los sistemas de la empresa, empezó a hacer comprobaciones de antecedentes. "Me aseguré de que todos los miembros del equipo -no importaba quiénes eran, ni qué reputación tenían- fueran investigados, porque hay que estar seguros", dice Duane.

Las ventanas de los despachos de algunos ejecutivos y de las salas de conferencias se cubrieron con capas de papel de carnicería, para evitar la vigilancia con micrófonos láser -una técnica de escucha a larga distancia que capta las conversaciones a partir de las vibraciones de los cristales de las ventanas- por parte de supuestos espías en los bosques de los alrededores. El edificio fue barrido en busca de micrófonos. Varios ejecutivos insistieron en que encontraron dispositivos de escucha ocultos, aunque algunos eran tan viejos que sus baterías estaban agotadas. Nunca quedó claro si esos micrófonos tenían alguna relación con la brecha.

Mientras tanto, el equipo de seguridad de RSA y los investigadores contratados para ayudar estaban "desmontando la casa hasta los cimientos", como dice Curry. En cada parte de la red que los piratas informáticos tocaron, dice, limpiaron el contenido de las máquinas potencialmente comprometidas, e incluso las adyacentes. "Fuimos físicamente alrededor y, si había una caja en la que estaban, se borraba", dice Curry. "Si se perdían datos, mala suerte".

A finales de Mayo de 2011, unos dos meses después del anuncio de la brecha, RSA seguía recuperándose, reconstruyendo y pidiendo disculpas a los clientes cuando recibió una réplica: apareció un post en el sitio web del influyente bloguero tecnológico Robert X. Cringely, titulado "InsecureID: ¿No más secretos?"

El post se basaba en una fuente de un importante contratista de defensa, que le había dicho a Cringely que la empresa estaba respondiendo a una extensa intrusión de piratas informáticos que parecían haber utilizado valores de semilla RSA robados para entrar. Todo el mundo en el contratista de defensa estaba reemplazando sus tokens RSA. De repente, la brecha de RSA parecía mucho más grave de lo que el anuncio original de la compañía había descrito. "Bueno, no tardó mucho tiempo para que quien crackeó RSA encontrara una cerradura que se ajustara a esa llave", escribió Cringely. "¿Y si todos los tokens de RSA han sido comprometidos, en todas partes?".

Dos días después, Reuters reveló el nombre del contratista militar hackeado: Lockheed Martin, una empresa que representaba una cornucopia de planes ultrasecretos de armas y tecnologías de inteligencia. "La costra se estaba curando", dice Castignola. "Entonces llegó Lockheed. Eso fue como un hongo nuclear. Volvimos a las andadas".

En los días siguientes, los contratistas de defensa Northrop Grumman y L-3 también fueron nombrados en las noticias. Los hackers con los valores de la semilla de SecurID también los habían atacado, según las historias, aunque nunca quedó claro hasta qué punto los intrusos habían penetrado en las empresas. Tampoco se reveló a qué habían accedido los hackers dentro de Lockheed Martin. La empresa afirmó que había evitado que los espías robaran información sensible como datos de clientes o secretos clasificados.

En otra carta abierta a los clientes, a principios de junio de 2011, Art Coviello, de RSA, admitió: "Pudimos confirmar que la información tomada de RSA en marzo había sido utilizada como elemento de un intento de ataque más amplio contra Lockheed Martin, un importante contratista de defensa del gobierno estadounidense."

Hoy, con 10 años de retrospectiva, Coviello y otros ex ejecutivos de RSA cuentan una historia que contradice claramente los relatos de la época: La mayoría de los antiguos empleados de RSA que hablaron conmigo afirman que nunca se demostró que SecurID tuviera algún papel en la brecha de Lockheed. Coviello, Curry, Castignola y Duane sostienen que nunca se confirmó que los intrusos dentro de los sistemas de RSA hubieran robado con éxito la lista completa de los valores de las semillas en una forma no corrompida y no encriptada, ni la lista de clientes asignada a esas semillas necesaria para explotarlas. "No creo que el ataque de Lockheed estuviera relacionado con nosotros en absoluto", afirma rotundamente Coviello.

Por el contrario, en los años transcurridos desde 2011, Lockheed Martin ha detallado cómo los hackers utilizaron la información robada en la brecha de SecurID de RSA como trampolín para penetrar en su red, aunque insiste en que no se robó ninguna información con éxito en ese evento. Una fuente de Lockheed con conocimiento de la respuesta al incidente de la compañía reafirmó a WIRED las afirmaciones originales de la empresa. "Mantenemos los resultados de nuestra investigación forense", dice la fuente. "Nuestro análisis determinó que la violación de nuestro proveedor de token de autenticación de dos factores fue un factor que contribuyó directamente al ataque a nuestra red, un hecho que ha sido ampliamente reportado por los medios de comunicación y reconocido públicamente por nuestro proveedor, incluyendo a Art." De hecho, la fuente de Lockheed afirma que la empresa vio a los hackers introducir códigos SecurID en tiempo real, confirmó que los usuarios objetivo no habían perdido sus tokens y luego, tras sustituir los tokens de esos usuarios, observó cómo los hackers seguían introduciendo sin éxito los códigos de los antiguos tokens.

La NSA, por su parte, nunca ha tenido muchas dudas sobre el papel de RSA en los posteriores hackeos. En una sesión informativa ante el Comité de Servicios Armados del Senado un año después de la brecha de RSA, el director de la NSA, el general Keith Alexander, dijo que el hackeo de RSA "llevó a que al menos un contratista de defensa de los Estados Unidos fuera víctima de actores con credenciales falsificadas", y que el Departamento de Defensa se había visto obligado a reemplazar todos los tokens de RSA que utilizaba.

En la audiencia, Alexander siguió atribuyendo esos ataques, vagamente, a un culpable cada vez más común: China. El New York Times y la empresa de seguridad Mandiant publicarían más tarde un innovador informe sobre un grupo de hackers estatales chinos al que Mandiant había bautizado como APT1. Se creía que el grupo era la Unidad 61398 del Ejército Popular de Liberación, con sede en las afueras de Shanghai. Entre sus docenas de objetivos durante los cinco años anteriores: los gobiernos de Estados Unidos, Canadá, Corea del Sur, Taiwán, Vietnam; y las Naciones Unidas, y RSA.

Después de que esos informes se hicieran públicos, Bill Duane imprimió una foto del cuartel general de los hackers, un edificio blanco de 12 plantas situado en la calle Datong de Shanghai. La pegó en una diana de su oficina.

Le pregunté a Duane, que se retiró de RSA en 2015 tras más de 20 años en la empresa, en qué momento consideró que la brecha de RSA había terminado realmente: ¿Fue la mañana después de tomar la solitaria decisión de desconectar una parte de la red de la empresa? ¿O cuando la NSA, el FBI, Mandiant y Northrop terminaron y se fueron? "Nuestra opinión era que el ataque no había terminado nunca", responde. "Sabíamos que dejaron puertas traseras, que siempre van a poder entrar, que el atacante puede, con sus recursos, entrar cuando quiera".

La angustiosa experiencia de Duane en respuesta a la intrusión le enseñó -y quizás debería enseñarnos a todos- que "toda red está sucia", como él dice. Ahora predica a las empresas que deben segmentar sus sistemas y acordonar sus datos más sensibles para que sigan siendo impenetrables incluso para un adversario que ya esté dentro del cortafuegos.

En cuanto a Todd Leetham, observó el fiasco de SolarWinds durante los últimos seis meses con una sombría sensación de déjà vu. "Todo el mundo estaba conmocionado. Pero en retrospectiva, bueno, duh, estaba en todas partes", dice sobre SolarWinds. Al igual que, por analogía, SecurID, 10 años antes.

Leetham ve las lecciones del compromiso de la cadena de suministro de RSA en términos más crudos que incluso su colega Bill Duane: fue "una visión de lo frágil que es el mundo", dice. "Es un castillo de naipes durante un aviso de tornado".

SolarWinds demostró lo precaria que sigue siendo esta estructura, argumenta. Tal y como lo ve Leetham, el mundo de la seguridad confió ciegamente en algo que existía fuera de su modelo de amenazas, sin imaginar que un adversario podría atacarlo. Y una vez más, el adversario sacó una carta de apoyo que apuntalaba los cimientos de la casa, una que se había confundido con tierra firme.

Traducción completa de www.meneame.net/story/finalmente-puede-contar-historia-completa-impres

etiquetas: artículo

» noticia original ()

Al parecer existe un fallo de seguridad bajo embargo que afecta a las últimas arquitecturas x86 que implementan direccionamiento virtual y que requerirían cambios en hardware para ser solucionado. Esta vulnerabilidad afecta a la generación de direcciones de memoria virtuales, lo que permitiría a un proceso acceder a datos fuera de su entorno de ejecución. Se están desarrollado de manera urgente parches software tanto para Linux como para Windows, aunque implican perdidas de rendimiento significativas de incluso un 50% en algunos casos.

etiquetas: lpti, intel, vilnerabilidad

» noticia original (pythonsweetness.tumblr.com)

Lo que ayudó mucho a reducir ese miedo fue entender cómo funcionan las cosas en los aviones y acostumbrarse a los ruidos, los golpes y la turbulencia. Esta entrada de blog trata de entender un poco más acerca de cómo funcionan las cosas a bordo de un avión. Más específicamente, los sistemas de entretenimiento en vuelo (IFE) Mientras volaba de Varsovia a Dubai decidí probar mi suerte y jugar con el IFE un poco, tocando esto y lo otro. De repente, después de tocar un punto específico en una de las esquinas superiores de la pantalla,el dispositivo

etiquetas: hackeo, desde, pantalla, multimedia, avión

» noticia original (blog.ioactive.com)

etiquetas: steam, hack, cuentas, privacidad, metodos de pago

» noticia original ()

etiquetas: openssl, ssl, heartbeat, heartbleed, cifrado, encriptación

» noticia original (news.idg.no)