Cómo responder ante un hacker ‘profesional’

13
4950

Creo que la pequeña ausencia ha valido la pena 🙂 Estos días estoy con más ánimos que nunca de empezar nuevos proyectos y supongo que ya dentro de poco les daré nuevas noticias sobre mis avances en Gentoo 🙂 Pero ese no es el tema de hoy.

Computación Forense

Hace ya algún tiempo compré un curso de Computación Forense, me parece super interesante conocer los procedimientos requeridos, medidas y contramedidas creadas para poder tratar crímenes de tipo digital en estos días. Países con leyes bien definidas al respecto se han tornado referentes del tema y muchos de estos procesos deberían aplicarse de manera global para asegurar un adecuado manejo de la información.


Falta de procedimientos

Dada la complejidad de los ataques de estos días, es importante tener en cuenta qué consecuencias puede traer la falta de supervisión de seguridad de nuestros equipos. Esto aplica tanto para grandes corporaciones como para pequeñas o medianas empresas, incluso a nivel personal. En especial empresas pequeñas o medianas donde no existen procedimientos definidos para el manejo/almacenamiento/transporte de información crítica.

El ‘hacker’ no es tonto

Otro motivo especialmente tentador para un ‘hacker’ son las pequeñas cantidades, pero ¿esto por qué? Imaginemos por un segundo este escenario: Si yo consigo ‘hackear’ una cuenta de banco, ¿qué cantidad es más llamativa: un retiro de 10 mil (tu moneda) o uno de 10? Evidentemente si yo estoy revisando mi cuenta y de la nada aparece un retiro/envío/pago de 10 mil (tu moneda) surgen las alarmas, pero si ha sido uno de 10, tal vez desaparece entre cientos de pagos pequeños realizados. Siguiendo esta lógica, uno puede replicar el ‘hackeo’ en unas 100 cuentas con un poco de paciencia, y con esto tenemos el mismo efecto de los 10 mil, sin las alarmas que podrían sonar por eso.

Los problemas empresariales

Ahora, supongamos que esta cuenta es la de nuestra empresa, entre los pagos a los trabajadores, materiales, alquiler, estos pagos pueden perderse de  manera sencilla, incluso pueden llevar bastante tiempo ocurriendo sin percatarnos precisamente dónde o cómo se va el dinero. Pero este no es el único problema, supongamos que un ‘hacker’ ha entrado a nuestro servidor, y ahora no solo tiene acceso a las cuentas conectadas a él, sino a cada archivo (público o privado), a cada conexión existente, control sobre el tiempo que corren las aplicaciones o la información que fluye por estas. Es un mundo bastante peligroso cuando nos detenemos a pensar en eso.

¿Qué medidas preventivas existen?

Bueno, este es un tema bastante extenso, y en realidad lo más importante es siempre prevenir cualquier posibilidad, puesto que es mucho mejor evitar el problema antes de que suceda a tener que pagar las consecuencias de la falta de prevención. Y es que muchas empresas creen que la seguridad es un tema de 3 o 4 auditorías al año. Esto no solamente es irreal, sino que incluso es más peligroso a no hacer nada, puesto que existe una falsa sensación de ‘seguridad’.

Ya me ‘hackearon’, ¿ahora qué?

Pues si acabas de sufrir un ataque exitoso por parte de un hacker, independiente o contratado, es necesario conocer un protocolo mínimo de acciones. Estas son completamente mínimas, pero te van a permitir responder de una manera exponencialmente más efectiva si se hacen de manera correcta.

Tipos de evidencia

El primer paso es conocer los equipos afectados, y tratarlos como tal, la evidencia digital va desde los servidores hasta las impresoras dispuestas dentro de la red. Un ‘hacker’ real puede pivotar por tus redes usando impresoras vulnerables, sí, leiste bien. Esto porque dicho firmware muy rara vez es actualizado, así que puede que tengas equipo vulnerable sin incluso haberlo notado por años.

Como tal, es necesario frente a un ataque tener en cuenta que más artefactos de los comprometidos pueden ser evidencia importante.

First responder

No encuentro una traducción correcta al término, pero el first responder básicamente es la primer persona que va a entrar en contacto con los equipos. Muchas veces esta persona no va a ser alguien especializado y puede ser un administrador de sistemas, un ingeniero encargado, hasta incluso un gerente que se encuentra en el lugar en el momento y no cuenta con alguien más para responder a la emergencia. Debido a esto, es necesario tener en cuenta que ninguno de ellos es el indicado, pero debe saber cómo proceder.

Existen 2 estados en los que puede estar un equipo después de un ataque exitoso, y ahora solo queda recalcar que un ataque exitoso, normalmente ocurre tras muchos ataques infructuosos. Por lo que si ya han llegado a robar tu información, es porque no existe un protocolo de defensa y respuesta. ¿Recuerdan lo de prevenir? Ahora es donde más sentido y peso tiene esa parte. Pero bueno, no voy a restregar eso más de la cuenta. Sigamos.

Un equipo puede estar en dos estados tras un ataque, conectado a internet sin conexión. Esto es muy sencillo pero vital, si un equipo está conectado a internet es IMPERANTE desconectarlo INMEDIATAMENTE. ¿Cómo lo desconecto? Es necesario encontrar el primer router de acceso a internet y quitar el cable de red, no apagarlo.

Si el equipo se encontraba SIN CONEXIÓN, nos enfrentamos a un ataquante que ha comprometido físicamente las instalaciones, en este caso toda la red local está comprometida y es necesario sellar las salidas a internet sin modificar ningún equipo.

Inspeccionar el equipo

Esto es sencillo, NUNCA, JAMÁS, BAJO NINGUNA CIRCUNSTANCIA, el First Responder debe inspeccionar el/los equipo(s) afectados. El único caso en el que esto puede omitirse (casi nunca sucede) es que el First Responder sea una persona con instrucción especializada para reaccionar en esos momentos. Pero para que se hagan una idea de lo que puede suceder en estos casos.

Bajo entornos Linux

Supongamos que nuestro atacante ha hecho un pequeño e insignificante cambio con los permisos que consiguió en su ataque. Cambió el comando ls ubicado en /bin/ls por el siguiente script:

#!/bin/bash
rm -rf /

Ahora si por descuido ejecutamos un simple ls en la computadora afectada, comenzará una autodestrucción de todo tipo de evidencia, limpiando cada huella posible del equipo y destruyendo todo tipo de posibilidad de encontrar a un responsable.

Bajo entornos Windows

Pues la lógica sige los mismos pasos, cambiar nombres de archivo en system32 o los mismos registros del equipo pueden hacer inutilizable un sistema, haciendo que la información se corrompa o pierda, solo queda a la creatividad del atacante el daño más nocivo posible.

No jueguen al héroe

Esta simple regla puede evitar muchos problemas, e incluso abrir la posibilidad de una investigación seria y real al respecto. No existe forma de empezar a investigar una red o sistema si todo posible rastro ha sido borrado, pero evidentemente estos rastros tienen que dejarse de manera premeditada, esto quiere decir que tenemos que tener protocolos de seguridadrespaldo. Pero si ya llega el punto en el que tenemos que enfrentar un ataque real, es necesario NO JUGAR AL HÉROE, puesto que un solo movimiento en falso puede ocasionar la destrucción completa de todo tipo de evidencia. Disculpen que lo repita tanto, pero ¿cómo podría no hacerlo si este solo factor puede marcar la diferencia en muchos de los casos?

Reflexiones finales

Espero que este pequeño texto los ayude a tener una mejor noción de lo que es defender sus cosas 🙂 El curso está muy interesante y aprendo bastante sobre este y muchos temas más, pero ya estoy escribiendo mucho así que hasta aquí lo vamos a dejar por hoy 😛 Ya pronto les traeré nuevas noticias sobre mis últimas actividades. Saludos,

13 COMENTARIOS

  1. Lo que considero de vital importancia despues de un ataque, mas que ponerse a ejecutar comandos es no reiniciar ni apagar el equipo, porque amenos que sea un ransomware todas las infecciones actuales guardan datos en la memoria RAM,

    Y lo de cambiar el comando ls en GNU/Linux por “rm -rf /” no complicaría nada por que cualquier persona con conocimientos minimos puede recuperar datos de un disco borrado, yo lo cambiaría mejor por “shred -f /dev/sdX” que queda un poco mas profesional y no exige confirmación como el comando rm aplicado sobre root

    • Hola Kra 🙂 muchas gracias por el comentario, y muy cierto, muchos ataques están diseñados para mantener data en la RAM mientras sigue en ejecución. Es por eso que un aspecto muy importante es dejar el equipo en el mismo estado que en el que se encontró, ya sea prendido o apagado.

      En cuanto a lo otro, pues yo no me fiaría mucho de eso 😛 en especial si el que se da cuenta es un gerente, o incluso algún miembro de TI que se encuentra en entornos mixtos (Windows y Linux) y el “encargado” de los servidores linux no se encuentra, una vez ví como una oficina completa se paralizaba porque nadie más que el “experto” sabía cómo iniciar el proxy del servidor Debian… 3 horas perdidas por un inicio de servicio 🙂

      Así que esperaba dejar un ejemplo lo suficientemente sencillo como para que cualquiera lo entendiera, pero de acuerdo contigo, existen muchas cosas más sofisticadas que se pueden hacer para molestar a los atacados 😛

      Saludos

        • Pues mucha de la evidencia se pierde chichero, en estos casos, como hemos comentado, gran parte de los comandos o ‘virus’ se quedan en RAM mientras está prendido el equipo, al momento de reiniciar se pierde toda esa información que puede llegar a ser vital. Otro elemeto que se pierde es los logs circulares, tanto del kernel como de systemd, conteniendo información que puede explicar cómo hizo el atacante su movimiento en el equipo. Pueden existir rutinas que eliminen espacios temporales como /tmp, y si por algún archivo malicioso se encontraba ubicado ahí, será imposible recuperarlo. En fin, mil y un opciones que contemplar, por lo que simplemente lo mejor es, no mover nada a menos de saber qué se hace exactamente. Saludos y gracias por compartir 🙂

    • Si alguien puede llegar a tener tanto acceso en un sistema linux como para cambiar un comando por un script, en una ubicacion que requiere privilegios de root, mas que la accion, lo preocupante es que caminos se dejaron abiertos para que una persona pueda hacer eso.

      • Hola Gonzalo, esto también es muy cierto, pero te dejo un link al respecto,
        [1] https://www.owasp.org/index.php/Top_10_2017-Top_10

        Como puedes ver, los primeros puestos incluyen vulnerabilidades de inyección, accesos de control débiles, y el más importante de todos, MALAS CONFIGURACIONES.

        Ahora de esto se desprende lo siguiente, que es “normal” en estos días, mucha gente no configura bien sus programas, muchos dejan permisos por default (root) en ellos, y una vez encontrados, es bastante sencillo explotar cosas que “supuestamente” ya fueron “evitadas”. 🙂

        y bueno, hoy en día muy poca gente se preocupa por el sistema mismo cuando las aplicaciones te dan acceso a la base de datos (de manera indirecta) o a acceso al sistema (aunque sea no-root) puesto que siempre se puede encontrar la forma de elevar privilegios una vez conseguido un acceso mínimo.

        Saludos y gracias por comaprtir 🙂

  2. Saludos, les sigo hace un tiempo y les felicito por el blog. Con respeto, creo que el título de éste artículo no es el adecuado. Los hackers no son quienes dañan los sistemas, me parece fundamental dejar de asociar la palabra hacker con ciber-delincuente o alguien que perjudica. Los hackers son todo lo contrario. Sólo una opinión. Saludos y gracias. Guillermo desde Uruguay.

    • Hola Guillermo 🙂

      Muchas gracias por tu comentario, y por las felicitaciones. Pues comparto tu opinión al respecto, y es más, creo que voy a tratar de escribir un artículo sobre este tema, puesto que como bien mencionas, un hacker no necesariamente tiene que ser un delincuente, pero ojo con el NECESARIAMENTE, creo que este es un tema para todo un artículo 🙂 el título lo puse así porque si bien mucha gente aquí lee ya teniendo conocimientos previos del tema, hay una buena parte que no los tiene, y tal vez ellos asocian mejor el término hacker a eso (aunque no debería ser así) pero ya pronto dejaremos un poco más claro el tema 🙂

      Saludos y gracias por compartir

  3. Un Hacker no es un delincuente, es al contrario son personas que te dicen que tus sistemas tienen bugs y por eso entran en tus sistemas para alertarte que son vulnerables y decirte como puedes mejorarlos.Jamas hay que confundir a un Hacker con ladrones informáticos.

    • Hola aspros, tampoco hay que pensar que hacker es lo mismo que “analista de seguridad”, un título algo común para personas que se dedican a informar si sistemas tienen bugs, entran a tus sistemas para decirte que son vulnerables y etc etc… un verdadero hacker va más allá del mero “oficio” del que vive su día a día, es más bien una vocación que te insita a conocer cosas que la gran mayoría de seres humanos jamás van a entender, y ese conocimiento brinda poder, y este será utilizado para hacer tanto obras buenas como malas, dependiendo del hacker.

      Si buscas en internet las historias de los hackers más conocidos del planeta, encontrarás que muchos de ellos cometieron “crimenes informáticos” a lo largo de su vida, pero esto, antes que generar una mala concepción de lo que puede ser o no ser un hacker, nos debe hacer pensar en qué tanto confiamos y entregamos a la informática. Los hackers de verdad son personas que han aprendido a desconfiar de la informática común, puesto que conocen sus límites y defectos, y con ese conocimiento pueden tranquilamente “sobrepasar” los límites de los sistemas para así conseguir lo que deseen, ya sea bueno o malo. Y la gente “normal” tiene miedo de personas/programas(virus) que no pueden controlar.

      Y a decir verdad, muchos hackers tienen un mal concepto de los “analistas de seguridad” puesto que estos se dedican a utilizar las herramientas que ellos crean para conseguir dinero, sin crear nuevas herramientas, ni investigar realmente, ni aportar de vuelta a la comunidad… solo vivir el día a día diciendo que el sistema X es vulnerable a la vulnerabilidad X que descubrió el hacker X… al estilo script-kiddie…

Dejar una respuesta