Exposing Tanium: A Hacker’s Paradise(penconsultants.com)
penconsultants.com
Exposing Tanium: A Hacker’s Paradise
http://penconsultants.com/blog/post/exposing-tanium-a-hackers-paradise
9 comments
There is an undercurrent of "This is completely unacceptable," but anyone who's been a pentester will tell you these are pretty standard enterprise blunders.
Rather than trying to expose malfeasance, try to write with a spirit of helping others correct problems. Everyone screws up security, even HN: https://news.ycombinator.com/security.html
Also, 21 exclamation points are a bit much.
If you're looking for a model for good technical writing, NCC Group makes some of their audit reports available publicly, e.g. https://www.nccgroup.trust/us/our-research/ricochet-security...
Rather than trying to expose malfeasance, try to write with a spirit of helping others correct problems. Everyone screws up security, even HN: https://news.ycombinator.com/security.html
Also, 21 exclamation points are a bit much.
If you're looking for a model for good technical writing, NCC Group makes some of their audit reports available publicly, e.g. https://www.nccgroup.trust/us/our-research/ricochet-security...
> Also, 21 exclamation points are a bit much.
Yes, 17 is the limit!
Yes, 17 is the limit!
As long as line length is pep8 compliment, there can be as many exclamation points as you want.
There's a lot of talk about data confidentiality, but I would argue that the data you could get from any one endpoint would be useful for reconnaissance within its own peer neighborhood, and not much else, but I welcome use cases where I'd be wrong.
Additionally, downloading a client without getting the public key for the server won't help you - you can't just connect to any server you find. The author then links to a KB article about generating a different key than the one he would need anyway.
Relying on any vendor's documentation for proof of anything is the first mistake this author made. Giving himself an out by not actually trying any of these things, or weighing drawbacks against the benefits, means this is little more than speculative clickbait.
Additionally, downloading a client without getting the public key for the server won't help you - you can't just connect to any server you find. The author then links to a KB article about generating a different key than the one he would need anyway.
Relying on any vendor's documentation for proof of anything is the first mistake this author made. Giving himself an out by not actually trying any of these things, or weighing drawbacks against the benefits, means this is little more than speculative clickbait.
> Additionally, downloading a client without getting the public key for the server won't help you - you can't just connect to any server you find.
Right. The fact that the client is publicly accessible is a point in the vendor's favor, if anything: the fact that this "auditor" seems to think security-by-obscurity is a good idea makes me question why I bothered to read any of it.
Right. The fact that the client is publicly accessible is a point in the vendor's favor, if anything: the fact that this "auditor" seems to think security-by-obscurity is a good idea makes me question why I bothered to read any of it.
> If each workstation is doing data aggregation of the data it’s receiving from its peers, what does that require about its ability to read the plaintext data from its peers?
Uh, nothing? Encryption has existed for several decades?
I mean, I have no idea if they're actually using encryption, but "use logical reasoning" is not an explanation of why they necessarily must not be using encryption.
> As you should have discovered from the previous challenges, it would be impossible for peers to perform deduplication/aggregation with other peers if they were unable to see cleartext/plaintext data.
This is absolutely incorrect.
> The first thing to note is that the "hashing" algorithm appears to be something home grown, as opposed to an industry standard (md5, sha1, etc.).
This needs proof that this is what the actual client does, as opposed to just an example for a human-readable FAQ for readers who don't know what hashing is. (Also, I question the competence of someone who's writing up an analysis and thinks of MD5 and SHA-1 as their first industry-standard hashes.)
> 13.x.y.133 Amazon Corporate Services Pty Ltd
... This is an AWS host. Attributing it to Amazon itself is just incompetent. https://ip-ranges.amazonaws.com/ip-ranges.json
(Full disclosure: I am unaffiliated with Tanium and have never used it, but I think a couple of former coworkers from a now-failed startup now work there.)
Uh, nothing? Encryption has existed for several decades?
I mean, I have no idea if they're actually using encryption, but "use logical reasoning" is not an explanation of why they necessarily must not be using encryption.
> As you should have discovered from the previous challenges, it would be impossible for peers to perform deduplication/aggregation with other peers if they were unable to see cleartext/plaintext data.
This is absolutely incorrect.
> The first thing to note is that the "hashing" algorithm appears to be something home grown, as opposed to an industry standard (md5, sha1, etc.).
This needs proof that this is what the actual client does, as opposed to just an example for a human-readable FAQ for readers who don't know what hashing is. (Also, I question the competence of someone who's writing up an analysis and thinks of MD5 and SHA-1 as their first industry-standard hashes.)
> 13.x.y.133 Amazon Corporate Services Pty Ltd
... This is an AWS host. Attributing it to Amazon itself is just incompetent. https://ip-ranges.amazonaws.com/ip-ranges.json
(Full disclosure: I am unaffiliated with Tanium and have never used it, but I think a couple of former coworkers from a now-failed startup now work there.)
Tanium has more holes than a colander.
It has a nice interface for enterprise security staff. It is supposed to reveal security problems for enterprises. While it does a pretty good job to report common attacks, it is useless for identify above average hackers and introduces new vulnerabilities that are a hacker heaven.
In general, anybody that is after the enterprises's data will consider any enterprise software a huge honey pot.
If you are serious about security, invest the money that you pay for Tanium's licenses to hire security experts, instead than IT candies for below average security staff.
It has a nice interface for enterprise security staff. It is supposed to reveal security problems for enterprises. While it does a pretty good job to report common attacks, it is useless for identify above average hackers and introduces new vulnerabilities that are a hacker heaven.
In general, anybody that is after the enterprises's data will consider any enterprise software a huge honey pot.
If you are serious about security, invest the money that you pay for Tanium's licenses to hire security experts, instead than IT candies for below average security staff.
I've seen security vendors fail far too often to think they're infallible, but I've also seen overzealous security 'researchers' make incorrect claims about vulnerability based on misconfiguration or lack of product knowledge. This however goes so far beyond... At least he/she had the chutzpa to say it upfront.