Blogs

    Publish
     
      • Who's Watching You Sleep?

        Nov 25 2014, 10:48 PM

        by Brook Chelmo 1

        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.

        • Products
        • website security solutions
        • Symantec Website Security
        • encryption
        • passwords
        • password
        • Identity and Authentication Services
        • IoT
        • DigiCert Code Signing
        • white hat
        • VIP (Validation ID Protection)
        • Products and Solutions
      • Perfect Forward Secrecy - Protecting the gateway to your world

        Jul 31 2014, 10:40 AM

        by Robert Lin 0

        Remember the movie "The Truman Show", where Jim Carrey played the main character of a TV show that chronicled the life of a man who was initially unaware that he was living in a constructed reality television show, broadcast around the clock to billions of people around the globe. Imagine that your organisation is chronicled the same way. Every online transaction, secured or not.

        That's what Heartbleed can do.  Fortunately most systems using OpenSSL libraries have been patched (hopefully) to counter this. What if there is another way that this can be done. That this could be happening right now, on a  daily basis and that this is not a vulnerability, but is actually how most clients connect to organisations during SSL/TLS negotitaions for the past decade?

        Fristly have a look at how SSL/TLS handshake works. 

        Consider this scenario:

        A script kiddie downloads Wireshark and uses it to track network activities within your organisation. Entire transations are recorded, including SSL sessions.  Several years later, after gaining much experience, he can now gain access to the servers and the expired Private Key pairs that were once used to encrypt these sessions. These sessions were encrypted with RSA key exchange. He emails the CSO, "I know what you did last summer".

        OK. A bit too dramatic and over the top, but perfectly possible. This is the flaw (not vulnerability) when using RSA Key Exchange in SSL/TLS negotiations without proper Key Management. As each session is related to the RSA private key used, recorded sessions can be decrypted later.

        An alternative to the RSA key exchange is to use another algorithm, Diffie-Hellman, which creates sessions that are not associated with the private key. Even if the session information is recorded there is no easy way to decipher the computations. With proper Diffie-Hellman implementation, encrypted information cannot be deciphered in the future. This is called Forward Secrecy.

        To see how Perfect Forward Secrecy can be be achieved, ready your coffee, get your thinking cap on and start reading the document attached. 

        • DSA
        • DigiCert Code Signing
        • key management
        • ECDHE
        • Security Community Blog
        • Products
        • TLS
        • Symantec Enterprise Security
        • Thought Leadership
        • ECC
        • Symantec Website Security
        • SSL
        • encryption
        • cipher
        • DHE
        • RSA
      • Think you're safe? Think again - SSL Attack Survey

        Aug 05 2014, 1:21 PM

        by Robert Lin 0

        Look! I have a lock, I see https://, I even see the Green Bar, I believe I have protected my server and the clients connecting to our services from attackers now. I can't start increasing security and block clients to my site by disabling SSLv3, MD5 or RC4. I'll be losing customers and profit! I can accept a weaker security as long as user traffic and profit are not affected.

        Performance vs Security is a constant struggle between security experts and management. When it comes to SSL it is no different. Do we allow as many clients to access our site as possible, or do we block all the weak connectivities. There has been numerous studies on this, so I won't go into it here. As a SSL security expert, allow me to take sides this time. Allow me to provide some more gear for us to convince our management why SSL security is more important and how we can migitate the risks without affecting performance or traffic too much.

        Last year September a comprehensive survey was done by iSECPartners,Inc on the various vulnerabilities with the SSL/TLS technology.

        Have a look: Attack on SSL

        • Products
        • TLS
        • Symantec Enterprise Security
        • Thought Leadership
        • Symantec Website Security
        • SSL
        • encryption
        • Vulnerabilities
        • DigiCert Code Signing
        • cipher
        • Security Community Blog
      • SSL Ciphers - Beyond Private key and Certificate

        Oct 20 2017, 8:35 PM

        by Robert Lin 2

        Today SSL is an integral part of online businesses and any secured communication. It is however not an area that many system administrators or security experts are comfortable with. For most administrators the correct installation of the private key and its corresponding certificate is sufficient. As long as the green bar, the padlock, or https:// can be seen during the SSL/TLS negotiation, both the administrators and their clients trust that the connectivity is secure.

        However many security flaws and vulnerabilities have been discovered in the recent years. From the server side there is the infamous Heartbleed bug or CCS injection - CVE-2014-0224, side-channel attacks such as Beast, Lucky 13, Crime or BREACH, and others (SSL Attack Survey).  It is not sufficient to just have a correct installation of the private key and certificate pair on the server. Beside patching up server libraries and client applications, additional control to SSL/TLS negotiations need to be applied. One of those control mechanisms is selecting the right cipher suite.

        The strength of an SSL/TLS negotiation depends not only the size of the private key or certificate. As of 2014, the recommended minimium key pair size is 2048 bit, however this does not guarantee maximum encryption sessions. During SSL/TLS handshakes, the agreement of what cipher suite to use determines if the negotiation will be using SSL or TLS protocols. It also determines the key exchange and encryption algorithms. If the agreed encryption level between the client and the server is low, the SSL/TLS session will still be vulnerable. For a system to be truly secure, strong cipher suites are required.

        To address this issue, a project was initiated. The result, "SSL/ TLS Cipher Suite Analysis and strong Cipher Enablement" is included in this blog.

        The purpose of this research is to provide an implementation process to set up a strongly secured SSL/TLS system by viewing the available cipher suites present in a system, recognizing the strength and weakness of the different ciphers and choosing the most applicable cipher suite.

        Note:  The configuration examples given in this document do not represent the complete or best set of strong ciphers to use. Depending on the various security policies and business requirements, the examples given in the document may not apply .

        • Products
        • Symantec Enterprise Security
        • Thought Leadership
        • ciphersecurity
        • Symantec Website Security
        • SSL
        • encryption
        • private key
        • DigiCert SSL TLS Certificates
        • certificate
        • cipher
        • Security Community Blog