Matasano Chargen - Latest Comments in Matasano Security Recommendation #001: Avoid Agents

Re: Matasano Security Recommendation #001: Avoid Agents

Thomas Ptacek — Sat, 26 May 2007 22:44:12 -0000

Not sure what you meant by that...

Re: Matasano Security Recommendation #001: Avoid Agents

HAL — Sat, 26 May 2007 22:21:39 -0000

And you guys were getting so close. Well, it's a brave new world.

Be seeing you....

Re: Matasano Security Recommendation #001: Avoid Agents

Miguel Lourenco — Sun, 29 Apr 2007 14:40:13 -0000

I wonder if you guys or anyone has any input into the security of open source agent based configuration management applications like cfengine and bcfg2? Or even, how they stack up against these proprietary ones in terms of what they achieve? Having no hands on experience with proprietary ones I would be curious in knowing...

Re: Matasano Security Recommendation #001: Avoid Agents

batz — Mon, 18 Dec 2006 14:28:37 -0000

With respect to the vast knowledge about systems and security that is collected here, there is a difference that is overlooked in this discussion. From the perspective of an ITSec manager, I've found that when something goes wrong with an agent solution it is his problem, whereas with an appliance solution, it is the vendor's problem.

It's a matter of what the culture of the company is. Government tends towards appliance solutions because the security group can use it to establish a beachhead in the data centre and extend their influence outward over the various IT silos by offering a service.

Smaller companies, particularly ones with large mobile sales forces will go for the agent solution because they can actually manage the security of the laptops via the agents, and they have the authority to get the agent on all the machines. This is exceedingly difficult in government systems, though it is occasionally done.

The minutae of different sectors comes into play to determine which solution is more suitable to them, however, few will ever make the decision of which technology to deply based on the esoteric (albeit important) arguments raised in this discussion.

Re: Matasano Security Recommendation #001: Avoid Agents

ivan — Sat, 16 Dec 2006 14:32:18 -0000

three words: Pass the hash
ok, ok, lets not be picky... Berkeley r*
DNS, NFS, NDS, AD...
So what's my point? Agents are not an intrinsically bad idea, the design (and implementation) of their current incarnations are. All these technologies were thought off following the paradigms of the previous decades: client/server architectures, centralized control on star-topology or hierarchical networks, monolithic code, centralized databases, etc.
Distributed databases, mobile code, reputation-based systems and P2P networks are all alien concepts (or at least "interesting research ideas") to the current vendors of agent-based products, if you add to that software bloat, agent complexity and poor security development practices you can easily justify aversion to all agent-based technology but I would not dismiss all of it just because all current, well-known vendors lack the imagination and guts to build things differently and show that they are forward-thinking organizations, at the possible expense of cannibalizing their business.

Re: Matasano Security Recommendation #001: Avoid Agents

Thomas Ptacek — Wed, 13 Dec 2006 00:04:09 -0000

Very few OS services establish transitive trust relationships amongst every machine running the service.

Re: Matasano Security Recommendation #001: Avoid Agents

ivan — Tue, 12 Dec 2006 23:57:39 -0000

hm ok.. and how are these third party agents any different from your run-of-the-mill OS service?
In the end its just the same thing and you don't want redundant, complex and bloated services that provide a larger attack surface either right?

Re: Matasano Security Recommendation #001: Avoid Agents

Anton Chuvakin — Mon, 11 Dec 2006 19:16:53 -0000

Hmm, how is it not obvious? Given a choice of achieving THE SAE without an agent or with an agent, who would say "yep, I wonna run another piece of vulnerable software on all of my X,000 servers and X0,000 workstations, etc..."

However, the sad truth is that sometimes you cannot do it without an agent or you can but you'd open a bigger-than-agent security hole in the process...

Re: Matasano Security Recommendation #001: Avoid Agents

Thomas Ptacek — Mon, 11 Dec 2006 15:40:49 -0000

Nope. There is zero chance that agents are going away. There is, at this point, zero notion of doing an agent product here.

We just don't think people are thinking about agent security enough.

Re: Matasano Security Recommendation #001: Avoid Agents

Al Huger — Mon, 11 Dec 2006 15:28:12 -0000

Hey Tom,

Well written. You are not coming to market soon with a product that will prove to be a panacea to this issue, are you?

-al

Re: Matasano Security Recommendation #001: Avoid Agents

Thomas Ptacek — Mon, 11 Dec 2006 08:15:49 -0000

I can't list the software we tested without listing the software that was vulnerable, because all of it was vulnerable (with one easy-to-deduce exception). We haven't yet agreed on a way to release information about vulnerable vendors before they've patched.

I'm sorry it seems disingenuous. It isn't.

Re: Matasano Security Recommendation #001: Avoid Agents

Amrit — Mon, 11 Dec 2006 03:03:48 -0000

BTW - Why don't you list the software you tested and found to be insecure or not list any at all. This is kind of like me saying "penetration testing companies are a serious risk to your intellectual property and there is lots of evidence of compromised or stolen code, or vulnerablities found and made public without the research firms following responsible disclosure. Examples of penetration testing companies are Matasano, Symantec." It just seems really disingenuous.

Re: Matasano Security Recommendation #001: Avoid Agents

Amrit — Sat, 09 Dec 2006 23:07:30 -0000

Reality is that until we go back to a thin-client architecture, systems and security management agents are required. No other way to do all the things IT needs to do to the end-points, from a security or an operational perspective. Of course it is in the best interest of a network security company to demean agents, just as it it would be in the best interest of an agent-based vendor to cry foul of all the failues in network security.

You need both. Anyone who tells you otherwise has an agenda. I agree that organizations need to limit the amount of agents deployed, there are far too many fighting for control of system resources. But this doesn't mean you do not need any.

So the advice is really to eliminate redundant and insecure agents and realign disparate agents into a common management infrastructure.

Advising organizations to place a high-value assets on syst3ems with no agents it not good advice.

Re: Matasano Security Recommendation #001: Avoid Agents

toby — Sat, 09 Dec 2006 22:15:17 -0000

And of course there's the information leakage that occurs when the agent tries to phone home to its central server no matter what network it is on or whether the central server can be reached or not. Or worse, just using Karma at that point to spoof the central server....

You know, the irony is that there are other impacts as well. BigFix's agent may be able to manage other software but it has a massive hit on battery life due to the way it is constantly hitting the disk. It also listens all the time and hence is available no matter what network I'm on.

I can't speak to Blink 3.0 but I can observe that there is more than just having a kick-ass agent, you have to have a decent central console among other things. Though I have to admit, I have greater hopes that Blink would not have the typical vulnerabilities than other agents.

McAfee's collection of agents take up more RAM between them than many applications. I can always tell when McAfee is updating because it pegs my processor and kills all response. Now they are trying to integrate it with ePO which just makes me feel all warm and fuzzy...

Re: Matasano Security Recommendation #001: Avoid Agents

Thomas Ptacek — Sat, 09 Dec 2006 11:40:51 -0000

You CAN hide your agent traffic in SSL tunnels, and that might not be a bad idea, but remember, one of the central problems with this architecture is that no matter what you do to provide access control and protect the protocols, you have 1000+ machines with legitimate access to the underlying protocol.

It's not practicable to keep 1000 diverse machines secure. Forget it. It's not going to happen. Now you're in a spot where, when any one of those machines happens, everything you've attempted to do to protect the management server is nullified.

"It's the application, stupid!"

Re: Matasano Security Recommendation #001: Avoid Agents

Ryan Russell — Fri, 08 Dec 2006 23:28:45 -0000

So here's the long, drawn-out version of my response:
http://ryanlrussell.blogspot.com/2006/12/nothin...

Re: Matasano Security Recommendation #001: Avoid Agents

dre — Fri, 08 Dec 2006 19:18:29 -0000

somehow the expression 's/strategies/mitigation strategies' got out of the last sentence and into my name as an "i". i'm sure you're all doing your mental calculations / parsing on that and i appreciate. i blame trackpads.

Re: Matasano Security Recommendation #001: Avoid Agents

dri — Fri, 08 Dec 2006 19:06:58 -0000

Classes of vulnerabilities uncovered included

agreed. this stuff is scary. i take it you're not talking about munin, nagios, or net-snmp agents.

also did you miss Ross Brown's point about consolidation of agents or did you choose to not respond to it yet on purpose?

for the client-side, can't we load up netcat to bind to a tcp or udp port on localhost and send enterprise traffic to it (make the management station setting in the client equal to 127.0.0.1), which then pipes to stunnel? and then stunnel sends the traffic to the real management station? and then the management station listens with stunnel and sends the traffic on localhost to the real management application?

there's a certain `consolidation of agents' in a nutshell.

maybe it would be a good idea to write the gluelayer that is netcat/stunnel, make it work well with windows, and document it and release it to the public? this would secure the traffic on the wire.

for now, i'll call it simply, "gluelayer", since it doesn't exist.

but there is still a problem of the listeners on the enterprise mgmt apps. if you can't shut them off easily (note that i don't trust firewalls), maybe you could completely intercept them assuming they don't bind to every address+socket and also use SO_REUSEADDR, SO_EXCLUSIVEADDRUSE, or enhanced socket security. hijacking a server socket is as simple as binding to a specific IP address (again, gotta love that netcat). another gluelayer project, but this one doesn't work in every situation and has a lot of requirements and dependencies.

i hate to use the words "layer-3 switches at the access-layer and firewall every port", but i don't trust software firewalls (however, http://force.coresecurity.com is NOT bad).

but COME ON, TOM. you know that MITM is a much worse attack than attacking the listener since ARP poisoning is so prevalent still. and don't tell me you didn't teach your kids how to use Cain (http://www.oxid.it) yet, because anybody can use this stuff. maybe i should provide some links to DHCP snooping, IP/MAC source guard, and dynamic arp inspection (Cisco's DAI).

oh crap i just said Cisco, nevermind everything i said. make sure to also set port-security to 1 static and 1 dynamic per port as well to prevent CAM table overflow. and 3,000 other "also's / as well's".

in reality though people - somebody has already thrown ettercap and openssl into post-phatb0t code (no wait, openssl was in the original phatb0t). downgrade attacks (i could use netsed for this) work great as well. i'm sure Matasano uses more advanced techniques than just these. they probably read chapters 4 and 5 of "hunting security bugs (Microsoft Press)".

oh and i spelled phatbot wrong. it doesn't have a zero... that was for random self-post-bumping.

your strategies are great! i guess future recommendations you might want to incorporate would be using consolidated agents, implementing DAI in the network, and/or possibly moving to IPv6.

Re: Matasano Security Recommendation #001: Avoid Agents

Thomas Ptacek — Fri, 08 Dec 2006 16:46:36 -0000

One of the most broken systems we looked at had smart programmers and had a team that included the designer of a well-regarded authentication protocol.

How do you know what applies to you or doesn't apply to you unless you've tested? And if you've tested, can't you just explain what you tested, how you tested it, and what it means for the security of your design?

Re: Matasano Security Recommendation #001: Avoid Agents

Ryan Russell — Fri, 08 Dec 2006 16:28:15 -0000

I don't know if the other agents are bad, I'm taking your word for it. I haven't done any real competitive analysis. Sure, many of your recommendations are great, some don't apply, depending on the design.

I especially like the recommendations to not make programming errors and create bad protocols.

Oh wait, the sarcasm got turned back on there again for a sec, sorry. ;)

Re: Matasano Security Recommendation #001: Avoid Agents

Thomas Ptacek — Fri, 08 Dec 2006 13:41:17 -0000

Ross: I didn't just say "run fewer agents". I also said "use fewer agent vendors". I see those as two significantly different, equally important recommendations.

I wouldn't be even close to surprised to find that eEye has the strongest agent implementation on the market; you have an excellent team. But you should be able to document what you did to secure Blink.

Re: Matasano Security Recommendation #001: Avoid Agents

Thomas Ptacek — Fri, 08 Dec 2006 13:38:48 -0000

I have several friends at agent vendors. All of them like their agents, and agree that everyone else's are terrible. I'm willing to concede the point if you're willing to concede that our recommendations are good.

I'll reiterate that we haven't looked at BigFix. BigFix might have excellent security. But if it does, it will be an anomaly.

Re: Matasano Security Recommendation #001: Avoid Agents

Ryan Russell — Fri, 08 Dec 2006 13:35:49 -0000

If you don't like agents, would you advocate scanners or sneakernet? (Sarcasm off)

I can't disagree that customers should look at reducing the number of agents, since Big Fix produces an agent that can (and does) manage just about anyone else's software. And we do that with ONE agent, not by adding slave agents, etc... For example, we will take care of code and sig updates for I think 6 or more AV vendors.

Any further rebuttal would require some sort of architecture documentation, which I'm still behind on.

Re: Matasano Security Recommendation #001: Avoid Agents

Ross Brown — Fri, 08 Dec 2006 13:32:07 -0000

Hey, I got an idea. How about we put all the security functions into a single, hardened agent to reduce the number of agents running to as few as possible?

Wait, we already did that with Blink Professional. V3.0, which comes in the next few weeks, consolidates about 10 different agents into a single agent, hardened from exploitation and managed using a secured architecture.

Thomas is right in the principle of 'less is more' when it comes to agents. I like the idea of having as few agents as possible running, but with systems management, software distribution and the need to secure the underlying OS and applications, it becomes a need to balance risk against functionality.

Re: Matasano Security Recommendation #001: Avoid Agents

Thomas Ptacek — Fri, 08 Dec 2006 12:50:28 -0000

Enterprise security teams, who are your buyers, should have as a primary objective "minimize the number of agent installations and the number of agent vendors supported". I'm pretty sure these aren't primary goals today. They should be.