OSSEC remote protocol uses weak cryptography

[tomrittervg]

NCC Group Security Advisory - 2015-07-OSSEC

https://www.nccgroup.trust

OSSEC remote protocol uses weak cryptography

Vendor: Trend Micro Vendor URL: http://www.ossec.net/ Versions affected: All versions up to and including 2.8 Systems Affected: The ossec-remoted component in agent-server configurations Severity: Low (Confidentiality bypasses) Author: NCC Group

Details:

The OSSEC HIDS can be configured to run in an agent-server architecture, where agents forward log messages to a server via various protocols, including the ossec-remoted protocol, which uses encryption and runs over UDP port 514. The remoted server decrypts the log with a client-specific key using Blowfish in CBC mode1. However, the protocol uses a static initialization vector (IV)2 to encrypt and decrypt all messages.

Because the IV is reused for each message, an attacker can determine when message content is similar, and therefore discern what kind of log messages are being forwarded.

In addition, it does not authenticate the message; while it uses an MD5 hash as an internal checksum3, this is not a strong authenticator. The lack of authentication may allow message tampering, due to CBC mode encryption malleability.

Due to the use of a checksum and compression, message tampering would be difficult; however, the use of zlib compression combined with partial message disclosure (from the use of CBC mode) could lead to a decryption oracle via compression errors or timing leakage.

Fix Information:

When using block cipher encryption modes that use an IV, generate a unique and securely random IV for each message and transmit it along with the ciphertext.

The use of CBC mode Blowfish should be replaced with an authenticated encryption (AE) cipher, such as (Galois/Counter Mode) GCM. For more information see the following whitepaper: https://www.nccgroup.trust/globalassets/newsroom/us/blog/documents/2013/introduction_to_authenticated_encryption.pdf

Replace the use of Blowfish with AES, which provides more robust security and benefits from hardware acceleration on some platforms.

Vendor Communication:

2015-06-19 - Primary OSSEC committer notified via email 2015-06-29 - Follow-up email after no response 2015-06-29 - Receipt confirmed 2015-07-29 - Follow-up email 2015-08-24 - Follow-up email, request preparing issue for public release 2015-08-24 - Recieved response, included other project members to chain 2015-10-27 - Indicate to OSSEC we will be preparing issue for public release 2015-11-25 - Recieve response indicating no fix is currently in the works. OSSEC agrees issue should not be withheld from public. 2015-12-08 - Deliver unredacted report to FPF for publication 2015-12-11 - Public release

Thanks to:

Tim Newsham, Raphael Salas, Sean Devlin, Tom Ritter

About NCC Group:

NCC Group is a full-service security consulting firm that provides penetration testing, secure systems development, security education and software design verification, with offices in San Francisco, Sunnyvale, Seattle, Austin, Chicago, and New York.

https://www.nccgroup.trust/us/

[dcid]

That's not fully correct.

1- We don't use an IV, but the first bytes from the message are random. That has the same effect as using an IV.

   rand1 = (u_int16_t)random();
   .. 
   snprintf(_tmpmsg, OS_MAXSTR,"%05hu%010u:%04hu:%s",
                              rand1,

2- We have message counters, which also prevent someone from guessing if the messages are similar. That + the random initializer, gives enough variability per message.

3- MD5 is used to verify the integrity of the message, not for authentication.

I agree that it is probably time to change to AES (code was written 15 years ago when blowfish was cool), but can't see any practical attacks coming out of it.

Thanks,

Daniel B. Cid (yes, I wrote that code :) )

[gmichelo]

Hi there, what about of using SSL/TLS with client authentication to secure the communication between clients and servers? Now the pre-shared keys are directly stored in memory on both sides and that could be dangerous since they can be retrieved. I also believe that it should ease the deployment phase, since with SSL/TLS there's no need to generate and manage the keys, but only to create a self-signed certificate with public and private keys.

What do you think? Is it worth it?

Giulio

[davidszabo26]

Hello everyone, I though I’d send an update on this thread. We’re Virgil Security, the tech behind Twilio’s End-to-End Encrypted Messaging and we recently announced at OSSEC Conf that we’ll soon release a security-updated OSSEC version that’s using the NoiseSocket Protocol, developed by Alexey Ermishkin and Trevor Perrin using the same tech behind the messaging app Signal. This release makes OSSEC End-to-End Encrypted with Perfect Forward Secrecy to keep your log data safe and enterprise servers compliant with GDPR and HIPAA standards.

Please send me an email if you’re interested to join the close Beta program and be among the first customers to roll out this tech. Dave at VirgilSecurity.com

https://virgilsecurity.com/ossec-encryption

[hex2a]

@davidszabo26 could you share some insight/reasons behind using NoiseSocket? since from my understanding End-to-End in this context should mean ossec agent <--> ossec-manager, a proper implementation of TLS would also solve this (including PFS).

[davidszabo26]

@hex2a: we chose NoiseSocket because it works without certificates, it uses modern & strong crypto by default and easier to implement. It’s also lower network footprint, which most of the OSSEC customers who we interviewed liked in their VPN-heavy data center network topologies.

If one wants to set up a Certificate Authority, build a client auth and the other reasons above don’t matter, TLS is also a good option.

Our customer interviews and design work with Atomicorp led us to the conclusion that NoiseSocket is the best choice for OSSEC customers.

[the6thBook]

So versions above 2.8 have NoiseSocket?

[cpu]

@the6thBook no - main and all released versions of OSSEC from this repo continue to use weak cryptography. The original report is as accurate now as it was in 2015.