Money doesn't grow on trees. And, Linux Advocates is growing. Naturally, we anticipate operating costs and hope to be able to meet them.
But, any amount you feel you are able to donate in support of our ongoing work will be most surely appreciated and put to very good use. Your contributions keep Linux Advocates growing.
Moderators, PLEASE stop modding biters up. A visible biter highlights the invisible troll he's biting and the dumbass stupid enough to respond to a troll should be modded "troll" as well as the troll he's biting. I biter is as bad as a troll!
I think I'll do a little metamoderating. I hope I run across the ignorant comment I'm responding to.
There's a spammer that posts a huge rant mentioning hosts files. The filter doesn't stop that, but it wouldn't let the GGP post a code snippet.. The downmod is from someone that doesn't get the irony.
No, all apaches are vulnerable - if the binary is replaced in this way. cPanel doesn't use packaged binaries for apache, and therefore you can't spot if you've been hacked *by simple use of the package manager*.
According to the threads I read, all are vulnerable. Since the binary is not changed on disk, vidating checksums won't detect this. They really did not go into much detail in any of the reading I got following TFA three levels deep. No versions, no rigs, no mods, etc.. Did you read outside of TFA that it was CPA el only? Sittin in the dr office now, have to read more when back at the office.
It's a cpanel vulnerability, Apache is merely modified by the payload to help it spread. Seriously, giving a web server process root -- what the hell are those guys thinking?
That is why this thing is overhyped. Yes it's a problem but only on grossly msiconfigured servers. They might as well left the Root password as "password"
I worked at an ISP using cPanel for a couple hundred shared servers... Let me just say that cPanel is the biggest hunk of crap out there. It is poorly written with no attention paid to security. It is squarely aimed at end-users who have no clue about system administration and has a penchant for letting those same people shoot themselves in the foot as often as possible. cPanel, for instance, lets you format/partition hard drives via the gui without much in the way of instructions or warnings rega
it's just to bad that it doesn't fire an actual bullet into their foot or at least zap em good when they screw up. Might help educate some of those damn PEBKAC issues
by Anonymous Coward writes:
on Monday April 29, 2013 @12:13PM (#43581539)
Here's another link [welivesecurity.com] about this issue.
Seems systems with cPanel installed are getting hit with this. Better get a hash of your current apache executable so you can easily check it down the road.
That won't work for this particular attack surface, because cPanel installs Apache itself and doesn't use a package manager. As far as rpm is concerned, Apache isn't installed to verify.
In our previous posts, we recommended the utilization of tools like “rpm -Va” or “rpm -qf” or “dpkg -S” to see if the Apache modules were modified. However, those techniques won’t work against this backdoor. Since cPanel installs Apache inside/usr/local/apache and does not utilize the package managers, there is no single and simple command to detect if the Apache binary was modified.
Yeah, you'd be vulnerable if your apache installation is done using cpanel (as many hosting providers are).
rkhunter and chkrootkit as a quick example. two tools which are more or less set and forget, and which also target workstation users. (Done in background periodically, no interaction required, except running a small command after an update to avoid triggering false positive in one case)
Probably hundreds of sysadmin-oriented tools can do it too.
(checking files for modification is a very sane step to protect against corruption and possible compromise)
having the/usr mount read-only and only/var,/tmp & co read-write is a rather sane measure which is also wide spread (not only on big server farms, on the technical grounds that the/usr might be served over the network. but even some smart-phone do it, webOS for example)
On the other hand, a trojan targeting Linux is a proof that Linux server *are* a very valuable infection target, and lower markter share at the desktop isn't the only valid argument explaining the scarcity of Linux viruses.
And I liked how they left out whatever it inserts (or deletes from) the httpd.conf file
On cPanel-based servers, instead of adding modules or modifying the Apache configuration, the attackers started to replace the Apache binary (httpd) with a malicious one.
So tell us what exactly it inserts (or deletes from) the httpd.conf file without modifying the Apache configuration?
It's completely invisible, as long as you're blind.
The timestamp, permissions and owner are the same as the rest of the associated files (this infection isn't stupid). I'm sure you could use your x-ray vision to see that it's been replaced by a malicious copy. Please share your expertise with the rest of us.
The timestamp, permissions and owner are the same as the rest of the associated files (this infection isn't stupid). I'm sure you could use your x-ray vision to see that it's been replaced by a malicious copy. Please share your expertise with the rest of us.
rpm -V also checks the MD5 sum of the file - if it's been modified, it should flag a difference in checksums, even if every other bit of metadata is the same.
That said, it's quite easy to believe that lots of people aren't running "rpm -V httpd" regularly on their Linux servers, so all the people responding "DUH, NOOBZ" just sound like dicks. Next time, they should probably try showing off their deep knowledge of rpm by helpfully suggesting "rpm -V will find this, and you should be running this on all your
TFA actually says that "rpm -V" (or debsums or whatever) doesn't detect it because the vulnerable software is not installed through the package manager, and so is not present in the package database. It's still a modified executable, so tripwire or another host-based intrusion detection system will see it, if it's configured to monitor stuff in/usr/local.
I read TFA..and the article they point to and then the article that *that* article points to and none of them say anything about the checksum....EXCEPT...
"We also recommend using debsums for Debian or Ubuntu systems and `rpm –verify` for RPM based systems, to verify the integrity of your Apache web server package installation. (However, remember to temper this advice with the reality that the package
Half right. It doesn't say "the checksum doesn't change" - it points out that cPanel doesn't use a packaging system to install apache - and so rpm -V won't detect changes made to files that weren't installed by rpm in the first place.
Tripwire (or other similar admin tools) can easily detect changes to the binary since a known-good baseline was taken, and report those out to you, as well.
I read and searched TFA (net-security.org and blog.sucuri.net), and the words "sum", "hash", and "checksum" do not occur on either page.
The closest it comes is saying that the timestamp is the same as the original, and that rpm -V won't work IF you use cPanel--because that's outside the package management system.
They suggest grepping for open_tty, though it would be possible to circumvent that with upx... in which case file would report a corrupted ELF file.
Any host-based intrusion detection system will have a hash of the executable, and will report when it changes. This is not some new cutting-edge security precaution, it's routine for many, many installations.
Interestingly enough the modified httpd is apparently write protected the same way. At least according to a google translation of a new article referenced from the wikipedia article on cPanel. http://en.wikipedia.org/wiki/CPanel#cite_note-11
Which of course makes for easy detection (lsattr -R), if you don't use chattr yourself.
Exactly. Almost all rooted servers I've seen have the modified binaries (that hide things) made immutable. Insanely stupid. I don't know anyone that uses immutability for anything under normal circumstances so immutable files will stand out.
A daily scan like this: find / -type f -exec lsattr -a {} \; | grep -- '----i'
will find all immutable files on your system.
Run it from a crontab and you'll get notified by mail. It produces no output when it doesn't find anything so you'll only get a mail when something i
Technically, this isn't apache. It's more like a pod-person version of apache (a modified binary replaces/usr/sbin/httpd or/usr/local/sbin/httpd outside of apache's control).
This looks like a module for apache that, while sinister and clever, must be installed like any other module. Presumable, unless I'm missing something, this requires root access. If this so called "back door" (debatable) is on a system where it shouldn't be there is a bigger question on how was access to install it obtained it the first place.
I did. I probably over-read because I got caught up in 3 other articles about the subject. I'm sorry about the confusion. My main point stands. The real issue is that this requires an insecure system in the first place.
This looks like a module for apache that, while sinister and clever, must be installed like any other module. Presumable, unless I'm missing something, this requires root access. If this so called "back door" (debatable) is on a system where it shouldn't be there is a bigger question on how was access to install it obtained it the first place.
Yes, sort of confusing. What I gained from the various articles is that by visiting a malicious webpage on a compromised server, it will try to install the backdoor thru whatever methods it has. What they aren't that specific on is how they manage to replace the apache executable. But since it seems there isn't a standard way to tell if apache is infected, that is sort of stupid.
We also don’t have enough information to pinpoint how those servers are initially being hacked, but we are thinking through SSHD-based brute force attacks.
They didn't really find a backdoor in Apache, rather they found a modified httpd with some interesting new features installed on otherwise compromised servers. It's not an Apache problem. If you keep your servers secure in first place, you won't have this problem.
It sounds like a FUD campaign by a commercial competitor of Linux. It's full of deceptive headlines and there is zero substance on how the infection works. So we have to infer that it is 100% propaganda.
That seems like a pretty significant trace. Check the MD5 yourself. You can check it with 'debsums', you don't even have to set it up unlike tripwire [sourceforge.net].
Surely detection is pretty easy if the httpd binary has been modified, most distributions already have features to check the binaries on a system against known checksum lists from the packages they were installed from, so a modified httpd would stick out like a sore thumb.
Given that you didn't mention what tools you could use to compare the checksums to the package tells me that you, and most others aren't checking packages on a regular basis.
Maybe I missed it, but I don't see any details on how httpd gets compromised in the first place? Is there a zero-day vulnerability in apache that allows itself to be overwritten?
"ESET researchers.. have been analyzing a new threat affecting Apache webservers. The threat is a highly advanced and stealthy backdoor.. Researchers have named the backdoor Linux/Cdorked.A, and it is the most sophisticated Apache backdoor seen so far"
How does this advanced threat get onto the Apache webservers in the first place?
What is with the hyper-sensationalized reports of "advanced and stealthy" Apache vulnerabilities lately? First darknet, now Cdorked? It is clearly FUD, as even the least competent systems administrator could confirm.... Neither of these security issues have anything at all to do with Apache except that they target the Apache binaries for modification.
The only vulnerability here is that for some reason you allowed your server to get rooted. Neither of these attacks can be carried out without root access,
Interesting, I didn't know about it. I think they made a mistake but it's a simple one to undo for server administrators as it's a configuration switch. Check at the end of this file [github.com]. Furthermore it's up to the applications to honor the flag, the web server is just a middleman here, right?
If all else fails, immortality can always be assured by spectacular error.
-- John Kenneth Galbraith
http://www.linuxadvocates.com/p/support.html (Score:-1)
Dear Linux Advocate,
Money doesn't grow on trees. And, Linux Advocates is growing. Naturally, we anticipate operating costs and hope to be able to meet them.
But, any amount you feel you are able to donate in support of our ongoing work will be most surely appreciated and put to very good use. Your contributions keep Linux Advocates growing.
Show your support by making a donation today.
Thank you.
Dieter T. Schmitz
Linux Advocates, Owner
http://www.linuxadvocates.com/p/support.html [linuxadvocates.com]
Re: (Score:0)
I rather preferred the APK spam.
Re: (Score:3)
I rather preferred the APK spam.
At least this is shorted and less offensive to the eye.
Spam is spam, though.
Re: (Score:0)
Moderators, PLEASE stop modding biters up. A visible biter highlights the invisible troll he's biting and the dumbass stupid enough to respond to a troll should be modded "troll" as well as the troll he's biting. I biter is as bad as a troll!
I think I'll do a little metamoderating. I hope I run across the ignorant comment I'm responding to.
Re: (Score:0)
maybe he's part of the wachootoo tribe... apparently they're biters
Re: (Score:0)
This whole story is inverse-spam, AKA Microsoft FUD.
I hate this new corporate-friendly Slashdot - it's all just so banal.
doesn't look so scary (Score:5, Insightful)
Only cpanel apaches vulnerable and modified httpd easily found by grep'ing a string?
*yawn*
Re:doesn't look so scary (Score:5, Funny)
Yeah, and I'm sure you could fix it with an apropriate hosts file.
Re: (Score:1)
Yeah, and I'm sure you could fix it with an apropriate hosts file.
LAWLZLAWLZLAWLZ
Re: (Score:1)
Doh. It's not like commenters on a nerd site want to post code-like text that may contain repetition.
Re: (Score:2)
Is redirection to ::1 all the rage for hosts files these days? I'm out of touch.
Re: (Score:0)
There's a spammer that posts a huge rant mentioning hosts files. The filter doesn't stop that, but it wouldn't let the GGP post a code snippet.. The downmod is from someone that doesn't get the irony.
Re: (Score:3, Interesting)
No, all apaches are vulnerable - if the binary is replaced in this way. cPanel doesn't use packaged binaries for apache, and therefore you can't spot if you've been hacked *by simple use of the package manager*.
Re:doesn't look so scary (Score:5, Insightful)
Re: doesn't look so scary (Score:3)
Re:doesn't look so scary (Score:5, Insightful)
It's a cpanel vulnerability, Apache is merely modified by the payload to help it spread. Seriously, giving a web server process root -- what the hell are those guys thinking?
Re:doesn't look so scary (Score:4, Insightful)
Bingo.
That is why this thing is overhyped. Yes it's a problem but only on grossly msiconfigured servers. They might as well left the Root password as "password"
Re:doesn't look so scary (Score:4, Funny)
They might as well left the Root password as "password"
You can change it ???
Re:doesn't look so scary (Score:5, Funny)
They might as well left the Root password as "password"
You can change it ???
Don't worry, I already did it for you!
Re:doesn't look so scary (Score:4, Funny)
They might as well left the Root password as "password"
You can change it ???
Yes, but it's a bad idea. Think of changed passwords as security through obscurity.
Re: (Score:0)
Re: (Score:2)
Re: (Score:2, Funny)
incorrect is much better choice, that way the system reminds you if you forget it
Re: (Score:1)
I use "Iforgot"
Re: (Score:1)
That's inefficient password usage.
My root password is "12345". That way both my web server and luggage are secured.
Re: (Score:1)
Re: (Score:2)
What distro ships apache as root? Haven't seen it in a looong time
Re: (Score:3)
I worked at an ISP using cPanel for a couple hundred shared servers... Let me just say that cPanel is the biggest hunk of crap out there. It is poorly written with no attention paid to security. It is squarely aimed at end-users who have no clue about system administration and has a penchant for letting those same people shoot themselves in the foot as often as possible. cPanel, for instance, lets you format/partition hard drives via the gui without much in the way of instructions or warnings rega
Re: (Score:2)
it's just to bad that it doesn't fire an actual bullet into their foot or at least zap em good when they screw up. Might help educate some of those damn PEBKAC issues
Does it hurt? (Score:5, Funny)
Getting Cdorked in the backdoor sounds painful.
Re: (Score:2)
It hurts less with this.. http://www.rfxn.com/projects/linux-socket-monitor/ [rfxn.com]
Another Link (Score:4, Informative)
Here's another link [welivesecurity.com] about this issue.
Seems systems with cPanel installed are getting hit with this. Better get a hash of your current apache executable so you can easily check it down the road.
Wow (Score:5, Insightful)
"other than a modified 'httpd' file,"
It's completely invisible, as long as you're blind.
Re:Wow (Score:5, Insightful)
when was the last time you checked your httpd file?
Re:Wow (Score:4, Informative)
rpm -V httpd ?
Not that difficult to put in a cron job.
Re:Wow (Score:4, Interesting)
Who even does that in the first place? OpenBSD gives you a daily email containing all changes to config files that have occurred.
Re:Wow (Score:5, Informative)
Re: (Score:0)
Tripwire can hash binaries? md5 sums of hosted applications such as apache is pretty common.
Re: (Score:0)
rpm -V httpd ?
Not that difficult to put in a cron job.
Now that you know about it. Synerg1y has it right.
Re:Wow (Score:5, Informative)
rpm -V httpd ?
That won't work for this particular attack surface, because cPanel installs Apache itself and doesn't use a package manager. As far as rpm is concerned, Apache isn't installed to verify.
Re:Wow (Score:5, Insightful)
The solution to this is be a big boy and don't use cPanel.
Re:Wow (Score:4, Informative)
rpm -V httpd ?
Not that difficult to put in a cron job.
Cited FA [sucuri.net]:
In our previous posts, we recommended the utilization of tools like “rpm -Va” or “rpm -qf” or “dpkg -S” to see if the Apache modules were modified. However, those techniques won’t work against this backdoor. Since cPanel installs Apache inside /usr/local/apache and does not utilize the package managers, there is no single and simple command to detect if the Apache binary was modified.
Yeah, you'd be vulnerable if your apache installation is done using cpanel (as many hosting providers are).
Re: (Score:0)
Every 15 minutes when my config management system checksums and reports the diff for it.
Re:Wow (Score:5, Informative)
when was the last time you checked your httpd file?
If you're using tripwire or another similar tool and its properly configured, then you should be notified of file changes.
As long as you're paying attention, this doesn't seem like much of an issue.
Re: (Score:0)
Until tripwire or another similar tool gets replaced too.
Just of the top of my head... (Score:4, Informative)
rkhunter and chkrootkit as a quick example.
two tools which are more or less set and forget, and which also target workstation users.
(Done in background periodically, no interaction required, except running a small command after an update to avoid triggering false positive in one case)
Probably hundreds of sysadmin-oriented tools can do it too.
(checking files for modification is a very sane step to protect against corruption and possible compromise)
having the /usr mount read-only and only /var, /tmp & co read-write is a rather sane measure which is also wide spread (not only on big server farms, on the technical grounds that the /usr might be served over the network. but even some smart-phone do it, webOS for example)
On the other hand, a trojan targeting Linux is a proof that Linux server *are* a very valuable infection target, and lower markter share at the desktop isn't the only valid argument explaining the scarcity of Linux viruses.
Re: (Score:0)
This morning. Although it was because a temporary glitch was best handled by a new mod_rewrite rule before software could be patched...
Prior to that, last week...
But I suspect I'm a bit more devops than a lot of /.
Re: (Score:3)
when was the last time you checked your httpd file?
This morning, debsum and rkhunter didn't report anything that requires attention.
Re: (Score:2)
Mine is checked daily by debsums, along with all other binaries.
Re: (Score:0)
Right. And I liked how they left out whatever it inserts (or deletes from) the httpd.conf file.
Ah the Monday FUD.
Re: (Score:3)
And I liked how they left out whatever it inserts (or deletes from) the httpd.conf file
So tell us what exactly it inserts (or deletes from) the httpd.conf file without modifying the Apache configuration?
Re: (Score:0)
"other than a modified 'httpd' file,"
It's completely invisible, as long as you're blind.
The timestamp, permissions and owner are the same as the rest of the associated files (this infection isn't stupid). I'm sure you could use your x-ray vision to see that it's been replaced by a malicious copy. Please share your expertise with the rest of us.
Re: (Score:1)
The timestamp, permissions and owner are the same as the rest of the associated files (this infection isn't stupid). I'm sure you could use your x-ray vision to see that it's been replaced by a malicious copy. Please share your expertise with the rest of us.
md5sum /usr/sbin/httpd
Re: (Score:3)
rpm -V also checks the MD5 sum of the file - if it's been modified, it should flag a difference in checksums, even if every other bit of metadata is the same.
That said, it's quite easy to believe that lots of people aren't running "rpm -V httpd" regularly on their Linux servers, so all the people responding "DUH, NOOBZ" just sound like dicks. Next time, they should probably try showing off their deep knowledge of rpm by helpfully suggesting "rpm -V will find this, and you should be running this on all your
You are the noob (Score:2)
Re: (Score:0)
TFA actually says that "rpm -V" (or debsums or whatever) doesn't detect it because the vulnerable software is not installed through the package manager, and so is not present in the package database. It's still a modified executable, so tripwire or another host-based intrusion detection system will see it, if it's configured to monitor stuff in /usr/local.
Re: (Score:0)
I read TFA..and the article they point to and then the article that *that* article points to and none of them say anything about the checksum....EXCEPT...
http://www.welivesecurity.com/2013/04/26/linuxcdorked-new-apache-backdoor-in-the-wild-serves-blackhole/
"We also recommend using debsums for Debian or Ubuntu systems and `rpm –verify` for RPM based systems, to verify the integrity of your Apache web server package installation. (However, remember to temper this advice with the reality that the package
Re: (Score:2)
Half right. It doesn't say "the checksum doesn't change" - it points out that cPanel doesn't use a packaging system to install apache - and so rpm -V won't detect changes made to files that weren't installed by rpm in the first place.
Tripwire (or other similar admin tools) can easily detect changes to the binary since a known-good baseline was taken, and report those out to you, as well.
Re: (Score:1)
I read and searched TFA (net-security.org and blog.sucuri.net), and the words "sum", "hash", and "checksum" do not occur on either page.
The closest it comes is saying that the timestamp is the same as the original, and that rpm -V won't work IF you use cPanel--because that's outside the package management system.
They suggest grepping for open_tty, though it would be possible to circumvent that with upx...
in which case file would report a corrupted ELF file.
Re: (Score:0)
debsums does the same for debian/ubuntu users by the way.
Re: (Score:2)
Well for n00bs like you, yes. you will never see it.
The rest of us get a tripwire alert that a watched binary was changed. You are using security software on your publicly accessed servers right?
Re: (Score:2)
Any host-based intrusion detection system will have a hash of the executable, and will report when it changes. This is not some new cutting-edge security precaution, it's routine for many, many installations.
chattr +i anyone? (Score:2)
chattr +i anyone?
just unchattr when you need to update httpd/apache
more interesting is where the hole/holes are in cpanel
Re: (Score:1)
Interestingly enough the modified httpd is apparently write protected the same way. At least according to a google translation of a new article referenced from the wikipedia article on cPanel. http://en.wikipedia.org/wiki/CPanel#cite_note-11
Re: (Score:2)
interesting, the backdoor uses chattr
Re: (Score:1)
Which of course makes for easy detection (lsattr -R), if you don't use chattr yourself.
Re: (Score:2)
Which of course makes for easy detection (lsattr -R), if you don't use chattr yourself.
Exactly. Almost all rooted servers I've seen have the modified binaries (that hide things) made immutable. Insanely stupid. I don't know anyone that uses immutability for anything under normal circumstances so immutable files will stand out.
A daily scan like this:
find / -type f -exec lsattr -a {} \; | grep -- '----i'
will find all immutable files on your system.
Run it from a crontab and you'll get notified by mail. It produces no output when it doesn't find anything so you'll only get a mail when something i
I thought with Apache I was impregnable. (Score:0)
Re: (Score:0)
please, do elaborate
Re: (Score:2)
I must be missing something.. (Score:1)
How are they gaining access to the server to install their malicious software?
Re: (Score:1)
cpanel
It's bad, but is this really a back-door? (Score:5, Interesting)
This looks like a module for apache that, while sinister and clever, must be installed like any other module. Presumable, unless I'm missing something, this requires root access. If this so called "back door" (debatable) is on a system where it shouldn't be there is a bigger question on how was access to install it obtained it the first place.
Re: (Score:1)
Re: (Score:3)
I did. I probably over-read because I got caught up in 3 other articles about the subject. I'm sorry about the confusion. My main point stands. The real issue is that this requires an insecure system in the first place.
Re: (Score:0)
A shitty idiot tool called cpanel is insecure and a commercial company proved it to damage the reputation of Linux. COINTELPRO-style.
Not a single capable expert Linux admin uses the cpanel shit.
Re: (Score:0)
Wrong.
Just about every web hosting outfit has cpanel on their servers for the convenience of their less tech savvy customers.
Re: (Score:3)
This looks like a module for apache that, while sinister and clever, must be installed like any other module. Presumable, unless I'm missing something, this requires root access. If this so called "back door" (debatable) is on a system where it shouldn't be there is a bigger question on how was access to install it obtained it the first place.
Yes, sort of confusing. What I gained from the various articles is that by visiting a malicious webpage on a compromised server, it will try to install the backdoor thru whatever methods it has. What they aren't that specific on is how they manage to replace the apache executable. But since it seems there isn't a standard way to tell if apache is infected, that is sort of stupid.
But other then that, it sounds a bit clever.
Not really a backdoor in Apache (Score:1)
We also don’t have enough information to pinpoint how those servers are initially being hacked, but we are thinking through SSHD-based brute force attacks.
They didn't really find a backdoor in Apache, rather they found a modified httpd with some interesting new features installed on otherwise compromised servers. It's not an Apache problem. If you keep your servers secure in first place, you won't have this problem.
Re: (Score:0)
It sounds like a FUD campaign by a commercial competitor of Linux. It's full of deceptive headlines and there is zero substance on how the infection works. So we have to infer that it is 100% propaganda.
Does not leave traces on the hard-disk... (Score:2, Insightful)
other than a modified 'httpd' file.
That seems like a pretty significant trace. Check the MD5 yourself. You can check it with 'debsums', you don't even have to set it up unlike tripwire [sourceforge.net].
Finally, a reason to compromise servers (Score:2)
Back in the day, people broke into servers for fun.
Now, people break into servers to serve advertising.
Soon, people will break into servers to drop bitcoin miners on them.
I guess now we know where the real money is: ad impressions. What Ad networks serve ads to the cracker community?
Re: (Score:2)
Already happening. [infoworld.com]
Detection (Score:3)
Surely detection is pretty easy if the httpd binary has been modified, most distributions already have features to check the binaries on a system against known checksum lists from the packages they were installed from, so a modified httpd would stick out like a sore thumb.
Bad sysadmins (Score:1)
Given that you didn't mention what tools you could use to compare the checksums to the package tells me that you, and most others aren't checking packages on a regular basis.
Re: (Score:3)
Because they are distribution specific...
rpm -v
debsums
equery check
Partial reading of Subject... (Score:2)
"Apache Backdoor in the Wild"
Am I the only one who initially pictured a rear entrance to a teepee in the countryside?
Re: (Score:0)
Re: (Score:0)
"Apache Backdoor in the Wild"
Am I the only one who initially pictured a rear entrance to a teepee in the countryside?
Rear entrance, yes. In the countryside, yes. But not to a teepee, no.
How does httpd get compromised in the first place? (Score:1)
Maybe I missed it, but I don't see any details on how httpd gets compromised in the first place? Is there a zero-day vulnerability in apache that allows itself to be overwritten?
Method of infection? (Score:4, Insightful)
How does this advanced threat get onto the Apache webservers in the first place?
Anti-apache FUD, just like darknet (Score:1)
What is with the hyper-sensationalized reports of "advanced and stealthy" Apache vulnerabilities lately? First darknet, now Cdorked? It is clearly FUD, as even the least competent systems administrator could confirm.... Neither of these security issues have anything at all to do with Apache except that they target the Apache binaries for modification.
The only vulnerability here is that for some reason you allowed your server to get rooted. Neither of these attacks can be carried out without root access,
Open Source Issues? (Score:1)
Isn't Apache Open Source?
Isn't Open Source the only way to prevent this stuff from getting into the wild?
Are we totally screwed because our last best hope hopeless?
Re: (Score:1)
Re: (Score:2, Insightful)
Well according to the above comments the vulnerability comes from CPanel, which isn't open source.
Re: (Score:2)
They are getting root so that they can install their hacked Apache binary by exploiting holes in Cpanel. Which is closed source.
Sneaky buggers! (Score:0)
It is a high level hack........gov't/porn has great programmers
Re: Apache sucks (Score:1)
This is the most ignorant statement I have ever seen on slashdot.
Re: (Score:2)
Which is irrelevant to the obvious point that this particular item says nothing about whether apache sucks or not.
But sure, tit's not the most ignorant statement that's been posted on slashdot, it's at the top end of the list though.
Re: (Score:2)