Days ago, a mysterious online group called Shadow Brokers claims to have stolen US “cyber weapons” from a hacking team called Equation Group. These “cyber weapons” contain about a dozen vulnerabilities which are believed to be exploits used by the National Security Agency (NSA). In this blog, I will analyze the shellcode from the Cisco exploit and show its behind-the-scenes behavior.
This week Microsoft released a patch for a critical Silverlight issue, MS16-006, and since I worked on Silverlight signatures in the past it caught my eye. It’s a Remote Code Execution vulnerability which allows attackers to run code of his or her choice on the victim machine. I had a hunch that something more was hiding. I started to analyze it as soon as I finished writing signatures for the existing patch. When I was working on the analysis Kaspersky Lab published a great blog post about the story of this vulnerability.
In this blog, I’m presenting analysis of a different function that was also fixed in the same patch.
It was a routine patch Tuesday and I was developing signatures for Qualys VM to identify vulnerabilities. But when I glanced at CVE-2015-1635 it was clear immediately that there was nothing routine about it. It’s a critical vulnerability which can allow remote attackers to take complete control of IIS web servers without have any prior credentials to the server. Now that is BIG! After releasing the VM signature I started working on this blog post which explains a bit further on how an attack using CVE-2015-1635 works. The blog post also explains the working of Qualys VM QID 91041.
Recently three students from University of Saarland in Germany discovered that the MongoDB databases running on several thousand commercial web servers allow remote attackers to easily access and manipulate the database from the Internet. According to their research, it is not uncommon for MongoDB databases to be configured to accept any connection from the Internet.
In this blog I will discuss how unauthorized access works and how to check if your MongoDB is exposed. Qualys Vulnerability Management has released QID 19965 to check for the same.
Today Qualys is releasing QID 13038 in VULNSIG Release VULNSIGS-2.2.831-5 for remotely detecting ShellShock. For details on BASH ShellShock, refer to Wolfgang’s blog BASH Shellshock vulnerability – Update2. As you may know there could be multiple exploit vectors and the most popular remote vector is via the use of a cgi script using HTTP headers. QID 13038 is based on a similar technique. If you need a complete inventory of your machines that need patching we recommend that you use the authenticated QID 122693 and QID 122698.
Videoconferencing equipment has been in the news recently for its potential for use by attackers to snoop on confidential company meetings, view charts mounted on meeting room walls, or listen in on conversations stealthily. While this is not a new vulnerability per se, and videoconferencing equipment has been usable for more than a decade in this way, I thought it would be interesting to build and release an open source tool that could detect whether a given videoconferencing system is vulnerable to these attacks. That tool is now complete and available as auto-detect.py.
In this article, I explain the underlying videoconferencing protocol, how it is vulnerable, and how the tool detects the vulnerability. I also discuss why we decided to release this tool rather than fully enabling it in QualysGuard at this time.
‘Auto-answer’ is the ability to accept incoming calls or requests automatically without or with very little prompting. ‘Auto-answer’ is enabled by default in most videoconferencing equipment, and can allow an attacker to ‘join’ a videoconference by stealth.
H.323 is a recommendation from the ITU Telecommunication Standardization Sector (ITU-T) that defines the protocols used to provide audio-visual communication sessions on any packet network. Most videoconferencing equipment uses the H.323 protocol stacks, which contain the protocols as shown below:
In the TCP/IP layering model, H.323 sits at the application layer and uses the TCP/UDP services provided to transmit H.323 packages in a TCP/IP based network. H.323 uses Q.931, the ITU standard ISDN connection control signaling protocol, to establish connections. When the Q.931 connection has been successfully set up, videoconferencing initiation is implied. Below is how Q.931 connection is set up:
Once the Q.931 connection is established, both A and B can start their videoconferencing. If Caller B has ‘auto-answer’ enabled, Caller B will directly reply with a ‘CONNECT’ message without the ‘ALERTING’ step, initiating the videoconferencing session without the incoming call indicator.
The ‘auto-detect.py’ tool needs two parameters, an IP address and a port number, and can be run as shown in the screen capture below. The tool also displays other information from the remote equipment like the Manufacturer ID and Product ID:
The tool establishes a TCP connection and creates a Q.931 ‘SETUP’ message as shown below:
If you run wireshark, you can see the ‘SETUP’ message being sent with other fields in the Q.931 protocol.
If the remote videoconferencing equipment answers with the ‘ALERTING’ message, it implies that the equipment is ringing to indicate an incoming call. It also implies that ‘auto-answer’ is turned OFF. But if the videoconferencing equipment answers with the ‘CONNECT’ message, that implies that we are connected to the videoconference. The remote equipment is accepting incoming calls automatically (‘auto-answer’ is ON) as shown below:
As we’ve seen, the process of detecting ‘auto-answer’ requires a real call to be placed on the videoconferencing equipment. At this time, we think this could be disruptive, possibly causing interruptions or annoyance, so we have provided the option to use auto-tect.py to detect wether 'auto-answer' is enabled manually.
Customers can use QualysGuard in conjunction with the auto-detect.py tool to identify videoconferencing systems with 'auto-answer' enabled as follows:
Once vulnerable videoconferencing systems are identified, QualysGuard and internal processes can be used to manage and reduce the risk of attack to these systems.
This videoconferencing vulnerability, like the printer vulnerability identified in January, is a timely reminder that, while most vulnerability management effort is focused on the core set of servers and end-user devices like PCs, it’s important to consider the potential vulnerability of all devices in your network.
On October’s Patch Tuesday 2011, Microsoft released Security Bulletin MS11-082 to fix “Access of Unallocated Memory DoS Vulnerability” within Microsoft Host Integration Server. According to the security advisory, a remote, anonymous attacker who exploited this vulnerability could cause the affected system’s SNA Server service to stop responding to new requests. This is caused because the snabase.exe crashes and also kills snarpcsv.exe and mngagent.exe due to the dependencies between them.
To get a better understanding of the cause of this vulnerability, we have reverse engineered the affected server and found the condition that triggers the DoS. This article also has a short Python PoC which uses CVE-2011-2008.
The Host Integration server snabase.exe listens on UDP port 1478 or TCP ports 1477 and 1478. Figure 1 shows the code path that it takes when a UDP packet is received and EAX points to the received packet. At location 01029B73, the server moves the third byte (EAX+2) to ECX and then compares it with different values. If the value is greater than 5 the code jumps to 01029EAC. If the value is equal to 5 it jumps to 01029E77. The value can now only be in range 1-4 at 01029B90. Next it decrements the value by 1, step by step, to check if it is 1 , 2, 3 or 4. This is a typical switch statement which compares the value and calls different handlers. The compiler replaces the switch statement with the sub/dec instructions to optimize the program execution.
Figure 1: Switch statement to handle the third byte.
For a successful exploit there are two conditions that need to be satisfied. The first condition is that the third byte is 0x1. The execution will then goto 01029C42 and then 0101F99D.
The 4th and 5th bytes of the packet contain the “entries” in this message. The server reads the values and then checks these entries one by one in a loop. But if the server was told that there are more than 0x4B entries then the server will try to access memory locations that are not allocated resulting in the process getting terminated. This is the second condition that should be satisfied for a successful exploit. The number of entries must be greater than 0x4b.
Figure 2: The checking for number of entries.
For the PoC both the conditions as stated above need to satisfied which just takes 5 bytes. What we need is to set the 3rd byte to 0x1 and then set 4th and 5th byte greater than 0X4B. The first and second byte does not affect our exploit, so any value will work. The Python script should like this:
#!/usr/bin/python
import socket, sys
from struct import pack
target = sys.argv[1]
port = int(sys.argv[2])
request = "\x00\x00\x01\x4C\x00"
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
try:
print "[+] Sending request"
s.sendto(request, (target, port))
except:
print "[X] Unable to connect to %s" % target
Figure 3: Accessing unallocated memory (Process dies)
By using binary diff tool we can see that the patch added a new verify function at 67481133:
The function takes the length and address of the UDP package as parameters.
Figure 4: The checking for number of entries.
The packet will be considered as invalid unless the function 67480AE6 returns 0 (return value is stored in EAX). This function first checks the length of the UDP packet. It return error(EAX not 0) if the length is less than 3. Then there is another switch statement on the third byte of the packet.
Figure 5: The checking for number of entries.
If the third byte is 0x1 the function jumps to 67480B3F. The value at dwEnableTraces is always 0x6. This means that the patch will drop all packets whose third byte is 0x1. My guess is that this is a temporary fix from Microsoft. EAX will set to 0 at 67480B46 and jump to 67480BE4. At 67480B46 the program will increase EAX by 1 before return and in this way sanitize the input before calling the function that crashed earlier.
The Host Integration Server will crash when a remote attacker sends 5 bytes of malicious UDP packet. There are also other vulnerabilities fixed by MS11-082 which are not analyzed in this article. We recommend customers to scan their environment for QID 90748 and apply this security update as soon as possible.
