5

According to the OpenSSL project the version in use on a server we control is not vulnerable: 0.9.8o. According to OpenVPN v 2.1.3 is also not vulnerable (also in use). These are running on Debian Squeeze (6) and are repo packages.

However, when using two web based tools and the Python PoC code, this site reports as vulnerable on all three.

Are these tools (SSLLabs, filippo.io/Heartbleed, and the python PoC) to be trusted? Can someone give me an idea of their reliability and possibility for false positive?

I use SSLLabs often for different purposes and it is historically quite reliable.

Output from the Python PoC:

     ptdeb ~/scripts/heartbleed # ./heartbleed.py REDACTED-DOMAIN.com
    Connecting...
    Sending Client Hello...
    Waiting for Server Hello...
     ... received message: type = 22, ver = 0302, length = 86
     ... received message: type = 22, ver = 0302, length = 1040
     ... received message: type = 22, ver = 0302, length = 4
    Sending heartbeat request...
     ... received message: type = 24, ver = 0302, length = 16384
    Received heartbeat response:
      0000: 02 40 00 D8 03 02 53 43 5B 90 9D 9B 72 0B BC 0C  [email protected][...r...
      0010: BC 2B 92 A8 48 97 CF BD 39 04 CC 16 0A 85 03 90  .+..H...9.......
      0020: 9F 77 04 33 D4 DE 00 00 66 C0 14 C0 0A C0 22 C0  .w.3....f.....".
      0030: 21 00 39 00 38 00 88 00 87 C0 0F C0 05 00 35 00  !.9.8.........5.
      0040: 84 C0 12 C0 08 C0 1C C0 1B 00 16 00 13 C0 0D C0  ................
      0050: 03 00 0A C0 13 C0 09 C0 1F C0 1E 00 33 00 32 00  ............3.2.
      0060: 9A 00 99 00 45 00 44 C0 0E C0 04 00 2F 00 96 00  ....E.D...../...
      0070: 41 C0 11 C0 07 C0 0C C0 02 00 05 00 04 00 15 00  A...............
      0080: 12 00 09 00 14 00 11 00 08 00 06 00 03 00 FF 01  ................
      0090: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00  ..I...........4.
      00a0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00  2...............
      00b0: 0A 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00  ................
      00c0: 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0F 00  ................
      00d0: 10 00 11 00 23 00 00 00 0F 00 01 01 57 36 34 29  ....#.......W64)
      00e0: 20 41 70 70 6C 65 57 65 62 4B 69 74 2F 35 33 37   AppleWebKit/537
      00f0: 2E 33 36 20 28 4B 48 54 4D 4C 2C 20 6C 69 6B 65  .36 (KHTML, like
      0100: 20 47 65 63 6B 6F 29 20 43 68 72 6F 6D 65 2F 33   Gecko) Chrome/3
      0110: 33 2E 30 2E 31 37 35 30 2E 31 35 34 20 53 61 66  3.0.1750.154 Saf
      0120: 61 72 69 2F 35 33 37 2E 33 36 0D 0A 52 65 66 65  ari/537.36..Refe
      0130: 72 65 72 3A 20 68 74 74 70 73 3A 2F 2F 35 34 2E  rer: https://x.
      0140:                                                  x.x.x/admi
      0150: 6E 2F 75 73 65 72 5F 70 65 72 6D 69 73 73 69 6F  n/user_permissio
      0160: 6E 73 0D 0A 41 63 63 65 70 74 2D 45 6E 63 6F 64  ns..Accept-Encod
      0170: 69 6E 67 3A 20 67 7A 69 70 2C 64 65 66 6C 61 74  ing: gzip,deflat
      0180: 65 2C 73 64 63 68 0D 0A 41 63 63 65 70 74 2D 4C  e,sdch..Accept-L
      0190: 61 6E 67 75 61 67 65 3A 20 65 6E 2D 55 53 2C 65  anguage: en-US,e
      01a0: 6E 3B 71 3D 30 2E 38 0D 0A 43 6F 6F 6B 69 65 3A  n;q=0.8..Cookie:
      01b0: 20 6F 70 65 6E 76 70 6E 5F 73 65 73 73 5F 36 30   openvpn_sess_60
      01c0: 39 36 32 63 39 32 66 61 63 35 35 36 34 39 61 33  962c92fac55649a3
      01d0: 62 36 32 32 39 35 65 61 63 66 32 64 63 35 3D 62  b62295eacf2dc5=b
      01e0: 38 65 66 39 33 65 66 65 62 39 38 32 63 31 35 34  8ef93efeb982c154
      01f0: 65 30 33 36 30 65 37 65 35 66 30 32 66 38 30 3B  e0360e7e5f02f80;
      0200: 20 6F 70 65 6E 76 70 6E 5F 73 65 73 73 5F 38 36   openvpn_sess_86
      0210: 65 38 33 34 64 37 30 38 34 38 35 34 30 34 62 39  e834d708485404b9
      0220: 31 64 32 66 61 38 39 31 64 36 31 30 38 38 3D 35  1d2fa891d61088=5
      0230: 61 30 66 33 38 61 30 65 32 39 62 61 66 35 66 31  a0f38a0e29baf5f1
      0240: 36 32 33 39 30 35 33 31 36 34 61 66 38 33 38 3B  6239053164af838;
      0250: 20 6F 70 65 6E 76 70 6E 5F 73 65 73 73 5F 30 38   openvpn_sess_08
      0260: 64 62 34 38 65 63 32 33 65 30 34 65 35 38 36 37  db48ec23e04e5867
      0270: 33 35 66 34 61 32 34 38 35 66 62 31 39 38 3D 35  35f4a2485fb198=5
      0280: 38 33 62 62 63 33 36 38 61 65 35 35 36 65 30 66  83bbc368ae556e0f
      0290: 35 61 32 39 63 31 64 61 30 66 63 62 64 65 37 0D  5a29c1da0fcbde7.
      02a0: 0A 0D 0A 2A F3 EF 73 12 99 DB B9 B3 1C 6B 2E B7  ...*..s......k..
      02b0: 90 42 58 00 00 00 00 00 90 03 68 00 00 00 00 00  .BX.......h.....
      02c0: 90 03 68 00 00 00 00 00 90 03 68 00 00 00 00 00  ..h.......h.....
      02d0: 90 03 68 00 00 00 00 00 90 03 68 00 00 00 00 00  ..h.......h.....
      02e0: 90 03 68 00 00 00 00 00 90 03 68 00 00 00 00 00  ..h.......h.....
      ...
      3fe0: 90 03 68 00 00 00 00 00 90 03 68 00 00 00 00 00  ..h.......h.....
      3ff0: 90 03 68 00 00 00 00 00 90 03 68 00 00 00 00 00  ..h.......h.....

    WARNING: server returned more data than it should - server is vulnerable!
1
  • Of the tools you listed, I would trust Qualys SSL Labs or the python PoC. Qualys because of their reputation and incentives and the python PoC because of its auditability.
    – freb
    Apr 14, 2014 at 20:10

4 Answers 4

4

All of the answers to this question helped me. What confused me was that the library name of OpenSSL isn't actually the real version number. OpenVPN has its own statically linked OpenSSL library and the name of the library was libssl.so.1.0.0. It turns out this library executable isn't actually version 1.0.0, is vulnerable, and needed to be upgraded.

See: http://nginx.com/blog/nginx-and-the-heartbleed-vulnerability/

To find the version number of the OpenSSL library, you have to run 'strings' on the binary. Following is my output before upgrading OpenVPN:

# strings /usr/local/openvpn_as/lib/libssl.so.1.0.0 | grep OpenSSL
OpenSSLDie
SSLv2 part of OpenSSL 1.0.1c 10 May 2012
SSLv3 part of OpenSSL 1.0.1c 10 May 2012
TLSv1 part of OpenSSL 1.0.1c 10 May 2012
DTLSv1 part of OpenSSL 1.0.1c 10 May 2012
OpenSSL 1.0.1c 10 May 2012

After upgrading OpenVPN, the output was as follows:

# strings /usr/local/openvpn_as/lib/libssl.so.1.0.0 | grep OpenSSL
OpenSSLDie
SSLv2 part of OpenSSL 1.0.1g 7 Apr 2014
SSLv3 part of OpenSSL 1.0.1g 7 Apr 2014
TLSv1 part of OpenSSL 1.0.1g 7 Apr 2014
DTLSv1 part of OpenSSL 1.0.1g 7 Apr 2014
OpenSSL 1.0.1g 7 Apr 2014

You can clearly see that OpenSSL was upgrade from 1.0.1c to 1.0.1.g.

Kudos to @ser3484698 for links to the patched versions of OpenVPN and pointing out the OpenVPN statically linked libraries.

1
  • Awesome, @freb. This is the answer I was looking for. Thanks for all the responses, however, they were all helpful.
    – eficker
    Apr 14, 2014 at 20:05
2

You can have several versions of OpenSSL in various places on your system, in additional to possible statically compiled code.

Perhaps pull up another couple client-based tools from my answer here - in particular, perhaps one of the "go" language based ones, and see if they also agree, since you've already used a python one.

To verify, however, open up a hex editor that can read server memory and search for what your tester is returning (as one example, HxD can do this on windows). If you can run a few tests, get different chunks of result data, and then match that result data to the contents of the target server's memory, then you've got some very good evidence to bring up for others to review at your company.

3
  • 4
    Also try: sudo cat /proc/<serverpid>/maps and look at the path to the version of libcrypto.so being linked in dynamically by the server process. Apr 10, 2014 at 4:47
  • If a tool reports a script as vulnerable and returns a lot of data, then it is vulnerable. Whether it is written in Python or Go does not matter. In case of doubt, open a packet sniffer such as Wireshark. The latest development version has an Expert info filter for malformed heartbeats.
    – Lekensteyn
    Apr 14, 2014 at 13:27
  • Tools can have errors and bugs; several of the ones I saw as of the date the answer was written simply give a line of text as a result, and often that line was a cryptic error. If the script returns a lot of data and says it was from the target, well, that's why the original question was asking about false positives; perhaps the testing tool is mistaken. I recommended tools from different languages because in looking at them, I found 3 python tools, and each was a fork/copy of the others; thus, if there's a flaw in the root code, perhaps all 3 have it. A tool in go would be less likely to. Apr 15, 2014 at 6:12
2

Your Webserver (heartbleed.py tests https on port 443) seem to be affected, but it doesn't tells you weather OpenVPN is affected or not. (as Anti-weakpasswords already stated, you could have multiple OpenSSL libraries or static linked libraries on your system).

To test your OpenVPN, I wrote a similar Python script which explicitly talks to OpenVPN to test for vulnerability:

2

The SSL library in OpenVPN is vulnerable the following 2 files in /usr/local/openvpn_as/lib/ eg: libssl.so.1.0.0 and libcrypto.so.1.0.0

download one of the following versions for your distro at https://openvpn.net/index.php/access-server/download-openvpn-as-sw.html

that should solve your problem.

Remember to backup you config files.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .