full-disclosure - RPC DCOM footprints

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <02ec01c35ea7$bb1327d0$0100a8c0@newmarkr>
From: harqman at btopenworld.com (harq deman)
Subject: RPC DCOM footprints

Michael De La Cruz,

There are two categories of DCom exploit in the wild that I know of, that do
not crash the SVCHOST thread.

One of them exits cleanly, returning to the SVCHOST thread without crashing
it.  http://www.k-otik.net/exploits/08.07.oc192-dcom.c.php

The other category binds a cmd.exe shell to a listening port, but when the
socket is closed (because the `haxer' disconnects), it re-binds the port to
accept another connection.  Because execution never returns to svchost.exe,
it does not crash.

The second category is often found listening on port 57005, as per the
authors original exploit.  If a system is listening on that port, connection
will likely result in a cmd.exe shell as user NT_AUTHORITY/SYSTEM.  Earlier
posts on this forum suggest that it may have been turned into a worm.

I tested this myself over a VMware network, and found a couple of things
interesting:
Firstly, the user that you are logged in as has no authority to shut down
the system using conventional methods such as the shutdown -r command.
Secondly, the use has authority to access the data stored in the SAM section
of the registry.  This is a privilidge not usually granted to system
administrators, although programs such as l0phtcrack utilise DLL injection
to accomplish the same result.

The following was taken from a windows 2000 Professional box, onto which I
had put the shutdown.exe and reg.exe utilities from a windows XP
installation.

<SNIP-1>
C:\>shutdown -r -f -t 0
The operation completed successfully.
A required privilege is not held by the client.

C:\>reg query HKLM\SAM\SAM

! REG.EXE VERSION 3.0

HKEY_LOCAL_MACHINE\SAM\SAM
    C   REG_BINARY      0600CENSORED0000020001000100CENSORED000074000000
1CENSORED000000002001C000100000002CENSORED0100000000000100000000CENSORED
020000000000CENSORED0200010100000000000100000CENSORED800CENSORED010200000000
0005
2000000CENSORED00102000000000005200000CENSORED0001020000000CENSORED000002002
0000

HKEY_LOCAL_MACHINE\SAM\SAM\Domains

HKEY_LOCAL_MACHINE\SAM\SAM\RXACT

C:\>
</SNIP-1>

The following commands will, however, allow you to reboot a system via the
command shell, closing the gaping security hole.

<SNIP-2>
@ECHO OFF & cd/d %temp% & echo [version] > rebloot.inf
(set inf=InstallHinfSection DefaultInstall)
echo signature=$chicago$ >> rebloot.inf
echo [defaultinstall] >> rebloot.inf
rundll32 setupapi,%inf% 1 %temp%\rebloot.inf
</SNIP-2>

I realise that this is nothing new

peace
harq

----- Original Message ----- 
From: "Michael De La Cruz" <delacruzma@....com>
To: <full-disclosure@...ts.netsys.com>
Sent: Friday, August 08, 2003 7:31 PM
Subject: [Full-Disclosure] RPC DCOM footprints

> Hello all,
>
>      Just in case some other security professionals are looking at
> identifying if their boxes have been exploited, I've typed up some
> occurences after a successful DCOM exploit.
>
>      - Windows XP SP 0 (haven't tried it on SP 1 yet)
>        Generates a System Shutdown message after a disconnect.  The
message
> indicates that Windows must now restart because the RPC service terminated
> unexpectedly.
>
>      - Windows 2000 Professional all SP's
>        A Service Control Manager error is reported on the Application Logs
> with a message ID of 7031 indicating that RPC terminated unexpectedly.
The
> W2K boxes I've tested this on didn't allow me to view the event logs after
> exploitation.  A few mmc.exe error messages also appeared.  A quick reboot
> appeared alleviate the event log viewing issue.
>
> *Note* This is using the final universal DCOM exploit that was found on
> http://cyruxnet.com.ar/rpcxploit2.htm.  I've heard there is an exploit
that
> does not crash the port though, so an error may not be generated with that
> exploit.
>
>      I'll try to include any new effect I manage to gather from my tests.
> Did anyone else experience these types of behaviors?  Thanks.
>
> Michael De La Cruz
> Information Security Officer
> delacruzma@....com