Timeline for How can malicious user change file on server without it being logged in server logs and how to protect against it?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 4 at 16:45 | comment | added | Heinlein | @browsermator Thanks for clarification about POST and PUT! | |
| Aug 4 at 16:44 | comment | added | Heinlein | @browsermator static.php is part of Magento 2 crm, it should not be accessed directly and indeed gives a 500 error if called instead of index.php. You can check it at github.com/magento/magento2/blob/2.4-develop/pub/static.php if you're interested. Strangely it was also modified around time info.php was edited, but what's left is just an empty line after original code. Info.php is indeed my file, forgot to hide it after checking server config. They've got 200 after POST request because malicious code that was executing command on server sent via POST request was injected. | |
| Aug 4 at 16:34 | comment | added | Heinlein | @ja1024 Checked the logs -- it's strange, but there are no successful requests to any part of the application circa time the file was modified, except shown in the log above. | |
| Aug 4 at 16:32 | vote | accept | Heinlein | ||
| Aug 2 at 20:38 | comment | added | browsermator | PUT and POST verbs allowing direct uploads and changing of data was from the old old old days of the internet's REST protocol. (when it was a closed network of trusted clients) Not to be confused with frameworks marketed as a "RESTful" API of some sort. (they brought back the old verbs, but not in the same way... things used to be truly state-less... but again that was in the very old days) | |
| Aug 2 at 20:23 | comment | added | browsermator | can you include code for "static.php"? It's interesting that they caused a 500 error when posting to it. What is that used for? Also "info.php" (I think generally that leaks a lot of data about your server... is that your file?) They actually got a 200 response from a POST to that, which seems odd. They seemed to be probing for previous infections before that. | |
| Aug 2 at 19:51 | comment | added | browsermator | simplest way to do this is exploit some backend code that trusts user input... say on a file upload where the backend actually trusts the user's filename. Path traversal, and bam they've uploaded/overwritten a file. (they use your back end code's privileges not their request) | |
| Aug 2 at 19:47 | answer | added | vidarlo | timeline score: 2 | |
| Aug 2 at 19:43 | comment | added | Ja1024 | If you want to investigate the web application first, then check for known vulnerabilities (if it’s a third-party application) and any features that might enable writing a file (like an upload or admin interface). Check the PHP log for possible errors caused during the attack. | |
| Aug 2 at 19:43 | comment | added | Ja1024 | A file cannot simply be overwritten through an HTTP request. If there’s a vulnerability in your web application, then this might enable such an action (regardless of the request method), but nothing of what you’ve shown so far proves this. It could be an entirely different attack vector that didn’t involve the webserver at all, so don’t jump to conclusions. | |
| S Aug 2 at 18:31 | review | First questions | |||
| Aug 2 at 21:14 | |||||
| S Aug 2 at 18:31 | history | asked | Heinlein | CC BY-SA 4.0 |