topic h323-message-body values in Custom Signatures

h323-message-body values

Froning — Thu, 26 Nov 2015 13:25:52 GMT

We seem to have a new h.225/h.323 scanning campaign going on that disturbs meetings. The strings that seem to be the same throughout are "productId: MERA RTU" and "versionId: 4.4.0-06a".

So I've tried two different methods of catching this traffic. Custom threat signatures and custom apps with the same pattern matched, but neither work. Here's a sample custom threat signature:

<vulnerability-threat version="6.1.0">
  <entry name="42006">
    <signature>
      <standard>
        <entry name="H323 productId MERA RTU">
          <and-condition>
            <entry name="And Condition 1">
              <or-condition>
                <entry name="Or Condition 1">
                  <operator>
                    <pattern-match>
                      <pattern>\x4d45524120525455\x</pattern>
                      <context>unknown-req-tcp-payload</context>
                    </pattern-match>
                  </operator>
                </entry>
              </or-condition>
            </entry>
          </and-condition>
          <order-free>yes</order-free>
          <scope>protocol-data-unit</scope>
        </entry>
      </standard>
    </signature>
    <default-action>
      <alert/>
    </default-action>
    <threatname>H323 MERA Test 4</threatname>
    <severity>high</severity>
    <direction>client2server</direction>
    <affected-host>
      <server>yes</server>
    </affected-host>
  </entry>
</vulnerability-threat>

I've also tried matching with the versionId pattern (\x342e342e302d303661\x) or the word "MERA", both fail. Any idea how to catch this with a signature?

Here are the relevant parts of the pcap:

I've a case open with support, but our partner support can be slow...

Thanks,

Will

Re: h323-message-body values

murphyj — Thu, 26 Nov 2015 13:53:45 GMT

I just did a quick look and it looks like H323 also seems to use UDP so you might want to and the same pattern but the a udp context. I could be completely wrong though.

Re: h323-message-body values

Froning — Thu, 26 Nov 2015 14:27:19 GMT

Hello murphj,

The initial session setup is an h.225 connection on tcp/1720, which is where this value is found.

Thanks,

Will

Re: h323-message-body values

rcole — Thu, 26 Nov 2015 16:25:58 GMT

I've reviewed some of the documentation available, and I don't believe we have any exposed contexts to make signatures for h225/h323 traffic.

I don't believe attempting to match this as unknown-req-tcp-payload will work given that the traffic is likely being interpreted by the correct decoder and isn't technically "unknown."

A custom application may be possible; I have less experience here, but am willing to investigate when I return to the office on Monday. If you attach a full packet capture, I can toy around with it in my lab to see what is possible?

Re: h323-message-body values

Froning — Thu, 26 Nov 2015 17:54:16 GMT

Hello rcole,

Thanks for the reply.

This sounds about right. The PAN totally sees it as an h.225 app, and so it makes sense that it's not "unknown".

I didn't see a place to attach a file, so here's a link to dropbox: h225-fw.pcap It's not sanitized, but there's nothing you can't find out from a scan...

I tried setting up a custom app, but the signature options I saw were the same. Hopefully, you'll have more success.

Thanks,

Will

Re: h323-message-body values

rcole — Sat, 28 Nov 2015 15:00:23 GMT

Froning:

I've verified your findings, and you are correct; it appears the exposed decoder contexts for custom applications are pretty much identical to the ones used in custom vulnerability signature creation.

I'm not certain that with the currently exposed contexts we would be able to write a custom signature/app to match this traffic; if a way exists, I'm not seeing it. Can the scan be blocked by it's originating IP with a security policy?

Re: h323-message-body values

Froning — Sat, 28 Nov 2015 16:33:00 GMT

@rcole wrote:

I'm not certain that with the currently exposed contexts we would be able to write a custom signature/app to match this traffic; if a way exists, I'm not seeing it. Can the scan be blocked by it's originating IP with a security policy?

At this point we've seen 230+ unique IPs with 10-15 new ones each day, so unfortunately blocking based on source IP isn't going to work. I have the pattern identified, which means I can put something together, but the PAN is supposed to make my life easy.

I appreciate you looking into this for me. I asked my partner support team to escalate the ticket to PAN, so hopefully we get something from them.

Thanks,

Will