h323-message-body values

Reply
L1 Bithead

h323-message-body values

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:

Screenshot 2015-11-26 16.21.20.png

 

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

 

Thanks,

Will

L2 Linker

Re: h323-message-body values

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.
L1 Bithead

Re: h323-message-body values

Hello murphj,

 

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

 

Thanks,

Will

L4 Transporter

Re: h323-message-body values

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?

L1 Bithead

Re: h323-message-body values

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

L4 Transporter

Re: h323-message-body values

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?

L1 Bithead

Re: h323-message-body values


@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

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!