Partager via

Kewl Tools

  • Article

Microsoft released a new support tool to monitor port usage on a computer. To quote the Web page, "Port Reporter logs TCP and UDP port activity on a local Windows system. Port Reporter is a small application that runs as a service on Windows 2000, Windows XP, and Windows Server 2003. On Windows XP and Windows Server 2003 this service is able to log which ports are used, which process is using the port, if the process is a service, which modules the process has loaded and which user account is running the process."

You can pick it up here.

Comments

  • Anonymous
    March 17, 2004
    Installing this tool appears to open the possibility for an elevation of privilege attack from Power Users to SYSTEM.

    This is a service that when installed runs as SYSTEM, and the EXE file for the service is installed in the Program Files directory, where it inherits a DACL that's just not strong enough for a service that runs as SYSTEM.

    A power user could overwrite the EXE file with an arbitrary program, then start the service to launch her code running as SYSTEM.

    The installer should be fixed to either set the DACL on the EXE so only administrators are allowed to overwrite it, or even better, it should be installed in a subdirectory off the Windows installation root, which always has a strong DACL on it.

    On a personal note, Power Users is evil and should be eliminated. I hope the Longhorn team doesn't back down on that one...
  • Anonymous
    March 19, 2004
    Errrrr..... Power Users already have "Change" access to %systemroot% and %programfiles%, so they can already do this in a default install of the OS. This doesn't seem to add any new vulnerabilities.
  • Anonymous
    March 19, 2004
    Ever wonder why we call Power Users, 'Admin Lite'
  • Anonymous
    March 20, 2004
    Good point. Power Users do have change access to those directories, so simply installing under those roots won't solve the problem.

    But if you check the ACLs on built-in services (like inetinfo.exe, services.exe, etc.), they do not allow anyone but administrators to overwrite them. So power users cannot simply overwrite these files. Heck, even NOTEPAD.EXE is locked down this way.

    Do you happen to know of a way that a power user can elevate to SYSTEM in a default install of Windows? Sure, he can overwrite WINWORD.EXE and wait for a real admin to run it, but is there a way he can elevate immediately to SYSTEM in the way this service with its weak ACL would allow?

    Any privileged EXE should have a strong ACL on it, period. That's just good hygiene. And I'm disappointed that this tool doesn't set a better example, especially considering that it's a "security" tool.
  • Anonymous
    March 20, 2004
    Hmmm, on one of my machines SVCHOST is has "Power Users: Change" but on another machine it doesn't. Both have XP SP 2 installed. I wonder why?

    In fact, the ACL is whacked-out:

    cacls svchost.exe

    MACHINEWeb Applications:N
    MACHINEWeb Anonymous Users:N
    MACHINEIUSR_PTORR-NEW:N
    BUILTINUsers:R
    BUILTINPower Users:R
    BUILTINAdministrators:F
    NT AUTHORITYSYSTEM:F
    BUILTINUsers:R
    BUILTINPower Users:C
    BUILTINAdministrators:F
    NT AUTHORITYSYSTEM:F

    I wonder if IISLockDown has anything to do with it...?
  • Anonymous
    March 21, 2004
    Hmm. I tried this tool and found that it may be useful for debug use but it is not something we can log "everything we need" when we operate servers. That is, when we filter out specific ports like HTTP, this tool cannot log the connection attempts. I watched this behavior with ICF, IPSec, and RRAS on Windows Server 2003. It seems this tool resides over these filters, possibly in user mode, not the kernel.

    It cannot always log udp traffics like ISAKMP or Syslog, as we have evaluated. (We here means Mr. Hideaki Ihara <a Japanese MVP>, other cool Japanese engineers, and me.)

    (I am going to submit a feedback through an appropriate path to the author later.)

    Well, let's focus on good things in this tool. ;-)

    What is good in this tool is that it picks up the related modules (not only *.exe but related DLLs, with the name of the service it is initiated from), the port status (whether it is listening or not), and the process info.

    We can use this tool to see if a worm has sent tons of connection requests to the network the machine resides, for example, or more generic debugging purposes like application development or troubleshooting on network matters.

    Is there any other good points?

    I still think this tool is cozy and useful, so let's share the knowledge.

    Hope this info helps you all.
  • Anonymous
    March 22, 2004
    Hi everyone. I appreciate all of the feedback you have provided on Port Reporter. I think Keith has valid point. I have done two things to address this issue:

    1. I have updated the installation steps listed in the KB article (http://support.microsoft.com/?id=837243). It now gives administrators some guidance on securing the installation directory.

    2. I have updated the installer so that it sets DACLs on the default installation directory (%SystemDrive%Program FilesPortReporter). It gives the local administrators group full control and it explicitly denies all access to the local guest and anonymous logon groups.

    If you have other suggestions about how this directory should be ACL'ed please let me know with another post here.

    I still have some testing to do so I can't give you an ETA on when the package will be updated on the download center.

    Thanks again.

    Tim
  • Anonymous
    July 31, 2004
    The comment has been removed