New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
My Laravel11 server was attacked. Has anyone encountered the same thing?
Yesterday, when I was checking the server site, I found an extra file in the public folder. I used the Laravel 11 framework. I used very few dependencies and did not receive any vulnerability reports from Github, but for some reason there was an extra PHP file. What does this file do? AI's answer was ambiguous. Since the site is not very important, I think I need to find its breakthrough to prevent other Laravel 11 sites from being attacked. Does anyone have any suggestions?
Comments
Check folder permissions. It has nothing to do with laravel.
I read through it just for fun and though I don't know PHP, it seems like a badly/barely-obfuscated "nonsense" script. Maybe it's to check if infiltration was successful dunno.
Make sure you allow only image types or needed file types in validation rules
This is the first entrance I suspected, but all images will be directly converted to webp format and compressed after being uploaded, and will also be sent to NSFW detection. Any failure in the detection will result in failure, so I think it is impossible to invade from the upload entrance.
Indeed, but this one is indeed uploaded as public/Lndex.php He has come up.
public-folder only grants permission to www, but public/Lndex.php has root:root permission, which I think is dangerous.
public/Lndex.php is the strange file uploaded by the hacker.
From static analysis: this php file is called remotely with parameters 'id'(get) or 'ftp'(post) with hex encoded php script payload, random 6 character (lowercase, uppercase and 0-9) filename with '.gif' extension configured, placed within whichever detected temp directory.
File written from function 'filterStr', which is obfuscated to write the standard php start, then after with a new-line delimiter. Now, 'filterStr' manually iterates through the get/post parameter, of the to-be hex encoded php script payload, then appends the standard php script ending.
Prints some random 'hello world' to cli, ie junk data.
Now checks if the file exists in the configured destination, if yes, uses 'require_once' to execute the script. After this runs, it deletes the executed payload.
Then more junk data of generating and spitting out a md5 sum.
So this is a remote script? I can't find any entry points? There is no point in tracking this file anymore, right?
As far as I can tell, yes, this seems to be a dropper/backdoor, for persistence.
could put the script into pastebin and link it here?
This is absolutely a backdoor. Look at the GET and he can put anything to write in a file.
I like that summary, itachikonoha.
Part I'm even more concerned with is the root permission on the file, but someone knowledgeable in php and it's webservers would need to commentate on that.
Source File Content here of backdoor: https://pastebin.com/5kS2Wei8
After checking the vistslogs, the following anomalies were found:
1. Why is the injected file root:root and named Lndex.php, sourcefile: https://pastebin.com/5kS2Wei8
2. An abnormal GET access appeared in the access log:
The query string probably isn't related the suspicious file as these parameters won't execute anything in the file.
Analysis self-correction: Parameters 'id' and 'ftp' both required.
Further inspection, 'id' specifies array key while 'ftp' specifices array value (1 => encoded-payload).
Deobfuscated: https://pastebin.com/MCeM7AcL
If anyone versed in php can explain that array modification of c to a, please commentate or pm me.
I love those obfuscated virus files. Hexdec has something magical. And when you deobfuscate that mambo jumbo you know that you cracked crackers mind.
Not a virus, but JavaScript obfuscation techniques are pretty wild. The most impressive I came across was four-layers of direct addressing tables in a loop (with about 5 other variants of the same function), along with a simple cipher, that stored string constants used to decompress a custom compression file format into JSON and then key into it. Any built-in methods such as indexing were also aliased 6 times, with each alias branching off into 2-3 other aliases. It was a pain to deobfuscate that one by hand.
I'm not entirely sure, but it might have something to do with references.
https://www.php.net/manual/en/language.references.php
Check the first comment in this. It looks to be a similar situation to what you pointed out.
Thank you very much Advin, that is exactly it.
Anyone interested in the strange behavior: https://pastebin.com/CFVMVxeE
Obfuscation ($b =& $a[1];) summary: establishing a unused reference(pointer) to an established array cell(value) allows it to be open to any modification later, until unset.