Disturbing trend - Hiding in plain sight

Hey Hey,

My roommate and I were discussing this earlier and it happened to tie in with some work I was doing at the college today..

Why wouldn't something similar to Proxy Authentication do the trick... While something that caches on the router wouldn't be sufficient.... Something that creates a cookie would do the trick. If these programs are self-contained (which I believe is what was previously mentioned) the odds of them having the proper code to connect to a proxy, authenticate and store/use the cookie seems very unlikely. The user logs in in the morning and the first time they use IE, they authenticate... They get a cookie and the proxy reads the cookie and allows the users to access the internet using http/https. At the same time, since the odds are the malware code can't properly authenticate against the proxy, it'll be stopped dead... If nothing else it will be another cog in the wheel to slow them down.

Peace,
HT

Quote:

---

The user logs in in the morning and the first time they use IE, they authenticate...

---

But that's an HTTP connection they will most probably be connecting on. You'd be better off to auth on the first SSL connection to receive the cookie to minimize user intervention, (Read: Whining... ;)). Those that din't do their online banking from work will never be affected by the additional authentication and those that require business related SSL connections can have the need to prove that it is actually them connecting to the information explained to them. If they don't like it MacDonalds is hiring.... :D

Greetings HT,

Quote:

---

They get a cookie and the proxy reads the cookie and allows the users to access the internet using http/https. At the same time, since the odds are the malware code can't properly authenticate against the proxy, it'll be stopped dead... If nothing else it will be another cog in the wheel to slow them down.

---

If I understand you correctly, you are suggesting a form of port authentication, where clients would be denied outbound access on specified ports based on an authentication mechanism. This would indeed stop this software, at least temporarily, if it was unable to gain permissions to use port 443. However, once a web browser had gained permission to use that port, the malware would then be able to use it as well if simple packet rules were used. A stateful firewall would be required which would authenticate each connection.

This would either require a cookie, as you have mentioned, or would require users to authenticate each time they opened an SSL connection, a headache which I would rather not deal with. And yes, sooner or later, this malicious code would find a way to read that cookie.

I don't think that relying on the ignorance of spyware authors would be a good idea. It would serve as a temporary and mildly secure solution at best. Relying on the willingness of users to put up with, what would seem to them, a machevellian security policy wouldn't be so smart either.

Personally, I like the idea of third party software doing the job of authenticating each application to a firewall better. Specific information on which application is generating network traffic could be obtained. This would not only eliminate this type of malware, but would allow for much more control over network access as well. Unfortunately, it also relies on the assumption that users and/or malware will not break that code or find a way around it.

Hrm...

No easy solution yet.

Post C&C ip addy, then we all scan the crap out of them.............What you recon :)