fix(query): adding support for CloudFormation queries missing ingress/egress resources - Part 3
Reason for Proposed Changes
Note that, unlike part 2, this part contains all changes from part 1, that part should be merged first so the "Files changed" only show the relevant changes.
-
Currently some CloudFormation queries do not support the newer "AWS::EC2::SecurityGroupIngress" and "AWS::EC2::SecurityGroupEgress" resources, only working for samples with the legacy "AWS::EC2::SecurityGroup" resource.
-
This Pull Request will handle queries 11-14.
Query List
| Query Name | Query ID | Query Logic |
|---|---|---|
| ELB With Security Group Without Outbound Rules | 01d5a458-a6c4-452a-ac50-054d59275b7c | query 1 |
| DB Security Group With Public Scope | 9564406d-e761-4e61-b8d7-5926e3ab8e79 | query 2 |
| Default Security Groups With Unrestricted Traffic | ea33fcf7-394b-4d11-a228-985c5d08f205 | query 3 |
| EC2 Sensitive Port Is Publicly Exposed | 494b03d3-bf40-4464-8524-7c56ad0700ed | query 4 |
| ELB Sensitive Port Is Exposed To Entire Network | 78055456-f670-4d2e-94d5-392d1cf4f5e4 | query 5 |
| HTTP Port Open To Internet | ddfc4eaa-af23-409f-b96c-bf5c45dc4daa | query 6 |
| Remote Desktop Port Open To Internet | c9846969-d066-431f-9b34-8c4abafe422a | query 7 |
| Security Groups Allows Unrestricted Outbound Traffic | 66f2d8f9-a911-4ced-ae27-34f09690bb2c | query 8 |
| Security Group Unrestricted Access To RDP | 3ae83918-7ec7-4cb8-80db-b91ef0f94002 | query 9 |
| Security Groups With Exposed Admin Ports | cdbb0467-2957-4a77-9992-7b55b29df7b7 | query 10 |
| Security Groups With Meta IP | adcd0082-e90b-4b63-862b-21899f6e6a48 | query 11* |
| Security Group With Unrestricted Access To SSH | 6e856af2-62d7-4ba2-adc1-73b62cef9cc1 | query 12* |
| Unknown Port Exposed To Internet | 829ce3b8-065c-41a3-ad57-e0accfea82d2 | query 13* |
| DB Security Group Open To Large Scope | 0104165b-02d5-426f-abc9-91fb48189899 | query 14* |
Proposed Changes
-
✅Security Groups With Meta IP
- In terms of the query's logic this update is similar to the one done to the HTTP Port Open To Internet and Remote Desktop Port Open To Internet in part2 with similar/identical auxiliary functions; the missing resources were added and also a new check for any ingress with
IpProtocolset to "-1".
- In terms of the query's logic this update is similar to the one done to the HTTP Port Open To Internet and Remote Desktop Port Open To Internet in part2 with similar/identical auxiliary functions; the missing resources were added and also a new check for any ingress with
-
✅Security Group With Unrestricted Access To SSH
- The current query logic is unimpressive, it would only flag for the SSH (22) port being exposed if one of the "FromPort" or "ToPort" fields was explicitly set to said value, no "range" checking was done.
- The implementation is once again similar to queries like the Security Groups With Meta IP, the new resources are now supported, the logic was improved to properly check port ranges and the case for "-1" protocol was added.
- The query is near identical to the Security Group Unrestricted Access To RDP query from part2 except this time there was no analog query doing the same check, it was simply "missing" (in practice other queries flag for identical circumstances like "Security Groups With Exposed Admin Ports")
-
✅ Unknown Port Exposed To Internet
- Logic fixes once again similar to plenty other queries updated before. New resources added and logic for the "containsUnknownPort" helper function improved.
-
✅DB Security Group Open To Large Scope
- Analog to the changes done to DB Security Group With Public Scope in part1; additionally the
check_publicfunction was updated and renamed tois_public_db.
- Analog to the changes done to DB Security Group With Public Scope in part1; additionally the
I submit this contribution under the Apache-2.0 license.

KICS version: v2.1.17
|
|
⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.
Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.
🔎 Detected hardcoded secret in your pull request
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 21271469 | Triggered | Generic Password | 8bc5e18978bcdeaa48bdafcd835ecfb05772844f | assets/queries/terraform/azure/unrestricted_sql_server_access/test/positive4.tf | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.






