Debug School

rakesh kumar
rakesh kumar

Posted on

How a Gambling Page Replaced My Laravel Homepage—and Why Restoring index.php Fixed It

What happened
Where the problem was
Why your commands made the homepage work
Mitigation checklist

What happened

Your screenshot now shows the normal HolidayLandmark homepage. Earlier, requests to / returned the CERUTU4D gambling page, and a server search found cerutu4d inside:

sudo grep -RIlFi --binary-files=without-match 'cerutu4d' \
Enter fullscreen mode Exit fullscreen mode 

/opt/lampp/htdocs/holiday-new/hl-home/index.php
/opt/lampp/htdocs/holiday-new/hl-home/blog/index.html
Enter fullscreen mode Exit fullscreen mode

Apache’s HolidayLandmark configuration points to hl-home. That explains why changing a file in this folder could change what visitors saw. The Git copy of index.php was reportedly clean, so the evidence points to a change in the deployed copy. It does not yet establish who made the change or how they gained write access.
There is a second, urgent issue: the investigation reported that visitors could download /.env. The restored homepage does not prove that this exposure is fixed. Laravel warns that serving the project root can expose sensitive configuration files; its intended web entry point is public/index.php

There are two connected security failures:

  1. The live homepage was changed. Everyone requesting / receives the gambling page. The clean Git repository suggests the unwanted change is in the deployed files, but it does not tell us who changed them or how.
  2. Private Laravel files are reachable through the website. You report that .env is downloadable, along with artisan and composer.json. If the response contains the real .env file, treat every secret in it as exposed. Laravel specifically warns that serving the project root can expose sensitive configuration files.

Where the problem was

Why your commands made the homepage work

You ran:

git checkout -- index.php .htaccess
mv blog/index.html "$Q/blog-index.html.live"
php artisan optimize:clear
Enter fullscreen mode Exit fullscreen mode

Mitigation checklist

Fix it in this order

  1. Preserve evidence Keep private copies of the altered index.php and blog/index.html, their stat output, Apache access/error logs, and Git status. Do not delete the spam files before saving them; their timestamps and contents may help identify the entry point. CISA’s incident guidance calls for preserving evidence while responding. CISA

Do kaam karne hain:

  1. access block karein: HolidayLandmark ke Apache virtual host mein diya gaya rule lagane se visitors .env, artisan, composer.json aur composer.lock jaise filenames nahi khol paayenge. httpd -t configuration ki syntax check karta hai; uske baad Apache ko reload karke URLs test karne honge. Apache mein aur Require all denied isi tarah file access control ke liye use hote hain. Apache HTTP Server Version 2.4

  2. Permanent layout fix karein: HolidayLandmark ka DocumentRoot Laravel ke public folder par set karein. Tab .env aur baaki project files web root ke bahar rahengi. Laravel requests ka intended entry point public/index.php hai. laravel.com
    /trips/ aur /blog/ ko pehle map karne ka matlab: pata karein ki ye URLs abhi kis folder, Apache Alias, ya Laravel route se chal rahe hain. Uske baad DocumentRoot badlein, taaki ye working pages accidentally band na ho jaayein.

  1. Stop public access to secrets immediately The lasting fix is to configure this Laravel application’s Apache DocumentRoot to the correct public directory, with the project and .env outside that web root. First map the current /trips/ and /blog/ routing so the change does not break them. Laravel documents public/index.php as its intended entry point. laravel.com Until that layout is corrected, add an Apache access rule in the HolidayLandmark virtual host to deny the exposed filenames: 
<FilesMatch "^(?:\.env(?:\..*)?|artisan|composer\.(?:json|lock))$">
    Require all denied
</FilesMatch>
Enter fullscreen mode Exit fullscreen mode

Apache supports FilesMatch and Require all denied for this purpose. Check the configuration with sudo /opt/lampp/bin/httpd -t before reloading Apache, then confirm those URLs return 403 or 404. This filename rule is temporary protection; it does not make serving a Laravel project root safe. Apache HTTP Server Version 2.4

  1. Restore the clean homepage Since the Git version of index.php has reportedly been checked and is clean, restore that file only from the verified repository. Check blog/index.html separately: the earlier search found the spam term there too, even though /blog/ currently works. Restore it from a clean version if it is altered. Avoid git reset --hard or a broad pull on production; those can erase unrelated changes.
  2. Replace exposed credentials After blocking .env access, rotate the credentials listed in it: database users, Keycloak client secret, API/SMTP/storage keys, and any other active credentials. Review their access logs for misuse. Plan APP_KEY rotation carefully: Laravel uses it to decrypt application data, so changing it without a migration plan can affect sessions or encrypted values. laravel.com
  3. Find how the files were changed Use the saved file modification times to examine SSH logins, deployments, Apache requests, application logs, and writable directories around those times. Also check who can write to hl-home/index.php. A clean Git repository does not rule out a stolen SSH/deployment credential, an unsafe upload path, or an application vulnerability.

chatgpt

Top comments (0)