To bypass code-signing checks, malware gang steals lots of certificates | Ars Technica "There are lots of ways to ensure the success of an advanced hacking operation. For a gang called Suckfly, one of the keys is having plenty of stolen code-signing certificates on hand to give its custom malware the appearance of legitimacy.

Since 2014, the group has used no fewer than nine separate signing certificates from nine separate companies to digitally sign its hacking wares, according to a blog post published Tuesday by security firm Symantec.

Probably the only thing worse than "no security" is the illusion of security.

Labels: app security, codesigning

Practical Windows Code and Driver Signing: "A lot of this information can be verified in official Microsoft documentation found on MSDN, and I will try to cite the official documentation when needed. The authoritative documents on kernel-mode code signing are kmsigning.doc and KMCS_walkthrough.doc. These are pretty good resources, but they are from 2007 and thus contain no information about Windows 7, Windows 8, or SHA-2. Also, their scope is more limited than the scope of this document because they don't talk about signing executables. Therefore, a lot of the things I say here are actually conclusions that I have drawn from my own experiments. When I am telling you something that I determined experimentally, I will use phrases like 'it seems like' or 'in my experience'. When my experiments contradict the official documentation I will say so."

Terrific guide to code signing in Windows environment. Better bone up because WinObjC is here and works great.

Labels: authenticode, codesigning

BBC News - Android Fake ID bug exposes smartphones and tablets
BlueBox Labs said it was particularly concerning as phone and tablet owners did not need to grant the malware special permissions for it to act.

If this is true, then essentially Android devices do not have codesigning protection. Sounds like any app can use a self-signed certificate chain to spoof the identifier of a well-known manufacturer. I guess the good news is they are fixing the bug.

Labels: android, certificate, certificate authority, codesign, codesigning

Of Flash Player versions and codesigning and signatures | Jaharmi’s Irreality
However, it’s also difficult to understand why a large corporation with the resources of Adobe cannot codesign a piece of software as critical to the Mac OS X browsing experience as the Adobe Flash plugin is — especially when its “Install Manager” application is signed."

One of the many problems with Flash vulnerabilities. You can't even check to see if the Flash plug-in is authentic.

Yesterday I opened a Safari session on Mavericks and was pummelled with dialog boxes (reminisent of Windows popups) asking me to upgrade Flash.

I was redirected to the Adobe website and didn't think to check the codesign on the Flash installer before installing. What a nightmare!

Labels: codesigning, security

No teams showing in organizer | Cocoabuilder
You *can* sign with Developer ID on a Mac running Snow Leopard.  It is not officially supported, but it is unofficially supported and somewhat documented.

You need a Mac running Xcode 4.3+ in order to retrieve your Signing Certificate(s).  You then export this from Xcode 4.3+, then import into Keychain Access in your Build Mac.  Then you can sign anything with Developer ID on your Build Mac using the 'codesign' command-line tool.  I am running Xcode 3.2.5 under 10.7 (not supported, but I do it anyhow), and have successfully added this step to my build script and it works.

Personally, I haven't had any trouble building and signing with Xcode 3.2.5. However, in order to get applications into the App Store successfully you will need to build retina Icons on Lion or Mountain Lion using iconutil and then use these icns in your Xcode 3.2.5 build.

Labels: codesigning, lion, mac app store, mountain lion, retina

Re-Signing iOS apps
In order for an app to run on an iOS device, it needs to be code signed. This proves to iOS that the app has been approved to run on iOS devices. This is true of any apps in the App store, ad-hoc, or enterprise apps. The App store apps add an additional level of protection, as the apps are not only cryptographically signed by Apple, but also protected by DRM. Since only Apple can apply this DRM to apps, the app needs to go through the approval process and be “blessed” by Apple."

Even though this article is about iOS applications, it reveals some important ideas for Mac developers distributing applications signed with Developer ID. If the application itself does not check the code signature, your work could be altered and redistributed with different credentials.

Labels: ASN.1, codesigning, developerid, ios

Before DeveloperID was announced, I spent considerable time creating a 3-layer self-signed codesign certificate chain for my own applications. There are bugs (at least in Keychain Access for Snow Leopard) that make creating self-signed certificates painstakingly error-prone. Mostly due to the fact that the Certificate Assistant does not remember all settings when moving backward and forwards through the wizard.

In any event, it is possible to create your own root Certificate Authority (which you can publish on your web site, ala Apple's Root CA) and your own intermediate software-signing certificate and your own leaf certificates.

Someone conversant with OpenSSL can probably get it done faster and quicker than with Certificate Assistant.

My intent in creating a self-signed certificate chain was to verify that 3rd party codesigning certificates -- and binaries signed with 3rd party certificates -- would work with Tighten Pro. And they do. As long as the signing chain has 3 certificates.

Labels: certificate authority, codesigning, self-signed certificates, validation

Bundle was signed with this leaf certificate:
certificate leaf[subject.CN] = "Developer ID Application: Gen Kiyooka"

NUMBER COMMON NAME
0 Developer ID Application: Gen Kiyooka
1 Developer ID Certification Authority
2 Apple Root CA
designated requirements = anchor apple generic
and identifier "com.genkiyooka.developerid"
and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */
or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */
and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */
and certificate leaf[subject.OU] = MQK467HD9A)


Presumably for changes coming with Gatekeeper, Xcode 4.3 generates more elaborate designated requirements for codesigned Mac applications, depending on whether the signing certificate is a DeveloperID (internet distribution), MacDeveloper, or 3rd Party Mac Developer certificate (App Store submission).

I'm no x509 expert, but it appears that Apple has defined some certificate extensions for use in it's code signing certificates and the new designated requirements are referencing fields within the certificate extensions.

In particular, field.1.2.840.113635.100.6.1 is the prefix for constant kSecOIDAPPLE_EXTENSION_CODE_SIGNING and field.1.2.840.113635.100.6.2 is the prefix for extension constant kSecOIDAPPLE_EXTENSION_INTERMEDIATE_MARKER.

While these new designated requirements are certainly fancy, they are by no means required for DeveloperID codesigned applications to run under Gatekeeper. At least not the Gatekeeper simulation available under Lion.

REFERENCES:
x509 certificate extensions at stackoverflow.com
libsecurity_keychain/CertificateValues.cpp at opensource.apple.com

Labels: codesigning, developerid, gatekeeper

Gatekeeper vs. Leopard: an ongoing tale — Fetch

XCode 4.3 generated designated requirements for Gatekeeper and Developer ID.

[ 1] designated => (
[ 2] anchor apple generic
[ 3] and certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */
[ 4] or
[ 5] anchor apple generic
[ 6] and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */
[ 7] and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */
[ 8] and certificate leaf[subject.OU] = some-developer-id
[ 9] ) [10] and identifier "some-bundle-id""

SOURCE: fetchsoftworks.com

Labels: codesigning, designated requirements, gatekeeper

Code Signing - PureDarwin
As of Mac OS X and Darwin, a Mach-O code signature system (similar in concept to Microsoft AuthentiCode for PE binaries on Windows, and Solaris ELF signing) has been implemented. At least on Darwin, this system is not "formally" used, and no binaries are signed."

SOURCE: puredarwin.org

Labels: codesigning, darwin, otool

Fedora Linux Capitulates to Microsoft Boot Certificate CIO.com
In order to get its Linux distribution to run on the next generation of secured desktop computing hardware, the Fedora Project will obtain a digital signature from Microsoft, a developer from the project announced Wednesday."

One for the Dark Lord on his dark throne. In the Land of Mordor where the Shadows lie. One Root to rule them all, One Root to find them...

Labels: codesigning, microsoft

VIDEO:
http://youtu.be/KYGhay3yapk
CODE:
https://github.com/axelexic/SanboxInterposed

Labels: codesigning, hacking osx, mountain lion, sandbox, security

App Sandbox Design Guide: Migrating an App to a Sandbox

To support migration of app support files when a user first launches the sandboxed version of your app, create a container migration manifest.

SOURCE:http://goo.gl/VRhVo

If you App stores preference data in a location __OTHER THAN__ the standard location (.plist in ~/Library/Preferences), you will need a container migration

Labels: codesigning, gatekeeper, mac app store, sandbox

Building for the Mac app store

SOURCE: http://hartcw.com/francis/building-for-the-mac-app-store/

How to do a manual codesign of your app and installer bundle from the command line or makefile.

Labels: codesigning, mac app store, snow leopard, xcode

Bypassing iPhone Code Signatures - Jay Freeman (saurik): 

An interesting read.

Labels: codesigning, ios, iphone

MacTech | The journal of Apple technology.: "Code Signing - Get Used to It!

Digitally signed applications and you

by Scott Corley

What Is Code Signing?

So you're a computer. And you're not happy executing just any old software. No, you want to only run software that has been approved by someone you trust. How can you, the computer, tell the good from the bad?"

A nice gentle introduction to codesigning from mactech.com.

Labels: codesigning, tutorial

Proof-of-concept app exploiting iOS security flaw gets researcher in trouble with Apple | Ars Technica: "However, iOS 4.3 introduced 'sandboxing entitlements,' special exceptions granted on a very limited basis, to allow things like Nitro's JIT JavaScript compilation to work. In iOS 4.3 and later, MobileSafari has an entitlement called 'dynamic code signing.'"

Every sandbox has a skirmish, or it wouldn't be a sandbox.

Labels: codesigning, store receipt validation

sandbox — Secure Mac Programming: "App sandboxing

The really big news for most developers is that the app sandboxing from iOS is now here. The reason it’s big news is that pretty soon, any app on the Mac app store will need to sign up to sandboxing: apps that don’t will be rejected. But what is it?"

A very friendly description of sandboxing on Mac OS X from the author of Secure Mac Programming.

Labels: codesigning, developerid, mountain lion, sandbox, security, snow leopard

Checking Code Signing and Sandboxing Status in Code – Ole Begemann: "Can we do the same in code? Yes we can. With a lot of help from my coworkers Jörg Jacobsen (see his work on XPC and Sandboxing for the iMedia framework) and Christian Beer (who pointed me to the source code for the codesign utility), I wrote a category on NSBundle that can tell you for any application bundle: a) whether it has a valid code signature b) whether it is sandboxed and c) whether it was downloaded from the Mac App Store."

A really nice article and sample code about checking entitlements etc. The problem with using a category on NSBundle is that category methods are easily identified in the binary and can be hijacked.

Labels: codesigning, sandbox, security

Red Sweater Blog – Developer ID Gotcha: "For the upcoming Gatekeeper feature in Mac OS X 10.8, Apple will make it easy for customers to prevent software from running that has not been digitally ‘signed’ by developers with a certificate from Apple called the Developer ID certificate.

A nice handy post about how the default designated requirements generated by the build process don't always behave as expected on various flavors of X.

Labels: codesigning, developerid, gatekeeper, sandbox, security