From 776776621abbabb4917814b02b89f0fa341191b6 Mon Sep 17 00:00:00 2001 From: Techbrunch Date: Tue, 18 May 2021 15:53:10 +0200 Subject: [PATCH] Added a few Magento related templates --- cves/2020/CVE-2020-5776.yaml | 2 +- cves/2020/CVE-2020-5777.yaml | 2 +- exposed-panels/magento-admin-panel.yaml | 25 +++++++++++ exposures/configs/magento-config.yaml | 2 +- technologies/magento-detect.yaml | 41 +++++++++++++++++++ technologies/magmi-detect.yaml | 1 + .../magento/magento-2-exposed-api.yaml | 38 +++++++++++++++++ .../magento/magento-cacheleak.yaml | 22 ++++++++++ .../magento-unprotected-dev-files.yaml | 20 +++++++++ workflows/magento-workflow.yaml | 20 +++++++++ 10 files changed, 170 insertions(+), 3 deletions(-) create mode 100644 exposed-panels/magento-admin-panel.yaml create mode 100644 technologies/magento-detect.yaml create mode 100644 vulnerabilities/magento/magento-2-exposed-api.yaml create mode 100644 vulnerabilities/magento/magento-cacheleak.yaml create mode 100644 vulnerabilities/magento/magento-unprotected-dev-files.yaml create mode 100644 workflows/magento-workflow.yaml diff --git a/cves/2020/CVE-2020-5776.yaml b/cves/2020/CVE-2020-5776.yaml index 7d27f193f8..e8b8df0a28 100644 --- a/cves/2020/CVE-2020-5776.yaml +++ b/cves/2020/CVE-2020-5776.yaml @@ -6,7 +6,7 @@ info: severity: high description: Currently, all versions of MAGMI are vulnerable to CSRF due to the lack of CSRF tokens. RCE (via phpcli command) is possible in the event that a CSRF is leveraged against an existing admin session for MAGMI. reference: https://www.tenable.com/security/research/tra-2020-51 - tags: cve,cve2020,magmi + tags: cve,cve2020,magmi,magento # Due to the lack of CSRF tokens, RCE (via phpcli command) is possible # in the event that a CSRF is leveraged against an existing admin session for MAGMI. diff --git a/cves/2020/CVE-2020-5777.yaml b/cves/2020/CVE-2020-5777.yaml index 3446c882c4..2781b85b50 100644 --- a/cves/2020/CVE-2020-5777.yaml +++ b/cves/2020/CVE-2020-5777.yaml @@ -6,7 +6,7 @@ info: severity: high description: MAGMI versions prior to 0.7.24 are vulnerable to a remote authentication bypass due to allowing default credentials in the event there is a database connection failure. reference: https://github.com/dweeves/magmi-git/blob/18bd9ec905c90bfc9eaed0c2bf2d3525002e33b9/magmi/inc/magmi_auth.php#L35 - tags: cve,cve2020,magmi + tags: cve,cve2020,magmi,magento # Response code 503 indicates a potential successful "Too many connections" error # While the Db connection is down, you can access http://[TARGET]/magmi/web/magmi.php diff --git a/exposed-panels/magento-admin-panel.yaml b/exposed-panels/magento-admin-panel.yaml new file mode 100644 index 0000000000..f623c7a640 --- /dev/null +++ b/exposed-panels/magento-admin-panel.yaml @@ -0,0 +1,25 @@ +id: magento-admin-panel + +info: + name: Exposed Magento Admin Panel + author: TechbrunchFR + severity: info + description: As a security best practice, Magento recommends that you use a unique, custom Admin URL instead of the default admin or a common term such as backend. Although it will not directly protect your site from a determined bad actor, it can reduce exposure to scripts that try to gain unauthorized access. + reference: + - https://docs.magento.com/user-guide/stores/store-urls-custom-admin.html + tags: magento + +# There might be a better way and I don't know if it will always return a 302 or set an admin cookie +requests: + - method: GET + path: + - '{{BaseURL}}/admin' + matchers-condition: and + matchers: + - type: status + status: + - 302 + - type: dsl + dsl: + - contains(tolower(all_headers), 'admin=') # Set-Cookie: admin=nfocvc2vj376c28red2o6aukpe; e + part: header \ No newline at end of file diff --git a/exposures/configs/magento-config.yaml b/exposures/configs/magento-config.yaml index abf80cc0fe..882d7d3b77 100644 --- a/exposures/configs/magento-config.yaml +++ b/exposures/configs/magento-config.yaml @@ -3,7 +3,7 @@ info: name: Magento Config Disclosure author: geeknik severity: medium - tags: config,exposure + tags: config,exposure,magento requests: - method: GET diff --git a/technologies/magento-detect.yaml b/technologies/magento-detect.yaml new file mode 100644 index 0000000000..9ee2a37f3b --- /dev/null +++ b/technologies/magento-detect.yaml @@ -0,0 +1,41 @@ +id: magento-detect + +info: + name: Magento Detect + author: TechbrunchFR + severity: info + description: Identify Magento + tags: magento + +requests: + - method: GET + path: + - '{{BaseURL}}' + matchers: + - type: dsl + dsl: + - contains(tolower(all_headers), 'x-magento') + part: header + # - method: GET + # path: + # # There might be a better way to do that, the idea of this check is that Magento might be behind some kind of proxy when + # # consumed by a SPA/PWA app so we need a valid GraphQL query from Magento to check + # # https://devdocs.magento.com/guides/v2.4/graphql/ + # - '{{BaseURL}}/graphql?query=+{customerDownloadableProducts+{+items+{+date+download_url+order_increment_id+remaining_downloads+status+}}+}' + # matchers-condition: and + # matchers: + # - type: status + # status: + # - 200 + # - type: word + # words: + # - "The current customer isn't authorized." + # part: body + # - method: GET + # path: + # # Based on a check done by magereport.com + # - '{{BaseURL}}/js/varien/product.js' + # matchers: + # - type: status + # status: + # - 200 \ No newline at end of file diff --git a/technologies/magmi-detect.yaml b/technologies/magmi-detect.yaml index 519ab9f47c..e45dade5e1 100644 --- a/technologies/magmi-detect.yaml +++ b/technologies/magmi-detect.yaml @@ -4,6 +4,7 @@ info: name: "MAGMI (Magento Mass Importer) Plugin Detect" author: "dwisiswant0" severity: "info" + tags: magento requests: - method: GET diff --git a/vulnerabilities/magento/magento-2-exposed-api.yaml b/vulnerabilities/magento/magento-2-exposed-api.yaml new file mode 100644 index 0000000000..e175f5bdb8 --- /dev/null +++ b/vulnerabilities/magento/magento-2-exposed-api.yaml @@ -0,0 +1,38 @@ +id: magento-2-exposed-api + +info: + name: Exposed Magento 2 API + author: TechbrunchFR + severity: info + description: The API in Magento 2 can be accessed by the world without providing credentials. Through the API information like storefront, (hidden) products including prices are exposed. + reference: + - https://support.hypernode.com/en/ecommerce/magento-2/how-to-protect-the-magento-2-api + tags: magento + +requests: + - method: GET + path: + - '{{BaseURL}}/rest/V1/products' + matchers-condition: and + matchers: + - type: status + status: + - 400 + - type: word + words: + - "searchCriteria" + part: body + - method: GET + path: + - '{{BaseURL}}/rest/V1/store/storeViews' + matchers: + - type: status + status: + - 200 + - method: GET + path: + - '{{BaseURL}}/rest/V1/store/storeConfigs' + matchers: + - type: status + status: + - 200 \ No newline at end of file diff --git a/vulnerabilities/magento/magento-cacheleak.yaml b/vulnerabilities/magento/magento-cacheleak.yaml new file mode 100644 index 0000000000..c9eb368289 --- /dev/null +++ b/vulnerabilities/magento/magento-cacheleak.yaml @@ -0,0 +1,22 @@ +id: magento-cacheleak + +info: + name: Magento Cacheleak + author: TechbrunchFR + severity: high + description: Magento Cacheleak is an implementation vulnerability, result of bad implementation of web-server configuration for Magento platform. Magento was developed to work under the Apache web-server which natively works with .htaccess files, so all needed configuration directives specific for various internal Magento folders were placed in .htaccess files. When Magento is installed on web servers that are ignoring .htaccess files (such as nginx), an attacker can get access to internal Magento folders (such as the Magento cache directory) and extract sensitive information from cache files. + reference: + - https://support.hypernode.com/en/best-practices/security/how-to-secure-magento-cacheleak + - https://www.acunetix.com/vulnerabilities/web/magento-cacheleak/ + - https://royduineveld.nl/magento-cacheleak-exploit/ + tags: magento + +requests: + - method: GET + path: + # Based on royduineveld.nl blogpost, was not tested against a vulnerable Magento site + - '{{BaseURL}}/var/resource_config.json' + matchers: + - type: status + status: + - 200 \ No newline at end of file diff --git a/vulnerabilities/magento/magento-unprotected-dev-files.yaml b/vulnerabilities/magento/magento-unprotected-dev-files.yaml new file mode 100644 index 0000000000..0dfcd79dcd --- /dev/null +++ b/vulnerabilities/magento/magento-unprotected-dev-files.yaml @@ -0,0 +1,20 @@ +id: magento-unprotected-dev-files + +info: + name: Magento Unprotected development files + author: TechbrunchFR + severity: high + description: Magento version 1.9.2.x includes /dev directories or files that might reveal your passwords and other sensitive information. The /dev directories and files are not protected by default. According to Magento, "these tests are not supposed to end up on production servers". + reference: + - magereport.com + tags: magento + +requests: + - method: GET + path: + # Based on royduineveld.nl blogpost, was not tested against a vulnerable Magento site + - '{{BaseURL}}/dev' + matchers: + - type: status + status: + - 200 \ No newline at end of file diff --git a/workflows/magento-workflow.yaml b/workflows/magento-workflow.yaml new file mode 100644 index 0000000000..1f22b614c7 --- /dev/null +++ b/workflows/magento-workflow.yaml @@ -0,0 +1,20 @@ +id: magento-workflow + +info: + name: Magento Security Checks + author: TechbrunchFR + description: A simple workflow that runs all Magento related nuclei templates on a given target. + tags: workflow + +workflows: + - template: technologies/magento-detect.yaml + + subtemplates: + - template: technologies/magmi-detect.yaml + subtemplates: + - template: cves/2020/CVE-2020-5776.yaml + - template: cves/2020/CVE-2020-5777.yaml + - template: exposures/configs/magento-config.yaml + - template: exposed-panels/magento-admin-panel.yaml + - template: vulnerabilities/magento + #- tags: magento #716 \ No newline at end of file