Steve,

Thanks for the review. I'm glad you enjoyed my paper. I CC'ed vulnwatch
with a TXT version of my paper. If you find the formatting unacceptable
please feel free to format it properly. This was the best I could do on
short notice.

Sincerely,
'ken'

Steve wrote:

> Hey Ken.
>
> Good paper. Could I ask you to please forward this email and a TXT
> version of your paper to VulnWatch at vulnwatchvulnwatch.org.
>
> Thanks.
>
>
>
>
>>-----Original Message-----
>>From: 'ken'FTU [mailto:franklin_tech_bulletinsyahoo.com]
>>Sent: Thursday, November 01, 2001 8:07 PM
>>To: bugtraqsecurityfocus.com; submissionspacketstormsecurity.org
>>Subject: Three Windows XP UPNP DOS attacks
>>
>>
>>Below you will find a quick recap of a few denial of service
>>exploits I discovered against Windows XP and selected
>>versions of WinME. Microsoft confirmed my findings: bulletin
>>MS01-54. The paper is a narrative and the author hopes it
>>will be useful for newbies and an enjoyable paper for the experts.
>>
>>Do not hesitate to contact me at the following email address:
>>franklin_tech_unlimitedyahoo.com . It is also listed in the paper.
>>
>>- 'ken'
>>
>>----------------------------------------------
>>
>>Just a side note: this paper really should be named 'I still
>>haven't found what I'm looking for': I expected a buffer overflow.
>>
>>We are attacking a server named SSDPSRV bound to port 5000
>>running on XP or selected versions of WinME. This is
>>Microsoft's UPNP server that is installed and runs by default
>>on WindowsXP.
>>
>>In two of the three hacks we are interested in a .dll named
>>MSVCRT.dll. This library has a page fault that can be used to
>>crash the application.
>>
>>The first DOS is simply due to bad code. We can send the
>>application a specific header and it will crash the server.
>>There is a page fault at 0197:78004a16 in MSCVRT.dll.
>>
>>The second DOS is due to the way the SSDPSRV handles input.
>>We can chew up memory by opening a connection, sending the
>>proper header, and then just strings and strings of 'A's (or
>>whatever else you like). If one connection is made and such
>>strings are sent we will receive a page fault in MSVCRT.dll
>>again. This time it is at 0197:010083fe. But, if we open
>>approximately 200 connections and send the proper header
>>followed by a string of 'A's we can deplete the system
>>resources. Using a Pentium II 336Mhz machine I tested a
>>Pentium IV 1.4Ghz with 128M of memory and took the system
>>resources from 65% to 48% in 20 minutes. The only problem
>>with this method is that it takes a substantial amount of
>>time to send these strings over the network.
>>
>>The third and final DOS is the cool one. SSDPSRV cannot
>>handle multiple connections well. If one opens up 1018
>>simultaneous connections one can temporarily freeze the
>>machine. The user's keyboard and mouse input are held in the
>>buffer but do not appear to register. With this attack one
>>can sink the system resources under 4% in about a second. In
>>a minute or two the system corrects itself.
>>
>>
>>
>>
>>
>>
>>
>

How I discovered, researched and reported a security vulnerability to Microsoft.
                By 'ken' of FTU
                franklin_tech_unlimitedyahoo.com
Disclaimer
        This paper is for educational purposes only. The author assumes
no responsibility for how this information is used. The purpose of the paper is
not -- and should not be used -- for criminal or illegal activities.
        This paper may be freely distributed on the internet under the
following conditions: first, this paper may not be altered in any form from the
original content; second, the paper must be distributed in whole and cannot
be broken into sections.
        Explicit consent is needed to publish this paper in any form. Please
contact the author at the email address above.

Intro
        This article will discuss the discovery, testing and reporting of a security
vulnerability to a major U.S. vendor. In this case the effected operating systems are
Microsoft's Windows XP (XP) and certain OEM's distribitutions of Windows ME
(WinME) . The vulerable application is Microsoft's new network Universal Plug and
Play server. My format is a story and my story begins at my girlfriend's house this past
June.
        While I researched trojans and OS backdoors from my girlfriend's PC, I realized
her computer accessed the Internet though a cable modem. I recently read that computers
with an "always on" connection are constantly probed for weakness. Since she rarely
powers down her PC, could it be that her computer was compromised? Perhaps someone
installed software that remotely controlled the operating system and she participated in
DDOS attacks without knowing it!

Discovery
        Quickly I opened a DOS prompt and typed 'netstat -an' to display all network
connections and services that ran on her machine. I looked for an anomaly, a rouge
service. Since my girlfriend did not use her PC for development I safely assumed few
ports were open on her machine.
        I was correct. Ports below 1024 were not open except for the typical windows
services such as nbdatagram, nbname, and nbsession. From experience I know the OS
usually makes a few loop back connections right above 1024. So, the connections made
on ports 1025 and 1026 did not bother me. But I noticed there was a TCP service in the
listening state on port 5000. This aroused my suspicion. I telneted to port 5000, hit return
a few times and received an error message: "HTTP/1.1 400 Bad Request." The service on
port 5000 spoke using the HTTP protocols. What was this service? Was the machine
compromised? And if so, who compromised it?
        My blood pressure rose: I needed more information. What program bound itself to
port 5000 and waited for an incoming request? I know of a program that maps ports to
processes for Windows NT and Windows 2000 Advanced Server and Windows 2000
Professional, but not for WinME. Luckily I found a solution. I installed a personal
firewall on her computer and manually connected to port 5000 using telnet. Bingo! The
firewall reported that I requested a connection to a program named SSDPSRV.exe. Using
'Find' I located the binary, right clicked on the executable, selected properties and clicked
on the Version tab. Low and behold the application was writted by Microsoft. To verify
this I surfed over to Microsoft's website. After I searched a bit I verified that the program
was truly written by Microsoft.
        Since more preliminary research was necessary, I stopped at my parent's house
and netstat'ed their new WinME box. They too ran this service. At this point I concluded
that my girlfriend's computer was probably not compromised since my parents ran the
same Microsoft service. Plus, the fact that my parents do not have an "always on"
connection added extra reassurance. A few questions now surfaced: first, what was this
service? How did one communicate with it? Second, what were the odds that this new
server also had vulnerabilities? Third, what was the scope of the problem should a
vulnerability be found? I already discovered two PCs running the service. If this was a
new part of the OS, how many WinME boxes were vulnerable?

Research
        I surfed back to Microsoft's Website for more information. Microsoft provided
few clues to the product. Initially I found a page or two that listed, but did not explain, the
files associated with program SSDPSRVexe. I also learned that SSDPSRV.exe is
Microsoft's Universal Plug and Play technology applied to a network. In the future this
will allow for seemless connectivity of various devices such as a printer or a network CD
burner without the need to install a driver. So I searched more and found only one
technical document relating to UPNP. It was enough! From this document I learned how
to query the server and extract information. In fact the server is designed to give away
information -- such as the devices and services enabled on the machine -- when requested.
My first challenge presented itself: I would simply write a program to communicate with
the server and extract information. Looking forward, I planned to create a suite of utilities
to test the full functionality of the server as defined in the specification. I did not get that
far.
        After I created a simple program to enumerate all the devices on the machine, I
pulled out my 10/100 Ethernet hub, connected my trusty 336Mhz Linux laptop to my
parents 1.4Ghz WinME box and made the necessary configurations. I navigated to my
recently complied program; rapidly typed the parameters and hit enter to send the request.
Crash! I crashed Microsoft's server! It didn't even live up to the specifications they
developed. At this point I realized two things: first, I just discovered a DOS attack.
Second, the application probably had more bugs.
        What is the ultimate bug leading to a compromise? A buffer overflow! Since
WinME is a single user system arbitrary code will run as root! So, that's what I decided to
test next. I pumped the server full of 'A's and thought the application might crash with
EIP equaling '41414141'. The application crashed but not due to an overflow. I also
noted at this point that my little 336Mhz laptop could chew up 25% of the available
resources of a 1.4Ghz machine before the application crashed again. Alas, I did not secure
EIP but I found my second DOS.
        At this point I wondered what else might be wrong with the application. Since this
application was a server it was natural to ask if this server had a limitation on the number
of concurrent connections? How many total open connections could the server handle at
once?
        I then revised my program for the third time to make as many simultaneous open
connections as possible. Well, I made about 1000 open connections at once. I found I
could knock the free memory to below 4% in approximately half a second. My third
WinME DOS was as sweet as honey.
        I decided to end my research and contact Microsoft. I knew I found at least two
exploits because I could crash the application and drain the system's memory.

Contacting Microsoft
        Based on my research I created a technical paper with my three DOS findings.
Then I emailed the paper and the program to Microsoft for verification. Microsoft and I
exchanged emails for over approximately three months. Here is a rough account of the
exchange.
        When I emailed Microsoft they assigned me a case number and sent my report to
the WinME security team. Microsoft did not reply with a status so I sent an email asking
for their findings. At this point they did not confirm my report but stated that their
"investigation is still ongoing." They were checking to determine the scope of the
problem and whether or not OEMs were distributing the server enabled by default. They
said, "Almost nobody has it turned on." Nobody? Well, I then reported to Microsoft that
both my parents and my girlfriend purchased the same major OEM's computer over the
course of a year. I speculate that this tidbit of information appeared to spark something
because the next email from Microsoft read: "We're having to find and contact the
configuration managers for each vendor, and then convince them to treat this as a priority.
As a result, [progress] is taking longer than we had expected." Since Microsoft already
sought this information from a number of OEMs and found nothing, perhaps this new
report triggered some tension between them? The next set of emails in early September
officially confirmed the WinME UPNP vulnerability and extended the scope of the
problem into their new XP operating system!
        Microsoft offered me the possibility to test the patch for the WinME and XP
vulnerabilities. I thought it was really great to be the only one in the world with the new
software; so I agreed. The problems I reported were fixed. I believed there were more
errors in the code, but at that point I did not posess the utilities to test my theories. So, I
guess I shall wait a bit to report anything new as I build my UPNP tools.
        Microsoft will incorporate the fixes into a XP patch to be released in late October,
2001. A security bulletin crediting me with the find should be released after the XP patch.
The bulletin number: MS01-54.

Disabling the Service
        For those who own a computer running the port 5000 UPNP server you can either
download the patch from Microsoft (see bulletin MS01-54) or disable it by deleting the
following registry key and rebooting:
 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServ
ices\SSDPSRV

Conclusion
        The lessons learned from this experience are astounding. First, software vendors
should extensively test their products for vulnerabilities. When an OS ships with many
sleeping executables, plan as though they will be enabled. In this case, problematic
software was released live and running on consumer's PCs! Second, at least one major
OEM placed their customer's at risk. They enabled a service to run on their distributions
of WinME that had security vulnerabilities. This happened in the past as well, but it is the
most recent I can recall. Second, since the WinME UPNP problem was not discovered
for approximately a year, we can safely assume most users never look and will never look
under the covers of their PCs to determine what is actually running. Hence, there will
always be computers on the Internet with the potential to be easily cracked. Finally, given
that there are security vulnerabilities out there in the wild, perhaps it is best if consumers
run a personal firewall on their PC. Who knows what service will next be enabled and
vulnerable without our knowledge and who will be looking to exploit it.

'ken' developed secure B2B e-commerce applications. He enjoys OS hardening,
penetration testing, network scanning and anything security related. He can be reached at
franklin_tech_unlimitedyahoo.com

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]