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.

Certificate Transparency

Hacker Medic October 13, 2014 No Comments

The next change for SSL Certificates

The next change for SSL Certificates

Certificate Transparency (CT) is a Google initiative to log, audit, and monitor certificates that Certificate Authorities (CAs) have issued. CT’s intent is to prevent CAs from issuing public key certificates for a domain without the domain owner’s knowledge. Chrome support for CT requires that all CAs log all Extended Validation (EV) SSL certificates in publicly auditable, append-only logs for the green address bar to appear in Chrome. Read more to understand this change within SSL and how Symantec plans on supporting their customers through this transition.

Impeding Mis-Issuance

SSL certificates are a critical and an integral part of online security when it comes to e-commerce, online banking, or simply checking your email. An SSL certificate performs two main functions.

It enables encryption between client browser and the website so that no one else can interpret the information exchanged between the two.
Equally important, it provides trusted identity information about the website to the end user.

Certification Authorities (CAs) that issue SSL certificates, like Symantec, rigorously validate this trusted information. CAs invest heavily in validating an organization’s information and ownership of the website before they issue Organization (OV) or Extended Validation (EV) certificates. However, not all CAs are created equal and in the past some have issued certificates for prominent websites to unauthorized parties.

Detecting mis-issuance in a timely manner can be very important in mitigating further misuse of fraudulent certificates. Certificate Transparency (CT) provides a viable mechanism to address this issue.

How CT Works

There are four main participants in CT:

CAs,
Log servers that act as public repository of SSL certificates,
Auditors (web browsers or any client that accepts an SSL certificate), &
Monitors.

Before issuing an SSL certificate, a participating CA sends all information about that certificate to one or more log servers, which are trusted by the CA and auditors. The Log server accepts the certificate and issues a cryptographically tamperproof unique verification (Signed Certificate Timestamp – SCT) to the CA. While issuing the certificate, the CA then includes such proof(s) inside the certificate. There are other ways to deliver these proofs but we will discuss them later in this blog.

The current TLS/SSL system vs. TLS/SSL with CT

When a browser visits an SSL enabled website, it first validates the SSL certificate against various industry defined checks. CT proposes that browsers who perform an auditor’s role in CT should also check for the SCT proofs included with the certificate. CT provides a guideline on how many proofs a certificate should have based on validity period of the certificate. A browser checks the SCT proofs based on the log servers it trusts. For a SCT proof to be valid, a browser must have the issuing log server’s public key in its CT trust store. It is important to note here that the browser does not make a real-time check with the log server. As of today only Google Chrome has planned to support CT. The browser’s role in CT is mainly to enforce that CAs publish certificates they are going to issue and include proof(s) of such publication.

CT monitors can be developed and deployed by anyone who wants to keep reviewing newly added certificates to log servers. The intention here is by monitoring log servers one can detect mis-issued certificates for specific websites.

Apart from embedding SCT proofs in SSL certificates they can be delivered as a TLS extension or via OCSP stapling. These methods require advance configurations on web servers.

CT is a good attempt to make available all issued SSL certificates in one or more public repositories. If a CA decides not to publish the issued SSL certificates to log servers then browsers can decide on how to treat that certificate. In its initial proposal, sometime early next year, Google’s Chrome browser will not be showing the “green browser bar” for EV certificates that do not include the required CT proofs with them. One can argue that instead of creating public repositories one can look at all publicly accessible certificates to detect mis-issuance. However, this may be more time consuming than just checking the proofs of publication before accepting a certificate. Thus the intrinsic value of CT is created by the enforcement of the browser(s). In the absence of a vast and diversified pool of CT auditors, it will not provide the full value it promises. At this time, except for Google Chrome, there are no published plans from any other major browsers to support CT. Additionally, desktop applications, mobile applications, and web services that are part of SSL ecosystem need to participate in CT for it to be truly effective.

CT monitors will be a good mechanism to detect mis-issuance relatively quicker than crawling the entire web. However, not every website owner will have resources to build and run such monitors. Only big companies are likely to build such monitors to detect any mis-issuance.

CAA, an Alternative?

One important thing to note is CT does not solve the problem of mis-issuance but makes it easier to detect errant issuance. There are other solutions like CAA, which focuses on preventing mis-issuance but in a different way. In CAA, a website owner specifies in the DNS records which CA can issue certificates to its website. Every CA that supports CAA is supposed to check for such authorization before issuing a certificate. One can argue that this is not mandatory but if auditor/browser enforcement is designed similar to what is present in CT, then CAA can be effective in preventing mis-issuance.

Data Privacy Challenges

From a privacy angle CT poses a challenge. If an authorized website owner for some reason does not want to publish its certificate details publicly then EV certificates may not work properly with browsers that enforce CT. Just think about a certificate issued for an internal website for a new product to a company that fiercely guards its new product information from being leaked, or a classified government project. CT must include a way to respect and handle such privacy.

How Symantec Helps

For customers with existing EV SSL certs, we will be reaching out to understand your privacy requirements on internal EV SSL certificates. We want to make sure that internal data remains internal and not be listed on public CT logs. External EV SSL certificates will be automatically published on the CT logs before February 2015 to help ensure that the corresponding external sites continue to be highlighted with the green address bar on Chrome. Future EV SSL certificates will come with an option to be published on the logs. To learn more please visit our knowledge base article.

Stay in Touch

Follow us on Twitter or Facebook to be kept apprise of the latest in security news and our latest blogs. Visit our support forum as well to get user hints and solutions to common user issues.

Die nächste Änderung für SSL-Zertifikate

Hacker Medic October 13, 2014 No Comments

The next change for SSL Certificates

Zertifikatstransparenz (Certificate Transparency, CT) ist eine Initiative von Google zur Protokollierung, Prüfung und Überwachung von Zertifikaten, die von Zertifizierungsstellen ausgestellt werden. Mit dieser Initiative soll verhindert werden, dass Zertifizierungsstellen ohne Wissen des Domäneninhabers Public-Key-Zertifikate (Zertifikate mit öffentlichem Schlüssel) für eine Domäne ausstellen. Zur Unterstützung von CT erfordert Google Chrome, dass alle Zertifizierungsstellen sämtliche SSL-Zertifikate mit Extended Validation (EV) in ein öffentlich prüfbares, nicht überschreibbares Verzeichnis eintragen, damit die grüne Adressleiste angezeigt wird. Nachfolgend finden Sie weitere Informationen zu dieser Änderung an SSL und dazu, wie Symantec seine Kunden bei dieser Umstellung unterstützen wird.

Erschwerung von Falschausstellungen

SSL-Zertifikate sind eine wichtige und zentrale Sicherheitskomponente in den Bereichen Online-Handel, Online-Banking und E-Mail. Ein SSL-Zertifikat hat zwei Hauptfunktionen:

Es ermöglicht die verschlüsselte Datenübertragung zwischen Browser und Website, damit niemand die Informationen mitlesen kann, die ausgetauscht werden.
Es stellt dem Benutzer vertrauenswürdige Identitätsangaben über die Website bereit.

Zertifizierungsstellen wie Symantec, die SSL-Zertifikate ausstellen, überprüfen diese Angaben in einem aufwendigen Verfahren. Dabei prüfen Sie sowohl die Angaben zum Unternehmen als auch seine Eigentumsrechte an der Website, bevor sie SSL-Zertifikate mit Unternehmensvalidierung (Organization Validation, OV) oder Extended Validation (EV) ausstellen. Allerdings sind nicht alle Zertifizierungsstellen gleich, weshalb es in der Vergangenheit vorgekommen ist, dass manche von ihnen unbefugten Antragstellern Zertifikate für bekannte Websites ausgestellt haben.

Die rechtzeitige Erkennung solcher Falschausstellungen ist bei der Verhinderung eines weiteren Missbrauchs betrügerisch erlangter Zertifikate sehr wichtig. Mit Certificate Transparency (CT) steht hierfür eine probate Methode zur Verfügung.

Funktionsweise von CT

CT beruht auf vier Säulen:

Zertifizierungsstellen,
Protokollierungsservern als öffentliches Repository für SSL-Zertifikate,
Auditoren (Webbrowser oder jeder Client, der ein SSL-Zertifikat akzeptiert) und
Überwachern.

Bevor eine teilnehmende Zertifizierungsstelle ein SSL-Zertifikat ausstellt, sendet sie sämtliche Informationen über dieses Zertifikat an mindestens einen Protokollierungsserver, der von der Zertifizierungsstelle und den Auditoren als vertrauenswürdig eingestuft wurde. Der Protokollierungsserver akzeptiert das Zertifikat und stellt der Zertifizierungsstelle eine kryptografisch gegen Manipulationen gesicherte eindeutige Verifizierung (Signed Certificate Timestamp, SCT) aus. Diesen Nachweis schließt die Zertifizierungsstelle bei der Ausstellung eines Zertifikats darin ein. Es gibt auch noch andere Möglichkeiten, diese Nachweise bereitzustellen. Darauf werden wir später in diesem Blog eingehen.

Das aktuelle TLS/SSL-System im Vergleich mit TLS/SSL mit CT

Wenn ein Browser eine SSL-geschützte Website aufruft, unterzieht er das SSL-Zertifikat zunächst verschiedenen branchendefinierten Prüfungen. CT sieht vor, dass Browser die Rolle eines Auditors übernehmen und auch die im Zertifikat enthaltenen SCT-Nachweise überprüfen. Die CT-Leitlinien geben Empfehlungen, wie viele Nachweise ein Zertifikat je nach Gültigkeitsdauer enthalten sollte. Ein Browser überprüft die SCT-Nachweise mithilfe der Protokollierungsserver, die von ihm als vertrauenswürdig eingestuft werden. Damit ein SCT-Nachweis als gültig akzeptiert wird, muss sich der öffentliche Schlüssel des ausstellenden Protokollierungsservers im CT Trust Store des Browsers befinden. Hierbei ist zu beachten, dass der Browser keine Echtzeitprüfung mit dem Protokollierungsserver vornimmt. Bis jetzt beabsichtigt nur Google Chrome die Unterstützung von CT. Die Rolle des Browsers bei CT besteht hauptsächlich darin, durchzusetzen, dass Zertifizierungsstellen veröffentlichen, welche Zertifikate sie ausstellen und den Zertifikaten Veröffentlichungsnachweise beifügen.

CT-Überwacher können von jedem entwickelt und implementiert werden, der regelmäßig Zertifikate prüfen will, die Protokollierungsservern neu hinzugefügt wurden. Hiermit wird bezweckt, dass durch die Überwachung der Protokollierungsserver für bestimmte Websites falsch ausgestellte Zertifikate erkannt werden können.

Außer durch die Einbettung in SSL-Zertifikate können SCT-Nachweise auch als TLS-Erweiterung oder per OCSP Stapling ausgeliefert werden. Für diese Verfahren müssen auf Webservern erweiterte Konfigurationen vorgenommen werden.

CT ist ein guter Ansatz dafür, sämtliche ausgestellten SSL-Zertifikate in mindestens einem öffentlichen Repository zur Verfügung zu stellen. Wenn eine Zertifizierungsstelle die von ihr ausgestellten SSL-Zertifikate nicht auf Protokollierungsservern veröffentlicht, können Browser entscheiden, wie sie mit einem solchen Zertifikat umgehen. Der ursprüngliche Vorschlag von Google sah vor, dass Chrome ab einem bestimmten Zeitpunkt im nächsten Frühjahr die Adressleiste im Browser für EV-Zertifikate ohne die erforderlichen CT-Nachweise nicht mehr grün anzeigt. Sicherlich könnte man, statt öffentliche Repositorys zu erstellen, auch sämtliche öffentlich zugänglichen Zertifikate überprüfen, um eine Falschausstellung zu erkennen. Allerdings wäre der Zeitaufwand hierfür wahrscheinlich wesentlich höher als für die Überprüfung der Veröffentlichungsnachweise, bevor ein Zertifikat akzeptiert wird. Daher besteht der inhärente Wert der CT in der Durchsetzung durch die Browser. Ohne einen großen und breit gefächerten Pool von CT-Auditoren wird CT nicht seinen vollen potenziellen Nutzen liefern. Außer Google Chrome hat bislang keiner der anderen großen Browser Pläne zur Unterstützung von CT veröffentlicht. Zudem müssten auch Desktop-Anwendungen, Mobilanwendungen und Webdienste, die Teil der SSL-Infrastruktur sind, an CT teilnehmen, damit sie wirklich effektiv wäre.

CT-Überwacher sind ein gutes Verfahren, mit dem sich falsche Ausstellungen deutlich schneller als mit einer Durchsuchung des gesamten Internets feststellen lassen. Allerdings hat nicht jeder Betreiber einer Website die erforderlichen Ressourcen, um solche Überwacher zu erstellen und auszuführen. Wahrscheinlich werden nur Großunternehmen solche Überwacher erstellen, um falsche Ausstellungen erkennen zu können.

CAA als Alternative?

Ein wichtiger Punkt ist, dass CT das Problem falsch ausgestellter Zertifikate nicht behebt, sondern nur die Erkennung solcher Zertifikate erleichtert. Es gibt andere Lösungen wie CAA, die das Problem auf andere Art und Weise angehen. Bei CAA gibt der Betreiber einer Website in den DNS-Einträgen an, welche Zertifizierungsstelle Zertifikate für seine Website ausstellen darf. Jede Zertifizierungsstelle, die CAA unterstützt, sollte vor der Ausstellung eines Zertifikats prüfen, ob eine solche Autorisierung vorliegt. Man kann dagegenhalten, dass dies nicht zwingend vorgeschrieben ist, aber wenn die Prüfung durch die Auditoren/Browser auf ähnliche Weise wie bei CT erfolgt, kann CAA die Ausstellung falscher Zertifikate effektiv verhindern.

Unterstützung von Symantec

Wenn Sie zu unseren Kunden zählen und bereits über EV SSL-Zertifikate verfügen, werden wir mit Ihnen Kontakt aufnehmen, um uns über Ihre Anforderungen bei der Datensicherheit interner EV SSL-Zertifikate zu informieren. Wir möchten sicherstellen, dass Ihre internen Daten intern bleiben und nicht in öffentlichen CT-Protokollen auftauchen. Externe EV SSL-Zertifikate werden bis Februar 2015 automatisch in den CT-Protokollen veröffentlicht, um sicherzustellen, dass die zugehörigen externen Websites in Chrome weiterhin mit einer grünen Adressleiste angezeigt werden. Bei zukünftigen EV SSL-Zertifikaten erfolgt die Veröffentlichung in den Protokollen optional. Wenn Sie hierüber mehr erfahren möchten, lesen Sie bitte den entsprechenden Artikel in unserer Online-Wissensdatenbank.

Bleiben Sie in Verbindung

Folgen sie uns auf Twitter oder Facebook, damit Sie über die neuesten Entwicklungen im Bereich Sicherheit und unsere neuesten Blog-Beiträge informiert werden. Besuchen Sie auch unser Support-Forum, um sich über Tipps und Kniffe zu informieren, mit denen Benutzer die gängigsten Probleme lösen können.