Category Archives: Website Security

Symantec to Pre-Verify Applicants on .bank and .insurance gTLDs

Hacker Medic December 12, 2014 No Comments

a fundamental shift in the Internet landscape

Twitter Card Style:

summary

As recently announced, fTLD Registry Services has partnered with Symantec to verify applicants before domain names are approved in the new .bank and .insurance generic Top-Level Domains (gTLDs). So what does this truly mean? Ultimately, it offers a form of brand protection for .bank and .insurance in this new era of the Internet.

July 2013 through February 2014 marked the second major landrush for addresses on the Internet. Companies from around the world applied to ICANN to operate nearly any gTLD they could think of (namely common search terms). For example we have applied to operate .symantec and .norton. With the new gTLDs as options for website developers, there are increasing risks to end-users who may confuse spoofed destinations with their real counterparts. For instance, let’s say ChelmoBank.com was a real address with millions of customers visiting daily. Without pre-verfication there would be little stopping a hacker from creating ChelmoBank.uk or Chelmobank.shop to confuse my customers and funnel them into a phishing scam as they do with subdomains (e.g., ChelmoBank.example.com). fTLD Registry Services recognizes this and is acting as the responsible operator of this new portion of the Internet. Fundamentally, this is a best practice among gTLD operators. It not only provides better brand protection, but it also enables website owners to go through a majority of the processing for an SSL certificate, which will allow the owners to easily apply for and rapidly install an SSL certificate from Symantec. At the end of the day this drives value for gTLD operators and allows their new virtual tenants to be seated among other websites which have all been vetted. Personally, I see this as the equivalent of setting up shop in a shopping mall in an affluent neighborhood.

If other registry service organizations would be interested in doing something similar to what fTLD Registry Services has done, then please email geoffrey_noakes@symantec.com today.

5 ways to protect your business against SQL injection

Hacker Medic December 9, 2014 No Comments

Twitter Card Style:

summary

Your database has been breached, malware has infected your systems and sensitive records are available for anyone to download on the internet. Your first action is to launch an investigation to find out more about the breach. The report shows that the vulnerability has been exploited for months and all forensic logs have been deleted.

SQL injection isn’t new and it has been around for more than 10 years. However, most companies still plunge huge amounts of dollars into IDS/IPS, firewalls, security gateways and anti-virus software. Web application attacks are growing at an alarming rate and most security teams focus is network security and not business critical data that is found in databases. Unless there’s a breach, then focus tend to shift but it’s simply too late.

How does SQL-injection work?

SQL injection is a very simple attack that is easy to execute. Basically the attacker adds a SQL statement into a web form and tries to modify, extract, add or delete information from the database.

Michael Giagnovoco uses a very simple analogy. I go to court and register my name as “Christoffer, you are now free to go.” The judge then says “Calling Christoffer, you are now free to go” and the bailiff lets me go, because the judge instructed him to do so.

In this example the “you are now free to go” instruction was injected into a data field intended only for a name. Then the rogue input data was executed as an instruction. That’s basically the principle behind how SQL injection operates.

How does SQL-injection impact my business?

As all other types of attacks SQL injection has evolved. When the first instances of SQL injection were discovered the attackers simply tried to dump all records from a database. Today, SQL injection is usually part of an attack toolkit that hackers downloads and uses to launch several types of attacks. It’s no longer a challenge to dump the database records but the challenge has moved to installing malware behind expensive firewalls and other security measures in place deep inside the victim organization. The installed malware is far more dangerous and destructive than a simple database attack. Imagine a hacker eavesdropping on sensitive communication, dumping the windows password file to gain access to restricted systems or stealing the private keys for your SSL and Code Signing certificates? The private keys for Code Signing certificates can be protected by Symantec Secure App Service but unfortunately not all sensitive assets have proper security measures and are vulnerable to theft.

How does SQL-injection impact consumers?

Imagine that you’re about to log onto your favorite e-commerce site, greathappybargains.com. You enter your user name and password. When you look at your order history you find several orders that you didn’t make. What happened could be the result of a SQL-injection attack. Due to poor programming, some sites allows an attacker to log onto the site posing as the previous user, you. If your credit card info is linked to a user account you can be certain that the hacker has access to that information by now. Did you use the same user name and password for other e-commerce accounts? Chances are that those accounts are compromised as well using the information from the first breach.

How do I protect my company from an SQL-injection?

Install a Web Application Firewall (WAF).

Keep in mind that a WAF can’t interpret an obscured SQL injection attack as it is based on signatures

Use Symantec Malware Scan

It comes free with all Symantec SSL certificates and provides a daily scan of your web applications and provides you with a detailed report if a SQL injection vulnerability is found

Hire a penetration tester to test all web applications tied to a relational database.

Great option but time consuming and testing needs to be conducted continuously.

Re-write all web applications

Doable but consumes resources and budget. Training your staff in secure coding is critical and a good investment.

Apply a database defense in depth strategy

The only way to protect your business from the SQL injection threat is to monitor all SQL statements at the database tier using an arsenal of tools.

There is no such thing as perfect security but following these steps will get you closer to it. Follow us on Facebook and Twitter to stay up to date on SQL injection techniques and how you can help better keep your environment safe. Take the first step by contacting us today about applying a Web Application Firewall and a DDoS Mitigation Service today.

SSL; More than Encryption

Hacker Medic December 3, 2014 No Comments

Twitter Card Style:

summary

While doing an online search for “SSL Certificates” and one of the ads said “$4.99, Why Pay More?” Without clicking on the ad I know what they are going to offer me; a simple domain validated (DV) SSL certificate. This certificate will encrypt my site’s traffic at a basic level but this isn’t 1997; the business climate and threat landscape have changed and so have our requirements for security. SSL is more than encryption. We have to consider trust, security, service, certificate management & reliability. While many Certification Authorities are cutting corners to compete with each other on price, Symantec is working around the clock to continually deliver best-in-class solutions. At Symantec we believe in these core factors as does 91% of the fortune 500 and 94 of the top 100 financial institutions in the world. Here’s why:

1. Increased End-Consumer Trust

Trust Seal — Trust seals suggest that websites are safe to interact with. The Norton Secured Seal has been shown through independent research to be the most recognized trust seal on the Internet. Offered only by Symantec, it is seen about 4 billion times per month on websites all around the world. The seal ensures visitors that they are communicating with organizations that not only encrypt their traffic but also are legitimate organizations that have gone through Symantec’s strong authentication screening as well.

Visual Cue — The “Green Bar” also represent that a site is trustworthy. With Symantec EV Certificates, browsers will change the color of the address bar to green, serving as a cue for safe interaction. DV certificates won’t provide for a visual cue to website visitors

2. Stronger Business Authentication and Website Security

Authentication — With every Symantec certificate, Symantec performs strong authentication to ensure that a website visitor can trust who they are communicating with. Security-minded organizations realize that encryption alone is not enough and require, as a matter of policy, that all certificates issued for their organization have strong authentication. On the other hand, domain validated certificates, like those that Let’s Encrypt intends to offer, will only provide encryption of data. Thus, they will not prevent a credit card number or password from going to an encrypted website that may be fraudulent.

Scanning and Alerts — Symantec products also secure customer websites with scanning for critical vulnerabilities and active malware. Symantec proactively notifies customers about security risks within a customer’s unique environment and provides guidance to ensure that such issues are quickly and easily resolved.

3. Simplified Certificate Management and Live Worldwide Support

Management Tools — Symantec enables customers to track and manage large volumes of certificates with a wide range of tools. Organizations are often burdened with the complexity of managing a variety of SSL certificates that may include of self-signed, client certificates or SSL certificates that chain up to public roots.

Accessible Technical Support — Symantec provides 24/7/365 support worldwide to ensure that customers’ sites stay up and running and secure, with an optional premium support that include SLA’s on problem escalation and resolution. This is a critical component for organizations that need to ensure that their website operations remain. A free offering like Let’s Encrypt rarely comes with any form of live support.

4. Powerful Technical Capabilities and Advanced Options

Client Ubiquity — As the longest operating Certification Authority, Symantec’s roots are in more clients than any other Certification Authority. Organizations that want to support Always on SSL and connectivity with the greatest number of users choose Symantec to secure their transactions.

Advanced Certificate Options — Symantec Secure Site Pro products include both RSA 2048 bit certificates and ECC 256 bit certificates which are optimal within Perfect Forward Secrecy. These high security, high performance certificates are the future of SSL/TLS encryption and Symantec’s ECC roots are in more clients than any other Certification Authority.

Best in Class Revocation — Symantec provides revocation information to clients through both the Online Certificate Status Protocol (OCSP) and Certificate Revocation Lists (CRLs). Both of these services are updated continually to communicate certificate revocation activity to clients worldwide. The services are tuned to provide the fastest response times possible. In the case of websites, OCSP response times can impact page load times and Symantec has invested in its infrastructure to provide OCSP responses in about 50 milliseconds for almost every major region in the world.

5. Reliable Security and Business Assurances

Warranties — Symantec offers the highest warranties of any Certification Authority. These warranties can cover customers for losses of up to $1,750,000 from incorrect information contained on Symantec certificates.

Military-Grade Data Centers — Symantec’s roots and signing services are protected by the most stringent physical, network, and logical security and process controls. The hardened facilities provide our customers with confidence that certificate issuance for their domains will not be compromised. With ten years of continuous uptime, Symantec’s robust continuity practices are the best in the industry.

Contractual Commitments — Symantec customers have a contractual commitment from Symantec to maintain their products for the term of their contract. Let’s Encrypt, as a non-profit, open-source Certification Authority, it will be difficult to offer such contractual guarantees, given the significant expenses associated with operating a publicly audited Certification Authority.

Focused investment – As the world’s largest security company, Symantec has both the resources and the motivation to ensure that the our SSL products are uncompromised. Vulnerabilities like Heartbleed have clearly demonstrated that, despite the good intentions of OpenSSL, a non-profit organization with limited resources will be challenged to keep up with the rapidly-changing security threat landscape.

Modern Security for Modern Needs

Companies that know security understand they need to use modern-day security solutions in today’s environment and that SSL is more than just simple encryption.Please keep all of these factors in mind as you are building out your webserver security plans.For more information on Symantec SSL, please visit our website.

Who’s Watching You Sleep?

Hacker Medic November 25, 2014 No Comments

The Gaping Hole in the Internet of Things

Thanks to George Orwell’s classic book 1984, I graduated High School thinking I would eventually live in a world monitored and suppressed by world governments. In the wake of the PRISM scandal in 2013 I started to get the feeling that Orwell’s dystopian novel was looking like an ill-timed prophesy. In light of comedian Pete Holms’ rant on how Privacy is Uncool, it is little brother (us) leaking our secrets; no one has to steal them from us. If you thought unmanaged Social Media privacy settings were bad, how much would you cringe if you knew you were letting people watch you sleep? Welcome to the perils of the Internet of Things (IoT).

Up until very recently a number of security camera manufactures were shipping internet connected cameras (AKA IP cameras) with default passwords. Many of these passwords were never changed by the purchaser after setting them up. It was only a matter of time that someone would set up a website displaying many of these feeds (Up to 73K at its peak).

Let me introduce Insecam, the website dedicating to not only showing you the unrestricted feeds of home and commercial security cameras but also to where they are located with all of the admin and password information. In addition to this they have social plugins that let you share your favorite feeds with your community. Ultimately taken from the pages of the improving-through-shaming security book, this site claims to seek the end of default passwords yet places advertisements conveniently next to navigation icons.

Sleep edit.jpg

On my review of the site, I saw mundane shots of doors and walkways and more mild scenes of people working the front counters of gas stations and dry-cleaners. With a chill down my spine I saw a bartender drinking the profits and an overhead shot of a girl scrolling through a fashion site. What startled me was the shear amount of cameras in bedrooms, a no-no in my world. Granted that a majority of these were aimed at cribs but the alarming part was the number of unsecured cameras pointed at hospital patients, adult beds, living rooms, and private hot tubs. Sadly, various online forum contributors claim to have found dead bodies and adults in very private or intimate situations. Situations like this define the need for better security in the internet of things landscape.

No matter what colored bucket of hacker you place the Insecam’s creator into, they have exposed a gaping hole in the IoT landscape. In 2011 there were over 9 Billion devices connected to the internet and by the year 2020 it is expected that number will be close to 24 billion. This is a cause for concern for manufactures and companies like Symantec and a potential bonanza for hackers. As more and more things come online, we are discovering new vulnerabilities and how some security practices are becoming out of date. There are obstacles with current security practices but there are ways to overcome them.

Better Password Management

I’m not a fan of passwords. Since we have to live with them we have to learn how to use them. I wrote a fun mocku-blog on password best practices for you to loathe and share. Passwords are a very weak form of security and Insecam proved that. Two Factor authentication can be used to install and access IP camera feeds via a computer or mobile device. If you have the time, take a peek at this white paper from Symantec on digital certificates used for authentication.

When it is all said in done, Insecam victims used default ports and passwords and were most likely discovered by an IP address surfing tool. A simple change of the password would eliminate them from the site but it could still be guessed by a serious stalker. Keep in mind that passwords are the number one thing sought after by hackers since we often use the same ones on multiple sites. Here is how they do it.

Encryption; an IoT solution

As a best PKI practice, all data SHOULD be encrypted in transit and at rest between a Host and Client. If the device manufactures enabled encryption of the data, only the end user could review the video stream with client authentication. This would slow the feed a bit but it would secure the connection. If marketers want to instill trust in their internet connected devices they need to consider implementing a security promise with their messaging. So how can they encrypt a live feed?

My engineering buddy and counterpart Frank Agurto-Machado recommends the use of embedding a private SSL ROOT CA within each device. The connection between the manufacture’s infrastructure and the camera would be secured and encrypted via client authentication to this private SSL root. Ultimately, this may increase the cost of a device but it would help better ensure security. While this DOES NOT remedy the Password hijacking, it secures the model from point-to-point between the “client” and the host. Symantec offers Private CAs to enterprises that need customized encryption for server to server communication or for applications such as this.

The Security Trade-Off

Balance Act_0.jpg

Throughout the course of world history humans have always had to juggle between access and fortification when it comes to security. Our ancestors had to find a way to secure a food hoard that would not take hours to hide or cover. Castles had to ensure soldiers and citizens could pass freely yet survive a siege. Anti-virus software on your PC has to allow you to quickly surf the internet but check and possibly restrict all incoming traffic. Manufactures within the IoT space have to learn how to balance these two and improve customer messaging to assist them in setting up a trustworthy and secure devices.

Edit: Since the writing of this blog insecam has been shut down. From appearances it appears to be taken down by a third-party hacker.

The SSL 3.0 Vulnerability – POODLE Bug (AKA POODLEbleed)

Hacker Medic October 15, 2014 No Comments

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

Hacker Medic October 15, 2014 No Comments

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.

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:

usar la caja de herramientas de SSL, un recurso gratuito de Symantec, para comprobar si los servidores web de la empresa corren peligro;
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;
desactivar el uso de conexiones SSL 3.0 o el cifrado en modo CBC con SSL 3.0;
usar un firewall para aplicaciones web basado en la nube para extremar las precauciones (más información en nuestro sitio web);
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:

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);
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»;
estar pendiente de los avisos que reciban de sus proveedores de servicios y cambiar las contraseñas o actualizar el software si es necesario;
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 Twitter o Facebook. 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)

Hacker Medic October 15, 2014 No Comments

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.

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:

Überprüfen Sie mit unserer kostenlosen SSL-Toolbox, ob Ihre Webserver gefährdet sind.
Verwenden Sie Tools, die TLS_FALLBACK_SCSV unterstützen. Dieser Mechanismus verhindert, dass Angreifer Webbrowser zur Verwendung von SSL 3.0 zwingen können.
Deaktivieren Sie SSL 3.0 vollständig oder deaktivieren Sie die Verschlüsselung im CBC-Modus von SSL 3.0.
Eine cloudbasierte Firewall für Webanwendungen kann vor einer Schwachstelle dieser Art schützen. Weitere Information finden Sie auf unserer Website.
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:

Stellen Sie sicher, dass SSL 3.0 bei Ihrem Browser deaktiviert ist (bei Internet Explorer beispielsweise unter „Internetoptionen > Erweiterte Einstellungen“).
Vermeiden Sie Man-in-the-Middle-Angriffe, indem Sie kontrollieren, ob „HTTPS“ auf den von Ihnen besuchten Websites immer aktiviert ist.
Beachten Sie alle Benachrichtigungen der Hersteller der von Ihnen verwendeten Softwareprodukte mit Empfehlungen zur Aktualisierung der jeweiligen Software oder der zugehörigen Kennwörter.
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)

Hacker Medic October 15, 2014 No Comments

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).

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 :

Pour savoir si vos serveurs Web courent un risque, utilisez notre service gratuit SSL Toolbox.
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.
Désactivez complètement le protocole SSL 3.0 ou désactivez le cryptage en mode CBC SSL 3.0.
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.
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 :

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).
Pour vous prémunir contre les attaques MITM, veillez à la présence du préfixe « HTTPS » dans la barre d’adresse de votre navigateur.
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.
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.

Nouveau cap technologique pour les certificats SSL

Hacker Medic October 13, 2014 No Comments

The next change for SSL Certificates

Certificate Transparency (CT) est un projet Google de journalisation, d’audit et de surveillance des certificats émis par les autorités de certification (AC). Le but de cette initiative est d’empêcher les AC d’émettre des certificats à clés publiques à l’insu des propriétaires des domaines concernés. En ce sens, Google Chrome exige des autorités de certification qu’elles enregistrent tous leurs certificats SSL Extended Validation (EV) dans des registres vérifiables publiquement, condition indispensable à l’affichage de la barre d’adresse verte dans son navigateur. Ce billet fait le point sur l’implication d’un tel changement dans SSL, tout en détaillant le plan d’accompagnement des clients Symantec dans cette transition.

Prévention des émissions non autorisées

Composante indispensable des systèmes de sécurité en ligne, les certificats SSL protègent les opérations d’e-commerce, les transactions de banque en ligne, ou plus simplement les serveurs de messagerie électronique. Un certificat SSL remplit deux grandes fonctions :

Il crypte les échanges entre un navigateur client et un site Web pour prévenir toute lecture de ces informations par un tiers.
Il fournit aux internautes des informations fiables sur l’identité du site Web qu’ils visitent.

À l’image de Symantec, les autorités de certification (AC) émettrices de certificats SSL procèdent à une validation rigoureuse de ces informations d’identification. Pour ce faire, elles investissent des moyens conséquents dans la vérification de l’identité des entreprises et de leurs droits de propriété sur les sites Web à protéger. Ce n’est qu’au terme de cette procédure que des certificats OV (Organization Validation) ou EV (Extended Validation) sont délivrés. Toutefois, toutes les AC ne se valent pas, comme en témoignent certains cas récents de certificats émis pour des sites Web réputés à la demande de tiers non autorisés.

La détection rapide de ces émissions non autorisées joue un rôle crucial dans l’élimination de la fraude aux certificats. À cet égard, Certificate Transparency (CT) offre un mécanisme préventif viable.

Fonctionnement de Certificate Transparency (CT)

CT repose sur quatre acteurs principaux :

Les AC
Les serveurs de journalisation – qui servent de référentiels publics des certificats SSL
Les auditeurs (navigateurs Web ou tout client qui accepte les certificats SSL)
Les contrôleurs

Avant d’émettre un certificat SSL, une AC envoie toutes les informations afférentes à un ou plusieurs serveurs de journalisation auxquels l’AC et les auditeurs font confiance. Le serveur de journalisation accepte le certificat et émet une vérification unique et cryptographiquement inviolable à l’attention de l’AC. C’est ce que l’on appelle l’horodatage de certificat signé – SCT. Ainsi, lorsque l’AC émet le certificat, elle y intègre cette/ces preuve(s). Il existe d’autres moyens de les obtenir, mais nous y reviendrons plus tard.

Système TLS/SSL actuel vs. TLS/SSL avec CT

Lorsqu’un navigateur se rend sur un site Web équipé d’un certificat SSL, il valide d’abord ce certificat sur la base d’une série de vérifications standard. Le projet CT propose que les navigateurs, qui jouent le rôle d’auditeurs dans son mécanisme, passent également en revue les preuves SCT incluses dans le certificat. CT fournit des indications quant au nombre de preuves qu’un certificat doit apporter en fonction de sa période de validité. Un navigateur vérifie donc les preuves SCT émises par les serveurs de journalisation de confiance. Pour être valide, une preuve SCT doit être émise par un serveur de journalisation dont le navigateur détient la clé publique, signe de sa fiabilité. Notons que dans ce cas, le navigateur n’effectue pas une vérification en temps réel auprès du serveur de journalisation. Aujourd’hui, seul Google Chrome prévoit d’appliquer le mécanisme CT. Le principal rôle du navigateur est d’inciter les AC à publier les certificats qu’elles comptent émettre et à y inclure une/des preuve(s) d’une telle publication.

Il est possible de développer et déployer des contrôleurs CT chargés de vérifier les certificats nouvellement ajoutés aux serveurs de journalisation. Cette surveillance a pour objectif de détecter toute émission non autorisée de certificat pour des sites Web particuliers.

Hormis leur intégration aux certificats SSL, les preuves SCT peuvent se présenter sous la forme d’extensions TLS ou d’« agrafages OCSP » (OCSP stapling). Ces méthodes nécessitent cependant une configuration avancée des serveurs Web.

CT constitue un bon moyen de rassembler tous les certificats SSL émis au sein d’un ou plusieurs référentiels publics. Si une AC décide de ne pas inscrire ses certificats SSL sur des serveurs de journalisation, libre aux navigateurs de leur faire confiance ou non. Dans la configuration CT initiale, prévue début 2015, le navigateur Google Chrome n’affichera plus la barre d’adresse verte pour les certificats EV n’intégrant pas les preuves SCT requises. D’aucun pourront rétorquer qu’au lieu de créer des référentiels publics, il est toujours possible d’examiner tous les certificats publiquement accessibles afin de détecter d’éventuelles émissions non autorisées. Toutefois, cette méthode prendra certainement plus de temps qu’une simple vérification des preuves de publication. Ainsi, la valeur intrinsèque de CT repose sur sa mise en application par le/les navigateur(s). En d’autres termes, en l’absence d’un vaste pool diversifié de contrôleurs CT, ce projet ne pourra pas tenir toutes ses promesses. Or, à l’heure de la rédaction de ce billet, Google Chrome est le seul grand navigateur s’engageant officiellement à prendre en charge CT. En outre, l’efficacité du système CT passe aussi par son intégration des applications PC/mobiles et des services Web présents dans l’écosystème SSL.

Étant donné qu’ils n’ont pas à passer tout le Web au crible, les contrôleurs CT sont appelés à détecter relativement plus rapidement les émissions non autorisées de certificats. Toutefois, tous les propriétaires de sites ne disposeront pas des ressources nécessaires au développement et à l’exécution de tels contrôleurs. Seules les grandes entreprises sont donc susceptibles d’en créer.

CAA, une alternative ?

En réalité, CT ne résout pas le problème des émissions non autorisées, mais facilite leur détection. D’autres solutions comme CAA (Certification Authority Authorization) recourent à des méthodes différentes pour réellement agir sur la prévention des émissions non autorisées. Dans CAA, un propriétaire de site Web spécifie dans les enregistrements DNS l’AC autorisée à émettre des certificats pour son site. Avant d’émettre un certificat, chaque AC participante doit donc vérifier qu’elle y est autorisée. Certes, ses détracteurs pourront toujours arguer qu’un tel système n’a rien de contraignant. Mais, si sa mise en application par les auditeurs/navigateurs suit un schéma similaire à celui de CT, alors CAA pourra lutter efficacement contre les émissions non autorisées de certificats.

Ce que Symantec peut faire pour vous

Nous envisageons de lancer une grande concertation avec tous nos clients SSL EV existants pour définir ensemble leurs exigences de confidentialité sur leurs certificats SSL EV internes. Ainsi, nous veillerons à ce que leurs données internes restent privées et n’apparaissent pas sur les registres CT publics. Quant aux certificats SSL EV externes, ils seront automatiquement publiés dans les registres CT d’ici février 2015, ce afin de maintenir l’affichage de la barre d’adresse verte dans Chrome. Enfin, la publication CT sera facultative sur les futurs certificats SSL EV. Pour en savoir plus, lisez l’article de notre base de connaissances sur le sujet.

Restez connecté

Pour ne rien manquer de l’actu sécurité et des derniers articles de nos blogs, suivez-nous sur Twitter ou sur Facebook. Pour des conseils et solutions aux problèmes utilisateurs les plus courants, rejoignez notre forum spécial support.

Nuevos horizontes para los certificados SSL

Hacker Medic October 13, 2014 No Comments

The next change for SSL Certificates

Certificate Transparency (CT), o transparencia de los certificados, es una iniciativa de Google que aspira a registrar, auditar y supervisar los certificados que emiten las autoridades de certificación. El objetivo es evitar que estas emitan certificados de clave pública para un dominio sin que lo sepa el propietario del mismo. Dado que Chrome se acogerá a esta iniciativa, dicho navegador solo seguirá mostrando la barra de direcciones verde propia de los certificados SSL con Extended Validation si la autoridad de certificación emisora los ha registrado previamente en un servidor público y auditable que solo permita anexar datos. A continuación, explicamos en qué consiste exactamente el cambio y qué ayuda prestará Symantec a sus clientes para que la transición sea lo más sencilla posible.

Medidas para asegurar que los certificados se emitan a quien corresponde

Los certificados SSL son esenciales para proteger a quienes compran por Internet, realizan operaciones de banca electrónica o, simplemente, consultan su correo electrónico. Estos certificados desempeñan dos funciones principales.

En primer lugar, cifran la información que se intercambia entre el sitio web y el navegador de quien lo visita, de forma que sea imposible interceptarla.
En segundo lugar, indican a los internautas a quién pertenece el sitio web, lo cual es igual de importante.

Las autoridades de certificación que emiten certificados SSL con validación de empresa (OV) o con Extended Validation (EV), como es el caso de Symantec, siguen procedimientos de autenticación muy rigurosos. Sin embargo, no todas son iguales. Algunas han emitido certificados para sitios web destacados a personas no autorizadas que nunca deberían haberlos obtenido.

Si sucede algo así, es importante detectarlo a tiempo para evitar males mayores. La iniciativa Certificate Transparency (CT) tiene como objetivo facilitar este proceso.

La iniciativa CT, al detalle

Hay cuatro elementos que hacen posible esta iniciativa.

Las autoridades de certificación.
Los servidores de registro, que proporcionan un listado público de certificados SSL.
Los auditores (en este caso, navegadores web o clientes que aceptan certificados SSL).
Los llamados «monitores».

Una autoridad de certificación que desee cumplir los requisitos de la iniciativa CT deberá enviar toda la información relativa al certificado a uno o varios servidores de registro que tanto ella como los auditores consideren de confianza. El servidor aceptará el certificado y le facilitará una marca de verificación cifrada e imposible de manipular llamada SCT (Signed Certificate Timestamp). Al emitir el certificado, la autoridad de certificación deberá incluir al menos un elemento de prueba de este tipo, a no ser que se utilicen otros métodos, como los especificados en el apartado siguiente.

Diferencias entre el sistema TLS/SSL actual y el sistema TLS/SSL con CT

Cuando un navegador visita un sitio web protegido con tecnología SSL, realiza una serie de comprobaciones estándar para cerciorarse de que el certificado SSL sea válido. La iniciativa CT va más allá y convierte a los navegadores en «auditores» que comprueban si las SCT integradas en el certificado son válidas y si el número de elementos de prueba (que depende del periodo de validez del certificado) coincide con el estipulado en las directrices pertinentes. A la hora de validar las SCT, el navegador se basa en los servidores de registro que considera de confianza. Para dar las SCT por válidas, la clave pública del servidor de registro debe figurar en el listado de almacenes CT de confianza del navegador. Esto no significa que el navegador haga una comprobación en tiempo real en el servidor de registro: por ahora, solo Google Chrome tiene previsto incorporar la función CT, así que el papel principal del navegador es el de obligar a las autoridades de certificación a publicar los certificados que vayan a emitir e incorporar en ellos los elementos de prueba que lo demuestren.

Cualquiera podrá consultar los certificados que se han añadido hace poco a los servidores de registro. Basta con crear e implementar «monitores» que detecten si se han emitido certificados fraudulentos para determinados sitios web.

Los elementos de prueba SCT no solo pueden integrarse en los certificados SSL; también es posible «graparlos» a una respuesta OCSP o usar una extensión TLS, aunque estos métodos exigen conocimientos avanzados sobre configuración de servidores web.

La iniciativa CT pretende dejar constancia de todos los certificados SSL emitidos en uno o más almacenes públicos. Si una autoridad de certificación decide no publicar los certificados SSL que emite en los servidores de registro, los navegadores podrán tenerlo en cuenta a la hora de decidir si los aceptan. A principios del año que viene, fecha prevista para la adopción inicial, Google Chrome dejará de mostrar la barra de direcciones verde si un certificado con EV no incluye las SCT que demuestren que está en los registros. Hay quien considera que, para detectar la emisión errónea de certificados, no es necesario crear almacenes públicos, sino que bastaría con pasar revista a todos los certificados accesibles públicamente. Sin embargo, esto llevaría mucho más tiempo que verificar las pruebas de publicación antes de aceptar un certificado. Por otro lado, la iniciativa CT solo funcionará si los navegadores son compatibles con ella; de lo contrario, la falta de «auditores de CT» y la escasa variedad de estos limitará su valor. Por ahora, de todos los navegadores más usados, solo Google Chrome tiene previsto adoptar este sistema. Además, existe otro problema: a menos que los servicios web y las aplicaciones para móviles y ordenadores se sumen a esta iniciativa, tampoco se logrará la eficacia deseada, pues dichos elementos también forman una parte esencial del entorno SSL.

Los «monitores de CT» permitirán detectar si se han emitido certificados por error sin necesidad de hacer un barrido completo de Internet, con el consiguiente ahorro de tiempo. Sin embargo, no todos los propietarios de un sitio web disponen de los recursos necesarios para crearlos y utilizarlos, así que es muy probable que solo las grandes empresas lo hagan.

CAA, una posible alternativa

La iniciativa CT no resuelve los errores relacionados con la emisión de certificados, pero sí facilita su detección. Hay otras soluciones, como el sistema CAA (Certification Authority Authorization), que utilizan mecanismos distintos para conseguir que solo se emitan certificados a quien corresponde. Con CAA, el propietario de un sitio web especifica en los registros DNS qué autoridad de certificación puede emitir certificados para su sitio web. Todas las autoridades de certificación que utilicen CAA deberían consultar esta información antes de emitir un nuevo certificado para comprobar si están autorizadas a hacerlo. Aunque respetar estos requisitos no es obligatorio, el sistema CAA podría ser igual de eficaz que la iniciativa CT si su aplicación se controlara mediante navegadores o auditores.

Apoyo a nuestros clientes

Symantec se pondrá en contacto con todos clientes que ya tengan certificados SSL con EV. En el caso de los certificados internos, les explicaremos cómo proteger los datos confidenciales para que no aparezcan en los registros de CT públicos. Los certificados SSL con EV externos se publicarán automáticamente en los registros de CT antes de febrero de 2015 para que, al acceder desde Chrome a los sitios web que protegen, siga viéndose la barra de direcciones verde. En adelante, los solicitantes de certificados SSL con EV podrán especificar si aceptan o no la publicación de sus certificados en los registros. Este artículo de nuestra base de conocimientos contiene más información al respecto.

Manténgase al día de las novedades

Síganos en Twitter o Facebook para estar al corriente de las últimas noticias sobre seguridad y de las nuevas entradas de nuestro blog. También le invitamos a pasarse por nuestro foro de asistencia, en el que encontrará consejos y soluciones a los problemas más frecuentes.