Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Found a Vulnerability in the code #18

Closed
remhopster-isdp opened this issue Jun 25, 2024 · 8 comments
Closed

Found a Vulnerability in the code #18

remhopster-isdp opened this issue Jun 25, 2024 · 8 comments

Comments

@remhopster-isdp
Copy link

Dear reader(s),

I have found a vulnerability in the code.
Can you please share the contact details to report a vulnerability I have found or enable the security policy so that I can fill a report?
Awaiting the response and suggested next steps.

Kind Regards,

R.

@kirilkirkov
Copy link
Owner

Hello @remhopster-isdp
You can share the report here and i will fix the vulnerabilities which you found. Thank you

@remhopster-isdp
Copy link
Author

PHP Object Injection

Summary

Using unserialize() on untrusted user input, such as data from cookies, can lead to serious security vulnerabilities, including PHP Object Injection attacks.
Upon inspection and testing of the code of the platform, it was found that PHP Object Injection is possible by crafting a malicious "Evil class".
By taking control of the content of the laraCart cookie, I was able to create a serialized payload. This allowed me to read files and execute arbitrary code, demonstrating the potential for Arbitrary Code Execution.

Details

The vulnerable code is found in \\app\\Cart.php in the private function "getCartProductsIds()".
Vulnerable code:

if (isset($_COOKIE['laraCart']) && $_COOKIE['laraCart'] == null && !empty($_COOKIE['laraCart'])) {
$_SESSION['laraCart'] = unserialize($_COOKIE['laraCart']);

PoC

Start:
Add an extra class to Cart.php. In this case, we created "EvilClass" to demonstrate how I could exploit the vulnerability.

class EvilClass
{
    public function __destruct()
    {
        // code executed 
        //phpinfo();
        system('cmd /c dir > C:\\windows\temp\EvilGdump.txt');    
	}
}

// Craft malicious serialized string
$maliciousData = serialize(new EvilClass());

// Set the cookie with the malicious data
setcookie('laraCart', $maliciousData, time() + 3600, '/');

// Simulate accessing the vulnerable method
$cart = new Cart();
$cart->getCartProductsIds();

and set the function public of the class getCartProductsIds() in Cart,php:

public function getCartProductsIds()

If you don't set the function to public of getCartProductsIds(), the user will get an error message by going to the index page. But "system('cmd /c dir > C:\\windows\\temp\\EvilGdump.txt');" has run. When set on public the command will also be executed by loading the page, but the user will see the normal website.

POC of EvilGdump.txt

afbeelding

afbeelding

Running the command "phpinfo()" (see also the code)
phpinfo - Request_URI and Script_name

afbeelding

Injection in Cookie laraCart:

afbeelding

Possible Real world scenario: Make it more difficult for a user or developer to spot.
By creating a new file with the class name 'prodclass.php', include the same code but replace 'Evil' and 'malicious' with other words like 'prods'. 'productItms', and call the class in Cart.php. Harder to detect and looks like legit code.

Solution

Use JSON encoding/decoding.
Code example (not tested!):

private function getCartProductsIds()
{
    $products = array();
    if (!isset($_SESSION['laraCart']) || empty($_SESSION['laraCart'])) {
        if (isset($_COOKIE['laraCart']) && !empty($_COOKIE['laraCart'])) {
            $cookieData = json_decode($_COOKIE['laraCart'], true);
            if (json_last_error() === JSON_ERROR_NONE) {
                $_SESSION['laraCart'] = $cookieData;
            }
        }
    } else {
        $products = $_SESSION['laraCart'];
    }
    return $products;
}

With JSON encoding and decoding, you avoid the risks associated with PHP's unserialize() function, as JSON does not support object serialization and hence does not invoke any magic methods like __wakeup() or __destruct(). This way, the application is safer from object injection attacks.

Impact

A03:2021 - Injection OWASP-top 10
PHP object injection is a vulnerability that occurs when untrusted user input is deserialized into a PHP object. This can lead to various security risks, including arbitrary code execution, data tampering, and unauthorized actions.

Affected:
End-Users / Companies
Users and companies using vulnerable web applications may have their personal and sensitive information exposed or manipulated. They could also be subjected to unauthorized actions or service disruptions.

Affected Products: other
Severity: Estimated - 7.2

CVE-ID: Not yet provided.

kirilkirkov pushed a commit that referenced this issue Jul 3, 2024
@kirilkirkov
Copy link
Owner

@remhopster-isdp The issue was resolved with this commit - a02111a

@remhopster-isdp
Copy link
Author

remhopster-isdp commented Jul 3, 2024 via email

@remhopster-isdp
Copy link
Author

Hi Kiril,

Hope you are doing well.
I am curious if you can give an update on the CVE-ID?

kind Regards,

R.

@kirilkirkov
Copy link
Owner

I am not sure that is possible for that project @remhopster-isdp ?

@remhopster-isdp
Copy link
Author

remhopster-isdp commented Jul 15, 2024 via email

@kirilkirkov
Copy link
Owner

@remhopster-isdp Yes, they are different platforms and yes they are used for Ecommerce as they are

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants