Monthly Archives: November 2013

CVE October Awareness Bulletin

[Following previous month’s CVE Awareness Bulletin here and here, below the October release]

The CVE October Awareness Bulletin is an initiative that aims to provide further intelligence and analysis concerning the last vulnerabilities published by the National Institute of Standards and Technology (NIST), National Vulnerability Database (NVD) and the IDS vendors’ coverage for these vulnerabilities.

Common Vulnerabilities and Exposures (CVE) is a public list of common names made available by MITRE Corporation for vulnerabilities and exposures that are publicly known.

This is the most popular list of vulnerabilities and is used as a reference across the whole security industry. It should not be considered absolute but due to the nature of its mission and the current sponsors – Department of Homeland Security (DHS), National Cybersecurity and Communications Integration Center (NCCIC) – it is widely adopted across the industry.

Based on this public information I decided to take a look at what has been released during the month of October. There were 582 vulnerabilities published where 78 were issued with a Common Vulnerability Scoring System (CVSS) score of 8 or higher – CVSS provides a standardized method for rating vulnerabilities using a scoring system based on their different properties from 1 to 10. From these security vulnerabilities, I compared the last signature updates available from products that have a significant share of the market i.e., Checkpoint, Tipping point, SourceFire, Juniper, Cisco and Palo Alto. The result is that Juniper, SourceFire and TippingPoint has the best coverage with 13%. Checkpoint and Cisco rank second with 12% whereas was the last Palo Alto with 1% coverage.

The following graph illustrates the mapping between the CVEs published in October with a CVSS equal or higher than 8 by vulnerability type and the vendor coverage:



In addition to looking at all the vulnerabilities released, it is also essential to look into detail for specific coverage like Microsoft products vulnerabilities. On the 8th of October the Microsoft Security Bulletin (a.k.a Patch Tuesday) announced 27 vulnerabilities. From these 14 have a CVSS score equal or higher than 8. From these the vendor coverage is shown in the following table:


The vendors analyzed have provided signatures on the same date (8 of October) or few days later. The mentioned signatures and patches should be applied as soon as possible but you should also fully evaluate them (when possible) before applying it production systems.

In addition to that, following signature update deployment, you should always check which signatures have been enabled by default.  Plus you should be evaluating what is the impact in your environment for the CVEs that don’t have coverage.

Bottom line, the vendors that were analyzed have a quick response but the coverage should be broader. September we saw 78 vulnerabilities with a CVSS higher than 8 but only 13% of them have coverage in the best case (SourceFire, Juniper and TippingPoint). This means 87% of the published vulnerabilities don’t have coverage. Regarding the vendor response to the Microsoft Security Bulletin Summary for October 2013, the coverage is better and goes up to 30% in the best case (Juniper, SourceFire and TippingPoint). Interesting to note that some of these vulnerabilities are related to software that don’t have significant share in the market. Even if the vendors would have 100% coverage they would not apply to all environments. Furthermore, the likelihood of these vulnerabilities to be successful exploited should also be considered since some of them could be very hard to pull off. So it’s key that you know your infrastructure, your assets and mainly where are your business crown jewels. Then you should be able to help them better protect your intellectual property and determine will be the impact if your intellectual property gets disclosed, altered or destroyed.

Tagged , , , ,

Crypto Basics

“In order to understand security in cyberspace, you need to understand cryptography. You don’t have to understand the math, but you have to understand its ramifications” – Bruce Schneier

Following my previous articles here and here about Public Key Infrastructure (PKI) let’s reinforce and review the crypto stuff  that makes its foundations.

Confidentiality ensures that a message can be read only by the intended recipient. Confidentiality is achieved through the use of encryption. Encryption is the mathematical transformation of plain text into ciphertext using an algorithm and a key. There are two types of encryption systems:

  • Symmetric Encryption: Also called shared-key encryption or secret-key cryptography, A symmetric encryption algorithm uses a single key that both the sender and recipient possess. The same key is used to encrypt and decrypt data and is shared by both parties.  If Alice wants to send Bob a secret document they agree on a cryptosystem and a common key. Alice encrypts the secret document (plaintext) using the agreed algorithm and the secret key. This will produce a encrypted document (ciphertext) that she will sent to Bob. Bob will decrypt the document using the same algorithm and same key and reads it. Example of symmetric encryption algorithm are DES, 3DES, RC2 or AES. The following picture illustrates this process.

Symetric crypto

Let’s see how we could encrypt (enc) a plaintext document (-in) using a symmetric algorithm (-des3) using a key (-k) to produce a ciphertext document (-out). This will be done on a Linux command line with OpenSSL.

$openssl enc -des3 -k secretkey -in plaintext.doc -out ciphertext.bin

Now that we have our encrypted the plaintext document lets dump the contents of both files in hexadecimal and ASCII (hexdump -C) both files to see the plaintext and the gibberish.

$ hexdump -C plaintext.doc
00000000  74 6f 70 73 65 63 72 65  74 0a                    |topsecret.|
$ hexdump -C ciphertext.bin 
 00000000  53 61 6c 74 65 64 5f 5f  2a 34 ce d4 6f 43 6b 93  |Salted__*4..oCk.|
 00000010  2f 41 5e 00 aa 14 e7 60  ce 89 66 35 2c 08 60 99  |/A^....`..f5,.`.|

We can also encrypt files on Windows system by taking advantage of the EFS functionality. To do this operation we will need to first generate a new certificate and key (cipher /K). Then we could encrypt (/E) a plaintext document using a symmetric algorithm. This will be done on a Windows command line with cipher /E. We can then display information about the encrypted with (/C).

c:\TopSecret> cipher /K
EFS certificate thumbprint for computer HOST:
7FE0 9328 7CBF 915D 672C B617 2368 A34E BC33 FE7E
c:\TopSecret> cipher /E plaintext.doc
Encrypting files in c:\TopSecret
plaintext.doc [OK]
1 file(s) [or directorie(s)] within 1 directorie(s) were encrypted.
c:\TopSecret> cipher /C plaintext.doc
Listing c:\TopSecret\
New files added to this directory will not be encrypted.
E plaintext.doc
Compatibility Level:
Windows XP/Server 2003
Users who can decrypt:
 Host\Alice [Alice(Alice@Host)]
 Certificate thumbprint: 5DFF 4841 DA18 6D3B 5646 246B 71E3 EC3B 735A 9BC6
No recovery certificate found.
Key Information:
 Algorithm: AES
 Key Length: 256
 Key Entropy: 256
  • Asymmetric encryption: Unlike the symmetric encryption that uses the same key, asymmetric encryption uses multiple keys. There are two mathematically related keys. It’s a key pair consisting of a public key and a private key which are used for the encryption and decryption process. If the public key is used for encryption, the associated private key is used for decryption – this is the encryption process. If the private key is used for encryption, the associated public key is used for decryption – this is the signing process. The private key should be kept secret and the public key can be freely distributed. The public key which can be an attribute of a digital certificate is usually published in a public directory service such as LDAP or Active Directory. You can also combine public-key encryption with hash algorithms to produce a digital signature. If Alice wants to send Bob a secret document they agree on a public-key cryptosystem. Bob then sends Alice his public key. Alice encrypts the secret document using Bob’s public key and sends it to Bob. Bob will decrypt the document using the same algorithm and his private key. Example of asymmetric encryption algorithms are RSA, DSA, ElGamal, and ECC. Below is an illustration of this process using a public directory service:

 Assymetric crypto

Let’s see how Bob could create a RSA key pair (genrsa) and save it to a file (bob-privatekey.pem). Then Bob will export his public key  (-pubout) and save it a file (bob-publickey.pem).

Bob@host:~$ openssl genrsa -out bob-privatekey.pem 2048 Generating RSA private key, 2048 bit long modulus

e is 65537 (0x10001)
Bob@host:~$ openssl rsa -in bob-privatekey.pem -pubout -out bob-publickey.pem writing RSA key

Alice can now use Bob public key to send her a encrypted version of the plain text document. Alice will use the RSA algorithm (rsautil -encrypt) with Bob public key (-pubin bob-publickey) to encrypt plaintext (-in plaintext.doc) and save the ciphertext to a file (-out ciphertext.bin).

Alice@debian:~$ openssl rsautl -encrypt -pubin -inkey bob-publickey.pem -in plaintext.doc -out ciphertext.bin

Alice then sends the cipher document to Bob. Bob can now use is private key to decrypt the file and read it.

Bob@debian:~$ openssl rsautl -decrypt -inkey bob-privatekey.pem -in ciphertext.bin -out plaintext.doc

Integrity assures the recipient that a message has not been altered. Integrity is achieved through the use of hashing functions. Hashing is the mathematical result of taking the plain text (arbitrary length data) as input and producing a fixed-length output. The result is called message digest or fingerprint. Passing the same plain text through a hash function always produces the same result. If a single character is changed in the plaintext document, the resulting message digest will be different. Hash algorithms like MD5 and SHA1 are commonly used. Hash functions are used in digital signatures, since they can be efficiently used for detecting message tampering. If Alice wants to send Bob a document and they want to ensure the document has not been changed. Alice and Bob agres on the hashing algorithm. Alice produces a one-way hash of the document. Alice sends the document and the hash  to Bob. Bob produces the one-way hash of the document using the same hash function. If the hash match the hash generated then Bob can attest its integrity.

Hashing function

Let’s see how we could produce the  plaintext document message digest using a  hashing algorithm (sha1). This will be done on a Linux command line with OpenSSL and/or sha1sum.

user@debian:~$ openssl sha1 plaintext.doc 
SHA1(plaintext.doc)= a5e1d5a106a4dc55eb5bf7b4c6c32b411702e358

user@debian:~$ sha1sum plaintext.doc a5e1d5a106a4dc55eb5bf7b4c6c32b411702e358 plaintext.doc

On a Windows system we can produce the  plaintext document message digest using a  hashing algorithm (sha1) using the Microsoft fciv utility.

c:\TopSecret>fciv.exe -sha1 plaintext.doc
// File Checksum Integrity Verifier version 2.05.
0e029f230b119861e0358978f6b088752216221e plaintext.doc

Authentication and Non-Repudiation assures the recipient of  a message that the originator participated in the transaction and is who he or she claims to be. Authentication and non-repudiation is achieved through a combination of asymmetric encryption and hashing functions. Although encryption can keep data secret and protect against alterations, a digital signature proves the senders identity (authentication) and ensures the participation of the signer cannot be denied (non-repudiation).  If Alice wants to digital sign a document and sent it to Bob they both agree on digital signature algorithm. Alice produces a one-way hash of the document. Alice encrypts the hash with her private key, thereby signing the document. Alice sends the document and the signed hash to Bob. Bob produces the a one-way hash of the document using the same hash function. Then using the digital signature algorithm, decrypts the signed hash with Alice’s public key. If the signed hash match the hash generated then Bob can attest the signature is valid (authentication and non-repudiation). The following picture illustrates this process.

Digital signing

Lets demonstrate how we could digital sign a message using OpenSSL. To sign plaintext.doc you need to calculate its hash (dgst -sha1)  and then encrypt (-sign) that hash using your private key (privatekey.pem) and save the result to file (alice-signature.bin).

Alice@host:~$ openssl dgst -sha1 -sign alice-privatekey.pem -out alice-singature.bin plaintext.doc

Then Alice sends the signature and the plaintext to Bob. Alice public key is made available to Bob (e.g Ldap, ActiveDirectory, etc). Bob then can verify the signature of a message attesting its proof of origin and integrity.

Bob@host:~$ openssl dgst -sha1 -verify alice-publickey.pem -signature alice-singature.bin plaintext.doc Verified OK

Hopefully, with this article you now have a slight better understanding on how cryptography protects users by providing functionality for the encryption of data and authentication of other users. Symmetric-key encryption is a excellent method for quickly and securely encrypting data. However, the condition that sender and receiver must exchange a secret key before data can be exchanged is its weakness and limitation. Combining symmetric algorithms to encrypt the data with public-key algorithms to exchange the secret key produces a solution that is both fast and scalable.

It was also described with illustrations how someone can achieve confidentiality trough the use of symmetric and/or asymmetric encryption systems. How hashing functions are used to achieve integrity. Moreover how to combine encryption systems and hashing functions to produce digital signatures and achieve authentication and non-repudiation. With the use of the most famous characters – Alice and Bob – in modern cryptography examples were complemented with the usage of simple OpenSSL and Microsoft EFS commands.

Cryptography is a colossal, fascinating and mysterious world. If you like cryptography and you want to better understand the techniques and concepts behind it then a indispensable reference is the Applied Cryptography: Protocols, Algorithms and Source Code in C by Bruce Schneier. For a brilliant review of the history behind cryptography than David Kahn’s The Code Breakers is essential. If you would like to read about the intriguing stories of espionage behind the history breakthroughs of codes and code breaking then Simon Singh The Code Book is a must.

For a more hands-on approach the CrypTool – project started by Prof. Bernhard Esslinger – is the most complete e-learning tool available to raise awareness and increase the interest in cryptography. CrypTool v1 was originally designed as a business application for information security training but is now an important open-source Windows project in the field of cryptology. Successors are CrypTool v2 (for Windows .NET) and JCrypTool (for Unix, Windows and MacOS). As a complement to these offline CrypTool programs there is the MysteryTwister C3 (MTC3) international cryptography competition. This website offers four levels of cipher challenges from simple challenges consisting in breaking a Caesar cipher or solving the “Greetings from Russia with love” to complex crypto problems like RSA factoring — most of them embedded in interesting stories.


B. Komar, Microsoft Press, Windows Server 2008 PKI and Certificate Security
B. Schneier, John Wiley, Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd ed.
J. Viega; M. Messier and P. Chandra, O’Reilly, Network Security with OpenSSL
CrypTool 1.4.31

Tagged , , ,