Slack[ing] off our notifications

We :heart: Slack. The elderly in our team were IRC die hards, but Slack even won them over (if for no other reason, for their awesome iOS changelogs).


Thanks to Slack integrations, its robust API and webhooks, we have data from all over filter into our Slack, from exception reporting to sales enquiries. If it’s something we need to know, we have it pushed through to Slack.


At the same time, our Canary product (which prides itself on helping you “Know. When it matters”) was able to push out alerts via email, sms or over it’s RESTful API. Canaries are designed from the ground up to not be loquacious. I.e They don’t talk much, but when they do, you probably should pay attention. Having them pipe their results into Slack seemed a no-brainer.


Our initial stab at this was simple: By allowing a user to enter the URL for a webhook in their Console, we could send events through to the Slack channel of their choosing.

Thinkst Canary - Configuration 🔊 2016-05-26 11-04-27.png


Of course, this wasn’t all that was needed to this get working. The user would first have to create their webhook. Typically, this would require the user to:

Click on his team name, and navigate to Apps & Integrations


Hit the slack apps page and navigate to “Build”


Be confused for a while before choosing “Make a custom integration”

Select “Incoming Webhooks”



At this point the user either:
1.Decides this is too much work and goes to watch Game of Thrones
2.Goes to read the “Getting started” Guide before going to [a]
3.Chooses his destination channel and clicks “Add Incoming webhooks Integration” 


After all this, the user’s reward is a page with way more options than is required for our needs (from a developer's point of view, the options are a delight and the documentation is super helpful, but for an end user... Oy vey!)

Finally... the user can grab the webhook URL, and insert it in the settings page of their console.

(This isn’t the most complicated thing ever... It’s not as confusing as trying to download the JDK - but Canary is supposed to make our users' lives easier, not drive them to drink)

With a bit of searching, we  found the Slack Button.  

add_to_slack@2x.png

This is Slack's way of allowing developers to make deploying integrations quick and painless. This means that our previous 8 step process (9 if you count watching Game of Thrones) becomes the following:

The User clicks on the “Add to Slack” button (above)

He is automatically directed to a page where he authorises the action (and chooses a destination channel) 



There is no step 3:



Of course, we do a little more work, to allow our users to easily add multiple integrations, but this is because we are pretty fanatical about what we do.

At the end of it though, 2 quick steps, and you too can have Canary goodness funnelled to one of your Slack channels!

Slack 2016-05-25 12-22-32.png

At the moment, we simply use the incoming webhooks to post alerts into Slack but there is lots of room to expand using slash commands or bot users, and we heard that all the cool kids are building bots. (aka: watch this space!)  

P.S. If you are a client, visit /settings on your console to see the new functionality.

Certified Canarytokens: Alerts from signed Windows binaries and Office documents

As part of a talk at the ITWeb Security Summit last week, we discussed how to trigger email alerts when file signatures are validated with our Canarytokens project. Building on that alerting primitive, we can make signed executables that alert when run or signed Office documents that alert when opened. 


Canarytokens is our exploration of light-weight ways to detect when something bad has happened on the inside a network. (It’s not at all concerned with leaks in that dubious non-existing line referred to as “the perimeter” of a network.) We built an extensible server for receiving alerts from passive tokens that are left lying around. Tokens are our units of alerts. When a token URL link is fetched or a token DNS name is queried this triggers an alert via the Canarytokens server. With these (and other tokens) we set out to build alerts for more significant incidents.

Office Document Signatures


A security researcher, Alexey Tyurin, drew our attention to how opening signed Office documents can trigger token alerts. On opening a signed Word document, Office verifies the signature automatically with the certificate embedded in the document. A notable exception to this is when a document is opened with Protected View enabled (typically after the document is downloaded from the web or opened as an email attachment.) The signature verification in that case, happens only after the user clicks to disable protected view. During the verification, a URL from the certificate is fetched. We can set the retrieved URL to a token URL (which integrates with Canarytokens to fire an alert to set us off). The URL we set is in a field called Authority Information Access (AIA). This field tells the signature verifier where to fetch more information about the CA (such as intermediate CAs needed to verify the signing certificate).


Signed document that has already triggered an alert

Signing Word documents gives us  another way to alert when the document is opened. The previous technique, which is implemented on Canarytokens, uses a remote tracking image embedded in the document. While the document signing is not currently integrated in Canarytokens, it can easily be automated. This requires creating a throwaway CA with token URLs to generate a tokened signing certificate and then signing a document. Thanks to Tyurin, creating the CA is a short script. Signing the document programmatically can be tricky to get right. We've automated this by offloading the signing to the Apache POI library in a Java program.

It’s worth noting more closely how the token URL is hit: Office offloads the signature verification to the Microsoft CryptoAPI which is what hits the URL. (In our tests the User-Agent that hits the URL is Microsoft-CryptoAPI/6.1). We should be able to re-use this trick with other applications that offload the signature verification in this way.

Windows Executables Signatures


A signed copy of Wireshark
If signed documents could be used to trigger Canarytokens we wondered where else this could work. Microsoft’s Authenticode allows signing Windows PE files, such as executables and dlls. The executables signatures are verified on launch if the setting for it is enabled in the security policy. The name of the setting is a mouthful: System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies". Our initial tests of signed .NET DLLs were able to trigger alerts when loaded by custom executables even without the setting enabled. However, if Authenticode can alert us when Windows executables have been launched, we have a uniquely useful way of knowing when binaries had been executed, without any endpoint solutions installed.

To deploy signed executables, all that is needed is to token executables that attackers routinely run such as ipconfig.exe, whoami.exe and net.exe to alert us to an attacker rummaging around where they shouldn’t be. Zane Lackey's highly recommended talk (and slides) on building defenses in reaction to real world attack patterns makes the case for how alerts like these can build solid attacker detection.

The verification, just like in the Office document case, is offloaded for Microsoft CryptoApi to handle. Signing certificates for the executables are produced in the same way. However, the signing certificate must also have the Code Signing key usage attribute set. Creating signed binaries is made simple by Didier Stevens’ extensive work on Authenticode. This is integrated into Canarytokens to make signing a binary as simple as uploading a copy to sign, but is also available as a standalone tool from the source.


AIA fields of a signing certificate
To sign an executable on Canarytokens, you upload an executable to the site. The site will sign the binary with a tokened signing certificate. Simply replace the original executable with the tokened one and verify that signature verification for executables is enabled. An attacker who lands on the machine and runs the tokened executable, will trigger the signature verification which gets an alert email sent (via Canarytokens) to let you know that something bad has happened.

Many of our other canary tokens are built on top of application-specific quirks. Adobe Reader, for example, has the peculiar behaviour of pre-flighting certain DNS requests on opening a PDF file. What the Office document and executable signings point to, is a more generic technique for alerting on signature (and certificate) validation. This a more notable alerting primitive and is likely more stable than application quirks given that URL-fetching extensions are enshrined in certificate standards. Although in this post we’ve used the technique in only two places, more may be lying in wait.

Edited 2016-06-14: Thanks to Leandro in the comments and over email, this post has been updated with his observation that Office document signature verification won't happen automatically when the document opens Protected View.