[Snort-sigs] [SID 36903, 37674] invalid offset value of content option (jungun.baek)

Alex McDonnell amcdonnell at sourcefire.com
Tue Feb 6 12:12:22 EST 2018


Unless I'm misreading, the rfc specifies 16 bytes in the header,

the IKE_SA initiator's SPI and the responder's SPI, which are both 8 bytes.

Looking at the figure describing the structure below we see that:

                     1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                       IKE_SA Initiator's SPI                  !
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                       IKE_SA Responder's SPI                  !
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !  Next Payload ! MjVer ! MnVer ! Exchange Type !     Flags     !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                          Message ID                           !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                            Length                             !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 4:  IKE Header Format

      o  Initiator's SPI (8 octets) - A value chosen by the
         initiator to identify a unique IKE security association.  This
         value MUST NOT be zero.

      o  Responder's SPI (8 octets) - A value chosen by the
         responder to identify a unique IKE security association.  This
         value MUST be zero in the first message of an IKE Initial
         Exchange (including repeats of that message including a
         cookie) and MUST NOT be zero in any other message.

      o  Next Payload (1 octet) - Indicates the type of payload that
         immediately follows the header.  The format and value of each
         payload are defined below.


On Tue, Feb 6, 2018 at 12:00 PM, <snort-sigs-request at lists.snort.org> wrote:

> Send Snort-sigs mailing list submissions to
>         snort-sigs at lists.snort.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.snort.org/mailman/listinfo/snort-sigs
> or, via email, send a message with subject or body 'help' to
>         snort-sigs-request at lists.snort.org
>
> You can reach the person managing the list at
>         snort-sigs-owner at lists.snort.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Snort-sigs digest..."
>
>
> Today's Topics:
>
>    1. [SID 36903, 37674] invalid offset value of content option
>       (jungun.baek)
>    2. Snort Subscriber Rules Update 2018-02-06 (Research)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 6 Feb 2018 14:54:17 +0900
> From: "jungun.baek" <jungun.baek at axgate.com>
> To: snort-sigs at lists.snort.org
> Subject: [Snort-sigs] [SID 36903, 37674] invalid offset value of
>         content option
> Message-ID: <C0FF97BA-49BF-4D8C-9034-E75787791308 at axgate.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Dear Snort-Team,
>
> I had discovered something wrong in the rules, so I want to know if I am
> misunderstanding.
>
> alert udp $EXTERNAL_NET any -> $HOME_NET 500 (msg:"SERVER-OTHER Cisco ASA
> IKEv2 invalid fragment length heap buffer overflow attempt";
> flow:to_server; content:"|84 20|"; depth:2; offset:16;
> byte_test:2,<,8,12,relative; metadata:policy balanced-ips drop, policy
> security-ips drop; reference:cve,2016-1287; reference:url,tools.cisco.com/
> security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike <
> http://tools.cisco.com/security/center/content/
> CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike>;
> classtype:attempted-admin; sid:36903; rev:2;)
> alert udp $EXTERNAL_NET any -> $HOME_NET 500 (msg:"SERVER-OTHER Cisco ASA
> IKEv1 invalid fragment length heap buffer overflow attempt";
> flow:to_server; content:"|84 10|"; depth:2; offset:16;
> byte_test:2,<,8,12,relative; metadata:policy balanced-ips drop, policy
> security-ips drop; reference:cve,2016-1287; reference:url,tools.cisco.com/
> security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike <
> http://tools.cisco.com/security/center/content/
> CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike>;
> classtype:attempted-admin; sid:37674; rev:1;)
>
> In the above two rules, content option seems to check "Next payload",
> "MjVer", "MnVer" of IKE header. According to section "3.1 The IKE Header"
> of RFC4306, Next Playload field was located offset 8. I wonder why the
> offset of the content option is 16.
>
> RFC4306 : https://tools.ietf.org/html/rfc4306#page-41 <
> https://tools.ietf.org/html/rfc4306#page-41>
>
> Best regards,
> Eric Baek
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.snort.org/pipermail/snort-sigs/
> attachments/20180206/aef3b8e5/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 6 Feb 2018 14:03:34 GMT
> From: Research <research at sourcefire.com>
> To: snort-sigs at lists.snort.org
> Subject: [Snort-sigs] Snort Subscriber Rules Update 2018-02-06
> Message-ID: <201802061403.w16E3Yeb000702 at rcdn-core-1.cisco.com>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Talos Snort Subscriber Rules Update
>
> Synopsis:
> This release adds and modifies rules in several categories.
>
> Details:
> Talos has added and modified multiple rules in the file-image,
> file-other, file-pdf, malware-backdoor, malware-cnc, policy-other and
> server-webapp rule sets to provide coverage for emerging threats from
> these technologies.
>
>
> For a complete list of new and modified rules please see:
>
> https://www.snort.org/advisories
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBAgAGBQJaebW1AAoJEPE/nha8pb+tW30P/1kPaCJMDnyolXdkSdhGEAWB
> /tnt0yi7aKhHLh4p/3dyP6bcRx7GXuCeiwDSnvQpEQcJ2hLtnZNN0uMZAhPzxWBC
> GZucqqyXUIShcP4o4XJbF0TyYDSej9/WoaHcZmdWABIohPcF1IdKsFa/71xTVgY9
> Xj7wMzbfksQapfYn1a/6p9vEWMQWVuJRkV7Bjsdn5RHUT8kYM9eagJLg01psYIk6
> dX1XUT6yJRSfVRclxAYTMIcP+5fxXOSbsFmQ3y3+Ru8iinvo3syfOZ9q3iZGiNi7
> KnWxmR03jB5Pzr7JH3xIdqU33cJemrhWFlS8PKqhvcqjUp95qIlBih0K2JKlB5sz
> f/4d4OYbBdORtOLZlBYWjSD1f1UERD7KdhttxI+9pl7JKYJAMqKG5e8Tgx/kDh4f
> RNSwpT0F4ZV6XM0e1usmHfPP97hfr1UYAge+RTnG7kX7n83V6R8xxFRGDJz7Ti5K
> GsXKYiyeBvVMSC4A76ttummrczFLlPrgl9GtbcEaDdst2gFvUz9dhUDiIfeVdQ7T
> qqBJae6sdjQ6khNimZ2ZQzjb5cMyda7Uy6x5JYhQecGhRvSPzM0tLah5RFnir1Nr
> vSYuUmYxanYv4Y2Zn3ku2OHWfRXOgzFqsZTGr3dZNfNq4BcFpxDzsX1NG7C79SLr
> g66/SRgMfDNO5UOQDPV5
> =kBHe
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs at lists.snort.org
> https://lists.snort.org/mailman/listinfo/snort-sigs
> http://www.snort.org
>
> Please follow these rules: https://snort.org/faq/what-is-
> the-mailing-list-etiquette
>
> Please visit http://blog.snort.org for the latest news about Snort!
>
>
> ------------------------------
>
> End of Snort-sigs Digest, Vol 9, Issue 7
> ****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20180206/729bce72/attachment-0001.html>


More information about the Snort-sigs mailing list