OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: 'ken'FTU
Date: Fri Nov 02 2001 - 00:00:23 CST

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

    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