Ransomware infecta a compañías a través de RDP

En Uruguay una búsqueda rápida en shodan nos da que puede haber más de 2000 equipos vulnerables (Equipos Windows), lo que demuestra una vez más la falta de conciencia en la seguridad de las redes y los datos.

Posibles afectados por ransomware via RDP expuesto en Uruguay

Los atacantes armados con ransomware buscan vulnerar a empresas a través de un hoyo encontrado comúnmente en los mal asegurados servidores de escritorio remoto visibles desde Internet de la red de las organizaciones.

Según Wouter Jansen, especialista forense en TI de Fox-IT, la compañía ha sido llamada últimamente por una serie de empresas que se han visto afectadas con ransomware, y un subconjunto de estas ha dejado que los atacantes y el ransomware entren a través del canal mostrado en la imagen:

“Las entradas en los archivos de bitácoras muestran que los atacantes consiguieron acceso a los servidores mediante ataques de fuerza bruta a usuarios y contraseñas en los servidores de escritorio remoto visibles desde Internet. Día tras día, los intentos fallidos de inicio de sesión que se registran provienen de cientos de direcciones IP únicas probando cientos de nombres de usuario únicos”, señaló Jansen. “Después de atacar a las credenciales por fuerza bruta para obtener acceso a un servidor de escritorio remoto, los atacantes pueden hacer cualquier cosa en el servidor o la red con los permisos que tenga la cuenta de usuario comprometida.”

En el pasado eso significaba que los atacantes, en general, intentaban obtener datos que pudieran vender en el mercado negro, añadir al sistema comprometido a una red de bots o usarlo para enviar correos electrónicos no deseados. Sin embargo, algunos de los atacantes han cambiado al uso de ransomware en un esfuerzo para obtener ganancias forma rápida y evitar complicaciones posteriores.

“Dependiendo de la segmentación y segregación de la red, el impacto del ransomware que se ejecuta desde una estación de trabajo en un cliente de la LAN puede estar limitado a los segmentos de red y recursos compartidos de la estación de trabajo y los que la cuenta de usuario afectado puede alcanzar. Desde un servidor, sin embargo, un atacante podría ser capaz de encontrar y llegar a otros servidores y cifrar los datos críticos de la empresa para aumentar el impacto”, señaló Jansen.

Los atacantes también pueden tratar de descubrir cuándo se llevan a cabo las copias de seguridad con el fin de decidir cuándo ejecutar el ransomware para obtener la máxima eficacia. Por lo general son exitosos manteniendo oculta su presencia en la red corporativa hasta que desencadenan el malware.

Afortunadamente, este tipo de ataque puede ser fácilmente frustrado por los administradores. Hacer que el servidor de escritorio remoto sea inaccesible de forma remota no es posible, por lo que las cuentas de usuario con acceso remoto deben tener una contraseña compleja y difícil de adivinar, adicionalmente se puede implementar la autenticación de dos factores o la verificación de dos pasos y la conexión remota debe estar cifrada.

Fuente: Help Net Security RC

[ZIMBRA] Protegernos contra ataques DoS postfix AUTH

En un cliente tuvimos problemas ataques varios contra el servidor de correo Zimbra, aparte de problemas por weak passwords (decisiones gerenciales) y la costumbre de poner “123456” y “qwaszx12” que se rompen por diccionario fácilmente.

Luego de que tomaran conciencia de esto y mejorar mucho el manejo de claves igualmente seguimos sufriendo ataques constantes.

Usamos entre otras cosas fail2ban junto a zimbra desde hace algún tiempo ( [ZIMBRA] ENFRENTANDO EL SPAM CON FAIL2BAN )

Ultimamente aumentaron los ataques contra postfix y las reglas del fail2ban que usabamos no las filtraban

En el log se los ve así :

Apr 6 06:30:49 mail postfix/smtpd[00000]: connect from unknown[151.237.190.118]
Apr 6 06:30:49 mail postfix/smtpd[00000]: lost connection after AUTH from unknown[151.237.190.118]

Así que creamos las siguientes reglas en el fail2ban

1: Agregar esto al final de /etc/fail2ban/jail.local

[zimbra-auth-dos]
enabled = true
filter = zimbra-auth-dos
action =iptables-allports[name=Zimbra-auth-DoS]
logpath = /var/log/zimbra.log
ban= 600
retry=5

2: Crear el filtro /etc/fail2ban/filter.d/zimbra-auth-dos.conf

[Definition]
failregex = lost connection after AUTH from (.*)\[<HOST>\]
ignoreregex =

3: Reiniciar fail2ban y luego de 5 intentos los bloqueamos por 600s

 

 

Respaldo automático a disco USB

Si tenemos algun server o nuestro desktop de vez en cuando viene bien respaldarlo en un disco externo.

Una opcion facil y barata ( si no te dan $$$ para hacerlo como deberías) es usar un disco USB y que el respaldo se ejecute al conectarlo al puerto USB/Firewire.

Si bien no voy a explicar cómo encriptar los datos, esto sería deseable!!

Que necesitamos: GNU/Linux ( Debian/Ubuntu), Rsync, disco USB/FireWire

1: Setear udev

# dmesg
[ 1164.319347] scsi 8:0:0:0: Direct-Access TOSHIBA External USB 3.0 5438 PQ: 0 ANSI: 6
[ 1164.319746] sd 8:0:0:0: Attached scsi generic sg3 type 0
[ 1164.321741] sd 8:0:0:0: [sdc] 1953525164 512-byte logical blocks: (1.00 TB/931 GiB)
[ 1164.323140] sd 8:0:0:0: [sdc] Write Protect is off
[ 1164.323145] sd 8:0:0:0: [sdc] Mode Sense: 23 00 00 00
[ 1164.324014] sd 8:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1164.333037] sdc: sdc1
[ 1164.366188] sd 8:0:0:0: [sdc] Attached SCSI disk

Vemos que el disco que conectamos, ahora vamos a obtener la data para configurar el udev

# udevadm info -a -p $(udevadm info -q path -n /dev/sdc)
KERNELS=="8:0:0:0"
SUBSYSTEMS=="scsi"
DRIVERS=="sd"
ATTRS{model}=="External USB 3.0"
ATTRS{state}=="running"
ATTRS{vendor}=="TOSHIBA "

De todo los datos que nos larga, nos interesan esos 3 para que udev reconozca el disco al conectarlo, se pueden usar otros como el idVendor.

Ahora creamos un archivo en /etc/udev/rules.d con el nombre 50-backup2usb.rules, las reglas de usuario deben ser empiezan por 50.

# UDEV rules para respaldo automatico al conectar disco.
#   udevinfo -a -p $(udevinfo -q path -n /dev/sda)
KERNEL=="sd?1", ACTION=="add", SUBSYSTEMS=="scsi", ATTRS{vendor}=="TOSHIBA", ATTRS{model}=="External USB 3.0", RUN+="/path/script/respaldo2usb.sh %k"

Esto funciona así:

Cuando el kernel encuentra un disco sd?1 ( unica particion de tu disco USB) y está conectado en el subsystem SCSI y la marca es TOSHIBA y el modelo es “External USB 3.0”

entonces corre el script backup2usb.sh, el parámetro %k le pasa al script que el disco/partición es sdc1 ( si lo corres a mano al script debes agregarlo al final)

2: Bajar script y corregir paths

El script está disponible en: https://github.com/cristianmenghi/usbbackup

3: Testearlo

 

Espero que te sirva como a mi.

 

Shodan Creepy Stuff

Con un tiempo libre, me puse a jugar con Shodan y las cosas que puedes encontrar son interesantes ( como la cantidad de equipos afectados por DROWN en Uruguay)

Acá no estamos libres, me he encontrado con varias cosas de este tipo, algunas de reconocidas empresas de sistemas, es evidente la falta de cultura en seguridad de sistemas.

Algunos ejemplos:

Algo por china
Algo por China
en Singapure puntuas el toilet
en Singapure puntuas el toilet
Scada Analogico.
clock
Sera para el work from home?
creepy webcam
creepy webcam
creepy webcam
creepy webcam
monitoreo remoto
monitoreo remoto
algun scada ruso
algun scada ruso
scada noruego
scada noruego
planilla polaca
planilla polaca
login de la tienda
login de la tienda
Scada Turco
Scada Turco

 

 

[Zimbra] Deshabilitar IM

Para un cliente, en el cual corremos Zimbra desde hace muchos años surgió la necesidad de deshabilitar el IM para algunos usuarios, surge por el problema de la distracción de sus tareas al tenerlo habilitado.

Las formas para hacerlo, funciona en versiones 7.x o anteriores es y desde consola:

Para todo el dominio/COS especifico:

zmprov mc default zimbraFeatureIMEnabled FALSE
zmprov mc default zimbraFeatureInstantNotify FALSE
zmprov mc default zimbraPrefIMAutoLogin FALSE

Para un usuario especifico:

zmprov ma usur@domain.com zimbraFeatureIMEnabled FALSE
zmprov ma user@domain.com zimbraFeatureInstantNotify FALSE
zmprov ma user@domain.com zimbraPrefIMAutoLogin FALSE
Gracias Zimbra 😉

Hola Android Marshmallow flash time.

Siguiendo con la experimentación en mi celular Android, me dispuse a probar la preview 3 de Android Marshmallow (v6).

Luego de realizar el backup correspondiente y investigar el tema de root (imprescindible para mi) baje los archivos oficiales de google para mi celular y con mi anterior post sobre como flashear me puse manos a la obra.

Los pasos que seguí son los mismos, no quería (me daba pereza) hacer un factory reset y procedí con un dirty flash, que es realizar un cambio de rom si borrar los datos.

Inicia, todo lindo, anda casi todo… el botón home no responde.

Esto es un bug que sucede al realizar dirty flash pero hay una forma de que todo quede funcionando sin tener que hacer factory reset.

Correr el Setup Wizard nuevamente, en teoría se puede realizar desde terminal en el mismo celular, a mi no me funciono, así que manos a la obra desde la consola y con el adb actualizado.

adb shell am start -n com.google.android.setupwizard/.SetupWizardTestActivity

Esto nos lanza el setup en el celular, el cual realizados y magia! funciona nuevamente.

De momento, funciona… no perdí las apps y datos que tenia supongo que con el nuevo sistema de backups cuando pase a la versión final no tendría que haber inconvenientes en importar las configuraciones desde la nube.

Pizza as a Service

SAP publico un excelente gráfico realizado por un  Software Architect de IBM donde se presenta la analogía de los servicios en la nube como si de una Pizza se tratara, me pareció excelente esta explicación, sobre todo cuando estamos con una persona ajena a IT y debemos explicar que es cada cosa y donde quedan sus datos.

Me tome el atrevimiento de traducirlo, estuve tentado de hacer el ejemplo mas rio-platense ( Asado as a Service).

Pizza as a Service
Pizza as a Service

 

xaaS
xaaS

Protección contra el SCAM

Esta es una pequeña guía para evitar se víctima de un ataque basado en Ingeniería Social mediante uso del correo electrónico, pero no limitado a este. Los comentarios son bienvenidos.

Evite el uso de servidores de correo gratuito (Outlook, Gmail,Adinet,etc ) Estos están bien para un uso “domestico” pero no para una empresa. Establezca un dominio corporativo y que ese sea el canal de comunicación oficial de su organización.

Tenga cuidado con lo que publica en las redes sociales, incluso en su web institucional, sobre todo información especifica sobre una tarea/trabajo, información jerárquica detallada o simples “out-of-the-office” la ingeniería social hace uso intensivo de muchas fuentes de información y realiza inteligencia sobre la misma.

Desconfíe de solicitudes de confidencialidad/reserva o de realizar algún tipo de operación con mas celeridad de lo normal, sobre todo si esta operación es fuera de lo común.

Considere otras medidas de seguridad adicionales tanto a nivel de IT, Financieras o de autenticación/autorización. Incluya métodos de autenticación/autorización complementarios.
Tenga cuidado con los cambios bruscos en las prácticas organizacionales, si un cliente/socio pide de repente ser contactado a través de su dirección de correo electrónico personal cuando todo el intercambio se a realizado a travez de el correo corporativo, esta solicitud podría ser fraudulenta. Siempre verifique por otros canales que posea con su cliente/socio antes de realizar algún tipo de operación que sea fuera de lo normal.

Establecer otros canales de comunicación, tales como llamadas telefónicas/Videoconferencia, para verificar las operaciones delicadas y sensibles.
Trate de implementar otro método de autenticación para las operaciones fuera del correo electrónico.

Uso de Firmas electrónicas: Ambas lados de una transacción deberían utilizar firmas electrónica, estas pueden ser usadas para firmar o encriptar la información. Sin embargo, esto no funciona con muchos servicios de correo electrónico basados en la web.

Eliminar Spam: Tratar de eliminar inmediatamente correo electrónico no deseado (spam).
NO abra el correo electrónico no deseado (SPAM).
NO haga clic en los enlaces o abra archivos adjuntos de estos correos, a menudo contienen malware que podrían facilitar el acceso a sus sistemas o ser víctima de algún tipo de ataque.

Reenviar vs. Responder:
Es deseable que no utilice la opción “Responder” para responder a todos los correos electrónicos empresariales que puedan ser sensibles o tenga dudas sobre su origen, en su lugar utilice la opción de “Reenviar” y escriba la dirección de correo electrónico de la persona a contactar o seleccionela de la libreta de direcciones para garantizar que es la dirección correcta de su contacto.

Basado en recomendaciones del FBI para empresas

Android 5.1 a 5.1.1 en dispositivo Stock con root y recovery

Hace unos días GOOGLE publico las imágenes de fabrica para nuestros Nexus de Android 5.1.1. Como en mi post anterior puse los pasos para actualizar a la versión 5.1 y a instalarle el custom recovery para luego rootear y aplicar los mods que mas nos gusten, todo esto sin perder nuestros datos claro. El problema de estos pasos es que al notificarnos del OTA el dispositivo y querer realizarlo no podremos por tener el custom.

Para esto debemos recurrir a un equipo u seguir los siguientes pasos.

Bajar la imagen correspondiente de google. https://developers.google.com/android/nexus/images

Ir a la carpeta donde tenemos el adb y el fastboot y descomprimir todo allí, incluido lo que este dentro de image-hammerhead-lmy48b.zip

#adb reboot bootloader (o reiniciamos con bajar volumen al encenderlo)

#fastboot flash bootloader bootloader-hammerhead-hhz12h.img
#fastboot flash boot boot.img
#fastboot flash radio radio-hammerhead-m8974a-2.0.50.2.26.img
#fastboot flash system system.img
#fastboot flash cache cache.img

Colocarle nuevamente el custom recovery

#fastboot flash recovery archivo.img

(tip: colocarle el cwm en lugar del TWRP ya que no lo carga por alguna razón), reiniciar y copiarle el SuperSU, flashear y listo el root.

Actualizar Nexus a Lollipop 5.1

Hace unos días Google libero las imagenes de fabrica y el código de la version 5.1 de Android.

Como usuario que me encanta trastear con estas cosas y aprovechando el tiempo libre obligado que tuve me puse a hacer update de los dispositivos Nexus que tengo.

Uno de ellos como no tenia datos baje las imágenes de fabrica y lo flashee completamente, no tenia datos dentro de que preocuparme.

En cuanto al Celular si, no tenia ganas de respaldar o esperar la OTA, si bien podría haber cargado el OTA por sideload esta no me funciono, me dio error y pase a realizar el flasheo por medio de fastboot sin perder los datos.

Para esto baje la imágenes para mi dispositivo y extraerlos. Se debe tener instalado ADB y fastboot ( en la red se puede encontrar ambos sin necesidad de instalar todo el SDK)

Para hacer todo esto se debe tener el dispositivo con el bootloader unlocked, sin esto no hay vuelta y se pierden los datos.

Ponerlos en la carpeta donde este fastboot

Editamos los archivos flash-all.bat (Windows) o  flash-all.sh (*nix) y editamos la linea que dice:

fastboot update  -w image-hammerhead-lmy47d.zip

y quitamos la opcion “-w” (erase userdata and cache)

Con el celular conectado al equipo ejecutar

#adb kill-server
#adb usb
#adb restart-bootloader
#flash-all.sh (o ejecutamos los comandos a mano)

Luego de esto simplemente nos queda reiniciar esperar que se termine la generación de la cache de ART e instalar Custom recovery (me gusta TWRP), para hacerlo de nuevo reiniciar al bootloader y ejecutar

#fastboot flash recovery openrecovery-twrp-2.8.5.2-hammerhead.img

Después de esto ya podemos bajar superSU y rootear nuestro dispositivo y sin haber perdidos los datos. (por lo menos en mi caso)