Appcanary makes sure you never run vulnerable software in your apps.
Subscribe to our newsletter!

Making Appcanary easier to use

I’m excited to announce that we’ve added two features that make Appcanary a heck of a lot easier to use!

Add monitors by uploading a file

Our Monitor API is great if you want to track a set of Linux packages or your Gemfile. We give you a dashboard showing which packages are vulnerable, and email you whenever new vulnerabilities that affect you come out. However, there’s always a bunch of setup to get a new API going.

With that in mind, we made the interface a lot more user friendly! You can now upload a file to watch directly through the website. Just go to add monitors to be able to upload a file directly. Monitors support Ruby’s Gemfile.lock, /var/lib/dpkg/status for Ubuntu and Debian, and the output of rpm -qa for Centos and Amazon Linux!

Automatically upgrade vulnerable packages

A few of our customers told us that knowing about vulnerabilities is nice, but you know what would be great? If we could somehow patch them automatically. We thought about it and said, sure, why not!

If you have the Appcanary agent installed on an Ubuntu server, and you’re running the latest version, you can run

appcanary upgrade

in order to install updates for any packages we know to be vulnerable.

You can also run

appcanary upgrade -dry-run

in order to see what the agent will do, without it actually touching your system.

Now you can manage vulnerabilities, learn about new ones that affect you, and apply patches, all through Appcanary!

If you haven’t tried us yet

Stay on top of the security vulnerabilities that affect you, today.

Appcanary, monitors your apps and servers, and notifies you whenever a new vulnerability is discovered in a package you rely on. And now it will help you patch vulnerable packages as well.

Sign up today!

Vulnerabilities I Have Known and Loved #1: Symantec's Bad Week

tl;dr: If you use software with “Symantec” or “Norton” somewhere in its name, stop what you’re doing and upgrade.

Back in my security consulting days, a mentor taught me One Weird Trick to increase conversions on your phishing campaign. It goes like this: set up an email server, get as many employee addresses you can find, and spoof a mass message that reads:

Hello this is your boss.

I’m going to fire someone next week and you get to vote on who! To get your arch-nemisis fired, please log into this website that looks exactly like our company portal, but has one character in the domain name mispelled.

Thanks, Your Boss.

Then you sit back and count how many people fell for it.

The executive who hired you is happy because they get to demonstrate the value of increasing their security budget. The consultancy you work for is happy, because they get to upsell a bunch of “security awareness training”.

Soon, you’ll be spending three days telling your victims about the importance of that little green lock in their browser’s address bar (but only when it’s in the right place!) and that they should never ever click on links, never open attachments, and if at all possible, stop using computers altogether. Everybody wins.

Obviously, everyone at this stage wants to increase the conversion rate1 of these phishing emails. This is where The One Weird Trick comes in: after you send out your first campaign, you craft another one. Before you know it, everyone on your list receives a helpful tip from the IT Helpdesk:

Hi,

We’ve heard reports of a phishing campaign being waged against us. Don’t open those emails! It’s critically important that you reset your password to protect against those evil hackers who tried to phish us.

Click here to do it!

It turns out that round two gets way more clicks than round one. Most people will figure out that email #1 is a little fishy. Email #2 manages to reaffirm that, and so they dutifully click, like lambs to slaughter.

This is the phishing equivalent of the Double Tap. No, not the one from Zombieland. The Double Tap I’m talking about is a controversial military technique where after attacking a target, you follow up by sending another missile at the first responders. You do some damage, and then attack the response to that damage.

Symantec is Having a Bad Week

Last week Tavis Ormandy dropped 8 vulns against every single Symantec/Norton antivirus product. Judging by the press, things are not looking good for them.

You can find a writeup up on the Google Project Zero blog, and the issues for all 8 vulnerabilities can be found here. They’re all remotely exploitable,2 and they all should give an attacker remote code execution as root/SYSTEM (and in ring 0 for one of them to boot!)

If you’re using a Symantec product I can’t stress this enough: stop what you’re doing and upgrade.

These vulnerabilities reminded me of phishing and the Double Tap for two reasons. First, every one of these vulns can be exploited by just sending an email. Since the product is an antivirus, so it’s going to scan every file that touches your disk and every email you get for viruses. You don’t have to get your target to click a link or even open the message you sent — Symantec will happily try to parse every email you receive.

Second, the stack overflow in Symantec’s PowerPoint parser depends on a Double Tap-like attack! This parser is used to extract metadata and macros from PowerPoint decks (and presumably scan them for known malware) by exposing an I/O abstraction layer — which it then caches for performance. Tavis found that he could get that cache into a misaligned state, which resulted in the stack buffer overflow.

This vulnerable codepath is in something called “Bloodhound Heuristics”, which Symantec promotes as a more advanced set of malware detection checks. Since they’re not always run, you’d think that the vulnerability wouldn’t be very exploitable. And yet, it can be targetted every time! Under the default configuration, the system dynamically decides which set of checks to run. All Tavis had to do was try a bunch of known PowerPoint malware, see which one triggered the automatic mode to turn on “Bloodhound Heuristics,” and put his payload into them.

The exploit pretends to be a certain kind of known malware in order to trigger some special aggressive checks, which are the exploit’s true target. The Double Tap!

Vulnerability Management

While the above vulnerability is pretty cool, the Symantec bugs that are most interesting to us at Appcanary are CVE-2016-2207 and CVE-2016-2211.

Symantec was shipping its product with out of date versions of libmspack and unrarsrc. Out of date versions that have dozens of known vulnerabilities with public exploits! All Tavis had to do was download public exploits for these known vulnerabilities, and he had an attack against Symantec.

Ironically, Symantec sells a product called Enterprise Vulnerability Management! This is a hard problem for everyone. At Appcanary, we’re working on solving it.

P.S.

Do you have suggestions for vulnerabilities you’d like me to write about? You can let me know at max@appcanary.com.


Paying the Bills

One quarter of the critical vulnerabilities found in Symantec’s products last week were there because they relied on out-of-date libraries with known security holes.

Our product, Appcanary, monitors your apps and servers, and notifies you whenever a new vulnerability is discovered in a package you rely on.

Sign up today!


  1. You know, it’s interesting that before I became the CEO of a startup, the only time I thought about “conversion rates” of emails in my career was when I was involved in phishing campaigns. 

  2. I’m going to well-actually myself here so you don’t have to. Tavis gives a clear path to exploit for 6 of the 8. Of the two that are left, one is a lack of bounds checking on an array index, and the other is an integer overflow bug. I’m going to go out on a limb and say I think both can lead to code execution. I can’t fault the researcher for not going further though; after you find the first 6 remote code executions, you stop feeling the need to keep proving the point… 

Should you encrypt or compress first?

Imagine this:

You work for a big company. Your job is pretty boring. Frankly, your talents are wasted writing boilerplate code for an application whose only users are three people in accounting who can’t stand the sight of you.

Your real passion is security. You read r/netsec every day and participate in bug bounties after work. For the past three months, you’ve been playing a baroque stock trading game that you’re winning because you found a heap-based buffer overflow and wrote some AVR shellcode to help you pick stocks.

Everything changes when you discover that what you had thought was a video game was actually a cleverly disguised recruitment tool. Mont Piper, the best security consultancy in the world, is hiring — and you just landed an interview!

A plane ride and an Uber later, you’re sitting across from your potential future boss: a slightly sweaty hacker named Gary in a Norwegian metal band t-shirt and sunglasses he refuses to take off indoors.

You blast through the first part of the interview. You give a great explanation of the difference between privacy and anonymity. You describe the same origin policy in great detail, and give three ways an attacker can get around it. You even whiteboard the intricacies of __fastcall vs __stdcall. Finally, you’re at the penultimate section, protocol security.

Gary looks you in the eyes and says: “You’re designing a network protocol. Do you compress the data and then encrypt it, or do you encrypt and then compress?” And then he clasps his hands together and smiles to himself.

A classic security interview question!


Take a second and think about it.

At a high level, compression tries to use patterns in data in order to reduce its size. Encryption tries to shuffle data in such a way that without the key, you can’t find any patterns in the data at all.

Encryption produces output that appears random: a jumble of bits with a lot of entropy. Compression doesn’t really work on data that appears random — entropy can actually be thought of as a measure of how “compressable” some data is.

So if you encrypt first, your compression will be useless. The answer must be to compress first! Even StackOverflow thinks so.


You start to say this to Gary, but you stop mid-sentence. An attacker sniffing encrypted traffic doesn’t get much information, but they do get to learn the length of messages. If they can somehow use that to learn more information about the message, maybe they can foil the encryption.

You start explaining this to Gary, and he interrupts you — “Oh you mean like the CRIME attack?”

“Yes!” you reply. You start to recall the details of it. All the SSL attacks with catchy names are mixed together in your mind, but you’re pretty sure that’s the one. They controlled some information that was being returned by the server, and used that to generate guesses for a secret token present in the response. The response was compressed in such a way that you could validate guesses for the secret by seeing how you affected the length of the compressed message. If the secret was AAAA and you guessed AAAA, the compressed-then-encrypted response will be shorter than if you guessed BBBB.

Gary looks impressed. “But what if the attacker can’t control any of the plaintext in any way? Is this kind of attack still possible?” he asks.


CRIME was a very cool demonstration of how compress-then-encrypt isn’t always the right decision, but my favorite compress-then-encrypt attack was published a year earlier by Andrew M. White, Austin R. Matthews, Kevin Z. Snow, and Fabian Monrose. The paper Phonotactic Reconstruction of Encrypted VoIP Conversations gives a technique for reconstructing speech from an encrypted VoIP call.

Basically, the idea is this: VoIP compression isn’t going to be a generic audio compression algorithm, because we can rely on some assumptions about human speech in order to compress more efficiently. From the paper:

Many modern speech codecs are based on variants of a well-known speech coding scheme known as code-excited linear prediction (CELP) [49], which is in turn based on the source-filter model of speech prediction. The source-filter model separates the audio into two signals: the excitation or source signal, as produced by the vocal cords, and the shape or filter signal, which models the shaping of the sound performed by the vocal tract. This allows for differentiation of phonemes; for instance, vowels have a periodic excitation signal while fricatives (such as the [sh] and [f] sounds) have an excitation signal similar to white noise [53].

In basic CELP, the excitation signal is modeled as an entry from a fixed codebook (hence code-excited). In some CELP variants, such as Speex’s VBR (variable bit rate) mode, the codewords can be chosen from different codebooks depending on the complexity of the input frame; each codebook contains entries of a different size. The filter signal is modeled using linear prediction, i.e., as a so-called adaptive codebook where the codebook entries are linear combinations of past excitation signals. The “best” entries from each codebook are chosen by searching the space of possible codewords in order to “perceptually” optimize the output signal in a process known as analysis-by-synthesis [53]. Thus an encoded frame consists of a fixed codebook entry and gain (coefficient) for the excitation signal and the linear prediction coefficients for the filter signal.

Lastly, many VoIP providers (including Skype) use VBR codecs to minimize bandwidth usage while maintaining call quality. Under VBR, the size of the codebook entry, and thus the size of the encoded frame, can vary based on the complexity of the input frame. The specification for Secure RTP (SRTP) [3] does not alter the size of the original payload; thus encoded frame sizes are preserved across the cryptographic layer. The size of the encrypted packet therefore reflects properties of the input signal; it is exactly this correlation that our approach leverages to model phonemes as sequences of lengths of encrypted packets.

That pretty much summarizes the paper. CELP + VBR means that message length is going to depend on complexity. Due to how linear prediction works, more information is needed to encode a drastic change in sound — like the pause between phonemes! This allows the authors to build a model that can break an encrypted audio signal into phonemes: that is, deciding which audio frames belong to which unit of speech.

They then built a classifier that, still only using the packet length information they started with, decides which segmented units of encrypted audio represent which actual phonemes. They then use a language model to correct the previous step’s output and segment the phoneme stream into words and then phrases.

The crazy thing is that this whole rigmarole works! They used a metric called METEOR and got scores of around .6. This is on a scale where <.5 is considered “interpretable by a human.” Considering that the threat vector here is a human using this technique to listen in on your encrypted VoIP calls — that’s pretty amazing!


Epilogue

After passing the rigorous all-night culture fit screening, you end up getting the job. Six months later, Mont Piper is sold to a large conglomerate. Gary refuses to trade in his Norwegian metal t-shirts for a button-down and is summarily fired. You now spend your days going on-site to a big bank, “advising” a team that hates your guts.

But recently, you’ve picked up machine learning and found this really cool online game where you try to make a 6-legged robot walk in a 3d physics simulation…


P.S.


Paying the Bills

Vulnerabilities come out every day, and most don’t get blog posts like this written about them.

Our product, Appcanary, monitors your apps and servers, and notifies you whenever a new vulnerability is discovered in a package you rely on.

Sign up today!

Appcanary now supports Debian!

I’m excited to announce that Appcanary now fully supports Debian. If you install our agent on a Debian server, we will email you notifications whenever any package you have installed on your system has a known vulnerability. We track over 24,000 vulnerabilities already!

You can also use our Check API to verify if your Debian server has any vulnerable packages, and our Monitor API to register to receive notifications if a set of Debian packages ever has new vulnerabilities.

If you’re not a current user and want to try out Appcanary for Debian, you can sign up!

You can always let us know what you think at hello@appcanary.com.

Two new APIs from Appcanary

After the success of our check API, we found that our users told us:

“I love your API so much! But can I use it register the packages my app uses and get emailed if new vulnerabilities that affect me come out? Oh, and it would be nice if I could pragmatically query the servers I have agents running on too!”

So we went ahead and built both.

The Monitor API

The “Monitor” API lets you register a Gemfile or an Ubuntu/CentOS package list to be emailed when new vulnerabilities are discovered. It like what our agent does, but in situations where it doesn’t make sense like when you use Docker or deploy on a PaaS like Heroku.

You can register a new monitor by:

curl -H "Authorization: Token YOURTOKENHERE" \
     -X POST -F file=@./Gemfile.lock \
     https://appcanary.com/api/v2/monitors/my-great-app?platform=ruby

and you’ll get a response like:

{
  "data": {
    "type": "monitor",
    "attributes": {
      "name": "my-server",
      "uuid": "56eac124-35c2-49bd-ab02-45de56c03ef4",
      "vulnerable": true
    }
  }
}

And, you’ll be emailed about any vulnerabilities that affect your app as soon as we find out about them!

You can also list, inspect, or delete monitors via the API. More information here.

The Server API

The “Server” API allows you to navigate the servers you have the Appcanary agent running on via API, and list any vulnerabilities that affect them!

I can see the servers I have agents running on with: bash curl -H "Authorization: Token YOURTOKENHERE" \ https://appcanary.com/api/v2/servers

and you’ll get a response like:

{
  "data": [
    {
      "type": "server",
      "attributes": {
        "name": "server1",
        "uuid": "55a5baeb-2ad4-4787-8784-a062d254900e",
        "hostname": "server1",
        "last-heartbeat-at": "2016-03-27T03:33:02.185Z",
        "vulnerable": true,
        "apps": [
          {
            "type": "app",
            "attributes": {
              "name": "",
              "path": "/var/lib/dpkg/status",
              "uuid": "55a5baec-3e5c-4cca-832c-06aaa36418f6",
              "vulnerable": true
            }
          },
          {
            "type": "app",
            "attributes": {
              "name": "",
              "path": "/var/www/myapp/current/Gemfile.lock",
              "uuid": "55a5baec-027d-4618-b8de-12638281f34c",
              "vulnerable": true
            }
          }
        ]
      }
    },
    {
      "type": "server",
      "attributes": {
        "name": "server2",
        "uuid": "560b0e75-1317-481c-98bb-15e6ae5978b6",
        "hostname": "database",
        "last-heartbeat-at": "2016-03-08T00:21:31.105Z",
        "vulnerable": true,
        "apps": [
          {
            "type": "app",
            "attributes": {
              "name": "",
              "path": "/var/lib/dpkg/status",
              "uuid": "560b0e77-0a26-41fd-bc35-38b5aac33709",
              "vulnerable": true
            }
          }
        ]
      }
    }
  ]
}

You can also inspect or delete any server with an agent on it via the API.

Our API fully supports Ruby, Ubuntu, and CentOS 7! Learn more about how to use it by visiting the docs page.

You can sign up for Appcanary to use our APIs today!

Hello, new Appcanary API and CentOS support!

A lot of our users have told us,

“Gosh, I love knowing exactly which packages I have to update in order to keep my apps and servers secure. Have you thought about an API?”

We listened carefully to that feedback, and it is with pride and pleasure that we’re announcing our new beta! We’re still busy improving it, so we won’t charge you for it for now.

Once you sign up, all you have to do is issue a curl:

curl -H "Authorization: Token YOURTOKENHERE" \
     -X POST -F file=@./Gemfile.lock \
     https://appcanary.com/api/v2/check/ruby

and you’ll get a response like:

{
  "vulnerable": true,
  "data": [
    {
      "type": "artifact-version",
      "attributes": {
        "name": "rack",
        "kind": "rubygem",
        "number": "1.6.0",
        "vulnerabilities": [
          {
            "title": "Potential Denial of Service Vulnerability in Rack",
            "description": "Carefully crafted requests can cause a `SystemStackError` and potentially \ncause a denial of service attack. \n\nAll users running an affected release should upgrade.",
            "criticality": "high",
            "cve": [
              "CVE-2015-3225"
            ],
            "osvdb": [],
            "patched-versions": [
              "~< 1.5.4",
              "~< 1.4.6",
              ">= 1.6.2"
            ],
            "unaffected-versions": [],
            "uuid": "55807540-053f-40f0-9266-a3d1ca6a5838",
            "upgrade-to": [
              ">= 1.6.2"
            ]
          }
        ]
      }
    }
  ]
}

Our API fully supports Ruby, Ubuntu, and CentOS 7! You can learn more about how to use it by visiting the docs page.

Which reminds us,

We now support CentOS 7!

Appcanary now fully supports CentoOS 7. If you install our agent on a CentOS 7 server, we will email you notifications whenever any rpm package you have installed on your system has a known vulnerability.

If you’re not a current user and want to try out Appcanary’s API and/or use us to monitor your CentOS 7 servers, you can sign up!

You can always let us know what you think at hello@appcanary.com.