A partir de la versión de PHP 5.6 se activa por defecto en todas las conexiones seguras SSL / TLS la verificación del nombre del host que coincida con el certificado y que este no sea autofirmado. Esto trae una mayor seguridad para las transacciones bancarias, información sensible, correos electrónicos, venta online, etc... ya que se comprueba que realmente la conexión segura sera realmente quien dice ser y no se pueda alterar por medio de un ataque “man in the middle”, capturar el trafico y asegurar que realmente donde estemos conectados sea quien dice ser.

Pero dicho esto existe algunos problemas por mala programación o por desconocimiento que puede provocar que algunas web dejen de forma correcta, como por ejemplo el envió de correo electrónico SMTPS, ya que al comprobar el nombre de certificado que este sea idéntico ya no se puede usar conexión LOCALHOST al servidor SMTP y se tiene que sustituir por el nombre del servidor, ejemplo: kvm9.srvdr.com

Este cambio también afecta a conexiones STARTTLS , FTPS, HTTPS y MYSQLS con lo cual es bueno revisarlo todo y tener unos certificados de seguridad validos.

Como parche temporal mientras se tramitan los nuevos certificados se pueden desactivar la comprobación usando: verfiy_peer a false y allow_self_signed a true, con riesgo de perdida de seguridad en las comunicaciones o añadir los nuevos CA en caso de no poder adquirir certificados validos en la configuración global de PHP en openssl.cafile

Más información en:

http://php.net/manual/en/context.ssl.php

Roadmap de PHP:

http://www.php.net/supported-versions.php

Estamos en una nueva era de Malware, más complejos y peligrosos, llamados Ransomware que al infectar el ordenador cifra los ficheros o zonas del disco duro normalmente con una clave asimétrica, haciendo imposible su recuperación. Aunque eliminemos el malware los datos permanecerán encriptados. Algunos de estos programas incluyen una cuenta regresiva informando del tiempo que les queda antes de borrar permanentemente los datos.

Para recuperar los datos, el mismo malware pide dinero en forma de transferencia monetaria de varias formas Ukash, PaySafeCard o incluso Bitcoins (normalmente sin posibilidad de un rastreo policial), amenazando  diciendo que sino se efectúa el pago, no se recuperarán los ficheros del disco duro.

Aunque lleguemos a este punto, no recomendamos en absoluto realizar el pago, ya que no se garantiza la recuperación de los datos, ya qué puede pedir sucesivos pagos, o peor aun, dar nuestros datos personales a terceras personas que los usarán de forma fraudulenta. Y contribuyendo también a que las mafias intensifiquen sus acciones con esta nueva linea de infección mas rentable.

Como podemos evitar la infección y/o minimizar sus efectos:

• Tener actualizado su sistema operativo, (Windows 7 / 8 / Server 2012 / Linux). Sobre todo aplicar el parche de seguridad MS14-012
• Uso de navegadores WEB alternativos a Internet Explorer como Firefox, Opera, Safari, Chrome.
• Actualizar software de terceros periódicamente, especialmente JAVA y FLASH.
• Usar contraseñas complejas.
• Copias de seguridad frecuentes con al menos 20 días de histórico, siendo preferible copias externas.
• No usar los servidores como puestos de trabajo habitual.
• No instalar software pirata, los cracks y serials llevan regalito.
• No compartir carpetas o ficheros innecesarios, esto también se puede aplicar a los puestos de trabajo, nosotros recomendamos que se desactive la opción “Compartir impresoras y archivos para redes Microsoft”.

Actualmente los principales sistemas vulnerables son Servidores Microsoft Windows 2003 y superiores, que aprovechando claves de seguridad débiles, acceso de escritorio remoto, compartición de archivos, Navegación web, etc..., esto da una temporal ventaja a Servidores Linux y MAC, pero no por mucho tiempo, hasta que evolucionen a lenguajes multiplataforma como JAVA.
Esto debe empezar a ser una prioridad para las empresas, el tomar conciencia de lo importante de la seguridad informática.

Hay que recordar que una vez que el sistema esté comprometido, la única forma de recuperar los datos es usando la copia de seguridad, además de instalar el sistema desde 0 (formatear), para eliminar cualquier resto del malware y evitar futuros problemas. Realizar auditorías de seguridad y analizar las posibles vías de infección, proteger de forma eficiente los recursos para no volver a ser infectados.

Referencias:

• Filecoder: Secuestrando tus datos
• RANSOMWARE, el virus de la Policía resucita y vuelve enfadado
• ESET detecta nuevo código malicioso que pide dinero a cambio de descifrar archivos
• Solución al cifrado de ficheros producido por CRYPTORBIT
• Boletín de seguridad de Microsoft MS14-012 - Crítica

Recientemente unos de nuestros servidores se disparo una alarma por incremento de mensajes en cola. Cuando empezamos la búsqueda del origen del envió masivo, nos dimos cuenta que se realizaba desde una web en Joomla con Virtuemart 1.1.7, al repasar el registro de acceso del apache aparecian unos miles de accesos por POST similares a estos:

112.207.247.13 - - [13/Mar/2014:23:08:14 +0100] "POST /index2.php HTTP/1.1" 200 1731 "http://xxxxx.xxxxx.com/index2.php?page=shop.recommend&product_id=283&pop=1&tmpl=component&option=com_virtuemart&Itemid=2 
9" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; iOpus-Web-Automation; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)" 
112.207.247.13 - - [13/Mar/2014:23:08:15 +0100] "GET /templates/theme137 HTTP/1.1" 301 325 "http://xxxxx.xxxxx.com/index2.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; iOpus-Web-Auto 
mation; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)" 
112.207.247.13 - - [13/Mar/2014:23:08:15 +0100] "POST /index2.php HTTP/1.1" 200 1750 "http://xxxxx.xxxxx.com/index2.php?page=shop.recommend&product_id=283&pop=1&tmpl=component&option=com_virtuemart&Itemid=2 
9" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; iOpus-Web-Automation; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)"

Para solucionar el problema hay que editar el fichero:

/administrator/components/com_virtuemart/html/shop.recommend.php

y eliminar el siguiente código:

include_once(CLASSPATH.'ps_communication.php');
 
 
$vm_mainframe->addStyleSheet( 'templates/'. $mainframe->getTemplate() );
 
 
if( empty( $_POST['submit'] ) || !$ok ) {
        $mainframe->setPageTitle( $VM_LANG->_('VM_RECOMMEND_FORM_LBL') );
        echo '<h3>'.$VM_LANG->_('VM_RECOMMEND_FORM_LBL').'</h3>';
 
 
        ps_communication::showRecommendForm($product_id);
}
else {
        $mainframe->setPageTitle( $VM_LANG->_('VM_RECOMMEND_FORM_LBL') );
        echo '<span class="contentheading">'. $VM_LANG->_('VM_RECOMMEND_DONE').' '. shopMakeHtmlSafe(vmGet($_POST,'recipient_mail')).'</span> <br />
                <br />
                <br />
                <a href="javascript:window.close();">
                <span class="small">'. $VM_LANG->_('PROMPT_CLOSE') .'</span>
                </a>';
 
 
}

El código anterior permite una suplantación de identidad y que servicios de email spoofing aprovechen esta vulnerabilidad para sus “clientes”.

Ya no se podrán realizar recomendaciones, pero al menos los atacantes tampoco.
Como solución mas elegante se podría activar el recaptcha, pero lo mejor es que migre el cliente a Virtuemart 2.0

Al principio no hemos encontrado ninguna referencia, pero si que existe reporte del problema desde el 2010, lo grave del asunto es que hayan pasado 4 años no se informe a la gente ni se cree una versión con parche desde virtuemart para solucionarlo.

• https://forum.virtuemart.net/index.php?topic=72804.0

En sistemas centralizados donde se usa un sistema de autenticación por LDAP anteriormente se usaban los grupos de usuarios para dar permisos a los distintos usuarios, se asignaba por ejemplo al grupo de plugdev para poder montar PEN USB o CDROM, grupo audio para acceder al audio, poder apagar el ordenador en el menú de GNOME o GDM, etc..

Pero con el nuevo cambio al sistema polkit se tiene que crear una configuración por cada puesto de trabajo dentro de /etc/polkit-1/rules.d/ con lo cual tener un sistema centralizado desaparece, por tener que sincronizar en todos los ordenadores los ficheros para ajustar los permisos. Apareciendo los errores de "Mount failed: Not Authorized" al intentar montar un dispositivo USB, no mostrando en el menú de usuario las opciones de apagar y reiniciar, no poder conectarse a una red wifi, etc...

Existe una solución que aunque no muy elegante puede funcionar en la mayoría de los casos, sobre todo si no existen grandes limitaciones para los usuarios, es dar permisos a todos y en casos necesarios quitarlos. Con lo cual simplificamos las reglas de polkit.

Creamos el fichero 50-allowall.rules en /etc/polkit-1/rules.d/

polkit.addRule(function(action, subject) {
        return polkit.Result.YES;
});

Y a partir de ese momentos todos los usuarios tendrán permisos, luego es ir creando reglas para quitar permisos a los usuarios o grupos que nos interesan.

Referencias:

• Homepage Polkit
• Ubuntu LDAP Admins and GUI Root Passwords

Nada mas recibir la notificación de este serio problema de seguridad (la cual permite subir ficheros al servidor) que afecta a la versión de Joomla 1.5.xx empece a revisar el código y planificar las actualizaciones a los clientes alojados en los diferentes servidores.

Pero por desgracia no todos los clientes han migrado a las versiones mas recientes y el numero de ellos no es pequeño, con lo cual prepare un pequeño script que los actualiza solo aquellos que estén afectados por el problema.

Ajunto el script, en caso necesario es fácil cambiar la ruta donde se encuentras los dominios alojados.

#!/bin/bash
 
echo "Actualizando file.php....."
 
md5sum */htdocs/libraries/joomla/filesystem/file.php|while read x
do
    m5="`echo $x|awk '{print $1}'`"
    file="`echo $x|awk '{print $2}'`"
    if [ "$m5" == "7a06b1674f30d36521f4755f3438acaf" ]
    then
        #cp file.php $file
        echo "$file -> Actualizado"
    else
        if [ "$m5" == "0eabdf91e2c7a26493eeb3dbe7a3fb39" ]
        then
            echo "$file -> Actualizado"
        else
            echo "$x -> Version desconocida"
        fi
    fi
done
 
echo
echo
echo "Actualizando media.php....."
 
md5sum */htdocs/administrator/components/com_media/helpers/media.php|while read x
do
    m5="`echo $x|awk '{print $1}'`"
    file="`echo $x|awk '{print $2}'`"
    if [ "$m5" == "8ee5fd1f0d70d0a3b00006aa35267afe" ]
    then
        #cp media.php $file
        echo "$file -> Actualizado"
    else
        if [ "$m5" == "3de2ea3338d49956b5dabf3a3fa1200d" ]
        then
            echo "$file -> Actualizado"
        else
            echo "$x -> Version desconocida"
        fi
    fi
done
 

  joomla_1526patch.zip (5.92 kB)

Referencias:

• Joomla 1.5 security patch made easy to install
• Joomla Bug [#31626] Unauthorized file upload security issue

Después de realizar un website con Joomla si el cliente no necesita añadir nuevas funcionalidades o no puede actualizar los módulos, componentes o plugins porque se ha quedado desactualizada, suele suceder que empiezan a encontrarse numerosas vulnerabilidades que son aprovechadas para acceder al código para manipularlo, enviar emails, mostrar otros productos, infectar a los visitantes o atacar a otras webs.

Ante este panorama, sí el cliente no esta dispuesto a realizar cambios y a realizar una pequeña inversión en subsanarlos nos vemos avocados recibir todo tipo de ataques.

Para solucionar este problema existe varias soluciones, una de ellas que es fácilmente aplicable, simplemente es proteger el espacio web contra escritura, ya qué muchos ataques se basan en modificar los ficheros index.php , template.php, footer.php, etc... y con añadir solamente la escritura en las zonas, donde sea necesario para el correcto funcionamiento del Joomla, solucionamos muchos quebraderos de cabeza.

Hemos realizado un pequeño script en bash que tiene en cuenta las versiones de Joomla1.0 hasta la 3.1 y los habituales componentes que escriben en partes especiales como el docman, akeeba, virtuemart 1.5.x, sef404, extplorer, breezingforms.
Con esto el cliente podrá continuar trabajado con su web añadiendo nuevos artículos, recibiendo información de los formularios, etc.. pero no podrá ni instalar nada nuevo ni modificar archivos css ni php. En caso necesario se tendría que habilitar la escritura en esos archivos pero limitandolo para que a los atacantes les cueste más y que desistan e intente atacar a otra web menos protegida.

 Descarga script (2.05 kB)

#!/bin/sh
 
dir="/var/www/$1/htdocs"
 
if [ ! "$1" ]
then
    echo "falta el nombre del dominio"
    exit 1
fi
 
if [ ! -d $dir ]
then
    echo "no existe el dominio"
    exit 1
fi
 
cd $dir
 
chmod ogu-w $dir
chmod ogu-w -R administrator components includes language libraries modules plugins templates
chmod ogu-w *.php
 
# Permisos para joomla =1.0
if [ -d editor ]
then
    chmod ogu-w -R editor
fi
if [ -d mambots ]
then
    chmod ogu-w -R mambots
fi
 
# Permisos para joomla =1.5
if [ -d xmlrpc ]
then
    chmod ogu-w -R xmlrpc
fi
 
# Permisos para joomla >=1.6
if [ -d cli ]
then
    chmod ogu-w -R cli
fi
 
# Permisos para joomla >=3.0
if [ -d bin ]
then
    chmod ogu-w -R bin layouts
fi
 
chmod ogu+w -R administrator/cache
 
if [ -d administrator/backups ]
then
    chmod ogu+w -R administrator/backups
fi
 
# Ajusta permisos para virtuemart 1.5.x
if [ -d components/com_virtuemart/shop_image ]
then
    chmod ogu+w -R components/com_virtuemart/shop_image
fi
if [ -e administrator/components/com_virtuemart/virtuemart.cfg.php ]
then
    chmod ogu+w -R administrator/components/com_virtuemart/virtuemart.cfg.php
fi
 
 
# Ajusta permisos para rsform
if [ -d components/com_rsform/uploads ]
then
    chmod ogu+w -R components/com_rsform/uploads
fi
 
 
# Ajusta permisos para docman
if [ -e administrator/components/com_docman/docman.config.php ]
then
    chmod ogu+w -R administrator/components/com_docman/docman.config.php
fi
 
 
# Ajusta permisos para sef404
if [ -d administrator/components/com_sh404sef/config ]
then
    chmod ogu+w -R administrator/components/com_sh404sef/config
fi
if [ -d components/com_sh404sef/cache ]
then
    chmod ogu+w -R components/com_sh404sef/cache
fi
 
 
# Ajusta permisos para akeeba
if [ -d administrator/components/com_akeeba/backup ]
then
    chmod ogu+w -R administrator/components/com_akeeba/backup
fi
 
 
# Ajusta permisos para extplorer
if [ -d administrator/components/com_extplorer/config ]
then
    chmod ogu+w -R administrator/components/com_extplorer/config
fi
 
 
# Ajusta permisos para breezingforms
if [ -d administrator/components/com_breezingforms/ajax_cache ]
then
    chmod ogu+w -R administrator/components/com_breezingforms/ajax_cache
fi
if [ -d administrator/components/com_breezingforms/payment_cache ]
then
    chmod ogu+w -R administrator/components/com_breezingforms/payment_cache
fi

• Como mejora suplementaria, sí el cliente no necesita añadir ninguna imagen nueva también se puede proteger todo el directorio /images
• Como existen infinidad de módulos, componentes y configuraciones en caso de encontrar algún componente que no funcione, enviadnos para incluirlo.

Muchas veces caemos en la falsa sensación que los ataques de seguridad y el malware es una cosa muy lejana, nada mas lejos de la realidad, los hackers y compañía no paran de mejorar sus métodos de infección y de búsqueda de sites vulnerables para instalar programas de envió de SPAM, capturar contraseñas, infectar a los navegadores, etc.., tanto en CMS (Joomla, Wordpress, Drupal, etc...) como en software desarrollado a medida.
Existen unas reglas básicas y obvias que podemos seguir para limitar que nuestro website sea presa de manos no deseables.

1. Contraseñas

   Es obvio pero las contraseñas tienen que tener un grado de complejidad que no se encuentren fácilmente en sistemas de diccionarios y también cambiarla periódicamente. No hace falta que sea cada semana pero como mínimo de 6 meses.

2. Limitar el acceso a /administrator/

   Existes sistemas para bloquear por IP, países o regiones y así en caso de que caigan en malas manos la contraseña de acceso al backend esta no puede ser usada en un primer momento, nos da tiempo a cambiarla y limitar la maleza que puedan realizar.

3. Refactorización

   Limpiar y eliminar componentes, módulos y plugins no necesarios, esto nos permitirá limitar en lo posible la aparición de agujeros de seguridad a lo largo del tiempo y simplificar las actualizaciones.

4. Actualizar

   Tener instaladas las ultimas actualizaciones, esto no es garantía al 100% pero si que nos eliminara la posibilidad de código antiguo y ya conocido como vulnerable.

5. Bloqueo website

   Si tu negocio es local, regional o de un solo país, se puede bloquear para que por ejemplo solo se puede consultar desde una lista de países permitidos, o también se puede poner una lista negra (rusia y china, por ejemplo), que no se traducirán en conversiones ni de clientes ni monetarias para nosotros. Esto también mejora el rendimiento para poder eliminar consultas y carga innecesaria. Nos baraja la estadísticas pero mejorara la calidad y usuarios que navegan por ella.

6. Comentarios

   Si no vas ha realizar una web social desactiva los comentarios, la impresión, el reenvió por email, etc.. que puede dejar el camino para que usen tu web como envió de SPAM. En caso de usarlos activar un sistema de captcha para no ser inundados con mensajes basura y SPAM.

7. Envió de correo SMTP
   

   Esto depende de las políticas de seguridad implementadas en el hosting pero lo mejor "por experiencia" es crear una cuenta de correo por cada website y en la configuración del Joomla o cualquier otro programa usar el envió a través de una conexión segura (TLS o SSL) y con autenticación. Eliminamos el envió del comando mail de php que es la principal forma que tienen los atacantes de enviar SPAM usando nuestro servidor y en caso de tener una web comprometida es fácil saber en que dominio.

8. Registro de usuarios

   Es habitual encontrar en website activado el registro de nuevos usuarios, mientras que el site no sea de E-Commercer o sea un requisito, no le pongamos la vida fácil a los hackers dándoles mas acceso que podría ser usado para escalar privilegios. Para desactivar simplemente sigue los pasos siguientes:

   Joomla 1.5 ve a la pestaña Sitio, Configuración Global, Sistema y pon que no en la opción “Permitir el registro de usuarios”

   Joomla 2.5 y posteriores, ir a Gestor de usuarios, pulsar en opciones y desactivar el “Permitir el registro de usuarios”