Filebeat Vulenerability - Logjam attack

Hi ,
Background - ELK 2,3, Shield 2.x, Filebeat latest stable.

Configuration done -
We are trying to configure Filebeat with TLS V1.2
Filebeat sending data to logstash , so logstash output is configured.
For that we configured min and max version to 1.2 along with all the required certificates, root,int. certs and client cert key file. Our CA cert is having 2048 bit encryption

Problem -
We are getting vulnerability in VA as follows -

low] [5044/tcp/unknown] SSL/TLS Diffie-Hellman Modulus <= 1024 Bits (LogJam)
Vulnerable connection combinations : SSL/TLS version : TLSv1.1 Cipher suite : TLS1_CK_DHE_RSA_WITH_AES_128_CBC_SHA Diffie-Hellman MODP size (bits) : 1024 Warning - This is a known static Oakley Group2 modulus. This may make the remote host more vulnerable to the Logjam attack. Logjam attack difficulty : Hard (would require nation-state resources) SSL/TLS version : TLSv1.1 Cipher suite : TLS1_CK_DHE_RSA_WITH_AES_256_CBC_SHA Diffie-Hellman MODP size (bits) : 1024 Warning - This is a known static Oakley Group2 modulus. This may make the remote host more vulnerable to the Logjam attack. Logjam attack difficulty : Hard (would require nation-state resou

What will be the solution to resolve this.

Interesting. Can you share you filebeat output configuration? Which tool are you using for the analysis? You have a trace of SSL/TLS handshake we can have a look at?

Which JVM are you running logstash with? Exact filebeat version in use (1.2.3?) ?

The TLS version used is somewhat limited by JVM in use. Logstash with Java 7 VM might only support TLS 1.1, not 1.2.

Unfortunately one can not configure the cipher suites in use with logstash, but beats provides some supports cipher_suites setting.

According to (See Paper and Recommendations), one should prefer eliptic curve based DH and use a 'strong DH group'.

go already uses elliptic curve Diffie-Hellman (ECDH suites), but no idea about JVM here. The cipher suite mentioned TLS1_CK_DHE_RSA_WITH_AES_128_CBC_SHA is not even defined in go or beats. I guess it's coming from JVM libs.

Thanks for the responce -
Here is the filebeat configuration

    # The Logstash hosts
    hosts: [""]

    # Number of workers per Logstash host.
    #worker: 1

    # Set gzip compression level.
    #compression_level: 3

    # Optional load balance the events between the Logstash hosts
    #loadbalance: true

    # Optional index name. The default index name depends on the each beat.
    # For Packetbeat, the default is set to packetbeat, for Topbeat
    # top topbeat and for Filebeat to filebeat.
    #index: filebeat
    bulk_max_size: 1024
    # Optional TLS. By default is off.
      # List of root certificates for HTTPS server verifications
      certificate_authorities: ["/etc/pki/tls/certs/chain.crt"]

      # Certificate for TLS client authentication
      certificate: "/etc/pki/tls/certnew.pem"

      # Client Certificate Key
      certificate_key: "/etc/pki/tls/private/irldxvm081.key"
      min_version: 1.2
      max_version: 1.2
      # Controls whether the client verifies server certificates and host name.
      # If insecure is set to true, all server host names and certificates will be
      # accepted. In this mode TLS based connections are susceptible to
      # man-in-the-middle attacks. Use only for testing.
      #insecure: true

      # Configure cipher suites to be used for TLS connections
      cipher_suites: [ECDHE,SHA,SHA256,SHA384]

      # Configure curve types for ECDHE based cipher suites
      curve_types: [P-256]

[root@irldxvm081 conf.d]# java -version
java version "1.7.0_101"
OpenJDK Runtime Environment (rhel- u101-b00)
OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)
[root@irldxvm081 conf.d]# filebeat -version
filebeat version 1.2.3 (amd64)

    [root@irldxvm081 conf.d]# openssl s_client -connect -tls1_2
    depth=2 C = US, O = International Business Machines Corporation, CN = IBM Internal Root CA
    verify error:num=19:self signed certificate in certificate chain
    verify return:0
    140444073035592:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:
    Certificate chain
     0 s:/C=IN/ST=New Delhi/L=New Delhi/
       i:/C=US/O=International Business Machines Corporation/CN=IBM INTERNAL INTERMEDIATE CA
     1 s:/C=US/O=International Business Machines Corporation/CN=IBM INTERNAL INTERMEDIATE CA
       i:/C=US/O=International Business Machines Corporation/CN=IBM Internal Root CA
     2 s:/C=US/O=International Business Machines Corporation/CN=IBM Internal Root CA
       i:/C=US/O=International Business Machines Corporation/CN=IBM Internal Root CA
    Server certificate
    -----END CERTIFICATE-----
    subject=/C=IN/ST=New Delhi/L=New Delhi/
    issuer=/C=US/O=International Business Machines Corporation/CN=IBM INTERNAL INTERMEDIATE CA
    No client certificate CA names sent
    Server Temp Key: ECDH, secp521r1, 521 bits
    SSL handshake has read 4350 bytes and written 230 bytes
    New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
    Server public key is 2048 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
        Protocol  : TLSv1.2
        Cipher    : ECDHE-RSA-AES256-SHA
        Session-ID: 57BAF570551E8F25E87BE0D8383B2D3A7EAC93DCB4A235E36E12FD17AE6E4941
        Master-Key: 605609BB67E5832B02066A1C248B40C24D1E956EF7C77FF925525234CF4D3502317F4B46FFD544BE4971542CBA58E671
        Key-Arg   : None
        Krb5 Principal: None
        PSK identity: None
        PSK identity hint: None
        Start Time: 1471870320
        Timeout   : 7200 (sec)
        Verify return code: 19 (self signed certificate in certificate chain)

Does your filebeat config load as is? The cipher_suites config is pretty much wrong. I wonder if you have some indentation error (you only used spaces, right?). It must be one of the longer names. The openssl client for example uses ECDHE-RSA-AES-256-CBC-SHA.

I find it kinda weird the cipher suite used by openssl client being different from suite reported to be used by beats (the one reported for beats doesn't even exist in beats).

Can you capture a trace (use tcpdump) of SSL handshake? I'd like to have a look at the SSL envelope in wireshark.

Which tool exactly are you using checking for SSL vulnerabilities?

Thanks for the response. It was openjdk 7 jvm issue. I was able to fix using java 8.
In the latest scan report I do not see any vulnerabilities now.
Yes cipher suite configuration is wrong, so I have commented it now.
Am I really supposed to configure cipher suites and curve types or let it take whatever default ones.

If I configure cipher suites according to what you have mentioned , I get following error but filebeat is started -

[root@irldxvm081 opt]# /etc/init.d/filebeat restart
2016/08/23 11:47:10.488034 transport.go:125: ERR SSL client failed to connect with: EOF
Stopping filebeat:                                         [  OK  ]
Starting filebeat: 2016/08/23 11:47:10.612413 transport.go:125: ERR SSL client failed to connect with: EOF
                                                           [  OK  ]
[root@irldxvm081 opt]# /etc/init.d/filebeat status
filebeat-god (pid  28169) is running...
[root@irldxvm081 opt]#


Great it works with java 8. I think java 7 also supports TLSv1.2, but disables it by default.

Unless you've got some specific cipher requirements (use this, but make sure that one can not be used), I don't think cipher_suites and curves must be configured. One might want to configure multiple cipher_suites, as some libs might not support all.

For connections to succeed, 'connection parameters' must be supported by both sides. Most likely you the see EOF in beats, due to java 8 not supporting some parameters configured in beats (I cipher_suite, as set of allowed suites must have at least some suites in common). Due to parameters-check failing early, the connection is closed during handshake by server and we see the EOF. If you're lucky you can find some logs on server side telling you what went wrong. Unfortunately, working with SSL can be very frustrating both as user and as developer, for reasons like this. E.g. libs just closing connections, but never getting any report/logs/code telling you what actually did happen. That is, once you get it working correctly, SSL is great. But until you get it working right, it all feels super fragile :frowning:

This topic was automatically closed after 21 days. New replies are no longer allowed.