lunes, 2 de julio de 2018

una-al-día | Hispasec: TicketMaster, un drama en tres actos (y un epílogo)

Ataques como estos son ejemplos claros del alcance que pueden llegar a tener los fallos de seguridad en proveedores u otras dependencias de código. 
Aunque Inbenta ha sido la empresa atacada, es TicketMaster el más afectado tanto en imagen como económicamente. Incluso los efectos colaterales han llegado a Monzo, un tercero sin relación directa de negocio con ninguno de ellos.

Es importante recordar que la seguridad de nuestra infraestructura es tan débil como el componente más inseguro de la misma y que, por tanto, todos necesitan ser revisados para garantizar un producto seguro a nuestros usuarios y evitar que un problema de terceros nos afecte directamente.
 

una-al-día | Hispasec: TicketMaster, un drama en tres actos (y un epílogo)

lunes, 14 de mayo de 2018

Disponible el informe anual del CCN-CERT sobre amenazas y vulnerabilidades en dispositivos móviles

Un hecho destacable es la predominancia del sistema operativo Android y la casi completa desaparición del malogrado Windows Phone. Respecto a Android se vuelve a confirmar algo que ya sabíamos y que hemos repetido varias veces desde Una-al-día: la fragmentación de Android. Un fenómeno que no solo fastidia a los desarrolladores de la plataforma de Google, sino que también significa que una larga porción de usuarios podría estar exponiéndose a vulnerabilidades que afectan a versiones sin soporte.

No obstante, respecto a la fragmentación de Android, el informe recoge una interesante iniciativa que intentará paliar los efectos de este fenómeno. Básicamente, se trataría de separar la capa de personalización de los fabricantes del sistema base. Esto, facilitaría que el gigante del buscador pueda ofrecer actualizaciones de forma más rápida a los usuarios, sin tener que esperar meses o de manera indefinida a un parche producido por el fabricante del terminal.

El informe, también dedica un capítulo a explorar las diferentes medidas se seguridad biométrica, como el sistema FaceID de Apple, el escaneo del iris y reconocimiento facial de Samsung o el Intelligent Scan que estrenaron los dispositivos S9 y S9+ del mismo fabricante. 

Otros aspectos destacables del informe son la adopción paulatina de formas adaptadas de inteligencia artificial en estos dispositivos y los sistemas de protección frente a desbloqueos y extracción forense de datos en caso de sustracción o pérdida del terminal. Recordemos la importancia de estas plataformas hace que sean un objetivo muy apetecible para el robo de información sensible, sobre todo en el ámbito de las organizaciones y gobiernos.

A destacar la parte de análisis de las amenazas más destacadas en el sentido del malware que afecta a sistemas operativos móviles, en la que vuelve a ser el protagonista Android, así como la orientación de los objetivos del código malicioso a explotar las capacidades computaciones de estos sistemas para minar criptomoneda.

En resumen, una interesante lectura que glosa lo acontecido en seguridad de sistemas y plataformas móviles durante el pasado año y marca, a su vez, las lineas de tendencia que podría seguir el presente año.

https://unaaldia.hispasec.com/2018/05/disponible-el-informe-anual-del-ccn.html

martes, 27 de febrero de 2018

Guía paso a paso para configuración de certificados Let’s Encrypt en Apache HTTPD sobre Windows Server

Para poder configurar nuestro servidor web Apache con SSL lo primero que vamos a hacer es obtener los cerficados Let's Encrypt.

Descargamos y descomprimimos la última versión de la utilidadletsencrypt-win-simple.v1.9.8.4.zip

Dentro una ventana de comandos con permisos de administrador ejecutamos letsencrypt.exe y nos aparece el siguiente menú:


Elegimos la primera opción M y nos aparece el siguiente menú:


Ahora elegimos la opción 4 para introducir el nombre de nuestro servidor manualmente (www.ejemplo.com):


En este apartado es posible introducir varios nombres de dominio de virtual hosts configurados en tu servidor pero yo no he conseguido que instale en todos ellos el fichero de comprobación de la propiedad del dominio, por ello he realizado estos pasos de instalación para cada virtual host.

En el siguiente menú nos pregunta que procedimiento utilizar para la instalación del fichero de comprobación de propiedad del dominio.


Como se puede apreciar elegimos la opción 3 en la que proporcionamos la ruta de nuestro DocumentRoot según lo tenemos configurado en Apache.

Seguidamente nos pregunta si se realiza la copia del fichero de comprobación de propiedad del dominio y decimos que sí.


Una vez realizado esto la utilidad letsencrypt-win-simple ya está en disposición de comprobar que vamos a instalar el certificado en un servidor del que somos propietarios por ello pregunta si queremos comenzar el proceso de instalación (más bien creación) de certificados.


Elegimos la opción 2 pues no necesitamos ejecutar acciones adicionales mediante un script, tal y como se ve en el pantallazo de arriba.

Ya finalizando podemos ver estos mensajes de confirmación de la creación del certificado y la creación de la tarea programada para la renovación.


Podemos ver los ficheros de certificado que se han creado en la carpeta:
C:\ProgramData\letsencrypt-win-simple\httpsacme-v01.api.letsencrypt.org
Seguidamente vamos a configurar Apache HTTPD Server para que utilice los certificados.

En el fichero httpd.conf tenemos que realizar las siguientes modificaciones:


  • Añadir un listener para el puerto 443 de HTTPS
  • Activar el módulo de SSL



El fichero donde tenemos configurados los virtual hosts httpd-vhosts.conf quedará de esta manera para cada uno de los virtual hosts:


<VirtualHost *:80>
    ServerAdmin miemail@miserver.es
    DocumentRoot "C:/miWebRoot"
    ServerName www.midominio.es

RewriteEngine On
# Redirect to the HTTPS site
RewriteCond %{HTTPS} off
RewriteRule ^/?(.*)$ https://www.midominio.es/$1 [NE,L,R=301]

</VirtualHost>


<VirtualHost *:443>
    ServerAdmin miemail@miserver.es
    DocumentRoot "C:/miWebRoot"
    ServerName www.midominio.es

RewriteEngine On
    # Redirect to the correct domain name
    RewriteCond %{HTTP_HOST} !^www.midominio.es$ [NC]
    RewriteRule ^/?(.*)$ https://www.midominio.es/$1 [NE,L,R=301]

SSLEngine on
SSLCertificateFile "C:/ProgramData/letsencrypt-win-simple/httpsacme-v01.api.letsencrypt.org/www.midominio.es-crt.pem"
SSLCertificateKeyFile "C:/ProgramData/letsencrypt-win-simple/httpsacme-v01.api.letsencrypt.org/www.midominio.es-key.pem"
SSLCertificateChainFile "C:/ProgramData/letsencrypt-win-simple/httpsacme-v01.api.letsencrypt.org/ca-VALORESHEXADECIMALES-crt.pem"

</VirtualHost>




Como vemos además de los certificados hemos añadido redirecciones desde el puerto 80 al 443 por lo que todas las url no seguras funcionarán siendo redirigidas a su equivalente en HTTPS.

En caso de tener conectores AJP para servir páginas desde TOMCAT copiaríamos la configuración de AJP al virtualhost con el puerto 443 y nos seguirá funcionando correctamente también con páginas seguras.

Si todo es correcto ya tenemos nuestro servidor sirviendo páginas en HTTPS y solo nos quedaría estar atentos a que las renovaciones automáticas de los certificados se realicen correctamente.







miércoles, 26 de abril de 2017

Hispasec @unaaldia: Corregida vulnerabilidad crítica en Drupal

El equipo de seguridad de Drupal ha publicado un boletín de seguridad calificado como crítico, en el que se soluciona una vulnerabilidad que podría permitir a un atacante evitar los controles de acceso.

El problema, con CVE-2017-6919 y considerado crítico, consiste en un salto del acceso. Un sitio solo se ve afectado si se cumplen las siguientes condiciones: el sitio tiene activo el módulo RESTful Web Services, permite peticiones PATCH y el atacante puede tener o registrar una cuenta de usuario en el sitio.

Se ven afectadas las versiones 8.x anteriores a 8.2.8 y 8.3.1. Se recomienda la actualización a las versiones Drupal 8.2.8 o 8.3.1.



Hispasec @unaaldia: Corregida vulnerabilidad crítica en Drupal

martes, 11 de octubre de 2016

What Yahoo's NSA Surveillance Means for Email Privacy - ProtonMail Blog

Two weeks ago, we published a security advisory regarding the mass hacking of Yahoo. Unfortunately, due to recent events, we are issuing a second advisory regarding all US email providers.

What happened?

This week, it was revealed that as a result of a secret US government directive, Yahoo was forced to implement special surveillance software to scan all Yahoo Mail accounts at the request of the NSA and FBI.
Sometime in early 2015, Yahoo secretly modified their spam and malware
filters to scan all incoming email messages for the phrases in the court
order and then siphoned those messages off to US intelligence. This is
significant for several reasons:

  • This is the first known incident
    where a US intelligence directive has indiscriminately targeted all
    accounts as opposed to just the accounts of suspects. Effectively, all
    500 million+ Yahoo Mail users were presumed to be guilty.
  • Instead of searching stored messages, this directive forced Yahoo to scan incoming messages in real-time.
  • Because ALL incoming email messages
    were targeted, this program spied on every person who emailed a Yahoo
    Mail account, violating the privacy of users around the world who may
    not even have been using a US email service.

What does this mean for US tech companies?

This is a terrible precedent and ushers in a new era of global mass surveillance. It
means that US tech companies that serve billions of users around the
world can now be forced to act as extensions of the US surveillance
apparatus.
The problem extends well beyond Yahoo. As was
reported earlier, Yahoo did not fight the secret directive because Yahoo
CEO Marissa Mayer and the Yahoo legal team did not believe that they
could successfully resist the directive.


What Yahoo's NSA Surveillance Means for Email Privacy - ProtonMail Blog