A
A
Alexey Nikolaev2016-04-27 23:47:10
Burglary protection
Alexey Nikolaev, 2016-04-27 23:47:10

Is there a system that helps identify the source of the hack (besides the standard logs)?

Goodnight.
There is a server on which site modifications are regularly carried out (there are several of them on the server). Moreover, .htaccess is modified, which allows an attacker to create technically non-existent pages. The code has been checked many times, nothing suspicious has been found. The kernel (ModX latest version) is checked against the source - everything is clean. There is also nothing in the access logs that you can catch on to. I suspect that htaccess is being modified because, for some reason, the attacker has no further access (in fact, all folders are closed, and they could not identify obvious holes either).
There are thoughts to take sites to a level above the root, leaving only the entry point, but I would like to understand the nature of such attacks, and what is the hole - the CMS itself, crooked plugins or hosting problems. Are there ways to track in detail how exactly the access to the server was obtained, from where the file was modified? How is the search for exploits on the site generally carried out if there are no ideas?
Thanks in advance for your advice.

Answer the question

In order to leave comments, you need to log in

2 answer(s)
I
index0h, 2016-04-28
@Heian

checked with the source - everything is clean

And in the database too? I last touched MODx a very long time ago and as far as I remember, it was in fashion to store some of the source codes in the database.
I hope you checked the sources not manually? (in the sense through diff in your VCS + in the database)
This is the first thing to do
0 - If you have more than one entry point in the public directory, but the whole project - you have already shot yourself in the foot
1 - CVEs are searched in the CMS bug tracker
2 - Plugins installed in the system are checked, they may also contain vulnerabilities
3 - The ability to load and execute the file. For example, on uploads (or whatever the directory is called), the rights to launch should be completely absent
4 - Open ports of the server are checked (if mysql, redis, memcached, ... sticks out - then evil Pinocchio themselves)
5 - All possible points are searched with eval/include/require/include_once/require_once/exec/shell_exec/... for third party code this is a potential execution point
6 - Look for possible sql injections by cms/plugins code
7 - Looking for all kinds of phpmyadmin and similar services sticking out
8 - If global variables are actively used in the code - this is a potential security hole
9 - If method arguments are not checked - this is also a potential security hole
10 - You should also make sure that that there is no internal leakage. On one project, I accidentally found phpspy flooded with former employees

M
Mikhail Yesenin, 2019-01-17
@mirzok

There is such a system - it's Auditd. But it seems that you need to identify the root cause of these events, index0h correctly described the search for holes. You can do this either with the help of online security scanners like Pentest-tools , METASCAN , or by hand using popular utilities from the same Kali Linux . :)

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question