Security Musings Blog
There’s a common mythos perpetuated by many security vendors (or, at least, by their sales forces) that you can buy a tool, install it, and problems will be solved. This mythos oftentimes short-circuits problem solving processes, jumping to “solutions” without doing earlier steps, such as defining the problem. More often than not we see this sales approach coupled with a heavy dose of FUD, intended to “prove” to a prospective customer that there is a great “risk” (term used incorrectly) that must be mitigated. If you buy their tool, then you’ll be saved! Or not, as the case more likely is…
A vulnerability demonstration this week involving a technology that’s generating buzz reminded me of an important concept: Security is as much about implementation as the underlying technologies you use. You can put together several “secure” components and still build an insecure system.
The example that reminded me of this relates to Bitcoin, a somewhat controversial form of digital currency that’s recently been discussed by several high-profile media outlets. I’m not going to talk about any specific merits or problems associated with Bitcoin, but note that it relies on mathematically solid encryption schemes to allow transactions while preventing theft.
However, regardless of how strong your encryption, an insecure application using that encryption can introduce easily exploitable vulnerabilities. And Adam Baldwin of evilpacket has shown how this can happen with Bitcoin by creating a video demo of XSS/CSRF problems in a Bitcoin exchange site. These application-level issues could enable an attacker to steal Bitcoins without cracking the basic cryptography employed.
Using proven security technologies is important, but it’s only one part of securing your organization. I still remember my surprise when I first discovered that an “unbreakable” cipher did exist: the one-time pad. But using one-time pads is often impractical, and they are still susceptible to compromise from human factors. Building secure business operations requires understanding the risks at each level of a system and having a defense-in-depth response.
At Gemini, we can help you assess those risks, architect strategies to handle them, then apply those solutions in your organization to produce measurable security improvements. Don’t simply trust in “encryption” or WAFs to protect your data – let us help you understand the big picture of your company’s security today.
I recall back in the 80s, when “computer virus” was a new term, “antivirus software” hadn’t been invented yet, nobody had coined the term “malware”, and Apple was still running incomprehensible TV ads.
It’s ironic: Apple computers were the predominant home computers when computer virii and malware were invented. And yet, the first malware kit for the MAC OS (or, more accurately, OS X), Weyland-Yutani BOT, was only released earlier this month. For obvious reasons, I’m not about to download it and play around, but preliminary reports indicate that this kit may have caused a significant increase in OS X malware. And supposedly, kits for iPad and Linux are just around the corner.
To be honest, I find the iPad more disturbing. An increased awareness of mobile OSes in the black hat community can only mean more malware for those platforms. Various experts have been predicting widespread malware in mobile devices like phones and tablets for some time now. With the release of Weyland-Yutani BOT, we’re that much closer. The exact development cycle for such kits is hard to pin down, but a spike in mobile device malware is likely in the very near future. If you haven’t already, now would probably be a good time to look at anti-malware for all of your computing devices – Weyland-Yutani BOT is just the beginning.
Disclaimer: I am *not* a mathematician. I just happened to take a Number Theory class from an awesome professor (Dr Blakley) at Texas A&M.
When I took Dr Blakley’s Math 673 class, I was in over my head at first (and probably still would be if I hadn’t seen the applications of the topics in his class since taking his class). Unfortunately, I graduated and didn’t get to take the second part of the course, which friends told me was just as good as the first part. We learned about polynomial math, and at the time, I had no clue what it could be used for…. Then a friend linked me to this awesome stick figure explanation of AES. Once again, I remembered seeing this “math” in Dr Blakley’s class. We did a lot more with it than the AES description shows (but I couldn’t tell you what or how).
We first learned finite field arithmetic by drawing the fields and looking up the solution on the “chart.” Then, we moved to making sure that we understood modulo arithmetic. Then, we finally learned how to apply this to polynomials. (I still didn’t get my aha! moment until years later). But, now, I can read (and understand) the stick figure description of AES. It’s worth learning if you want to delve deeper into cryptography, as many cryptographic functions are based on math learned in a number theory class.
OpenVPN isn’t anything new. But today I finally overcame a hurdle I had with trying to connect to our company VPN via my Android device. The OpenVPN for android project isn’t anything new; it’s actually been in the works since late 2009 if you follow it all the way back through a couple forks.
The main issue that was holding me up wasn’t anything to do with Android-OpenVPN port itself. It was simply to do with the Android device I was using (thanks Samsung for crapping on us with the Galaxy S devices). A recent ROM update finally put the final pieces I needed into motion for being able to utilize OpenVPN. The main holdback was the lack of tun in the kernel of my Android build.
It may be true that cloud computing services are permeating nearly every facet of our networked world; but in the process of sharing our data with the companies that provide these resources, what do we do about the trust issue? Data in the cloud is vulnerable unless it’s protected somehow. And if this protection isn’t implemented, then the whole service becomes less useful for those people who require it.
Not all services are affected equally, however; and some are not affected much at all. For example, protecting certain data fields stored in a distributed online database may be as common-practice as using strong encryption. However, more delicate services may not be as flexible…
How do you force the image data stored on a cloud image editor to be encrypted at their end? Or force a word processor to encrypt your latest holiday shopping list? Without the assistance of the service providers, the only solution is a customized technical workaround; colloquially known as a hack.
An example of precisely this kind of workaround was outlined in this paper (pdf) by Yan Huang and David Evans. In it, they describe a method (and a working example) by which a user can use Google Docs while maintaining both confidentiality and integrity.
It works by way of some very clever applications of incremental encryption, data structuring, and indexing to transparently handle all of the security operations. And although it interferes with some functional capabilities, it stands as an example of the kind of solutions needed to shine some light on the shady parts of the cloud.