Last updated at Fri, 22 Sep 2017 19:35:00 GMT
For my inaugural post on the SecurityStreet blog, I thought it would be beneficial to highlight the H.323 coverage I recently added to Nexpose. With all the attention HD Moore's work in this area garnered, it seemed that there was a definite need for this functionality, so as of Nexpose 5.2, users can scan their networks for devices running H.323 services as well as detect whether those services have the auto-answer functionality enabled.
Discovering H.323 Devices
There are many ways to detect whether a service running on a port is in fact H.323. The trick is doing so in a non-disruptive way. You can, like many other vulnerability scanners out there (who shall remain nameless), send a “Call Setup” message to the device and see how it responds. This is a very disruptive approach however, as it can potentially cause the device to alert its users by popping up an alert message or, in some cases, even audibly ring. The method I use elicits a valid H.323 response from the endpoint without trying to actually set up a call. I found that sending a “Status Enquiry” message to an H.323 service, which is used to detect the status of existing calls, will get a “Status Enquiry Response” regardless of whether a call actually exists. In this way, I can tell if an H.323 service is running without calling the endpoint, thereby avoiding all the figurative and literal noise that other scanners create. Also, by actually parsing responses instead of just looking at a byte or two, I can tell with certainty that a device is in fact running an H.323 service.
Detecting Auto-Answer Functionality
I also added a vulnerability check to detect whether an H.323 device has “auto-answer” enabled. For the reasons I pointed out above, this check is intrusive because, unlike the device fingerprinter, it attempts to actually set up a call with an endpoint. It then recursively reads and parses responses from the device, looking for indications of a successful or unsuccessful call completion. Endpoints can respond in many different ways to an attempt to set up a call. The most popular initial response to a “Call Setup” message is an “Alerting” message. Think of this as the sound you hear when you make a phone call and are waiting for the other person to answer. You can get several “Alerting” messages before the endpoint finally answers, so recursively reading responses is very important. And this is only one possible call-flow scenario, which is why actually parsing responses is also very important. Our H.323 scanner recognizes many different types of responses and changes its behavior based on the response it receives, so it can handle whatever an H.323 endpoint is configured to do. With some scanners I tested, they failed to even register a device as an H.323 endpoint at all if it didn't follow their shallowly defined detection scheme, let alone being able to place a call to the point of completion necessary to detect the auto-answer vulnerability.
Conclusion
The H.323 protocol is extremely complex and convoluted, and the way it is implemented can vary wildly from vendor to vendor. When scanning a network for devices running this service, especially with regard to vulnerable implementations, it is important to use a scanner that deeply understands the protocol. Otherwise, your results could be inaccurate and even disruptive. Luckily, you have us.
