Skip to content

Latest commit

 

History

History
163 lines (112 loc) · 8.58 KB

File metadata and controls

163 lines (112 loc) · 8.58 KB

Cloudflare Security

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

In a Cloudflare account there are some general settings and services that can be configured. In this page we are going to analyze the security related settings of each section:

Websites

Review each with:

{% content-ref url="cloudflare-domains.md" %} cloudflare-domains.md {% endcontent-ref %}

Domain Registration

  • In Transfer Domains check that it's not possible to transfer any domain.

Review each with:

{% content-ref url="cloudflare-domains.md" %} cloudflare-domains.md {% endcontent-ref %}

Analytics

I couldn't find anything to check for a config security review.

Pages

On each Cloudflare's page:

  • Check for sensitive information in the Build log.
  • Check for sensitive information in the Github repository assigned to the pages.
  • Check for potential github repo compromise via workflow command injection or pull_request_target compromise. More info in the Github Security page.
  • Check for vulnerable functions in the /fuctions directory (if any), check the redirects in the _redirects file (if any) and misconfigured headers in the _headers file (if any).
  • Check for vulnerabilities in the web page via blackbox or whitebox if you can access the code
  • In the details of each page /<page_id>/pages/view/blocklist/settings/functions. Check for sensitive information in the Environment variables.
  • In the details page check also the build command and root directory for potential injections to compromise the page.

Workers

On each Cloudflare's worker check:

  • The triggers: What makes the worker trigger? Can a user send data that will be used by the worker?
  • In the Settings, check for Variables containing sensitive information
  • Check the code of the worker and search for vulnerabilities (specially in places where the user can manage the input)
    • Check for SSRFs returning the indicated page that you can control
    • Check XSSs executing JS inside a svg image
    • It is possible that the worker interacts with other internal services. For example, a worker may interact with a R2 bucket storing information in it obtained from the input. In that case, it would be necessary to check what capabilities does the worker have over the R2 bucket and how could it be abused from the user input.

{% hint style="warning" %} Note that by default a Worker is given a URL such as <worker-name>.<account>.workers.dev. The user can set it to a subdomain but you can always access it with that original URL if you know it. {% endhint %}

R2

On each R2 bucket check:

  • Configure CORS Policy.

Stream

TODO

Images

TODO

Security Center

  • If possible, run a Security Insights scan and an Infrastructure scan, as they will highlight interesting information security wise.
    • Just check this information for security misconfigurations and interesting info

Turnstile

TODO

Zero Trust

{% content-ref url="cloudflare-zero-trust-network.md" %} cloudflare-zero-trust-network.md {% endcontent-ref %}

Bulk Redirects

{% hint style="info" %} Unlike Dynamic Redirects, Bulk Redirects are essentially static — they do not support any string replacement operations or regular expressions. However, you can configure URL redirect parameters that affect their URL matching behavior and their runtime behavior. {% endhint %}

  • Check that the expressions and requirements for redirects make sense.
  • Check also for sensitive hidden endpoints that you contain interesting info.

Notifications

  • Check the notifications. These notifications are recommended for security:
    • Usage Based Billing
    • HTTP DDoS Attack Alert
    • Layer 3/4 DDoS Attack Alert
    • Advanced HTTP DDoS Attack Alert
    • Advanced Layer 3/4 DDoS Attack Alert
    • Flow-based Monitoring: Volumetric Attack
    • Route Leak Detection Alert
    • Access mTLS Certificate Expiration Alert
    • SSL for SaaS Custom Hostnames Alert
    • Universal SSL Alert
    • Script Monitor New Code Change Detection Alert
    • Script Monitor New Domain Alert
    • Script Monitor New Malicious Domain Alert
    • Script Monitor New Malicious Script Alert
    • Script Monitor New Malicious URL Alert
    • Script Monitor New Scripts Alert
    • Script Monitor New Script Exceeds Max URL Length Alert
    • Advanced Security Events Alert
    • Security Events Alert
  • Check all the destinations, as there could be sensitive info (basic http auth) in webhook urls. Make also sure webhook urls use HTTPS
    • As extra check, you could try to impersonate a cloudflare notification to a third party, maybe you can somehow inject something dangerous

Manage Account

  • It's possible to see the last 4 digits of the credit card, expiration time and billing address in Billing -> Payment info.
  • It's possible to see the plan type used in the account in Billing -> Subscriptions.
  • In Members it's possible to see all the members of the account and their role. Note that if the plan type isn't Enterprise, only 2 roles exist: Administrator and Super Administrator. But if the used plan is Enterprise, more roles can be used to follow the least privilege principle.
    • Therefore, whenever possible is recommended to use the Enterprise plan.
  • In Members it's possible to check which members has 2FA enabled. Every user should have it enabled.

{% hint style="info" %} Note that fortunately the role Administrator doesn't give permissions to manage memberships (cannot escalate privs or invite new members) {% endhint %}

DDoS Investigation

Check this part.

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}