Welcome to the Acumen Security Blog

Car Hacking

As computers have went from luxuries to necessities in our daily lives they have solved many problems for a lot of people and made life easier. The problem is that it also applies to people who wish to harm others in various ways.

First, let us take into consideration the car hacking that has surfaced over the past couple of years. Research has shown that it is possible, it is dangerous and we need to be prepared to protect ourselves or be protected by the manufacturers. We definitely do not need to wait until serious damage is done before we fix a problem that will cause serious issues. Vehicle manufacturers are already making improvements to the development process to include more robust security measures to be in place for these interconnected automobiles.

Second, I imagine it will not stop with just our personal vehicles. What about construction vehicles that are also working to implement telematics systems that give companies the ability to monitor vehicles through GPS, cellular or Wi-Fi? A hacked dozer could do some serious damage. I do not know what those companies have in place for securing the systems they are developing. I have made some calls but I have not received any responses yet.

This is a completely new topic to me and I will continue to follow it closely. As time goes on, I hope to see more awareness, not just in vehicle computer security, but in security as a whole whenever a computer is involved. We can make things easy but if it’s not safe we may lose just as much as we thought we gained or more.

The certification community already have a set of best practices around protection of data (e.g., cryptography) and secure management.  Now, the certification industry is presented with an opportunity to be involved in the growing industry of connected vehicles before some of the same mistakes are made in the industries before them.


More than 11 million websites and e-mail services protected by the transport layer security protocol are vulnerable to a newly discovered, low-cost attack that decrypts sensitive communications in a matter of hours and in some cases almost immediately, an international team of researchers warned Tuesday March 1 2016. More than 81,000 of the top 1 million most popular Web properties are among the vulnerable HTTPS-protected sites.

This new vulnerability termed as DROWN (Decrypting RSA with Obsolete and Weakened encryption),CVE-2016-0800, a novel cross-protocol attack uses SSLv2 handshakes to decrypt TLS sessions. A patch is already available for countering the vulnerability and the users are advised to upgrade to the following respective versions-

  • OpenSSL 1.0.2 users are strongly advised to upgrade to OpenSSL 1.0.2g
  • OpenSSL 1.0.1 users are recommended to upgrade to OpenSSL 1.0.1s
  • If you are using another version of OpenSSL, you should move up to the newer versions 1.0.2g or 1.0.1s.


The vulnerability allows an attacker to decrypt an intercepted TLS connection by repeatedly using SSLv2 to make connections to a server. In the process, the attacker learns a few bits of information about the encryption key each time. In technical terms, DROWN is a new form of cross-protocol Bleichenbacher padding oracle attack. This attack has been leveraged into a new form of attack (DROWN) that allows an attacker to decrypt intercepted TLS connections by making specially crafted connections to an SSLv2 server that uses the same private key. The most important thing to note is that the attack is only successful if the private keys are same. According to best security practices, however, it is not advisable to reuse private keys. Often times, due to cost, organizations will use a single private key for multiple servers.

This type of attack makes use of bugs in one protocol implementation (SSLv2) to attack the security of connections made under a different protocol entirely — in this case, TLS. More concretely, DROWN is based on the critical observation that while SSLv2 and TLS both support RSA encryption, TLS properly defends against certain well-known attacks on this encryption — while SSLv2’s export suites emphatically do not and DROWN attack relies on a bug in the way OpenSSL handles SSLv2 key processing.


For many FIPS modules, this vulnerability will not directly affect their certifications for a number of reasons. For example, many software FIPS modules do not include protocol implementation within the FIPS boundary (typical FOM implementation) and SSLV2 itself is not a FIPS approved service. Common Criteria, on the other hand, includes a vulnerability assessment. Many certifying schemes include requirement that they will not post any certification for a product with a known vulnerability.