Open ipc$ Sharing _ Security Tutorial

First, let's get to know what ipc$ is.

ipc$ (Internet Process Connection) is a resource that shares a named pipe, which is a named pipe that is open for interprocess communication, by providing a trusted username and password, where both parties can establish secure channels and exchange encrypted data with this channel. This enables access to the remote computer. Ipc$ is a new feature of nt/2000, which has the feature of allowing only one connection to be established between two IP at the same time. NT/2000 provides the ipc$ functionality while also opening the default share when the system is first installed, that is, all logical shares (c$,d$,e$ ...) Shared with system directory winnt or Windows (admin$). All of this, Microsoft's original intention is to facilitate the management of administrators, but intentionally or unintentionally, resulting in a reduction in system security.
At ordinary times we can always hear someone say ipc$ loophole, ipc$ loophole, in fact, ipc$ is not a real loophole, I think the reason why some people say so, must be refers to Microsoft's own placement of the ' back door ': null session (NULL sessions). So what is a null session?

Before we introduce a null session, it's important to understand how a secure session is built.
In Windows NT 4.0, the Challenge Response protocol is used to establish a session with a remote machine, and a successful session becomes a secure tunnel in which the two parties exchange information, in the following order:
1 The session requester (the client) transmits a packet to the session receiver (the server), requesting the establishment of the safe tunnel;
2 The server produces a random 64-digit number (to achieve the challenge) to send back to the customer;
3 The customer obtains this by the server to produce 64 digits, uses the password which attempts to establish the session the account to disturb it, returns the result to the server (realizes the response);
4 The server receives a response and sends it to the local Security authentication (LSA), and the LSA verifies the response by using the user's correct password to confirm the requester's identity. If the requester's account number is a local account of the server, verify that local occurrences occur, and if the requested account number is a domain account, the response is transmitted to the domain controller for verification. When the response to the challenge is verified to be correct, an access token is generated and then routed to the customer. The client uses this access token to connect to the resource on the server until the proposed session is terminated.
The above is a general process of establishing a secure session, so what about empty sessions?

A null session is a session established with the server without trust (that is, a username and password is not provided). However, according to the WIN2000 access control model, the establishment of NULL session also needs to provide a token, but the null session in the establishment process and no user information authentication, so this token does not contain user information, Therefore, this session cannot send encrypted information between systems, but this does not mean that the null session's token does not contain the security identifier SID (which identifies the user and the owning group), and for a null session, the SID of the token provided by the LSA is s-1-5-7, which is the SID of the null session. Username is: ANONYMOUS LOGON (this username can be seen in the user list, but it is not found in the SAM database, is a built-in account of the system), this access token contains the following disguised groups:
Everyone
Network
Under the security policy, this null session will be authorized to access all the information that the two groups above have access to. So what can be done to establish a null session?

For NT, under the default security settings, the use of an empty connection can enumerate the users and shares on the target host, access to everyone's permissions, access to a small number of registry, and so on, and there is little value to be used; less effective for 2000 because in Windows 2000 and later versions, the default is that only administrators and Backup Operators have access to the registry from the network, and that it is inconvenient to implement, using tools.
From these we can see that this kind of untrusted session is not very useful, but from a complete ipc$ intrusion, null session is an indispensable springboard, because we can get a list of households from it, and most of the weak password scanning tool is to use this user list for password guessing, The successful export user list greatly increases the success rate of the guessing solution, which is sufficient to illustrate the security implications of empty sessions, so it is incorrect to say that empty sessions are useless. Here are some specific commands you can use in a null session:

1 First, we set up an empty connection (which, of course, requires a target open ipc$)
Command: NET use \\ip\ipc$ ""/user: ""
Note: The above command includes four spaces, net and use in the middle of a space, use the following one, the password around a space.

2 View shared resources for a remote host
Command: NET view \\ip
Explanation: If you set up a null connection, you can view the shared resource of the remote host with this command, and if it is shared, you can get the result as follows, but this command cannot display the default share.

Shared resources in the \\*.*.*.*
Resource Share name Type purpose note

-----------------------------------------------------------
NETLOGON Disk Logon Server share
SYSVOL Disk Logon Server share
Command completed successfully.

3 View the current time of the remote host
Command: NET time \\ip
Explanation: Use this command to get the current time of a remote host.

4 Get the list of NetBIOS user names for remote hosts (need to open their own NBT)
Command: NBTSTAT-A IP
This command allows you to obtain a list of NetBIOS user names for a remote host, returning the following results:

Node IPAddress: [*.*.*.*] Scope Id: []

NetBIOS Remote Machine Name Table

Name Type Status
---------------------------------------------
SERVER <00> UNIQUE Registered
Oyamanishi-h <00> GROUP Registered
Oyamanishi-h <1C> GROUP Registered
SERVER <20> UNIQUE Registered
Oyamanishi-h <1B> UNIQUE Registered
Oyamanishi-h <1E> GROUP Registered
SERVER <03> UNIQUE Registered
Oyamanishi-h <1D> UNIQUE Registered
.. __msbrowse__.<01> GROUP Registered
Inet~services <1C> GROUP Registered
is~server......<00> UNIQUE Registered

MAC address = 00-50-8b-9a-2d-37

The above is what we often use empty session to do things, seems to be able to get a lot of things yo, but to note: the establishment of the ipc$ connection operation will be in the event log record, regardless of whether you log in successfully. OK, so let's take a look at what Port ipc$ is using?

First, let's take a look at some basic knowledge:
1 SMB: (Server message Block) Windows protocol family for file print sharing services;
2 NBT: (NetBIOS over TCP/IP) uses the 137 (UDP) 138 (UDP) 139 (TCP) port to implement a NETBios network interconnect based on TCP/IP protocol.
3 in WindowsNT, SMB is implemented based on NBT, which uses 139 (TCP) ports, whereas in Windows2000, SMB can be implemented directly through 445 ports in addition to NBT based implementation.

With these basics, we can further discuss the choice of ports for accessing network shares:

For the Win2000 Client (initiator):
1 if the server is allowed to connect, the client will try to access the 139 and 445 ports at the same time, if 445 ports have a response, then send RST packet to 139 port disconnect, use 455 port for session, when 445 port is not responding, use 139 ports, If two ports are not responding, the session fails;
2 If the server is connected without NBT, the client will only attempt to access the 445 port and the session fails if the 445 port is not responding.

For the Win2000 server side:
1 if NBT is allowed, then UDP port 137, 138, TCP port 139, 445 will be open (listening);
2 If NBT is prohibited, then only 445 ports are open.

We have established the ipc$ session to the port of choice also adhere to the above principles. Obviously, a ipc$ session cannot be established if the remote server does not listen for 139 or 445 ports.

The IPC pipeline was originally designed by Microsoft to facilitate administrator remote management, but it seemed to the intruder that the host that opened the IPC pipeline was more likely to succeed. Through the IPC pipeline, we can call some system functions remotely (mostly through tools, but need appropriate permissions), which is often the key to the success or failure of the invasion. If this is not taken into account, only from the transfer of files in this respect, the IPC pipeline has given the intruder a great support, and even become the most important means of transmission, so you can always see in the major forums, some friends can not open the target machine's IPC pipeline and can not help crying. Of course, we can not ignore the authority in the IPC pipeline plays an important role, presumably you must have tasted the embarrassment of the empty session, no authority, open the pipeline we also helpless. However, once the intruder has access to the administrator, the IPC pipeline this double-edged sword will show its hideous side.

The quickest method of ipc$ intrusion at present
[1]psexec.exe \\IP-u Admin Account-p password cmd
With this tool, we can get the shell one-step.

OpenTelnet.exe \\server Admin Account password NTLM authentication method port
\ \ Use it to easily change the authentication method and port of Telnet to facilitate our landing

[2]
There is no second step, with a step to get the shell, you can do anything, Ann Backdoor can use WinShell, cloning on the CA bar, open terminal with 3389.VBE, record password with Win2kpass, in short, a lot of good tools, as you choose, I will not say more.

See ipc$ so terrible security hidden trouble, still don't close it, still wait for what?

Next, we introduce some ways to prevent ipc$ intrusion.

First, prevent the establishment of ipc$ NULL connection

Modify Registry Hkey_local_machine\system\currentcontrolset\control\lsa\

Value name: RestrictAnonymous Type: DWORD Value: 1

Click to view detailed introduction Click to download Noipc.reg file

Second, the closure of C $ and other systems default sharing

Modify Registry Hkey_local_machine\system\currentcontrolset\services\
LanmanServer\Parameters

Value name: AutoShareServer Type: DWORD Value: 0

Click to view detailed introduction Click to download Noshare.reg file

Third, stop the Server service (turn off the ipc$ service)
net stop server/y (Server service will reopen after reboot)

Four, shielding 139,445 ports
Because there is no more than two ports support, it is not possible to establish ipc$, so shielding 139,445 ports can also prevent ipc$ intrusion.

1, 139 ports can be blocked by NBT
Local connection-tcp/it Properties-Advanced-wins-Select ' Disable NetBIOS on tcp/it '

2, 445 ports can be modified by modifying the registry to screen
Add a key value
Hive:hkey_local_machine
Key:system\controlset\services\netbt\parameters
Name:smbdeviceenabled
Type:reg_dword
value:0

V. Installation of firewall for port filtering

Six, set up a complex password, to prevent through ipc$ poor cite password, I think this is the best way to enhance security awareness, than non-stop patching to be more secure.