Blog

Security in NoMAD

As an application dealing with passwords and certificates, NoMAD takes security very seriously. While you’re more than welcome to peruse the code, here’s some notes to give you a better understanding of what NoMAD does with your secrets.

General Thoughts
NoMAD itself doesn’t do any of the heavy lifting as far as signing in to AD and getting you SSO access. The interaction with Active Directory is all done via Kerberos and LDAP, Heimdal Kerberos and OpenLDAP to be specific. NoMAD uses the versions of those tools that ship with macOS.

Source Available
Since NoMAD is an open source project, all of the source code used for it is publicly available. You are more than welcome to inspect the source, run it through a security scanner, or otherwise ensure that we’re doing things in the proper way.

If you have any concerns about particular lines of code, please let us know as we’d be very interested in making sure that NoMAD is as secure as we say it is.

Passwords
While most of NoMAD is written in Swift, there is no easy way to directly interact with the Heimdal Kerberos APIs on macOS in Swift. Because of that an Objective-C bridging header is used to mix the two languages. Whenever you are asked for a password it’s done via a secure text field and never written out anywhere. The password is then used with the Heimdal APIs and Objective-C to do gss_aapl_initial_cred() and get a TGT for the user. When changing passwords the same process is followed using the Heimdal APIs to do gss_aapl_change_password().

The password is never piped to kinit or other Kerberos tools.

When NoMAD is finished with your password the variable is blanked to remove any trace from memory as quickly as possible.

Keychain Usage
NoMAD, if the preference is set, will put the user’s password into the local Keychain. This is done through the use of SecKeychainAddGenericPassword() and other SecKeychain methods. The password is stored in the default keychain and will be removed if the user selects “Log Out” from the menu.

If a password is present in the Keychain, NoMAD will use that password on launch to get Kerberos tickets. If the password is unable to authenticate the user, NoMAD deletes the password from the keychain so that it won’t ever “accidentally” lock you out by attempting to sign in with an incorrect password.

Active Directory Security
NoMAD  does not require any security settings to be changed in Active Directory. NoMAD only uses SASL-authenticated binds when interacting with AD. In addition NoMAD will use the users’ Kerberos ticket to encrypt any LDAP traffic with AD by default. For additional security, starting with version 1.0.5, NoMAD can be configured to use SSL in addition for LDAP connections to AD.

User Space
NoMAD runs in user space, not as root. As such it has no more privileges than the currently logged in user does. There is no functionality difference if NoMAD is being used by a non-admin user as an admin user.

Preferences
All of the application preferences can be set using configuration profiles either installed locally or from an MDM service. Setting the preferences in this way will prevent a user from being able to change them.

Certificates
Similar to passwords, NoMAD does not send a private key across the wire. In fact the private key used for generating your CSR never leaves the Keychain. The process is done entirely within NoMAD using the SecKeychain and SecCertificate APIs.

By default the private keys are marked as non-exportable. However, you can use a preference to change this.

When sending the CSR to the Windows CA, Kerberos authentication is used and then the CSR is sent via SSL. Even though nothing in the CSR is sensitive, good data-in-motion hygiene is respected. The resulting signed public key is retrieved using Kerberos and SSL as well and then matched up with the private key in the Keychain.

SSL
The project in the repository has been set to Allow Arbitrary Loads for App Transport Security. You can change this in the Info tab of the project in Xcode.

This setting allows for self-signed, but specifically trusted, certificates to be used. The reason for this is that many Windows CAs use a self-signed certificate root that all machines in the organization trust. In that situation, NoMAD would not be able to get a x509 identity, even if the root certificate was explicitly trusted in the user’s Keychain.

You’re more than welcome to remove this flag before compiling, just keep in mind that if you’re not using a publicly trusted certificate you’ll most likely have issues when attempting to get a certificate for a user. However, if you have no intent of using the certificate functionality within NoMAD, then no other parts of NoMAD are impacted by changing SSL settings.

Network Connections
NoMAD does not listen for any incoming connections. All communications from NoMAD are outbound queries for DNS, LDAP, Kerberos and some web connections for certificates and other integrations that have been configured in the NoMAD preferences.

Sandboxing
Currently NoMAD is unable to be sandboxed on OS X/macOS due to a few features.

  1. The function being used to sleep the screen is not allowed inside a sandbox.
  2. If you want to sync the AD password with the local password, NoMAD needs to be able to change the local Keychain password. It does this using a private API SecKeychainChangePassword(). If/when a public API becomes available that fulfills the same function, we’ll move to that.
  3. The aforementioned App Transport Security flag.

© 2017 Orchard & Grove Inc.