new linux malware

NAVIGATION

CATEGORIES

Security

REFERRENCE

If you have some good idea, Cilck and mail to us please...

LINKS

Home » Security

new linux malware
11 answers - 4484 bytes -
Today, we received a notification about a new Linux malware ItW (In the
Wild).
Chas Tomlin (http://www.ecs.soton.ac.uk/~cet/) provided Shadowserver
(http://www.shadowserver.org/) and Nicholas Alright who notified the
relevant operational communities, with the information on the binaries.
He captured them with squil (http://sguil.sourceforge.net/).
Chas is working with Shadowserver to identify better ways to
trackdown/takedown botnets.
*The credit should go to him and Shadowserver*.
Shadowserver has been a responsible and essential part of recent
Internet security activities.
As anti virus vendors have been notified will soon do a write-up on it,
I see no reason not to publicize it here.
MD5:
~/samples/derfiq
~/samples/session
We are not quite sure as of yet exactly what this does, it can be a
Linux virus, a Linux Trojan horse, a Linux worm we are not even sure
if the checksums above are useful at all. We hope to know more soon and
we will update as we do.
There are some interesting strings to be noted:
NTICE %s :TSUNAMI <target<secs= Special
packeter
that wont be blocked by most firewalls
NTICE %s :PAN <target<port<secs= An
advanced syn
flooder that will kill most network drivers
NTICE %s :UDP <target<port<secs= A udp flooder
NTICE %s :UNKNWN <target<secs= Another
non-spoof udp flooder
NTICE %s :NICK <nick= Changes
the nick
of the client
NTICE %s :SERVER <server= Changes
servers
NTICE %s :GETSPFS = Gets the
current
spoofing
NTICE %s :SPFS <subnet= Changes
spoofing
to a subnet
NTICE %s :DISABLE = Disables all
packeting from this client
NTICE %s :ENABLE = Enables all
packeting from this client
NTICE %s :KILL = Kills the
client
NTICE %s :GET <http address<save as= Downloads
a file
off the web and saves it onto the hd
NTICE %s :VERSIN = Requests
version
of client
NTICE %s :KILLALL = Kills all
current packeting
NTICE %s :HELP = Displays this
NTICE %s :IRC <command= Sends this
command to the server
NTICE %s :SH <command= Executes a
command
'session', current detection:
AntiVir6.33.1.50/20060218found [BDS/Katien.R]
Avast4.6.695.0/20060216found nothing
AVG718/20060217found nothing
Avira6.33.1.50/20060218found [BDS/Katien.R]
BitDefender7.2/20060218found nothing
CAT-QuickHeal8.00/20060216found nothing
ClamAVdevel-20060126/20060217found nothing
DrWeb 4.33/20060218found nothing
eTrust-InoculateIT23.71.80/20060218found nothing
eTrust-Vet12.4.2086/20060217found nothing
Ewido3.5/20060218found nothing
Fortinet2.69.0.0/20060218found nothing
F-Prot3.16c/20060217found nothing
Ikarus0.2.59.0/20060217found [Backdoor.Linux.Keitan.C]
Kaspersky4.0.2.24/20060218found [Backdoor.Linux.Keitan.c]
McAfee4700/20060217found [Linux/DDoS-Kaiten]
ND32v21.1413/20060217found nothing
Norman5.70.10/20060217found nothing
Panda9.0.0.4/20060218found nothing
Sophos4.02.0/20060218found nothing
Symantec8.0/20060218found [Backdoor.Kaitex]
TheHacker5.9.4.098/20060218found nothing
UNA1.83/20060216found nothing
VBA323.10.5/20060217found nothing
'derfiq' current detection:
AntiVir6.33.1.50/20060218found [Worm/Linux.Lupper.B]
Avast4.6.695.0/20060216found nothing
AVG718/20060217found nothing
Avira6.33.1.50/20060218found [Worm/Linux.Lupper.B]
BitDefender7.2/20060218found nothing
CAT-QuickHeal8.00/20060216found nothing
ClamAVdevel-20060126/20060217found nothing
DrWeb 4.33/20060218found nothing
eTrust-InoculateIT23.71.80/20060218found nothing
eTrust-Vet12.4.2086/20060217found nothing
Ewido3.5/20060218found nothing
Fortinet2.69.0.0/20060218found nothing
F-Prot3.16c/20060217found nothing
Ikarus0.2.59.0/20060217found [Net-Worm.Linux.Lupper.B]
Kaspersky4.0.2.24/20060218found nothing
McAfee4700/20060217found nothing
ND32v21.1413/20060217found nothing
Norman5.70.10/20060217found nothing
Panda9.0.0.4/20060218found nothing
Sophos4.02.0/20060218found nothing
Symantec8.0/20060218found [Hacktool]
TheHacker5.9.4.098/20060218found nothing
UNA1.83/20060216found nothing
VBA323.10.5/20060217found nothing
This write-up can be found here:
We will notify as we get new updates here:
http://blogs.securiteam.com
Gadi.
No.1 | | 2798 bytes | |
>1. PHP is the "serious" or at least open-source/Linux/security freak's
>choice for web development. Mine as well (although as many still say, Perl
>does a better job).
While PHP is extremely popular, especially in open-source and Linux communities,I am not sure it qualifies as the defacto choice of "serious" web developers.
And I did not think it was as popular in the security community (when I
occasionally scan one of the reports on the frequent PHP based applications
that grace this list, I thought exploit code is as often as not given in
Perl:)
>
>2. Developing secure applications in PHP is difficult, as one of PHP's
>creators said recently - even to him after years of trying.
The number of PHP applications getting reported on bugtraq would seem to
support this, although likely also contributed to the fact that it is popular,
and perhaps that it is (or at least has the reputation of being) of being
easy to program, leading to programs written by people without understanding
of security implications.

My personal knowledge of PHP is somewhat meager, but having had to install
it recently for a developer I find the philosophy of the PHP security options
to be somewhat odd. It almost seemed like the emphasis was on distrusting
the programmer rather than the person running the program. I think it would
strongly benefit from the Perlish concept of data tainting.
>
>3. Staying on top of new PHP vulnerabilities has become impossible, popping
>around everywhere.
While I concede I am less than happy about the frequency with which patched
versions of php come out, and most versions include some security related
patches, I do not think it is impossible. Furthermore, most of the "security"
patches have been rather localized, and affect only a small number of functions
and often only in rather specific circumstances, and with some knowledge of the
PHP applications running on your system you can often leap frog over some
of the versions.

Most bugtraq messages with PHP in the subject appear to be holes in specific
applications, usually due to programming errors on the part of the application
author. This does not mean the language is inherently insecure; although it
may indicate that it is difficult to write secure PHP code. It could also
mean that PHP is easy enough to program that a lot of people without knowledge
of how to program securely are writing PHP code.

Tom Payerle
Dept of Physicspayerle (AT) physics (DOT) umd.edu
University of Maryland(301) 405-6973
College Park, MD 20742-4111Fax: (301) 314-9525
No.2 | | 1428 bytes | |
22/02/06, Kevin Waterson <kevin (AT) oceania (DOT) netwrote:
This one time, at band camp, Gadi Evron <ge (AT) linuxbox (DOT) orgwrote:

3. Staying on top of new PHP vulnerabilities has become impossible,
popping around everywhere.

What vulnerabilities in PHP?
Are implying the fault is within the language itself?

I think Gadi meant vulnerabilities in PHP applications; though the
language doesn't make it particularly easy to write secure code.

This is akin to saying C has vulnerabilites because some script kiddie
wrote a poor application.

Like this ?

"We can give you advice on how to write good cryptographic code. Avoid
any programming language that allows buffer overflows. Specifically:
don't use C or C++" -- Practical Cryptography, Schneier and Ferguson,
(p149 in my copy).

It's a point of view that has something to be said for it. You *can*
write secure code in C and PHP, but it takes a lot of care and most
programmers don't take that care. I've been told privately that one
penetration tester could gain system privileges on the majority of
webservers he checked; that used to surprise me, but doesn't any
longer. I don't whether that's a 'vulnerability', 'disadvantage' or
'feature' of PHP and other scripting languages.

cheers,
Jamie
No.3 | | 2442 bytes | |
PHP, like any and all projects, does indeed have security flaws. So
does MySQL. So does Linux. So does sshd. So does Windows. To claim
that we should abandon any individual service simply because it has
security bugs is absurd. Yes, there are non-trivial problems with
PHP's memory management, but the same could easily be said for Java as
well.

I don't really get Gadi's point. Is he claiming that keeping up to
date on security fixes is too much of a hassle for him? is he
claiming that he doesn't want to use PHP applications, because they
are often riddled with security holes? is he just bitching in
general that there's insecure software out there? It seems like it's
probably the latter. When's the last time you saw a super-secure
program written in Perl, or ColdFusion, or ASP, or any other web
language for that matter? People do buffer overflow attacks on Apache
all the time, is he planning on abandoning that?

Security requires vigilance, get over it.

2/22/06, Kevin Waterson <kevin (AT) oceania (DOT) netwrote:
This one time, at band camp, Gadi Evron <ge (AT) linuxbox (DOT) orgwrote:
--
3. Staying on top of new PHP vulnerabilities has become impossible,
popping around everywhere.

What vulnerabilities in PHP?
Are implying the fault is within the language itself?
This is akin to saying C has vulnerabilites because some script kiddie
wrote a poor application.
--
4. Determining how secure a PHP application is, looking at the code and
for how silly past vulnerabilities were (i.e. looking at the coder
rather than the code) is now more important than the actual application

As with all web based technologies, security should be the foundation of the application

Much like their self criticism said, PHP needs to grow to a far more
secure language, much like we need to chose more carefully what PHP
software we use.
Which self critism is this?
--
Some of us have been joking for a while about creating a script to
choose from different paragraph we create, and email bugtraq
re-assembling the randomly with a new PHP bug and a random PHP
application name every few hours. Would any of us be able to readily
tell the difference?

Perhaps we can do the same for linux kernel problems and blame it on C?

Kind regards
Kevin
--
No.4 | | 1161 bytes | |
Sun, 31 Dec 2006, Kevin Waterson wrote:

This one time, at band camp, Gadi Evron <ge (AT) linuxbox (DOT) orgwrote:

Indeed, the most annoying thing about the PHP worms today is that these
PHP vulnerabilities being exploited are everywhere.

These are not PHP vulnerabilities, these are application vulnerabilities.

I agree. Unless this thread is focusing on vulnerabilities in the
PHP parser itself, exploitable simply by pushing arbitrary information
through any available post/get channel, then I think we can call it a PHP
vulnerability. Until then, let's keep the FUD to a minimum.

*ANY* language implemented for *ANY* purpose is as secure as the
programmer makes it. The way the original post is written,
s/PHP/(Perl|ASP|C|bash|BASIC|four little buddhist monks fighting over an
abacus)/ is applicable. The vulnerabilities that we see, that Gadi refers
to, aren't widespread because PHP is widespread, but because insecure
applications written in PHP are. A better use of energy would be
focusing on the most vulnerable platforms and educating the developers.
- billn
No.5 | | 634 bytes | |
This one time, at band camp, Gadi Evron <ge (AT) linuxbox (DOT) orgwrote:

Indeed, the most annoying thing about the PHP worms today is that these
PHP vulnerabilities being exploited are everywhere.

These are not PHP vulnerabilities, these are application vulnerabilities.

2. Developing secure applications in PHP is difficult, as one of PHP's
creators said recently - even to him after years of trying.

Who said this? do you have a source?

3. Staying on top of new PHP vulnerabilities has become impossible,
popping around everywhere.

Application vulnerabilities

kevin
No.6 | | 703 bytes | |
Bill Nash schrieb:

*ANY* language implemented for *ANY* purpose is as secure as the
programmer makes it. The way the original post is written,
s/PHP/(Perl|ASP|C|bash|BASIC|four little buddhist monks fighting over an
abacus)/ is applicable. The vulnerabilities that we see, that Gadi refers
to, aren't widespread because PHP is widespread, but because insecure
applications written in PHP are. A better use of energy would be
focusing on the most vulnerable platforms and educating the developers.

But aparently they aren't educatable - hence they stick to this
language. (Because of the many bad examples they can cut&paste
code from)

T.
No.7 | | 2060 bytes | |
<Peeve type="pet">
"They" (developers) and "it" (the secure language) are both moving
targets.
There is no "genetic memory" with the human race; any more than there is
an "inherently secure" language. For every developer that learns how to
write "secure code", at least one more starts cutting his/her teeth in
the same language; possibly for the same reasons. Anyone who insists
that there either exists a "secure language" or that the problem of
"secure code" can be "completely solved" is IMH, severely deluded.
Neither will ever be even remotely true.
</Peeve type="pet">

If you have issue with someone's code habits, address it with them
first. This is part & parcel to the "education" process. If this fails
because of their unwillingness or inability to adjust, then you've done
what you can. If this unresolved problem presents a public disservice,
then you report it. Public opinion is a powerful motivator.

Jim

Message
From: Tino Wildenhain [mailto:tino (AT) wildenhain (DOT) de]
Sent: Monday, January 01, 2007 1:00 PM
To: Bill Nash
Cc: Kevin Waterson; bugtraq (AT) securityfocus (DOT) com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux
malware]

Bill Nash schrieb:

*ANY* language implemented for *ANY* purpose is as secure as the

programmer makes it. The way the original post is written,
s/PHP/(Perl|ASP|C|bash|BASIC|four little buddhist monks fighting over
an abacus)/ is applicable. The vulnerabilities that we see, that Gadi
refers to, aren't widespread because PHP is widespread, but because
insecure applications written in PHP are. A better use of energy would

be focusing on the most vulnerable platforms and educating the
developers.

But aparently they aren't educatable - hence they stick to this
language. (Because of the many bad examples they can cut&paste code
from)

T.

All mail to and from this domain is GFI-scanned.
No.8 | | 3484 bytes | |
While I agree that it is poor coding habits on the part of many
developers that are responsible for most PHP application security flaws,
nonetheless there are features in PHP4 which encourage these habits by
choosing insecure defaults. "Magic quotes" was one example.

of the powerful aspects of PHP, and of Perl, is the string-oriented
"typeless" approach where things magically become the appropriate type
(as compared to e.g. C, where you can blithely stuff an integer value
into a float and thereby corrupt the value if not cause a crash of the
runtime library when you feed this garbage to it -- no type conversion.
Strict typing requiring explicit conversion (with validation) improves
security by eliminating certain types of vulnerability. Java held some
promise in this regard but the associated libraries have many bugs
(e.g. one I just hit in JDK 1.507 for http proxy. a bug that wasn't
there in 1.4.2). course, the large number of available library code
is part of the attraction of Perl, Java and PHP; ML, for example, while
I have seen CGI code written in it lacks the broad developer community
(there is one, its just small compared to the more popular languages).

Jim Harrison wrote:
<Peeve type="pet">
"They" (developers) and "it" (the secure language) are both moving
targets.
There is no "genetic memory" with the human race; any more than there is
an "inherently secure" language. For every developer that learns how to
write "secure code", at least one more starts cutting his/her teeth in
the same language; possibly for the same reasons. Anyone who insists
that there either exists a "secure language" or that the problem of
"secure code" can be "completely solved" is IMH, severely deluded.
Neither will ever be even remotely true.
</Peeve type="pet">

If you have issue with someone's code habits, address it with them
first. This is part & parcel to the "education" process. If this fails
because of their unwillingness or inability to adjust, then you've done
what you can. If this unresolved problem presents a public disservice,
then you report it. Public opinion is a powerful motivator.

Jim
--
Message
From: Tino Wildenhain [mailto:tino (AT) wildenhain (DOT) de]
Sent: Monday, January 01, 2007 1:00 PM
To: Bill Nash
Cc: Kevin Waterson; bugtraq (AT) securityfocus (DOT) com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux
malware]

Bill Nash schrieb:

>*ANY* language implemented for *ANY* purpose is as secure as the
>
>

>programmer makes it. The way the original post is written,
>s/PHP/(Perl|ASP|C|bash|BASIC|four little buddhist monks fighting over
>an abacus)/ is applicable. The vulnerabilities that we see, that Gadi
>refers to, aren't widespread because PHP is widespread, but because
>insecure applications written in PHP are. A better use of energy would
>
>

>be focusing on the most vulnerable platforms and educating the
>
developers.

But aparently they aren't educatable - hence they stick to this
language. (Because of the many bad examples they can cut&paste code
from)

T.

All mail to and from this domain is GFI-scanned.
--
No.9 | | 4075 bytes | |
and similar statements can be made for Basic (pickyourflavor) as well.
This argument proves my point that there is no such thing as a truly
"secure" language; it's entirely dependent on the dev skills.

Message
From: Dana Hudes [mailto:dhudes (AT) hudes (DOT) org]
Sent: Monday, January 01, 2007 2:37 PM
To: bugtraq (AT) securityfocus (DOT) com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux
malware]

While I agree that it is poor coding habits on the part of many
developers that are responsible for most PHP application security flaws,
nonetheless there are features in PHP4 which encourage these habits by
choosing insecure defaults. "Magic quotes" was one example.

of the powerful aspects of PHP, and of Perl, is the string-oriented
"typeless" approach where things magically become the appropriate type
(as compared to e.g. C, where you can blithely stuff an integer value
into a float and thereby corrupt the value if not cause a crash of the
runtime library when you feed this garbage to it -- no type conversion.
Strict typing requiring explicit conversion (with validation) improves
security by eliminating certain types of vulnerability. Java held some
promise in this regard but the associated libraries have many bugs
(e.g. one I just hit in JDK 1.507 for http proxy. a bug that wasn't
there in 1.4.2). course, the large number of available library code
is part of the attraction of Perl, Java and PHP; ML, for example, while
I have seen CGI code written in it lacks the broad developer community
(there is one, its just small compared to the more popular languages).

Jim Harrison wrote:
<Peeve type="pet">
"They" (developers) and "it" (the secure language) are both moving
targets.
There is no "genetic memory" with the human race; any more than there
is an "inherently secure" language. For every developer that learns
how to write "secure code", at least one more starts cutting his/her
teeth in the same language; possibly for the same reasons. Anyone who

insists that there either exists a "secure language" or that the
problem of "secure code" can be "completely solved" is IMH, severely
deluded.
Neither will ever be even remotely true.
</Peeve type="pet">

If you have issue with someone's code habits, address it with them
first. This is part & parcel to the "education" process. If this
fails because of their unwillingness or inability to adjust, then
you've done what you can. If this unresolved problem presents a
public disservice, then you report it. Public opinion is a powerful
motivator.

Jim
--
Message
From: Tino Wildenhain [mailto:tino (AT) wildenhain (DOT) de]
Sent: Monday, January 01, 2007 1:00 PM
To: Bill Nash
Cc: Kevin Waterson; bugtraq (AT) securityfocus (DOT) com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux
malware]

Bill Nash schrieb:

>*ANY* language implemented for *ANY* purpose is as secure as the
>
>

>programmer makes it. The way the original post is written,
>s/PHP/(Perl|ASP|C|bash|BASIC|four little buddhist monks fighting over

>an abacus)/ is applicable. The vulnerabilities that we see, that Gadi

>refers to, aren't widespread because PHP is widespread, but because
>insecure applications written in PHP are. A better use of energy
>would
>
>

>be focusing on the most vulnerable platforms and educating the
>
developers.

But aparently they aren't educatable - hence they stick to this
language. (Because of the many bad examples they can cut&paste code
from)

T.

All mail to and from this domain is GFI-scanned.

All mail to and from this domain is GFI-scanned.
No.10 | | 2678 bytes | |
No; this wasn't flame-bait, although I'd be silly not to expect some.
Let me make my position clear; the goals of secure coding and secure
languages are both grand and well worth the time spent.

There are two primary factors which make this an impossible task:

1. "secure" is moving, contextual target. That which is deemed "secure"
by today's standards will be "just ok" or "watta joke" by future
evaluators. What is good enough for Joe's Garage won't even make it in
the door of Fred's Bank (3 anti-social points for each reference),
although some could argue that Joe's security requirements should equal
Fred's, since they both pin their business on it.

2. Until the human factor is removed from both, mistakes and simple
ignorance will always render them both "less than secure" in any
context. This is the core of my argument.

Again; I agree with and fully support the effort. What I'm trying to
point out is the literal impossibility of actually achieving "genuine
security" in either our code or the languages it's written in.

Message
From: Darren Reed [mailto:avalon (AT) caligula (DOT) anu.edu.au]
Sent: Tuesday, January 02, 2007 2:58 AM
To: Jim Harrison
Cc: Dana Hudes; bugtraq (AT) securityfocus (DOT) com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux
malware]

In some mail from Jim Harrison, sie said:

and similar statements can be made for Basic (pickyourflavor) as
well.
This argument proves my point that there is no such thing as a truly
"secure" language; it's entirely dependent on the dev skills.

I disagree. But then the above could be taken to be just flame-bait.

In functional programming languages (think 4GLs like prolog), rather
than functional programming languages (2 and 3GL - C/Pascal/perl/etc),
the ability of a programmer to do something that exposes a security
problem is greatly diminished (if we exclude "shell escapes", etc.)

Where do 9 out of 10 security problems with applications arise from?

Dealing poorly with externally supplied input.

This is the crux of nearly *all* PHP security bugs.

Maybe our problem is that PHP, perl, etc, are all built on top of C and
in such a manner that the origin and trustworthiness of data is lost and
can no longer be delt with in an appropriate fashion.

So maybe there isn't a "secure" functional language yet but I can't see
why we can't develop one.

Darren

All mail to and from this domain is GFI-scanned.
No.11 | | 3379 bytes | |
"comment has nothing to do with either" - I'm addressing the
generalistic "genuine security" arguments offered in this discussion. I
have no contrary argument to the point that PHP in its current
incarnation is not designed to be secure; only that those who espouse
the idyllic language are in for a nasty surprise (if they're paying
attention at all).

"you're saying "genuine security" is impossible" - yes; that's
exactly what I'm saying.
I'm not trying to use it as a dissuading argument, only a reality check.

Message
From: Darren Reed [mailto:avalon (AT) caligula (DOT) anu.edu.au]
Sent: Tuesday, January 02, 2007 10:37 AM
To: Jim Harrison
Cc: bugtraq (AT) securityfocus (DOT) com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux
malware]

In some mail from Jim Harrison, sie said:

No; this wasn't flame-bait, although I'd be silly not to expect some.
Let me make my position clear; the goals of secure coding and secure
languages are both grand and well worth the time spent.

There are two primary factors which make this an impossible task:

1. "secure" is moving, contextual target. That which is deemed
"secure"
by today's standards will be "just ok" or "watta joke" by future
evaluators. What is good enough for Joe's Garage won't even make it
in the door of Fred's Bank (3 anti-social points for each reference),
although some could argue that Joe's security requirements should
equal Fred's, since they both pin their business on it.

This discussion is about secure programming and the problems related to
PHP. Your comment has nothing to do with either except to state that
what is considered secure by two different environments are actually
different (big deal.)

2. Until the human factor is removed from both, mistakes and simple
ignorance will always render them both "less than secure" in any
context. This is the core of my argument.

Again; I agree with and fully support the effort. What I'm trying to
point out is the literal impossibility of actually achieving "genuine
security" in either our code or the languages it's written in.

Well given that the ultimate root of any invention is going to be human,
you're saying "genuine security" is impossible.

I'm quite confident that someone could develop a very secure interpreted
language. It might not do a lot, but it could easily be done (even if
only to prove you wrong) - if one doesn't already exist. I could
probably even prove a case with /bin/sh.

The problem we have right now is that the language commonly used for
dynamic web pages on non-Microsoft platforms is PHP and that this has
not been engineered *for security*.

The goal of a language such as PHP should be to make it possible to do
what is required without the person using it needing to know anything
about security or secure programming practices. Just as people using
perl generally don't need to worry about buffer overflows, why should
people using PHP need to worry about SQL escapes and filepath issues?
They shouldn't.

Darren

All mail to and from this domain is GFI-scanned.

Re: new linux malware

EMSDN.COM

Question 'new linux malware' on 'Security'

Security

new linux malware