Ms Terminal Services 0 Dayz Exploit?

Full Version: Ms Terminal Services 0 Dayz Exploit?

GovernmentSecurity.org > System Security > Windows Systems

BoNzO

Jul 17 2005, 06:35 AM

QUOTE

News of a 0 day exploit against Windows Remote Desktop this morning has been light on details. A remote DOS is possible and has been discussed on the daily dave mailing list. Remote Desktop is not enabled by default on Windows XP SP2 systems however the terminal services service is running in support of Remote Assistance and Fast user switching. The server does not start a listener on port 3389 until a remote assistance request is sent. However if you enable Remote Desktop your system may be vulnerable.
I doubt that this is the last we are going to here of this.

QUOTE

Port 3389

Yesterday, we mentioned about port 3389 on Windows 0 day exploit. Our reader, Joe, has detected some scans on this port. Looking at port 3389 graph, there is also a spike in the last few days. If you also have experienced the same scan, please let us know.

http://isc.sans.org/port_details.php?port=3389

from SANS

DarkieD

Jul 17 2005, 08:13 AM

not the 1st time the scans get up , but i doubt there is a 0day for term serv

toe

Jul 17 2005, 08:24 AM

forget the links now but basically ms says they wont be able to execute commands, just dos. So far i have seen know news to be able to disagree with ms.

-toe

pita

Jul 17 2005, 08:44 AM

all this is because a discussion on the dailydave mailing list
about this:
http://www.security-protocols.com/upcoming/xp-sp2-remote.jpg

QUOTE

>Dave Aitel wrote:
>pageexec@freemail.hu wrote:
>On 14 Jul 2005 at 11:19, Dave Aitel wrote:
>
>
>
>>http://www.security-protocols.com/upcoming/xp-sp2-remote.jpg
>>
>>
>
>rdpwd.sys from XPSP2? ;-)
>
>
>
>Ah, that'd make sense. RDP would pass through the firewall since it
>would need to be used for the remote helper service. Having SPIKE GPL
>has a side benefit that Microsoft can't, by their own policy, use it for
>their own applications. Because SPIKE has a slightly different coverage
>profile than their own fuzzers, it does occasionally still pop out good
>stuff. :>

pageexec@freemail.hu wrote:

>i think this is the driver in question indeed. the bug is at
>a 'mov cl,[eax+1]' where eax apparently pointed to an invalid
>address. given that this is inside a 4kB long function (the
>calltree is:
> ShareClass::CompressV2Int24
> ShareClass::CompressV2Int32
> ShareClass::BC_Compress
> ShareClass::BC_CompressBitmap
> ShareClass::SDGSendSDARectWorker
> ShareClass::SDGSendSDARect
> ShareClass::SDG_SendScreenDataArea
> ShareClass::UP_SendUpdates
> ShareClass::DCS_TimeToDoStuff
> _WD_Ioctl),
>i can imagine there's more than a mere DoS in this. in any
>case, next patch tuesday will probably come sooner than
>they expected it ;-).
>

myth

Jul 17 2005, 08:44 AM

http://security-protocols.com/modules.php?...rticle&sid=2783

Thats the article that triggered off the scans - people will start scanning now - when the PoC is released, the hackers already know which computers to hit...

DarkRider

Jul 17 2005, 01:16 PM

QUOTE(myth @ Jul 17 2005, 08:44 AM)

It's just a DoS

http://www.microsoft.com/technet/security/...ory/904797.mspx

tibbar

Jul 17 2005, 07:47 PM

it's a BOF in a kernel mode driver. MS say its only DOS because the number of people who are capable of writing kernel mode shellcodes is currently very limited. In truth it is a serious vunerability which can lead to remote execution of code.

It is possible though and i think we will soon be seeing the first kernel shellcodes emerge.

eeye did a paper on this a while ago and demonstrated a POC on kernel shellcodes for a firewall with a BOF in it .sys driver.

for anyone interested, it is attached.

DiabloPatch

Jul 17 2005, 07:56 PM

OMFG never thought it was possible and heard about kernel mode exploitation before. but as tibbar said I only saw pocs of it and not really "real-world" examples on daily base.

but hell this seems like the next BOF upgrade since most applications today are getting more and more protected against normal BOF

BuzzDee

Jul 18 2005, 03:17 AM

hey thx tibbar for the link. the best paper i read in the last few weeks

really interesting heh

Killaloop

Jul 18 2005, 03:35 AM

this would be a nice target for exploit writers to get more knowledge about kernel exploits.
maybe we will see one, but until then all machines should be patched.
well the scan activity is nothing unusual.
as others said fxp kids are already scanning for targets.
for a learning point of view it would be really nice to see a working exploit.
for skiddies it will mostly be useless since making it generic is almost inpossible (with currently less knowledge about this topic).

easternerd

Jul 19 2005, 01:40 AM

Hmm TsGrind was in itself a big Vulnerability for Terminal Services in Windows, now an exploit release will make it worse case scenario like the radmin exploit a couple of years back.

Digian

Jul 19 2005, 02:24 AM

Except that RDP is a thousand fold more used than radmin

brOmstar

Jul 19 2005, 09:10 PM

back on gsO

Very interesting paper @tibbar. I also think that this vuln could be exploitable after i have read this paper. Can someone provide the Memory.Dmp of the rdp blue screen here???

aelphaeis_mangarae

Jul 19 2005, 09:23 PM

I had a really strong feeling this might allow code execution, with alot of things if the person that releases the information on the exploit is purely ethical they try and hide the fact that code execution is possible, in this case it would be obvious that eEye would indeed try and hide what they have discovered.

Sooner or later a PoC should arise...someone will figure this all out...I wish i knew this stuff..seems pretty advanced, but I am going to read that pdf tibbar posted later.

click

Jul 20 2005, 10:31 PM

Not too much development with kernel-mode exploits in this topic? Well, i have been doing some research on making kernel-mode rootkits and shellcode. So far, i have gotten a few more good resources:

hxxp://www.ntkernel.com/wprod.php?ids=3
- Good site for NTKernel breakdown. Contains mostly net functions on a kernel level, but that is partially what we need for this exploit.

hxxp://www.rootkit.com/newsread.php?newsid=327
- Yet again, Greg & Jamie @ rootkit.com have come through with even more usefull knowledge. This time, it is "Rootkits: Subverting the Windows Kernel." I highly recommend this book, it is a pretty good read.

hxxp://www.xfocus.net/projects/Xcon/2004/Xcon2004_sk.pdf
- "Windows Local Kernel Exploitation" is an old powerpoint presentation (from 2004 HITB security conference) but still contains a lot of useful points and links. Obviously this would be much more useful with an accompanying speaker!

hxxp://www.xfocus.net/articles/200306/545.html
- here is some kernel shellcoding in a working exploit (for MS03-013) coded by Eyas. if anyone can translate, that would be nice!

But lets see what we can do with this -- i am sure we can whip up something here

tibbar

Jul 20 2005, 11:16 PM

i could probably write a kernel shellcode if i had a spare week...

it's very time consuming as you have to rescue the BOF'ed driver from crashing, otherwise you get a BSOD.

you need to do the whole thing on vmware or 2nd machine debugging over a cable / virtual com port.

you must use APC method to create a usermode redirection of cmd.exe over a socket...

myth

Jul 21 2005, 03:38 AM

Im sorry for not 'googling first' and whatnot - but has Microsoft released a patch for this yet ? or has anybody have any idea when the PATCH will be released ?

Please dont tell me the patch will be released the second tuesday in august - the same day as the PoC...

poerkel

Jul 21 2005, 09:26 AM

QUOTE(myth @ Jul 21 2005, 03:38 AM)

afaik there is no patch and m$ is not planning on releasing one.

QUOTE

Microsoft and other security experts have recommended that in order to mitigate this vulnerability, users should disable RDP and ensure that TCP Port 3389 is blocked at the firewall level.

(eeye)

fulvioo

Jul 21 2005, 11:22 AM

QUOTE(poerkel @ Jul 21 2005, 09:26 AM)

QUOTE(myth @ Jul 21 2005, 03:38 AM)

afaik there is no patch and m$ is not planning on releasing one.

QUOTE

Microsoft and other security experts have recommended that in order to mitigate this vulnerability, users should disable RDP and ensure that TCP Port 3389 is blocked at the firewall level.

(eeye)

Of course not. poerkel, this is usually what they say (close the service) untill the patch is released. And yeah, it seems we will see the patch only on august. But I'd say it will be released before that

DevNull

Jul 26 2005, 11:03 PM

Good morning all.

I took a quick glance at tibbar's pdf, seems a very nice read, well laid out. I'll have fun reading that later after classes. Since I'm fairly new to this type of forum, I had to look up BOF ("beginning of file" for anyone picking this thread up). I actually picked up this forum while doing research for a paper on port security and vulnerability assessments. there is very little information on this port for some reason, lots of MS saying to keep it closed, and patch coming and stuff, but no real knowledge save for the pic/pdf posted on this forum (so far at least in my research).

Either way, I have a keen interest in how exploits work, particularly what the code looks like in transit. I like finding dump files/log files of this traffic so I can be aware of what is going on, and tuning my NIDS/HIDS to find this traffic. Can anyone here recommend a packet shaper ... or do I need to write one myself (my C/++/# skills are a bit rusty and out of practice as I've been dealing with hex and sniffers for the last year or so).

Hope to be a productive resource in this forum.

--DevNull

G777

Jul 27 2005, 02:33 AM

BOF is actually buffer overflow m8

DevNull

Jul 29 2005, 02:19 AM

QUOTE(G777 @ Jul 26 2005, 06:33 PM)

BOF is actually buffer overflow m8

Ah, that does make a bit more sense, but I figured the same thing with Beginning of File, because you overflow the area in memory set aside for the buffer, and therefore start writing over the Beginning of File of the next system file stored in sequence with the buffer allocation.

Either way it makes sense, its more important HOW it makes sense (to me at least).

Thank you for your clarification though.

--DevNull

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.