Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Malik1
Contributor

Vulnerability scan show weak encryption ciphers and DH groups on VPN device

Hi Experts,

Vulnerability scan has detected the below two vulnerabilities on port 500  

  1. Weak Encryption Ciphers identified on VPN Device
  2. Weak Diffie-Hellman groups identified on VPN Device

 

are these vulnerabilities detected because these encryption ciphers  and DH groups are being used in different VPN communities .

Should this  been detected ? as the scan is run on the gateway IP .

How this can be mitigated ? Can we disable weak ciphers?

 

Regards,

Sijeel

 

 

 

0 Kudos
9 Replies
Timothy_Hall
Champion Champion
Champion

Are you sure the detection was on UDP port 500 and not involving TLS on some other port such as 443?  What was the weak cipher?  3DES?  Read through these SKs and see if they apply to your situation:

sk113114: Check Point response to CVE-2016-2183 (Sweet32)

sk100647: Check Point response to common false positives scanning results

sk120774: Vulnerability scan shows that there are weak ciphers related to TLS 1.2

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
_Val_
Admin
Admin

You beat me to it 🙂

0 Kudos
Malik1
Contributor

Hi Tim and Val 

Below was the evidence shared that was shared by the team and yes its a vulnerability on port 500

Weak encryption ciphers

Transform Set:: Mode: Main, Encryption: 3DES, Hash type: SHA, Auth method: pre-shared key, DH Group: Group 2
Transform Set:: Mode: Main, Encryption: 3DES, Hash type: SHA, Auth method: RSA signatures, DH Group: Group 2
Transform Set:: Mode: Main, Encryption: 3DES, Hash type: SHA, Auth method: Checkpoint Hybrid, DH Group: Group 2

Weak DH groups

Transform Set:: Mode: Main, Encryption: AES, Key Length: 256, Hash type: SHA, Auth method: pre-shared key, DH Group: Group 2,
Transform Set:: Mode: Main, Encryption: AES, Key Length: 256, Hash type: MD5, Auth method: RSA signatures, DH Group: Group 2,
Transform Set:: Mode: Main, Encryption: AES, Key Length: 256, Hash type: SHA, Auth method: Checkpoint Hybrid, DH Group: Group 2,

 

We were using traditional vpn previously and  under the traditional vpn configuration most of the encryption ciphers (3des,des,aes128,aes256,cast) and hash(md5,sha1 and sha256) are enabled. Only DH group 2 is enabled in config.The configuration is still present

0 Kudos
G_W_Albrecht
Legend
Legend

When the Check Point Gateway uses a Traditional Mode policy, the encryption suites defined are found in the Gateway properties, under the IPsec VPN tab. The IKE Properties are configured to set the encryption and hashing algorithms the Security Gateway will support if it is the responder (when the IKE negotiation is initiated by the peer).

When the Security Gateway is the initiator, it uses the strongest available encryption suite.When the Security Gateway initiates Phase 1, it will use the AES-256 encryption algorithm and the SHA-256 hashing algorithm.

Details can be found in sk117438 How to know which VPN encryption suites a Check Point Gateway will offer in Phase 1 and 2 w...

CCSE CCTE CCSM SMB Specialist
Timothy_Hall
Champion Champion
Champion

OK that makes sense, with the Traditional VPN setup in the Encrypt Action properties you would select multiple encryption/hashing/DH groups that would be acceptable.  This must be what the scanning tool is picking up. When simplified VPNs were introduced in R52, the VPN settings were moved out of the rulebase and into the VPN Community objects, which would only let you set one encryption/hashing/DH group for all tunnels of that community.

So what you will need to do is edit all the Encrypt Actions of your VPN rules and deselect the weak ciphers.  As long as all firewalls utilizing those rules are yours (i.e. managed by the same SMS or CMA) making this change should be safe as long as you reinstall policy to all participant gateways immediately.  However if there are any externally managed gateways or interoperable devices utilizing these rules being edited, LOOK OUT as deselecting a protocol that the VPN peer is intending to use can most definitely break the tunnel. 

Once all weak ciphers are deselected from all Encrypt actions they should stop being offered by the firewall and the scan should pass.  Also look in the Global Properties under VPN and its sub-screens, if you have Traditional Mode active there may be some other settings there that you'll need to adjust to disable the weak ciphers, can't quite remember.  Edit: After reading Gunter's post these settings are on the gateway object, not Global Properties.

See this SK for some helpful instructions and screenshots:  sk117438: How to know which VPN encryption suites a Check Point Gateway will offer in Phase 1 and 2 ...

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
_Val_
Admin
Admin

To add what @Timothy_Hall  mentioned already, why don't you just disable those weak cyphers? Also, why are you still running unsupported config? Traditional VPN is long gone, or should, in you case.

0 Kudos
Malik1
Contributor

we have already migrated to simplified mode. but the old policy packages that have the encrypt action and the traditional vpn configuration under the gateway object is still present. That hasnt been removed .From the suggestion shared by  @Timothy_Hall i can remove the encrypt action from the old policy package as they aren't being used  and uncheck all the cipher under the traditional vpn configuration in gateway object . That should fix the issue.

0 Kudos
Malik1
Contributor

Also to add .As we are only be using simplified vpn mode that uses communities , we should not face the vulnerability in future . 

0 Kudos
Cyber_Serge
Collaborator

Did you use those  ciphers  and DH groups in the VPN communities? I remember on some documents from vendors the screenshot instruct user to use weak cipher for compatibility reasons (?), or just old document. So it was using the weak cipher during initial setup. We had to review them and change the setting at one point.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events