Main menu

Tag Archives: crypto

Hey, you, get off my digital lawn and put down my binary flamingos!!!!!

If you have been living under an online rock these last couple of weeks, then you might have missed all of the news and hype about the threats to your SSL traffic. It seems that some folks, like Lenovo and Comodo, for example, have been caught with their hands in your cookie jar. (or at least your certificate jar, but cookie jars seem like more of a thing…)

That’s a LOT of people, organizations and applications playing with my (and your) SSL traffic. What is an aging infosec curmudgeon to do except take to the Twitters to complain?

There’s a lot of advice out there, and if you are one of the folks impacted by Superfish and/or PrivDog directly, it is likely a good time to go fix that stuff. It also might be worth keeping an eye on for a while and cleaning up any of the other applications that are starting to be outed for the same bad behaviors.

In the meantime, if you are a privacy or compliance person for a living, feel free to drop us a line on Twitter (@lbhuston, @microsolved) and let us know what your organization is doing about these issues. How is the idea of prevalent man-in-the-middle attacks against your compliance-focused data and applications sitting with your security team? You got this, right?

As always, thanks for reading, and we look forward to hearing more about your thoughts on the impacts of SSL tampering on Twitter!

Even as the govt was touting their takedown, threat intelligence companies around the world (including MSI), were already noticing that the attackers were mutating, adapting and re-building a new platform to continue their attacks. The attackers involved aren’t likely to stay down for long, especially given how lucrative the crypto locker malware has been. Many estimates exist for the number of infections, and the amount of payments received, but most of them are, in a word, staggering. With that much money on the line, you can expect a return of the nastiness and you can expect it rather quickly.

Takedowns are effective for short term management of specific threats, and they make great PR, but they do little, in most cases, to actually turn the tide. The criminals, who often escape prosecution or real penalties, usually just re-focus and rebuild.

This is just another reminder that even older malware remains a profit center. Mutations, variants and enhancements can turn old problems like Zeus, back into new problems. Expect that with crypto locker and its ilk. This is not a problem that is likely to go away soon and not a problem that a simple takedown can solve.

If you use OpenSSL anywhere, or use a product that does (and that’s a LOT of products), you need to understand that a critical vulnerability has been released, along with a variety of tools and exploit code to take advantage of the issue.

The attack allows an attacker to remotely tamper with OpenSSL implementations to dump PLAIN TEXT secrets, passwords, encryption keys, certificates, etc. They can then use this information against you.

THIS IS A SERIOUS ISSUE. Literally, and without exaggeration, the early estimates on this issue are that 90%+ of major web sites and software packages using OpenSSL as a base are vulnerable. This includes HTTPS implementations, many mail server implementations, chat systems, ICS/SCADA devices, SSL VPNs, many embedded devices, etc. The lifetime of this issue is likely to be long and miserable.

Those things that can be patched and upgraded should be done as quickly as possible. Vendors are working on patching their implementations and products, so a lot of updates and patches will be forthcoming in the next few days to weeks. For many sites, patching has already begun, and you might notice a lot of new certificates for sites around the web.

Our best advice at this point is to patch your stuff as quickly as possible. It is also advisable to change any passwords, certificates or credentials that may have been impacted – including on personal sites like banking, forums, Twitter, Facebook, etc. If you aren’t using unique passwords for every site along with a password vault, now is the time to step up. Additionally, this is a good time to implement or enable multi-factor authentication for all accounts where it is possible. These steps will help minimize future attacks and compromises, including fall out from this vulnerability.

Please, socialize this message. All Internet users need to be aware of the problem and the mitigations needed, even for personal safety online.

As always, thanks for reading, and if you have any questions about the issues, please let us know. We are here to help!

An interesting problem is occurring in the mobile development space. Many of the applications being designed are being done so by scrappy, product oriented developers. This is not a bad thing for innovation (in fact just the opposite), but it can be a bad thing for safety, privacy and security.

Right now, we are hearing from several cross platform mobile developers that the API sets across iOS, Android and others are so complex, that they are often skipping some of the APIs and rolling their own code methods for doing some of this work. For example, take crypto from a set of data on the device. In many cases, rather than using standard peer-reviewed routines and leveraging the strength of the OS and its controls, they are saying the job is too complex for them to manage across platforms so they’ll embed their own code routines for doing what they feel is basic in-app crypto.

Problems (like those with the password vault applications), are likely to emerge from this approach toward mobile apps. There is a reason crypto controls require peer review. They are difficult and often complex mechanisms where mistakes in the logic or data flows can have huge impacts on the security of the data. We learned these lessons long ago. Home-rolled crypto and other common security routines were a big problem in the desktop days and still remain so for many web applications, as well. Sadly, it looks like we might be learning those lessons again at the mobile application development layer as well.

Basically, the bottom line is this; if you are coding a mobile application, or buying one to access critical data for your organization, make sure the developers use the API code for privacy, trust and security functions. Stay away from mobile apps where “roll your own/proprietary security code” is in use. The likelihood of getting it right is a LOT less than using the APIs, methods and code that the mobile OS vendors have made accessible. It’s likely that the OS vendors are using peer-reviewed, strongly tested code. Sadly, we can’t say that for all of the mobile app developer code we have seen.

I saw this excellent article this morning that covers 5 basic tools for doing file cryptography across platforms. Many of these tools are great solutions and we use them frequently with clients. In particular, we find True Crypt to be a very powerful and useful tool. Many client have embraced this solution for laptop encryption, leveraging the free price and benefit for compliance.