En los medios es común ver historias de "rogue traders" (corredores de bolsa tramposos), como la de Kweku Adoboli que comentamos en este blog hace ya más de un año. Es decir alguien que es premiado por hacer las cosas mal, hasta el momento en el cual se descubre todo el tinglado y como un castillo de naipes todo se desploma. Pero son pocas las historias de programadores tramposos, aunque en teoría deberían ser tan comunes como en otras profesiones. No existe una razón para que una carrera como el desarrollo de software esté excenta de gente con muy pocos escrúpulos y dispuesta a hacer dinero fácil incluso a costa de la seguridad de otros. Pues la historia que ha aparecido en el blog sobre seguridad del equipo de investigación de riesgo de Verizon Business es sencillamente impresionante, un programador (o desarrollador) contratado por una importante empresa norteamericana que ofrece servicios de infraestructura, simulaba trabajar mientras en realidad enviaba todos los requerimientos a una empresa que había contratado en la ciudad china de Shenyang. El dedicaba un quinto de sus ingresos que según otra fuentes era de seis dígitos al año a pagar los servicios de la empresa china que hacía realmente el trabajo. Lo sorprendente para mi no ha sido el hecho de que esto pasara sino los comentarios en el blog de Verizon Business, que consideran que este progamador no ha hecho nada malo y que tan sólo equivocó su rol, que por el contrario en lugar de ser despedido merece un aumento y ser promovido a ser gerente de outsourcing, y en realidad a menos que este mal, dichos comentarios no eran irónicos. Incluso uno de las personas que dejo cometarios recomendó que en lugar de hacer la VPN desde China, para evitar ser detectado lo mejor hubiera sido iniciar la connexión a la VPN de la empresa usando como proxy el PC de la casa del programador tramposo.

Como la historia es tan fascinante y nos deja tantas lecciones, me he tomado la libertad de traducirla al español para que pueda ser leída por aquellos que no dominan el idioma:

Caso de Estudio: Puede ser una buena idea la revisión pro-activa de los logs
por: Andrew Valentine
14 de enero 2013

Con la llegada del año nuevo, es difícil no reflexionar sobre la carga de trabajo del año pasado. Mientras que las violaciones a la seguridad de los datos en gran escala es lo que hace los titulares y son ampliamente discutidos entre profesionales de la seguridad, a menudo los casos pequeños y desconocidos son los que son recordados como los más interesantes desde el punto de vista de los investigadores. De vez en cuando un caso viene a la memoria un caso que aunque pequeño, todavía implica algún tipo de ataque único – una forma inteligente y creativa por la cual un atacante víctimiza a una organización. Son estos casos únicos, los que son diferentes, los que a menudo se han convertido en lo más memorable y más hablado de entre los investigadores.

Este caso ocurrió en 2012. El escenario fue como sigue. Recibimos una solicitud de una empresa con sede en EE.UU. pidiendo nuestra ayuda para comprender alguna actividad anómala de la cual estaban siendo testigos en sus registros (logs) de la VPN. Esta organización había ido poco a poco avanzando hacia una fuerza de trabajo más orientado teletrabajo, y por lo tanto había comenzado a permitir a sus desarrolladores puedan trabajar desde sus casas en ciertos días. Para lograr esto, se había instalado un concentrador VPN bastante estándar, aproximadamente dos años antes de que recibieramos su llamada. A principios de mayo del 2012, después de leer el DBIR 2012, su departamento de la seguridad IT decidió que debían iniciar un seguimiento activo de los registros que se generan en el concentrador VPN. (Como se ilustra en nuestras estadísticas DBIR, una revisión continua y proactiva del registro prácticamente nunca sucede (sólo el 8% de las violaciones de seguridad en el 2011 fueron descubiertos por revisión del registro interno). Así, comenzaron escudriñando diariamente las conexiones VPN en su entorno. Lo que encontraron los asustó y sorprendó: una conexión VPN abierta y activa desde Shenyang, ¡China! Y además está conexión estaba ACTIVA cuando fue descubierta.

Además de lo obvio, este descubrimiento desconcertó mucho al personal de seguridad, por tres razones principales:

• Son una empresa de infraestructura de los EE.UU.  y fue una conexión VPN no autorizada desde CHINA. Las consecuencias fueron graves y no podían ser exageradas.
• La compañía implementó una autenticación de dos factores para estas conexiones VPN. El segundo factor es un token dinámico generado por una llave RSA. Si este mecanismo de seguridad había sido comprometido por un atacante, una vez más, las consecuencias eran alarmantes.
• El desarrollador cuyas credenciales se utilizaban estaba sentado en su escritorio en la oficina.
   

Claramente dicho, los registros de la VPN mostraban conectado desde China al empleado, que sin embargo estaba sentado ahí en su escritorio, mirando fijamente su monitor. Poco después de haber hecho este descubrimiento, se pusieron en contacto a nuestro grupo de asistencia. Con base en la información que había obtenido, la empresa inicialmente sospechó algún tipo de malware desconocido que fue capaz de enrutar el tráfico de una conexión de confianza interna hacia China, y luego enviarla de vuelta. Esta era la única manera que intelectualmente podría resolver el problema de autenticación. ¿Qué otra explicación puede haber?

Nuestros investigadores pasaron las horas iniciales trabajando con la víctima para facilitar una comprensión completa de la topología de red, la segmentación, la recopilación de los registros de autenticación, y la correlación entre estos, así continuaron. Una bandera roja que fue inmediatamente evidente para los investigadores era que esta extraña conexión VPN desde Shenyang no era nueva, ni mucho menos. Desafortunadamente, los registros disponibles en el concentrador VPN sólo se remontaban a 6 meses, pero se encontró conexiones casi todos los días desde Shenyang, y en ocasiones estas conexiones duraban toda la jornada laboral. En otras palabras, los intrusos no sólo entraban al entorno de la empresa de manera frecuente, sino que también lo habian estado haciendo durante algún tiempo.

Una parte central de la investigación fue el propio trabajador, la persona cuyas credenciales se habían utilizado para iniciar y mantener una conexión VPN desde China.

El perfil de empleado es de un hombre a mediados de sus 40 años, desarrolladores de software experto en C, C++, Perl, Java, Ruby, PHP, Python, etc., permanencia relativamente larga en la empresa, hombre de familia, inofensivo y tranquilo. Alguien que uno no miraría dos veces en un ascensor. Por razones de estudio del caso, vamos a llamarlo "Bob".

El personal IT de la compañía estaban seguros de que el problema tenía que ver con algún tipo de malware de día cero que fue capaz de iniciar conexiones VPN de la estación de trabajo de Bob a través de proxy externo y luego ruteaba el tráfico VPN a China, sólo para ser enviados de regreso a su concentrador . Sí, es una teoría un poco complicada, y como todas las teorías un poco complicadas, resultó ser incorrecta.

Como una medida de investigación básica, cuando los investigadores obtuvieron una imagen forense del disco duro de la computadora de Bob, se pasó a trabajar en hallar tantos archivos recuperables como fuera posible del espacio no asignado en el disco. Esto ayudaría a identificar si se ha introducido un software malicioso en el sistema que se haya eliminado posteriormente. También serviría para ilustrar los hábitos de trabajo de Bob y potencialmente revelar si inadvertidamente bob había descargado algo en su sistema. Lo que descubrimos nos sorprendió, cientos de facturas en formato PDF de un contratista desarrollador en (lo has adivinado) Shenyang, China.

Como resultado se descubrió que Bob se había limitado subcontratar su trabajo a una empresa de consultoría china. Bob le pagó menos de una quinta parte de su salario de seis cifras por una empresa china para hacer su trabajo en su lugar. No había ningún problema con la autenticación porque Bob había enviado físicamente su llave RSA generadora de tokens por FedExed a China para que el contratista externo puede acceder al sistema bajo sus credenciales durante la jornada laboral. Aparentaba, estar trabajando en promedio de 9 AM a 5 PM todos los días laborables. Pero los investigadores revisando su historial de navegación en la web, descubrieron la historia completa.

Un  día "típico" de trabajo para Bob se veía así:

9:00 am – Llegada y navegar Reddit durante un par de horas. Ver videos de gatos

11:30 a.m. – Tomar el almuerzo

1:00 p.m. – tiempo Ebay.

Alrededor de las 2:00 p.m actualizaciones de Facebook – LinkedIn

4:30 pm – Envío de un e-mail con el reporte de lo hecho a la gerencia.

5:00 p.m. – Sale a su casa

La evidencia sugirió incluso que tenía la misma estafa en varias empresas de la zona. Dicho todo esto, parecía que ganaba varios cientos de miles de dólares al año, y sólo tuvo que pagar a la empresa de consultoría china cerca de cincuenta mil dólares al año. ¿Cuál es la mejor parte? Los investigadores tuvieron la oportunidad de leer las opiniones sobre su rendimiento en el trabajo por parte del departamento de recursos humanos. Durante los últimos años de forma consecutiva recibió excelentes comentarios. Su código es limpio, bien escrito y presentado de manera oportuna. Trimestre tras trimestre, su evaluación de desempeño le señaló como el mejor desarrollador en el edificio.