Re: OT: Criptominador Outlaw en cuenta de usuario
El 26/10/23 a las 05:36, Camaleón escribió: El 2023-10-25 a las 15:34 -0300, JavierDebian escribió: Buenas tardes. Hace un par de años fui víctima de Outlaw's https://www.trendmicro.com/en_us/research/19/f/outlaw-hacking-groups-botnet-observed-spreading-miner-perl-based-backdoor.html (...) ¿Alguien tiene idea de dónde se esconde el maldito gusano? Porque he revisado TODO (bashrc y los etcéteras que se les ocurran) y no encuentro un script o algo que lo lance. Y a nivel WEB, no encuentro nada nuevo, todo del 2020/2021. En la página que mandas de Trendmicro algo dicen: Routine Our data shows that the malware gains access to the system with brute-force attacks via SSH and executes two possible command files. Components of the file and routine appear similar to those of a published entry, while our sample executed .x15cache, the bash script that downloads the malware. (...) The shell script downloads, extracts, and executes the miner payload. The extracted TAR file contains folders with scripts and the miner and backdoor components. También en esta otra de Microsoft que enlazan desde la anterior: https://www.microsoft.com/en-us/security/blog/2019/05/23/uncovering-linux-based-cyberattack-using-azure-security-center/ After the initial successful SSH brute force compromise, the attacker proceeds to download a first stage ‘tddwrt7s.sh’ script using utilities like ‘wget’ that delivers further payload to the host. Azure Security Center surfaces this behavior via a “Detected suspicious file download” alert. Post stage 1 download, the attacker executed the script to find ‘dota.tar.gz’ by enumerating multiple hosting URLs. Once a live hosting IP was found, the second stage file gets delivered in directory ‘/tmp/.mountfs.’ Most of these exploitation and persistence techniques are observed from the /tmp folder. In this case all activities were tracked under /tmp/.mountfs and /tmp/.mountfs/.rsync directories. Creating directories with a dot keeps the activity hidden from the user interface, a common technique used by attackers. Saludos, Estoy presumiendo que el problema vino por allí, que hace dos años me hackearon, y guardaron la clave en algún bot. Asociado a mi dirección No-IP. Justamente, hace cosa de un par de meses, mi ISP me cambió el módem-router. E hice una chambonada: dejé el puerto 22 abierto directo al 22 de la PC. Ayer lo cambié a otro más alto que sólo tiene sentido para mí redireccionado a la PC. Espero haya sido eso solamente. Estoy verificando día a día. JAP
Re: Vulnerabilidad CVE-2021-25216 (libdns-export1104 y libisc-export1100)
El jue, 26-10-2023 a las 13:56 +0200, Usuario Lista escribió: > Nada. > El sistema me dice que no tiene nada que limpiar. > > Estoy por escribir en la lista de Wazuh y ver si es algo del SIEM. De todos modos, si estás en boockworm, puedes probar a hacer un apt remove sobre esas librerias antiguas y eliminarlas. Un saludo
Re: Vulnerabilidad CVE-2021-25216 (libdns-export1104 y libisc-export1100)
Nada. El sistema me dice que no tiene nada que limpiar. Estoy por escribir en la lista de Wazuh y ver si es algo del SIEM. Gracias. El mié, 25 oct 2023 a las 16:31, Listas () escribió: > > El mié, 25-10-2023 a las 15:43 +0200, Camaleón escribió: > > El 2023-10-25 a las 14:46 +0200, Julio Herrero escribió: > > > > > > > > Esos paquetes libdns-export* y libisc-export* no me aparecen en los > > > repositorios de Debian de mi sistema, que son los oficiales. > > > > > > $ apt search libisc-export > > > Ordenando... Hecho > > > Buscar en todo el texto... Hecho > > > $ > > > $apt search libdns-export > > > Ordenando... Hecho > > > Buscar en todo el texto... Hecho > > > $ > > > $ dpkg -l|grep libdns > > > $ dpkg -l|grep libisc > > > $ > > > > Están... son de Debian Buster. > > > > https://packages.debian.org/buster/libdns-export1104 > > https://packages.debian.org/buster/libisc-export1100 > > > Efectivamente, me di cuenta después de mandar el correo. Son de > versiones anteriores a la estable actual de Debian. > > De todos modos, la versión de bind9 que indica el Op se corresponde con > la actual estable, bookworm, por lo que supongo que esas librerías > serán algún resto de alguna actualización. Si es así se pueden eliminar > esas y otros posibles restos. Con apt autoremove --purge se eliminarán > esos restos. > > Un saludo > >
Re: OT: Criptominador Outlaw en cuenta de usuario
El 2023-10-25 a las 15:34 -0300, JavierDebian escribió: > Buenas tardes. > > Hace un par de años fui víctima de Outlaw's > > https://www.trendmicro.com/en_us/research/19/f/outlaw-hacking-groups-botnet-observed-spreading-miner-perl-based-backdoor.html (...) > ¿Alguien tiene idea de dónde se esconde el maldito gusano? > > Porque he revisado TODO (bashrc y los etcéteras que se les ocurran) y no > encuentro un script o algo que lo lance. > Y a nivel WEB, no encuentro nada nuevo, todo del 2020/2021. En la página que mandas de Trendmicro algo dicen: Routine Our data shows that the malware gains access to the system with brute-force attacks via SSH and executes two possible command files. Components of the file and routine appear similar to those of a published entry, while our sample executed .x15cache, the bash script that downloads the malware. (...) The shell script downloads, extracts, and executes the miner payload. The extracted TAR file contains folders with scripts and the miner and backdoor components. También en esta otra de Microsoft que enlazan desde la anterior: https://www.microsoft.com/en-us/security/blog/2019/05/23/uncovering-linux-based-cyberattack-using-azure-security-center/ After the initial successful SSH brute force compromise, the attacker proceeds to download a first stage ‘tddwrt7s.sh’ script using utilities like ‘wget’ that delivers further payload to the host. Azure Security Center surfaces this behavior via a “Detected suspicious file download” alert. Post stage 1 download, the attacker executed the script to find ‘dota.tar.gz’ by enumerating multiple hosting URLs. Once a live hosting IP was found, the second stage file gets delivered in directory ‘/tmp/.mountfs.’ Most of these exploitation and persistence techniques are observed from the /tmp folder. In this case all activities were tracked under /tmp/.mountfs and /tmp/.mountfs/.rsync directories. Creating directories with a dot keeps the activity hidden from the user interface, a common technique used by attackers. Saludos, -- Camaleón
Re: faillock ante ataques de fuerza bruta
El 2023-10-25 a las 22:07 +0200, Roberto Leon Lopez escribió: > En Debian 12 está el paquete libpam-modules-bin la utilidad faillock y su > módulo pam_faillock.so, al leer su página man no declara ninguna advertencia > porque podemos dejar el sistema totalmente bloqueado para acceder con > cualquier cuenta y es algo muy normal que pase al colocar las dos siguiente > líneas: > > auth [default=die] pam_faillock.so authfail > auth sufficient pam_faillock.so authsucc > > En /etc/pam.d/login o en /etc/pam.d/common-auth. > > ¿Me pueden dar alguna recomendación o alternativa al respecto? Bueno, para eso sirven los equipos de prueba :-) Para probar cosas (configuraciones, apliiaciones, etc...) antes de introducirlas en producción. Las máquinas virtuales vienen muy bien precisamente para esto. En cuanto a la pregunta, en principio ese tipo de módulos no debería afectar al usuario root, salvo configuración expresa (even_deny_root), en las páginas del manual tendrás más información. https://manpages.debian.org/bookworm/libpam-modules/pam_faillock.8.en.html https://manpages.debian.org/bookworm/libpam-modules/faillock.conf.5.en.html Saludos, -- Camaleón
Re: faillock ante ataques de fuerza bruta
> El 25 oct 2023, a las 22:46, Listas escribió: > > El mié, 25-10-2023 a las 22:07 +0200, Roberto Leon Lopez escribió: >> En Debian 12 está el paquete libpam-modules-bin la utilidad faillock >> y su módulo pam_faillock.so, al leer su página man no declara ninguna >> advertencia porque podemos dejar el sistema totalmente bloqueado para >> acceder con cualquier cuenta y es algo muy normal que pase al colocar >> las dos siguiente líneas: >> >> auth [default=die] pam_faillock.so authfail >> auth sufficient pam_faillock.so authsucc >> >> En /etc/pam.d/login o en /etc/pam.d/common-auth. >> >> ¿Me pueden dar alguna recomendación o alternativa al respecto? > > Pues en principio solo debería bloquear la cuenta que tuvo los intentos > de login incorrectos. También, por defecto, esas cuentas se desbloquean > a los 10 minutos. Mientras se hacen pruebas se puede disminuir ese > valor en /etc/security/faillock.conf > > Un saludo > Te explico en más detalle. En Debian 12 lees la página `man pam_faillock` y te habla del fichero /etc/pam.d/login, aunque en los ejemplos del final es /etc/pam.d/config, donde escribir las siguientes líneas: auth [default=die] pam_faillock.so authfail auth sufficient pam_faillock.so authsucc Pero si vas al fichero /etc/pam.d/login aparecen muchas entradas de tipo service y en medio encuentras: # Standard Un*x authentication. @include common-auth Si pones las dos líneas de pam_faillock antes o después se produce un bloqueo que no deja hacer login ni con root. Tendría que cambiar el fichero /etc/pam.d/common-auth y asegurarte colocar las líneas de faillock después de: auth[success=1 default=ignore] pam_unix.so nullok Y no olvidar que si llamas a pam-auth-update puedes borrar todos los ficheros common-* y vuelve a su estado original. Lo que más me escama es la situación de bloqueo total del sistema.
