hackeado

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.

 

Fuente: desdelinux

¿Quién está en línea?

Hay 14578 invitados y ningún miembro en línea