Tutoriales y Manuales
Entradas Mensuales
-
►
2024
(Total:
916
)
- ► septiembre (Total: 50 )
-
►
2023
(Total:
710
)
- ► septiembre (Total: 65 )
-
►
2022
(Total:
967
)
- ► septiembre (Total: 72 )
-
►
2021
(Total:
730
)
- ► septiembre (Total: 56 )
-
►
2020
(Total:
212
)
- ► septiembre (Total: 21 )
-
►
2019
(Total:
102
)
- ► septiembre (Total: 14 )
-
►
2017
(Total:
231
)
- ► septiembre (Total: 16 )
-
►
2016
(Total:
266
)
- ► septiembre (Total: 38 )
-
►
2015
(Total:
445
)
- ► septiembre (Total: 47 )
-
▼
2014
(Total:
185
)
- ► septiembre (Total: 18 )
-
▼
abril
(Total:
8
)
- Guia de seguridad en servicios DNS
- ¿Las redes P2P son legales en España? Crear softwa...
- Grave vulnerabilidad en OpenSSL llamada Heartbleed
- Falso antivirus de pago para Android estafa a más ...
- Campaña de FACUA para que las operadoras liberen g...
- HighSecCON III - Conferencias Seguridad Informática
- Nuevo conector reversible USB 3.1
- Windows 8 volverá a tener el menú de inicio, y apl...
-
►
2013
(Total:
100
)
- ► septiembre (Total: 3 )
-
►
2011
(Total:
7
)
- ► septiembre (Total: 1 )
Blogroll
Etiquetas
seguridad
(
394
)
privacidad
(
362
)
google
(
345
)
ransomware
(
336
)
vulnerabilidad
(
293
)
Malware
(
257
)
android
(
238
)
Windows
(
236
)
cve
(
231
)
tutorial
(
223
)
manual
(
208
)
software
(
201
)
hardware
(
189
)
linux
(
123
)
twitter
(
115
)
ddos
(
92
)
WhatsApp
(
89
)
Wifi
(
84
)
cifrado
(
77
)
herramientas
(
75
)
hacking
(
73
)
app
(
65
)
sysadmin
(
62
)
Networking
(
52
)
nvidia
(
52
)
ssd
(
50
)
youtube
(
50
)
adobe
(
43
)
firmware
(
41
)
hack
(
40
)
office
(
40
)
firefox
(
35
)
contraseñas
(
32
)
eventos
(
32
)
antivirus
(
31
)
juegos
(
31
)
cms
(
30
)
flash
(
28
)
anonymous
(
27
)
MAC
(
25
)
programación
(
25
)
apache
(
23
)
exploit
(
23
)
javascript
(
22
)
multimedia
(
22
)
Kernel
(
20
)
ssl
(
19
)
SeguridadWireless
(
17
)
documental
(
16
)
Forense
(
15
)
conferencia
(
15
)
Debugger
(
14
)
lizard squad
(
14
)
técnicas hacking
(
13
)
auditoría
(
12
)
delitos
(
11
)
metasploit
(
11
)
Virtualización
(
10
)
adamo
(
9
)
reversing
(
9
)
Rootkit
(
8
)
Ehn-Dev
(
7
)
MAC Adress
(
6
)
antimalware
(
6
)
oclHashcat
(
5
)
Entradas populares
-
Desde 2016, todas las conversaciones de WhatsApp están cifradas de extremo a extremo, lo cual está considerado el modo más seguro para evita...
-
Tal vez no conozcas Medicat USB , aquí aprenderás qué es si ya no lo sabías, y si ya lo conocías, aprenderás cómo utilizar esta poderosa c...
-
Después de ver qué es una vCPU y la diferencia entre núcleos (cores) e hilos en los procesadores, pasamos a explicar toda la nomenclatura d...
Grave vulnerabilidad en OpenSSL llamada Heartbleed
martes, 8 de abril de 2014
|
Publicado por
el-brujo
|
Editar entrada
El bug llamado Heartbleed es una vulnerabilidad importante en la popular
librería criptográfica OpenSSL. Esta debilidad permite robar información
protegida por el cifrado SSL/TLS usada en buena parte de la seguridad en Internet.
SSL/TLS permite conexiones seguras y privadas en servicios web (https Apache y ngnix), de
correo electrónico, mensajería instantánea y redes virtuales privadas
(VPN) como OpenVPN.
Las versiones OpenSSL afectadas son la 1.0.1 hasta 1.0.1f (incluída) y la 1.0.2-beta.
Las ramas anteriores
Para aquellos que no conozcan OpenSSL, es una biblioteca criptográfica utilizada para cifrar gran parte del tráfico que se envía a través de internet de una manera segura y eficiente. OpenSSL es un proyecto basado en software libre que a su vez se utiliza en un gran número de aplicaciones conocidas como OpenSSH y la mayoría de navegadores web a la hora de cifrar el tráfico.
Heartbeat (literalmente "Corazón Sangrante") es una funcionalidad añadida a TLS/DTLS que básicamente permite refrescar una sesión segura sin necesidad de efectuar una renegociación. Entre cliente y servidor se envían mensajes en forma de estructuras muy básicas para asegurarse que el cliente va a seguir enviando peticiones o el servidor sigue ahí para seguir respondiéndolas.
Cuando OpenSSL sedecidió a implementar el RFC correspondiente (RFC 6520), introdujo un bug en la implementación. Dicho fallo permite leer partes de la memoria del proceso, hasta 64k, tanto en el cliente como en el servidor, dependiendo del punto de vista del atacante. Ese es el motivo del apodo con el que han bautizado la vulnerabilidad.
El primer byte del registro SSLv3 es el "heartbeat type". El macro n2s toma 2 bytes de p, y los pone en en el payload. Esto es actualmente la longitud (lenght) del payload. Date cuenta que la actual longitud del registro SSLv3 no es comprobada.
En linux hay dos maneras de asignar dinámicamente la memoria con malloc(), una es usando sbrk (2) y la otra es usando mmap (2).
Esta vulnerabilidad ha sido denominada por los investigadores como Heartbleed. En resumen, con ella se puede engañar a cualquier sistema que utilice una versión de OpenSSL de hasta 2 años de antigüedad a que revele fragmentos de datos que se encuentren alojados en la memoria del sistema. Esto puede permitir que en un intento de recuperar dicha información se consigan las claves privadas utilizadas para cifrar los datos y, con ellas, se consiga tener acceso completo a los datos que, aparentemente, habían sido cifrados y enviados de forma segura.
Esta vulnerabilidad lleva presente desde diciembre de 2011, es decir, desde la versión 1.0.1 de OpenSSL hasta la actual 1.0.1f publicada en enero de este mismo año, aunque no ha sido hasta hoy cuando ha sido descubierta y publicada.
Recordemos que OpenSSL es una librería usada en multitud de proyectos y es distribuida en múltiples versiones de Linux, etc. Es decir, actualmente existe un número enorme de equipos y servidores que podrían estar expuestos a esta vulnerabilidad. Hay que actualizar la librería OpenSSL a la última versión no vulnerable o compilar las fuentes descartando el soporte Heartbeat definiendo la opción -DOPENSSL_NO_HEARTBEATS.
Un ejemplo de la posible envergadura de esta vulnerabilidad es, por ejemplo, que el servidor web Apache, utilizado por aproximadamente el 50% de las páginas web a nivel mundial, utiliza OpenSSL, por lo que todo el tráfico que se genere en ellos quedará vulnerable. También es vulnerable ngnix ya que por defecto usa las librerías de OpenSSL.
Podemos tener un seguimiento actualizado sobre el avance de esta vulnerabilidad desde la página web oficial de Heartbleed. Estaremos pendientes para informar sobre los avances de esta vulnerabilidad y anunciar tan pronto como sea posible la solución a esta vulnerabilidad que ha afectado a la mayoría de las conexiones de internet “seguras”.
Esta vulnerabilidad está presente desde la versión de OpenSSL que introdujo la implementación con el bug, desde la versión 1.0.1. El fallo fue descubierto por investigadores de la empresa Codenomicon en colaboración con Neel Mehta del equipo de seguridad de Google. Tiene asignado el CVE-2014-0160. Podemos leer un análisis técnico (en inglés) aquí y el commit al repositorio Git de OpenSSL del parche en este enlace . El parche se encuentra incluido en la última versión de OpenSSL, la 1.0.1g.
Los usuarios (clientes) no deben hacer nada (ni actualizar el navegador, ni nada por el estilo), es una vulnerabilidad que afecta y debe ser corregida por los administradores de sistemas de los sitios web y demás servicios que usen SSL.
http://filippo.io/Heartbleed/#meneame.net:443
http://filippo.io/Heartbleed/#foro.elhacker.net:443
Grado A
https://www.ssllabs.com/ssltest/analyze.html?d=foro.elhacker.net
Por ejemplo el popular servicio de Yahoo era vulnerable durante horas:
http://filippo.io/Heartbleed/#yahoo.com
Módulo Metasploit Framework:
Algunas de las versiones afectadas son:
Comando para comprobar servicios que usan SSL y deben ser reiniciados:
En Ubuntu y variantes apt-get:
En Centos/RHE (RedHat 6.5 and CentOS 6.5 son vulnerables) pero se puede actualizar usando yum
Resultado:
En Debian Wheezy:
Y es completamente necesario reiniciar los servicios afectados que dependen de ssl, como por ejemplo el servidor web Apache si usamos https o nginx.
Pero el problema no acaba aquí, es necesario regenerar otra vez las llaves privadas, ya que durante las horas, días que la vulnerabilidad ha estado presente un atacante haya podido leer la memoria del servidor.
Las recomendaciones son:
Y el problema no es tanto el buffer overflow de la memoria, que se puede explotar pero es relativamente complicado, el problema es que con un simple script puedes dumpear parte de la ram y ver los datos de la sesión (token), ponerlos en una cookie y acceder como otro usuario: es decir hacer un hijacking de una sesión.
https://gist.github.com/takeshixx/10107280
Por ejemplo sitios como Prezi.com (presentaciones dinámicas tipo PowerPoint) recomiendan a todos sus usuarios cambiar contraseñas:
http://engineering.prezi.com/blog/2014/04/12/heartbleet/
O la Wikipedia:
https://blog.wikimedia.org/2014/04/10/wikimedias-response-to-the-heartbleed-security-vulnerability/
Wordpress
http://en.blog.wordpress.com/2014/04/15/security-update/
GitHub
https://github.com/blog/1818-security-heartbleed-vulnerability
Fuentes:
http://unaaldia.hispasec.com/2014/04/openssl-afectada-por-una-vulnerabilidad.html
http://www.redeszone.net/2014/04/08/un-error-muy-grave-en-la-seguridad-de-openssl-amenaza-internet/
Análisis técnico del bug:
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
Las versiones OpenSSL afectadas son la 1.0.1 hasta 1.0.1f (incluída) y la 1.0.2-beta.
Las ramas anteriores
- OpenSSL 1.0.1g NO es vulnerable
- OpenSSL 1.0.0 rama NO es vulnerable
- OpenSSL 0.9.8 rama NO es vulnerable
Para aquellos que no conozcan OpenSSL, es una biblioteca criptográfica utilizada para cifrar gran parte del tráfico que se envía a través de internet de una manera segura y eficiente. OpenSSL es un proyecto basado en software libre que a su vez se utiliza en un gran número de aplicaciones conocidas como OpenSSH y la mayoría de navegadores web a la hora de cifrar el tráfico.
Heartbeat (literalmente "Corazón Sangrante") es una funcionalidad añadida a TLS/DTLS que básicamente permite refrescar una sesión segura sin necesidad de efectuar una renegociación. Entre cliente y servidor se envían mensajes en forma de estructuras muy básicas para asegurarse que el cliente va a seguir enviando peticiones o el servidor sigue ahí para seguir respondiéndolas.
Cuando OpenSSL sedecidió a implementar el RFC correspondiente (RFC 6520), introdujo un bug en la implementación. Dicho fallo permite leer partes de la memoria del proceso, hasta 64k, tanto en el cliente como en el servidor, dependiendo del punto de vista del atacante. Ese es el motivo del apodo con el que han bautizado la vulnerabilidad.
Los registros tienen tipo (type), longitud (lenght) y datos (data)typedef struct ssl3_record_st { int type; /* type of record */ unsigned int length; /* How many bytes available */ unsigned int off; /* read/write offset into 'buf' */ unsigned char *data; /* pointer to the record data */ unsigned char *input; /* where the decode bytes are */ unsigned char *comp; /* only used with decompression - malloc()ed */ unsigned long epoch; /* epoch number, needed by DTLS1 */ unsigned char seq_num[8]; /* sequence number, needed by DTLS1 */ } SSL3_RECORD;
/* Read type and payload length first */ hbtype = *p++; n2s(p, payload); pl = p;
El primer byte del registro SSLv3 es el "heartbeat type". El macro n2s toma 2 bytes de p, y los pone en en el payload. Esto es actualmente la longitud (lenght) del payload. Date cuenta que la actual longitud del registro SSLv3 no es comprobada.
unsigned char *buffer, *bp; int r; /* Allocate memory for the response, size is 1 byte * message type, plus 2 bytes payload length, plus * payload, plus padding */ buffer = OPENSSL_malloc(1 + 2 + payload + padding); bp = buffer;
/* Enter response type, length and copy payload */ *bp++ = TLS1_HB_RESPONSE; s2n(payload, bp); memcpy(bp, pl, payload);
En linux hay dos maneras de asignar dinámicamente la memoria con malloc(), una es usando sbrk (2) y la otra es usando mmap (2).
Esta vulnerabilidad ha sido denominada por los investigadores como Heartbleed. En resumen, con ella se puede engañar a cualquier sistema que utilice una versión de OpenSSL de hasta 2 años de antigüedad a que revele fragmentos de datos que se encuentren alojados en la memoria del sistema. Esto puede permitir que en un intento de recuperar dicha información se consigan las claves privadas utilizadas para cifrar los datos y, con ellas, se consiga tener acceso completo a los datos que, aparentemente, habían sido cifrados y enviados de forma segura.
Esta vulnerabilidad lleva presente desde diciembre de 2011, es decir, desde la versión 1.0.1 de OpenSSL hasta la actual 1.0.1f publicada en enero de este mismo año, aunque no ha sido hasta hoy cuando ha sido descubierta y publicada.
Recordemos que OpenSSL es una librería usada en multitud de proyectos y es distribuida en múltiples versiones de Linux, etc. Es decir, actualmente existe un número enorme de equipos y servidores que podrían estar expuestos a esta vulnerabilidad. Hay que actualizar la librería OpenSSL a la última versión no vulnerable o compilar las fuentes descartando el soporte Heartbeat definiendo la opción -DOPENSSL_NO_HEARTBEATS.
Un ejemplo de la posible envergadura de esta vulnerabilidad es, por ejemplo, que el servidor web Apache, utilizado por aproximadamente el 50% de las páginas web a nivel mundial, utiliza OpenSSL, por lo que todo el tráfico que se genere en ellos quedará vulnerable. También es vulnerable ngnix ya que por defecto usa las librerías de OpenSSL.
Podemos tener un seguimiento actualizado sobre el avance de esta vulnerabilidad desde la página web oficial de Heartbleed. Estaremos pendientes para informar sobre los avances de esta vulnerabilidad y anunciar tan pronto como sea posible la solución a esta vulnerabilidad que ha afectado a la mayoría de las conexiones de internet “seguras”.
Esta vulnerabilidad está presente desde la versión de OpenSSL que introdujo la implementación con el bug, desde la versión 1.0.1. El fallo fue descubierto por investigadores de la empresa Codenomicon en colaboración con Neel Mehta del equipo de seguridad de Google. Tiene asignado el CVE-2014-0160. Podemos leer un análisis técnico (en inglés) aquí y el commit al repositorio Git de OpenSSL del parche en este enlace . El parche se encuentra incluido en la última versión de OpenSSL, la 1.0.1g.
Los usuarios (clientes) no deben hacer nada (ni actualizar el navegador, ni nada por el estilo), es una vulnerabilidad que afecta y debe ser corregida por los administradores de sistemas de los sitios web y demás servicios que usen SSL.
Heramienta on-line para comprobar si un sitio web es vulnerable:
Ejemplos:http://filippo.io/Heartbleed/#meneame.net:443
http://filippo.io/Heartbleed/#foro.elhacker.net:443
All good, foro.elhacker.net:443 seems not affected!Por cierto, Report en SSL Labs del certificado del foro:
Grado A
https://www.ssllabs.com/ssltest/analyze.html?d=foro.elhacker.net
This server is not vulnerable to the Heartbleed attack. (Experimental)
Por ejemplo el popular servicio de Yahoo era vulnerable durante horas:
http://filippo.io/Heartbleed/#yahoo.com
Script en Phyton llamado hb-test.py por Jared Stafford:
Módulo Metasploit Framework:
Algunas de las versiones afectadas son:
- Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
- Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
- CentOS 6.5, OpenSSL 1.0.1e-15
- Fedora 18, OpenSSL 1.0.1e-4
- OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
- FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013
- NetBSD 5.0.2 (OpenSSL 1.0.1e)
- OpenSUSE 12.2 (OpenSSL 1.0.1c)
- Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14
- SUSE Linux Enterprise Server
- FreeBSD 8.4 - OpenSSL 0.9.8y 5 Feb 2013
- FreeBSD 9.2 - OpenSSL 0.9.8y 5 Feb 2013
- FreeBSD Ports - OpenSSL 1.0.1g (At 7 Apr 21:46:40 2014 UTC)
Parches, Soluciones
Es necesario que los administradores de servicios que empleen OpenSSL, se aseguren de actualizarse a la última versión,/* Read type and payload length first */ if (1 + 2 + 16 > s->s3->rrec.length) return 0; /* silently discard */ hbtype = *p++; n2s(p, payload); if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; /* silently discard per RFC 6520 sec. 4 */ pl = p;
Comando para comprobar servicios que usan SSL y deben ser reiniciados:
lsof -n | grep ssl | grep DEL
o bien
ls -l /proc/*/fd | grep 'ssl.*(deleted)'
En Ubuntu y variantes apt-get:
sudo apt-get update sudo apt-get upgrade
apt-get update && apt-get upgrade
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Se actualizarán los siguientes paquetes:
libssl1.0.0 openssh-client openssl
En Centos/RHE (RedHat 6.5 and CentOS 6.5 son vulnerables) pero se puede actualizar usando yum
yum -y update
Resultado:
Loaded plugins: fastestmirror
Cleaning repos: base extras updates
Cleaning up Everything
Cleaning up list of fastest mirrors
Loaded plugins: fastestmirror
Determining fastest mirrors
* base: ftp.hosteurope.de
* extras: mirror.softaculous.com
* updates: centos.mirror.linuxwerk.com
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package openssl.x86_64 0:1.0.1e-16.el6_5.4 will be updated
---> Package openssl.x86_64 0:1.0.1e-16.el6_5.7 will be an update
---> Package openssl-devel.x86_64 0:1.0.1e-16.el6_5.4 will be updated
---> Package openssl-devel.x86_64 0:1.0.1e-16.el6_5.7 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Updating:
openssl x86_64 1.0.1e-16.el6_5.7 updates 1.5 M
openssl-devel x86_64 1.0.1e-16.el6_5.7 updates 1.2 M
Transaction Summary
================================================================================
Upgrade 2 Package(s)
Total download size: 2.7 M
Downloading Packages:
--------------------------------------------------------------------------------
Total 40 MB/s | 2.7 MB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Updating : openssl-1.0.1e-16.el6_5.7.x86_64 1/4
Updating : openssl-devel-1.0.1e-16.el6_5.7.x86_64 2/4
Cleanup : openssl-devel-1.0.1e-16.el6_5.4.x86_64 3/4
Cleanup : openssl-1.0.1e-16.el6_5.4.x86_64 4/4
Verifying : openssl-1.0.1e-16.el6_5.7.x86_64 1/4
Verifying : openssl-devel-1.0.1e-16.el6_5.7.x86_64 2/4
Verifying : openssl-1.0.1e-16.el6_5.4.x86_64 3/4
Verifying : openssl-devel-1.0.1e-16.el6_5.4.x86_64 4/4
Updated:
openssl.x86_64 0:1.0.1e-16.el6_5.7 openssl-devel.x86_64 0:1.0.1e-16.el6_5.7
Complete!
.. upgrade complete.
En Debian Wheezy:
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_amd64.deb dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb dpkg -i libssl-dev_1.0.1e-2+deb7u5_amd64.deb
Y es completamente necesario reiniciar los servicios afectados que dependen de ssl, como por ejemplo el servidor web Apache si usamos https o nginx.
Reglas Iptables
Requiere módulo u32. Ejemplo para tráfico https (puerto 443). Logear ataque, bloquear ataque
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT"
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j DROP
Reglas Wireshark
tshark -i interface port 443 -R 'frame[68:1] == 18'
tshark -i interface port 443 -R 'ssl.record.content_type == 24'
Pero el problema no acaba aquí, es necesario regenerar otra vez las llaves privadas, ya que durante las horas, días que la vulnerabilidad ha estado presente un atacante haya podido leer la memoria del servidor.
Las recomendaciones son:
- Parchear / actualizar
- Regenerar las nuevas llaves privada
- Enviar la nueva CSR a tu entidad certificador CA.
- Obtener e instalar el nuevo certificado firmado
- Revocar los viejos certificados.
- Apagar el servidor
- Actualizar
- Regenerar los certificados Y ENCIENDE.
Y el problema no es tanto el buffer overflow de la memoria, que se puede explotar pero es relativamente complicado, el problema es que con un simple script puedes dumpear parte de la ram y ver los datos de la sesión (token), ponerlos en una cookie y acceder como otro usuario: es decir hacer un hijacking de una sesión.
https://gist.github.com/takeshixx/10107280
Por ejemplo sitios como Prezi.com (presentaciones dinámicas tipo PowerPoint) recomiendan a todos sus usuarios cambiar contraseñas:
http://engineering.prezi.com/blog/2014/04/12/heartbleet/
O la Wikipedia:
Le recomendamos cambiar su contraseña como medida de precaución estándar, pero no tenemos la intención actualmente de hacerlo obligatorio para todos los usuarios. Reiteramos que no hay evidencia de que los usuarios de la Fundación Wikimedia fueran el blanco de este ataque, pero queremos que todos nuestros usuarios estén lo más seguros posible.
https://blog.wikimedia.org/2014/04/10/wikimedias-response-to-the-heartbleed-security-vulnerability/
Wordpress
Was WordPress.com vulnerable to Heartbleed?
Yes. WordPress.com servers were running the latest version of OpenSSL, which was vulnerable. We generally run the latest version of OpenSSL to enable performance enhancements, such as SPDY, for our users. The non-vulnerable versions of OpenSSL were over two years old.
http://en.blog.wordpress.com/2014/04/15/security-update/
GitHub
We've patched all our systems using the newer, protected versions of OpenSSL. We started upgrading yesterday after the vulnerability became public and completed the roll out today. We've recreated and redeployed new SSL keys and reset internal credentials.We've forcibly reset all browser sessions that were active prior to the vulnerability being addressed on our servers.
Change your GitHub password. Be sure your password is strong; for more information, see What is a strong password?
https://github.com/blog/1818-security-heartbleed-vulnerability
Fuentes:
http://unaaldia.hispasec.com/2014/04/openssl-afectada-por-una-vulnerabilidad.html
http://www.redeszone.net/2014/04/08/un-error-muy-grave-en-la-seguridad-de-openssl-amenaza-internet/
Análisis técnico del bug:
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
Enviar por correo electrónico
Escribe un blog
Compartir con Twitter
Compartir con Facebook
Compartir en Pinterest
1 comentarios :
Publicar un comentario
Los comentarios pueden ser revisados en cualquier momento por los moderadores.
Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.
Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.