[nuclei-template] Symfony RCE

[Elsfa7-110]

Template Details https://raw.githubusercontent.com/Elsfa7-110/testbug/main/SymfonyRCE.yaml and thx to my friend Emad Shanab

id: rce-symfony

info:
  name: symfony rce
  author: ELSFA7110
  severity: high
  reference: |
    - https://www.acunetix.com/vulnerabilities/web/symfony-rce-via-weak-predictable-app_secret
    - https://www.ambionics.io/blog/symfony-secret-fragment
  tags: rce

requests:
  - method: GET
    path:
      - "{{BaseURL}}/_fragment?_path=_controller=phpcredits&flag=-1"

    matchers-condition: and
    matchers:
      - type: word
        words:
          - "PHP Credits"
        part: body

      - type: status
        status:
          - 200

[ehsandeep]

@Elsfa7-110 As per the linked blog, we need a secret key to get the RCE, can you share additional information?

[dorkerdevil]

looks like you will need to have access to .env file containing the secret key as directed in the ambionics article

$ grep -F APP_SECRET .env # Find secret APP_SECRET=50c8215b436ebfcc1d568effb624a40e

so either you might have access to .env cuz of some misconfig or you might have access to server locally

so in either case doesn't makes sense.

That's what i can observe , unless the author of this template have better solution for this.

[Elsfa7-110]

@dorkerdevil @ehsandeep i think can get it by PHPinfo

On recent symfony versions (3.x), secret is stored in .env as APP_SECRET. Since it is then imported as an environment variable, they can be seen through a phpinfo() page. (this also in the ambionics article)

so the path

path:

• "{{BaseURL}}/_fragment?_path=_controller=phpcredits&flag=-1"

[meme-lord]

Hi, If you get PHPInfo to execute from the Symfony context it will leak the APP_KEY however I do not think your template will work. Have you gotten that payload to work on any host? I tested for this bug a lot and as far as I understand you need a valid hash generated with the secret in order for the controller to execute. The main issue discussed in that blog posts was that people were using guessable secrets and so code execution could be achieved via this script: https://github.com/ambionics/symfony-exploits/blob/main/secret_fragment_exploit.py I don't think this is easily templatable to test the actual RCE but here is the template I used to detect accessible _fragment endpoints:

id: symfony-fragment

info:
  name: Symfony Fragment Endpoint Accessible
  author: meme-lord
  severity: low
  tags: symfony
  reference: https://www.ambionics.io/blog/symfony-secret-fragment 

requests:
  - method: GET
    redirects: true
    max-redirects: 3
    path:
      - "{{BaseURL}}/_fragment"
      - "{{BaseURL}}/app_dev.php/_fragment"
    headers:
      User-Agent: "Mozilla Firefox Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0"
    matchers-condition: and
    matchers:
      - type: word
        words:
          - "Oops! An Error Occurred"
          - "Something is broken. Please let us know what you were doing when this error occurred."
        condition: and
      - type: status
        status:
          - 403

Yes this is prone to false positives but I don't think much better can be achieved. There are already templates for other potential paths that would point to Symfony being used like /_profiler/phpinfo.

[Elsfa7-110]

@meme-lord read this https://twitter.com/Alra3ees/status/1419058927422017540

[meme-lord]

I have read that before and it just doesn't make sense and has never worked in my testing. I just tested your template against a few thousand known Symfony websites from my previous scans with varying versions and only got some false positives (eg. they will show phpinfo on all pages). I think his payload is a misunderstanding of the ambionics article. Maybe @cfreal can weigh in on this?

[cfreal]

Hi,

The first nuclei template, despite referencing my blogpost, tests for CVE-2015-4050. The bug allows you to trigger /_fragment without a _hash. This is an old bug.

As some of you correctly stated, for recent versions you need the secret key to compute the hash.

For the second template: it checks if /_fragment returns 403, and writes standard error messages (such as ""Oops! An Error Occurred"). First, you can't be sure that /_fragment is really FragmentListener, and not some other page that returns 403. I've also seen /_fragment pages that return 500 straight up. Second, the matchers are too specific. If a guy overwrites the 403 message or if Symfony uses another language, it won't detect /_fragment. Third, being able to access /_fragment does not mean you can exploit the bug, since you need to know (or bruteforce) the key.

So, at best, as meme-lord said, the second template can detect some cases where the exploit might work. It offers no garanty both for fingerprinting or for exploitability.

I don't know much about nuclei, but I think since you need to compute the hash in function of the full URL, you can't implement my exploit using nuclei.