I recently had the privilege to perform full scope application security testing against 1E’s Tachyon, an endpoint incident response and remediation platform. I was so impressed with it, I sought (and received) approval from 1E to release this article publicly, detailing my impressions.

Earlier this year, 1E and I began dialoguing about the possibility of evaluating their product. It was a true honor and privilege to be given this opportunity, and is an even greater honor to be allowed to share what I found.

My Tachyon Testing

After NDAs, negotiations, and agreements, I was given access to a fully working Tachyon demo environment and the installers to stand-up as many endpoint nodes as I saw fit for my testing. I was granted 90 days access to the Tachyon agent and infrastructure. 1E permitted me to come at Tachyon with everything I had, utilizing my 15 years of infoSec knowledge. Additionally, I was given full admin access to every part of the infrastructure so I could perform more detailed and accurate “white box” testing.

Tachyon vs Tanium

Background

As many know, I wrote about some serious and fundamental issues with another endpoint product – Tanium. I performed research about the product based on their documentation and marketing material, drafted an article with my concerns, then sent it (pre-release) to Tanium asking for feedback. After 7 days, two emails and zero responses, I published the article. To this date (1 year later), they still have not offered me access to the platform to prove my claims false, nor have they even returned an email.

Unlike Tanium, 1E bent over backwards to provide me full access to the Tachyon platform and everything needed to setup a fully working demo environment. I have received a response for every email sent. Every claim I made about their product was taken seriously and has been addressed.

Introduction

This article is about the fundamental differences in not only the two products, but the differences of the vendors themselves. I will also compare their willingness to work with a security researcher, address concerns, and allow for public disclosure of one’s impressions. I hope this article not only continues to encourage the dozens of people who have contacted me about Tanium, but I hope it also encourages you to take a serious look at 1E and consider their Tachyon platform.

The following is a comparison of 1E’s Tachyon and Tanium Core. Tanium does not appear to grant researchers access to their product. Last year, I managed to learn a great deal from their publicly accessible documentation, installers, and customer deploys, as seen in my article. Even more, I have been honored to talk with, email and IM with numerous individuals and teams who are current or former Tanium customers in several major industries, some of which are at multiple levels of the DoD. It is with this combined knowledge that I would like to share where I feel Tanium is weak and Tachyon is strong.

Distributed Scripting

At the time of my article last year, Tanium was sending scripts (aka “Tanium sensors”) to the endpoint, unencrypted, as flat files. Several months after my article, I learned from Tanium customers that Tanium was getting away from flat files with a progression towards putting things such as scripts and query parameters in a SQLite DB with some of the data encrypted. Multiple Tanium customers have confirmed it is now even more trivial to gain access to and decrypt/decode the scripts/sensors/parameters due to multiple implementation shortcomings. Another concern I have heard is virtually every query that is run places a script on disk. Very little functionality is built into the agent, it just runs those scripts, thus making the exposure/attack surface much greater.

Tachyon injects instruction content (ex. customer created scripts) directly into processes/interpreters without needing to write to disk, thus making it more secure. Out of the many built-in instructions, I found none writing so much as a temp file to disk. It is truly in-memory only. The only way I found to get to a handful of scripts on the endpoint (other than scraping memory) was through the enabling of verbose WMI/Powershell/agent/etc. logging. 1E has taken steps to mitigate much of this and includes details, in customer install documentation, on how to harden these logs to limit access to the rest. With that said, the vast majority of the built-in instructions require no scripts at all and are fulfilled by “method” processes internal to the Tachyon agent in the 1E SCALE language (Simple Cross-platform Agent Language for Extensibility).

Peer Chain

As described in my article last year, Tanium passes around queries and query results through (up to) 100 other (potentially infected) peer nodes. That is a hacker’s dream…pop one endpoint and see data from (up to) 100 other endpoints. As a result, not only is unencrypted (hashed) data sent from each node to others, but, Tanium has listening TCP ports on every endpoint. Any listening port is a potential entry point for an attacker, and potential DDOS target.

In contrast, Tachyon does not pass any data from one peer to another, much less sensitive query parameters and results. Tachyon Agents initiate all connections, so no listening TCP ports in their architecture. All data is sent directly between the Tachyon Agent and “Tachyon Switch” server side listeners which act as the gateway between the Tachyon Agent and Tachyon Core.

Encryption

Tanium’s architecture literally prevents client-to-server encryption. They are purposely allowing data confidentiality to be violated because of their endpoint data aggregation “feature”. This feature requires that the endpoint sees cleartext data from its peers, thus, making endpoint-to-server encryption and data confidentially an architectural impossibility. This, in conjunction with the fact that this data is being passed around to (up to) 100 other endpoints, is the reason I cannot stress enough – do not deploy Tanium in your environment until/unless they fix this huge architectural flaw.

Tachyon, however, has true and properly implemented endpoint-to-server encryption. They utilize industry standard (TLS) encryption between a single endpoint and the “Tachyon Switch” server. I was unable to leverage any of the well-known SSL/TLS attacks against the encryption. It is cryptographically and architecturally infeasible for one peer to see another peer’s agent traffic or data.

Hashing

Tanium claims to provide data confidentiality with “hashing”. Do not be fooled by Tanium’s smoke and mirrors around hashing. I have been told that any junior level hacker can easily decipher it from “the wire”, memory, or disk.

Tachyon provides true confidentially through real encryption. It does not play around with immature obfuscation techniques for data confidentiality.

Tachyon Vulnerabilities

Although there are many positives, Tachyon is not perfect. Throughout the course of my 90 days of access, I did discover a few vulnerabilities in the testing environment I was using, ranging from a severity score of “info” all the way up to a “critical”:

• 8 of the 19 discoveries were attributed to the somewhat atypical demo environment I was given. I am reasonably certain (after discussing them with the vendor) that these 8 would not be found in a typical install.
• 4 of the 19 were fully corrected and/or mitigated within just a few days of receiving my disclosure.
• The remaining 7 (3 Med, 4 Info) are being resolved with the next major release. Mitigations were put in place for the three Mediums until the code changes get pushed.

In short, all of the “High” and “Critical” issues were related to the non-standard implementation and have been corrected already. No material issues were found with Tachyon itself and the only remaining issues are of “Info” status.

Consider Tachyon

[This is not a vendor endorsement. This is a testimonial of my experience with this product and vendor.]

You may ask, “Why should I purchase a product that has had known vulnerabilities?”.

I’ve been in infoSec for 15 years and have evaluated hundreds of products/services with different levels of rigor. There have been exactly ZERO products with no security gaps. Strictly looking at the number of vulnerabilities a product has over time is a meaningless metric to have for a vendor, IMO. Instead, considering the following is a much better approach.

Three Things to Consider

Three things I would encourage you to consider when thinking about the overall security maturity of a vendor (such as 1E) are:

1. The Fundamentals

I found no fundamental flaws with Tachyon, unlike with Tanium. All gaps, even the highs/critical, were easily addressable. As mentioned above, several of them were demo specific and non-issues in a typical corporate environment.

2. Vendor Transparency

Vendor transparency is a major difference between Tanium and 1E. Their treatment of me, a security researcher, could not be more diametrically opposed. Tanium is not alone in trying to suppress security research and independent review, though. Here are three more recent examples: https://www.zdnet.com/article/nss-labs-files-lawsuit-against-crowdstrike-symantec-eset-amtso

1E’s leadership was easy to work with and surpassed my expectations by allowing me to write this article. They even stated that they intend to release a portion of my 31-page app testing report to some of their prospective customers. When I asked one of their VPs (Jason Keogh) about this, he told me, “I believe very strongly that good security should stand up to scrutiny”.

This level of transparency is nearly unheard of during my 15 years in infosec. Although vendors often state they are transparent, I can count on one hand the number of vendors who truly are. 1E is one of those.

3. Honesty and Ownership of Issues

1E began immediately (as in hours) to address every one of my 19 findings. The most common reply I received from 1E was [paraphrasing], “You’re right. That is an issue, and we’ll get it fixed immediately”.

On the contrary, Tanium and their surrogates denied every claim. Think I’m exaggerating about that? Here are two examples of their surrogates in action:

• On 29 Nov 2017, DIUx (Defense Innovation Unit Experimental) sent me an email which stated (among other things), “We did a protocol review and don’t see an architecture that aligns with your assessment.” You tell me: Are they just incompetent, or spinning the facts? Interestingly enough, of the more than a dozen DoD personnel/leaders I’ve communicated with about Tanium, this was the only one that denied the issues.
• On 08 Aug 2018, a former Tanium employee denied every raised issue: https://penconsultants.com/home/exposing-tanium-a-hackers-paradise/#comment-4029651620.

They say the first step to getting better is to admit you have a problem. Tanium is not likely to change until they admit their architectural flaw. 1E is a mature vendor. You can trust them to admit their faults, correct their faults, and even thank you for pointing their faults out.

Other Items to Consider

Other items to consider and questions to ask a prospective vendor:

3rd-Party Software

Does the product rely on 3rd-party software to perform core functions? Sure, customers having the ability to utilize 3rd-party software, at will, is a plus. But, do you really want to be forced into the usage of random software the vendor has strapped together with their product in order to make it run?

Think about the additional risks. Whether you like it or not, you must now be concerned about the security maturity of every vendor tied to every piece of 3rd-party software within that environment. Is your vendor going to quickly update/patch all of that 3rd-party software when public vulnerabilities are discovered and exploits are released? The weakest link could be used to compromise your environment.

And, what about the 3rd-party tools which can be used/abused by an attacker, such as psexec, nmap, pscp, npcap etc.? Do you really want those tools to be required on each endpoint in order for the product to work? Worse yet, do you want your vendor telling you that not only is it required, but you “must create exclusions” for those to “run without interference” and that they “expressly disclaim all warranties and liability of any kind related to such Third Party Items”? (Source: https://docs.tanium.com/discover/discover/requirements.html#host_and_network)

Talk about a hacker’s paradise! I don’t even need to bring along my own tools; Tanium provides them for me!

Tachyon does not needlessly expose you to any of these risks. They have built the core functionality into their software while still giving you the OPTION to run 3rd-party software if YOU want to.

Protected Binaries

Consider how the product and its core components are assembled (from a code perspective). See this article for more information: https://penconsultants.com/home/vendor-protect-your-code-and-your-customers/.

Tachyon uses machine-compiled C++ for their binaries, which are also signed, making decompilation to a higher level language much harder and binary “patching” (or trojanizing) nearly impossible.

By comparison, as pointed out earlier, most of the Tanium functionality is provided by scripts sent to each endpoint for execution. These simply cannot be as secure as compiled code!

A Challenge to Vendors

Are you going to be like Tanium and cower away from a hacker like me and deny you have any issues? Or, will you put your pride aside and allow me to help you find and fix your weaknesses?

I go out of my way to be fair with responsible vendors and their products. Click here to see Pen Consultants’ growing list of testimonials and companies we have helped: http://penconsultants.com/testimonials.

I challenge you to do what 1E has done. Give me access to your product for 90 days and let me rip it apart, highlighting every gap I can find. And/or, invite me to come, red team, your organization. My prices, for the services provided, are unbeatable: http://penconsultants.com/services.

Thanks

A final thank you to 1E for giving me the opportunity to evaluate their product, Tachyon. It was a huge honor to be given access, and it was great seeing things done right with machine-compiled and signed binaries, client-to-server communications (not “client peering”), and encrypted (not “hashed”) communications. A special thanks to Corné, Mark, and Jason for being a great team to work with throughout the testing and disclosure process.

Featured image (background) courtesy of tenleaf: https://pixabay.com