A journey into forgotten Null Session and MS-RPC interfaces – Source: securelist.com

A journey into forgotten Null Session and MS-RPC interfaces (PDF)

It has been almost 24 years since the null session vulnerability was discovered. Back then, it was possible to access SMB named pipes using empty credentials and collect domain information. Most often, attackers leveraged null sessions for gathering domain users through techniques such as RID (Relative Identifier) enumeration. RIDs uniquely identify users, groups, computers and other entities within the domain. To enumerate them, the attacker used MS-RPC interfaces to make some calls and collect information from the remote host.

To prevent such attacks, Microsoft restricted null session capabilities by limiting what an attacker can do after connecting to named pipes, and provided security policies that could be implemented to stop all null session activities. Today, although null sessions still exist and are enabled by default on domain controllers (most likely for compatibility purposes), most system administrators close this capability by hardening the security policies and monitoring domain controller activities, including anonymous access through SMB.

As penetration testers, we always pose the question: is it really as secure as it seems? In this case we asked if we can bypass policies and restrictions today, after 24 years, and bring the idea of anonymous access back to life. This research is tailored for security researchers and penetration testers seeking to enhance their understanding of MS-RPC interfaces and refine their research techniques. It’s important to note that all information in this article is intended for legitimate security research purposes only, and must not be used for illegal activities.

The research is divided into two parts. In this post we share the first part, devoted to the research methodology against MS-RPC interfaces, developed after observing some interesting behavior from one of the Windows interfaces. Also included is a discussion of how we can link this behavior to null sessions, and revive their legacy by enumerating information from the domain controller, specifically domain users without triggering any alerts.

About null session

Null sessions have emerged as a pivotal area of interest and concern within the field of cybersecurity. They occur when access to a network resource, most commonly the IPC$ “Windows Named Pipe” share, is granted with empty credentials. $IPC (Inter-Process Communication) is a hidden share that processes on different computers use to communicate with each other. After obtaining anonymous access to this resource, an attacker can bind an MS-RPC interface exposed by a particular named pipe inside the IPC$ share, and start to gather information such as shares, users, groups, registry keys and much more.

In newer Windows versions, the null session capability has become more restricted, and is available in Windows servers that act as domain controller only. When you upgrade your server to a domain controller, null session access to the following named pipes is available by default:

• “pipenetlogon”;
• “pipesamr”;
• “pipelsarpc”.

To prevent null sessions, two related system policies were introduced: “Restrict anonymous access to Named Pipes and Shares” and “Network access: Named Pipes that can be accessed anonymously.” The first policy, “Restrict anonymous access to Named Pipes and Shares,” is enabled by default. The second policy, “Network access: Named Pipes that can be accessed anonymously,” contains the three named pipes we discussed earlier (netlogon, samr, and lsarpc). To prevent any action related to null sessions, the latter policy is set to empty so that these named pipes can be accessed anonymously.

Enumerating network interfaces without authentication

During my work in traffic analysis, I noticed many packets related to DCOM communications between domain controller and other endpoints, which were tagged by Wireshark under the IOXIDResolver RPC interface and the ServerAlive2() method. The IOXIDResolver interface is actually the IObjectExporter interface. As Microsoft mentions, it is used for OXID resolution, pinging and server aliveness tests. In brief, it helps in the process of locating and connecting to remote objects involved in resolving OXID references to actual network locations (such as IP addresses) of objects in a DCOM environment.

One of the IObjectExporter methods is ServerAlive2. The ServerAlive2 (OPNUM 5) method was introduced with version 5.6 of the DCOM Remote Protocol, and extends the ServerAlive method. It returns string and security bindings for the object resolver, which allows the client to choose the most appropriate settings, compatible with both client and server. The IObjectExporter interface uses TCP port 135 as an MS-RPC endpoint.

In the traffic for each TCP stream related to DCOM communication, there were four packets. The first is related to binding the IObjectExporter interface, the second to the server binding response, the third to the ServerAlive2 function call, and the final packet is the response for the ServerAlive2 function, which contains all the network interfaces for the domain controller.

The image above shows a bind request for IObjectExporter interface. You can see that the Auth Length header is equal to zero, indicating that the authentication level is None, and hence, there is no authentication. With just two packets from the client, we can enumerate network interfaces for the remote host without authentication.

The idea struck me: what if there are other RPC interfaces vulnerable to no authentication? What kind of enumeration could be obtained from them? Can we map it to the famous null session? And what research strategy should I follow to find this out? In the full version of the research (PDF), I try to answer these questions, discuss a new path for enumerating domain information, and share a tool that implements the idea of this new path.