Heartbleed - CVE-2014-0160

Below shows how an attacker used RMI requests to identify which servers on the network used Java for networking. Whichever servers were found that were not using Java, they attacked with the exploit Heartbleed.

I recieved five Suricata rule alerts from Azure. One was unique, and the other four were the same. Analysis of both alerts below.

Source IP - 192.168.10.151:34656 Destination IP - 192.168.10.144: 445

Port 445 is the Server Message Block, which is network file sharing between computers on the network.

Pattern of Behaviour

Source device is sending RMI (remote method invocation) request from a random source port (34656) to destination device through port 445.

“Alert Rule” references “reference:url, github.com/rapid7/metasploit-framework/blob/04e8752b9b74cbaad7cb0ea6129c90e3172580a2/lib/rex/proto/rmi/model.rb;”

Packet encoded in Base64. Python script to convert Base64 to byte sequence.

Ethernet frame analyzer for packet.

Source MAC Address is not registered, and destination MAC address to VMware device.  Unsure if destination and source addresses are flipped in this scenario. Possible that attacker tried to connect to a honeypot, or the captured packet could be the response (destination) to the attacking machine which is using VMware.

Packet capture was incomplete and has continuation data. Packet_info.linktype: 1 indicates ethernet connection. Likely scripts:

nmap --script rmi-dumpregistry -p 445 <host>
nmap --script=rmi-vuln-classloader -p 445 <target>
nmap -sV -sC -p <target>
msfconsole = auxiliary/scanner/misc/java_rmi_server

Tactics:

TA0007 - Discovery: The RMI request can be used to discover/interact with Java objects on a device.

Techniques:

T1046 – Network Service Discovery: The RMI request can be used to discover/interact with Java services on a device.

Procedures:

Network Traffic Obfuscation: Port 445 is a notorious port as it is used for file sharing across a network. The attacker could be using an RMI request in an attempt to bypass the port 445 protection, and then discovering which devices are java enabled on the network.

Recommendations:

Java RMI is not used anymore as both client and server need to be programmed in Java, and is insecure. All Java RMI objects should be replaced with REST or raw socket programming immediately.

Insight 1504:

1.       Source IP – 192.168.10.185:12320

2.       Destination IP – 192.168.10.151:57060

Insight 1505 source:

1.       Source IP – 192.168.10.198:47769

2.       Destination IP – 192.168.10.151:44594

Insight 1552 source:

1.       Source IP – 192.168.10.189:443

2.       Destination IP – 192.168.10.146:42356

Insight 1555 source:

1.       Source IP – 192.168.10.198:47769

2.       Destination IP – 192.168.10.146:42164

Pattern of Behaviour:

The Suricata alert sends a warning when a TLS message is received with content that matches the string “00 02 02 28”. The first two blocks “00 02” indicate the major version (TLS version) and minor version (CipherSuite) which in this case is TLS_RSA_WITH_NULL_SHA, respectively.

TLS 1.0 was published in 1999, and TLS 1.1 in 2006, which were both “officially” deprecated 2021, even though more secure methods have been widely adopted a long time before deprecation.

Hopefully no internal server or device would be using TLS 1.0 or 1.1, therefore we are treating this as malicious. Immediately we would assume this as a TLS downgrade attack.

The other clue we have is that the packets included in the metadata was encoded using base64, as well as packet_info.linktype: 1 which is ethernet. Convert base64 packet to hex in screenshot below.

Source devices below from insight 1504, 1505, 1552, and 1555 respectively.

The source device of insight 1505, and 1555 have the same mac address, as well as the same IP address and source port (192.168.10.198:47769). The system supressed messages from each insight 69, 35, 29, and 11 times, respectively.

Another notable item is the payload_printable field which reads “......(“.

Through a bunch of digging around on the internet, this is found on an openssl website (https://mta.openssl.org/pipermail/openssl-users/2015-March.txt), which fits the Suricata rule perfectly.

Found through more digging that the traffic we’ve seen is related to the Heartbleed vulnerability.

With the repeated and supressed requests we can be certain it’s the Heartbleed exploit, which is easily accessible through Metasploit. Heartbeat was a feature added for keep-alive functionality.

Tactics

-          Exploitation of the heartbeat extension (RFCC6520) causing memory leakage from the server to the client and the client to the server.

Techniques

-          Sending specialized and repeated heartbeat requests.

Procedures

-          Data extraction once encryption keys have been captured.

Recommendation

Identify if any servers are using TLS 1.2 or less, and ensure all servers use TLS 1.3.