[Snort-sigs] LDAPv3 with simple authentication

Joel Esler (jesler) jesler at ...3865...
Tue Jan 31 12:35:00 EST 2017


If a service is matched in Firepower, it will use the service.  If Firepower CANNOT match a service, then it will default to ports.

However, it looks like, in your case, it matched a service. (ldap)

--
Joel Esler | Talos: Manager | jesler at ...3865... <mailto:jesler at ...3865...>






> On Jan 31, 2017, at 8:30 AM, FOULDE Damien <damien.foulde at ...4205...> wrote:
> 
> Hello Joshua,
> 
> For information the addition of the « metadata:service ldap; » directive helped a lot the rule to match.
> Even if, as far as I understand it should match the same without this directive :
> 2.7.1 Rule evaluation <>
> In rule evaluation, service information can be used instead of the ports when the metadata service(s) in the rule matches the service corresponding to the traffic. If the rule does not have metadata service(s), or the packet service was not matched then the port checks are used exclusively.
> 
> If you have information about the usage of metadata / service keywords with Sourcefire Firepower, I’m really interested.
> 
> Thank you & regards,
> 
> Damien
> 
> De : Joshua Williams [mailto:joshuwi2 at ...435... <mailto:joshuwi2 at ...3413....>]
> Envoyé : mercredi 25 janvier 2017 19:26
> À : FOULDE Damien
> Objet : Re: [Snort-sigs] LDAPv3 with simple authentication
> 
> Damien,
> 
> Thanks for your submission. I'll review and test this and get back to you when it has finished.
> 
> --
> Josh Williams
> Detection Response Team
> TALOS Security Group
> 
> On Wed, Jan 25, 2017 at 12:54 PM, FOULDE Damien <damien.foulde at ...4205... <mailto:damien.foulde at ...4205...>> wrote:
> Hello,
> 
> I finally wrote two working rules through a full decoding of the LDAP BER data :
> alert tcp any any -> any 389 (sid:1000000; gid:1; flow:established,to_server; content:"|30|"; depth:1; byte_test:1,=,0,0,relative,bitmask 0x80; content:"|02|"; distance:1; within:1; byte_test:1,=,0,0,relative,bitmask 0x80; byte_jump:1,0,relative,bitmask 0x7f; content:"|60|"; distance:0; within:1; byte_test:1,=,0,0,relative,bitmask 0x80; content:"|02 01 03 04|"; fast_pattern; distance:1; within:4; byte_test:1,=,0,0,relative,bitmask 0x80; byte_jump:1,0,relative,bitmask 0x7f; content:"|80|"; distance:0; within:1; msg:"LDAPv3 simple Authentication SSSS"; classtype:policy-violation; rev:1;)
> 
> alert tcp any any -> any 389 (sid:1000001; gid:1; flow:established,to_server; content:"|30|"; depth:1; byte_test:1,=,1,0,relative,bitmask 0x80; byte_jump:1,0,relative,bitmask 0x7f; content:"|02|"; distance:0; within:1; byte_test:1,=,0,0,relative,bitmask 0x80; byte_jump:1,0,relative,bitmask 0x7f; content:"|60|"; distance:0; within:1; byte_test:1,=,1,0,relative,bitmask 0x80; byte_jump:1,0,relative,bitmask 0x7f; content:"|02 01 03 04|"; fast_pattern; distance:0; within:4; byte_test:1,=,0,0,relative,bitmask 0x80; byte_jump:1,0,relative,bitmask 0x7f; content:"|80|"; distance:0; within:1; msg:"LDAPv3 simple Authentication LSLS"; classtype:policy-violation; rev:1;)
> 
> I’ve some difficulties to write other ones as I just noticed that a value extracted through “byte_extract” can only be supplied to the “offset” argument of the “byte_jump” rule keyword and not to the “bytes_to_convert” argument.
> 
> For example I have these bytes and I need to check the 0x80 byte :
> 82 00 05 12 24 56 78 12 80
> 0x82 = 10000010
> The MSB is set to 1, so the value of the 7 other bits is not the length of the data but the number of bytes used to describe the length of the data, in this example, the number of bytes to describe the length of the data is 0000010 = 2
> We can get this value through “byte_extract:1,0,var_length,relative,bitmask 0x7f;”.
> Then we would need to get the “00 05” = 5 value, to jump over the 5 following bytes : “12 24 56 78 12” and finally test the 0x80 content we need to check.
> This could be achieved through “byte_jump:long_length,0,relative;” if the “byte_jump” rule keyword would accept an extracted value for the “bytes_to_convert” argument, unfortunately this is not the case.
> How should we proceed ?
> Any help would be really appreciated.
> 
> If someone from Talos could take some time to review the simpler rule provided previously it would be great.
> I think that detecting / blocking all LDAP simple authentication, with cleartext password over the network, could benefit to everyone security.
> 
> Thank you & regards,
> 
> Damien
> 
> De : FOULDE Damien [mailto:damien.foulde at ...4205... <mailto:damien.foulde at ...4205...>]
> Envoyé : mercredi 4 janvier 2017 17:36
> À : snort-sigs at lists.sourceforge.net <mailto:snort-sigs at ...639...forge.net>
> Objet : Re: [Snort-sigs] LDAPv3 with simple authentication
> 
> Hello,
> 
> You’ll find a packet capture attached to this email.
> It would be really great if the signature provided previously could be reviewed.
> 
> Thank you & regards,
> 
> Damien
> 
> De : FOULDE Damien [mailto:damien.foulde at ...4205... <mailto:damien.foulde at ...4205...>]
> Envoyé : jeudi 29 décembre 2016 16:37
> À : snort-sigs at lists.sourceforge.net <mailto:snort-sigs at ...639...forge.net>
> Objet : Re: [Snort-sigs] LDAPv3 with simple authentication
> 
> Hello,
> 
> The previous message is currently waiting for a moderator approval.
> As it’s not released for the moment, I registered to the maillinglist and here it is.
> 
> Regards,
> 
> Damien
> 
> De : FOULDE Damien
> Envoyé : mercredi 21 décembre 2016 10:51
> À : snort-sigs at lists.sourceforge.net <mailto:snort-sigs at ...639...forge.net>
> Objet : RE: LDAPv3 with simple authentication
> 
> Hello,
> 
> Any ideas / suggestions / advices will be greatly appreciated regarding this question.
> 
> In the meantime, here’s a working signature without fully decoding the BER data :
> alert tcp any any -> any 389 (sid:1000000; gid:1; flow:established,to_server; content:"|30|"; depth:1; content:"|02|"; distance:1; within:127; content:"|60|"; distance:1; within:5; content:"|02 01 03 04|"; fast_pattern; distance:1; within:127; content:"|80|"; distance:1; within:127; content:!"|02 01 03 04 00 a3|"; offset:7; depth:257; msg:"LDAPv3 simple Authentication"; classtype:policy-violation; rev:1; )
> 
> It would be great if it could be reviewed by Talos.
> I can provide a packet capture if needed.
> 
> Regards,
> 
> Damien
> 
> De : FOULDE Damien [mailto:damien.foulde at ...4205... <mailto:damien.foulde at ...4205...>]
> Envoyé : lundi 19 décembre 2016 12:39
> À : snort-sigs at lists.sourceforge.net <mailto:snort-sigs at ...639...forge.net>
> Objet : [Snort-sigs] LDAPv3 with simple authentication
> 
> Hello,
> 
> We need to write a signature to match on LDAPv3 with simple authentication.
> LDAPv3 is described in the RFC 2251 through Abstract Syntax Notation 1 (ASN.1) and encoded through a subset of Basic Encoding Rules (BER) in the packets.
> You may have a look to this great website http://www.selfadsi.org/ldap.htm#Frame <http://www.selfadsi.org/ldap.htm#Frame> to have a quick look over the encoding.
> https://en.wikipedia.org/wiki/X.690#BER_encoding <https://en.wikipedia.org/wiki/X.690#BER_encoding> is also a good source of information.
> As you should have seen the length can be encoded in a short or long form.
> When the short form is used the MSB is set to 0 and the 7 remaining bits are used to encode the length directly from 0 to 127.
> Using the byte_jump function we should be able to jump to the next encoded data.
> When the long form is used the MSB is set to 1 and the 7 remaining bits are used to encode the number of bytes that follow from 1 to 126 which will contains the actual length.
> Using byte_extract and byte_jump functions with bitmask we should be able to jump to the next encoded data.
> Before reaching the point where the LDAPv3 authentication is set to simple (encoded to 0) or sasl (encoded to 3) there’re 5 short or long length bytes.
> Is there a way through the subset of snort packet dissection functions to match on this without writing 32 (2^5) different signatures to match all short / long possibilities ?
> The BER encoding is also used to encode SNMP, the same kind of issue may have been seen there also.
> 
> Thank you for your help,
> 
> Damien
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot <http://sdm.link/slashdot>
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net <mailto:Snort-sigs at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/snort-sigs <https://lists.sourceforge.net/lists/listinfo/snort-sigs>
> 
> http://www.snort.org <http://www.snort.org/>
> 
> Please visit http://blog.snort.org <http://blog.snort.org/> for the latest news about Snort!
> 
> Visit the Snort.org to subscribe to the official Snort ruleset, make sure to stay up to date to catch the most <a href=" https://snort.org/downloads/#rule-downloads <https://snort.org/downloads/#rule-downloads>">emerging threats</a>!
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org <http://slashdot.org/>! http://sdm.link/slashdot_______________________________________________ <http://sdm.link/slashdot_______________________________________________>
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net <mailto:Snort-sigs at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/snort-sigs <https://lists.sourceforge.net/lists/listinfo/snort-sigs>
> 
> http://www.snort.org <http://www.snort.org/>
> 
> Please visit http://blog.snort.org <http://blog.snort.org/> for the latest news about Snort!
> 
> Visit the Snort.org <http://snort.org/> to subscribe to the official Snort ruleset, make sure to stay up to date to catch the most <a href=" https://snort.org/downloads/#rule-downloads <https://snort.org/downloads/#rule-downloads>">emerging threats</a>!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20170131/2d330e3b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20170131/2d330e3b/attachment.sig>


More information about the Snort-sigs mailing list