David Kane-Parry - Leviathan Security Group

Why Authenticity Is Not Security

nospam@example.com (David Kane-Parry) — Tue, 07 Feb 2012 10:26:59 -0700

Code signing aims to solve two specific problems. The first problem is how to identify the author of code. The second problem is how to verify that code has not been modified after release. Truly solving one or the other would be a good step forward. That both may be solved simultaneously is a great step forward. There is a common misconception, however, that code signing represents a giant leap forward by making the signed code itself "secure". There is not a little danger in trusting code simply because it is signed, without regard to the security of its development before release.

First, a primer on how code signing works. Code signing calculates a cryptographic hash of the code, which is then digitally signed by the author and appended to the code itself. After release, the appended hash can be compared to a newly calculated hash in order to detect modification of the code. The digital signature can be compared to the author's certificate in order to also detect modification of the appended hash. Optionally, the author's certificate may be compared against a certificate authority to detect an inauthentic certficiate. Remember that this process was only designed to gurantee the authenticity of the code, that it has not been modified after release and that it was released by the expected author. None of those steps, however, can attest to the safety of the signed code; inversely, code that is not signed is not necessarily less safe.

Safety is introduced into the code signing process as a byproduct of an organization's criteria for signing code and revoking certificates. For example, developers may request that Microsoft sign the developers' drivers through Microsoft's Windows Logo program, to indicate that they have passed Microsoft's tests for reliability and compatibility. In addition, x64 architecture Windows drivers are required to be signed by the author or they will be prevented from loading, and will also be prevented from loading if the signing certificate is revoked. The signature certificate could be revoked in the event the driver is observed to be misbehaving, but by then the damage is already done and only the scope can be minimized. Microsoft could decline to sign a driver that fails to pass their tests, but in this case, security is not something for which they are testing. For signed code to be trusted as secure, and not merely as authentic, it must be reviewed for vulnerabilities.

In fact, the code signing process could incorporate an actual level of security. Large software vendors could require security reviews as part of their code signing process. In addition, large organizations with their own security team could take this responsibility for reviewing the security of applications they use, regardless of whether the author signed them, and re-distributing them internally with the organization's own signature. Smaller organizations might outsource this responsibility to a security vendor. Finally, security vendors could counter-sign code as a seal of approval to encourage adoption of a product.

The primary advantage of this approach is enabling end-users to decide on the trustworthiness of an application based on whether it has been signed by a trustworthy security team, and not merely by the author, if it is signed at all. The secondary advantage is the possibility of automatically enforcing these trust decisions at an administrative level, rather than leaving it up to careless users on a case-by-case basis. That, however, is a post for another time....

Moving Targets: Location-Based Threats and Mitigations

nospam@example.com (David Kane-Parry) — Wed, 22 Sep 2010 14:10:27 -0700

This year at ToorCon 12 in San Diego, California I will give a presentation entitled "Moving Targets.”

Location-based services are built into every major mobile platform, almost every social networking site, and more and more consumer electronics every day. These services, that record and sometimes share their users’ geographical location in real or near-real time, have been deployed by developers and embraced by users with little consideration of the threat posed by this data. An attacker who possesses the user’s location can abuse it to leverage both technical and social engineering attacks on that user. From cellular networks to web apps such as Foursquare, each layer presents a unique data set that is ripe for different attacks. In many cases, however, these threats can be mitigated with mindful application of recommendations for both location service development and usage. If you want to learn how your moving targets can avoid becoming someone else’s sitting ducks, then come to Toorcon 2010.

Please contact me directly at dkp at leviathansecurity if you have any questions or comments.

**Update: You can find the slides for this presentation here

More Bugs In More Places: Secure Development On Mobile Platforms

nospam@example.com (David Kane-Parry) — Wed, 22 Sep 2010 13:39:09 -0700

At the Blackhat Briefings USA 2010 in Las Vegas I gave a presentation entitled "More Bugs In More Places" which was about secure development on mobile platforms.

Nothing succeeds like success, and with the attention garnered by Apple’s App Store, many companies are either looking to port existing applications to or develop exclusive applications for the top mobile platforms: Blackberry, iPhone, Windows Mobile, and Android. Each of these platforms provides the would-be developer with a SDK to do the heavy-lifting of coding, but can they be trusted to carry that weight? Just as some languages make it easier or harder to develop secure applications, so it is with SDKs. One SDK may provide robust cryptographic functions, another may restrict hardware access, and yet another may enforce strict memory management. Below are slides to the talk given at Black Hat 2010; they compare the top four SDKs in terms of the security features they provide and lack. They will help new mobile developers decide which is the safest and most dangerous for their applications.

Please contact me directly at dkp at leviathansecurity if you have any questions or comments.

You can view the presentation slides here