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.
Comments
plot twist: he is attacking that python3 run as root and this is why there is nothing in HTTP logs
As a start, check open ports with
nmap -F [target]And check that CF can't be bypassed with
curl http s:// DOMAIN.EXAMPLE --resolve 'DOMAIN.EXAMPLE:443:192.0.2.17'(Remove spaces in https address. I added them because I get blocked)
Be aware there is a lot redis vulnerabilities.
The most basic security step was misshandled - properly limited file access rights. Everything else is irrelevant as there is billion ways to compromise system via incorrect permissions. Hackers fantasy is only limitation here.
The "magic" that can happen from a POST request 😬
Is your app actually running under the root user? if yes that's the first thing you need to change asap at least to mitigate/limit damage.
Are you using the WAF on Cloudflare properly configured? It's not impossible to bypass but it can help block many attacks. Although in your case I wonder if you have insecure-file-upload vulnerability or a insecure-file-inclusion one. Do you allow users to upload files? Does your app make request to remote or local resources that are then included and parsed with PHP, where the paths/URLs of those resources can somehow be controller by the user easily (e.g. with just Burp Suite or something)? Does the app make outbound http requests to URLs that can be controlled/provided by users? If yes, there may be a server-side-request-forgery vulnerability that could be abused to query the metadata server for your compute instance and obtain information that could be used to gain access to your machine. I am not up to date with AWS. but in the past at least this could be used to add SSH keys to the metadata of the machine and poof, the attacker can SSH into your machine easily. A while ago Google, which had the same problem, introduced the requirement of a specific header that must be provided with requests to the metadata server, effectively blocking this kind of vulnerabilities (unless you are stupid and let users configure both the URL for outbound requests AND the headers). I am not sure if Amazon does something similar. Anyway user uploads, file inclusion and SSRF are something you would need to check.
As for Cloudflare, I echo what someone else said about the fact that the attacker might actually be bypassing it altogether, so it's useless. There are tools like SecurityTrails and others that allow you to find the IPs of the origin servers behind Cloudflare, if for example TLS certificate requests have been issued from the origin servers, which is something you need to do when you use the "Strict" TSL configuration in Cloudflare.
Me too, it happens to the best. Via a WP a tier Linkedin authentication plugin ... I got a registration message. While subscriptions are disabled ;p
No new member on the WP, but modified files. A backup, deactivate all plugins 90mn later it was solved ... Nothing since 48h, except access attempts in the logs. In short, probably a robot on a new flaw ...
Yep, nobody's safe ...
I change my folder rules, I change them to other users, for example I create a new user, and I add them all to the folder with the new user created.
For example I create a new user, and I add them all to the folders with the new user created, and I do not allow root to have access to the folders, and also in the management of the servers in htop, I change everything to a new user.
and lastly root also you must block from your ssh access and change port, it is mandatory.
and the php I use is PDO, it is more secure. if you want to avoid these things, use Laravel or PDO.
this is only php and mysql? or wordpress? if it is wordpress, every now and then, i read news of hacking very often.
To detect and monitor changes in the file system using the inotify function, you can use the inotify-tools package. This package includes command-line programs that provide an interface to inotify, allowing you to monitor filesystem events on Linux. You can install inotify-tools on major Linux distributions such as Ubuntu, Debian, Fedora, and CentOS using the package manager specific to your distribution. Once installed, you can use the inotifywait and inotifywatch commands to monitor and react to filesystem events in real time. Additionally, consider using the libnotify-bin package for desktop notifications and automation. These tools provide a simple and efficient way to monitor changes in the filesystem using the inotify function.
bruh are you sure thats not your developer trolling you?
Thats what i was thinking too
Plot twist: it is his developer who is hacking him...
Have you paid your developer on-time?
I love the way this starts as "do you think the problem is with PHP its self"
Consider all your infra (absolutely everything) compromised and start again clean room..
Not enough especially if the issue is inside your Code. You need to find that hole and patch it. As others have mentioned, I recommend getting professionals to look at it.
Thank you for answer.
As expected, there was a file modification today.
Python3 is used in aaPanel, so let's take a look at it.
Is there anyone you can recommend?
https://rack911labs.ca/
I contacted them.
Dockerize your application and use a single writable volume for data. If your app is ever compromised, just restart the container and all changes to the app are reversed.
That's a terrible idea. If app is compromised having an immutable file system doesn't reverse any data leaked from your persistent storage (customer data, account data etc..) or data changed (e.g. casino balance inflated etc..). You need to spend money, probably looking at around 10k for decent audit and then fully managed dedicated hosting as tbf you have not got a good grasp on this, if you're paying for CF enterprise already then I suspect this is a cost of business you can cover.
Exactly. That combined with some remote logging would be a pretty neat approach to figure out what's going on but then he's still toying around looking for ways to "isolate the issue to public_html", so i somewhat doubt he'll make much out of it.
At this point file permissions, cloudflare, the hosting service, what php functions are blocked, "tamper-proof software", etc are all irrelevant. You also can't trust any audit logs on the machine itself when the hacker can modify/delete them. Its a waste of time for anybody here to try and remotely help you because it will take 1000x back and forth questions and the issue could be in your application code anyway.
You never even mentioned if you setup a clean environment/reinstalled from scratch on AWS or after discovering the initial hack. The hacker probably added a backdoor e.g. their own account in the sudoers/wheel and a reverse shell and has been using that the whole time.
A professional security firm, or some of your own employees who know what they're doing are what you need. Not this thread.
I'm struggling to keep track of and upload changed files using rsync on a remote server.
The hacker detected this, modified the file, and prevented it from being deleted or edited.
I recovered the file after chattr -i index.php.
How can I prevent root access right now?
AWS only migrated public_html after a clean installation in a clean state.
You are running around like a headless chicken here, it is clear you need expert help if you're starting to undo chattr +i, if there money in the business go hire someone, also where does AWS come in?
I am quite up to speed on how AWS paid support works and it's limitations, they ain't logging into a severely compromised EC2 and moving around public_html folder for you - they well aware of their liability when dealing with support cases. Have you got another company confused with AWS?
and aapanel in production.... seriously bro?
Please research further and find a good panel to be used.
Assume the data will leak. Encrypt data that you can't afford to leak with a passphrase supplied at runtime (not stored in some config file).
if equifax can have a data breach, a leak from a PHP app by an independent developer isn't really a gold mine of information for the hacker, so the bigger problem isn't the data leak but that the hacker can destroy the database or encrypt it for ransom, but this can be mitigated with a file system capable of snapshots like btrfs or zfs. Take hourly snapshots and you'll never lose more than an hour's worth of data.
There is no generalized way of "preventing root access" short of "fixing the exploit". As others have said, you'd probably be better off getting an actual expert on the job.
I'm not 100% what your actual setup is here but i can tell you that it's not a good way to detect changes. You'll want to send events to another server in real time (i.e. for example the inotify approach mentioned above logging to a file combined with something like
tail -f log | ssh [email protected] 'cat > remote_log'in the simplest case - there's probably actual dedicated remote logging schemes but the one-liner would pretty much do the job quick and dirty style). Everything else will not be safe from manipulation.You should actually reinstall the application and restore nothing but the actual data(-base) as even your web files might contain backdoors after intrusion.
While likely not that probable a sufficiently skilled attacker will just dump the decryption key from RAM. It's obviously still better than plaintext though.
Those filesystems are capable of taking snapshot and storing them remotely? If not the attacker will also control the snapshots and is free to encrypt them too or even just simply delete them. While there's a chance this will be overlooked or simply not anticipated by an automated attack chances for it providing no added safety at all are way higher than with the encryption key stored in RAM. If the attacker is able to root the box any kind of data is only safe from manipulation if it isn't stored on the box to begin with.
that's why it needs to be containerized. you can create an image without a shell at all and no utilities and there's nothing for the attacker to break "out" into.
zfs can, but I'm talking about zfs on native host and the app/database running inside a container. everything the attacker sees is virtual, including the disk and file system. Just like an LXC-based vps... try to break out of that into the host if you can.
I see. Yeah, if the actual system is separated (with something a little harder to break out from than a chroot) from the php application that would make sense (assuming it's really the php app which is at fault here). It's pretty much still just a stop gap to gain time for actually fixing the underlying problem though.
What was the content of the modified file, and how did the hacker contact you?