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 +0×100] 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.

I know, there ain’t no such thing!

Well, we could have a lively debate on that topic, but not right now.

On this occasion, I’m just letting anyone who wonders what happened to the Mac Virus web site (http://www.macvirus.com), which I inherited from Susan Lesch some years ago, what’s happening with it. We have nothing to do with the cobwebby sites at http://www.macvirus.net and http://www.macvirus.org, or with http://macvirus.wordpress.com, whatever that is.

The http://www.macvirus.com URL actually redirects to my own Mac page at Small Blue-Green World site, which now re-redirects to a Wordpress page. If you want to go straight to the Mac Virus blog, you can go direct here. It’s still malware-oriented, of course, and, is likely to become more rather than less active in that area.

In fact, most of my Small Blue-Green World content now resides on blog pages. ESET content is still blogged at http://www.eset.com/threat-center/blog/, of course, and AVIEN content is blogged at http://avien.net/blog/.

Confused? Me too…

We now return you to your normal programming. Scheduling, that is, not coding. Unless that’s what you’re doing at the moment. Oh, never mind.

The next time I blog here, it will be about a proper security issue again. I hope.

David Harley FBCS CITP CISSP
Security Author/Consultant at Small Blue-Green World
Chief Operations Officer, AVIEN
ESET Research Fellow & Director of Malware Intelligence

Also blogging at:
http://avien.net/blog
http://www.eset.com/threat-center/blog
http://smallbluegreenblog.wordpress.com/
http://macviruscom.wordpress.com
http://blog.isc2.org/
http://dharley.wordpress.com

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 …

Popular brazilian websites under attack. Again.

This time the target was Vivo (http://www.vivo.com.br) and the attack was reported by Miguel Di Ciurcio Filho, a security researcher from Institute of Computing, Campinas State University - Unicamp (site, personal).

In short:

• \WINDOWS\system32\drivers\etc\hosts changed to redirect traffic to popular brazilian banks:

  69.162.114.180 santander.com.br
  69.162.114.180 www.santander.com.br
  69.162.114.181 itau.com.br
  69.162.114.181 www.itau.com.br
  69.162.114.181 www.itau.com
  69.162.114.181 itau.com
  69.162.114.181 itaupersonnalite.com.br
  69.162.114.181 www.itaupersonnalite.com.br
  69.162.114.182 www.bradesco.com.br
  69.162.114.182 bradesco.com.br
  69.162.114.182 www.bradesco.com
  69.162.114.182 bradesco.com
  69.162.114.182 www.bradescoempresa.com.br
  69.162.114.182 bradescoempresa.com.br
  69.162.114.182 www.bradescoprime.com.br
  69.162.114.182 bradescoprime.com.br
  69.162.114.182 bradescocartoes.com.br
  69.162.114.182 www.bradescocartoes.com.br
  69.162.114.179 www.nossacaixa.com.br
  69.162.114.179 nossacaixa.com.br

• Java applet (.JAR) disguised as JPEG file (MD5: 3d4756a74d76d7b3004604c6b30e23f5)
• Access to server files (/etc/hosts, /etc/passwd) via specially crafted URLs. Part of the problem.
• Virustotal analysis: logo_top.jpg, laa.class
  

Simple but effective attack. According to a script in another vulnerable website used in this attack thousands of users were infected.

As the Wordpress team scramble around trying to resolve the latest set of security issues, and doing all the wrong things like giving their users a 14-step process for upgrade, the following Jewel came up:

4. WordPress is Not Secure: WordPress is incredibly secure and monitored constantly by experts in web security. This attack was well anticipated and so far, WordPress 2.8.4 is holding. If necessary, WordPress will immediately release a update with further security improvements. WordPress is used by governments, huge corporations, and me, around the world. Millions of bloggers are using WordPress.com. Have faith they are working overtime to monitor this situation and protect your blog.

This is funny on so many levels.
(HT: Jericho, AKA security curmudgeon)

The swine flu craze in Asia is almost becoming ridiculous. Flying into Beijing a doctor came on board to check everyone’s temperature before they would let us out of the plane. Before passing immigration we were checked again and filled in forms to prove we are all in top health.

Ironically, on the inbound flight to Beijing I caught the flu from the Chinese girl sitting next to me (I’m talking about the regular flu. No need to call an emergency medical team on me). I spent the week gobbling Chinese medicine herbs which did a great job in preventing me from crashing sick. But the problem is that I am about to fly out back to San Francisco through Tokyo, and I’m trying to think how to convince the Narita officials that my germs are pure and genuine Asian bodies and are were not carried with me from any American pigs (political innuendos not intended).

It seems I’m also a carrier of something else, and again it’s not my fault. All I did was connect my USB stick to a computer on the business center in my Beijing hotel. I just wanted to print a document but didn’t bother locking the stick to ‘read only’. Apparently that was enough to have a Trojan infect the USB stick from the malware infested public computer.

Not that it would matter, really, since my machine runs Ubuntu. In fact, I wouldn’t have noticed it unless someone that borrowed the USB stick from me showed me the Virus warning that popped up as they plugged the stick into their Windows machine. I could have infected dozens of machines by the time I found out about it – all those poor Windows machine, Trojaned just for borrowing my USB stick; I really don’t need that on my conscience.

Once I know the Trojan is there, the cleanup is easy, I will ‘rm’ the files and the stick will be healthy again and stop be a carrier for defenseless Windows machines. Now if only it was that easy to recover from this damn flu.

Dinosaur that I am, it never occurred to me that long URLs were a major problem.  Sure, I’d gotten lots that were broken, particularly after going through Web-based mailing lists.  But you could generally put them back together again with a few mouse clicks.  So what?

So the fact that there were actually sites that would allow you to proactively pre-empt the problem, by shortening the URL, came as a surprise.  What was even more of a surprise was that there were lots of them.  Go ahead.  Do a search on “+shorten +url” and see what you get.  Thousands.  http://bit.ly/ http://tubeurl.com/ http://www.shortenurl.com/index.php http://urlzoom.org/ http://ayuurl.com/ http://urlsnip.com/ http://url.co.uk/ http://metamark.net/ http://8ez.com/ http://notlong.com/ http://shorten.ws/ http://myurl.si/ http://dwindle.me/ http://nuurl.us/ http://myurlpro.com/ http://2url.org/ http://tiny.cc/

I would not, by the way, advise visiting that last.  .cc is a domain used by those on the dark side.  In fact, I wouldn’t recommend visiting many of those: I have no idea where they came from, except that a search pops them up.  Which is part of the point.

Are URL shorteners a good thing?  Joshua Schachter says no.  Therefore, in opposition, Ben Parr says yes.  There are legitimate points to be made on both sides.  They add complexity to the process.  (Shorteners aren’t shorteners: they are redirectors.)  They make it easier to tweet (and marginally easier to email).  They disguise spam.  Some of the sites give you link use data.  They create another failure point.  They hide the fact that most Twitter users are, in fact, posting exactly the same link as 49,000 other Twitter users.

URL shorteners/redirectors are going to be used: that is a given.  Now that they here, they are not going away.  Those of pure heart and altruistic (or, at least, monetary only) motive will provide the services, have reasonable respect for privacy, and add functions such as those providing link use data to the originator (and, possibly, user).  A number of the sites will be set up to install malware on the originator’s machine, to preferentially try to break the Websites identified, to mine and cross-corelate URL and use data, and to redirect users to malicious sites.

If you are going to use them (and you are, I can tell), then choose wisely, grasshopper.  There are lots to choose from.  Choose sites that offer preview capabilities.  If someone doesn’t use the preview options, you can still add them.  http://tinyurl.com/a-short-url-that-expands is the same as http://preview.tinyurl.com/a-short-url-that-expands : you just have to add the “preview.” part.  http://is.gd/ is even easier: just add a hyphen to the end of the shortened URL.  I’m hoping that one of the sites will start checking the database for already existing links, and returning the same “short form”: it’d make it easier to identify all the identical tweets.  (With the increasing use of the sites, it will also ensure that the hash space doesn’t expand too quickly, which would be to the advantage of the shortening sites.)

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

I’m sitting in CanSecWest.  We’ve just had a talk on platform-independent static binary code analysis.  (It isn’t really platform independent: just translating from specific instruction sets.  Not that it isn’t cool: REIL is a sort of RISC version of an assembly version of pseudocode.)  The presentation, and what they’ve done so far, is fairly abstract.  They are approaching the analysis with a type of Turing machine, and, with a sort of lattice-based state machine model, hoping that the transforms they can see with their model, are close enough to what the actual program will do in an actual machine in order to tell you if there is teh possibility of a bug or an exploit.

So, it’s kind of complex.  We are applying some highly abstract, theoretical stuff, pretty directly to the real world.

Now, in the abstract world, it’s been more than 25 years since Fred Cohen proved that this type of thing will never completely work.  Either you are going to get an infinite number of false positives (false alarms, where you spend time chasing down problems that aren’t problems), or an infinite number of false negatives (which is our current situation with security: our tools aren’t telling us about the problems that do exist), or both.

(One of the authors responded to this point that he chose to err on the side of false positives.  A reasonable position if you are doing research.)

However, this system is so complex that it got me thinking: they are hoping that the model and transforms they have put together is close enough to reality that it will give them useful results and help, but they really don’t know.  What if we are now to the point where our security tools and models, themselves, have gaps that can hide problems, and be exploited?

(There was a reason the original security models were so simple …)

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.

Online payment system infected with malware? not good.

You are receiving this message because you are a subscriber to online bill payment services through CheckFree or through a provider who contracts with CheckFree for these services. This message is sent on behalf of CheckFree by Silverpop Systems.

December 11, 2008
AVIRAM JENIK

[address omitted]

Dear AVIRAM JENIK,
We take great care to keep your personal information secure. As part of these ongoing efforts, we are notifying you that the computer you use for online bill payment may have been exposed to software that puts the security of your computer’s contents at risk. This letter will help you determine if your computer is actually infected and advise you how to fix the problem and protect yourself against future risk.

The malicious software affects some but not all customers who accessed online bill payment on Tuesday, December 2, 2008. For a limited period of time, some customers were redirected from the authentic bill payment service to another site that may have installed malicious software. Your computer may be infected if all of the following are true:

• You attempted to access online bill payment between 12:30 a.m. and 10:10 a.m. Eastern time (GMT -5) on Tuesday, December 2, 2008, and
• You were using a computer with the Windows operating system, and
• You reached a blank screen rather than the usual bill payment screen when you attempted to navigate to online bill payment, and
• After reaching the blank screen, your computer’s virus protection program did not tell you via pop-up or other messaging that malicious software was detected and quarantined.

If all four of the conditions above are true, your computer may be infected. [marketing blurb about an AV vendor that was quick enough to cash in]

CheckFree will never ask for your password via email or via phone.  If you ever receive an email requesting your password, do not respond and delete the email immediately.

We value your business and your trust, and we apologize for any inconvenience this incident has caused.
Thank you,

Art D’Angelo
Vice President, CheckFree Customer Operations

I guess we’ll call this the CheckFree botnet?

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