Reminder to anyone using #ApacheCamel SCP/SFTP connections: Apache Camel does not perform host identity validation unless you explicitly configure "StrictHostKeyChecking" as "yes". The default value for "StrictHostKeyChecking" is "no". If you do not explicitly configure this option as "yes", the connections are susceptible to meddler in the middle attacks.

What is the impact of such insecure configuration?

If you are using SSH password authentication, the attacker in a privileged network position can perform full MiTM, grab the username and password, and thus gain authenticated access to the target server.

If you use a key-based authentication, the attacker cannot perform full MitM. However, they can still present a fake server and, in case of upload, steal the uploaded files. In case of download, the malicious server can present fake or malicious files for download.

So, any configuration that could get intercepted MUST always specify the host identity and use "StrictHostKeyChecking" "yes". Even configurations in secured networks should use "yes" for additional security.

Unfortunately, the Apache Camel documentation isn't clear on this topic, and the OpenSSH's similar option and its default value working in a different manner can easily lead to confusion and insecure configurations.

#insecuredefaults

If you're using #GnuTLS please note that GnuTLS defaults to weak security profile:

"The message authenticity security level is of 64 bits or more, and the certificate verification profile is set to GNUTLS_PROFILE_LOW (80-bits)."

This means for example that Diffie-Hellman group size of 1024-bits is allowed. This was deemed insufficient already 10 years ago. See https://weakdh.org/

This issue will be remedied in future GnuTLS release. Meanwhile the fix is to inject %PROFILE_MEDIUM as part of the priority string, for example "NORMAL:foo" becomes "NORMAL:%PROFILE_MEDIUM:foo". See https://gnutls.org/manual/html_node/Priority-Strings.html for details.

#insecuredefaults #cybersecurity #infosec #development

Be mindful of python-daemon default umask. For some unfathomable reason the default umask is 0. This leads to newly created files having default permissions of -rw-rw-rw (666) and directories rwxrwxrwx (777), or “world writable”. This can easily lead to #privilegeescalation vulnerabilities if the daemon is running as privileged user.

This default insecure umask was direct root cause of CVE-2017-9450 and CVE-2022-38170. #infosec #insecuredefaults #vulnerability #python

TFW when you find out there IS logging of specific actions in M365 that would have been incredibly useful in proving WITHOUT A DOUBT that thing "X" happened or did NOT happen.

And it's a security thing.

And the default for said logs is OFF.

And the only way to know they CAN be enabled is to find the Powershell command and options to enable them.

Why, why on earth Microsoft, would we NOT want to know these things? They are not voluminous events, but super important when they happen.

Would much rather have filtered them OUT rather than missing them 'this time'.

Setting is now ON.

#insecureDefaults