From: dcopley at eeye.com (Drew Copley)
Subject: Re: Administrivia: Testing Emergency Virus Filter..


> -----Original Message-----
> From: Thor Larholm [mailto:lists.netsys.com@...ript.dk] 
> Sent: Thursday, August 21, 2003 1:32 AM
> To: Drew Copley; full-disclosure@...ts.netsys.com
> Subject: Re: [Full-Disclosure] Re: Administrivia: Testing 
> Emergency Virus Filter..
> 
> 
> > From: "Drew Copley" <dcopley@...e.com>
> > Actually, quite a few don't, some still rely on piggy 
> backing Outlook. 
> > But, yes, this trend should be dissapearing as people 
> upgrade so their 
> > Outlook client will no longer be able to be remote controlled by 
> > another application. (Current versions not only block 
> attachments but 
> > also the ability for applications to access the api framework, 
> > itself).
> 
> Specific parts of the API for Outlook is blocked completely 
> (unless the enduser manually approves otherwise), which has 
> also had an effect on existing mainstream applications such 
> as tighly integrated antispam products (I had problems using 
> my favorite, www.spamfighter.com). Precisely because of this, 
> several solutions were devised almost immediately to 
> circumvent these restrictions by proxying through thirdparty 
> COM objects such as Redemption ( 
> http://www.dimastr.com/redemption/ ) so one > could still reach 
> the entire Outlook object model.

Actually, I have used redemption in developing Outlook testing tools, et
al. I found it to be crappy and restrictive.

I do not think that would be a good solution for virii writers whom
should write in assembly, anyway.

> 
> "Outlook Redemption works around limitations imposed by the 
> Outlook Security Patch and Service Pack 2 of MS Office 2000 
> and Office XP (which includes Security Patch) plus provides a 
> number of functions to work with properties and functionality 
> not exposed through the Outlook object model."
> 
> I like Redemption, not as much for its ability to circumvent 
> the complete API block but for its utility functions which 
> come quite handy when developing Outlook extensions :)

I don't know, maybe I should work with it some more sometime. I forget
all of my issues with it.

> 
> > Even if email clients do start encrypting this information, it will 
> > still be easy to bypass because it is local. There is 
> always a crack 
> > for local work. But, such a thing may deter some virus writers.
> 
> 99% of virus writers would have problems understanding the 
> concept of Redemption. I'm still amazed at how many virii 
> rely on enduser interaction when they clearly need not to.

Yes, but it is the 1% that don't have any issue with this at all. Groups
like 29a have written papers and code which surpasses much of that you
can find on internal Windows wizardry. Seriously, when you get down deep
into the internals of the NT kernal, the number of sites out there
actually offering information begines to dwindle to a handful. (Let's
see, 29a, sysinternals, some NT books, some posts and articles about
this NT books, rootkit.com). 

The problem here is that 29a has also written some of the most prolific
viruses ever. Sure, it is opensource. It also probably infected your
network.

Whoever wrote this latest sobig virus made it multi-threaded.
Multi-threading is not the most technical task a developer can do, but
it can sure be a complex difficulty. 

Regardless, the difficulty about adding dlls to a virus is not just the
size, but the signature it would provide. You would then not only have
to worry about your own binary altering itself to evade detection, but
also someone else's.

All this for what? You can find the pst files - the raw outlook files -
and grep everything from them. Why use outlook at all? For sending mail?
That just connects to your webserver and uses complete plain text to
send, then disconnects.

 

> 
> 
> 
> Regards
> Thor Larholm
> PivX Solutions, LLC - Senior Security Researcher
> 
> 

Powered by blists - more mailing lists