Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Sophisticated Apache Backdoor In the Wild

samzenpus posted about a year ago | from the protect-ya-neck dept.

Security 108

An anonymous reader writes "ESET researchers, together with web security firm Sucuri, have been analyzing a new threat affecting Apache webservers. The threat is a highly advanced and stealthy backdoor being used to drive traffic to malicious websites carrying Blackhole exploit packs. Researchers have named the backdoor Linux/Cdorked.A, and it is the most sophisticated Apache backdoor seen so far. The Linux/Cdorked.A backdoor does not leave traces on the hard-disk other than a modified 'httpd' file, the daemon (or service) used by Apache. All information related to the backdoor is stored in shared memory on the server, making detection difficult and hampering analysis."

cancel ×

108 comments

Sorry! There are no comments related to the filter you selected.

http://www.linuxadvocates.com/p/support.html (-1)

Anonymous Coward | about a year ago | (#43581519)

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:http://www.linuxadvocates.com/p/support.html (0)

Anonymous Coward | about a year ago | (#43582085)

I rather preferred the APK spam.

Re:http://www.linuxadvocates.com/p/support.html (2)

RabidReindeer (2625839) | about a year ago | (#43582921)

I rather preferred the APK spam.

At least this is shorted and less offensive to the eye.

Spam is spam, though.

Re:http://www.linuxadvocates.com/p/support.html (0)

Anonymous Coward | about a year ago | (#43590677)

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:http://www.linuxadvocates.com/p/support.html (0)

Anonymous Coward | about a year ago | (#43586689)

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 (5, Insightful)

iggymanz (596061) | about a year ago | (#43581525)

Only cpanel apaches vulnerable and modified httpd easily found by grep'ing a string?

*yawn*

Re:doesn't look so scary (5, Funny)

Eunuchswear (210685) | about a year ago | (#43581567)

Yeah, and I'm sure you could fix it with an apropriate hosts file.

Re:doesn't look so scary (1)

Anonymous Coward | about a year ago | (#43581669)

Yeah, and I'm sure you could fix it with an apropriate hosts file.

LAWLZLAWLZLAWLZ

Re:doesn't look so scary (0)

simplypeachy (706253) | about a year ago | (#43581799)

Or a Privoxy rule: [Redacted] (Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition.)

Doh. It's not like commenters on a nerd site want to post code-like text that may contain repetition.

Re:doesn't look so scary (-1)

Anonymous Coward | about a year ago | (#43581847)

Or a Privoxy rule: [Redacted] (Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition.)

Doh. It's not like commenters on a nerd site want to post code-like text that may contain repetition.

Try appending a host file. That way the filter doesn't think it's spam.... only the readers do.

Re:doesn't look so scary (1)

simplypeachy (706253) | about a year ago | (#43583181)

Is redirection to ::1 all the rage for hosts files these days? I'm out of touch.

Re:doesn't look so scary (3, Interesting)

Anonymous Coward | about a year ago | (#43581577)

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 (4, Insightful)

The Mighty Buzzard (878441) | about a year ago | (#43581771)

All everything is vulnerable if the binary is replaced. There's exactly jack and shit sophisticated about replacing binaries.

Re: doesn't look so scary (2)

s.petry (762400) | about a year ago | (#43583083)

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.

Re:doesn't look so scary (-1)

Anonymous Coward | about a year ago | (#43584463)

This is just the latest iteration of FUD against Linux. We all know who spreads it. I would not be surprised they first created that cpanel shit and then show how to fuck up Apache with their own crap contraption. Welcome to the capitalist world !

Re:doesn't look so scary (4, Insightful)

KiloByte (825081) | about a year ago | (#43581827)

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 (3, Insightful)

Lumpy (12016) | about a year ago | (#43582135)

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 (4, Funny)

Anonymous Coward | about a year ago | (#43582723)

They might as well left the Root password as "password"

You can change it ???

Re:doesn't look so scary (5, Funny)

Anonymous Coward | about a year ago | (#43585073)

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 (3, Funny)

ebno-10db (1459097) | about a year ago | (#43586057)

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:doesn't look so scary (0)

Anonymous Coward | about a year ago | (#43582993)

I foiled them! My root password is "root'!

Re:doesn't look so scary (1)

shaitand (626655) | about a year ago | (#43585863)

I went with "god" it's always the best password!

Re:doesn't look so scary (2, Funny)

Anonymous Coward | about a year ago | (#43584637)

incorrect is much better choice, that way the system reminds you if you forget it

Re:doesn't look so scary (1)

Anonymous Coward | about a year ago | (#43585151)

That's inefficient password usage.

My root password is "12345". That way both my web server and luggage are secured.

Re:doesn't look so scary (0)

quintus_horatius (1119995) | about a year ago | (#43583427)

Well, it was good enough for Microsoft...

Re:doesn't look so scary (1)

tibman (623933) | about a year ago | (#43584241)

What distro ships apache as root? Haven't seen it in a looong time

Re:doesn't look so scary (2)

IMightB (533307) | about a year ago | (#43585357)

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 regarding the potential consequences of this action. We had many calls from people who claimed to have done nothing to their servers but turned out that they were trying to free up space and formatted /var or /. We often joked that we should cretaed a page in the GUI with a bug red button that says "Do NOT push" that would add an iptables rule to drop all connections from that IP and wait for the hilarity to commence.

Re:doesn't look so scary (1)

fast turtle (1118037) | about a year ago | (#43586633)

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? (5, Funny)

geek (5680) | about a year ago | (#43581531)

Getting Cdorked in the backdoor sounds painful.

Another Link (4, Informative)

Anonymous Coward | about a year ago | (#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.

Wow (4, Insightful)

Dr. Evil (3501) | about a year ago | (#43581543)

"other than a modified 'httpd' file,"

It's completely invisible, as long as you're blind.

Re:Wow (4, Insightful)

Synerg1y (2169962) | about a year ago | (#43581573)

when was the last time you checked your httpd file?

Re:Wow (4, Informative)

Poeli (573204) | about a year ago | (#43581607)

rpm -V httpd ?

Not that difficult to put in a cron job.

Re:Wow (3, Interesting)

ArchieBunker (132337) | about a year ago | (#43581667)

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 (5, Informative)

larry bagina (561269) | about a year ago | (#43581747)

httpd isn't a config file; it's the apache executable. Tripwire or other such utilities would catch it.

Re:Wow (0)

Anonymous Coward | about a year ago | (#43583223)

Tripwire can hash binaries? md5 sums of hosted applications such as apache is pretty common.

Re:Wow (0)

Anonymous Coward | about a year ago | (#43581813)

rpm -V httpd ?

Not that difficult to put in a cron job.

Now that you know about it. Synerg1y has it right.

Re:Wow (5, Informative)

ShaunC (203807) | about a year ago | (#43582283)

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 (5, Insightful)

h4rr4r (612664) | about a year ago | (#43582577)

The solution to this is be a big boy and don't use cPanel.

Re:Wow (3, Informative)

c0lo (1497653) | about a year ago | (#43587469)

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:Wow (0)

Anonymous Coward | about a year ago | (#43581657)

Every 15 minutes when my config management system checksums and reports the diff for it.

Re:Wow (5, Informative)

lky (246353) | about a year ago | (#43581685)

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:Wow (0)

Anonymous Coward | about a year ago | (#43582473)

Until tripwire or another similar tool gets replaced too.

Just of the top of my head... (3, Informative)

DrYak (748999) | about a year ago | (#43581881)

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:Wow (0)

Anonymous Coward | about a year ago | (#43582265)

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:Wow (2)

El_Muerte_TDS (592157) | about a year ago | (#43584085)

when was the last time you checked your httpd file?

This morning, debsum and rkhunter didn't report anything that requires attention.

Re:Wow (1)

jrumney (197329) | about a year ago | (#43587211)

Mine is checked daily by debsums, along with all other binaries.

Re:Wow (0)

Anonymous Coward | about a year ago | (#43581635)

Right. And I liked how they left out whatever it inserts (or deletes from) the httpd.conf file.

Ah the Monday FUD.

Re:Wow (2)

Qzukk (229616) | about a year ago | (#43581703)

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?

Re:Wow (0)

Anonymous Coward | about a year ago | (#43581689)

"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:Wow (1)

Anonymous Coward | about a year ago | (#43581901)

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:Wow (2)

Americano (920576) | about a year ago | (#43581999)

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 systems regularly," rather than shitting up the comment thread with "I'm not vulnerable, anybody who is must be a fucking idiot."

You are the noob (1)

s.petry (762400) | about a year ago | (#43583145)

Read TFA, it tells you that the checksum does not change, but you go ahead and think rpm -V will save you

Re:You are the noob (0)

Anonymous Coward | about a year ago | (#43583335)

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:You are the noob (0)

Anonymous Coward | about a year ago | (#43583407)

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 manifest could have been altered by an attacker.)"

That last part may be what you're thinking of but it appears you are the n00b.

BONUS: CAPTCHA="expert"

Re:You are the noob (1)

Americano (920576) | about a year ago | (#43583497)

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:You are the noob (1)

idunham (2852899) | about a year ago | (#43583573)

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:Wow (0)

Anonymous Coward | about a year ago | (#43583309)

debsums does the same for debian/ubuntu users by the way.

Re:Wow (1)

Lumpy (12016) | about a year ago | (#43582201)

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:Wow (1)

Urban Garlic (447282) | about a year ago | (#43583259)

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? (1)

MoFoQ (584566) | about a year ago | (#43582401)

chattr +i anyone?

just unchattr when you need to update httpd/apache

more interesting is where the hole/holes are in cpanel

Re:chattr +i anyone? (1)

Anonymous Coward | about a year ago | (#43582523)

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:chattr +i anyone? (1)

MoFoQ (584566) | about a year ago | (#43582549)

interesting, the backdoor uses chattr

Re:chattr +i anyone? (1)

anyanka (1953414) | about a year ago | (#43586481)

Which of course makes for easy detection (lsattr -R), if you don't use chattr yourself.

I thought with Apache I was impregnable. (0)

Anonymous Coward | about a year ago | (#43581575)

However I was wrong. This could be easily fixed with a slightly modified HOSTS file.

Re:I thought with Apache I was impregnable. (0)

Anonymous Coward | about a year ago | (#43581727)

please, do elaborate

Re:I thought with Apache I was impregnable. (1)

Culture20 (968837) | about a year ago | (#43582309)

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).

Apache sucks (-1, Troll)

Doug Otto (2821601) | about a year ago | (#43581591)

Thanks for the confirmation.

Re: Apache sucks (1)

Anonymous Coward | about a year ago | (#43581731)

This is the most ignorant statement I have ever seen on slashdot.

Re: Apache sucks (-1, Flamebait)

Doug Otto (2821601) | about a year ago | (#43581793)

You must be new if you think that's the most ignorant statement you've ever see here.....

Seriously, I know apache is everywhere but it doesn't perform nearly as well as lighttpd or nginx on high traffic sites. None of them are without their quirks but the difference is night and day in most cases.

Re: Apache sucks (1)

nedlohs (1335013) | about a year ago | (#43583599)

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: Apache sucks (-1)

Anonymous Coward | about a year ago | (#43588927)

tit's

I must be missing something.. (1)

Anonymous Coward | about a year ago | (#43581595)

How are they gaining access to the server to install their malicious software?

Re:I must be missing something.. (0)

KiloByte (825081) | about a year ago | (#43581839)

cpanel

It's bad, but is this really a back-door? (4, Interesting)

dmomo (256005) | about a year ago | (#43581599)

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:It's bad, but is this really a back-door? (1)

bvanheu (1028050) | about a year ago | (#43581739)

Did you RTFA? This is not an apache module.

Re:It's bad, but is this really a back-door? (2)

dmomo (256005) | about a year ago | (#43582025)

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:It's bad, but is this really a back-door? (0)

Anonymous Coward | about a year ago | (#43584523)

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:It's bad, but is this really a back-door? (0)

Anonymous Coward | about a year ago | (#43585217)

Wrong.

Just about every web hosting outfit has cpanel on their servers for the convenience of their less tech savvy customers.

Re:It's bad, but is this really a back-door? (2)

Nyder (754090) | about a year ago | (#43581751)

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 (1)

Anonymous Coward | about a year ago | (#43581785)

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:It's bad, but is this really a back-door? (0)

Anonymous Coward | about a year ago | (#43584545)

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... (2, Insightful)

Anonymous Coward | about a year ago | (#43581663)

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] .

Backdoor? (-1)

Anonymous Coward | about a year ago | (#43581697)

Something the fags on this site are used to going through.

Re:Backdoor? (-1)

Anonymous Coward | about a year ago | (#43582031)

Right, only homos have anal sex.

You're drunk grandpa, go to bed.

Finally, a reason to compromise servers (1)

mveloso (325617) | about a year ago | (#43581707)

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:Finally, a reason to compromise servers (1)

raju1kabir (251972) | about a year ago | (#43582095)

Soon, people will break into servers to drop bitcoin miners on them.

Already happening. [infoworld.com]

Detection (2)

Bert64 (520050) | about a year ago | (#43581721)

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 (1)

Anonymous Coward | about a year ago | (#43581741)

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.

I used to care about Apache (-1)

Anonymous Coward | about a year ago | (#43582093)

but now I don't ever since they patched their software to ignore Do Not Track from web browsers. It's just a matter of time before Nginx takes the bright spot as it's already a better web server than Apache.

Re:I used to care about Apache (1)

pmontra (738736) | about a year ago | (#43583113)

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?

Partial reading of Subject... (1)

Bobfrankly1 (1043848) | about a year ago | (#43583367)

"Apache Backdoor in the Wild"

Am I the only one who initially pictured a rear entrance to a teepee in the countryside?

Re:Partial reading of Subject... (1)

gbkersey (649921) | about a year ago | (#43584959)

Nice... It's about as prevalent as your description :) Thanks!

Re:Partial reading of Subject... (0)

Anonymous Coward | about a year ago | (#43589395)

"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? (1)

Anonymous Coward | about a year ago | (#43584313)

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? (3, Insightful)

dgharmon (2564621) | about a year ago | (#43585227)

"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?

Anti-apache FUD, just like darknet (1)

Anonymous Coward | about a year ago | (#43586931)

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, and if your server is already rooted, a modified httpd binary could end up being the least of your worries. (I'd be willing to bet you got rooted for a really dumb reason like a bad password, and if so, you probably also have extremely stupid practices like keeping plaintext password lists or private keys on the server...in which case, you just gave your entire infrastructure to some script kiddie.)

Open Source Issues? (1)

kwbauer (1677400) | about a year ago | (#43587029)

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:Open Source Issues? (1)

ruir (2709173) | about a year ago | (#43587251)

As if proprietary software also hasn't bigger problemsopen source is supposed to mitigate this problems, and improve the quality of software.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>