Por @Alvy — 16 de Noviembre de 2018

Muchas veces conseguir cosas es tan fácil como pedirlas con educación. Por eso es muy instructivo –y a la vez divertido– escuchar de boca del propio Kevin Mitnick, uno de los hackers más famosos de todos los tiempos, cómo usó la ingeniería social para hacerse con el código fuente del Motorola MicroTAC que era «como el iPhone X de la época». Estamos remontándonos a 1992 y todo era un poco diferente.

Siendo entonces un fugitivo de la justicia –había sido atraído un poco por el Lado Oscuro– Mitnick llamó directamente al servicio de información telefónica para pedir el número de las oficinas de Motorola. Pidió amablemente que le pasaran con el jefe de producto del MicroTAC.

La burocracia de las grandes empresas es como es, de modo que esa llamada le hizo saltar por siete u ocho personas intermedias, mientras aprendía qué departamentos había y algo sobre cómo trabajaban, hasta que llegó a un vicepresidente de la compañía, quien le dio el nombre y extensión de la jefa de producto en cuestión. Casualmente estaba de vacaciones pero había dejado el nombre de otra compañera de trabajo en el mensaje grabado, así que con mucha paciencia Mitnick siguió llamando hasta que logró hablar con ella para pedirle el código. «¿Qué versión quieres?» le dijo. «La última y la mejor» fue su respuesta.

Como en toda buena historia, nuestro héroe está a punto de fracasar en tan rocambolesco camino. Pero el hecho de que hubiera cientos de directorios con cientos de ficheros no fue un impedimento (enseñó a su interlocutora a usar TAR para comprimirlo todo en un archivo de 5 MB). Ni tampoco que el FTP donde le pidió que lo subiera estuviera fuera de la red de Motorola y no funcionara: la buena mujer se levantó para hablar con el responsable de seguridad y volvió con su nombre de usuario y contraseña para dárselo a Mitnick. Desde ese momento todo fue mucho más fácil.

Como es bien sabido el protagonista de esta historia acabó pasando una temporadita a la sombra, no exactamente por esto (el código resultó no ser gran cosa) sino por otros asuntos similares anteriores, que lo llevaron a un controvertido juicio con el FBI en su contra.

Tras esto Mitnick se convirtió en un hacker redimido y actualmente trabaja como consultor de seguridad para un montón empresas y suele dar conferencias por todo el mundo. En su twitter aparecen siempre cosas interesantes: @KevinMitnick.

Bonus: mi vídeo de ingeniería social favorito, Jessica Clark haciendo de madre agobiada mientras roba una cuenta de la compañía telefónica y cambia la contraseña de su supuesto «novio». Oro puro que merece estudiar detalle a detalle.

(Vía Motherboard.)

Compartir en Flipboard  Compartir en Facebook  Tuitear
Por @Alvy — 5 de Octubre de 2018

Intra

Intra (descargable en Google Play para Android) es una app de código abierto desarrollada por Jigsaw (una de las compañías de Google/Alphabet). Sirve para proteger el DNS de las conexiones, de modo que nadie pueda bloquearlo, censurarlo o modificarlo. Se instala rápido y fácil y a partir de ese momento, a navegar seguro y por cualquier servidor.

El Sistema de Nombres de Dominio DNS normalmente funciona bien aunque a veces los proveedores puedan tener sus fallos ocasionales; el verdadero problema es cuando se manipula para bloquear sitios por órdenes de gobiernos o porque aplicaciones o malware lo interceptan para fines «turbios».

Lo que hace Intra es básicamente cifrar las peticiones de DNS usando el protocolo DNS sobre HTTPS (permite elegir proveedor de DNS que se prefiera, y ofrecen algunos muy populares). De este modo a menos que los servidores originales desaparecieran de internet o estuvieran sin conexión, siempre se podría acceder a ellos (cosa que podría no suceder al utilizar el DNS de un proveedor local). Dicen sus creadores que el sistema no afecta a la velocidad de las conexiones y además no tiene limitaciones de uso.

Para los fanáticos de la seguridad y quien quiera aprender más el código fuente de Intra también está en Github, para examinarlo, modificarlo o lo que cualquier quiera.

(Vía ZDNet.)

Compartir en Flipboard  Compartir en Facebook  Tuitear
Por @Alvy — 12 de Septiembre de 2018

BA JavaScript / RiskIQ

En RiskIQ han publicado el análisis post mortem del robo de datos que sufrió British Airways a finales de agosto: Inside the Magecart Breach of British Airways: How 22 Lines of Code Claimed 380,000 Victims. En concreto afectó a todas las personas que utilizaron la pasarela de pagos de la web principal y de la app móvil, entre el 21 de agosto y el 5 de septiembre.

Según parece un grupo denominado Magecart que ya había actuado antes consiguió inyectar su código en una librería de JavaScript que utiliza la web de British Airways, concretamente la Modernizr version 2.6.2.

Como muchas webs actualizan sus librerías a menudo si por alguna razón no pasan un chequeo de seguridad estricto puede que alguien la haya modificado con malas intenciones en otro lugar –por ejemplo el repositorio de código del que se descargan– en forma de actualización menor que pasa desapercibida – y ahí es cuando empiezan los problemas.

Ante este problema los usuarios, clientes y visitantes no pueden hacer nada, tal y como explican en Hackeo a British Airways en El Confidencial. Es la empresa propietaria de la web/app quien debe garantizar la seguridad cuando se le proporcionan datos sensibles. Este caso demuestra que esto puede suceder en sitios web y apps de todo tipo: desde los relativamente sencillos como los gestionados con WordPress a las grandes megacorporaciones que hacen grandes desarrollos pero dependen de código externo como son estas librerías. Es algo que requiere aumentar las medidas de seguridad especialmente cuando se manejan sistemas de pago, datos personales o cuentas con contraseñas.

(Vía The Next Web + El Confidencial + Mikko Hypponen.)

Compartir en Flipboard  Compartir en Facebook  Tuitear
Por @Alvy — 16 de Agosto de 2018

En este vídeo de Jon Masters, ingeniero de Red Hat, se explica de forma técnica pero accesible –para quien tenga los conocimientos mínimos necesarios, claro– el problema que supone la nueva vulnerabilidad de seguridad llamada L1 Terminal Fault (L1TF) que permite el acceso no autorizado a cierta información en los procesadores Intel Core i3/i5/i7/M, Xeon D/E3/E5/E7 v1-v4 y otros modelos. (Según parece, los AMD se han librado en esta ocasión).

El asunto va en línea con las vulnerabilidades Meltdown y Spectre detectadas a principios de año. La explicación técnica comienza por el clásico y divulgativo «cómo hemos podido llegar hasta aquí» y explica el funcionamiento de las memorias cachés de los procesadores, cómo funciona la memoria física y la virtual y cómo actúa la ejecución especulativa y fuera-de-orden. Al final se explica que la vulnerabilidad se deba a que se puede acceder a memoria que se supone «protegida» provocando ciertos fallos al solicitar acceso a la información, aprovechando las cachés y usando las técnicas que ya explotaban Meltdown y Spectre.

Ya existen algunos parches triviales para el problema prinipial, pero esta vulnerabilidad afecta también a las Software Guard Extensions (SGX) del enclave seguro que dicen «podrían llegar a ver completamente destruido su ecosistema» y a los entornos virtualizados (máquinas virtuales, hipervisores y diferentes zonas protegidas de la memoria).

Por suerte el L1TF se conoce desde enero –aunque se ha dado de conocer ahora– y a fecha de hoy no se ha detectado todavía software malicioso que lo explote abiertamente. El problema será más relevante para los proveedores de virtualización y cloud computing que para los individuos (entre otras cosas porque algunas soluciones ralentizan un poco las máquinas), así que dentro de lo que cabe el problema al menos está ya en manos de los mejores profesionales posibles.

Compartir en Flipboard  Compartir en Facebook  Tuitear