Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

OSSEC remote protocol uses weak cryptography #714

Open
tomrittervg opened this issue Dec 11, 2015 · 7 comments
Open

OSSEC remote protocol uses weak cryptography #714

tomrittervg opened this issue Dec 11, 2015 · 7 comments

Comments

@tomrittervg
Copy link

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
Copy link

dcid commented Dec 11, 2015

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
Copy link

gmichelo commented Jun 12, 2017 •
edited

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
Copy link

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
Copy link

hex2a commented May 22, 2018

@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
Copy link

davidszabo26 commented May 22, 2018 •
edited

@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.

@Glamdring Glamdring mentioned this issue Oct 12, 2020
Open
@cpu cpu mentioned this issue May 9, 2023
Open
@the6thBook
Copy link

So versions above 2.8 have NoiseSocket?

@cpu
Copy link
Contributor

cpu commented Feb 13, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@tomrittervg @cpu @dcid @hex2a @gmichelo @davidszabo26 @the6thBook