Info Sec/ Remediation

Question 1

Weak SSL/TLS protocols should not be used

Answer 1

SSL and TLS version before TLS1.2 are considered weak
TLSv1.3 being the most secure as it removes support for older and insecure cipher suites.

Refactor uses of “SSLContext.getInstance” to a central SSLContextFactory that defaults to “TLS”.

Question 2

Whats the different parts of a cipher suite

Answer 2

Share

A cipher suite is a set of cryptographic algorithms used to secure a network connection, particularly in the context of TLS (Transport Layer Security) and its predecessor SSL (Secure Sockets Layer). During the handshake phase of a TLS connection, the client (e.g., a web browser or application) and the server agree on a cipher suite, which determines how various aspects of the connection are secured.

A cipher suite typically defines:

Key Exchange Algorithm: How the client and server will securely exchange the keys to be used for encryption (e.g., RSA, Diffie-Hellman, ECDH). This step is crucial for setting up a secure communication channel without prior key knowledge.

Authentication Algorithm: How the server’s identity is authenticated to the client (e.g., RSA, ECDSA). The server proves it holds a private key corresponding to a trusted certificate.

Symmetric Encryption Algorithm: How the actual data transferred between the client and server is encrypted (e.g., AES, ChaCha20). This encryption ensures confidentiality, meaning that only the client and server can understand the exchanged data.

Message Authentication Code (MAC) Algorithm: How the data’s integrity is ensured (e.g., HMAC-SHA256). This prevents tampering or unauthorized alteration of the messages being exchanged.

For Example

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
can be broken down as follows:

TLS: Specifies that the cipher suite is for use with the TLS protocol.
ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): The key exchange algorithm. It ensures forward secrecy by generating a temporary key pair for each session.
RSA: The authentication algorithm, where the server proves its identity by using an RSA certificate.
AES_128_GCM: The symmetric encryption algorithm. AES (Advanced Encryption Standard) is used with a 128-bit key in GCM (Galois/Counter Mode), which provides both encryption and message integrity in a highly efficient manner.
SHA256: The message authentication code (MAC) algorithm. It uses HMAC (Hashed Message Authentication Code) with the SHA-256 hashing function to ensure the integrity of the messages.

Question 3

How user passwords should be stored in data. What is Syn doing wrong

Answer 3

Syn doesnt use one way hashing . It uses encryption
Hashing one way using SHA-256 or bcrypt .. will ensure a hashed value is store in the db
In adddition to this using a random salt ensure that same password dont generate the same hash .

The ideal thing we want is to use the latest hashing algorithm “Argon2id”
Use a different salt to generate the hash.. the modern algo use it by default
use a pepper to generate the hash that stays out of the database

and have a high work factor > 2 or 5 depending on how much is your ssystem capacity as it slows things down

Question 4

jasypt

Answer 4

jsypt can be used to encrypt values in the properties file. Its a bidirectional encryption so you can decrypt it also

Question 5

What Measures for InfoSec at work place are in place .

Answer 5

Think use of Snyke/Sonar qube
Think of the remediation that has been put in place
SQL injection./ XML parsers/ TLS context factory etc.

Weak SSL/TLS protocols should not be used so remove SSL move to TLS by default

Server certificates should be verified during SSL/TLS connections. When certificate validation is disabled, the client skips a critical security check.

Solution:
Refactor uses of “SSLContext.getInstance” to a central SSLContextFactory that defaults to “TLS”.

Consider making protocol version overridable on the relevant CAF components.

Enable Server certificate validation by removing TrustEveryoneTrustManager and the related “trust everyone” property.

By default XML processors attempt to load all XML schemas and DTD (their locations are defined with xsi:schemaLocation attributes and DOCTYPE declarations), potentially from an external storage such as file system or network, which may lead, if no restrictions are put in place, to server-side request forgery (SSRF) vulnerabilities.
XML parsers should not be vulnerable to XXE attacks (XML External Entity Injection Attacks)

The best defense against XXE is to disable doctype declarations, but Syn feeds make extensive use of these.
* Therefore they are not disabled:

we have created a XMLParsing class which can give instance of DocumentBuilderFactory or newSAXParserFactory that disables the loading of external entities
factory.setFeature(“http://xml.org/sax/features/external-general-entities”, false);
factory.setFeature(“http://xml.org/sax/features/external-parameter-entities”, false);

Can also consider using a

Only load schemas from a trusted location on the file system; reject anything else.

Synn needs to use an EntityResolver that will only load the schemas from allowed locations.