El incidente (misconfused)

(La entrada de hoy es la segunda colaboración de Francisco Benet, un amigo de algunos de nosotros —y familia de algún otro— que tiene gran experiencia en la gestión e integración de sistemas, protección de datos de carácter personal y evaluación de soluciones de integración de software y hardware, entre otros aspectos. Esperamos que les guste.)

Hace algo más de un lustro me enfrente a una situación un tanto extraña en el área de Sistemas de la organización para la que trabajaba, y que les describo a continuación (NOTA: parte de la situación descrita es ficción, para dar dramatismo y mayor realidad a la historia; no crean todo lo que leen).

El incidente

Nuestra historia comienza un buen día del mes de noviembre, en el que sin aviso previo el departamento de Sistemas comienza a recibir una buena cantidad de llamadas de personal de la empresa que no puede acceder a sus archivos de correo. Tras no pocas indagaciones, vemos que un par de servidores han perdido parte de la información, pero de una manera ciertamente extraña: algunas unidades tienen una estructura de archivos incompleta o vacía, y la fecha de los archivos no es correcta, pero el resto de las unidades están correctas. Todo hace pensar que ‘algo’ ha pasado aquella noche en varios servidores, y que no es un simple accidente; en aquel primer momento parecía como si se hubiera intentado disimular lo que había pasado. Lo que hacía la situación todavía más confusa era el hecho de que los técnicos del departamento no fuesen capaces de dar una explicación o al menos información objetiva sobre lo que pasaba.

Aunque ese párrafo no transmite una idea de la confusión reinante, seguro que pueden hacerse una idea aproximada. Naturalmente, como pasa en muchas organizaciones, los técnicos del departamento van «de cráneo» y con solucionar el trabajo que les llega tienen más que suficiente, pero el no tener una información relacionada con el incidente hizo que a nivel interno (y personal) empezará a solicitar algunos datos.

El primer paso que se tomó (conjuntamente con el jefe del servicio técnico que estaba contratado) era consultar con los técnicos, los cuales a regañadientes y entre muchas llamadas nos aseguraron que no sabían por que había pasado y que tenían mucho trabajo como para pararse a investigar (¡!) .

El segundo paso fue evaluar la situación: qué había pasado. Y lo que vimos es que se habían perdido cientos de archivos y los servidores presentaban un aspecto a medio configurar, a la vista de la jerarquía de directorios y fechas de los archivos. Mientras se procedía a su restauración y configuración evaluamos que ‘sólo’ se había accedido a información del correo de toda la empresa. Debido al no conocimiento de la causa y la importancia del tema, se elevó la criticidad del asunto y se puso en conocimiento del Director de Sistemas, tras lo que se abrió una investigación capitaneada por el narrador de estas líneas y el jefe del servicio técnico externo.

Paso 1: Determinar el estado del resto de servidores de la empresa. Tras evaluar el resto de aplicaciones y servidores no vimos que hubiera más datos afectados.

Paso 2: Inicio de la investigación forense (si es que se le puede denominar así a lo que hicimos). Antes de nada, como en toda novela barata de detectives, hicimos nuestros propios comentarios e hipótesis al borde de un café; qué mejor lugar. Hoy recuerdo aquello como una situación bastante desordenada. La primera cuestión fue cómo comenzar, así que decidimos hacerlo por la procedencia del potencial atacante; las vías de acceso a los servidores eran o bien desde dentro, o bien desde el acceso externo mediante una conexión por VPN; era necesario determinar el tramo horario de acceso.

Puesto que éramos autónomos en el aspecto técnico comenzamos a investigar por nuestra cuenta sacando todos los accesos del registro de sucesos de Windows, que uno de los técnicos nos proporcionó en formato ‘legible’. Pese a que por cuestiones de memoria no puedo reproducir dichos accesos (fue hace ya sus casi seis años), pudimos observar que en uno de los servidores había accesos nocturnos en un horario no habitual y por parte de un usuario no determinado.

Pero habían dos servidores implicados, y esto sólo pasaba en uno de ellos. Inexplicablemente, el segundo servidor no presentaba estas entradas, aunque la auditoria estaba activa. Fue entonces cuando decidimos mirar en otro tramo horario en dicho servidor, y encontramos que el registro había sido manipulado.

Con dichas evidencias la cosa cambiaba, ya que era una prueba evidente de que se estaba intentando encubrir una manipulación, intrusión o ataque; llámenlo como quieran. En ningún momento dejamos volar la imaginación hacia una intrusión externa (tal vez si en un principio, pero no de forma realista) ya que estadísticamente el 90% de los ataques de seguridad proceden de fuentes internas, y porque una persona técnicamente capaz de realizar dicha intrusión con las medidas de seguridad que teníamos implantadas hubiera sido mucho más cuidadoso y no habría dejado las cosas así de feas. Dicho de otra forma, la situación solo podía estar entre dos opciones: o era uno de los técnicos especializados del servicio o era un intruso con un conocimiento y habilidad técnica muy grande, pero al mismo tiempo un auténtico chapuzas.

Por tanto, puesto que no teníamos demasiadas dudas de la procedencia interna, desde ese momento cualquier persona con capacidad técnica (exceptuándonos a nosotros mismos) estaba en tela de juicio, incluso aquellos técnicos a los que habíamos pedido ayuda y con los que habíamos comentado estos aspectos. En ese momento, reunimos a los cinco técnicos y se les informó del avance de la ‘investigación’, lo que como es natural no produjo resultado alguno. Todos negaron rotundamente su posible implicación. Para entonces ya había pasado un día y medio; la situación de los sistemas era estable pero la de los técnicos era más bien inestable, ya que se sentían ‘observados’ por nosotros.

Acorralando al amigo (enemigo)

Debido a que el acceso había sido nocturno, decidimos obtener los accesos desde el exterior a partir de los logs del firewall, de la VPN y el servidor de acceso, lo que mostró que el usuario con el que se había accedido era uno genérico de administrador. La IP desde donde se accedió tardarían algún tiempo en obtenerla, pero para entonces habíamos resuelto el caso, cual Sherlock Holmes y Hércules Poirot.

El jefe del servicio técnico me indicó que le permitiera actuar con algunos de los técnicos más experimentados por su cuenta, y tras varias reuniones de estos por separado, uno de ellos se derrumbó y confesó.

¿Qué pasó y por qué no lo contó? El técnico había estado trabajando toda la noche para resolver una incidencia, pero con el volumen de trabajo que tenía y conexiones a multitud de sistemas, sin darse cuenta se equivocó de servidor al realizar unos cambios. Intentó arreglarlo, pero no supo cómo, así que por miedo a represalias pensó que al día siguiente podría ‘tapar’ el incidente y resolverlo, y seguir trabajando sin mayor problema. Como es obvio, su forma de taparlo no fue la más elegante ni inteligente, pero mucha gente habría actuado de forma similar al darse cuenta de lo que acababa de hacer; el que más y el que menos ha tenido esa sensación de sudor frío en algún momento de su carrera como técnico. Poco tiempo después dicho técnico abandonó nuestras instalaciones, ya que aunque se le había dado el comodín del público por nuestra parte, su responsable no se lo dio.

Lo más impactante de todo fue descubrir que el técnico que había estado proporcionando los datos era el mismo que había generado el incidente, y que había hecho gala de una ingeniería social que le permitió saber en cada momento cual era el estado y las hipótesis que manejábamos.

Conclusiones

De ese hecho, que he resumido en unas pocas líneas aquí, aprendí lo curiosa que es la personalidad humana, y me di cuenta de que aunque ponemos todos los medios tecnológicos para preservar nuestra seguridad, nos olvidamos de la concienciación de los usuarios y del personal interno, así como de la falta de procedimientos ágiles y de figuras relacionadas con la seguridad y la investigación de incidentes de seguridad.

* * *

(N.d.E) En relación con la historia que acaban de leer, confesaré que hace ya algunos años, en mi etapa profesional anterior, descubrí que las Sun Sparc 3500 con doble controladora de disco (disculparán que no recuerde los detalles técnicos exactos) muestran con format el doble de discos de los que en realidad tiene la máquina. Intenten pensar qué pasa cuando reparticionas un disco de una máquina en funcionamiento, y qué ocurre cuando pasas tres días metido en una sala de servidores, a la temperatura de una sala de servidores. En mi defensa diré que de habérseme permitido reparticionar de nuevo los discos con su configuración original (que tenía guardada), me juego un brazo a que el sistema habría vuelto a funcionar sin apenas molestias. Pero alguien lo reinició manualmente… y ahí es donde comenzó la ‘diversión’.

Claro que, continuando con las historias de miedo, a un técnico que conocí en aquella época, para cambiar los permisos de acceso de varios ficheros que comenzaban por punto, no se le ocurrió otra idea mejor que ejecutar un chmod -R XXX .* (no recuerdo los permisos, de ahí las tres ‘X’), lo que llevó literalmente a cambiar los permisos de toda la máquina. Las consecuencias tampoco son difíciles de imaginar.

Pasando a la encuesta de la semana pasada, las respuestas están más o menos distribuidas, aunque parece que hay consenso en una cuestión: el programador no tiene la culpa. Lo que quiere decir que, o la mayoría de los participantes son programadores, o es que se interpreta que no aplicar técnicas de programación segura no es culpa suya sino de la falta de formación en seguridad, de lo que no son responsables al menos de manera directa.

[poll id=»10″]

Para la semana que viene, les invito a contestar a la siguiente encuesta, relacionada con las consecuencias reputacionales que pueden tener diversos problemas de seguridad para una empresa de cierto tamaño:

[poll id=»11″]

Por lo demás, buen fin de semana a todos. Nos vemos el lunes, o el domingo si hay suerte.