headers
Vic Brown | 2 Feb 2007 20:25
Picon

Help with Exploit

Hello List,

We're experiencing a serious problem on our networking with an exploit. 
  After running the Microsoft rootkit detector we found the following:

Key name contains embedded nulls (*),8/13/2001 12:06,0
bytes,HKLM\SECURITY\Policy\Secrets\SAC*
Key name contains embedded nulls (*),8/13/2001 12:06,0
bytes,HKLM\SECURITY\Policy\Secrets\SAI*
Key name contains embedded nulls (*),3/24/2005 11:56,0
bytes,HKLM\SECURITY\Policy\Secrets\XATM:148d93c5-f0a9-4110-8d38-f44f341e286d*
Hidden from Windows API.,1/31/2007 15:25,13.00
KB,C:\WINNT\system32\pfplgflt.dll
Hidden from Windows API.,1/31/2007 16:32,7.50
KB,C:\WINNT\system32\pfplgnfo.dll
Hidden from Windows API.,1/31/2007 16:32,9.50
KB,C:\WINNT\system32\pfplgprx.dll
Hidden from Windows API.,1/31/2007 16:32,12.50
KB,C:\WINNT\system32\pfplgscn.dll

Did some research on the pfplgflt.dll files and found this:
http://vil.nai.com/vil/content/v_122073.htm

All of the files and registry settings listed on the McAfee site were 
found on the system, and also a strange a.exe file.  Found some general 
info about the a.exe file, but all of it was useless and did not relate 
at all to this exploit IMHO.  I guess it uses a.exe just because.  The 
boxes had the latest AV updates and engines, and also the latest OS 
updates (Windows 2000).  Even worst, after reinstalling one of the 
boxes, and updating to the latest everything once more, the box was
(Continue reading)

Permalink | Reply | 10 comments |
headers
Josh Miller | 2 Feb 2007 22:18

Re: Help with Exploit

There are a couple of methods you could employ to determine whether or 
not this is a problem:

1. Monitor the network using tcpdump, ethereal or other monitoring tool 
and shut down all non-necessary services on this host.  If you see 
suspicious traffic, this might indicate who or where it is going to so 
you can validate it and/or the contents.

2. Use the sysinternals tools from Microsoft to discover who is doing 
what on your server:
   download from: 
http://www.microsoft.com/technet/sysinternals/default.mspx

One problem here is that if it's malicious code at work you're defending 
hosts when you should be defending your network(s).  Find out where the 
problem is coming from and shut it down at the firewall.

Thanks,
Josh Miller

Vic Brown wrote:
> Hello List,
> 
> We're experiencing a serious problem on our networking with an exploit. 
>  After running the Microsoft rootkit detector we found the following:
> 
> Key name contains embedded nulls (*),8/13/2001 12:06,0
> bytes,HKLM\SECURITY\Policy\Secrets\SAC*
> Key name contains embedded nulls (*),8/13/2001 12:06,0
> bytes,HKLM\SECURITY\Policy\Secrets\SAI*
(Continue reading)

Permalink | Reply | 0 comments |
headers
David LeBlanc | 4 Feb 2007 22:24
Picon

RE: Share and NTFS permissions

I know this is about 3 weeks old, but I just now stumbled on it - 

This isn't correct - first of all, there's always implicit WRITE_DAC for the
owner of the object. Owner of something can always change permissions on it.
Before any ACEs are checked, if WRITE_DAC is requested, and you're the
owner, you get that bit allowed.

Second thing the user could do, if they were determined and could write
code, is that the ACL on something can be supplied atomically at creation
time - it's one of the parameters to CreateFile. This is really one of the
nicer things about the Windows API because you don't have to worry about
race conditions between creating something and locking it down, and if
you're using restricted tokens - say with Vista services - you'll need to
supply an ACL for some things.

There are ways to work around some of this, depending on conditions -

1) If the files are located on a share, you can not give the people with
access to the share permissions to change permissions on anything in the
share. Share permissions are in general confusing and annoying, but this is
one case you can use share and file permissions together. This won't stop
creating the file with an ACL supplied, but it stops other forms of user
mischief.

2) If you want to go to this much trouble, create a service that looks for
changes in that directory, and when it finds them, it takes ownership of
anything showing up there, and sets an ACL the admin finds appropriate. The
user's no longer owner. You'll also lose any information about who created
something, unless you log it somehow. Note that this doesn't absolutely work
until all the outstanding handles with WRITE_DAC access are closed, but it's
(Continue reading)

Permalink | Reply | 0 comments |
headers
Murda Mcloud | 5 Feb 2007 05:30
Favicon

RE: Help with Exploit

Hi Vic.
I found that you can actually see the Security hive under HKLM if you run
regedit interactively:
One way of doing this is: run the command at in a cmd prompt like this:
at 9:23am /interactive regedit.exe

Change the time here to suit-that is a few minutes into the future.
When regedit opens up then you can simply check the hive but some keys are
'secret' and I don't know how to access them...yet.
I actually received a very similar flag from RR when running it on a
friend's machine and I'm wondering if the first two lines are normal.

-----Original Message-----
From: Murda Mcloud [mailto:murdamcloud <at> bigpond.com] 
Sent: Monday, February 05, 2007 8:52 AM
To: 'Vic Brown'; 'focus-ms <at> securityfocus.com'
Subject: RE: Help with Exploit

Hi Vic-are the timestamps/datestamps here significant to you?

>> Key name contains embedded nulls (*),8/13/2001 12:06,0
bytes,HKLM\SECURITY\Policy\Secrets\SAC*
Key name contains embedded nulls (*),8/13/2001 12:06,0
bytes,HKLM\SECURITY\Policy\Secrets\SAI*

I've done some googling and am finding that the new RR version  checks the
security hive(which I believe to be 'invisible' to regedit-can someone
correct me if I'm wrong?).

These two keys maybe some password store perhaps and are the timestamps
(Continue reading)

Permalink | Reply | 0 comments |
headers
Murda Mcloud | 4 Feb 2007 23:52
Favicon

RE: Help with Exploit

Hi Vic-are the timestamps/datestamps here significant to you?

>> Key name contains embedded nulls (*),8/13/2001 12:06,0
bytes,HKLM\SECURITY\Policy\Secrets\SAC*
Key name contains embedded nulls (*),8/13/2001 12:06,0
bytes,HKLM\SECURITY\Policy\Secrets\SAI*

I've done some googling and am finding that the new RR version  checks the
security hive(which I believe to be 'invisible' to regedit-can someone
correct me if I'm wrong?).

These two keys maybe some password store perhaps and are the timestamps
indicative of some s/w install date? Or even the OS? 
You might find it useful to post on the Sysinternals forums too
http://forum.sysinternals.com/

-----Original Message-----
From: listbounce <at> securityfocus.com [mailto:listbounce <at> securityfocus.com] On
Behalf Of Vic Brown
Sent: Saturday, February 03, 2007 5:25 AM
To: focus-ms <at> securityfocus.com
Subject: Help with Exploit

Hello List,

We're experiencing a serious problem on our networking with an exploit. 
  After running the Microsoft rootkit detector we found the following:

Key name contains embedded nulls (*),8/13/2001 12:06,0
bytes,HKLM\SECURITY\Policy\Secrets\SAC*
(Continue reading)

Permalink | Reply | 7 comments |
headers
De Rienzo, James | 5 Feb 2007 16:33

RE: Share and NTFS permissions

Change the file's Ownership to Administrator, and be done with it. 

Simple yet effective.

-----Original Message-----
From: listbounce <at> securityfocus.com [mailto:listbounce <at> securityfocus.com]
On Behalf Of David LeBlanc
Sent: Sunday, February 04, 2007 4:25 PM
To: 'M. Burnett'; 'Jim Harrison'; Monrad.DC <at> Forces.gc.ca;
focus-ms <at> securityfocus.com
Subject: RE: Share and NTFS permissions

I know this is about 3 weeks old, but I just now stumbled on it - 

This isn't correct - first of all, there's always implicit WRITE_DAC for
the owner of the object. Owner of something can always change
permissions on it.
Before any ACEs are checked, if WRITE_DAC is requested, and you're the
owner, you get that bit allowed.

Second thing the user could do, if they were determined and could write
code, is that the ACL on something can be supplied atomically at
creation time - it's one of the parameters to CreateFile. This is really
one of the nicer things about the Windows API because you don't have to
worry about race conditions between creating something and locking it
down, and if you're using restricted tokens - say with Vista services -
you'll need to supply an ACL for some things.

There are ways to work around some of this, depending on conditions -
(Continue reading)

Permalink | Reply | 501 comments |
headers
David LeBlanc | 5 Feb 2007 18:31
Picon

RE: Share and NTFS permissions


> -----Original Message-----
> From: De Rienzo, James [mailto:James.DeRienzo <at> hq.doe.gov] 
> Sent: Monday, February 05, 2007 7:34 AM
> To: David LeBlanc; M. Burnett; Jim Harrison; 
> Monrad.DC <at> Forces.gc.ca; focus-ms <at> securityfocus.com
> Subject: RE: Share and NTFS permissions
> 
> Change the file's Ownership to Administrator, and be done with it. 
> 
> Simple yet effective.

And have the likely side-effect of removing access from the original owner.
I'd suggest taking a more thorough approach. This is why I originally wrote:

"it takes ownership of anything showing up there, ****and sets an ACL the
admin finds appropriate****"
Permalink | Reply | 503 comments |
headers
M. Burnett | 5 Feb 2007 18:58

RE: Share and NTFS permissions

One way you can set custom permissions on new files is to use the file
screens feature in Win2003 R2. You could create a file screen for all new
files, have that screen run a script and that script can set permissions and
can be as elaborate as you want. 

Of course, this does introduce a bit of a race condition but that would only
be for the creator/owner. It may not work for every situation. 

I mentioned this technique recently in my blog:
http://xato.net/bl/2007/02/01/using-filescreens-for-server-lockdowns/

Mark Burnett

-----Original Message-----
From: David LeBlanc [mailto:dleblanc <at> mindspring.com] 
Sent: Monday, February 05, 2007 10:31 AM
To: 'De Rienzo, James'; 'M. Burnett'; 'Jim Harrison';
Monrad.DC <at> Forces.gc.ca; focus-ms <at> securityfocus.com
Subject: RE: Share and NTFS permissions

> -----Original Message-----
> From: De Rienzo, James [mailto:James.DeRienzo <at> hq.doe.gov] 
> Sent: Monday, February 05, 2007 7:34 AM
> To: David LeBlanc; M. Burnett; Jim Harrison; 
> Monrad.DC <at> Forces.gc.ca; focus-ms <at> securityfocus.com
> Subject: RE: Share and NTFS permissions
> 
> Change the file's Ownership to Administrator, and be done with it. 
> 
> Simple yet effective.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ansgar -59cobalt- Wiechers | 5 Feb 2007 21:50
Favicon

Re: Share and NTFS permissions

On 2007-02-05 David LeBlanc wrote:
> On Monday, February 05, 2007 7:34 AM James De Rienzo wrote:
>> Change the file's Ownership to Administrator, and be done with it. 
>> 
>> Simple yet effective.
> 
> And have the likely side-effect of removing access from the original
> owner. I'd suggest taking a more thorough approach.

Access should (almost) always be granted by group, not by account or
owner. Which makes this a non-issue.

Regards
Ansgar Wiechers
--

-- 
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq
Permalink | Reply | 0 comments |
headers
David LeBlanc | 6 Feb 2007 07:01
Picon

RE: Share and NTFS permissions

Because the effective permissions on a share are the intersection of the
file system permissions and the share permissions. So for example, let's say
that I had permissions on a shared folder that allowed me to add new files,
and gave me read-write-delete on files I created. The file system is going
to implicitly give me permission to change permission on things I own.

If I'm an obnoxious user, I create a new directory, fill it up with say
pirated music files, and then to keep the pesky admins out, I change the
acls to allow me and my friends full control, admins are denied. This
creates a problem for the admins.

Now if the admins only give me change permissions at the share level, I
can't change the permissions after I've created something, which allows me
to accomplish something that can't be done at the scope of the file system.
This will be enough to keep most users from causing this problem. 

> -----Original Message-----
> From: Jeff Flack [mailto:jeff_flack99 <at> yahoo.com] 
> Sent: Monday, February 05, 2007 12:39 PM
> To: De Rienzo, James; David LeBlanc; M. Burnett; Jim 
> Harrison; Monrad.DC <at> Forces.gc.ca; focus-ms <at> securityfocus.com
> Subject: RE: Share and NTFS permissions
> 
> WHy are you even bothering w/ SHARE permissions?
> 
> 
> 
> --On Monday, February 05, 2007 10:33 AM -0500 "De Rienzo, James" 
> <James.DeRienzo <at> hq.doe.gov> wrote:
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane