Tag Archives: vulnerability

Vulnerabilidad FREAK puede dejar las comunicaciones cifradas expuestas a ataques

Una falla reportada recientemente permite a los atacantes forzar las conexiones seguras a usar un método de cifrado más débil y quebrantable.

Read More

Superfish

      No Comments on Superfish
What you need to know

A security flaw was discovered in software that was pre-installed on some Lenovo laptops. Lenovo has issued the following Press Release.  The story has been reported on multiple sites (for example, here and here). We applaud Lenovo for quickly publishing details on affected models and instructions for removing the flaw. The problem lies in the software from a company called Superfish that was pre-installed by Lenovo on certain computers. The main function of the software was to intervene when the user performed web searches in IE or Chrome browsers, and insert Superfish’s content into the search result page. Lenovo enabled this software to “help users find and discover products visually”, by incorporating relevant search results not offered by the search engine.

Interjecting content in web pages is not new (for example, via browser add-ons), but Superfish’s approach was novel, and didn’t use a browser add-on. Instead, the software intercepted all traffic between the browser and the network external to the computer. But since most large search engines (such as, Google, Bing, and Yahoo) now serve all content over https, the Superfish software couldn’t read (and more importantly, modify) any of that encrypted traffic. To get around this, an SSL Man-in-the-Middle (MITM) was set up in the computer itself, creating fake SSL certificates with the domain name of the intended web site. These certificates were signed by or chained up to Superfish’s private root certificate. Ordinarily, browsers would display a prominent warning that such a certificate wasn’t trusted, so that was addressed that by injecting Superfish’s root certificate into the Windows trusted root store during manufacture. To make all this work, of course, the private key corresponding to that root certificate had to be pre-installed on all of these computers. Superfish took steps to encrypt that private key, but the encryption was trivial and quickly broken.

The result is that attackers now have the private key corresponding to a root certificate that is trusted in these Lenovo computers, and that can be abused in too many ways to describe here.

In some ways, this is similar to the recent incident with Gogo inflight wifi service. Both make use of an SSL MITM technique to insert themselves into the otherwise secure connection between a browser user and the websites they visit. See our recent blog post to learn how SSL MITM attacks work. In Gogo’s case, the MITM (the actor generating certificates on the fly) was in Gogo’s network; in Superfish’s case, the MITM is in the computer itself.

As we’ve said before, SSL Man-in-the-Middle solutions can be justified within an enterprise, for example, to monitor employees’ web traffic. But the well-intentioned inclusion of Superfish had unintended consequences far beyond web searching, and created a potential for malicious MITM attacks. Pre-installing any root that does not belong to an audited Certificate Authority and marking it as trusted undermines the trust model created and maintained by platform vendors, browser vendors, and Certificate Authorities. Platform and browser vendors go to great lengths to validate the Certificate Authorities whose roots they include in their trusted root store. Microsoft provided the ability for an enterprise to add additional roots to the Windows trusted root store, and Google Chrome explicitly avoids performing public-key pinning checks for such added roots. As a result, Chrome users receive no warning of the MITM, as they did in the Gogo incident.

If you think you may have an affected Lenovo computer, visit this web site to check. Uninstalling the Superfish software isn’t enough to remove the vulnerability – you must also remove the Superfish root from the Windows trust store. The instructions provided by Lenovo achieve both objectives.

JASBUG : Una nueva vulnerabilidad de Windows que requiere atención inmediata de los administradores de sistemas.

Para mitigarla se deben reconfigurar los equipos y aplicar un parche adicionalRead More

An old threat is back: Ramsonware CriptoWall 3.0. Get Avast for protection.

The nightmare is back! Your security could be seriously compromised if you do not act now. Install and update your Avast for PC before is too late. The original version of CryptoWall was discovered in November 2013, but a new and improved variant of the CryptoWall ransomware starts to infect computers all over the world […]

The SSL 3.0 Vulnerability – POODLE Bug (AKA POODLEbleed)

A bug has been found in the Secure Sockets Layer (SSL) 3.0 cryptography protocol (SSLv3) which could be exploited to intercept data that’s supposed to be encrypted between computers and servers. Three Google security researchers discovered the flaw and detailed how it could be exploited through what they called a Padding Oracle On Downgraded Legacy Encryption (POODLE) attack (CVE-2014-3566).

Información sobre la vulnerabilidad POODLE (o POODLEbleed) del protocolo SSL 3.0

A bug has been found in the Secure Sockets Layer (SSL) 3.0 cryptography protocol (SSLv3) which could be exploited to intercept data that’s supposed to be encrypted between computers and servers. Three Google security researchers discovered the flaw and de

SSLv3_poodle-300px.png

Se ha detectado una vulnerabilidad que afecta al protocolo criptográfico Secure Sockets Layer 3.0 (SSLv3) y que podría utilizarse para interceptar los datos transmitidos de un equipo a un servidor o viceversa, que en principio deberían estar cifrados. Tres investigadores de seguridad de Google dieron recientemente con el problema, al que denominaron Padding Oracle On Downgraded Legacy Encryption (POODLE) y asignaron el identificador CVE-2014-3566.

Es importante recalcar que se trata de una vulnerabilidad del protocolo SSLv3, no de un defecto de los certificados SSL, de su diseño ni de sus claves privadas. Los certificados no presentan problema alguno y, aunque se utilicen para proteger servidores compatibles con el protocolo SSL 3.0, no es necesario sustituirlos.

Según parece, la vulnerabilidad no es tan grave como Heartbleed (que afectaba a OpenSSL), ya que, para explotarla, el atacante debe tener un rol privilegiado en la red. No obstante, el riesgo de que se produzca un ataque de interposición «Man-in-the-Middle» aumenta si se utilizan puntos de acceso o redes Wi-Fi públicas.

brook-4.png

Información adicional

Aunque SSL 3.0 es un protocolo criptográfico bastante antiguo (se introdujo en 1996), según el último informe de Netcraft, casi el 95 % de los navegadores web siguen permitiendo su uso. Al conectarse con servidores antiguos, muchos clientes que usan habitualmente el cifrado TLS (Transport Layer Security) pasan a utilizar automáticamente SSL 3.0, que resulta menos seguro. Según Google, un atacante que controle la red mediante la que se conectan el equipo y el servidor podría interferir con el handshake (el proceso que comprueba qué protocolo criptográfico admite el servidor) y hacer que la transmisión de datos se proteja con el protocolo SSL 3.0 en vez de usar otro más reciente. Un ataque de interposición «Man-in-the-Middle» realizado en estas condiciones permite descifrar las cookies HTTP seguras y, de este modo, robar datos o apropiarse de cuentas de servicios online. En el momento en el que se redactó esta entrada, muchos administradores de sitios web ya habían tomado medidas para que el servidor utilizara obligatoriamente el protocolo TLSv1 o versiones posteriores en lugar de SSL 3.0, pero no todo el mundo reacciona con la misma rapidez. Heartbleed ya demostró que las grandes empresas responden enseguida a problemas de este tipo, pero las de menor tamaño suelen tardar más en resolver las vulnerabilidades críticas.

Recomendaciones para las empresas

Para reducir los riesgos, recomendamos:

  1. usar la caja de herramientas de SSL, un recurso gratuito de Symantec, para comprobar si los servidores web de la empresa corren peligro;
  2. utilizar herramientas compatibles con el mecanismo TLS_FALLBACK_SCSV, que impide que los atacantes obliguen a los navegadores web a establecer una conexión mediante el protocolo SSL 3.0;
  3. desactivar el uso de conexiones SSL 3.0 o el cifrado en modo CBC con SSL 3.0;
  4. usar un firewall para aplicaciones web basado en la nube para extremar las precauciones (más información en nuestro sitio web);
  5. desconfiar de los mensajes sospechosos, ya que habrá quien pretenda aprovecharse de la incertidumbre y de la falta de conocimientos técnicos de algunas personas.

Mi compañero Christoffer Olausson aconseja lo siguiente para resolver el problema en Apache:

> SSLProtocol All -SSLv2 -SSLv3                   <- Elimina SSLv2 y SSLv3

> apachectl configtest                                   <- Prueba la configuración

> sudo service apache restart                      <- Reinicia el servidor

Google ya ha anunciado que, en cuestión de unos meses, sus productos dejarán de ser compatibles con el protocolo SSL 3.0, y Mozilla también ha anunciado que Firefox 34 (que saldrá a finales de noviembre) tampoco admitirá su uso.

Recomendaciones para los internautas

En el caso de los internautas, Symantec recomienda:

  1. comprobar si el navegador que usan permite el uso del protocolo SSL 3.0 (por ejemplo, en Internet Explorer se puede comprobar yendo a Opciones de Internet > Opciones avanzadas);
  2. asegurarse de que la URL de los sitios web que visitan empiece siempre por «https», lo que reduce el riesgo de ataques «Man-in-the-Middle»;
  3. estar pendiente de los avisos que reciban de sus proveedores de servicios y cambiar las contraseñas o actualizar el software si es necesario;
  4. comprobar la procedencia de los mensajes de correo electrónico en los que se solicita un cambio de contraseña y asegurarse de que los enlaces conducen al sitio web oficial, ya que podría tratarse de intentos de phishing.

Más información

Symantec ya ha publicado varios artículos relacionados con este tema en la base de conocimientos.

Artículo para usuarios de Symantec Managed PKI for SSL

https://knowledge.verisign.com/support/mpki-for-ssl-support/index?page=content&id=AR2182

Artículo para usuarios de Symantec Trust Center/Trust Center Enterprise

https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR2183

Manténgase al tanto de las novedades

¿Quiere que le informemos de todo lo relacionado con esta u otras vulnerabilidades? Síganos en TwitterFacebook. Si tiene algún problema para gestionar sus certificados SSL o Code Signing, le invitamos a pasarse por nuestros foros técnicos.

Schwachstelle in SSL 3.0: POODLE (bzw. POODLEbleed)

A bug has been found in the Secure Sockets Layer (SSL) 3.0 cryptography protocol (SSLv3) which could be exploited to intercept data that’s supposed to be encrypted between computers and servers. Three Google security researchers discovered the flaw and de

SSLv3_poodle-300px.png

Im Verschlüsselungsprotokoll Secure Sockets Layer (SSL) 3.0 (SSLv3) wurde eine Schwachstelle festgestellt, die zur Ausspähung von Daten ausgenutzt werden könnte, die zwischen Computern und Servern verschlüsselt übertragen werden sollten. Drei Sicherheitsforscher von Google haben diesen Fehler entdeckt und aufgezeigt, wie er durch einen sogenannten Poodle-Angriff (Padding Oracle On Downgraded Legacy Encryption) (CVE-2014-3566) ausgenutzt werden kann.

Hierbei muss betont werden, dass es sich nicht um einen Fehler der SSL-Zertifikate, ihrer privaten Schlüsseln oder ihrer Funktionsweise handelt, sondern des alten Protokolls SSLv3. SSL-Zertifikate sind nicht betroffen und Zertifikate auf Servern, die SSL 3.0 unterstützen, brauchen nicht ersetzt zu werden.

Diese Schwachstelle wird als weniger schwerwiegend angesehen als die Schwachstelle Heartbleed in OpenSSL, da der Angreifer eine privilegierte Rolle im Netzwerk haben muss, um sie ausnutzen zu können. Problematisch wird sie aber in öffentlichen WLAN-Hotspots. da sie Man-in-the-Middle-Angriffe begünstigt.

brook-4.png

Hintergrund

Obwohl SSL 3.0 bereits 1996 eingeführt wurde, wird es laut dem neuesten Bericht von Netcraft immer noch von 95 % der Webbrowser unterstützt. Viele TLS-Clients (Transport Layer Socket) schalten ihr Verschlüsselungsprotokoll auf SSL 3.0 herunter, wenn sie mit älteren Servern kommunizieren. Laut Google kann ein Angreifer, der Kontrolle über das Netzwerk zwischen Computer und Server hat, mit einem „Protocol Downgrade Dance“ in den Handshake-Prozess eingreifen, mit dem überprüft wird, welches Verschlüsselungsprotokoll der Server akzeptieren kann. Hierdurch werden die Computer gezwungen, das ältere Protokoll SSL 3.0 zum Schutz der zu übermittelnden Daten zu verwenden. Angreifer können die Schwachstelle dann ausnutzen, indem sie einen Man-in-the-Middle-Angriff ausführen und sichere HTTP-Cookies entschlüsseln, um Daten zu stehlen oder die Kontrolle über die Online-Konten des Opfers zu übernehmen. Obwohl die Webmaster bereits mit Hochdruck daran arbeiten, SSL 3.0 zu deaktivieren, und zu TLSv1 und höher wechseln, bleibt noch viel Arbeit zu tun. Wenn Heartbleed uns eines gelehrt hat, dann dass die größten Unternehmen schnell handeln, während viele kleinere Unternehmen hinterherhinken, wenn es um die Schließung kritischer Sicherheitslücken geht.

Was müssen Unternehmen tun?

Die Schwachstelle kann auf mehrere Arten beseitigt werden:

  1. Überprüfen Sie mit unserer kostenlosen SSL-Toolbox, ob Ihre Webserver gefährdet sind.
  2. Verwenden Sie Tools, die TLS_FALLBACK_SCSV unterstützen. Dieser Mechanismus verhindert, dass Angreifer Webbrowser zur Verwendung von SSL 3.0 zwingen können.
  3. Deaktivieren Sie SSL 3.0 vollständig oder deaktivieren Sie die Verschlüsselung im CBC-Modus von SSL 3.0.
  4. Eine cloudbasierte Firewall für Webanwendungen kann vor einer Schwachstelle dieser Art schützen. Weitere Information finden Sie auf unserer Website.
  5. Seien Sie misstrauisch: Betrüger könnten versuchen, Unsicherheit und mangelndes technisches Wissen mit Spam-Mails auszunutzen.

Mein Kollege Christoffer Olausson gibt einige Tipps dazu, wie sich dieses Problem bei Apache beheben lässt:

> SSLProtocol All -SSLv2 -SSLv3                   <- Entfernt SSLv2 und SSLv3

> apachectl configtest                                   <- Testet Ihre Konfiguration

> sudo service apache restart                      <- Startet den Server neu

Google gab bekannte, in den nächsten Monaten bei allen seinen Produkten die Unterstützung für SSL 3.0 zu entfernen. Auch Mozilla kündigte an, dass SSL 3.0 bei FireFox 34 deaktiviert wird, der im November veröffentlicht wird.

Was müssen Benutzer tun?

 

Endbenutzern, die auf Websites zugreifen, empfiehlt Symantec Folgendes:

  1. Stellen Sie sicher, dass SSL 3.0 bei Ihrem Browser deaktiviert ist (bei Internet Explorer beispielsweise unter „Internetoptionen > Erweiterte Einstellungen“).
  2. Vermeiden Sie Man-in-the-Middle-Angriffe, indem Sie kontrollieren, ob „HTTPS“ auf den von Ihnen besuchten Websites immer aktiviert ist.
  3. Beachten Sie alle Benachrichtigungen der Hersteller der von Ihnen verwendeten Softwareprodukte mit Empfehlungen zur Aktualisierung der jeweiligen Software oder der zugehörigen Kennwörter.
  4. Seien Sie wachsam und fallen Sie nicht auf mögliche Phishing-E-Mails herein, in denen Sie zur Aktualisierung Ihres Kennworts aufgefordert werden. Rufen Sie immer nur den offiziellen Domänennamen der Website auf, um nicht auf eine gefälschte Website zu gelangen.

Weitere Informationen

Symantec hat in seiner Online-Wissensdatenbank Artikel zu diesem Thema veröffentlicht:

Symantec Managed PKI for SSL

https://knowledge.verisign.com/support/mpki-for-ssl-support/index?page=content&id=AR2182

Symantec Trust Center/Trust Center Enterprise

https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR2183

Bleiben Sie in Verbindung

Bleiben Sie mit uns in Verbindung, um stets aktuell über Schwachstellen informiert zu sein. Folgen Sie uns auf Twitter und Facebook oder besuchen Sie unsere Technikforen zu Problemen mit der Verwaltung von SSL und Code-Signing-Zertifikaten.

Vulnérabilité SSL 3.0 – bug POODLE (ou POODLEbleed)

A bug has been found in the Secure Sockets Layer (SSL) 3.0 cryptography protocol (SSLv3) which could be exploited to intercept data that’s supposed to be encrypted between computers and servers. Three Google security researchers discovered the flaw and de

SSLv3_poodle-300px.png

Chez Google, trois chercheurs en sécurité ont découvert une faille dans le protocole de cryptage Secure Sockets Layer (SSL) 3.0 (SSLv3), qui pourrait servir à intercepter des données a priori cryptées entre des ordinateurs et des serveurs. Ils l’ont baptisée POODLE (Padding Oracle On Downgraded Legacy Encryption), qui accessoirement veut aussi dire « caniche » (CVE-2014-3566).

Avant toute chose, notons que cette vulnérabilité touche l’ancien protocole SSLv3, et NON les certificats SSL, leurs clés privées, ou leur conception intrinsèque. Nos clients équipés de certificats sur des serveurs compatibles SSL 3.0 n’ont donc aucune raison de les remplacer.

Il semble également que cette faille s’avère moins nocive que le bug Heartbleed dans OpenSSL car son exploitation requiert des droits d’accès privilégiés au réseau. Toutefois, l’utilisation des hotspots et du WiFi public pose ici un réel problème puisque POODLE suit un schéma d’attaque par interception (Man In The Middle, MITM).

brook-4.png

Contexte

L’introduction de SSL 3.0 remonte à 1996. Or, selon le dernier rapport Netcraft, ce protocole est encore pris en charge par 95 % des navigateurs Web. De nombreux clients TLS (Transport Layer Socket) utilisent l’ancien protocole de cryptage SSL 3.0 pour communiquer avec des serveurs plus anciens. D’après Google, un pirate qui contrôle le réseau situé entre un ordinateur et un serveur peut s’immiscer dans le processus de négociation SSL (handshake SSL) utilisé pour vérifier les protocoles de cryptographie pris en charge par un serveur. C’est ce que les chercheurs appellent la « danse en marche arrière » (downgrade dance). Il pourra alors contraindre les ordinateurs du réseau à utiliser le protocole SSL 3.0 pour protéger les données en transit. Ensuite, libre à lui de lancer une attaque MITM pour intercepter des cookies HTTPS à la volée. Ainsi, il pourra voler des informations, voire prendre le contrôle des comptes en ligne de ses victimes. Et même si, à l’heure où nous écrivons ces lignes, les webmasters ne ménagent pas leurs efforts pour désactiver SSL 3.0 et migrer vers TLSv1 et des versions plus récentes, beaucoup reste encore à faire. De même, s’il est une leçon que l’on a pu retenir de l’affaire Heartbleed, c’est que les grandes entreprises sont beaucoup plus rapides que les petites structures pour corriger des vulnérabilités critiques. 

Conseils aux entreprises

Il existe un certain nombre de mesures pour neutraliser la menace :

  1. Pour savoir si vos serveurs Web courent un risque, utilisez notre service gratuit SSL Toolbox.
  2. Servez-vous d’outils compatibles TLS_FALLBACK_SCSV, un mécanisme qui empêche les pirates de forcer les navigateurs Web à utiliser SSL 3.0.
  3. Désactivez complètement le protocole SSL 3.0 ou désactivez le cryptage en mode CBC SSL 3.0.
  4. Un pare-feu applicatif Web (WAF) vous protège contre ce type de vulnérabilités. Pour en savoir plus, rendez-vous sur notre site.
  5. Méfiez-vous des e-mails d’arnaqueurs qui tenteraient de capitaliser sur le climat d’incertitude et un éventuel manque de connaissances techniques de votre part.

Pour combler la faille sur Apache, suivez les conseils de mon collègue Christoffer Olausson :

> SSLProtocol All -SSLv2 -SSLv3                   <- Désactivez SSLv2 et SSLv3

> apachectl configtest                                   <- Testez votre configuration

> sudo service apache restart                      <- Redémarrez le serveur

Pour sa part, Google a annoncé la fin du support de SSL 3.0 sur tous ses produits dans les prochains mois. Mozilla a également déclaré vouloir désactiver SSL 3.0 dans Firefox 34, dont la sortie est prévue courant novembre.

Conseils aux internautes

Symantec émet plusieurs recommandations à l’attention des internautes :

  1. Assurez-vous que SSL 3.0 est désactivé dans votre navigateur (dans Internet Explorer, allez dans Options Internet, puis dans Paramètres avancés).
  2. Pour vous prémunir contre les attaques MITM, veillez à la présence du préfixe « HTTPS » dans la barre d’adresse de votre navigateur.
  3. Restez attentifs aux avis des éditeurs et constructeurs dont vous êtes client concernant d’éventuelles mises à jour logicielles ou demandes de modification de mot de passe.
  4. Méfiez-vous des éventuels e-mails de phishing vous demandant de modifier votre mot de passe. Pour éviter de vous retrouver sur un site Web frauduleux, limitez-vous au domaine du site officiel.

Pour plus d’informations

Reportez-vous aux articles de la base de connaissances Symantec sur le sujet :

Utilisateurs Symantec Managed PKI for SSL

https://knowledge.verisign.com/support/mpki-for-ssl-support/index?page=content&id=AR2182

Utilisateurs Symantec Trust Center/Trust Center Enterprise

https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR2183

Restez connecté

Pour plus d’infos sur cette vulnérabilité et toute l’actualité sécurité, suivez-nous sur Twitter et Facebook. En cas de problème de gestion de vos certificats SSL et Code Signing, rendez-vous sur nos forums techniques.