I was recently asked to comment on the compromise, or hack – although I don’t like to use that term in the context of criminal behavior, of a very popular regional website (see my comments here). The site’s homepage was replaced with an image of the Malaysian Coat of Arms and information about who was responsible for the attack. While not a desirable event to endure for any organization, the attack could have been much worse. How? In this case, the site was used for notoriety of the group responsible and not to attack the users of the site (read, the organizations customers and/or it’s data). The down time of the site was minimal, the real site was back online within minutes of the first reports of the defacement. So how does an organization handle such an event? This brings us into the often times confusing world of security. For anyone well-versed in security, and website security in particular, you probably already have several ideas as to what happened. For those not in security you probably have no idea where to begin. Instead of making this another article on the technical measures that can be put into place, I’m going to look at it from the business’s perspective. And in particular, a business that either doesn’t have the security professionals on staff or has hired out their technology services and therefore rely exclusively on a third-party. Continue reading
Sovereign Keys Introduction
Secure communication over the internet depends almost exclusively on Secure Sockets Layer (SSL) and/or Transport Layer Security (TLS). In order to understand the Electronic Frontier Foundation’s (EFF) Sovereign Keys proposal, we need to take a closer look at how public key cryptography works as well as the public key infrastructure (PKI) that is in place to manage the public/private keys that are relied on for TLS. After discussing public key cryptography and PKI, we will discuss current implementations of SSL/TLS and the numerous components therein: Domain Name System (DNS), Certificate Authorities (CA) and client/server implementation. Finally, we will discuss the primary weaknesses in the current implementation, the Sovereign Keys proposal and how it aims to remedy those weaknesses.
To begin, we need to understand public key cryptography, which is also known as asymmetric cryptography. In asymmetric cryptography there must exist two keys in which to provide for the desired cryptographic functions – namely the encryption/decryption of plaintext/ciphertext or the generation/validation of a digital signature. This differs from symmetric cryptography, which only utilizes a single key for desired cryptographic functions. The two keys utilized in asymmetric cryptography are commonly referred to as the public and private key. As the name implies, the public key is ultimately made public and utilized in encrypting plaintext and verifying digital signatures. Public keys are therefore made available to be public and not protected as a private key is. Private keys, on the other hand, are utilized to decrypt ciphertext (ciphertext is the result of running an encryption algorithm on plaintext) and to generate a digital signature. (“Introduction to Public-Key”, 2014)(“Public-key Cryptography”, 2014)
Shellshock Bash Bug
Everyone’s probably heard of the Shellshock Bash bug by now, which was announced with CVE-2014-6271 on September 24, 2014. According to the announcement:
GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution, aka “ShellShock.”