Domingo, 04 Diciembre 2016 12:06

PHP 5.6 y las conexiones seguras SSL / TLS

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

 

Publicado en Seguridad

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.

crypt2

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:

Publicado en Seguridad

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:


Ver código
  1. 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
  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)"
  3. 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
  4. mation; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)"
  5. 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
  6. 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:

Ver código
  1. include_once(CLASSPATH.'ps_communication.php');
  2.  
  3.  
  4. $vm_mainframe->addStyleSheet( 'templates/'. $mainframe->getTemplate() );
  5.  
  6.  
  7. if( empty( $_POST['submit'] ) || !$ok ) {
  8.         $mainframe->setPageTitle( $VM_LANG->_('VM_RECOMMEND_FORM_LBL') );
  9.         echo '<h3>'.$VM_LANG->_('VM_RECOMMEND_FORM_LBL').'</h3>';
  10.  
  11.  
  12.         ps_communication::showRecommendForm($product_id);
  13. }
  14. else {
  15.         $mainframe->setPageTitle( $VM_LANG->_('VM_RECOMMEND_FORM_LBL') );
  16.         echo '<span class="contentheading">'. $VM_LANG->_('VM_RECOMMEND_DONE').' '. shopMakeHtmlSafe(vmGet($_POST,'recipient_mail')).'</span> <br />
  17.                 <br />
  18.                 <br />
  19.                 <a href="javascript:window.close();">
  20.                 <span class="small">'. $VM_LANG->_('PROMPT_CLOSE') .'</span>
  21.                 </a>';
  22.  
  23.  
  24. }

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.

Publicado en Seguridad
Domingo, 22 Septiembre 2013 11:18

Autenticación LDAP y Polkit

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:

Publicado en Seguridad

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.

Ver código
  1. #!/bin/bash
  2.  
  3. echo "Actualizando file.php....."
  4.  
  5. md5sum */htdocs/libraries/joomla/filesystem/file.php|while read x
  6. do
  7. m5="`echo $x|awk '{print $1}'`"
  8. file="`echo $x|awk '{print $2}'`"
  9. if [ "$m5" == "7a06b1674f30d36521f4755f3438acaf" ]
  10. then
  11. #cp file.php $file
  12. echo "$file -> Actualizado"
  13. else
  14. if [ "$m5" == "0eabdf91e2c7a26493eeb3dbe7a3fb39" ]
  15. then
  16. echo "$file -> Actualizado"
  17. else
  18. echo "$x -> Version desconocida"
  19. fi
  20. fi
  21. done
  22.  
  23. echo
  24. echo
  25. echo "Actualizando media.php....."
  26.  
  27. md5sum */htdocs/administrator/components/com_media/helpers/media.php|while read x
  28. do
  29. m5="`echo $x|awk '{print $1}'`"
  30. file="`echo $x|awk '{print $2}'`"
  31. if [ "$m5" == "8ee5fd1f0d70d0a3b00006aa35267afe" ]
  32. then
  33. #cp media.php $file
  34. echo "$file -> Actualizado"
  35. else
  36. if [ "$m5" == "3de2ea3338d49956b5dabf3a3fa1200d" ]
  37. then
  38. echo "$file -> Actualizado"
  39. else
  40. echo "$x -> Version desconocida"
  41. fi
  42. fi
  43. done
  44.  

 

 icon joomla_1526patch.zip (5.92 kB)

 

Referencias:

Publicado en Seguridad
Domingo, 12 Mayo 2013 12:02

Protege tu Joomla contra los hackers

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.

icon Descarga script (2.05 kB)

Ver código
  1. #!/bin/sh
  2.  
  3. dir="/var/www/$1/htdocs"
  4.  
  5. if [ ! "$1" ]
  6. then
  7. echo "falta el nombre del dominio"
  8. exit 1
  9. fi
  10.  
  11. if [ ! -d $dir ]
  12. then
  13. echo "no existe el dominio"
  14. exit 1
  15. fi
  16.  
  17. cd $dir
  18.  
  19. chmod ogu-w $dir
  20. chmod ogu-w -R administrator components includes language libraries modules plugins templates
  21. chmod ogu-w *.php
  22.  
  23. # Permisos para joomla =1.0
  24. if [ -d editor ]
  25. then
  26. chmod ogu-w -R editor
  27. fi
  28. if [ -d mambots ]
  29. then
  30. chmod ogu-w -R mambots
  31. fi
  32.  
  33. # Permisos para joomla =1.5
  34. if [ -d xmlrpc ]
  35. then
  36. chmod ogu-w -R xmlrpc
  37. fi
  38.  
  39. # Permisos para joomla >=1.6
  40. if [ -d cli ]
  41. then
  42. chmod ogu-w -R cli
  43. fi
  44.  
  45. # Permisos para joomla >=3.0
  46. if [ -d bin ]
  47. then
  48. chmod ogu-w -R bin layouts
  49. fi
  50.  
  51. chmod ogu+w -R administrator/cache
  52.  
  53. if [ -d administrator/backups ]
  54. then
  55. chmod ogu+w -R administrator/backups
  56. fi
  57.  
  58. # Ajusta permisos para virtuemart 1.5.x
  59. if [ -d components/com_virtuemart/shop_image ]
  60. then
  61. chmod ogu+w -R components/com_virtuemart/shop_image
  62. fi
  63. if [ -e administrator/components/com_virtuemart/virtuemart.cfg.php ]
  64. then
  65. chmod ogu+w -R administrator/components/com_virtuemart/virtuemart.cfg.php
  66. fi
  67.  
  68.  
  69. # Ajusta permisos para rsform
  70. if [ -d components/com_rsform/uploads ]
  71. then
  72. chmod ogu+w -R components/com_rsform/uploads
  73. fi
  74.  
  75.  
  76. # Ajusta permisos para docman
  77. if [ -e administrator/components/com_docman/docman.config.php ]
  78. then
  79. chmod ogu+w -R administrator/components/com_docman/docman.config.php
  80. fi
  81.  
  82.  
  83. # Ajusta permisos para sef404
  84. if [ -d administrator/components/com_sh404sef/config ]
  85. then
  86. chmod ogu+w -R administrator/components/com_sh404sef/config
  87. fi
  88. if [ -d components/com_sh404sef/cache ]
  89. then
  90. chmod ogu+w -R components/com_sh404sef/cache
  91. fi
  92.  
  93.  
  94. # Ajusta permisos para akeeba
  95. if [ -d administrator/components/com_akeeba/backup ]
  96. then
  97. chmod ogu+w -R administrator/components/com_akeeba/backup
  98. fi
  99.  
  100.  
  101. # Ajusta permisos para extplorer
  102. if [ -d administrator/components/com_extplorer/config ]
  103. then
  104. chmod ogu+w -R administrator/components/com_extplorer/config
  105. fi
  106.  
  107.  
  108. # Ajusta permisos para breezingforms
  109. if [ -d administrator/components/com_breezingforms/ajax_cache ]
  110. then
  111. chmod ogu+w -R administrator/components/com_breezingforms/ajax_cache
  112. fi
  113. if [ -d administrator/components/com_breezingforms/payment_cache ]
  114. then
  115. chmod ogu+w -R administrator/components/com_breezingforms/payment_cache
  116. 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.
Publicado en Joomla
Martes, 11 Diciembre 2012 01:41

Como mejorar la seguridad de tu web en Joomla

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 usuariosj15nuevosusuarios

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

 

Publicado en Código en Joomla