Hackers Beware

Figure 12.12. Legion automatically mapping the share to the next available drive letter.

The user may also want to export the list of discovered shares to a text file for later use by an alternate utility or simply for reference. This can be accomplished by clicking the Save Text button. The output is a standard text file in the format of \\ HOSTNAME \SHARENAME, as shown in Figure 12.13.

Figure 12.13. Text file produced when the list of discovered shares is exported.

When the user wants to attempt a brute force password cracking attack (which in reality is a dictionary attack) against a NetBIOS share with share-level access, the user can initiate the Brute Force Password Cracking Tool by clicking the Show BF Tool button at the bottom of the screen. The Force Share window then appears, as shown in Figure 12.14. The user must type the name of the target share in the Path dialog box, add one or more word lists to the Word Lists dialog box, and then click the Start button.

Figure 12.14. Legion attempting to perform a brute force password cracking attack.

Legion displays a response informing the user whether or not the brute force attempt was successful, as shown in Figure 12.15.

Figure 12.15. Successful brute force password attack with Legion.

If successful, Legion automatically maps the share to the first available drive and informs the user, as shown in Figure 12.16.

Figure 12.16. Legion automatically mapping to shared drive after the password was cracked.

Signature of the Attack

The true signature of a Legion enumeration attempt, as well as many other enumeration attempts, are inbound NetBIOS session TCP connections to TCP port 139. Unfortunately, Microsoft has not implemented a native capability into its platforms that allow for the monitoring and logging of network-level events such as these. On WinNT systems, the share enumeration component of Legion does result in the

generation of a Privilege Use Success Event #576 in the Security Event Log, and the brute force password cracking tool results in the generation of Logon/Logoff Failure Events #529 (and potentially #539 if the account gets locked out) in the Security Event Log. This is shown in Figure 12.17.

Figure 12.17. NT EventViewer log showing indication of a Legion attack.

Upon a more detailed investigation, it becomes evident that the Privilege Use Event #576 is generated in response to the granting of the SeChangeNotifyPrivilege to the new logon, as shown in Figure 12.18.

Figure 12.18. Detailed view of the privilege use event log generated by legion.

The Logon/Logoff Failure Event #529, Figure 12.19, looks just like any other “Unknown user name or bad password” logon failure from a remote workstation (Logon Type: 3), and the “Account locked out” Logon/Logoff Failure Event #539, Figure 12.20, looks like it as well. It should, however, be relatively easy to distinguish between the brute force password guessing attempts of a tool, such as Legion, and the occasional invalid password simply because of the sheer volume of invalid logon attempts generated by Legion and the short time span over which they occur.

Figure 12.19. Event #529, “unknown user name or bad password” log entry.

Figure 12.20. Event #539, “account locked out” log entry.

One fact worth noting about these Event log entries is that although Microsoft has chosen to record the workstation name from which these attempts originate, (this can be easily spoofed by simply changing the workstation name) they have neglected to record the source IP address of the attempts, thereby making the incident handling process that much harder.

That being said, at least WinNT writes a log entry—Win9x systems don’t even do that. There is no innate capability to record or detect any kind of attack signature whatsoever on these platforms.

Fortunately, the personal firewall market has finally started to mature, and there are some very good Win9x-/WinNT-based firewalls, which are not very expensive and do an excellent job of detecting, recording, blocking, and alerting the user to unwanted network activity directed at their workstation. One of my favorites is @Guard, which was originally a WRQ product, but it is now part of the Norton Internet Security Suite of products. This is just one of several quality products that are available.

With such a product installed, it is easy to identify unwanted network activity. Figure 12.21 shows the @Guard log file, captured on a Win95 system, which makes evident the tell tale signs of the brute force password cracking component of Legion. Multiple inbound connection attempts to the NetBIOS-ssn TCP port 139 are clearly visible in the log. Furthermore, the attack was blocked, and the IP address of the offending system was easily obtained from the log.

Figure 12.21. @Guard log file showing a Legion attack.

How to Protect Against Legion

Depending on which version of Windows you are running, there are different ways to protect against Legion.

For Win9x systems:

1.If the system is not connected to a LAN and does not need to share files across the Internet, unbind “Client for Microsoft Networks” and “File and printer sharing for Microsoft Networks” from every network adapter using TCP/IP.

2.If you are connected to a LAN and you must use NetBIOS file sharing, adhere to the Principle of Least Privilege when granting access to those shares. That is share only the directories that are absolutely required, make the share read only if possible, grant only user-level share access, if your version of Win9x supports this option, and be certain to use strong passwords for share-level access to file shares.

3.Install a personal firewall, implement a security policy that denies inbound access to the NetBIOS over TCP ports (TCP and UDP ports 135 through 139), and monitor the firewall logs for signs of illicit activity.

For WinNT Systems:

1.Prevent the anonymous user from connecting to a null session and enumerating system information by setting the RestrictAnonymous Registry key. See Microsoft Knowledge Base article Q143474 for information regarding the implementation of this feature.

2.If you are connected to a LAN, and you must use NetBIOS file sharing, adhere to the Principle of Least Privilege when granting access to those shares. (That is share only the directories that are absolutely required, make the share read only if possible, grant user-level share access only to required individuals.)

3.Install a personal firewall, implement a security policy that denies inbound access to the NetBIOS over IP ports, (TCP and UDP ports 135 through 139) and monitor the firewall logs for signs of illicit activity.

4.Ensure that the account policy is configured to lock out all accounts after a small number of unsuccessful login attempts.

For the Network:

Block all inbound network traffic destined for the NetBIOS over IP ports (TCP and UDP ports 135 through 139) at the perimeter firewall or perimeter router.

Additional Information

Additional information on legion can be found at the following sites:

•http://sans.org/topten.htm

•http://www.securityfocus.com/

•http://support.baynetworks.com/library/tpubs/html/router/soft1200 /117358AA/B_39.HTM

•http://www.technotronic.com/rhino9/

Relative Shell Path Vulnerability

This exploit is a variant of the traditional Trojan horse mechanism, in which a bogus and potentially malevolent executable is made to masquerade as and/or launch an authentic executable. It also qualifies as a privilege escalation exploit, which allows a user with limited privileges to gain more privileges by exploiting a system vulnerability.

Exploit Details

•Name: Relative Shell Path” Vulnerability

•Variants: none

•Platforms Affected: Windows NT 4.0 and Windows 2000

•Protocols/Services: This vulnerability exists through the Windows API call “CreateProcess” and its particular usage in conjunction with

invoking executables whose paths are contained in the Windows NT/2000 Registry.

•Written by: Earl Ray Evans

It is possible for a non-privileged user to cause Windows NT 4.0 or Windows 2000 to invoke an alternate, bogus version of explorer.exe (desktop) during logon sessions, instead of the authentic explorer.exe executable.

This means that the non-privileged user could cause anyone who logs into the machine (including a privileged user) to run the non-privileged user’s code of choice upon logon.

Protocol Description

The Windows API call “CreateProcess” invokes an executable. The way in which it locates the correct executable to invoke (the executable path) is at the heart of this vulnerability.

Description of Variants

Trojan horses are among the most ancient of attacker exploits. Examples include:

•Phony logon screens that record passwords for later use by an unauthorized entity.

•Replacement of legitimate system functions (such as compilers and mail applications) with malevolent code that masquerades as the real thing.

•Rootkits that contain executables, which hide the fact that an attacker has compromised a system.

Trojan horses are often part of a progressive exploit in which a system vulnerability is used to allow the attacker to plant the malevolent Trojan code into the system. For example, in the specific case contained in this document, the vulnerability allows the attacker to replace the legitimate explorer.exe (essentially, the Windows desktop) with arbitrary code.

How the Exploit Works

When a Windows NT 4.0 or Windows 2000 system function calls for invocation of an executable with a relative (not fully specified) pathname, it searches a predictable set of paths to find the executable. The most likely sequence is:

1.%SystemDrive%\ (for example, C:\)

2.%SystemRoot%\System32 (for example, C:\WINNT\System32)

3.%SystemRoot% (for example, C:\WINNT)

These paths are defaults, and may be different on some machines depending on installation choices. Detailed information on these paths and what they represent can be found in the “Additional Information” section of this exploit description.

If an attacker somehow places an executable with the same name as a legitimate executable earlier in the search path sequence, and if the executable is invoked with a relative (not fully qualified) path name, the attacker’s executable will be invoked instead of the legitimate executable.

This requires that:

•The attacker has read/write privileges to a directory in the search path.

•The executable is not specified with a fully qualified path name.

By default, users on a machine have read/write access to a directory in the search path—the root of the system drive (for example, C:\). Also, by default, the Registry entry that calls explorer.exe (the Windows desktop) upon logon uses a relative path name (explorer.exe) instead of a fullyqualified pathname.

So, by placing a bogus executable named explorer.exe in the C:\ directory, an attacker can cause any user logging in to the machine to run the bogus explorer.exe in the logon sequence. The bogus explorer.exe might then run the real explorer.exe (to avoid suspicion), but would also perform actions to help the attacker gain further privileges on the machine.

How to Use It

This exploit permits a non-privileged user to surreptitiously cause a privileged user to run arbitrary code under the security context of the privileged user upon logon. One good way to take advantage of this ability would be to cause code to be invoked, which adds a new privileged user account to the system.

The sample exploit that I have tested and documented includes the following steps:

1.Create a bogus explorer.exe file, which first invokes the authentic explorer.exe (in the \WINNT directory), but which also runs a utility (addusers.exe) to add a new, privileged user account to the system.

2.Login interactively to the target machine as a non-privileged user.

3.Place the bogus explorer.exe, addusers.exe, and the support file accounts.txt in the C:\ directory.

4.Await a privileged user to log into the machine.

5.Return to the machine and log in using the new, privileged account. Welcome to the Administrators group!

Signature of the Attack

Strange files placed in the C:\ directory are a sign that something is amiss. In particular, a file named explorer.exe in the C:\ directory is a dead giveaway.

How to Protect Against It

Microsoft patches are available to fix this specific problem. See the Microsoft Bulletin and FAQ for additional details, which is located at www.microsoft.com.

Other best practices that would protect against exploits of this nature include:

1.Do not permit interactive login to critical machines, such as domain controllers, servers, and other infrastructure platforms. Use both physical and logical security to safeguard these platforms.

2.Change file permissions on systems as appropriate to safeguard directories.

3.Use host intrusion detection tools (such as Tripwire) to detect and alarm when changes are made to key directories.

4.Use auditing to log and discover key system changes (such as the addition of a new, privileged user account).

Source Code/Pseudo Code

I have included source code that (in concert with the addusers.exe utility from the Windows 2000 Resource Kit) demonstrates how this vulnerability can be exploited. I have successfully tested this code on a Windows 2000 Professional platform.

The bogus program explorer.exe is created from the following explorer.c source file. This was compiled with the C compiler in Microsoft Visual Studio 6.0.

Listing of explorer.c

#include <stdio.h> #include <process.h>