-
Notifications
You must be signed in to change notification settings - Fork 238
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
shell-detector looks like the malware it says it's scanning #24
Comments
i mean, do i read this properly? isn't this running eval on the malicious code it just detected? https://github.com/emposha/PHP-Shell-Detector/blob/master/shelldetect.php#L470 wtf? |
And why is everything detected as |
|
@DanielRuf about (Positive, its a 1405674947) probably some false positive, can you provide more info about thins |
I just run PHP Shell Detector on a normal WordPress website with full rights and got this positive detection on all files. |
But this does not describe why the db file is a huge base64 encoded string (which adds ~30% overhead). |
I might be wrong but isn't the database file world-writable after an update? So possibly a privilege escalation to the user running shell-detector would be possible. |
hi i got the error can someone tell me how do i solve this error ? |
Please check your php.ini and ask your hosting provider @RameshMaharjan |
I know have problem with Backdoor:PHP/CryptInject.YA but not detected by scanner |
Hi @6a6ak,
This project looks for files with specific file hashes. Backdoor:PHP/CryptInject.YA might not be part of the file hashes by default. Did you manually create the file hashes for the scanner? |
See https://github.com/emposha/PHP-Shell-Detector/blob/master/shelldetect.db for the database file. A file hash based approach is not very reliable as the smallest change will result in a completely different file hash. |
this code is problematic, to say the least:
now not only does this look like the malware it's suppose to stop, it's actually vulnerable to remote code execution (if
file_get_contents('https://...)
can be broken, which I wouldn't be surprised - yay sslstrip) as unserialize will happily execute code it uncompresses: http://ca1.php.net/manual/en/function.unserialize.php#refsect1-function.unserialize-notesseriously, why is this DB stored that way anyways? it's just a huge array... why not store it in a non-executable code format?
The text was updated successfully, but these errors were encountered: