This page is designed to bring your attention to the bugs in M$ software (for educational purposes of course).

If you need to find out what kind of server a machine on the internet is running then click here...

Windows NT seems to be the up and coming OS. At a glance Windows NT may look secure but of course its not.........

Windows NT Tools

L0phtcrack R1

L0phtcrack will recover passwords from Windows NT registries through dictionarys & by brute force. the program will return cleartext passwords both Lanman and MD4 up to 14 characters in length.

L0phtcrack is available from here

Below is descriptions of some interesting things to do with some NT ports.

Port 80

Port 80 has a massive problem in NT 4.0 (see posting below)

A lot of people are using the Microsoft Internet Information Server for their corporate web sites and intranets. The following procedure will halt the web services and effectively "kill" whatever web server they may have.

1. telnet the server on port 80 (if 80 is the http port)
2. GET ../..

It definetely works on NT4 + SP1 + IIS2.0. There are conflicting reports of it's effectiveness on 3.51, etc.

Microsoft has briefly addressed the problem stating that upgrading to IIS3.0 will solve the problem, however, I have also heard conflicting reports about that.

I guess a quick fix would be to move the http server to some other port that would take a long time to guess, or you could set up your NT server to reboot every 1.5 minutes.

FTP and POP on NT servers are not encrypted and with the use of a simple packet sniffer it would be simple to snag legitimate logins and passwords by setting the sniffer to the machine and port.

Port 19
CHARGEN, or port 19 which dumps endless ascii crap when connected to is a prime target for a flood, suppose that a IP spoof flood comes in (ICMP, UDP whatever) and queries this port a few thousand times... perhaps over a period of hours, the server will be shut down..

Port 53
DNS port 53 is by default an open port on NT, this makes it very easy to play around in this port..

Port 161
SNMP port 161 could be used to enable the NT performance monitor, by which a large amout of data about the targeted server could be obtained very easy.

Port 513 & 514
RSH and RCMD ports 513 and 514 respectively can be used to issue remote commands.

Port 520
RIP port (520) which uses UDP is another which could be used to spoof commands to a server. (send some mail via spoofed UDP to a forwarding address or whatever..)

NT 3.51 the REMOTE.exe and RSHSVC.exe files though RSHSVC is supposed to more secure can be used to issue commands over these servers with no restrictions. This could be potentially bad.

Other problems related to NT4, there is a default file called ism.html on IIS that can be used for doing remote/local administration on a server. The security of this file is horribly poor, each NT machine has a default account called "Administrator" and half of the servers out there are using the domain names as the password, or the machine name as the password. The FTP accounts on NT servers running virtual servers are very bad also. With "mainhost" being the host machine, for a virtual server:

ftp://ftp.mainhost.com/home/www.virtualhost.com/cgi-bin/filename.cgi

it will give you access to that file and call it up[ on the screen if you are using a web browser. Now if you then go to the main directory e.g

ftp.*.*/home/www.*.*/cgi-bin

it then lists the scripts if you're in a web browser u can view all the scripts on screen and check for any bugs, u then pull up the web browser and access those scripts using

http://www.vurualhost.com/cgi-bin/filename.cgi?

command and you can run the scipt having found the bugs, and this is all from the anonymous ftp login. it works at Microsoft.com as long as you know the directory structure you want to go to, even if the directory is hidden in anonymous ftp.
This bug is lethal.

When a Windows for Workgroups or Windows 95 machine shares any folder, bugs in Microsoft's SMB implementation over all network protocols allow access to the whole drive, with whatever permissions the sharename was given.

These resources are advertised on a browse list that is made available to anyone on the local network by default, and to anyone on the Internet who knows the machine's IP address. Any user sharing any folder over TCP/IP without a password is opening the whole disk to the whole Internet (for those that can locate the machine) and those with a password should be aware that Windows has no protection against brute force attacks.

SMBCLIENT, an ftp-style browser for any UNIX, plus a complete file system for Linux and a few UNIX versions, are available from the Samba web site. Please note that Samba's exploitation of this fundamental bug in Microsoft file sharing was unintentional, and was immediately reported to Microsoft. It could have happened with any client over any protocol.

An alleged fix for Windows for Workgroups was quietly released in early October, and Microsoft publicly announced a fix for Win95 on October20th. It has not been rigorously tested, but it appears to fix the problem. The fix for Windows for Workgroups might not be a complete fix, but rather a patch for one way to exploit the problem. (The release version of Win95 prevented cd .. below the shared folder "root," but not cd../)

The patches and Microsoft press releases (which have been corrected at least twice, but which still erroneously identify Samba as shareware, neglect to credit the people who notified Microsoft of the problem, and neglect to mention that this is a fundamental bug in Windows, not a problem specific to TCP/IP or Samba) are available on Microsoft's Windows 95 Updates Page. The patch only works on the US/English version of Windows 95; at this writing, all non-English versions of Windows 95 are still vulnerable.

With Remote Administration and File Sharing for Netware Networks enabled on a Windows 95 machine, once a remote administrator accesses the system, a shared resource pointing to the hard drive is created to which all users on the same network have access. This share remains available even after the administrator logs off the system.

The shared drive is not visible by browsing through the Explorer, but may be found by mapping a network drive to \\computername\C$. This gives read-only access to the entire local hard drive of the sharing computer.

By default, Windows 95 and Windows for Workgroups implement a "password caching feature" whereby the passwords for all network services (NetWare, NT, Samba, SLIP/PPP service) are automatically and permanently stored in C:\WINDOWS\<USERNAME>.PWL.

Microsoft claims they are encrypted securely.

Peter determined that the Windows PWL encryption algorithm was incredibly insecure. Frank wrote a program to break the .PWL files in Windows. (More details are forthcoming, a draft version is available currently.) Source code and a Windows NT executable for the exploit program are available. In effect, anyone with physical or network access to a Windows machine has access to all network passwords used by all users of that machine.

Late afternoon December 14th, Microsoft released an alleged fix (altenate site here) for the problem, which is supposed to make passwords harder to find, but it has not been reviewed by outside experts, and it doesn't even come with a ReadMe file. Unlike Netscape, Microsoft has not published its encryption algorithm for the customary peer review. Until they do, we recommend disabling password caching and user profiles; see the win95netbugs list archive and FAQ.

Winpopup crash under NT.
Obtain user listings etc through trust in NT
Mount "C:".
Obtain Win95 cleartext passwords over internet.
ISS V3 Vulnerability.
ISS V1 Security Vulnerability.
Buffer overflows in Windows.
Its facinating what you can find.
Killing NT4 name server[micro011.txt - MISSING].