Probing the Trustworthiness of Encryption Continues

The process of scrutinizing the OpenSSL source code, which began with the discovery of the Heart Bleed vulnerability, is continuing and picking up speed. As we previously foretold, professionals around the world have turned their heads to the encryption library, to better the way we keep our information safe. This is why, new vulnerabilities are bound to be discovered.  A fresh example of that, are the new vulnerabilities found just a day ago. The large number of nine new weaknesses, may frighten you at first, but what it really means is that much is done to patch the leaks and improve the user experience of the encryption library.

To put things in context we will spare few words for each of the newly found vulnerabilities:

•           There is a flaw in the OBJ_obj2txt that may cause pretty printing functions such as X509_name_online , X509_name_print_ex etc. to leak information. The vulnerability my affect some applications and cause them to echo pretty printing output to a malicious actor.

•           An issue allowing a malicious server to crash the client by specifying an SRP cipher suite even though it was not properly negotiated with the client.  This can be exploited through a DDoS attack.

•           Up to 255 bytes of freed memory can be written up if a multithreaded client connects to a malicious server with a resumed session and the server sends an ec point format extension.

•           An error condition can be forced by an attacker, crashing OpenSSL while processing DTLS packets, due to the double freeing of memory. This also can be exploited through a DDoS attack.

•           OpenSSl can be forsed to consume large amounts of memory while processing DTLS handshake messages. This can be exploited through a Denial of Service attack.

•           By sending carefully crafted DTLS packets an attacker could cause OpenSSL to leak memory. This can be exploited through a Denial of Service attack.

•           OpenSSL DTLS clients enabling anonymous (EC)DH cipher suites are subject to a denial of service attack. A malicious server can crash the client with a null pointer dereference (read) by specifying an anonymous (EC)DH cipher suite and sending carefully crafted handshake messages.

•           A flaw in the OpenSSL SSL/TLS server code causes the server to negotiate TLS 1.0 instead of higher protocol versions when the ClientHello message is badly fragmented. This allows a man-in-the-middle attacker to force a downgrade to TLS 1.0 even if both the server and the client support a higher protocol version, by modifying the client’s TLS records.

•           A malicious client or server can send invalid SRP parameters and overrun an internal buffer. Only applications which are explicitly set up for SRP use are affected.

To ease the nerves of our clients, we would like to state that we have done a timely operational update, that has patched all known vulnerabilities. We are currently running OpenSSL version 1.0.1i as it is secured from all discovered weaknesses of the encryption library source code and is recommended by the OpenSSL team.  The update of the OpenSSL library has been applied throughout our whole infrastructure and all of our Points of Presence are now patched for these vulnerabilities.

The cleaning up of OpenSSL’s source code is far from over. This means that there are surely new weak points to be found in the future and new fixes and patches to be applied. We would like to assure our customers that each fix is implemented within the shortest time possible and all of their information is safe with us. We strive to achieve utmost service excellence and lasting customer satisfaction, this is why we do our best to keep both our infrastructure and our software up-to-date and as secure as possible.

Attention Banks: Customer Confidence is in Your Hands!

Not long ago, the FFIEC released a statement aiming to give the heads up about the ever-so-popular use of Distributed Denial of Service attacks against financial institutions. The fact that for the first time a financial governing body is addressing cyber security in such a manner, is an indication of the growing risks and concerns over the rising number and frequency of cyberattacks.

The one particularly popular and devastating type of attack – Distributed Denial of Service or DDoS – was extensively explained in the NCCIC’s DDoS Quick Guide and is the reason behind the release of the FFIEC statement. With the financial sector increasingly dependent on technology, a somewhat moderate DDoS attack can lead to dire consequences. In the banking sector, it all comes down to preserving customer confidence in the institution and the sense of safety customers perceive when they are to entrust somebody with their money. Service outages during a DDoS attack, caused by the lack of preparedness, can lead to an immense decline in the confidence in a particular bank. Follows the downward spiral of revenue losses, declining liquidity and low capital adequacy.

Intentionally harming an institution’s reputation that result in material losses, is not the only damage a DDoS attack can do. Often the aim is to directly access and steal assets. How? A DDoS attack does not steal anything, you might say. It is accomplished by deploying the DDoS as a “smoke screen”, hiding ensuing intrusion attempts in an institution’s network. By flooding a server or the channel to it, the hacker not only severs public but also administrator access. When the attacker has grabbed an authentic customer’s credentials, they can easily transfer money out of the bank. All of this is done while the whole IT department is busy fighting the DDoS attack and discovers the assailant’s true purpose only when it’s too late to counteract effectively.

Vistnet is a battle-tested veteran in DDoS mitigation, thus is experienced, knowledgeable and skilled in fending off attackers and protecting an institution’s infrastructure, even under the most severe and complex attack vectors. Unlike other vendors, when things get strained, we do not null route a customer, so we can protect others on the network. Readily available burst capacity is at your disposal at all times with the sole purpose to do just the opposite: no null routing occurs – we just take the load off when you are bombarded with tremendous amounts of traffic. Our customers do not have to upgrade their plan with us due to the size of the attack. Nice isn’t it? You can rest assured that all of your services will remain available to your customers, no matter the type or size of the DDoS attack.

As people start to appreciate the real dangers DDoS poses to businesses and even more to financial institutions, as customers they may want you to show them a good reason to place their confidence in you. Do not take matters lightly. Professional teams with real expertise and technology is what’s needed to provide protection and mitigate attacks. We provide you with critically needed protection so you can live through even the most severe of DDoS attacks, without you even realizing one has occurred.

Stay Tuned For More Trouble With SSL

After the notorious Heartbleed vulnerability was found, researchers and programmers worldwide are turning their heads to the OpenSSL encryption library source code. The numerous close examinations conducted by specialists in the field, revealed that OpenSSL is far from perfect and that there are more unexpected weak points to be discovered in the future. The first one to come after Heartbleed is the new SSL/TLS vulnerability.

In essence, this is a typical man-in-the-middle attack, where the attacker is able to intercept and decrypt information exchanged between the client and the server. The attacker can also modify or inject his own traffic. This vulnerability is exploited by using a carefully crafted handshake, which in turn can force the use of weak keying material, thus enabling the attack. The vulnerability affects servers running OpenSSL 1.0.1 and 1.0.2-beta1. Users of earlier versions of the OpenSSL library are not vulnerable to this type of man-in-the-middle attack, but are advised to upgrade as a precaution. What raises concern is that clients are vulnerable in all versions of OpenSSL, but the attack can be performed only between a vulnerable client and server. Although the attacker must be in a man-in-the-middle position, this can be easily achieved when an untrusted network is used.

We at Vistnet, would like to inform our clients that the version of OpenSSL we have been using on our servers has been 0.9.8y, which is not vulnerable to this exploit as a server. As our service interacts both as server and client with our customers, we have upgraded to 1.0.1h that is not vulnerable either as a server, nor as a client. Communication between our servers and clients has been secure and no customer information was ever exposed. However, communication between us and those of our clients, whose backends have been running any of the vulnerable versions of OpenSSL, has been exposed and susceptible to attacks. We strongly advise all of our clients to upgrade their OpenSSL libraries to the newest corresponding version.

The imperfections of the OpenSSL source code have led us to the conclusion that there may be many more vulnerabilities to be found in the future. As we always like to be on the safe side, we have designed our infrastructure in such a way that implementation of patches and upgrades can be done as soon as possible. OpenSSL has been updated throughout all of our points of presence in mere minutes after the SSL/TLS vulnerability was publicly announced. We strive to present our customers with the best service, this is why we spare no expense in maintaining a safe, up-to-date infrastructure.