Archivo

Vulnerabilidades de XXE y RCE en ZIMBRA

marzo 25, 2019 Deja un comentario

No hay duda que Zimbra es uno de los software para implementar correos electrónicos sobre Linux mas usados, debido a ello no es ajeno a vulnerabilidades, recientemente un investigador de seguridad ha descubierto que mediante la explotación en secuencia de vulnerabilidades recientemente descubiertas, es posible lograr ejecución remota de comandos “RCE” sobre una plataforma Zimbra para tomar el control completo de esta.

Las vulnerabilidades se han catalogado como CVE-2016-9924, CVE-2018-20160 y CVE-2019-9670, las versiones afectadas son todas sin embargo ZIMBRA ha lanzado los parches para la versiones  8.7.11 y 8.8x, las cuales las pueden ubicar aquí :

https://wiki.zimbra.com/wiki/Zimbra_Releases

https://wiki.zimbra.com/wiki/Zimbra_Releases/8.7.11/P10

https://wiki.zimbra.com/wiki/Zimbra_Releases/8.8.9/P9

El exploit realizado en python al parecer a la fecha aún no es publico ( si lo encuentran me avisan 😀 ), ya que se ha publicado un vídeo del P.O.C. de la explotación hace unos días  :

 

Zimbra ha emitido un comunicados y parches a las vulnerabilidades por versión especifica, como la 8.8.x y 8.7.11 sin embargo hasta que el exploit este disponible no se sabrá certeramente si las otras versiones también son afectadas.

Este seria el procedimiento para aplicar el parche en la versión 8.7.11

Descargar el parche:

Descomprimir :

Reiniciar los servicios :

Espero que cuando ubique el exploit poder realizar las pruebas para verificar la vulnerabilidad por ahora solo toca aplicar los parches respectivos.

Saludos

Juan Oliva

@jroliva

 

Anuncios
Categorías:Manuales y tutoriales

Instalación de Openstack en Ubuntu

junio 5, 2016 4 comentarios

openstackHace un tiempo que llevo investigando, trabajando y usando de Openstack, es todo un mundo nuevo y fascinante, a continuación les muestro como instalarlo sobre Ubuntu 14.04 64bits en una instalación  All-in-One (todo en uno) ya que existe también la arquitectura muli nodo.

1.- Preparación del sistema operativo

Algunos detalles de la instalación y post instalación de Ubuntu para openstack

  • Es recomendable crear un usuario “stack” para ser usado, luego ingresar con ese usuario para realizar la instalación.
  • Es necesario configurar una dirección IP fija en el archivo “interfaces”

2.- Instalación de pre-requisitos
Ingresar con el usuario “stack” y luego escalar a root

2.1.- Instalar git
sudo su
sudo apt-get -y install git

2.2.- Clonar openstack del repostitorio dev
git clone https://git.openstack.org/openstack-dev/devstack

2.3.- Configurar el archivo “local.conf” con las credenciales y parámetros de red.
cp /home/stack/devstack/samples/local.conf /home/stack/devstack/local.conf
cd devstack/
vim local.conf

openstackDonde:

ADMIN_PASSWORD : Es la contraseña de acceso para horinzon
FLOATING_RANGE=192.168.10.224/27 : El el segmento LAN de la red, se considera el pool de IPs que seran asignadas para las maquinas virtuales.
FIXED_RANGE=10.11.12.0/24 : El segmento de direcciones internas asignadas a las maquinas virtuales.

3.- Instalación de Openstack
Una vez que tengamos configurado el archivo “local.conf” iniciarnos el proceso de instalación, Es un proceso largo, de 30 a 40 minutos, así que tengan un buen cafe a la mano.

./stack.sh

4.- Ingresar a Horizon
Una vez que el proceso culmine será posible ingresar a hortizon que es la interfase de administración de openstack de la siguiente forma:

openstack5.- Crear imágenes
Se puede definir a una imagen como un sistema pre configurado que se usa como base para crear una “instancia” , aterrizando conceptos sería instancia = maquina virtual, una instalación por defecto:

openstackEvidentemente es posible crear una nueva imagen las cuales pueden ser de tipo : AKI, AMI, ARI, hasta de tipo ISO, sin embargo la mas común es de tipo QCOW2 que son de tipo qemu.

Una buena explicación de los tipos de imágenes pueden encontrarla aquí: http://docs.openstack.org/image-guide/image-formats.html

Se puede encontrar imágenes de las principales distribuciones de Linux :
https://www.rdoproject.org/resources/image-resources/

Y crear sus propias imágenes :

openstack6.- Crear instancias.
Conceptual mente es un “clon” de una imagen que crea un usuario, es decir es bueno tener una diversa cantidad de imágenes para poder tener instancias de los diversas distribuciones.

openstack7.- Conclusiones
Definitivamente Openstack es ahora una nueva alternativa para crear nubes o virtualizar simplemente, definitivamente crear instancias solo es la punta del iceberg en este entorno de trabajo.

Una Guía muy detallada de como usar horizon pueden encontrarla aquí

Espero les sirva
Juan Oliva
@jroliva

 

 

 

 

 

Interconexión entre Elastix y Gateway Dinstar vía PRI E1

octubre 16, 2015 4 comentarios

De ves en cuento me piden realizar algunas configuraciones un poco fuera de lo común, sin embargo también es una muestra de lo versatil que puede ser usar software y hardware que cumplen con los estándares abiertos en telefonía y VoIP.

Es así, que en esta oportunidad vamos a ver como interconectar un Elastix contra un gateway con puertos E1 de la marca DINSTAR modelo MTG1000

Vamos a realizar una configuración diferente, haremos que Elastix trabaje como “operador”  y el Gateway como cliente de la siguiente forma:

DINSTAREn este caso el Elastix 1 trabajara como “operador” es decir tendrá señalización pri_net y manejará el clock (parámetro 0 de la configuración de span)

El tutorial lo vamos a dividir en 4 pasos

1.- Configuración de Elastix1
2.- Configuracion de Gateway Dinstar
3.- Verificar que la conexión E1 esté levantada en ambos
4.- Configuración del Trunk SIP entre el Dinstar y el Elastix2
5.- Creación de rutas entrantes /salientes  y pruebas

Comencemos:

1.- Configuración de Elastix1

En el detector de hardware configuramos el E1 de esta forma

DINSTARVerificar que tenemos el timing en “0” por que nosotros tendremos el clock.

Si entramos a “/etc/dahdi/system.conf” tendremos lo siguiente :

DINSTAR
Y en el “/etc/asterisk/dahdi-channels.conf” tendremos :

DINSTARComo ven en el parametro signalling lo tenemos como “pri_net” por que emularemos ser el operador.

 

2.- Configuración de Gateway Dinstar

Vamos a :   PSTN Group Config -> E1/T1 PARAMETER en donde definimos el comportamiento del E1 si va ser operador(local) o cliente(remote)

DINSTAR
Luego tendremos que modificar los parametros para el puerto donde tendremos configurado el PRIMARIO E1 en este caso será el port 0 de la siguiente forma :

DINSTAR

Ahora es necesario crear la troncal SIP con la cual trabajará el gateway es decir al servidor que le enviará las llamadas, en este caso el Elastix 2 , vamos a SIP CONFIG -> SIP TRUNK y creamos nuestra troncal de la siguiente forma

DINSTAR
Donde la dirección IP 192.168.10.220 será la IP de nuestro Elastix 2 basado en el esquema que estamos desarrollando

Ahora vamos a PRI CONFIG -> PRI TRUNK para darle las configuraciones finales de la siguiente forma.

DINSTARNote se en Switch type lo tenemos como  “User Slide” porque trabaja como CLIENTE según nuestro escenario.

3.- Verificar que la conexión E1 esté levantada en ambos

Hasta este punto, luego de reiniciar el gateway o el Elastix 1 inclusive ya tendremos levantado el E1 en el Elastix 1

DINSTAR
Y en el E1 tendremos lo siguiente :

DINSTAREn “Physis Status” tenemos el estado correcto.

Con esto nos aseguramos que tenemos ambos lados bien, es decir el Elastix 1 y el gateway configurados correctamente vía E1


4.- Configuración del Trunk SIP entre el Dinstar y el Elastix2

Ahora veremos como configurar el gateway contra el Elastix 2 mediante SIP.

Recordar que ya tenemos creada una troncal en el gateway que apunta al Elastix 2 , ahora tendremos que crear la troncal :

DINSTAREn los detalles del peer tendremos que apuntar a la IP del gateway

Luego ingresamos al gateway a la sección y veremos que tenemos establecido la troncal como se muestra a continuación.

DINSTAR

5.- Creación de rutas entrantes/salientes  y pruebas

Ahora en el Elastix 2 tendremos que crear una ruta entrante con un DID de prueba que será enviado desde el Elastix 1

DINSTARDINSTAR

Cuando llamemos desde el Elastix 1 al DID 7073890 el gateway lo recibirá y lo enviará al Elastix 2 y de esta forma lo veremos en el CLI de este ultimo:

La salida del CLI del Elastix 2

DINSTARDINSTAR

La llamada en funcionamiento :

DINSTAR

Agradecimiento a mi buen amigo Pedro Bustamante de BestSol que siempre tiene la buena disposición de prestarnos hardware para probar configuraciones como esta.

Espero les sirva
Saludos
Juan Oliva

 

 

 

Categorías:Asterisk, Centos, Linux Etiquetas: , , , , , , ,

Hacking Fortinet – SQLI test

julio 8, 2015 8 comentarios

fortinetPara los que me siguen en Facebook y en Twitter,  saben que últimamente he tenido una especial curiosidad en los equipos Fortinet,  ya que por un lado, es uno de los equipos que tienen mayor posicionamiento de instalaciones en la región y por otro lado en mis proyectos de pentest a pesar de estar presentes, nunca tuve inconveniente de bloqueos en los ataques que realizaba.

Debido a ello, la semana pasada junto a mi amigo Alexis Torres un colega del área de pentest y que también es especialista en soluciones Fortinet , realizamos algunas pruebas de seguridad ofensiva para validar si realmente el equipo bloqueaba ataques cuando protege una aplicaciones Web, en este caso usando un Appliance FortiGate 60D el cual fue configurado adecuadamente por el , ya que la idea era hacer las pruebas como dios manda.

Fortinet
El test consistió en poner una aplicación web vulnerable como DVWA la cual estaba protegida por un Appliance Fortinet D60 específicamente.

fortinet

Entrando a los Ataques:

Como saben las vulnerabilidades de SQL Inyection ( SQLI) son las mas comunes en las aplicaciones web, esto lo pueden validar ya que están en el primer lugar del Owasp top 10.

Entonces nos valimos de la aplicación vulnerable para primero realizar ataques de SQLI muy sencillos.

‘ union select 1 —

Para mi sorpresa el Fortinet detectaba el patrón de SQL , y lo bloqueaba.

Fortinet

La regla que detectaba el ataque fue “http.uri.sql.injection” evidentemente no dice mucho sobre su funcionamiento interno ya que debe ser un secreto bien guardado por la marca.

fortinet

Es así, que no nos dimos por vencidos y decidimos ir un poco más allá y desarrollar ataques un poco más elaborados con SQLMAP , herramienta por excelencia hará desarrollar SQLI.

Sin embargo era obvio que si enviaba el ataque con sqlmap sin ajustar sería presa fácil del Fortinet.

Así que le agregamos un par de modificaciones:

Velocidad:

–threads=1 , Ajustamos el máximo numero de solicitudes a 1
–delay=60 , Retrasar en 60 segundo cada envío de sqli

Ofuscación

–technique U, especificamos la tecnica basado en UNION QUERY
–batch ,  obviar el ingreso de Y/N
–tamper, especificamos el tipo script que usará como payload para ofuscar las cadenas sqli

en el caso de sqlmap tenemos una amplia variedad como en botica:

space2hash.py
space2morehash.py
space2mssqlblank.py
space2mysqlblank.pycharencode.py
chardoubleencode.py
charunicodeencode.py

De tal forma que el ataque quedó de está forma :

python sqlmap.py –url=”http://192.168.19.253/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#” –cookie=”security=low; PHPSESSID=d0fa0f05f0b714c18b3ba3ebace3f450″ -v 3 –dbms “MySQL” –technique U -p id –batch –threads=1 –delay=60 –tamper “space2mysqldash.py”

Después de algún tiempo de espera ya que como indicamos bajamos la velocidad del ataque, oh sorpresa el equipo detecto y bloqueo el ataque para cada uno de los payloads existentes con sqlmap.

fortinet-sqlmap

fortinet-sqlmap

Bueno, es evidente que fue un buen resultado para Alexis pero no para mi en mi posición de atacante, sin embargo bajo la perspectiva de protección, es bueno saber que el equipo cumple con su trabajo, aunque es necesario tener en cuenta estos dos factores:

1.-  Configuración adecuada
Como indique desarrollé las pruebas con un especialista en la marca, pero no solo activando o desactivando reglas o configuraciones, como la mayoría de empresas/implementadores lo hacen,  es importante también que un especialista en ataques haga la otra de parte, de tal forma que es posible tener los dos lados del escenario desarrollando test de seguridad ofensiva así como defensiva y de está forma garantizar que la configuración es la adecuada.

2.- Respecto a las pruebas
Desde la perspectiva del pentester no es posible asumir una posición que el equipo tiene la seguridad perfecta, por lo menos hablando de SQLI, teniendo en cuenta que se usó una aplicación web muy conocida en temas de inseguridad, sin embargo es correcto precisar que bajo este escenario fue efectivo, habría que realizar mas pruebas y en otros escenarios web para sentirse mas conforme.

En el futuro espero desarrollar otro tipo de pruebas de seguridad ofensiva como XSS, Session Hijacking, entre otros y ver como nos va.

Como siempre espero les sirva la información.

Saludos
Juan Oliva
@jroliva

 

 

 

 

 

Categorías:Hacking Etiquetas: , , ,

Elastix con Incrond , monitoreando cambios en los archivos de configuración.

marzo 15, 2015 2 comentarios

Selection_999(415)Es sábado en la noche , he terminado de dictar la penúltima clase de Ethical Hacing en Huancayo , una de las ciudades mas importantes de la sierra central del Perú, me queda una hora antes de que salga el bus hacia Lima, así que vamos a aprovechar el tiempo con este post.

Hace unos meses una empresa que usa Elastix como su sistema principal de telefonía me pidió una forma de detectar automáticamente, en caso de que archivos como extensions_curstom.conf o sip_general.conf , fueran modificados o siquiera fueran fueran abiertos de alguna forma  y además que les enviara alertas al correo en caso de recibir esos eventos.

Pues alguna forma tendría que a ver, para hacer ello 😀 , me puse a buscar en la red, y esto es lo maravilloso del todo lo que está al rededor del Open Source y Linux, que puedes encontrar una programa que te sirva como base y luego moldearlo hacia el objetivo que necesites.

Es así que encontré INCROND , es un servicio que lo que hace es justamente, es monitorear los eventos que suceden en el sistema de archivos de Linux, es decir notifica sobre los cambios que pueden suceder en dentro de una carpeta o un archivo en especifico.

Con esto ya tenemos el servicio que en esencia hace lo que buscaba, a continuación vamos a ver como lo configuramos, y nos apoyamos en otros elementos, para cumplir el requerimiento solicitado.

1.- Instalar servicio
Instalar el servicio desde los repositorios

#yum install incron
#service incrond start

2.- Configurar servicio
Luego de instalarlo , la carpeta de configuracion es “/etc/incron.d/”  vamos a crear una archivo llamado “monitor_archivos_elastix” para configurarlo de la siguiente forma.

#vim /etc/incron.d/monitor_archivos_elastix

# contenido del archivo /etc/incron.d/monitor_elastix
# <directorio> <cambio a monitorear> <comando que se debe ejecutar> <parámetros del comando>
/etc/asterisk IN_MODIFY /root/incrond/incrond_email.sh $@ $# $%

Lo que hace el archivo lo siguiente :
/etc/asterisk  : Carpeta a monitorear
IN_MODIFY   : Evento que deseamos monitorear en este caso modificación.
/root/incrond/incrond_email.sh  : Script al cual vamos a enviar los parámetros que se disparan al activarse el evento
$@ : path del fichero o directorio.
$# : Nombre del fichero o directorio, sin el path.
$% : nombre del evento que se disparó

3.- Preparar programa de alertas
Ahora vamos a crear el archivo “incrond_email.sh” el cual va recibir los parametros definidos en el archivo de configuración  “monitor_elastix”

3.1.- Crear la carpeta y los archivos
#mkdir /root/incrond
#touch /root/incrond/incrond_email.sh
#touch /root/incrond/incrond_email.txt

3.2.- Crear el script incrond_email.sh

#vim /root/incrond/incrond_email.sh

#!/bin/bash
/bin/echo “ALERTA DE MONITOR DE ARCHIVOS / Se ha producido cambios en los archivos del servidor ELASTIX , los detalles son : Ruta archivo modificado: $1 Nombre archivo modificado: $2 Evento/Accion: $3 \n” > /root/incrond/incrond_email.txt
/bin/mail -s ALERTA-MODIFICACION-ARCHIVOS-ELASTIX jroliva@gmail.com</root/incrond/incrond_email.txt

4.- Desarrollando las pruebas
Ahora vamos a crear un archivo dentro de la carpeta “/etc/asterisk” que generará el evento.

– Creamos el archivo
#touch /etc/asterisk/prueba1.txt

– Luego incrond le envia los parametros al archivo “incrond_email.sh” y este genera el email , la salida la pueden ver en :
#tail -f /var/log/maillog

5.- Agregando Funciones horarias
Digamos que queremos que la monitorizacion solo lo haga a partir de las 18 horas , ya que en horario de oficina hacemos cambios regulares en el servidor.

5.1.- Programa para verificar horario

#vi /root/incrond/incrond_funcionhoraria.sh

#!/bin/bash
HORA=$(date +%H)
echo $HORA

if [ $HORA > 18 ]; then
/sbin/service incrond start
else
/sbin/service incrond stop
fi

5.2.- Automatizando en el Crontab

#chmod a+x  /root/incrond/incrond_funcionhoraria.sh
#crontab -e

*/60 *     * * *     /root/incrond/incrond_funcionhoraria.sh

Cualquier cambio o aporte serán bienvenidos
Espero les sirva
Juan Oliva
@jroliva

Categorías:Manuales y tutoriales

Instalación Elastix en Rasperry PI

marzo 2, 2015 21 comentarios

uelastix

Para los que no lo saben, existe una distribución de Elastix especifica para dispositivos Rasperry  y se llama “uelastix” http://uelastix.com  , ahora veremos como instalarlo.

uelastix

1.- Descargar Uelastix.

Primero necesitamos descargar el tar.gz para Rasperry de la pagina de Uelastix : http://uelastix.com/

Luego descomprimir el archivo creará una carpeta “elastix-arm-2014-01-30” con los archivos necesarios para la instalación de la siguiente forma :

uelastix

2.-  Iniciando el particionado

Necesitamos una memoria SD al menos de 4GB ..  en esta instalación yo uso una de 8GB.

primera partición deberá ser de tipo FAT y de tamaño al menos 256  MB.
La segunda partición deberá ser de tipo EXT3 de al menos 1.6 GB.
La tercera partición puede ocupar el resto del espacio per debe ser de al menos 1 GB.

#fdisk -l

uleastix

Comenzando el particionado

uelastix

Una vez finalizado el particionado debería debería quedar de esta forma.

uleastix

Creamos los sistemas de archivos que son obligatorios para cada partición.

#mkfs.vfat -n ‘/BOOT’ /dev/mmcblk0p1
#mkfs.ext3 -L ‘/usr’ /dev/mmcblk0p2
#mkfs.ext3 -L ‘/’ /dev/mmcblk0p3

3.- Copiando los archivos

Ahora copiamos los archivos para cada partición montada.

#mount /dev/mmcblk0p1 /mnt/
#tar -C /mnt/ -xzf BOOT.tar.gz
#umount /dev/mmcblk0p1
#mount /dev/mmcblk0p2 /mnt/
#tar -C /mnt/ -xzf usr.tar.gz
#umount /dev/mmcblk0p2
#mount /dev/mmcblk0p3 /mnt/
#tar -C /mnt/ -xzf root.tar.gz
#umount /dev/mmcblk0p3

4.- Probando Uelastix

Una vez que esté desmontado ingresar la tarjeta SD al Rasperry  , la IP por defecto es 192.168.1.251 el usuario “admin” y la contraseña “palosanto”

uelastix

Referencias :

– El archivo README.es que viene a la hora de descomprimir.
Probando uElastix (1era Parte)

Espero les sirva
Juan Oliva
@jroliva

 

 

 

Categorías:Manuales y tutoriales

GHOST , Vulnerabilidad fantasma en glibc Linux

enero 30, 2015 1 comentario

ghost

Hace unos días,  fue anunciada una nueva vulnerabilidad que afecta a sistemas Linux, la cual se ha detectado en la biblioteca glibc Linux y nombrado esta vulnerabilidad como “FANTASMA”  o “GHOST”

La libreria GNU C Library (glibc) es una implementación de la biblioteca estándar de C y una parte central del sistema operativo Linux,

La vulnerabilidad ha sido etiquetada con el código CVE-2015-0235  .la cual fue descubierta  por  investigadores de seguridad de la empresa Qualys .

GHOST es un error de tipo  ‘buffer overflow’ que afecta un par de funciones llamadas gethostbyname () y gethostbyname2 () residentes en la biblioteca glibc.

Esta vulnerabilidad permite a un atacante remoto que es capaz de hacer una llamada de solicitud de cualquiera de estas funciones para ejecutar código arbitrario con los permisos del usuario que ejecuta la aplicación.

A la fecha, existen dos exploit P.O.C. en concreto para explotar la vulnerabilidad, uno es para EXIM y otro para WordPress, pero no se descarta que mas adelante se desarrollen para otros programas o servicios.

Por lo tanto, es mas que recomendable actualizar los sistemas, a continuación veremos si somos vulnerables en un sistema Centos 5.X,  mediante el uso de un script desarrollado por la gente de Redhat , que valida la versión de de GLIBC  instalada.

El script se puede descargar desde aqui

1. Copiar el script en el sistema Linux a evaluar con el nombre ghost.sh

Ghost

2.-Brindarle permisos de ejecución

#chmod +x ghost.sh

3.- Ejecutar y probar si es vulnerable.

ghost

4.- Parchando
Para corregir y parchar el sistema, es necesario ejecutar el comando :

#yum update glibc

ghost

5.- Verificar el parche

ghost

Aquí los enlaces informativos de las distribuciones afectadas:

RedHat: https://rhn.redhat.com/errata/RHSA-2015-0090.html

Ubuntu: https://launchpad.net/ubuntu/+source/eglibc

Debian: https://security-tracker.debian.org/tracker/CVE-2015-0235

Oracle Enterprise Linux: https://oss.oracle.com/pipermail/el-errata/2015-January/004810.html CentOS: http://lists.centos.org/pipermail/centos-announce/2015-January/020906.html

OpenSUSE: http://lists.opensuse.org/opensuse-updates/2015-01/msg00085.html GNU C Library: http://www.gnu.org/software/libc/

Espero les sirva
Saludos
Juan Oliva
@jroliva

 

 

 

 

 

Categorías:Manuales y tutoriales