Unhide 20121229 is out !

Finalmente y tras haber lanzado la beta con una gran respuesta a nivel descargas y feedback,  ¡tenemos la versión final de Unhide!

Para los mas ansiosos, se puede descargar desde aquí

La nueva versión trae bastantes cambios con respecto a la anterior versión (20110113)

Copio y pego el 'Changelog':

IMPORTANT

  - unhide-linux26.c was renamed to unhide-linux.c

  - unhide.c was renamed to unhide-posix.c

  - The log file of unhide-linux is renamed 'unhide-linux_AAAA-MM-DD.log'

  - The log file of unhide-tcp is named 'unhide-tcp_AAAA-MM-DD.log'

  - By default, unhide-tcp now use /sbin/ss from iproute2 package, to use netstat as before '-n' option must be given on command line.

  - Display is more verbose and multi-lines for hidden processes (unhide-linux).

  - If asked to (-l and/or -f), display is more verbose and multi-lines for hidden ports (unhide-tcp).

  - sysinfo test is no more called as part of compound quick and sys tests as it may give false positives.

    It could still be run using the checksysinfo, checksysinfo2 or checksysinfo3 command line parameter.

NEW FEATURES

  - Major enhancement of unhide-tcp :

    * Add capability to output a log file (unhide-tcp_AAA-MM-DD.log)

    * Add capability to output more information (via lsof and/or fuser) on hidden port if available

    * Add verbose mode (disabled by default) to display warning

    * Add a new method (via option '-s') very fast on system with huge number of opened ports

  * Make a double check of port access to avoid false positive (previous single check version is available as unhide-tcp-simple-check.c if needed).

  - Add a quick port in C language of unhide.rb (unhide_rb.c) and guess what ...it's 40 times faster than original ruby unhide.rb

    

Note: unhide_rb doesn't take any option.

  - Add "-d" option for doing a double check in brute test, this reduce false positives.

  - Add "-o" option as synonym of "-f".

  - For found hidden processes, display the user and the working directory as extracted from the process environment. Note that it doesn't work well for kernel processes/threads nor for deamons.

  - For found hidden processes, display cmdline, exe link and internal command name.

MISCELLANOUS

  - Add french and spanish man page for unhide-tcp

  - Update english manpage of unhide-tcp to reflect changes

  - Minor corrections in french manpage of unhide

  - Display copyright and license information in start banners.

  - Make message from sysinfo tests more clear.

  - Add a NEWS file :)

  - Update README.txt, LISEZ-MOI.txt and LEEME.txt to clarify difference between unhide-posix and unhide-linux.

  - Remove sysinfo test from quick and sys compound tests as it may give false positive.

sysinfo test still can be used via the checksysinfo[2|3] command line parameters.

BUG FIXES

  - Suppress pedantic compilation warnings (glibc >=2.3, gcc >=4.6).

  - Correct the number of processes displayed for /proc counting in sysinfo test.

[+] Página principal de Unhide (unhide-forensics.info)

Leer más...

Detectando la presencia de rootkits con Unhide

Por mucho que nos esforcemos en defender nuestras redes informáticas, en el momento que estas crecen, tanto en sistemas como en servicios, el riesgo de ser “visitados” por algún inquieto personaje asiduo a las listas de bugtraq armado con el último exploit publico.

Este tipo de personajes nada entiende de “horas valle”, sistemas de QA para aplicar parches en sistemas críticos y ese tipo de cosas tan poco obvias para quien no ha tenido que lidiar con ellas.

Por mucho que apliquemos el catenaccio a nuestra política de seguridad, siempre hay servicios y aplicaciones que exponer al exterior y que en algún momento de su ciclo de vida, serán victimas de alguna vulnerabilidad. Ante esa eventualidad resulta interesante disponer de un procedimiento para realizar auditorías forenses de forma mas o menos automatizada.

Una buena práctica resulta emplear herramientas de tipo Tripwire cuya misión es asegurar la integridad de los ficheros en el sistema. Tripwire es una herramienta comercial (con algunas versiones libres) pero existen alternativas totalmente libres (código fuente, sin coste) como por ejemplo Afick.

Aprovechando que acabo de publicar la ultima version de Unhide, en este Post me gustaría compartir con vosotros una pequeña descripción de como funciona.

Unhide es una herramienta destinada a identificar anomalías en sistemas Unix / Linux, lo hace identificando procesos y puertos tcp / udp ocultos, que suele ser síntoma inequívoco de la presencia de un rootkit en nuestro sistema.

A diferencia de otras soluciones más al estilo anti-virus, Unhide no emplea firmas y se basa en los conceptos del tipo “detección de anomalías” contrastando diferentes fuentes de información y buscando inconsistencias entre ellas.
El software se divide en tres herramientas :

unhide : Para sistemas Unix genéricos (solaris, *BSD, linux antiguos)

Esta herramienta realiza dos tipos de “checks” en el sistema:

• /bin/ps contra /proc : se basa en comparar la salida del comando /bin/ps contra las entradas del directorio /proc. Si encuentra una entrada en /proc y no encuentra su correspondiente proceso en /bin/ps marca esa PID como “pid oculta”

• /bin/ps contra syscalls: el objetivo de este test es intentar deducir si existe algún proceso oculto interrogando directamente al Kernel mediante syscalls y comparando su salida contra /bin/ps

unhide-linux26 : Para sistemas Linux kernel 2.6

Esta versión de unhide para sistemas linux modernos añade, ademas, otro método de detección consistente en “bruteforcear” el espacio de PIDs del sistema a base de múltiples forks() y comparar contra /bin/ps. Si el sistema, durante el proceso de forks(), no ha dado alguna PID que no aparece listada en /bin/ps es síntoma de que algo no marcha correctamente

unhide-tcp : Herramienta para detectar puertos TCP / UDP ocultos

Esta herramienta localiza puertos TCP o UDP que no aparecen listados en el comando netstat intentando realizar un bind() sobre el espacio de puertos disponibles en el sistema y compararlo contra netstat. Si un puerto en el que no se ha podido hacer bind() no aparece en netstat, ese puerto es cuanto menos, sospechoso

Para usar Unhide puedes descargarlo de la web y compilarlo de la siguiente forma (para compilar únicamente hace falta un gcc normalito) :

#gcc unhide-linux26.c -o unhide-linux26

#gcc unhide-tcp.c -o unhide-tcp

O bien, si eres usuario de Debian Sid / Lenny o Ubuntu puedes instalarlo directamente con apt-get

Para iniciar el scaneo de puertos ocultos únicamente debemos ejecutarlo de la siguiente forma:

#./unhide-tcp

Y para ejecutar los diversos checks de la herramienta unhide-linux26:

#./unhide-linux26 proc
#./unhide-linux26 sys
#./unhide-linux26 brute

Lo interesante sería ejecutar periódicamente la suite de herramientas en nuestros sistemas Unix como medida para detectar eventuales compromisos en el sistema.

Leer más...

Unhide 20121212-Beta is out !!

Ha pasado algún tiempo desde la última vez que se liberó una versión nueva de Unhide.

En todo este tiempo, lejos de estar parados, el proyecto ha sufrido una transformación muy notable. Muchas partes se han re-escrito totalmente y la mano de mi compañero Patrick se ha dejado notar mucho.

Además también han enviado parches Leandro Lucarella y François Boisson.

Esta versión, como decía al principio, ha sido re-escrita en un gran porcentaje, de hecho, unhide-tcp se podría decir que es nuevo.

Por eso, me encantaría que toda persona amante de Linux, administrador de sistemas o simple usuario, lo pudiera ver y probar para poder lanzar cuanto antes una versión estable a partir de esta beta.

Para compilar:

gcc -Wall -O2 --static -pthread unhide-linux*.c unhide-output.c -o unhide-linux

gcc -Wall -O2 --static unhide-tcp.c unhide-tcp-fast.c unhide-output.c -o unhide-tcp

Si obtienes algún tipo de error usando esa forma de compilar, elimina --static (en Fedora suele dar ese error)

Una vez compilado los comandos son:

unhide-linux 

unhide-tcp

Agradecería mucho que, en caso de encontrar algún fallo, problema, sugerencia, mejora, etc lo reportaseis en el bug tracker de SourceForge para que todos los miembros del equipo lo vean y puedan asignarle parches.

Podéis descargar la versión beta desde aquí

Y el bug tracker está aquí

¡¡ Muchas gracias a todos por la ayuda y el interés !!

Leer más...

Análisis de Jynx (Linux Rootkit)

Últimamente poco se había innovado en el campo de los Rootkits para sistemas Linux, muy atrás quedaron los tiempos en los que 'adore' (LKM) o 'SuckIT' (parcheo de la memoria en caliente) marcaban el paso en cuanto a rootkits para sistemas Linux.

Poco a poco el Kernel de Linux ha ido evolucionando y haciendo bastante mas compleja la labor de modificarlo para esos fines, así que actualmente la forma mas efectiva de instalar un rootkit en un sistema Linux es ir hacia la parte 'userland'

De esta clase de rootkits existen dos tipos, o bien los que cambian los típicos binarios del sistema asociados a obtener información (ps y amigos) y los rootkits más sofisticados que inyectan una librería en los procesos.

Desde hace tiempo han existido rootkits que actuaban de esa forma, pero habían permanecido un tanto ocultos, hace relativamente poco se ha hecho pública una implementación completa y funcional de un rootkit con capacidad para infectar un sistema Linux actual, su nombre: Jynx

Este tipo de rootkits actúan inyectando una librería compartida (.so) en todos los procesos del sistema.

Aun a riesgo de que un purista encuentre objeciones, podemos decir que este tipo de vectores en Linux serían análogos al 'API Hooking' en Windows, las librerías .so serían el análogo a las Dlls y el fichero /etc/ld.so.preload sería el análogo a la clave de registro

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs

En resumen, lo que hacen este tipo de rootkits es añadir una línea en el fichero /etc/ld.so.preload apuntando hacia la librería del rootkit en la que se encuentran 're-escritas' ciertas funciones asociadas a la obtención de información del sistema. Luego, será el propio sistema Linux el que se encargue de hacer que cada proceso creado en el sistema lleve cargada esa librería con las funciones alteradas. La única salvedad son los binarios compilados de forma estática.

Si miramos en el fichero ld_poison.c de Jynx podemos ver claramente que funciones del sistema van a ser re-escritas:

static int (*old_fxstat)(int ver, int fildes, struct stat *buf);

static int (*old_fxstat64)(int ver, int fildes, struct stat64 *buf);

static int (*old_lxstat)(int ver, const char *file, struct stat *buf);

static int (*old_lxstat64)(int ver, const char *file, struct stat64 *buf);

static int (*old_open)(const char *pathname, int flags, mode_t mode);

static int (*old_rmdir)(const char *pathname);

static int (*old_unlink)(const char *pathname);

static int (*old_unlinkat)(int dirfd, const char *pathname, int flags);

static int (*old_xstat)(int ver, const char *path, struct stat *buf);

static int (*old_xstat64)(int ver, const char *path, struct stat64 *buf);

static DIR *(*old_fdopendir)(int fd);

static DIR *(*old_opendir)(const char *name);

static struct dirent *(*old_readdir)(DIR *dir);

static struct dirent64 *(*old_readdir64)(DIR *dir);

Y ahora un ejemplo real, he infectado con este rootkit un sistema linux ocultando dos procesos a la vista de ps y derivados, he creado un proceso bash y otro nc ocultos.

[campus@... ~]$ ./nc -l 9000

Si interrogamos a ps en busca de procesos nc:

[root@... ~]# ps aux | grep -i nc

[root@... ~]#

El comando ps no ve nada.

Ahora vamos a usar Unhide para detectar estos procesos. De entrada, si Unhide está compilado estáticamente (como se recomienda en el manual) es totalmente inmune a esta clase de rootkits, no obstante vamos a usar una versión de Unhide compilada de forma normal debido a que -lamentablemente- la mayoría de distribuciones Linux lo empaquetan así.

Empezamos con un escaneo empleando syscalls

[root@... unhide-20110113]# ./unhide-linux26 sys

Unhide 20110113

http://www.unhide-forensics.info

[*]Searching for Hidden processes through getpriority() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through getpgid() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through getsid() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_getaffinity() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_getparam() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_getscheduler() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_rr_get_interval() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through kill(..,0) scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through  comparison of results of system calls

[*]Searching for Hidden processes through sysinfo() scanning

HIDDEN Processes Found: 2       sysinfo.procs = 143   ps_count = 142

¡¡ Bingo !! los procesos son detectados, el comando identificado y también la ruta en la que se encuentra.

Ahora vamos a probar un escaneo empleando los tests proc

[root@... unhide-20110113]# ./unhide-linux26 procall

Unhide 20110113

http://www.unhide-forensics.info

[*]Searching for Hidden processes through /proc stat scanning

[*]Searching for Hidden processes through /proc chdir scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through /proc opendir scanning

[*]Searching for Hidden thread through /proc/pid/task readdir scanning

En este caso el rootkit ha bloqueado y ocultado la presencia de los procesos ante stat, readdir, opendir y readdir pero como Unhide también emplea chdir ha caído en ese test.

Conclusión: Este tipo de rootkits son bastante efectivos a la hora de hacer su trabajo, pero no son infalibles.

Leer más...

WinUnhide

Desde hace algún tiempo tenía en mente el portar Unhide a plataformas Windows, Unhide está muy ligado a plataformas Unix/Linux y el hacer un port a una plataforma como Windows suponía un reto interesante.

Finalmente he conseguido un port plenamente funcional sobre el que poder trabajar más adelante y añadir más funcionalidad.

Unhide es una herramienta orientada a detectar inconsistencias en el sistema operativo a la hora de mostrar los procesos que se están ejecutando y los puertos TCP/UDP que están en uso, este tipo de comportamiento suele estar asociado a sistemas troyanizados con 'rootkits'. Unhide consta de dos partes, una orientada a localizar procesos ocultos y otra para puertos TCP/UDP igualmente ocultados empleando algún tipo de rootkit.

La versión Unix de Unhide emplea el comando 'ps' para hacer un listado de procesos y ejecuta una serie de pruebas para discernir la fiabilidad de la información mostrada por ese comando. En el caso de Windows, existe una herramienta idéntica llamada 'tasklist' pero he preferido emplear la interface WMI para Windows con el comando 'wmic'.

En concreto estoy usando el comando 'wmic process get ProcessId' para hacer un listado de procesos visibles a través de este comando, posteriormente empleo openprocess() y Toolhelp para barrer un amplio espacio de PIDs intentando localizar procesos que sean accesibles mediante estas APIs pero no aparezcan con el comando wmic.

En el caso de Unhide-TCP, he preferido 'saltarme' la filosofía empleada en entornos Unix debido a que la idea de parsear el comando 'netstat' en Windows sin ayuda de sed / awk, me pareció bastante titánica. Probablemente usando pcre hubiese sido factible, pero me pareció complicar sobremanera el código así que usé otra aproximación al problema.

Lo que he hecho con WinUnhide-TCP es listar los puertos TCP/UDP visibles mediante las llamadas GetTcpTable() y GetUdpTable(), y luego emplear bind() sobre todo el espacio de puertos posible para detectar puertos que no aparecen listados con las llamadas anteriores y en los que no se puede hacer bind(), señal de que esas funciones han sido troyanizadas.

Existen herramientas 'anti-rootkits' para entornos Windows como por ejemplo GMER, que son bastante mas completas y complejas, mi idea es simplificar el concepto ejecutando una serie de tests que indiquen si el sistema se encuentra comprometido o no, en caso de encontrar indicios, sería el momento de entrar a usar herramientas más complejas para identificar exactamente el problema

[+] Podéis descargar WinUnhide desde aquí

Leer más...

Unhide 20090810 (BETA)

Hace poco mas de un año publicamos la última versión de Unhide y ya iba tocando una versión nueva.

Gracias a la inestimable ayuda de Jan Iven que amablemente me envió una serie de útiles parches y otra serie de correcciones / mejoras que implementé, ya tenemos la versión 20090810 de Unhide en modo Beta.

Las novedades mas destacadas son las siguientes:

• Se ha mejorado la detección del numero máximo de PIDs del sistema
• Unhide ahora es mucho mas fiable a la hora de detectar falsos positivos
• Se ha añadido una nueva rutina de detección basada en la syscall kill()
• Se han corregido algunos bugs en el código fuente.

En las pruebas que he realizado en una Fedora 11 y Debian 5 todo ha funcionado bien, pero me encantaría saber que tal se comporta esta versión en Ubuntus / Debians / CentOS un poco mas antiguas (hay reportado un extraño bug en la rutina de fuerza bruta en el bugzilla de Debian).

Si alguien se anima a probarlo y me da feedback lo agradeceré enormemente, podéis descargar la última versión de Unhide desde aquí

Leer más...

Unhide 20110113 is out !

Calentita del horno sale la última versión de Unhide (20110113) ofrecida en primicia para SbD. Por si alguien anda despistado Unhide es una herramienta de análisis forense para sistemas Unix de la que hemos hablado aquí y aquí (por ejemplo)

En esta ocasión el lanzamiento de la última versión estable coincide con el lanzamiento en paralelo de su propio sitio web www.unhide-forensics.info

La novedad mas destacada es que Patrick Gouin, arquitecto senior en desarrollo de sistemas embebidos, se une al staff de forma estable, y de su mano han llegado bastantes de las novedades de esta versión.

Entre las novedades mas destacadas :

• Mayor granularidad a la hora de ejecutar tests: Hasta ahora existían 'metatests' que estaban compuestos en algunos casos por múltiples tareas, en esta versión se pueden seleccionar específicamente que tests ejecutar (por ejemplo un test con una syscall determinada)
• Añadido un nuevo e interesante test llamado 'reverse' para identificar sistemas en los que se haya comprometido /bin/ps para hacerle creer que existe un proceso en ejecución que realmente no lo esté
• Ampliados los test sobre procfs añadiendo chdir / readdir
• Posibilidad de volcar el resultado del scan a un fichero con la opción -f
• Posibilidad de ejecutar un test específico (-r) para Kernels cuyo planificador no sea el estándar (error detectado en sistemas cuyo kernel era una versión 'pura' de kernel.org)
• Mejor integración con rkhunter

Y muchas otras más que podréis ver reflejadas en la pagina man del proyecto.

Para descargar la última versión: www.unhide-forensics.info

Leer más...

Seguridad antirootkits y antivirus en iPhoneOS for fun

¡Hola!, antes de nada me gustaría agradecer a SbD el permitirme escribir este artículo, es todo un placer por mi parte.

Sin más, vamos a tratar la seguridad en los iPhone, iPod Touch, iPad y futuros iGadgets en los que esté funcionando iPhoneOS a los que se les haya aplicado Jailbreak. Por un lado, hacer Jailbreak hace más inseguro al dispositivo (instalación de software no oficial, servicio SSH escuchando ...), pero por otro lado nos permite tener control total sobre él.

Primero vamos a implantar seguridad básica, y luego vamos a pasar al artículo en sí.

Implantar seguridad básica significa cambiar la contraseña por defecto de root para evitar intrusiones típicas (virus rastreando en busca de dispositivos configurados por defecto para entrar por SSH e instalarse).

Abrir Mobile Terminal (disponible en Cydia) para poder acceder a la terminal de comandos, y ejecutar las sentencias:

su

(password alpine por defecto)

passwd

(y la cambiáis por la que queráis)

Esto es lo normal, lo básico. Pero, ¿y si queremos más? Un dispositivo con Jailbreak es, al fin y al cabo, una máquina Unix-like a la cual podemos instalar (vía Cydia) los comandos típicos. Si a esto le sumamos que tenemos un compilador de C (además de algunos lenguajes interpretados), no sería mala idea portar aplicaciones y adaptarlas, e incluso programar nuevas aplicaciones por nuestra cuenta.

Pues este es el cuerpo de artículo, explicar y compartir algunas aplicaciones (dos portadas, una nueva) para iPhoneOS orientadas a protección antirootkits y antimalware. He metido todas en un pack, al final del artículo tenéis la descarga y el modo de instalación (muy sencillo, y desde terminal).

Antes de empezar, decir que para que funcionen adecuadamente necesitaremos usar estas aplicaciones con privilegios de root.

- Unhide

Una aplicación de la que creo que no hace falta hablar mucho aquí. Permite descubrir procesos y puertos TCP/UDP ocultos por rootkits / LKMs o cualquier otra técnica de ocultación.

Al estar escrita en C sólo ha habido que modificar los comandos del sistema que usa, y una función. Encaja muy bien en el sistema, es una herramienta bastante portable. El código fuente está incluido en la descarga, ya que ha sido modificado para poder adaptarlo.

Requiere descargar los siguientes paquetes de Cydia -> adv-cmds, sed, grep, network-cmds y Gawk. (Es posible que para encontrarlos tengáis que quitar el filtro de paquetes, ponedlo como Developers).

El uso es muy sencillo, para buscar procesos ocultos:

./unhide sys

Para buscar puertos:

./unhide-tcp

- Chkrootkit

Una herramienta que busca de forma local rootkits conocidos, strings sospechosas, comportamientos extraños del sistema (interfaz en modo promiscuo por ejemplo), etc ... Escrita también en C, en este caso el código no se incluye ya que no se ha modificado el original.

Requiere descargar los mismos paquetes que para Unhide (mirar arriba).

El README es muy bueno, y vienen los diferentes modos de uso. El más normal es arrancar el shell script que automatiza un análisis completo.

./chkrootkit

Esto nos analizará todo el sistema de ficheros.

 

Es una gran herramienta pero no está orientada a iPhoneOS, sino en general a sistemas Unix-like.

Ese era el problema, que no conocía ninguna herramienta orientada a iPhoneOS (a sus virus, a sus problemas de seguridad). Así que a raiz del artículo, he escrito un programa bastante sencillo que pretende ser algo así como un Antivirus diseñado para iPhoneOS. Las soluciones antivirus para este sistema son por ahora inexistentes, o poco conocidas (de forma oficial, en la AppStore no hay ninguna).

- iNovirs (Antivirus para iPhoneOS)

Programa muy sencillo que busca (en cuanto a su base de datos) archivos de virus en el sistema e intenta borrarlos. Está programado en C, y el código está licenciado bajo GNU/GPLv3. La base de datos es texto ASCII, y por lo tanto es personalizable por el usuario. Por defecto detecta y elimina el gusano ikee (variantes A, B, C y D). El código fuente se incluye en la descarga. No requiere ningún comando externo (usa el rm de forma opcional).

No es un software antivirus como tal, ya que no se van a proporcionar actualizaciones. Es una herramienta de ayuda antivirus, y la idea es que sea el propio usuario el que modifique y mantenga la base de datos (si le interesa estar seguro, o ante una infección). La herramienta está hecha just for fun.

He escrito un README en inglés con toda la información sobre cómo mantener la base de datos, los diferentes modos de funcionamiento del programa ... etc.

Tiene tres modos de funcionamiento: scan, normal y aggresive.

./inovirs scan (Busca virus, pero no borra nada).

./inovirs normal (Busca virus, en caso de encontrarlo y que el fichero NO sea delicado lo borra).

./inovirs aggresive (Busca y elimina todos los ficheros de virus encontrados, puede dañar algún componente del sistema).

iNovirs detecta si el fichero es delicado o no en función de lo que ponga en la base de datos (cada campo tiene -> nombre de virus:dirección del fichero del virus:acción a realizar).

Aquí está la ayuda:

Escaneamos en busca de virus (modo scan) y no encuentra nada.

Simulamos que estamos infectados y volvemos a ejecutar (modo scan). Vemos que encuentra el virus y nos avisa, pero no desinfecta.

Volvemos a lanzarlo para desinfectar (modo normal), lo que nos eliminará el virus del sistema.

Estos tres programas están metidos en un paquete .tar, subido al repositorio de software. Para obtenerlos vamos a abrir la terminal, y vamos a descargar el paquete con Wget (disponible en Cydia).

wget http://sbdtools.googlecode.com/files/iphone-norootk.tar

Una vez descargado sólo hay que descomprimir.

tar -xvf iphone-norootk.tar

Tendréis la carpeta iphone-norootk a la que podéis moveros, y dentro estarán las tres herramientas en sus carpetas correspondientes.

Hasta aquí el artículo. Escrito por Alberto Ortega Llamas

Leer más...

Vota Unhide como mejor herramienta 2014 !

Como cada año, el prestigioso site 'ToolsWatch' organiza la encuesta para elegir la mejor herramienta del año, el año pasado ganó la enormemente famosa herramienta 'Zap' quedando también muy bien situadas herramientas como Burp o PEStudio (nada menos !!).

Este año me he decidido a presentar Unhide, una herramienta de la que he hablado largamente en este blog y de la que estoy preparando una 'release' que verá la luz próximamente.

Para el que no lo sepa (y no le apetezca leerse las entradas sobre la herramienta), Unhide es una herramienta anti malware para sistemas Unix que viene 'by default' en distribuciones Linux tan potentes como Fedora o Debian (y otras muchas más) orientada a verificar si un sistema se encuentra comprometido y alguien está ocultando cosas que deberían poder verse mediante herramientas del sistema.

Personalmente, agradecería MUCHO ese pequeño gesto si os tomarais apenas unos minutos para votarla como herramienta.

Podéis votar desde aquí

¡¡ Muchas gracias !!

Leer más...

Análisis de intrusión y malware en PHP: Un caso práctico

Sucedió hace unas semanas. Recibo la llamada de un cliente preocupado, en la que me dice que algo raro está pasando en dos de sus servidores, que las colas de los procesos de correo se han vuelto locos y que están brutalmente sobrecargados. Se trata de una humilde empresa que da servicios de hosting web y correo a varios clientes a través de dos servidores alquilados. Me envía las credenciales de acceso a los mismos, tanto para SSH como para Plesk.

Una vez conectado a las máquinas, y tras comprobar que la carga de las mismas no es excesivamente elevada, descargo un kit de herramientas para diagnosticar el problema. Mediante unhide, rkhunter y chkrootkit, veo que el sistema no muestra procesos ocultos ni malware conocido. La ejecución de unhide-tcp así como un nmap remoto completo, me deja ver que no hay sockets ocultos aparentes (me parecería extraño que hubiese algún malware que exigiese port knocking previo para activarse/desactivarse, aunque la idea es bastante buena). Por otra parte, el tipo de empresa, y la de sus clientes, no me pareció que fuesen a ser el objetivo de ninguna organización ni gobierno que quiera robar secretos nucleares, por lo que no me hago a la idea que vaya a ser muy complejo el mecanismo por el que le están atizando.

Sin embargo, las colas de correo siguen incrementándose más y más. La sangre no ha debido llegar al río suficientemente, puesto que amispammer no indica que las direcciones IP de mi cliente hayan sido incluídas en alguna lista antispam. Los logs de diferentes servicios no arrojan excesiva información, excepto el de qmail, que no para de mostrar montones de intentos de conexión a servidores de AOL, a los que no puede enviar determinados mensajes por no ser válidos los buzones buscados. ¿Pero esto de AOL no se había muerto ya hace años? Sin embargo, con un simple "top" observo que se ejecuta frecuentemente un mismo cgi en php. No veo un aumento significativo de recursos cada vez que se ejecuta, pero por echarle un vistazo, nada pierdo, ¿verdad?

Pues touché… según edito el fichero, me encuentro con un script php en una única línea, que claramente han ofuscado. ¿Adivináis la ruta? Dentro de un directorio con plugins para joomla de uno de los dominios clientes de hosting. En concreto en /components/com_content/newso2p.php y /components/com_content/statgpZO.php, con idéntico contenido.

Probé a subirlo a virustotal, y oh sorpresa, aparecía referenciado por muy pocos antimalware. En concreto, los únicos que lo detectaban eran ClamAV, DrWeb, Sophos, Trendmicro y VBA32… 

Entre otras acciones, como borrar los ficheros en concreto, le propuse al cliente que actualizara Joomla y sus componentes, eliminara los plugins inútiles, etc, etc, dentro de lo que el panel de hosting le permite.

A partir de aquí caben dos preguntas. ¿Cómo ha llegado ese PHP ahí? ¿Y qué es lo que hace?

La primera de las preguntas parece de fácil respuesta: dado que el fichero tenía como dueño el usuario de Apache, y dado el lugar donde estaba, tiene toda la pinta que por alguna vulnerabilidad de Joomla! que permita escribir ficheros en sus directorios de plugins o componentes. 

¿Qué hace el "malware"?

Como indiqué más arriba, el código PHP está ofuscado y, en una sola línea, hace bastante incómoda su lectura:

Por no liarme a buscar el ofuscador utilizado para este script, usé mi manido Perl para dejarlo de una forma más legible. Me hice un script quick & dirty que me permitiese pre-procesarlo:

Con lo que me queda en out.php, la idea era identificar las diversas variables del fichero, y cambiarlas por un valor más sencillo de ver, como por ejemplo $a en vez de $v1cb251ec, f1 en vez de n9a2d8ce3 para los nombres de funciones, etc,… Aproveché a eliminar funciones que no eran llamadas nunca, que simplemente confundían más al análisis.

Así, el script PHP quedaría de esta manera:

Fundamentalmente, el atacante, simplemente tenía que hacer llamadas a este PHP, mediante el método HTTP POST y en el POST DATA enviaba en varios campos diferentes la información necesaria para construir los correos: origen, destino, subject y cuerpo.

Inicialmente, estos datos vienen codificados en Base64 y se descodifican en tiempo de ejecución. Por otra parte, se procesa en el código, una lista con las direcciones  de correo destino, que viene también en la llamada. Se establecen las cabeceras necesarias del correo y el propio bicho busca si hay servidor de correo en localhost. Si lo hay, lo usa, y si no lo hay resuelve él mismo los registros MX de los correos que recibirán el spam y les abre un socket al puerto 25, estableciendo una comunicación SMTP, enchufándoles el contenido con cabeceras del correo generado.

Conclusiones

• Pese a no ser un troyano muy mediático, el script está suficientemente bien hecho para que llame poco la atención dentro del sistema. No consume muchos recursos, ya que envía correos según se le hacen llamadas desde fuera, y en una sola llamada puede generar la ejecución de muchos correos de spam a la vez.
• Los logs que deja no son muchos, debido a que al ser con POST, no quedan datos almacenados por los parámetros que tendría si se hiciese mediante GET.
• Además, si da algún error la llamada POST, tampoco deja rastro, puesto que lo primero que hace en su ejecución, es deshabilitar cualquier tipo de traza así: "@error_reporting(0); @ini_set('error_log', NULL); @ini_set('log_errors',0); "
• En cualquier caso, y supongo que para evitar WAFs o algunos IPS que analicen las llamadas HTTP, codifica los parámetros en base64. De esta manera evitas la detección de los ingredientes necesarios para construir correos con spam en base a patrones.
• En este caso, quien se quejaba, era el sistema de monitorización de procesos del hosting, en los que el administrador veía que las estadísticas de envío de correo no eran normales, para lo que estaban acostumbrados a ver. 
• Es interesante que se comunica con el atacante (o con el bot que lo ejecuta) mediante códigos OK + el md5 de "1234567890" cuando es correcto y un código de estado + el md5 de "0987654321" cuando es incorrecto. 
• Los logs generados por Qmail se dispararon también en tamaño y un tcpdump del puerto 25 era como ver pasar las letras de Matrix pero a alta velocidad.

Leer más...

Análisis de procesos en sistemas RedHat (y derivados)

Hace tiempo que no publicamos un post linuxero y para no perder la costumbre hoy vamos a publicar algo relacionado con seguridad, análisis forense y procesos en linux.

El motivo real de este post es la próxima liberación de una nueva versión de Unhide así que, aprovechando el post, presento la nueva versión en sociedad y en rigurosa exclusiva (Ríete del Ipad!!).

Voy a dividir el post en dos tipos de procesos 'los que ves' y 'los que no ves'.

Los que ves: Hace tiempo, una de las cosas con las que mas frecuencia se recurría para atacar a los sistemas Windows desde acérrimos usuarios de Linux era la enorme cantidad de procesos que te podías encontrar en un sistema Windows frente a la simpleza de un sistema Linux. Esta situación ha cambiado drásticamente, véase un ejemplo de una workstation Linux:

$ ps ax | wc -l

228

No está mal, 228 procesos que, como es lógico, resultan poco manejables para averiguar que-es-que y si son legítimos o ilegítimos. Para este menester acude en nuestra ayuda rpm que es el gestor de paquetes en sistemas RedHat, Fedora, CentOS y derivados. Rpm implementa firma digital para verificar la autoría de los paquetes y, adicionalmente, tiene una base de datos con las firmas digitales de los ficheros de cada paquete. Y eso es realmente interesante, porque con un pequeño script en Perl, podemos interrogar a cada proceso en ejecución si pertenece a algún paquete y si ha sido alterado. El script lo podéis bajar de aquí y lo que hace básicamente es lanzar ps, buscar la ruta del ejecutable mirando en /proc/pid/exe (sorprendentemente, ps no lista bien la ruta de los ejecutables en *todos* los procesos) y lo interroga con rpm -Vf.

 $ perl procv.pl

El proceso [ 2936 /usr/bin/gnome-session ] ha sufrido modificaciones en su paquete base:

S.5....T    /usr/share/gnome/default.session                                           

El proceso [ 3227 /usr/bin/python ] ha sufrido modificaciones en su paquete base:

S.5....T    /usr/lib/python2.5/distutils/sysconfig.pyc                          

El proceso [ 9977 /opt/firefox/firefox-bin ] ha sufrido modificaciones en su paquete base:

el archivo /opt/firefox/firefox-bin no es propiedad de ningún paquete

Como se puede ver, en principio nada serio, procesos en cuyos paquetes se han modificado ficheros de configuración y un proceso que no corresponde a ningún rpm. Con esto se puede tener una idea aproximada de que es lo que está corriendo en el sistema.

Lo que no ves: En este punto entran en juego los famosos rootkits, tiempo atrás ya hable de Unhide así que no me voy copy-pastear a mi mismo, solo aprovechar para presentar la versión 20100201 disponible en el repo sbd de herramientas y que espero publicar en Febrero. Esta nueva versión incorpora un buen número de mejoras en fiabilidad y rendimiento además de un nuevo tipo de escaneo empleando hilos (threads). Si alguien encuentra algo-que-no-va-bien correito, por favor

UPDATE: Juan Galiana ha publicado en su blog un port del script para que funcione en sistemas Debian (y derivados) 

Leer más...

Lynis: Herramienta de auditoría para hardening *NIX

Hoy ha llegado a una lista de distribución de correo a la que pertenezco (Seguridad-en-Ebonia), un enlace a un producto libre destinado a la auditoría: Lynis

El remitente lo recomendaba como producto que había probado como para una máquina de casa, y que en alguna ocasión le había dado alguna sorpresa a la hora de haber securizado dicha máquina.

Se trata de una herramienta que funciona mediante línea de comandos, aunque se puede añadir como una entrada en el cron de la máquina para comprobar periódicamente si ha habido modificaciones (consecuencia de algún posible compromiso por ejemplo)

Viendo la documentación del producto, nos encontramos con que:

1. Es una herramienta de auditoría, no arregla ni modifica nada.
2. El público al que va destinada es mayormente, especialistas en seguridad, administradores de sistemas que quieren dormir más tranquilos, auditores SOX, HIPAA, PCI DSS (algún día le dedicaré un post completo a esto, lo prometo), etc...
   
3. Lo "venden"/publicitan como un antirootkit, aunque en las conclusiones veréis que recomiendo otras opciones
   

Bueno pues la he instalado en mi CentOS y la he probado convenientemente. He de decir que es bastante poco intrusivo, hace sus tests y genera al final un report con sus consejos para mejorar la seguridad del equipo.

Los resultados de la evaluación han sido los siguientes:

El producto primeramente identifica la máquina en la que corre y busca una serie de herramientas que puedan estar instaladas para su propio funcionamiento. Luego efectúa una serie de checks de seguridad categorizados en:

• Arranque y servicios
• Kernel: sus opciones y módulos cargados
• Usuarios, grupos y autenticación: Busca diferentes mecanismos de autenticación instalados en la máquina (PAM, LDAP, NIS, NIS+) así como herramientas para fortalecimiento de contraseñas
• Shells: Te indica el número de shells válidas que hay en el equipo (mira el fichero /etc/shells)
• Sistemas de ficheros: analiza características típicas (el sticky bit en el /tmp, volúmenes LVM, etc...). Curiosamente no mira si están montada como read only alguna partición como noexec, nosuid (o al menos no indica en ninguna parte que haga esta comprobación)
• Almacenamiento: Mira si está el servidor NFS levantado. (En mi caso no lo estaba, así que no sé qué otro tipo de comprobación haría si lo estuviera)
• Software: name services. Investiga si hay algún servidor DNS instalado en la máquina, así como ciertas características de la resolución de nombres. Busca por BIND, PowerDNS y alguno más. Mi maravilloso DJBDNS pasa desabercibido para Lynis porque no lo busca tampoco.
• Puertos y paquetes: Analiza el sistema de gestión de paquetes
• Red: Analiza ciertos parámetros de configuración de la red (gateway por defecto, si hay algún interfaz funcionando en modo promiscuo, etc)
• Impresoras y colas: Analizando si está el servidor de impresoras. Aquí falla puesto que dice [NOT FOUND] y yo tengo claro que está levantado.
• Software: e-mail y mensajería: Busca por Exim o Postfix (que lógicamente no encuentra). Raro se me hace que no busque sendmail. Mi Qmail tampoco lo detecta.
• Software: firewalls. Analiza si existen capacidades de firewall de la máquina y si está habilitado.
• Software: webserver. Busca si hay un servidor web en la máquina.
• SSH Support: Analiza si está levantado el SSH y que las características de configuración sean las adecuadas para otorgar los mayores niveles de seguridad.
• SNMP Support: Mira si hay servidor SNMP corriendo en la máquina.
• Databases: Busca SGBDs en la máquina (curiosamente sólo busca MySQL, de Postgress se han olvidado). Echo de menos también que ya que detecta que hay un mysql, investigue por ejemplo ciertas características que se pueden hacer sin permisos (como )
  
• Servicios LDAP: Mira si existe servidor OpenLDAP
• Software: PHP. Busca si hay PHP instalado y valida alguna opción de configuración
• Logging y ficheros: Interesante análisis sobre diferentes opciones de syslog, aunque no detecta que syslog-ng está instalado y funcionando, aunque lo están
• Servicios inseguros: Analiza el estado de Inetd. ¿¿No mira xinetd??
• Banners e indentificación: Parámetros del /etc/motd
• Tareas programadas: Si existe los servicios crond o atd levantados
• Accounting
• Tiempo y sincronización: analiza si existen opciones configuradas para sincronización horaria.
• Criptografía: Validando expiración de certificado SSL
• Virtualización: No hay Xen instalado, por lo que no mira nada en mi caso
• Frameworks de seguridad: Busca si Selinux o AppArmor está en el sistema
• Software: Integridad de ficheros. Busca por diferentes herramientas como AFICK, AIDE, Osiris, Tripwire, etc,...
• Software: Malware scanners. Busca por diferentes antirootkits (chrootkit, Rootkit Hunter, ClamAV,...) Lo siento Yago, no busca por Unhide pero si son inteligentes lo harán
  
• Herramientas de sistema: Mira sobre los permisos de algunos ficheros.
  
• Directorios Home: Analiza ficheros de history de los usuarios.

Conclusiones de evaluación
Total, 123 checks hechos. Como habéis podido leer (si habéis llegado hasta aquí sin hacer trampa) la auditoría que se efectúa del sistema es bastante completa.
Sin embargo, y como he ido mencionando por el camino, encuentro ciertas deficiencias (añadiría soporte para buscar programas tan comunes como Qmail, DJBDNS, Tomcat, etc,...) e incluso malfuncionamiento de algunas cosas (servicios que dice que no están y están)
Casi se me sale el corazón del pecho, cuando he visto que me reportaba dos procesos zombies no controlados (fruto de algún troyano??? pom pom, pom pom) y realmente han sido dos falsos positivos. Para buscar procesos ocultos recomiendo encarecidamente Unhide, herramienta de la que ya hemos hablado alguna vez en este blog. También he utilizado Chkrootkit y ambos me parecen buenas alternativas.

En la misma línea, otro producto que también puede ser interesante y más versátiles para diferentes sistemas operativos es utilizar las herramientas del Center for Internet Security (CIS). Hasta hace unos meses, eran libres. Actualmente, lo siguen siendo sólo para miembros de CIS. Los demás sólo podemos descargar las guías/benchmarks de securización (gracias por el update Jesús).

Como digo, Lynis podría ser más profundo en algunos aspectos aunque, como decía quien envió el enlace a la herramienta, para un servidor casero bien vale.

Leer más...

Crónica del CSI 2013 en Pereira - Colombia - Día 2 #CSI2013

Seguimos con la crónica del segundo día del evento CSI 2013 en Pereira - Colombia. Podéis ver la crónica del primer día en este enlace

TUMI: Desde el Fingerprint hasta el informe por Walter Cuestas 

Desde muy temprano, abrió el evento el peruano Walter Cuestas, hablándonos de una herramienta, basada en una interfaz web, que permite hacer pruebas unitarias en todo el proceso de una auditoría. La herramienta se llama Tumi. Está escrita en Python, utiliza Javascript para la interfaz de menús, llama por debajo a herramientas genéricas como nmap o sqlmap. Como ventaja principal es que es totalmente opensource y permite integrar scripts hechos por uno mismo. Se puede descargar la beta desde aquí. 

') UNION SELECT 'Esta_Platica' AS (Nuevas Técnicas de Optimización y Ofuscación') por Roberto Salgado

Esta era una de las charlas que esperaba con mayor expectación. Me habían hablado maravillas de este mexicano afincado en Canadá, socio de la empresa Websec, junto a Pedro Joaquín y Paulino Calderón, y pude comprobar que todo era cierto al 100%.

Fue una charla eminentemente técnica en la que comparó diferentes algoritmos utilizados para hacer Blind SQL Injections, fundamentalmente Bitwise y Bisection.

Además, explicó un algoritmo que descubrió él y que llamó Bin2Pos, mostrando estadísticas y pruebas en tiempo real para adivinar cadenas con todos los métodos, siendo Bin2Pos el que menor número de peticiones enviaba (de media).

Además, mostró diferentes consultas SQL en una sola línea, que permiten acelerar el proceso de una auditoría, enviando una única petición y obteniendo el mismo resultado que al dividirla en N peticiones, así como ofuscación y evasión de WAF en base a caracteres no estándar, además de diversas "rarities"que el servidor SQL sigue entendiendo y ejecutando, pero que el WAF no lo interpreta como un ataque,…  En esta línea dio ejemplos para saltarse la protección de mod_security, GreenSQL o libinjection.

Esta charla, que Roberto dio hace dos semanas en Blackhat, fue brutal. Hasta el día de hoy, la que más me ha gustado! 

RogueAP / SSLStrip por Carlos Betancour…

El colombiano, miembro de la comunidad Buggly, quiso mostrar qué tan fácil era llevar a cabo un ataque en una red wireless, mediante un Man in The Middle utilizando la herramienta SSLStrip de Moxie Marlinspike. Lamentablemente, la red wireless de la Universidad era un jungla ya de por sí, y no fue posible verlo en modo práctico. En cualquier caso, nos lo creemos totalmente!

Actualización: Carlos dijo que ya que no funcionó en ese momento, lo grabaría en un video y lo pondría a disposición de todo el mundo.

  

"Advanced Topics for rootkits in Linux" por Marcos Ricardo Schejtman

Continuamos con otra de las charlas más técnicas del día. El ponente mexicano empezó introduciendo conceptos de arquitectura y privilegios de ejecución de procesos en Linux, estructura en anillos, sistemas de ficheros virtuales, etc,…
Siguió relatando los diferentes sitios donde Linux guarda objetos de los procesos, por lo que serán rutas a tener en cuenta a la hora de construir un rootkit. Además contó el funcionamiento de diferentes componentes del sistema operativo del pingüino, scheduler, tablas de procesos, mapas de memoria, syscalls, etc…
Luego nos deleitó con diferentes maneras para esconder procesos que incluso herramientas como rkhunter ni chkrootkit pudieron detectar.
Acordamos que se pondría en contacto con Yago para validar si Unhide sería o no capaz de detectarlo. El código fuente del rootkit que programó Natas no lo liberará, atendiendo a una política de Responsible Disclosure, esperando primero a que existan formas de detección de este tipo de rootkits, o incluso publicará él mismo una contramedida.

"Pentesting en la era post-pc" por Jaime Andrés Restrepo   

Aunque esta charla se la ví hacer a Jaime en el EHCon de 2012 en Santa Cruz de la Sierra en Bolivia, reconozco que la disfruto cada vez más. En este caso, Jaime enseñó la utilidad de diferentes elementos como keyloggers hardware, micrófonos simulados en pendrives USB, herramientas que se pueden utilizar sobre software de auditoría en dispositivos móviles como teléfonos, tabletas, etc,…  Dispositivos "mini", que llevan internamente un ordenador, con APs wireless levantados que permiten conectarse en remoto, piñas wireless camufladas en libros huecos, y un sinfin de ideas muy interesantes para llevar a cabo ataques basados en ingeniería social/wireless, y otras perversidades. La charla culmina con diferentes videos, en los que Jaime muestra los resultados de diferentes ejercicios, llevados a cabo en lugares públicos, consistentes en simular redes wireless abiertas.

"Software en Tiempos de Espías" por Roberto Olaya

Mi buen amigo ecuatoriano fue el protagonista de una excelente charla sobre un tema que actualmente está en boca de todos: las estrategias de inteligencia de diferentes paises, así como los diferentes sistemas utilizados (al menos los que se conocen). Sistemas de espionaje de comunicaciones como Echelon, Enfopol, Promis, Carnivore, etc,…  Agencias que se unieron en USA como la DEA, FBI, NGA, NRO, NSA, ODNI, US. Air Force, US ARmy, para formar un sistema de comunicación común….  Nos contó igualmente los avances implementados en elementos militares, como lo que llevan en el casco, traductores online, cámaras que emiten vía satélite "lo que el soldado ve", identificación humana a distancia mediante reconocimiento facial (incluso aunque se haya hecho cirugía estética) etc,…

Habló por supuesto de Prism, así como de una página muy curiosa, Prism-Break con herramientas que te resultan más recomendables si quieres mejorar tu privacidad.

"Sé el primero en auditar tu web"  por Jhon Cesar Arango [jcaitf]

Esta charla, la única que dio Jhon César, uno de los organizadores del evento, versó sobre diversas herramientas de auditoría web: Uniscan, W3AF, Nikto, Joomscan, plecost, sqlmap, zap, etc…. 

Hizo varias demos con las mismas, de manera que permite hacer ver de una forma bastante fácil, que con un poco de formación, es posible adelantarse a los "chicos malos", a fin de poder mitigar el riesgo de un montón de vulnerabilidades. Sólo con esto no aseguraremos que la web está segura al 100% pero siempre quedará menos por securizar.

"Robo de identidad digital" por Gustavo Nicolás Ogawa

En esta charla, el compañero Gustavo Ogawa hizo un caso de búsqueda de una persona, desde el principio, encontrando la identidad digital del objetivo a través de internet. A partir de ahí hizo varias demostraciones en las que usaba Facebook como medio de ataque, engañando a la víctima para explotar una vulnerabilidad de algún software (creo que fue un JRE no actualizado) con Metasploit, accediendo a su equipo.

Leer más...

Sobre el contenido de SbD

Después de ver por ahí algún copy / paste de contenido generado en este blog, en muchos casos sin poner la fuente, en otros sin mencionar la autoría del articulo por su correspondiente autor, y ya en el paroxismo del cachondeo, poniendo la URL original sin un href, "escrita" únicamente, hemos decido registrar el contenido de SbD con licencia Creative Commons del tipo Reconocimiento - No comercial

¿Que significa esto? Básicamente que el contenido se puede copiar y reproducir en su totalidad siempre y cuando se mencione expresamente la autoría y, nota importante, no exista animo de lucro. Con animo de lucro se entiende fusilar el contenido entre cientos de banners publicitarios.

Nosotros creemos firmemente en la filosofía de compartir, en mi caso concreto, por ejemplo, mantengo Unhide el cual está licenciado bajo GPL y forma parte de Ubuntu y Debian.

Lo que no nos parece bien son actitudes parásitas cuyo único valor es copiar y pegar el contenido, entre banners publicitarios. No es que tengamos particularmente nada en contra de los blogs con publicidad, simplemente es un tema que no hemos abordado y que probablemente no lo hagamos en mucho tiempo. Lo que no es de recibo es que mientras la fuente original se mantiene "virgen", el contenido sea copiado con un claro animo de lucro.

Dicho lo cual, disculpas a los lectores habituales por este super offtopic.

Leer más...